Call us on 03450 21 21 51
Call us on 03450 21 21 51
Share this article
As a remote management software provider to thousands of IT support firms, the recent ransomware attack suffered by Kaseya continues to make waves. The devastating supply chain attack is estimated to have delivered ransomware to a million computers used by Kaseya customers. As a result, the attack managed to take down Co-Op stores in Sweden alongside more than 200 other companies.
Needless to say, the cost of the attack has been colossal, both in terms of financial losses and reputational damage. It’s a clear example of just how serious a supply chain attack can be, and how important effective protection is.
But no two supply chain attacks are the same. We’re going to take a closer look at some of the most common supply chain vulnerabilities and how they are exploited, as well as assessing what you can do to protect your organisation and those in your chain.
Most software supply chain attacks consist of an upstream server or code repository being injected with malicious payload. This payload is then distributed downstream, impacting as many users as possible.
However, it is important to recognise that attacks don’t only flow “downstream”, as was demonstrated by the infamous Codecov supply chain attack. In this instance, no malicious code was distributed downstream, but the after-effects of the attack were. The attackers obtained credentials that could be used to modify the Codecov Bash Uploader, as per the official security advisory. The attackers could then modify the Uploader hosted on the Codecov server to collect any environment variables being uploaded from customers’ continuous integration and delivery environments.
In this way, information was sent upstream from the user environment. These downstream repositories were affected as they were configured to upload their data to the Codecov’s Bash Uploader. As a result, hundreds of customer networks were breached.
The somewhat simplistic nature of dependency confusion is what makes it such a threat to businesses, due to its wide usage. These attacks work with minimal effort necessary from cybercriminals, exposing and making use of an inherent design weakness found in multiple open-source ecosystems.
Dependency confusion works on software that is built using a private, internally created dependency that does not exist on a public open-source repository. Attackers are able to register a dependency with the same name on a public repository with a higher version number. As such, the attacker’s public dependency will be pulled into your software build, as opposed to your internal dependency.
Famously, ethical hacker Alex Birsan displayed the effectiveness of this, exploiting commonly used ecosystems like npm, RubyGems and PyPI to hack into 35 big tech firms and walk away with more than $130,000.
Thankfully, there are multiple ways to resolve dependency confusion. The simplest of these is to register the names of all your private dependency on public repositories before an attacker can. There are also automated solutions, like a software development lifecycle (SDLC) firewall that stops conflicting dependency names from entering your supply chain. A good example of this comes from Java component repository Maven Central, which employs a simple, domain-based verification to verify namespace ownership. This practice can be easily remodelled by other ecosystems.
SSL certificates are now an integral part of any and all online communications, thanks to the rise in HTTPS websites. As such, if SSL certificates become compromised, it could threaten the secure communication and assurance offered by an encrypted connection to their end users.
This was the case earlier this year, when Mimecast revealed that a certificate used by its customers to establish connections to Microsoft 365 Exchange had been compromised. This impacted the communications of as many as 10% of Mimecast users, and researched suspected that it was an SSL certificate.
But a stolen code-signing certificate can be even more problematic than a compromised SSL certificate. Attackers who gain access to a private code-singing key can potentially sign their malware as an authentic software program or update. Incidents like those which impacted Stuxnet and HashiCorp show the dangers presented when a private key is exposed to hackers.
Human exploitation remains the weakest link in cybersecurity, which means exploitation can come from anywhere. When the Linux Foundation recently banned University of Minnesota researchers who were suggesting intentionally buggy patches to introduce vulnerabilities into the company’s source code, it demonstrated several things. Namely, that developers are spread thin and cannot vet every single proposed code change, and that social engineering can come from the places you’d least expect.
In this instance, the source was a group of seemingly credible university researchers with an ‘.edu’ email address.
The open collaboration of a GitHub project provides another example of this in action – demonstrating how one collaborator going rogue can put the security of the entire supply chain in jeopardy. Attackers have been creating typosquatting and brandjacking software packages to target open-source developers, introducing malicious code in their upstream builds.
What’s clear from these examples is that supply chain attacks are constantly changing and evolving. There are a plethora of different weaknesses, attack vectors and techniques that hackers can use to successfully pull off a wide range of far-reaching breaches. So as these attacks continue to evolve, so too must the solutions we impose.
Staying up to date with innovative supply chain solutions and strategies is key when it comes to protecting the security of everyone involved in your business process. Preventative measures offer a proactive approach to supply chain management that focusses on protection rather than damage control, giving you peace of mind as you conduct your day to day activities.
