アップデイト:この投稿は、AWS S3レプリケーション、CloudTrail、セキュリティチームとのコラボレーションで得られた新しい情報を反映するために更新されました。
包括的なバックアップ戦略は、あらゆるDR計画の礎石です。しかし、正当なバックアップ活動と悪意のあるデータ流出をどのように区別するのでしょうか？
サイバー攻撃者は、クラウドネイティブ・バックアップを実行する機能を含むクラウド・コントロール・プレーンへのアクセスをますます増やしている。ここでは、これらのツールを活用して、組織の本番環境全体からデータを流出させる方法を紹介します。
このブログでは、攻撃者がS3レプリケーションを悪用して効率的にデータを環境から移行する方法を詳しく見ていく。作成したときと同様に、読んで面白いと感じていただければ幸いである。
この攻撃は、ここに挙げた4人の異なるアクターの視点から、別々のストーリーで展開される。
- S3レプリケーションサービスS3レプリケーション・サービスは、レプリケーション・ルールに従ってS3のデータをバケット間でレプリケートする。
- 邪悪なS3レプリケーション・サービスデータを外部にコピーするために悪用される。
- 攻撃者S3レプリケーション・サービスをコントロールし、サービスを悪用し、そのロギングの欠如を利用してレーダーをかいくぐる。
- SOCチームのメンバー(セキュリティ・オペレーション・センター）のメンバーは、S3レプリケーション・サービスを介したデータ移動が部分的に見えないことを知るが、それを補うために検知戦略を変更することができる。
S3レプリケーション・サービス、その機能と優れたユースケースの紹介
AWS S3サービスは、もはや「シンプル・ストレージ・サービス」ではなくなっている。何十もの機能と統合により、AWSのエンタープライズ顧客にとって最も選択されるデータストアになった。また、非常に複雑であるため、すべての機能を理解し、セキュリティを確保することは難しい。S3の数ある機能の1つに、リージョンやアカウントを越えてデータをコピーし、データのアクティブバックアップを作成する機能がある。
この記事にあるように、この機能は悪用される可能性が高く、可視化するのは難しい。
AWSのレプリケーション・サービスは、あなたが考えている通りのことをする。ルールで指示すると、S3のデータをバケット間でコピーする。
サービスはレプリケーション・ルールから指示を受けます。Ruleを設定することで、複数のバケットにデータをコピーし、同じソースオブジェクトの複数のレプリカを作成するようサービスに指示することができます。
デスティネーションバケットは、ソースバケットと同じリージョンや同じアカウントである必要はありません。
そのデータ複製機能は、Serviceにその権限が付与されている場合にのみ可能である。S3 Replication Serviceを有効にするには、ソースとデスティネーションの両方のバケットにアクセスするIAMパーミッションが付与されたIAM Roleを想定して設定する。
攻撃者がAWSのS3レプリケーションを使用する能力を得た場合、どのような影響がありますか？
クロスアカウント・レプリケーションは、データ損失が発生した場合の復旧を支援する。しかし、レプリケーション・サービスが悪用されると、cybercriminels 、信頼できない場所にデータを吸い上げることが可能になる。
S3レプリケーション・サービスは悪用される可能性が高く、結果として攻撃者の格好の標的となっている。
もし攻撃者がReplication Rulesを作成する能力を得れば、S3 Replication Serviceに攻撃者が管理する外部バケットにデータをコピーするよう指示することができる。被害者のAWS組織の外部に存在するものでさえも。
外部にレプリケートするには、どのようなIAMパーミッションが必要ですか？
S3レプリケーションサービスは、ソースバケットからオブジェクトを取得し、攻撃者が管理する外部のバケットにオブジェクトをレプリケートするために、S3オブジェクトのパーミッションを必要とします。
以下は、レプリケーションに必要なアクションを定義するIAMポリシーの例だが、リソースフィールドを "*"のままにして、リソースへのパーミッションのスコープを無視している。このポリシーは非常に寛容なので、S3 Replication Serviceは、アカウント外のバケットであっても、どのバケットにもオブジェクトをコピーすることができる。
過度に寛容なポリシーの場合、攻撃者はレプリケーションルールを更新し、攻撃者が管理するバケットにデータをコピーするようレプリケーションサービスに指示する機能が必要になる。オブジェクト自体にはパーミッションは必要なく、ルールを更新する能力だけが必要である。
要約すると、アカウントからデータを直接コピーまたは移動する代わりに、悪意のあるレプリケーションルールの結果として、攻撃者がS3レプリケーションサービスを活用し、同じアクションを代わりに実行することができる。これは修復可能なバグではなく、「機能の悪用」と呼ばれるクラウド脆弱性の一種です。
S3レプリケーション・サービスはどのようにその活動を記録するのか？また、それは攻撃者が気づかれないようにするためにどのように役立つのでしょうか？
S3レプリケーションサービスを介したデータの移動は、透過性が低いため、データの流出を追跡することが特に難しく、攻撃者がクラウド環境内で平然と活動を隠すことができます。
データプレーントレイルのコンフィギュレーション・バケット・スコープに基づいて、レプリケーションサービスがCloudTrailにイベントを書き込むタイミングと 場所を見てみよう。
S3オブジェクトに影響するイベントを可視化するには、S3データイベントの収集に参加する必要がある。これらのイベントのスコープは、'現在と将来の全てのS3バケット'を含むように設定することもできるし、個々のバケットを列挙することもできる。このCloudTrail設定は、S3データプレーンロギングに特定のバケットをスコープインするフィルタリングメカニズムとして機能する。
S3 Replication Serviceによってデータがコピーされると、レプリケーション時にサービスがオブジェクトを取得するため、GetObjectイベントが発生する。このイベントはSource Account CloudTrailに書き込まれる。
GetObjectイベントの後、PutObjectイベントは、デスティネーションバケットを明らかにし、外部デスティネーションアカウントとソースアカウントの両方に記録される。
ログが特定のバケットに制限されている場合、CloudTrail S3データプレーンロギングの動作はどうなりますか？
コストを管理するために、組織は「現在と将来のすべてのバケット」でのロギングにお金を払うのではなく、価値の高いバケットでのみS3データプレーンログを有効にすることがよくあります。このロギング設定は、S3レプリケーションサービスの可視性をどのように変更しますか？
GetObject イベントに続いて、PutObjectイベントが Destination Account CloudTrail コンフィギュレーションに従って Destination Account に記録される。ただし、ソース・アカウントには PutObject イベントは記録されない。
これが実際に意味することは、レプリケーション・サービスによってデータがコピーされる際、ソース・アカウントのCloudTrailには、外部のデスティネーション・バケットを明らかにするレコードは存在しないということです。
CloudTrailが特定のソースアカウントバケットからS3データプレーンイベントをキャプチャするように構成されている場合、ロギングにギャップが存在し、ソースアカウントにデータプレーンイベントであるPutObjectを記録せずにデータをコピーすることができる。
現在および将来のすべてのバケットからのログを含むようにスコープされたデータプレーンログがなければ、攻撃者はレプリケーションルールを更新してオブジェクトを外部バケットに複製することができる。
幸いなことに、予防策ははっきりしている。
いつものように、AWS IAM アイデンティティポリシーを定義するとき、ポリシーの権限がどのポリシーにも適用できるように、リソースフィールドを空白のままにしないでください。Replication Service が想定する IAM Role が、どのバケットに対して操作を許可するかを明示的に列挙していることを確認してください。
クラウド、守備側にはどのような影響があるのだろうか？
ザット・ハンターは、レプリケーション・ルールの悪意のある更新を、データ流出が自分の環境で静かに発生している可能性を示す手がかりとして利用することができる。
S3レプリケーション・サービスの悪用がいかに防げるか、そしてなぜこの可視性の欠如が世界の脅威ハンターやクラウドディフェンダーにとって重要なのか。
なぜこのようなロギングの不整合が重要なのかを知るためには、組織における防御者の使命について議論する必要がある。クラウド 防御者は、侵害の指標を探すために、クラウド環境について絶えず質問している。彼らの仕事は、予防措置の最善の努力にもかかわらず、物事がうまくいかなくなったときに、検知 。
防御者の糧となるのは、データが境界から移動していることを早期に警告するための検知に使用するログである。防御者が利用できるデータプレーンのログは、コストの問題に対処し、すべてをキャプチャする際に生成される可能性のあるデータプレーンのログの膨大な量を削減するために、既知の価値の高いバケットのみに制限される場合があります。
コピー先のバケットを記録することなくデータをコピーできる場合、CopyObjectやPutObjectイベントのようなデータプレーンイベントで不良バケットを探すことで、データの流出を包括的にアラートしたり追跡したりすることはできない。
ディフェンダーは、データ境界を包括的に監視できるように、レプリケーション・ルールの更新を含めるように監視するイベントを拡大する必要がある。
SOC が「現在および将来のすべてのバケット」に対して S3 データプレーンロギングを強制できない場合、PutBucketReplication イベントを監視してアラートすることが、防御者が外部のデスティネーションバケットを可視化できる唯一の場所となる。このイベントはデータがコピーされたことを示すのではなく、レプリケーションサービスにデータコピーのルールが設定されていることを示すだけである。
レプリケーション・サービスを悪用した場合の教訓
S3 Replication Serviceは、組織がランサムウェアへの耐性を高めるのに役立ちますが、脅威モデルを構築する際には、攻撃者の視点からクラウドの機能を見ることができるように、邪悪なユーザーストーリーを作成することが重要です。
コストがかかるため、一般的な組織では、アカウント内のすべてのバケットでS3データプレーンロギングを有効にすることをためらい、価値の高いバケットでのみ選択的にログを取得することを好むかもしれません。私たちが見てきたように、その戦略は、PutObjectイベントがソースアカウントに書き込まれないため、S3の流出の可視性にギャップをもたらす。
2022年8月現在、AWSはS3 Replicationサービスのロギング問題の修正を拒否している。AWSと議論する中で、以下の解決策または'機能要求'が提案された。
- GetObjectイベントにデスティネーションバケットを含める
- これらの2つのイベントは、デスティネーションバケットのデータプレーンのログスコープを考慮するのではなく、ソースバケットのスコープフィルタの結果としてソースアカウントに書き込まれます。
報告タイムライン
10/19/21
[Vectra]：最初の脆弱性報告書が提出され、同日中に受領が確認された。
10/20/21
[AWS]：AWS：脆弱性ではないとの回答：
「このレポートに記載されている動作がセキュリティ上の懸念になるとは考えていません。私たちは、バケットのレプリケーションポリシー[1]に加えられた変更をログに記録するCloudWatchアラームを提供しています。S3BucketChangesAlarm "の詳細を参照。
10/20/21
[Vectra]：AWS がログの欠落を脆弱性とは考えていないことの確認を要求。このレポートに対する AWSレスポンス を、いかなる公開情報においても '修正しない' と表現することを指示。
10/26/21
[AWS]：AWSは、私がこの情報開示をどこで公表するのか、また、そのテキストの事前コピーを入手することができるのか、と尋ねてきた。
10/26/21
[Vectra]：公開された情報の事前コピーを受け取ることができることを認めた。
2/2/22
[Vectra]：S3レプリケーションサービスのロギングを強化するよう、AWSセキュリティチームの内部連絡先に元の脆弱性レポートを再送しました。
2/3/22
[AWS]：AWS: 内部でチケットを入れたことを確認。
7/20/22
[Vectra]：レプリケーション時間制御(RTC)が有効な場合にのみロギング問題が発生すると説明した、この件に関する初期調査の発表。
7/25/22
[Vectra]：RTCを有効にしていてもいなくてもロギングが発生しないことを発見し、再テストしました。
7/26/22
[Vectra]：fwd:cloudSecにて研究成果を発表
8/18/22
[Vectra とAWS]：調査結果を議論するためのミーティング。このミーティングでは、CloudTrail S3データプレーンスコーピングフィルタが、PutObjectイベントがソースアカウントに書き込まれるかどうかを制御するメカニズムであることが理解された。
[1]https://docs.aws.amazon.com/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf