What to do about inherent security flaws in critical infrastructure?

July 3, 2022 TH Author

The latest threat security research into operational technology (OT) and industrial systems identified a bunch of issues — 56 to be exact — that criminals could use to launch cyberattacks against critical infrastructure.

But many of them are unfixable, due to insecure protocols and architectural designs. And this highlights a larger security problem with devices that control electric grids and keep clean water flowing through faucets, according to some industrial cybersecurity experts.

“Industrial control systems have these inherent vulnerabilities,” Ron Fabela, CTO of OT cybersecurity firm SynSaber told The Register. “That’s just the way they were designed. They don’t have patches in the traditional sense like, oh, Windows has a vulnerability, apply this KB.”

In research published last week, Forescout’s Vedere Labs detailed 56 bugs in devices built by ten vendors and collectively named the security flaws OT:ICEFALL.

As the report authors acknowledged, many of these holes are a result of OT products’ being built with no basic security controls. Indeed, Forescout’s analysis comes ten years after Digital Bond’s Project Basecamp that also looked at OT devices and protocols and deemed them “insecure by design.”

A few hours after Forescout published its research, CISA issued its own security warnings related to the OT:ICEFALL vulnerabilities.

CVEs: The problem? Or the fix?

“Up until this point, CVEs haven’t been generated for these insecure-by-design-things, and there’s a reason for that,” Fabela said. “It’s bad for the industry.”

Once a CVE is generated, it sets into motion a series of actions by industrial systems’ operators, especially in heavily regulated industries like electric utilities and oil and gas pipelines.

First, they have to determine if the environment contains any affected products. But unlike enterprise IT, which usually has centralized visibility and control over IT assets, in OT environments, “everything is distributed,” Fabela noted.

If industrial and manufacturing environments do have any products impacted by the vulnerability, that triggers an internal review and regulatory process that involves responding to CISA and developing a plan to improve security.

One SynSaber customer sarcastically described OT:ICEFALL as “the gift that keeps on giving,” Fabela said. “He said, ‘Now I have this on top of all my other like, the real vulnerabilities’,” which present a slew of other problems when it comes to patching — such as having to wait until a planned maintenance outage that may be months out — if the manufacturer has a patch at all.

OT protocols don’t use authentication

For example: The current Modbus protocol, which is very commonly used in industrial environments, does not have authentication.

Forescout’s analysis details nine vulnerabilities related to unauthenticated protocols and disputes the argument that against assigning a CVE ID to a product with an insecurity OT protocol.

“On the contrary, we believe a CVE is a community recognized marker that aids in vulnerability visibility and actionability by helping push vendors to fix issues and asset owners to assess risks and apply patches,” the authors wrote.

While this makes sense from an IT security perspective, Fabela said it’s unrealistic from an OT perspective, and ultimately doesn’t make critical infrastructure any more secure.

Modbus, as a protocol that does not use authentication, could generate “thousands” of CVEs that “affect every product line in the world,” he Fabela. “You’re tying up the product security teams with the OEMs and you’re tying up the customers, the asset owners with CVE that they can’t do anything about.”

Basecamp researcher weighs in

Reid Wightman is a senior vulnerability researcher with OT security shop Dragos’ threat intel team. He’s also one of the original Project Basecamp researchers, and, more recently has done work on the ProConOs and MultiProg software vulnerabilities.

Forescout cited some of his research, and dedicated a section of the ICEFALL analysis to security flaws with the ProConOS runtime in PLCs.

In an email to The Register, Wightman noted that a lot of industrial controllers have the same set of problems that isn’t going away: “they allow unauthenticated code to run on the PLC.”

“This means that one malicious logic transfer to the PLC may permanently compromise the PLC,” he added, noting that, because the control logic is causing the change, it can happen outside of a normal firmware update. “It’s kind of a thing I’ve harped on since the Basecamp days, but may be worth repeating. Over and over again. Until the sun burns out, probably.”

Lately, one of Wightman’s “big, personal concerns” is that some vendors say they can use TLS and client certificates to secure controllers, presumably to avoid. In reality, this would just make the traffic more difficult to inspect, Wightman said.

“If an attacker gets onto the engineering system, they may load a malicious payload using CVE-2022-31800/CVE-2022-31801 (or any of the similar problems that exist in almost every logic runtime) into the controller,” he added. “Only, now we have no way of telling whether they did it because the traffic is encrypted.”

So how do we fix the problem?

“I guess my answer would be: if your engineering system is compromised, throw away all of the controllers that it was allowed to talk to,” Wightman said. “And I doubt most end users would go to that level of paranoia.”

Which, again, points to the insecure-by-design nature of how these systems are engineered.

“Thankfully, we see no signs of any widespread abuse of these protocols or ‘features’ in spite of some of the bugs being well-known for years,” Wightman added. “I really do hope it stays that way.” ®