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