IoT
Black Hat Trip Report – Trend Micro
Trend Micro presented two important talks on IIoT vulnerabilities at Black Hat USA 2020. The first discussed weaknesses in proprietary languages used by industrial robots, while the second discussed vulnerabilities in protocol gateways.
Save to Folio
Last week, Trend Micro presented two important talks on IIoT vulnerabilities at Black Hat USA 2020. The first discussed weaknesses in proprietary languages used by industrial robots, while the second discussed vulnerabilities in protocol gateways. Any organization using robots, as well as any organization running a multi-vendor OT environment, should be aware of these attack surfaces. Here is a summary of the key points from each talk.
Rogue Automation
This was presented at Black Hat, on Wednesday, August 5. The presentation slides are at https://www.blackhat.com/us-20/briefings/schedule/index.html#otrazor-static-code-analysis-for-vulnerability-discovery-in-industrial-automation-scripts-19523.
Industrial robots contain powerful, fully capable computers. Unlike most contemporary computers, however, industrial robots lack basic information security capabilities. First, at the architectural level, they lack any mechanism to isolate certain instructions or memory. That is, any program can alter any piece of storage or run any instruction. In traditional mainframes, no application could access, change, or run any code in another application or operating system. Even smartphone operating systems have privilege separation. An application cannot access a smartphone’s camera, for instance, without being specifically permitted to do so. On the other hand, industrial robots allow any code to read, access, modify, or run any device connected to the system, including the clock. This eliminates data integrity in industrial robots and invalidates any audit of malfunctions. Debugging, as a result, becomes exceptionally difficult.
Industrial robots also do not use conventional programming languages, like C or Python. Instead, each manufacturer provides its own proprietary programming language. This means that a specialist using one industrial robot cannot use another vendor’s machine without training. Additionally, there are no common information security tools for code validation, since vendors do not develop products for fragmented markets. These languages describe programs that tell the robot how to move. The languages also support reading and writing data, analyzing and modifying files, opening and closing input/output devices, getting and sending information over a network, and accessing and changing status indicators on connected sensors. Once a program starts to run on an industrial robot, it can do anything that a fully functional computer can do, without any security controls at all. Notably, contemporary industrial robots do not have any countermeasures against this threat.
Most owners of industrial robots do not write their own programs. The supply chain for industrial robot programs, in fact, involves many third-party actors. Figure 1 illustrates a simplified diagram of a supply chain. In each community, users of a particular vendor’s languages share code informally and rely on user’s groups for hints and tips to solve common tasks. However, these forums rarely discuss security measures. Many organizations hire third-party contractors to implement particular processes, but there are no security certifications relevant to these proprietary languages. Most programmers, unfortunately, learned their trade in an air-gapped world and still rely on a perimeter which separates the safe users and code inside from the untrusted users and code outside. Furthermore, the languages offer no code scanners to identify potential weaknesses such as validating inputs, modifying system services, altering device state, or replacing system functions. These machines also lack a software asset management capability. As a result, it is difficult to learn where the components of a running program originated from.
Still, all is not quite lost. In the short term, Trend Micro Research has developed a static code analysis tool called OTRazor, which examines robotic code for unsafe code patterns. This was demonstrated during our session at Black Hat on Wednesday, August 5. The corresponding research paper is available at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/unveiling-the-hidden-risks-of-industrial-automation-programming.
Over time, vendors will have to introduce basic security checks such as authentication, authorization, data integrity, and data confidentiality. The vendors will also have to introduce architectural restrictions. For instance, an application should be able to read the clock but not change it. Similarly, applications should not be able to modify system files, programs, or data, nor should they be able to modify other applications. Nevertheless, these changes will take years to arrive in the market. Until then, CISOs should audit industrial robot programs for vulnerabilities, segment networks including industrial robots, and apply baseline security programs, as they do now, for both internally developed and procured software.
Protocol Gateway Vulnerabilities
This was presented at Black Hat, on Wednesday, August 5. The presentation slides are at https://www.blackhat.com/us-20/briefings/schedule/index.html#industrial-protocol-gateways-under-analysis-20632, while the corresponding research paper is available at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/lost-in-translation-when-industrial-protocol-translation-goes-wrong.
Industry 4.0 leverages the power of automation alongside the rich layer of software process control tools, particularly enterprise resource planning (ERP) and its bigger cousin, supply chain management (SCM). By bringing together dynamic industrial process control with hyper-efficient “just-in-time” resource scheduling, manufacturers can achieve minimum cost, minimum delay, and optimal production. However, these integration projects require that IIoT devices speak with other technology, including the IIoT from other manufacturers and legacy equipment. Since each equipment or device could have their own communication protocol, Industry 4.0 relies heavily on protocol converters.
Protocol converters are simple, highly efficient, low-cost devices that translate one protocol into another. Protocol converters are ubiquitous, but they lack any basic security capabilities — authentication, authorization, and data integrity or data confidentiality — and they sit right in the middle of the operational technology (OT) network. Attackers can subvert protocol converters to hijack communication or change configuration. An attacker can disable safety thresholds, generate a denial of service (DoS) attack, and misdirect an attached piece of equipment.
In the course of this research, we found nine vulnerabilities and are working with vendors to remediate these issues. Through our TXOne subsidiary, we are developing rules and intelligence specifically for IIoT message traffic, which are then embedded in our current network security offerings, providing administrators with better visibility and the ability to enforce security policies in their OT networks.
Protocol converters present a broad attack surface, as they have limited native information security capabilities. They don’t validate senders or receivers, nor do they scan or verify message contents. Due to their crucial position in the middle of the OT network, they are an exceptionally appealing target for malicious actors. Organizations using protocol converters — especially those on the way to Industry 4.0 — must address these weak but critical components of their evolving infrastructure.
What do you think? Let me know in the comments below or @WilliamMalikTM.