実事例で学ぶクラウドコンピュートのクレデンシャル侵害

  • 2,431
    people reacted
  • 0
  • 2 min. read

By

Category: Cloud

Tags: , , , , , , ,

A pictorial representation of a cloud breach

This post is also available in: English (英語)

概要

多くの場合、クラウドの侵害はストレージサービスの設定ミスやクレデンシャル(認証情報)の漏えいから起こります。とくにクラウドコンピューティングサービスを標的として、関連するクレデンシャルを盗み、クラウドインフラに不正にアクセスする攻撃の傾向が強まっています。こうした攻撃は「脅威アクターに追加されたクラウドリソースへの予期せぬ請求」、「被害修復に必要な期間」の両面で標的組織に損害を与えうるものです。

本稿では、野生(in the wild)で行われたクラウドコンピュートのクレデンシャルに対する攻撃事例を2つ取り上げます。初期アクセスのステージも重要ではありますが、本稿では攻撃中に実行された侵害後の活動にとくに着目し、クラウドインフラに対するこれら2事例の攻撃フローを共有します。これらの攻撃フローは、脅威アクターが盗んだコンピュートのクレデンシャルを悪用し、さまざまな攻撃ベクトル(暗号通貨のマイニングやデータ窃取など)を追い求め、クラウドサービスを予想外の方法で悪用する様子を示します。

以下で解説する攻撃の検出には、クラウドインフラレベルの活動を可視化してくれる、Amazon Web Services (AWS)やGoogle Cloud提唱のクラウドロギングやモニタリングのベストプラクティスが欠かせません。このことからは、ベストプラクティス遵守がいかに重要かがよくわかります。

パロアルトネットワークスは組織のクラウドにおけるセキュリティ問題への対応をCortex XDR for cloudとPrisma Cloudとで支援しています。Cortex XDR for cloudはクラウドコンピュートのクレデンシャル窃取などのクラウドの攻撃を検出し、Prisma Cloudは最小特権のエンタイトルメントによってIDエンタイトルメントを管理します。

関連するUnit 42のトピック Cloud, phishing, cloud security, coin miner

目次

クラウドサービス利用の大原則
攻撃事例1: AWS Lambdaのクレデンシャル侵害からフィッシング攻撃へ
攻撃フロー
検出をめぐる補足的知見
攻撃事例2: Google Cloud App Engineのサービスアカウントが侵害され暗号通貨マイニング用インスタンスをデプロイ
攻撃フロー
検出をめぐる補足的知見
結論: 高まるコンピュートトークン窃取の脅威

クラウドサービス利用の大原則

話に入る前に、クラウドサービスを使う上での基本的で重要なルールを理解しておく必要があります。すべてのエンティティは、それが人間であれ計算ワークロード(compute workload)であれ、インフラのレベルでクラウド環境にアクセスするには関連する正当なクレデンシャルを求められます。こうしたクレデンシャルは、認証(authentication: エンティティの身元を確認する)と認可(authorization: エンティティに許可されている内容を確認する)に使われます。

ベストプラクティスとして、ある計算ワークロードがクラウドでAPIコール(呼び出し)を実行する場合(例: ストレージサービスにクエリを送る)、そのワークロードに紐づくクレデンシャルは、そのワークロード専用のものでなくてはいけません。またそれらクレデンシャルは、対象のワークロードや人間だけが使用できるようにし、そのほかのエンティティは使用してはいけません。

以下の2つの事例でも見ていく予定ですが、クラウドコンピュートのクレデンシャル攻撃リスク低減において重要なセキュリティ原則は最小特権アクセスです。具体的には、「クレデンシャルに紐づく特権は、そのクレデンシャルを使用するコードが実際必要とする最小限の内容に範囲を絞るべき」ということになります。こうすることで、攻撃者がコンピュートのクレデンシャルを盗んでもできることは限られます。

攻撃事例1: AWS Lambdaのクレデンシャル侵害からフィッシング攻撃へ

この事例では攻撃者がLambdaのクレデンシャルを盗むことでLambda関数の代わりにAPIコールを発行していました。これにより攻撃者は複数のAPIコールを実行し、クラウド環境内のさまざまなサービスを列挙できました(図1)。これらのAPIコールのほとんどは権限不足で許可されませんでしたが、この攻撃の結果、脅威アクターが作成したAWS Simple Email Service (SES)からフィッシング攻撃が開始されることになりました。

図1はAmazon Web Servicesのスクリーンショットで、攻撃者がクラウド環境内でLambdaトークンを盗み、Lambda関数になりすましている様子を表す。
図1. 侵害したLambda関数のクレデンシャルでクラウド環境を列挙する攻撃者

このフィッシング攻撃で被害組織は予期せぬ請求を受け、ほかの組織もさらなるリスクに晒されることになりました。

この攻撃による実害は大きなものでしたが、さらに大きな損害をまねく可能性もありました。この事例の被害組織はアクティブなSESを持っていませんでしたが、もし持っていれば、攻撃者はこれを悪用して被害組織に攻撃を仕掛けられたでしょうし、フィッシング攻撃に正規のメールアカウントが使われていたかもしれません。

企業が利用するクラウドサービスは多種多様なので、クラウドの攻撃がどこへ行き着くか予測するのは難しいことがあります。クラウドからフィッシングへ至る手口は少々予想外のものでした。

攻撃フロー

ある攻撃者は、Lambdaの環境変数(AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN)を取得し、自身の攻撃用マシンへエクスポートすることに成功していました。

漏出したクレデンシャルで以下の手順で攻撃が開始されました。

> WHOAMI - 2022-05-20T20:35:49 UTC

攻撃はGetCallerIdentityコマンドから始まりました。このコマンドはwhoamiと同等のもので、クレデンシャルに紐づいているエンティティに関する情報を提供します。このコマンドへの応答から、攻撃者はアカウントIDや盗んだクレデンシャルの種類などの追加情報を得られます。ただしIDに紐付いている特権がどのようなものかはまったくわかりません。

> IDおよびアクセス管理(IAM)の列挙 - 2022-05-20T20:35:55 UTC

攻撃の次の段階はIDおよびアクセス管理(IAM)の列挙でした。IAMは攻撃における最重要部分と考えられています。IAMにアクセスできれば、攻撃者は権限を昇格させて被害者アカウントでの永続性を得られます。

IAMの列挙では2つのAPIコールが行われましたが、どちらも権限不足で拒否されました。

  • ListAttachedRolePolicies
  • ListRolePolicies

ここでは、許可がないことに気づいた攻撃者がコマンドを2回実行しただけでIAM列挙を終了させたと考えるのが妥当でしょう(これはおそらく不要なノイズを残さないためでしょう)。

> そのほかの列挙 2022-05-20T20:39:59 UTC

IAMの列挙に失敗した後、攻撃者は異なるリージョンの異なるサービスに対する列挙を開始しました。この手法は、攻撃者が対象となるアカウントのアーキテクチャについて学び、さらに重要なことに、クラウドアカウントに存在しうる機密情報へのアクセスを試みることから、さらにノイズを増やすものです。

実行された主なサービスやAPIコールの一部を以下に記載します。

ストレージの列挙

  • ListBuckets
  • GetBucketCors
  • GetBucketInventoryConfiguration
  • GetBucketPublicAccessBlock
  • GetBucketMetricsConfiguration
  • GetBucketPolicy
  • GetBucketTagging

EC2の列挙

  • GetConsoleScreenshot
  • GetLaunchTemplateData
  • DescribeInstanceTypes
  • DescribeBundleTasks
  • DescribeInstanceAttribute
  • DescribeReplaceRootVolumeTasks

ネットワークの列挙

  • DescribeCarrierGateways
  • DescribeVpcEndpointConnectionNotifications
  • DescribeTransitGatewayMulticastDomains
  • DescribeClientVpnRoutes
  • DescribeDhcpOptions
  • GetTransitGatewayRouteTableAssociations

ロギングの列挙

  • GetQueryResults
  • GetBucketLogging
  • GetLogRecord
  • GetFlowLogsIntegrationTemplate
  • DescribeLogGroups
  • DescribeLogStreams
  • DescribeFlowLogs
  • DescribeSubscriptionFilters
  • ListTagsLogGroup

バックアップの列挙

  • GetPasswordData
  • GetEbsEncryptionByDefault
  • GetEbsDefaultKmsKeyId
  • GetBucketReplication
  • DescribeVolumes
  • DescribeVolumesModifications
  • DescribeSnapshotAttribute
  • DescribeSnapshotTierStatus
  • DescribeImages

SESの列挙

  • GetAccount
  • ListIdentities

そのほかの列挙

  • DescribeRegions
  • DescribeAvailabilityZones
  • DescribeAccountAttributes

> バックドア 2022-05-20T20:43:22 UTC

IAM列挙に失敗した攻撃者はこの間にCreateUserコマンドを実行して新規ユーザーを作成しようとしていました(失敗)。

> クラウドからフィッシング攻撃へ 2022-05-20T20:44:40 UTC

列挙したAPIコールの大半は権限不足という結果に終わったものの、攻撃者はSESの列挙には成功しました。そこで攻撃者はクラウドメールサービスを悪用してVerifyEmailIdentityやUpdateAccountSendingEnabledなどのコマンドを実行してフィッシング攻撃を仕掛けました。

> 防御の回避 2022-05-20T23:07:06 UTC

最終的にこの攻撃者はDeleteIdentityコマンドを実行してSESのIDを削除することで自身の活動の一部を隠蔽しようとしました。

検出をめぐる補足的知見

この攻撃で非常に重要なIoC(侵害の痕跡)は、IPアドレス50.82.94[.]112でした。

Lambda関数からのAPIコールは、そのLambda用に生成されたクレデンシャル(AccessKeyIdを含む)のIPアドレスから実行されるのが普通です。したがってそのAccessKeyIdを持つAPIコールはすべてLambda関数とみなされます。しかしこの攻撃中、脅威アクターはLambdaのクレデンシャル窃取によりLambdaのなりすましに成功していました。

つまりIPアドレスは「これはLambdaではない」と検出する方法として使える重要なIoCとなります。攻撃者は盗んだクレデンシャルでLambda関数になりすましてAPIコールを代行していましたが、Lambdaに紐付かないIPアドレスやクラウド環境に属さないIPアドレスからこれを行っていました。

攻撃事例2: Google Cloud App Engineのサービスアカウントが侵害され暗号通貨マイニング用インスタンスをデプロイ

この事例では、ある攻撃者がGoogle Cloud App Engineのサービスアカウント(SA)のクレデンシャル窃取に成功しました。攻撃者が窃取を成功させる方法はいろいろあって、必ずしもクラウドサービスプロバイダの脆弱性とは関係がありません。たとえば多くの場合、ユーザーはクレデンシャルを安全でない場所に保管したり、推測が簡単でブルートフォースで破られてしまうようなパスワードを使っていたりします。

この事例で盗まれたサービスアカウントはデフォルトサービスアカウントで、これには高い特権を持つロール(プロジェクトの編集者)が付与されていました。このおかげで、当該脅威アクターの開始した攻撃は最終的には、暗号通貨のマイニングを目的とする複数のハイコアCPUの仮想マシン(VM)作成につながりました(図2)。

図2は侵害したApp Engineサービスのアカウントで攻撃者がマイニング用の複数のクラウドインスタンスを探している様子を表したスクリーンショット。
図2. 攻撃者が侵害したApp Engineのサービスアカウントを悪用しマイニング用に複数のクラウドインスタンスを割り当てている

脅威アクターが被害環境で何千ものVMを起動したさい、予想コストが大幅に増加しました。かりに自社環境内のこうした攻撃にすぐに気づけたひとがいたとしても、コストインパクトは相当なものだったでしょう。

攻撃フロー

Google App EngineはGoogle Cloudのフルマネージドサーバーレスプラットフォームで、サービスアカウントがトークンにあたります。ユーザーがApp Engineインスタンスを作成すると、クラウドプロバイダはデフォルトサービスアカウントを作成して、作成したApp Engineインスタンスにアタッチします。

このApp Engineのデフォルトサービスアカウントには、プロジェクトの編集者のロールが付与されています。編集者のロールは権限が高いので、そこが攻撃者の突いてくる要素となります。このロールでは高い権限の求められる以下のようなAPIコールの実行が可能です。

  • 計算ワークロードの起動
  • ファイアウォール(FW)ルールの変更
  • サービスアカウントキーの作成

> 特権昇格 2022-06-16T12:21:17.624 UTC

この攻撃は特権昇格の試みから始まりました。前述の通り、デフォルトのApp Engineのサービスアカウントはプロジェクトの編集者の権限を持っています。これらの権限を得た攻撃者はIAMポリシーに以下のオブジェクトを追加し、Compute管理者のロールを追加しようとしました。

図3のスクリーンショットは脅威アクターがIAMポリシーにオブジェクトを1つ追加しているようすを示す3行のコード。ここではCompute管理者のロールを追加しようとしている。

上図からも確認できるとおり、このサービスアカウントのドメインプレフィックスのappspotは、このサービスアカウントがApp Engineサービスのものであることを示しています。

> ファイアウォールルールを Allow Any/Any に変更 2022-06-16T12:21:29.406 UTC

次にこの攻撃者はプロジェクトレベルのファイアウォールルールを変更していました。まずdefaultという名前のサブネットを作成しようとしています。次にそのサブネットに以下のルールを追加しています。

画像4は12行のコードのスクリーンショット。脅威アクターはdefaultという名前のサブネットを作成しようとしている

このルール変更は暗号通貨のマイニングという攻撃者の目標に向けた行為で、ネットワークレベルの制限をすべて解除することで、制限なくマイニングできるようにしています。

ここで注意しなくてはならないのがpriority(優先順位)のフィールドです。これを「0」に設定すると、攻撃者のルールが最も高い優先度に設定されます。つまり、既存ファイアウォールルールの順序では、攻撃者の設定したルールが最優先で有効になります。

> マイナーの大群 2022-06-16T12:21:38.916 UTC

設定を完了すると攻撃のメインフェーズが始まり、複数のリージョンでVMが起動されます。

攻撃者は高性能CPUマシンを作成することもできたのですが、この事例では高性能GPU (例: nvidia-tesla-p100)を4つ搭載した標準的VM(例: n1-standard-2)を作成していました。

画像5は脅威アクターが標準的VMを作成したようすを示したコード行のスクリーンショット。合計で1,600台以上が作成されている

この攻撃では合計で1,600台以上のVMが作成されました。

> バックドア 2022-06-16T13:25:56.037 UTC

この攻撃者は攻撃に使ったサービスアカウントキーが検出されて失効することを想定してgoogle.iam.admin.v1.CreateServiceAccountKey APIコールを実行して(後で使うために)複数のサービスアカウントキーを作成していました。

検出をめぐる補足的知見

1つめの事例と同じでIPアドレスが重要なIoCとなります。今回の事例では複数のIPアドレス(全体で9つの異なるIPアドレス)から攻撃が行われていて、そのなかにはアクティブなTorの出口ノードもありました。

この事例についても、App Engineのサービスアカウントはクラウド環境内のIPアドレスからの利用を想定すべきであって、Torの出口ノードからの利用などもってのほかです。

ファイアウォールルールの改ざんはこの手の攻撃ではよく見られるやり口です。アクティブなマイニングプールへのアクセスを拒否するネットワークトラフィックルールを適用している組織が多いので、攻撃者は目的達成のためにファイアウォールルールを改ざんしなければならないのです。

最後に、defaultという名前のネットワークを編集することで攻撃者は検出逃れを図っていました。オプションを無効化していない場合は、新規プロジェクトの作成時にはデフォルトで「default」というネットワークが作成されます。攻撃者はこれを利用することで、独自ネットワークを構築せずにすむようにしたようです。

結論: 高まるコンピュートトークン窃取の脅威

今回取り上げた2つの事例に共通するのが計算ワークロードトークンの窃取です。今回の事例はいずれもサーバーレスサービスに関するものでしたが、この攻撃ベクトル自体はどのコンピュートサービスであっても有効です。

この手の攻撃は多種多様な攻撃経路を起点としうることを強調しておかねばなりません。設定ミスやクラウドセキュリティポスチャー管理(CSPM)の不備だけでなく、アプリケーションの脆弱性やLog4Shellのようなゼロデイ攻撃などもそうした起点になりうるのです。

これらの攻撃に対処するには、検出と調査対応(IR)の両面でクラウドの監査ログが不可欠です。エージェントをインストールできないサーバーレスワークロードの場合、その手の攻撃の阻止が難しいことから、クラウドの監査モニタリングはとりわけ重要となります。

AWSとGoogle Cloudはロギングとモニタリングに関するベストプラクティスを提供しており、これらの事例を防止する上での明確なガイダンスとなります。AWSのGuardDutyサービスは、別のAWSアカウントで使われたEC2インスタンスのクレデンシャルなど、類似した攻撃の検出とアラートにも役立つ可能性があります。追加の防止手段としては、Lambdaのインターフェースエンドポイントポリシーを設定して、Lambdaの利用をVPC内のみに制限する方法があります。

パロアルトネットワークス製品をご利用中のお客様はコンピュートトークンの窃取から以下の方法で保護されています。

  • Cortex XDR for cloudはクラウドホスト、クラウドトラフィック、監査ログからの活動内容と、エンドポイントやネットワークのデータとを統合します。この統合によりSOCチームはデジタルドメイン全体を俯瞰したインシデントのストーリーを得ることができます。
  • Prisma CloudはIDエンタイトルメント管理をサポートすることでクラウド環境におけるIAM管理のセキュリティ課題に対応します。Prisma CloudのIAMセキュリティケイパビリティは、各クラウドサービスプロバイダに適した権限を自動で算出し、緩すぎるアクセスを検出し、最小特権のエンタイトルメントを実現する修正を提案します。

クラウド環境の攻撃から組織を守るには、攻撃の調査・対応を行うUnit 42クラウドインシデントレスポンスサービスや、攻撃を受ける前に自社のセキュリティ態勢を評価しておくサイバーリスクマネジメントサービスについてもぜひご一読ください。

Ignite '22でクラウドの脅威の検出手法を学ぶ
パロアルトネットワークスによる未来のセキュリティカンファレンス「Ignite '22」では、クラウドセキュリティ関連セッションが多数提供されています。パロアルトネットワークスのチーフテクノロジーオフィサー、ミスラ アジェイによる2つの講演を含むクラウドセキュリティセッションをぜひご視聴ください。オンデマンドでも配信されます。イベント参加登録はこちらから。