NPM

9 Articles

This Week In Security: NPM, Kerbroasting, And The Rest Of The Story

September 12, 2025 by 3 Comments

Two billion downloads per week. That’s the download totals for the NPM packages compromised in a supply-chain attack this week. Ninety-nine percent of the cloud depends on one of the packages, and one-in-ten cloud environments actually included malicious code as a result of the hack. Take a moment to ponder that. In a rough estimate, ten percent of the Internet was pwned by a single attack.

What extremely sophisticated technique was used to pull off such an attack? A convincing-looking phishing email sent from the newly registered npmjs.help domain. [qix] is the single developer of many of these packages, and in the midst of a stressful week, fell for the scam. We could refer to the obligatory XKCD 2347 here. It’s a significant problem with the NPM model that a single developer falling for a phishing email can expose the entire Internet to such risk.

And once that account was compromised, it didn’t take long for the mystery attacker to push malicious code. Within an hour, cryptocurrency stealing code was added to two dozen packages. Within a couple hours, the compromise was discovered and the cleanup effort began.

While the attack was staggering in its breadth, in the end only a few hundred dollars worth of cryptocurrency was actually stolen as a result. Why was such a successful attack, when measured by deployment, so minimal in actual theft? Two reasons: First, the malware was only live for two hours before takedowns began. And a related second reason, the malicious code was specifically aimed at developer and end-user machines, while the majority of the installs were on servers and cloud deployments, where cryptocurrency transactions weren’t happening.

It brings to mind the question, what could have happened? Instead of looking for cryptocurrency to steal, if the malicious code was tailored to servers and stealth, how long would it have taken to detect? And is there malicious code on NPM and in other places that we just haven’t discovered yet?

SAP ERP CVEs

Let’s break down this Alphabet soup. SAP is an acronym for “Systems, Applications and Products in Data Processing”, a German company providing business software. ERP is their Enterprise Resource Planning software, and of course a CVE is a Common Vulnerabilities and Exposure. So to translate the acronyms, SAP’s accounting software has vulnerabilities. And in this case, CVE-2025-42944 is a ten out of ten on the CVSS severity scale.

In fact, there are four vulnerabilities altogether, all CVSS of nine or higher, and all in the underlying NetWeaver platform. SAP owned up to the problems, commenting that they operated as a backdoor, allowing unauthorized access. Patches are available for all of these issues, but some of them have been found in use in the wild.

Kerbroasting

You know it’s bad when a sitting US Senator can tell that your security has problems. Though before I read the article, I had a feeling it would be [Ron Wyden].

The issue here is Microsoft’s support for RC4 encryption in Active Directory. RC4, also known as ARC4, is a pseudorandom number generator developed at RSA in 1987. This continuing support leads to an attack known as kerberoasting.

Kerberos is one of the protocols that powers Active Directory. It works through a sort of ticket signing system. The server doing the signing takes a hash of a password and uses that hash as an encryption key to encrypt the Kerberos ticket. There are two possible problems. First, that password may be a human generated password, and therefore a weak password. And second, the legacy combination of RC4 and original NT hashing makes for extremely fast offline password guessing.

So here’s the kerberoasting attack: Take any account in the Active Directory, and request a Kerberos ticket, specifying the legacy RC4 encryption. Take this offline ticket to a modern CPU/GPU, and use Hashcat to crack that password, at a guess rate measured in the billions per second. Once that password is discovered, arbitrary Kerberos tickets can be signed, providing access to basically any account on the AD system.

This was part of the 2024 ransomware attack on Ascension health, and why the US senate is taking notice. What’s strange is how resistant Microsoft has been to fixing this issue. Microsoft states that RC4 only makes up .1% of traffic, which is nonsense, since the attack doesn’t rely on traffic. Finally in 2026, new installs of Windows server 2025 will disable RC4 by default.

Reverse Engineering and TLS Hacking

We get a great primer from [f0rw4rd] on how to defeat TLS certificates, in a very specific scenario. That scenario is reverse engineering an embedded or industrial Linux system. One of the tools you might want to use is to intercept traffic from the embedded system to some web server, but if that system uses HTTPS, it will fail to verify that certificate. What is a researcher to do?

One possible solution is to abuse LD_PRELOAD to poison the application. This approach uses dynamic library loading to insert a “malicious” library before program execution. tls-preloader is a tool to do exactly this, and supports multiple SSL/TLS libraries, allowing sniffing all that useful TLS data.

The Rest of the Story

Just recently we mentioned several 0-day vulnerabilities that were being used for in-the-wild attacks. This week we have updates on a couple of those. First is the iOS and macOS vulnerability in DNG image file processing. The basic issue is that this file type has a TIFF header that includes a SamplesPerPixel metadata, and a SOF3 section with a component count. A properly formatted file will have consistency between these two elements, and the Apple file processing didn’t handle such an inconsistency correctly, leading to memory corruption and potentially Remote Code Execution (RCE).

The other recent 0-day is a FreePBX flaw that was discovered through the presence of a clean.sh script on multiple FreePBX installs. The flaw was an automatic class loader that allowed an unauthenticated user to include module files when calling the ajax.php endpoint. One way to turn this into an exploit is SQL injection in one of the modules. This is what has been patched, meaning there are likely more exploits to find using this php injection quirk.

Bits and Bytes

The Apple CarPlay SDK had a buffer overflow that was reachable by a device connecting to the vulnerable head unit. Researchers from oligo discovered this flaw, and presented it at Def Con this year. The end result is root-level RCE, and while Apple has already published an SDK update, most cars are still vulnerable to this one.

And finally, enjoy [LaurieWired] taking a look at this year’s International Obfuscated C Code Contest (IOCCC) winners. This contest is all about pushing the limits in how terrifying C code can be, while still compiling and doing something interesting. And these entries don’t disappoint.

This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG

October 14, 2022 by 12 Comments

First up is some clever wizardry from the [Aqua Nautilus] research team, who discovered a timing attack that leaks information about private npm packages. The setup is this, npm hosts both public and private node.js packages. The public ones are available to everyone, but the private packages are “scoped”, meaning they live within a private namespace, “@owner/packagename” and are inaccessible to the general public. Trying to access the package results in an HTTP 404 error — the same error as trying to pull a package that doesn’t exist.


The clever bit is to keep trying, and really pay attention to the responses. Use npm’s API to request info on your target package, five times in a row. If the package name isn’t in use, all five requests will take the expected amount of time. That request lands at the service’s backend, a lookup is performed, and you get the response. On the flipside if your target package does exist, but is privately scoped, the first request returns with the expected delay, and the other four requests return immediately. It appears that npm has front-end that can cache a 404 response for a private package. That response time discrepancy means you can map out the private package names used by a given organization in their private scope.

Now this is all very interesting, but it turns into a plausible attack when combined with typosquatting and dependency confusion issues. Those attacks are two approaches to the same goal, get a node.js deployment to run a malicious package instead of the legitimate one the developer intended. One depends on typos, but dependency confusion just relies on a developer not explicitly defining the scope of a package.

Continue reading “This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG” →

This Week In Security: NPM Vandalism, Simulating Reboots, And More

January 14, 2022 by 33 Comments

We’ve covered quite a few stories about malware sneaking into NPM and other JavaScript repositories. This is a bit different. This time, a JS programmer vandalized his own packages. It’s not even malware, perhaps we should call it protestware? The two packages, colors and faker are both popular, with a combined weekly download of nearly 23 million. Their author, [Marak] added a breaking update to each of them. These libraries now print a header of LIBERTY LIBERTY LIBERTY, and then either random characters, or very poor ASCII art. It’s been confirmed that this wasn’t an outside attacker, but [Marak] breaking his own projects on purpose. Why?

It seems like this story starts back in late 2020, when [Marak] lost quite a bit in a fire, and had to ask for money on Twitter. Edit: Thanks to commenter [Jack Dansen] for pointing out an important detail that was missing. Marak was charged for reckless endangerment, and was suspected for possible terrorism aspirations, as bomb-making materials were found in his burned-out apartment. Two weeks later, he tweeted that billions were being made off open source devs’ work, citing a FAANG leak. FAANG is a reference to the big five American tech companies: Facebook, Apple, Amazon, Netflix, and Google. The same day, he opened an issue on Github for faker.js, throwing down an ultimatum: “Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.”
Continue reading “This Week In Security: NPM Vandalism, Simulating Reboots, And More” →

This Week In Security: Printing Shellz, Ms-officecmd, And AI Security

December 10, 2021 by 18 Comments

Researchers at f-secure have developed an impressive new attack, leveraging HP printers as an unexpected attack surface. Printing Shellz (PDF) is a one-click attack, where simply visiting a malicious webpage is enough to get a shell and reverse proxy installed to a printer on the same network. The demo below uses a cross-site printing (XSP) attack to send the malicious print job to the printer without any further interactions.
Continue reading “This Week In Security: Printing Shellz, Ms-officecmd, And AI Security” →

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.

The Dark Side Of Package Repositories: Ownership Drama And Malware

September 8, 2021 by 77 Comments

At their core, package repositories sound like a dream: with a simple command one gains access to countless pieces of software, libraries and more to make using an operating system or developing software a snap. Yet the rather obvious flip side to this is that someone has to maintain all of these packages, and those who make use of the repository have to put their faith in that whatever their package manager fetches from the repository is what they intended to obtain.

How ownership of a package in such a repository is managed depends on the specific software repository, with the especially well-known JavaScript repository NPM having suffered regular PR disasters on account of it playing things loose and fast with package ownership. Quite recently an auto-transfer of ownership feature of NPM was quietly taken out back and erased after Andrew Sampson had a run-in with it painfully backfiring.

In short, who can tell when a package is truly ‘abandoned’, guarantee that a package is free from malware, and how does one begin to provide insurance against a package being pulled and half the internet collapsing along with it?

Continue reading “The Dark Side Of Package Repositories: Ownership Drama And Malware” →

What Does GitHub’s Npm Acquisition Mean For Developers?

March 26, 2020 by 33 Comments

Microsoft’s open-source shopping spree has claimed another victim: npm. [Nat Friedman], CEO of GitHub (owned by Microsoft), announced the move recently on the GitHub blog.

So what motivated the acquisition, and what changes are we likely to see as a result of it? There are some obvious upsides and integrations, but these will be accompanied by the usual dose of skepticism from the open-source community. The company history and working culture of npm has also had its moments in the news, which may well have contributed to the current situation. This post aims to explore some of the rationale behind the acquisition, and what it’s likely to mean for developers in the future.

Continue reading “What Does GitHub’s Npm Acquisition Mean For Developers?” →