supply chain attack

6 Articles

This Week In Security: XRP Poisoned, MCP Bypassed, And More

April 25, 2025 by 7 Comments

Researchers at Aikido run the Aikido Intel system, an LLM security monitor that ingests the feeds from public package repositories, and looks for anything unusual. In this case, the unusual activity was five rapid-fire releases of the xrpl package on NPM. That package is the XRP Ledger SDK from Ripple, used to manage keys and build crypto wallets. While quick point releases happen to the best of developers, these were odd, in that there were no matching releases in the source GitHub repository. What changed in the first of those fresh releases?

The most obvious change is the checkValidityOfSeed() function added to index.ts. That function takes a string, and sends a request to a rather odd URL, using the supplied string as the ad-referral header for the HTML request. The name of the function is intended to blend in, but knowing that the string parameter is sent to a remote web server is terrifying. The seed is usually the root of trust for an individual’s cryptocurrency wallet. Looking at the actual usage of the function confirms, that this code is stealing credentials and keys.

The releases were made by a Ripple developer’s account. It’s not clear exactly how the attack happened, though credential compromise of some sort is the most likely explanation. Each of those five releases added another bit of malicious code, demonstrating that there was someone with hands on keyboard, watching what data was coming in.

The good news is that the malicious releases only managed a total of 452 downloads for the few hours they were available. A legitimate update to the library, version 4.2.5, has been released. If you’re one of the unfortunate 452 downloads, it’s time to do an audit, and rotate the possibly affected keys. Continue reading “This Week In Security: XRP Poisoned, MCP Bypassed, And More” →

This Week In Security: The Github Supply Chain Attack, Ransomware Decryption, And Paragon

March 21, 2025 by 4 Comments

Last Friday Github saw a supply chain attack hidden in a popular Github Action. To understand this, we have to quickly cover Continuous Integration (CI) and Github Actions. CI essentially means automatic builds of a project. Time to make a release? CI run. A commit was pushed? CI run. For some projects, even pull requests trigger a CI run. It’s particularly handy when the project has a test suite that can be run inside the CI process.

Doing automated builds may sound straightforward, but the process includes checking out code, installing build dependencies, doing a build, determining if the build succeeded, and then uploading the results somewhere useful. Sometimes this even includes making commits to the repo itself, to increment a version number for instance. For each step there are different approaches and interesting quirks for every project. Github handles this by maintaining a marketplace of “actions”, many of which are community maintained. Those are reusable code snippets that handle many CI processes with just a few options.

One other element to understand is “secrets”. If a project release process ends with uploading to an AWS store, the process needs an access key. Github stores those secrets securely, and makes them available in Github Actions. Between the ability to make changes to the project itself, and the potential for leaking secrets, it suddenly becomes clear why it’s very important not to let untrusted code run inside the context of a Github Action.

And this brings us to what happened last Friday. One of those community maintained actions, tj-actions/changed-files, was modified to pull an obfuscated Python script and run it. That code dumps the memory of the Github runner process, looks for anything there tagged with isSecret, and writes those values out to the log. The log, that coincidentally, is world readable for public repositories, so printing secrets to the log exposes them for anyone that knows where to look.

Researchers at StepSecurity have been covering this, and have a simple search string to use: org:changeme tj-actions/changed-files Action. That just looks for any mention of the compromised action. It’s unclear whether the compromised action was embedded in any other popular actions. The recommendation is to search recent Github Action logs for any mention of changed-files, and start rotating secrets if present. Continue reading “This Week In Security: The Github Supply Chain Attack, Ransomware Decryption, And Paragon” →

This Week In Security: Cookie Monster, CyberGhost, NEXX, And Dead Angles

April 7, 2023 by 5 Comments

“Operation Cookie Monster” ranks as one of the best code names in recent memory. And it’s apropo, given what exactly went down. Genesis Market was one of those marketplaces where criminals could buy and sell stolen credentials. This one was a bit extra special.

Websites and services are getting better about detecting logins from unexpected computers. Your Google account suddenly logs in from a new computer, and a two-factor authentication challenge launches. Why? Your browser is missing a cookie indicating you’ve logged in before. But there’s more. Providers have started rolling out smart analytics that check for IP address changes and browser fingerprints. Your mix of time zone, user string, installed fonts, and selected language make a pretty unique identifier. So sites like Genesis offer Impersonation-as-a-Service (IMPaaS), which is session hijacking for the modern age.

A victim computer gets owned, and credentials are collected. But so are cookies and a browser fingerprint. Then a criminal buyer logs in, and runs a virtual browser with all that collected data. Run through a proxy to get a IP that is geolocated close enough to the victim, and Mr. Bad Guy has a cloned machine with all accounts intact.

And now back to Operation Cookie Monster, a multi-organization takedown of Genesis. It’s apparently a partial takedown, as the latest word is that the site is still online on the Tor network. But the conventional domains are down, and something like eight million credentials have been captured and added to the Have I Been Pwned database.

Another researcher team, Sector 7, has been working the case with Dutch authorities, and has some interesting details. The vector they cover was a fake activation crack for an antivirus product. Ironic. There are several extensions that get installed on the victim computer, and one of the most pernicious is disguised as Google Drive. This extension looks for a Command and Control server, using Bitcoin as DNS. A hardcoded Bitcoin address is polled for its latest transaction, and the receiving address is actually an encoded domain name, you-rabbit[.]com as of the latest check.

This extension will look for and rewrite emails that might be warning the victim about compromise. Get an email warning about a cryptocurrency withdrawal? It modifies it in the browser to be a sign-in warning. It also allows Genesis customers to proxy connections through the victim’s browser, bypassing IP address security measures. Continue reading “This Week In Security: Cookie Monster, CyberGhost, NEXX, And Dead Angles” →

This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key

March 31, 2023 by 6 Comments

There’s a naming overload here, as two bits of security news this week are using the “MacStealer” moniker. We’re first going to talk about the WiFi vulnerability, also known as Framing Frames (pdf). The WPA encryption schemes introduced pairwise encryption, ensuring that not even other authenticated users can sniff each others’ traffic. At least that’s the idea, but this attack finds a couple techniques to bypass that protection.

A bit more background, there are a couple ways that packets can be delayed at the sender side. One of those is the power-save message, that signals the access point that the given client is going into a low power state. “Hold my calls, I’m going to sleep.” That message is a single bit in a frame header. And notably, that bit isn’t covered by WPA encryption or verification. An attacker can send a message, spoof a victim’s MAC address, and the access point marks that client as being in power-save mode.

This observation leads to a question: What happens when the encryption details change between the packet joining the queue, and actually transmitting? Turns out, the specifications on WiFi encryption don’t spell it out, and some implementations do the last thing you’d want, like sending the packets in the clear. Whoops. This behavior was the case in the Linux kernel through version 5.5.0, but starting with 5.6.0, the buffered packets were simply dropped when the encryption key was unavailable. Continue reading “This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key” →

A Zhengbang Pick&Place machine, with a Virustotal 53/69 result and "53 security vendors and 1 sandbox flagged this file as mailcious" crudely overlaid on top of the image

Zhengbang Pick & Places Your Confidential Data In The Bag, Slowly

January 22, 2022 by 30 Comments

Isn’t it convenient when your pick-and-place machine arrives with a fully-set-up computer inside of it? Plug in a keyboard, mouse and a monitor, and you have a production line ready to go. Turns out, you can have third parties partake in your convenience by sharing your private information with them – as long as you plug in an Ethernet cable! [Richard] from [RM Cybernetics] has purchased a ZhengBang ZB3245TSS machine, and in the process of setting it up, dutifully backed up its software onto a USB stick – as we all ought to.

This bit of extra care, often missed by fellow hackers, triggered an antivirus scanner alert, and subsequently netted some interesting results on VirusTotal – with 53/69 result for a particular file. That wasn’t conclusive enough – they’ve sent the suspicious file for an analysis, and the test came back positive. After static and dynamic analysis done by a third party, the malware was confirmed to collect metadata accessible to the machine and send it all to a third-party server. Having contacted ZhengBang about this mishap, they received a letter with assurances that the files were harmless, and a .zip attachment with replacement “clean” files which didn’t fail the antivirus checks.

It didn’t end here! After installing the “clean” files, they also ran a few anti-malware tools, and all seemed fine. Then, they plugged the flash drive into another computer again… to encounter even more alerts than before. The malware was equipped with a mechanism to grace every accessible .exe with a copy of itself on sight, infecting even .exe‘s of the anti-malware tools they put on that USB drive. The article implies that the malware could’ve been placed on the machines to collect your company’s proprietary design information – we haven’t found a whole lot of data to support that assertion, however; as much as it is a plausible intention, it could have been a case of an unrelated virus spread in the factory. Surprisingly, all of these discoveries don’t count as violations of Aliexpress Terms and Conditions – so if you’d like to distribute a bunch of IoT malware on, say, wireless routers you bought in bulk, now you know of a platform that will help you!

This goes in our bin of Pretty Bad News for makers and small companies. If you happen to have a ZhengBang pick-and-place machine with a built-in computer, we recommend that you familiarize yourself with the article and do an investigation. The article also goes into details on how to reinstall Windows while keeping all the drivers and software libraries working, but we highly recommend you worry about the impact of this machine’s infection spread mechanisms, first.

Supply chain attacks, eh? We’ve seen plenty of these lately, what’s with communities and software repositories being targeted every now and then. Malware embedded into devices from the factory isn’t a stranger to us, either – at least, this time we have way more information than we did when Supermicro was under fire.

Editor’s Note: As pointed out by our commenters, there’s currently not enough evidence to assert that Zhengbang’s intentions were malicious. The article has been edited to reflect the situation more accurately, and will be updated if more information becomes available.

Editor’s Note Again: A rep from Zhengbang showed up in the comments and claims that this was indeed a virus that they picked up and unintentionally passed on to the end clients.

ua-parser-js compromised

Supply Chain Attack: NPM Library Used By Facebook And Others Was Compromised

October 22, 2021 by 26 Comments

Here at Hackaday we love the good kinds of hacks, but now and then we need to bring up a less good kind. Today it was learned that the NPM package ua-parser-js was compromised, and any software using it as a library may have become victim of a supply chain attack. What is ua-parser-js and why does any of this matter?

In the early days of computing, programmers would write every bit of code they used themselves. Larger teams would work together to develop larger code bases, but it was all done in-house. These days software developers don’t write every piece of code. Instead they use libraries of code supplied by others.

For better or worse, repositories of code are now available to do even the smallest of functions so that a developer doesn’t have to write the function from scratch. One such registry is npm (Node Package Manager), who organize a collection of contributed libraries written in JavaScript. One only need to use npm to include a library in their code, and all of the functions of that code are available to the developer. One such example is ua-parser-js which is a User Agent Parser written in JavaScript. This library makes it easy for developers to find out the type of device and software being used to access a web page.

On October 22 2021, the developer of ua-parser-js found that attackers had uploaded a version of his software that contained malware for both Linux and Windows computers. The malicious versions were found to steal data (including passwords and Chrome cookies, perhaps much more) from computers or run a crypto-currency miner. This prompted GitHub to issue a Critical Severity Security Advisory.

What makes this compromise so dangerous is that ua-parser-js is considered to be part of a supply chain, and has been adopted even by Facebook for use in some of its customer facing software. The developer of ua-parser-js has already secured his GitHub account and uploaded new versions of the package that are clean. If you have any software that uses this library, make sure you’ve got the latest version!

Of course this is by no means a unique occurrence. Last month Maya Posch dug into growing issues that come from some flaws of trust in package management systems. The art for that article is a house of cards, an apt metaphor for a system that is only as stable as the security of each and every package being built upon.