情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt80000009sgk-att/2022r04h_sc_pm1_qs.pdf

はじめまして
午後１  問１  設問１（４）の問題ですが、正式回答は、サーバ証明書を検証し通信相手がWサーバであることを確認する実装でした。

ここで質問ですが、攻撃者が仮にＷサーバに似たドメインを正式に取得して、サーバ証明書も正式に取得した場合でもちゃんとエラー表示（検証失敗）になるのでしょうか？

全く別物ですが、SPFにも似たような状況がありましたよね。

キャッシュポイズニングされた偽サイトにアクセスしても攻撃者が証明書まで発行していたら、検証成功するのではと思いましたので、どこで失敗するのかを具体的に示して教えていただけたら幸いです。

リンクが春季のようです

失礼しました！

https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt80000008smf-att/2022r04a_sc_pm1_qs.pdf

>ここで質問ですが、攻撃者が仮にＷサーバに似たドメインを正式に取得して、
>サーバ証明書も正式に取得した場合でもちゃんとエラー表示（検証失敗）に
>なるのでしょうか？
なりません。
正規の証明書なので、証明書の検証は成功します。

>キャッシュポイズニングされた偽サイトにアクセスしても攻撃者が証明書まで
>発行していたら、検証成功するのではと思いましたので、どこで失敗するのかを
>具体的に示して教えていただけたら幸いです。
すみませんが、この質問は上の質問とリンクしていません。
キャッシュポイズニングで誘導された偽サイトは、クライアント側では本物の
サイトのFQDNとして認識されています。
そのため、
・攻撃者はそもそも証明書が用意できい
・攻撃者はが偽の証明書を用意しても、証明書の件検証で失敗する
となります。

スレ主様はFQDNについて誤解されていませんか。
証明書の検証において、FQDNはサーバ側で設定されるものではなく、
クライアント側で認識したものがFQDNになります。

>攻撃者が仮にＷサーバに似たドメインを正式に取得して、サーバ証明書も正式に取得した場合でもちゃんとエラー表示（検証失敗）になるのでしょうか？

→証明書の発行手順を確認すれば分かりますが、信頼できる認証局が身元不明の攻撃者に証明書を発行しないと考えますので、その仮定は杞憂です(ドメイン認証(DV)、組織認証(OV)、EV認証(EV)の3段階の認証レベルで審査過程が異なるアレです)。
攻撃者は信頼できない認証局(WEBブラウザに登録されていないルート証明書)か自己署名の証明書でユーザを騙そうとするため、証明書の検証で警告が出ます。

お二方回答ありがとうございます。
追加ですが質問させてください。

ov証明書やev証明書は確かに組織と存在性とかの審査があるとのことで、認証局が発行を許可しない可能性があるというのはおっしゃるとおりだと理解しました。
しかしこれがdv証明書だったら認証局も発行してくれる可能性ってないのでしょうか。←追加質問

私が考えた不正ダウンロードが成功させる手段は以下の通りだと思いました。

仮に
WサーバのサイトURLが
"HTTPS://www.servw.com"でIPアドレスX.X.X.X（信頼ある認証局からDV証明書発行済み）

攻撃者の偽WサーバのサイトURLが
"HTTPS://www.servww.com"でIPアドレスY.Y.Y.Y（信頼ある認証局からDV証明書発行済み）
だった場合

①製品Rが"HTTPS://www.servw.com"にアクセス開始しようとする
②ＤＮＳのキャッシュがない場合、製品Rがwww.servw.com（FQDN)の名前解決を行う
③ＤＮＳキャッシュポイズニングを受けてwww.servw.com（FQDN)のIPアドレスはY.Y.Y.Yとして製品Rにキャッシュされてしまう。
④製品Rが"HTTPS://www.servww.com"にアクセスしてしまう
⑤現在アクセスしているwww.servww.comというFQDNと攻撃者の証明書のcommonNameが一致する
⑥サーバ証明書のエラーがでず、偽のファームウェアをダウンロードしてしまう

このような感じで、エラー警告がでず、偽のファームウェアをダウンロードさせることができるのではないかと思ったのですが、どうでしょうか。←追加質問
（おそらく間違っているとおもいますが。。。。）

>⑤現在アクセスしているwww.servww.comというFQDN

この部分は、pixさんの以下の指摘のようになります。
>証明書の検証において、FQDNはサーバ側で設定されるものではなく、
クライアント側で認識したものFQDNがになります。

なのでクライアントのFQDNとサーバーのコモンネームが異なり、証明書エラーが出ます。
 
もし攻撃するのであれば、www.servww.comへのリンクを貼ったメールを送り、クリックさせるのが定番です。

クライアント側で認識したものがFQDNになるについて、調べてみてようやくこんな感じかなって思いました。

WサーバのサイトURLが
"HTTPS://www.servw.com"でIPアドレスX.X.X.X（信頼ある認証局からDV証明書発行済み）

攻撃者の偽WサーバのサイトURLが
"HTTPS://www.servww.com"でIPアドレスY.Y.Y.Y（信頼ある認証局からDV証明書発行済み）
だった場合

①製品Rが"HTTPS://www.servw.com"にアクセス開始しようとする
②ＤＮＳのキャッシュがない場合、製品Rがwww.servw.com（FQDN)の名前解決を行う
③ＤＮＳキャッシュポイズニングを受けてwww.servw.com（FQDN)のIPアドレスはY.Y.Y.Yとして製品Rにキャッシュされてしまう。
④IPアドレスY.Y.Y.Y宛に"HTTPS://www.servw.com"要求リクエストを送る。
⑥要求リクエストのwww.servw.comというFQDN（これがクライアント側で認識したFQDN？）とwww.servww.comという証明書のCNが一致しない
⑤よって検証失敗でエラー

これであっていますでしょうか。

ということはつまり情報試験で良く問われるＤＮＳキャッシュポイズニングの問題って全部ＨＴＴＰ通信を前提とした問題だったってことなんでしょうか。これをみるとＨＴＴＰＳを実装しておけば、仮にＤＮＳキャッシュポイズニング受けてもほぼ問題ないように思えますね。
少し混乱してきました。

>これであっていますでしょうか。
はい。あっています。

>ということはつまり情報試験で良く問われるＤＮＳキャッシュポイズニングの
>問題って全部ＨＴＴＰ通信を前提とした問題だったってことなんでしょうか。
>これをみるとＨＴＴＰＳを実装しておけば、仮にＤＮＳキャッシュポイズニング
>受けてもほぼ問題ないように思えますね。
はい。WebシステムにおいてDNSキャッシュポイズニングへの最大の対処措置が
HTTPSによる証明書の検証になります。

しかし、DNSに登録されているのはWebシステムだけではありません。
その他、メールシステムや業務システムなどTLSと証明書を利用していない
システムの場合、DNSキャッシュポイズニングの攻撃を受けてしまいます。

いままでの勘違いしていた知識がアップデートできた感じがして、とてもよかったです。
回答してくれた皆様、本当にありがとうございます。