Drive – ASW #165

A new OWASP Top 10 is coming this month, which coincides with OWASP's 20th anniversary. A first question might be, how has the Top 10 list changed since its inception? But that's a question that accepts the premise of the OWASP Top 10 in the first place. As this new version points out from the start, "The OWASP Top 10 is primarily an awareness document." As a means of awareness, the Top 10 has become the catch-phrase for bad things that happen to web apps and a recognizable reference. Over time it's been a mix of risks, attacks, and weaknesses. In 2021 it's nice to see the list settling into a more coherent focus on root causes with associated CWEs as examples of common ways those underlying flaws manifest. But it's still not a list of specific vulns that you scan for or a prescriptive standard that you demonstrate adherence to. So what does appsec have to show for nearly two decades of awareness? To pose the question differently, how would you use this list? If two major items are insecure design and security misconfigurations, what tools and processes would you use to build confidence in a secure design and configuration? In other words, what's more relevant to your DevOps team today -- a catalog of CWEs or a framework (or paved road or secure default or analysis tool) that makes it harder to introduce these weaknesses in the first place?

Best practices are sometimes just good practices and sometimes irrelevant practices -- a lot of appsec requires context to understand a threat model and recommend security practices to address it. On the other hand, lots of bad practices are common practices that nevertheless should be replaced by better choices. In the same month we get a new draft of the OWASP Top 10, CISA gives us three bad practices. And where the OWASP Top 10 has some ambiguous actionability (it's an awareness project), these bad practices have clear actions that an org can take to address them. They might not be easy -- removing and replacing unsupported and end-of-life software is easier said than done -- but they're still useful goals to align against. After all, a goal like moving away from single-factor authentication (hint: adopt FIDO keys and WebAuthn) is measurable and impactful. Check out the discussion on GitHub at https://github.com/cisagov/bad-practices/discussions

Here's a vuln write-up that doesn't involve reverse engineering a binary or poking about in C code. Some researchers took a look at the recent patch from Atlassian that fixed an RCE and worked out how to exploit the original vuln. It's a nice example of diving into an unfamiliar area (OGNL) and applying an attacker mindset to the app's design in order to identify and exploit a flaw.

Ok, we're back to another write-up that involves compiled binaries and insecure C code. What stands out in this case is the successful use of fuzzing (AFL) to find yet another vuln in an image parser -- this time in Whatsapp's handling of GIF files. It seems that image files remain a profitable attack surface, which also seems to point to image handling code as an area to prioritize for refactoring into a more memory-safe language.

The details behind these flaws are perhaps more interesting than the bugs themselves. If you're using Node.js and either of these packages, then you'll want to upgrade. Just as you'd normally upgrade for any security release. What might be more interesting is the session in path sanitization and normalization. In this case, the code made the effort to normalize paths before applying security checks to them, but the code was subverted by some simple, yet clever, patterns. It's a nice demonstration of the need for comprehensive test cases. Plus, if your org has a more mature appsec or DevOps program, it's also a potential use case for fuzzing. Check out these advisories for more details: - https://github.com/npm/node-tar/security/advisories/GHSA-3jfq-g458-7qm9 - https://github.com/npm/node-tar/security/advisories/GHSA-5955-9wpr-37jh

The title may say it's tedious, but the truth is that this overview of tokens takes the topic seriously and provides helpful technical insight into common design patterns. It's not much of a spoiler to say JWTs are (quite actively) discouraged. The article provides clear, concise reasoning on why that particular construct is poor and how alternatives are more appealing from a security and usability perspective.

"Credential" is my word choice, here. Technically, the system's IMEI can be gathered without authentication, and then that "credential" used along with the owners email address provide enough authentication to disarm a system.

Ignoring the provider, the Unit42 guys did some good research, here. Let's focus on two things: 1) Look at figures 13 and 14, and think about how could someone running their own k8s cluster identify and remediate permissions issues like these. 2) Software supply chain is a popular theme in 2021. Should we also be asking for SBOMs from our cloud providers?