ハッキングされたMicrosoftのテストアカウントに管理者権限が付与される

[GN⁺]

Hacker Newsの意見

• 昔のRobloxハッキング事例を思い出した。非本番のステージングサイトでユーザー登録が可能で、「ここにあるものはすべて永続的ではない」というバナーが表示されていた。本番アカウントに新しい管理者アカウントが追加された際、誰かがステージングサイトで同じユーザー名で登録し、Cookieとトークンを使って本番アカウントを乗っ取り、サイトを危険にさらした。こうした問題が珍しくないと考えるのは難しくない。たとえば、ユーザー名やユーザーIDを基に暗号化トークンを生成していて、本番/ステージングごとに異なる秘密情報がない場合や、ステージングサイトが本番権限を取り違える外部サービスと通信している場合など。
• 大企業における開発/本番の境界は、人々が考えるよりはるかに透過的だ。よくある一日を考えると、PCにログインし、メールを確認し、その後同じ資格情報を使ってAzureポータルにログインする（すべて同じテナントによって支えられている）。アカウントはGitHubやクラウドアカウントにも接続されている。
• TeamsやOneDriveで作業できるように、理解しづらい権限を持つグループやチームがあちこちに作られ、それらは会社のディレクトリ内でほとんど見分けのつかないセキュリティグループとして残る。
• ときどき、まだ必要なものを使っているか尋ねる自動メールが届くが、メッセージは不明瞭で、本当に大きな会社では誰に聞けばいいのかも分からない（ヘルプデスクは返答に2日かかるし、TwitterでJohn Savillに連絡することもできないので、結局確認を押して先へ進む）。
• 結局のところ、構造には綻びが生じ、攻撃者は弱い地点で運よく当たれば、テナントをまたいで欲しいものを手に入れられる。
• ある賢明なCISOがかつて言ったように、ハッカーは侵入するのではなくログインする。
• サイバーセキュリティ業界では、これをよく "whoopsie" と呼ぶ。
• 研究者でセキュリティ専門家のKevin BeaumontはMastodonで、OAuthアプリに full_access_as_app ロールを割り当てられるアカウントは管理者権限を持っているはずだと指摘した。「誰か」が本番環境でかなり大きな設定ミスを犯したと述べている。
• システムの詳細は分からないが、それが問題ではないように思えるし、専門家がそれを問題だと言っていることに驚く。そもそも、そのようなミスを犯せる方法があってはいけない。設計者と管理者がそれを不可能にすべきであり、彼らが責任を負うべきだ。
• 立派なセキュリティ認証があっても、Amazonで36ドルの本に書かれているよく考えられたベストプラクティスが完全に無視されているように見える。
• この投稿で欠けているのは、著者たちが「本番」をどう定義しているのか、そして「非本番」アカウントが本番ドメインに対する管理権限を持ちうるのかという点だ。
• このパターンはMSエコシステム全体で例外ではなく常態だが、Microsoft自身がそれをやっているのは特に気まずい。
• ある会社では、最高アーキテクトがパスワードを覚えたくないという理由で、すべての本番サーバーとデータベースのパスワードをコードリポジトリ内のテキストファイルに保存していた。これがどれほど愚かなことかをCTOに指摘したところ、「我々は社員を信頼している」という返答と、「セキュリティ監査は通過した」という返答が返ってきた。
• 新しい職場に行くと、「そのほうが簡単だから」という理由で誰かが大量の権限を付与するのが嫌いだ。そんなことはすべきではない。会社を危険にさらすだけでなく、自分が望まない責任まで負うことになる。うっかり重要なものを壊してしまうかもしれないし、ハッキングされたら、権限を持っているせいで自分がやったと疑われるかもしれない。
• これがなぜ「ミス」と見なされるのか？ Microsoftで管理者として働くスパイの行動だった可能性もある。