ASW #195 – Lynn Marks

Bypassing client isolation in multi-tenant cloud deployments is major goal of attackers and researchers. Here's yet another series of vulns from Wiz.io that achieved this against Microsoft Azure. There are a lot of details to think about in this article. One of which is how a poorly crafted regex enabled this attack. On the positive side, the regex used anchors to match from the beginning to the end of a certificate's Common Name. Forgetting to anchor text matches (and forgetting to ensure the test is handled as a single-line instead of multi-line) is a common security mistake because it allows an attacker to prepend or append arbitrary text to what an app is expecting to see. Unfortunately, adding an unrestricted wildcard at the end of a pattern mostly negates the end anchor, which is particularly important when checking certificates -- you always want to match the full domain when you're basing security decisions on domain membership. Check out Microsoft's disclosure at https://msrc-blog.microsoft.com/2022/04/28/azure-database-for-postgresql-flexible-server-privilege-escalation-and-remote-code-execution

The article has a sentence that summarizes this change well, "Google is effectively killing a feature that is not widely used and is gaining a huge security benefit as a result." In other words, rather than accommodate a feature that's used in some situations to weaken the Same Origin Policy, Google is closing off that insecure design pattern in favor of more secure alternatives. It's a good step (albeit a small one) towards making the browsing experience more secure. Read Chrome's decision and recommendations on how to migrate away from this anti-pattern at https://developer.chrome.com/blog/immutable-document-domain/ If you're really curious about the process of proposing and discussing impactful changes like this, check out a W3C thread on the issue at https://github.com/w3ctag/design-reviews/issues/564

We're a fan of making fuzz happen. Even if it's going to take a while for fuzzing to become a regular part of the software development process. This article provides insights on Go's fuzzer along with recommendations on how to improve it to be better at identifying flaws. One improvement is being smarter about understanding and manipulating the grammar of protocols like HTTP. Being able to use grammar and syntax that an app expects helps a fuzzer reach -- and therefore disrupt -- more states that the app can get into. Other improvements are very tactical in terms of manipulating bytes and variable encodings like little endian base 128. Creating more flexible fuzzers should lead to more reachable states and a wider variety of flaws to discover. Unrelated to Go, but also on the topic of fuzzing is this article from DoyenSec, https://blog.doyensec.com//2022/04/26/vbox-fuzzing.html. It describes the practical side of setting up and running fuzzers, in this case against VirtualBox device drivers. If you're interested in setting up a lab to experiment with fuzzing, this would be a good start.

Thinkst have published another round-up of presentations. These have always been great ways to discover interesting conference presentations and, thankfully, the PDF isn't behind a marketing page or registration wall. For the appsec population, the "Low-level, but high-privilege bug hunting" section covers five presentations that get into technical detail on mostly hardware and kernel-level issues. Then "Confidential computing for the masses" covers two approaches to protecting data within Kubernetes and observations on making post-quantum cryptographic algorithms more accessible for implementers. Skip to the "Nifty sundries" for broader appsec issues. "Attacking JavaScript Engines in 2022" is fun and "Why no one pwned Sinology at Pwn2Own and Tianfu Cup in 2021" offers insights into the positive impacts of following a secure SDLC by implementing good defaults, applying sandboxing principles, and taking steps to make attackers work harder when crafting exploits.

We've touched on this in the past and this article is still in the category of the calling for a CVE-like system, but it's worth popping back up briefly to tie into the Azure vuln from Wiz.io we also cover in this episode. Perhaps one of the biggest questions about a need like this is who would the audience be and how would they use this information. For example, this week's "ExtraReplica" in Azure doesn't require any user action. So, how do we create new information sources -- or perhaps present new information sources -- in a way that helps users make decisions rather than just become another list.

A list! But...not really an interesting list? It seems to boil down to log4j, running Exchange Server, and a smattering of VPNs. It's relevant if you have one of those three things, but otherwise doesn't feel like it has a broader lesson or point of discussion on app security or architectures. However, path traversal made the list as one of the attack vectors, so it had to get a mention just for that.

We've covered a handful of Linux kernel vulns recently, but that's because the articles have all been excellent examples of explaining a complex topic. We'll (almost) always highlight articles that walk through the attacker mindset, from describing the basics of the app being targeted, to describing its attack surface, to walking through the trial-and-error steps of probing security boundaries and trying various techniques until a flaw falls to an exploit. Plus, we haven't covered race conditions and TOCTOU concepts very much, so this gives us a chance to expand the range of flaws we discuss.

From this year's PyCon (https://us.pycon.org/2022/), here's a curious foray into the browser, HTML, and Python all bound together with WebAssembly. It demonstrates an emerging area for appsec practitioners to keep an eye on. The project is based on the open source Pyodide, which you can find at https://pyodide.org/en/stable/