侵害されたMicrosoftキー: 想定以上に大きい影響

 (wiz.io)
1 ポイント 投稿者 GN⁺ 2023-07-24 | 1件のコメント | WhatsAppで共有
  • Storm-0558事件はExchange Online・Outlook.comの侵害として知られていたが、侵害されたMSA署名キーがAzure ADアプリケーションのOpenID v2.0トークン偽造にも悪用できたという分析が出ている
  • 影響が及ぶ可能性のある範囲は、個人Microsoftアカウント認証を使うMicrosoftアプリ、「Login with Microsoft」対応の顧客アプリ、特定条件のマルチテナントアプリにまで広がる
  • 問題の公開キーは少なくとも2016年からMicrosoft OpenIDキー一覧に存在し、2023年6月27日〜7月5日の間に置き換えられており、Microsoftが公開したacquired signing keyのthumbprintと一致する
  • Microsoftはキーを失効させて新たな偽造トークンは防いだが、キー失効前に生成されたセッションや古い公開キーのキャッシュを引き続き信頼するアプリは別途点検が必要
  • 偽造トークンはオフラインで作成できるためAzureポータルに発行の痕跡が残らず、生のトークンやkidログがなければ侵害確認は非常に困難

Exchange Onlineを超える影響範囲

  • MicrosoftとCISAは、Exchange OnlineとOutlook.comの複数顧客に影響したセキュリティインシデントを公表した
  • Microsoftによれば、中国関連の脅威アクターとされるStorm-0558がMSAキーという秘密鍵を取得し、Outlook Web AccessとOutlook.com向けのアクセストークンを偽造した
  • 脅威アクターはMicrosoftのトークン検証プロセスにあった2つのセキュリティ上の問題もあわせて悪用したと伝えられている
  • Wiz Researchの分析では、侵害されたキーはOutlook.comとExchange Onlineに限定されず、複数のAzure Active Directoryアプリケーション向けアクセストークンの偽造にも使えた可能性がある
    • 個人アカウント認証をサポートするアプリケーション
    • SharePoint、Teams、OneDriveのようなMicrosoft管理アプリケーション
    • 「Login with Microsoft」をサポートする顧客アプリケーション
    • 特定条件のマルチテナントアプリケーション

侵害されたキーはどのように確認されたか

  • 2023年7月11日、Microsoftは悪意ある行為者がMSA consumer signing keyを取得し、Exchange OnlineとOutlook.comアカウント向けのアクセストークンを偽造できたと公表した
  • WizはMicrosoftアカウントとAzure Active Directoryアプリケーション向けOpenIDトークンに署名できるキーを確認するため、MicrosoftのOpenIDトークン検証の公式ドキュメントを調査した
  • 当時、Azure個人アカウントv2.0アプリケーションは8個の公開キーに依存しており、Microsoftアカウントを有効化したAzureマルチテナントv2.0アプリケーションは7個の公開キーに依存していた
  • Internet Archive Wayback Machineで確認した結果、少なくとも2016年から一覧にあった公開キーの1つが2023年6月27日〜7月5日の間に置き換えられていた
    • この時期は、Microsoftがブログで明らかにした取得済みキーの置き換え時期と一致する
    • 以前の公開キー証明書は2016年4月5日に発行され、2021年4月4日に失効していた
    • thumbprintはMicrosoftが最新ブログで「Thumbprint of acquired signing key」として公開した値と同じである
  • Storm-0558が取得したキーはMicrosoftのMSAテナント向け秘密鍵だったが、複数のAzure Active Directoryアプリケーション向けOpenID v2.0トークンにも署名できたと分析されている

OpenID署名キー侵害が危険な理由

  • Azure identity platformはアプリケーション種別ごとに異なる信頼済み公開キー一覧を公開し、Azure Active Directoryが発行したトークンの完全性検証にこれを使用する
  • AADアプリケーションは正しい公開キー一覧でトークン署名を確認したうえで、トークンを信頼するかどうかを決定する
  • 一覧に含まれるキーの1つが侵害されると、その一覧で検証するアプリケーションは特定条件下で偽造アクセストークンを有効なトークンとして受け入れる可能性がある
  • WizがMicrosoftブログから推測した内容によれば、Storm-0558はAADアクセストークンの署名と検証に使われていた複数キーのうち1つにアクセスしたとみられる
  • 侵害されたキーは、個人アカウントおよびmixed-audience、つまりマルチテナントまたは個人アカウント向けAADアプリケーションのOpenID v2.0アクセストークン署名において信頼されていた
  • その結果、Storm-0558は理論上、Microsoft OpenID v2.0のmixed audienceおよび個人アカウント証明書を信頼する影響対象アプリケーションで、任意ユーザーとして認証されるトークンを偽造できた
  • identity providerの署名キーはTLSキーよりもさらに強力な秘密と見なせる
    • TLSキーが漏えいしても、攻撃者は影響を広げるために当該サーバーになりすます必要がある
    • identity providerキーは、メールボックス、ファイルサービス、クラウドアカウントなどへ単一ステップでアクセスできるトークンの偽造に使える
    • 同じリスクはMicrosoftだけでなく、Google、Facebook、Oktaのような主要identity providerの署名キー漏えいにも当てはまる

影響を受けたアプリケーションの種類

  • 影響対象はMicrosoftのOpenID v2.0を使うAzure Active Directoryアプリケーションに限定される
  • v1.0アプリケーションは侵害されたキーをトークン検証に使わないため影響を受けない

  • 個人Microsoftアカウントのみをサポートするアプリケーション

    • Microsoft v2.0プロトコルを使い、「Personal Microsoft accounts only」をサポートするAzure Active Directoryアプリケーションは影響を受ける
    • Outlook、SharePoint、OneDrive、TeamsのようなMicrosoft管理アプリケーションと、Microsoft Account認証をサポートする顧客アプリケーションが含まれる

  • マルチテナントと個人Microsoftアカウントを同時にサポートするアプリケーション

    • 「mixed audience」をサポートし、Microsoft v2.0プロトコルを使うAzure Active Directoryアプリケーションも影響を受ける
    • 脅威アクターは、個人Microsoftアカウントでログインしたアプリケーション利用者になりすます有効なアクセストークンを偽造できた
    • MicrosoftはMSAキーで組織アカウントをなりすましできないようにするため、OpenIDプロトコル拡張を導入した
    • 開発者はissuer claimをOpenID公開キー一覧のissuerフィールドと比較して検証する必要がある
    • この検証は、MSAテナント以外のissuerを持つアクセストークンにMSAキーが署名することを防ぐための仕組みである
    • この拡張はMicrosoft独自であり、実装責任はアプリケーション所有者にある
    • Wizは、多くのアプリケーションでこの検証手順が存在しない可能性があり、その結果として組織アカウントのなりすまし可能性も残っていると見ている
    • Microsoftブログによれば、OWAも同様の問題の影響を受ける
    • Microsoftは7月12日にこの検証機能を公式Azure SDKへ追加した

  • マルチテナントのみをサポートするアプリケーション

    • マルチテナントアプリケーションが「Organizations」ではなくcommon v2.0キーエンドポイントに依存するよう設定されていた場合、影響を受ける
    • このような構成は誤設定と見なすべきである
    • Microsoftの公式ドキュメントは「common」エンドポイントをいつ使うべきかを明確にしておらず、一部のマルチテナントアプリケーションも影響を受けうる

  • シングルテナントアプリケーション

    • 「この組織ディレクトリ内のアカウントのみ」をサポートするシングルテナントアプリケーションは影響を受けない

トークン偽造が成立する条件

  • OpenIDトークン検証では、アプリケーション開発者はトークンが意図されたスコープに対応する権限ある秘密鍵で署名されているか、audフィールドが対象アプリケーションのスコープと一致するかを確認しなければならない
  • アプリケーションはjwks_uriというメタデータエンドポイントから署名検証に許可された証明書を取得してトークンを検証する
  • 脅威アクターはJWTトークンを作成し、被害者のメールアドレスなどのデータを埋めたうえで、Azure Active Directory公開証明書エンドポイントに登録された侵害キーで署名し、有効なアクセストークンを偽造できる
  • 例として挙げられた侵害キーのkidは1LTMzakihiRla_8z2BEJVXeWMqoである
  • Microsoftのガイダンスでは、トークンが有効であるためにはiss claimがjwks_uriエンドポイントのissuerフィールドで指定されたMSAテナントissuerであり、tid claimもMSAテナントIDである9188040d-6c67-4c5b-b112-36a304b66dadでなければならない
  • AAD mixed-audienceアプリケーションでは、個人アカウントになりすます限り、MSAテナントがAzure ADアカウント用に署名したトークンが有効と見なされる可能性がある
  • ID Token検証の詳細はMicrosoftの公式ガイダンスで確認できる

キー失効後にも残るリスク

  • Microsoftが侵害されたキーを失効させたため、Azure Active Directoryアプリケーションはもはやそのキーで偽造されたトークンを有効なトークンとして受け入れない
  • 有効期限が長く設定されたトークンもアプリケーション側で拒否される
  • ただし、キー失効前に顧客アプリケーションですでにセッションが作成されていた場合、脅威アクターはアプリケーション権限を利用して永続化を確保した可能性がある
    • アプリケーションごとのアクセスキー発行
    • アプリケーションごとのバックドア設定
    • Microsoftの対応前にStorm-0558がOWA向けアクセストークンを偽造し、有効なExchange Onlineアクセストークンを発行した事例
  • Microsoft証明書失効前のAAD公開キーのコピーを保持しているアプリケーションもリスクがある
    • ローカル証明書ストアやキャッシュ済みキーを使用し、侵害キーを引き続き信頼している場合、トークン偽造に脆弱である
    • Microsoftはローカルストアと証明書キャッシュを少なくとも1日1回更新するよう推奨している

Azure利用者が確認すべきこと

  • 環境で侵害キーが使われたか確認するには、潜在的に影響を受けたアプリケーションを特定し、偽造トークン使用の痕跡を探し、Microsoftが公開したIndicators of Compromiseを活用して関連IPアクティビティを点検する必要がある
  • Microsoft OpenID公開証明書をキャッシュしたアプリケーションがある場合は、キャッシュを更新しなければならない
  • MicrosoftはMSAキーで組織アカウントに認証することを防ぐ追加検証を公式Azure SDKに組み込んでおり、当該パッケージ利用者は最新版へ更新すべきである

検知が難しい理由

  • 脅威アクターはアクセストークンをオフラインで偽造できるため、Azureポータルにはトークン発行の痕跡が残らない
  • クラウド利用者がキー使用の有無を確認するには、影響を受けうるAADアプリケーションのアプリケーション別ログを確認する必要がある
  • Wizが把握した影響対象は、Microsoft v2.0アクセストークン検証に次のエンドポイントを使用したアプリケーションである
  • 潜在的に影響を受けたAADアプリケーションは、Azure CLIでsigninaudienceがAzureADMultipleOrgs、AzureADandPersonalMicrosoftAccount、PersonalMicrosoftAccountのアプリを照会して特定できる
  • Azure WebAppsへリダイレクトされるAADアプリも別のCLIクエリで見つけられる
  • アプリケーションで使用されたアクセストークンを展開し、JOSE Headerのkidフィールドに1LTMzakihiRla_8z2BEJVXeWMqoという文字列があるか確認すれば、侵害キーで署名されたトークンを見つけられる
  • Microsoftによれば、侵害キーは非アクティブ状態だったため、このキーで署名されたすべてのアクセストークンは疑わしいものとして扱うべきである
  • アプリケーション別ロギングには標準化された慣行が不足している
    • 多くのアプリケーション所有者は、生のアクセストークンや署名キーを含む詳細ログを保持していない
    • このためイベントの特定と調査は非常に困難になりうる
  • 個人Microsoftアカウントをサポートしないマルチテナント専用AADアプリケーションでは、issとtid claimで偽造トークンを検知できる
    • MSAテナントID 9188040d-6c67-4c5b-b112-36a304b66dadで署名されたアクセストークンの接続試行は、侵害キーの使用を示している可能性がある
  • WebAppでHTTP Logsを有効にしている場合、Microsoftブログに記載された脅威アクター関連IPアドレスがアプリケーションにアクセスしたかどうかをLog Analyticsで確認できる

残る疑問と実務的な結論

  • 全体の影響は当初知られていたものよりはるかに大きく、クラウドの信頼、特にクラウドの基本構成要素であるidentity layerに長期的な影響を与える可能性がある
  • 潜在的に脆弱だったアプリケーションはMicrosoftアプリと顧客アプリを含めて数百万にのぼり、多くは侵害の有無を判断するのに十分なログを持っていない
  • アプリケーション所有者はAzure SDKを最新版へ更新し、アプリケーションのキャッシュが更新されているかを優先して確認すべきである
  • キャッシュが更新されていないアプリケーションは、侵害キーを使う脅威アクターに対して依然として脆弱である可能性がある
  • 現在も調査中の事案であり、脅威アクターがキーをどのように取得したのか、正確にいつ発生したのか、ほかのキーも侵害されたのかは、公表済み情報だけでは答えるのが難しい

関連記事

1件のコメント

 
GN⁺ 2023-07-24
Hacker News のコメント

  • アイデンティティプロバイダーの署名鍵は、現代において最も強力な秘密値に近いものです。たとえば TLS 鍵よりはるかに強力です
    多くの面で認証局（CA）の鍵と同等であり、Microsoft と Azure のサービスを使っている組織は潜在的な影響を評価すべきです
    「卵を一つのかごに盛るな」という古い言葉を、人々は忘れてしまったようです

    • これらの鍵がそれほど重要なら、なぜ CA 鍵レベルのセキュリティ対策で扱っていないのか分かりません
      なぜ数十、数百、場合によっては数千台のサーバーが少数の鍵を共有する構造なのか疑問です
      HSM ベースのルート鍵、データセンターごとの中間鍵、サーバーごとの一時署名鍵、証明書失効リストはどこにあるのでしょうか
      こうした攻撃に対してベアラートークン（bearer token）を安全に保護することがそもそも可能なのか、元のサービスに乱数を提示してペイロードを安全に取得する方式に戻るべきなのか考えてしまいます
    • そのことわざが作られた当時は、鶏たちが機能をできるだけ多く統合して生活の質を高めようと強く推し進めていなかったからでしょう
      卵を一か所に集めないと使えない機能が生まれてしまったわけです
    • うちの会社も Office 365、Teams などすべてに全振りしています
      全部が崩れたときに備えてポップコーンは用意してありますし、確かなのは会社が自分たちのせいにはしないという点です
    • 卵をどう分けろというのか気になります
      単に鍵をなくしていなかったであろう別の業者を使えという意味なのか分かりません
    • 現実的にどう避けられるのか分かりません
      今や事実上、巨大テック企業は4社程度しかないように思えます

  • 「侵害された MSA 鍵により、攻撃者は複数種類の Azure Active Directory アプリケーション向けアクセストークンを偽造できた可能性がある」という結論になりました
    これには SharePoint、Teams、OneDrive、「Microsoft でログイン」をサポートする顧客アプリケーション、特定条件下のマルチテナントアプリケーションのように、個人アカウント認証をサポートするすべてのアプリケーションが含まれます
    Microsoft が最近 Azure AD を Entra ID に変えたのが偶然であることを願います: https://devblogs.microsoft.com/identity/aad-rebrand/

    • これは初耳ですが、Microsoft の命名惨事は尽きない娯楽ですね
      セキュリティ製品を思い浮かべるときに、悪意ある行為者を外に締め出すのではなく、人々を中へ「入れる」ベンダーを思い浮かべたくはありません。entra は entrar、つまり「入る／入ってくる」に由来する言葉なので /s
      スペイン語では命令形なので、誰かに「入れ！」と指示している感じまであります

  • 「既存の公開鍵の証明書は2016年4月5日に発行され、2021年4月4日に失効しており、フィンガープリントは Microsoft が最新のブログ記事で『取得された署名キーのフィンガープリント』として掲載したキーのフィンガープリントと一致していた」
    これを正しく読めているなら、キーが失効していたのに使われ続けていたという意味なのか？

    • これらのキーが使われたシステムで有効期限検証がどう動作するのかは分からないが、一般にキーや証明書ベースの検証で失効したキー／証明書を扱う方法は2つある
      Microsoft がこれらのキーをどこで使っていたにせよ、どちらの方式だったのか知っている人がいるのか気になる
      1つは TLS の検証方式で、Cn が Cn-1 に署名され、さらに … C0 まで続く証明書チェーンを検査するとき、おおよそ次のように動作する
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 return NOT_EXPIRED
      各証明書の失効日を現在時刻を基準に検査する
      もう1つはコード署名で使われる方式で、おおよそ次のとおり
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      Cn は現在時刻を基準に検査し、それ以外は直下の証明書に署名した時刻を基準に検査する
      コード署名がなぜそのように動作するのかは理解できる。本質的にはデジタル公証なので、公証人が後から資格を失って免許が失効したからといって、すでに公証済みの文書が未公証の状態になってはいけないからだ
    • Microsoft が顧客に「Storm-0558 が非アクティブな MSA コンシューマー署名キーを取得した」と説明したときは、「Storm-0558 が失効した MSA コンシューマー署名キーを取得した」と言うべきだった
      また「検証上の問題により、このキーが Azure AD トークン署名で信頼され得た」としたときは、「複数の検証上の問題により、このキーが Azure AD トークン署名で信頼され得た」と言うべきだった
      そして「攻撃者は対象環境、ログ記録ポリシー、認証要件、ポリシーと手順をよく理解していた」と言ったときは、むしろ次のように言うべきだった
      「攻撃者は大胆な一撃離脱を狙っており、ポリシーのような細かいことには1秒たりとも気を払っていなかった可能性がある。あるいは攻撃者が未熟で、米国国務省がメールボックスアクセスイベントを詳細にログ記録できる特権のために、われわれにずっと多くの金を払っているという事実すら知らなかったのかもしれない。Boeing が MCAS でヒントを出したようなものだ。さらに攻撃者は、Chrome 92 が2021年に最後に更新されたもので、最新ブラウザを使うべき米国省庁の ICT システムを攻撃するにはかなり悪いユーザーエージェントの選択だという点も見落としていたようだ。また、米国国務省のメールボックスがどのようにアクセスされるのかをほとんど理解しておらず、欧州各地のランダムな公開データセンターを使って、ひどくお粗末な推測をしたものと思われる」
      [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
      [2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
      [3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...

  • このキーが HSM にあった可能性は非常に低そうに見える
    HSM にあるべきに思えるキーが盗まれたというニュースを見るたびに、いまだに驚かされる

    • HSM 内のキーはチームにとって使いにくく、ネットワーク接続型 HSM もあるが、開発者がよく使うツールチェーンとの統合が良くない
      最近、ツールチェーンとハードウェアセキュリティエンクレーブの間のギャップを埋める理想的なツールを自分で作ることができた: https://keymux.com
    • 人気のある HSM の1つである Thales Luna Network HSM は、毎秒20,000回の ECC 演算を実行できる [1]
      Azure AD の規模を考えても、Microsoft が署名用途に多数の HSM を必要としているとは限らない
      ただし HSM は管理が特に簡単ではなく、それが必要なほど広く使われていない理由の1つかもしれない
      [1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
    • 2つのシナリオがある
      1つ目は、Microsoft が JWT 署名キーをメモリ上に置いて使用しており、攻撃者がコードインジェクションや当該プロセスのメモリイメージへのアクセスによってキーを取得した可能性
      2つ目は、Microsoft が実際に HSM を使っていたものの、キーを地理的に分散する必要があり、その過程で攻撃者がキーにアクセスできた可能性
      1つ目のほうが可能性は高いが、2つ目も排除はできない
    • HSM って何？

  • FAANG 同士が互いにサイバー戦／スパイ活動を行うことを合法化すべきではないだろうか？
    そうすれば、曖昧さに頼る代わりに、少なくとも最低限のセキュリティベストプラクティスの水準には達せざるを得ない気がする

    • どこもバグバウンティプログラムを運営している
      実害を与えたり実際の顧客データをダウンロードしたりせず、発見内容を開示するなら、すでに合法だ

  • Satya が次の決算発表でこの大混乱を覆い隠すには、AI という言葉をもっとずっと多く言う必要がありそうだ

  • 外国勢力が、その勢力に相対するわれわれの代表者のメールアカウントに侵入したことより悪い侵害は、想像しにくい
    米国政府が、コンピューティングを主要クラウドプロバイダーへ移す政策を真剣に再検討することを望む

  • 「最後に、この記事について私たちと緊密に協力し、技術的に正確であることを確認するのを手伝ってくれた Microsoft チームに感謝します」
    このニュースを金曜日に公開することにしたのは、どういう経緯だったのだろう？

    • 夏の金曜日のニュース・ダンプのその後を見ると、月曜の夕方になっても静かなまま
      Google ニュースで「microsoft」と検索して最初の5ページを見て諦めたが、関連する言及は合計2件だけだった
      ほとんどは宣伝記事、製品プロモーション、株価関連のノイズのような「ニュース」だった

  • 「今回の事件の全体的な影響は、私たちが当初理解していたよりもはるかに大きい。この事件はクラウドへの信頼と、それを支える中核的な構成要素、とりわけクラウド上で私たちが行うあらゆることの基本的な土台であるアイデンティティ層に、長期的な影響を及ぼすだろう。私たちはここから学び、改善しなければならない」
    まずは何でもかんでもクラウドに入れないところから始めてはどうかと思う
    問題はクラウドそのものというより、結局は独占、あるいは少数の大企業によるカルテルを生み出す壊れた資本主義経済にある
    ロングテールの小規模企業にとっては、大企業の製品やサービスを使うのが合理的ではない場合でも、市場の勝者により大きな力を与えれば、結局は潰すには大きすぎる企業が生まれる
    こうした大企業は、たった一度のミス、たった一度のつまずきだけで、攻撃対象領域があまりにも大きくなる。こういう事故は起きるかどうかではなく、いつ起きるかの問題だ
    長期的に社会が生き残るには、利便性の一部を犠牲にしてでもフェデレーテッドなサービスが答えだ

    • コンピューター分野では、その原因はだいたい「IBMを買ってクビになった人はいない」という人間の本性に近い
      ビジネスリーダーは、より大きく、より良いフェデレーテッドなサービスを夢見る技術オタクではない
      ITはたいてい、損益計算書の上でも、コンピューターの問題を学び、決定し、対処するために費やす時間と苦痛の面でも、大きなコストだ
      たとえるなら、天気が微妙なのに Microsoft Airlines に乗ることにした場合、フライトが欠航して遅れても、同じ立場の人や同情してくれる人は多い
      反対に列車に乗る独自路線を選ぶと、列車の時刻表や駅などを把握する負担はすべて自分にのしかかる。「飛行機はみんな知っている」やり方だからだ
      そして Microsoft Air は無事に到着したのに列車で問題が起きれば、台所の床に湯気を立てる汚物の山のように、一人だけ目立つことになる

  • すばらしいまとめで、恐ろしくもあった
    複雑なテーマなのに、消化しやすく説明されていた