DDoS攻撃は情報を明らかにしたり、ハッキングを仕掛けたりするために使用できますか?私の理解では、DDoSまたはDoSのすべてのポイントは、すべてのリソースを消費するか、サーバーを過負荷にしてサーバーをクラッシュさせることです。そして、それがDDoSを行う唯一の理由です。
DDoSは情報の取得に使用されていると聞きました。それは本当ですか、それとも完全に偽ですか?
DDoSは確かに、攻撃者に応答時間、負荷能力、ルーティングに関する情報を提供します。
また、インシデントが内部および外部でどのように処理されるか、およびどのように一般に報告されるかについての情報も提供します。
しかし、これは主な用途ではありません。
一般に、DDoSの2つの主な理由は次のとおりです。
最初の方法はよく知られており、非常に人気があり、比較的簡単に実行できます。大規模な攻撃に対する唯一の防御策は、大量のDDoS軽減サービスです。
2つ目はほとんど使用されませんが、攻撃者のツールセットの一部と見なされています。インシデントレスポンスチームをロードすると、侵入の検出が困難になり、攻撃の本当の理由を隠すことができ、DDoSからの多数のログエントリの中の侵入の証拠を隠すことができます。
完全な答えは、攻撃と攻撃対象に依存するので、私はそれを一般的にしておきます。
DoSは副作用として情報を漏らす可能性があります。以前は、スイッチがネットワークで使用され、マシンが他の2つのマシン間の通信をリッスンするのを防いでいました。設計上の問題により、スイッチに対してDoS攻撃を開始することにより、これを大きな衝突ドメインに変えることができ、通信を再び聞くことができます。攻撃の説明:スイッチは、どのマシンがどのポートに接続されているかを学習します。マシンがパケットを別のマシンに送信すると、スイッチはメモリ内でこのマシンがどのポートにあるかを調べ、トラフィックをこのポートのみに転送します。別のポートのマシンはトラフィックを認識しません。スイッチのメモリに収まるマシンよりも多くのマシンがネットワーク上にある場合、問題が発生します。一般的な動作は次のとおりです。
特に一般的なのは最初のタイプでした。攻撃者は、アナウンスメントブロードキャストでDoSingすることにより、このポートに大量のマシンがあるように見せかけることができます。
DoSに関連するもう1つの攻撃は、セキュリティダウングレード攻撃です。 AとBの2つのサブシステムで構成されるシステムがあります。Bは、追加のセキュリティチェックを行うためにAによって使用されます。 Bが時間内に応答しない場合、Aはこのチェックをスキップし、成功したと見なします。攻撃者がシステムBをDoSできる場合、システムAのセキュリティチェックに合格するだけでよいので、より簡単なゲームになります。一部のシステムは、システムAの可用性が重要であり、攻撃者がシステムBをDoSしたり受け入れたりすることを誰も考えなかったため、このように設計されています。リスク。実際の攻撃の詳細はお伝えできませんが、一部のアンチスパムブラックリストはこのように機能します。
一部の高度なグループ/組織は、セキュリティスタッフの焦点をDDoSのターゲットに引き付けるか、DDoSトラフィック間の攻撃トラフィックを隠すことにより、実際の攻撃をそらすために(D)DoS攻撃を開始することも知られています。
もう1つのオプションは、その量のトラフィックが必要だが、それを(D)DoSする必要がないことです。たとえば、SSLに対する攻撃には、情報を回復/操作するのに十分なパケットが必要です。ここで、DoSはトラフィック量の副作用になります。
Denial of Service攻撃は、分散されているかどうかにかかわらず、リソースを共有するマシンを正常に識別するために使用できます。サービスをハッキングしたい場合は、他のサービスを監視しながら、サービスに対して攻撃を仕掛けることができます。これらも表示されない場合は、同じマシンでホストされている可能性があります。これらの他のサービスは、ハッキングされやすく、必要なサービスにアクセスするための「バール」として使用できます。
これは、Torネットワークで hidden services に対して使用すると壊滅的になる可能性があります。特定の個人が隠しサービスをホストしていると信じる理由がある場合は、同じハードウェアまたは同じデータセンターで開いているサービスに対して攻撃を開始することでこれをテストできます。隠しサービスがダウンした場合は、推測が正しいこと、および隠しサービスの背後にあるIDが侵害されていることを確認した可能性があります。
これをテストするたびに、1つのサンプルが得られますが、これは誤検知の可能性があります。ランダムな間隔で十分な回数それを行うと、正しい可能性を高めることができます。
DDOS攻撃を使用して情報を入手することは可能です。他の攻撃がより長く検出されないようにするためにインフラストラクチャ情報の取得またはインシデントレスポンスチームの過負荷に焦点を当てているRory AlsopとH. Iddenによる回答に加えて、他にいくつかの可能性があります。
アプリケーションの自動スケーリング-DDOS攻撃を自動スケーリングするアプリケーションプラットフォームで作業する場合、DDOS攻撃が何かを実行するために自動スケーリングするという事実を利用する場合があります。これは、他の種類の攻撃または情報と協調する必要がありますが、一般的な考え方は、「再起動」プロセスを悪用するのに十分な知識がある場合、DDOSを使用して新しいサーバーを強制的にオンライン魔女が再起動プロセスを実行するというものです。 、エクスプロイトを許可します。これは、既存のセキュリティ問題に追加されることに注意することが重要です。これは、まったく異なるエクスプロイトをオンラインにする(またはテストする)ツールにすぎません。私が考えることができるサンプルは、パブリックgithubリポジトリでコードベースをホストしているProductionサーバーで、scalesが新しいコードをサーバーにプルしてから起動します。そのgithubリポジトリに不正なコードを追加し(正しく管理されていない場合)、強制的に再起動して悪用することができます。
先着順アプリケーション-プロセスの一部で「先着順」のアプリケーションがいくつかあります。 IRC(コメントから)は例ですが、他にもあります。先着順のアプローチでユーザーのために何かを予約するサービスは、DDOSを介して悪用される可能性があります。特定の人が自分のものになるまで、または再起動を強制し、再起動後に「スロット」で別のチャンスを得るまでのスロット。これらはかなり一般的であり、これを認証に使用するサービスは少し変わっていますが、前代未聞ではありません。事実ライセンスサービスはこれを常に行います。「ABC」のライセンスを持つ最初のユーザーはABCの資格のあるユーザーです。再起動後にそのデータが失われた場合、DDOSがその再起動を引き起こし、ドアに足を踏み入れる可能性があります。
スタートアップの脆弱性-念のため、サーバーの起動によりサービスが「オン」のままになることが何度かありました。たとえば、緊急時のアクセスが必要な場合に備えて、再起動後もSSHパスワードをオンのままにし、数時間後にオフにしてみましょう。または、再起動後、FTPが30分間オンになります。これはネットワークアプライアンスでより一般的です。 「最初の2分間の安全でないwifiアクセス」や「何でも2分間何でもアップロードできる」など。通常、これはアップグレード/更新メカニズムの一部です。たとえば、Ciscoルーターは、再起動後に検出したTFTPデータを受け入れる場合があります。一部のコンピューターは、再起動時にネットブートサーバーをリッスンします。 DDOSは再起動を開始し、「不正なコード」の侵入を許します。
本質的に、DDOSはそれ自体でいくつかのことを伝えることができますが、通常、それ自体では役に立たないものだけを伝えます。 DDOSを他の攻撃方法と組み合わせると、非常に効果的です。
注ここで使用する方法はラボで機能しますが、セキュリティチーム(または通常のIT部門)にとってはあまり効果がありません。それらは実際に存在しますが、攻撃者はDDOSを実行している誰かよりもはるかに内部のアクセス/知識を取得している必要があります。
これが起こっている実例はSteamです。彼らはクリスマスの日にDoS攻撃を経験しました。これに応じて、Steamサービスのキャッシュルールを変更したため、顧客は引き続きストアページにアクセスできました。残念ながら、最終的には構成エラーが発生し、ユーザーに他のユーザーの個人情報が表示されることがありました。
システムは、システムの負荷が高いときに予期しない動作をする場合があり、セキュリティの脆弱性につながる可能性があります。ハッカーがこれを悪用する可能性はありますが、ハッカーがこれを計画する可能性は低く、悪用は予測不可能です。また、負荷が高いためにサーバーの応答が遅くなる可能性があるという事実にも対処する必要があります。
理論的には、DDOS攻撃は、別の回答で述べられているようにエクスプロイトを妨害するだけでなく、それと組み合わせることもできます。
サーバーが特定の方法で接続されたときに情報を返した Heartbleedバグ について考えてみます。
DDOS攻撃でサーバーに接続し、この方法でリリースされた情報を収集することにより、サーバーから取得した情報を増やすことができます。
サーバーの起動時間の強制
コメントで接線的に言及されているが、他の非常に優れた回答では取り上げられていないことの1つは、アプリケーション/サーバーがいつ起動したかを知ることが役立つ場合があることです。たとえば、ある種の恐ろしく安全でない乱数ジェネレータ(セキュリティ関連のタスクには決して使用すべきではありませんが、常に時々使用されます)は、システム時刻を「ランダム」シードとして使用します。
その場合、RNGがシードされたとき(できれば数分以内の精度)を推定でき、ジェネレーターの出力のいくつかのサンプルがある場合、シードを見つけてRNG状態を再構築し、将来のトークンを予測するのはかなり簡単です。 。さて、通常、サーバーはその開始時間を公開すべきではありません(ただし、いくつかは常にそうですが)。ただし、DDoS攻撃を使用してサーバーを強制的に再起動できる場合は、サーバーの開始時間を知ることができます。
これにより、セッションハイジャックなどのさまざまなトークンベースの攻撃につながる可能性があります。
これは修正される可能性がありますが、グループポリシーの初期の頃は、グループポリシーサーバーの過負荷が悪用の1つであり、一部の構成ではローカルポリシーが適用されていました。したがって、ローカルポリシーを最小限に設定します。拒否は、サーバーポリシーが権限を減らしたエクスプロイトとしてのみ使用できます。私はすべての用語が正しいわけではないことを知っています。グループポリシー管理を行ってからしばらく時間が経っています。
ルーターを危険にさらしたが、そのルーターが必要なトラフィックを取得していなかったとします。良いルーターでDoSを実行して、ハックルーターへのトラフィックを取得することができます。
DoS攻撃は、競合状態のエクスプロイトと一緒に使用できると思います。サーバーの負荷が高い場合、エクスプロイトは使いやすくなります。
ただし、ルーティング、応答時間、内部のインシデント処理に関する以前の回答で示したように、DoS攻撃だけでもいくつかの情報が得られる可能性があります。