Siklu EtherHaul Unauthenticated Remote Command Execution Vulnerability (<7.4.0)

Siklu EtherHaul devices are vulnerable to a remote command execution (RCE) vulnerability. This vulnerability allows an attacker to execute commands and retrieve information such as usernames and plaintext passwords from the device with no authentication.

Siklu EtherHaul devices (wireless point-to-point radios) have a feature in the web interface that allows you to configure both radios in a pair from either side. In other words, you can log in to the tower-side radio and use that to configure the radio on the other end, and vice versa, assuming that that they already have a wireless connection established.

I was curious how they accomplished this, so I started my investigation just by running a quick port scan on one of ours, using nmap.

22 and 443 are for management, but 555 was a mystery to me.

Connecting to port 555 via telnet just closes the connection after a couple seconds, however, sometimes, if you repeatedly connect and hit enter a few times, it will eventually output a bunch of information about the signal level, formatted in XML.

The web interface on the EtherHauls will refresh the information displayed on the page, such as the signal level, every few seconds. Examining those requests in Chrome’s developer console reveals that they return the exact same XML that we saw when connecting via port 555. The web interface on the EtherHauls appears to connect to port 555 on both itself and the other radio in the pair in order to retrieve the information it displays in the web interface.

Further examination of these requests also revealed the command that was used to retrieve this particular information: “mo-info rf”. Performing other actions in the web interface revealed other commands as well. Entering these commands via telnet didn’t appear to do anything, so at this point, it became necessary to delve deeper to see exactly what the devices were saying to each other on port 555.

Using another vulnerability I found on the EtherHauls, I was able to log in as root and access a Linux shell. The EtherHauls have a tcpdump binary on them, which allowed me to record a packet capture of all traffic involving port 555 and see exactly what data was being sent between the devices.

Prior to the “mo-info rf” command being sent, the device making the request first “authenticates” by sending the username of whoever is logged in, surrounded by a lot of null bytes:

Immediately after the username is sent, the command goes out with only 1 null byte on the very end:

I tried following this same basic procedure in telnet, sending “admin” and then sending “mo-info rf”, but being unable to easily send the null bytes in telnet, I experienced mixed results. It appeared to work sometimes, but extremely inconsistently.

I threw together a script in Python that opens a socket on port 555 and sends the full payload, including all the null bytes, effectively pretending to be another EtherHaul. This worked perfectly, and I was consistently able to get the response I was expecting from the device.

While playing around with sending various commands to the EtherHauls, I found that one command actually retrieves the usernames and passwords from the device in plaintext. This command gets inconsistent results; sometimes it works, other times, the device will always return blanks for the password. However, you can also send a command that sets a new password on the admin user. Links to proof of concept exploits are at the bottom of the post.

Security concerns from this vulnerability:
Passwords are stored in plaintext on the device
The service running on port 555 authenticates the user using only the username. No password is required.
This service doesn’t implement any kind of ACL or firewall, meaning anyone on the internet can access it.

2016/12/22 – Vulnerability reported to Siklu
2016/12/22 – Initial response from Siklu
2016/12/25 – Siklu confirms the vulnerability and says they’re working on a patch
2017/02/13 – Siklu releases an update for all models but the EH-1200 and EH-1200TL (those two are EOL)
2017/02/20 – Publicly disclosed

Show username and password in plaintext:
Set password to “Abc123123″:

CVE ID: CVE-2017-7318

Show Comments