HiSilicon hi3520d DVR/NVR デバイス向けの概念実証エクスプロイトと脆弱性開示です。Web インターフェースを介した RCE、バックドア認証情報、バッファオーバーフローの解析を実証します。
= HiSilicon DVR ハック Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Contents :image_width: 100%
[abstract] このレポートは、HiSilicon hi3520d および類似のシステムオンチップ (SoC) を使用して構築された DVR/NVR デバイスの深刻な脆弱性（概念実証 (PoC) コード付き）を開示します。これらの脆弱性を悪用すると、Web インターフェースのみを使用して不正なリモートコード実行 (RCE) が可能になり、悪用されたデバイスを完全に乗っ取ることができます。アップグレードされたファームウェアが提供されていないため、これらのデバイスの使用は推奨されません。 2016年12月より前にベンダーに連絡しましたが、まだ返答がありません。開示の公開日は2017年2月です。
== 序文
数年前、私は eBay で安価な中国製 DVR デバイスを購入しました。デバイスの起動ロゴには「SECULINK - Security Monitoring」と表示されます。IT セキュリティ愛好家として、このセキュリティ監視サービスがどの程度「安全」なのかを確認するために、デバイスを詳しく調べることにしました。このテーマについて Google で検索すると、いくつか興味深い資料が見つかりましたが、さらに深く掘り下げたところ、このデバイスに関するさらに興味深く、はるかに深刻な問題（0-day）を発見しました。
ハッキングセッション全体を最初から見てみましょう。（新しい独自の成果は、既知の古い成果と同様に記載されます。）
== DVR の探索
まずは公式ユーザーインターフェースを学び、その後さらに深く掘り下げ、おそらくファームウェアの入手を試みるべきです。脆弱性を見つける可能性はファームウェアとともに高まります。
=== 一目見た DVR
テスト用の DVR デバイスは「Seculink」というブランドです。
image::./seculink_device.png[Seculink DVR device]
利用可能な物理インターフェース:
公式ユーザーインターフェース:
直接アクセス可能なセットアップインターフェースは、ユーザー認証（ユーザー名、パスワード）によって制限されています。デフォルトのスーパーユーザーは 'admin'、デフォルトのパスワードは空です。
強力なパスワードを設定した後、ユーザーは自分のカメラビューが他の人からアクセスされないと安心して感じるかもしれません。人々は、外部から DVR ストリームにアクセスするために、自宅の安全な LAN から DVR デバイスの Web ポート（tcp/80）を WAN 側に転送することがよくあります（これは、適切な Shodan 検索で確認できます ;) ）。
=== ファームウェアの取得
ファームウェアを入手する方法はたくさんあるかもしれません：
後者（ダウンロード）の方法はここでは機能し、最も簡単ですが、デバイスに関する他の情報も得られるため、最初の方法を試してみましょう。
=== サービススキャン
DVR に対してフルポートスキャンを実行しましょう。なお、（root で実行した場合のデフォルトの）SYN スキャンはパケットがドロップされるため非常に遅いですが、フル TCP コネクトスキャンは数分で完了します。
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
要約と手動テスト:
なお、rtsp ストリームを開くには認証情報も必要です。
ここで、このデバイスはおそらく Linux 系のシステムであると言えます。
raw netcat で 9527/tcp に接続すると、ログメッセージとログインプロンプトが表示されるアプリケーションコンソールが表示されます。定義済みのアプリケーション認証情報のいずれかでログインできます。プロンプトで help を実行すると、コンソールコマンドの簡単な説明が表示されます。shell コマンドが最も興味深いようです。そうです、デバイスに root シェルを与えます。 ;)
これは明らかに深刻なセキュリティ問題です。なぜなら、いかなる（低権限の）アプリケーションユーザーも、デバイス上で自動的に root シェルを取得できるべきではないからです。
=== root シェル
root シェルでデバイスを調査すると（例：dmesg）、DVR が Linux カーネル（バージョン 3.0.8）を実行しており、ARMv7 CPU を搭載し、SoC モデルが hi3520d であることが明らかになります。
実行中のプロセスのリスト（ps）から、DVR アプリケーションが /var/Sofia であることがわかります。これは、nmap で検出された上記の tcp ポートに加えて、34568/udp および 34569/udp でもリッスンしています（netstat -nlup）。
マウントされたディスクのリスト（mount コマンド）から、ファームウェアイメージが /dev/mtdblockX デバイス（X=0,1,2,3,4,5）にあることがわかります。
ファームウェアは小さく、制限されているため、デバイスとの間でファイルをコピーしたい場合は工夫が必要です。幸い NFS がサポートされているので、デスクトップマシンに NFS サーバーをセットアップし、DVR からマウントすれば問題は解決します：
これでファームウェアの取得は簡単です：
ファイル（生イメージだけでなく）を取得することもできます：
=== telnet インターフェース
telnet インターフェース（ポート 23/tcp）を介してデバイスにアクセスするには、OS の認証情報が必要になる場合があります。/etc/passwd を見ると、root ユーザーのパスワードハッシュがあります：
root 以外のユーザーは存在せず、すべてがフル権限で実行されていることに注意してください。（つまり、誰かが何らかの方法でデバイスに侵入した場合、障壁はなく、攻撃者は即座に完全な権限を取得します。）
6文字の英数字（小文字）パスワードを想定すると、hashcat は上記の弱い DES ハッシュをすぐに解読します：
$ ./hashcat64.bin -a3 -m1500 absxcfbgXtb3o -1 ?l?d ?1?1?1?1?1?1
absxcfbgXtb3o:xc3511
Session..........: hashcat Status...........: Cracked Hash.Type........: descrypt, DES (Unix), Traditional DES Hash.Target......: absxcfbgXtb3o Time.Started.....: Sun Sep 3 03:25:07 2017 (2 mins, 29 secs) Time.Estimated...: Sun Sep 3 03:27:36 2017 (0 secs) Guess.Mask.......: ?1?1?1?1?1?1 [6] Guess.Charset....: -1 ?l?d, -2 Undefined, -3 Undefined, -4 Undefined Guess.Queue......: 1/1 (100.00%) Speed.Dev.#1.....: 815.9 kH/s (203.13ms) Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.........: 121360384/2176782336 (5.58%) Rejected.........: 0/121360384 (0.00%) Restore.Point....: 93440/1679616 (5.56%) Candidates.#1....: sa8711 -> h86ani HWMon.Dev.#1.....: N/A
したがって、ユーザー root とパスワード xc3511 を使用して、ポート 23/tcp の telnet インターフェースを介してログインすることが可能です。閉じることができない telnet インターフェースでアクセス可能なこのハードコードされた root アカウントは、明らかにバックドアです。
これらの結果は、私たちの研究より前に他の人々によってほぼ利用可能でしたが、以下は完全に新しいものです。
== ファームウェアのリバースエンジニアリング
ファームウェアを調査すると、バイナリ /var/Sofia が、ビデオ処理などを除くすべてのインターフェースを実装するメインアプリケーションであることがわかります。したがって、このバイナリは私たちにとって最も興味深いものと思われます。
残念ながら、このバイナリは（静的にリンクされており）ストリップされているため、静的解析が難しくなっています：
したがって、静的解析（radare2 や IDA を使用）に加えて、動的解析も非常に役立つはずです。
=== リモート gdb
動的解析には、GNU プロジェクトデバッガ (GDB) をリモートの /var/Sofia アプリケーションにアタッチすることが有利です。推奨される方法は、リモートデバイス上で gdbserver を実行（およびアタッチ）し、ローカルマシンから gdb で接続することです。
もちろん、適切な ARM アーキテクチャ用に（できれば静的に）コンパイルされた gdbserver が必要です。これをビルドするには、組み込みシステム（私たちの DVR など）に推奨される C ライブラリである https://www.uclibc.org/[µClibc] を使用できます。利用可能なビルドはダイナミックビルドであり、私たちの DVR では問題があるため、カスタムの静的ビルドを自分で作成する必要があります。https://buildroot.org/[Buildroot] という素晴らしいビルド環境があり、追加の設定なしでビルドを実行できます（make menuconfig で必要なアプリ（例：gdb）を選択し、静的ライブラリを選択することを忘れずに、make を実行します）。
短いビルド時間（約 10〜15 分）の後、必要なツールがすべて利用可能になります。静的バイナリは、前述の NFS メソッドでデバイスに転送できます。Sofia バイナリを含むディレクトリ /var は ramfs であり、再起動後も持続しないことに注意してください。バイナリを（ほぼ）永続的に転送したい場合は、設定ファイルを含む読み書き可能なパーティション /mnt/mtd が適切なターゲットになります。openssh パッケージもビルドすると、scp が利用可能になり、ファイルの転送がより簡単になります。
これでファームウェアはリバースエンジニアリングの準備が整いました。リモートで gdbserver をアタッチできるようになりました（Sofia プロセスの PID を取得するのは ps で簡単です）：
ローカルマシンから接続します：
なお、何らかの GDB 拡張機能（http://gef.readthedocs.io/en/master/[GEF] など）を使用することをお勧めします。何らかの理由でアプリケーションの一時停止（C-c を使用）が機能しない場合は、Sofia プロセスに TRAP シグナルを送信すると（kill -TRAP 610）、一時停止するはずです。
=== 認証手順の調査
静的解析の推奨ツールは、明らかに Hex-Ray の https://www.hex-rays.com/products/ida/[IDA Pro] です。残念ながら安価ではありませんが、他のどのツールよりもはるかに優れています。
初期の自動解析後には 15,000 以上の関数がありますが、IDA を使えば（簡単な Python スクリプトを使用して）認証関数を見つけるのは一瞬です。以下の https://www.hex-rays.com/products/ida/support/idapython_docs/[IDAPython] スニペットは、「Users」および「Password」の両方（同時に）に関連するものを参照するすべての関数を検索します：
