2024: Year of the supply chain attack?

The news of Hezbollah agents being targeted with exploding pagers and UHF radios was a shock to us all. Whilst this type of attack was always a possibility in theory, seeing it occur in practice was perhaps the most visually horrific instance of a supply chain attack in recent history.

This attack, along with the .mobi WHOIS debacle and the faulty Crowdstrike update, got me thinking quite a lot about supply chain attack surface. We all have these vulnerabilities, and there’s very little we can do in the way of mitigation.

Its a matter of trust

A supply chain attack is one where a target organisation or individual’s external suppliers are compromised with the intention to attack the target. Suppliers can come in many forms. For Hezbollah, it was the hardware manufacturers, but it could also be software dependencies, SaaS apps, internet infrastructure, service suppliers, or any other entity with a privileged connection to you or your business.

You trust suppliers of all forms to provide a product or service free from vulnerabilities. In some cases there are contracts to set limits on damages - I know I had to buy some hefty insurance before pentesting HFT firms in the past. In other cases there is no contract - trust is given for no apparent reason. Why would you have any reason to doubt the company supplying your office desks?

The risk of supply chain attacks should be included in any threat model where relevant. For most of us, although the likelihood of exploding devices is approaching zero, the impact is so high that we should perhaps pay more attention to the mundane suppliers. Those are the ones that will be the easiest for adversaries to compromise and remain unnoticed.

Six attack vectors in supply chains

1. Compromised internet infrastructure

One of the most mundane of all suppliers is the system of domain name registries, registrars, WHOIS, DNS, and other creaking tech that underpin all goings on on the internet. As a co-founder of an early domain name registrar I know first hand that some of the regisitration and update processes had very little in the way of authentication and authorisation. Some of this tech we still rely on today - WHOIS for example.

WatchTowr recently found that they could register an outdated domain used by the .mobi registry to take over the TLD. When the .mobi TLD became available, the registry switched their WHOIS server from whois.dotmobiregistry.net to whois.mic.mobi. Their error was allowing their .net domain to lapse, which makes it registerable again by anyone - in this case, WatchTowr researchers. They found that many companies - including TLS Certificate Authorities (CAs) - relied on WHOIS data as an authoritative source.

The .mobi registry has learnt a hard lesson - don’t let important domain names lapse - ever. But really the victims of this attack are far removed from the regsitry. The victim is not the registry, or the CAs, or the businesses who relied on those CAs. The victims are the users of those encrypted websites, ordinary people like you and me.

How could we as users have mitigated the risk of this attack? Honestly there’s not much we can do. Its a matter of trust.

2. Compromised SaaS app

We all use so many SaaS apps in business that reliance on them has become a serious security concern. There are risks around data ownership, identity and access management, regulatory issues, vendor security standards, data loss, shadow IT, and incident response complexity. Using SaaS apps effectively widens your trust boundary to include those companys as well as your own.

This greatly increases attack surface for your business, whilst making security controls more difficult to deploy. One of my favourite preventative controls is pentesting and red teaming, but both of these can be very difficult to perform when SaaS apps are involved because of legal issues testing components that don’t belong to your business.

A recent example of a vulnerable SaaS app that affected many users is the 2024 DropBox Sign issue. A malicious actor gained access to a DropBox configuration tool, and was able to exfiltrate emails and usernames, phone numbers, hashed passwords, and authentication information such as OAuth tokens and MFA data.

There are few mitigations against vulnerable SaaS apps. You could send out one of those third-party security questionnaires asking about which standards they comply with, what are their SSDLC practices and so on, but really those are quite pointless. I’ve seen too many vendors tell pork pies about their security practices in order to win business. The concensus, unfortunately, is that a SaaS app is secure “because everyone else is using it!”.

You could perhaps check if the SaaS app is signed up to a bug bounty program. At least that is verifiable publicly.

3. Compromised hardware supplier

This is the hot one right now due to what’s going on in Lebanon. There are however precedents for this type of attack, although not quite as spectacular. In 2022 it was revealed that Supermicro motherboards contained a rice-grain sized extra chip embedded in them, which connected out to China periodically for unknown reasons… AWS and Apple have denied that any of the compromised hardware ever made it in to their cloud infrastructure.

The five-eyes governments of USA, UK, Canada, Australia and New Zealand have all banned Huawei devices from their critical national networks, for fear of the overbearing control the Chinese Communist Party (CCP) have over private companies in China.

This type of attack would require the manufacturer to be in cahoots with the attacker. A lesser but still effective entry point for an attacker would be to intercept shipment of devices and plant the dodgy hardware in the devices then. I expect this was the attack vector in Lebanon, though I would also expect the attack to be easily identified if one of the devices was opened up. You can’t hide explosives as well as hardware measured in nanometres.

Hardware supply chain attacks are partially the reason why governments procure Evaluated Products for their SECRET and TOP SECRET projects. Devices that have passed the Common Criteria have a higher level of assurance than uncertified devices. So if you’re a government, that’s your mitigation, although it sometimes takes so long for a device to be Evaluated that it’s hard to find bleeding edge tech in the list.

Owing to the level of sophistication of this attack, the most likely targets are nation states, cloud suppliers and critical national infrastructure. If you did suspect some C4 in your mobile phone, I expect kevlar phone cases to become available shortly. The rest of us can probably keep this marked down as an accepted risk.

4. Compromised software supplier

There are two stand-out examples of a software supply chain issues recently.

First, In July 2024, a faulty update from Endpoint Detection and Response (EDR) tool maker Crowdstrike caused many high profile outages across the world. Since this tool is deployed extensively by governments and high-security organisations, the impact was considerable. Personally, I couldn’t use my bank card or use the checkouts at my local grocery store for a few hours due to outages.

Although this denial of service was unintentional, it’s still a risk and should be included in threat models. The outage didn’t affect me much - I just waited a couple hours to get my bread and milk. But some companies are seeking significant compensation, due to thing like trading systems and critical healthcare systems going down.

Second, the SolarWinds attack in 2020. SolarWinds is a very popular IT management tool that helps administer IT equipment in your company’s network. This was a bonafide attack - pinned on the Russian group Cozy Bear - who compromised SolarWinds build system to inject malware into software updates. In many cases the update was shipped automatically, giving Cozy Bear remote access to any of the targets. They stayed hidden for months within the target networks, exfiltrating any data they found useful.

Targets for software supply chain attacks are much greater than for hardware. Since it’s much easier to inject malware in software than it is to compromise hardware, the scope is much wider. All businesses are targets for software supply chain attacks, and therefore it must be included in any threat model.

The mitigation to ensure a malicious actor has not tampered with a software update is to check the signatures of the update binaries. But for attacks where the supplier itself has been compromised, there’s not many good preventative security controls. Stopping a compromised software vendor comes down to detection and response. This is where EDR plays a vital role, and why the Crowdstrike issue was peak irony.

5. Compromised software libraries

I split this one away from software suppliers because libraries are imported in to your organisation’s own code, rather than downloaded as a separate product. This is an important difference, because libraries don’t have automatic updates. Software engineers usually pick a version of a third party library that works, and then stick with it until something breaks. This can, unfortunately, cause old and vulnerable versions to persist in your own products. It’s also easy for a malicious actor to slip some code in to open-source products in particular.

The best recent example of this is the Log4Shell issue in 2021, where a critical vulnerability had been shipping in the popular Log4j logging framework since 2013. Anyone running Log4j was vulnerable to remote code execution for 8 years! That included most of the cloud suppliers and other enterprise networks.

The mitigation for this type of vulnerability is to use a dependency checker like OWASP’s Dependency-Check or an equivalent commercial product. You could also run DAST tools to scan for any publicly disclosed vulnerabilities that might be accessible on listening ports or have some other exposure on the local machine.

6. Compromised third-party employees

I’ve done my fair share of contracts as a hired gun cyber security consultant in London, and I can say from experience that my background was almost never checked by the hiring company. After a scan of my CV, a single interview, and my signature on an NDA, I was given root access to many companys’ most critical systems.

Contractors fill an important role as a supplier of services, where expertise is required but only for a specific project of time period. Many contractors need access to sensitive assets such as source code, network infrastructure, and physical spaces.

The mitigation for malicious contractors is the same as for your internal employees. Vet them! Background checks and reference checks are a good start, along with providing them with your company laptop rather than letting them use their own.

Summary of best practices

• Threat model all systems at a business level and a technical level
• Install detection and response tools at the endpoint and in the browser
• Constantly monitor your external and internal attack surface
• Check if SaaS apps are signed up to a bug bounty program
• If you’re in government, check that hardware products have passed the Common Criteria
• The more paranoid amongst us could crack open hardware and take a look with a logic analyser
• Check the signatures for software binaries after download
• Deploy a dependency checker
• Consistently run SAST and DAST scans against your code and app
• Security code review
• Vet your contractors and supply them with a company laptop