CVE-2020-12124に対する概念実証の実装
原文はこちら：https://www.klogixsecurity.com/scorpion-labs-blog/anatomy-of-an-iot-exploit-from-hands-on-to-rce
執筆者：David E. Baker、公開日：2023年6月1日
この調査は、2020年6月時点のWavlink Wireless-AC1200 Gigabitルーターのファームウェアに関するものです。ここで取り上げる脆弱性はベンダーによって修正されている場合もあれば、されていない場合もあります。しかし、これは脆弱性調査の一例であり、結論に至るまでの過程自体に価値があることを示しています。著者は、これらの脆弱性が一般に公開される前、ただし他の研究者によって独立して発見されベンダーに報告された後に、調査を実施しました。
ベンダーは自社製品のファームウェアをウェブサイトのサポートセクションで公開しています。これはIoTファームウェアを入手する一般的な方法であり、デバイスのメモリから抽出するよりも便利な代替手段です。ファームウェアは暗号化されていないため、binwalkで簡単に抽出できます。動的解析は、デバイスの物理的な実機を用いて行われ、静的解析はGhidraを通じて行われました。
Wavlink Wireless-AC1200 Gigabitルーターのウェブインターフェースには、脆弱なエンドポイントが複数存在します。これにより、ユーザーが提供したデータをアプリケーションスタックに無制限にコピーしたり、コマンドラインに直接渡して任意のコマンドを実行したりすることが可能です。
デバイスの最初のスキャンでは、唯一公開されているリソースは管理用ウェブコンソールであり、LANインターフェース上の認証済みユーザーがHTTP（TCPポート80）でアクセスできることが示されました。デバイスはより多くのサービスを提供できますが、これらは初期状態では有効になっておらず、デフォルトではありません。したがって、この調査はウェブインターフェースのみに焦点を当てます。
実機デバイスのnmapスキャン結果。ウェブインターフェースのみが待機状態であることを示している。
通常のテスト（デバイスの診断パネルでpingやtracerouteコマンドのパラメータにコマンドインジェクションを試みるなど）では、すぐに興味深い結果は得られず、残念な結果に終わりました。
管理ウェブパネルに認証後に利用可能な管理オプション。「USB Storage」が2番目のオプションとして表示されている。
最初に調査した（最終的に悪用可能な）インターフェースは、上記スクリーンショットの2番目のオプションである「USBストレージ」パネルで見つかりました。デバイスには802.2イーサネットプラグの隣にUSBポートがあり、ネットワーク接続ストレージ（NAS）機能を提供できることを示唆しています。
実際の実機デバイスの背面写真。USBポートが利用可能であることを示している。
脆弱性調査の簡単な原則として、コードが相互作用するコンポーネントが多ければ多いほど、また可動部分が多ければ多いほど、悪用可能なコードが潜んでいる可能性が高くなります。NAS機能の存在は有望であり、デバイスのソフトウェア層、ハードウェア層、および接続された周辺機器（USBストレージ自体）と同時に相互作用するコードが存在することを示しています。
USBストレージコンソールの管理インターフェースを以下に示します。「Workgroup」フィールドの存在だけでも有望です。これは、このWiFiルーターがServer Message Block（SMB）を介した通信を試みる可能性を示唆しており、IoTルーターとしては大きな機能です。ユーザーが提供した入力がUnixのsmbpasswd関数の引数として直接コマンドラインに渡されるのを何度も見てきました。
認証されたユーザーが利用可能なUSBストレージオプション。
これらの設定を変更しようとする最初の試みは、デバイスがUSBドライブを検出しなかったため失敗しました。以下を参照してください。
USBストレージオプションの構成変更は、適切にフォーマットされたドライブがデバイスのUSBポートに手動で挿入されない限り保存されない。
しかし、正しくフォーマットされたドライブが挿入されると、デバイスはFTPのユーザー名とパスワードを設定できるようになりました。予想通り、このユーザー提供の入力がコマンドラインに配置されました。
「password」フィールドへのコマンドインジェクションにより、デバイスのオペレーティングシステムへの最初のシェルアクセスが得られる。
興味深いものの、この脆弱性は過度に興奮するものではありません。デバイスの管理インターフェースへの認証情報付きアクセスだけでなく、USBドライブを操作するための物理的なアクセスも必要だからです。上記のエクスプロイトにより、研究者は個々のオペレーティングシステムコンポーネントと対話し（リバースエンジニアリングのためにそれらを外部に持ち出すことが）できます。
このデバイスは、Lighttpdを搭載したウェブインターフェースを持つBusyBox中心のLinuxシステムでした。Common Gateway Interface（CGI）機能は、/etc_ro/lighttpd/www/cgi-bin/内の個別のバイナリによって提供され、CGI URIへのウェブリクエストはこれらのバイナリを直接起動します。Ghidraでnas.cgiを簡単に見ると、以下の38行目にコマンドインジェクションが示されており、ユーザーが提供したパスワードがdo_system関数（標準libcのsystemコールの単なるラッパー）に直接送信されます。
ユーザー入力が38行目でchpasswd.shスクリプトの引数としてコマンドラインに配置され、コマンドインジェクションとデバイスのオペレーティングシステムへの直接のシェルアクセスが発生する。
/cgi-bin/ディレクトリを調べることで、より興味深いエクスプロイトを見つける作業は、ユーザーが利用可能なCGIインターフェースを列挙することに帰着します。以下に示します。
デバイス上で利用可能なCGIバイナリの完全なリスト。このセクションで説明したエクスプロイトによって確立されたシェルから直接取得。ユーザー入力が38行目でchpasswd.shスクリプトの引数としてコマンドラインに配置され、コマンドインジェクションとデバイスのオペレーティングシステムへの直接のシェルアクセスが発生する。
最初の調査でいくつかの点が際立ちます。まず重要なのは、CGIバイナリがしばしばcheck_valid_user関数を呼び出すことです。このメソッドは、リクエストを行っているIPアドレスがファイルシステム上の特定の一時ファイルに保存されているかを確認します。簡単なテストで、クライアントの認証ステータスはこのメソッドが呼び出されるまで検証されないことがわかります。したがって、各CGIバイナリ内でこの関数が呼び出される前のコード面全体は、認証されていない状態でアクセス可能です。
adm.cgiの逆コンパイル結果。check_valid_userメソッドが表示されている。この呼び出しより前のすべてのコードは、リクエスト元の認証ステータスを検証する前に実行される。
もう一つの興味深い観察点は、ユーザー提供の入力を直接スタックにコピーするメソッドが多数存在することです。例えば、wireless.cgiの逆コンパイルでは、14行目と15行目でウェブリクエストの本文から取得されたNewNameパラメータ引数が、34行目でガードなしのstrcpyによってスタックにコピーされています。以下を参照してください。
14行目と34行目で、リクエスト本文のNewNameパラメータがガードなしのstrcpyによってプログラムスタックに直接コピーされている。adm.cgiの逆コンパイル結果。check_valid_userメソッドが表示されている。この呼び出しより前のすべてのコードは、クライアントの認証ステータスを検証する前に実行される。
このユーザー入力のスタックへのコピーだけでも、メモリ破壊エクスプロイトが示唆されます。以下のコマンドで確認できます。
curl -XPOST --data "page=SetName&NewName=\`python3 -c 'print(\\"A\\"*(512)'\`" http://target-ip/cgi-bin/wireless.cgi
有望ではありますが、リターン指向攻撃（ROP）はここでは最適ではありません。すでに取得したオペレーティングシステムへのシェルアクセスを使用して、以下のコマンドを実行すると「1」と表示され、Address Space Layout Randomization（ASLR）が弱い強制力を持っていることがわかります。これにより、ROPチェーンが目的のガジェットに着地する確率は256分の1になります。
# cat /proc/sys/kernel/randomize_va_space
1
さらに、以下のコマンドは、リトルエンディアンのバイナリがスタックガードバイト付きでコンパイルされていることを示しており、チェーン内の最後のガジェットのみがバイナリ内の所定の位置に着地できます。クラッシュ後にウェブサーバーを再起動するウォッチドッグプロセスが存在する場合、リターン指向エクスプロイトを繰り返し投げて最終的に成功する可能性は否定できませんが、コード内の他の場所にさらに優れたバグが潜んでいる可能性もあります。
xxd /etc_ro/lighttpd/www/cgi-bin/wireless.cgi | head -n 10
CGI関数をさらに調べていくと、やがてlive_api.cgiにたどり着きます。このバイナリはcheck_valid_userを呼び出さないため、URI /cgi-bin/live_api.cgiへのウェブリクエストはすべて、認証なしでこのCGIアプリケーションを実行します。図11の9行目では、QUERY_STRING環境変数（Apache CGI仕様によれば、リクエストURIの中で疑問符の直後に続く部分であり、ユーザーが提供する）がpcVar1に格納され、図11の19行目でsatellite_statusメソッドに送信されます。
live_api.cgiの逆コンパイル結果。9行目でURIからユーザー入力が取得され、19行目でsatellite_statusに送信されている。adm.cgiの逆コンパイル結果。check_valid_userメソッドが表示されている。この呼び出しより前のすべてのコードは、クライアントの認証ステータスを検証する前に実行される。
図12に示すsatellite_statusメソッドの逆コンパイルでは、クエリ文字列自体（現在はparam_1）がpage、id、ipパラメータに解析されます。ipパラメータは、図12の38行目でsprintf関数を介してローカル変数にコピーされ、39行目でdo_system関数に渡されます。check_user_authへの呼び出しがないことは、認証されていないユーザーからの任意のクライアント入力がURI内のipパラメータでコマンドラインに直接配置されることを示しています。以下で確認します。
satellite_status関数の逆コンパイル結果。クエリ文字列（現在はparam_1）が22行目と23行目でipパラメータに解析され、38行目と39行目でdo_systemを呼び出していることが示されている。
結果がすべてを示している。エクスプロイトを使用してデバイスをリモートで乗っ取る様子。
市場に登場したばかりのIoTデバイスでエクスプロイトを見つけることは、この記事の冒頭で述べたように、低いところにある果実のように思えるかもしれません。しかし、この調査の価値はその結果ではなく、過程にあります。
認証回避の仕組みやコマンドインジェクションの場所を理解することは、ファームウェアの静的解析なしでは不可能であったでしょう。もしファームウェアがオンラインで入手できなければ、それらを取得するためにデバイスのオペレーティングシステムへの動的アクセスが必要となり、その見込みは薄かったでしょう。このレベルのアクセス自体、デバイスへの物理的アクセスと、特殊なハードウェア、あるいはコード内で誤りが発生しそうな場所を推測する導き出された推測に依存していました。
この過程をお楽しみいただけたでしょうか。またお越しください。 ハッピーハッキング！
著者：
David Baker, Senior Security Consultant, Testing, K logix