Message-ID: <0MTbOB-1cHGdL3IXv-00SRXf@mrelayeu.kundenserver.de>
Date: Thu, 24 Nov 2016 12:55:04 +0100
From: "Curesec Research Team (CRT)" <crt@...esec.com>
To: fulldisclosure@...lists.org
Subject: [FD] The HS-110 Smart Plug aka Projekt Kasa

Content Table

1. Introduction
2. The Firmware
3. The Android Application
4. The Problems
5. Conclusion
6. Appendix
6.1. Excursion Dalvik
6.2 Control script

1. Introduction

The HS-110 is a Smart Plug meaning it is capable of being controlled with
commands via a network. TP-Link released a mobile application called "Kasa for
Mobile" for Android and iOS devices to control the Smart Plug. The
possibilities range from simple tasks like turning the Plug on and off to
advanced options like planing schedules and timers. The HS-110 additionally has
the possibility to measure and store data regarding power consumption. These
are screenshots of the app home screen, the main control and the settings for a
plug:

app control screen plug control screen plug settings

The device itself is pretty straightforward with only two buttons. The one at
the top is the reset button and the other one in the front is the power button
and status led:

plug from the front plug from the top plug from the back

To open it we remove the hidden screw under the information sheet and then
break it open using a little bit of force:

[open1] [open2]

Now we remove the top part of the board and the two screws on the second part
to get rid of the plastic hull:

[open3] [open4] [open5]

We can now see the Atheros AR9331 (Hornet) on the right board in the middle
picture above. It is a System-on-a-Chip (SOC) which has a MIPS 24K processor
and is a full featured IEEE 802.11n 1x1 AP/Router. It also has a 32 MiB RAM
(Zentel A3S56D40GTP-50l) on the opposite side of the same board. The other
board hosts the electronics for the actual plug. But the interesting question
is: What this SOC is actually running so let's move on to the next section.

2. The Firmware

The Smart Plug runs on a 64-bit Linux (2.6.31). The Firmware is available at
the Website of TP-Link. Our version is 1.0.7. There is also an unofficial
unstable API on GitHub.

For a first analysis of the Firmware we used binwalk . It is important to also
install sasquatch for this since unsquashfs appears to have issues with TP-Link
firmware. You can just install the necessary tools for the installation of
sasquatch via apt

sudo apt-get install build-essential liblzma-dev liblzo2-dev zlib1g-dev

or the corresponding packages if you don't use apt. After that just clone the
sasquatch git repository and run the build script. At the end we have to
install binwalk by cloning it's git repository and running the setup.py script
via

sudo python setup.py install

or

sudo python3 setup.py install

if you are using python3.x. For the dependencies we can run deps.sh, at least
when we are using apt. Otherwise you have to install them by yourself. A list
is available at github .

Now we are ready to run binwalk at the firmware with following command:

root@...i:~/Desktop/test# binwalk hs110v1_us_1.0.7_Build_151016_Rel.24186.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
15904 0x3E20 U-Boot version string, "U-Boot 1.1.4 (Oct 16 2015 - 11:22:22)"
15952 0x3E50 CRC32 polynomial table, big endian 17244 0x435C uImage header,
header size: 64 bytes, header CRC: 0xA2B5F4E6, created: 2015-10-16 03:22:22,
image size: 38777 bytes, Data Address: 0x80010000, Entry Point: 0x80010000,
data CRC: 0xFED80D4A, OS: Linux, CPU: MIPS, image type: Firmware Image,
compression type: lzma, image name: "u-boot image" 17308 0x439C LZMA compressed
data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size:
112564 bytes 66240 0x102C0 uImage header, header size: 64 bytes, header CRC:
0x4D2B83AC, created: 2015-10-16 03:22:56, image size: 772570 bytes, Data
Address: 0x80002000, Entry Point: 0x8019BF90, data CRC: 0xC849B1ED, OS: Linux,
CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name:
"Linux Kernel Image" 66304 0x10300 LZMA compressed data, properties: 0x5D,
dictionary size: 33554432 bytes, uncompressed size: 2238780 bytes 1114816
0x1102C0 Squashfs filesystem, little endian, version 4.0, compression:lzma,
size: 2112689 bytes, 194 inodes, blocksize: 16384 bytes, created: 2015-10-16
03:25:36

It is the most basic command of binwalk and only tells it to analyze the
specified file. As we can see binwalk detects quite a few things. First of all
there is the U-Boot version string and -image header together with its lzma
archive and the polynomial table. U-Boot is a common bootloader, as we can see
it was created on October 16th 2015 at 11 o'clock but it is out of our scope to
go through it. Next thing we notice is the Kernel header and archive which is a
little bit more interesting but we are still looking for the actual system
which is the last entry, the squashfs filesystem, compressed with lzma. Now we
could extract the squashfs filesystem via dd but we can also modify our command
with the argument -e to let binwalk do this. The e argument is the command to
extract the firmware using predefined dd rules. The output should look like
this:

root@...i:~/Desktop/test# binwalk -e
hs110v1_us_1.0.7_Build_151016_Rel.24186.bin Scan Time: 2016-11-17 13:13:18
Target File: /root/Desktop/test/hs110v1_us_1.0.7_Build_151016_Rel.24186.bin MD5
Checksum: 73ad741d2256755f78cfb65d73b798c6 Signatures: 344 DECIMAL HEXADECIMAL
DESCRIPTION
--------------------------------------------------------------------------------
15904 0x3E20 U-Boot version string, "U-Boot 1.1.4 (Oct 16 2015 - 11:22:22)"
15952 0x3E50 CRC32 polynomial table, big endian 17244 0x435C uImage header,
header size: 64 bytes, header CRC: 0xA2B5F4E6, created: 2015-10-16 03:22:22,
image size: 38777 bytes, Data Address: 0x80010000, Entry Point: 0x80010000,
data CRC: 0xFED80D4A, OS: Linux, CPU: MIPS, image type: Firmware Image,
compression type: lzma, image name: "u-boot image" 17308 0x439C LZMA compressed
data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size:
112564 bytes 66240 0x102C0 uImage header, header size: 64 bytes, header CRC:
0x4D2B83AC, created: 2015-10-16 03:22:56, image size: 772570 bytes, Data
Address: 0x80002000, Entry Point: 0x8019BF90, data CRC: 0xC849B1ED, OS: Linux,
CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name:
"Linux Kernel Image" 66304 0x10300 LZMA compressed data, properties: 0x5D,
dictionary size: 33554432 bytes, uncompressed size: 2238780 bytes 1114816
0x1102C0 Squashfs filesystem, little endian, version 4.0, compression:lzma,
size: 2112689 bytes, 194 inodes, blocksize: 16384 bytes, created: 2015-10-16
03:25:36

We see that everything was extracted perfectly fine. When we now look into that
new directory binwalk extracted the files to we see this:

root@...i:~/Desktop/test# ls
_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted/ 10300 10300.7z
1102C0.squashfs 439C 439C.7z squashfs-root

There are a couple of files and directories. They are the Kernel, Firmware and
the squashfs filesystem. We know what everything is by looking at the name of
the specific file which is the beginning of the archives in hexadecimal. For
example we see in our output that the u-boot lzma archive begins at 0x439C in
hexadecimal numbers or 17308 in decimal so the lzma archive is labeled 439C
accordingly. The interesting directory is squashfs-root, the unpacked
firmware's root directory.

root@...i:~/Desktop/test/_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted
/squashfs-root# ls -la total 48 drwxrwxr-x 12 root root 4096 Nov 17 16:00 .
drwxr-xr-x 4 root root 4096 Nov 17 13:55 .. drwxrwxr-x 2 root root 4096 Okt 16
2015 bin drwxr-xr-x 3 root root 4096 Okt 16 2015 dev drwxrwxr-x 5 root root
4096 Okt 16 2015 etc drwxrwxr-x 3 root root 4096 Okt 16 2015 lib lrwxrwxrwx 1
root root 11 Nov 17 13:55 linuxrc -> bin/busybox lrwxrwxrwx 1 root root 8 Nov
17 13:55 mnt -> /tmp/mnt drwxrwxr-x 2 root root 4096 Okt 16 2015 proc
drwxrwxr-x 2 root root 4096 Okt 16 2015 root drwxrwxr-x 2 root root 4096 Okt 16
2015 sbin drwx--xr-x 2 root root 4096 Okt 16 2015 sys drwxrwxr-x 2 root root
4096 Okt 16 2015 tmp drwxrwxr-x 4 root root 4096 Okt 16 2015 usr

So now that we have our filesystem we start looking into it. Doing so we found
a BusyBox installation with version 1.01. Having a look into etc/ we find the
shadow file, containing a single password hashed with DES for user root:

root@...i:~/Desktop/test/_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted
/squashfs-root# cat etc/shadow root:7KBNXuMnKTx6g:15502:0:99999:7:::

Using john the ripper we cracked this password, it is 'media'.

root@...i:~/Desktop/test/_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted
/squashfs-root# john pw Using default input encoding: UTF-8 Loaded 1 password
hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16]) Press 'q' or Ctrl-C
to abort, almost any other key for status media (root) 1g 0:00:00:00 DONE 2/3
(2016-11-17 15:50) 3.571g/s 12382p/s 12382c/s 12382C/s garlic..overkill Use the
"--show" option to display all of the cracked passwords reliably Session
completed root@...i:~/Desktop/test/
_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted/squashfs-root# john
--show pw root:media 1 password hash cracked, 0 left

The next thing to notice is the 2048_newroot.cer which is a certificate:

VeriSign Class 3 Public Primary Certification Authority - G5 Identity: VeriSign
Class 3 Public Primary Certification Authority - G5 Verified by: VeriSign Class
3 Public Primary Certification Authority - G5 Expires: 16.07.2036

This certificate is obviously used for SSL communication and checking if the
Smart Plug is connected to the correct remote server.
There is also the file sw.version which includes the softwareversion:

root@...i:~/Desktop/test/_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted
/squashfs-root# cat etc/sw.version 1.0.7 Build 151016 Rel 24186

But the most interesting executable for us was at usr/bin/:

root@...i:~/Desktop/test/_hs110v1_us_1.0.7_Build_151016_Rel.24186.bin.extracted
/squashfs-root# ls -la usr/bin/ total 1988 drwxrwxr-x 2 root root 4096 Okt 16
2015 . drwxrwxr-x 4 root root 4096 Okt 16 2015 .. lrwxrwxrwx 1 root root 17 Nov
17 13:55 [ -> ../../bin/busybox lrwxrwxrwx 1 root root 17 Nov 17 13:55 arping
-> ../../bin/busybox -rwxrwxr-x 1 root root 4804 Okt 16 2015 calDump -rwxrwxr-x
1 root root 1976548 Okt 16 2015 shd -rwxrwxr-x 1 root root 38052 Okt 16 2015
shdTester lrwxrwxrwx 1 root root 17 Nov 17 13:55 test -> ../../bin/busybox
lrwxrwxrwx 1 root root 17 Nov 17 13:55 tftp -> ../../bin/busybox lrwxrwxrwx 1
root root 17 Nov 17 13:55 tty -> ../../bin/busybox

shdTester is the a client to configure the emeter and calDump appears to dump
calibration data from /dev/caldata. The interesting executable is shd which is
the main server application. Running strings against it we were able to get a
list of commands to control the plug via network. An analysis with IDA Pro 
(mipsb processor type is not included in free version) is left as an excercise
for the reader.

3. The Android Application

We had to reverse-engineer the Android app using dex2jar and JD-GUI because the
communication between plug and app is encrypted. More precisely the app
communicated via tcp with an encrypted payload containing the commands. To do
so we used dex2jar on the apk file like this:

santoku@...toku-VirtualBox:~/Desktop/test$ d2j-dex2jar
Kasa.ver.1.2.4.583.build.583.apk dex2jar Kasa.ver.1.2.4.583.build.583.apk ->
Kasa.ver.1.2.4.583.build.583-dex2jar.jar

Dex2jar essentially only builds a jar file out of the dex files contained in
the apk file. Using JD-GUI we can then analyze the jar file to view the Java
source code. If you wish to learn more about dex files, apks and the Android
Runtime Environment here is a small excursion in the Appendix.

Although the app was obfuscated we found the de-/encoder which uses an
xor-cipher with a fixed key. It appears that the key is the same for every Plug
and app and even for completely different devices like the HS-100 Smart Plug.

The Cipher xor-es the first byte with -85 and the next one with the result from
the xor before and so on. The final payload send to the plug also has the
static prefix '\x00\x00\x00\x23'. This is the encoder from the app, the
byte-array is the payload/command:

byte[] arrayOfByte = paramString.getBytes(); int k = -85; for (int m = 0; m <
arrayOfByte.length; m++) { arrayOfByte[m] = ((byte)(k ^ arrayOfByte[m])); k =
arrayOfByte[m]; }

Knowing the mechanism we could reverse it to decode the payloads of the tcp
packets captured. These were actually commands send with the json format.
Knowing this we could then send our own commands. For this we used the python
control script

4. The Problems

Using the known commands we were able to get complete control over the plug
because there is no authentication method provided, as long as we are on a
local network. So anyone who knows the IP of the Plug can compromise it A list
of commands with a little control script in which the most interesting commands
are implemented is in the Appendix.

The most valuable ones were the bind/unbind command which are used to bind the
plug to an TP-Link account if you want to be able to control it remotely. The
process for a normal user goes like this:

First you log in on your smartphone with your TP-Link account, then your mobile
sends your username and password to the Smart Plug which then uses this info to
tell an amazon web services (AWS) server that it is now bound to that account.
After that the app communicates with the Server via TLS.

Maybe you already saw the problem. The app sends username and password to the
plug, encoded with the xor-cipher we found earlier which means that we get the
login credentials if we manage to intercept the communication.

The remaining question is, how do we get the user to bind his account to the
plug again. Of course we can’t force him to do so but we can trap him using the
unbind command from the control script which unbinds the plug from the existing
account. We don’t need any specific information to do so and the only visible
change for the owner is that the remote access in the settings is switched off
which doesn’t look too suspicious.

root@...i:~/Desktop/Kasa# ./control.py -d -H 10.0.0.188 unbind DEBUG: About to
send: { "cnCloud": { "unbind": null } } DEBUG: Got following answer: {
"cnCloud": { "unbind": { "err_code": 0 } } }

remote switch off

And the moment he switches it back on we have his data.

Other possible attacks include capturing the plug by binding it to our own test
account using the bind command.

root@...i:~/Desktop/Kasa# ./control.py -d -H 10.0.0.188 bind DEBUG: About to
send: { "cnCloud": { "bind": { "username": "username@...l.com", "password":
"password" } } } DEBUG: Got following answer: { "cnCloud": { "bind": {
"err_code": 0 } } }

As we can see in the screenshot below, the owner can’t revoke our access using
the app and has to reset the Plug manually if he isn’t using a script like we
do. This means that we can now control the device conveniently via our own app
as long as we are logged in with a viable TP-Link Account which we send to the
plug.

remote switch disabled

We can also control the state of the Smart Plug and keep it on while switching
its LED off or vice versa. This might actually be useful if the owner doesn't
like having a constantly running LED at night. It is also possible to get the
system state and to reboot or reset the device.

5. The Conclusion

TP-Link addressed the problem with the possible stealing of account data in
another app version (currently at 1.3.3.593, 04.11.2016; tested was 1.2.4.583)
by changing the communication protocol between plug and app to a custom one.
However it is still possible to control the plug with the commands provided in
this article it is not possible anymore to see login credentials.

6. Appendix

6.1. Excursion Dalvik

What is an apk file

An apk file is basically just a zip archive containing necessary data for the
Java Virtual Machine used by Android, called Dalvik.

Why the Dalvik Virtual Machine was developed

As you may know Android apps are commonly written in Java. The problem is that
although the license for the standard Java Virtual Machine is GPL2, which means
it is free and open source, on mobile devices the Java Micro Edition should be
used which isn't under GPL2 license. So there was the need of an alternative VM
for Android. This is the reason the Dalvik VM was developed by Google, claiming
it is a "clean room" implementation of a standard Java VM. Oracle disagreed and
tried to sue Google in August 2010 but failed in May 2012.

How it works

The Dalvik VM was build with the limited resources of a mobile VM in mind, so
it was slimmed down, is able to run multiple instances and so on. Essentially
the Java bytecode generated from the source code is translated into Dalvik
bytecode which is stored in a dex file (Dalvik EXecutable). You can think of a
dex file in a similar way as a jar file. This means multiple class files are
converted into a single "classes.dex" file, while being optimized. For example
strings and constants used throughout different class files are included only
once in the dex file in order to save space. The Dalvik executables can also be
modified during installation for further optimization, including the swapping
of byte-order and linking data structure and function libraries inline, making
it smaller and faster. Android 2.2 (Froyo) extended the Dalvik VM with
trace-based just-in-time (JIT) compilation. This enables the device to trace
which parts of a program are used frequently and translate them into native
machine code dynamically, speeding up the execution by a significant amount. So
when the application is started the first time, the Dalvik VM parses the
classes.dex file from the apk archive and stores the processed file in its so
called Dalvik cache from where it is executed, meaning you end up with two
files. To avoid this and get better startup times a dex file can be
pre-compiled. These files are called odex files (Optimized Dalvik EXecutable)
and are stored in an apk archive, just like the dex files. But because they are
execution ready the Dalvik VM does not need to process these files or store a
copy in its cache, saving precious space. The drawback of this is that it is
more difficult to hack odex files.

The Successor

The Dalvik VM was replaced by the Android Runtime (ART) with Android Version
5.0 (Lollipop) after being introduced as an alternative runtime environment on
Android 4.4 (KitKat). For backward compatibility the ART also uses dex files as
an input but the odex files are replaced by Executable and Linkable Format
(ELF) executables. Once an application is compiled by ART only the ELF
executable is used. The reason for this lies in the compilation method itself.
While Dalvik used a JIT compilation ART uses an ahead-of-time (AOT)
compilation. The difference is that ART translates the whole application into
native machine code upon installation, improving the execution efficiency by 2
to 3 times and saving power while using slightly more space, a trade-off that
is valuable considering modern hardware. ART also has more advantages,
including improved memory allocation, better garbage collection and new and
better debugging features.

Further Information

For further information on Dalvik and ART you may visit androidcentral(a little
bit less confusing but also less detailed, only Dalvik) or the Wikipedia pages
of Dalvik and Android Runtime respectively . For more information upon odex
files I can recommend this post on stackoverflow, and for really detailed
information on both, Dalvik and ART, go to the Android Developers Website.

6.2. Control script

We used a script originally written and published by Adrian Reber for the
HS-100 and implemented more commands. Find the adjusted version in our github
at https://github.com/curesec/Blog/. Interesting files for the KASA Project are
the commands.txt and control.py.


Blog Reference:
https://www.curesec.com/blog/article/blog/The-HS-110-Smart-Plug-aka-Projekt-Kasa-165.html
 
--
blog:  https://www.curesec.com/blog
tweet: https://twitter.com/curesec

Curesec GmbH
Curesec Research Team
Josef-Orlopp-Straße 54
10365 Berlin, Germany

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists