継続的インテグレーションサービスのセキュリティ（TOTP中継フィッシングとコード署名鍵の漏えい）

問3　継続的インテグレーションサービスのセキュリティに関する次の記述を読んで，設問に答えよ。

　N社は，Nサービスという継続的インテグレーションサービスを提供している従業員400名の事業者である。Nサービスの利用者（以下，Nサービス利用者という）は，バージョン管理システム（以下，VCSという）にコミットしたソースコードを自動的にコンパイルするなどの目的で，Nサービスを利用する。VCSでは，リポジトリという単位でソースコードを管理する。Nサービスの機能の概要を表1に示す。

表1　Nサービスの機能の概要（抜粋）

　NサービスはC社のクラウド基盤で稼働している。Nサービスの構成要素の概要を表2に示す。

表2　Nサービスの構成要素の概要（抜粋）

　フロントエンドは，ソースコードのコミットの通知を受け取ると図1の処理を行う。

図1　フロントエンドが行う処理

1. 通知を基にNサービス利用者とリポジトリを特定し，そのNサービス利用者が登録したVCSのホスト名，各リポジトリ固有の認証用SSH鍵，及びシークレットをユーザーデータベースから取得する。
2. バックエンドを一つ選択する。
3. 2.で選択したバックエンドのCIデーモンに1.で取得した情報を送信し，処理命令を出す。

　CIデーモンは，処理命令を受け取ると，特権を付与せずに新しいコンテナを起動し，当該コンテナ内でソースコード取得機能とコマンド実行機能を順に実行する。

　ビルドスクリプトには，利用者が任意のコマンドを記述できるので，不正なコマンドを記述されてしまうおそれがある。さらに，不正なコマンドの処理の中には，①コンテナによる仮想化の脆弱性を悪用しなくても成功してしまうものがある。そこで，バックエンドには管理者権限で稼働する監視ソフトウェア製品Xを導入している。製品Xは，バックエンド上のプロセスを監視し，プロセスが不正な処理を実行していると判断した場合は，当該プロセスを停止させる。

　C社は，C社のクラウド基盤を管理するためのWebサイト（以下，クラウド管理サイトという）も提供している。N社では，クラウド管理サイト上で，クラウド管理サイトのアカウントの管理，Nサービスの構成要素の設定変更，バックエンドへの管理者権限でのアクセス，並びにクラウド管理サイトの認証ログの監視をしている。N社では，C社が提供するスマートフォン用アプリケーションソフトウェア（以下，スマートフォン用アプリケーションソフトウェアをアプリという）に表示される，時刻を用いたワンタイムパスワード（TOTP）を，クラウド管理サイトへのログイン時に入力するように設定している。

　N社では，オペレーション部がクラウド管理サイト上でNサービスの構成要素の設定及び管理を担当し，セキュリティ部がクラウド管理サイトの認証ログの監視を担当している。

〔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/”ディレクトリが作成され，英数字が羅列された内容のファイルが作成されていた。そこで，③RFC 9162に規定された証明書発行ログ中の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に示す事後処理と対策を行うことにした。

図2　事後処理と対策（抜粋）

1. フロントエンド及び全てのバックエンドを再構築する。
2. 認証局Rに対し，Nサービスのドメインのサーバ証明書が勝手に発行されていることを伝え，その失効を申請する。
3. 偽サイトでログインを試みてしまっても，クラウド管理サイトに不正ログインされることのないよう，クラウド管理サイトにログインする際の認証を⑥WebAuthn（Web Authentication）を用いた認証に切り替える。
4. Nサービスのドメインのサーバ証明書を発行できる認証局を限定するために，Nサービスのドメインの権威DNSサーバに，Nサービスのドメイン名に対応する [ a ] レコードを設定する。

〔N社の顧客での対応〕

　Nサービスの顧客企業の一つに，従業員1,000名の資金決済事業者であるP社がある。P社は，決済用のアプリ（以下，Pアプリという）を提供しており，スマートフォンOS開発元のJ社が運営するアプリ配信サイトであるJストアを通じて，Pアプリの利用者（以下，Pアプリ利用者という）に配布している。P社はNサービスを，最新版ソースコードのコンパイル及びJストアへのコンパイル済みアプリのアップロードのために利用している。P社には開発部及び運用部がある。

　Jストアへのアプリのアップロードは，J社の契約者を特定するための認証用APIキーをHTTPヘッダーに付加し，JストアのREST APIを呼び出して行う。認証用APIキーはJ社が発行し，契約者だけがJ社のWebサイトから取得及び削除できる。また，Jストアは，アップロードされる全てのアプリについて，J社が運営する認証局からのコードサイニング証明書の取得と，対応する署名鍵によるコード署名の付与を求めている。Jストアのアプリを実行するスマートフォンOSは，各アプリを起動する前にコード署名の有効性を検証しており，検証に失敗したらアプリを起動しないようにしている。

　P社は，Nサービスのソースコード取得機能に，Pアプリのソースコードを保存しているVCSのホスト名とリポジトリの認証用SSH鍵を登録している。Nサービスのシークレット機能には，表3に示す情報を登録している。

表3　P社がNサービスのシークレット機能に登録している情報

　Pアプリのビルドスクリプトには，図3に示すコマンドが記述されている。

図3　ビルドスクリプトに記述されているコマンド

1. コンパイラのコマンド
2. 生成されたバイナリコードにAPP_SIGN_KEYを用いてコード署名を付与するコマンド
3. STORE_API_KEYを用いて，署名済みのバイナリコードをJストアにアップロードするコマンド

　1月4日，P社運用部のKさんがN社からの通知を受信した。それによると，ソースコード及びシークレットが漏えいしたおそれがあるとのことだった。Kさんは，⑦Pアプリ利用者に被害が及ぶ攻撃が行われることを予想し，すぐに二つの対応を開始した。

　Kさんは，一つ目の対応として，⑧漏えいしたおそれがあるので，STORE_API_KEYとして登録されていた認証用APIキーに必要な対応を行った。また，二つ目の対応として，APP_SIGN_KEYとして登録されていたコードサイニング証明書について認証局に失効を申請するとともに，新たな鍵ペアを生成し，コードサイニング証明書の発行申請及び受領を行った。鍵ペア生成時，Nサービスが一時停止しており，鍵ペアの保存に代替手段が必要になった。FIPS 140-2 Security Level 3の認証を受けたハードウェアセキュリティモジュール（HSM）は，⑨コード署名を付与する際にセキュリティ上の利点があるので，それを利用することにした。さらに，二つの対応とは別に，リポジトリの認証用SSH鍵を無効化した。

　その後，開発部と協力しながら，P社内のPCでソースコードをコンパイルし，生成されたバイナリコードに新たなコード署名を付与した。JストアへのPアプリのアップロード履歴を確認したが，異常はなかった。新規の認証用APIキーを取得し，署名済みのバイナリコードをJストアにアップロードするとともに，⑩Kさんの二つの対応によってPアプリ利用者に生じているかもしれない影響，及びそれを解消するためにPアプリ利用者がとるべき対応について告知した。さらに，外部委託先であるN社に起因するインシデントとして関係当局に報告した。