Accessing corporate networks via software updates: cybercriminals attempt to penetrate well-secured corporate networks using manipulated applications from third parties or by exploiting gaps in components, e.g. “Log4Shell”. This attack vector via the supply chain confronts IT security officers with new challenges.
Text: Andreas Heer, Image: AdobeStock,
In December 2020, it was revealed to the wider public literally overnight that cybercriminals are now not only capable of attacking the IT infrastructure of organisations directly, but also via the software used by these organisations. Suspected state-funded actors managed to create a back door into SolarWinds Orion, a network management software system. The compromised update, which included code signed by the manufacturer itself, was then distributed to around 18,000 organisations whose infrastructure the cybercriminals now had easy access to. This “sunburst” attack, as it became known, has the dubious honour of not only being one of the most sophisticated and serious cyberattacks of all time, but also, it is believed, of being the biggest attack carried out on the software supply chain to date.
But things can always get worse. No sooner had the IT security world recovered from this shock when a small Java library caused a stir. “Log4j” not only saves log files of applications, but in December 2021, it was also identified as the source responsible for executing random program code from a remote system. All that was needed was for an application, when called up, to send an easily constructed URL string to Log4j. Accordingly, this RCE (remote code execution) gap received a criticality score of 10, the highest on the scale. The gap itself circulated as “Log4Shell” and was actively being exploited soon after detection.
But that’s not all. As the library is integrated into applications, companies had to first find out whether they themselves had been affected. And so a feverish search ensued around the globe for applications using Log4j. Only then could companies install the update that would plug the gap.
Compromised software from trustworthy sources, gaps in software libraries and a lack of transparency regarding the libraries and frameworks effectively implemented: the software supply chain has revealed itself as the Achilles heel in otherwise well-protected IT infrastructure. And the danger is anything but over: at the start of 2022, a gap was discovered in the “Spring” framework used by many Java applications, a story that is undoubtedly set to be continued.
According to the Swisscom Cybersecurity Threat Radar, supply chain attacks are among the main trends that IT security officers need to keep a close eye on. Oliver Jäschke, Security Governance Manager at Swisscom, gave his assessment of the situation in an interview.
Oliver Jäschke, what is the significance of supply chain attacks in IT security, for example, compared to common ransomware attacks?
Supply chain attacks, that is, attacks on deliverables, are still very rare in comparison. That’s because they are not as widespread compared to the ransomware attacks we see today. But uncovering them is much more difficult because authorised users are the ones making the changes in the deliverables and these changes therefore often go unnoticed. Further measures beyond the dual-control principle are needed in the development process to combat this.
Despite this, supply chain attacks have still received plenty of attention. What’s the problem here?
Attacks within the supply chain are very difficult to detect. You trust your suppliers to have security under control. At the end of the day, you’re paying for a product and expect certain standards. You expect security to be part of the package.
The fact that suppliers use other suppliers for subcomponents or even free and open-source software (FOSS) is often neglected. Traceability is very difficult at this late stage.
How can companies respond to this situation?
Companies need to take security measures, of course. They can also demand that deliverables be inspected using specific security checks. Furthermore, the topic of SBOM is garnering a lot of attention at the moment. While such a software bill of materials (SBOM), that is, a BOM of installed software components, does not prevent attacks on the supply chain per se, it allows companies to identify products with particular vulnerabilities early on and take appropriate action. Companies would have stood a much better chance of combating Log4Shell if every supplier had used an SBOM to demonstrate that they were using this specific component.
Would you like to regularly receive interesting articles and whitepapers on current ICT topics?
More on the topic: