Update: the following blog post has been updated to reflect the disclosure by a German firm that the artifacts discovered by ReversingLabs and other firms were part of a "red team" assessment of leading German firms. - May 11, 2022:
Research by ReversingLabs suggests that npm dependency confusion attacks are more widespread than previously reported, and may be playing a role in targeted attacks against media, logistics and industrial firms in Germany.
New npm packages discovered last week by ReversingLabs appear to target a major German media conglomerate as well as a major rail and logistics operator. The packages are similar to those discovered by researchers at the firm Snyk and disclosed in late April.
"In the Snyk case, the target of the attack wasn't known, as they noted,” said Karlo Zanki, a reverse engineer at ReversingLabs. “The packages we found are obviously targeting these German firms or some of their clients using npm packages.”
Initially believed to be evidence of a malicious attack, the packages now appear to be part of a so-called "red team" assessment of the firms, according to a statement Tuesday by Code White GmbH, a penetration testing and security research firm.
Flaws enable dependency confusion
Security experts have been raising alarms about so-called “dependency confusion” attacks on applications that use the public npm Javascript registry for months. The attacks exploit misconfigurations in private npm repositories to upload malicious npm modules in the place of legitimate, non-public code.
For the most part, dependency confusion attacks have been limited to proofs-of-concept. In 2021, for example, the researcher Alex Birsan showed how dependency confusion attacks could be used to plant malicious code inside applications operated by some of the world’s most prominent firms including Apple, PayPal, Tesla, Netflix, Uber, Shopify and Yelp!.
Birsan and his colleagues researched public Internet developer forums as well as repositories like GitHub, npm and others to uncover private (internal) software package names belonging to prominent firms. In many cases, the names of non-public modules were inadvertently exposed inside packages published to public repositories as internal paths or "require()" calls.
That was especially true for Javascript files, Birsan discovered. Internal package.json files often have the name of the javascript project’s dependencies embedded into public script files during the build process, exposing internal package names for all to see, he wrote.
By setting up public repositories with identical names to the private packages, attackers could leverage simple typosquatting to sow confusion about what was public- and private code.
But leaking internal package names and typosquatting aren’t enough to make dependency confusion attacks work. They also rely on misconfigurations or exploitable business logic flaws in platforms like Github, npm and JFrog. For example, Birsan and his team discovered that the Python command line argument "--extra-index-url" in conjunction with the pip install library will check both public and private repositories for the package designated, then install the package with the highest version number—no matter whether it is sourced from the public or private repository. Flaws in Github and other platforms yielded similar results, allowing would-be attackers to push malicious code to targeted organizations in the guise of a legitimate software module.
Dependency confusion attacks get real
In April, however, dependency attacks moved from hypothetical to actual, after researchers working for the security firm Snyk discovered a dependency confusion attack in the wild that targeted an as-yet-unknown firm.
Snyk researchers discovered three, public npm packages: one named gxm-reference-web-auth-server—a name apparently chosen to impersonate a private npm package used by an unknown firm. Snyk identified two other, dependent npm packages, with gibberish names: ldtzstxwzpntxqn and lznfjbhurpjsqmr.
The Snyk researchers were able to de-obfuscate and analyze the packages and determine that, when executed in the target environment, they would open a back door to attackers, allowing them to execute a reverse shell and obtain complete control over the infected machine, communicate with command and control servers, and so on. However, Snyk was not able to identify the firm that was the intended target of the attacks.
Targeted npm attacks take aim at German firms
ReversingLabs used the information uncovered by Snyk to conduct our own research. In the process, the research team discovered more malicious packages related to the attack that are not mentioned in the Snyk report.
For example, ReversingLabs noticed differences between the third package (lznfjbhurpjsqmr) documented by Synk and a package used to target the rail and logistics firm. Specifically: the package ReversingLabs analyzed invoked an encrypted Stage 2 agent that was larger than the agent associated with the Snyk files. It also used a different C2 (command and control) server and encryption keys.
Otherwise, the Snyk npm modules and the versions discovered by ReversingLabs are nearly identical. They employ the same obfuscation and encryption techniques as well as identical malware architecture and package contents. They also have similar functionality, common to malware, like "download", "upload", "exec", "eval", "delete", and "register".
Both sets of malicious modules also used elevated version numbers to force the malicious packages onto target environments. For example, the targeted private packages for the transportation and logistics firm had versions 0.5.69 and 4.0.48, while the malicious, public versions were identically named, but used versions 0.5.70 and 4.0.49.
Npm maintainer accounts and associated email addresses for developers—most set up at protonmail.com—also implied affiliation with the targeted firms. (ReversingLabs is withholding the names of the targeted firms for security reasons.)
References to the German firms are consistent with a detail of Snyk’s analysis. That company noted that the malicious modules ldtzstxwzpntxqn and lznfjbhurpjsqmr were published by an npm maintainer using the name “Boschnodemodules" - another apparent reference to a prominent German company.
Unclear origins, unclear impact
Many of the malicious packages we identified were removed from npm before we could obtain copies. (Some were removed by the “user” who published them. Others appear to have been removed by the npm security team.) However, packages used in the attack on the transportation and logistics firm were still active as of late last week, allowing ReversingLabs to download and analyze them. ReversingLabs has reported these modules to the affected firms and npm.
Efforts to track down the original developer of the malware yielded few clues, as the npm user accounts associated with the malware were clearly straw-man accounts. Still, the actors responsible for the attack took few steps to conceal their activities. The maintainer accounts provide a glimpse at the development of the attack packages over a period of weeks. For example, a collaborator using the handle asdfafe5 published packages that revealed efforts to implement the obfuscation techniques used in the final malware. Those packages had publication dates in early March, more than a month before the packages Snyk identified. Like the malicious packages served to the German firms, asdfafe5’s packages also used the version numbers 0.5.70 and 4.0.49.
On Tuesday, however, the firm Code White, based in the southern German city of Ulm, acknowledged responsibility for the files and credited security researchers for uncovering their work. The dependency confusion attacks were engineered by an intern at the company who was tasked with "research(ing) dependency confusion as part of our continuous attack simulations for clients."
Code White said it was "trying to mimic realistic threat actors for dedicated clients as part of our Security Intelligence Service and ...brought our 'own' package manager that supports yarn and npm."
Dependency confusion grows
It is still not clear whether the attacks launched on these firms via npm were successful and gave attackers access to the target environments. What is clear is that npm dependency confusion attacks have quickly morphed from a proof-of-concept to the wild and are being used to further targeted attacks against prominent firms. That discovery, alone, is the reason that firms involved in software development need to assess their vulnerabilities to dependency confusion and start taking steps to remediate the risks.
We’ll have more on this in the days and weeks ahead, starting with our May 11 ConversingLabs podcast, where reverse engineer Karlo Zanki will join me to talk about his research and what he learned about these npm dependency confusion attacks.
