- Microsoft への侵害は、MFA のない古いテストアカウントが上級幹部やセキュリティ・法務チームのメールへのアクセスにつながった点で、単なるアカウント乗っ取りよりも深刻
- ロシア国家関連グループ Midnight Blizzard は、脆弱な認証情報を password spraying で悪用し、「legacy non-production test tenant account」にログインした
- 攻撃者は侵害したテストテナントで OAuth アプリ権限を利用し、Office 365 Exchange Online の
full_access_as_app ロールを取得した
full_access_as_app の付与には 管理者権限が必要なため、テストアカウントが本番環境で過剰な権限を持っていた設定ミスだったとの批判が出ている- 最小権限の原則を外れたテストアカウントと、住宅用プロキシを使った password spraying は、従来の侵害指標中心の検知を難しくする
テストアカウントからメールアクセスまで
- ロシアの国家ハッカーは password spraying により脆弱な認証情報を悪用し、「legacy non-production test tenant account」にログインした
- このテストアカウントは 多要素認証で保護されていなかった
- その後、Microsoft の上級幹部とセキュリティ・法務チーム社員のメールアカウントにアクセスできる権限が取得された
- 攻撃グループ Midnight Blizzard は OAuth 認証プロトコルを悪用し、権限のあるメールアカウントへ継続的にアクセスした
- 侵害したテストテナントで 悪意あるアプリを作成した
- Microsoft Office 365 メールサービスのすべてのメールアドレスにアクセスできる権限をアプリに付与した
- 既存のテスト用 OAuth アプリケーションを使って、Office 365 Exchange Online の
full_access_as_app ロールを付与した
管理者権限を持つ legacy テストアカウント
- Microsoft の更新情報には、「legacy test OAuth application」が Microsoft corporate environment で elevated access を持っていたことが含まれている
- Kevin Beaumont によれば、OAuth アプリに
full_access_as_app ロールを付与するには、アカウントに 管理者権限が必要
- Beaumont はこの構成を「本番環境におけるかなり大きな設定ミス」と評価した
- 古い legacy テストアカウントにこのような広範な権限を付与し、維持する妥当な理由は想像しにくいとの批判が出ている
- Microsoft は、テストアカウントが当初なぜそのような構成に設定されたのか、legacy 状態になった後もなぜ維持されたのかについて説明を拒否した
最小権限の原則を外れた構成
- この構成は、アカウントが作業実行に必要な最小限の権限だけを持つべきだという 最小権限の原則に反している
- legacy テストアカウントが管理者権限を持つ必要がある理由を理解しにくい点が核心的な問題
- Beaumont はこれを、セキュリティ、MFA、ファイアウォール、監視のないテストドメインに、本番システムの Domain Admin ユーザーを置いている状況に例えた
- Domain Admin ユーザーは、ドメインコントローラーと Active Directory を含む、ネットワークに接続されたデバイスに対する完全な管理者権限を持つ
- ネットワークで最も強力なアカウントであるため隔離されるべきで、本番システムに含まれることはまれであるべき
- 強力なパスワードや標準的なセキュリティ対策なしにこのようなアカウントが放置されると、被害が大きくなる
他組織への侵害とステルス性の高い password spraying
- Microsoft は、Midnight Blizzard が他の組織も追加で侵害していたことを検知し、影響を受けた組織に通知した
- Hewlett-Packard Enterprises も、自社ネットワークが Midnight Blizzard にハッキングされたと明らかにした
- その侵害は5月に発生した
- 発見と遮断は12月まで行われなかった
- テストアカウントへのアクセスに使われた password spraying は、限られた数のアカウントに対し、アカウントごとに少ない回数で実行された
- 攻撃者は分散した 住宅用プロキシインフラにより、悪意ある活動を目立ちにくくした
- 評判の良い IP アドレスから接続した
- 想定される地域にある IP アドレスを使用した
- 正規ユーザーのトラフィックに紛れて見えるようにした
従来の侵害指標検知の限界
- 住宅用プロキシを使う手法は新しいものではなく、2020年の SolarWinds サプライチェーン攻撃でも使われた
- SolarWinds 攻撃も Midnight Blizzard が実行したものと関連付けられている
- 住宅用プロキシは多数の正規ユーザーの IP を通じてトラフィックをルーティングするため、従来の 侵害指標ベースの検知は実質的に困難になる
- Midnight Blizzard は、米英政府がロシア対外情報庁 SVR のために活動していると説明したグループ
- 同じグループを追跡する別名として APT29、the Dukes、Cloaked Ursa、UNC2452、Dark Halo が使われている
1件のコメント
Hacker News の意見
昔聞いた古い Roblox ハッキングを思い出す。ユーザー登録が可能な非本番のステージングサイトがあり、「ここにあるものは永続的ではない」というバナーが出ていた。
本番環境に新しい管理者アカウントが追加されたところ、誰かがステージングサイトで同じユーザー名で登録し、その Cookie とトークンを使って本番アカウントを乗っ取り、サイトを侵害できた。
ユーザー名やユーザー ID ベースで暗号化トークンを作る際に本番/ステージングごとに別のシークレットを使っていなかったり、ステージングサイトが外部サービスと通信する中で本番の権限付与と混ざったりする場合、こうした問題はそれほど珍しくない気がする。
気づいてすぐに正直に知らせた。
大企業における 開発/本番の境界は、人々が考えたがるよりもはるかに穴だらけだ。
典型的な一日を考えると、PC にログインし、メールを確認してから同じ資格情報で Azure ポータルにログインする。結局すべて同じテナントに紐づいていて、アカウントは GitHub やクラウドアカウントにも接続されている。
Groups や Teams があちこちに作られ、怪しげな権限が付いたまま、Teams や OneDrive を使うために生まれたものが、会社のディレクトリ内でセキュリティグループとほとんど区別されない状態で残っている。
ときどき「これはまだ必要ですか」という自動メールが来るが、メッセージは不透明で、非常に大きな会社では誰に聞けばいいのかもはっきりしない。ヘルプデスクは2日後にしか返事をしないし、だからといって Twitter で John Savill に聞くわけにもいかないので、そのまま確認を押して済ませてしまう。
結局、組織の布地が裂け始め、攻撃者は弱い箇所から運よく入り込み、テナント内を 横移動して欲しいものを持っていく。
賢明な CISO が言ったように、ハッカーは侵入するのではなくログインする。
もちろん、みんなが Microsoft クラウド、Skype、Twitter、OneDrive のようなものを使っているという話で、もっともらしく人名まで放り込んでいる。
「管理者権限を持つアカウントだけが、OAuth アプリにほぼ全権に近い full_access_as_app ロールを付与できる。誰かが本番環境でかなり大きな設定ミスをした」という Kevin Beaumont の言葉について、システムの詳細を知らない立場から見ると、それが核心的な問題のようには思えない。
そもそも、そういうミスをする方法自体が存在してはいけない。設計した人と運用する人が不可能にしておくべきで、責任もそこにある。
内部の人全員を感電させるボタンがある工場を作って運用し、誰かが誤ってそのボタンを押したのなら、問題がどこにあるかは明らかだ。
何年もの間、ポリシー・手順・規定・法律をすべて無視して、そのような権限をまったく必要としない VIP に スーパー管理者/root 権限を与えろという要求を何度も受けた。
最近はあらゆる仕事が兼務、パートタイム、二重役割、三重役割のようになっていて、さらに悪化している。
付与可能な実際の権限よりロール数のほうが多いロールベースアクセス制御も見たことがある。そうなると RBAC の目的は自壊する。権限を個別に付与するほうが早かったが、それではレポートにロールが表示されないという理由で許可されなかった。
こういうものは技術担当者から出てくるのではなく、悪いリーダーシップから出てくる。
以前、社内 ERP の RBAC 権限システムにこの問題を緩和する拡張を設計したことがある。「権限例外」というタイプを用意し、ロール外の権限が必要な人はその方法で割り当てることで、職務ロール外の作業が可能な人の一覧をレポート化できるようにした。
結局、権限にフラグを1つ追加しただけだが、うまく機能した。HR が四半期ごとに権限例外を確認して削除を検討し、パートタイムのヘルプデスクが試行錯誤で権限を解き放つ代わりに、実際に分かっている権限者が管理できた。
定量化可能なリスクから企業や産業を守るという立派な セキュリティ認証は山ほどあるのに、Amazon で36ドルの本に書かれている理性的で思慮深いベストプラクティスは完全に無視されるのが笑える。
セキュリティがまるでリボンキャンペーンのように見える。
セキュリティを製品のように売る人は詐欺をしているのだ。
一般社員はセキュリティそのものにほとんど関心がなく、ただ自分の仕事をしている。
サーバー・アプリケーション・設定が多すぎて、セキュリティ意識のある社員だけですべてをレビューするには足りない。
長く見ていれば、どんな会社でもいつかは開いていてはいけないものが開いている状態になる。ハッカー集団がやっているのは、まさにずっと隙を探し続けることだ。
会社は運用中に新しいサーバーや新しい設定を作り続けなければならないので、一度設定して終わりという問題ではない。
新しい職場に行ったとき、誰かが「このほうが簡単だから」といって権限を大量に付与してくるのが本当に嫌だ。そんなことをしてはいけない。
会社が侵害にさらされるだけでなく、自分に望まない責任まで押し付けることになる。誤って重要なものを壊してしまうかもしれないし、何かがハッキングされたとき、自分がその権限を持っているという理由で疑われるかもしれない。
実質的にはサービスレベルで Windows XP のセキュリティポップアップのようなものを経験している。作業の各段階で別の何かに認証するよう求められ、適切な権限が付いた適切な資格情報を得るまでに数日かかることもある。
サポートチームが諦めて、新入社員にアカウントと権限をまとめて投げ渡すのも、人間的には理解できる。
この記事で抜けている点は、非本番アカウントが本番ドメインの管理者権限を持っているなら、筆者たちが「本番」をどう定義しているのかということ
だから「22万人規模の会社で、ある時点で誰かがミスをした」という見方に集中しても、あまり役に立たない
ただし、ほとんどの会社では本番システムとテストシステムの間に、たいてい堅く厚い線引きがある。テストアカウントに本番アクセス権を与えることは実質的に不可能であるべきなので、どうしてそんなことが起きたのかが調査の焦点になるべき
もっとひどい例も見たことがある。法律事務所で働いていたとき、管理者とパートナーにあらゆるものへの管理者アクセス権を与えていた
パスワードリセット後のデフォルトパスワードは「passme」だった。元のパスワードが長すぎて覚えにくいという理由だった。サーバーにログインした後でパスワードを変更することになっていた
ハッカーが彼らのアカウントをいくつか乗っ取り、あれこれいじってデータを盗んだ。一部のテストアカウントにも管理者権限があった
もうそこで働いていなくてよかった。私はプログラマーアナリストで、Visual BASIC 6.0を動かすために自分のPCへの管理者権限だけを持っていた
こうしたパターンはMicrosoftエコシステム全体では例外というより規則に近いが、Microsoft自身がそうしていたというのは特に面目を失う話だ
Microsoftのセキュリティチームは、こうした大事故を防ぐためのツールやベストプラクティス文書にかなり力を入れてきた
M365の多要素認証の強制はかなりひどい。お金を払う仕組みになっている
もっと大きな問題は、人々が忘れてしまうことだ。管理者権限を持つテストアカウントを5つ作っておき、誰かが全社ユーザー権限監査をするまで表に出てこない
以前勤めていた会社は、本番サーバーとデータベースのすべてのパスワードをコードリポジトリ内のテキストファイルに入れていた。チーフアーキテクトがパスワードを覚えたくないという理由だった
CTOにそれがどれほど愚かなことかを話したら、「われわれは従業員を信頼している」「セキュリティ監査に通っている」と返された
いまだに顔を手で覆った衝撃が残っている
ただの厄介な要素であって、セキュリティ機能ではない。「c00lz500」のようなパスワードは使わず、いっそ空文字列のようなものを使う
その代わりにファイアウォールと内部ネットワークを使う