Snowflakeのデータ流出：ハッカーがインフォスティーラー感染を通じたアクセスを確認
(hudsonrock.com)- 2024年5月31日、クラウド企業Snowflakeが大規模なデータ流出を経験
- ハッカーはインフォスティーラー感染を通じてアクセスしたとHudson Rockに確認
- ハッカーはTicketmasterやサンタンデール銀行を含む複数の主要企業のデータをロシア語のサイバー犯罪フォーラムで販売
ハッキング手法
- ハッカーはSnowflake従業員のServiceNowアカウントに、盗まれた認証情報を使ってログイン。
- OKTAを回避してセッショントークンを生成し、大量のデータを流出させた。
- ハッカーは約400社が影響を受けたと主張。
追加の証拠
- ハッカーはSnowflakeサーバーへのアクセス権を示すCSVファイルをHudson Rockの研究者に共有。
- このファイルには、Snowflakeの欧州サーバーに関連する2,000件以上の顧客インスタンスが記録されている。
ハッカーの目的
- ハッカーはデータを取り戻したければ2,000万ドルを支払うようSnowflakeに要求。
- 会社はこれに応答していない。
インフォスティーラー感染の増加
- インフォスティーラー感染は2018年以降6,000%増加し、主要な初期攻撃ベクターとして定着。
- これはランサムウェア、データ流出、アカウント乗っ取り、企業スパイ活動などを含むサイバー攻撃の実行に使われている。
GN⁺の見解
- サイバーセキュリティの重要性: 今回の事件は、企業がサイバーセキュリティにより一層注意を払う必要があることを示している。特に従業員の認証情報管理が重要。
- インフォスティーラーの脅威: インフォスティーラーは非常に速いペースで拡散しており、企業はこれに対する備えを講じる必要がある。
- 対応戦略: ハッキング事件が発生した際には、迅速な対応と被害最小化の戦略が必要。Snowflakeの対応の遅れが被害を拡大させた。
- セキュリティ教育: 従業員へのセキュリティ教育を強化し、認証情報管理やフィッシング攻撃への認識を高めることが重要。
- 代替ソリューション: Snowflakeと類似の機能を提供する他のクラウドストレージソリューションを検討することもできる。たとえば、AWS S3やGoogle Cloud Storageなど。
1件のコメント
Hacker Newsのコメント
現在リンクされているURLが
/に 302リダイレクトされる。@dang、下のアーカイブリンクに差し替えたほうがよさそうhttps://web.archive.org/web/20240531140540/https://www.hudso...
ただし、Hudson Rockがブログ記事を取り下げたことも興味深いシグナルなので、単にアーカイブリンクに差し替えて終わりにすべきではない。何が変わったのだろうか？
追記: Snowflakeの公式回答は、元記事の中核的な主張を事実上ほぼすべて否定しているように見える。Hudson Rockが不誠実な情報源にだまされ、ミスに気づいて記事を取り下げた可能性もある
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
SnowflakeのFelipeです。この件に関するSnowflakeの最新の見解はこちらにあります: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
追加情報があれば、このURLを継続的に更新します
しかしSnowflakeの「影響を受けた顧客アカウントと同様に、脅威アクターが元Snowflake従業員所有のデモアカウントの個人認証情報を入手し、アクセスした証拠を見つけた。機微なデータはなかった」という文は、SnowflakeがHudson Rockの説明を虚偽と見ている、という意味に読める。この理解で合っているか？
一方でSnowflakeの記事は、顧客アカウントの認証情報が流出し、それで終わりであり、中央アカウントや他のアカウントへのアクセスはなかった、というふうに見える。2要素認証のない従業員アカウント情報の使用については何も述べていない
Snowflakeが社内従業員のすべてのアクセス認証情報に2要素認証を求めているのは明らかだ。以前は、顧客が望めば自分のデータにログインするために名前/パスワードだけを作成し、2要素認証なしでもアクセスできた
チャットログのスクリーンショットが本当に印象的だ。この会社は実際の犯罪者とやり取りしていると主張し、その犯罪者は、この会社を使っていれば侵害を防ぐ助けになったはずだと言っている
それで、この会社の信頼性についての判断を更新した
Hudson Rockはそれに合わせ、実際より大きな侵害であるかのように話を膨らませたようだ。ハッカーが先にHudson Rockへ行ったのか、それとも受け入れた最初の会社がHudson Rockだったのかも気になる
「Hudson Rockの保護を買っておくべきだった。そうすれば今回の件は防げたはずだ」
「その通り、間違いなく役に立ったはずだ」
「おめでとうございます。貴社は抜き打ちの情報セキュリティ監査に合格し、ランサムウェアの被害者となりました。」
[...]
提供内容: 1) 完全な復号支援 2) データ削除の証拠 3) 発見した脆弱性のセキュリティレポート 4) データを公開または販売しない保証 5) 今後攻撃しない保証
結局のところ、あなたが給与名簿に載せていたとは知らなかったセキュリティコンサルティング会社にすぎない
ちなみにデータ削除の証拠として何を出すのか見たところ、文字どおり
rm -vrf dataの標準出力だけだった。不在の証明を提供することは不可能で、被害者に交渉力がないのは理解しているが、この演出はかなり気に入っているたとえ本物だとしても、Hudson Rockのメッセージは省くのが常識だったはずだ。この会社は頭の中のブラックリストに入れた
攻撃者の言い分だけを見ると、Snowflakeは単一の管理者アカウント1つにすべての全権限を与えるような形でシステムを設計していたように見える。
Snowflakeが5月31日の発表で「一部の顧客に影響を与えた、業界全体にわたるアイデンティティベースの攻撃」を調査中だと述べたことも、TicketmasterとSantanderの話に信ぴょう性を加えている。
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
脅威アクターが適切に動いていたなら、史上最大級のデータ漏えいの1つになっていた可能性もある。
データは、顧客や見込み客向けのデモを作る際に使っていた、その人物のSnowflakeアカウントから出たように見える。顧客が実データの一部をデモに使うようアクセス権を与えていた可能性はあるが、顧客のSnowflakeデータベース自体に無制限にアクセスできたという話とはかなり違う。
ハッカーが、デモ用の偽物だがそれらしいデータを抜き出し、その違いに気づいていない可能性も十分ある。
1人のセールスエンジニアは複数のアカウントを担当する。Snowflakeのセールスエンジニアは通常、顧客環境の中では構築せず、誰でも作れる400ドル分のクレジット付きデモアカウントをセットアップする。デモアカウントは時間が経つと期限切れになるため、継続的に新しく作る。
セールスエンジニアは作成したデモアカウント内で構築し、顧客に見せる。30日後、Snowflakeはクレジットカードがなければアカウントをロックし、その後デモインスタンスとデータを削除する。
作業のために、顧客は自社のSnowflakeインスタンスから、セールスエンジニアが作ったデモインスタンスへデータを共有することもできるし、SSO経由でそのSnowflakeのセールスエンジニアにアクセス権を与えることもできる。
いずれにせよ、組織側がセキュリティ態勢を十分に制限的に運用していなかった問題に近い。熱心に働いていたセールスエンジニアと、従業員・契約者・ゲストの権限範囲を適切に制限していなかった顧客を見つけたという点以外、新しいところはない攻撃だ。
興味深いことに、最初のページには東欧のNGOを対象にPegasusが使われたという隣接する話もある。最小権限の原則も重要だが、デバイスのセキュリティも重要だ。
https://news.ycombinator.com/item?id=40535912
Snowflake社員ではないが、Snowflakeとそのセールスエンジニア組織とは多くの時間を一緒に仕事してきた。
顧客とデモを作る際、セールスエンジニアは誰でも作れる400ドル分のSnowflakeデモアカウントでデモ環境を作る。デモを作るには、顧客がそのセールスエンジニアにアクセス権を与え、セールスエンジニアは一部のデータをデモ環境に持ち込んで作業する。Hudson Rockが公開した環境名もこれを裏付けている。
私の見方では、データを共有していた人のIDを顧客が失効させておらず、脅威アクターが認証情報を盗んだというプロセス上の問題だ。脆弱性攻撃ではないので、新しいものではない。
それからHudson Rock、コンピューターにマルウェアがあって被害を受けた人を公然とさらしたこと、おめでとう。契約者に認証情報を渡して、それが盗まれた場合と何も変わらない。かなり悪質な行為だ。
Snowflakeでは、セールスエンジニアの認証情報が盗まれる可能性があり、その認証情報は多要素認証を回避でき、記事によれば有効期限もない。これはストライク1、2、3だ。
Snowflakeのセキュリティ慣行は、顧客が広範なデータセットへのアクセス権をSnowflake社員に共有することを求められる、少なくとも促される状況を作っていた。ストライク4だ。
顧客にも広すぎるアクセス権を付与した責任はあるが、こうしたアクセスが不要になるようなより良いシステムを作らなかった、あるいは少なくともこの推移的なアクセスをより適切に監督・制御できなかった責任はSnowflakeにもある。
このようなアカウントが顧客データへのアクセス権を受け取った瞬間、もはや「デモアカウント」ではない。実アカウントであり、実際に非常に価値の高いデータを持つアカウントなので、そのように扱うべきだ。
追記: Snowflakeは、当該デモアカウントは顧客データにアクセスしておらず、漏えいの出所でもないと主張しており、これは攻撃者の主張と矛盾する。
「世界中の侵害された企業数十万社と、アクティブな脆弱性を持つ見込み客開拓プラットフォームにアクセスし、それらを顧客に変えられると想像してみてください。」
この種の会社を何社か見たことも相手にしたこともあるが、かなり低級な戦術で、技術的にも熟練度や努力の水準は低い。
Snowflakeの公式回答にはこう書かれている
「これは、顧客データの取得を意図した、業界全体で継続中のアイデンティティベースの攻撃の結果だと見ています。調査によれば、これらの攻撃は、無関係なサイバー脅威活動を通じて露出した顧客のユーザー認証情報を使って実行されています。現時点では、この活動がSnowflake製品内の脆弱性、設定ミス、悪意ある活動によって発生したとは見ていません。」
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
記事は非公開にされたようだが、Wayback Machineにはまだ残っている: https://web.archive.org/web/20240531140540/https://www.hudso...
この記事は、数日前のTicketmaster侵害が実際にはSnowflake従業員の盗まれた認証情報を通じて400社以上に影響した、はるかに広範なハッキングだったと主張している
現時点ではhudsonrock.comだけが報じている大きな話に見える。Hudson Rockは初めて聞いたが、信頼できる情報源かどうか知っている人はいる？
複数のアカウントがRedditの運営者や管理者により禁止された。個人的には信頼できる、または信用に足る情報源とは見ていない
https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
Snowflakeは自分たちのせいではなく顧客のせいだと言っているように見える
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
https://www.hudsonrock.com/blog/snowflake-massive-breach-acc...が完全な作り話でないなら、Snowflakeは事実をやや不誠実に語っている
「調査によれば……」という表現は、自社調査なのか一般的なセキュリティ研究なのか曖昧だ。「Snowflake製品内の脆弱性、設定ミス、悪意ある活動が原因とは見ていない」という文言も、あり得るシナリオを列挙して否定しつつ、実際にどう起きたのかは巧妙に省いている
Hudson Rockを信じるなら、Snowflakeは悪意ある行為者から連絡を受けていたので、どのように発生したのかをかなりよく把握していた可能性が高い
「無関係なサイバー脅威活動を通じて露出した顧客のユーザー認証情報で実行」されたと言っているので、作り話でないなら、認証情報は別の場所で入手されたと見ているようだ
最後には顧客にアカウント設定を確認するよう求めているので、責任を自分たちからそらす方向だ。ただし現時点の情報源は、ハッキングされたとされる会社と、この事件を利用して自社製品を宣伝しつつ従業員を厚かましく晒した会社なので、より詳しい情報が出るまで待つべきだろう
ハッカーはリフレッシュトークンすら失効させていなかったと主張しているが、本当なら非常に重大で明白な問題だ
記事は「数百の顧客が侵害」という見出しとあまり整合していないように見える
第一に、lift/oktaのパスワードはServiceNowポータルへのアクセスを許すだけで、顧客アカウントへのアクセスではないようなので、リフレッシュトークンの問題はServiceNowポータルに限定され、実際の顧客Snowflakeアカウントのデータ露出とは関係ないように見える
第二に、10社のアカウントが侵害されたというスクリーンショットには、異なるSnowflakeアカウント認証情報が4つ見えており、そのうち1つは個人のデモアカウントのように見える。したがって最大でも3件程度の顧客侵害は説明できるが、他の顧客侵害を示す詳細はない
セールスエンジニアが担当していた全顧客の全認証情報が侵害されたと仮定しても、侵害された顧客数はおそらく低い2桁だろう。各顧客アカウントがセールスエンジニアに個別にアクセス権を付与している必要があるからだ
内部Oktaポータルのリフレッシュトークン問題を根拠にSnowflakeの顧客全体が侵害されたと言うのは大きな飛躍であり、その問題はどの顧客のSnowflakeアカウントとも結び付いていない