A Deceptive Dependabot, Insecure JWT, CISA Wants HBOMs, OpenSSF’s Critical Projects – ASW #257

Attackers impersonated commit messages to make the commits appear to come from Dependabot. The attackers apparently compromised the Personal Access Token of repo owners and contributors in order to execute the attack.

I wanted to highlight this as an example of shifting attack surface. Dependabot is a great tool with an excellent UX for developers.

One solution is to enable vigilant mode, which would make these types of malicious commits more apparent -- assuming attackers didn't also compromise the contributor's keys used to sign commits. But vigilant mode also seems to hearken back to the browser lock icon -- a subtle security hint about the identity of a site (or commit) that worked far better in concept than in practice.

Ouch. Here's a very simple example of a very classic JWT security flaw -- "using the none signing algorithm to subvert signature validation checks when verifying JWT tokens used for OAuth authentication."

It's a great article that walks through the attacker mindset in finding and exploiting a flaw.

It's also a chance to talk about secure by design and secure by default. The JWT design espouses cryptographic agility in the "alg" header, which is intended to provide options for what algorithm signs the JWT. But this has led to many security flaws, including the one in this article. When crypto agility is touted as a benefit, who is actually benefitting? How does it influence threat models? Is it a feature desired by security teams or a feature useful to developers?

Even the best practices RFC explicitly calls out the security problems that arise from this feature.

For comparison, check out how Paseto approaches this problem with default choices and a versioning scheme.

This week's Podcast Bill of Materials includes this article on a bill of materials for hardware. This is a good step for hardware and a direction that security should be heading towards in terms of better enumeration about what's in an artifact -- whether hardware or software.

But this all looks like we're still in the early stages of the concepts and adoption. If all the articles and discussions about this are still using metaphors with food ingredients labels, it feels like we're far away from having the S- and H-BOMs stand on their own in terms of delivering value.

We continue to watch the positive attention that the OpenSSF has been giving to the open source ecosystem, especially because it's doing much, much more than just pointing out vulns for devs to fix. It's been investing in the fixing and hardening side as well.

But the OpenSSF has real-world constraints of budget and developer time. So, where can its investments have the most impact?

This list of critical projects is one way to identify and prioritize where to invest that attention. It's also interesting to see what's on the list -- from the mature and historically secure projects like Curl and SQLite to the old and still useful somewhere projects like Perl to the infamous default-that-no-one-really-used-anyway of the log4j project.

This is one of those articles that I include in order to use it as a means to talk about a different topic entirely. Researchers have identified a new side-channel attack in GPUs. What stood out to me was a section near the bottom that talked about other browsers.

To quote the article, "Chrome is vulnerable to the pixel stealing attack demonstrated in the paper because it satisfies the following three criteria: 1. It allows cross-origin iframes to be loaded with cookies. 2. It allows rendering SVG filters on iframes. 3. It delegates rendering tasks to the GPU. Other browsers, like Firefox and Safari, do not meet all these criteria and are therefore not vulnerable."

This struck me as a way to talk about the consequences of design choices and how they influences defenses against classes of vulns -- even when those vuln classes are unknown.

This project was teased a few weeks ago in a blog post about a fun project coming, but no repo to go along with it. Now we have a repo to look at.

The problems that it's highlighting are meaningful ones to tackle -- SBOMs, provenance, compliance, asset inventory. But it also feels heavy on the problem statement with a framework for organizing all that metadata, yet leaving a lot of concerns about the completeness and quality of that metadata left unsaid. That's not to take away from the goals of this project, it's more about seeing where it helps teams more easily collect and organize this data, while discovering that a lot of process and tooling will still need to be implemented to make this metadata valuable.

The thing I found most interesting on this article is the RCE without user input. Usually remote code execution relies on the user taking some action, but in this particular case, RCE happened without the user doing anything at all, making this attack particularly insidious.

Not so much an article as an FYI: the RSA CFP is open, and I highly encourage you to submit your ideas!

The title of this Malware as a Service is what drew me to this article, but what kept me there is the idea that MaaS is an actual thing! For the low price of $250, you can buy BunnyLoader: a software that provides various functionalities such as downloading and executing a second-stage payload, stealing browser credentials and system information, and much more.

I'm filing this under "Lies, damn lies, and statistics."

That said, the point of the article here is this ChatGPT thing is not a silver bullet. It has great uses, but remain suspicious when either using or hearing about others use of AI.

Us ASW hosts are fans of bug bounties, but maybe not everybody out there is. Of note is the Zig Software Foundation (yeah I never heard of them either), who put out a post claiming bug bounties "damage" open source projects

h/t hackaday. https://hackaday.com/2023/09/27/do-bounties-hurt-foss/ has more overall comments on the subject.

OK lol no those guys don't question their choices. I do! but looks like there's a buffer overflow vuln on the port 25 smtp listener. Patch now and patch often!

On the cloud security side of things - or just opsec in general - honeypots have always interested me. But running them in prod - keeping them "up to date," reviewing the findings, etc - does require dedication. It's nice to see that a cloud provider is running one of these, and using that data to feed their security products.

There's at least one startup out there I'm watching that also is working on making Threat Intel usable for the org that doesn't have 10+ security people to sit around writing rules. Without this type of thing, personally I think the "security data lake" is sorta pointless, unless you're a storage vendor.

Over the last few years, a corner of the container/cloud-native security space has turned to eBPF to answer all their questions and solve all their problems. But...eBPF wasn't created for security or monitoring. Trail of Bits has a good blog pointing out the issues here, and how to work around them (I had this listed for ASW 257, moving to 258 as we ran out of time)