Last Updated on 23 January 2024 by admin
Tech giants Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla, and Uber have recently fallen victim to a new supply chain exploit technique called dependency confusion after a researcher executed counterfeit code on their networks.
Table of Contents
What is dependency confusion?
Software is developed using a variety of packages collected to build applications. These packages are sourced in-house, purchased from third-party suppliers, and downloaded from public sources.
The common hybrid component configuration manages both private and publicly available packages which are automatically downloaded. When dependencies are installed, programming languages such as Python and Node will look to the internet to find these. If an attacker has registered a dependency that is the same name as a private package, the programming language would use the attacker’s package containing malicious code. This is called a dependency confusion attack – another supply chain vulnerability.
This inherent design flaw of open-source development tools ultimately allows this kind of attack to be used to adversely affect the application development process. Therefore, it is a cause of serious concern for many organizations.
Dependency confusion – a case that got everyone talking
Recently, cyber security researcher and Bug hunter Alex Birsan exploited the possibility that software might contain elements from both public and private sources.
Birsan successfully managed to breach over 35 internal systems after discovering numerous private module names and creating aliases on public repositories, such as NPM and RubyGem. To find out the precise actions Birsan took, check out his Medium article in which he provides detailed insights into his process.
Since his discovery, Birsan has been awarded over $130,000 in bug bounties for his efforts. However, following his haul, countless new bogus npm packages have appeared. So, it seems that these have been published by copycat researchers that likely have bad intentions.
How does a dependency confusion attack work?
A dependency confusion is when two or more software packages have the same name. For example, if the attacker registers the package “hello_world”, any language that depends on the “hello_world” package will also get the same file and therefore be exposed to the attacker’s malicious code.
The likelihood of this happening is low, but it can be very dangerous.
A dependency confusion attack could happen in one of two scenarios:
- When a third-party package (either on the open or closed source side) is used and the same name is used by an existing package. In this scenario, the open-source package name is the trigger for an attack.
- When a third-party package (either on the open or closed source side) is used and the same name is used by an untrusted source. In this scenario, the closed source package name is the trigger for an attack.
Who is vulnerable to an attack?
Dependency confusion is not necessarily a security threat for all organizations. The main concern is that this kind of attack could affect the development process of an organization and negatively affect the security posture of an organization and its private packages.
For example, if a company uses a third-party open-source dependency and the name of the package is the same as the package the company provides, then the company may be vulnerable to a dependency confusion attack.
This is a cause for concern because the development process is highly dependent on open-source packages, which could easily become compromised through a dependency confusion attack.
If you download code from a public open-package index website (such as npm and PyPI) in the process of developing apps, you could be at risk.
What are the most common attacks?
There has been a lot of research on dependency confusion attacks, most centred on the telecommunications industry. Below are some of the most common dependency confusion attacks:
- Fake software updates – Attackers can create fake software updates with a malicious package and send them to legitimate software companies. These fake updates claim to fix a legitimate software dependency but in actuality, they only cause a false positive. If the legitimate software company installs these updates, their software is tricked into recording the dependency as a fake to begin with. With this in mind, there is a good chance that the legitimate software company might be misled into believing that their software is fake.
- Fake dependency signatures – Attackers have also been found to create fake dependency signatures. This might seem like a minor attack, but it is often more dangerous than fake updates or updates that cause a false positive. This is because attackers can trick legitimate software companies into believing their signatures are legitimate. This creates a major problem because software companies can now potentially sign malicious code causing further exploitation and vulnerabilities.
- Fake dependencies in updates – The final attack that has been seen in the telecommunications industry is fake dependencies in updates. This is one of the most complex types of attacks employed by hackers. The objective of this kind of attack is to trick software into treating a legitimate dependency as fake. Because of this, the software is no longer able to function properly and becomes exposed to significant vulnerabilities.
How can I detect and prevent dependency confusion?
As a business owner, the most important thing you can do to protect your internal packages, and your entire company from dependency confusion, is to be vigilant.
Be on the lookout for any signs that hackers might be using dependency confusion attacks. One clear sign of this type of attack is strange user behavior that indicates employees are visiting websites that do not make sense for their work or are inappropriate.
To detect dependency confusion attacks, create an environment that fosters an open and honest relationship between employees and their supervisors. In this type of environment, leaders can quickly identify if employees may be breaking company rules.
Leaders should also be informed about any security issues that might exist in their organization so that they are able to address them with their teams. You may also consider using package managers. Last, but not least, you should maintain a policy that prohibits employees from browsing inappropriate websites while at work.
What does this mean for the future?
Microsoft has since released a whitepaper to warn companies of this new attack technique, and many have responded accordingly by remediating this vulnerability and attempting to prevent it. However, Birsan himself said, I still get the feeling that there is more to discover. 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 surfaces for dependency confusion bugs.
Since Birsan’s discovery, a novel supply chain attack has been detected – just days after he disclosed his technique.
Tech organizations must be vigilant. This new sort of vulnerability – now established – is one that every developer should be aware of, posing potentially detrimental repercussions.
