
Эксплойт внедрения команд для камеры TP-Link Tapo C200 (CVE-2021-4045), обеспечивающий доступ к root shell через UART и анализ обратно-инженерного бинарного файла uhttpd.
CVE-2021-4045
CVE-2021-4045 — это уязвимость внедрения команд, обнаруженная в камере TP-Link Tapo C200, которая позволяет атакующему полностью захватить устройство с привилегиями root. Эта уязвимость затрагивает все версии прошивки до 1.1.16 Build 211209 Rel. 37726N.
🔗 Официальное уведомление INCIBE: https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2021-4045 (Заменить на реальную ссылку)
🔧 Рекомендуемое решение: Обновить прошивку до версии 1.1.16 или выше.
$ nmap -sV -p- 192.168.1.81
**Результат**:```
PORT STATE SERVICE
443/tcp open https
554/tcp open rtsp
2020/tcp open xinupageserver
8800/tcp open sunwebadmin
Как видите, на устройстве имеется несколько интересных открытых портов. Первым делом я проверил порт 443. Хотя nmap четко указывает, что используется https, при начальном сканировании я это упустил и потратил довольно много времени, думая, что порт 443 использует http. Из-за этого я проверял только http://192.168.1.81:443 вместо https://192.168.1.81:443, поэтому получал только ответы 400. Как я уже говорил во введении, этот процесс был полон ошибок. Что касается остальных портов, то службы, работающие на них, были мне совершенно незнакомы, и я не нашел никакой четкой информации о них. В тот момент у меня закончились известные варианты, и пришло время копать глубже.
----[ Получение shell ]-------------------------------
Перед покупкой камеры я искал в интернете предыдущие исследования этого устройства и, к счастью, нашел этот репозиторий на GitHub, где люди совместно проводили обратную разработку. В одной из проблем объяснялось, как получить доступ к консоли через порт UART, о чем я тогда совершенно не знал. Поэтому я изучил основы и купил преобразователь USB в TTL для подключения.
С помощью упомянутой проблемы мне удалось вскрыть устройство ножом и отверткой и быстро найти UART. После нескольких попыток и большого терпения я наконец припаял несколько проводов к контактным площадкам.
Затем настало время проверить, достаточно ли хороша пайка для передачи данных. Я подключил провода к USB-адаптеру, учитывая, что Rx UART идет к Tx адаптера и наоборот, и подключил адаптер к компьютеру. Опять же, благодаря упомянутой проблеме, я знал, что скорость передачи для последовательного соединения равна 57600, поэтому я выполнил:
$ sudo screen /dev/tty.usbserial-0001 57600
Где '/dev/tty.usbserial-0001' — это USB-порт, к которому подключен адаптер и который питает устройство. Я сразу же начал получать данные, отлично.
Однако доступа к консоли у меня еще не было. Я получал просто последовательность загрузки устройства, которая на самом деле была загрузчиком U-Boot. Выглядело это примерно так:
U-Boot 2014.01-v1.2 (Jul 16 2021 - 18:41:10)
Board: IPCAM RTS3903 CPU: 500M :rx5281 prid=0xdc02 force spi nor mode DRAM: 64 MiB @ 1066 MHz Skipping flash_init Flash: 0 Bytes flash status is 0, 0, 0 SF: Detected XM25QH64A with page size 256 Bytes, erase size 64 KiB, total 8 MiB Using default environment
Autobooting in 1 seconds copying flash to 0x81500000 flash status is 0, 0, 0 SF: Detected XM25QH64A with page size 256 Bytes, erase size 64 KiB, total 8 MiB SF: 8388608 bytes @ 0x0 Read: OK
[...]
При нажатии Enter нас просят ввести имя пользователя и пароль. Благодаря той проблеме на GitHub мы знаем учетные данные, поэтому можем успешно войти с пользователем 'root' и паролем 'slprealtek' и, наконец, получить доступ к консоли.
Как только я убедился, что соединение работает, мне нужно было укрепить пайку, так как она дважды ломалась в процессе сборки корпуса. Я нанес термоклей, чтобы закрепить все провода, и закрыл устройство, отключив все двигатели. Теперь мой тестовый блок был готов.
----[ Изучение устройства ]--------------------------
Теперь, когда у нас есть корпус, давайте изучим устройство:
root@SLP:~# uname -a Linux SLP 3.10.27 #1 PREEMPT Wed Nov 11 20:42:05 CST 2020 rlx GNU/Linux
root@SLP:~# cat /etc/openwrt_version 12.09-rc1
Как видим, это машина на OpenWRT, работающая под управлением Linux 3.10.27. Теперь проверим активные процессы и открытые порты:
root@SLP:~# ps PID USER VSZ STAT COMMAND 1 root 2328 S init 2 root 0 SW [kthreadd] 3 root 0 SW [ksoftirqd/0] 4 root 0 SW [kworker/0:0] 5 root 0 SW< [kworker/0:0H] 6 root 0 SW [kworker/u2:0] 7 root 0 SW [rcu_preempt] 8 root 0 SW [rcu_bh] 9 root 0 SW [rcu_sched] 10 root 0 SW< [khelper] 11 root 0 SW< [writeback] 12 root 0 SW< [bioset] 13 root 0 SW< [kblockd] 14 root 0 SW [khubd] 15 root 0 SW [kworker/0:1] 16 root 0 SW [kswapd0] 17 root 0 SW [fsnotify_mark] 18 root 0 SW< [crypto] 27 root 0 SW [kworker/u2:1] 46 root 0 SW< [deferwq] 47 root 0 SW< [kworker/0:1H] 247 root 2328 S -ash 262 root 0 SW [irq/27-gpio res] 273 root 0 SW< [cryptodev_queue] 282 root 860 S /sbin/hotplug2 --override --persistent --set-rules-f 304 root 888 S /sbin/ubusd 325 root 8152 S tp_manage 357 root 3416 S /usr/bin/ledd 361 root 3408 S /sbin/msglogd 367 root 3220 S /usr/sbin/netlinkd 370 root 5468 S < /usr/bin/system_state_audio 379 root 10180 S /usr/sbin/wlan-manager 491 root 1636 S /sbin/netifd 492 root 1520 S /usr/sbin/connModed 494 root 11488 S /usr/bin/dsd 496 root 1532 S /usr/sbin/connModed 502 root 7640 S /bin/cloud-service 520 root 4360 S /bin/cloud-brd -c /var/etc/cloud_brd_conf 653 root 15020 S /bin/cloud-client 830 root 2320 S /usr/sbin/telnetd -b 127.0.0.1 861 root 3852 S /usr/sbin/uhttpd -f -h /www -T 180 -A 0 -n 8 -R -r C 870 root 6048 S /usr/bin/relayd 872 root 5948 S /usr/bin/rtspd 879 root 4612 S /usr/bin/p2pd 884 root 11152 S /bin/dn_switch 889 root 4180 S /bin/storage_manager 920 root 40940 S /bin/cet 956 root 32336 S /bin/vda 960 root 3808 S /bin/wtd 970 root 11288 S /bin/nvid 1019 root 2332 S udhcpc -p /var/run/static-dhcpc.pid -s /lib/netifd/s 1037 root 0 SW [RTW_CMD_THREAD] 1059 root 1212 S wpa_supplicant -B -Dwext -iwlan0 -P/tmp/supplicant_p 1089 root 2332 S /usr/sbin/ntpd -n -p time.nist.gov -p 133.100.9.2 -p 1103 root 3840 S /usr/bin/motord 1447 root 2324 R ps