SPEAKER_01 0:01

All right, we're live. Today is May 21st. Uh it's a sunny day in uh the Seattle area. I'm sure it's sunny in Australia. In my head, it's always sunny there, even though I've lived there and I know that like that's not how it works.

Paul McCarty 0:17

Yeah, it's been raining for like weeks. It's um my whole oh, actually, my pool is. I'll take a picture and send it to you. It's uh it's muddy, you can't see it. It's like it looks like we just had torrential rain um and the whole yard is saturated. So yeah, the sun is out right now, so that's happy to hear.

SPEAKER_01 0:35

Lovely. Well, um, you've been in the middle of your marathon of conferences. I've been getting over the conflu. Um, I still have a few days before I hit through it again. Uh maybe you give a quick update. What have you been hearing at uh you're at Oz Cert right now, you were at B-sides Melbourne last weekend, you're heading to Gold Coast B Sides tomorrow.

Paul McCarty 1:00

Tomorrow, yeah.

SPEAKER_01 1:01

Yeah, what's what's the vibe? What have you been hearing?

Paul McCarty 1:03

Oh my gosh. I mean, I think that you know, I think that all of these attacks have kind of hit you know the mainstream InfoSec. So like the conference I'm at right now is very kind of traditional InfoSec. It's called Oz Cert, it's been going for 25 years. Um it's a f it's it's Australia's cert uh conference, so like a US cert, for example. Um what I'm hearing is that uh these attacks have kind of gotten the visibility of SISO's and um mainstream InfoSec. Like anything else, like S bombs three years ago, right? They're all looking for these simplistic answers and you know they're regurgitating stuff that they've heard from other people. And so right now, everybody is like cooldown periods is gonna fix this. If I had if I heard cooldown periods one more time this week, I'm gonna freak out and publish some, I don't know, anyhow. Oh, we lost your audio. Jen's got a Jen's got a rogue, uh yeah, she's got a rogue microphone issue, but um All right, you got me I got ya, I got you, homie.

SPEAKER_01 2:17

I I have no explanation for that. It's the gremlins. Um computers. They somebody in the universe knew that we were gonna start uh talking some smack. Uh no, I was gonna say, I gave a little bit of a lightning talk last week about some of the top tips for um like more on the application security side for preventing malware consumption. And it was very much like, yes, you should do all these things. For example, cooldown periods, version pinning, uh, you know, dealing with life cycle scripts, but none of them are a silver bullet. There are no silver bullets in malware. Um, so on that note, I actually want to take us slightly out of order than what we'd planned on. And I want to start with uh, I don't even know if you've had a chance to catch up on this. The new NPM feature that uh just came out for staged publishing. Have you caught up on it yet?

Paul McCarty 3:11

I've done zero writing, so it's your show here.

SPEAKER_01 3:14

Okay, so I'll give kind of an overview of what I've looked into with the caveat that this is, you know, I've reviewed the docs and I've kind of poked around about what the concept is, but I have not implemented this. So if you've implemented this and you have a different experience than what I talked about, then definitely share that. But basically, the concept here is it creates a staging area for your package that requires an additional approval before it ships. So instead of npm publish pushing a package live immediately, you run this new npm stage publish, which is going to hold it in the staging area, and then a maintainer is gonna review and approve it. They have to have 2FA, and uh then it goes public. So the idea is it's a human checkpoint for open source packages or packages hope it's hosted on npm. So I will say first off, this is a real improvement. Um there's lots of things that npm has needed to do to improve security. And so if your you know, CI pipeline stages a release and a second human has to interactively approve it with a different account, then you've added a genuine barrier. Um, you know, the docs confirm that you can't um use OIDC tokens, it requires interactive authentication, so it can't just be automated away if you decide to turn this on, like there's a human holding the keys. Um what I understand, this probably would have prevented the compromise of those cap uh packages, what a month ago, where um team PCP had exploited a misconfigured OIDC trusted publisher workflow. However, um in my mind, this comes with a lot of caveats, and I'm sure you're already like spinning through what you think they are. Um, first of all, this is not going to do you any good if you're a maintainer group of one, right? Uh so that's the simple like this is meant or is going to be most valuable in a team type of environment. So the Axios compromise, for example, from what, like six weeks ago? Uh that would not have been stopped by this. Um, the other thing is there's a lot of stuff that the docs don't explicitly cover. Like my first question was um, if you turn this on, what's involved in turning it off? Like if my account was compromised, can the attacker just go in and turn this off? Um unclear. Also, it has to be enabled per package. It's not an org-wide publishing option, or there is no org-wide publishing. And so um I don't know that that's bad, but uh it definitely is a barrier to like turning it on in an easy mechanism. And there's no enforcement mechanism that says that the person who staged the package can't be the person approving the package. So yeah, like I would say lots of caveats with it. And even if this is the exact right type of like um feature for your organization, the reality is like when I had done some research earlier in the year with the Endor team, we had looked at accounts that were compromised previously through an ATO account takeover, and whether or not they had turned on trusted publishing, which is slightly different. And it was only like 13% of accounts that had already been compromised, which knew this was a problem, had turned on trusted publishing. And a lot of the accounts that hadn't turned it on were corporate accounts. Like you can look and see in the package names where you're like, oh, that's that's a company. So I think they should be using that. Sorry?

Paul McCarty 7:31

They should be using that.

SPEAKER_01 7:32

Yeah, they should be using it. And so, like, I think, yes, this is a good feature to exist, but it's very much, you know, opt-in. Um, there's lots of things that have to go right for this to go right, and there's just lots of questions that I personally have about how it will functionally work. Um, I would really hope that you know the person who turns it on can't necessarily I don't know, how would you handle turning it off?

Paul McCarty 8:05

Yeah, I mean, I don't know. You know, I've I've only been looking at it for a couple minutes here. You raise all these things are great points, right? And like you basically beaten me to all the things that I was gonna say. So there you go. Um, the it like you, I think this is a great effort. Good job, NPM. But uh I feel like this kind of falls into the bucket of like GitHub and NPM security stuff that they know nobody's gonna turn on, but then what they can do is they can say, Hey, see, we've been doing this, yeah, we've been doing stuff, and then you know nobody uses it, and so effectively the control doesn't provide any you know comfort.

SPEAKER_01 8:45

So yeah, they announced that this was coming back in January. I would have expected maybe a little bit more something around it, given it's been five months.

Paul McCarty 8:59

Yeah, well, I think most of the things that get pushed in NPM right now, which is not much, are really just people that have been seconded inside of Microsoft, put on this project, told to deliver it as quickly as possible, and then immediately go back to all their other Microsoft things. Because NPM doesn't have staff, right? Like NPM and GitHub are both being sucked into my well, npm already has been sucked into GitHub, and GitHub's being sucked into Microsoft, and you can just see it's terrible everywhere. They're not, you know, everything is bad right now. So I don't have a lot of good people.

SPEAKER_01 9:34

Uh two questions in the comments, and they're uh similar but different. So I'm gonna like take them one at a time. So the first one is from our uh YouTube stream, hello toaster32. What would you say would the size of team where you would recommend this being enabled by default, like Microsoft has in other areas to prevent ATO? Gosh, um, well, it's this probably pointless to do if your team's less than two. We'll we'll start there. Um, I think like poke at it a little bit, and I would err on the side like if you're a team of two, consider turning it on and seeing what the um friction looks like because it does absolutely introduce friction. This is designed to introduce a checkpoint. And so if you're a team of two and you turn this on and your second person is not looped in with your first person and you're releasing really quickly, then yeah, it could be a problem. I mean, uh a friend of mine, Alex, commented on the post that I did LinkedIn on LinkedIn earlier, and I'm just gonna read what he said because I think he kind of like um sums up the the thought process here of what where the bottlenecks could be. He says, like, is two-stage viable if an org has is publishing a boatload of packages, or what if they're looking at agentic code fixes moving really quickly? Does adding the human add security, but also a bottleneck? Like, absolutely, it's adding a bottleneck. Um well if it's a good bottleneck. But okay.

Paul McCarty 11:15

Sorry, sorry, I talked over you. My apologies.

SPEAKER_01 11:17

Go for it.

Paul McCarty 11:18

7,000 miles between you and I, and so there's a lot of you know distance for packets to travel, and so there's some latency there. But um uh all right, so I have to challenge. Listen, npm is not your staging branch. So if you are building in such a way where you're pushing lots and lots and lots of changes to your public npm packages, and this challenge, this MFA challenge is causing an issue, then I think that your CI and the way that you publish NPM packages is broken, full stop. Like that those those highly iterative stages need to be happening earlier in your in your CI process. And right, and so if you're pushing eight bazillion times, if this becomes an issue, then I frankly I think you probably aren't building and deploying to NPM in the right way. Sorry, that's my opinion.

SPEAKER_01 12:10

Yeah, that's fair. Okay, we've got a second one from Josh. Um, unique approver count required for this to avoid self-approve. Yeah, I don't know.

Paul McCarty 12:19

We yeah, sorry, Josh, we don't know yet. I just looked at this. I will get an answer for you, my friend, and I'll come back to you.

SPEAKER_01 12:25

Yeah, all right, let's move on to the next topic. I didn't think that was going to be as uh involved as it was, but it's very timely. Um, let's go back in time uh to May 18th. Was that really only like Monday? I guess so. Um you published a blog announcing that you had found three malicious NPM packages that were connected to the March Axios compromise that have been quietly harvesting developer credentials since early April. Paul, what did you find?

Paul McCarty 12:59

Yeah, I mean, uh that that's pretty much it. There's there's three NPM packages um that I've tied back to the the uh the threat actor that that published um the Axios. And Axios used a um you know a dependency. So plain Crypto.js was the actual payload, and they just changed they just added a post-install script to call that. Or uh no, sorry, just a sorry, I'm sorry, I lied, just a dependency. Um but yeah, I mean this uh I think I don't think we should be surprised. Um the uh DPRK, so North Korea in particular, loves uh multi-use attacks, right? And so and multi-kind of flanking attacks. I don't know, I'm using too many military terms here, but what I mean by that is that you know Axios, obviously one of the most popular packages on the face of the planet. If you get a malicious dependency into it, lots of people get exposed. But in the meantime, there's other or you know, other uh groups inside of DPRK inside of Lazarus that are doing contagious interview and all these other kind of campaigns in parallel. And so what what these three packages were built for, my assumption is to be well, actually, I found evidence of this. There's you know, there's several GitHub repos that are calling out to these packages. I think these additional malicious packages, which have slightly different um uh install uh or you know, payload mechanism, but very similar. Um I think they were built, you know, for like the contagious interview and the the task checker campaign and and and that kind of constant hum. And that's how DPRK works. They just create all this fabric of stuff and they just you know compromise everywhere they can.

SPEAKER_01 14:37

Yeah, very highly um productive. We'll share the link to that analysis. I already pushed it out to YouTube. I'll drop it in um LinkedIn later because I find that stream is not as friendly while things are running live. Okay, next topic is uh I had it labeled as team PCP, latest team PCP attack. It's actually not. Um we're not gonna get to GitHub yet, but we're going to GitHub, I promise. Um, you also discovered earlier this week that two maintainers were compromised. Uh, we don't know how yet. Uh these maintainers, especially one of them, have just a boatload of packages that they um maintain. And so the Threat Actor was able to publish over 600 malicious versions of these packages. Looks like they probably contain the same many Shy Halut payloads. Um, we haven't fully analyzed them yet. But, Paul, the blast radius that you have outlined in this blog is pretty substantial. You said that just three of the compromised packages account for five million downloads a week.

Paul McCarty 15:52

Yep.

SPEAKER_01 15:53

That's crazy.

Paul McCarty 15:54

Oh, it's crazy. Yeah, I mean, this is, you know, go ahead. Sorry.

SPEAKER_01 15:59

No, anything else you want to share on this given we haven't analyzed it fully yet?

Paul McCarty 16:03

Yeah, I mean, I've gotten into the guts of it. It's um, you know, it's it's very similar. There are a few differences, and you know, team PCP keeps evolving. Or wait, uh yeah, no, this is PCP. Yeah, yeah, yeah. Sorry. They all blend together. How dude, if I had a dollar for every time in the last two weeks I said hell, the last month, two months, it all blends together. Yeah, like four times yesterday at the conference. Uh yeah, slightly, but but they're evolving. You know, the the payloads, the kind of what they're looking for and what they're stealing are all evolving. Um, and they're you know, they're they're now attacking Claude and some of the the common agentic tools that we're all using. Um, but you know, I mean, I I want to talk about the the first part of it, which is this one individual developer, um, a tool, who got popped, um, Chinese developer. I mean, that has nothing to do with nothing, but um, 540 packages just under that one maintainer. And that's awesome.

SPEAKER_01 17:01

Yeah, just a ton, like the blast radius is huge on this.

Paul McCarty 17:06

Yeah, 104. I mean, I you know, there's there's lots of maintainers that are like this, and NPM has not done a good enough job as really kind of enforcing some of these um uh you know security changes and best practices to existing accounts. They're waiting for people to voluntarily do some of these things, but anyhow, you know, I mean it you know it is what it is. Old mate got popped, and you know, team PCP has sucked up a bunch more credentials and are gonna use those onwards until they get arrested, which hopefully happens soon.

SPEAKER_01 17:42

They did another thing on Monday or Tuesday as we're starting to compile the list of things to talk about on the show, and it I think we both kind of said it at the same time. We're getting we're getting a little tired of this topic.

Paul McCarty 17:54

Yeah, I mean, I would like to talk about something other than team PCP on the open source for a lot of reasons, yeah. Um they team PCP. I'm sorry, I'm gonna say that and then I'm gonna talk about team PCP. They did another interview, Jen. So before this, oh no, they did not. They did another interview and some more opse stuff in there. So I don't know, man. Just stop talking. You're just hastening. Uh maybe no, actually, keep talking.

SPEAKER_01 18:22

No, please keep talking.

Paul McCarty 18:23

Yeah, what am I thinking? What am I saying? Keep talking.

SPEAKER_01 18:27

Dig that that hole for yourself. Okay, last topic, uh, but it's still team PCP, sorry. Um on Monday, uh, GitHub detected. I'm gonna read off what they said, uh, detected and contained a compromise on an employee device involving a poisoned VS Code extension published by a third party. Um that's a bummer. So I was digging into it a little bit before the call because you uh knew about this pretty quickly, and you knew pretty quickly which VS Code extension it was. Unfortunately, uh this extension comes from NX, which was also compromised in the Singularity attack last year. Um, NX is used for monorepo management, and uh, we don't know specifically, you know, why this particular extension was being used, but understandable, this is a piece of infrastructure that gets used a lot. Um I will give Enex some credit. They write really good post mortems, they learn from their mistakes. So I'm gonna share a series of links here. I mean, there's always new mistakes to make, Paul. Let's be clear. Related mistakes.

Paul McCarty 19:45

Um, but they at least they're not check marks, right? Yeah.

SPEAKER_01 19:49

Um basically what happened uh is so when they got um compromised last year, when the NX package was compromised, the maintainer, um the threat actor had taken advantage of a GitHub as act GitHub actions vulnerability. And that's how they were able to publish. That is not what happened this time around. This time around, um, one of their developers was compromised through the Tanstack uh compromise that happened. I don't know, even when. Time is weird, a couple weeks ago. And so what they said was uh that the uh Tanstack, the malware in Tanstack uh silently exfiltrated the maintainer's GitHub CLI OAuth token seven days before the malware was published. And so what they said is the credential theft happened on May 11th, the marketplace published happened on May 18th. So they were active in Inex's GitHub repos for seven days without detection. Uh VS the Visual Studio Marketplace uh took it down within, it was like a really short amount of time, 11 minutes, and Open VSX took it down within 36 minutes. This is just showing like how fast these things move. So, you know, it was only up for a max amount of time of 36 minutes, and in that time, somebody from GitHub consumed one of those poisoned versions, and that's how Team PCP got access to what I think they're saying is like 5,000 repos, and they have said that they're um gonna sell the data.

Paul McCarty 21:41

Yeah, I mean, it's last last number that I saw for the repos was 3,800, 3,800. Um, and I was looking through late last night, I was looking through some of the names of some of those repos, and um, you know, it's what you expect. I also saw somebody did an analysis of just the names and kind. Of their uh observation was that it it checks out, like it looks like you know what you would expect. It uses the naming, um, the kind of common internal naming conventions that GitHub uses for different things, and so that kind of all checks out. Um, yeah, I mean, the uh just the I want to on that point of how long it was up. There's this is a this there's a contentious thing because they say it was only up for like 18 minutes or 31 minutes or whatever it is, but like I grabbed it outside of that window. Uh, I'm pretty sure. I mean, I might have grabbed it inside that window, but I grabbed it and um um you know while our automation grabbed it. Um and uh I've heard a lot of other people say that it was available via CDN or other you know means outside of that that you know that window.

SPEAKER_01 22:51

So uh let's totally possible. You've been preaching about this for a while, huh?

Paul McCarty 22:56

Right? Yeah, Remy mentioned.

SPEAKER_01 22:58

It's gone doesn't mean it's gone.

Paul McCarty 23:00

Yeah, yeah, like that's you know, both in the Python world and in the JavaScript world. And remember, VS Code extensions are just JavaScript, right? You can run the same analysis that you do on them that you do on your npm packages. You can use tools like guard dog and muadeeb and other stuff. But um yeah, what one of the things I thought was interesting, like I think if I understand this correctly, basically what happened was that a employee got done via TanStack, like you said, then published a malicious VS Code extension, then another Microsoft employee consumed said VS Code extension, which then led to the exposure. That's what I understand it. Yeah, yeah. I just the level of inception here is just you know, it blows my mind. I've got a whole blog post written up about that. I just haven't had a chance to post it. Just like it just blows my mind. Microsoft employee using a Microsoft product compromises another Microsoft employee, which then compromises leaks a bunch of GitHub repos. Um, pull your head out, yo. Uh seriously.

SPEAKER_01 24:04

Yeah, it's it's not great, not a good look. Um not a whole lot of information from GitHub. The link that I shared about the GitHub compromise is about three paragraphs. Uh, you know, they're staying focused on things like no customer data affected, but um I'm sure the threat actors got a hold of something that someone will want. It's probably not junk info.

Paul McCarty 24:32

I do have a little bit of information there. So they they were they were asking for bids. So they asked starting at 50k, which I thought way to start low, low expectation heaven. But I last I saw that the bid was up to $95,000. Um, and looking at the files, I mean, that's you know, I'm not surprised. Like, doesn't appear to be anything smoking. It's not like that size breach, Jesus.

SPEAKER_01 24:59

Yeah, oops. Um, so let's talk about keys in brief before we wrap up because both the if you say syssa or siza, either way, I think it's funny. You and I say CISO and SISO. Anyway, we mean the same thing. CISA, there was a uh private repository. That's how it was labeled as private.

Paul McCarty 25:23

Name it was public, it was name private private repository.

SPEAKER_01 25:26

Um, but it was not private and it had a whole bunch of keys in there. Um and I think this is kind of going back to what we talked about. I feel like maybe last week or the week before, where you need to really get a hold on uh having visibility into which keys have been compromised. Um, if you can't, you know, first of all, turn on whatever free stuff there is. There's lots of good free tools to scan for that sort of stuff. But yeah, more and more I'm seeing the need for these endpoint products that will look, you know, be able to tell what's on your developer endpoints so that you can rotate.

Paul McCarty 26:06

And and and we need to start talking about managing GitHub repo sprawl, right? Like I think that that private repo was in the size of um uh uh organization. I think I could be wrong, but I think it was inside the size of organization, GitHub organization, excuse me. Um like, you know, why are you letting people create public repos inside? I just you know it's the same thing that we were dealing with AWS and CloudSprawl, and then I mean a lot of this goes back to many permissions are opt-in, not opt-out.

SPEAKER_01 26:41

And with GitHub, you know, many of those permissions are opt-in. That's just and again, we've talked about this a lot. There's reasons for that. We may not agree with them, but there's reasons that you know products will decide to make you make a conscious decision to turn things on.

Paul McCarty 27:05

I um we can talk about this next week in more depth. Um, but I got a response back to my super base VDB disclosure, and it's not good.

SPEAKER_01 27:17

Oh goodness. Well, that's a good teaser for next week, right?

Paul McCarty 27:22

Dun dun dun. Wait, wait, what's the law and order one? Dun dun.

SPEAKER_01 27:29

All right. On that note, I think we've hit everything we wanted to cover. We did a good job keeping it in about 30 minutes this time. Anything you want to touch on before we wrap up?

Paul McCarty 27:41

Gold Coast B-Sides is tomorrow. If you're in Australia and you're in the area, there are still some tickets available. We'd love to see people come out. Gonna have a great day.

SPEAKER_01 27:48

I love a B-Sides. I wish I need an excuse to come down. I will be in San Francisco next week. If anyone's looking for some good stuff on uh AI agent security, I'm gonna be giving a talk next week on malicious skills, sketchy skills. And I think it's gonna be a good event. Um, I've heard a lot of good things about it. So check out Senate's AI agent summit, I think is what it's called. Yeah. All right. Well, enjoy Oz CERN B sides, and I'll catch you later.

Paul McCarty 28:19

Thanks everybody for listening. We appreciate it. Cheers.

SPEAKER_01 28:21

Cheers.