Webサーバー攻撃の方法論：脆弱性スキャナーがすべてを実行するのに、なぜ手動テストに煩わされるのですか？
私は有名な認証から白い帽子ハッキング本を読んでいます。彼らは、ウェブサーバーをハッキングするための方法論は次のとおりであると言います：
- 情報収集（ドメイン名、DNS、IPなど）
- フットプリント（例：バナーグラブ）
- ウェブサイトのミラーリング
- 脆弱性スキャン
- セッションハイジャック
- パスワードクラッキング
セッションのハイジャックと情報収集を除いて、すべての弱点を見つけるためになぜAcunetix Web App ScannerやNessusを起動しないのかわかりません。
自動化できる場合、手動テストを実行するポイントは何ですか？
たとえば、脆弱性スキャナーが脆弱なCookieを見つける方法を知らない場合、およびセッションハイジャックを実行する方法を手動で見つけた場合、そのためにNessusのAcunetixをトレーニングできません。たとえそうしたとしても、それがどれほど有益であるかはわかりません。
ツールにハッキングをさせない理由を説明してください。
ここにはいくつかの前提があります。
- スキャナーはすべての脆弱性を見つけることができます
- スキャナーが脆弱性を見つけられない場合、脆弱性はありません
- すべての手動タスクを自動化できます
- 攻撃者は自動化されたツールのみを使用し、手動のアプローチは使用しません
- 手動のアプローチをオーダーメイドの自動化ツールに変えることはできません
- 脆弱性を見つけることは、脆弱性を悪用することと同じです
これらの仮定のどれも普遍的に真実ではありません。
自動化されたスキャナーは、脆弱性を見つけるプロセスをより効率的にするのに役立ちますが、完全とは言えません。スキャナーはexploit脆弱性を有用な方法で設計するようにも設計されていません。
実際には、スキャナーの結果（誤検知）を手動でテストし、手動テストを実行して、自動化ツールが見逃した可能性のあるものを探します。
攻撃者はさまざまなアプローチを使用し、ツールを作成または変更して脆弱性を悪用し、再現性と信頼性を高めます。ただし、このツールが他の状況で機能するという意味ではありません。
自動テストは基本的なしきい値です。あなたのサイト/プログラムが自動化されたテストに失敗した場合、あなたはかなり骨の折れたエラーを作りました、そしてそれはすぐに修正されるべきです（それは見つけやすいからです）。しかし、自動スキャナーから非表示にするために、開発者がSQLに1=1のチェックを追加した例をいくつか見ましたが、2=2（最新のSQLスキャナーアカウントを使用してサイトを悪用することができました。これのために）。私はそれを手動のテストと個人的な経験からしか知りませんでした。ツールで経験と直感をエンコードすることはできません。
コーディングはめちゃくちゃ複雑な活動です。つまり、エラーも複雑になる可能性があります。すべての脆弱性を探したり悪用したりするためのツールを作成することはできませんでした。
[〜＃〜] dast [〜＃〜] ツールには、アプリケーションの手動検査を通じて対処する必要があるいくつかの制限があります。
- 彼らは、アプリケーションのユースケースと誤用ケースを理解していないため、ビジネスロジックの欠陥を見つけることができません。
- 既知の脆弱性のタイプとパターンのみを見つけます。走行距離はスキャナーの成熟度レベルによって異なりますが、最高のスキャナーですべての問題を見つけることはできません。
- 多くの場合、複雑なパターンには、OAuthなどの承認プロトコルのカスタム実装など、微妙なセキュリティの問題があります。基礎となるアーキテクチャーを詳細に調査することによってのみ、ペンテスターはこれらの欠陥を見つけることができますが、自動化ツールは失敗します。
- アプリケーションの悪用可能性を検証するためのペイロードは、多くの場合、特定のアプリケーション用に作成する必要があります。スキャナーが脆弱性を疑っている場合でも、その確認はしばしば手動で行わなければなりません。
とはいえ、セキュリティスキャナーは、侵入試験機の武器として、ぶら下がっている果物を特定するための便利なツールです。作業の大部分は依然として手動です。
さらに、可能であれば、セキュリティテスターとして常にホワイトボックステストを行う必要があります。これには、ソースコードへのアクセスが含まれるため、 [〜＃〜] sast [〜＃〜] ツールも使用できます。これらのツールには同様の制限がありますが、さまざまな種類の脆弱性を見つけることができるため、付加価値が高まります。ただし、DASTツールとSASTツールを組み合わせた場合でも、特に保護プロファイルが高いアプリケーションの場合、手動テストなしでは必要なテスト深度に到達できません。
これは、同じ問題に関連する非常に最近のトピックです： なぜOpenVASはNmapと比較してすべての開いているポートを見つけないのですか？ 。要点：各ツールは異なり、異なる結果をもたらす可能性があります。偽陽性と異なるテスト方法論は言うまでもありません。
簡単に言えば、自動化されたツールは、知識に基づいた推測と解釈の結果を導き出します。ほとんどの場合、彼らはそれを正しく理解しています。しかし、ツールがどのように機能するか、そしてそれが何をするか（そしてしないか）を理解し、最適な結果を得るために調整することができる必要があります。 。
簡単な例：デフォルトでは、nmap、Openvasなどはすべてのtcp/udpポートをスキャンするのではなく、65535から数千の最も人気のあるポートの選択をスキャンします。デフォルトの設定でツールを認識していない場合は、アクティブなポートを見逃しがちです。たとえば、多くのシステム管理者は、標準の22ではなく、ランダムなポートでSSHを実行することを選択します。
自動化ツールには通常、ボタンが1つだけではなく、多くのオプションがあります。そのため、ツールの機能を理解したり、暗闇の中で撮影したりする必要があります。次に、あなたが何をしているか、何を探しているのかわからないため、監査は詳細ではなく、ほとんど価値がありません。あなたがやったことはすべて、表面を引っ掻いて、最も明白な欠陥を探すことです。
別の言い方をすると、ツールのダウンロードと実行だけでよいのであれば、なぜプロのペンテスターを雇う必要があるのでしょうか。有能なペンテスターは経験を持っており、スクリプトキディが見逃すよりもさらに進んで脆弱性を見つけることができるからです。
「ツールを実行するのと同じくらい簡単」であることはめったにありません。
インターネット上で公開されている適切に構成されたマシンには、防御メカニズムの一種が組み込まれている必要があります。この種の偵察活動を阻止するファイアウォールやIDS。
ポートスキャンアクティビティを検出すると、通常、IPアドレスをブロックするか、トラフィックを抑制し、一部のパケットを選択的にドロップするか、意図的に誤解を招く結果をハッカーに返すことを選択します。あなたは、不完全またはまったくの偽の結果に終わります。
NmapやAcunetixなどのツールはノイズが多いので、IDSによって通常は非常に簡単に特定（およびブロック）できます。これは、ツールが生成するトラフィックが通常であるためです。 ）signaturesおよびpatterns。したがって、保護されていない、または緩やかに保護されている（LAN上で）マシンをテストしているのでない限り、意味のある結果を得るには、かなり調整する必要があります。
したがって、答えは両方を実行することです：自動ツールを使用してから手動テストを実行します（特に、ツールがオープンポートのような何かを検出したが、それを悪用できなかった場合） 、または再確認したい。
脆弱性スキャナーは、存在する可能性のあるすべての脆弱性を見つけることができません。彼らは基本的に、既知の脆弱性のパターンと悪用可能性を探します。
さらに、自動化ツールを使用すると、誤検知やその他の予期しない出力が表示される場合があります。したがって、出力を評価し、より高度なペンテストを実施できる専門家が必要です。
ここでは、通常は検出に失敗したり、誤検知が発生したりする可能性があるアプリケーションセキュリティの自動スキャナーに対する一般的な難しい課題（特に偵察活動とピボット活動）を示します。
- さらにスキャンするための隠れたパラメーター検出
- さらにスキャンするための非表示または比較的参照されているURL検出
- 潜在的な誤検出から脆弱性を特定するためのビジネス/ロジックセキュリティへの影響。 CSRF攻撃の脅威は、この種の課題に属します。スキャナーには、パラメーターの特定の値が設定されている場合にのみ表示される脆弱性に関する問題もあります。