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
2025-09-29 22:47:54 +00:00
parent 6e3a7219a9
commit 5fe04c0519
2 changed files with 45 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+22 -12
View File
@@ -4,20 +4,20 @@
## STS
자세한 정보는 다음을 참조하세요:
자세한 정보:
{{#ref}}
../aws-services/aws-iam-enum.md
{{#endref}}
### IAM 자격 증명에서 콘솔로
### IAM Creds에서 Console로
IAM 자격 증명을 얻었다면 **웹 콘솔에 접근하는 것**에 관심이 있을 수 있습니다.\
사용자/역할은 **`sts:GetFederationToken`** 권한을 가져야 합니다.
IAM credentials를 획득했다면, 다음 도구들을 사용해 **web console에 접근**하는 데 관심이 있을 수 있습니다.\
해당 사용자/역할에는 **`sts:GetFederationToken`** 권한이 있어야 합니다.
#### 사용자 정의 스크립트
#### Custom script
다음 스크립트는 기본 프로필과 기본 AWS 위치(정부 및 중국 제외)를 사용하여 웹 콘솔에 로그인하는 데 사용할 수 있는 서명된 URL을 제공합니다:
다음 스크립트는 default profile과 기본 AWS 리전을 사용(정부 리전(gov) 및 중국 리전(cn) 제외)하여 web console에 로그인할 때 사용할 수 있는 signed URL을 생성합니다:
```bash
# Get federated creds (you must indicate a policy or they won't have any perms)
## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
```
#### aws_consoler
You can **generate a web console link** with [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler)를 사용하여 **웹 콘솔 링크를 생성할 수 있습니다**.
```bash
cd /tmp
python3 -m venv env
@@ -64,22 +64,22 @@ pip install aws-consoler
aws_consoler [params...] #This will generate a link to login into the console
```
> [!WARNING]
> IAM 사용자가 `sts:GetFederationToken` 권한을 가지고 있는지 확인하거나, 가정할 역할을 제공하십시오.
> IAM 사용자에게 `sts:GetFederationToken` 권한이 있는지 확인하거나, assume할 role을 제공하세요.
#### aws-vault
[**aws-vault**](https://github.com/99designs/aws-vault)는 개발 환경에서 AWS 자격 증명을 안전하게 저장하고 액세스하는 도구입니다.
[**aws-vault**](https://github.com/99designs/aws-vault)은 개발 환경에서 AWS 자격 증명을 안전하게 저장하고 액세스하기 위한 도구입니다.
```bash
aws-vault list
aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
aws-vault login jonsmith # Open a browser logged as jonsmith
```
> [!NOTE]
> **aws-vault**를 사용하여 **브라우저 콘솔 세션**을 얻을 수도 있습니다.
> **aws-vault**를 사용해 **브라우저 콘솔 세션**을 얻을 수도 있습니다
### **Python에서 User-Agent 제한 우회하기**
### **Python에서 User-Agent 제한 우회**
사용된 **user agent에 따라 특정 작업을 수행하는 제한**이 있는 경우(예: user agent에 따라 python boto3 라이브러리 사용 제한) 이전 기술을 사용하여 **브라우저를 통해 웹 콘솔에 연결**하거나, 다음과 같이 **boto3 user-agent를 직접 수정**할 수 있습니다:
사용되는 **user agent**에 따라 특정 작업을 수행하는 데 **제한이 있는 경우**(예: user agent를 기준으로 python boto3 라이브러리 사용을 제한하는 경우), 이전 기법을 사용해 **브라우저를 통해 웹 콘솔에 연결**하거나, 직접 **boto3의 user-agent를 수정**하여 다음과 같이 할 수 있습니다:
```bash
# Shared by ex16x41
# Create a client
@@ -92,4 +92,14 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
# Perform the action
response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
```
### **`sts:GetFederationToken`**
이 권한을 사용하면 이를 실행한 사용자에 대해 그 사용자가 가진 권한으로 제한된 연합 신원(federated identity)을 생성할 수 있습니다.
```bash
aws sts get-federation-token --name <username>
```
sts:GetFederationToken이 반환하는 토큰은 호출한 사용자의 federated identity에 속하지만 권한이 제한됩니다. 사용자가 관리자 권한을 가지고 있더라도 IAM 사용자 목록 조회나 정책 연결(attaching policies)과 같은 일부 작업은 federated token으로 수행할 수 없습니다.
또한 이 방법은 다소 은밀합니다. federated user가 AWS Portal에 표시되지 않으므로 CloudTrail logs나 모니터링 도구를 통해서만 관찰할 수 있습니다.
{{#include ../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+23 -37
View File
@@ -6,9 +6,9 @@
### `sts:AssumeRole`
모든 역할은 **역할 신뢰 정책**으로 생성되며, 이 정책은 **누가 생성된 역할을 맡을 수 있는지**를 나타냅니다. **같은 계정**의 역할이 다른 계정이 이를 맡을 수 있다고 말하면, 해당 계정은 역할에 접근할 수 있게 됩니다 (그리고 잠재적으로 **privesc**를 할 수 있습니다).
모든 role은 **role trust policy**와 함께 생성됩니다. 이 정책은 **누가 생성된 role을 assume할 수 있는지**를 나타냅니다. **동일한 계정**의 role이 어떤 계정이 이를 assume할 수 있다고 명시하면, 그 계정은 해당 role에 접근할 수 있게 되며(그리고 잠재적으로 **privesc**) 권한 상승이 발생할 수 있습니다.
예를 들어, 다음 역할 신뢰 정책은 누구나 이를 맡을 수 있음을 나타내므로, **모든 사용자가 해당 역할과 관련된 권한으로 privesc를 할 수 있습니다**.
예를 들어, 다음 role trust policy는 누구나 해당 role을 assume할 수 있음을 나타내므로, 따라서 **어떤 사용자든 해당 role과 연관된 권한으로 privesc할 수 있습니다**.
```json
{
"Version": "2012-10-17",
@@ -23,41 +23,21 @@
]
}
```
당신은 다음 역할을 가장할 수 있습니다:
다음 명령을 실행하여 역할을 가장할 수 있습니다:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**잠재적 영향:** 역할에 대한 권한 상승.
**잠재적 영향:** Privesc to the role.
> [!CAUTION]
> 이 경우 권한 `sts:AssumeRole`은 **악용할 역할에 명시되어야** 하며 공격자의 정책에는 명시되지 않아야 합니다.\
> 한 가지 예외를 제외하고, **다른 계정의 역할을 가정하기 위해** 공격자 계정은 **역할에 대해 `sts:AssumeRole`** 권한이 **필요합니다.**
> 이 경우 권한 `sts:AssumeRole` 는 공격자가 가진 정책에 있는 것이 아니라 **남용할 역할에 명시되어야 한다.**\
> 한 가지 예외를 제외하고, 다른 계정의 역할을 **가정하려면** 공격자 계정은 해당 역할에 대해 **또한** **`sts:AssumeRole`** 권한을 가지고 있어야 한다.
### **`sts:GetFederationToken`**
이 권한을 사용하면 모든 사용자를 가장하기 위한 자격 증명을 생성할 수 있습니다:
```bash
aws sts get-federation-token --name <username>
```
이 권한을 다른 사용자를 가장할 수 있는 접근 권한을 주지 않고 안전하게 부여하는 방법은 다음과 같습니다:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
}
]
}
```
### `sts:AssumeRoleWithSAML`
이 역할에 대한 신뢰 정책은 **SAML을 통해 인증된 사용자에게 역할을 가장할 수 있는 권한을 부여합니다.**
이 역할의 trust policy는 **SAML로 인증된 사용자가 역할을 대리(impersonate)할 수 있는 접근을 허용한다.**
이 권한이 포함된 신뢰 정책의 예는 다음과 같습니다:
An example of a trust policy with this permission is:
```json
{
"Version": "2012-10-17",
@@ -78,21 +58,21 @@ aws sts get-federation-token --name <username>
]
}
```
역할을 가장하기 위한 자격 증명을 생성하려면 일반적으로 다음과 같은 방법을 사용할 수 있습니다:
일반적으로 role을 가장하여 credentials를 생성하려면 다음과 같이 사용할 수 있습니다:
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
하지만 **제공자**는 이를 더 쉽게 만들기 위해 **자신의 도구**를 가질 수 있습니다, 예를 들어 [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
하지만 **프로바이더**는 이를 더 쉽게 해주는 **자체 도구**를 제공할 수 있습니다, 예: [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
**잠재적 영향:** 역할에 대한 권한 상승.
**Potential Impact:** 역할에 대한 Privesc.
### `sts:AssumeRoleWithWebIdentity`
이 권한은 **모바일, 웹 애플리케이션, EKS...**에서 웹 아이덴티티 공급자를 통해 인증된 사용자에 대한 임시 보안 자격 증명 세트를 얻을 수 있는 권한을 부여합니다. [여기에서 자세히 알아보세요.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
이 권한은 웹 identity provider와 함께 모바일, 웹 애플리케이션, EKS 등에서 인증된 **사용자들**에게 임시 보안 자격 증명 세트를 얻을 수 있는 권한을 부여합니다. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
예를 들어, **EKS 서비스 계정**이 **IAM 역할을 가장할 수 있어야** 하는 경우, **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`**에 토큰이 있으며, 역할을 **가정하고 자격 증명을 얻을 수** 있습니다.
For example, if an **EKS service account** should be able to **impersonate an IAM role**, it will have a token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** and can **assume the role and get credentials** doing something like:
```bash
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod
@@ -105,9 +85,9 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere는 AWS 외부의 워크로드가 X.509 인증서를 사용하여 IAM 역할을 가정할 수 있도록 합니다. 그러나 신뢰 정책이 적절하게 범위가 지정되지 않으면 권한 상승을 위해 악용될 수 있습니다.
AWS IAM RolesAnywhere는 AWS 외부의 워크로드가 X.509 certificates를 사용해 IAM roles를 맡을 수 있도록 허용합니다. 그러나 trust policies가 적절히 범위(scope) 지정되지 않으면 권한 상승에 악용될 수 있습니다.
이 정책은 허용되는 신뢰 앵커 또는 인증서 속성에 대한 제한이 없습니다. 결과적으로, 계정의 모든 신뢰 앵커에 연결된 모든 인증서를 사용하여 이 역할을 가정할 수 있습니다.
이 정책은 어떤 trust anchor나 certificate attributes가 허용되는지에 대한 제한이 없습니다. 결과적으로, 계정 내의 어떤 trust anchor에 묶인 어떤 certificate라도 이 역할을 맡는 데 사용할 수 있습니다.
```json
{
"Version": "2012-10-17",
@@ -127,9 +107,9 @@ AWS IAM RolesAnywhere는 AWS 외부의 워크로드가 X.509 인증서를 사용
}
```
프라이빗 에스컬레이션을 위해 `aws_signing_helper`가 필요합니다. https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
privesc를 위해 `aws_signing_helper`가 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html 에서 필요합니다
그런 다음 유효한 인증서를 사용하여 공격자는 더 높은 권한 역할로 전환할 수 있습니다.
그런 다음 유효한 인증서를 사용하여 공격자는 더 높은 권한의 role로 pivot할 수 있습니다
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -138,6 +118,12 @@ aws_signing_helper credential-process \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
The trust anchor은 클라이언트 인증서 `readonly.pem`이 권한 있는 CA에서 발급되었는지 검증합니다. trust anchor를 생성할 때 CA의 공개 인증서가 포함되었고(현재 `readonly.pem` 검증에 사용됨), `readonly.pem` 내부에는 공개 키가 들어 있어 AWS가 해당 서명이 대응하는 개인 키 `readonly.key`로 만들어졌는지 확인하는 데 사용합니다.
이 인증서는 또한 신원을 증명하고 CN 또는 OU와 같은 속성들을 제공하며, `default` 프로파일은 이를 태그로 변환합니다. 역할의 trust policy는 이러한 태그를 사용해 접근 허용 여부를 결정할 수 있습니다. trust policy에 조건이 없다면 해당 태그들은 무시되고 유효한 인증서를 가진 누구나 통과할 수 있습니다.
이 공격이 가능하려면 trust anchor와 `default` 프로파일 둘 다 활성 상태여야 합니다.
### References
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)