クラッシュを探すファジング

ファジングとは、予期しない動作、特にクラッシュを引き起こすために、不正な形式またはサイズの大きい入力をプログラムへ送ることです。クラッシュは、多くの場合、メモリ破壊バグの兆候です。

バッファオーバーフローでは、まず対象をクラッシュさせ、オーバーフローが存在することを確認します。

古典的なエクスプロイトのワークフローは次のとおりです。

• ファジングしてプログラムをクラッシュさせます。
• リターンアドレスまでの正確なオフセットを見つけます。
• EIPを制御します。
• shellcodeへリダイレクトします。

このレッスンでは最初の2段階を扱います。

クラッシュを観察するには、対象にデバッガー（WindowsではImmunity Debuggerやx64dbg、LinuxではGDBなど）をアタッチします。

プログラムがクラッシュすると、デバッガーにはレジスタの状態、特にEIPが表示されます。これにより、リターンアドレスを上書きできたかどうかが分かります。

単純なファザーは、プログラムがクラッシュするまで、ますます長い文字列を送信します。一般的な開始方法は、多数の「A」文字（0x41）を送ることです。

クラッシュ後にEIPが41414141を示していれば、リターンアドレスを制御できることを確認できました。

アプリケーションがクラッシュし、EIPが41414141と等しい場合、オーバーフローが保存されたリターンアドレスまで到達しています。

ただし、EIPの前に何バイトあるかはまだ正確には分かりません。すべて同じバイトを送ると、EIPを制御できることは分かりますが、EIPがどこにあるかまでは分かりません。

正確なオフセットを見つけるには、すべて「A」にする代わりに重複しない一意のパターンを送信します。4バイトごとの範囲がすべて異なるため、EIPに入った値からオフセットを特定できます。

Metasploitにはこのためのpattern_create.rbが含まれています。

パターンでクラッシュさせた後、EIPの値を確認します。それをpattern_offset.rbに渡すと、EIPの前にある正確なバイト数が返されます。

このオフセットは、リターンアドレスのバイト列の前に置くパディングのサイズです。

必ず検証してください。offsetバイト分の「A」に続けて、4バイトの「B」（0x42）を置いた入力を作成します。EIPが42424242になれば、オフセットは正確です。

この確認により、後で数バイトずれたエラーのデバッグに何時間も費やすことを防げます。

EIPを制御した後は、クラッシュした瞬間にESPが指している位置も確認します。ESPは通常、上書きされたリターンアドレスの直後、残りのバッファ内を指します。

後でshellcodeを配置するのは、この領域です。

ファジングとパターン生成に役立つツールには、次のものがあります。

• Spikeとboofuzz：ネットワークプロトコル用ファザーです。
• pattern_create / pattern_offset：EIPのオフセットを特定します。
• Immunityのmona.py：パターン、オフセット、問題のある文字のタスクを自動化します。

有用なクラッシュには再現性が必要です。クラッシュを引き起こす正確な入力を保存し、クリーンな状態から再実行してオフセットが安定していることを確認します。

クラッシュに一貫性がない場合、バグが単純なスタックオーバーフローではないか、実行ごとに何らかの条件（タイミング、長さ、内容）が変化している可能性があります。

サイクリックパターンが同じバイトを並べた文字列より優れている理由を思い出してください。

これでクラッシュオフセットの見つけ方が分かりました。

• 入力を増やしながらファジングしてクラッシュを引き起こし、EIP内の41414141で確認します。
• サイクリックパターンとpattern_create / pattern_offsetを使って正確なオフセットを見つけます。
• パディングと4バイトの「B」（42424242）で検証します。
• 後でshellcodeを配置するため、ESPが指す位置を確認します。

次はEIPを完全に制御し、実行をリダイレクトします。