Hello everyone and welcome back to the Cognixia podcast. Every week, we dig up a new topic from the world of emerging digital technologies and share insights, ideas, information, stories, and more. We strive to inspire our listeners to learn new things and update their repertoire of skills to stay relevant and continue growing in their careers.
In today’s episode, we talk about something that is gaining the spotlight for the wrong reasons and has entities and people around the world. While cybersecurity is becoming an increasingly indispensable and all-important discipline, cyber threats evolve at a pace faster than our cybersecurity defense and prevention mechanisms can keep up most of the time. One such attack that is becoming commonplace is the Dependency Confusion Attack.
If you are a developer or work with developer teams, chances are you would have already heard about the dependency confusion attacks. If not, fret not, we are going to tell you right now, so keep listening. So, to understand what dependency confusion attacks let us first understand what dependencies in this context are.
When developing applications, one often needs to integrate third-party or open-source dependencies into the applications to meet the intended business requirement or utility. For instance, a food delivery app could be dependent on Google Maps or MapMyIndia for the Map functionality on which a user can track their food. An e-commerce app or website could have a dependency on WhatsApp for enabling a live chat with a customer service bot or a customer service rep to help answer any queries that the customer of the platform may have. These dependencies could be paid for by the using entity to the service/API provider or it could be open-source and play an important role in supporting the efficient functioning as well as any other features that the application might be providing. The simple logic here was instead of building a whole functionality from scratch, which by no means is an easy feat since it takes looking for and hiring the right people with the right skills and domain knowledge, and a boatload of resources to put together a team, lots of time, and so much more. Instead, one could use the API or functionality built by someone else, something that is already tested and ready to use with established success, just integrate it into whatever you are building, and voila! The functionality creator could get a licensing fee or a royalty payment of sorts, and the user entity has a perfectly functioning feature that would be highly valuable for its users.
Sounds like a great thing, right? It totally is. Then where exactly is the problem?
Well, whenever great innovations have taken place, haven’t the unscrupulous elements always caught up with them sooner or later for their gains while penalizing or harming others in some way?
Dependencies are no exception. Enters Dependency Confusion Attack.
Dependency confusion attacks are relatively new to the world, but in the short time they have been around, they have sent ripples around the world showing the unimaginable levels of harm they can cause. So, who is at risk? How do these attacks function? Can we do something to stop it or fight it once it happens? We are sure you have many questions, and we will try our best to answer as many of these as possible in this podcast episode.
New research by OX Security, a DevOps software supply chain company has revealed that just about every application that has more than 1 billion users and more than 50% of applications with roughly 30 million users are highly vulnerable to dependency confusion attacks. The research also makes a shocking revelation – organizations that are at the most risk would likely have about a whopping 73% of their assets exposed to dependency confusion attacks!
Earlier this year, another security firm – Orca Security also reported similar findings from its research.
If some of you find the name “Dependency Confusion” slightly familiar but are unable to recall where exactly you have heard it, allow us to refresh your memory. You would have heard of PyTorch Malicious Dependency Package that was reported by PyTorch last year. At that time, PyTorch had warned its users that there was a possible compromise of their Python Package Index code repository. In this incident, the cybercriminals carrying out the attack had installed a malicious dependency on their PyPI code repository and then ran a malicious binary to enable them to launch a destructive supply chain attack.
Another dependency confusion attack you might have heard of also occurred in 2022 when the criminals injected malicious code into the very popular open-source package node-ipc. During the duration of the attack activity, millions of files were wiped out from the computers that were in Russia and Belarus.
This brings us to a very important question we are sure a lot of you have.
What exactly happens during a dependency confusion attack?
In a dependency confusion attack, the criminal would upload a software package with the same name as an authentic one in a private repository. Now, there are two software packages with the same name, one in the private repository while the other is in the public repository. This can sometimes trick the development team into using the wrong package, after all, there are two files with the same name so you can see how easy it is for someone to use the wrong one in such a scenario. When developers working on building the application use the wrong software package or when the package managers search the public repositories for dependency packages, the otherwise legitimate app could go about installing the malicious code which the hacker criminal can now exploit for launching an attack on the software. They could steal the data, they could jam the traffic, they could change the functionality, and so much worse.
So, in a way, dependency confusion is a supply chain issue. Interestingly, the topic of dependency confusion first caught the world’s attention when a security researcher – Alex Birsan, shared in a post on Medium that he had managed to breach more than 35 companies, including Apple, Microsoft, Yelp, and PayPal, using some dependency confusion techniques. Sounds quite scary, doesn’t it?
The dependency confusion attack hinges on one key thing – identifying a package name in the private repository and then registering the same package name in the public repository. Once this happens, whenever a new update is rolled out, the application will hook to the malicious version present on the public repository instead of the safer, secure one present in the private repository. This is possible because undeniably, most application package managers like npm, pip, RubyGems, etc. would check for dependencies in the public repository before it reaches out to the private repository for the code. Owing to this, when a malicious package is registered in the public repository with the same name as the useful secure one in the private repository, the malicious one on the public repository would be hooked in first.
So, why are so many organizations at risk of these dependency confusion attacks? This is because most of these organizations would be using vulnerable packages or free-to-register public repositories. A dependency confusion attack would not just hurt the integrity and security of an organization’s assets but also have a far-reaching impact on the organization’s employees as well as users no matter where in the world they are located.
Now that we know what dependency confusion attacks are and how they take place, we would also like to give you some quick tips on a few things you do to begin to prevent such an attack on your organization’s assets. First and foremost, reserve private package names in the public registry. That way, nobody would be able to register the same in the public registry again, and you can prevent a dependency confusion attack at the source. Another important measure to take is to minimize human errors in the process which could expose the software and the organization to potential attacks. For instance, some of the most common human errors are the lack of sufficient code review, misconfigured build systems, insufficient best practices, as well as unvalidated external dependencies.
Yet another effective way is to validate the package source before installing any new package on the software or rolling out a new update. Use package managers that allow you to view the package before you go full-blast into installing it. You can also use package managers that permit the use of prefixes, IDs, or namespaces, as some sort of unique identifier for the package names. This way, if a criminal tries to hack in and install a malicious package, the name would still stand out and the developer will have the opportunity to prevent the attack as well as take corrective measures. This way, developers can also ensure that internal dependencies are fetched from the specific private repositories.
This must be a lot to absorb and we understand that cyberattacks can be a scary affair for anyone. Our aim with this episode is to create some awareness and help you take the right measures to do your best to prevent cyberattacks like dependency confusion attacks. We hope we have been able to inspire you to dig deeper into the varied facets of cybersecurity and weave it into your daily functioning instead of drawing focus on it only after you are amid a deadly cyberattack and are already a victim.
With that, we come to the end of this week’s episode of the Cognixia podcast. We hope you found it interesting and insightful. We would highly recommend checking out our range of live online instructor-led training and certification courses on our website – www.cognixia.com. You can get in touch with us directly over the chat function there and we will answer all your questions.
We will be back next week with another exciting episode of the Cognixia podcast. Until then, pull up your socks and get learning!
See you next week, happy learning!
