cisco-talos/mutiny-fuzzerPCAPトラフィックを変異エンジン（Radamsa）で再生し、カスタマイズ可能なメッセージプロセッサとモニターを介してターゲットホストの脆弱性を迅速に発見するネットワークプロトコルファザー。
ブログ記事はこちら:
このYouTubeビデオデモへのリンク:
ファジングキャンペーン/フィードバック/ハーネス向けの機能はこちら:
Mutiny ファジングフレームワークは、ミューテーショナルファザーを通じてPCAPを再生することで動作するネットワークファザーです。目標は、徹底性を犠牲にして、できるだけ早くネットワークファジングを開始することです。
Mutiny の一般的なワークフローは、ブラウザリクエストなどの正当なトラフィックのサンプルを取得し、それをプリップスクリプトに入力して .fuzzer ファイルを生成することです。その後、この .fuzzer ファイルを使用して Mutiny を実行し、ターゲットホストに対してトラフィックを生成し、ユーザーが望む任意のパケットを変異させます。
Mutiny の動作を変更できる拡張機能があります。これらには、入力/出力に基づくメッセージの変更、ネットワークエラーへの応答方法の変更、および別スレッドでのターゲット監視が含まれます。
Mutiny は変異を実行するために Radamsa を使用します。
Decept Proxy は多目的ネットワークプロキシであり、プレーンテキストまたは TLS TCP/UDP/ドメインソケット接続から別のプレーンテキストまたは TLS TCP/UDP/ドメインソケット接続へトラフィックを転送できます。その他の機能もあります。これは Mutiny の良いコンパニオンであり、特にTLS接続のファジング時に .fuzzer ファイルを直接生成できるため、Mutiny が TLS ホストと通信できるようになります。
sample_apps は、ファザーでできることの基本的なアイデアを提供し、テスト用のいくつかの異なるアプリケーション/クライアントが含まれています。
作成者: James Spadaro ([email protected])、Lilith Wyatt ([email protected])
Python と Scapy がインストールされていることを確認してください。
Radamsa を展開して make します（/usr/bin にインストールしたい場合以外は make install する必要はありません。ローカルの Radamsa を使用します）。変更した場合は mutiny.py の Radamsa へのパスを更新してください。
pcap をフォルダに保存します。<XYZ>.pcap に対して mutiny_prep.py を実行します（また、必要に応じてカスタムプロセッサのディレクトリを渡すこともできます。詳細は後述）。質問に答えると、pcap と同じフォルダに <XYZ>.fuzzer ファイルが作成されます。
mutiny.py <XYZ>.fuzzer <targetIP> を実行します。これでファジングが開始されます。ログは同じフォルダ内の <XYZ>_logs/<time_of_session>/<seed_number> ディレクトリに保存されます。
.fuzzer ファイルは人間が読める形式でコメントが付いています。これにより、どのメッセージまたはメッセージ部分をファズするかなど、ファザーファイルごとにさまざまなオプションを変更できます。
.fuzzer ファイル内にはメッセージの内容があります。これらは単に 'inbound' または 'outbound' で始まる行であり、メッセージの方向を示します。これらは Python の文字列形式で、非表示文字には '\xYY' が使用されます。これらは 'mutiny_prep.py' と Decept によって自動生成されますが、手動で修正する必要がある場合もあります。
メッセージに 'outbound' の後に 'fuzz' キーワードがある場合、それは Radamsa を通じてファズされることを示します。特定のメッセージは、引用符で囲まれた追加のメッセージデータを新しい行に置くことで行継続が可能です。この場合、2行目は1行目とマージされます。
代わりに、'sub' キーワードを使用してサブコンポーネントを示すこともできます。これにより、メッセージの別のコンポーネントを指定でき、特定の部分のみをファズしたり、メッセージプロセッサ内で便利に使用できます。
以下は任意のメッセージデータの例です:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
これにより、Mutiny は say hi and fuzz this but not this(0xdeadbeef) を送信します。0xdeadbeef は4バイトの16進数として送信されます。and fuzz this は Radamsa に渡されてファジングされますが、say hi と but not this(0xdeadbeef) はそのまま残ります。
Mutiny は 'inbound' 行があるため、上記の単一メッセージを送信した後、サーバーからの応答を待機します。サーバーの期待される応答は this is the server's expected response です。Mutiny は、サーバーが実際に送信した内容がこの文字列と一致するかどうかを確認する以外、このデータで多くのことはしません。クラッシュが発生した場合、Mutiny はサーバーからの期待される出力とサーバーが実際に応答した内容の両方をログに記録します。
mutiny_classes/ には、メッセージプロセッサ、モニター、例外プロセッサのベースクラスが含まれています。これらのファイルは、デフォルトでは .fuzzer と同じフォルダにコピーするか、.fuzzer ファイル内で 'processor_dir' として指定された別のサブフォルダにコピーできます。
これら3つのクラスにより、サーバーの応答を保存して送信メッセージを変更したり、別スレッドでターゲットを監視したり、Mutiny が例外を処理する方法を変更したりできます。
メッセージプロセッサは、ファジング実行中に呼び出されるさまざまなコールバックを定義します。これらのコールバック内では、任意の Python コードを実行できます。経験上、これらは主に3つの方法で使用されます。
最も一般的なのは、サーバーが将来の送信メッセージに追加する必要があるトークンを送信する場合です。例えば、Mutiny の最初のメッセージがログインし、サーバーがセッションIDで応答した場合、postReceiveProcess() コールバックを使用してそのセッションIDを保存できます。その後、preSendProcess() で送信データをそのセッションIDで修正できます。この例は sample_apps/session_server にあります。
メッセージプロセッサのもう1つの一般的な使用法は、ファズされたメッセージを制限または変更することです。例えば、サーバーが常に1000バイトを超えるメッセージをドロップする場合、大きなメッセージを送信する価値はないかもしれません。preSendProcess() を使用して、ファジング後かつ送信前にメッセージを短縮したり、例外を発生させたりできます。
例外を発生させることは、メッセージプロセッサが一般的に使用される最後の方法です。コールバック内では、mutiny_classes/mutiny_exceptions.py で定義された任意のカスタム例外を発生させることができます。コメント付きのいくつかの例外があり、これらは Mutiny にさまざまな動作を引き起こします。これらは通常、ログ記録、再試行、または現在の実行の中断のいずれかです。
モニターには、メインの Mutiny ファザーとは別のスレッドで実行される monitorTarget() 関数があります。その目的は、何らかの方法でホストを監視できる長時間実行プロセスを実装できるようにすることです。これは、Python で実行できる任意のものであり、ターゲット上で動作するモニターデーモンとの通信、長いファイルの読み取り、またはファジングセッションの要件に応じてホストに繰り返し ping を送信することなどが含まれます。
モニターがクラッシュを検出した場合、いつでも signalMain() を呼び出すことができます。これにより、メインの Mutiny スレッドにクラッシュが発生したことが通知され、クラッシュがログに記録されます。この関数は通常、無限ループで動作する必要があります。戻るとスレッドが終了し、再起動されないためです。
例外プロセッサは、ファジングセッション中に特定の例外に対して Mutiny が何をすべきかを決定します。最も一般的な意味では、processException() 関数は、Python および OS レベルの例外を可能な限り Mutiny のエラー処理アクションに変換します。
例えば、Mutiny が 'Connection Refused' を受け取った場合、デフォルトの応答はターゲットサーバーが回復不能な状態でダウンしたと仮定し、Mutiny は前回の実行をログに記録して停止します。これはほとんどの場合に当てはまりますが、この動作は mutiny_classes/mutiny_exceptions.py 内の任意の例外の動作に必要に応じて変更でき、クラッシュ検出とエラー修正の調整が可能です。