Cyble’s weekly sensor report is an always fascinating look at the vulnerabilities that threat actors are actively exploiting. While new vulnerabilities are quickly exploited, older ones are still exploited with remarkable, if not alarming, frequency.
Now before you go blaming grandpa for never updating that five-year-old Windows desktop, you’re not going to believe what is consistently the most exploited vulnerability. Or if you work in IoT or critical infrastructure cybersecurity, you might not be surprised by the answer.
It’s not unusual to see this security vulnerability attacked more than 100,000 times in a given week, but this week Cyble sensors detected a jaw-dropping 411,000 attacks on this one vulnerability, showing that exploitation is growing dramatically over time. It’s getting worse, not better.
The vulnerability is CVE-2020-11899, a four-year-old known vulnerability in the Treck TCP/IP stack that was developed as an IPv6 implementation for the limited space of embedded devices. That means there’s a good chance the flaw – which affects Treck TCP/IP versions before 6.0.1.66 – could be present in any medical, industrial or critical infrastructure device that supports IPv6, and some consumer devices too.
CVE-2020-11899 is an Out-of-bounds Read vulnerability rated a not-scary 5.4, but when used as part of the “Ripple20” series of vulnerabilities, it can lead to some Halloween levels of scariness. As Ripple20 discoverer JSOF put it:
“…data could be stolen off of a printer, an infusion pump behavior changed, or industrial control devices could be made to malfunction. An attacker could hide malicious code within embedded devices for years. One of the vulnerabilities could enable entry from outside into the network boundaries; and this is only a small taste of the potential risks.”
With potentially hundreds of millions of IoT, IIoT and embedded devices affected by the vulnerabilities, including some consumer devices, it’s a software supply chain vulnerability on steroids. CISA’s Ripple20 advisory – just updated last month – lists 17 prominent industrial, medical and critical infrastructure device manufacturers as potentially affected by the vulnerabilities. As those devices may also be difficult to update, mitigations may be the best that many organizations can do to control risk in this case.
We’ll look at what organizations can do to protect themselves from this very active exploit – along with the deplorable state of IoT security and hopes for improvement.
The Most Exploited Vulnerability and IoT Security
2024 could mark a turning point for the better for IoT security, with the EU Cyber Resilience Act and the UK Product Security and Telecommunications Infrastructure (PSTI) Regulations taking effect and initiatives underway in several other countries, but the new rules and laws will do little for the millions, if not billions, of older devices that remain vulnerable and exposed to physical and cyber attacks.
There are many reasons why IoT devices often harbor known vulnerabilities. Some have reached end-of-life (EOL) and are too integral or expensive to replace. Some must operate continuously, presenting daunting logistical challenges for patch management. Others are physically remote, or part of a vast network of different operating systems and configurations – many non-standard – that make updating nearly impossible. And some were never meant to be exposed to the internet, with connected functionality added as an afterthought.
In a blog post yesterday, Lesley Carhart, director of incident response at OT/ICS security company Dragos, noted positive changes in operational technology (OT) awareness even as the challenges remain daunting.
“We frequently see Windows 2003 or older operating systems,” Carhart wrote. “There is little ability to safely use modern forensic agents broadly in most environments. Everything centers around life and safety. However, more recently I have experienced an intriguing shift in incident response cases that I believe reflects a positive growth in OT cybersecurity awareness across various verticals.”
While OT security may be more centered around issues with programmable logic controllers (PLCs), perhaps the increasing interconnectivity between OT and IoT networks could result in improved awareness for IoT security too. There may be billions of internet-facing IoT devices with vulnerabilities – and possibly millions that are already infected. What’s an organization to do?
IoT Security Practices and Controls
There may be little an already-infected organization can do short of costly cleanup (if you’re in critical infrastructure, CISA may be able to offer free help), but there are steps that all organizations with IoT devices and networks can take to limit damage and access.
Start with an inventory of IoT devices so you’ll understand the scope of the problem. Patch where possible, and reach out to vendors for more information if needed.
If a device doesn’t need to be exposed to the internet, make sure it isn’t, and disable any unnecessary ports, services and protocols.
Carhart notes one major problem: “ineffective DMZ boundaries between Enterprise and OT,” and the same could be said for IoT. That’s best fixed by strong network segmentation and microsegmentation, and “zero trust” policies that limit access and permissions to only that which a role requires. Segmentation can be done even within the IoT network itself if some parts are more sensitive than others.
The vast majority of IoT traffic is unencrypted, making that a control that should be high on most organizations’ priority list. Firewalls, intrusion detection, network monitoring and even VPNs are better controls than many have in place now.
Default passwords and user names should be changed if they haven’t been, and multi-factor authentication (MFA) should be added wherever possible.
JSOF’s initial advisory listed 31 vendors affected by Ripple20, including big names like Dell, Cisco and HP/HPE, so IoT device environments need to do an assessment of their own inventory. Tenable built a Nessus plugin based on scripts in JSOF’s work and whitepapers.
