10年前に見つからなかった脆弱性が2019年に発見
スマートフォンのOSや誰もが使うSNSなどでは、サイバー犯罪者たちが、毎日のように攻撃するポイントである脆弱性を探している。セキュリティベンダーたちも、犯罪を未然に防ぐべく、さまざまな角度から安全性を検証している。
しかし、5年前、10年前の脆弱性となるとどうだろうか。最新のガジェットやサービスなどに使われていないソフトウェアとなると、うっかりバグが見過ごされて、今日までそのままになってしまう可能性があるかもしれない。
マカフィーは、アメリカの通信・ネットワーク機器メーカーであるアバイア（Avaya）のオープンソースのソフトウェアに、リモートコード実行（RCE）の脆弱性を発見した。同社が10年前にソフトウェアをコピーし変更した際、セキュリティパッチの適用に失敗した可能性があるという。オープンソースのソフトウェアに影響をおよぼすバグについては2009年に報告されているものの、これまで電話のファームウェアのバグは確認されていなかった。
この脆弱性を利用することで、攻撃者はスピーカーフォンから音声を盗み出して盗聴できる可能性があるという。なお、アバイアが6月25日に配布したファームウェアのイメージファイルを入手すれば、問題を解決することが可能になっている。
最新のデバイスを使っていると、なにかセキュリティに問題があればただちに報道されることも多いため、注意をうながされる機会も少なくないだろう。しかし、古いものをそのまま使い続けている場合だと、どうだろうか？ まだ未発見のバグがないとは言い切れず、ある日、サイバー犯罪者がそこを突いてくるかもしれない。
「なんとなく使っている」古い機器の見直しを
10年前の脆弱性が気づかれなかった事実は、極端な例ではない。さまざまな業界で、多くのデバイスが10年以上前の古いコードでプログラムを実行している。もし、そのようなデバイスがネットワークにつながっている場合、適切に隔離、監視されることが重要だろう。
最近では、消費者向けのIoTだけでなく、電気や水道など重要なインフラもインターネット経由で動作するケースが増えてきている。インフラにかかわる機器が悪意をもってハッキングされれば、大きな被害が出る可能性もあるかもしれない。
対策としては、バージョンアップの情報などをチェックする、必要があれば最新のパッチなどを適用する、デバイスがもつプライバシーを保護する機能を知る……などが考えられる。ただ、旧世代のデバイスやソフトウェアなどはサポートの対象外になることもある。古いデバイスをすべて新しくすることが必須とは言わないが、セキュリティ面で不安のない設備・サービスに切り替えることを検討するのも手だろう。
「なんとなく使っている」機器に、思わぬセキュリティの落とし穴が見つかる可能性がある。家庭や職場などで使用している古い機器は、使いっぱなしにせずに、定期的にセキュリティ面を見直す姿勢が必要だ。今回はMcAfee Blogから「Avaya 電話のファームウェアに10年前の脆弱性」を紹介しよう。（せきゅラボ）
※以下はMcAfee Blogからの転載となります。
Avaya 電話のファームウェアに10年前の脆弱性：McAfee Blog
Fortune誌が選ぶ100社の90％が導入しているAvayaは、中小・中堅企業から大企業まで幅広い顧客層に向けた製品を展開する世界第2位のVOIPソリューションプロバイダーです。広く普及しているソフトウェアやハードウェアの重大な脆弱性に関する調査を行なっているマカフィーAdvanced Threat Research（ATR）は、Avaya 9600シリーズIPデスクフォンについて調査することにしました。私たちはAvayaのオープンソースのソフトウェアにリモートコード実行（RCE）の脆弱性を発見しました。同社が10年前にコピー、変更した際、セキュリティーパッチの適用に失敗したと思われます。オープンソースのソフトウェアに影響を及ぼすバグについては2009年に報告されていますが、これまで電話のファームウェアのバグは確認されていませんでした。（SIPスタックも同種の電話で利用できますが）影響を受けるのはH.323のソフトウェアスタックのみとなります。Avaya Security Advisory（ASA）についてはこちらASA-2019-128からご確認ください。
下記のビデオでは、攻撃者がこのバグを悪用して電話の正常な動作を乗っ取る様子をご覧いただけます。攻撃者はスピーカーフォンから音声を盗み出し、電話を“盗聴”する可能性があります。今回の攻撃は、攻撃者のノートパソコンに直接つながれた電話を使って行なわれていますが、脆弱な電話と同じネットワークへの接続を介しても機能します。Avayaが6月25日に配布したファームウェアのイメージファイルをこちらで入手し、問題を解決することが可能です。
調査では何をさがすのか？
組み込みデバイスやIoTデバイスのセキュリティーの調査では、あらかじめ通常2～3個の調査目標を念頭において進めます。ほとんどの場合、主な目標には、デバイスの機能を確認するためにシステムにあるファイルを復元することと、（一般ユーザーの権限で実行できることを超えて）特権的な方法でシステムと直接やりとりする手段を見つけることの2つが挙げられます。これら2つの目標には密接なつながりがあります。たとえば、システムへの特権アクセスを取得すると研究者はそこに保存されているファイルを復元することができます。同時に、最初にファイルを復元することで、特権アクセスを有効にする方法を確認できるのです。
今回は、ファイルの復元は簡単でしたが、特権的アクセス権の取得については多少辛抱強い作業が必要でした。
電話からファイルを復元
電話からファイルを復元するとは、OSとそこで実行中の複数のソフトウェアを見つけることを意味します。連絡先、設定、通話記録などのユーザーファイルは通常セキュリティー研究者にとって関心のないものなので、ここでは取り上げません。ファイルを復元する一番簡単な方法は、デバイスのファームウェアの更新を調べることです。それらの情報は、無料で入手が可能で暗号化もされていないこともあります。ほとんどの場合、ファームウェアを暗号化してもシステムの安全性を高めることはありませんが、攻撃者同様、セキュリティー研究者とっても侵入のバリアを高めるられてしまいます。今回は、Avayaのウェブサイトが様々な電話製品のファームウェアの更新情報を提供しており、誰でもダウンロードすることができました。ダウンロードには複数のtarファイル（アーカイブファイルフォーマットの一種）が含まれています。その後、抽出したファイル上でbinwalkというツールを実行します。binwalkは既知のファイル形式をまとめた大きな辞書です。 未知のファームウェアファイルを見つけると、すべての既存のファイル形式を探し、当てはまるものを見つけ出すと、正常に処理しようとします。たとえば、ファームウェアの中に.zipファイルのようなものを見つけた場合、ファイルの解凍を試みます。未知のファームウェアファイルに直面した場合は、このツールを実行すると、役立つアイテムを識別してくれることが多いので、最初のステップとして有効です。
電話のファームウェアを処理する際には、抽出したファイル上でbinwalkを実行し、電話が起動時に実行するプログラム（ブートローダー）、電話が使用するLinuxカーネル、電話のあらゆるバイナリーと設定ファイルを含むJFFSファイルシステムを入手します。これらのデータからデバイスの内部構造を理解し、バグを探すことができるため、スムーズに作業を始めることができます。しかし、この段階では静的解析しか実行することができません。つまり、ファイルを調べて複数のバイナリーのアセンブリ命令をのぞき見ることはできますが、実行はできないのです。この状況を改善し、より円滑に作業を進める方法として、次の2つの選択肢があります。一つは電話全体あるいは少なくとも関心領域（ROI）をエミュレートする方法、もう一つはシステムへの特権的アクセス権を得る方法で、デバッグツールの実行はもちろんのこと、実行中のプログラムの検出も行ないます。これらすべての選択肢を適切に組み合わせたときに、最良の結果が得られるのです。今回は便宜上、後者のみ取り上げあげますが、どちらも様々な形で私たちの調査に役立ちました。
特権アクセスの取得
IoT／組み込みデバイスへの特権的アクセス権の取得について言えば、セキュリティー研究者は最高レベルの特権がある、あらゆるコードの実行を可能にするルートシェルと呼ばれる管理用インターフェースを期待しています。 それは保守目的であればすぐに利用できる時もあれば、存在はしているとしても簡単にはアクセスできない場合もあります。そこで鍵となるのがハードウェアハッキングです。セキュリティー研究者は、オープンデバイスをリッピングして保証を無効にし、潜在的なデバッグポート、求められている特権アクセスのゲートキーパーを探します。
電話の回路基板のクローズアップ。赤枠で囲んであるのがUARTポート、青枠がEEPROM
上の写真では、UART0とUART1と名前の付いた2つのデバッグポートがあります。銅が直接露出しているこのタイプのテストポイントは、通常、デバイスのプログラミングや動作検証のために製造過程で使用されます。UARTはUniversal asynchronous receiver-transmitterの略で、双方向通信に対応しています。これは私たちが求めている管理者権限が見つかる可能性が最も高い場所です。15ドルのUART – USB変換ケーブルを購入し、テスト基板にワイヤーをはんだ付けすると、電話が起動した際に画面にデバック情報が表示されますが、デバック情報のフローはすぐに終了します。これは気になる振る舞いです – なぜデバッグメッセージは停止するのでしょうか？ – さらに調べる必要があります。逆アセンブラーを使用し、生バイトをコンピューター命令に変換することで、修復したブートローダーのコードを見て、デバック機能全体をシリアルコンソールで有効すべきかを決定づけるブート処理の間に電話が外部メモリーから取得した設定を見つけ出すことができます。外部メモリーはEEPROMと呼ばれ、その形状と印字ラベルから、基板上で簡単に識別できます。電子部品上のラベルはそれら部品を識別し、電気工学的観点からチップの使用方法を説明した技術資料である関連データシートを検索するのに使用されます。ワイヤーを顕微鏡下でチップに直接はんだ付けし、プログラマー（バスパイレーツと呼ばれる30ドルの装置）に接続すると、保存された設定を変更し、電話のデバッグ能力を有効にすることができます。
再プログラミングのための準備が完了したEEPROM
電話を再起動することで、より多くのデバッグ情報を得られ、最終的には私たちが探していたルートシェルが見つかります。
ルートシェルを確認。“whoami” コマンド起動中は、無関係なデバッグメッセージが表示される
その他の方法
上述の方法ではかなり時間がかかるため、セキュリティー研究者にとって、こういった状況でない限り使いたくない方法です。より一般的な手法として、前回の調査で行なったように、フラッシュストレージ（基板の裏側にあるNAND型フラッシュ）を変換することにより直接ファイルシステムを修正し、自動的にSSHサーバーあるいはリモートシェルを起動する方法があります。またNAND型フラッシュを改ざんする手法もよく用いられます。ファイルシステムがメモリを読み込み、ブートローダーを例外状況にすることで、研究者はLinuxカーネルのブート引数を修正することができます。そうでなければ、リモートシェルアクセスを得るために、既知のRCEの脆弱性がある古いファームウェアを使うことが一番簡単な方法といえるでしょう。この方法は、セキュリティー研究者にとって有効な出発点となり、また最新のソフトウェアを所有する一般ユーザーにとっても脅威にはなることはありません。すべてを考慮すると、これらの方法はエンドユーザーにとってリスクにはならないばかりか、セキュリティー研究者にとっても調査を遂行する足がかりになります。
脆弱性の調査
ルートシェルへアクセスでき、電話のファイルをリバースエンジニアリングできるようになると、今度は脆弱性のある可能性のあるソフトウェアを探すという終わりのないタスクに直面します。電話がLinuxを実行すると、Linuxシステムを管理するために使用される一般的なコマンドラインユーティリティはすぐに利用できます。実行中のプロセス一覧リストで各プロセスのネットワーク接続状況などを確認するのは当然のことですが、色々と探るうちに、ユーティリティの1つであるdhclientが非常に重要であることがはっきりと分かります。dhclientはデフォルトで実行され（電話のIPアドレスを設定するDHCPリクエストと呼ばれる）ネットワーク設定を管理しています。dhclientをコマンドラインで呼び出すと、次のように表示されます。
予測通りの引数が記載された詳細なヘルプ画面が表示されるのはいつもと変わりませんが、2004年～2007年の著作権については要注意です。少し検索すると、バージョン4.0.0が10年以上前の古いもので、さらに悪いことに、一般に公開されていてエクスプロイトの標的となるということが分かります。 dhclientコードはオープンソースなので、連続した2つのバージョンの違いを見つけることは簡単なこともあり、エクスプロイトコードやバグに適用されたパッチを調べることは脆弱な可能性のあるコードを絞り込むのに有効です。逆アセンブラを再び使用することで、電話のdhclientのバージョンが2009年に報告されたバグに対して本当に脆弱かどうかを確認します。元のエクスプロイトを電話で機能するように変換するには1日ないし２日間の作業を要しますが、上記ビデオで実演された概念実証の構築はわずか数時間です。実際、独立した機器へ電話の音声を流すあらゆるツールはデフォルトでシステムにあるので、このデモを作る手間は大幅に省かれます。私たちはここでエクスプロイトを止めましたが、この段階で、プライベートネットワークを脅かすことができる兵器化されたバージョンを構築するのはソフトウェアエンジニアリングのタスクであり、熟練した攻撃者であれば、数日とはいかなくとも数週間もあればできると分かりました。
修復について
私たちは、欠陥を見つけるとすぐにAvayaにバグの再現方法と修正案について、詳細な説明とともに報告しました。修復は成功し、テスト後、パッチを適用したファームウェアイメージをおよそ2ヵ月以内にリリースすることができました。修正は30日以上経過してから公開されるため、IT管理者にとって新しいイメージを配置する時間的余裕があります。大企業の場合は、採用されたデバイスに新しいイメージファイルが配置された場合、配置によるコンフリクトの発生を防ぐために、最初に試験段階を経ることは非常に一般的です。これが、パッチリリースから全体配置まで、典型的なコンシューマー（一般消費者）向けのソフトウェアより時間がかかる理由です。
結論
IoTデバイスと組み込みデバイスは環境に紛れ込んでしまうので、それらが引き起こすセキュリティーやプライバシーのリスクについて十分考慮されない場合があります。今回は、最小限のハードウェア投資と無償のソフトウェアで、10年以上無視されてきた重要なバグを発見することができました。Avayaはすぐに問題に対処し、現在このバグがもたらす脅威は軽減されましたが、多種多様な業界で多くのデバイスが10年以上も前の古いコードでプログラムを実行しており、これは極端な例ではないという事実に気づくことが重要なのです。システム管理上の観点から見ると、これらのネットワークでつながったデバイスはアンマネージドコードを実行する小さなブラックボックスのコンピューターなのだと考え、適切に隔離、監視されることが重要です。McAfee Network Security Platform （NSP）は、この攻撃を“DHCP：サブネットマスクオプション Length Overflow” (signature ID: 0x42601100) として検出し、お客様のセキュリティーを保証します。最後に、この記事をお読みいただいているテクノロジー愛好家の皆さまに、オンラインのリソースや、安価なハードウェアが入手簡単になった現在では、ハードウェアハッキングへの壁はかつてないほど低くなったということをお伝えしたいと思います。これらの脆弱性を探し当てることは、情報セキュリティーのエントリポイントとなり、組み込みデバイスをより安全なものにします。
※本ページの内容は、2019年8月8日（US時間）更新の以下のMcAfee Blogの内容です。
原文：Avaya Deskphone: Decade-Old Vulnerability Found in Phone’s Firmware
著者: Philippe Laulheret
※本記事はアスキーとマカフィーのコラボレーションサイト「せきゅラボ」への掲載用に過去のMcAfee Blogの人気エントリーを編集して紹介する記事です。
■関連サイト
