AWS - Step Functions Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Для отримання додаткової інформації про цю службу AWS, перегляньте:
AWS - Step Functions EnumЦі техніки підвищення привілеїв вимагатимуть використання деяких ресурсів AWS Step Functions для виконання бажаних дій підвищення привілеїв.
Щоб перевірити всі можливі дії, ви можете перейти до свого облікового запису AWS, вибрати дію, яку ви хочете використовувати, і переглянути параметри, які вона використовує, як у:
Або ви також можете перейти до документації API AWS і перевірити документацію для кожної дії:
states:TestState
& iam:PassRole
Зловмисник з дозволами states:TestState
та iam:PassRole
може тестувати будь-який стан і передавати будь-яку роль IAM без створення або оновлення існуючої машини станів, що дозволяє несанкціонований доступ до інших служб AWS з дозволами ролі. У поєднанні ці дозволи можуть призвести до широкомасштабних несанкціонованих дій, від маніпуляцій з робочими процесами для зміни даних до витоків даних, маніпуляцій з ресурсами та підвищення привілеїв.
Наступні приклади показують, як протестувати стан, який створює ключ доступу для користувача admin
, використовуючи ці дозволи та дозволену роль середовища AWS. Ця дозволена роль повинна мати будь-яку політику з високими привілеями, асоційовану з нею (наприклад, arn:aws:iam::aws:policy/AdministratorAccess
), яка дозволяє стану виконувати дію iam:CreateAccessKey
:
stateDefinition.json:
Команда виконана для виконання підвищення привілеїв:
Потенційний вплив: Несанкціоноване виконання та маніпуляція робочими процесами та доступ до чутливих ресурсів, що може призвести до значних порушень безпеки.
states:CreateStateMachine
& iam:PassRole
& (states:StartExecution
| states:StartSyncExecution
)Зловмисник з states:CreateStateMachine
& iam:PassRole
зможе створити машину станів і надати їй будь-яку IAM роль, що дозволить несанкціонований доступ до інших сервісів AWS з дозволами ролі. На відміну від попередньої техніки підвищення привілеїв (states:TestState
& iam:PassRole
), ця не виконується сама по собі, вам також потрібно мати дозволи states:StartExecution
або states:StartSyncExecution
(states:StartSyncExecution
не доступна для стандартних робочих процесів, тільки для виразних машин станів) для того, щоб розпочати виконання над машиною станів.
Наступні приклади показують, як створити машину станів, яка створює ключ доступу для користувача admin
та ексфільтрує цей ключ доступу до S3 бакету, контрольованого зловмисником, використовуючи ці дозволи та поблажливу роль середовища AWS. Ця поблажлива роль повинна мати будь-яку політику з високими привілеями, пов'язану з нею (наприклад, arn:aws:iam::aws:policy/AdministratorAccess
), яка дозволяє машині станів виконувати дії iam:CreateAccessKey
та s3:putObject
.
stateMachineDefinition.json:
Команда виконана для створення машини станів:
Команда, виконана для початку виконання раніше створеної машини станів:
Контрольований атакуючим S3 бакет повинен мати дозволи на прийняття дії s3:PutObject з облікового запису жертви.
Потенційний вплив: Неавторизоване виконання та маніпуляція робочими процесами та доступ до чутливих ресурсів, що може призвести до значних порушень безпеки.
states:UpdateStateMachine
& (не завжди необхідно) iam:PassRole
Атакуючий з дозволом states:UpdateStateMachine
зможе змінити визначення машини станів, маючи можливість додати додаткові приховані стани, які можуть призвести до ескалації привілеїв. Таким чином, коли легітимний користувач запускає виконання машини станів, цей новий шкідливий прихований стан буде виконано, і ескалація привілеїв буде успішною.
Залежно від того, наскільки дозволяючим є IAM роль, пов'язана з машиною станів, атакуючий зіткнеться з 2 ситуаціями:
Дозволяюча IAM роль: Якщо IAM роль, пов'язана з машиною станів, вже є дозволяючою (наприклад, має прикріплену політику arn:aws:iam::aws:policy/AdministratorAccess
), тоді дозвіл iam:PassRole
не буде необхідний для ескалації привілеїв, оскільки не буде необхідності також оновлювати IAM роль, з визначенням машини станів буде достатньо.
Недозволяюча IAM роль: На відміну від попереднього випадку, тут атакуючий також вимагатиме дозвіл iam:PassRole
, оскільки буде необхідно асоціювати дозволяючу IAM роль з машиною станів, крім того, щоб змінити визначення машини станів.
Наступні приклади показують, як оновити легітимну машину станів, яка просто викликає функцію Lambda HelloWorld, щоб додати додатковий стан, який додає користувача unprivilegedUser
до групи IAM administrator
. Таким чином, коли легітимний користувач запускає виконання оновленої машини станів, цей новий шкідливий прихований стан буде виконано, і ескалація привілеїв буде успішною.
Якщо машина станів не має асоційованої дозволеної IAM ролі, також буде потрібен дозвіл iam:PassRole
для оновлення IAM ролі, щоб асоціювати дозволену IAM роль (наприклад, одну з прикріпленою політикою arn:aws:iam::aws:policy/AdministratorAccess
).
Команда, виконана для оновлення легітимної машини станів:
Потенційний вплив: Несанкціоноване виконання та маніпуляція робочими процесами та доступ до чутливих ресурсів, що може призвести до значних порушень безпеки.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)