- 中国を拠点とする脅威アクター Storm-0558 が、盗み出した MSA コンシューマー署名キーでトークンを偽造し、OWA と Outlook.com にアクセスした事件の技術調査結果
- 2021年4月の コンシューマー署名システムのクラッシュで生成されたクラッシュダンプに、競合状態（race condition）によりキーが含まれ、システムがこれを検知できなかった
- キーを含むクラッシュダンプが、隔離された本番ネットワークから、インターネット接続のある社内ネットワーク上の デバッグ環境へ移動され、資格情報スキャンでも検知されなかった
- コンシューマーキーで エンタープライズメールにアクセスできた原因は、メールシステムの開発者がライブラリのスコープ検証を誤って想定し、issuer/scope 検証を追加しなかったことにある
- すべての不具合は修正済みで、事後対応として キースコープ検証の自動化など多層防御の強化が適用された
キー取得の経緯
- Microsoft は、バックグラウンドチェック、専用アカウント、セキュアアクセスワークステーション、ハードウェアトークンベースの 多要素認証を備えた、隔離・制限された本番環境を運用している
- この環境では、メール、会議、Web リサーチなどのコラボレーションツールの利用をブロックし、マルウェア感染やフィッシングといったアカウント侵害経路を防いでいる
- Just in Time / Just Enough Access ポリシーにより、システムとデータへのアクセスを制限
- 社内環境（corporate environment）はセキュリティ認証とセキュアなデバイスを要求するが、メール・会議・コラボレーションツールの利用が許可されているため、スピアフィッシングやトークン窃取マルウェアなどに脆弱
- Zero-Trust および "assume breach" の原則に従い、キー素材は本番環境の外へ出てはならない
- 2021年4月、コンシューマー署名システムのクラッシュにより、クラッシュダンプ（crashed process のスナップショット）が生成された
- クラッシュダンプは機密情報をマスキング処理するため署名キーを含むべきではなかったが、競合状態によりキーが含まれた（修正済み）
- システムがクラッシュダンプ内のキーの存在を検知できなかった（修正済み）
- 当時、キーを含まないと判断されたクラッシュダンプが、隔離された本番ネットワークから デバッグ環境へ移動された
- 標準のデバッグ手順に沿ったものであり、資格情報スキャンがキーの存在を検知できなかった（修正済み）
- キー流出後、Storm-0558 のアクターが Microsoft エンジニアの 社内アカウントを侵害
- 当該アカウントは、キーを含むクラッシュダンプが存在するデバッグ環境へのアクセス権を持っていた
- ログ保持ポリシー上、具体的な流出証拠ログはないが、これがキー取得の最も有力な経路
コンシューマーキーでエンタープライズメールにアクセスできた原因
- コンシューマーおよびエンタープライズのアプリケーションをともにサポートしたいという顧客需要に対応するため、2018年9月に 共通キー メタデータ公開エンドポイントを導入
- 統合提供の一環として、エンタープライズアカウントとコンシューマーアカウントごとのキースコープ検証要件を明確にするようドキュメントを更新
- 署名を暗号学的に検証する API は提供していたが、ライブラリが スコープ検証を自動実行するようには更新していなかった（修正済み）
- メールシステムは2022年に共通メタデータエンドポイントを使用するよう更新された
- メールシステムの開発者が、ライブラリが完全な検証を実行すると誤って想定し、必要な issuer/scope 検証を追加しなかった
- その結果、メールシステムはコンシューマーキーで署名されたセキュリティトークンによるエンタープライズメール要求を受け入れた（更新済みライブラリで修正済み）
事後レビューと改善措置
- 署名キーがクラッシュダンプに含まれる原因となった 競合状態を特定し解決
- クラッシュダンプにキー素材が誤って含まれる場合の予防・検知・対応を強化
- デバッグ環境内の署名キーの存在をより適切に検知するため、資格情報スキャンを強化
- 認証ライブラリでキースコープ検証を自動化する改良版ライブラリを配布し、関連ドキュメントを明確化
2024年3月12日の追加更新
- 運用上の誤りにより、キー素材がセキュリティトークン署名環境の外へ出て、侵害されたエンジニアアカウントを通じてデバッグ環境でアクセスされたという 主要な仮説は維持されており、顧客・Microsoft への影響やアクターの活動に変化はない
- 2021年のクラッシュダンプがアクターのアクセス原因であった可能性があるとしていたが、影響を受けた キー素材を含むクラッシュダンプは発見されていない
- 言及された競合状態は、キーがクラッシュダンプに存在するかどうかではなく、クラッシュダンプがセキュリティ署名環境から 持ち出され得るかどうかに影響していた
- クラッシュダンプの持ち出しが標準のデバッグ手順に沿っていたという表現は、過去には禁止されていなかったことを意味するものであり、現在の Microsoft の標準デバッグ手順では、本番環境から当該資料を持ち出すことを禁止している
- 進行中の調査で 資格情報スキャン技術の限界が明らかになっており、発見され次第対応する予定
1件のコメント
Hacker News のコメント
ここには抜けているつながりがあるように見える：並行性バグやメモリ安全性バグによって秘密鍵がデバッグ成果物に偶然入り込むことは容易に理解できるが、攻撃者はクラッシュ発生の事実とクラッシュダンプの構造を知っていて、Microsoft の社内ネットワーク内で待機していなければならなかったのではないかと思う。
侵害を前提とした防御は優れたネットワークセキュリティ戦略だが、実際に侵害されていたという前提をそのまま受け入れるべきではない。
こうしたデータは、実際の価値に比べて十分安全に保管されていないことが多い。FAANG で働いた経験からすると、金融や企業規制の分野での経験がない新人は、ほぼ皆クラッシュデータをバグトラッカーに添付してもよいと考えている。だからクラッシュダンプのようなものは、人々が回避したくならないほど使いやすい金庫に入れるよう、習慣を変える必要がある。
侵害されたエンジニアのアカウントがあるなら、少なくともバグトラッカーへのアクセス権はあり、おそらくバイナリのデバッグシンボルを入手するか作成することもできると見るべきだ。残るのは、エンジニアの一人が不用意にクラッシュダンプをバグの添付ファイルとしてアップロードするのを待ち、誰かが気づいて削除する前に取得するだけだ。
また、Microsoft の資格情報スキャンツールがその鍵を見つけられず、その問題は修正されたというので、鍵はスキャンで検出可能な形だったようだ。
全体としては、エンジニアが鍵の入ったダンプを自分のアカウントに移してしばらく放置し、その後、攻撃者がアカウントに侵入して利用可能なファイルをすべて持ち出し、Microsoft より優れたツールで鍵をスキャンして大当たりを引いた、という状況に見える。
つまり、攻撃者はすでにネットワーク内にいて、検知されないスキャンの最中に偶然ダンプを見つけたか、そもそもこの特定のアカウントを狙っていたという話になる。
それでも攻撃者の側から見ると、出来事の連鎖があまりにも幸運にかみ合いすぎている感じがする。
小さな問題が連続して特定の順序でつながり、最終的に破滅的な失敗に至る過程を扱うシステム工学の授業がある。今回の件はまさにその破滅的な失敗と言える。
まず競合状態がなければならず、その競合状態が予想外の結果につながらなければならない。コードがテストされ、頻繁に使われていたなら、この時点ですでに発生確率は10%未満である可能性が高い。次にエンジニアがよりによってこのクラッシュダンプが必要だと判断し、資格情報スキャンソフトウェアがこの特定の資格情報を見つけられず、アカウントの一つが侵害されてネットワークアクセス権が生じ、そのユーザーが当該ダンプにアクセス可能で、ハッカーがそれを見つけて持ち出さなければならない。
それでも鍵は古く、コンシューマー向けメールアカウントへのアクセスにしか使えないので安全なはずだったが、古い鍵を受け入れるバグと、企業メールアカウント用トークンにこの署名鍵を拒否しないバグまであった。
良いシステム工学の教訓だ。どれだけ努力しても、結局は小さなものが十分に積み重なれば大事故が起きるので、起きたとしても爆発半径が限定されるように設計すべきだ。
事後分析では、不運な出来事がランダムに重なったかのように提示される。攻撃者が偶然 Microsoft を狙い、偶然競合状態があり、偶然クラッシュが起き、偶然どこかでクラッシュダンプを見つけたように見える。
しかし、最初の競合状態のバグから意図的に仕込まれていた可能性も考えるべきだ。クラッシュは意図的に誘発された可能性があり、攻撃者はダンプが特定の場所に生成されるのを待っていた可能性があり、共犯者がいた可能性もある。
Microsoft のエコシステムは、近所の子どもたちが各自の家から持ち寄った部品を適当にくっつけて作ったレゴの車のように見える。
競合状態と言うと人々は「発生確率10%未満」と言うが、実際には大きなクラッシュのたびに起きていて、単にクラッシュが頻繁には起きないだけかもしれない。
なぜディスクに書き込む前にマスキングしなかったのかは、神のみぞ知るというところだ。
西側ビジネス界の半分以上が Outlook.com に依存する構造は、かなり間違った状態に近いが、現在の金銭的インセンティブはレジリエンスや Outlook.com のような超中央集権的な存在を分割する方向に向いていないので、今後もこうしたことは起こり続けるだろう。
明確に説明されていない点がある：2023年7月11日に検知され、2021年4月に発生した疑いがあるなら、攻撃者はこの認証情報を2年以上持っていて、検知から公表まで2か月かかったということになる
偽造されたトークンがいくつあったのか、どれだけアクセスされたのかも抜けている。公表しないなら、悪い方向に推定せざるを得ない
検知後、修正適用までのスケジュールもなく、「この問題は修正された」という言葉だけだ。早く直していたことを願うしかない
直接的な問題4つは直したが、明らかにシステム的な問題があるように見えるのに、それに対して何をするのかも見えない
https://en.m.wikipedia.org/wiki/Adverse_inference
このような侵害には、Microsoft の内部インフラに対する非常に深い理解が必要だ。ハッカーチームによる組織的な作業だったと見るのが安全だ
安くできることではないが、見返りは莫大だ。超中央集権化は、ハッカーに少数の高価値標的へ労力を集中させる。成功さえすれば得るものが巨大だからだ
Google、Microsoft、Amazon のようなところの内部インフラを、すでに深く研究・分析している国家支援ハッカーチームがいることはほぼ確信している。今回の侵害は、彼らがすでにどれほどよく理解しているかを示している
もっと広いセキュリティ境界の中で分散化すべき時が来たと思う
慎重な表現を取り払えば、誰かが運用環境でミニダンプを開発用ワークステーションにダウンロードし、それがおそらくその開発者の社内 OneDrive のどこかで放置され、アカウントが侵害されたということだ。誰かがダンプを持ち去り、キーを見つけて大当たりしたわけだ
「いくつかの曖昧なバグが巧妙に悪用された」という表現は少しずれているように見える。どのセキュリティシステムも役割を果たせなかったミスの連鎖劇に近く見える
なぜ HSM を使わなかったのか分からない。そうしたハードウェアの核心的な目的は鍵素材の流出防止ではないのか
[1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
これは、キーが復旧不能なハードウェアに保存されていたのではなく、高権限の環境で実行される、単なるコンパイル済みコードである通常のサーバープロセスからアクセスできたという意味だ
このキーにアクセス可能なシステムが、通常の運用環境ではない別環境にあったという言及もない。したがって、どの運用機器でもキーにアクセスでき、その環境にアクセスできる誰もが潜在的に鍵素材を流出させられたと推定できる
https://learn.microsoft.com/en-us/azure/active-directory/dev... の検証セクションを見ると、私が見落としていなければ、発行者の日付や失効の有無を確認すべき重要性がまだ抜けているように思う
擬似コードにもないので、Microsoft が一度でも公開したキーならどんなキーでも信頼する実装が、ほかにもある可能性が高い。キャッシュ削除のような例外を除けば、という意味だ
Microsoft でさえ自社の看板製品である Outlook で自社のIDプラットフォームを正しく使えないなら、他の人たちに何の可能性があるのかと思ってしまう
単に Microsoft CA が署名したかどうかだけを確認したということだ。これはコードレビューで信じがたいほど明確に見える問題だ
本当に大きくやられた理由の一つは、キーをローテーションしていなかったためのように思う。キーがあってはならない場所へ移された時点と、実際に盗まれた時点の間に、かなり時間が経っていたように聞こえる
キーを頻繁にローテーションしていれば、そのキーでトークンを偽造することは不可能だったはずだ
こういう記事が出るたびに思うが、攻撃が物理的ではなくデジタルだという理由だけで、国家級の攻撃への対応を民間企業に任せる構造は本当におかしく見える。
中国の戦闘機が太平洋上空でFedExの航空機を撃墜したなら、米国の主権に対する攻撃と見なされ、政府が適切に対応したはずだ。FedExが自社の輸送機を守るために戦闘機部隊を自前で保有すべきだと期待されることもないだろう。「防空をまともにしていなかったFedExが悪い」と言う人もいないはずだ。
ところがデジタル領域になると、Microsoftが中国やロシアを相手に自力で防御すべきだ、ということを受け入れる空気になる。
各国政府は外国の工作員をかなり定期的に拘束しているが、そうした逮捕が全面戦争につながるわけではない。
第二に、米国もこうしたことを常に行っており、同盟国に対しても行っているため、より強い措置を正当化するのは難しい。
サイバー攻撃の範囲と量は非常に大きいが、米国もそれに相応する規模の対外攻撃を数多く行っていると理解している。