Dozens of security flaws found in common OT devices

The next thing your factory floor could be pumping out is malware.

Multiple CISA advisories stemming from a report by Forescout’s Vedere Labs have identified 56 vulnerabilities in operational technology (OT) devices made by 10 major manufacturers, including Honeywell, Emerson, Motorola, and Siemens—some of which were critical, racking up CVSS scores as high as 9.8 out of 10.

OT devices are the blue-collar counterpart to IT, monitoring and regulating physical processes. That could mean a pressure valve in an oil refinery that’s the difference between life and death, automated manufacturing equipment critical to manufacturing flow, or something as simple as a network of thermostats. They’ve typically been much less of a concern for the cybersecurity field than IT networks, which might be fine if people stopped connecting their OT devices to the internet.

The vulnerable products identified by Forescout mostly fall into two OT categories: level one, or equipment that directly monitors and modifies processes; and level two, which is basically their machine foreman.

The insecure devices flagged by CISA and Forescout include programmable logic controllers (PLCs), engineering workstations, and SCADA systems used in sectors including oil and gas, nuclear, chemicals, and water treatment. In other cases, the affected systems include building automation systems controlling subsystems like doors and environmental regulation. The most serious flaws allow nasty tricks like remote code execution and firmware manipulation, with unpredictable (and potentially destructive) results.

According to Forescout Head of Security Research Daniel dos Santos, while some of the affected devices were released recently, others were designed years or decades ago. Some of those may have originally been intended to work disconnected entirely from outside networks—and thus potentially assumed by some to be at low-risk from hackers.

“What kind of puts this vulnerability together…is basically because they are all related to one thing, which is called ‘insecurity by design,’” dos Santos told IT Brew. “It’s not the type of vulnerability where somebody programmed something wrong and that allows an attacker to exploit things, it’s just that there was no security control put in place in the first place.”

“So something like no authentication, or no encryption, or no check of [the] integrity of a firmware file” that should be verified via signature, dos Santos added.

About 38% of the flaws “allow for compromise of credentials,” while 21% allow firmware manipulation and 14% allow remote code execution. Yet nearly 3 out of 4 of the affected devices’s product families were nonetheless slapped with “some sort of security certification.” Reasons for this might include limited time and resources on the part of auditors or the assumption a given flaw would never be at risk of real-life exploitation, dos Santos said.

“Certification standards have their limitations,” dos Santos cautioned. “You need to pay attention, really, to what a certification actually means, right down to the fine print, down to the small letters.”

While the most famous OT attacks have historically been the domain of nation states–like Stuxnet, a cyberweapon designed to destroy nuclear gas centrifuges–the Forescout report warns exploitation of these and similar vulnerabilities is likely within the reach of commercial malware developers.

“If you have the right incentive, and you have the right amount of time, [and] the right skill set, of course, you will be able to understand how to exploit these devices,” dos Santos said.

Despite CISA’s involvement, not all of the manufacturers have been responsive, dos Santos added. He suggested both vendors and customers might have various reasons to not remedy the flaws, such as expensive production downtime or that a product's code might essentially have to be rewritten from scratch (which could cause complex problems in the environments they are actually installed in).

“Some of the responses have been like, ‘This is insecure, and a new version is coming, you know, somewhere in the future,’” dos Santos said. “Some others have been like, ‘This is insecure, and it’s just insecure the way it is…we’ll replace this product line at some point.’”

Often, when trying to remedy insecurity-by-design, “it’s not a programming error that you fix on the new firmware version,” he said. “It’s really the way that the protocols work; the way that they are designed. And they would require significant changes on the design of systems in production as well.”—TM

Do you work in IT or have information about your IT department you want to share? Email [email protected] or DM @thetomzone on Twitter. Want to go encrypted? Ask Tom for his Signal.