Advanced Threat Prevention
Prisma Cloud
Unit 42 Incident Response
This post is also available in: English (英語)
概要
SugarCRM におけるゼロデイの認証バイパス/リモート コード実行の脆弱性 (CVE-2023-22952) は一見ありがちなエクスプロイトのようで、実は防御側が注意すべき点が多いものです。SugarCRM は Web アプリケーションなので、正しく構成・保護されていなければ、舞台裏にあるインフラが脅威アクターによる影響の拡大をゆるしかねません。脅威アクターが CSP (クラウド サービス プロバイダー) の使っている基盤技術を把握しており、適切な権限を持つクレデンシャルにアクセスできるなら、そこから大きな成果をあげられるのです。
ここ 1 年で Unit 42 は SugarCRM の脆弱性 CVE-2023-22952 が初期攻撃ベクトルとなった複数の事例に対応してきました。これらの事例では、この脆弱性が原因となって、脅威アクターが AWS アカウントにアクセスに成功していました。原因は AWS の脆弱性ではなく、どのクラウド環境でも発生する可能性があります。脅威アクターは最初の侵害の後、設定ミスを利用してアクセスを拡大していました。
本稿は AWS 環境に対するさまざまな攻撃を MITRE ATT&CK Matrix フレームワークに従って示し、組織が自らの保護に導入できる複数の防御メカニズムをまとめます。これらの保護には、AWS が提供する制御とサービスの活用、クラウドのベストプラクティス、攻撃の全容把握のための十分なデータ保持体制の確認などが含まれます。
これらの攻撃の複雑さは、ロギングやモニタリングの設定により、不正な AWS の API コールを検出することの重要性を物語っています。たとえ無害に見えるコールでもです。足場を築くことができれば、さらに恐ろしい攻撃アクティビティにつながる可能性がありますし、そうしたアクティビティは必ずしも追跡可能とはかぎりません。クラウド セキュリティにどんな攻撃にも効く万能薬は存在しませんが、これらの攻撃は、いざというとき自身を確実に保護するために注力すべき重要エリアがどこにあるかを教えてくれます。
パロアルトネットワークスのお客様は、以下の方法で、以下で説明する攻撃に対する保護と緩和を受けています。
- 同脅威を含むさまざまな脅威に対し個別の支援を必要とされる場合は Unit 42 のインシデントレスポンスチームをご用命いただけます。
- Prisma Cloud は、本稿で報告したユースケースに対し、アラートと緩和ソリューションを提供可能です。
- Advanced Threat Prevention セキュリティ サブスクリプションを有効にした次世代ファイアウォール製品は、攻撃防止に役立ちます。
| 関連するUnit 42のトピック | AWS, Cloud |
MITRE ATT&CK Matrix
本稿ではこれらのインシデントを、サイバーセキュリティ攻撃のさまざまな要素を説明してくれる 14 種類の戦術からなる MITRE ATT&CK Matrix に当てはめ、ウォークスルー形式で紹介していきます。私たちが対応したさまざまな事例では、この脅威アクターのアクティビティを説明するのに 14 ある戦術のうち 9 つを使います。その 9 つとは、initial access (初期アクセス)、credential access (クレデンシャルへのアクセス)、discovery (探索)、lateral movement (ラテラル ムーブ)、 execution (実行)、exfiltration (漏出)、privilege escalation (特権昇格)、persistence (永続化)、 defense evasion (防御回避) です。
事例のウォークスルー
初期アクセス (Initial Access) - CVE-2023-22952
これらの AWS アカウント侵害の初期攻撃ベクトルは SugarCRM のゼロデイ脆弱性 CVE-2023-22952 でした。SugarCRM はチーム間のコラボレーションに重点を置いた顧客関係管理 (CRM) プラットフォームです。幅広い機能をもつ同社製品はさまざまな業種のユーザーに利用されています。
CVE-2023-22952 は 2023 年 1 月 11 日に NIST (アメリカ国立標準技術研究所 ) の NVD (脆弱性情報データベース) に公開された脆弱性で、基本スコアは 8.8 でした。入力検証不備に起因するこの脆弱性を悪用した脅威アクターは、SugarCRM の電子メール テンプレート モジュール経由でカスタム PHP コードを挿入できるようになります。
脅威アクターがこれらの攻撃で SugarCRM を標的にした理由は、SugarCRM の顧客データベース内のメール アドレスや連絡先情報、アカウント情報など幅広い機微データの存在を思えば理解しやすいでしょう。侵害に成功した脅威アクターはこれらの機微情報を直接販売してもよいし、被害者からさらに多額の金銭を脅し取ってもよいわけです。
SugarCRM のこの脆弱性が悪用された場合、脅威アクターはこのアプリケーションを実行している基盤サーバーに直接アクセスできるようになります。この脆弱性はリモート実行という要素を含んでいるからです。私たちが対応した事例の場合、これらのサーバーは Amazon Elastic Cloud Compute (EC2) インスタンスでした。ホスト上には期間の長い AWS のアクセス キーが保存されていて、脅威アクターはそれらのキーでアクセスの拡大に成功していました。これらの組織は自社のインフラをクラウド上にホストしていたことから、脅威アクターらがオンプレミスでのホスティングとはまた違った攻撃ベクトルを利用できる状態になっていました。
クレデンシャルへのアクセス (Credential Access)
EC2 インスタンスへのアクセスを取得した脅威アクターは、そのホスト上に存在する長期 AWS アクセス キーの侵害に成功していました。ホストの場所がオンプレミスかクラウドかに関係なく、AWS コマンドライン インターフェイス (CLI) を使うのであれば、認証に使う一時ないし永続的クレデンシャルは、そのホスト上のクレデンシャルファイルに保存しておくことができます (下図 1 参照。これにはファイル パスが含まれる)。
私たちが観測した事例では、これら平文のクレデンシャルが侵害ホスト上に存在していたため、脅威アクターがこのクレデンシャルを盗み、アクセス キーを使っての探索アクティビティを開始できていました。
探索 (Discovery)
この脅威アクターはまず GetCallerIdentity コマンドを実行してからスキャン アクティビティを実行していました。GetCallerIdentityは、whoami コマンドの AWS 版です。このコマンドは API コールを実行したエンティティに関するさまざまな情報を返します。たとえば、ユーザーID、アカウント、リクエストに署名に使われたクレデンシャルに関連するプリンシパルの Amazon リソースネーム (Amazon Resource Name、ARN) などです (図2)。ユーザー ID はコールを実行したエンティティの一意な識別子です。アカウントはそのクレデンシャルが属する AWS アカウントの一意な 12 桁の識別子です。ARN にはアカウント ID とコールを実行するプリンシパル名が、人間に読めるかたちで含まれています。
侵害したクレデンシャルに関する知識を若干得た脅威アクターはスキャン活動を開始します。彼らは Pacu や Scout Suite などのツールを使い、対象の AWS アカウント内にどんなリソースが存在しているかをさらに詳しく把握しました。Pacu はオープンソースの AWS エクスプロイト フレームワークで、クラウド版の Metasploit に相当する設計になっています。Scout Suite は、クラウド環境のセキュリティ態勢評価に使われるセキュリティ監査ツールです。
私たちが対応した事例のなかには、以前の侵入テストでホスト上に Pacu がすでに存在していたものも確認されました。侵害した EC2 インスタンスへの Scout Suite のダウンロードというのはあまり目にすることがないですが、このツールが使用されていたことは、脅威アクターのアクティビティに関連付けられたユーザー エージェントから確認できました。いずれのツールも、侵害した AWS アカウントの様相を探るための、多くの情報を脅威アクターにもたらします。
これらの事例では、以下にあげたようなさまざまな従来のサービスが両ツールによってスキャンされていました。
これらの脅威アクターは、必ずしも自身に有用な情報をもたらすとは思えないサービスに対しても探索用のコールを実行していました。たとえば、AWS Organizations サービスや AWS Cost and Usage Reports (AWS コストと使用状況レポート) サービスなどです。
AWS Organizations は組織に複数の AWS アカウントやリソースをまとめて集中管理できる場所を提供する管理サービスです。CloudTrail ログから脅威アクターのアクティビティを確認したところ、ある 3 つの Organizations API コールが目を引きました。最初のコールは ListOrganizationalUnitsForParent で、これはすべての Organizational Units (組織単位 OU) をリストするものです。
そこから、脅威アクターらは ListAccounts を実行しました。これにより、これらの各 OU に関連付けられたすべてのアカウント ID が返されます。脅威アクターに最も有益な情報をもたらした最後のコールは、 DescribeOrganization API コールでした。このイベントは、マスター アカウントの ID と、そのアカウントに関連付けられたマスター アカウントの電子メール アドレスを返します。この情報があれば、脅威アクターはそのアカウントの Root ユーザーとしてログインを試行するのに十分な情報を得られます。
私たちの興味を引いた最後の探索コールは、Cost and Usage Reports サービスを使うものでした。この脅威アクターはさまざまな GetCostandUsage コール (図 3) を実行していました。また応答では侵害されたアカウントに関するコストの概要が返されていました (図 4)。
脅威アクターは、クラウド アカウントのコストを把握することで、そのアカウントがどの程度アクティブなのかを判断できます。この点を防御側は認識しておく必要があります。アカウントの総コストが大きければ、新しいリソースをスピンアップしてもそのコストは目立たず、容易に検出を回避できるかもしれません。
ところが、アカウントの支出額が非常に小さければ、新しいリソースを少しスピンアップしただけで目立ってしまう可能性があります。支出の少ないアカウントの所有者はコスト関連の通知を厳しくしているかもしれないし、そこで脅威アクターが新しくリソースを作成すれば、アラートがトリガーされてしまうかもしれません。
Organizations の API コール、Cost and Usage の API コールはいずれも、クラウドにおける攻撃対象領域がどう違っているかがわかるよい例です。脅威アクターは一見とくに問題なさそうな API コールを使うことで、アラートをトリガーしかねない不審なアクティビティを実行せずに、アカウントの構造や使用状況に関する大量の情報を入手していました。
ラテラルムーブ/実行/漏出 (Lateral Movement/Execution/Exfiltration) – RDS
私たちが観測したインシデントで、環境のスキャンを完了した脅威アクターは、アカウント全体の探索からさまざまなサービスへのアクション実行へとアクティビティを絞り込むのに十分な情報を入手していました。このサービスにたいするアクション実行は Relational Database Service (RDS) から始まっていました。この脅威アクターは侵害した SugarCRM EC2 インスタンスから RDS サービスへのラテラル ムーブを行い、さまざまな SugarCRM RDS データベースから新しい RDS スナップショットを作成するコマンドの実行を開始しました。これらのスナップショット作成で元になった RDS データベースにダウンタイムは発生していません。
そこから脅威アクターは、インバウンドの SSH 接続がすでに許可されている既存セキュリティ グループのルールを変更し、MySQL トラフィック用にポート 3306 を追加しました。その後は漏出に移り、スナップショットから新しいデータベースを作成・公開し、変更したセキュリティ グループをアタッチしました。最後にマスター ユーザーのパスワードを変更して新しく作成した RDS データベースを変更しました。これでデータベースへのログインが可能になります。
仮想プライベート クラウドの(VPC) フロー ログを有効している場合は、データ漏出の有無の把握にこれらのログを使って環境から漏出したデータのバイト数を確認できます。VPC フロー ログが有効になっていない事例ではこのデータ漏出調査の結果には限界がありました。
ラテラルムーブ/実行 (Lateral Movement/Execution) – EC2
RDS のアクティビティの後、脅威アクターは再び EC2 サービスへのラテラル ムーブを行い、いくつか変更を加えていました。脅威アクターが最初に行ったのは、実行中の SugarCRM EC2 インスタンスから新しい Amazon マシンイメージ (AMIs) を作成することでした。そこから彼らは ImportKeyPair コマンドを実行し、サードパーティ ツールで作成した自分たちの公開鍵のペアをインポートしていました。これらのタスクが完了すると、脅威アクターは新しい EC2 インスタンスの作成を開始しました。また彼らは任意の IP アドレスから 22/tcp へのインバウンド アクセスを許可する既存セキュリティ グループを EC2 インスタンスにアタッチしていました (図 5)。
彼らは、被害組織がほかの通常のインフラを作っているリージョンと同じリージョンに EC2 インスタンスを作成していました。また彼らはリージョンを地理的に新しいエリアに切り替えて、任意の IP アドレスから 22/tcp で SSH へのトラフィックを許可する新しいセキュリティ グループを作成していました。次にアクターは別のキー ペアをインポートしました。別のリージョンへの切り替えを行ったので、ほかのリージョンで使用しているものと同じキー ペアであっても再インポートする必要があります。
セットアップ完了後、新しい EC2 インスタンスを作成しましたが、今回は AWS Marketplace で入手可能なパブリック AMI を使用していました。この EC2 インスタンスのアクティビティは、AWS アカウント内で起こっていることをすべて可視化する GuardDuty などのセキュリティ サービスをすべてのリージョンで有効にすることの重要性を示しているといえます。事前対策として、組織は使っていないリージョンを無効化することもできます。
特権昇格 (Privilege Escalation) – Root
本攻撃では特権昇格の段階でほかの事例で見られるような新たな IAM ユーザーの作成が試みられていませんでした。かわりに Root ユーザーとしてのログイン試行が選ばれていました。探索段階で実行した Organizations コールから取得した情報を使っていましたが、アクターは依然、Root ユーザーとしてうまくログインすることができませんでした。Root のログインの試行はかなりノイズが多くなるので、これらの失敗した Root ログインは CloudTrail ログ内で目立っていました (図 6)。
永続性 (Persistence) – リージョン
この脅威アクターは、Root アカウントでのログイン試行以外に永続化試行はあまりおこなっていませんでした。永続化への最も明確な試みは、組織がインフラをホストするために通常使用するリージョンとは異なるリージョンに EC2 インスタンスを作成することでした。Root ログイン試行と同様に、これらの新しい EC2 インスタンスは CloudTrail ログで目を引きました。ただしクラウド環境が大規模になってくれば、リージョンを切り替えて作られたリソースをぜんぶ追跡するのはそこそこ大変になるし、コンソールでリソースを確認するさいの見落としも起こりがちになります。
防衛回避 (Defense Evasion)
脅威アクターが AWS アカウントを侵害した後、アカウント所有者が問題を発見するまでの時間は限られています。そこで彼らは、気づかれにくいようにいつもとは違う地域にリソースをデプロイしていました。当該環境に滞在中、彼らは EC2 インスタンスのオンとオフも繰り返していました。
脅威アクターがオン・オフを繰り返す理由はいくつかあって、理由の 1 つが可視性を下げることです。AWS コンソールの EC2 インスタンス ページは、デフォルト設定の場合、running (実行中) の EC2 インスタンスのみが表示されます。ユーザーがあえて実行されていない EC2 インスタンスも確認しようとしないかぎり、脅威アクターが作成した新しい EC2 インスタンスが停止状態になっていれば一見しただけでは見落とされてしまいます。
もう 1 つの理由はこれらのリソースを停止して組織のアカウントに余分なコストが発生するのを抑えることです。組織がコスト関連の通知を厳格に行っている場合、脅威アクターが作成したリソースを停止すればコストを最小限に抑えられ、コスト関連のアラートのトリガーも抑止できます。これもまた防御回避の 1 つの手段です。
別リージョンでのリソース作成と作成したリソースの停止以外に、この脅威アクターはほかの防御回避手法、たとえば CloudTrail ログの停止や GuardDuty の無効化などを試みていませんでした。
緩和 (Remediation)
アクセス キー (Access Keys)
組織が将来この手の攻撃から身を守るために実行できる主な緩和策は 4 つあります。最初の対策はアクセスキーをめぐるものです。アクセス キーはよく AWS 侵害の根本要因になります。したがってアクセス キーの保護は組織にとっての重要事項です。
EC2 インスタンスに長期間のアクセス キーを使用する正当な理由は存在しません。そのかわり、EC2 Roles と Instance Metadata Service (IMDS) に存在する一時クレデンシャルを使用しましょう。また、IMDSv2 のみを使用するようにしてください。サーバー サイド リクエスト フォージェリ (SSRF) 攻撃から保護されます。
ホスト上のクレデンシャル ファイルに保存されている長期アクセス キーのクリーンアップ プロセスの作成をお勧めします。これは、作業完了時にこれらのファイルをクリーンアップするようユーザーに依頼するか、これらのファイルを自動的にクリーンアップする組織レベルのプロセスを作成することで実現できます。
また、アクセス キーの定期的なローテーション・削除もお勧めします。アクセス キーの有効期間が長くなるほど、侵害の可能性は上がります。キーを継続的にローテーションし、使っていないキーは削除して、AWS アカウントを積極的に保護しましょう。このプロセスは全体を自動化できますし、アクセス キーのセキュリティ維持に役立ちます。
最小特権の IAM ポリシー (Least-Privileged IAM Policies)
同アクターによる一連の攻撃が成功した理由はただ 1 つ、「組織が SugarCRM ホスト上の IAM User プリンシパルに付与した権限のスコープが緩すぎた」ことに尽きます。ホスト上に存在するこれらの IAM ユーザーには、たしかに AWS の権限がいくつか必要でしたが、それらの権限はアプリケーションに必要な最低限のものだけをピンポイントで含め、スコープを絞っておくべきでした。しかも私たちの調査では、こうした状況に陥っているのが今回の被害組織だけではないことがわかっています。『Unit 42クラウド脅威レポートVol.6』によれば、クラウド ユーザー、ロール、サービス、リソースの 99% に使用されていない過剰な権限が付与されていました。
AWS Access Analyzer を使用すれば、特定 IAM プリンシパルによる API 使用履歴を調べ、対象期間に使われた API のみにアクセスを制限するアクセス ポリシーを自動生成できます。
たしかに権限の緩いポリシーを作成しておけば楽ですが、スコープを絞って権限を作成し、AWS アカウントを適切に保護しておくことにはそれだけの見返りがあります。
Root のモニタリング (Monitoring Root)
組織に推奨するもう 1 つの緩和策は、Root アカウントまわりの監視の設定です。環境内では、Root アカウントが必要とされるアカウント管理タスク実行にのみ、Root アカウントを使ってください。またその環境では、Root アカウントに対してフィデリティの高いアラートを維持することで、この最も価値の高いアカウントの保護に役立ててください。また、Root には多要素認証 (MFA) を常に有効にし、長いパスワードで保護されているか確認することをお勧めします。
ロギングとモニタリング (Logging and Monitoring)
組織の皆さんに推奨する最後の緩和策はロギング設定が正しいか確認することです。全リージョンで CloudTrail と GuardDuty の両方を有効化し、ログは一元管理できる場所に送信すべきです。
GuardDuty では、アラートの重大度に基づき、対応チームにアラートを送る必要があります。GuardDuty を有効にしていた組織での事例は、この GuardDuty が攻撃のかなり早い段階でこれらアクセス キーの侵害を捕捉していたことがわかっています。これはアカウントを保護する簡単な方法です。
また組織の皆さんには発生しうるデータ漏出の捕捉のために VPC フロー ログを有効にしておくことをお勧めします。これらのログは、ネットワーク接続の問題のトラブルシューティングを行うときに非常に役立ちます。これらのサービスのデータ保存期間は、適切な長さにしておくことが重要です。侵害は環境を問わず発生します。攻撃の全体像を掴めるよう、十分な期間のログを保持しておくことが重要です。
結論
脅威アクターはこの一連の攻撃でかなりの成功をおさめました。ただし組織側にも、導入すれば保護に役立つ優れた緩和策が複数あることがわかりました。アクセス キーは最も一般的な初期攻撃ベクトルです。可能なかぎり、長期のアクセス キー使用は避けてください。AWS の場合それは EC2 ロールや IAM Role Anywhere、開発者ワークステーション用の Identity Center インテグレーションの利用を意味します。これらのキーを保護するためのもう 1 段の保護レイヤーは、異常な使用に関する監視を設定することです。一連の攻撃でこの脅威アクターは異常な API コールを行っていますが、これらはすべて、じゅうぶんに長い期間取得しておいたログを分析すれば検出可能です。
また、クラウド内外で実行されるコードには、ジョブの実行に最低限必要とする権限だけを持たせるよう、基本的な最小特権分析を行うことも不可欠です。
アクセス キーの監視に加え、クラウド アカウントの異常なアクティビティを常に監視する必要があります。AWS の場合それは CloudTrail や VPC フロー ログ、S3 サーバー アクセス ログなどで、さまざまなサービスを監視することを意味します。監視の構成を見直してください。クラウド アカウント内のサービスが、平時と異なる新しい IP アドレスや、平時と異なるポートを介し、内外へののアクセスを発生させていた場合に、それらのアクティビティについて警告を発するようにしてあるでしょうか。また S3 バケットに機微データを保存している組織であれば、S3 サーバーのアクセス ログを監視し、バケットへの異常なコールを記録しておくと、攻撃のプロアクティブな発見につながります。
そして最後に強調しておきたいのが、権限絞り込みの重要性です。これがされていなかったがために、同アクターは今回の事例で行った一連の攻撃に成功していました。IAM User に属する侵害されたアクセス キーの権限が絞り込まれていれば、このアクターは攻撃過程で阻止できていたはずです。
製品による保護
パロアルトネットワークスのお客様には、弊社製品/サービスの保護・更新を通じて同脅威の特定・防御が提供されています。
侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、こちらのフォームからご連絡いただくか、infojapan@paloaltonetworks.comまでメールにてご連絡いただくか、下記の電話番号までお問い合わせください(ご相談は弊社製品のお客様には限定されません)。
- 北米フリーダイヤル: 866.486.4842 (866.4.UNIT42)
- 欧州: +31.20.299.3130
- アジア太平洋: +65.6983.8730
- 日本: +81.50.1790.0200
Prisma Cloud
Prisma Cloudは、本稿で報告したユースケースに対し、以下の方法でアラートと緩和ソリューションを提供可能です。
- Prisma Cloud の Anomaly Policies をデプロイすると、使用されていない AWS リージョンで実行されているインスタンスを検出したり、AI/ML アルゴリズム機能を通じ、不審な IAM クレデンシャルの使用を検出したりできます。
- このほか Prisma Cloud の Attack Path Policies は、本稿で解説した EC2 インスタンスに対するラテラルムーブや特権昇格攻撃を検出できます。
Prisma Cloud は、検出・リスク緩和機能の開発指針に MITRE ATT&CK フレームワークを採用しています。
Advanced Threat Prevention を有効にした次世代ファイアウォールと Prisma Access
Advanced Threat Prevention セキュリティ サブスクリプションを有効にした次世代ファイアウォールは、脅威防御シグネチャ 93591 を通じ、攻撃防止に役立ちます。
Cortex XDR
Cortex XDR for cloudはクラウド ホスト、クラウド トラフィック、監査ログからのアクティビティの内容と、エンドポイントやネットワークのデータとを統合します。この統合によりSOCチームはデジタルドメイン全体を俯瞰したインシデントのストーリーを得ることができます。
IoC
IP アドレス:
- 13[.]90.77.93
- 31[.]132.2.66
User-Agent:
- Boto3/1.26.45 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 Botocore/1.29.45
- Boto3/1.7.61 Python/3.5.0 Windows/ Botocore/1.10.62
- aws-cli/1.19.1 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 botocore/1.29.58
- aws-cli/1.18.69 Python/3.5.2 Linux/4.4.0-1128-aws botocore/1.16.19
- Scout Suite/5.12.0 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 Scout Suite/5.12.0
2023-08-16 10:00 JST 英語版更新日 2023-08-16 13:45 PDT の内容を反映し、Cortex に関連する情報を追記
目次
関連項目 リソース
脅威リサーチ
主なサイバー脅威
脅威アクター グループ
Unit 42 からの最新情報を取得