【情報処理安全確保支援士試験 令和5年度 秋期 午後 問3 No.2】
情報処理安全確保支援士試験 令和5年度 秋期 午後 問3
【出典:情報処理安全確保支援士試験 令和5年度 秋期 午後 問3(一部、加工あり)】
[N社のインシデントの発生と対応]
1月4日11時、クラウド管理サイトの認証ログを監視していたセキュリティ部のHさんは、同日10時にオペレーション部のUさんのアカウントで国外のIPアドレスからクラウド管理サイトにログインがあったことに気付いた。
HさんがUさんにヒアリングしたところ、Uさんは車内で同日10時にログインを試み、一度失敗したとのことであった。Uさんは、同日10時前に電子メール(以下、メールという)を受け取っていた。メールにはクラウド管理サイトからの通知だと書かれていた。Uさんはメール中のURLを開き、クラウド管理サイトだと思ってログインを試みていた。Hさんがそのメールを確認したところ、URL中のドメイン名はクラウド管理サイトのドメイン名とは異なっており、Uさんがログインを試みたのは偽サイトだった。Hさんは、同日10時の国外IPアドレスからのログインは②攻撃者による不正ログインだったと判断した。
Hさんは、初動対応としてクラウド管理サイトのUさんのアカウントを一時停止した後、調査を開始した。Uさんのアカウントの権限を確認したところ、フロントエンド及びバックエンドの管理者権限があったが、それ以外の権限はなかった。
まずフロントエンドを確認すると、Webサイトのドキュメントルートに、”/.well-known/pki-validation/”ディレクトリが作成され、英数字が羅列された内容のファイルが作成されていた。そこで、③RFC9162に規定された証明書発行ログ中のNサービスのドメインのサーバ証明書を検索したところ、正規のもののほかに、N社では利用実績のない認証局Rが発行したものを発見した。
バックエンドのうち1台では、管理者権限をもつ不審なプロセス(以下、プロセスYという)が稼働していた(以下、プロセスYが稼働していたバックエンドを被害バックエンドという)。被害バックエンドのその時点のネットワーク通信状況を確認すると、プロセスYは特定のCDN事業者のIPアドレスに、HTTPSで多量のデータを送信していた。TLSのServer Name Indication(SNI)には、著名なOSS配布サイトのドメイン名が指定されており、製品Xでは、安全な通信だと判断されていた。
詳しく調査するために、TLS通信ライブラリの機能を用いて、それ以降に発生するプロセスYのTLS通信を復号したところ、HTTP Hostヘッダーでは別のドメイン名が指定されていた。このドメイン名は、製品Xの脅威データベースに登録された要注意ドメインであった。プロセスYは、④監視ソフトウェアに検知されないようにSNIを偽装していたと考えられた。TLS通信の内容には被害バックエンド上のソースコードが含まれていた。Hさんはクラウド管理サイトを操作して被害バックエンドを一時停止した。Hさんは、⑤プロセスYがシークレットを取得したおそれがあると考えた。
Hさんの調査結果を受けて、N社は同日、次を決定した。
- 不正アクセスの概要とNサービスの一時停止をN社のWebサイトで公表する。
- 被害バックエンドでソースコード取得機能又はコマンド実行機能を利用した顧客に対して、ソースコード及びシークレットが第三者に漏えいしたおそれがあると通知する。
Hさんは図2に示す事後処理と対策を行うことにした。
下線②について、攻撃者による不正ログインの方法を、50字以内で具体的に答えよ。:偽サイトに入力されたTOTPを入手し、そのTOTPが有効な間にログインした。
「Hさんがそのメールを確認したところ、URL中のドメイン名はクラウド管理サイトのドメイン名とは異なっており、Uさんがログインを試みたのは偽サイトだった。Hさんは、同日10時の国外IPアドレスからのログインは②攻撃者による不正ログインだったと判断した。」
Uさんが、クラウド管理サイトの偽サイトにログインを試みたとのことで、ログイン時に入力する情報を確認すると、「N社では、C社が提供するスマートフォン用アプリケーションソフトウェア(以下、スマートフォン用アプリケーションソフトウェアをアプリという)に表示される、時刻を用いたワンタイムパスワード(TOTP)を、クラウド管理サイトへのログイン時に入力するように設定している。」とあります。
したがって、偽サイトでUさんのTOTPを入手し、そのTOTPが有効な時間内でログインすることで、Uさんになりすまして、正規のクラウド管理サイトにログインすることが可能となります。
下線③について、RFC 9162で規定されている技術を、解答群の中から選び、記号で答えよ。:ア
(解答群)
ア Certificate Transparency
イ HTTP Public Key Pinning
ウ HTTP Strict Transport Security
エ Registration Authority
「まずフロントエンドを確認すると、Webサイトのドキュメントルートに、”/.well-known/pki-validation/”ディレクトリが作成され、英数字が羅列された内容のファイルが作成されていた。そこで、③RFC9162に規定された証明書発行ログ中のNサービスのドメインのサーバ証明書を検索したところ、正規のもののほかに、N社では利用実績のない認証局Rが発行したものを発見した。」
Hさんによる調査では、Uさんになりすました攻撃者が、不正にディレクトリを作成し、ファイルを配置していることが判明しました。
これが、認証局Rが発行するサーバ証明書の基となるファイルになります。
サーバ証明書の発行には、ドメイン名(FQDN)が申請者の管理下にあることを証明するため、当該ドメインのサーバに認証局が指定するファイルを配置し、認証局が外部からアクセス可能である必要があるためです。
これに関連し、RFC9162で規定されている技術は、「CT(Certificate Transparency)」です。
下線④について、このような手法の名称を、解答群の中から選び、記号で答えよ。:イ
(解答群)
ア DNSスプーフィング
イ ドメインフロンティング
ウ ドメイン名ハイジャック
エ ランダムサブドメイン攻撃
「詳しく調査するために、TLS通信ライブラリの機能を用いて、それ以降に発生するプロセスYのTLS通信を復号したところ、HTTP Hostヘッダーでは別のドメイン名が指定されていた。このドメイン名は、製品Xの脅威データベースに登録された要注意ドメインであった。プロセスYは、④監視ソフトウェアに検知されないようにSNIを偽装していたと考えられた。」
SNIについては、「被害バックエンドのその時点のネットワーク通信状況を確認すると、プロセスYは特定のCDN事業者のIPアドレスに、HTTPSで多量のデータを送信していた。TLSのServer Name Indication(SNI)には、著名なOSS配布サイトのドメイン名が指定されており、製品Xでは、安全な通信だと判断されていた。」とありますが、SNIはTLSのネゴシエーション時に、ブラウザが接続したいFQDNを通知する機能です。
この場合、SNIで著名なOSS配布サイトを指定しますが、この時の通信は暗号化通信の開始前であり、製品XでSNIの内容を確認できます。
その後、TLS通信で暗号化通信を開始しますが、HTTP Hostヘッダーでは別のドメイン名が指定されていたということです。
このような手法を、ドメインフロンティングと言います。
下線⑤について、プロセスYがシークレットを取得するのに使った方法として考えられるものを、35字以内で答えよ。:/procファイルシステムから環境変数を読み取った。
「Hさんは、⑤プロセスYがシークレットを取得したおそれがあると考えた。」
シークレットについては、表1に「APIキーなど環境変数として登録された情報」とありました。
プロセスがシークレットである環境変数を取得する方法としては、Linux上でプロセスやシステム情報を提供する仮想ファイルシステムである「/procファイルシステム」で参照する方法があります。(知識問題でした)
下線⑥について、仮に、利用者が偽サイトでログインを試みてしまっても、攻撃者は不正ログインできない。不正ログインを防ぐWebAuthnの仕組みを、40字以内で答えよ。:認証に用いる情報に含まれるオリジン及び署名をサーバが確認する仕組み
「偽サイトでログインを試みてしまっても、クラウド管理サイトに不正ログインされることのないよう、クラウド管理サイトにログインする際の認証を⑥WebAuthn(Web Authentication)を用いた認証に切り替える。」
WebAuthnとは、公開鍵暗号によるデジタル署名を利用しパスワード不要の認証を実現する技術のことで、Webサーバが利用者認証を行う際、利用者側でFIDO規格に対応した認証器(スマホなど)を使用します。
認証器には利用者の秘密鍵を登録し、公開鍵をサーバ側に登録します。
利用者がWebサーバにアクセスすると、Webサーバがチャレンジとオリジン(WebサーバのURL情報など)を返信します。
利用者側で生体認証など認証器による認証が成功すると、チャレンジとオリジンを秘密鍵で署名し、Webサーバに送信します。
Webサーバで利用者の公開鍵で署名を検証することで、不正ログインができない仕組みを提供します。
aに入れる適切な字句を、解答群の中から選び、記号で答えよ。:ア
(解答群)
ア CAA イ CNAME ウ DNSKEY エ NS
オ SOA カ TXT
「Nサービスのドメインのサーバ証明書を発行できる認証局を限定するために、Nサービスのドメインの権威DNSサーバに、Nサービスのドメイン名に対応する(a)レコードを設定する。」
知識問題ですね。
サーバ証明書を発行できる認証局を限定するためにDNSサーバに設定するのは、CAAレコードです。
CAA(Certification Authority Authorization)は、CA(認証局)の認証のことであり、当該認証局以外での証明書を発行しないという宣言になります。