Hikまたはハック？ （NOT）Hikvision IPカメラを使用したIoTセキュリティ

現代の世界では、何らかの形で小型コンピューターを表す「スマート」デバイスに囲まれています。 家電やスマートホーム、医療および銀行機器、エンターテイメントシステム、産業機器など、最新の機器との統合の観点から、これらはすべて組み込みシステム（ 組み込みデバイス ）です。



スマートガジェットは私たちの生活に非常に緊密に統合されており、 インターネット経由など、低コスト、利便性、使いやすさから、その数は年々増加しています 。 ただし、多くのプラスの裏には隠れている短所があり、平均的なユーザーには一見して見えません。



NeoQUEST-2017 Confrontation レポートの1つで 、広範なクラスの組み込みデバイス（IPカメラ）が検討され、組み込みソフトウェアを分析する一般的なアプローチが議論されました。 この記事では、メーカーが使用するHikvision DS-2CD2432F-IWカメラ、そのファームウェア、および埋め込みと変更からの保護メカニズムの研究について詳しく説明します。

知人

Webインターフェイスにアクセスして機能を調べます。ソフトウェアバージョンを確認し、ネットワークサービス（SSH、SNTP、FTPなど）をアクティブにします。 かなり古いファームウェア5.3.0を搭載したカメラを入手しました。 当然、ベンダーはバージョンごとに、デバイスの機能だけでなくセキュリティの問題にもパッチを当てています。 執筆時点では、このカメラの最新ファームウェアのバージョンは5.4.5です。









カメラからライブビデオを表示するには、ブラウザプラグインが必要です。 プラグインの1つはカメラ自体に保存されています-ダウンロードしてください。おそらく便利でしょう。









SSHを介してデバイスに接続し、現在のカメラ設定を確認したり、独自の設定を行ったり、Webインターフェースよりもデバイスに関するより多くの情報を学習したりできる特定のコマンドセットでCLIを確認します。









コマンドをチェックし、それらの1つを使用して、OS、OSカーネル、プロセッサアーキテクチャ、ファイルシステム、RAMサイズ、物理メモリパーティションなどに関する情報を見つけます。

情報検索

研究者にとって重要なスキルは、情報を検索する能力です。結局のところ、誰かがすでにあなたの前にこれを行っている可能性が高いです。 多くの質問への回答は、テーマ別フォーラムまたは単に検索エンジンで見つけることができます。 たとえば、さまざまなカメラ、レジストラなどに特化したフォーラムに参加します。



少しサーフィンして、さらに深く「フォールスルー」する方法を見つけてください 。つまり、CLIとファイルシステムの「カット」コマンドが使用可能なルートシェルで見つけてください。



ルートシェルにアクセスすることで、開いているポートとプロセスのリストを取得したり、ファイルシステムから実行可能ファイルを抽出して検査したり、独自のファイルを起動したりできます。 SDカードを使用して両方をインポート/エクスポートできます。









カメラを知る段階でさえ、 RS232タブがWebインターフェイスに表示されていました。 このインターフェイスの使用方法に関するスレッドがフォーラムにすぐに登場しました。









UARTをカメラに接続し、 minicomに必要なパラメーターを設定することにより、カメラの起動のログ全体を読み取り、デバイスの起動を停止し、ブートローダーで「失敗」することができます。 ログは非常に大きく、起動されたプロセス、合格したチェック（これまでのところ不明）、エラー、その他のシステム情報が表示されます。









ブート自体とそのコマンドも同様に興味深いもので、データをデバイスの物理メモリに読み書きしたり、tftpサーバー経由でカメラを更新したり（突然「レンガ」に変えた場合）、カメラの内部に関するさらに詳細な情報を取得したりできます。

ファームウェア構造

ヘッダー

カメラ自体の少しの研究の後、ファームウェアイメージの研究に進みます。 イメージをダウンロードします。ファームウェアは拡張子が「.dav」の不明なファイルであることに注意してください。 16進エディタで何かを見ようとしています。









原則として、ファームウェアイメージは、ほとんどの場合、イメージ自体およびサポートされているデバイスに関するメタデータを含むヘッダーで始まります。 前の図から、タイトルに似たものがわかります。 binwalkファームウェアファイルを「フィード」してみましょう。 最初の〜13万バイトでは何も見つかりませんでした。これは、このブロックが暗号化されている可能性が高いことを示しています。









私たちはすでに述べたフォーラムを「煙」にして、それに出くわします 。 ファームウェアファイルのヘッダーは、実際にはバイト単位で暗号化されていることがわかります。 ブロック暗号化は、XOR操作に基づいて実装されます。 操作キー=「BA CD BC FE D6 CA DD D3 BA B9 A3 AB BF CB B5 BE」。 後続の各xorの前に、キーはバイト単位で循環的に左にシフトされます。 ヘッダーを解読するための小さなスクリプトを作成しています。 これまでのところ、結果として、おそらくいくつかのファイルの名前と未知のバイトのセットを取得します。









利用可能な情報（画像のサイズとバージョン、binwalk`aログなど）をヘッダー内の不明なデータと比較してみましょう。 たとえば、binwalkも検出した画像のサイズまたは.gzアーカイブのオフセットを確認できます。 バイト順に、これはリトルエンディアンであると結論付けることができます。









デートの段階でダウンロードしたブラウザプラグインを思い出してください。 その名前はタイトルに表示されます。 変位後すぐに、画像にそのサイズが表示されます。









ファイルに関連付けられた構造には、ファイル名（32バイト）、そのオフセット（4バイト）、およびサイズ（4バイト）が含まれることは既に知られています。 さらに4バイトの情報は、次の構造まで不明のままです。 これはほとんどの場合チェックサムです。 どのアルゴリズムで計算されるのかは不明です。 長さが4バイトしかないため、これは一般的なハッシュ関数（MD5（）、SHA *（））の結果ではないと言うことができます。 CRC32（）が使用されていると想定できます。 試してみます-量が収束しません。



いくつかの仮定の後、奇妙な依存関係が見つかりました。ファイルサイズが大きくなると、チェックサムも大きくなります。 これにより、ファイルの1つに連続してバイトを追加するようになりました。 実際、チェックサム計算アルゴリズムは非常に単純であり、バイトが順次追加されます。 同様に、ヘッダーチェックサムが計算されます。ヘッダーチェックサムは、サイズの隣の最初に配置されます。



復号化されたヘッダーには次の情報が含まれます。

• イメージ自体について：バージョン、アセンブリ、サイズについて。
• デバイスについて;
• ファームウェア内のファイルについて：名前、オフセット、サイズ、チェックサム。

詳細な見出し構造は次のとおりです。









ヘッダー構造が完全にわかったので、ヘッダーを解析し、イメージを個別のファイルに圧縮解除するスクリプトを書くことは難しくありません（記事の最後に、元のファームウェアイメージを解凍して新しいイメージを作成するプログラムのソースへのリンク！）。 そして、ここでそれらを注意深く研究します！

hroot.img

イメージの一部であるファイルを調べます。 一部の予定については名前から既に明らかですが、残っているのは現時点で推測することだけです...拡張子が「.img」のファイルがすぐに目を引きます。これはおそらく、ファイルシステムのイメージです。 すぐにマウントできません。 binwalkを「フィード」して「.gz」アーカイブを表示しますが、64バイトのみであり、画像には独自のヘッダーがあります。









原則として、ファイルシステムのイメージのヘッダーには、イメージのチェックサム、サイズ、およびデバイスのRAMのロードアドレスが含まれます。 私たちの場合、CRC32チェックサム（）。 「マジックバイト」KDMR（RMDK、ramdisk magic）も追加されました。 残りのヘッダーバイトはゼロで埋められます。

initrun.sh

すでに名前で、デバイスの電源がオンになったときにスクリプトが起動されると想定できます。 調査した結果、必要なディレクトリの作成、アーカイブのアンパック、ファイルのコピー、バイナリファイルの起動、不要なファイルの削除、カーネルモジュールのロード、必要なパーティションのマウント、シンボリックリンクの作成が行われることがわかりました-これらはすべてRAMで発生します。

davinci.tar.gz

lib_so.tar.gz-動的ライブラリを含むアーカイブは目立たないように見えますが、ライブラリ内のアーカイブ内では、実行可能バイナリファイルdaemon_fsp_appが失われました。 このアーカイブに置かれたのは奇妙ですが、残りのバイナリは画像内の残りのファイルと連結されただけです。 まあ、それを元に戻す必要があります！



このバイナリファイルは、ファームウェア内のファイルの1つであるdavinci.tar.gzを復号化、開始、および削除し、プロセス内でハングさせたままにすることが判明しました。 これは最も興味深いファイルです-デバイスの基本的なロジックを実装するdavinci暗号化された実行可能ファイル。 Webサーバーを「管理」し、新しいファームウェアのインポートされたイメージをチェックします。



ファイルのチェックサム、それらのオフセットとサイズ、ファームウェア内のファイル数、イメージのサイズとそのバージョン、互換性のあるデバイスのクラス、ヘッダーのチェックサムとサイズ、ファイルシステムイメージのヘッダー、そしてもちろん「マジックバイト」がチェックされます。 各ファイルの構造を分析する場合、これらのチェックを回避することはそれほど難しくありません。 これにより、イメージを変更したり、独自のイメージを作成したりできます。



製造業者はdavinciを圧縮されたtar.gzアーカイブとして偽装しましたが、実際にはまったく異なる入れ子人形があります（下図を参照）。 バイナリファイルはtarアーカイブにパックされ、lzmaアルゴリズムを使用して圧縮され、AES対称ブロック暗号化アルゴリズムを使用して暗号化されます。ブロックサイズ-128ビット、キーサイズ-256ビット、暗号化モード-ECB、および「マジックバイト」復号化中にチェックされます。



暗号化キーはEVP_BytesToKey（）キー生成関数を使用して生成されます。MD5（）は2つのパスで使用され、パスフレーズは「R0sslV53cryptor0」、ソルトは「HangZhou」です。 さまざまなクラスと一連のデバイスでは、このキーは異なります。調べているカメラのシリーズはR0です。

_cfgUpgSecPls

ファイルはdavinciバイナリファイルと同じ方法で暗号化されますが、暗号化キーが異なるだけで、復号化はdavinci自体によってすでに行われています。 キーは、別のパスフレーズを使用して生成されるため、「h @ k8807H $ Z5998」と異なります。 「HangZhou」ソルトと同じ場所で、davinciバイナリファイルの「内部」にあります。



次の図に示す復号化されたファイルの構造によれば、これは2番目の画像ヘッダーであると言えます。メタデータ、ファイル名、オフセット、サイズ、チェックサムも含まれています。 主な違いはチェックサム計算アルゴリズムです-ここに通常のSHA（）（SHA1（）および他のSHA（）アルゴリズムと混同しないでください）と、ファイル自体の暗号化アルゴリズムがあります。 このファイルは、ヘッダーと同様に、davinciによってチェックされます。









画像内の残りのファイルは、上記ほど興味深いものではありません。 それらの簡単な説明を以下の表に示します。

悲しい結果を要約するには...

何が言えますか？ ほとんどの組み込みデバイスは中国で製造されており、メーカーはプログラマーとハードウェアの作業を節約しようとしています。その結果、このハードウェアの計算リソースは非常に限られています。 その結果、元のソフトウェアの変更（または完全な不在）を防ぐためのセキュリティメカニズムの実装が不十分でした。



さらに、製造業者は独立してバックドアを置くことができます。 また、スマートティーポットのハッキングが重大な損害を与える可能性が低い場合（これは、 潜在的にスマートティーポットがペンタゴンのサイトを「置く」こともできるという主張に基づいて議論できますが）、より重要な組み込みシステムへの攻撃は深刻な結果を招く可能性があります結果。



ほとんどのデバイスの自動更新の欠如は、その安全性を完全に損ないます。普通の人は、個人に影響を与えるか、誰もがそれについて話すまで、情報セキュリティの分野のニュースをフォローしません。 主婦が中国のサイトからカメラの新しいファームウェアをダウンロードすることはまずありません。



デバイスは何年も更新されない場合があります。 その結果、攻撃者は、「犠牲者」の平凡な監視からボットネットの作成まで、個人的な利益のためにアクセス可能な抜け穴を悪用します。



将来的には、メーカーが製品の安全性にもっと責任を持ち、それが私たちの生活にますます注がれていることを願うだけです。たとえば、 電子デジタル署名などのソフトウェアの変更や置換からそれらを保護するための最新の信頼できるメカニズムを導入します 。

PS

調査中に、 元のファームウェアイメージを解凍し、 Pythonで新しいイメージを作成するプログラムが作成されました。 アンパッカーは、イメージをコンポジションに含まれる個別のファイルに分割します。 アセンブリは、デバイスへのダウンロード時にチェックされるこれらのフィールドを考慮します。これにより、イメージ内のファイルを（イメージに新しいファイルを追加せずに）変更し、新しいファームウェアファイルをアセンブルできます。 アセンブリには、展開されたイメージが必要です。