本文の内容は、2022年11月29日に JASON AVERYが投稿したブログ（https://sysdig.com/blog/extortion-in-cloud-storage/)を元に日本語に翻訳・再構成した内容となっております。
恐喝とは、簡単に言えば “強要によって利益を得ること” です。データおよびクラウドの強奪スキームは、貴重なデータやアクセス権が攻撃者によって盗まれ、支払いやその他の要求によってそれを回復することを約束する場合に発生します。
この記事では、よくある、あるいは一般的ではない恐喝の手口をいくつか取り上げ、その手口を検知し、被害に遭わないようにするための方法を紹介します。
足がかり
まず、攻撃者は、ある環境に足がかりを得る必要があります。この足がかりは、さまざまな方法で得ることができます。- Log4ShellやSpring4Shellのような脆弱性は、アクセスするために悪用されることが多い。
- ソースコードに格納されたアクセスキーやその他のトークン。
- ソーシャル・エンジニアリングにより、アクセスを許可したり、アクセス認証やキーを開示したりする。
- ワークステーションに感染したマルウェアは、保存されている認証情報を見つけることができる。
アマゾン ウェブ サービス (AWS)
AWS環境では、Amazon Simple Storage Service（S3）バケットに、バケット単位またはファイル単位でファイルの暗号化を行うことができます。暗号化には、AWSが提供するキー、お客様独自のキー、または他のアカウントのキーを使用することができます。一般的に、暗号化はいつでも変更可能です。侵害されたアカウントにアクセスできる攻撃者は、他のアカウントからの暗号化キーを使用して、アカウント上のファイルへのアクセスを暗号化してロックアウトすることを利用することができます。
まず、攻撃者はお客様のAWSアカウントでカスタムキーを作成します。これは、この目的だけのために使い捨てのアカウントから作成することもできますし、攻撃を開始するために別の侵害されたアカウントから作成することもできます。
攻撃者は、どの被害者アカウントに悪意のある鍵へのアクセスを許可するかを指定します。鍵に関するポリシーを記述する際、攻撃者はkms:Decryptとkms:DescribeKeyをポリシーから削除します。これにより、被害者がその鍵を使ってファイルにアクセスしたり、鍵に関する情報を取得したり、ファイルから鍵を削除したりすることができなくなります。
攻撃者の鍵ポリシーは、次のようになります：
アクセスがロックアウトされると、被害者は自分のファイルにアクセスしようとすると、”Access Denied “というメッセージを受け取ります：
ロックされたファイルから外部キーを削除しようとすると、エラーになることがあります：
このような状況には、バケットのバージョニングが有効です。バージョニングとは、ファイルの古いコピーを保持し、ロールバックを可能にするためのクラウドストレージの機能です。ファイルの以前のバージョンにロールバックすることで、アカウント所有者はファイルへのアクセスを回復できる可能性があります。
AWSストレージでの強奪を検出する
賢い攻撃者は、バケットのバージョニングを無効にして、ファイルの古いコピーを削除したいと思うでしょう。Falcoのルールは、バケットのバージョニングを無効にしようとする試みをアカウント所有者に警告することができ、そのような警告は軽く扱われるべきではありません。ルール “AWS S3 Versioning Disabled “は、そのような試みを検出します。- rule: AWS S3 Versioning Disabled
desc: Detect disabling of S3 bucket versioning.
condition:
aws.eventSource = "s3.amazonaws.com" and
aws.eventName = "PutBucketVersioning" and
jevt.value[/requestParameters/VersioningConfiguration/Status] = "Suspended" and
not aws.errorCode exists
output:
The file versioning for a bucket has been disabled.
(requesting user=%aws.user,
requesting IP=%aws.sourceIP,
AWS region=%aws.region,
arn=%jevt.value[/userIdentity/arn],
bucket name=%jevt.value[/requestParameters/bucketName])
priority: WARNING
source: aws_cloudtrail
最終的に被害者の以前のキーへのアクセスを削除するために、攻撃者はキーの削除をスケジュールできます。 キーをすぐに削除することはできません。 代わりに、キーが最終的に破棄されるまでに最低 7 日間の待機期間があります。
Falcoを使用しているアカウント所有者は、鍵の削除がスケジュールされると、ルール ”Schedule Key Deletion” によって警告を受け、状況を改善するために直ちに行動を起こすことができます。
- rule: Schedule Key Deletion
desc: Detect scheduling of the deletion of a customer master key.
condition:
aws.eventName="ScheduleKeyDeletion" and not aws.errorCode exists
output:
A customer master key has been scheduled for deletion.
(requesting user=%aws.user,
requesting IP=%aws.sourceIP,
AWS region=%aws.region,
arn=%jevt.value[/userIdentity/arn],
key id=%jevt.value[/requestParameters/keyId])
priority: WARNING
source: aws_cloudtrail
暗号が変更され、ロールバックコピーが削除され、オリジナルの鍵が破壊されると、被害者は攻撃者からデータへのアクセスを回復するよう要求されることになります。
もっと詳しく知りたい方は、本番環境で採用したいAWSセキュリティのベストプラクティス26選をご覧ください。
Google Cloud Platform (GCP)
AWSとは異なり、GCPは同じ暗号化キーの切り替えによる強要の手法の影響を受けません。バケット作成時に暗号化は必須であり、後から変更することは可能ですが、暗号化解除された状態や他のアカウントの鍵では変更できません。GCPユーザーは、Googleが管理するキーを使用するか、独自のキーを供給することができます。鍵はBucket上の全てのファイルに一律に適用されるため、ファイルごとの鍵が変更されるようなことはありません。
AWSで説明した鍵の切り替え方式ではなく、攻撃者はより低速な方法でアクセスをロックアウトすることができます。バケットからファイルを移し、古いコピーを削除し、オプションでプレースホルダとして暗号化されたファイルをアップロードする必要があります。攻撃者はファイルを手動でダウンロードするか、転送ジョブを作成してその作業を代行させることができます。
Transfer JobはGCPの機能で、あるバケットから別のバケットへデータをコピーし、その過程でオプションとしてソースファイルを削除することができます。これは、攻撃者が被害者からデータを盗み出すための高速な方法として使用できます。ファイルが転送されて利用できなくなると、被害者はデータを取り戻すために攻撃者の要求の気まぐれにさらされることになります。
GCP Storageにおける強奪の検出
GCPユーザーにとって残念なことに、転送ジョブが開始されたことを示す唯一の監査ログメッセージは、storage-transfer-service.iam.gserviceaccount.comサービスアカウントに転送を実行する許可をroles/storage.objectAdminで与えるstorage.setIamPermissionsメソッドの呼び出しだけです。曖昧なため、注意深く見ていると簡単に見逃してしまうでしょう。Falcoのルール “GCP Set Bucket IAM Policy” は、バケットに対するこのようなポリシーの変更と同様の変更を検出することができます。
- rule: GCP Set Bucket IAM Policy
desc: Detect setting the permissions on an existing bucket using IAM policies.
condition:
gcp.methodName="storage.setIamPermissions" and
jevt.value[/protoPayload/status]={}
output:
The permissions on an existing bucket have been set using IAM policies
(requesting user=%gcp.user,
requesting IP=%gcp.callerIP,
region=%jevt.value[/protoPayload/resourceLocation/currentLocations/0],
bucket=%jevt.value[/protoPayload/resourceName])
priority: WARNING
source: gcp_auditlog
AWSと同様に、GCPでもバケット全体のバージョニングが実装されています。バケットバージョニングを無効化すると、ファイルは以前のバージョンを保持しますが、新しいバージョンは作成されません。
アカウント所有者にとっては残念なことに、Object Versioningが無効化されたり、ファイルのバージョンが削除されたりすると、GCPのログメッセージには単に “unspecified bucket change” というメッセージが記録されるだけです。このため、潜在的に危険な変更を通知されることは困難です。攻撃者によってファイルが削除された場合、そのファイルの以前のバージョンもすべて、しばらくすると削除されることになります。
その他のヒントは、オープンソースを利用したGoogle Cloudのセキュリティベストプラクティス24項目にてご確認ください。
Microsoft Azure
Azureは、ファイルストレージのニーズに応じて “Storage Accounts” を提供しています。ストレージアカウント（バケット）には、コンテナ（ディレクトリ）に格納されるデータのBlob（ファイル）があります。用語は少し違いますが、AWSやGCPとほぼ同じ運用が可能です。
AzureはデフォルトでMicrosoftが提供するキーでBlobの暗号化が可能です。GCPと同様に、Azureは海外アカウントの鍵の使用を許可していません。
AWSやGCPで説明したように、ソフト削除やファイルのバージョン管理などの機能を利用することで、攻撃から保護することができます。しかし、Azureはメリットとは言えない機能を提供しています。ストレージアカウントは、デフォルトで読み取りアクセスで一般に公開されます。これは、知らず知らずのうちにAzureのお客様をデータ漏洩の危険にさらす可能性があります。
一般にアクセス可能なBlobからは、認証情報、個人識別情報（PII）のような機密情報、あるいはその他の非公開であるべきデータが漏れる可能性があります。漏洩した情報は、元の所有者から情報を漏洩しないように強要するだけで、攻撃者にとって価値あるものとなり得ます。NetSPIのMicroBurstのようなツールは、匿名アクセスが可能なストレージアカウントをスキャンして検索するのに使用することができます。
Azure Storageにおける強要の検出
Falcoのユーザーは、”Azure Access Level for Blob Container Set to Public” というルールを使って、ストレージアカウントのパーミッションの変更にアラートを出すことができます。- rule: Azure Access Level for Blob Container Set to Public
desc: |
Anonymous, public read access to a container and its blobs can be enabled in Azure Blob storage. It grants read-only access to these resources without sharing the account key, and without requiring a shared access signature. It is recommended not to provide anonymous access to blob containers until, and unless, it is strongly desired. A shared access signature token should be used for providing controlled and timed access to blob containers. If no anonymous access is needed on the storage account, it's recommended to set allowBlobPublicAccess false.
condition:
jevt.value[/operationName]="MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and
jevt.value[/resultType]="Success" and
jevt.value[/resultSignature]="Succeeded.OK" and
jevt.value[/properties/responseBody] contains "\"allowBlobPublicAccess\":true"
output:
Anonymous access to blob containers has been allowed on storage account
(requesting user=%jevt.value[/identity/claims/http:~1~1schemas.xmlsoap.org~1ws~12005~105~1identity~1claims~1name],
storage account=%jevt.value[/resourceId])
priority: WARNING
source: azure_platformlogs
パブリック リード アクセスはデフォルトで有効になっており、Web インターフェイスまたは Azure コマンド ライン インターフェイス (CLI) を使用して無効にする必要があります。以下は、Azure CLI を使用してパブリック アクセスを無効にする方法です。
# First, gather a list of storage accounts.
az storage account list \
--query '[*].name'
# For each result, use the returned value (as ACCOUNT_NAME) to get a list of containers
az storage container list \
--account-name ACCOUNT_NAME \
--query '[*].name'
# Now for each container name (as CONTAINER_NAME), check if public access is allowed.
az storage container show \
--account-name ACCOUNT_NAME \
--name CONTAINER_NAME \
--query 'properties.publicAccess'
# Result should be 'container', 'blob', or nothing (meaning 'private' and no public access).
# Now for each result with 'container' or 'blob', disable public-access:
az storage container set-permission \
--account-name ACCOUNT_NAME \
--name CONTAINER_NAME \
--public-access off
まとめ
クラウド環境の特徴を理解することは、効果的なセキュリティ・ポリシーを適用するための重要な要素です。クラウドストレージの強奪は、適切なセキュリティ態勢を導入するコストよりも簡単に大きなコストとなり得ます。環境を常に監視することで、セキュリティイベントが制御不能になる前に効果的に対応することができます。
クラウド・セキュリティ・ポスチャー・マネジメント（CSPM）への準拠を保証するソリューションと、対応に時間を費やさないようにするリアルタイム検知を組み合わせることで、あらゆるシナリオに対応できるようになります。
Sysdigは、膨大なコストのかかるデータレイクの保存を必要とせず、クラウドの長いログをふるいにかけて、セキュリティイベントの可能性をいち早く警告することができます。
さらに、Sysdigは、クラウドセキュリティポスチャーマネジメント（CSPM）とクラウド脅威検知を統合しています。
詳しくは、以下の記事でご紹介しています。