srcery-vscode icon indicating copy to clipboard operation
srcery-vscode copied to clipboard

[MALWARE] 0.3.9 is COMPROMISED; USE 0.3.10

Open IlyasMakari opened this issue 6 months ago • 12 comments

🚨 Security Alert: Malicious Version Detected on Open VSX

Hi, I’m a malware researcher at Aikido Security. I wanted to let you know that we’ve identified a compromised version of your VS Code extension Srcery published on Open VSX.

Specifically:

This version appears to have been injected with malicious code that could trigger a payload when users install the extension.

We’ve already contacted Open VSX directly so they can take action on their side, but I wanted to make sure you’re aware as the maintainer. It would be a good idea to:

  • Rotate your tokens and any associated credentials
  • Enable MFA wherever possible
  • Review recent account activity to ensure no other projects are affected
  • Publish a new, clean version of the extension to help protect your users

We are still investigating the source of this attack, but we’ve seen a wave of similar attacks affecting multiple projects today.

If you’d like more technical details from our findings, I’d be happy to share them.

IlyasMakari avatar Oct 17 '25 19:10 IlyasMakari

@MindTooth Do you know if you might have been breached? I'm trying to figure out where I would have got pwned but can't find it though... Do you know what's the modus operandi of the attack? I wonder if it can help figuring out the vulnerability. Are all affected packages on OpenVSX ? I assume that the open-vsx email campaign about the "publisher agreement change" is a prime occasion for a phishing campaign...

gagbo avatar Oct 17 '25 19:10 gagbo

Oh. Where would you suspect me being compromised? I can rotate my GitHub password.

Do we know where the vulnerability occurred?

MindTooth avatar Oct 17 '25 19:10 MindTooth

I don't know, I didn't click any link recently, so the next thing is maybe you, and then the next most likely thing is an admin account on Eclipse being compromised. That's weird that we indeed have a 3h old 3.9 version

And it seems we have no audit log on open-vsx, too

gagbo avatar Oct 17 '25 19:10 gagbo

I don’t see other tags in other repos.

Yeah, the email was strange. But, the 3.9 is only on VSX? I don’t see any tags for 3.9 here.

MindTooth avatar Oct 17 '25 19:10 MindTooth

Ok, my access token was used 3h ago, which should be only existing on my home desktop if I were to believe the name.... The weirdest part is that the machine hasn’t even turned on in a while

gagbo avatar Oct 17 '25 19:10 gagbo

I had some within the last week. Not sure if I could see when more specific. I deleted all. Also changed my password earlier.

MindTooth avatar Oct 17 '25 19:10 MindTooth

I just republished 3.10 from https://github.com/srcery-colors/srcery-vscode/pull/20 creating a new token and deleting the old one. I’ll also delete this new one

Now I guess I need to figure out where and how that token I even forgot existed leaked...

gagbo avatar Oct 17 '25 19:10 gagbo

@IlyasMakari how can you verify your identity?

Thanks for flagging it. But now it coming things from multiple directions. 😅

MindTooth avatar Oct 17 '25 20:10 MindTooth

I tried to look at openvsx API (through the codebase of the CLI on their repo), and it seems that the create-namespace endpoint doesn’t require a known user/namespace in order to "try" a PAT.

I just tested it. OpenVSX has an issue where their create-namespace endpoint is checking for namespace validity AFTER checking for authentication. And an openVSX token is just an uuidv4

❯ npx ovsx create-namespace 'norese_>' -p $VALID_TOKEN
❌  Invalid namespace name: norese_>

❯ npx ovsx create-namespace 'norese_>' -p $INVALID_TOKEN
❌  Invalid access token.

So spamming the queries with random uuid4s means you "just" fish for valid tokens against the total pool of existing tokens, without any visible side-effect even, since the namespace isn’t created.

I’ll let you @IlyasMakari deal with the disclosures, or maybe you already did; sorry for not trying more than this, I’m still a bit irritated about getting notified for this.

gagbo avatar Oct 17 '25 20:10 gagbo

Meanwhile, I’ll just delete all my tokens there

Once you fished a valid uuid token:

  • create a real namespace
  • invite an account you control as an admin -> Hacker’s account has an invitation from the uuid’s user
  • Hacker revoke rights to fake namespace, so that OG user doesn’t see anything
  • Now hacker
    • knows the identity of OG user (and can navigate their packages to know what to publish), and
    • obviously has the token

I’m not 100% sure that would work, but I know that’s what I would try

Actually, you probably don’t even need to create a fake namespace to test things, unless maybe the rate limits/detection is different between namespaces that exist and the ones that don’t. Not having to specify anything else than a uuid4 against the complete list of outstanding tokens seems weird to me

gagbo avatar Oct 17 '25 20:10 gagbo

Write up: https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace

MindTooth avatar Oct 20 '25 21:10 MindTooth

I'm still not sure I was infected, or I have an otherwise squeky-clean credential hygiene: I have 0 suspicious github or npm activity, and the credentials weren't yet found in clear text in the computer that had them (I guess it might have been in the shell history) I'm still trying to assess how I could've been infected. Maybe the packaging issue they mention: I haven't scanned the package before uploading to open-vsx, and maybe the .envrc I tend to use has been pushed even if it's ignored

gagbo avatar Oct 22 '25 07:10 gagbo