バックドアとしてウェブカメラを悪用するハッカーの手口
モノのインターネット(IoT)機器に対するハッキング成功の報告が増加している。これらの取り組みのほとんどは、そのようなデバイスにアクセスしたり、そのセキュリティ障壁を突破したりする方法を示すものである。これらの攻撃のほとんどは、デバイス自体に価値のある実際のデータ(クレジットカード番号やPIIなど)が含まれていないため、比較的取るに足らないと考えられている。問題のデバイスは一般的に、多くの帯域幅にアクセスできるものの、CPUやRAMの点ではほとんどない傾向があるため、ボットネットの所有者に大きな価値を提供することはありません。
しかし、こうしたデバイスは、ネットワーク内に持続的なアクセスポイントを確立するために利用できるようになると、高度な攻撃者にとってより魅力的な標的となります。例えば、ウェブカメラにコールバック型バックドアを仕込むことで、ハッカーはノートパソコン、ワークステーション、サーバーを感染させる必要なく、ネットワークへの常時アクセス権を得ることができます。これらはいずれも通常、厳重な監視下に置かれており、頻繁にパッチが適用される可能性があるからです。 このような小型デバイスには、アンチウイルスソフトもエンドポイント保護も存在しません。実際、そのデバイスにソフトウェアが搭載されていること自体、誰も想定していないのです。このため、ステルス性の高いコマンド＆コントロール経路を利用して攻撃を管理する、執拗な攻撃者にとって、これらのデバイスは格好の標的となり得ます。
攻撃者にとっての欠点は、このクラスのデバイスは通常、本当に使える永続ストレージを持たないことだ。その代わり、コンフィギュレーションを保存するためにnvramを使い、実行中のコードを保存するためにフラッシュROMを使う。そのため、攻撃者が本当の意味で永続性を求めるには、フラッシュROMの中身を制御できるかどうかにかかっている。このブログでは、デバイスがインストールされているネットワークへの永続的なバックドアを実現するために必要なすべてのツールを含む新しいフラッシュ・イメージを作成することがいかに難しいかを探ります。いったんこのようなフラッシュ・イメージができれば、それを導入するためには、すでに配備されているデバイスを「アップデート」するか、デリバリー・チェーンのどこか、つまりエンド・カスタマが受け取ってインストールする前のデバイスにバックドアをインストールする必要があります。この実験を意味のあるものにするためには、デバイスが通常の機能を実行し続けることが不可欠である。そうでなければ、すぐに疑惑を持たれたり、顧客がデバイスを正常なバージョンと交換する原因となってしまう。
ウェブカメラ・エクスプロイトを始める
このシナリオでは、Vectra Threat LabsチームはコンシューマーグレードのD-Link WiFiウェブカメラをおよそ30米ドル*で購入した。その小さな素晴らしいプラスチックケースを割ってみると、レザーマンがすべての仕事に適した道具ではないことを思い知らされる、素晴らしい体験だった...。
回路基板を見るとわかる：
- WiFiアンテナ
- ラリンク RT5350F
- SDram M12L2561616a-6t
- フラッシュROM MX25L3205
ステップ1：フラッシュメモリーのダンプ
PCB上にフラッシュメモリーチップがあることから、データ／コードが永続的に保存されているのはここだろうと推測される。そこで最初にすべきことは、そのチップの中身をダンプし、何が保存されているかを確認することだ。
バス海賊をボードに接続した後、フラッシュロムを使ってコンテンツをダンプすることができる。
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1Mflashrom v0.9.7-r1782 on Linux 4.0.0-kali1-amd64 (x86_64)flashromはフリーソフトウェアです。ソースコードを入手する。 遅延ループのキャリブレーション...OK。buspirate_spiでMacronixフラッシュチップ "MX25L3205(A)" (4096 kB, SPI)が見つかりました。buspirate_spiでMacronixフラッシュチップ "MX25L3205D/MX25L3208D" (4096 kB, SPI)が見つかりました。buspirate_spiでMacronixフラッシュチップ "MX25L3206E" (4096 kB, SPI)が見つかりました。複数のフラッシュ・チップ定義が検知されたチップに一致します: "MX25L3205(A)"、"MX25L3205D/MX25L3208D"、"MX25L3206E "どのチップ定義を使用するか、-cオプションで指定してください。
これで、さらなる分析のためにフラッシュ・チップの内容をダンプできるようになった。
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c 'MX25L3205(A)' -r MX25L3205-A
ステップ2：フラッシュダンプの分析
フラッシュのきれいなダンプができたら、binwalkを使ってその中に何が入っているかを調べることができる。
#binwalk -Me MX25L3205-A DECIMAL HEXADECIMAL DESCRIPTION------------------------------------------------------------------------ 0 0x0 uImage header, header size: 64 bytes, header CRC: 0x11BEF629, created：Tue Feb 3 11:07:53 2015、イメージサイズ：111116バイト、データアドレス：0x80200000、エントリポイント：0x80200000、データCRC：0xCD95F789、OS：Linux、CPU：MIPS、イメージタイプ：イメージタイプ：スタンドアロンプログラム、圧縮タイプ：なし、イメージ名："SPI Flash Image "91040 0x163A0 U-ブートバージョン文字列、"U-Boot 1.1.3"105424 0x19BD0 HTML 文書ヘッダー105777 0x19D31 HTML 文書フッター105780 0x19D34 HTML 文書ヘッダー105979 0x19DFB HTML 文書フッター106140 0x19E9C HTML 文書ヘッダー106840 0x1A158 HTML 文書フッター210495 0x3363F PEM 証明書211671 0x33AD7 PEM RSA 秘密鍵327680 0x50000 uImage ヘッダー、ヘッダーサイズ：64 バイト、ヘッダー CRC：0xABF213A9、作成されました：Tue Feb 3 11:07:48 2015, image size: 3730981 bytes, Data Address：0x80000000、エントリポイント：0x8038B000、データCRC：0x2829F3C1、OS：Linux、CPU：MIPS、イメージタイプ：OS Kernel Image、圧縮タイプ：lzma、イメージ名："Linux Kernel Image "327744 0x50040 LZMA圧縮データ、プロパティ：0x5D、辞書サイズ：33554432バイト、非圧縮サイズ：6394309バイト327744 0x50040 LZMA圧縮データ、プロパティ：0x5D, 辞書サイズ: 33554432 バイト, 展開サイズ: 6394309 バイト
つまり、このファームウェアのフォーマットは、u-bootとLinuxカーネルとイメージで構成されている。
dd、lzma、cpioを使ってファームウェアの中身を取り出すこともできるし、binwalkにこの作業をさせることもできる。イメージの中身を見るには、cpioイメージの最後のステップを抽出する必要がある。
#cpio -ivd --no-absolute-filenames -F. 0.cpio この最後のステップが終われば、Linuxイメージ・ファイルシステムにアクセスできる。
ファイルシステム内の興味深いバイナリの1つは/bin/upgradefwで、これはファームウェアの検証とアップデートを実行するために使用される実行ファイルのようだ。
#ファイル ./bin/upgradefw./bin/upgradefw：ELF 32-bit LSB 実行ファイル, MIPS, MIPS-II version 1 (SYSV), ダイナミックリンク, インタプリタ /lib/ld-uClibc.so.0, ストリップ済み
ステップ3：upgradefwバイナリの解析
このセクションでは、アップグレード・バイナリをリバースエンジニアリングするツールとして、IDA Pro を使用します。
IDAは、バイナリの最初のパスを非常にうまく取ることができるので、解析が非常に簡単になる。メイン関数からのコードパスをたどっていくと、mtd_writeに送る前にフラッシュ・イメージが有効かどうかを検証する「check」という関数にたどり着く。
upgradefwバイナリによって行われる検証には、いくつかのcrc32チェック、memem/strstrチェック、値を計算して固定値と比較するループなどがあるようだ。
エントリー・ポイントからサクセス・リターンまでのチェック関数のロジックの流れは、おおよそ次のようになる：
1.ファイルが正しく開かれているか確認する
2.ファイルサイズの確認
3.ファイルをロードし、読み込みが成功したことを確認する。
4.署名」をチェックする："
5.リリース "をチェックする："
6.リリースを現在のリリースと比較する
7.Uboot/uimageチェックルーチン
55AA55AAのチェックサムのため、ここでx86に切り替えた。
ステップ4：ウェブカメラにバックドアを追加する
この時点で、バックドアを追加することは、おおよそLinuxシステム内にサービスを追加することに発展する。これは、スタートアップスクリプトのsrelayとnetcat、またはより最適化されたCコードで達成することができるし、システムにすでに存在するnetcatとbusyboxを使ったシェルで、単純なコールバックバックバックのバックドアを作ることもできる。
追加する機能はできるだけ軽量にするのが常に良いアイデアだ。結局のところ、ここではフルラップトップで作業するのではなく、4MBのROMを搭載した小さなウェブカメラで作業するのだ。ですから、あまり多くの機能を追加するとソフトウェアが壊れてしまいます。修正を加える一方で、将来的にデバイスをリフラッシュする機能を削除することもできる。こうすることで、管理者主導のファームウェア・アップデートを防ぐことができる。
ステップ5：スクリプトのリパッケージ
リパッケージ・スクリプトの作成に時間を費やした後、Ralinkのウェブサイトでかなり便利なスクリプトを見つけた。
と一緒に使う：
make -f Makefile.4M
その後、必要なのはファイルのチェックサムを修正することだけである。これは、addchecksum という名前の RaLink ユーティリティを使うか、手動でチェックサムを修正することで実現できます。チェックサムが使用するオフセット/範囲は、upgradefwまたはaddchecksumバイナリの両方で見つけることができます。そしていつものように...エンディアンをチェックしてください。
ステップ6：コネクトバックのテスト
telnetd / busybox / netcatを使うことで、外部のホストにtelnetソケットを戻し、ウェブカメラにリモートの永続性を持たせることができる。ウェブカメラがプロキシとして機能することで、攻撃者は制御トラフィックをネットワークに送信して攻撃を進めることができ、同様にウェブカメラを使って盗んだデータを吸い出すことができる。
エスケープ文字は '^]' です。(none) login: adminPassword:BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) 組み込みシェル (ash)Enter 'help' for list of built-in commands.# ls /biniwpriv pcmd nvram_daemon ntpclient sounddb ipush touch pwd ls cpov7740 switch mii_mgr mtd_write notifystream schedule sync ps login chmoduvc_stream gpio ated msmtp mydlinkevent lanconfig sleep ping killcatmail nvram_set reg mDNSResponder imagetp iperf sh mount grep ashi2c nvram_get pppoecd lld2d upgradefw inadyn sed mknod echo busyboxswing ralink_init openssl disablebonjour audiopush umount rm mkdir date alphapd
結論ウェブカメラのバックドアからの保護
では、これらすべてはD-Linkのウェブカメラに重大なセキュリティ上の問題があることを意味するのでしょうか？必ずしもそうとは限りません。価格相応の品質というもので、Amazonで30ドルで販売されているウェブカメラのベンダーに対し、ソフトウェア更新の内容や署名を検証するためにTPMや専用チップを必要とするような安全なファームウェア更新機能を提供するよう求めるのは、あまり現実的ではありません。むしろ、この実証実験の目的は、IoTデバイスがネットワークの攻撃対象領域に及ぼす実際の影響を浮き彫りにすることにあります。 これまで示してきたように、これらのデバイスをハッキングするための障壁は比較的低く、最も基本的なデバイスでさえ、持続的なコマンド＆コントロールチャネルの基盤となり得ます。これらのデバイスはハードウェアコストの面では価値が低いものの、ネットワークのセキュリティにとっては依然として重要であり、チームは悪意のある動作の兆候を見逃さないよう、常に監視を続ける必要があります。
*Vectra は2015年12月初旬にD-LInkにこの問題を開示した。2016年1月7日現在、同社は修正プログラムを提供していない。