Oracle Cloudから600万件のデータ漏えい Oracleは否定、研究者は事実だと指摘
サイバー攻撃によってOracle Cloudから約600万件のデータが漏えいしたという主張をOracleは否定した。実際に漏えいがあったのだろうか。セキュリティ研究者の主張を紹介する。
「Oracle Cloud」がサイバー攻撃を受け、約600万件のデータが漏えいしたというニュースは本当なのだろうか。
米国のセキュリティ研究者がその真偽を裏付ける情報を発表した。
Oracleは否定、研究者は事実だと指摘
サイバー脅威インテリジェンスなどを提供するCloudSEKは2025年3月21日(現地時間、以下同)、Oracle Cloudがサイバー攻撃を受けた結果、14万以上のテナントにまたがる600万件以上のレコードが流出したという内容の報告書を公開した。
報告書によれば過去の攻撃履歴がない未知の攻撃者が、盗み出した600万件以上のレコードを販売するオファーをダークWebに投稿したという(注1)。
Oracleは同日、コンピュータ情報サイト「Bleeping Computer」に「侵害はなかった」と否定する声明を発表した(注2)。だが、CloudSEKの研究者は2025年3月24日、侵害の主張を裏付ける新たな証拠を掲載した報告書を追加公開した。
誰が何を盗んだのか
CloudSEKの研究者によると、攻撃者は「rose87168」と名乗っている。rose87168はダークWebのフォーラム「BrechForums」でOracle Cloudのログインサーバに侵入し、シングルサインオン(SSO)認証情報やLDAP認証情報、OAuth2キー、顧客のテナント情報などの機密データを売り出した。
どのような危険性があるのか
CloudSEKは今後どのような影響があるのかをまとめた。それによれば、4つのリスクがある。
(1)大量のデータ暴露 認証関連の機密データを含む600万件の記録が危険にさらされており、今後の不正アクセスや産業スパイのリスクが高まる。
(2)認証情報の漏えい 暗号化されたSSOのパスワードとLDAPパスワードを利用すると、Oracle Cloud環境全体でさらなる侵害が可能になる可能性がある。
(3)身代金の要求 攻撃者は影響を受けたユーザー企業にデータ削除のための支払いを強要しており、金銭的リスクとユーザー企業の評判リスクが高まる。
(4)サプライチェーンのリスク Javaプラットフォームで使用されるJava Keystore(JKS)とキーファイルを利用して、攻撃者が相互に接続された複数の企業のシステムを利用して他の企業のシステムを危険にさらす可能性がある。(キーマンズネット編集部)
事件はどのように推移したのか
CloudSEKの研究者によれば、事件の発端は2025年1月にさかのぼるという。未知の攻撃者はSSOのパスワードの解読を手助けする協力者に対して報酬を提供し、被害者にデータ削除の「手数料」を支払わせようとしていたという。
攻撃者が狙っていたのは「login.us2.oraclecloud.com」だった。このアドレスはCloudSEKの研究者が2025年3月21日に侵害を発見した時点の約30日前まで稼働していた本番環境のSSOサーバだ。CloudSEKによれば、このサーバは「Oracle fusion middleware 11g」をホストしていたと考えられるという。
「攻撃者はOAuth2認証プロセスにおけるゼロデイ脆弱性または設定ミスを利用したと推測できる」(CloudSEKの広報担当者)
CloudSEKによれば、Oracle Access Manager(OpenSSO Agent)の脆弱性「CVE-2021-35587」を利用した可能性が考えられるという。
Oracleの広報担当者は2025年3月25日時点でコメントを控えていた。
IANS Researchのジェイク・ウィリアムズ氏(研究員兼Hunter Strategyの研究開発担当副社長)は、Oracleが否定しているにもかかわらず、同社の環境が侵害されたことに「ほとんど疑いはない」と述べた。IANS Researchは最高情報セキュリティ責任者(CISO)やチームに対して、実践的で経験に基づいたセキュリティインサイトを提供することを目的とした組織だ。
「攻撃者が『実際に使用されていたログインサーバのWebルートにデータをアップロードできた』という直接的な証拠があるため、一部で指摘されているような『レガシーエンドポイント』だけが原因であるはずがない」(ウィリアムズ氏)
Oracle Cloudのユーザーはどうすればよいのか
CloudSEKは有用なツールを発表した。攻撃者が公開した被害者リストにユーザー企業が掲載されているかどうかが分かるWebページ(CloudSEK Nexus and cyber HUMINT)だ。
即座に実行しなければならない対策
このWebページに掲載されていなかったとしても即座に対策を取る必要がある。まずはパスワードのリセットだ。特にテナント管理者などの特権アカウントに重点を置く。侵害された全てのLDAPユーザーアカウントのパスワードを直ちにリセットしなければならない。その際、強力なパスワードポリシーに従わなければならず、多要素認証(MFA)も追加する。次にSimple Authentication and Security Layer(SASL)フレームワークのハッシュ(SASL/MD5ハッシュ)を再生成するか、より安全な認証方式に移行しなければならない。
テナントを保護する
次はテナントレベルのクレデンシャルのローテーションが必要だ。直ちにOracleのサポート窓口に連絡して、テナント固有の識別子(orclmttenantguid、orclmttenantunameなど)をローテーションする。修復手順の検討も必要だ。
証明書を置き換える
証明書とシークレットの再生成も必要だ。侵害された LDAP構成に関連するSSO/SAML/OIDCシークレットまたは証明書を再生成して置き換える必要がある。
監査と監視
最後はログの調査だ。疑わしい認証試行がないかどうか、LDAPログを確認する。不正アクセスの可能性を検出するために、最近のアカウント活動を調査する必要がある。その後、不正アクセスや異常な行動を追跡するための継続的な監視を実施する。犯罪者はすぐにはあきらめないからだ。(キーマンズネット編集部)
出典:Researchers back claim of Oracle Cloud breach despite company’s denials(Cybersecurity Dive)
注1:The Biggest Supply Chain Hack Of 2025: 6M Records Exfiltrated from Oracle Cloud affecting over 140k Tenants(CloudSEK)
注2:Part 2: Validating the Breach Oracle Cloud Denied - CloudSEK’s Follow-Up Analysis(CloudSEK)
注3:Oracle denies breach after hacker claims theft of 6 million data records(Bleeping Computer)
© Industry Dive. All rights reserved.
関連記事
たったそれだけ? クラウドセキュリティのお寒い実態
広く普及したクラウドサービスには弱点がある。セキュリティ対策だ。サービス事業者に任せきりにできる部分はあるものの、ユーザー側の防御が不可欠だ。調査の結果、最低限の対策ができていない企業が残っていることが分かった。頻発するクラウドインシデントを防ぐ「だろう」運用と対策
クラウドでインシデントが起きると情シス担当者の評価に大きく影響します。今回はこうしたクラウドのインシデントを整理し、どのような対策ができるかについてお話しします。Snowflakeユーザーを狙った大規模サイバー攻撃 被害者の共通点とは
Snowflakeを利用していた企業のうち、少なくとも100社がサイバー攻撃を受けた。原因はSnowflakeなのか、それともそれ以外の原因があるのだろうか。