12

ここで少し非正統的な質問:

私は現在、少数のカスタム モジュールで Apache を壊そうとしています。

テストを引き起こしたのは、Apache が大きすぎると見なす要求 (例えば 1 MB のゴミ) を適切にフックされたモジュールに内部的に転送し、不要なデータを処理するよう強制することです。炎上する。ああ、ああ、ああ。

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

現在、生のHTTPリクエストをサーバーに送信できるツールがあります（または、確立されたTCP接続を介して生データを送信できます。これは、HTTPリクエストの形式に従っている場合、HTTPリクエストとして解釈できます。 ...") そして、私は他のアイデアを考え出そうとしています. (Slowloris や Nkiller2 のような TCP レベルの攻撃は、現時点では私の焦点では​​ありません。)

サーバーのカスタムモジュールを混乱させてサーバーの自己焼身のポイントにする方法について、いくつかの良いアイデアを持っている人はいますか?

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

私は自分自身を非常に優れたテスターだとは考えていません (必要に迫られてマンパワーが不足しているため、これを行っています。残念ながら、Apache の内部構造について基本的な知識しか持っていません)。洞察に満ちた応答または 2 つまたは 3 つを期待しています。自分のプロジェクトで同様のテストを行ったことがある人もいるでしょうか?

(スタックオーバーフローがこの質問の適切な場所でない場合は、お詫びします。他にどこに置くべきかわかりません。)

4

2 に答える 2

11

Apache は、地球上で最も堅固なソフトウェア プロジェクトの 1 つです。Apache の HTTPD の脆弱性を見つけるのは簡単なことではありません。比較すると、今日私が見たNginxの脆弱性など、他の HTTPD の脆弱性はより一般的です (冗談ではありません)。非常によく似たソース コード開示の脆弱性が他にもありました。 lhttpdは、ほぼ 10 年間 sf.net で放棄されており、影響を与える既知のバッファー オーバーフローがあり、テストするのが楽しいアプリケーションになっています。

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

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

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

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

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

幸運を！

于 2010-06-01T23:05:04.947 に答える
4

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

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