これは、私のタームペーパーのHTML版であり、PDFとしてダウンロードできます ここ。
ファジングは、ソフトウェアのバグを見つける「最も効果的な方法の1つ」となっています。このような主張や 類似した主張で、現在のファジング関連の論文の多くが始まります [google-scholar]。 「Internet of Vulnerable Things」というトピックに関する前回のタームペーパーの主な目標は、メモリ関連のバグを見つけて、 この脆弱性のエクスプロイトを書くことでした。ファームウェアをリバースエンジニアリングして脆弱性を 見つけることはできましたが、メモリ関連のバグは見つかりませんでした。バッファオーバーフローを 手動でバイナリをリバースして見つけるのは、時間がかかるだけでなく、多くの経験も必要です。 同時に、ファジングはそのようなメモリ関連の脆弱性を見つける「最も効果的な方法」を目指しています。 例えば、Googleはオープンソースソフトウェアを継続的にファジングするOSS-Fuzzを導入し、 すでに1,000プロジェクトで10,000以上の脆弱性を発見しています [oss-fuzz]。
このタームペーパーの目標は、再びメモリ関連の脆弱性を見つけることですが、今回はファジングを 使用します。対象となる脆弱性は、管理者の資格情報を知らなくてもネットワーク経由で悪用可能で ある必要があります。この論文はこの目標を達成する方法を説明します。そのために、論文は 2つの部分に分かれています。最初の部分は、有力なターゲットを見つける方法、使用できるツール、 優れたファジングターゲットが何で構成されるべきかに焦点を当てています。2番目の部分では、 バイナリ内の特定の関数をファジングできるハーネスを開発およびデバッグする方法を説明します。 そして、開発されたハーネスはAFL++によってターゲット関数をファジングするために使用されます。 以下では、IoTデバイスのファジングに関する現在の技術水準と背景を簡単に説明します。
このタームペーパーの文脈で作成されたすべてのファイルは、GitHub上で完全に公開されており、 次のURLからアクセスできます。 otsmr/blackbox-fuzzing。
IoTデバイスのファジングは、オープンソースプロジェクトのファジングほど簡単ではありません。多くの場合、ソースコードは プロプライエタリであり、最高のファジングパフォーマンスのためにソースコードを計測するグレーボックスファジングは 不可能です [afl-persistent]。 また、CPUアーキテクチャがファザーによってネイティブにサポートされていないことが多く、 QEMU [qemu] のようなエミュレータが必要になり、ファジング速度も遅くなります。 [afl-persistent]。 もう1つの問題は、ハードウェアペリフェラルであり、一般的なアプローチの開発を複雑にします。 論文「Embedded Fuzzing: A Review of Challenges, Tools, and Solutions」 [embedded-fuzzing] は、ハードウェアベースの組み込みファジングなど、さまざまなファジング戦略の概要を提供します。これらの戦略のほとんどは、 ターゲットプログラムのソースコードを必要とします。例えば、ファザーのソースコード（AFLなど）をARMベースのIoTデバイスに 移植してIoTハードウェア上でファザーを実行する場合です。デバイスのハードウェア上でファザーを実行すると、 パフォーマンスの問題もあります。多くの場合、通常のデスクトップCPUよりも遅い低レベルのCPUを搭載しているためです。 この論文で紹介されているもう1つのアプローチは、エミュレーションベースの組み込みファジングです。 これは、単一のターゲットプログラムをエミュレータ内で実行してカバレッジガイド付きファジングを実行するか、 システム全体を実行します。
前述のアプローチはすべて、エミュレータを使用するかソースコードを計測することにより、バイナリを直接ターゲットにします。
これらのアプローチでは、多くの場合、単一のIoTデバイス向けに特別に作成する必要があるファジング設定が必要であり、
一般化が困難です。そのために、研究者はプログラム
IoTFuzzer を作成しました。これは、「ファームウェアイメージにアクセスせずにメモリ破壊の脆弱性を
見つける」ことを目的とした自動ファジングフレームワークです。
[iotfuzzer]。 IoTFuzzers
は、ほとんどのIoTデバイスにそれらを制御するモバイルアプリがあり、そのようなアプリにはデバイスとの
通信に使用されるプロトコルに関する情報が含まれているという観察に基づいています。プログラムは次に
プログラム固有のロジックを特定して再利用し、テストケースを変異させてIoTターゲットを効果的にテストします
[iotfuzzer]。
ハーネスは、ファザーが提供する入力を処理するAPI呼び出しのシーケンスを記述します。通常はハーネスを必要としない 通常のアプリケーションとは対照的に、再利用可能な関数を実装するライブラリは、正しいパラメータで、かつ 正しい順序で呼び出す必要があります。これにより、複数の共有関数呼び出しの間の状態を 呼び出すことができます。状態機械を構築せずにライブラリをランダムにファジングしても成功する可能性は低く、 逆に、ライブラリの依存関係が強制されない場合、多くの誤検知のクラッシュが発生します。 これは、例えば、ファザーがバッファサイズチェックをスキップし、結果として誤ったバッファオーバーフローが発生する 場合に起こり得ます。
この論文では、通常のアプリケーションをファジングしますが、ソケットとマルチスレッドの使用に関する ハードウェア依存性のため、それらのためにもハーネスを作成する必要があります。ハーネスは バイナリのコンテキストでロードされ、対象プログラムの内部関数を呼び出すことができます。 これは Code 10 に示されています。
「コーパス」という用語は、有効な入力サンプルまたはテストケースを表し、ファジングプロセス中に新しい入力データを 生成するための基礎となる参照として機能します。Code 10では、これは例えば HTTPリクエストになります。ファザーはこのコーパスを利用して、変異した、または多様化されたテスト ケースを作成し、さまざまな入力シナリオの探索を通じてソフトウェアの脆弱性の検出を 支援します。
ブラックボックスファジングの最も時間のかかる部分は、潜在的な
脆弱な関数をファームウェア内で見つけることです。最初のステップは、
興味深いバイナリを見つけることです。例えば、ネットワーク経由でアクセス可能で、
安全でない関数を使用する、またはスタックカナリアのようなセキュリティ機能が
有効になっていないバイナリです。スタックカナリアはバッファオーバーフロー保護です。前回の論文
([iovt]) では、対象ルーターからファームウェアを抽出する方法と、
潜在的に危険なバイナリを見つける方法についてすでに説明しました。
このために、EMBAツール [emba] が使用されました。EMBAは、
ファームウェア内で見つかったすべてのバイナリを、安全でない関数の数、例えば
strcpy、ネットワークアクセス、そしてスタックカナリアやNXビットのような
セキュリティ保護によってランク付けします。これらはバッファオーバーフローを悪用する際に重要になり、
Code 1 にあります。
コード1: strcpy関数の安全でない使用に関するEMBAの結果。
本論文の目的は、管理者の認証情報を知らなくてもネットワーク経由で悪用可能なメモリ脆弱性を 見つけることであるため、脆弱な関数はネットワーク経由で呼び出し可能であり、提供されたユーザー入力と直接 やり取りする必要がある。しかし、ネットワークとのやり取りがあるからといって、そのバイナリが ネットワーク経由で直接アクセス可能であるとは限らない。どのバイナリが待ち受けているかを調べるには、 [iovt]で 既に確立されたUARTルートシェルを使用することができる。
```txt ~ # netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:20002 0.0.0.0:* LISTEN 1045/tmpd tcp 0 0 0.0.0.0:1900 0.0.0.0:* LISTEN 1034/upnpd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1027/httpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1224/dropbear udp 0 0 0.0.0.0:20002 0.0.0.0:* 1048/tdpd [...] ```コード2: UARTルートシェルを使用してnetstatを実行する
最初に有望と思われるバイナリは wscd です。このバイナリは、(libcmm.so ライブラリを除けば) 最も安全でない strcpy 呼び出しとネットワーク通信を持ち、wscd の場合は UPnP デバイスに接続し、特定のポートで待ち受けることはありません。後述するように、ファジングしやすい関数を持っているため、本書では一般的な手順を説明するための例としてこのバイナリが選ばれました。リバースエンジニアリングの前に、UARTルートシェルを使用して、このバイナリが実行されているかどうか、またどのように起動されたかを確認できます。
コード3: psコマンドを使用して実行中のすべてのプログラムを表示する。
psを使うと、バイナリが実行されていることだけでなく、引数も確認できます。引数は、
潜在的な関数が実際に呼び出されているかどうかを検証するために重要です。これらの引数の意味は、
バイナリを引数なしで呼び出したときに表示されるCLIヘルプから得ることができます。
コード4: バイナリ wscd のオプション。
コード4 に示すように、wscd は "Enabled UPnP Device service" で起動され、有望に見えます。バイナリが実際にルーター上で実行されていることを確認した後、Ghidra を使用してバイナリを分析し、疑わしい関数を検索することができます。ファジングでは、パース関数が特に興味深いです。パース関数は通常複雑であり、解析される入力には、含まれるデータの長さフィールドが頻繁に存在するからです。たとえば、TCPパケットにはペイロードの長さが含まれます。
図1: Ghidra を使用したパース関数の検索。
