Sniff Wifi Traffic to uncover Secrets of your Home Devices - Part 2

André Eichhofer

In the first part we prepared our Raspberry PI as an access point and we installed the necessary tools, like mitmproxy and tcpdump.

Now, it’s time to test the setting on one of our devices. Before digging deeper, there’s the question why someone should do that? Well, the ultimate goal for a security researcher would be to get the firmware of an embedded device. For example, you can try to catch the url from where the firmware is downloaded. To do that, it makes sense to monitor the traffic first.

Secondly, we should differentiate between two kinds of embedded devices:

1. Traditional IoT devices: These devices sit in your network and have some ports open, mostly http or snmp and they can be administered over their own web interface. A typical example is a (legacy) printer for which you can download the firmware directly from the vendor and then install it locally. We will leave these devices aside for Today.

2. Over the air devices: You control these devices with an app on your smartphone, laptop or over a website. These devices get their user data from a datebase hosted in the cloud. The user commands are often sent to a control server to which the device is connected to. When you trigger a firmware update, it is downloaded directly to the device and not locally to your computer.

Be aware, that most devices use encrypted https traffic to communicate with their command server. If the traffic would be unencrypted, this would be a huge flaw. However, mitmproxy will only intercept unencrypted traffic that is coming from the device. The reason is, that the device will not trust mitmproxy and as you don’t have access to the firmware you cannot install a certificate. So, you will usually not see a lot, if the traffic is encrypted.

But don’t worry, let’s get started.

When I was looking for interesting devices I found this thing in the room of my daughter.

This Toniebox plays something when you put a figure on top. The figures have an RFID chip built-in. You upload some music files through your Toniebox web account and connect them with a specific figure. The Toniebox then downloads the music from the control server. Later, when you put the figure onto the Toniebox, it associates the music files with the figures.

Now, let’s login to our Raspberry PI and make sure that the access point is working.

Next, connect the Toniebox to the Raspberry PI access point. As soon as the Toniebox connect to the AP you will see this output:

wlan0: AP-ENABLED
wlan0: STA 48:70:1e:66:65:a8 IEEE 802.11: associated
wlan0: AP-STA-POSSIBLE-PSK-MISMATCH 48:70:1e:66:65:a8
wlan0: AP-STA-POSSIBLE-PSK-MISMATCH 48:70:1e:66:65:a8
wlan0: AP-STA-CONNECTED 48:70:1e:66:65:a8

Next, we will get the IP address of the Toniebox:

admin@raspberrypi:~ $ arp -vn
Address         HWtype  HWaddress    Flags Mask    Iface
10.3.141.81     (incomplete)                       wlan0

Next, we start mitmproxy and tcpdump and filter out the traffic from the Tonibox: tcpdump -i wlan0 host 10.3.141.81

Now, it’s time to switch to our Tonibox account on the their website and do some changes to the Toniebox configuration. Then we press both ears of the Toniebox to sync the changes. Lets’s have a look at tcpdump…

As we can see there is some traffic and it seems that the database with our Toniebox data is hosted at AWS. We could save the packet files and later inspect them with Wireshark, but we would probably not find something interesting.

Let’s have a look at mitmproxy…

Unfortunately, there’s nothing. The Toniebox apparently doesn’t use unencrypted traffic, at least not when it’s communicating with the cloud. Good for the Toniebox, bad for us.

But that’s not the end of the story, there are still some tests we can try out… See part 3.