Blog: How-Tos

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

David Lodge 20 May 2016

LinkSwitchHeader

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.

LinkSwitch1

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:

LinkSwitch2

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:

LinkSwitch3

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:

LinkSwitch4

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:

LinkSwitch5

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:

LinkSwitch6

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:

LinkSwitch7

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:

5d746a047dbeb0b2971adf7535477e53422ba2f5d78baeed508f463dc202909aa4ec81c6
5d75ae6a62b7dd37971adf7535477e5c422ba2f5d787aeed508f463dc202909a521281c6d8d52b36
5d77ae6a62b7dd37971adf7535477e5f422ba2f5d797aeed508f74b0c202909a591381c0464e465f27d942b5a44608403418222a80b19b77
5d75ae6a62b7dd37971adf7535477e5e422ba2f5d787aeed508f74b0c202909a5b1981c6d8d52b36
5d75ae6a62b7dd37971adf7535477e59422ba2f5d787aeed508f74b0c202909a5b1181c6d8d52b36
5d75ae6a62b7dd37971adf7535477e58422ba2f5d787aeed508f74b0c202909a5b1a81c6d8d52b36
5d75ae6a62b7dd37971adf7535477e5b422ba2f5d787aeed508f74b0c202909a521281c6d8d52b36
5d77ae6a62b7dd37971adf7535477e5a422ba2f5d793aeed508f4e5cc202909a591381c0464e465f27d942b5a44608403418222a7c4e9b77c7eb7608
5d75ae6a62b7dd37971adf7535477e45422ba2f5d787aeed508f4e5cc202909a491381c6d8d52b36
5d75ae6a62b7dd37971adf7535477e44422ba2f5d787aeed508f4e5cc202909a6b1381c6d8d52b36
5d75ae6a62b7dd37971adf7535477e47422ba2f5d787aeed508f4e5cc202909a6b1281c6d8d52b36
5d75ae6a62b7dd37971adf7535477e46422ba2f5d787aeed508f4e5cc202909a7b1381c6d8d52b36
5d75ae6a62b7dd37971adf7535477e41422ba2f5d787aeed508f4e5cc202909a1b1381c6d8d52b36

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:

LinkSwitch8

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.