SPEAKER_01 0:01

Hello, it is Wednesday, October 28th. My name is Jen Guile. I have Paul McCurdy here with me. We're the co-founders of Open Source Malware, and this is the open source malware show where we talk about the week's malware news, trends, etc. This week on the agenda, we're going to be talking about the postmortem that Late LLM put out. They shared how they ended up getting compromised a second time. We're going to talk about a little campaign. But first, we're going to kind of break our norm because the last what, seven to ten days, Paul, have been a little rough for people working in cybersecurity. You know, between PHP and broadly, there's just been a whole world of hurt for um security teams having to go in and figure out if they're affected by recent vulnerabilities. Normally we wouldn't talk about vulnerabilities because uh by definition, they're not malware. However, uh we are kind of suspending that for today to talk about broadly.

Paul McCarty 1:22

We have an embargo. We're gonna we're gonna talk about we're gonna talk about vulnerabilities today.

SPEAKER_01 1:26

Yeah. Uh but yeah, first things first, like hearts go out to everyone who's been dealing with this. I've been in a couple different conferences over the last couple weeks and a lot of stress going around. Um, whether these are exploitable or not, or you know, exploitable in your environment, kind of at the end of the day, doesn't matter. For a lot of people, they still have to deal with you know identifying where it is and fixing it. And that just that stinks.

Paul McCarty 1:53

Well, and and dropping everything that you're doing right now, all your normal kind of keep the lights on kind of stuff in project work and having to go into incident response mode. I think this is a great way to start to talk about this whole last couple of weeks. You know, the it it really, you know, the Vonepocalypse, we've been talking about it for ages. The the PHP to shell thing kind of really started this latest wave. And I want to talk about PHP to shell, not because I give any uh beeps about it, but the because it it's part of the kind of mindset that is that we need to talk about, which is you know, there's just a lot of um hype about this uh set. There's two um two now three uh CVE's vulnerabilities. I mean, the NSA, the NSA came out and made a tweet saying, you know, if you've got PHP apps, you should probably take them offline. There's just like the hyperbole and the hype behind this. We've noticed.

SPEAKER_01 2:51

Yeah, the whole turn everything off guidance is unusual. Um that's that's a big step. Um, there's definitely a lot of people talking about, you know, kind of the world that we're in right now where these are AI discovered vulnerabilities, and you know, it's able to find things that have been around for a long time that nobody human could find before. Um, our friend Josh over at the open source security podcast uh published a really nice op-ed um about responsible disclosure. I'll share that in the chat because I think the future of responsible disclosure uh certainly probably does need to change. Um there have been some moves to, you know, for certain ecosystems to say we're no longer going to require confidential reporting for uh, what is it, low and medium grade vulnerabilities because the volume is just too high. Um, the responsible disclosure process is heavy and bureaucratic, and getting it right is really hard. And so certain ecosystems organizations have decided to reserve that process for only the worst of the worst. But I will share that article and then Paul, why don't you talk about why you went deep on Bratley specifically?

Paul McCarty 4:26

Yeah, that's a good question. Uh before I do that, I just want to finish this thought, this high-level thought about the Volm Pocalypse. And so we had all these people telling us to turn off these PHP apps, and you know, just everybody was talking about it. It was in the mainstream media. And what happened is there were no exploits initially. Like basically, we were just watching all these failed attempts, and just there was millions of non-effective uh pox, proof of concepts, and exploit code. And I actually talked to a friend of mine. This is a true story. I talked to a friend of mine here in Australia who spent a whole day trying to build a detection based on a set of exploits that he found in GitHub. Turned out those exploits were junk, they didn't actually do what they were supposed to do. And so he wasted a whole day, did not have at the end of it a detection for PHTB. Now, you know, so for multiple days, there was no actual exploits happening, and all these people telling us that we're not seeing any exploits. And what happened is I think the the the zeitgeist is now, oh listen, we over we over-reacted and we turn stuff off, and look, it's an it's a nothing burger. So meanwhile, and here's where this is all going. Meanwhile, uh shortly off after you know the PHP to shell um exploits or sorry, vulnerabilities were announced, another set of vulnerabilities were announced, um, where which actually go back, have their have their roots years years back. Umperva and somebody else announced this set of vulnerability or this one vulnerability in the Brotly decoder, but only a node. And they named it node to shell. And that was like this is not me, you know, slinging arrows, but it was just a bad name because it implied that this only affected node. And it turns out the bug wasn't actually a node. Well, it was, but it was in Bratley and you know, node you know, 20, 22, and 24 bundled in Bratly. So, anyhow, there's there's a C decoder called Bratly. I've used it before, I was familiar with it. It's owned by Google, it's an open source project managed by Google, and um it's everywhere. And because it's C code and because it's tight and it does its job, it's a lossless compression algorithm. It basically uses keywords, so basically, instead of having to use these big long pieces of text, it uses these like these keys that replace that text that are much shorter, and then you just add a bunch of those together based on the uh the chance that certain strings will be in text. It's a very, very effective compression algorithm, anyhow. Encoder and decoder. The bug was actually in the decoder process, not in the the compression part of the algorithm. This C code is vendored into everything. I found it in Rust, I found it in PHP, I found it in Python, I found it in everywhere. So nobody was everybody was just sleeping on it, and that's why I jumped in. So like I hate doing I do disclosure all the time. I hate it because people treat me like crap. Um, I really get frustrated um and I get pissy because people are not treating me well, but I had to do it for all kinds of different stuff. So Microsoft, Click House, um uh Rust, Python. I made I don't know about 15, somewhere between 15 and 20 disclosures.

SPEAKER_01 7:40

Cloudfair Basil.

Paul McCarty 7:42

Uh yeah, yeah. Oh yeah, that was the Basil registry. That was heaps of fun. Uh in a future, in a future talk, we'll talk about why all these projects are telling you when you disclose things to them, use our bug bounty process. The problem there is the bug bounty triagers think that you're a bug bounty researcher and they they apply the same kind of process to you. And all you're trying to tell them is like, hey, you're using an old version of Brotly inside of this package on Basil or Cloudflare worker D or whatever the case may be. And they're they just they don't know how to ch to to modify their workflow, and so they just close these tickets. And then so then the Basil just didn't do anything about it, right? So, anyhow, that's why I got involved. Sorry, that was a that was a stream of consciousness. I apologize, audience, but that's that's why I got involved because nobody was. People were sleeping on it, and I just saw this stuff everywhere. I was familiar with the library, so I just jumped in. Um I got a at least one CVE out of it, which is interesting because it's my it's my first Microsoft CVE in I don't know, 20 years or something.

SPEAKER_01 8:46

But um well, what do you want people to know about what's going on with Bratley? Because it doesn't seem like it's necessarily getting the same level of awareness as the PHP one, which I think perhaps is the point that you were making earlier that you know there's so much attention on this PHP one, it turned out to be a little bit of a nothing burger. Perhaps that has overshadowed what's going on with Bratley.

Paul McCarty 9:14

Yeah, that's exactly it. That thank you for condensing that into a cogent uh couple of sentences versus my stream of consciousness. That's exactly the point I was trying to make was that people are sleeping on this. Um and this bug is in more places um and it's in more stuff. And I'm not discounting the PHP to shell. There are now we are now seeing genuine in the wild bad guys exploiting PHP to shell, but it took a while for it to happen and it's hyper complex. Meanwhile, Bratly's everywhere. And because Bratly's vented, I think there's a really important thing for our listeners that aren't software engineers. Uh I want to make this really important distinction. When I have a piece of software that calls a package and that package has a vulnerability in it, it's relatively easy for me to find it and track it because I can just look in the package manifest and find it. Well, here's the thing this C code is what's called vendored. In other words, people just grab you know these uh 1100 lines of code and they just drop it into their code base. So they're not calling a package. They're not a lot of times they don't even mention Bratley. They just grab the C code and they put it in and then they call the C code, you know, from their from their project.

SPEAKER_01 10:27

And because of that, you have to like hunt for the presence of well, and this is what makes C particularly challenging for SCA, for example, because you just don't know what your dependencies really are. Um, but you wrote a little how to discover if you're a vulnerable set of um steps. So first off, you're gonna search for those bundled copies. Since you can't just search your dependencies, you can grep um for the vendored code, um, you know, look in container images, there's a whole bunch of places, uh, manually upgrade what you're able to. So Bratly has, you know, patched it. You can directly consume that. Uh, if you're consuming it through a product that hasn't patched it yet, which it's been a week. So I would really hope that it's all patched, but I think things are still rolling in. Um, there are some things that you can do, which are covered in the bro blog. Um yeah, anything else that you want to kind of encourage people to take a look at as they're figuring out if they're affected?

Paul McCarty 11:34

We're this is gonna be log for this is gonna be like log for J. I've said this multiple times now. Like we're gonna be finding this stuff for months. I mean, that the long tail of this is gonna be long. Um, and so uh I I will you know encourage people to take a look at uh our blog post, which which Jen just mentioned. I need to add a few more things to it. Um, but basically what you're looking for is you're looking for the presence of the of the decode.c and.h files, which are the C files. And then the easiest detection is to find out does this file exist and is there this particular string in it, which is actually the fixed copy. Now, if you find that you've got a decode.c and you don't have that string, well, there's a pretty good chance that you're running an older version of Brotly that has the decoder um problem. So it's an unusual one to to um to find, but it you can find it. I found hundreds, uh not hundreds, sorry, tens of thousands of examples of it in in GitHub. Um so I'll make a promise to to strengthen some of those kind of search sections inside the blog post. But what's there right now is a really, really good place to start.

SPEAKER_01 12:37

Great. Why don't we uh move on and talk about malware?

Paul McCarty 12:42

Let's do it. Vulnerability gone. And go back to like there's two types of software risk, and we're not gonna talk about vulnerabilities, right?

SPEAKER_01 12:50

We're we're done with that. So uh let's talk about light LLM. There's a couple of links that I'll share shortly. Um, they put out a retrospective uh last week, early this week, time is funny, um, about the most recent compromise. Um, because this is the second time they've been compromised this year. We did talk about it last week on the pod. Um this compromise was a malicious version that came out in 1.107.0. It was related to a credential that leaked way back in May, I think it was. And um you know, I definitely was interested to see the retrospective because the way that they got breached the first time was related to the team PCP compromise that started with TRIVI and you know, cascaded like a true supply chain attack. Anybody who used TRIVI was susceptible, as far as we understand. That's how light LLM was compromised back in March. Um, this recent compromise is in no way related to that. So as we kind of um speculated last week that this is not team PCP behind this, at least it doesn't appear to be anyone who is affiliated with them. It's not affiliated with that original compromise. Um, but what they said was back in May, they committed a configuration file to a public repo, and it accidentally contained an admin key to an internal deployment of their platform. So they they leaked a secret. Um, they said that they identified it quickly, um, deleted the file, uh, noted that the keys required revocation, but uh through some error, they said human error, the original commit actually stayed in the repo's public history until October 22nd. Um and so two problems happened here. Number one, that commit should not have been in the public history. It contained a leaked secret. And number two, uh, nobody followed through and revoked the admin key. So it was still valid when the threat actors um came around to use it. So fast forward to October on the 10th, the threat actor used that leaked key to gain control of their uh deployment. That's how they were able to push through a malicious version.

Paul McCarty 15:25

Yeah, I think there's there's a really interesting um uh paragraph in the Hacker News article, and I'm gonna read it verbatim here. They're talking about how the threat actor was able to use, get access to and use the token. The restriction was relaxed earlier this week to accommodate the temporary push for more frequent releases and bug fix backports, allowing any two engineers to trigger and approve a release. As such, the threat actor used one of the tokens to trigger the release after having repointed the deploy deployer to their malicious repository and another to approve it. So I think that's a really important distinction. Basically, after the the um team PCP hack, they put a bunch, and we were talking to the team, like kudos to this team.

SPEAKER_01 16:11

They actually their maturity is overall pretty good, and I there's a I think they learned a lot from March, and this was just one of those, like, uh, that sucks. Like I remember being impressed into the best of us 100%.

Paul McCarty 16:25

Like, I remember their response in March being really it was quite good. Yeah, and I was surprised because a lot of other teams, much more like check marks, a really good example, just to pick on them. You're right. Their their response to their particular compromise was they just ignored it, they just you know just ghosted response. Whereas Light LLM took it on the chin, said, Hey, listen, we weren't doing some things right, we're gonna do things better, which I thought was awesome. And again, the same kind of thing here, they're being very transparent. But the important thing in reading that paragraph is to stay to say, you know, developers want to be able to push changes, and so what they did is they relaxed one of these controls that they had in place you know since March and uh when they were originally attacked, and that allowed the attacker to then be able to use the token and and you know onwards from there. So you know, you just gotta constantly be vigilant, man. Let's just say I need to weigh every deployment and and integration decision that I make in these complicated CI CD pipelines that I've got against the I the fact that there's a security concern here, and we're not necessarily gonna understand there's not we're not gonna have visibility, the team's not necessarily gonna have visibility on what that threat potentially is. So it's constantly kind of weighing the two together.

SPEAKER_01 17:40

So again, yeah, it's a bit of a um uh uh what word am I looking for? Uh use case to demonstrate why threat modeling is a useful exercise. Um we actually we had the CEO reach out to us on LinkedIn and we haven't had time to follow up yet asking for some advice. And so let's like yellow a little bit, Paul. Um, you know, if you were sitting down with the team right now, not knowing more than what they've published publicly, you know, outside of doing some threat modeling and being a little bit more cautious about uh when they relax some of these controls. You know, given this was a pretty different compromise example from the March one, you know, the the improvements that I'm sure they implemented in March maybe wouldn't have prevented this. Uh, what would be your advice?

Paul McCarty 18:36

Well, I mean, I'm cognizant of not giving a lot of advice right now because I don't understand the exact chronology of and exactly what they had enabled and what they didn't, and how many users had access to what and stuff. So I'm gonna give general advice, which is you know, to your point about threat modeling, we have to have this hat on. And software engineers, like our job is to deliver features as quickly as possible and as robustly as possible, right? But the reality of speed is always, literally always, the enemy of secure. And so every time you're like you're making a change based on the fact that you want to go faster, you know, if you want to push your the USS Enterprise to go even faster, you have to understand that you know it might start things might start flying off out off it. I don't know, that's a terrible metaphor, but you have to be conscious of those, you know, what you're what you're giving up when you make those changes to go faster. So um I know that's doesn't equate to technical um uh things. I think that some of the things that GitHub has implemented recently, for example, like the the GitHub um CLI token refresh thing now, I think that could have been a very helpful thing here.

SPEAKER_01 19:52

Yeah, there's something about, you know, uh more fine-grained scopes, shorter durations, things like that. Like this is kind of nothing new. Uh, I'm gonna share a resource uh for threat modeling. It's funny, I just saw this in the wild last week while I was in Barcelona. Um, Adam Schostack's pretty well known for threat modeling. His four questions um is sort of like deceptively simple and yet very effective. So for anyone who needs to do some threat modeling to look at how you might uh prevent this kind of thing from happening, I would suggest starting with that.

Paul McCarty 20:30

The other thing too is that in particular with the light LLM team, they opened up the ability to okay um uh these changes to a group of people. And you just have to be when you do that, you have to make sure that each one of those people individually, you have a conversation with them face to face, whether it's over a video conference or in person, say there's a responsibility that comes with this now, right? We want to go faster, but each one of you holds the key to allowing us to be able to push these things, understand that comes with consequences, and take the time to look. And I'm not saying those people didn't do that, I'm just saying that's what we have to do, right?

SPEAKER_01 21:04

Yeah, you've been given that you think, oh, go ahead.

Paul McCarty 21:07

I was just saying when you've been given that responsibility, it's a responsibility, right? It comes with you know trade-offs.

SPEAKER_01 21:14

Uh no, I as somebody who was on an airplane today, it reminds me of the talk that you get from the flight attendants if you're sitting in the exit row. You know, do you understand? Are you prepared to do this? You know, everyone has to answer in the affirmative before that plane takes off. I mean, it's kind of oversimplified, but same concept, right?

Paul McCarty 21:34

Yeah, agreed.

SPEAKER_01 21:35

It's a responsibility. Last topic that we have is um related to hold on, I'm getting my notes. They're here, they're here, they're here. Um so there was uh a resurgence in the Malfex campaign oh early in October that we documented at the time. It's in our um threat reports. But uh didn't really give it a whole lot of extra thought. Um, this is a campaign that's been going on since uh 2023. Uh it's assessed to likely be the work of a lone threat actor. Um there's some indication that they're a Portuguese speaker. Um it is uh it contains Windows malware where it's gonna um use uh sorry, it's gonna have Overlord, which is a rat written in Go. Uh always like it when I see the mixed uh language ecosystem malware because this is an NPM package or a collection of NPM packages. So it's gonna start with this Go um rat that uses Solana transactions to extract the C2 address. Um it includes uh an install uh of a whole bunch of stuff that targets uh Discord browsers, telegram, crypto wallets, and it has a downloader. Um the reason that this caught my attention is there was actually an article published a couple days ago that's related to this. So um a security vendor found in one of their um customers uh within the developers downloads folder, they found a malicious instruction file. It's a um agents.md file that was trying to get uh the agents to execute a set of steps that you know were not uh from the developer. So we're seeing kind of an interesting evolution here with this campaign, right? Um I think the natural language uh AI prompt injection stuff hasn't taken off perhaps as quickly as we thought that it would, or perhaps we're just not as good at catching it. That's totally possible, also. But um, Paul, you and I were talking about this one beforehand. One of the things that makes it really unique is a malicious image file.

Paul McCarty 24:04

Yep. Yeah, we've seen a resurgence of these kind of malicious image files across a number of threat actor groups. Um and you know, before I was I was hurriedly before the call today, you know, before the show today, I was trying to figure out, trying to collect who they all are, and I didn't have time to do that. But um yeah, I'm when I'm looking at one of them right now, um, CDN-img-fetch, um, which was downloaded about a thousand times, it sounds like um a lot of these out there. I think that this group that's mentioned in this latest Mailfax campaign is actually a subset of I mean, they they say it's been going on for a while, so obviously it is a subset, but I've seen a larger number of these recently, but basically they're deceptively tiny and and simple. So basically they've got three.

SPEAKER_01 24:51

Yeah, it's not the typical like look for a really big file that like is sketchy.

Paul McCarty 24:55

No obfuscation, like no filler. It's three files, it's a readme. And the funnily enough, the readme is lowercase readme.md, which um oh yeah, that is unusual, huh? Yeah, I'm pretty sure that the the npm package. Um, when you go to publish, I think it requires that it be a capital reading, but maybe I'm wrong. Anyhow, um man, I'm like honestly, basically there is no install script. Um, so this is gonna work on import. Um it basically calls main, the entry point is main from the package.json, which is like 10 lines, it's super simple. And all it really does is it just pulls this malicious payload um and then extracts it. And there's like a there's a malicious blob inside of the payload. But the reality is that when you look at this file, it's a legit um PNG file, uh, regardless of what the the file extension is. The ones I've looked at have all been uh PNG format, but it hides a payload. And now to your point, then this threat actor, what's actually in the payload, has been evolving very, very quickly. And and so I'm not necessarily across all those changes, you know, over the last month or so. But we're seeing this from lots of threat actors where they're experimenting, right? We saw it with ghost actions. Ghost actions is a perfect example of somebody that's experimenting with additional kind of payload styles and you know, additional acts or secondary access. And um so they're all they're all innovating, and um, that's what this this threat actor is doing. But yeah, finding it it's tiny and it's you know looks really good.

SPEAKER_01 26:33

Yeah, I think it's it's unique because a lot of it looks somewhat normal from the outside. You know, we've seen the contagious interview campaign use um what's labeled as SVG, so that's an image uh file, but then when you open it, there's no image, it's just obfuscated JavaScript. But in this case, it actually is a legitimate image. So, you know, as we're talking about the kind of things that would help you detect these, you know, you're not looking at uh a file that contains something that it's not supposed to necessarily, or uh, you know, a file that's excuse me, really big because it contains a downloader. Like they they've optimized this nicely. Good job, I guess.

Paul McCarty 27:21

Yeah. I I just want to make one, I don't know, correction is not the right word, but uh uh update to that. Well, like when you look at it, it definitely has the header right and the the file header for uh a PNG file, but it's not actually an image, right? It's it's um it's just sitting there as uh as an envelope to hold a payload. But um the you know, I it just goes to show you that you know things that seem innocuous, like file images, um, and you know, we were talking about this before we started recording. DPRK has used lots of the these file extensions to hide it's just JavaScript with a dot extension on it. So let's let's not trust what these file extensions, you know, uh these suffixes say they are. Um it's a whole new world. And with vibe coding, anybody can use you know any type of file format to do anything they want to. So um there's a lot of people that that, for example, when they're downloading uh malware malicious components, just exclude uh image files because they just don't want to because the size, they're just trying to make them as thin as possible. You don't want to do that in this case because you're gonna be missing the actual payload itself.

SPEAKER_01 28:32

Yeah, and speaking of DPRK and their fake font, I've documented two more variations. Uh they've started to hide it in um TIFF files and OFT files. So those are both legitimate font types, but you know what I'm seeing is they're often force pushing over an existing infection. And you can see all of the you know legacy WAF WAF2 files that they had in there from the first time. And then you'll see like a mix-in of these other ones. So they're still iterating really quickly. Um, it goes to show that searching based on file type, opting in, opting out based on file type is not necessarily the way you want to go. You want to be looking more at the signals that are in the content of the payload.

Paul McCarty 29:24

And to that last point, when you go to GitHub and you see all the security researchers creating their threat detection stuff, you see them, you know, looking for asterisk.waf2, and you're like, well, okay, so the threat actors can see that, right? They can see that everybody's like looking looking for WAF2 files. Guess what they're gonna do? They're just gonna use some other like file extension, right? That's meaningless. Again, back to my point, the file extension itself is is meaningless because it's all JavaScript. In this case, it's all JavaScript inside of it. By the way, I just want to say I think it's hilarious that Jen has become our primary DPRK. Um You're not the only one.

SPEAKER_01 30:01

He's not making fun of me, to be clear.

Paul McCarty 30:04

I'm not, I'm not. She's like Jen is like I have I've been I've been focusing on other stuff lately, and Jen has been finally. Yeah, this is she sends me a frickin' thousand uh uh repos, and I'm like, how quickly our roles have changed.

SPEAKER_01 30:20

Um yes, well, thank you, Claude, my my best friend.

Paul McCarty 30:25

We gotta pay that guy.

SPEAKER_01 30:26

Uh he gets paid, he's fine.

Paul McCarty 30:29

He does get paid. Um gets paid quite well, actually. Um yeah, anyhow. Good good job. I guess I guess that was my way of giving you kudos. Thank you.

SPEAKER_01 30:40

I appreciate it. It means a lot. Um, all right. Well, I think we're uh we've exhausted our topics. You and I are both fighting gold, so we might be veering into the the delirious stage of this podcast. So uh it's time to wrap it up. We'll see you all next week in the month of November.

Paul McCarty 30:56

Stay safe, thanks so much for listening. Appreciate it.

unknown 30:59

Bye.