ASW #229 – Nick Selby

Reddit provides a transparent report on a recent breach. The attacker succeeded in phishing an employee. However, "soon after being phished, the affected employee self-reported, and the Security team responded quickly."

It's good to see there seems to be a positive culture around security and that the compromise was handled relatively quickly.

However, the post still repeats the trope that humans are the weakest link. They're not. Humans are betrayed by bad threat models along with insufficient tools and processes. Even the xkcd comic they link to speaks to this -- your threat model should include that $5 wrench and, depending on the risks that come with compromised credentials, consider something like a $50 Yubikey to counter it.

(We could also mention threats to employees, personal threats for owners of large cryptocurrency wallets, or insider threats from individuals who have legitimate credentials for illegitimate purposes. But let's just kill the trope, not the joke.)

We always appreciate a well-written post with technical details and a story about an attacker's mindset. And occasionally I see a story with flaws that make me shake my head in disappointment. This one has two such flaws: access controls apparently implemented in client-side Angular(!?) and an impersonation API that allows for minting arbitrary JWTs.

I always wonder how no one else found such dead simple vulns before the author, which they disclosed and Toyota fixed. The end of the article points out an important motivation of bug hunters. There was no bounty available. The researcher did the right thing in disclosing the bug, but indicated they'll likely turn their attention to sites with bug bounty programs.

Normally, that lack of incentive would be a loss for the site. However, with such basic vulns present, the site probably needs a good security review before kicking off a bounty program. Otherwise, they risk wasting money on discovering lots of basic flaws that could have been found more efficiently.

Here's a video from a conference oriented towards bug bounty researchers. This particular one hits one of my favorite topics, regular expressions, and one of my favorite payloads, null bytes (%00). It's a detailed walkthrough of regex failures and fuzzing URLs with ranges of characters to find those failures.

Slides are available on their GitHub repo.

Another memory safety issue, this time in the ASN1 parser where a field is mistakenly treated as an ASN1TYPE instead of an ASN1STRING. A size mismatch leads to disclosing some memory, which isn't good for a service that handles secret keys.

The bigger point is that OpenSSL should be on its way out. Its design leads to mistakes and misuse. It has too large an attack surface, although the post-Heartbleed era got rid of many insecure algorithms and poorly supported platforms.

OpenSSL 3.0 promises more improvements, so it's not likely to go away soon. Rustls is a Rust implementation of TLS, but it's not a drop-in replacement for OpenSSL (nor is it intended to be). Hopefully we'll start to see OpenSSL shift towards use in legacy systems and memory-safe alternatives become the preferred library for new projects.

The OpenSSL advisory is here.

A client-side path traversal technique, a reference to Dirty Dancing for OAuth techniques, and the ongoing browser desync attacks -- those three alone made me happy about this list.

Here's a bug bounty report that highlights a distinction between security and privacy. The API works as intended, the bug doesn't appear to cross any security boundaries or otherwise break a security assumption, but it still has a privacy angle that should be addressed. The industry is still just starting to see privacy engineering teams. We don't exactly need new terms like DevPrivOps or PrivOps or AppPriv(?), but the appsec industry should be giving equal weight to privacy issues.

NIST announced the list of finalists for cryptographic algorithms in IoT and other small devices.

Each one comes with a reference software implementation. Sadly, these implementations are still predominantly all in C. There's a nod to Python, Java, and Rust, but if we want to move the industry towards memory-safe languages, we need more memory-safe examples of how to do so. This is doubly hard for the constrained and performance sensitive environments like IoT, but cryptography would be a wonderful leverage point to encourage that transition.

One of the motivations in this migration from a monolith to microservices was an impending EOL for Python 2. We could consider that one appsec angle.

But the bigger appsec angle is gaining an appreciation for the estimation, planning, and execution of a major software project. Better appsec comes from understanding how services are designed and built in the real world. If we only ever made pronouncements about how things ought to be and only ever relied on lists, then we'd build a world with secure code in theory that would never become practice. This article is full of insights and ideas about influencing large projects and making them successful. Appsec always talks about security awareness for developers, think of this as developer awareness training for appsec.

Here are two other articles from different authors in a similar vein of understanding the developer perspective on coding:

• https://research.nccgroup.com/2023/02/08/rustproofing-linux-part-2-4-race-conditions/
• https://nullprogram.com/blog/2023/02/11/

Why is not being able to delete your DMs a security risk? Well, these DMs are not end-to-end encrypted. They are still potentially available on Twitter's servers after 'deletion' and can be viewed internally as a result.

A counterpoint to Mike's article on the Reddit hack, this article argues that employees are indeed a vital part of defense, as MFA continues to be circumnavigated.

Good writeup of poking around Docker for Windows, finding named pipes, then managing to leverage those pipes to break out of the container. I like the part at the end that talks through how to weaponize these things, as rebooting a PC is a pretty obvious tell that something's going on

AWS has been growing around 1600 new APIs per year for the last 6 years, and is now around 12k APIs.

Also, the API permission sets is sorta bonkers. AWS has more than 18k API privileges, Azure around 13k, GCP around 7k. Good luck controlling that.

Interesting piece on two particular cultures of programming - sure, there's tons of different ways we can slice these beasts up, this is just one example. While I think us appsec types can talk a lot of trash about the "culture 2" types, there's good reasons for their existance.

I'm linking to Visual Studio Magazine here as they're focusing on the .NET aspect of this report. I wouldn't have expected .NET to be the cause of so many issues.

(and yes, VSCoders - we get that .NET is not a programming language)