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-escalation/

Browse Source
This commit is contained in:
Translator
2025-06-24 14:06:47 +00:00
parent a054ae2049
commit 0a939c6f51
2 changed files with 50 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-roles-anywhere-privesc.md
-42
View File
@@ -1,42 +0,0 @@
# AWS - IAM Roles Anywhere Privesc
{{#include ../../../../banners/hacktricks-training.md}}
AWS IAM RolesAnywhere дозволяє навантаженням поза AWS приймати IAM ролі, використовуючи X.509 сертифікати. Але коли політики довіри не мають належних обмежень, їх можна зловживати для ескалації привілеїв.
Ця політика не має обмежень на те, які атрибути довірчого якоря або сертифіката дозволені. В результаті будь-який сертифікат, пов'язаний з будь-яким довірчим якорем в обліковому записі, може бути використаний для прийняття цієї ролі.
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}
```
Для підвищення привілеїв необхідний `aws_signing_helper` з https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Потім, використовуючи дійсний сертифікат, зловмисник може перейти до ролі з вищими привілеями.
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
### Посилання
- https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation/
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+50 -11
View File
@@ -6,9 +6,9 @@
### `sts:AssumeRole`
Кожна роль створюється з **політикою довіри ролі**, ця політика вказує **хто може прийняти створену роль**. Якщо роль з **того ж облікового запису** говорить, що обліковий запис може її прийняти, це означає, що обліковий запис зможе отримати доступ до ролі (і потенційно **privesc**).
Кожна роль створюється з **політикою довіри до ролі**, ця політика вказує **хто може прийняти створену роль**. Якщо роль з **того ж облікового запису** говорить, що обліковий запис може її прийняти, це означає, що обліковий запис зможе отримати доступ до ролі (і потенційно **privesc**).
Наприклад, наступна політика довіри ролі вказує, що будь-хто може її прийняти, отже, **будь-який користувач зможе privesc** до дозволів, пов'язаних з цією роллю.
Наприклад, наступна політика довіри до ролі вказує, що будь-хто може її прийняти, отже, **будь-який користувач зможе privesc** до дозволів, пов'язаних з цією роллю.
```json
{
"Version": "2012-10-17",
@@ -23,11 +23,11 @@
]
}
```
Ви можете видавати себе за роль, яка виконується:
Ви можете видати себе за роль, яка виконує:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Потенційний вплив:** Привласнення прав до ролі.
**Потенційний вплив:** Привілейоване підвищення до ролі.
> [!CAUTION]
> Зверніть увагу, що в цьому випадку дозвіл `sts:AssumeRole` потрібно **вказати в ролі для зловживання** і не в політиці, що належить атакуючому.\
@@ -35,7 +35,7 @@ aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
### **`sts:GetFederationToken`**
З цим дозволом можливо згенерувати облікові дані для імітації будь-якого користувача:
З цим дозволом можливо згенерувати облікові дані для видавання себе за будь-якого користувача:
```bash
aws sts get-federation-token --name <username>
```
@@ -55,7 +55,7 @@ aws sts get-federation-token --name <username>
```
### `sts:AssumeRoleWithSAML`
Політика довіри з цією роллю надає **користувачам, аутентифікованим через SAML, доступ до імітації ролі.**
Політика довіри з цією роллю надає **користувачам, аутентифікованим через SAML, доступ до наслідування ролі.**
Приклад політики довіри з цим дозволом:
```json
@@ -82,25 +82,64 @@ aws sts get-federation-token --name <username>
```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
```
**Потенційний вплив:** Privesc до ролі.
**Потенційний вплив:** Привласнення прав до ролі.
### `sts:AssumeRoleWithWebIdentity`
Ця дозволяє отримати набір тимчасових облікових даних безпеки для **користувачів, які були автентифіковані в мобільному, веб-додатку, EKS...** з постачальником веб-ідентифікації. [Дізнайтеся більше тут.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
Ця дозволяє отримати набір тимчасових облікових даних безпеки для **користувачів, які були автентифіковані в мобільному, веб-додатку, EKS...** з постачальником веб-ідентичності. [Дізнайтеся більше тут.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
Наприклад, якщо **обліковий запис служби EKS** повинен мати можливість **видавати себе за IAM роль**, він матиме токен у **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** і може **взяти на себе роль і отримати облікові дані**, виконавши щось на зразок:
Наприклад, якщо **обліковий запис служби EKS** повинен мати можливість **видавати себе за IAM роль**, він матиме токен у **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** і може **прийняти роль і отримати облікові дані**, виконавши щось на зразок:
```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
```
### Зловживання федерацією
### Federation Abuse
{{#ref}}
../aws-basic-information/aws-federation-abuse.md
{{#endref}}
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere дозволяє навантаженням поза AWS приймати IAM ролі, використовуючи X.509 сертифікати. Але коли політики довіри не мають належних обмежень, їх можна зловживати для ескалації привілеїв.
Ця політика не має обмежень на те, які атрибути довірчого якоря або сертифіката дозволені. В результаті будь-який сертифікат, пов'язаний з будь-яким довірчим якорем в обліковому записі, може бути використаний для прийняття цієї ролі.
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}
```
Для підвищення привілеїв, `aws_signing_helper` потрібен з https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Потім, використовуючи дійсний сертифікат, зловмисник може перейти до ролі з вищими привілеями.
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
### Посилання
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)
{{#include ../../../banners/hacktricks-training.md}}