Supply-Chain Hack Breaches 35 Companies, Including PayPal, Microsoft, Apple

Ethical hacker Alex Birsan developed a way to inject malicious code into open-source developer tools to exploit dependencies in organizations internal applications.

An ethical hacker has demonstrated a novel supply-chain attack that breached the systems of more than 35 technology players, including Microsoft, Apple, PayPal, Shopify, Netflix, Tesla and Uber, by exploiting public, open-source developer tools.

The attack, devised by security researcher Alex Birsan, injects malicious code into common tools for installing dependencies in developer projects which typically use public repositories from sites like GitHub. The malicious code then uses these dependencies to propagate malware through a targeted company’s internal applications and systems.

Once he began to target companies with his attack, “the success rate was simply astonishing,” Birsan said in a post on Medium that elaborately details the attack.

All told, the vulnerability he exploited, which he called dependency confusion, was detected inside more than 35 organizations to date, across three tested programming languages—Python, Ruby and Java.

“The vast majority of the affected companies fall into the 1000+ employees category, which most likely reflects the higher prevalence of internal library usage within larger organizations,” Birsan noted.

The researcher received more than $130,000 in both bug bounties and pre-approved financial arrangements with targeted organizations, who all agreed to be tested. The hack’s original target PayPal, as well as Apple and Canada’s Shopify, each contributed $30,000 to that amount.

Birsan said he came up with an idea to explore the trust that developers put in a “simple command,” “pip install package_name,” which they commonly use with programming languages such as Python, Node, Ruby and others to install dependencies, or blocks of code shared between projects,.

These installers—such as Python Package Index for Python or npm and the npm registry for Node–are usually tied to public code repositories where anyone can freely upload code packages for others to use, Birsan noted.

However, using these packages comes with a level of trust that the code is authentic and not malicious, he observed.

“When downloading and using a package from any of these sources, you are essentially trusting its publisher to run code on your machine,” Birsan wrote. “So can this blind trust be exploited by malicious actors?”

Code-Inspired Idea

Birsan decided to answer this question last summer while attempting to hack PayPal with another ethical hacker, Justin Gardner, who shared with him “an interesting bit of Node.js source code found on GitHub,” Birsan said.

The code, which was meant for internal PayPal use, had in its package.json file a mix of public and private dependencies, including public packages from npm, as well as non-public package names, most likely hosted internally by PayPal, that did not exist on the public npm registry at the time.

“What happens if malicious code is uploaded to npm under these names?” Birsan wondered, according to the post. “Is it possible that some of PayPal’s internal projects will start defaulting to the new public packages instead of the private ones?”

The short answer is, “yes,” he discovered. Birsan applied his idea to upload his own “malicious” Node packages to the npm registry under all the unclaimed names, which would “phone home” from each computer they were installed on, he explained. The code would notify him if it was installed on any of the PayPal-owned servers.

He created a Node package that collects basic information about each machine it is installed on through its preinstall script. Then, to strike a balance between the ability to identify an organization based on the data, he logged the username, hostname and current path of each unique installation.

“Along with the external IPs, this was just enough data to help security teams identify possibly vulnerable systems based on my reports, while avoiding having my testing be mistaken for an actual attack,” he said.

DNS for Data Exfiltration

Once he orchestrated his way in, Birsan decided to use DNS exfiltration for sending data from organizations back to him, “knowing that most of the possible targets would be deep inside well-protected corporate networks,” he said. Birsan also surmised that it would make it less likely that the data would be blocked or detected on the way out, and

To do this, he hex-coded the data and used it as part of a DNS query, which reached his custom authoritative name server, either directly or through intermediate resolvers. He configured the server to log each received query, essentially keeping a record of every machine where the packages were downloaded, Birsan explained.

Once he had the basic attack method in place, Birsan explored how to cast as wide a net as possible in terms of targeted organizations, expanding the number of ecosystems he could attack. He ported the code to both Python and Ruby so he could upload similar packages to PyPI (Python Package Index) and RubyGems respectively.

More importantly, he combed private package names belonging to targeted companies to find as many relevant dependency names as possible. His search revealed that many other names could be found on GitHub, as well as on the major package hosting services–inside internal packages which had been accidentally published–and even within posts on various internet forums.

His efforts discovered that the best place to find private package names turned out to be javascript files. This is because it’s common for package.json files, which contain the names of a javascript project’s dependencies, to become embedded into public script files during their build process, exposing internal package names, Birsan said.

Similarly, leaked internal paths or require() calls within these files may also contain dependency names, scenarios he discovered at Apple, Yelp and Tesla, he added.

However, javascript’s susceptibility to the attack does not necessarily mean that Python and Ruby are less susceptibl, Birsan noted. In fact, though he only identified internal Ruby gem names belonging to eight organizations during his searches, four of those companies—including Shopify–turned out to be vulnerable to dependency confusion through RubyGems, he said.

Threatpost WEBINAR: Is your small- to medium-sized business an easy mark for attackers? Save your spot for 15 Cybersecurity Gaffes SMBs Make,” a  FREE Threatpost webinar on Feb. 24 at 2 p.m. ET. Cybercriminals count on you making these mistakes, but our experts will help you lock down your small- to mid-sized business like it was a Fortune 100. Register NOW for this LIVE webinar on Wed., Feb. 24.

Suggested articles

vmware

VMWare Patches Critical RCE Flaw in vCenter Server

The vulnerability, one of three patched by the company this week, could allow threat actors to breach the external perimeter of a data center or leverage backdoors already installed to take over a system.

Discussion

  • Sharon Hope on

    Wouldn’t consistent use of software ID (SWID) tags, ala NISTIR 8060, for all software modules, particularly in-house developed software packages, help defeat this hack?
  • Bhack00r on

    Surprising...."pip install"....a widely used command.....can be exploited ..a good eye opener for all developers who extensively use open source packages.
  • Anon on

    Edit: " ...projects which typically use public depositories from sites like GitHub " depositories are for banks and financial institutions. Did the author mean GitHub "repositories"?
  • carlyn Ross on

    So should I not go into Pay Pal or Shopify? Maybe I should just stay off line.
  • Disabled Lives Matter on

    I got a phone call from PayPal today, 2.13.21, telling me that they have been hacked & did I want my account closed. I had received over 6 emails with PayPal stating they're charging me $799 for this, $499 for that, $699 for this, $399 for that, etc. I told them I never MADE an account. I'm looking for the real story, not an ethical hacker's attempts. Where is the PSA warning the public that it has already happened? All PayPal accounts need to be closed. Thanks.
  • C on

    Those are scam calls, they have nothing to do with PayPal. PayPal won't call you because they were hacked or to confirm or cancel orders.

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.