A backdoor that researchers found hiding inside open source code targeting four German companies was the work of a professional penetration tester. The tester was checking clients’ resilience against a new class of attacks that exploits public repositories used by millions of software projects worldwide. But it could have been bad. Very bad.

Dependency confusion is a new form of supply-chain attack that came to the forefront in March 2021, when a researcher demonstrated he could use it to execute unauthorized code of his choice on networks belonging to Apple, Microsoft, and 33 other companies. The researcher, Alex Birsan, received $130,000 in bug bounties and credit for developing the new attack form.

A few weeks later, a different researcher uncovered evidence that showed that Amazon, Slack, Lyft, Zillow, and other companies had been targeted in attacks that used the same technique. The release of more than 200 malicious packages into the wild indicated the attack Birsan devised appealed to real-world threat actors.

This isn’t the dependency you’re looking for

Dependency confusion exploits companies’ reliance on open source code available from repositories such as NPM, PyPI, or RubyGems. In some cases, the company software will automatically connect to these sources to retrieve the code libraries required for the application to function. Other times, developers store these so-called dependencies internally. As the name suggests, dependency confusion works by tricking a target into downloading the library from the wrong place—a public source rather than an internal one.

To pull this off, hackers scour JavaScript code, accidentally published internal packages, and other sources to discover the names of internally stored code dependencies by the targeted organization. The hackers then create a malicious dependency and host it on one of the public repositories. By giving the malicious package the same name as the internal one and using a higher version number, some targets will automatically download it and update the software. With that, the hackers have succeeded in infecting the software supply chain the targets rely on and getting the target or its users to run malicious code.

Over the past few weeks, researchers from two security firms have tracked code dependencies that used maintainer and package names that closely resembled those that might be used by four German companies in the media, logistics, and industrial sectors. The package names and corresponding maintainer names were:

• bertelsmannnpm; bertelsmannnpm@protonmail.com
• boschnodemodules; boschnodemodules@protonmail.com
• stihlnodemodules; stihlnodemodules@protonmail.com
• dbschenkernpm; dbschenkernpm@protonmail.com

Based on those names, the researchers deduced that the packages were designed to target Bertelsmann, Bosch, Stihl, and DB Schenk.

Inside each package was obfuscated code that obtained the target’s username, hostname, and the file contents of specific directories and exfiltrated them through HTTPS and DNS connections. The malicious package would then install a backdoor that reported to an attacker-operated command and control server to fetch instructions, including:

• Download a file from the C2 server
• Upload a file to the C2 server
• Evaluate arbitrary Javascript code
• Execute a local binary
• Delete and terminate the process
• Register the backdoor on the C2 server

Researchers from JFrog and ReversingLabs—the two security firms that independently discovered the malicious packages—quickly found they were part of the same family as malicious packages that security firm Snyk found last month. While Snyk was the first to spot the files, it didn’t have enough information to identify the intended target.

Plot twist

On Wednesday, just hours before both JFrog and ReversingLabs posted blogs here and here, a penetration testing boutique named Code White took credit for the packages.

“Tnx for your excellent analysis,” the firm said in a tweet that addressed Snyk and cited its blog post from last month. “And don’t worry, the ‘malicious actor’ is one of our interns 😎 who was tasked to research dependency confusion as part of our continuous attack simulations for clients. To clarify your questions: we’re trying to mimic realistic threat actors for dedicated clients as part of our Security Intelligence Service and we brought our ‘own’ package manager that supports yarn and npm.”

In a direct message, Code White CEO David Elze said the company intern created and posted the packages as part of a legitimate penetration-testing exercise explicitly authorized by the companies affected.

“We do not disclose the names of our clients but specifically, I can confirm that we’re legally contracted by the affected companies and were acting on their behalf to simulate these realistic attack scenarios,” Elze said.

Code White’s involvement means that the dependency confusion attacks discovered by Snyk and later observed by JFrog and ReversingLabs weren’t a sign that real-world exploits of this vector are ramping up. Still, it would be a mistake to think that this attack class is never used in the wild and won’t be again.

In March, security firm Sonatype uncovered malicious packages posted on npm that targeted Amazon, Slack, Lyft, and Zillow. These packages contained no disclaimers indicating that they were part of a bug bounty program or a benign proof-of-concept exercise. What’s more, the packages were programmed to exfiltrate sensitive user information, including bash history and the contents of /etc/shadow, the directory where Linux user password data is stored. In some cases, the packages also opened a reverse shell.

JFrog has also spotted malicious attacks in the wild, including the previously mentioned presence of more than 200 packages on npm for various Azure projects that stole personal information from developers’ computers.

That means that even though this latest discovery was a false alarm, malicious dependency confusion attacks do occur in the wild. Given the dire consequences that could arise from a successful one, organizations should invest time testing their systems or use the services of companies like Snyk, JFrog, ReversingLabs, or Sonatype, all of which monitor open source ecosystems for vulnerabilities and exploits.

https://arstechnica.com/?p=1853739