How I can gain control of your TP-LINK home switch

A while back I bought a small TP-LINK switch for using whilst testing. I got a TP-LINK TL-SG105E (version 1) switch because it had a very useful port mirroring feature – i.e. it would send everything from one port to another, effectively allowing me to easily sniff data passing over an interface.

This isn’t a post about port mirroring though, it’s a post about the switch’s management interface and how I decoded the management traffic to get information such as the devices credentials.

You see, as the switch is designed as a basic home consumer unit it doesn’t have a fancy web interface, it uses a custom program (Easy Smart Configuration Utility) to allow you to configure this through a custom protocol.

The Traffic

I’m curious, so I turned on a network sniff through Wireshark whilst I was using the switch. Here’s a very quick screenshot of the sniffed conversations:

To make sense of the above, the important two conversations are the two at the bottom, covering traffic from my laptop (192.168.0.2) to the switch (192.168.0.1) on port 29808/udp.

The immediate thing that jumps out is that all traffic is sent to the broadcast address, 255.255.255.255:

This means that any device on that subnet (i.e. any device connected to the switch) will receive this traffic!

That’s not desired, so maybe we can steal the switch’s credentials, so let’s have a look at the data stream:

Ah, that’s no good – that’s been encoded in some way. Though we can see that the data repeats itself, this is clearer if we use the hex view of the packets:

Note how each “line” (i.e. each packet) starts with 5d 74, this is indicative of a simple constant encoding pattern, either just mangling with XOR or a shift, or encrypting with a static key.

So the next step to decode it is to examine how the application encodes the data.

Decoding the application

A quick dig around the installed application showed that it was written in Java, which has been compiled into a Portable Executable file (a PE file). This can be opened in 7-zip, which allows extraction of the compiled Java Classes:

Once opened, the class files can be extracted to a temporary directory and opened in the jd-gui utility, which is a graphical front end to the jd Java decompiler. A search through the decompiled classes, lead to the com.tplink.smb.easySmartUtility.RC4 class, which gives a hint of the algorithm in use and shows the key used to encrypt:

So now I know the algorithm to encrypt the data, know it’s a static key and know the key. The next step is to…

Decrypt the content

As I’m too lazy to write a proper program to decrypt it, I made a quick proof of concept. First I took the contents of the Wireshark session and saved it using the Save data as Raw option, which saves it as a set of hex strings:

Where each line feed terminated line is one packet. As the lines each start with the same hex value we know that the encryption is applied for each packet, so we can step through them in a loop.

I’ve posted the python I munged together from a generic RC4 function to our github, here https://github.com/pentestpartners/snippets/blob/master/decode-sg-105e.py. I’ve removed the key so as to not make it too easy for the script kiddies to abuse it.

Here’s the python being applied, to decrypt the stream:

The bits highlighted in red shown the admin credentials (admin:admin). From here I could easily gain control of the switch.

Making yourself safe

So, is this a security issue? Maybe, if you use this switch, or its big brother (the SG-108e) as a proper switch then you need to be aware that its traffic is not safe.

In theory you could configure a VLAN on it and use only one of its interfaces as a management interface which would get rid of the problems.

I had a discussion with TP-LINK’s support who were really responsive, and I’ll quote them directly to ensure that I don’t misphrase them:

1. Traffic between utility and switch is sent by broadcast
It is a common way for Utility to communicate with devices with broadcast in our industry, other productors like Netgear does it this way too.

Broadcast will have some shortcomings as you said and we will think about it too, but the premise is LAN is not safe.

In most scenes LAN is a relative safe environment. We will have NAT router and firewall in front of our LAN network, most attacks will be blocked. Firewall and secure software can protect our LAN’s safety. But when LAN is not safe, even we don’t use broadcast, other method like faked ARP can get traffics between utility and switch.

2. Decode of Utility exe and static encryption.
Our Easy Smart Switch is a product for home and small office, so chip is not powerful enough to ensure a very high security.

As you know, Utility is written in Java and it means decompilation is avoidless, anyone can do it if they know how. It is the cost of Java’s universality and we can’t change it. Our R&D will think about add more covers to our codes to make our switch more safe in next Utility.

Their position makes sense for the intended purpose of the device. Although I would like its management traffic to go over unicast rather than broadcast. This won’t stop me using the switch for the purpose I bought it for.