Half of publicly reported supply chain attacks were carried out by “well known APT groups”, according to an analysis by EU infosec agency ENISA, which warned such digital assaults need to drive “new protective methods.”
Of the 24 supply-chain attacks studied by ENISA since January 2020, a dozen were attributed to APTs while 10 of them hadn’t been attributed to anyone at all in open-source reporting, the agency said.
Juhan Lepassaar, ENISA’s exec director, said in a canned statement: “Due to the cascading effect of supply chain attacks, threat actors can cause widespread damage affecting businesses and their customers all at once. With good practices and coordinated actions at EU level, Member States will be able to reach a similar level of capabilities raising the common level of cybersecurity in the EU.”
The open-source study is intended as a primer on supply-chain attacks, which typically consist of targeting B2B software suppliers that have extensive customer lists. Once the supplier is compromised, the attackers then move laterally into their customers’ networks, typically to steal data and extort the victims.
“An additional characteristic of supply chain attacks involves the complexity in handling them and the efforts required to mitigate and address such attacks,” said ENISA in its report.
This was illustrated when IT management toolmaker Kaseya pulled the software-as-a-service offering of its VSA suite offline and told clients to turn off their on-prem deployments of VSA after installations of the software were exploited to deliver ransomware. Restoration of those services was repeatedly delayed as the biz tried to figure out how to patch its code to prevent any further infections.
To the best of our knowledge, all we really know is that, according to Kaseya, “the attackers were able to exploit zero-day vulnerabilities in the VSA product to bypass authentication and run arbitrary command execution. This allowed the attackers to leverage the standard VSA product functionality to deploy ransomware to endpoints.”
ENISA criticized suppliers for either not knowing or not admitting in public how they were compromised. The UK is taking advantage of Brexit to lower incident reporting thresholds in security frameworks first created by EU laws; perhaps the political bloc may follow suit.
ENISA, which is soon to be dragged from its Greek home – split between capital Athens and the sunny island of Heraklion – to the grey towers of Brussels, also proposed its own unique taxonomy for analyzing supply chain attacks. In doing so it lightly pooh-poohed both MITRE’s ATT&CK and Lockheed Martin’s Cyber Kill Chain analysis frameworks as “too generic.”
The report lists the supply-chain incidents studied by ENISA. Aside from the high-profile ones involving Accellion, SolarWinds, and Kaseya, it also lists Fujitsu’s ProjectWeb, the Bignox Noxplayer Android emulator, and more.
Er, is this good advice?
“In order to compromise the targeted customers, attackers focused on the suppliers’ code in about 66 per cent of the reported incidents,” noted ENISA. “This shows that organisations should focus their efforts on validating third-party code and software before using them to ensure these were not tampered with or manipulated.”
Though we appreciate the spirit of this advice, it’s doing a lot of heavy lifting for what is a non-trivial issue.
The most high-profile supply-chain attack of late was the SolarWinds Orion compromise. In this, Russian spies compromised the vendor’s systems to hide a backdoor in an update for the Orion network management and monitoring software. The end goal being that SolarWinds’ customers would install the tainted update, and selected valuable targets would be infiltrated via the implanted vulnerability.
That update was fetched by 18,000 organizations through normal channels, none of them suspecting any foul play; the backdoor was stashed in a signed .dll file. It’s tricky to see how your common or garden end-user organization could have detected that.
It’s not feasible to ask every org to break out disassemblers, source code editors, and network and memory analysis tools, and have staff on hand capable of using them, to inspect every update, be they open or closed source.
It would be better to have robust mechanisms in place to verify that software packages are legit, and released and fetched as intended by their maintainers, and in a way that if build systems are infiltrated, as we saw with SolarWinds, unauthorized changes are still apparent. This can be done, though making it completely airtight is not quite as easy as one might hope if your adversary is the Kremlin.
Crucially, even then, it’s on the suppliers to first create these mechanisms, and customers to then use them.
That all said, Google’s SLSA proposal may prove be useful down the line. ®