How we protected ourselves from the Dependency Confusion attack

Apple, Microsoft, Tesla and many others paid $130 000 to a single hacker for a supply chain attack called Dependency Confusion. Here is how we have mitigated this attack vector for our packages hosted in our internal Artifactory instance.

Written by: Alexander Kjäll, Security Engineer at Schibsted Stian Kristoffersen, Security Engineer at Schibsted Ståle Pettersen, Head of Product and Application Security at Schibsted

There has been an increased focus on supply chain security lately, from the Solarwinds breach and Chrome extensions becoming malicious , to Google announcing the Open Source Security Foundation (OpenSSF) . Supply chain security is a complex problem with many aspects to take into consideration as pointed out by Eric Rescorla’s recently published article “ Notes on Addressing Supply Chain Vulnerabilities “. On Feb 9th, Alex Birsan published an article on how he managed to hack companies like Apple, Microsoft, Tesla, Uber , and many others, through publishing packages in public package repositories with the same name as internal packages inside these companies. The developers and package systems got “confused”, which made them pull in the public packages instead of the internal ones, so he coined the term “Dependency Confusion”. There are already threat actors exploiting this according to Sonatype .

Package managers like npm, NuGet, PIP, Maven, Gradle, Cocoapods, Gems and Composer can all end up in an insecure configuration where they are vulnerable to “dependency confusion”. Packages typically have full access to the system they are installed on, except Deno’s permission model and Java’s Security Manager, making the impact severe. In addition, in many companies it is common practise to have a package repository manager (like Nexus or Artifactory ) as an extra layer between the developer machine and local/remote repositories, adding an extra layer of confusion to the problem.

Leave a Comment