OT:Icefall: 56 vulnerabilities plague OT devices from 10 different major industrial manufacturers
Ten years ago, Project Basecamp introduced SCADA exploits into Metasploit. The hope was that it would encourage a ‘Firesheep Moment’ (that is, the rapid solution to a long-known security issue following publication of an exploit); and more specifically, persuade manufacturers to introduce ‘security by design’. Ten years on, researchers have examined whether it worked – and it hasn’t.
In 2013, Dale Peterson, founder and CEO at Digital Bond and contributor to Project Basecamp wrote, “We coined the term of Insecure By Design as part of Project Basecamp… Most ICS vulnerabilities matter little because most ICS protocols and controllers are Insecure By Design.”
Ten years after Basecamp, Vedere researchers at Forescout have conducted their own project, dubbed OT:Icefall, so named because Icefall is the second stop on the Everest route after Basecamp, to see if anything has changed. The conclusions are not reassuring.
“Typically, we focus our research on program error vulnerabilities,” Daniel dos Santos, head of security research at Forescout, told SecurityWeek. But most OT malware – Industroyer, Triton, Incontroller – doesn’t use programming error vulnerabilities. Instead, they use flaws in the protocols, the authorization, certifications: in fact, they use the weaknesses that shouldn’t be there if the products were not insecure by design.
Forescout found 56 insecure by design problems in ten manufacturers, including Baker Hughes (Bentley Nevada), Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens, and Yokogawa.
The issues are not new. Many of the products were designed long ago and are still operational and still being manufactured. Vendors are trying to improve them; but a wholesale switch to new products is not a viable solution for users. Even patching products where continuity of operation is essential is a heavy lift for OT operators.
Discovered flaws are often not given CVEs, are often not patched by vendors, and can be ignored by users. After all, some of them are deep in products that are supposedly isolated from the internet in products not accessible by attackers.
But security by obscurity does not work. The motivation for attacks against OT is growing – both for geopolitical nation state reasons and for criminal extortion attacks. Criminals can use the same vulnerability research methods used by researchers such as Forescout’s Vedere.
“Criminals can buy these products secondhand on Ebay and can then go through the same process of reverse engineering that we use. It’s not as difficult as people tend to think,” he added. “For the simplest types of protocols, it took us from one day to two weeks to understand the protocol and be able to interact and exploit things. For more complicated systems, with multiple devices and multiple types of protocols, it takes more like six man-months to understand the product family – so a group could do it in just a couple of months.”
The result is that attacks against critical industries and infrastructure are less difficult than we might assume – from disruption to ransomware and even wipers.
Forescout found four primary categories of vulnerabilities: insecure engineering protocols; weak cryptography or broken authentication schemes; insecure firmware updates; and remote code execution via native functionality. All are listed in the OT:Icefall report (PDF), have been given CVEs and have been disclosed to the vendors. But even if fixes are provided, the operational difficulty in patching OT doesn’t mean that the problem will go away.
Learn More About OT Cybersecurity at SecurityWeek’s ICS Cyber Security Conference
Dos Santos raised an additional problem with SecurityWeek; poor product certifications. “There has been a push for security certification of products – but the effect could lead to a false sense of security. Around 70% of the devices that we analyzed had some sort of security label on them, but still they had basic issues. Part of the cause has been the unwillingness to assign CVEs in the past, but other causes are limited evaluations and imprecise security definitions.”
He also noted a supply chain issue. “We didn’t focus on the supply chain, we focused on specific devices. But we found some vulnerabilities that were assigned previously to a PLC runtime – assigned by the original vendor of the software – that didn’t make it downstream to all the other vendors that were using that software. That speaks to the problem of not having software bills of materials (SBOM), not understanding precisely what components are in each device, and having vulnerable things that are not always identified. They are known to be vulnerable at the source but never make it down to other vendors.”
The overriding message from this research is that easy-to-find vulnerabilities are rife in OT devices. The problems are partly historical, but not easy to solve. Forescout’s application of CVEs to the vulnerabilities will encourage vendors to provide patches, but whether OT departments will be able to apply the patches is a different matter.
OT security teams need to accept that there are vulnerabilities in their OT devices, and that criminal gangs either know about them or are looking for them. The security teams should accept that they need to take on greater responsibility to protect them, and not rely on the vendors to fix them. That means isolation, passive anomaly detection, segmentation and zero trust must be given a high priority.