We've had no issues with it up 'til a couple weeks ago, when we noticed that the door on the detergent dispenser no longer opened automatically during the wash cycle.

The detergent dispenser looks like this:

To run a load, you put some soap into both compartments and close the lid. Soap in the pre-wash compartment trickles out through the plastic grate while soap in the main wash area remains sealed in. At some point – about 15-20 minutes later in our dishwasher – the lid swings open, releasing the soap from the main wash compartment. Or, at least, it used to.

The lid could still be operated manually; I could close it and it would latch, and then I could unlatch it using the little grey latch and the spring in the hinge would force it to fling open. Since there didn't appear to be any mechanical issues with the door, this pointed to an issue with the electronics controlling the dispenser.

Upon opening up the main body of the dishwasher, one issue became immediately apparent.

This mechanism is the actuator that automatically releases the latch on the soap dispenser. The burnt out white thing is a normally closed solenoid. When turned on, the solenoid generates a magnetic field, which pulls on a small metal rod (visible in the center of the spring in the second photo), compressing the spring and pulling that plastic hook arm thing in the counter-clockwise direction. That hook is connected to the latch on the front of the soap dispenser, so when this hook moves, it unlatches the lid. When the solenoid is turned off, the magnetic field goes away, allowing the spring to expand so that the soap dispenser is able to latch again next time you want to run the dishwasher.

In case that orange-brown color wasn't enough of a clue that the solenoid is dead, you can also measure the electrical resistance using a multimeter in ohms mode. Based on my research, it seems like 200-400 ohms is a common range for a working detergent dispenser solenoid. My multimeter wouldn't give me a resistance value at all, meaning something inside the solenoid had been destroyed so there was no longer electrical continuity. It was definitely broken.

I needed a replacement solenoid, but how could I find one in exactly the same size? There's some text on the front of the solenoid:

Searching for the 91413.03 part ended up being the key. I'm not sure what the 2801811 part means. I could only find used solenoids pulled from other dishwashers, no brand new ones, so I ended up buying one on eBay for $20.

I ran the dishwasher again after installing it, but the soap dispenser door still didn't pop open during the wash cycle. There must be something else wrong. There are two brown wires coming off of the solenoid that lead back to the main control board.

Along the bottom of the control board you can see a connector labeled BROWN with two terminals labeled DISP:

This is where those two brown wires lead to. One of the two wires simply connects to power. The other one leads into a triac (labeled TR4 in the image above).

A triac is basically a high voltage switch that connects two spots on the circuit board when it receives a signal from a third, separate spot. You can think of it like a circuit breaker or a relay, except, unlike either of those, it's a solid-state semiconductor, so there are no moving parts.

In this case, the triac is used to make or break the circuit that allows power to flow to the solenoid. When the triac is triggered, the solenoid's power circuit is complete and power flows through the solenoid, unlatching the soap dispenser lid and releasing the soap.

Eagle-eyed readers may be able to make out that TR4 in the image above has, unfortunately, exploded.

Thankfully, these triacs are off-the-shelf parts (part number 0107NA) you can buy online from any electronic components distributor (e.g. Mouser, DigiKey).

In my haste to fix the problem and get our dishwasher back in working order, I ended up purchasing a replacement from Amazon, because it was cheapest and had overnight shipping. The only catch was that pins 2 and 3 were swapped on the new triac, but I didn't let that dissuade me.

Unfortunately, after assembling the dishwasher again, the soap dispenser still wasn't working. Rather than looking for other problems, I started getting self-conscious that my Amazon triac, a BTA16-600B, may not have been the correct choice due to a minor difference in the datasheets, so I ended up ordering an exact replacement 0107NA from Mouser instead.

That's better! However, the dishwasher still didn't work after this.

I followed the trace leading up out of the first leg of the triac to figure out what other components were left to rule out. All that was left was what appears to be a big SMD microcontroller and one resistor. I figured the microcontroller was probably fine, since literally everything besides this soap dispenser seemed to be working, so that just left the resistor.

My multimeter would not give a reading for this resistor's resistance, even after removing it from the circuit board, while the two next to it both correctly read as 220 ohms, so this resistor was definitely dead!

I don't have any SMD components on hand, but I do have plenty of regular old resistors.

The new resistor obviously sits a little taller than the one it replaced, but the plastic enclosure that holds the control board in place still gives the new resistor enough clearance that it isn't touching anything.

To everyone's surprise, the soap dispenser works now. Our dishes are clean again!

In hindsight, I'm curious if the triac I bought from Amazon would have worked fine had I found and replaced the dead resistor.

Just goes to show that it never hurts to open something up and try to diagnose the problem yourself before you pay to have someone else look at it or throw it away. Sometimes, the parts that went bad are easy to spot and source replacements for.

It's also an opportunity to exercise my problem-solving muscle and potentially learn something new about the inner workings of an everyday machine that I often take for granted. Challenging our collective acceptance of planned obsolescence is a nice bonus too.

Most complex things are actually just made up of a bunch of pretty simple things connected together, and, with a little research, can be broken down into digestible, bite-size chunks. Buying into the idea that anything technical is too complicated for "laypeople" to understand only serves corporations, who are eager for you to give up and hand them $700 for a brand new thing that shoots hot water and soap at your dishes. They'll even haul your old one away to the landfill so you don't have to think about that part.

The first step I took to block the ads was installing Pi-hole in a Docker container on one of the Linux boxes on our network. Pi-hole's main purpose is to block ads by blackholing the DNS records of known advertising and tracking hosts. You can subscribe to enormous blocklists using Pi-hole's web interface to effectively prevent any devices on your network from communicating with any of these hosts.

You can use Pi-hole to block Youtube ads, but I found that Youtube videos are served from the same hosts that serve the ads, so using a Pi-hole to block the ads also prevents you from viewing any of the videos you want to see.

If Youtube ads are served from the same hosts as the videos, I figured there must be some way to differentiate between the two. To try to determine what these differences are, I checked the HTTP requests my browser makes when trying to load a Youtube video and compared those to the requests made when loading ads.

These two types of requests appear very similar at first glance, but there are some differences.

After comparing the requests from a bunch of different videos and ads, I found that requests for ads consistently contained the URL parameter "ctier=L", and the initial requests for any video contained the parameter "aitags". The value of "aitags" varied, but it was always present.

This ended up being the only thing I needed to programmatically determine whether or not a request was for an ad or a normal video. To verify, I loaded up mitmproxy to create a man-in-the-middle proxy. mitmproxy sits in between your client (e.g. your TV) and the server (Youtube) and gives you full visibility and control over all of the data sent between them. I can see and modify anything that the client sends to Youtube, and vice versa.

I initially tested the mitmproxy ad blocker using my laptop, just by setting Firefox to send all requests through the proxy.

Then I could see requests from my browser appearing in mitmproxy.

I utilized mitmproxy's scripting engine to perform the actual content matching and request blocking. mitmproxy allows you to write scripts that can interact with every request that goes through the proxy. You can view every detail of the request and alter the response in any way you please.

My script verifies the following things about a request before deciding to block it:

• .googlevideo.com is in the URL
• /videoplayback is in the URL
• aitags appears in the URL parameters
• ctier=L appears in the URL parameters

from mitmproxy import http, ctx


def request(flow: http.HTTPFlow) -> None:
    if ".googlevideo.com" in flow.request.pretty_url and \
       "/videoplayback" in flow.request.path and \
       "aitags" in flow.request.query and \
       flow.request.query.get("ctier", None) == "L":
            # we found an ad, return dummy response
            ctx.log.info("***INTERCEPTING***")
            flow.response = http.HTTPResponse.make(
                200,  # status code
                b"BLOCKED",  # content
                {"Content-Type": "text/html"}  # headers
            )

It works! When I visited a Youtube video without an adblocker enabled in my browser, the video appeared to buffer for a few extra seconds while Youtube tried and failed to load in ads, and ultimately just loaded the video without playing any ads.

The log message from the script also appeared in the mitmproxy window, indicating that it decided to block an ad request.

The next step was to get my TV sending requests through the proxy server. Unfortunately, Roku devices give users very limited access to network settings, so you can't even set a static IP address, let alone force the use of an HTTP proxy.

Luckily, mitmproxy also features a transparent proxy mode. This mode allows mitmproxy to receive normal HTTP/HTTPS requests as though it was an ordinary web server. The mitmproxy documentation contains instructions for setting up a Linux system to act as a transparent proxy: https://docs.mitmproxy.org/stable/howto-transparent/

As mentioned in those instructions, in order to get requests flowing through my transparent mitmproxy, I had to make the Linux host the target device's default gateway. On many other systems, this would've been a trivial settings change, but due to the restricted nature of the Roku TV, I had to make this change elsewhere.

My Roku TV receives its IP address and default gateway from my network's DHCP server, which is running on an Ubiquiti EdgeRouter Lite. To change my Roku TV's default gateway, I gave the TV a static DHCP mapping from the router's web interface. Then, from the router's CLI, I can assign that mapping a different default gateway than the rest of the devices on the network:

configure
edit service dhcp-server LAN1 DHCP subnet 192.168.0.0/24
set static-mapping ROKU-TV static-mapping-parameters "option router 192.168.0.105;"
commit; save

Now, after power cycling the TV, I can see in the settings menu that it receives a default gateway of 192.168.0.105, instead of my router's IP. This means that all traffic from my TV goes directly to my Linux machine instead of the Ubiquiti router. Now, HTTP and HTTPS requests made by the TV should appear in my mitmproxy window.

Interestingly, when powering on the TV and moving through the menus, I can see it make many unencrypted HTTP requests to various servers to download background images for the main screen, fonts, and layout information in XML format.

Unfortunately, although the Youtube app on my Roku TV does use HTTPS, they seem to have properly implemented certificate validation checks. This means that while my proxy setup functioned properly, the Youtube app on the Roku TV noticed that mitmproxy identified itself with an invalid certificate, so it aborts the connection.

There are a few other attack vectors I'm interested in exploring.

• Hardware-based attacks, such as physically opening the TV and looking for flash chips to dump. This is our only TV though, and I don't want to break it. It looks like people are selling replacement boards from inside the TV for ~$20 on eBay, so maybe I'll pick one of those up. Looking at the board images from the FCC filing, it looks like they used an MStar ARM SoC and a Realtek RTL8812BU based wifi module. There are a few headers on the board that look interesting, but nothing immediately jumps out at me as being a clear way in.
• The unencrypted HTTP requests the Roku makes in the main menu. Messing with the layout XML or the images could potentially lead to some kind of vulnerability.
• Uploading a channel to the Roku TV using developer mode

Until then, I guess we will just deal with the ads.

While the mateidu user does not have root privileges in the Linux shell, these devices run an outdated Linux kernel that may be vulnerable to privilege escalation exploits.

The vendor recommends that users “log as mateidu user and change the password via the GUI this will close the old internal protection port access. [sic]”

The mateidu user’s password is the same as its username.

This vulnerability is similar to CVE-2015-0936, which detailed the discovery of an RSA key pair that allowed an attacker to log in as the mateidu user via SSH.

CVE-2017-9137

Timeline:

• 2017/05/12 - Contacted vendor
• 2017/05/14 - Vendor acknowledges report
• 2017/05/16 - Vendor sends their recommendation
• 2017/05/18 - Publicly disclosed

All vulnerabilities below affect versions <2.2.3, except for the last one (authenticated RCE #2), which also affects version =2.2.3.

Mimosa AP’s (<2.2.3) are also vulnerable to the MQTT information leakage vulnerability explained below.

• Information leakage in the web interface (leads to DoS): There is a page in the web interface that will show you the device’s serial number, regardless of whether or not you have logged in. There is another page that allows you to remotely factory reset the device simply by entering the serial number. (CVE-2017-9134)
• Information leakage in the MQTT broker (leads to DoS): These devices run Mosquitto, a lightweight message broker, to send information between devices. By using the vendor’s hard-coded credentials to connect to the broker on any device (whether it be an AP, Client, or Backhaul model), an attacker can view all the messages being sent between the devices. If an attacker connects to an AP, the AP will leak information about any clients connected to it, including the serial numbers, which can be used to remotely factory reset the clients. (CVE-2017-9132)
• Unauthenticated remote command execution (RCE) in the MQTT broker (leads to DoS): By connecting to the MQTT broker on the wireless AP and a wireless client, an attacker can gather enough information to craft a command that reboots the client remotely when sent to the client’s MQTT broker. This command can be re-sent endlessly to act as a DoS attack on the client. (CVE-2017-9131)
• Unauthenticated local file disclosure: In the device’s web interface, there is a page that allows an attacker to use an unsanitized GET parameter to download files from the device as the root user. The attacker can download any file from the device’s filesystem, including block device images. This can be used to view unsalted, MD5-hashed administrator passwords, which can then be cracked, giving the attacker full admin access to the device’s web interface. This vulnerability can also be used to view the plaintext pre-shared key (PSK) for encrypted connections, or to view the device’s serial number (which leads to DoS). (CVE-2017-9136)
• Authenticated remote command execution #1: In the device’s web interface, after logging in, there is a page that allows you to ping other hosts from the device and view the results. The user is allowed to specify which host to ping, but this variable is not sanitized server-side, which allows an attacker to pass a specially crafted string to execute shell commands as the root user. (CVE-2017-9133)
• Authenticated remote command execution #2: On the backend of the device’s web interface, there are more tests the user can run than just the ping test mentioned above. These other tests are not all shown on the webpage; some are only accessible by crafting a POST request with a program like cURL. There is one test accessible via cURL that does not properly sanitize user input, allowing an attacker to execute shell commands as the root user. (CVE-2017-9135)

Timeline:

• 2017/04/05 – Vendor notified of some of the above vulnerabilities
• 2017/04/05 – Vendor acknowledgement
• 2017/04/07 – Vendor notified of web interface RCE #1
• 2017/04/07 – Vendor acknowledges web interface RCE #1
• 2017/04/11 – Vendor releases patch for all vulnerabilities that were known at the time
• 2017/04/11 – Web interface RCE vulnerability #2 discovered and reported to vendor
• 2017/04/12 – Vendor acknowledges vulnerability
• 2017/05/12 – Public disclosure

It affects version 1.01.03, but I am unable to determine exactly which version contains the fix for this vulnerability. The vendor has confirmed that this vulnerability is fixed in the latest version (1.4.8 as of the time of writing).

DragonWave has a proprietary management program that can be used to administer their radios, called Merlin.

In Merlin, a user can connect to a DragonWave device via Telnet and issue commands. Merlin prompts the user for login credentials, however, when connecting to the device, Merlin first tries to authenticate using hard-coded credentials. These credentials were discovered by examining the Telnet traffic in Wireshark.

Credentials used by Merlin include (format is username:password):
b&haul:msh*mark
vib*gyor:superb
energetic:wireless (default device credentials)

Some interesting commands I found after logging in:
Show admin credentials (plaintext): get super user
Show other credentials, if any (plaintext): get user accounts
Read bytes from RAM: read word <hex address> <length>

Timeline:
2017/03/29 – Vendor notified
2017/03/30 – Vendor says that vulnerability is already fixed in newest version
2017/04/06 – Publicly disclosed

CVE ID: CVE-2017-7576

One of our Trango Altum AC600′s was infected by a variant of the malware that spread between out-of-date Ubiquiti devices in May 2016 (http://www.securityweek.com/worm-infects-many-ubiquiti-devices-old-vulnerability).

The version of the malware from May spread between Ubiquiti devices by making use of a vulnerability in the web interface. This new variant simply connects to IP addresses via ssh, on both ports 22 and 2222, and then tries a series of credentials until it either authenticates successfully, or runs out of combinations to try.

In the case of our AC600, the malware on some other device was able to successfully log in to our AC600 using the username “root” and the password “abcd1234″. I tested this on other up-to-date AC600′s we own, and it worked on them as well.

At the time of writing, this login is not documented anywhere on Trango’s website, nor in any manuals. It is enabled by default and can be accessed via both SSH and telnet. It appears that you can change the root password without breaking anything.

CVE ID: CVE-2016-10306

Timeline:

• 2016/12/23 – vulnerability reported to Trango
• 2017/01/03 – no response yet, so I emailed Trango again
• 2017/01/04 – disclosure posted
• 2017/01/09 – initial response
• 2017/01/11 – Trango says they will update the manual
• 2017/02/17 – Trango still has not updated the manual

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.

Timeline:
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

Exploits:
Show username and password in plaintext: https://gist.github.com/ianling/c06636fba1b294393f0d3b7df082aa91
Set password to “Abc123123″: https://gist.github.com/ianling/6f4b8c76aa369618e3ae7dd494958762

CVE ID: CVE-2017-7318

Around a year ago, I extracted a software update package for a Trango GigaPlus radio and found that it simply contained an ext2 filesystem image. After mounting that, I checked /etc/shadow and found a hashed root password, which I immediately put into Cain & Abel, but since I had no idea what length the password was, or what sort of characters it contained, I didn’t end up making any progress bruteforcing it.

More recently, I took another look at the filesystem image. I ended up finding some login credentials, but not for the root account. Instead, it was for Trango’s FTP server, which hosts many of their software update packages.

I downloaded many old packages for their legacy devices, figuring that they were probably much worse at securing their devices 5 years ago than they are now, so looking at those may reveal more than looking at recent packages would.

One of the packages I downloaded contained the root password I was looking for in plaintext. After verifying that it worked on our devices, I immediately reported the find to Trango, who removed the package containing the plaintext password from their FTP server. They said they’d get back to me within a week about next steps.

That same day, I also spoke to a Trango rep on the phone. He said that while this root password worked on some older devices, the password had been changed to something longer in newer device/software versions. This means that the vulnerability still exists in all software revisions of their devices, but with a different password than the one I found.

Three weeks later, I still hadn’t heard back, so I emailed them again asking for an update. I also asked if it would be safe to go ahead and change the root passwords ourselves on our devices, so that we didn’t have to wait for an update to be released. The rep said that it was safe to change the password ourselves, and that there “is no known vulnerability with our product or the software,” which I take to mean that they don’t consider this root backdoor a vulnerability.

While I was going through the filesystem, I also made an interesting discovery with regard to how ssh works on some of their devices. When you connect to a GigaPlus, for example, via ssh, the shell (/bin/sh) immediately spawns a telnet connection to 127.0.0.1, which is what gives you the proprietary configuration CLI. If you end the telnet session without ending the ssh session, either by pressing Ctrl+d or Ctrl+], then it drops you back into the ssh connection, which is just a unix shell.

Obviously having full root access to this unix shell gives you a lot more control over these devices than just having access to the device configuration CLI, making this vulnerability even more serious. Devices compromised in this way can easily be added to botnets, such as the massive one recently aimed at Dyn.

While I was waiting for a response from Trango, I also took the liberty of going through the software packages I had access to via their FTP server and determining what versions of each product use the shorter password I found:

Affected (the short password):

Apex <= 2.1.1 (latest)
ApexLynx < 2.0
ApexOrion < 2.0
ApexPlus <= 3.2.0 (latest)
Giga <= 2.6.1 (latest)
GigaLynx < 2.0
GigaOrion < 2.0
GigaPlus <= 3.2.3 (latest)
GigaPro <= 1.4.1 (latest)
StrataLink < 3.0
StrataPro - all versions?

I couldn’t test the SpartaElite software because the packages are encrypted. The StrataPro was the device that contained the root password in plaintext, and all of its packages were removed from the FTP server, so I wasn’t able to test those either.

Also, it’s important to keep in mind that just because one of Trango’s devices isn’t listed above, doesn’t mean it isn’t vulnerable to this root backdoor; it just means that the one password I found isn’t working. All of their devices still appear to have a root account accessible via ssh using other passwords, and passwords are all stored as a salted MD5 hash, so it’s only a matter of time…

Timeline:

2015 – backdoor first discovered
2016/10/07 – password found
2016/10/07 – reported to trango via email
2016/10/07 – spoke to trango rep on the phone
2016/10/07 – trango said they’d get back to me next week with next steps
2016/11/03 – Emailed trango again asking for an update, as I hadn’t heard anything back from them
2016/11/07 – trango responded, said it’d be okay for us to change the root passwords manually, implied that they don’t consider this a vulnerability and they won’t be fixing it

Demonstration:

ianl@ianl-laptop:~$ ssh root@1.2.3.4
root@1.2.3.4 password:
Trango System:  TrangoLINK GigaPlus Command Line Interface v3.2.3
(CLI-view)#
<press Ctrl+d to kill telnet connection>
#
# id
uid=0(root) gid=0(root) groups=0(root),10(wheel)

CVE ID’s:
CVE-2016-10305
CVE-2016-10306
CVE-2016-10307

edit (2016/12/23): I found another password, this one goes to the Trango Altum AC600′s: “abcd1234″. Yeah.

Product:
======================
-FibeAir IP-10 (<7.2.0)

Vulnerability Type:
===================
Authentication Bypass

Vulnerability Details:
=====================
Ceragon FibeAir IP-10 devices do not properly ensure that a user has authenticated before granting them access to the web interface of the device. The attacker simply needs to add a cookie to their session named “ALBATROSS” with the value “0-4-11”. They can then browse to one of the following URL’s (varies by model number and software version) to add their own user account with full admin privileges:

/responder.fcgi1?winid=106&winname=Users%20%26%20Groups&slot=1&mainslot=1
/responder.fcgi1?winid=109&winname=Users%20%26%20Groups&slot=1&mainslot=1
/responder.fcgi1?winid=103&winname=Users%20%26%20Groups&slot=1&mainslot=1
/responder.fcgi0?winid=89&winname=Users%20%26%20Groups&slot=0

After adding their own user account, they can clear their cookies and log in with the new credentials they created.

Affected versions:
All versions below 7.2.0

Disclosure Timeline:
===================================
Vendor Notification: May 5, 2016
Public Disclosure: June 15, 2016

Severity Level:
================
Critical

CVE ID: CVE-2016-10309

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.