- Cloudflareは2023年11月23日、自社ホストのAtlassianサーバーで脅威アクターを検知したが、顧客データ・顧客システム・グローバルネットワークのシステムと設定には影響がなかったと発表した
- 侵入経路は、2023年10月のOkta侵害後にローテーションされていなかった1つのアクセストークンと3つのサービスアカウント認証情報であり、アクセスはJira、Confluence、BitbucketなどのAtlassian環境に集中していた
- 脅威アクターは11月14日から17日にかけて偵察と内部文書へのアクセスを行った後、11月22日にScriptRunner for Jiraを通じてSliverをインストールし、永続的アクセスを確保した
- Cloudflareは「Code Red」対応として、5,000件以上の本番認証情報をローテーションし、4,893台のシステムをフォレンジック選別調査し、グローバルネットワークの全マシンとAtlassian製品を再イメージ化・再起動した
- CrowdStrikeによる独立調査でも見落とされた活動は見つからず、最後の脅威活動の証拠は2023年11月24日10:44 UTCと確認された
事件の概要と影響範囲
- Cloudflareは2023年11月23日、自社ホストのAtlassianサーバーで脅威アクターを検知した
- セキュリティチームは直ちに調査を開始し、アクセスを遮断した
- 11月26日にCrowdStrikeのフォレンジックチームを招き、独立分析を実施した
- 今回の事件で顧客データや顧客システムは影響を受けていない
- サービスは関与していなかった
- グローバルネットワークのシステムや設定変更もなかった
- アクセス制御、ファイアウォールルール、自社のZero Trustツールで強制したハードウェアセキュリティキーがラテラルムーブメントを制限した
- 脅威アクターのアクセス範囲は、社内WikiであるAtlassian Confluence、バグデータベースJira、ソースコード管理システムBitbucket、そしてAtlassianが稼働するサーバーに限定されていた
侵入に使われた認証情報
- 侵入は、2023年10月のOkta侵害後に漏えいしていたもののローテーションされていなかった1つのサービストークンと3つのサービスアカウントから始まった
- Moveworksサービストークン: Atlassianシステムへのリモートアクセスに使用
- Smartsheetサービスアカウント: Atlassian Jiraインスタンスの管理者権限を保有
- Bitbucketサービスアカウント: ソースコード管理システムへのアクセスに使用
- AWS環境アカウント: グローバルネットワーク、顧客データ、機密データへのアクセス権限はなかった
- これらのトークンとアカウントは未使用だと誤認され、ローテーション対象から漏れていた
- Cloudflareは、この問題はAtlassian、AWS、Moveworks、Smartsheetの不備ではなく、Cloudflareが認証情報をローテーションできなかった結果だと明記した
攻撃タイムライン
- 11月14日09:22:49から脅威アクターがシステム探索と偵察を開始した
- Oktaインスタンスへのログイン試行は拒否された
- Cloudflare Dashboardへのアクセスも遮断された
- Cloudflare Appsマーケットプレイスを動かすAWS環境にはアクセスしたが、この環境はグローバルネットワークと顧客データから分離されていた
- 11月15日16:28:38にAtlassian JiraとConfluenceへのアクセスに成功した
- Moveworksサービストークンでゲートウェイを通過し、SmartsheetサービスアカウントでAtlassian製品群にアクセスした
- Wikiでremote access、secret、client-secret、openconnect、cloudflared、tokenなどを検索した
- 2,059,357件のJiraチケットのうち36件、194,100件のWikiページのうち202件にアクセスした
- アクセスしたJiraチケットには、脆弱性管理、secretローテーション、MFAバイパス、ネットワークアクセス、Oktaインシデント対応に関する項目が含まれていた
- 11月16日14:36:37には、Smartsheet認証情報で一般のCloudflareユーザーのように見えるAtlassianアカウントを作成し、複数のグループに追加した
- Smartsheetサービスアカウントが削除されてもAtlassian環境に継続アクセスできるようにする措置だった
- 11月17日14:33:52から11月20日09:26:53までは、短いアクセステストを除いてCloudflareシステムへのアクセスが中断した
- 11月22日14:18:22には、SmartsheetサービスアカウントのJira管理者権限を利用してScriptRunner for JiraプラグインでSliver Adversary Emulation Frameworkをインストールした
- Sliverは、レッドチームと攻撃者がC2、接続性、永続的かつ秘匿的なアクセスのために使うツールおよびフレームワークである
- これによりAtlassianサーバーへの永続的アクセスを確保し、ラテラルムーブメントを試みた
- ブラジル・サンパウロの、まだ本番投入されていないデータセンターにある非本番コンソールサーバーへのアクセス試行は失敗した
ソースコードと文書へのアクセス
- 脅威アクターは11月22日以降の1日間で、11,904件のリポジトリのうち120件のコードリポジトリを閲覧した
- このうち76件のリポジトリは、Atlassian Bitbucketのgit archive機能を使ってAtlassianサーバーへダウンロードされた
- Cloudflareは外部流出の有無を確認できなかったが、流出したものとみなして対応した
- 76件のリポジトリは主に次の領域に関連していた
- バックアップの動作方式
- グローバルネットワークの設定と管理
- CloudflareのIDシステム
- リモートアクセス
- TerraformとKubernetesの利用
- 一部のリポジトリには暗号化されたsecretが含まれており、Cloudflareは強力に暗号化されていた場合でも直ちにローテーションした
- Cloudflareは、ソースコードそのものよりも、コードに含まれる埋め込みsecret、脆弱性、その後の攻撃に悪用され得る経路を重点的に調査した
- Cloudflareは多くのソースコードをオープンソースとして公開しており、ブログを通じて使用しているアルゴリズムや手法も公に扱ってきたと説明した
検知と遮断
- 11月23日16:00にセキュリティチームが脅威アクターの存在に関するアラートを受けた
- 15:58: 脅威アクターがSmartsheetサービスアカウントを管理者グループに追加
- 16:00: この変更に関する自動アラートがセキュリティチームに送信
- 16:12: Cloudflare SOCが調査開始
- 16:35: Smartsheetサービスアカウントを無効化
- 17:23: 脅威アクターが作成したAtlassianユーザーアカウントを発見し無効化
- 17:43: Cloudflare内部でインシデントを宣言
- 21:31: 脅威アクターの既知のIPアドレスをブロックするファイアウォールルールを適用
- 11月24日には最後の活動とSliverの削除が確認された
- 10:44: 最後に確認された脅威アクターの活動
- 11:59: Sliverを削除
- 脅威アクターは、内部メトリクス、ネットワーク設定、ビルドシステム、アラートシステム、リリース管理システムなど多様なシステムへのアクセスを試みたが、成功しなかった
- グローバルネットワーク、データセンター、SSLキー、顧客データベースまたは設定情報、Cloudflare Workers、AIモデル、ネットワークインフラ、Workers KV、R2、Quicksilverのようなデータストアへのアクセスの証拠は見つからなかった
「Code Red」対応と強化作業
- Cloudflareは11月24日に脅威アクターを環境から排除した後、侵入調査とアクセス範囲の確認のために全社的な人員を投入した
- 11月27日からは、セキュリティチーム内外の多くの技術者がCode Redプロジェクトに集中した
- 今後の侵入に備えて環境の統制を強化・検証・修正した
- 脅威アクターが継続してアクセスできないことを検証した
- すべてのシステム、アカウント、ログを調査し、永続的アクセスの有無とアクセス・試行の対象を確認した
- 主な措置は次のとおり
- 5,000件以上の本番認証情報をローテーション
- テストおよびステージングシステムの物理的分離
- 4,893台のシステムをフォレンジック選別調査
- グローバルネットワークの全マシンを再イメージ化し再起動
- Jira、Confluence、BitbucketなどすべてのAtlassian製品を再イメージ化し再起動
- サンパウロのデータセンター設備は製造元に返却された
- 製造元のフォレンジックチームがアクセスまたは永続性確保の有無を調査した
- 何も見つからなかったが、Cloudflareはハードウェアを交換した
- さらに、更新されていないソフトウェアパッケージ、作成された可能性のあるユーザーアカウント、未使用の有効な従業員アカウント、Jiraチケットやソースコードに残っている可能性のあるsecret、WikiにアップロードされたHARファイルを調査した
- HARファイルはトークンが含まれていた可能性に備えて削除された
- 即時のCode Red作業は2024年1月5日に終了したが、認証情報管理、ソフトウェア強化、脆弱性管理、追加アラート改善作業は継続している
CrowdStrike調査とIOCs
- CrowdStrikeは脅威アクター活動の範囲と永続性の証拠を独立して評価した
- Cloudflareの調査で見落とされた活動は見つからなかった
- 最後の脅威活動の証拠は2023年11月24日10:44 UTCと結論づけられた
- Cloudflareは業界および政府の同業者との協力に基づき、今回の攻撃はCloudflareグローバルネットワークへの持続的かつ広範なアクセス獲得を狙った国家支援型攻撃者によって行われたと判断している
- Cloudflareは、Okta侵害の影響を受けた可能性のある他組織がログを確認できるよう、侵害指標を公開した
193.142.58[.]126: 主要な脅威アクターインフラ、M247 Europe SRL所有198.244.174[.]214: Sliver C2サーバー、OVH SAS所有idowall[.]com: Sliverペイロード配布インフラjvm-agent: Sliverペイロードのファイル名、SHA256 bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1件のコメント
Hacker Newsのコメント
Cloudflareのこのような公開分析と対応があるからこそ、自分のデータやビジネスを任せられると思う。
完璧ではないし同意できないこともあるが、会社全体に共有されたエンジニアリングマインドセットと、この種の出来事を深刻に受け止める姿勢のおかげで信頼に値すると感じる
競合他社よりも高い完全性を備えていると強調し、最近のセキュリティ事故の後でいくつかの運用調査を共有するやり方だ。
しかしCloudflareはPCI/DSSの決済カード処理事業者としてのSOCリスク分析を提供しておらず、なぜ権限が昇格したアカウントを見逃したのか、またそのアカウントがそもそもどう侵害されたのかも説明していない。責任より remediation だけを説明している。
第三者監査に触れているが、それはユーザーのためではなく、PCI/DSSが決済カード情報が侵害された組織に毎年の現地監査を要求するからだ。そうでなければ主要カード会社は決済処理を停止していただろう
何も失っていないという話は信じがたいし、私が見てきた大半のJira/Confluenceには機密情報が山ほど入っていた
「アクセスしたWikiページ、バグデータベースのIssue、ソースコードリポジトリを分析したところ、グローバルネットワークのアーキテクチャ、セキュリティ、管理に関する情報を探していたようだ」という一節を見ると、国家主体にとって最も簡単な方法は、忠実な市民を標的企業の従業員として送り込み、その人物に当該情報を渡させることだ。
面白い話ではあるが真偽は不明で、10年以上前にGoogleのSREの社交的な集まりで、数人が自国の情報機関から給料をもらっていると認めたことがあったという
そうでないなら、そんな集まりでどれほど強いドラッグが回っていたら、あんなひどい作戦保安上の失敗が起きるのか気になる
オーストラリア人は、市民権の基本条件であるかのように、その種のスパイ活動に参加する「機会」を与えられる https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
良い点があるとすれば、ゼロトラスト手順やシステム開発における良い実践を強制する助けにはなりうることだ
「私たちは二度目のOktaシステム侵害の被害者になった」という部分を見ると、CloudflareがOkta利用を再検討しているのか気になる
Oktaも批判されるべきだが、これはCloudflareが自分たちのミスを覆い隠すために責任を下に流しているように感じる
私は「初期」に受け取った古いMacBookをそのまま使っていて、管理ソフトウェアがまったく入っていない。当時はIT部門がなく、ただ手つかずの新品ノートPCを受け取っただけだった。
会社はM1/M2 Proへのアップグレードを申し出てくれたが、業務用コンピュータに個人のパスワードや鍵が一つでもあるなら、Oktaのログインシステムは使いたくないとして断った。
そのため、業務に大きな支障が出るまではアップグレードできない。この手の事故は、IT部門に対して自分の考えを正当化する材料として使えるかもしれない
「あるサービストークン1つとアカウント3つは未使用だと誤って信じていたため、ローテーションしなかった」という話は妙だ。未使用なら、なぜ完全に廃止しなかったのかわからない。
何かが抜けているか、伝言ゲームの中で落ちた内容があるのだろうが、文面どおりにはあまり理解できない
たとえばデータベースのどこかで、そのサービスアカウントが「廃止済み」や「整理済み」といった無効状態として表示されていたが、その表示が誤っていたという状況かもしれない。だから有効なアカウントのパスワードはすべてローテーションしたが、無効なアカウントは飛ばしたのだろう。
私がよく知る公開鍵基盤と証明書失効の文脈だけを見ても、証明書を期限切れのままにすること、「もう使っていない」と表示すること、完全に失効させることはかなり違う。認証局は最初のケースでは何もしなくてよく、二つ目では何もしないか失効させることができ、三つ目では失効リストを積極的に維持・配布しなければならない。誰かが「秘密鍵を誤って上書きしたので、新しい鍵用の証明書を発行してほしい」と言ってきても、普通は以前の証明書を失効リストには載せない
「これはAWS、Moveworks、Smartsheetのエラーではまったくなく、私たちがローテーションし損ねた認証情報にすぎない」と明確に書いたのは、良い指摘だ
Cloudflareは、攻撃者のアクセスは限定的だったと考え、その後確認もしていたにもかかわらず、本番環境の認証情報5,000件以上をすべてローテーションし、テスト・ステージング環境を物理的に分離し、4,893台のシステムをフォレンジック調査し、世界中のネットワーク上の全マシンを再イメージ化・再起動した
まだ本番投入前だったSão Pauloデータセンターのコンソールサーバーへのアクセス試行も失敗に終わったが、ブラジルのデータセンター機器をメーカーに送り返してフォレンジックを受けさせ、何も見つからなかったにもかかわらずハードウェアを交換した
ここまでしなくても済んだし、実際そうしない方が簡単だったはずなのに、実際にやった点は評価に値する
新しいデータセンター構築の初期段階に侵入するのは、ほとんど究極のエクスプロイトだ。新しいMeet-Me room(https://en.wikipedia.org/wiki/Meet-me_room)のど真ん中に入り込み、基幹スイッチへの持続的アクセス権を得る状況を想像すればいい
Cloudflareのデータセンターは、膨大なデータトラフィックのハブであることが多い。攻撃者が「本番前」のデータセンターの価値を理解していたという事実は、正式なセキュリティ体制が整う前にそこへ足場を築かれたら100%ゲームオーバーだとCloudflare側も認識していたことを意味するのだろう。構築・立ち上げ中のデータセンター内に誰かが居座ることに成功したら、会社が終わりかねない事案だ
データセンター構築初期には、すべてのスイッチや機器がデフォルト設定または空のrootパスワード(
admin/admin)を使い、ファームウェアも古く脆弱性が多いことも覚えておくべきだ。自動化で全ファームウェアにパッチが当たる前にこうした攻撃が起きたなら、「全機器を返品してメーカーに新品を送らせよう」というレベルの事案だ証明できる範囲のアクセスしか攻撃者に許されていないと仮定すると、攻撃者が生き残る抜け道を残すことになる。これをしなくてよいと言うなら、複数人による定足数の承認が必要であるべきだ
もちろん理想論ではある。うちのチームが、直接的な金銭的・ユーザー的利益のない機能を実装する時間を与えられているだけでも幸運だと思う
この種の認証情報ローテーションを実行できるよう備えるには規律と準備が必要で、正直なところ大半のチームはそこに投資していない。頭が良くてリソースも豊富なチームでさえそうだ
Cloudflareのセキュリティチームが、すべてのシークレットをローテーションし、すべてのマシンを再イメージ化しようと決め、その判断が妥当な時間内に実際に実行されたのだとしたら、かなり印象的だ
† https://twitter.com/badthingsdaily?lang=en
ここで一番驚くべき点は、CloudflareがBitbucketを使っていることだ
データ流出はひとたび外に出たら、この件ではソースコードが永久に外部にあるのと同じで、誰が持っていくのかまったく制御できない
事故後の強化はいくらでもできるし、それをどれだけ語っても、止めたかった事態はもう起きてしまっている。割ってしまった卵は元には戻せない
古いコードからは別のイースターエッグも見つかるかもしれない。ほぼすべての会社には文書化されていないバックドアがある
顧客データ流出の方がより悪いのは確かだが、これも本当に良くない
来年の顧客データも今年の顧客データと同じではない
AtlassianのConfluenceでは、内蔵のApache Lucene検索エンジンだけでも機密情報が漏れる可能性があり、この種のアクセスは追跡・特定が非常に難しいことがある
機密情報が検索結果ページにすでに表示されるなら、攻撃者はConfluenceのページを開く必要すらない
「サービストークン1つとアカウント3つは使われていないと誤認してローテーションしなかった」というくだりは奇妙だ。使われていない認証情報は、ローテーションではなく削除すべき可能性が高い
「このアカウントは何？」「ああ、使ってないよ。ログにも出てこない」「それでもローテーションすべきだろ」「いや、侵害されていたかもしれない古い認証情報を持つ適当なアカウントをそのまま残しておこう……理由はまあ何となくある」みたいな状況か？
Oktaの事故の後に流出した認証情報をローテーションしたのなら、その上にハニーポットを仕掛けて、攻撃者が何をするのか待つべきだったと思う
ハニーポットには、見破られることを恐れて攻撃者がそれ以上先へ進めなくなる効果もある