Hello everybody, Welcome to another thrilling episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio and the voice for being a mine. But I'm still your host, and sirih thinks I'm talking to her for some reason. With me today we have a special returning Yes, mister Farross, a book a DJ.
How you doing, Fross?
I'm doing good. Thanks for having me here.
Yes, for those of you that wonder how to say his name, it's think about like booking a DJ for a show or something like that.
That's what he told me, and it still works for me.
I'm impressed you remember that, Steve, because yes, it is pretty memorable ized pose.
Yes, yes, so Fross.
Before we get into our lovely dark world of internet hacks and people trying to steal cryptocurrency, why don't you give us a little background on who you are and why you're famous, and your company and what it does and all that good stuff.
Cool.
Yeah, I wouldn't say I'm famous, but I'm happy to give you a background on.
What I would.
But that what I've done today. Yeah.
So I started off kind of writing open source software. That was kind of what I did for most of my career. I found the early no JS community to be like a really welcoming and awesome place. Kind of found my way to the early node con conferences in the one in in San Francisco that Michael Rodgers organized, as well as the note Confee you and kind of just got really addicted to publishing NPM packages. Published a bunch of those over the years, some projects like webparrent.
And standard js.
Uh and uh, yeah, I just learned a lot about the you know, the supply chain, the way that open source software is used by companies, the way that you know, open source development happens, and and I got really addicted to it and it was really fun.
It's an amazing community.
Uh And ultimately that kind of to me starting Socket in twenty twenty, after seeing a ton of attacks happening against JavaScript packages, I got kind of obsessed with like trying to fix the problem.
I was like, why why do we accept that.
Packages are just going to keep getting compromised and every time that happens, we're just going to have to hope that we were lucky and not affected by that in some way or another, Like, can't we actually be proactive about this?
Scan for this prevent this, and so I.
Started a company Socket to do that, and now we're like, it's a big company now, I mean we're like seventy five people. We have a ton of big customers, a lot of companies you probably recognize, and just trying to help people use open source safely.
So just to clarify for us and I were talking about this ahead of time, his website is socket dot dev, not socket dot io, if you make that mistake. Socket io is Girmo Rouscher's old library for doing web sockets. Socket dot dev is Frost's entity that helps keep supply chain stuff safe. So for us, that's quite the list of recent compromises and attempts to compromise the NPM supply chain.
I know that.
The most recent one that comes to my mind that we got hit with was the one, and we'll get to this, the Chalk Library and all those libraries by that same author that got compromised with a crypto trying to steal cryptocurrency stuff. And fortunately for us, we weren't using those libraries, so we were okay. But apparently that's just one in a string of recent compromise attempts.
So with further Ado.
I'll let Frost take over and talk about what's been going on lately.
Yeah.
Sure, So we've seen a bunch of attacks over the last couple of months. I'll try to give you like a high level summary and then we can dig into the the different details if that's interesting to you.
Yeah.
So we saw a phishing campaign that started about two months to go back in July where a lot of kind of popular MPM maintainers got this phishing email that was impersonating npm and asking them to like add to FA to their account. And it turns out that that email was actually sent from well, it appeared to be sent from support at npmjs dot org, which is like a real email that npm uses, but actually it wasn't sent from there.
It was just spoofed.
And unfortunately the npm js dot org domain didn't have the proper like email headers set up d mark and SPF headers that would would have helped different email clients to know that that that email, you know, wasn't legit from from npmjs dot org. Turns out like they send email from npmjs dot com, uh, and that had the headers set up, but npmjs dot org is a real domain that NPM uses, so it was still quite convincing
to get an email from that for people. So Lesson learned there is like you need to set up these email headers in these email these DNS records that help you know, block spoofed emails even on domains that you're not sending email from. As long as they're like a domain that your users recognize that you use, you know, you got.
To protect them with those same with those same GNS records.
So what happened is if people clicked on the link in the email, it would take you to a website that looked exactly like NPM, but it was a proxy, so it sort of anything you clicked on would work, and it would let you navigate through the whole site just like you were on the real site, but the domain was off by a letter, so it wasn't the real site. And then of course if you logged in
it would it would steal your credentials. So that that was something that was going around back in July, and we kind of noticed it over at Socket because some of the folks on our team got this got this fishing email, and we were like, oh, this is interesting, So we wrote about it, tried to warn people about it, but nonetheless, a couple of days later there was kind of the first prolific maintainers that were starting to get affected by this, and that started with a Prettier project.
So the Prettier package, a.
Couple of Prettier packages were compromised, including yes lint can fike Prettier, which is the reusable yes link configuration that kind of has the the rules for es lint in it that you can kind of apply to to to yes lint, and so that was compromised with a with
a like a Windows specific DLL file. So for those who don't know, that's basically just like a kind of a compiled code file that that you know, you can run on Windows machines, and that when that ran, it would it would steal a bunch of system system information like your environment variables. Uh, and then it would open a web socket, speaking of web sockets, uh, It would open a web socket to the attacker and it would
leave that connection open. And so then the attacker could have base to be like an interactive shell, so they would any text that they sent over that web socket would be received on your your computer, your machine, or your server and it would get run like in a shell, and then the output would get sent back to the attacker. So it's like they were almost acessation into your system, but using a web socket to kind of run commands on your computer or on your server. That's bad, right, Yeah,
it goes out saying that's bad. Yeah, yeah, they so, so I think, you know it was it was cross platform in that way, so there was the Windows piece that the doll file, but then it was also like it would also affect you on Mac and Linux because of.
The web socket, and yeah, not good.
They also kind of tried to hide their tracks through through different like anti analysis techniques, so they would encrypt the data going across the web socket, so if you were like looking at the text, you wouldn't see, like, you know, what was going.
Across that that socket.
So that was kind of the first first sort of effect of this fishing campaign was it actually hit you know, this popular library. Then it was kind of all quiet for a little while for about a month there until August when the popular NX build system was had one of their packages compromised. And this this attack was interesting for a couple of reasons. I'd say the first reason. Well, for first of all, it just it was similar and
that it still just tried to steal credentials. So it would like search your system for you know, s s H keys, NPM tokens, basically any file that you might have on your system that contains like a key or a token in it. It was it would just hunt through the file system looking for that and send it off to the attacker. But what was interesting about how they did it was it didn't just use like it
you know, just code to do that. It instead abused AI tools like Claude and Gemini to scan your file system for sensitive data, which is a technique that we
had never seen before. So this means that it would look for or uh Claude or Gemini installed on your system like this the cli tool that lets you interface with these AI agents and these AI tools, and it would use them to with a prompt asking the agent to go and like search your file system for interesting files, and then it listed out a whole bunch of file extensions in the prompt like dot t x T, dot log, dot n you know, uh, dot back, you know, just
different different kind of interesting extensions that could have keys or data in it. That might be interesting to the attacker, and then the agent would go and find all those files and then collect them in one in one place that could then be sent off to the attacker. So I'd never seen like an LM being used in this way kind of kind of you know, as a like like effectively that the payload of the attack is not like some malicious code, it's actually just a couple of
sentences in English. So that was that really blew my mind when when I saw that.
So why is that effective? Then you find it wor inner or just that that was the attempt.
Oh no, it was effective. Yeah.
I mean if you had if you had to have claud or Gemini on your system for it to work, if you didn't, it wouldn't do anything. So that was that was kind of the funny part was that it wasn't you know, it wouldn't affect you if you didn't have those CLI tools installed.
So they kind of limited their reach a little bit.
But I suspect they did it because it it was an attempt to get past code scanning tools that look for you know, suspicious code and if you know, if it's just a string, then a lot of those scanners will skip it, skip it.
That's it.
Socket socket wasn't wasn't tricked by this because we use ourselves. We use l ll ms to look at the code, which is a newer technique.
Right.
A lot of the sort of other security tools do static analysis on the code alone. But if you actually use an l M to look at the code, an l N isn't going to be tricked by a sentence. You know, you can ask the l M like what is this code doing, and it'll look at the prompt and it will tell you. So this, you know, with with the right prompting that actually it's possible for like defenders, for the good guys to also you know, use these AI tools to catch the bad guys.
Using a tools.
So it's it's it is a cat and mouse game some extent. But but I think you know, it didn't get past us. But but I would say it was. It was effective in that that if you actually ran the code, it worked as it was intended to. Okay, yeah, so that's uh, that's we're still not to the chalk attack yet. But but I wanted to say one other thing about this one. So NX, I don't know if you're familiar with. It's this build system, so it's it's kind of an open source it's an open source project.
They have a GitHub repo that folks can contribute to.
It's just a kind of a standard you know, NPM open source project like people are familiar with, and so they accept pull requests from the community.
And one thing that was interesting about the uh.
The way that this attack happened was it didn't use the phishing email, so that's not how they got the attack or got access. They used a different method, and so I wanted to talk through that because I think that the method was quite quite impressive. So they they used a get of action workflow that the an X project had, you know, added to their EPO, and it had some vulnerabilities in it that the attacker was able to use.
And so I want to walk through that because I want to.
Make sure people are aware that get up actions are, like they're very powerful, they're very useful. I use them all the time, but they're also very dangerous if you don't use them correctly. And there's a lot of foot guns, like just ways that you can just think you're doing something very innocent, very very very you know that looks doesn't look dangerous, but it's actually like a like a trick, like you're you're you're actually doing something very dangerous and
it's just it doesn't seem that way. So the thing that they did, so they did a couple of things. But the first one was they they were trying to print out the PR title in the action. So they had this echo command that just said like echo PR title and then it put the variable you know, into the command that that was that would print out the
PR title. The way they did that with echo, right, and by putting the variable in there created a shell injection, which is it's very similar to a SQL injection if people are familiar with probably more familiar with SQL sql injection attacks, and that just means that an attacker can effectively insert their code into the command, so it's your instead of the instead of something being treated as data,
it is inadvertently treated as code and executed. And so the way you do that here is you as an attacker, you'd just open a PR to this an x open source project, and you'd put your attack code in the title of the PR, but you'd start it with like a double quote to sort of close off the quote that they had in their command and then and then the rest would be kind of run as runs as a command, So you could get code effectively running in the in the environment of the you know, of the project.
Now that is in and of itself not that like interesting, because like there has to be some something in that environment that you want to take or you want to steal as an attacker. And uh so that this is the kind of where you get to the second part where get of actions support two ways of responding to pull requests. So they have these triggers where you say, effectively, when this thing happens, run my git of action right.
And so the thing that happens is the pull request has been opened, right, And they have two ways to react to pull requests that are being opened. One of them is called pull requests and one of them is called pull request target. And for many years, pull request target was the one that was recommended in the getub docs and was what a lot of tutorials and code samples were using. So it's probably the one that a
lot of people chose to use. The problem with that one is that, unlike the standard pull request trigger, the poll request target one will will run the workflow with elevated permissions, and it includes this get up token environment variable that gives you full read and write access to their pository.
So that token is just sitting there in the environment. And so if.
You use pull request target in your project, it means now anyone can open a PR on your project, and if they can run code in that environment, you know that can look at the environment vables. There's going to be a really juicy environment vable there that lets them effectively commit to your repository. So the combination of those two things meant that an attacker could put code into the title of a PR, send it to just just open it on, you know, send a PR to the project,
and then that code would run. And they made that code basically look for that environment variable and steal it and send it off to them via an HTTP request. So now they have the get up token, they can commit to this, you know, important open source project, even though they're not supposed.
To be able to do that. So what do they do with that, Well, they were trying to get onto NPM, They're trying to compromise the NPM.
Package, but they only have the get up token. So this project like a lot of projects have a published workflow, which is just another get of action that they've set up that will published NPM, and they made sure that the NPM published token was only available to.
That publish workflow, so it was isolated over there, which is great. They did a good job of that. But now the attacker can write to the entire repository.
So all they had to do was going and they just they just edited the publish workflow file and just added an extra step that would I think print out or send the NPM token to them, because once you can write to the repo, you know, then you can just edit any of the workflows and just it doesn't matter that the NPM token was only available to some of the workflows. They can just edit the workflow and
print out the tokens and stuff. So that's how they they basically stole the NPM token and then published the
malicious packages. So that was a lot of information, but I just wanted to walk through it because I think I don't know if you were following all of it or it was interesting to you, but I think it's fascinating because it's just like you're just using gid of actions, you like don't think about like I'm going to like my entire repo was going to get hacked and my NPM package is going to get a compromise because I just like you know, printed out a PR title like
in my in my get of action, Like that doesn't seem like it should lead to that. So it's, uh, it's pretty wild.
So a couple of things.
One, for those who want a good example of sequel injection attacks, look up xk CD number three twenty seven, otherwise titled Exploits of a mom and you're recognized Bobby Tables.
Yeah, just leave that to you to look up.
That's one of the few xkcds that I have memorized, the number that and nerd sniping. But so a question for you then regarding how you know, like you just said, you wouldn't think that a GitHub action could expose you know, you just somebody stealing your token?
Is that on the is that on GitHub?
Is that on the creator of the action they have to know the finding security details of creating a GitHub action or is it just the nature of you know what it is that you can everybody's looking for vulnerability somewhere and somebody happened to be created creative or how do you look at that?
I mean, as with security, all things in security, it's it's a complicated answer. I think there's blame to be shared on all sides. But I put probably more of the blame on the design of get of actions because it, you know, it's not fair. I don't think it's fair to you know, have kind of a bad design or bad defaults and then just say, oh, well I documented it.
You know, go read the docks. The docks tell you how how you know how not to use this.
If it's if it's too if it's if you have too many like booby traps or you know what sometimes called foot guns in the design of of something, then you know, you you definitely have some of the blame on the creator of that design. So there were a few things in the design here that we're just that we're not obvious to people. I think, you know, the fact that they were recommending pull request target for a year instead of the safer pull request trigger is definitely
on GitHub. They've now documented that very well. So it is all documented. But you know, there's a lot of tutorials and guides and things that are going to still have the old information, so, you know, and then I think the other part of the design that is probably not that obvious is so that the I mean the NX the credit of the NX project. I was very impressed they actually figured out that they had this shell injection vulnerability and they fixed their get of action two
years before this attack happened. So from their perspective, they fixed the problem, like they fixed the echo issue, you know, and so how are they still affected?
Right? That's kind of another interesting part of the story.
It turns out that if you have an old branch that still has the you know, still has an action on that branch, then anyone can open a PR against an old branch, right like when you open prs, you can target any branch. You don't have to open the PR on or on Maine. You can open the PR on something from two years ago if if the branch
is still there. And so they had fixed this issue two years before, but it was still lying around on a whole branch, and so again to me, that's like, I guess technically that's probably explained somewhere in the get of Actions documentation, but I you know, I as security person probably wouldn't have made that connection.
Like I you know, I don't. I like to be kind.
I like to sort of be try to have some grace for people that are just trying to do their best to like do things right. And I think there was a lot of things that the NX team did really well here and yet despite all that, like they were still affected.
So I definitely put some of the blame on the design to get of actions here.
Well. You know that's interesting because I can remember, I don't remember when it was, I want to say, within the past year somebody raising a question with GitHub regarding the deletion of branches and whether or not they're truly deleted, and you know, because they're thinking, Okay, I'm deleting a branch, it's gone, and getthub saying no, that's a beat or not a bove ug, you know, as they purposely keep
old branches around if you say you've deleted them. And I was like, okay, and I can think of I can think of a time where that has been useful, you know, where I wanted to recuperate an old branch for some reason and it's still and I know they get up and deleted, but you know, at the same time, that looks like a two edged sword in the case that you're describing that someone thinks they deleted it, but
it's really not. And so now you got to worry about old branch you supposedly deleted, which is still around.
It can be used as an attack vector. Yeah, my head spins just thinking about it. So anyway, this.
Also matters a lot when you're trying to clean up like an accidental commit that contains a secret or token and you go intro you forced push to try to get rid of it from the history, and but then it's actually like still lying around on GitHub.
So for those folks that don't know, if you know, to.
Commit hash of the the commit that contains the the secret or the you know, the one that you thought you did, the commit that you thought you deleted, if you put that commit hash into GitHub, it'll actually still be there forever. It's just immutable, like it's just the URL that just will exist forever with whatever you whatever data you thought you deleted. So if you want to actually fully delete it, you have to contact get up support and basically ask them to going manually. Yeah yeah,
so yeah, even if you force pushed, the only only truly. Truly, I think the clean way to fix it is to completely delete their entire repo. But even then you might have forks. If it's been a public repo and someone's forked it, then my understanding is that that the fork actually then kind of keeps a reference to all those commits and then still won't get deleted. So yeah, you should just assume if it's been ever in a commit and it's been pushed to get hub like, it's public forever.
Even if you've force pushed over it like, it's basically you can't bring you can't put the toothpaste back in the tube.
Interesting, Yeah, well it makes you nervous. So the only so if you delete it.
So what you're saying, and if I understand at least forget up, I use getting lab in my day to day work, we're using get labs, so I'm not sure if all of this carries.
Over there as well.
But the so, if you delete the entire repo, then you know, say it was private and nobody's forked, then it should be gone. But individual branches are not truly deleted within a repo that's still up.
Yeah, the repo's up then then the commits, the then specific commit hashes if you know, those hashes will allow you to recover the data. So, uh, the question is how do you find that hash. I'm not an expert in this stuff, so I'm kind of uh talking mostly based off of some research I read that was put out by the truffle Hog team. You know, a truffle hog is like a security tool that lets use for tokens and secrets in things like get ub repos and
they've done a lot of research on this area. So if if you search for their blog, you can kind of find out find out some of this stuff that Dylan Iri.
Is the the.
Founder and creator of that project over there, and it's where I kind of learned most of the stuff from. But yeah, I think so the short version is just if it's if if you've ever pushed it up to get hub, assume it's gone and you know, assume it's out there, and then there is a there is a way to kind of contact support and get those those commit hashes removed.
But you you know, you you should just you should still obviously rotate the tokens and you know, revoke them if you can, and try to try to assume all that data is just gone even even if you do that.
Right, Yeah, I don't know how it works get lab. That's that's another that's another interesting question though.
Yeah, so, uh, do you want to talk about the uh the chalk one now?
The ones that go to yeah, okay in regards to another two f a email reset and being compromised.
Yeah, that's right. That one was was a similar email. This time the email originated from support at npm JS dot help.
So, uh, I don't know. I I kind of feel like that.
Email is obviously not not not legit, but that then that said, you know, there are a lot of companies these days.
Using these these interesting new TLDs.
And is help legit?
Is that a?
Is that a tl D?
I suppose it is? Yeah, let me see uh Google really quickly.
Here, Yeah, Google looked. There's so many it's hard to keep track from all.
Yeah, it's like any word, you know. The one that really the world only really.
Still bothers me that they made it to a TLD is dot zip because now you can Yeah, you can have a file name that's like dot zip and you're just typing it out the name of it and then it'll get it'll automatically turn into a link in a lot of programs now and it's like, yeah.
I'm trying to do here.
Yeah, but anyway, uh yeah, so so so it. But I think, you know, again, like the phishing email stuff, it's really effective, surprisingly effective. Even people that are security experts fall for this stuff sometimes. So I don't want to put any blame on the on the maintainer. The only thing I'll say is, like, you know, phishing resistant to FA would have would have solved these problems. And so for those who don't know what is fishing resistant t FA, I'm just going.
To ask that. Yeah.
So two FA is just you know, a second factor right, second factor to two factor authentication. It's just the idea that you provide, you know, some other evidence that you are who you are besides your password. Typically you'll see things like a time based code, or you'll see like a text, like a two factor a text or by another app or something like that. That's all great, it's better than than just having a password alone. But the gold standard what you really want to have is phishing
resistant TUFA. And what that is is it's basically a two FA method that is resistant to phishing attacks.
What does that mean?
That means that there's no way to trick a person, a human ofulnerable, you know, human to take that to a fake token and to put it into the wrong website, to put it onto a fake website. So how is that enforced. Well, let's let's take a simple example of one of those methods.
It would be a UBI key.
So for those who haven't seen them, they're the diesel you know, hardware tokens that you can.
You can buy it.
I've used those, yeah, yeah, So what's what's one of the best things about those is that they will refuse to give up the you know, the key material to the wrong domain. So if you're on a fake website, you're on a fake NPM website and you you ask that you know, you touch the key and you ask it to provide key material, it won't provide the key material to the wrong domain. It's going to provide different key material to the to the attacker. So what that
means is that it can't be tricked. Right, it works directly with the browser to enforce that it's you know, providing material to the correct domain.
And and so that's that's why it's awesome. The other one you bought one of these.
I've used these before.
We had a fob, yeah, and they're there's another one that I had and I can't find where it was. I would plug it into a port on the laptop and you had to touch it yep, like USBC type port.
Yeah, So that the only kind it's it's all like the real benefit of it is just that it it's sort of the site get The site knows that, Okay, I'm talking to the person who's in physical possession of this device, so they know that, you know, someone some attacker isn't unless they stole the device from you, right, Like, what they're validating is that you have this physically in your possession. But the other piece of it is the
fishing resistance. So the device is smart enough to not give up the material to the wrong domain because it's it's literally working with the browser to check the domain and only provide it to the correct domain.
So that's the kind of power of it.
The other thing you've probably seen a lot more of these days is past keys, and there's a lot of sites that are prompting you now for past keys. And for a while I was like another thing I have to learn. But but past keys are also really cool. Passkeys have the same property in that they uh, it's it's working with either your you know, your your pastor manager or your operating system to store this pass key. And this pass key will only ever be given up
to the correct domain. So again it's fishing resistant. It can't be tricked to you know, it won't get entered into a into a fake site.
So appractically if I'm wrong, But a pass key is is specific to the device, right, So you can't have one key passkey that you use in multiple places or is that wrong?
It does lock you to a device in theory, although I can, like I have one password and I put my pass key into my one password, and you.
Can do that.
Yeah, you can do that. Yeah, And in that way, if you get a new device or you get a you.
Know, like I can set up my pass key once on my computer and then when I'm on my phone, I have my one password there as well, and I can just log into the same site. I don't have to keep binding numerous pass keys on every device and do it all over again when I get a new device.
Yeah, because I have that same setup because we use one password at work and I use it like for a DP which is our you know, personal HR management stuff, and I use it there all the time with you know, with the fingerprint you know on my MacBook, which is tied to one password which then gets me in.
But I didn't realize I could use that across devices. That's cool, Okay, yeah.
I think you can. So I'm not sure that the standard is very complicated.
There might be a way that some sites can like prevent you from putting your pass key into something that has cloud sync, but don't quote me on that.
I'm not I'm not, like, I just know there's.
A lot of complicated options, and sites can demand certain properties of the of the device, of the.
Of where the pass key is being stored.
But generally Mike had I already put it on Twitter Frost said that pass key I'm kidding.
No, it's a bit but but but in my experience, I can basically put a pass key into one password any any any any.
Any time I've been prompted, So it's pretty cool.
So anyway, the reason I bring all that up is just to say that like like basically, like the the maintainers wouldn't have been able to be tricked if if NPM had mandated to f A with this fishing resistant property. So it's somewhat disappointing that, you know, this was, you know, somewhat preventable, you know, if NPM would have been willing to kind of force this on maintainers, which is, you know, I'm not saying it's costless.
Obviously, there's there's some cost of kind of making everybody.
Go through this, but but for prolific maintainers with access to you know, billions and billions of downloads per week, you know, I think it's it's probably a it's obviously, in my opinion, a good trade off to make those maintainers take this extra step. So what happened here was this Kicks maintainer was compromised, he fell for the fishing attack, and then he had access to a lot of Cinder
sources packages and cinder sources. An awesome, amazing prolific maintainer who has some of the most useful and.
Popular packages on NPM.
Power is a huge, huge portion of the job script ecosystem, and so that compromise was was able to get able to allow the attacker to insert some code into those packages. In this case, the code was a scrypto stealing code. So it worked by hooking into the fetch API and the xml httpeer quest API and various like wallet provider APIs.
And so what it did was it was if you called those functions in your in your front end of your site, it would be able to be able to rewrite the transaction data and replace the legitimate addresses with tackle control addresses. So they were just actively trying to you know, insert themselves in the flow and like make sure that you sent the money to them instead of to your intended recipient.
Yeah. I remember when that came out, there was a bunch of them, and by the time we got notification and looked, I know that.
Uh was I talk.
That's the one that comes to mind. I know there's some other libraries that already had an updated version. I think they'd rolled back to a previous commit or something like that. I don't remember how they did it. And so if you installed that then you were pretty good.
Yeah, but this was a lot of popular packages.
There was like chalk color packages, debug it's a big one that people use.
I use dbug.
Yeah, so there's just a lot of these, a lot of like low level, widely widely used packages.
Sort of a left pad type thing again.
Yeah, yeah, exactly. Yeah, So that was that was a very big one. Fortunately it was only live for like four hours, but if you were unlucky enough to install during those four hours, you know, you were you were affected. So this is kind of what why like we started stock it to be totally honest with you, because it seems like everybody is like reactive to these things. You know, Oh I read about oh chalk was compromised. Oh let me check my system. Did I install the vulnerable version
or the malicious version? And then you just kind of hope that you were lucky enough to not have run an NPM update during that window of time. And it feels like, you know, we got we ought to be able to do better than this as a community, you know, as a as an industry, like we can you know, I mean fundamentally, the problem is we're installing code that we haven't evaluated. We haven't looked at the code that
we're running. That's really what it comes down to is we're hitting install, we're pulling code.
In on the internet. We're not looking at it and then it's we're executing it.
So that's where I think, you know, treat treating this code differently, treating it as something that's part of your application, that is your responsibility, is something that isn't just a black box. It can can change, can help you know, change change this sort of risk profile.
Here, or you know, you can use a tool to help you.
And that's what we try to help is looking at the at the code for you, using a bunch of automation, a bunch of static analysis, and a bunch of l ll M kind of like AI analysis to find these attacks even before uh, you know, anyone else, anyone has kind of discovered these, Like we're we're scanning of the automated in an automated manner, all of NPM as well as all of a bunch of the top ecosystems like the Python, dot Net, Rust, Ruby, Goo, Scalah, et cetera.
So yeah, so then hopefully you know, we can we can sort of be in the middle of that and and and and and prevent those those packages from getting on your system. Yeah, So that's that's that one, and then there's there's a few more that came after that.
If you're if you're interested to kind Oh, let's.
Keep going, keep going.
Okay, it sounds like I knew about that last one, the one Chalk, that's all. But you were telling me about the newer ones that I apparently haven't heard, so I want to hear about them.
So after the after the Chalk one, there was another one that followed the following day, uh, compromised this project called duck dB, which has three hundred thousand weekly downloads.
And that one duck dB. Yeah, and you did hear about it.
Okay, well, no, not that, I mean just duck dB.
It's a it's a the tool itself, right right, Okay, Yeah, And this one was was the same attacker as the day before, so this was exactly the same malware that effect Chalk. So this one was clearly the same person. And then the following week there was another set of attacks. And this kind of brings us towards the end of the story. So this one was interesting because it affected another color library. I don't know why it's always a color library, but it was a color library called tiny Color.
And on the Monday of September fifteenth, that hit about forty packages and basically the thing that made this attack interesting was that it searched your system for so the malar searched your system for NPM tokens, and if it found an NPM token, it wouldn't just steal it. It would actually figure out what are the packages that that
token gives access to. It would download those packages the tar ball, you know, the actual code of the package, and it would insert like itself, it would replicate itself the malware into that package and then publish it back to NPM. So if your package as a as a new version of the existing.
Package, oh wow, okay, so.
If you like, like if if you were affected, you would you would.
Not just have your NPM token stolen, but all your NPM packages that you maintained that you have access to would be infected with the same malware, so that it sort of spreads like a virus, like a worm, through through all of NPM. And so within like a day, so by by Tuesday, September sixteenth, By the following day,
five hundred packages had been affected by this. It just spread like a like a worm, completely through NPM, infecting, infecting like even some some pretty uh like surprising packages like crowdstrikes packages, which is a security company that like a lot of people use, one of the.
Largest security companies.
So it's just interesting to see how wide, uh this kind of spread before it was before it was.
You know killed.
So I'm looking at the blog post on your side about this when I believe it is a shi hulud or is that.
The one you're talking about?
That's right?
Yeah, okay, yeah, so the malware they called it that because of I think as a reference to the Dune.
Oh that's right, Okay, I did hear that. I remember that.
Yeah.
Yeah, this was like the first line with that out there before it got probably like two days or so.
It was probably like a couple of days it was out before it was caught. Report was fully shut.
Down because it's a long time.
Yeah, they kept.
Changing the malware, like the actual payload, so that there was like six or seven different versions that we were able to identify across the different packages. So you know, they kept evolving it to make it a little bit better and fix different bugs in the worm. But the ultimately, you know, was kind of petered out I think due to kind of once NPM realized once you know, we had we and others had reported at ten PM. I
think they have helped helped shred it down. So yeah, I mean, it's it's it's it's funny because like this concept of an NPM worm had been known about and talked about for several years before this happened. Like there'd been some some folks that had written posts about like, oh, I could make a worm and it would take over
all of NPM and in a day. And you know, they just just blog posts on this that you can find find where people are you know, good, good, good folks like good maintainers were sort of speculating about this and writing about this, but we'd never actually seen it happen. So it seems like the attackers finally like realized that they should try to do that and and and you know,
and it worked to some extent. I think that the issue with all these things though, is that they're so noisy that they end up being caught by the community or by security companies like Socket pretty quickly.
Uh.
And once once people are aware, then you know, we can put blocks in place for all of our customers to prevent them from bringing those in. And and then you know, once the registries alerted in there and if they're on top of things that can help shut these things down. So the real kind of reason we've been so lucky as a community that these things haven't been more deadly or more dangerous is that the attackers have been kind of noisy, i'd say, like loud and noisy, maybe a little clumsy.
In the way that they've done these attacks.
If you were smarter, you would actually be sneakier, and you would you know, try to last for several weeks or months without detection and then you know, and during that time kind of spread far and wide, whereas these things keep getting shut and shut down in a few hours.
And so, yes, it still affects a lot of people.
I mean, if you have a package with billions of downloads and it's live for four hours, that that's still.
Going to hit a lot of people.
But I think it would be much worse if it had been live for weeks, right, And that's kind of why I think they're failing to do right now today.
Yeah, I can think of, you know, not necessarily the same thing, but in terms of data hacks or intrusions, you know that they find that have been around for months or you know, Microsoft, I thinks had a couple, and there's other ones that could to mine where they've been in there for months, you know, like, oh, good lord, they've had time to find everything.
M yeah, totally.
So I'm just thinking that sort of a you know, back to your two edged sword. It's like, Okay, you create a product of the great product.
Everybody's using it.
Now your responsibility increases with that too, to to you know, to protect your users, because I think I think of a lot of us assume oh MPM. Everybody's pushing packages the MPM. It must be safe. They're not any problems, right. But you were talking about the uh, the blog posts that you know, people had written, say hey, I wonder you know, I wanted to write a worm, I could
do this and this. So were those in retrospect that you know, people noticed those blog posts that people had been writing, or was that you know, people had been somehow bad guy just read it, you know, saw those and said hey, let's try it. But was it in retrospect that people said, oh, yeah, somebody had been writing about this for a while, we should have done something about it.
I think that likely the attackers probably just independently thought of it. I mean, so many I don't know, I mean.
Who knows, but I feel like I feel like this is the kind of thing that if you have the attacker mindset or the security mindset that you know, you think of these things just for fun all the time, like you.
Know, I mean, like hackers are.
You know, it's it's obviously that all the things we've been talking about in this podcast are all bad in the sense that they're all you know, stealing data and it's all it's all crimes. But there's another angle by which, you know, hacking more generally is is kind of this creative endeavor, you know, where you're trying to find a gap between the written rules of a system and the
actual rules of a system. So the written rules of the system say, you know, like yeah, n PM's a place you publish code, and you know it's you know, you know, legitimate, only legitimate people can publish code there, and you know therefore you can.
Kind of rely on it.
But the actual rules of the system are you know, there's any ways to get access to packages that you shouldn't have access to, and and kind of the attackers and these hackers are good at seeing those gaps, and that's that's really what hacking is is seeing these these gaps or these differences between the way the way the system is supposed to.
Work, the way that works on paper, and the way that it actually works.
And so I think any kind of creative mind or you know, good hacker mind could could have thought of something like this, this worm, and it's just a matter of you know, who's going to think of it and who's going.
To do it. So that's why there's als be more attacks.
I mean, that's why security is interesting really, to be honest with you, Like, I love it because it's always changing. You have you have an adversary that's evolving and changing. You know, if you learn like architecture or you learn you know, pick your peak, your whatever field that you pick.
Like, you know, the laws of gravity don't change.
So if you know how to build a bridge today, you know you know how to build a one hundred years from now. Like, it's the same constraints, gravity is the same physics, it's basically the same, right, Whereas in security that's not true. You have this sort of intelligent opponent who is adapting to what you do. And so it's a dynamic system. So it's kind of exciting in that way.
Yeah, the term I've always used as a cat and mouse game, right, yep, Yeah, you know you mentioned that the old blog posted it brought to mind about I
think it was twelve years ago. I was working on Drouple and maintaining some Drouple sites for a for an organization, and there was a bug that came out that got put in there and it was referred to as Drupal gedding because it was so bad that if your site got infected, you basically needed to start over with your database and somehow, you know, import it from somewhere else.
And somebody went back in the in the issues history for the particular module or a piece of code that got it and found where somebody had filed the bug report that said hey, and it all had to do with an array that was passed in and how I had handled reading values out of an array. It was something super simple, just a couple of characters, and they had said, Okay, this issue is here. If somebody figures
this out, we could be in some serious trouble. And somebody figured it out and nobody fixed it and ended up being just a huge, huge thudge thing. But you know, I was just thinking in terms of bug happens, somebody goes back, Oh yeah, somebody raised US flag a while ago. Right, yeah, I mean that hindsight is twenty twenty right in anything in.
That in that sense, I mean, I guess yeah, I mean NPM has known about this risk for a while, but it's it's difficult. I mean, I don't want to keep all the blame on the on them.
I do. I do think that there's definitely some blame.
But like like with all things, there's blame to go around in kind of every every points of different places, right, you know, different people were at fault. But like, but it's a hard problem because you know they're balancing like usability of the package manager and you know, wanting to make publish workflows flexible for people like I mean, you know, it's useful to have to be able to have a get a action that can publish new versions of your package to ten PM, you know when without having to.
Run that locally on your system.
And if you try to do like a two FA there, you know, now you can't have automation. You can't have you know, uh, you know, you can't automatically do releases when you know when certain you know, you know, when when commits land and stuff like that. So a lot of like the maintainer workflows would be affected by by like a sort of a night you've change like that.
So that and then there actually already has been pushed back to some So the NTEAM has actually done some things in the in the last couple of weeks to address these attacks. They made some security changes, but even those modest changes that they're making have gotten like a lot of pushback from maintainers who don't want to deal with you know, deal with the extra steps.
And I don't blame them, I mean, it's it's annoying.
It's just this direct trade off of security and usability, which we always see.
All right, So we're getting close on times how we got a couple more recent incidents.
We made it through all of them, the ones that we want it through all of them. Well, there's always more.
I mean, I can tell you there's probably like there's we find stuff every day, Like I could tell you about something we found probably an hour ago, like we were always blogging about this stuff on Soccer contpt on our blog. So but just in terms of like the the sort of really big ones. Over the last little while, I think I think we covered all the main ones. I don't want to get into like every little piece of malware. But maybe that is itself interesting to you.
I don't know, cause, like you know, just the idea that this stuff is actually not it's not just when you see it in the news that it's happening.
Like there is this constant.
Low level burn of daily malware, like dozens and sometimes hundreds of malware packages being pushed every day to these registries, and we're always out there looking for this stuff, trying to get it taken down, trying to protect people. So yeah, shout out to the to the socket Threat team for doing such a great job like looking for these hunting for these things.
And well, yeah, let's segue into that, since you've given us all this information, we'll do some shameless plugging here. So why don't to talk about socket dot dev not io and look at tell us just about what you do big picture, and then some of the products that you offer to help with help.
You avoid these issues that we just talked about.
Yeah, so our whole mission is to help developers protect themselves from exactly the kind of stuff that we've been talking about. So we started in twenty twenty. We've been working at this for a while. Today we find around a thousand malicious open source packages every single week across NPM, Python and about eight other ecosystems that we track. So we're just trying to help developers stay safe. And there's a couple of ways that developers can use socket to
stay safe. I'll mention actually the newest one, which is I want to actually very excited about, called Socket Firewall, and this is a free product that anyone can use. It's really easy to get started with it. You just NPM install SFW, which stands for Socket Firewall or stands for Safer Work I guess depending on your.
You're the way you look at it. But once you install SFW, all you have to do is.
Run your normal package manager commands, but you just prefix it with SFW, So for instance, you'd run s FW NPM install, FOU or SFW NPM update or SFW PNPM install.
Or yarn ad.
It works with everything, works with Rust and Python and on all the jobscript package managers. And what will happen is everything will install like normal, except for if you're about to install something that's been compromised. So it's really
like a filter on the packages that come in. And if we've identified that there's malware in any of those packages or threats that you know could affect you, just basically prevent them from coming in and we'll print a message telling you this package was blocked for blah blah blah reason.
So it's very simple to use. It's totally free.
People can just install it and start using it, and we're just giving it away to the community to help people stay protected.
Oh okay, yeah, here, it's not listed on your products, but I see the blurb at.
The top of the page there.
Yeah. We just announced it literally last week, so it's it's exciting.
I mean, we we are gonna we do have a paid version of it for people that want to roll it out at their companies. Like you can deploy it in a in a server fashion, so instead of it being a wrapper around the package manager command, you can actually deploy it as like a server and then you can point your your your different like package managers to that server as a as your registry, so you can kind of set the registry to be the socket.
Firewall, and then it'll like work in that fashion.
So so folks can look into that if they're interested in like using another company. But the free version is really powerful and like does everything that folks need to do to protect themselves today. And I recommend that people actually alias it so you can alias it in your shell so that when you type NPM, it just runs a s FWNPM behind the scenes and so you don't have to remember anymore. You just put that in place once and then you just protected forever.
Awesome. Yeah, you can see the details on Socca dot dev.
Yeah, and it's really it's really cool. Yeah, people should definitely check it out. Sure feedback.
We tried to make it work really really well, and it works with NPM, YARN, PNPM, PIP, cargo.
And UV.
There's a bunch of different package managers that works with so cool. Yeah, and then the other thing people can do is our main product, Like this is the main thing we've been doing for like you know, years now. This is our bread and butter is we have a GitHub app or a CLI tool that you can use to scan your projects and protect your projects.
So if you're on GitHub, it's really easy.
You just go to socker dot dev, you hit install socket and it'll give you like two clicks. You'll just ask you if you want to install this on your gi hub organization. And once you do that, then all your pull requests will automatically be protected. So if we see you about to upgrade to a bad package, we'll be able.
To put a comment on that poll request and.
Tell you why this package is risky or why you shouldn't use it, or what would be a better alternative and all that kind of information. So, and it's all configurable, so you can go in and sort of tell it I really care about, you know, preventing deprecated packages from getting into our project, and then it'll warn you if you're bringing in a new package that's deprecated, or you could say, I really want to prevent unmaintained packages from
being brought into our project. And then we'll be able to tell you when someone on your team is bringing in a package that hasn't had an update in five years. You know, we'll be able to print a little comment and say, hey, this package hasn't an update in five years. Are you sure you want to use it? And it's up to you. You can block in that case, or you can just warn and let them, let them decide how they want to handle it.
It's really all up to you. So it's pretty.
Powerful awesome all right.
So before we get into picks, obviously we know about soccer dot.
Dev and your blog on there.
Where else can people hear what you have to say or give you money or anything like that?
Uh yeah, just check out check out soccer dot dev. I'm personally on x and the different social media platforms masted on, loose Sky all that stuff. My name is just Faross F E R O S. S. And then socket socket is is on there too under socket security. Yeah, and I mean also just shout out to or let people know like that. If anyone is interested in this stuff and wants to talk about security or you know, uh how to how to stay safe while using open source,
just hit me up. I'm happy to like to talk about this with people, even separate from like becoming a soccer customer. I'm I also have been a lecturer and like a teacher in the past, so I love talking about this stuff. So if if anyone listening wants to kind of learn more about like what they can do to protect themselves from these types of attacks, or just wants to like hear more about the latest stuff that
we're seeing that I'm seeing. Let me know, I'm happy to kind of consider doing a talk at your company to your developer team and just talk about these issues, not like a product pitch or anything, but just talking about supply chain security. I like to do that from time to time. So if you think your your company would be interested, let me know, I'm happy to help.
All right, Well, I don't I wouldn't have any problem with shamelessly plugging your company considering all the information you're putting out there.
So so thanks. Yeah, we're trying advertising, we're.
Trying to do the right thing.
And like you know, all of our data is public to you know, you can you can go to a socket and search for any package and just we'll give all the data back to you, so you'll see all of our scores and all the findings and whether it's safe and different risks and quality issues and it's all open.
So yeah, we're just trying to trying to be useful.
All righty, So with that we will move into picks.
Picks are part of the show where we get to talk about whatever we want to within reason of course, you know, books, movies, games, Chuck likes board games. Uh, you know, tech could be non tech, could be whatever.
I always like to say. I'm the high point of these with my dad jokes of the week. So we'll start with.
That and then let for us save the best for last, well almost the best for last. So anyway, a Roman walks into a bar, holds up two fingers and says, I'll have five beers, please.
The numerals. If you're wondering, yes, actually thanks.
A few people have said that to me an observation.
Humans are the only species that will cut down trees, make paper out of them, and then write save the trees on it. And then the other night my wife said, honey, why is there a strange baby in the crib? I said, you told me to change the baby.
Thank you. Those are the dad jokes of the week. All right for us? What do you have for us?
I have a few picks. One is a book.
I read picked up last weekend called The Power of Now, which is interesting.
It's about kind.
Of the idea of like living in the moment, being present, and it's kind of like a spiritual kind of a book. But I thought it was it was very interesting it's it's it's really a simple idea that, like, you know, your entire life is experienced in the moment, but yet we spend so much time thinking of the past or thinking of the future. And I'm someone who spends a lot of time thinking more about the future than the past. I don't tend to dwell on things, but I do.
I do worry a lot about, like, you know, what I want to do, what I want to accomplish next, Like what am I working on? I like to work a lot, and and so I just thought it was very eye opening kind of reminder that, you know, it's not it's not a good idea to live your entire life just thinking about you know what's to come, but like actually take a breath and appreciate, you know, how
how awesome the current moment is. And and so anyway, I recommend folks look at that if if they that resonated at all.
And my other pick will be just a.
Classic book I always go back to you every few years, which is the Enders game series. The Enders game series is excellent, and even the prequels are are just amazing.
So uh, I've heard about those, Yeah, and what kind of book is that is that?
Is it like sci fi?
Is it? Yeah?
What is it?
It's sci fi? It's sci fi.
Yeah, so it's it's uh, you know, it's about a lot of people at bread enders game, I think, but if they haven't. It's basically about a kid who has to go into space and learn how to become like an insanely competent commander of fleets so he can defend
Earth from an alien invasion that's coming. Uh. And the series is like kind of it goes in the future, it goes into like a really different direction, and it goes like two thousand years into the future and follows this this this is the kid as he kind of travels through the Solar System and encounters like different new alien species.
Uh. And then the prequels are about kind of the.
Earlier attacks that the aliens did on Earth and the kind of the people, the humans that kind of fought them. And it's just I just like the writing style a lot. I think it's really media and really simple, clear, crisp, like fast moving language. It's just a really a joy to read it. It's like a really fun, fun read.
Awesome is that it?
Yeah? I'm supposed to more than two picks. No, no, nope.
Some people just have one. Some people are like, I don't have any, so I'll shut it out.
I'll add a final one, which is just a reminder for people to to NPM install s FW and check out Socket Firewall, which we recently released. And please send us your feedback if you run into any problems or where you think it's awesome.
Or you you you know.
Use it at work or anything like that, let us know. It would be awesome to get people's feedback on that.
Cool.
All righty well, thank you for coming back for us and telling us about what's been going on in the web safety world, or in some cases, the lack of web safety. And thank you for listening to JavaScript Jabber and we will talk to you next time.