tl;dr: Siklu EtherHaul radios have a built-in, hidden root account, with an unchangeable password that is the same across all devices. This account is accessible via both ssh and the device’s web interface and grants access to the underlying embedded Linux OS on the device, allowing full control over it.
Before I start, some background info: Siklu is a company based out of Israel that produces wireless point-to-point radios. You basically buy two radios and point them at each other to establish a wireless network connection between the two, for connecting office buildings without having to pay anyone to lay fiber or something.
On December 2nd, 2015, I received an automated abuse report email stating that a device on my network (a Siklu EtherHaul) had participated in some attacks on someone else’s servers.
This was my first clue that there was something wrong with these devices internally. The CLI and web interface that I have seen on the EtherHaul is fairly locked down, so an attack of this nature originating from these devices should not have been possible, even if someone had somehow managed to use my administrator login to get into the device. My first guess was that Siklu had probably implemented a hidden backdoor on the devices for shell access, and that someone else had discovered this backdoor.
I reached out to Siklu, asking them if they were aware of any vulnerabilities that had yet to be patched in the EtherHaul devices. As it turned out, my device was several software versions behind, so there was already an update available. The Siklu rep I was emailing told me that the newest update fixed a vulnerability that bore similar symptoms to what my device was exhibiting, but would not get any more specific than that.
This spurred my curiosity, so I downloaded both software versions, the one I was currently on, and the newest update, and extracted them both. The software binaries are simply SquashFS images:
The SquashFS image begins at offset 131072, and there are no other images after it, so it’s easy to pull it out with dd:
dd if=SW_siklu-uimage-3.5.3-13654 bs=1 skip=131072 of=uimage.sqfs
After that, I used “unsquashfs” to extract the image to a regular directory tree, giving me access to all the files in the root mountpoint of the EtherHaul. I wonder if there is any sort of validation within the device to prevent it from being flashed with modified firmware, but I will explore that some other time.
I dove straight into /etc/shadow, the file containing the hashed passwords for the user accounts in Linux, and found that there are a total of four user accounts on the devices by default:
- admin (the standard login that you use to configure the device)
- root
- sshd
- emergency
I fed the shadow file to Jack the Ripper and let it run in the background while I continued to explore. My exploration didn’t last long though, as I ended up finding /etc/www/main/copy.bat, which contains the default root password in plaintext (it’s only 7 characters, lowercase alphanumeric, so it wouldn’t have taken John long to crack anyway).
I tested to see if this root account worked on any of my devices, and it does:
ianl@ianl-laptop:~$ ssh root@1.2.3.4 -p22
EH-<…>, S/N: <…>, Ver: 6.X.X
root@1.2.3.4’s password:
BusyBox v1.2.1 (2015.02.18-16:04+0000) Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
~ # id
uid=0(root) gid=0(root)
As shown above, it drops you directly into a BusyBox shell as root, giving you full control over the device. It also allows you to log in to the device’s web interface and make changes there.
John the Ripper did make quick work of the other two passwords; both are identical to the usernames:
- sshd:sshd
- emergency:emergency
Both of these logins allow you to access the web interface (but only with read permissions; you are not able to change any of the settings), but neither give ssh access. Attempting to log in to ssh using the ‘sshd’ user just closes the connection, while logging in as ‘emergency’ displays some Base64 before closing the connection. I have no idea what the Base64 is for, and decrypting it reveals nothing.
(censored parts of Base64 in case it contains anything private)
I disclosed this vulnerability to Siklu immediately after finding it, and they responded extremely quickly. I had several phone calls and emails back and forth with a representative, and the issue was forwarded to their R&D department on the same day. The representative kept me up-to-date with how they plan to fix it, and their timeline for getting an update out.
However, we have many of these devices deployed in production, and I did not want to leave these devices vulnerable to any attacks, so I asked if we could simply change the root password while we were waiting for a patch. I also mentioned in this email that I was a bit apprehensive about doing this because I guessed (correctly, it turns out) that this root password is used internally by the devices themselves and could brick them if it is changed. Siklu advised me not to change the password.
On 2016/02/04, more than two months after disclosure, Siklu released software version 6.9.0 for some Etherhaul models. There is no mention of this vulnerability in the patch notes, but the Siklu representative did confirm that this release contains a fix for this vulnerability:
The most concerning part though, is the bottom of the release notes, which states that this update is optional. There is no indication that this update fixes a major security vulnerability that affects all Etherhaul devices.
Another point of concern is that, as of the time this write-up is published (2016/06/02), an update has not been publicly released for the EH-1200/TL models, meaning that they are still vulnerable, 6 months after disclosure. If you have any Siklu Etherhaul devices in your network, you should ensure that they are up-to-date, and that they are not accessible on any public IP addresses.
CVE ID: CVE-2016-10308
UPDATE: Siklu released an update for the EH-1200/TL models on June 27th, 2016. The patch notes do contain information regarding the vulnerability this time.