Cracked Concatenation, Injection Against DNS, Allstar GitHub, & DEF CON Highlights – ASW #162

This is a really cool and simple vuln -- a researcher noticed how Steam was concatenating name/value pairs when creating input to a hash function. The intent was to track the integrity of a request during a checkout flow. However, they made a subtle mistake in not placing delimiters among the concatenation, thus leaving an attacker able to influence the final string in a way that would allow them to make arbitrary transaction amounts. In other words, the semantic distinction got lost between what should have been a field like "amount" with a value like "2000" and "amount2" with a value like "000", which then enabled the attacker to sneak in an arbitrary amount value of their own. The take-away: The nature and cryptographic strength of a hash function doesn't matter if the assumptions in the data to be hashed are broken; include delimiters when hashing concatenated fields that may have user-influenced values. Be sure to check out the bug bounty report https://hackerone.com/reports/1295844

This is a fun read even if you aren't familiar with the details of DNS. It hits two particularly favorite topics: Protocols and parsing. The researchers took some very simple payloads, like a NULL byte and escaped characters with a backslash, and found mismatches in how various libraries handled these within DNS packets. What's fun (from a security testing perspective) is that the researchers found new life in these very, very basic and very, very old payloads. It's a good lesson in parsing and handling data, with an extra challenge of keeping track of the semantic context of data separate from what syntax characters might show up in surprising places. That kind of issue is one reason we still struggle with XSS to this day. Check out the research paper at https://www.usenix.org/system/files/sec21-jeitner.pdf

The Open Source Security Foundation continues to push on ways to mature the secure SDLC. In this case, they're looking at "continuous automated enforcement" of policies within a GitHub repo. The current list of policy and enforcement may be small, but the key is in have clear policies with actionable recommendations. And bonus points for automating the process so DevOps teams can focus on building software while their bots monitor for security issues.

Here's an article that gives us a chance to revisit programming languages and whether or in what ways security should influence what a team chooses. While there can be some technical reasons to build a case for or against a language, it's more likely that your processes and tooling -- combined with secure design -- will contribute to the security of an app more than the language will.

"Have logs" shouldn't be the only recommendation a security team delivers to DevOps. It's important to understand the context of when logs will be used and what's helpful for them to contain. It's also important to be aware of the dangers of logging too much -- especially data like personal information or security tokens. Check out the related DEF CON talk at https://youtu.be/_Ti_ZmMvIHA

Here's another talk that came out of this summer's slew of security conferences. The takeaway isn't so much about getting to a specific definition of DevOps or DevSecOps, but what it takes to bring security into a regular practice of software development. It includes some helpful examples of what worked and what didn't work when trying to engage DevOps teams. Check out the DEF CON video at https://youtu.be/JRWH8AdPpeE

ML is the magic word that gets bandied about as a solution in all sorts of problem domains, including security. Regardless of whether it's fancy if-then statements or fancy math, the systems are complex and their normal operation can be difficult to understand. This research highlights once again how adversaries can ML models and take advantage of behavior in surprising ways. One way to generalize this idea beyond just ML is that, when threat modeling, make sure you have team that can be both creative about ways a system might be abused and enough domain knowledge to be able to evaluate risks that might be practical, hard, or hypothetical.

Some simple vulns that raise less simple questions. The vendor took quite a long time to respond to and resolve the bug, which sadly isn't uncommon for situations like this. That's usually a reflection of an org's appsec maturity or when bugs are complex and nuanced. Of course, there's nothing to nuanced about a classic XSS via img onerror. Another question is what design discussion or constraint led to an endpoint returning a user's hashed password as an intentional choice. Check out the original disclosure at https://labs.bishopfox.com/advisories/wodify

We've seen voltage "glitching" on smaller microcontrollers, but now researchers are seeing value in the method with modern "full" CPUs.

One of the nice things about the RISCV architecture is the open source design which allows researchers to more easily create projects like this, to make it harder for quantum computers to break cryptography