HOME»情報処理安全確保支援士掲示板»H29 春午後2問１設問２（１）
投稿する
そのような事はどこに書かれていますか？
何のチェックでしょうか？
マルウェアというか証明書はブラウザが行うのではないですか？
ますますわかりません。
P8 この段落のタイトルが[マルウェアのHTTPS通信の解析］です。
この段落では、図5の構成を理解する必要があります。
この図から、中継サーバを用意してHTTPSの暗号化を解除してパケット
キャプチャを行うという意図を読み取らなければいけません。
証明書のチェックは被疑サーバと通信するクライアントが行います。
一般的なPCの使用時はWebブラウザがクライアントとなって
証明書をチェックします。
マルウェアの場合は、マルウェア自身がクライアントとなって直接
被疑サーバと通信します。
この時証明書をチェックするのはマルウェアになります。
証明書のチェックとは
・証明書が信頼できる機関から発行されているか
・証明書が期限切れではないか
・証明書のFQDNが不適切ではないか
などをチェックします。
正常に通信できないと気付かれてしまい、通信が終了してしまします。
証明書は偽造なのですか？
証明書がなくても通信はできるのではないでしょうか
被疑サーバの本物の証明書（と秘密鍵）は被疑サーバに配置されており、
被疑サーバの管理者しか入手することはできません。
（厳密には証明書はだれでも手にはいります。秘密鍵は無理です。）
そのため、今回解析用被疑サーバと同じFQDNをもった証明書と秘密鍵を生成して
中継サーバ1に配置します。
今回解析用に生成した証明書と秘密鍵は、本物の被疑サーバの証明書と秘密鍵では
ないことから便宜的に偽装証明書と呼びました。
HTTPS通信では証明書は必須になります。
HTTP通信ならば必要ありません。
しかし、P4の[不審な通信の発見]で、不審な通信はHTTPSで行われていると
明記されているので、調査対象のプロトコルはHTTPSになります。
もしマルウェアがHTTPで通信しており、HTTPSのように暗号化されていな
ければ、今回のように詳細検証環境や偽装証明書を用意することなく
簡単にパケットキャプチャできていました。
通常はそうです。通常でしたらHTTPSで暗号化されている通信の中身は
パケットキャプチャしてもわかりません。
しかし、今回のシナリオはマルウェアと被疑サーバはHTTPSで通信している間に
強引に割り込んで、力技でHTTPに復号-パケットキャプチャ-再度HTTPSに暗号化して
通信するというシナリオです。
そのためには、
・マルウェアを隔離・だますための詳細検証環境
・被疑サーバになりすますための偽装証明書の準備
など手間をかけています。
ここまで準備すれば、たとえHTTPS通信であっても、HTTPに変換して
パケットキャプチャすることが可能になります。
復号というのはHTTPS->HTTPに変換することを指します。
暗号化通信:HTTPS
非暗号化通信:HTTP
です。
いいえ。違います。
最近タチの悪い荒らし行為に度々巻き込まれ、相手をしてしまっただけです。
それでも、書き込みが他の人に読まれて理解に役立てれば無駄ではなかったと思います。
くまさんとpixさんではなく、くまさんとykさんです。[0926]を見て下さい。
それにしても(No.15)であのコメントですから、ズッコケそうになりました。
いままで説明した時間を返してくれと言いたいですね。
pixさんも復習になりますし、閲覧者も勉強になりますのでwin-winです。
スレ主だけが変な人だったということです。
今回の投稿は閲覧者を笑わせて試験前に少しリラックス出来たことはあるかもしれません。
いつも詳しい解説有難うございます。
わからない人に説明するには高い知識と能力が要求されますね。
いろいろな質問に回答されるpixさんを尊敬いたします。
変な相手にも誠実な対応で好感が持てます。
やばそうな人だと感じたら早めに切り上げることも必要かなと思いました。
あまり無理をなさらずに今後も詳しい解説お願いいたします。
H29 春午後2問１設問２（１） [0949]
くまさん(No.1)
マルウェアがHTTPS通信を行う際、サーバ証明書の検証を行っている可能性を考慮し、検証が成功するよう、②サーバ証明書を発行し、図5の環境に、サーバ証明書と、それに対応する秘密鍵を組み込んだ。
②について、発行する証明書において、サブジェクトのコモンネームは、どのサーバの何を組み込むべきか。
A.被疑サーバのFQDN
何の為に証明書を組み込むのでしょうか？
マルウェアの攻撃が止めらるのでしょうか？
さっぱり意味が分かりません。
②について、発行する証明書において、サブジェクトのコモンネームは、どのサーバの何を組み込むべきか。
A.被疑サーバのFQDN
何の為に証明書を組み込むのでしょうか？
マルウェアの攻撃が止めらるのでしょうか？
さっぱり意味が分かりません。
2022.09.30 11:55
pixさん(No.2)
★SC ダイヤモンドマイスター
問題の趣旨をミスリードされています。
攻撃を止めるためではなく、HTTPS通信の内容を解析するためにこのような
手間のかかる準備を行っています。
被疑PC（マルウェア）は被疑サーバへ被疑PC内部の情報を送信していると
思われます。
ですが、被疑PC（マルウェア）-被疑サーバの通信はHTTPSで暗号化されて
います。
そのため、途中経路にパケットキャプチャ装置を挟んでも通信の内容を
知る事はできません。
今回は被疑PC（マルウェア）-被疑サーバを調査するために特別に詳細解析
環境を準備しました。
詳細解析環境とはマルウェアを閉じ込めるような檻の役割を果たします。
閉じ込められていることを知らないマルウェアは、被疑サーバへ通信を開始します。
詳細解析環境には被疑サーバのふりをする中継サーバ1を用意します。
マルウェアは中継サーバ1を被疑サーバと信じて通信します。
もし、マルウェアがこの時HTTPS通信用の証明書のFQDNを厳密にチェックしている場合、
FQDNが中継サーバ1だと、偽のサーバと見破られてしまいます。
そのため、中継サーバ1が完全に被疑サーバになりきるためには、中継サーバ1に
被疑サーバと同じFQDNを持った証明書を導入しておく必要があります。
これによりマルウェアを完全に欺くことができます。
その後の流れですが、
・中継サーバ1が一旦HTTPSを解除しHTTPに通信を変換し中継サーバ2と通信する
・その間にパケットキャプチャ装置を配置。通信はHTTPで暗号化されていないため
通信の内容を読み取る事が可能となる
・中継サーバ2はマルウェアのふりして、被疑サーバとHTTPS通信を行う
・戻りの被疑サーバ-被疑PC（マルウェア）の通信はこれと逆のことを行う
となります。
攻撃を止めるためではなく、HTTPS通信の内容を解析するためにこのような
手間のかかる準備を行っています。
被疑PC（マルウェア）は被疑サーバへ被疑PC内部の情報を送信していると
思われます。
ですが、被疑PC（マルウェア）-被疑サーバの通信はHTTPSで暗号化されて
います。
そのため、途中経路にパケットキャプチャ装置を挟んでも通信の内容を
知る事はできません。
今回は被疑PC（マルウェア）-被疑サーバを調査するために特別に詳細解析
環境を準備しました。
詳細解析環境とはマルウェアを閉じ込めるような檻の役割を果たします。
閉じ込められていることを知らないマルウェアは、被疑サーバへ通信を開始します。
詳細解析環境には被疑サーバのふりをする中継サーバ1を用意します。
マルウェアは中継サーバ1を被疑サーバと信じて通信します。
もし、マルウェアがこの時HTTPS通信用の証明書のFQDNを厳密にチェックしている場合、
FQDNが中継サーバ1だと、偽のサーバと見破られてしまいます。
そのため、中継サーバ1が完全に被疑サーバになりきるためには、中継サーバ1に
被疑サーバと同じFQDNを持った証明書を導入しておく必要があります。
これによりマルウェアを完全に欺くことができます。
その後の流れですが、
・中継サーバ1が一旦HTTPSを解除しHTTPに通信を変換し中継サーバ2と通信する
・その間にパケットキャプチャ装置を配置。通信はHTTPで暗号化されていないため
通信の内容を読み取る事が可能となる
・中継サーバ2はマルウェアのふりして、被疑サーバとHTTPS通信を行う
・戻りの被疑サーバ-被疑PC（マルウェア）の通信はこれと逆のことを行う
となります。
2022.09.30 12:31
くまさん(No.3)
>今回は被疑PC（マルウェア）-被疑サーバを調査するために特別に詳細解析環境を準備しました。
そのような事はどこに書かれていますか？
>HTTPS通信用の証明書のFQDNを厳密にチェック
何のチェックでしょうか？
マルウェアというか証明書はブラウザが行うのではないですか？
ますますわかりません。
2022.09.30 13:51
pixさん(No.4)
★SC ダイヤモンドマイスター
>そのような事はどこに書かれていますか？
P8 この段落のタイトルが[マルウェアのHTTPS通信の解析］です。
この段落では、図5の構成を理解する必要があります。
この図から、中継サーバを用意してHTTPSの暗号化を解除してパケット
キャプチャを行うという意図を読み取らなければいけません。
>マルウェアというか証明書はブラウザが行うのではないですか？
>ますますわかりません。
証明書のチェックは被疑サーバと通信するクライアントが行います。
一般的なPCの使用時はWebブラウザがクライアントとなって
証明書をチェックします。
マルウェアの場合は、マルウェア自身がクライアントとなって直接
被疑サーバと通信します。
この時証明書をチェックするのはマルウェアになります。
証明書のチェックとは
・証明書が信頼できる機関から発行されているか
・証明書が期限切れではないか
・証明書のFQDNが不適切ではないか
などをチェックします。
2022.09.30 14:01
pixさん(No.5)
★SC ダイヤモンドマイスター
補足します
この詳細解析環境で行っている動作は、一般的なWAFの動作を
マルウェア解析用に適用したものです。
一般的なWAFはオリジンサーバのFQDNをWAFが持つため、FQDNを
名前解決するとWAFへ接続されます。
WAFの内部では
・HTTPSの復号
・パケットの検査
・必要であればHTTPSの再暗号化（オリジンサーバがHTTPの場合は不要）
・オリジンサーバへの通信
を行っています。
通常、DNSサーバへ被疑サーバのFQDNを名前解決すると実際の被疑サーバの
IPアドレスを返してしまいます。
そのため、この詳細解析環境では
・解析用DNSサーバ
・解析用プロキシサーバ
を用いて、強制的に接続先を中継サーバ1へ変更しています。
もしこの問題が難しいと感じるようであれば
・HTTPS
・証明書
・WAF
のあたりを重点的に学習した方がよろしいかと思います。
この詳細解析環境で行っている動作は、一般的なWAFの動作を
マルウェア解析用に適用したものです。
一般的なWAFはオリジンサーバのFQDNをWAFが持つため、FQDNを
名前解決するとWAFへ接続されます。
WAFの内部では
・HTTPSの復号
・パケットの検査
・必要であればHTTPSの再暗号化（オリジンサーバがHTTPの場合は不要）
・オリジンサーバへの通信
を行っています。
通常、DNSサーバへ被疑サーバのFQDNを名前解決すると実際の被疑サーバの
IPアドレスを返してしまいます。
そのため、この詳細解析環境では
・解析用DNSサーバ
・解析用プロキシサーバ
を用いて、強制的に接続先を中継サーバ1へ変更しています。
もしこの問題が難しいと感じるようであれば
・HTTPS
・証明書
・WAF
のあたりを重点的に学習した方がよろしいかと思います。
2022.09.30 14:23
くまさん(No.6)
証明書は通信を復号するものではないので関係ないと思います。
2022.09.30 14:23
pixさん(No.7)
★SC ダイヤモンドマイスター
すみません
補足事項と投稿時間がかぶってしまいました
証明書は通信を復号するためではなく、マルウェアに中継サーバ1を
被疑サーバと思い込ませるために利用します。
そのためにFQDNが被疑サーバである偽装した証明書を中継サーバ1に
導入します。
そうすることによって、HTTPS通信の際に、マルウェアが中継サーバ1を
被疑サーバと誤認し、通信を行うようになります。
もし、偽装した証明書を導入していないとマルウェアは被疑サーバと
正常に通信できないと気付かれてしまい、通信が終了してしまします。
これでは当初の目的であるパケットキャプチャを実行できなくなってしまいます。
補足事項と投稿時間がかぶってしまいました
証明書は通信を復号するためではなく、マルウェアに中継サーバ1を
被疑サーバと思い込ませるために利用します。
そのためにFQDNが被疑サーバである偽装した証明書を中継サーバ1に
導入します。
そうすることによって、HTTPS通信の際に、マルウェアが中継サーバ1を
被疑サーバと誤認し、通信を行うようになります。
もし、偽装した証明書を導入していないとマルウェアは被疑サーバと
正常に通信できないと気付かれてしまい、通信が終了してしまします。
これでは当初の目的であるパケットキャプチャを実行できなくなってしまいます。
2022.09.30 14:31
くまさん(No.8)
＞もし、偽装した証明書を導入していないとマルウェアは被疑サーバと
正常に通信できないと気付かれてしまい、通信が終了してしまします。
証明書は偽造なのですか？
証明書がなくても通信はできるのではないでしょうか
2022.09.30 14:59
pixさん(No.9)
★SC ダイヤモンドマイスター
>証明書は偽造なのですか？
被疑サーバの本物の証明書（と秘密鍵）は被疑サーバに配置されており、
被疑サーバの管理者しか入手することはできません。
（厳密には証明書はだれでも手にはいります。秘密鍵は無理です。）
そのため、今回解析用被疑サーバと同じFQDNをもった証明書と秘密鍵を生成して
中継サーバ1に配置します。
今回解析用に生成した証明書と秘密鍵は、本物の被疑サーバの証明書と秘密鍵では
ないことから便宜的に偽装証明書と呼びました。
>証明書がなくても通信はできるのではないでしょうか
HTTPS通信では証明書は必須になります。
HTTP通信ならば必要ありません。
しかし、P4の[不審な通信の発見]で、不審な通信はHTTPSで行われていると
明記されているので、調査対象のプロトコルはHTTPSになります。
もしマルウェアがHTTPで通信しており、HTTPSのように暗号化されていな
ければ、今回のように詳細検証環境や偽装証明書を用意することなく
簡単にパケットキャプチャできていました。
2022.09.30 15:14
くまさん(No.10)
元々https通信しているので証明書をインストールする必要はないのでは？という意味です。
また、httpsであればキャプチャしても暗号化されているので中身は分からないはずです
また、httpsであればキャプチャしても暗号化されているので中身は分からないはずです
2022.09.30 15:27
pixさん(No.11)
★SC ダイヤモンドマイスター
この投稿は投稿者により削除されました。(2022.09.30 15:41)
2022.09.30 15:41
pixさん(No.12)
★SC ダイヤモンドマイスター
>元々https通信しているので証明書をインストールする必要はないのでは？
>という意味です。
>また、httpsであればキャプチャしても暗号化されているので中身は分から
>ないはずです
通常はそうです。通常でしたらHTTPSで暗号化されている通信の中身は
パケットキャプチャしてもわかりません。
しかし、今回のシナリオはマルウェアと被疑サーバはHTTPSで通信している間に
強引に割り込んで、力技でHTTPに復号-パケットキャプチャ-再度HTTPSに暗号化して
通信するというシナリオです。
そのためには、
・マルウェアを隔離・だますための詳細検証環境
・被疑サーバになりすますための偽装証明書の準備
など手間をかけています。
ここまで準備すれば、たとえHTTPS通信であっても、HTTPに変換して
パケットキャプチャすることが可能になります。
2022.09.30 15:42
くまさん(No.13)
複合できるのであれば普通にHTTPS通信をキャプチャすればいいのではないでしょうか？
2022.09.30 16:11
pixさん(No.14)
★SC ダイヤモンドマイスター
>複合できるのであれば普通にHTTPS通信をキャプチャすればいいのでは
>ないでしょうか？
復号というのはHTTPS->HTTPに変換することを指します。
暗号化通信:HTTPS
非暗号化通信:HTTP
です。
2022.09.30 16:15
くまさん(No.15)
結論は何の為に証明書を組み込むのかわかりません
2022.09.30 16:23
pixさん(No.16)
★SC ダイヤモンドマイスター
以下に流れをまとめます
・HTTPSを強制的にHTTPに変換して、パケットキャプチャを行いたい
・そのためには、中継サーバ1に偽装証明書を導入し、マルウェアに
中継サーバ1を被疑サーバと思わせて通信する必要がある
・中継サーバ1はHTTPSをHTTPに復号化して、中継サーバ2と通信する
・パケットキャプチャは中継サーバ1-中継サーバ2間のHTTP通信を
キャプチャする
何回も解説しておりますが、中継サーバ1を被疑サーバと思わせるためには、
中継サーバ1に被疑サーバのFQDNを持った偽装証明書の導入が必須になります。
中継サーバ1に被疑サーバのFQDNを持った偽装証明書を導入していない場合、
マルウェアはこの通信が偽物と判断し、通信を終了してしまします。
もしこの解説で不明のようでしたら、一旦Web技術（HTTP/HTTPS、証明書、WAF）を
復習するのがよろしいかと思います。
・HTTPSを強制的にHTTPに変換して、パケットキャプチャを行いたい
・そのためには、中継サーバ1に偽装証明書を導入し、マルウェアに
中継サーバ1を被疑サーバと思わせて通信する必要がある
・中継サーバ1はHTTPSをHTTPに復号化して、中継サーバ2と通信する
・パケットキャプチャは中継サーバ1-中継サーバ2間のHTTP通信を
キャプチャする
何回も解説しておりますが、中継サーバ1を被疑サーバと思わせるためには、
中継サーバ1に被疑サーバのFQDNを持った偽装証明書の導入が必須になります。
中継サーバ1に被疑サーバのFQDNを持った偽装証明書を導入していない場合、
マルウェアはこの通信が偽物と判断し、通信を終了してしまします。
もしこの解説で不明のようでしたら、一旦Web技術（HTTP/HTTPS、証明書、WAF）を
復習するのがよろしいかと思います。
2022.09.30 16:42
むむむさん(No.17)
なんか、やり取りが[0926]を思い起こさせますね。
くまさんはykさんと同一人物でしょうか。
感謝の気持ちがひとかけらも感じられませんでした。
そしてお礼もなく去ってしまいました。
(No.15)で、
って、そう言われたら(No.2)から今まで長い時間を割いて説明したことが水の泡です。
pixさん、代わりに私からお礼申し上げます。詳しい解説有難うございました。
くまさんはykさんと同一人物でしょうか。
感謝の気持ちがひとかけらも感じられませんでした。
そしてお礼もなく去ってしまいました。
(No.15)で、
>結論は何の為に証明書を組み込むのかわかりません
って、そう言われたら(No.2)から今まで長い時間を割いて説明したことが水の泡です。
pixさん、代わりに私からお礼申し上げます。詳しい解説有難うございました。
2022.09.30 17:45
pixさん(No.18)
★SC ダイヤモンドマイスター
スレ主以外にも私の書き込みを読んで頂きありがとうございます。
私もここに書き込むことによって、SCの内容を忘れないように
復習させていただいている次第です。
私の拙い説明の書き込みが皆様の合格の一助になれば幸いです。
私もここに書き込むことによって、SCの内容を忘れないように
復習させていただいている次第です。
私の拙い説明の書き込みが皆様の合格の一助になれば幸いです。
2022.09.30 17:57
夏の虫さん(No.19)
漫才かと思って笑ってしまいました。
試験前に少しリラックス出来ました、ありがとうございます。
試験前に少しリラックス出来ました、ありがとうございます。
2022.10.01 04:45
夏の虫さん(No.20)
くまさん、とpixさんは同一人物なのですね。
会話形式としてこのスレッドで自作自演のQ&Aをすることで頭の中の整理と備忘にされていて、読む人の為にもなると言うことで助かりました。
ありがとうございます。
会話形式としてこのスレッドで自作自演のQ&Aをすることで頭の中の整理と備忘にされていて、読む人の為にもなると言うことで助かりました。
ありがとうございます。
2022.10.01 04:51
pixさん(No.21)
★SC ダイヤモンドマイスター
>くまさん、とpixさんは同一人物なのですね。
いいえ。違います。
最近タチの悪い荒らし行為に度々巻き込まれ、相手をしてしまっただけです。
それでも、書き込みが他の人に読まれて理解に役立てれば無駄ではなかったと思います。
2022.10.01 05:52
むむむさん(No.22)
>夏の虫さん、
くまさんとpixさんではなく、くまさんとykさんです。[0926]を見て下さい。
それにしても(No.15)であのコメントですから、ズッコケそうになりました。
いままで説明した時間を返してくれと言いたいですね。
pixさんも復習になりますし、閲覧者も勉強になりますのでwin-winです。
スレ主だけが変な人だったということです。
今回の投稿は閲覧者を笑わせて試験前に少しリラックス出来たことはあるかもしれません。
>pixさん、
いつも詳しい解説有難うございます。
わからない人に説明するには高い知識と能力が要求されますね。
いろいろな質問に回答されるpixさんを尊敬いたします。
変な相手にも誠実な対応で好感が持てます。
やばそうな人だと感じたら早めに切り上げることも必要かなと思いました。
あまり無理をなさらずに今後も詳しい解説お願いいたします。
2022.10.01 07:52
夏の虫さん(No.23)
pixさん失礼しました。m(_ _)m
防ぎようがないかもですが、巻き込まれても紳士的な対応されていて尊敬致します。
防ぎようがないかもですが、巻き込まれても紳士的な対応されていて尊敬致します。
2022.10.01 09:46
!?さん(No.24)
自作自演ではないと信じますが、(No.11)だけ
顔アイコンがスレ主と同じだったのが気になります。
なんでそうなるの？
顔アイコンがスレ主と同じだったのが気になります。
なんでそうなるの？
2022.10.01 10:47
pixさん(No.25)
★SC ダイヤモンドマイスター
原因は不明ですが、No.11の書き込みを投稿した際に、
いつもの顔アイコンではなく、スレ主の顔アイコンが表示
されてしまいました。
投稿後にその現象に気付いたため、No.11の書き込みを削除して、
同じ内容を再度No.12に投稿したという次第です。
いつもの顔アイコンではなく、スレ主の顔アイコンが表示
されてしまいました。
投稿後にその現象に気付いたため、No.11の書き込みを削除して、
同じ内容を再度No.12に投稿したという次第です。
2022.10.01 14:01