rss-bridge 2024-05-30T11:19:55+00:00

Targeting an industrial protocol gateway

Inside industrial systems (also known as Operational Technology, or OT), devices communicate with each other and can be accessed over IP using familiar IT protocols (such as SSH, web services, etc.), as well as with a variety of industrial network protocols. Among them, you may have heard of Modbus, maybe S7comm, OPC-UA and a few others, but do you know all the industrial protocols you could find on industrial networks? It would take a lifetime to list them all, considering the field-specific standards, the manufacturer-dependent protocols and variations, the association-promoted specifications, and their numerous versions, layers, extensions and adaptations. In the end, an industrial process typically involves a collection of devices, servers and workstations that are likely to use many different protocols and still need to understand each other.

When devices don’t have any protocol in common to communicate, an additional component is required as a gateway to make the translation between protocols. From time to time, we encounter such gateways on industrial systems, but we barely see them as all they do is translate. However, these nearly invisible devices play a crucial role in the industrial process: if the translation stops, the communication between (part of) the devices involved in the process stops as well, which is critical in such environments.

From an attacker’s perspective, this means that targeting them may have significant consequences, and that their security must also be considered.

In light of that, I wanted to assess the security of a gateway model that I often encounter during penetration tests on OT: the Anybus X-Gateway from HMS networks. This device does the conversion from one protocol to another and has several models for several protocol translations. My target was the model AB7832-F, firmware version 3.29.01. I found several vulnerabilities reported as CVE-2024-23765, CVE-2024-23766 and CVE-2024-23767 that can be used to alter the configuration and make the device unavailable. In this article, I’ll go through the testing process and share the technical details of my findings and HMS’ responses.

Through the gateway

A device such as the Anybus X-Gateway AB7832-F is typically used in an industrial environment, usually located in closed cabinets in restricted areas, which reduces the likelihood of unauthorized physical access.

This particular model translates between Ethernet/IP over an IP link (although the IP in Ethernet/IP stands for Industrial Protocol but that’s another story) and Profibus over an RS-485 serial link.

Therefore, it is supposed to be connected to an IP network in an industrial system so that it can be configured and do what is needed: establish a link between devices that don’t speak the same language. In a perfect world, the gateway is reachable on the network only by authorized users and devices from restricted OT locations, but do we live in a perfect world?

To test our gateway, we mainly considered the scenario where an attacker can reach the gateway on the IP network, without physical access to it. This could happen, for instance, if the attacker is located on the OT network with direct access to the gateway or has managed to reach it from the IT network or from the Internet.

Without further waiting, let’s start talking to our gateway and see what we can do.

Network discovery

Although I read the manual and knew what the device did in theory, I did not know how it actually worked. Therefore, the first step was obviously to gather all the information I could, starting with UDP and TCP nmap scans.

Nmap scan report for boiboite (192.168.1.242)
PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Multitech MultiVoip 410 VoIP gateway ftpd
23/tcp    open  telnet        APC PDU/UPS devices or Windows CE telnetd
80/tcp    open  http          HMS Anybus-S WebServer
502/tcp   open  mbap?
7412/tcp  open  unknown
44818/tcp open  EtherNet-IP-2

Nmap scan report for boiboite (192.168.1.242)
PORT      STATE         SERVICE       VERSION
2222/udp  open|filtered msantipiracy
3250/udp  open|filtered hicp
7412/udp  open|filtered unknown
44818/udp open          EtherNet-IP-2

A few comments about these results:

We can see a few regular IT administration services on TCP: FTP, Telnet and HTTP. Not the most secure ones, if you ask me. I used all of them but is there anything left to say about their security? The only thing worth mentioning is that the Telnet service gives access to a very restricted shell.

Some ports correspond to industrial network services. The associated protocols have weaknesses on their own as well, but this exceeds the scope of this article:

Port 502/tcp is for Modbus TCP, which is widely used in OT and supported by the gateway;

Ports 44818/tcp, 44818/udp and 2222/udp are for Ethernet/IP, this is our entry point for protocol translation. I have not spent much time on this one yet but 44818/udp is uncommon, it could as well be something else and requires further investigation;

Port 3250/udp is used by the protocol HICP, which is the proprietary protocol used by HMS devices for IP network discovery and configuration. I took a good look at this one (see below);

Does anyone recognise port 7412?

Port 7412 and CVE-2024-23765

When encountering an unknown TCP service running on an unusual port, there are a few ways to find out what it is:

Try to communicate with the service using various protocols (or by sending random junk) and deduce the protocol from the service’s responses;

Find what the port number is usually bound to on the Internet;

Look for the answer in the device’s documentation;

Ask the manufacturer directly.

As for port 7412, I tried all four ways: the service never responded to my requests, this port does not seem to be the standard port for any service, the documentation does not say a word about it and the technical support from HMS Networks told me that it had no idea either (really?).

*N.B.: Yours truly has a great passion for searching for (and finding) obscure industrial protocols and has recently encountered port 7412 again. She now has new clues and is back to investigate! In the meantime, please share any information you have with your local police district (or myself).*

Ultimately, there was no need to know what it was to make the device crash. After a few attempts at sending requests on port 7412, expecting responses from the service to identify it, the device stopped working. In fact, it appeared that all the network services of the gateway systematically become unresponsive after sending 85 requests to this port. The content and length of the frame sent to the device does not matter. The vulnerability was reported as CVE-2024-23765.

from scapy.all import *
target = IP(dst="192.168.1.242")/UDP(dport=7412, sport=50000)
pkt = target/Raw(b"\x00")
for i in range(85):
send(pkt)

[...]

Original source