HTTP リクエストと Apache モジュール:創造的な攻撃ベクトル

Question

ここで少し型破りな質問:

現在、いくつかのカスタムモジュールを使用してApacheを破壊しようとしています。

テストのきっかけとなったのは、Apache が大きすぎると考えられるリクエスト (例:1 MB のゴミ）をモジュールに適切にフックし、ゴミデータの処理を強制し、カスタム モジュールでの処理の欠如により、Apache 全体が炎上しました。痛い、痛い、痛い。

この特定の問題は幸いにも修正されましたが、他にも同様の脆弱性があるのではないかという疑問が生じています。

現在、私は自由に使えるツールを使用して、生の HTTP リクエストをサーバーに送信できます (または、確立された TCP 接続を介して生データを送信できます。HTTP リクエストの形式に従っている場合は、HTTP リクエストとして解釈できます。「GET ...」）そして他のアイデアを考え出そうとしています。(Slowloris や Nkiller2 などの TCP レベルの攻撃は、 ない 現時点では私の焦点です。）

サーバーのカスタムモジュールを混乱させてサーバーの自己犠牲を引き起こす方法をいくつか考えた人はいますか?

• UTF-8が壊れていますか?(ただし、Apache がエンコードを気にしているとは思えません。生のバイトを操作しているだけだと思います。)
• ギリギリの長さの後に 0 バイトが続き、その後にジャンクが続くものですか?
• など

私は自分自身をあまり優れたテスターとは思っていません (人手不足で必要に応じてこれを行っています。残念ながら、私は Apache の内部構造について基本的な知識しか持っていないので、役立つ情報が得られることを期待しています。もしかしたら、自分のプロジェクトで同様のテストを行ったことがある人もいるでしょうか?

(stackoverflow がこの質問に適切な場所ではない場合は、申し訳ありません。他にどこに置けばいいのかわかりません。）

Answer 1

フックしている他のモジュール、およびそれらをアクティブ化するもの (または大きすぎるリクエストだけでしょうか?) に応じて、次のいくつかを試してみることをお勧めします。

• 不正なエンコーディング - 例:あなたが述べたように長すぎる utf-8 には、モジュールがそれに依存するシナリオがあります (特定のパラメーターなど)。
• パラメータ操作 - 繰り返しますが、モジュールの動作によっては、値の変更、予期されるパラメータの削除、または予期しないパラメータの追加によって、特定のパラメータがモジュールを混乱させる可能性があります。
• あなたの他の提案に反して、私は次のようなデータを検討します。 ギリギリ十分短い, 、つまり最大より 1 バイトまたは 2 バイト短いですが、さまざまな組み合わせ (さまざまなパラメータ、ヘッダー、リクエスト本文など) があります。
• 調べてください HTTP リクエストの密輸 （また ここ そして ここ) - 不正なリクエスト ヘッダーまたは無効な組み合わせ (複数の Content-Length、無効なターミネータなど) かもしれない モジュールが Apache からのコマンドを誤って解釈する原因となります。
• gzip、チャンクエンコーディングなども考慮してください。カスタム モジュールが長さチェックとデコードを順不同で実装している可能性があります。
• 部分的なリクエストはどうでしょうか？たとえば、100-Continue 応答を引き起こすリクエスト、または範囲リクエスト?
• ファジングツール、 桃, @TheRook が推奨する、これも良い方向性ですが、初めて使用するときに大きな ROI を期待しないでください。
• ソース コードにアクセスできる場合は、セキュリティ コードを重点的にレビューすることをお勧めします。または、Coverity (@TheRook が言及したように) またはそれより優れたツールのような自動コード スキャンさえも...
• ソース コードにアクセスできない場合でも、経験豊富なコンサルタント/ペンテスターに​​よる、または少なくとも自動ツール (世の中にはたくさんあります) を使用したセキュリティ侵入テストを検討してください。appscan、webinspect、netsparker、acunetix など。

Answer 2

Apache は、地球上で最も堅牢なソフトウェア プロジェクトの 1 つです。Apache の HTTPD の脆弱性を見つけるのは簡単な作業ではないため、より簡単な獲物を見つけることをお勧めします。比較すると、このような他の HTTPD の脆弱性は、 Nginx 今日見たものです（冗談ではありません）。非常によく似たソースコード漏洩の脆弱性は他にもあります。 これ そしてここにあります 別の. lhttpd sf.net では 10 年近く放置されていますが、それに影響を与えるバッファ オーバーフローが知られているため、テストするのが楽しいアプリケーションです。

プロジェクトを攻撃するときは、過去にどのような脆弱性が見つかったかを確認する必要があります。プログラマーは同じ間違いを何度も繰り返す可能性が高く、多くの場合、パターンが出現します。これらのパターンに従うことで、より多くの欠陥を見つけることができます。次のような脆弱性データベースを検索してみてください。 Nist の CVE の検索. 。ここでわかることの 1 つは、Apache モジュールが最も一般的に侵害されているということです。

Apache のようなプロジェクトは大幅にあいまいになっています。などのファジングフレームワークがあります。 桃. 。Peach はさまざまな方法でファジングを支援します。役立つ方法の 1 つは、作業用の厄介なテスト データを提供することです。ファジングは、成熟したプロジェクトにとってはあまり良いアプローチではありません。この方法を採用する場合は、私がターゲットにします Apacheモジュール できるだけ少ないダウンロードで。(警告プロジェクト 本当に ダウンロード数が少ないと、壊れたり、インストールが困難になる可能性があります。)

企業がセキュリティに懸念を抱いている場合、Coverity などの自動ソース分析ツールに多額の費用を支払うことがよくあります。国土安全保障省は、オープンソース プロジェクトをテストするためにコベリティに多額の資金を提供し、 Apache もその 1 つです. 。私が見つけたことを直接あなたに伝えることができます バッファオーバーフロー Coverity では拾えなかったファジングが発生しました。Coverity およびその他のソース コード分析ツール オープンソースのラット 多くの誤検知と誤検知が発生しますが、コード ベースに影響を与える問題を絞り込むのに役立ちます。

(初めて Linux カーネルで RATS を実行したとき、画面に strcpy() と strcat() への呼び出しが何千件も表示されていたため、椅子から転げ落ちそうになりましたが、コードを掘り下げてみると、すべての呼び出しが静的テキストを処理していました。それは安全です。）

脆弱性の研究とエクスプロイトの開発は、 とても楽しいこと. 。PHP/MySQL アプリケーションを活用して探索することをお勧めします。 ホワイトボックス. 。このプロジェクトは、コードを 1 行ずつ手動で読まないと発見できない現実世界の脆弱性が存在することを示しているため、重要です。また、攻撃に対して非常に脆弱な現実世界のアプリケーション (ブログやショップ) もあります。実際、これらのアプリケーションは両方ともセキュリティ上の問題により放棄されました。Webアプリケーションファザーのようなもの ワピティ そうしないと、acuentix がこれらのアプリケーションやそれに類するアプリケーションを強姦することになります。ブログにはコツがあります。新規インストールにはそれほど脆弱性はありません。アプリケーションを少し使用して、管理者としてログインしてみて、ブログ エントリを作成してからスキャンする必要があります。Web アプリケーションで SQL インジェクションをテストする場合は、エラー報告がオンになっていることを確認してください。phpで設定できます display_errors=On php.ini 内で。

幸運を！