AWS - Step Functions Privesc
Step Functions
Для отримання додаткової інформації про цю службу AWS, перегляньте:
AWS - Step Functions EnumTask Resources
Ці техніки підвищення привілеїв вимагатимуть використання деяких ресурсів AWS Step Functions для виконання бажаних дій підвищення привілеїв.
Щоб перевірити всі можливі дії, ви можете зайти у свій обліковий запис AWS, вибрати дію, яку ви хочете використовувати, і подивитися параметри, які вона використовує, як у:
Або ви також можете перейти до документації API AWS і перевірити документацію для кожної дії:
states:TestState
& iam:PassRole
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
& (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: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
).
Команда, виконана для оновлення легітимної машини станів:
Потенційний вплив: Неавторизоване виконання та маніпуляція робочими процесами та доступ до чутливих ресурсів, що може призвести до значних порушень безпеки.
Last updated