AWS - IAM Post Exploitation
Reading time: 4 minutes
tip
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримка HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.
IAM
Для отримання додаткової інформації про доступ до IAM:
AWS - IAM, Identity Center & SSO Enum
Проблема заплутаного заступника
Якщо ви дозволяєте зовнішньому обліковому запису (A) отримати доступ до ролі у вашому обліковому записі, ви, ймовірно, матимете 0 видимості щодо того, хто точно може отримати доступ до цього зовнішнього облікового запису. Це проблема, оскільки якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), можливо, що B також зможе отримати доступ до вашого облікового запису.
Отже, коли ви дозволяєте зовнішньому обліковому запису отримати доступ до ролі у вашому обліковому записі, можливо, ви зможете вказати ExternalId
. Це "секретний" рядок, який зовнішній обліковий запис (A) повинен вказати, щоб прийняти роль у вашій організації. Оскільки зовнішній обліковий запис B не знає цей рядок, навіть якщо він має доступ до A, він не зможе отримати доступ до вашої ролі.
.png)
Однак зверніть увагу, що цей ExternalId
"секрет" не є секретом, будь-хто, хто може читати політику прийняття ролі IAM, зможе його побачити. Але поки зовнішній обліковий запис A знає його, а зовнішній обліковий запис B не знає його, це запобігає зловживанню B для доступу до вашої ролі через A.
Приклад:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}
warning
Щоб зловмисник міг експлуатувати заплутаного заступника, йому потрібно буде якимось чином з'ясувати, чи можуть принципали поточного облікового запису видавати себе за ролі в інших облікових записах.
Несподівані довіри
Символи підстановки як принципал
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}
Ця політика дозволяє всім AWS приймати роль.
Служба як основний
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
Ця політика дозволяє будь-якому обліковому запису налаштувати свій apigateway для виклику цього Lambda.
S3 як принципал
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
Якщо S3 бакет вказаний як принципал, оскільки S3 бакети не мають ідентифікатора облікового запису, якщо ви видалили свій бакет, а зловмисник створив його у своєму обліковому записі, то вони могли б це зловживати.
Не підтримується
{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
Звичайний спосіб уникнути проблем з Confused Deputy - це використання умови з AWS:SourceArn
для перевірки вихідного ARN. Однак, деякі сервіси можуть цього не підтримувати (наприклад, CloudTrail згідно з деякими джерелами).
References
tip
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримка HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.