Building a Scanner and a Community with Zed Attack Proxy – Simon Bennetts – ASW #254

A secret key makes its way into a crash dump. That crash dump makes its way from a prod environment to a debugging one. A threat actor makes their way into an engineer's system with access to that environment -- giving them a key that can be used to forge access to mail systems even though those system shouldn't be validating the unexpected scope of that key.

And that's just the start of the appsec lessons to take from this breach.

Many articles covered this:

• Storm-0558 Update: Takeaways from Microsoft's recent report | Wiz Blog
• Microsoft details a chain of mishaps leading to Outlook hack on government officials
• Microsoft: Compromised Account, Series of Errors Led to Email Cloud Hack | Decipher

Our exposed secrets episodes continues with a signing key logged in cleartext because a legacy CI/CD system couldn't support the preferred centralized solution.

We could also go on about the poor UX of GPG keys, but there's plenty to learn from this in terms of handling keys and designing systems where security controls are consistent wherever those keys go.

This one's a bit older, but fits in with the theme of stolen secrets. Here's an example where an app uses a default, hard-coded secret -- and, of course, no one changes the default. The researchers scanned over a thousand instances and found more than 70% still used this default value. Those numbers might not feel impactful in the grand scheme of the internet, but it's very significant in terms of design anti-patterns.

Also check out their previous post on the topic.

We've seen parsing problems previously. We've specifically seen URL parsing problems. And now Rust joins the list with a problem that leads to path traversal(!).

I like how the writeups walk through the feature (an XInclude element in XML), the steps they took to identify a payload that could bypass validation, and the easy way they bypassed canonicalization.

Check out additional details in the issue's discussion page.

I came across this one from Risky Biz News.

I love talking about newly found bugs with ancient histories. This is a nine year old bug in the nftables feature in Ubuntu's kernel.

What's notable here is that this isn't an obscure area of code. The researchers even state, "Throughout 2022 and 2023 more than a dozen vulnerabilities were found in this subsystem and multiple LPE exploits relied on them.”

What stands out for me is how they described their approach in choosing what to audit and the question is brings up about when audits have found all the useful bugs. After all, if we spend time continuously auditing one section of code, that means other areas are being neglected.

In other words, when do we know we've had enough eyes to find all the shallow bugs?

Not much to comment on here. Rust is dealing with the growing pains of curating a package manager and its packages. But the language is also eight years old. At what point should these growing pains and solutions to typosquatting and malicious packages have been introduced?

I use jq a lot, especially as part of the toolchain for how I generate the wordclouds for the "Describe appsec in three words" prompt to our guests.

I included this because it shares a theme of maintaining OSS projects we touched on in the interview segment with Simon Bennetts of Zed Attack Proxy.

There aren't too many details about the exploit itself, but I wanted to note this as a win for the iPhone's Lockdown Mode. We can talk about strategies like architectures that isolate parsers from more privileged code (like the "Blast Door" introduced to iPhone 14), memory safe languages (there's a lot of legacy C and C++ still to be replaced), and fuzzing to proactively find more vulns (images are an especially good target for fuzzers).

But Lockdown Mode introduced an additional approach -- give the user a choice between a convenient UX and disabling some features that are historically popular attack paths.

Another quick article that I grabbed mostly to reference our discussion with Eve Mater about identity and privacy in cars back in episode 249.

The CNCF has released the latest version of developer's thoughts on Web Assembly. There's some interesting stats in here like 30% of respondents are using wasm for WASM, what draws them them to WASM(speed), and that COBOL is the primary language in 3% of WASM apps (what?).

We don't see too many rewrites of open source packages. Looks like the memory safety group have decided to rewrite sudo in rust.

As hard as it would be to do, it'd be interesting to see how many issues this actually mitigates...

Brian Krebs has a story on what looks like a pattern of crypto theft that seems to point back to data stolen from the lastpass breach and then cracked.

What's the appsec takeaway? How would you ensure that if your sensitive data was compromised, that it couldn't be easily(for various values of "easily") cracked?