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-2A 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)As you can imagine, this can be leveraged by an attacker to stop network flows to and from affected devices. As critical operational network flows transit through these gateways, their failure could interrupt such operations. A physical restart is required to restore the device, but such operation may be difficult in industrial facilities as the device may not be reachable physically. Also, there is no power button, so it requires disconnecting it from the power supply.
According to HMS networks, the bug comes from the physical components of the gateway, which means that there can be no patch to fix this vulnerability, the only solution is to replace the device.
The root of the problem is related to how the product is designed, i.e. it uses a mainboard and daughter cards. The mainboard uses the API of the daughter cards to create TCP and UDP services on port 7412. Unfortunately the implementation on the mainboard isn’t resilient against malformed packets, thus in the end this will starve the daughter card and it will run out of resources and make all other services on the daughter card unresponsive.
Let’s just use features (CVE-2024-23766)
At that point, we still don’t know what port 7412 is but at least we know how to misuse it. We can try to misuse other services, where the word “misuse” can have two meanings: either we make the device do what it is not supposed to do, or we make it do what it is supposed to do, but not in the intended way.
The gateway exposes the service HTTP to provide a web interface for network configuration and network diagnostics.
Fun fact: this interface does not require any authentication. Accessing it, we could mess with the network configuration and make it unreachable. But we can go further: when browsing the filesystem, I noticed (among others) a file called reboot.html, which is not used/callable in the web interface. Sending a get request to the URL http://<ip>/slave/reboot.html immediately reboots the gateway. Therefore, we could also use the reboot feature to carry out a denial-of-service attack by continuously sending unauthenticated GET requests to the associated URL. This vulnerability was reported as CVE-2024-23766.
if len(argv) != 2:
print("Usage: {0} ip_address".format(argv[0]))
exit(-1)
url = "http://{0}/slave/reboot.html".format(argv[1])
timeout = 30
print("Keep on sending GET requests to {0}".format(url))
while True:
try:
res = request.urlopen(url, timeout=timeout)
except ConnectionResetError:
passOnce again, this vulnerability can be used to stop the network flows to and from the device as it becomes completely unavailable. No need to investigate the cause, as what is going on is pretty obvious: it is a legitimate feature (but not meant to be called by the user) and it is not protected.
How to resume operation when this attack is ongoing? The easiest way would probably be to isolate the device on the network (it’s already down anyway) to prevent it from boot looping. Then, to prevent such an attack, the obvious thing to do would be to stop the HTTP service from the device’s settings, but this gateway does not allow disabling services. Alternatively, one must restrict access to this service using network segmentation and filtering rules. Another option is to remove the reboot.html page from the filesystem using the FTP service and hope that there will be no side effect.
However, as the web interface can be used to change the network settings anonymously, we can also alter the regular network flows, possibly preventing a process from running correctly and therefore achieving the same result with less effort.
Wait… HICP ?? (CVE-2024-23767)
The web interface is not the only way to change the network configuration. When we follow the installation process, HMS Networks recommends using their tools (e.g. IPConfig) to find HMS devices on the network and to configure them.
Capturing the traffic while using it, we observe that the requests are being sent to the port 3250/udp that we saw previously, using the protocol HICP. This is a proprietary protocol by HMS Networks primarily intended for devices’ IP network configuration. It is unencrypted, and supports authentication by setting a password, but authentication is disabled by default (by the way, I have never seen it enabled in real life). This means, at least, that:
- Unauthenticated users can change the network settings (same behavior as with the web interface) by sending legitimate requests to the device using the tools provided by HMS;
- Attackers can enable authentication with their own password, preventing legitimate users from changing the settings back.
Let’s make a proof of concept! To do this, we just send valid HICP requests to the device. Using the provided tools is enough, but I wanted to write an implementation of the protocol that can be used for further attacks (for instance, to write a fuzzer). We can see from the capture below that the protocol is text-based, quite straightforward and has few features and therefore few frames to implement, although sometimes the format is inconsistent between frames.
I used the amazing Scapy framework to write the implementation and HICP is now available as a layer in Scapy’s latest versions. We can now use it to write a script that can change the configuration, and even set a password if we want. The complete PoC is available on GitHub.
Once again, we can misuse legitimate features, essentially because they lack security measures. In addition to this, we can mention that, even when authentication is enabled by legitimate users:
- As the password is sent in clear text with every request, it could be eavesdropped;
- There is no password policy, we can set a weak password such as ‘a’;
- The service is not protected against bruteforce attacks to discover the password (PoC).
And of course, the authentication on HICP can be bypassed as the web interface also provides a feature to change the network settings, which remains unauthenticated, even when a password is set using HICP.
As you can see, the protocol itself can be considered vulnerable and all these issues have been reported as CVE-2024-23767. This one is also very hard to fix, as it requires a complete review of the protocol’s fundamentals. That is why HMS Networks developed the protocol SHICP, where S stands for Secure, to replace HICP. Since it is not supported by my test device, I am not able to review this new protocol.
Remediation
Disable the planet?
These three vulnerabilities rely on three different network services that should not interfere with the device’s primary usage (HTTP, HICP, and probably port 7412?). Therefore, the first remediation we could think of is to disable the services that are not in use, especially if they are vulnerable.
However, the device does not provide an easy way to disable any of the services and HMS Networks’ support confirmed that they can’t be disabled. To restrict access to them, the quickest way is to do it on the network, using segmentation rules, possibly combined with threat detection.
This prevents access to the vulnerable components but does not fix the vulnerabilities themselves, which would at least require to implement the means to disable services from the settings, remove the reboot feature, enable HICP authentication by default and ultimately use a more secure protocol.
Measures taken by HMS Networks
HMS Networks has a well-defined vulnerability disclosure process, it is easy to contact them. They also gave me regular updates on the actions taken in response to the publication, which is appreciated.
Here is what they decided as a countermeasure: As there is a newer version of this Anybus device (ABC4014-A), the vulnerabilities for this model will not be patched. To address the vulnerabilities, they published a document with guidelines on how to ensure the security of the gateway, published here.
According to them, this new model (which I haven’t tested) is not affected by these three vulnerabilities:
- Denial of service on port 7412: The new version uses a completely different hardware and firmware and does not implement the same services on port 7412, therefore the attack is not supposed to work;
- Reboot feature on web service: This unauthenticated URL endpoint is apparently not exposed, I have been told that the web service is the only service that can be disabled in this new version;
- HICP protocol: The new version only supports SHICP, not HICP;
This decision is quite understandable, especially considering that CVE-2024-23765 cannot be patched without replacing the hardware and that CVE-2024-23767 requires replacing the main protocol used for configuration (which has already be done in newer versions). Nevertheless, there are a few things we can discuss.
First, a remediation which consists the replacement of devices to enhance cybersecurity is difficult to accept, especially considering that devices are likely to stay longer and to be more difficult to replace in OT than in IT (and they are expensive). Of course, updating devices in industrial systems is also very difficult, but maybe a little less so.
Secondly, there are many versions of the same Anybus X-Gateway for different translations. My model appears to have a newer version, but this is not true for all models. HMS Networks confirmed that the other “old” models use the same hardware and firmware as the one I tested (e.g. AB7956, CC-Link IE Field Slave – EtherNet/IP Adapter) and that some of them won’t be replaced by the new versions. This means that we will continue to see in industrial systems the Anybus X-Gateway product line prone to these critical vulnerabilities for a long time.
There will be some versions that won’t be replaced by the new versions. All the old products are based on a platform that doesn’t have the capabilities to defend against most vulnerabilities, even after updates. For the old products that we will keep and sell, precautions must be taken when installing the product, we will provide guidance in user manuals.
Finally, the guideline warns about the security of devices interconnected, the device’s physical security, the security of stored data and shows where the gateway must be in a state-of-the-art network architecture, but it does not say anything about network segmentation itself. Yet, it seems to me that the first recommendation we can make, given that we cannot patch or harden the device, is to restrict as much as possible the logical access to these devices from the network.
Wrap up
You may have noticed from this article that not all cybersecurity issues related to this device have been published as CVE. Indeed, this model shares the same issues as many industrial devices, as it was not designed with cybersecurity in mind. I could have submitted a vulnerability for the use of insecure IT protocols, one for lack of authentication on the web interface, another for clear-text passwords in the filesystem (I have not mentioned these yet), more for buggy features on the web interface, and so on. But I chose to focus on vulnerabilities that I consider worth talking about.
All three vulnerabilities were reported because they can be used to conduct trivial remote attacks to make the device unavailable in industrial environments where availability is critical most of the time:
- One of the CVE causes crashes, another allows a very simple Denial of Service attack, and two of them can be used to legitimately change the configuration anonymously, which is already enough;
- They do not require a high level of knowledge to make use of them;
- They are very easy to uncover, by anyone, as they are all based on the regular usage of legitimate features.
Moreover, devices such as this one make easy targets: a gateway is a component that is not directly part of the production process and that is likely to be left aside (sometimes even forgotten!) by the maintenance team. This means that it may not be considered for cybersecurity hardening (and it does not provide any features for hardening), and that an attack targeting it may be difficult to investigate if no one knows that this component is a target.
At first, I wanted to test this device to find exploitable flaws in the implementation of industrial network protocols. As I made a short stop at these three vulnerabilities, I haven’t done this part yet, and this is my next step. But so far, we don’t even need that to do damage.
Timeline
- July-August 2023: Tests performed.
- 2023-09-25: Vulnerability reports sent to HMS Networks.
- 2023-09-27 : Acknowledgement.
- 2023-10-12 : Notice from HMS Networks: As the gateway AB7832-F replaced by new product ABC4014-A, the mitigation will only consist on a manual supplement to clarify how AB7832-F shall be used to ensure security.
- 2024-01-25 : CVE-2024-23765, CVE-2024-23766, CVE-2024-23767 registered.
- 2024-02-27 : Document “Anybus Gateway Cybersecurity Guidelines” published on HMS networks.
- 2024-06-25 : Technical disclosure.
Special thanks to Fredrik Brynolf (HMS Networks) and Jean-Pascal Thomas (Orange Cyberdefense)