web-dev-qa-db-ja.com

不正なSSL証明書でドメインを偽装するにはどうすればよいですか?

私は この記事 を読んでいました。2011年のComodoからの不正な証明書についてです。ドメイン偽装について話しています。

偽のWebサイトが詐欺的な証明書で保護される可能性があることを理解していますが、ドメインはまだ偽のWebサイトであり、死んだ贈り物ではありませんか?この種の攻撃は、DNSと何らかの形で関連していますか?

また、著者は、「1つの証明書はドメイン名ではなく、「グローバルトラスティ」用でした。これはおそらく、Web上の任意のドメインを完全に偽装するために使用できる悪意のあるCA証明書でした。」グローバル受託者とは一体何ですか?

10
Ryakna

侵害された証明書を悪用する方法はいくつかあります。

侵害されたWebサイトの証明書がある場合、侵害されたWebサイトのアドレスを入力するときに、サーバーにアクセスさせる必要があります。これを行うことができます:

  • DNSサーバーを制御することで、基本的にはWebサイトのURLとサーバーのIPアドレスの関連付けを変更できます。
  • DNSキャッシュポイズニング攻撃 を実行する
  • ターゲットとWebサイトの間で中間者攻撃(ルーターを所有しているなど)を実行し、その結果、彼を自分のサーバーにリダイレクトする

ルートCA証明書が危険にさらされている場合は、さらに効果的です。 「マスター」キーを持っているので、好きな人の名前で偽の証明書を偽造することができます。したがって、どのWebサイトにもなりすますことができます。これは、DNSサーバーを完全に制御できる人(インターネットの閉鎖国など)にとって非常に価値があります。なぜなら、彼らは証明書をその場で偽造し、途中で人を演じることができるからです攻撃。

11
M'vy

認証局(CA)に送信された証明書署名要求(CSR)には公開鍵が含まれているため、厄介なTLS証明書を用意するだけでは、悪いビジネスに取り掛かるのに十分ではありません。 CSRの公開鍵。最後に、被害者のDNSをハッキングしてトラフィックをリダイレクトする必要があります。セキュリティがこれほど悪い場合、TLS証明書は問題ではありません...確かにpossible TLSを危険にさらすために- not簡単または簡単です。

さて、あなたが参照する事件では、イランのハッカーがComodoのリセラーCAを危険にさらし、ハッカー自身の公開鍵をCSRとともに送信したため、CAに送信された公開鍵に関連する秘密鍵がありました。被害者からそれを盗む必要はありませんでした。つまり、それらはmostでしたが、それでもDNSをハッキングしてトラフィックをフッキーサーバーにリダイレクトする必要があります(s)。侵害された証明書が存在しても、構成されているホストにトラフィックが流れるまでは何も起こりません。

2
F1Linux