- 1Passwordは、従業員向けアプリへのアクセスを管理する内部Oktaインスタンスで9月29日に不審な活動を検知したが、ユーザーデータや機密システムへの侵害は確認されなかった
- 今回のアクセスは、Oktaのカスタマーサポート管理システム侵害に関連しており、攻撃者は顧客がアップロードしたHARファイルから認証Cookieとセッショントークンを取得できた
- 1Password社内のNotionレポートでは、攻撃者がIT担当者がOktaサポートとの作業中に作成したHARファイルを入手し、その中にOktaトラフィックとセッションCookieが含まれていたと整理されている
- 攻撃者は1PasswordのOkta tenantで管理者ユーザーレポートを要求し、Google本番環境の認証に使うIDPを更新・有効化したが、その後の再利用の試みはIDPの削除により失敗した
- Okta侵害は、ベンダー侵入が顧客企業への攻撃につながる後続攻撃の事例となり、1Passwordは確認されている中で2社目のOkta顧客標的となった
1Password、内部Oktaアクセスを検知
- 1Passwordは、数百万人のユーザーと10万社以上の企業が利用するパスワードマネージャーである
- 同社は、従業員向けアプリ管理に使用しているOktaインスタンスで9月29日に不審な活動を確認した
- CTOのPedro Canahuatiは、当該活動を直ちに停止して調査を行い、ユーザーデータや従業員向け・ユーザー向けの機密システムへの侵害は見つからなかったと述べた
- その後1Passwordは、Oktaとともに、正体不明の攻撃者がどのようにアカウントへアクセスしたのかを調査した
Oktaサポートシステム侵害とHARファイルの危険性
- 1Passwordの事案は、Oktaが公表したカスタマーサポート管理システム侵害に起因することが確認された
- Oktaは、脅威アクターがカスタマーサポートのケース管理システムに不正アクセスし、一部のOkta顧客がアップロードしたファイルを閲覧したと明らかにした
- 入手されたファイルには、Oktaサポート担当者がトラブルシューティング中に顧客ブラウザの挙動を再現するために使うHARファイルが含まれていた
- HARファイルには認証Cookieやセッショントークンのような機密情報が保存される可能性があり、攻撃者が正規ユーザーになりすますために悪用できる
BeyondTrustに続く確認済み2件目の標的
- セキュリティ企業BeyondTrustは、攻撃者が有効な認証Cookieを使って同社のOktaアカウントへのアクセスを試みた後に侵入を発見した
- BeyondTrustでは、攻撃者が「いくつかの限定的な操作」を実行できたものの、アクセスポリシー制御が活動を阻止し、アカウントアクセスを遮断した
- 1Passwordは、Okta侵害後の後続攻撃の標的となった、確認されている2社目のOkta顧客となった
社内Notionレポートに記された経緯
- 10月18日付で作成され、1Password社内のNotionワークスペースで共有されたレポートには、攻撃者が同社IT担当者の作成したHARファイルを入手したと記されている
- 当該担当者は、最近Oktaサポートとの作業の中でこのファイルを作成していた
- ファイルには、1Password従業員のブラウザとOktaサーバー間のすべてのトラフィック記録とセッションCookieが含まれていた
- 1Passwordは、匿名の従業員がテキストとスクリーンショットで提供した文書の真偽確認要請に応じていない
- レポートによると、攻撃者は1PasswordのOkta tenantにもアクセスした
- Okta tenantは、従業員、パートナー、顧客に割り当てられるシステムアクセス権と権限レベルの管理に使われる
- 攻撃者はグループ割り当てを確認し、ほかの操作も実行したが、一部の操作はイベントログに記録されなかった
- ログイン時にGoogleが提供する本番環境認証に使われるIDP(identity provider)を更新した
攻撃者が実行した操作と阻止された再試行
- 1PasswordのITチームは、9月29日に管理者権限を持つ1Passwordユーザー一覧の要求を示唆する予期しないメールを受け取り、アクセスの事実を把握した
- チームメンバーは、承認された従業員がその要求をしていないと判断し、社内のセキュリティ対応チームに通知した
- 攻撃者が実行した操作は次のとおり
- IT担当者のOktaダッシュボードへのアクセスを試みたが、阻止された
- 1PasswordのGoogle本番環境に接続された既存のIDPを更新した
- そのIDPを有効化した
- 管理者ユーザーレポートを要求した
- 10月2日、攻撃者は再び1PasswordのOkta tenantにログインし、以前に有効化したGoogle IDPの使用を試みたが、IDPが削除されていたため失敗した
- 2回のアクセスはいずれも米国のクラウドホストLeaseWebのサーバーから行われ、WindowsマシンのChromeバージョンが使われていた
- 事件後、1PasswordはOkta tenantの設定を変更し、Okta以外のIDプロバイダー経由のログインを拒否するようにした
ベンダー侵害が顧客企業への攻撃につながる構図
- Okta侵害は、近年、大規模な顧客基盤を持つソフトウェア・サービス提供企業を狙った一連の攻撃のひとつである
- 攻撃者は提供企業に侵入した後、その足場を利用して顧客企業を標的にする後続攻撃を実行する
- 今後、さらに多くのOkta顧客が確認される可能性がある
1件のコメント
Hacker Newsのコメント
SSOを外部に委ねるのは、技術的により簡単か、運用能力があるかだけの問題ではない。顧客契約書に評判の良いSSOプロバイダーを使っていると書けるし、鍵管理方式や鍵情報の保護に関する文書化責任もその業者が負うことになるのが大きい
1Passwordはすでにそうした体制を備えていた可能性が高いので少し特殊だが、普通は「組織内の誰も鍵にアクセスできない」と言うほうが、「Bobだけは例外で、彼がSSOサーバーを運用しており、私たちは彼を信頼している」と言うよりはるかに簡単だ
Cのメモリ安全性の脆弱性が最も多く語られるのは興味深いが、実際に影響が大きいのは、いわゆるベストプラクティス設計に従った結果として過度な複雑性から生じる洞察の崩壊であることが多い
巨大な複雑性を把握できない人間の限界が根本原因だと思う
後者は人間に関わるため複雑になりがちで、そのため技術に救いを求めやすい
「ITチームメンバーのすべてのシステム認証情報をローテーションし、MFAはYubiKeyのみを使うように変更した」という部分を見ると、これをきっかけに全社員が YubiKeyベースの2要素認証 を使うようになればよいと思う。FIDO2未満は本当に弱い。
それにしても、なぜいまだに人々がOktaを選ぶのか不思議だ。個人的には、IDプロバイダーとして GSuite を使うほうがずっと楽だと感じる。Oktaはかなり深刻な侵害を受けているし、正直それ以前からもセキュリティ慣行について良い話は聞かなかった。
ハードウェアベースのMFA強制は良い慣行であり、将来的にスピアフィッシングのような攻撃を防ぐことはできるが、今回の件そのものとは無関係だ。
人々がOktaを選ぶのは、「IBMを買ってクビになる人はいない」に近い。自前の Keycloak を運用して侵害されたら自分の責任だが、Oktaなら自分の問題ではなくなるというアウトソーシング構造も一因だ。
Google Workspaceを本格的な用途で実際に使ったことがあるのか疑わしい。最も機能の乏しいIDプロバイダーの1つで、Oktaは最も機能が多い部類だ。どちらも車輪が2つあるという理由で、自転車とオートバイを比べるようなものだ。
技術フォーラムでGoogle WorkspaceをIDプロバイダーとして勧めるのを見る日が来るとは思わなかった。
YubiKeyを使うと、あらゆるパスワード問題のカスタマーサポートを外部委託先ではなく社内IT部門が担うことになる。
MFAには技術的な問題と社会的な問題があり、キー・トークン・携帯電話・SMSといった実装の技術的セキュリティ面はほとんど些細で、カスタマーサポート・忘れたパスワード・洗濯機に入ったキー・メール受信不可といった社会的問題のほうが圧倒的に大きい。
誰もが、セキュリティにおける巨大で間抜けなカスタマーサポート役を外注したがるが、そうすると今度は全員がコスト削減へと動機づけられる。その結果がOktaだ。
例えば、全社員がGSuiteにいる組織でAWS組織へのアクセスを提供するには、AWS SSO[1]が推奨方式だ。接続を設定すればアクセスはできるが、穴がある。
GSuiteのユーザーグループを基準にAWS SSOへユーザーを自動プロビジョニングしたり削除したりする機能がない。SSOのSCIMサポートで自前のコードを書くことはできるが、保守が必要だ。
SSOセッションを作る際にMFA確認を強制する方法が、GSuite側にもAWS SSO側にもない。GSuiteはSAMLアプリ認証の前にMFA確認を要求できず、AWS SSOも内部Directoryを使う場合と違って、IDプロバイダー利用時にはMFA確認を強制できない。
Oktaや類似製品はこうしたことをやってくれ、利用中のエンドポイントに応じてMFA確認をかけることもできるらしい。自分で試したわけではなく、マーケティング資料や営業の説明ベースだ。
要するに、OktaはIDプロバイダーと利用アプリケーションの間に入る 自動化とセキュリティの接着剤 をはるかに多く提供している。
[1] ここでいうAWS SSOは、AWS製品の「AWS IAM Identity Center (Successor to AWS Single Sign-On)」を指す。
今見えている証拠は、Oktaが昨年侵害を受け、今回も侵害を受け、その今回の侵害はカスタマーサポート部門またはシステムで発生したらしい、という程度だ。侵害の公表が遅れたのかもしれないし、虚偽報告が多くて最近まで証拠を見つけられなかったのかもしれない。最初に通報した顧客を適切に評価せず、通報後の顧客とのコミュニケーションも不十分だったのかもしれない。
わからないことはずっと多い。攻撃者がどれほど熟練していたのか、各IDプロバイダーが何回侵害されたのか、何回検知したのか、検知しても隠蔽したのか、各サービスにセキュリティバグがどれだけあり、どれほど深刻で、見つけやすいのか、侵害検知能力はどうか、従業員教育はどれほど行き届いているのか、実際にセキュリティを気にかける従業員の割合はどれほどか、といったことはわからない。
Oktaが侵害を報告したという理由だけで、その製品がより悪いと結論づけることはできない。他製品がどれほど良いのかはわからず、Oktaが一部またはすべての競合より優れている可能性もあれば、もちろん劣っている可能性もある。
昔は1Passwordを定価で購入し、ソフトウェアは完全にオフラインで動作して、暗号化された保管庫をローカルやDropboxに保存していた。オンライン上に盗まれるものがないので、ハッカーを心配する必要もなかった。
ところが誰かがそろばんを弾いて、収益性を高める道は全員のデータを クラウド に移し、サブスクリプション料金 を取ることだと決めた。そして今、私たちはデータが流出したかどうかを心配している。
それに、今わかっている範囲ではDropboxに保管庫を置くのとどれほど違うのだろうか。Dropboxもハックされうるし、そのデータは暗号化されていないことで有名だ。少なくとも、実際に1Passwordの保管庫が侵害された事例を知っているわけではないだろう？
https://blog.1password.com/okta-incident/
元のインシデント報告書: https://blog.1password.com/files/okta-incident/okta-incident...
その後、未知の行為者が、そのHARファイル作成時に使われていたのと同じOktaセッションでOkta管理者ポータルにアクセスした。
銀行がいつも言うように、サポート担当者にパスワードを渡してはいけない。
今回の責任は明確に Okta にある。問題解決のために平文の HAR エンコード済みセッションを要求しながら、エンドユーザーがきちんと整理してくれることを当てにしている。
アップロード時点で HAR データを整理して、システムにアクセスできて薄給で人手も足りないサポート技術者が見るときには、関連があり安全な部分だけが残るようにすればいいのではないか。
HAR は構造化データなので、プログラムで整理するのは非常に簡単だ。ロケット科学ではない
なぜ人々が超簡単・超親切なオンラインサービスではなく セルフホスト・セルフ同期のパスワードマネージャー を使うのかとよく問われるが、理由は同じだ。自宅の鍵を近所の駅のロッカーに放り込まないのと同じことだ
こうした組織は、声明を出す数週間前、時には数か月前に問題を修正している。
オープンソースを使っていて致命的なバグが見つかれば、報道発表と同時にパッチを受け取れるだろうが、大規模サービスはその問題をすでに修正している可能性が高い。平均的なユーザーにとっては、リスクに対する見返りは サービス型ソリューション の側にある
スクリプトからも使える。
サーバー侵害もなく、Web 拡張機能の脆弱性もなく、サーバー障害で全パスワードを失うこともない。ただ普通にうまく動く
「1Password が後続攻撃の対象となったことが判明している 2 社目の Okta 顧客になった」という文は妙だ。Ars は Cloudflare も被害者だったことを知らないのか。
https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...
アプリで 不審な挙動 を監視するベストプラクティスが気になる。サービス全体のリクエスト率やエラー率の確認のような基本は分かるが、実際にはどこまで高度になるのだろうか。
イベントストリームを投入すると異常な挙動を見つけてくれる知的なツールがあるのか、それとも監視すべきことをすべて事前に洗い出してルールを追加しなければならないのか気になる
こうしたイベントストリームができれば、データ分析ツールを回せる。数日・数週間・数か月の活動から正常なベースラインを作り、大量のパスワード変更やメールアドレス変更のような飛び抜けた挙動でアラートが鳴るようにすべきだ。
ただし在宅の仮説にすぎないので、監査ログやその活用を実際に扱ったことがある人がいるのか気になる
また検知したのか。
https://news.ycombinator.com/item?id=37991863