Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ця техніка більше не працює, оскільки, якщо роль існує чи ні, ви завжди отримуєте цю помилку:
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas
Ви можете перевірити це, запустивши:
aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example
Спроба взяти на себе роль без необхідних дозволів викликає повідомлення про помилку AWS. Наприклад, якщо немає авторизації, AWS може повернути:
Це повідомлення підтверджує існування ролі, але вказує на те, що її політика прийняття ролі не дозволяє вам її прийняти. На відміну від цього, спроба прийняти неіснуючу роль призводить до іншої помилки:
Цікаво, що цей метод розрізнення між існуючими та неіснуючими ролями застосовується навіть між різними обліковими записами AWS. З дійсним ідентифікатором облікового запису AWS та цільовим словником можна перерахувати ролі, присутні в обліковому записі, не стикаючись з жодними вродженими обмеженнями.
Ви можете використовувати цей скрипт для перерахунку потенційних принципалів, зловживаючи цією проблемою.
Налаштування або оновлення політики довіри IAM ролі передбачає визначення, які ресурси або сервіси AWS можуть приймати цю роль та отримувати тимчасові облікові дані. Якщо вказаний ресурс у політиці існує, політика довіри зберігається успішно. Однак, якщо ресурс не існує, генерується помилка, що вказує на те, що було надано недійсний принципал.
Зверніть увагу, що в цьому ресурсі ви можете вказати крос-облікову роль або користувача:
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
Це приклад політики:
Це помилка, яку ви знайдете, якщо використовуєте роль, яка не існує. Якщо роль існує, політика буде збережена без жодних помилок. (Помилка стосується оновлення, але також працює при створенні)
Ви можете автоматизувати цей процес за допомогою https://github.com/carlospolop/aws_tools
bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt
Наше використання Pacu:
run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
Роль admin, використана в прикладі, є роллю у вашому обліковому записі, яка може бути використана pacu для створення політик, які йому потрібні для перерахунку
У випадку, якщо роль була неправильно налаштована і дозволяє будь-кому її приймати:
Атакуючий міг би просто припустити це.
Уявіть, що вам вдалося прочитати Github Actions workflow, який отримує доступ до ролі всередині AWS. Ця довіра може надати доступ до ролі з наступною політикою довіри:
Ця політика довіри може бути правильною, але відсутність більше умов повинна викликати у вас недовіру. Це пов'язано з тим, що попередню роль може бути прийнято КОЖНИМ з Github Actions! Ви повинні вказати в умовах також інші речі, такі як назва організації, назва репозиторію, середовище, гілка...
Ще однією потенційною помилкою конфігурації є додавання умови на зразок наступної:
Зверніть увагу на додаток (*) перед двоеточієм (:). Ви можете створити організацію, таку як org_name1, і прийняти роль з Github Action.
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
