kaleth4/cve-2021-4045TP-Link Tapo C200カメラ（CVE-2021-4045）向けのコマンドインジェクションエクスプロイト。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を使用していると長時間思い込んでいました。そのため、https://192.168.1.81:443 ではなく http://192.168.1.81:443 だけを試してしまい、400応答しか得られませんでした。序文で述べたように、このプロセスは失敗の連続でした。他のポートに関しては、そこで実行されているサービスは全く未知のもので、明確な情報は見つかりませんでした。その時点で既知の選択肢は尽きてしまったので、さらに深く調査する時が来ました。
----[ シェルを取得する ]-------------------------------
カメラを購入する前に、インターネットでこのデバイスに関する以前の研究を検索しました。幸運なことに、人々がリバースエンジニアリングのために協力しているGitHubリポジトリを見つけました。そのIssueの一つに、UARTポートを介してコンソールにアクセスする方法が説明されており、当時私はそのことを全く知りませんでした。そこで基本を学び、接続するためにUSB-TTL変換器を購入しました。
前述のIssueの助けを借りて、ナイフとドライバーでデバイスを開け、すぐにUARTを見つけることができました。数回の試行と多くの忍耐の後、ようやくパッドにワイヤーをはんだ付けできました。
次に、はんだ付けがデータ転送に十分かどうかを確認する時が来ました。ワイヤーをUSBアダプターに接続しました。UARTのRxはアダプターのTxに、その逆も同様になるように注意し、アダプターをコンピューターに接続しました。再び、前述のIssueのおかげで、シリアル接続のボーレートが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 Issueのおかげで認証情報がわかっているので、ユーザー'root'、パスワード'slprealtek'で正常にログインし、ついにコンソールにアクセスできました。
接続が機能することを確認した後、はんだ付けを強化する必要がありました。ケースを組み立てる過程で2回も壊れてしまったからです。ホットメルトシリコンを塗布してすべてのワイヤーを固定し、すべてのモーターを外してデバイスを閉じました。これでテストユニットの準備が整いました。
----[ デバイスを探索する ]--------------------------
ケースができたので、デバイスを探索してみましょう：
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
root@SLP:~# netstat -natpu Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8800 0.0.0.0:* LISTEN 920/cet tcp 0 0 127.0.0.1:929 0.0.0.0:* LISTEN 875/p2pd tcp 0 0 0.0.0.0:20002 0.0.0.0:* LISTEN 325/tp_manage tcp 0 0 0.0.0.0:2020 0.0.0.0:* LISTEN 969/nvid tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 920/cet tcp 0 0 127.0.0.1:23 0.0.0.0:* LISTEN 832/telnetd tcp 0 0 127.0.0.1:921 0.0.0.0:* LISTEN 878/relayd tcp 0 0 127.0.0.1:922 0.0.0.0:* LISTEN 877/rtspd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 863/uhttpd tcp 0 0 192.168.1.80:37380 52.19.66.90:443 ESTABLISHED 507/cloud-brd udp 0 0 0.0.0.0:20002 0.0.0.0:* 325/tp_manage udp 0 0 0.0.0.0:38000 0.0.0.0:* 1087/ntpd udp 0 0 0.0.0.0:3702 0.0.0.0:* 969/nvid
nmapスキャンで見られたオープンポートの背後にあるプロセス、例えばuhttpdやcetなどが確認できます。私は特にuhttpdプロセスに注目しました。なぜなら、それがhttpsサーバー（その時点ではまだhttpだと思っていました）の背後にあり、httpプロトコルにすでに非常に精通していたからです。