critical infrastructureDumbest Thing in Security This Week: The Most Exploited...

Dumbest Thing in Security This Week: The Most Exploited Vulnerability Is…

-

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 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 – is 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 are also 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 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.”

What might be most striking about Carhart’s post are the number of environments that have had known compromises for years.

“We have seen an increase in customers with an interest in scoping and creating removal plans for long-term infections (think, 5-10 years) and architectural compromises of their industrial environments,” Carhart wrote. “Safe industrial operation requirements make it extremely challenging to do mass clean-up and reimaging efforts in process facilities. Many facilities have maintained a level of infection and compromise for years and deemed it too costly or high risk to conduct mitigation activities. However, these points of compromise can cause eventual operational and technical impact, in an unpredictable way. Interest has increased in understanding the scale of the problem and ‘projectizing’ removal in a safe way.”

While Carhart sees the new awareness as positive, what’s troubling for those unfamiliar with OT security is how many have not only accepted the risk of unpatched devices, but may have also accepted the compromises that come with that.

Whatever the reasons, there may be billions of internet-facing IoT devices with vulnerabilities – and possibly millions that are already infected.

What’s an OT 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 critical IoT devices 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.” 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 OT 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 OT environments need to do an assessment of their own inventory. Tenable built a Nessus plugin based on scripts in JSOF’s work and whitepapers.

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments

Latest news

Must read

You might also likeRELATED
Recommended to you

0
Would love your thoughts, please comment.x
()
x