If a direct attack on a particular network isn’t viable, then what’s the hacker’s next move? In many instances, it’s a case of going upstream: i.e. identifying an application trusted by the target – and using that software as a backdoor means of malware delivery.
In the security world, these scenarios are referred to as software supply chain attacks. Recent findings from Crowdstrike suggest that at least two thirds of organisations have been hit via their software supply chains, so it seems that this type of activity is on the rise.
Here’s a closer look at how threat actors use supply chains for infiltration – and at the practical steps you can take to reduce the risk of a successful attack…
Why do hackers target software supply chains?
It’s easier than the alternatives. On the whole, larger businesses and organisations that hold valuable data (i.e. the type of target that hackers are most interest in) are ramping up their security technology. This increases the ability of organisations to pick up on vulnerabilities in their systems; even those vulnerabilities that have not been seen before. So instead of taking a direct route, you use a software supply chain as an alternative way in.
Here’s how it works…
- You identify a software application that’s popular in the sector you want to target (or that you know is used by the particular user you want to attack).
- Malicious code is embedded into the software maker’s output (e.g. new versions of their popular applications – or routine security updates).
- The malware-infected release is then downloaded by the end-target user.
How do hackers do it?
Infection of third party code. It’s rare for software applications to be built entirely from scratch. Usually, they are put together using a combination of custom code, together with large chunks of script from software libraries. According to Forbes, code from third-party software libraries typically accounts for 79% of the codebase for an application.
Most libraries are in the public domain; authored and added to by a global army of volunteers and subject to only minimal security checks. Doctor this code and it can have a knock-on effect on every application that uses it. As an example, Check Point discovered 50 malware-infected apps on Google Play that had all been infiltrated by the same portion of third-party code that had been used by various app developers.
Compromise the developer’s system before the new software is released. This is how the CCLeaner malware infection occurred, whereby a Windows optimisation tool was compromised, affecting more than 2 million users. With a successful spear-phishing attempt on an employee of the software house, it becomes possible to move across the network, ultimately gaining access to the location of the source code.
Target the distribution server. If you can compromise the internet server platform used to roll out updates to users, there’s the possibility of swapping legitimate files with infected ones.
Prevalence: How common are software supply chain attacks?
Crowdstrike recently surveyed 1,300 IT heads across the globe on this. They found the following:
- Two thirds had suffered a software supply chain attack. Of these, 90% had suffered financial loss as a result.
- Attacks occur across all sectors (although biotech, pharma, entertainment & media and IT services appear to be hit more frequently.
- Only a third of respondents say they vet their software suppliers for supply chain security.
Reducing the risk
Vet the security credentials of your suppliers. Rather than relying on empty assurances, look for evidence of concrete steps to prevent software from being infiltrated. This includes check digits built into the software to identify ALL instances of the code being altered during development. Any modifications made at the distribution stage (i.e. when the software resides on Internet accessible servers) would, in theory, break the digital signature of the code. So look for measures in place to pick up on this.
Stick to approved vendors. The ‘too good to be true’ supplier whose app is cheaper than the alternatives – but whose service and security credentials cannot be assessed: these are exactly the type of vendor to be wary of if you want to reduce your threat exposure risk.