見出し画像

令和5年度 秋期 情報処理安全確保支援士試験 午後 問3|CIサービスの乗っ取りが利用企業まで波及した日—情報処理安全確保支援士で学ぶサプライチェーン攻撃の事例

この記事で扱うセキュリティ事例

  • 試験区分: 情報処理安全確保支援士

  • 出典: 令和5年度 秋期 情報処理安全確保支援士試験 午後 問3

  • 主なテーマ: 継続的インテグレーション(CI)サービスのセキュリティ、フィッシングによる多要素認証バイパス、環境変数のシークレット窃取、FIDO2/WebAuthn、コード署名と秘密鍵管理、サプライチェーン攻撃

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

自社のシステムを必死に守っていても、利用している「ビルドの仕組み」が乗っ取られたら、被害は自社だけでは止まりません。情報処理安全確保支援士試験で出題されたこのセキュリティインシデント事例は、ソフトウェア開発を支える継続的インテグレーション(CI: Continuous Integration。コミットされたソースコードを自動でコンパイル・ビルドする仕組み)のサービス事業者が攻撃され、そのサービスを利用していた決済事業者の利用者にまで危険が及びかけた、という連鎖を描いています。

攻撃の入口は、ごく身近なフィッシングメールでした。そこから時刻同期型のワンタイムパスワード(TOTP)が突破され、クラウド上のビルド基盤に侵入され、環境変数に置かれていた秘密情報が抜き取られる。さらにその秘密情報には、決済アプリにコード署名を付けるための署名鍵まで含まれていた——。一つのサービスのほころびが、サプライチェーン(部品やサービスの供給網)をたどって次々と広がっていく構図が、この事例には凝縮されています。

この記事を読むと、なぜ多要素認証を入れていてもフィッシングで突破され得るのか、CIサービスのどこにシークレット(秘密情報)が置かれ、どう盗まれたのか、そしてフィッシングに強いFIDO2/WebAuthnやコード署名鍵の保護がなぜ重要なのかが見えてきます。受験対策としてはもちろん、委託先のクラウドサービスを使うすべての企業にとって「自社のリスクはどこまで広がっているか」を考える材料になるはずです。

インシデントの概要

インシデントの概要

舞台は、従業員400名の事業者であるN社です。N社は「Nサービス」という継続的インテグレーションサービスを提供していました。利用者は、バージョン管理システム(VCS: Version Control System。ソースコードの変更履歴をリポジトリという単位で管理する仕組み)にソースコードをコミット(変更を登録)すると、Nサービスがそれを自動で受け取り、コンパイル(ソースコードを実行可能な形式に変換すること)やビルドを実行してくれる、という仕組みです。

Nサービスには三つの中心的な機能がありました。一つ目はソースコード取得機能で、利用者が登録したVCSのホスト名とリポジトリ固有の認証用SSH鍵(サーバへ安全に接続するための鍵)を使い、最新のソースコードを取り込みます。二つ目はコマンド実行機能で、リポジトリの中に置かれた「ci.sh」という名前のビルドスクリプト(一連の処理を自動で実行させる手順書のようなファイル)を実行します。三つ目はシークレット機能で、ビルドスクリプトを動かすシェル(コマンドを実行する環境)の環境変数(プログラムに値を渡すための仕組み)に、APIキー(外部サービスを利用するための認証情報)などの秘密情報を設定しておけます。これにより、利用者はスクリプトの中にAPIキーを直接書かずに済みました。

Nサービスは、C社のクラウド基盤の上で動いていました。構成は、コミット通知をAPIで受け取るフロントエンド、SSH鍵やシークレットを保存するユーザーデータベース(読み書きはフロントエンドからだけ許可)、そして実際にビルドを処理するLinux製のバックエンドが50台。バックエンドにはCIデーモン(常に待機して処理を実行し続ける常駐プログラム)が動いており、処理命令を受け取るとコンテナ(アプリを隔離して動かす軽量な実行環境)を特権なしで起動し、その中でソースコードの取得とコマンド実行を順に行いました。バックエンドはインターネットへの通信も可能でした。

N社は、これらの構成要素をC社の「クラウド管理サイト」から管理していました。クラウド管理サイトへのログインには、C社のスマートフォン用アプリに表示される時刻を用いたワンタイムパスワード(TOTP: Time-based One-Time Password。一定時間だけ有効な使い捨ての数字)が要求されます。オペレーション部が構成要素の設定を担当し、セキュリティ部がクラウド管理サイトの認証ログを監視する——一見、隙のない体制に見えました。

何が起きたのか

何が起きたのか

1月4日の11時。クラウド管理サイトの認証ログを見張っていたセキュリティ部のHさんは、ある記録に目を留めました。同日10時、オペレーション部のUさんのアカウントで、国外のIPアドレスからクラウド管理サイトへのログインがあったのです。Uさんは国内で働いている。国外からのログインは、明らかに不自然でした。

HさんはすぐにUさんへ確認します。Uさんの説明はこうでした。「同じ10時ごろ、社内からログインを試みたが一度失敗した」。さらにUさんは、その少し前に一通のメールを受け取っていました。メールには「クラウド管理サイトからの通知だ」と書かれており、UさんはメールのURLを開いて、クラウド管理サイトだと思い込んだままログインを試みていたのです。

Hさんがそのメールを確かめると、URLの中のドメイン名(サイトを示す住所のような文字列)は、本物のクラウド管理サイトのものとは違っていました。Uさんがログインを試みていたのは、見た目をそっくり真似た偽サイト——フィッシング(正規のサイトを装ってIDやパスワードをだまし取る手口)でした。Uさんが偽サイトに入力したIDとパスワード、そして表示中のTOTPは、すべて攻撃者の手に渡っていたのです。TOTPは一定時間で切り替わりますが、攻撃者はその有効な間に、奪った情報で本物のクラウド管理サイトへ素早くログインしていました。Hさんは、10時の国外IPからのログインを、攻撃者による不正ログインだと判断します。

ここからが本当の問題でした。Uさんのアカウントには、フロントエンドとバックエンドの管理者権限があったのです。Hさんはアカウントを一時停止して調査を始めます。フロントエンドを調べると、Webサイトの公開ディレクトリに「/.well-known/pki-validation/」というディレクトリが作られ、英数字が並んだ正体不明のファイルが置かれていました。これはサーバ証明書(通信相手が本物であることを示す電子的な証明書)を発行する際に、ドメインの管理権限を証明するために使われる仕組みです。攻撃者は、N社のドメインのサーバ証明書を勝手に取得しようとしていた疑いがありました。

Hさんは、RFC 9162で規定された証明書発行ログ——発行されたサーバ証明書を誰でも検証できるように公開する仕組み——を使って、Nサービスのドメインの証明書を検索します。すると、正規の証明書のほかに、N社では使った覚えのない認証局Rが発行した証明書が見つかりました。攻撃者は、N社になりすますための証明書まで手に入れていたのです。

調査の手はバックエンドにも伸びます。50台のうち1台で、管理者権限を持つ不審なプロセス(実行中のプログラム。以下、プロセスY)が動いていました。この被害バックエンドの通信を確認すると、プロセスYは特定のCDN事業者(コンテンツを高速配信する事業者)のIPアドレスへ、HTTPSで大量のデータを送っていました。しかも通信の宛先を示すTLSのSNI(接続先サイト名を平文で伝える情報)には、著名なオープンソース配布サイトのドメイン名が指定されており、バックエンドを監視していた監視ソフトウェア製品Xは、これを「安全な通信」と判断していたのです。

Hさんは違和感を覚え、TLS通信ライブラリの機能で以降の通信を復号して中身を確かめました。すると、HTTPのHostヘッダー(本当に通信したいサイト名を示す情報)には、SNIとはまったく別のドメイン名が指定されていたのです。そのドメインは、製品Xが「要注意」として登録しているものでした。プロセスYは、監視ソフトウェアに見つからないよう、SNIに無害なサイト名を偽装して通信していた——監視の目をすり抜けるための、巧妙な偽装でした。そして復号された通信の中には、被害バックエンド上のソースコードが含まれていました。

Hさんは即座に被害バックエンドを停止させます。しかし、彼の頭をよぎったのはもっと深刻な懸念でした。プロセスYは、シークレット——つまり利用企業がビルドのために預けていたAPIキーや署名鍵——まで盗み出した可能性がある。N社は同日、不正アクセスの概要とNサービスの一時停止を公表し、被害バックエンドを使っていた顧客に「ソースコードとシークレットが第三者に漏えいしたおそれがある」と通知する決断をしました。

その通知を受け取った顧客の一つが、従業員1,000名の資金決済事業者P社でした。P社は、決済用のスマートフォンアプリ「Pアプリ」を提供しており、その最新版のコンパイルとアプリ配信サイト「Jストア」へのアップロードに、Nサービスを使っていたのです。P社がシークレットとして預けていたのは、アプリにコード署名(このアプリは正規の開発者が作った本物だと示す電子署名)を付けるための署名鍵とコードサイニング証明書、そしてJストアにアップロードするための認証用APIキー。攻撃の波は、CIサービス事業者を越えて、決済アプリとその利用者へと迫っていました。

ここから先は

6,895字 / 4画像
情報処理安全確保支援士に受かるにはとにかく事例をできるだけ多く知ることです。マガジン購入で他の年度記事へアクセス。現在量産中。全記事揃うまで半額提供のため購入はお早めに!

情報処理安全確保支援士(登録セキスペ)の午後問題、「読んでも頭に入らない」と感じていませんか?本シリーズでは、2017年〜2025年の過去…

この記事が気に入ったらチップで応援してみませんか?