Claroty’s Team82 finds path-traversal vulnerability in ABB TotalFlow flow computers and controllers
Claroty’s research arm Team82 disclosed on Tuesday details on a path-traversal vulnerability in ABB TotalFlow flow computers and remote controllers used across oil and gas organizations, which can be exploited by an attacker to inject and execute arbitrary code. The vulnerability can enable an attacker to take over the flow computers and remotely disrupt the flow computers’ ability to accurately measure oil and gas flow. These specialized computers are used to calculate these measurements that are used as inputs in a number of functions, including configurations and customer billing.
“A successful exploit of this issue could impede a company’s ability to bill customers, forcing a disruption of services, similar to the consequences suffered by Colonial Pipeline following its 2021 ransomware attack,” Vera Mens, a Claroty security researcher, wrote in a company blog post.
Mens adds that Team82 focused on ABB flow computers because of their use within many large oil and gas utilities worldwide. “We looked for vulnerabilities that could give an attacker the ability to influence measurements by remotely running code of their choice on the device. As a result, Team82 found a high-severity path-traversal vulnerability (CVE-2022-0902) in ABB’s TotalFlow flow computers and remote controllers. Attackers can exploit this flaw to gain root access on an ABB flow computer, read and write files, and remotely execute code,” she adds.
Affected products include ABB’s RMC-100 (Standard), RMC-100-LITE, XIO, XFCG5, XRCG5, uFLOG5 and UDC products. ABB has made a firmware update available that resolves the vulnerability in a number of product versions; it also recommends network segmentation as mitigation.
Flow computers are specialized computers that calculate volume and flow rates for oil and gas that are critical to electric power manufacturing and distribution. These machines take liquid or gas measurements that are vital to process safety but are also used as inputs by other processes, thus requiring accuracy to ensure reliability.
“One other important aspect to the role of flow computers within a utility is billing,” according to Mens. “The most noteworthy and related security incident was the ransomware attack against Colonial Pipeline, which impacted enterprise systems, and forced the company to shut down production because it could not bill customers. Disrupting the operation of flow computers is a subtle attack vector that could similarly impact not only IT, but also OT systems; this led us to research the security of these machines,” she adds.
The target of Team82’s research was ABB’s µFLO G5 flow computers, which can receive raw sensor data from other flow meters, perform flow calculations (following the AGA and ISO standards), and show/propagate the output, Mens said. “The µFLO G5 is a single board computer with IO ports (Ethernet, USB, etc.), CPU, and other peripherals. The CPU is an ARMv8 processor, which is a 32-bit architecture. The device runs Linux as an operating system, which was good news for us, because this increased our chances to emulate the device in the lab,” she adds.
From a security perspective, the µFLO G5 features three main mechanisms – security switch: a physical switch attached to the board that will enable/disable the use of the security passcode; security passcode: two four-digit passcodes; one for reading data, and another authorizing writing of data; and RBAC (role-based access control) which assigns roles and permission to read and write specific attributes, and can be implemented only on the client side.
Mens explained that the flow computer could be remotely configured with a designated configuration program. “The interesting thing to note is that configuration is done via a proprietary protocol designed by the ABB called TotalFlow. This protocol can be used on top of a serial or Ethernet (TCP) connection. Most of the communication between the client and the device—retrieval of the gas flow calculations, set and get device settings, import, and export of the configuration files—is done over the TotalFlow protocol (TCP/9999),” she adds.
“Our goal in this research is to achieve remote code execution on the device. The proprietary protocol seemed to be a good attack vector to start with because undocumented protocols are usually less reviewed by security researchers,” according to Mens.
As Team82 began the examination of the proprietary TotalFlow protocol, it knew that TotalFlow is used to configure the device and send the flow measurements to the client, and it listens on TCP port 9999.
“Our goal is to be able to send and receive messages of our choice to test the implementation of the protocol,” Mens said. “For this, we need to understand the protocol structure and build a simple client that constructs the payload. Luckily for us, the firmware is available online and is not encrypted, therefore we could easily extract it in order to analyze the application.”
She added that first, they wanted to find the binary that implements the protocol. “Often the implementation of the protocol will reside at the main executable file or one that is directly linked to it. Because our target is a Linux-based embedded device, the main binary will be executed at system’s init.”
The init revealed the name of the binary: devLoader[dot]exe, which allowed Team82 to reverse engineer it, Mens revealed. “The binaries within the firmware were stripped, but we had a lot of error-related logging strings, below, which was great for our research because it makes our life easier in finding interesting functions.”
Team82 created a device setup so it could dynamically debug it by emulating a flow computer on RaspberryPI.
However, Mens pointed out that “the main disadvantage of emulating the device is that at some point the application will want to communicate with peripherals. Unfortunately, our Raspberry Pi doesn’t have orifice plates attached to it, so any communication with them needs to be patched (changed within the binary).”
Using the working setup, Team82 was ready to analyze communication between the device and the client application. With a debugger, “we can stop at the interesting functions that we have found by reverse engineering the binary and completing our understanding of the protocol,” Mens said. “Since the device sends an error message on incorrect code and there is no rate limit mitigation available on the device, we can easily bypass the authentication mechanism by enumerating all possibilities,” she adds.
“Now that we have an authentication bypass, it is time to look at functionalities available to authenticated users,” Mens said. “Remember we said the configuration can be uploaded and downloaded? This is a good place to look for bugs because file operations are not always done securely.”
Mens adds that now “that we have an arbitrary read and write, it is simple to get code execution. We chose the simplest approach, reading /etc/shad0w and using hashcat cracking the root account password (which turned out to be root:root). Then we changed the SSH configuration file to enable root to connect using password. Then all that was left to do was to turn on the SSH daemon (using the TotalFlow protocol) and to connect to it.”
Last month, Team82 detailed a new method to extract heavily guarded, hardcoded, global private cryptographic keys embedded within the Siemens SIMATIC S7-1200/1500 PLC and TIA Portal product lines.
Related
