https://open.spotify.com/show/3Gmj15x6cGrgJEzmGnDTTj

Copycats Imitate Novel Supply Chain Attack That Hit Tech Giants

This week, over 150 new packages have been published to the npm open-source repository named after private components being internally used by major companies.

These npm packages are identical to the proof-of-concept packages created by Alex Birsan, the researcher who had recently managed to infiltrate over major 35 tech firms and walk away with over six-figures in bug bounty rewards.

Within 48 hours of Birsan’s disclosure going public, copycat actors began pushing similar packages to npm, likely in a quest to earn bug bounties.

Birsan has confirmed to BleepingComputer that he is not behind these imitation packages and that these are different actors following in his footsteps.

Also Read: Going Beyond DPO Meaning: Ever Heard Of Outsourced DPO?

Researcher breaches 35 tech firms in a novel supply chain attack

Recently, BleepingComputer had first reported on a supply chain attack that hit over 35 tech firms, namely Microsoft, Apple, PayPal, Tesla, Uber, Yelp, Shopify, among others.

The researcher, Alex Birsan, had taken advantage of an inherent design flaw of open-source development tools called “dependency confusion” or “namespace confusion” to squat names of private dependencies used by major companies on public open-source repos including npm, PyPI, and RubyGems.

Today, a report from Sonatype reveals, other copycat actors are now imitating Birsan’s research by flooding the npm repository with copycat packages marked “for security research purposes only.”

Copycat actors flood npm with identical packages

Within the last 48 hours, the Sonatype Security Research team, of which I am a part, noticed a sudden spike in the volume of suspicious packages caught by our automated malware detection systems and began analyzing these packages.

And then it made sense. The vast majority of 150+ components that were flagged and are continuing to come in at the time of writing, are lookalikes of Birsan’s PoC packages that let him breach over 35-tech companies as a part of his ethical research.

But Birsan tells BleepingComputer he is not behind these copycat “research” packages, although he did admit to uploading a few more packages today under his real npm account.

“I’ve uploaded a few more packages today.”

“My tests will always only collect the same non-sensitive data and will be uploaded from my own account with my contact information in the code itself.”

“It is, however, only natural to expect other bug hunters, or even malicious actors, to start uploading packages too now, and I have no control over what they do,” Birsan told BleepingComputer in a statement.

The researcher suspects that people are chasing bounties and therefore following in his footsteps.

Also Read: Limiting Location Data Exposure: 8 Best Practices

One such example would be the “shopify-cloud” npm package, named after the RubyGem by the same name that Birsan had used to execute his PoC code from Shopify’s systems via dependency confusion.

Although, the npm package is named “shopify-cloud,” it is unlikely to have any affect on Shopify’s build system which used the RubyGem (not npm) package by that name, unless they are also using a private npm dependency called “shopify-cloud.”

Other copycat packages are named, “apple-cloud,” “aol-slideshow,” and of course, “dependency-confusion-poc2,” the last one being overly honest. 

The code for “aol-slideshow” makes a DNS call to the author’s server and transmits basic information such as IP address, computer’s username, and the current directory, making a “callback” that would notify the package publisher of a successful attack.

Prior to attempting exfiltration, the code first attempts to connect to the author-controlled DNS servers, in this example, *.v1.ldd.pw 

Should the connection fail or take too long to establish, the code quietly sets DNS servers to Google’s (8.8.8.8 and 8.8.4.4) so as not to raise any suspicions arising from timeouts.

In another PoC package called “spectrum-css-temp,” seen by BleepingComputer, the author appears to have squatted a slight variation in the name of the Adobe’s Spectrum CSS package.

Yet, the squatter forgot to remove Birsan’s original contact information from the code comments, as seen by BleepingComputer.

But, it can’t be authoritatively verified if the names of these packages would indeed conflict with any private dependencies names used by Apple, AOL, and other companies, or if these private dependencies even exist in any corporate systems.

In our research, Sonatype also discovered npm packages that display a warning message to the developer building the internal project that they should be using the “private registry” for this particular npm.

It is not known if this file was created by the company purposely typosquatting the npm or a whitehat trying to warn the developers.

Regardless, the npm registry being bombarded with these copycat packages spotted by Sonatype is a telling sign that dependency confusion is a problem with no easy solution unless open-source repositories strengthen validations around who can publish to these repositories.

More importantly, onus is on the repositories to prevent threat actors from illicitly squatting names of private component/namespaces that are actively being used by legitimate brands.

In recent times, npm has been repeatedly hit with malicious typosquatting packages.

Earlier this month, npm took down three malicious packages, jquerry, and http-proxy-middelware that were misspelled versions of popular legitimate packages, and a third one named after me.

The dependency confusion problem with no easy solution now opens up the possibility of even more sophisticated attacks by threat actors.

Birsan believes these attacks are here to stay and that there remains more to discover.

The possibility remains for such attacks to resurface and grow, especially on open-source platforms with no easy solution for dependency confusion.

“Specifically, I believe that finding new and clever ways to leak internal package names will expose even more vulnerable systems, and looking into alternate programming languages and repositories to target will reveal some additional attack surface for dependency confusion bugs,” the researcher had earlier concluded in his blog post.

At the very least, companies should consider squatting their own private dependency names on public repos, including their typosquatted (misspelled) versions.

Also, the configuration of your development tools should be evaluated to ensure both private and public dependencies are not being inadvertently pulled from the public repository by default.