この検証方法は信頼性がありません。コマンドは実行される一方で、その出力は CGI によって構築されたシェルコマンドに消費され、クライアントに返される HTML レスポンスには反映されない可能性があります。その結果、サーバーは id の出力を含まない通常の HTTP 200 ページを返すことがあり、偽陰性を引き起こします。

この実装は、Metasploit モジュールで使用される検証ロジックに従います:

1. HTTP Basic 認証を使用して /cgi-bin/pakfire.cgi にリクエストを送信します。
2. レスポンスから IPFire のバージョンと Core Update を抽出します。
3. IPFire <= 2.19 かつ Core Update <= 110 を脆弱である可能性があるものとして扱います。
4. コマンドペイロードを OINKCODE フィールドで /cgi-bin/ids.cgi に送信します。
5. 200 以外のレスポンスを、拒否されたリクエストまたは認証の問題として扱います。
6. HTML ボディで uid=99(nobody) を検査しません。

この PoC はまた、Metasploit モジュールがサポートするコマンドペイロードファミリーに合わせて、Perl コマンドシェルペイロードを使用します。HTTP レスポンスが成功しただけではリバースシェルが接続されたことの証明にはならず、リスナーとネットワーク経路も検証する必要があります。

元のエクスプロイトとの違い

Metasploit モジュールの重要な成功基準は、予期しないレスポンスコードが無効な認証情報または拒否されたリクエストを示すことです。レスポンスボディに注入されたコマンドの出力が含まれている必要はありません。

必要条件

• Python 3
• requests
• Web インターフェースにアクセスできる有効な IPFire 認証情報
• ターゲット上の Perl インタープリター（通常 perl として利用可能）
• IPFire ホストから到達可能なリスナー

Python の依存関係をインストールします:

使用方法

1. ターゲットのバージョンのみを確認する

--password が指定されていない場合、パスワードは対話的に要求されます。コマンドにパスワードを直接記述すると、シェルの履歴やプロセスリストを通じて露出する可能性があるため、この方法が推奨されます。

2. リスナーを起動する

--lhost および --lport として指定したアドレスとポートでリスナーを使用します:

rlwrap がインストールされていない場合は、次を使用します:

3. Perl リバースシェルペイロードを送信する

通常の IPFire 自己署名 HTTPS 証明書では、--insecure/-k が必要です。これは、ラボで証明書の検証が意図的に不可能な場合にのみ使用してください。

ホストとポートの代わりに完全な URL を使用する

ターゲットは完全なベース URL として指定することもできます:

バージョンフィンガープリンティングをスキップする

これは、IPFire のバージョンがすでに独立して確認されている場合にのみ使用してください:

別の Perl パスを指定する

Perl がターゲットのデフォルトの PATH にない場合は、その絶対パスを指定します:

コマンドラインオプション

出力の解釈

ids.cgi からの HTTP 200

これは、Metasploit モジュールで使用されるものと同じ実用的な基準に従って、HTTP リクエストが CGI によって受け入れられたことを意味します。通常の HTML レスポンスが返されることが期待され、これは脆弱性チェックが失敗したことの証明にはなりません。

シェルがリスナーに届いているか確認してください。シェルが届かない場合は、コールバックアドレス、ルーティング、ファイアウォールの送信 (egress) ルール、Perl の利用可能性、選択したポートを調査してください。

HTTP 401 または HTTP 403

リクエストが許可されていません。ユーザー名、パスワード、ターゲット URL、ポート、およびアカウントが IPFire Web インターフェースにアクセスできるかどうかを確認してください。

HTTP 404

ターゲット URL または CGI パスが正しくない可能性があります。あるいは、サービスが想定される IPFire Web インターフェースではありません。

バージョンが認識されない

スクリプトは pakfire.cgi 内で期待されるバージョン文字列を見つけられませんでした。--skip-version-check を使用する前に、ターゲットを手動で確認してください。

ペイロード配信後のリクエストタイムアウト

注入されたコマンドは、コールバックを試みている間、CGI リクエストを開いたままにする可能性があります。これはシェルの確定的な証拠ではなく、リスナーを確認すべき兆候として扱ってください。

技術的なリクエストの流れ

スクリプトは HTTP Basic 認証を使用し、次のフォームフィールドを ids.cgi に送信します:

このコマンドはバッククォートで囲まれます。これは、脆弱なアプリケーションが OINKCODE の値をシェルコマンドに渡すためです。正確なリクエストの挙動は、ターゲットのバージョンとそのローカル設定によって異なります。

制限事項

• これは概念実証であり、完全なエクスプロイトフレームワークではありません。
• バージョンチェックは、参照された Metasploit モジュールの動作に基づいています。バナーが一致するすべてのターゲットが悪用可能であることを保証するものではありません。
• 200 レスポンスはリクエストが受け入れられたことを確認するものであり、リバースシェルがリスナーに到達したことを確認するものではありません。
• Perl ペイロードには、動作する Perl インタープリターと、IPFire からリスナーへのネットワーク接続が必要です。
• スクリプトは認証バイパスや CSRF の悪用を試みません。有効な認証情報が必要です。

参照

• NVD: CVE-2017-9757
• Exploit-DB 42149: IPFire 2.19 Remote Code Execution
• Exploit-DB 42369: IPFire < 2.19 Update Core 110 Remote Code Execution
• Metasploit module: ipfire_oinkcode_exec.rb
• Metasploit Perl command payload
• CWE-78: OS Command Injection

帰属

このプロジェクトは、0x09AL による公開研究および概念実証と、Metasploit コミュニティによって維持されている Metasploit モジュールに基づく教育用の Python 実装です。IPFire、Exploit-DB、または Rapid7 とは提携関係になく、その承認も受けていません。