Flaws in industrial wireless IoT solutions can give attackers deep access into OT networks

It’s common for operational technology (OT) teams to connect industrial control systems (ICS) to remote control and monitoring centers via wireless and cellular solutions that sometimes come with vendor-run, cloud-based management interfaces. These connectivity solutions, also referred to as industrial wireless IoT devices, increase the attack surface of OT networks and can provide remote attackers with a shortcut into previously segmented network segments that contain critical controllers.

Industrial cybersecurity firm Otorio released a report this week highlighting the attack vectors these devices are susceptible to along with vulnerabilities the company’s researchers found in several such products. “Industrial wireless IoT devices and their cloud-based management platforms are attractive targets to attackers looking for an initial foothold in industrial environments,” the Otorio researchers said in their report. “This is due to the minimal requirements for exploitation and potential impact.”

A shift in traditional OT network architecture

OT security has generally followed the Purdue Enterprise Reference Architecture (PERA) model to decide where to place strong access control layers and do segmentation. This model, which dates to the 1990s, splits enterprise IT and OT networks into six functional levels.

Level 0 is the equipment that directly influences physical processes and includes things like valves, motors, actuators, and sensors.

Level 1 or the Basic Control layer includes field controllers such as programmable logic controllers (PLCs) and remote terminal units (RTUs) that control those sensors, valves, and actuators based on logic (programs) uploaded to them by engineers.

Level 2 is the supervisory control layer which includes supervisory control and data acquisition (SCADA) systems that collect and act upon the data received from the Level 1 controllers.

Level 3 is the site control layer and includes systems that directly support a plant’s operations such as database servers, application servers, human-machine interfaces, engineering workstations that are used to program field controllers and more. This is typically referred to as the Control Center and connected to an organization’s general IT enterprise network (Level 4) through a demilitarized zone (DMZ).

It is in this DMZ where organizations have focused their perimeter security efforts to have a strong segmentation between the IT and OT parts of their networks. Additional controls are typically put in place between Level 3 and Level 2, to protect field devices from intrusions into the control centers.

However, some organizations can have remote industrial installations that they need to connect to their central control centers. This is more common in industries such as gas and oil where operators have multiple oil fields and gas wells in exploitation at different locations, but it’s also prevalent in other industries. These links between remote Level 0-2 devices and Level 3 control systems are often provided by industrial cellular gateways or industrial Wi-Fi access points.

These industrial wireless IoT devices can speak to field devices over multiple protocols, such as Modbus and DNP3, and then connect back to the organization’s control center through the internet by using various secure communication mechanisms like VPN. Many device manufacturers also provide cloud-based management interfaces for industrial asset owners to manage their devices remotely.

Vulnerabilities in industrial wireless IoT devices

These, like any other devices connected to the internet, increase the attack surface of OT networks and weaken the security controls traditionally put in place by organizations, offering a bypass for attackers into the lower levels of OT networks. “Utilizing search engines such as Shodan, we have observed widespread exposure of industrial cellular gateways and routers, making them easily discoverable and potentially vulnerable to exploitation by threat actors,” the Otorio researchers said in their report. Some of their findings regarding devices with internet-reachable web servers and interfaces include:

The researchers claim they found 24 vulnerabilities in the web-based interfaces of devices from three of these vendors — Sierra, InHand, and ETIC — and managed to achieve remote code execution on all three.

While many of these flaws are still in the process of responsible disclosure, one that has already been patched impacts Sierra Wireless AirLink routers and is tracked CVE-2022-46649. This is a command injection vulnerability in the IP logging feature of ACEManager, the web-based management interface of the router, and is a variation of another flaw found by researchers from Talos in 2018 and tracked as CVE-2018-4061.

It turns out that the filtering put in place by Sierra to address CVE-2018-4061 did not cover all exploit scenarios and researchers from Otorio were able to bypass it. In CVE-2018-4061, attackers could attach additional shell commands to the tcpdump command executed by the ACEManager iplogging.cgi script by using the -z flag. This flag is supported by the command-line tcpdump utility and is used to pass so-called postrotate commands. Sierra fixed it by enforcing a filter that removes any -z flag from the command passed to the iplogging script if it’s followed by a space, tab, form feed or vertical tab after it, which would block, for example, “tcpdump -z reboot”.

What they missed according to Otorio is that the -z flag doesn’t require any of those characters after it and a command like “tcpdump -zreboot”, would execute just fine and bypass the filtering. This bypass alone would still limit the attackers to executing binary files that already exist on the device, so the researchers developed a way to hide their payload in a PCAP (package capture) file uploaded to the device via another ACEManager feature called iplogging_upload.cgi. This specifically crafted PCAP file can also behave as a shell script when parsed by sh (the shell interpreter) and its parsing and execution can be triggered by using the -z vulnerability in iplogging.cgi.

Cloud management risks

Even if these devices don’t expose their web-based management interfaces directly to the internet, which is not a secure deployment practice, they would not be completely unreachable to remote attackers. That’s because most vendors provide cloud-based management platforms that allow device owners to perform configuration changes, firmware updates, device reboots, tunnel traffic over the devices, and more.

The devices typically communicate with these cloud management services using machine-to-machine (M2M) protocols, such as MQTT, and their implementation could have weaknesses. The Otorio researchers found critical vulnerabilities in the cloud platforms of three vendors, allowing attackers to compromise any cloud-managed devices remotely without authentication.

“By targeting a single vendor cloud-based management platform, a remote attacker may expose thousands of devices located on different networks and sectors,” the researchers said. “The attack surface over the cloud management platform is wide. It includes exploitation of the web application (cloud user interface), abusing M2M protocols, weak access control policies, or abusing a weak registration process.”

The researchers exemplify these risks with a chain of three vulnerabilities they found in the “Device Manager” cloud platform of InHand Networks and the firmware of its InRouter devices that could have resulted in remote code execution with root privileges on all cloud-managed InRouter devices.

First, they looked at the way in which devices talk to the platform via MQTT and the way authentication, or “registration,” is achieved and they found that the registration uses insufficiently random values and can be brute-forced. In other words, two of the vulnerabilities allowed the researchers to force a router to provide its configuration file by impersonating an authenticated connection and write tasks to the router such as changing its hostname.

The third vulnerability was in the way the router parsed configuration files via MQTT, particularly in the function used to parse parameters for a feature called auto_ping. The researchers found they could enable auto_ping and then concatenate a reverse shell command line to the auto_ping_dst function and this would execute with root privileges on the device.

Wireless attacks on OT networks

In addition to the remote attack vectors available over the internet, these devices also expose Wi-Fi and cellular signals locally so any attacks over these technologies could be used against them. “Different types of local attacks can be used against Wi-Fi and cellular communication channels, starting from attacks on weak encryptions such as WEP and downgrade attacks to the vulnerable GPRS, all the way to complex chipset vulnerabilities that may take time to patch,” the researchers said.

While the researchers didn’t investigate Wi-Fi or cellular baseband modem vulnerabilities, they performed reconnaissance using WiGLE, a public wireless network mapping service that collects information about wireless access points worldwide. “Leveraging the advanced filtering options, we wrote a Python script scanning for potentially high-value industrial or critical infrastructure environments, highlighting ones configured with weak encryption,” the researchers said. “Our scanning uncovered thousands of wireless devices related to industrial and critical infrastructure, with hundreds configured with publicly known weak encryptions.”

Using this technique, the researchers managed to find devices with weak wireless encryption deployed in the real world in manufacturing plants, oil fields, electrical substations, and water treatment facilities. Attackers could use such reconnaissance to identify weak devices and then travel on site to exploit them.

Mitigating wireless IoT device vulnerabilities

While patching vulnerabilities in such devices when they’re found is critically important because of their privileged position in OT networks and direct access to critical controllers, additional preventive steps should be taken to mitigate risks. The Otorio researchers have the following recommendations:

• Disable and avoid any insecure encryptions (WEP, WAP) and when possible, do not allow legacy protocols such as GPRS.
• Hide your networks names (SSID).
• Use MAC-based whitelisting, or use certificates, for connected devices.
• Validate management services are limited to the LAN interface only or are IP whitelisted.
• Ensure no default credentials are in use.
• Be alert on new security updates for your devices.
• Verify these services are disabled if unused (enabled by default on many cases).
• Implement security solutions separately (VPN, firewalls), treating traffic from the IIoT as untrusted.