reader comments
10 with 7 posters participating
A new type of supply chain attack unveiled last month is targeting more and more companies, with new rounds this week taking aim at Microsoft, Amazon, Slack, Lyft, Zillow, and an unknown number of others. In weeks past, Apple, Microsoft, Tesla, and 32 other companies were targeted by a similar attack that allowed a security researcher to execute unauthorized code inside their networks.
The latest attack against Microsoft was also carried out as a proof-of-concept by a researcher. Attacks targeting Amazon, Slack, Lyft, and Zillow, by contrast, were malicious, but it’s not clear if they succeeded in executing the malware inside their networks. The npm and PyPi open source code repositories, meanwhile, have been flooded with more than 5,000 proof-of-concept packages, according to Sonatype, a firm that helps customers secure the applications they develop.
“Given the daily volume of suspicious npm packages being picked up by Sonatype’s automated malware detection systems, we only expect this trend to increase, with adversaries abusing dependency confusion to conduct even more sinister activities,” Sonatype researcher Ax Sharma wrote earlier this week.
A slick attack
The goal of these attacks is to execute unauthorized code inside a target’s internal software build system. The technique works by uploading malicious packages to public code repositories and giving them a name that’s identical to a package stored in the target developer’s internal repository.
Developers’ software management apps often favor external code libraries over internal ones, so they download and use the malicious package rather than the trusted one. Alex Birsan—the researcher who tricked Apple and the other 34 companies into running the proof-of-concept packages he uploaded to npm and PyPi—dubbed the new type of supply chain attack dependency confusion or namespace confusion because it relies of software dependencies with misleading names.
Software dependencies are code libraries that an application must incorporate for it to work. Normally, developers closely guard the names of dependencies inside their software build systems. But Birsan found that the names often leak when package.json files—which hold various metadata relevant to a development project—are embedded into public script files. Internal paths and public scripts that contain the require() programming call can also leak dependency names.
In the event the file with the same name isn’t available in a public repository, hackers can upload a malicious package and give it the same file name and a version number that’s higher than the authentic file stored internally. In many cases, developers either accidentally use the malicious library, or their build application automatically does so.
Rumble, said. “My guess is it affects a ton of folks.” He added that most at risk are organizations that use large numbers of internal packages and don’t take special steps to prevent public packages from replacing internal ones.
Raining confusion
In the weeks since Birsan published his findings, dependency confusion attacks have flourished. Already hit by a proof-of-concept attack that executed Birsan’s unauthorized package in its network, Microsoft recently fell to a second attack, which was done by researchers from firm Contrast Security.
Matt Austin, director of security research at Contrast, said he started by looking for dependencies used in Microsoft’s Teams desktop application. After finding a JavaScript package called “Optional Dependencies,” he seized on a way to get a Teams development machine to download and run a package he put on npm. The package used the same name as a module listed as an optional dependency.
Shortly after doing so, a script Austin put into the module started contacting him from several internal Microsoft IP addresses. Austin wrote:
Whether the responses I saw were automated or manual, the fact that I was able to generate this reaction poses significant risk. By taking advantage of the post-install script, I was able to execute code in whatever environment this was being installed on. If attackers were to execute code the way I did on a build server for a desktop application update that was about to be distributed, they could insert anything they wanted into that update, and that code would go out to every desktop using Teams—more than 115 million machines. Such an attack could have monumental repercussions, potentially affecting as many organizations as the massive attack on the SolarWinds software factory that was revealed in December.
He provided the following figure illustrating how a malicious attack might work under this theoretical scenario:
A Microsoft spokeswoman wrote: “As part of our larger efforts to mitigate package substitution attacks, we quickly identified the issue mentioned and addressed it, and at no point did it pose a serious security risk to our customers.” The spokeswoman added that the system that executed Austin’s code was part of the company’s security testing infrastructure. Microsoft has more about the risks and ways to mitigate them here.
Attacks turn malicious
Like the packages uploaded by Birsan and Austin, the thousands of files that flooded npm and PyPi have mostly contained benign scripts that send the researchers the IP address and other generic details of the computer that runs them.
“These activities would take place as soon as a dependency confusion attack succeeds and would need no action from the victim, given the nature of the dependency/namespace hijacking issue,” Sharma, the researcher at Sonatype, wrote.
Bash histories, which store commands and other input that administrators type into their computers, often contain plaintext passwords and other sensitive data. Files stored in the /etc/shadow path of Linux machines store the cryptographic hashes of passwords needed to access user accounts on the computer. (For hashes to be compromised, the npm app would have to be running in super user mode, an extremely elevated set of privileges that are almost never given to software management apps.)
Sonatype said it had no way of knowing whether the files were executed by any of the companies targeted by the scripts.
The targets respond
In a statement, Slack officials wrote:
The mimicked library in question is not part of Slack’s product, nor is it maintained or supported by Slack. We have no reason to believe the malicious software was executed in production. Our security team regularly scans the dependencies used in our product with internal and external tools to prevent attacks of this nature. Additionally, Slack’s secure development practices, such as using a private scope when using private dependencies, make it unlikely that a dependency-related attack would be successful against our product.
A Lyft statement read: “Lyft was not harmed in this attempt. There is no indication that this malicious software was executed on Lyft’s network. Lyft has a dedicated information security program to defend against such supply chain attacks and runs an active bug bounty program to continuously test its security controls.”
Zillow officials wrote:
We are aware of the recent security report involving a possible attack involving spoofed software packages. After an investigation by our security team, we found no evidence that our systems were compromised or exploited by the disclosed technique. Our team is also taking a number of actions to monitor and defend against any future possible attempts to gain unauthorized access to our systems.
Representatives from npm, meanwhile, wrote: “We’ve provided guidance on how to best protect against these types of substitution attacks in this blog post. We’re committed to keeping npm secure and continuing to improve the security of the ecosystem.”
Amazon representatives didn’t respond to an email seeking comment. A representative for PyPi didn’t immediately have a comment.
The recent hack against network tools provider Solar Winds—which compromised the Texas company’s software build system and used it to distribute malicious updates to 18,000 customers—was a stark reminder of the damage that can result from supply-side attacks. Dependency confusion attacks have the potential to inflict even more damage unless developers take precautionary measures.
