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

設問1は、コンテナの脆弱性を利用しなくても成功する攻撃について問われています。

コンテナとは仮想化技術の一種で、アプリケーションとその実行に必要な環境を一つにまとめ、ホストOS上で隔離された形で動作させる技術です。仮想マシン型は、ゲストOSやミドルウェア、アプリケーションを含む完全な環境を仮想化する仕組みであるのに対し、コンテナ型はコンテナホストのOS（以下、ホストOSという）を共有します。仮想マシン型ではゲストOSをマシンごとに作るのに対し、コンテナはゲストOSを使用せず、基盤となるホストOSを共有します。この仕組みにより、コンテナは仮想マシンよりもオーバーヘッドが少なく、軽量であるという特徴があります。しかし、複数のコンテナが1つのホストOSを共有する特性上、ホストOSが1つのコンテナ経由で攻撃されると、他のコンテナも影響を受けるリスクがあります。

本来、コンテナからホストOSにアクセスしたり、他のコンテナにアクセスしたりすることはできません。しかし、コンテナに脆弱性が存在する場合、その脆弱性が悪用されてアクセスできないはずのホストOSや他のコンテナに不正に侵入されるおそれがあります。このような攻撃を「コンテナエスケープ」といいます。本問では、「コンテナによる仮想化の脆弱性を悪用しなくても成功」する攻撃に該当するものが問われているので、『コンテナエスケープを利用しなくても成功する攻撃はどれか』という観点で、選択肢を見ていくことになります。

本問では、「CIデーモンは，…新しいコンテナを起動し」という記述と、表2のバックエンド欄の記述より、バックエンドがコンテナホストの役割を果たしていることがわかります。バックエンド上でCIデーモンやコンテナエンジンが稼働しており、コンテナエンジンの上に作られたコンテナ内でソースコード実行機能やコマンド実行機能が動作する形です。

• 表2によると、CIデーモンはバックエンド上で稼働しています。したがって、コンテナエスケープを利用してバックエンドを攻撃されなければ成立しません。
• バックエンドにアクセスする必要がありますので、コンテナエスケープを利用してバックエンドを攻撃されなければ成立しません。
• 正しい。表2によると、バックエンドは「インターネットへの通信が可能である」とあります。すなわち、バックエンド上で稼働しているコンテナもインターネット通信が可能となります。ビルドスクリプトにインターネット通信をするコマンドを記述することにより、コンテナエスケープを利用せずとも成立します。
• 正しい。「ウ」と同様にコンテナからインターネットに通信できるので、コンテナエスケープを利用せずとも成立します。
• 他のNサービス利用者のビルドスクリプトの出力は、他のコンテナにあります。取得するためには、コンテナエスケープを利用してバックエンド経由でほかのコンテナに侵入しなければ成立しません。

設問2は、N社で発生したインシデントの発生とその対応が題材となっています。

• 攻撃者による不正ログインの方法について問われています。
  問題文によると、「Uさんが攻撃者から送られたフィッシングメールに引っかかり、攻撃者が用意した偽サイトにログインを試みた（要約）」とあります。「N社では、クラウド管理サイトへのログインにTOTPを使用している（要約）」とあるため、Uさんが偽サイトにTOTPを入力し、攻撃者がそのTOTPを盗み取ってログインを試みたことが読み取れます。
  注意すべきは、問題文中には「ID/パスワードを入力した」という記載がない点です。実務上、TOTPはID/パスワードと組み合わせて使用することが多いと思いますが、本問では記載がないため、勝手に情報を付け足さないように気をつける必要があります。また、今回はTOTPであるため時間制限があります。その時間内に入力しなければ、盗み取ったTOTPは無効になりますので、「そのTOTPが有効な間に」という文言が必要になります。
  
  ∴偽サイトに入力されたTOTPを入手し，そのTOTPが有効な間にログインした。
  
  
• RFC9162で規定されている技術について問われています。
  RFC9162は、デジタル証明書の発行とその有効性を公開的に監視・検証する仕組みを規定した規格です。この仕組みはCertificate Transparency(CT：証明書の透明性)と呼ばれ、証明書の発行履歴を改ざん不可能なログとして公開し、誰でもその内容を検証できるようにすることで、不正な証明書の発行や使用を抑止します。したがって正解は「ア」です。
  • 正しい。RFC9162は、Certificate Transparencyについて規定した規格です。
  • HTTP Public Key Pinningは、一度接続したサーバ証明書をブラウザに記憶させ（証明書のピン留め）、次回以降、同じサーバ証明書であるかを確認する仕組みです。正しく実装すれば、不正な証明書を悪用されることへの対策となりますが、実装が難しく、また証明書が危殆化して失効した場合の対応などが困難であり、現在はあまり使われていません。
  • HTTP Strict Transport Security(HSTS)は、ブラウザがHTTPで接続しようとした際に、強制的にHTTPS通信に切り替える仕組みです。
  • Registration Authority(RA)は、CA(認証局)の業務のうち、証明書発行の受付と発行要求をする主体のことです。登録局と呼ばれます。
  ∴ア：Certificate Transparency
  
  
• 下線④「監視ソフトウェアに検知されないようにSNIを偽装していた」手口について問われています。
  今回のように、SNIを偽装して他のサイトに誘導する手口を「ドメインフロンティング」と呼びます。ドメインフロンティングは、CDN(Content Delivery Network)を悪用した攻撃です。最初に、TLSのSNIヘッダー（TLSハンドシェイクでクライアントが接続を指定するFQDN）に記載された接続先に許可されている正規のCDNに接続を試みます。この時点ではTLSによる暗号化の前なので、SNIの内容を確認できます。その後、TLSで通信が始まるときにはHostヘッダーで別のドメイン（攻撃者のサイト）を指定します。CDN事業者はHostヘッダーに従って、攻撃者のサイトにリクエストを転送します。この通信はTLSで暗号化されているので、中身を見ることができません。こうして正規のサイトに接続しているように見せかけながら、攻撃者のサイトに接続します。
  
  そのほかの選択肢は以下のとおりです。
  • DNSスプーフィングは、正規のWebサイトにアクセスしようとした通信を不正なサイトにリダイレクトする攻撃の総称です。DNSキャッシュポイズニングが代表的な攻撃ですが、偽のDNSサーバへのなりすましやDNSレコードの改ざん行為なども含むより広い概念です。
  • 正しい。ドメインフロンティングとは、TLS通信を行う際にSNI(Server Name Indication)やHTTPリクエストのヘッダーに異なるドメインを記載し、通信先を隠してフィルタリングを回避しようとする手法です。
  • ドメイン名ハイジャックは、ドメイン名の管理者権限をもたない第三者が、不正な手段を用いてドメイン名を自身の管理下に置く攻撃手法です。レジストリや権威DNSサーバの情報を不正に書き換えることで攻撃が成立します。
  • ランダムサブドメイン攻撃は、DNSサーバに対するDDoS攻撃の一つです。存在しないランダムなサブドメインを大量に生成し、権威DNSサーバに送りつけることで、DNSサーバを過負荷状態に陥らせる攻撃です。
  ∴イ：ドメインフロンティング
  
  
• プロセスYがシークレットを取得するのに使った方法について問われています。
  本問での"シークレット"とは、表1の"シークレット機能"より「ビルドスクリプトを実行するシェルに設定される環境変数」であって、利用者がNサービスに登録した情報です。表2によると、バックエンドにはLinuxがインストールされています。/procファイルシステムは、Linuxでプロセスやシステム情報を提供する仮想ファイルシステムです。/proc配下のディレクトリやファイルを見ると、プロセス情報などが閲覧できます。プロセスYは管理者権限を持つので、被害を受けたバックエンドのプロセス情報をすべて見ることができます。環境変数もこの中に保管されています。
  
  ∴/procファイルシステムから環境変数を読み取った。
  
  
• WebAuthn(Web Authentication API：ウェブオースン)の仕組みについて問われています。
  認証方法は長らくID/パスワードを用いたものが主流でした。しかし、昨今はパスワードに依存しない認証方式が登場しています。WebAuthnは、FIDO2を構成する技術の一つで、Webサービスにおけるパスワード不要の認証に関する仕様です。仕組みを簡単に説明すると次のようになります。
  1. あらかじめ認証器の公開鍵/秘密鍵の鍵ペアを作成し、ユーザー情報とその公開鍵をサーバに登録しておく
  2. クライアントがWebサーバに接続する
  3. Webサーバはクライアントにチャレンジと呼ばれる乱数とオリジン（サーバのURL情報など）を送付する
  4. クライアントで生体認証またはPIN認証を行う
  5. クライアントは認証情報、チャレンジとオリジンを合成したものに秘密鍵で署名し、Webサーバへ返す
  6. Webサーバはクライアントの公開鍵を利用して署名を確認し、チャレンジ、オリジン、認証情報を検証する
  攻撃者が偽のサイトで認証情報を盗んだとしても、WebAuthnではログインに必要な条件（チャレンジ、オリジン、署名）が一致しないため、攻撃者はその情報を使って正規のサイトにログインすることができません。
  
  ∴認証に用いる情報に含まれるオリジン及び署名をサーバが確認する仕組み
  
  
• 証明書を発行する認証局を限定するためのリソースレコードについて問われています。
  • 正しい。CAA(Certification Authority Authorization)レコードは、ドメインに対する証明書の発行を許可する認証局のコモンネームを指定するレコードです。意図しない認証局から証明書が不正発行されるリスクを軽減することができます。
    
    example.com. 3600 IN CAA 0 issue "letsencrypt.org"
  • CNAMEは、Canonical Name（正式名）の略で、ホストの正式名と別名（エイリアス）の対応を定義するレコードです。
  • DNSKEYは、DNSSEC検証に用いる公開鍵を格納するためのレコードです。DNSSEC(Domain Name System Security Extensions)は、DNS応答の出自及びDNS応答の完全性を検証する仕組みです。
  • NSは、Name Serverの略で、そのドメインを管轄するDNSサーバのホスト名を指定するレコードです。
  • SOAは、Start Of Authority（権威の開始）の略で、ドメインやゾーンに関する重要な情報を登録するレコードです。
  • TXTは、Textの略で、DNSにテキストデータを登録するためのレコードです。SPFレコードなどの登録に使用されます。
  ∴a＝ア：CAA

設問3は、スマートフォン用のアプリについてです。

• ソースコード及びシークレットが漏えいしたことによる攻撃について問われています。
  問題文中、Kさんは想定される攻撃を防止するために次の2つの対応策を行っています。
  • STORE_API_KEYとして登録されていた認証用APIキーに必要な対応を行った
  • APP_SIGN_KEYとして登録されていたコードサイニング証明書を失効させ、再発行した（要約）
  表3によると、STORE_API_KEYは「Jストアにアプリをアップロードするための認証用APIキー」、APP_SIGN_KEYは「コード署名の付与に利用する署名鍵とコードサイニング証明書」とあります。つまり、APP_SIGN_KEYがあれば、アプリに有効な署名を付与することができ、STORE_API_KEYがあれば、Jストアにアプリをアップロードすることができます。この2つを入手した攻撃者は、ソースコードに攻撃コードを仕込み、それに有効な署名をして、Jストアに改変したアプリをアップロードすることが可能です。利用者に悪意のあるアプリが提供されるおそれがあるため、Kさんは即座に2つの対応策を実施したことになります。
  
  ∴有効なコード署名が付与された偽のPアプリをJストアにアップロードする攻撃
  
  
• STORE_API_KEYに行った対応について問われています。
  STORE_API_KEYは、JストアにアプリをアップロードするためのREST APIで使用する認証用APIキーです。問題文によると「認証用APIキーはJ社が発行し，契約者だけがJ社のWebサイトから取得及び削除できる」とあります。STORE_API_KEYが漏えい場合、攻撃者がアプリをJストアに不正にアップロードするリスクがありますから、P社としては直ちにJ社Webサイトから認証用APIキーを削除することが適切な対応となります。
  
  ∴J社のWebサイトから削除する。
  
  
• HSMを使うことによるセキュリティ上の利点について問われています。
  HSMはHardware Security Moduleの略で、暗号鍵の生成・保管などを行う物理的なモジュールです。似たようなものに暗号鍵の生成や保管などを行うTPM(Trusted Platform Module)がありますが、より高機能なものという位置付けです。TPMがPCやスマートフォンなどのデバイス内部に組み込まれ、デバイス単体をセキュリティの観点から保護するセキュリティチップであるのに対し、HSMは暗号鍵の生成や安全な保管に特化した専用のセキュリティ機器です。
  
  問題文中のFIPS 140-2は暗号化ハードウェアの性能と安全性を確認するための基準です。Security Level 3では、高度な耐タンパ性（ハードウェア内部への解析を検知すると破壊する性質）が求められており、非常に高いレベルの保護機能を有します。この認証を受けたHSMを利用すれば、秘密鍵を安全に保管することができ、秘密鍵が漏えいするリスクをほぼ排除することができます。
  
  ∴秘密鍵が漏れないという利点
  
  
• シークレットの漏えいに対する対策を取った結果、Pアプリに与えた影響と、Pアプリ利用者が取るべき対応について問われています。
  P社ではシークレットの漏えいを受け、コードサイニング証明書を失効させ、再発行を行っています。問題文中に「Jストアのアプリを実行するスマートフォンOSは，各アプリを起動する前にコード署名の有効性を検証しており，検証に失敗したらアプリを起動しない」とあります。このため、失効した元のコードサイニング証明書で署名されたPアプリは、コード署名の検証に失敗し、起動することができません。これが利用者に生じる影響です。この問題を解消するためには、再発行されたコードサイニング証明書で署名されたPアプリにアップデートする必要があります。
  
  ∴影響：Pアプリを起動できない。
  　対応：Pアプリをアップデートする。