Npm Security Woes Continue Amidst a Series of CDN Attacks
Seriously! It seems like every time I blink, the popular JavaScript package manager, Node Package Manager (npm), has had a new security violation revealed. Last year, WhiteSource, a leading open source security provider, declared a playground for malicious actors. They were right.
For example, Darcy Clarke, a former staff engineering manager for the npm CLI team, recently revealed a fundamental problem, dubbed “manifest confusion.” Clarke explained, “This massive bug at the heart of the npm ecosystem” arises from the lack of consistency between an archived package’s manifest files and its included JSON metadata file. Making things even worse, the manifests are never fully validated against the tarball’s contents.
I bet you assumed they were consistent. Well, you’re in good company. Everyone did. At one time, we could trust each other. Those days are long gone.
This npm package’s manifest/tarball discrepancy enables attackers to hide malicious dependencies and scripts inside packages, potentially leading to cache poisoning, installation of unknown dependencies, execution of unknown scripts, and potential downgrade attacks. Pretty much, you name it. It can happen.
Is that fun or what?
But, wait! There’s more.
In another incident, Check Point found a malicious npm package — imagine that! — which applied a phishing attack to gain user credentials. The package relied on a file from an already detected and removed malicious package. So how could it work? Easy.
The nasty code was still available through a popular npm Content Delivery Network (CDN) service – “jsDelivr.” A CDN, by the way, is a third-party server network that hosts code your front-end code accesses when the page loads.
How bad is this kind of attack? Very. Check Point found one malicious file, which had been removed over a year ago but could still be accessed via the jsDelivr CDN.
So, as Check Point warned, “It’s important to emphasize that the CDN hack was more disturbing than the malicious package, enabling threat actors to re-use their malicious code, share best practices, and evade common security monitoring tools used by 3rd party components.” It’s not enough to verify the code you’re using is safe, you need to double-check that any CDN code you use is actually safe as well.
Finally, and most recently, ReversingLabs security researchers have uncovered evidence of yet more malicious npm packages. These appear to have links to the same North Korean attackers that targeted cryptocurrency providers in the JumpCloud cryptocurrency supply chain attack.
The good news is these packages were removed from npm soon after being posted. The bad news is the threat actor may have removed them. Why? Because they didn’t want to get J. Random Javascript programmers, but a specific target. Once it had been delivered, in an effort to reduce the likelihood of detection, it was time to disappear.
Get the picture? Npm, and related supporting sites such as jsDelivr are under constant attack. The sooner npm adopts Sigstore to secure its code supply chain, the better. As it is, if you use npm — and we know you do — you must have rigorous validation and security checks in your pipeline to prevent malicious code from burying itself in your programs.
