Mackenzie Jackson - Worms, Tokens, and Trust The Industrialization of Supply Chain Attacks

This talk focuses on the rising issue of supply chain attacks in the software ecosystem, highlighting the challenges posed by open source dependencies and the interconnectedness of various libraries and tools. The speaker, a former co-founder of a health tech company and current security researcher, delves into the intricate layers of dependencies that make applications vulnerable to malicious exploits. They discuss concrete examples like Log4j and the impact of vulnerabilities, emphasizing the inadequacy of traditional CVE reporting in the fast-paced world of AI and malware attacks. The conversation reveals alarming statistics about undisclosed vulnerabilities and presents novel detection methods leveraging AI and LLMs to address these security challenges in real-time. Through anecdotes and case studies from their research, the speaker illustrates the breadth of the malware epidemic in open source software, urging the audience to rethink their security strategies.

That's super strange. Awesome. [laughter] Well, thanks everyone for coming out here today. We'll kick off. So, we're going to be talking a little bit about supply chain attacks. A pretty big topic recently that's coming through. We'll walk through some of the reasons of why these are so problematic and prevalent right now and have a look at ways that we can prevent it, ways that we can we

can stop it. A little bit about me. If you're wondering where my accent is from, I'm from Aotearoa or New Zealand. I'm the co-founder of Compargo which is a health tech company. It still exists but it's headquartered in Australia. I left Compargo a few years ago. I'm now a security researcher. You can find me anywhere on social media at that handle advocate Mac and I'm also the

host of the secure disclosure podcast. It's my mom's favorite podcast. She listens to it every day and she highly recommends it to all of you. So, make sure you check that out. [laughter] Um I want to start off with just a little bit about understanding our supply chain. So, this talk is obviously about supply chain attacks. I think some of you will probably be pretty familiar with

this concept and and and about it but I want to go through it anyway just very quickly. So, 70 to 90% of all the code that makes your application do stuff comes from open source projects and also a bunch of third party libraries and third party processes and SaaS tools as well. So, we take a look at this. We have our code that makes up a pretty

small part. That's what's unique to us. That's that's what we control. And then we have direct dependencies. These are the dependencies that we choose. Right? We know what they are. I looked on them. I went to their NPM page. I saw how many stars they have and I I selected them. But those open source packages also use open source packages. So, then we get into the realm

of transitive dependencies and we can go back multiple layers until we get to the world of foundational dependencies and these are kind of the things that are in everything. And because we share so much technology among stacks foundational dependencies where maybe in different languages or different ecosystems that you're dealing with. So it becomes really confusing. I have like a little visual of this. So we have our

application, then we have our direct dependencies. We know what they are. These have dependencies, those have dependencies. I had to stop there because the icons got too small. But basically you can go back about 30 layers, right? To make it a little bit more confusing, we also have third-party services. So maybe you're using something like Okta or Auth0 is here for authentication, Stripe for credit card processing,

all of that that kind of good stuff. So this is what we're dealing with with our supply chain. And it we when you look at it like this, it kind of makes sense. Like I can see the dependencies, I can see the relationship, and I can see how everything connects together. The problem is that in reality, it doesn't really look like this. If we were to describe

this accurately or do an actual representation of a real world example, it looks closer to this. Right? And that's because our dependencies can be dependent on each other, our third-party services have dependencies, and we don't really have any visibility in what's going on. So if we take one of these little open source tools, let's say this little red dot that we have there. Let's just give it

a really random name, just something I'll make up out of the blue. I'm going to call it Log4j. Um and uh if this has a vulnerability inside it, right? Or if this is turned malicious, then it can have an upstream impact on everything, ultimately turning our application malicious. And the problem with this is that we did nothing wrong. We didn't select to have Log4j in our in

our pipeline. It's just there. But because it has a remote code execution vulnerability in right? Then we can actually be susceptible to that in our application. Now attackers have figured this out, and they've realized that they can make far more sophisticated attacks, go deeper into the the be because of this. So here we have an actual financial model. Don't really ask me to explain all of this

what it does. I don't quite understand it, but I can tell you what it does. This here is a mathematical model that can calculate the impact and financial return on conducting a supply chain attack based on how popular the packages uh that you're attacking. So, this is a sophisticated way that threat actors can actually calculate how much resources they can commit to attacking an area in our

supply chain. This is one of the reasons, not necessarily this exact model, but the fact that these financial models do exist, are one of the reasons why we've seen such an increase in these types of attacks because they have such a big financial reward on the end for those attackers. So, they can invest much more into it. And we'll look at some examples Um this is a

meme that's been around everywhere. I'm sure everyone's seen it before. It's just so accurate. And it just kind of describes the scenario. This became so popular it sparked the term called the Nebraska problem. The Nebraska problem is basically that we have someone random from Nebraska thanklessly maintaining something that holds the entire internet up. This meme is so accurate that we can even tell you what those projects

are called. For example, there's a project called xc- util which was compromised. That was basically holding up the internet. We have something like log4j, which I've kind of joked about and talked about. We have something called debug. What all of these packages have in common is that they had massive vulnerabilities or they were compromised through a malware attack, but pretty much hold up the internet. So, this

meme is very accurate. There's an updated version of this. Currently, we're on this version, which is basically every time we add a new thing in the array, the meme gets more and more complicated. So, this is the current version of the Nebraska problem that we're at. This is kind of got chaos going everywhere. And it's a bit of a joke, but it kind of feels right. But

I want to take you through uh a couple of examples of this. So, I want to take you through the example of debug here. So, debug is an is a node project. It's on NPM, and it's pretty much one of the most popular packages on the internet, especially in the JavaScript ecosystem. So, we can see that it has around about 476 million weekly downloads to it. So,

this package is used by hundreds of millions of applications. It's got a long version history, so we know that it's well maintained. It has tens of thousands of dependencies of dependent, sorry, that packages relying on it. So, this is a very solid, wide-scale uh uh open source project that we have. It would be pretty catastrophic if this package was turned malicious. It would be pretty catastrophic if

a threat actor managed to figure out how they could get into this package and turn it and and I and make it do evil things. Uh which is exactly what happened. So, if you have a look at this, if you look at line 12 down there, this is in the NPM code viewer, line 12 looks pretty gross. Right? That is malware that a threat actor has managed

to input. The dead giveaway is the scroll bar to let you know that they try and keep malware on one line to kind of obfuscate it a little bit. But, this is kind of goes to show, you know, what can actually happen. And because this has such a massive impact, right? This here can actually spread into various different projects. And I'll talk a little bit more about

this specific example and and what I actually was the impact uh from But, how do we deal with this? How do we know, right? How do we know that we have a problem? Well, we have something called a CVE, right? It stands for common vulnerabilities and exposures. And we have these databases. So, here we have the CVE um for debug, right? So, debug was compromised. And we

have this uh number here. So, what we can do is we can look inside app application. We can see are we using this version of debug and does this version of debug have a CVE number, which is going to let me know if it's got vulnerabilities or malware. For the longest time, this kind of worked and it was what we could do to kind of deal with

this. The crux of my talk is this is completely useless now and I will explain why this process is completely as we get going. But, in the world of AI-powered attacks, we need something much faster than what a CVE can provide us. Um but, it's not just malware with CVEs, it's also vulnerabilities that we have and attackers are leaning on vulnerabilities as well. So, this is probably

the most famous CVE that we have. This is Log4j and 2021 in December, Log4j was was found to have a it and basically the entire internet was pretty much vulnerable to it for a while because this is a foundational project that's in everything. Right? And this kind of worked for us then. But, now what happens is when a CVE is created, attackers can use AI to generate

a working exploit in just a matter of minutes and go through that. And that is okay if we update to the latest versions all the time that we don't have any vulnerabilities in there and we get good exposure. But, to give you an example of like how bad we are at updating this, 2 years after Log4j came out and was discovered and got crazy press everywhere, 2

years later, 30% of all the applications that were using Log4j were still using a vulnerable version. 30%. So, we know that we're not doing what we need to do and this gives us this gives threat actors a great window and they don't need 2 years to build out an exploit. All they need is a few minutes to be able to do this. So, how are these CVEs

created, right? Well, a vulnerability is found or malware is found by researchers, maybe from people like us at Akido. It could be the maintainers. It could be someone using an open-source project. They find a bug or they find malware. Right? Then they submit a CVE report, and this goes through. People look at it. They analyze it. They give you a CVE number. Then we have a class

of tools called SCA. Stands for software composition analysis. These tools look at the all the dependencies and transitive dependencies that you have in your application. They match it with the CVE databases, and they let you know, do I have any vulnerable or malicious packages in my uh supply chain, right? So, they look at that. They look at your application. They may make something like an S-bomb, software

bill of materials, and then and then we know. Uh here is why that absolutely doesn't work anymore. And whilst we still should be doing this as good practices, if we're relying on this, it's not really a good use case. The time it takes from discovery of a vulnerability to a CVE being created is on average 3 months. So, it typically takes 3 months for that whole process

to go through. So, if malware is discovered on it, and we're relying on a CVE number to tell us that that malware exists, we're going to be we're going to be 3 months behind. And that doesn't work. It's the same for for vulnerabilities. So, how do we actually solve this in this kind of AI world? I think there's two parts that we're trying to focus on the

research team at Akido uh is trying to focus on to try and solve this. One, we're trying to detect vulnerabilities before a CVE is created um to speed up that process. And two, we're trying to detect malware in in real time. And we do this, I'm going to tell you all the the secrets of behind we do this. We do this for for free, and it's a

open source project that we're managing just that to help us. But I want to go through exactly some of it, and then we're going to talk about some of the fun malware that we've found and uh what makes it interesting. But our initial concept was pretty simple. What we noticed is that uh when a when a a vulnerability specifically is found in a in an open source

project, what will happen is they will typically solve it first. Before the CVE comes out, they patch it. So it gives us some time. But they often will put that patch in the change log. So what we started to do is we started monitoring all of the change logs of 5 million open source packages and trying to identify when a security fix was made. The idea being

if we can identify when a security fix was made, then we can bypass this whole national vulnerability database system that's taking a long time and build a temporary database to bridge that time. And the goal was to go from 3 months before the vulnerability is published to a couple of days, and at least give us the ability to do that. So we wanted to use LLMs to

monitor all the change logs, analyze it, then analyze code, and then give us a result so that we could as humans can analyze it with a whole bunch more context than what we would be dealing with if we were just kind of looking at random random things. At first we thought it was going to be simple. It turned out to be a bit more complicated. Some of

the complications of it was that change logs don't have standard formats. They're not in the same place. They're kind of difficult to scrape. Sometimes they're on GitHub, sometimes they're on a website, sometimes they're somewhere random. And also, we found that people uh willingly use ambiguous language when fixing security issues, right? So it's not very common that they tell you that they're going to fix the security issue.

So we needed a way to be able to kind of read between the lines and understand So just as an example, here are three change logs, all in different formats, all in different places. And so we started scraping scraping these. And we got some really good results, but we had some very interesting findings as So this is just kind of an example of a question that people

have is like why why do we need LLMs in this case? And it was for the reason I just explained, which is that the language is very ambiguous. Uh one of these we have something saying, "Hey, we escaped text to avoid cross-site scripting." All right, I could write a rule to find that and do it. But then when we get to some of these other examples, there

is a whole lot more ambiguous language where you really have to know um what it what is going on. So that's the use case for what LLMs actually brought. So in total we've discovered 2,106 vulnerabilities uh over the last year and a half. That may not sound like a match, but you got to remember these are the vulnerabilities that are in some of the the most popular

open-source packages that we have. And a lot of them are pretty critical. But we discovered something kind of terrifying. Our hypothesis at the start was that we're going to bridge the time between a CVE is being created. What we discovered is that most of the time a CVE is not created. So um in total 67% there was never reported. The vulnerability was never reported. So someone may

be using a vulnerable and they haven't upgraded that package cuz there's no known vulnerabilities in it. So you leave it where it is. It's not broken, don't fix it. But the problem is that actually there's a lot of vulnerabilities that aren't being disclosed. So 67% were never disclosed. Uh of them obviously a lot of low severity vulnerabilities weren't weren't disclosed. Okay, you can understand this. You can

sympathize with this. But 56% of critical vulnerabilities were never actually publicly disclosed. So 56 of of of of all those that we discovered are never actually published. So creates a huge blind spot. And because we're doing this, and I can tell you that it takes a little bit of computational kind of power, some tokens to burn to do this, but this is exactly the type of thing

that a threat actor can do to gain an advantage to make a supply chain attack. Find vulnerabilities that don't have a CVE because less likely people will have upgraded to them. So, this is kind of has a name for it. The official name is called silent patching. I like shadow patching better because it sounds cooler, so I'm trying to get that to catch on. Uh so far,

no luck, but you know, feel free to refer to it as shadow patching here on out. and there's a lot of reasons why these vulnerabilities aren't discovered. None of them are good. I think most of it comes down to the fact that submitting a CVE is difficult. It's hard. Uh you have lack of resources. Your dog ate your CVE report. Whatever the excuse may be. There are

various reasons why you might do it, but none of them are good because unfortunately we require this process of CVE creation, or we used to, to be able to solve the supply chain issues. So, it's not just small projects to do it. To give you some examples, here is a critical uh uh path traversal vulnerability we found here uh in a a popular PHP project. This has

uh 3 million weekly downloads on it. So, no CVE was ever created for this uh for this vulnerability uh as well. We have another one. This one here is in a very popular package. Uh 86 million weekly downloads. Uh again, another PHP project. Uh again, another critical vulnerability, deserialization of untrusted data. And again, no CVE was ever created for this issue. So, people don't have a way

of of of knowing about it. Uh we have a uh a a We have an a public uh available feed where we publish all of these findings. Anyone can access it. Uh you don't need to have any special access. And basically, what we do is we let you know all of the vulnerabilities that we've found, and then if a CVE is created, we let you know that

a CVE has been created in in that as well. So, you can check that out. Uh it's called a Keto Intel. But, I want to talk about something a little bit more interesting now and a little bit more topical, and that's malware. So, we talked about vulnerabilities, but vulnerabilities are part of the problem, but malware is definitely the problem that we're really facing right now, and that's

through compromising of packages. And I I gave you a sneak peek about debug, so I want to walk through some of the kind of issues that we have as well. there's a developer called Josh Junon. Josh is a legend. We love Josh, and he's one of those people He's not from Nebraska, but he's one of those people that are thanklessly maintaining projects. He's very prolific. One day,

Josh was at the doctor's, and he got an email on his phone. He was stressed, and he was trying to figure out, "How can I do something productive?" He got this email from NPM to say he needed to update his multi-factor authentication credentials. Seemed legitimate. The email was from npmjs.help, and not npmjs.com. This was a phishing email. Josh's projects, he's one of the most prolific open-source maintainers

around. His projects are downloaded 2.6 billion times a week, and the projects that he manages and maintains are debug, chalk, ansi-styles. And you look at these, all have hundreds of millions of downloads. So, as you kind of can figure out what happened next, the maintainers were actually able to compromise Josh's The attackers were able to compromise Josh's account. They stole his credentials. They injected malware into all

of his projects that we had. Um and I want to show you the process of the CVE reporting. So, we discovered this at a Keto, and we notified Josh. We wrote a report on this on September 8th. That was the day that the compromise happened. We publicly announced on September 8th that that this had happened. If we take a look at the CVE that we looked at

before, the CVE was published on September 15th, 7 days later. Now, 7 days of malware in your in your system is never going to be a good thing, but in this case, the CVE report would have been completely useless, and I'll explain why. The entire attack lasted only for 4 and 1/2 hours. So, we discovered the malware 30 minutes uh we and notified Josh within 30 minutes.

So, we had contact with Josh 30 minutes after the malware was published. It took Josh up to 4 hours to regain control of his NPM account. So, they had changed their credentials. Josh couldn't regain access without NPM's help. That took 4 hours. In 4 and 1/2 hours, they had gotten rid of all of the malicious versions and reverted back to the clean areas. So, 4 and 1/2

hours, this whole thing was over, right? Sounds promising, but we can actually look at the impact that that this 4 and 1/2 hours had. So, Wiz did some post analysis, and Wiz said that they found the actual malware in 10% of all of their cloud accounts. So, 10% of all of the cloud accounts had been infected with malware in 4 and 1/2 hours. 99% of the accounts

that they looked at had some exposure to it, right? And that's because these things like debug uh um that they're pretty much in in Um and and so, this just goes to show you how useless that that kind of process is. And we can also look at some other more recent examples in here. So, Trivy is an SCA tool. It's a tool that's designed to help protect

your supply chain. It's actually a fantastic tool. But unfortunately, Trivy was compromised with malware from a threat group called TeamPCP. So, Akita we we discovered this is kind of a long breach where they were compromised multiple times uh Trivy, and they weren't able to correct it the first time. Eventually, attackers may may were able to get in there. They put in credential stealers into Trivial. So, when

someone was trying to protect their supply chain, it was actually stealing their credentials and passing them to the attackers. The attackers created malware from that that we named Canister Worm, which was a self-propagating worm, and this the impacts of this attack, which was in March this year, are still being felt today. They're still ongoing because so many credentials were stolen, the attackers are still able to use

these to infect more and more packages So, we're looking at malware that is kind of at the speed of AI. And we can actually have a look at the growth of malware that we're finding in open-source packages now. So, you can see the gigantic trajectory, which kind of correlates with AI coming out. And that is because we used to have something called script kiddies, which used to

just be able to run malicious scripts and do kind of basic hacking. Well, now we're kind of in the world where we've given them superpowers, and now they can create malware at any moment that they that they like. They can create very sophisticated malware, and I'll show you some of that. So, we're really seeing this intense speed of malware being delivered. And also, they've changed their target.

Uh I'll just wait for the applause. Yeah. That they've changed their target a little bit. So, they used to be that they were attacking cloud accounts. Now, they're actually targeting developers specifically because developers have access to more credentials. So, I won't go into too much of this, we are how we're able to detect malware again, we're using a very similar process. We're actually using LLMs to detect

it. So, just to briefly explain, the difference between vulnerabilities and malware is that vulnerabilities are typically deterministic. Here is an SQL injection vulnerability. I can write a rule, and I can discover this. Malware is non-deterministic because this is maybe what malware looks like, but all the indications of malware have perfectly legitimate use cases. So, it may be heavily obfuscated. Uh it it may be calling external domains.

It may be using dangerous functions like eval. All of that, there are legitimate use cases for doing that. So, malware is a great use case for AI because we can discover all the indicators of malware using static tools, and then we can use AI to make a determination of whether or not they think that that is as malware or not. And this is the exact process that

we're taking. Again, we publish all of our results publicly, so all of this is open source, and you can check it all out for yourself at Akido Intel. Um I I won't go into too much of it cuz we're kind of coming coming down to uh to to the end of it, but I what I wanted to do is I wanted to go through some of the

more fun examples of malware that we've that we've found uh for you to have a look at. I'm just going to go through Here we are. So, the stupidest malware that we found, but is also kind of great, there was a package here. This is North Korean malware that we looked at. This was early on, and we got a notification that there was a very strong indication

that this package had malware in it. And we looked at it, and we're like, "There's no malware here. I can't see anything interesting in this package." Uh but if you look closely, some of you will may have noticed a scroll bar down the end. They had obfuscated their mal- their malware just by using white spaces. So, off screen, there was actually calling an external C2 server and

uh doing it. Why I love this is cuz it's such a stupid way of obfuscation because every tool would have picked it up, but it almost worked because we couldn't see it. So, that's kind of like great, but stupid. >> [snorts] >> Um And then once you go into the malware, you download the payload. It did everything that you would expect it nasty North Korean malware to

do. It tried to install backdoors, steal credentials, all of that. The biggest potential impact that we had, uh there's a cryptocurrency called Ripple. It's the sixth largest cryptocurrency. On the official Ripple SDK, we we found uh some very suspicious-looking code. So, down here, it was calling an external domain and introduced a new function called check validity of seed. Because this was the official SDK, this is the

package that nearly every cryptocurrency exchange uses to communicate with the Ripple ledger. So, this would have had a gigantic impact because when you actually look into what the malware malware does, so it introduces this new function here, check validity of seed, and it's sending across things like private keys. So, this is essentially trying to steal your wallet information. What makes it particularly nasty is that this wouldn't

have stolen your Ripple cryptocurrency. Had this been introduced in a place like Coinbase, it would have stolen the the wallet keys to everything that you have. So, they would have taken all of your cryptocurrency. So, this one was very particularly nasty. You can kind of have a look at some of the malware that we had, but this one had the the biggest potential impact. And the last

one that I want to talk about is one that's been ongoing for multiple years. We've been tracking this malware. It keeps reinventing itself in various different ways. But, I think that this is the most beautiful malware that I've ever seen in my life. Um so, the the name of this malware is called Glassworm. I'm really salty about the name cuz we discovered the malware a year ago,

but someone else named it. Um so, now we name all our malwares to make sure we don't have this mistake again. But, basically, we have this project here and on line four, you'll see this decode and then there's a single character here. So, what is actually happening is it's decoding from base 64, but it's only decoding one character. So, this makes absolutely no sense. It's a fixed

character. So, why would you want to decode a single string? Well, behind this string was a whole bunch of unprintable characters called Unicode PUAs. These are characters that you can give values to when the project runs. So, they're unprintable because they have no subject to them. Then, you can give them a subject and essentially use them as code in there. When we ran this project, it delivered

us a payload. When we analyzed that payload, we found this base 64 string. This base 64 string, hidden behind the invisible Unicode characters, sent us to a calendar invite page. When we went to that calendar at Google Calendar Invite, the title of that was another base 64 string, which gave us an address to give us our final payload uh data. Now, this was first discovered on NPM

March last year. We first discovered We just first discovered this. It has since been reinvented multiple times, including they've delivered it through VS Code uh extensions and various other places, and they've also recently pivoted to to to GitHub. So, the the process We first discovered it in March. It was actually Coy. Coy found this Their research team found this independently, and then they named it Glass Worm,

and then that's now the name that I have to give it. Um Coy did nothing wrong. I'm just real mad about it. Um and then it's still going, and in March this year, there's been a new wave going through uh this, including going on on GitHub. And uh what I might show you is I might show you this this malware uh living live, and then I'll promise

I'll get off the stage cuz I'm just out of time. But if you look on GitHub, there'll be a whole bunch of repositories that will have this indication in it. If we have a look at some of these, this here is is malware. But what's actually hiding behind it is a whole bunch of characters that you can't see. So, if I copy this, and we paste this

into a Unicode editor character, what you will see is if we view this, this is the code that we can see, and then behind this is all of the invisible Unicode characters that actually hidden there. So, this malware is still spreading. It's still really uh advanced uh and very interesting. And with that, I'm just on time. So, I don't know if I have any time for questions,

but I will be hanging around.