Finding a Use for GenAI in AppSec – Keith Hoodlet – ASW #323

Next.js provides devs with a toolchain to deliver React-based frameworks. Some bug bounty researchers discovered how to bypass its middleware controls by including a x-middleware-subrequest header with some easy-to-determine routes. (There's a wonderful nuance for some versions where it's necessary to repeat the value five times to trigger a recursion depth check.)

The consequence is that if the app relies on the Next.js middleware for authentication or authorization checks, then an attacker can trivially bypass those checks. If the app is enforcing such checks on the server side (not to be confused with rendering server-side React), then the app is fine.

Attackers compromised a project maintainer's GitHub Personal Access Token (PAT), created a malicious commit, used their access to point every release tag to the malicious commit, and watched as all the infected CI/CD pipeline Actions started logging secrets.

It's an example of shifting attack surfaces and another example of trust in supply chains. The commit masqueraded as coming from a Renovate bot, which wouldn't be unfamiliar at a glance from devs or appsec folks. But the commit wasn't signed. I'd hope that requiring signed commits would have prevented this attack outright or at least made the malicious activities more obvious.

As the recommendations section of the article points out, this is another good reason to pin Actions to known-good SHAs. That's something that feels like it's easy to automate and easy to include signature checks for.

Excellent research from the Portswigger crew as always. I couldn't pass this up because it hits on another favorite topic of mine -- parsers.

There are a few lessons in software engineering choices in this story. A long time ago, GitHub originally relied on the ruby-saml library, but switched to their own implementation in 2014 due to missing features. Their implementation received a slew of bug bounty reports, which led them to reconsider going back to ruby-saml. It's interesting to track the reasons behind choosing open source vs. building your own, forking projects, and improving security in open source.

The other lesson is in the ruby-saml library itself. It had code paths that led to two different XML parsers. One parser handled the manipulation messages and the other handled verification of the messages' signatures. However, the parsers exhibited different parsing behavior and tolerances, which is terrible for security. In this situation, it meant an attacker could insert any known valid signature (which is often easy to obtain) into an arbitrary message of their own and consequently log in as anyone else. The library saw a valid signature, but didn't validate that the signature matched the message.

Related articles:

• Sign in as anyone: Bypassing SAML SSO authentication with parser differentials - The GitHub Blog
• SAMLStorm: Critical Authentication Bypass in xml-crypto and Node.js libraries — WorkOS -- a different vulnerability with similar parsing problems
• A Survey of Parser Differential Anti-Patterns -- different ways parser mismatches manifest flaws
• XML Signatures are a bad idea executed even worse | SSOReady -- it's not just parsing that's the problem

This is one of those articles that takes the time to educate the reader with background context on a technical topic. The author gives a very nice overview of the Mach kernel, what makes its message handling between threads stand out, and how those messages are constructed.

Then it shows how a missing message verification step meant an attacker could leak credentials. The good news is that there's an existing secure design, both in access controls on keychain items and sender verification for these kinds of messages. This seems like the kind of bug that should be trivial to lint or have compiler warnings (or errors!) for.

I admit that this mostly caught my eye because the exploit example relied on an XML file. But the more important discussion points are around secure design choices and app behavior.

On one hand you have a feature intended to provide a better UX where "Windows Explorer automatically parses the contents of this file due to its built-in indexing and preview mechanism." It does this "automatically upon extraction to generate previews, thumbnails, or index metadata, even if the file is never explicitly opened or clicked by the user.”

However, that lack of initial user interaction or intent leads to a problem where a malicious file "triggers an implicit NTLM authentication handshake from the victim's system to the attacker-controlled SMB server. Consequently, the victim's NTLMv2 hash is sent without explicit user interaction."

For security and human sanity, it'd be nice to do away with XML altogether. But that wouldn't fix the underlying problem here. This needs some secure design answers to questions like, Should the preview wait until the user interacts with the file, What's a safe vs. unsafe file to preview, What are the security benefits and privacy consequences of proxying requests that a preview might trigger?

A very accessible high-level explanation of a new cryptographic foundation for the post-quantum world.

Now updated with more guidance on fuzzing.

What's the real world impact and exploitability of Rowhammer? Contribute to research that's trying to better understand the implications of this type of attack.