CISA and friends raise alarm on critical flaws in industrial equipment, infrastructure
(2022/06/21)
- Reference: 1655784065
- News link: https://www.theregister.co.uk/2022/06/21/56_vulnerabilities_critical_industrial/
- Source link:
Fifty-six vulnerabilities – some deemed critical – have been found in industrial operational technology (OT) systems from ten global manufacturers including Honeywell, Ericsson, Motorola, and Siemens, putting more than 30,000 devices worldwide at risk, according to the US government's CISA and private security researchers.
Some of these vulnerabilities received CVSS severity scores as high as 9.8 out of 10. That is particularly bad, considering these devices are used in critical infrastructure across the oil and gas, chemical, nuclear, power generation and distribution, manufacturing, water treatment and distribution, mining and building and automation industries.
The most serious security flaws include remote code execution (RCE) and firmware vulnerabilities. If exploited, these holes could potentially allow miscreants to shut down electrical and water systems, disrupt the food supply, change the ratio of ingredients to result in toxic mixtures, and … OK, you get the idea.
[1]
That's not to say all or any of these scenarios are realistically possible – just that these are the kinds of machines and processes involved.
[2]
[3]
Forescout's Vedere Labs discovered the bugs in devices built by ten vendors in use across the security company's customer base, and collectively named them OT:ICEFALL. According to the researchers, the vulnerabilities affect at least 324 organizations globally – and in reality this number is probably much larger since Forescout only has visibility into its own customers' OT devices.
In addition to the previously named manufacturers, the researchers found flaws in products from Bently Nevada, Emerson, JTEKT, Omron, Phoenix Contact, and Yokogawa.
OT devices insecure by design
Most of the flaws occur in level 1 and level 2 OT devices. Level 1 devices – such as programmable logic controllers (PLCs) and remote terminal units (RTUs) – control physical processes, while level 2 devices include supervisory control and data acquisition (SCADA) and human-machine interface systems.
In addition to the 56 detailed today in a [4]Vedere report , the threat-hunting team discovered four others that are still under wraps due to responsible disclosure. One of the four allows credentials to be compromised, two allow an attacker to manipulate OT systems' firmware, and the final one is an RCE via memory write flaw.
[5]
Many of these holes are a result of OT products' so-called "insecure-by-design" construction, Forescout's head of security research Daniel dos Santos told The Register . Several OT devices don't include basic security controls, which makes them easier for attackers to exploit, he explained.
Forescout's analysis comes ten years after Digital Bond's [6]Project Basecamp that also looked at OT devices and protocols, and deemed them "insecure by design."
[7]What if ransomware evolved to hit IoT in the enterprise?
[8]Five Eyes nations fear wave of Russian attacks against critical infrastructure
[9]Threat group builds custom malware to attack industrial systems
[10]Detailed: Critical hijacking bugs that took months to patch in Microsoft Azure Defender for IoT
Since that earlier analysis, "there have been real-word real incidents, real malware that has abused insecure-by-design functionality of devices to cause disruption and physical damage, like [11]Industroyer in the Ukraine in 2016, or [12]Triton in the Middle East in 2017," dos Santos said.
In fact, some of the vulnerabilities detailed by Forescout have already been targeted to compromise industrial control systems. This includes CVE-2022-31206 – an RCE affecting Omron NJ/ NX controllers, targeted by [13]Incontroller , a suspected state-sponsored malware tool.
"One instance of insecure-by-design is unauthenticated protocols," dos Santos said. "So basically, whenever you interact with the device you can call sensitive functions on the device, invoke this function directly without it asking for a password."
[14]
The security researchers found nine vulnerabilities related to protocols that have no authentication on them: CVE-2022-29953, CVE-2022-29957, CVE-2022- 29966, CVE-2022-30264, CVE-2022-30313, CVE-2022-30317, CVE-2022-29952 and CVE-2022-30276. Most of these can be exploited to download and run firmware and logic on someone else's equipment, thus leading to RCEs, or shutdowns and reboots, which can cause denial of service conditions. Ideally, machines using these protocols are not connected to computers and other systems in a way that would allow a network intruder to exploit them.
Credential compromise is the most common
Vedere Labs counted five of the flaws more than once because they have multiple potential impacts.
More than a third of the 56 flaws (38 percent) can be abused to compromise user login credentials, while 21 percent, if exploited, could allow a miscreant to manipulate the firmware, and 14 percent are RCEs. In terms of the other vulnerability types, denial of service and configuration manipulation account for eight percent, authentication bypass vulns make up six percent, file manipulation comes in at three percent, and logic manipulation at two percent.
The researchers noted that patching these security issues won't be easy – either because they are the result of OT products being insecure by design, or because they require changes in device firmware and supported protocols. "Realistically, that process will take a very long time," they wrote.
Because of this, they did not disclose all of the technical details for the buggy OT devices – hence the lack of depth here. They did, however, suggest that customers follow each vendor's security advisories – due out today or soon – for more details. Additionally, the security shop recommends isolating OT and industrial control systems' networks from corporate networks and the internet when possible.
More information can be found in [15]Vedere's report , and announcements from Uncle Sam's [16]CISA are due out today ®
Get our [17]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.forescout.com/resources/ot-icefall-report/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://github.com/digitalbond/Basecamp
[7] https://www.theregister.com/2022/06/01/ransomware_iot_devices/
[8] https://www.theregister.com/2022/04/21/five_eyes_russia/
[9] https://www.theregister.com/2022/04/14/hackers-custom-malware-ics-scada/
[10] https://www.theregister.com/2022/03/30/sentinelone_microsoft_azure_iot/
[11] https://malpedia.caad.fkie.fraunhofer.de/details/win.industroyer
[12] https://www.theregister.com/2022/03/28/in_brief_security/
[13] https://www.mandiant.com/resources/incontroller-state-sponsored-ics-tool
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] https://www.forescout.com/resources/ot-icefall-report/
[16] https://www.cisa.gov
[17] https://whitepapers.theregister.com/
Some of these vulnerabilities received CVSS severity scores as high as 9.8 out of 10. That is particularly bad, considering these devices are used in critical infrastructure across the oil and gas, chemical, nuclear, power generation and distribution, manufacturing, water treatment and distribution, mining and building and automation industries.
The most serious security flaws include remote code execution (RCE) and firmware vulnerabilities. If exploited, these holes could potentially allow miscreants to shut down electrical and water systems, disrupt the food supply, change the ratio of ingredients to result in toxic mixtures, and … OK, you get the idea.
[1]
That's not to say all or any of these scenarios are realistically possible – just that these are the kinds of machines and processes involved.
[2]
[3]
Forescout's Vedere Labs discovered the bugs in devices built by ten vendors in use across the security company's customer base, and collectively named them OT:ICEFALL. According to the researchers, the vulnerabilities affect at least 324 organizations globally – and in reality this number is probably much larger since Forescout only has visibility into its own customers' OT devices.
In addition to the previously named manufacturers, the researchers found flaws in products from Bently Nevada, Emerson, JTEKT, Omron, Phoenix Contact, and Yokogawa.
OT devices insecure by design
Most of the flaws occur in level 1 and level 2 OT devices. Level 1 devices – such as programmable logic controllers (PLCs) and remote terminal units (RTUs) – control physical processes, while level 2 devices include supervisory control and data acquisition (SCADA) and human-machine interface systems.
In addition to the 56 detailed today in a [4]Vedere report , the threat-hunting team discovered four others that are still under wraps due to responsible disclosure. One of the four allows credentials to be compromised, two allow an attacker to manipulate OT systems' firmware, and the final one is an RCE via memory write flaw.
[5]
Many of these holes are a result of OT products' so-called "insecure-by-design" construction, Forescout's head of security research Daniel dos Santos told The Register . Several OT devices don't include basic security controls, which makes them easier for attackers to exploit, he explained.
Forescout's analysis comes ten years after Digital Bond's [6]Project Basecamp that also looked at OT devices and protocols, and deemed them "insecure by design."
[7]What if ransomware evolved to hit IoT in the enterprise?
[8]Five Eyes nations fear wave of Russian attacks against critical infrastructure
[9]Threat group builds custom malware to attack industrial systems
[10]Detailed: Critical hijacking bugs that took months to patch in Microsoft Azure Defender for IoT
Since that earlier analysis, "there have been real-word real incidents, real malware that has abused insecure-by-design functionality of devices to cause disruption and physical damage, like [11]Industroyer in the Ukraine in 2016, or [12]Triton in the Middle East in 2017," dos Santos said.
In fact, some of the vulnerabilities detailed by Forescout have already been targeted to compromise industrial control systems. This includes CVE-2022-31206 – an RCE affecting Omron NJ/ NX controllers, targeted by [13]Incontroller , a suspected state-sponsored malware tool.
"One instance of insecure-by-design is unauthenticated protocols," dos Santos said. "So basically, whenever you interact with the device you can call sensitive functions on the device, invoke this function directly without it asking for a password."
[14]
The security researchers found nine vulnerabilities related to protocols that have no authentication on them: CVE-2022-29953, CVE-2022-29957, CVE-2022- 29966, CVE-2022-30264, CVE-2022-30313, CVE-2022-30317, CVE-2022-29952 and CVE-2022-30276. Most of these can be exploited to download and run firmware and logic on someone else's equipment, thus leading to RCEs, or shutdowns and reboots, which can cause denial of service conditions. Ideally, machines using these protocols are not connected to computers and other systems in a way that would allow a network intruder to exploit them.
Credential compromise is the most common
Vedere Labs counted five of the flaws more than once because they have multiple potential impacts.
More than a third of the 56 flaws (38 percent) can be abused to compromise user login credentials, while 21 percent, if exploited, could allow a miscreant to manipulate the firmware, and 14 percent are RCEs. In terms of the other vulnerability types, denial of service and configuration manipulation account for eight percent, authentication bypass vulns make up six percent, file manipulation comes in at three percent, and logic manipulation at two percent.
The researchers noted that patching these security issues won't be easy – either because they are the result of OT products being insecure by design, or because they require changes in device firmware and supported protocols. "Realistically, that process will take a very long time," they wrote.
Because of this, they did not disclose all of the technical details for the buggy OT devices – hence the lack of depth here. They did, however, suggest that customers follow each vendor's security advisories – due out today or soon – for more details. Additionally, the security shop recommends isolating OT and industrial control systems' networks from corporate networks and the internet when possible.
More information can be found in [15]Vedere's report , and announcements from Uncle Sam's [16]CISA are due out today ®
Get our [17]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.forescout.com/resources/ot-icefall-report/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://github.com/digitalbond/Basecamp
[7] https://www.theregister.com/2022/06/01/ransomware_iot_devices/
[8] https://www.theregister.com/2022/04/21/five_eyes_russia/
[9] https://www.theregister.com/2022/04/14/hackers-custom-malware-ics-scada/
[10] https://www.theregister.com/2022/03/30/sentinelone_microsoft_azure_iot/
[11] https://malpedia.caad.fkie.fraunhofer.de/details/win.industroyer
[12] https://www.theregister.com/2022/03/28/in_brief_security/
[13] https://www.mandiant.com/resources/incontroller-state-sponsored-ics-tool
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YrGWxlJ1exsb3s4nWzGDJgAAAIM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] https://www.forescout.com/resources/ot-icefall-report/
[16] https://www.cisa.gov
[17] https://whitepapers.theregister.com/
Re: Hmm
DS999
Wait, the requirement is that it "must" be isolated from your office network but it is only "preferable" it be isolated from the internet? Surely if it must be fully isolated from the office network it must also be equally isolated from the internet!
I didn't see it in person, but I recall an architecture diagram for a enterprise network that had an isolated network that was connected via a fiber with the receive line physically cut. It could get data out via UDP, but nothing could get in. I believe they used some sort of verbose LPDC coding like satellite transmissions use for error tolerance since there wasn't any way for the receiver to report missing data (though if your network is solid this shouldn't be much of a concern)
If the PLCs won't send their data via UDP, you'd just need a collection server inside the isolated PLC network that would handle the TCP/IP connections to the PLCs, and be the UDP source to the SQL servers in the office network.
Re: Hmm
Headley_Grange
I assume it’s because the bigger threat is employees either by phishing or other nefarious activities.
Re: Hmm
Doctor Syntax
That, or it's a subtle push to move our SQL servers (or maybe ALL of our servers) out to "the cloud".
Certainly not to the cloud. Put the servers for the plant onto the plant's network, separated from the office network. The tricky bit comes when you need to push reports back from the plant to the office.
Paul Crawford
Additionally, the security shop recommends isolating OT and industrial control systems' networks from corporate networks and the internet when possible.
Should that not have been the case from day #0?
Doctor Syntax
Ideally, yes. However the controllers may well have been designed before anyone started thinking about such things. For the last decade or more, however, the default assumption should have been that such equipment was inherently vulnerable and should be isolated.
"Fifty-six vulnerabilities [+4] – some deemed critical – have been found"
Pascal Monett
I think the hackers [1]already know . . .
[1] https://www.imdb.com/title/tt0337978/
Hmm
Funny thing - we were just told a few weeks ago by our Cyber-insurance carrier that we need to protect our Industrial network from our "office" network. The Industrial net needs to be completely and securely isolated from the rest of the network, and preferably from the Internet as well. Isolation from the local net isn't easy, since the PLCs need to send a sizeable stream of data to the SQL servers over in the office network.
Judging from this story, that may be holding the tiger by the wrong end. That, or it's a subtle push to move our SQL servers (or maybe ALL of our servers) out to "the cloud".