Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, або зовнішньому додатку з Google Workspace Marketplace, або внутрішньому обліковому запису служби GCP, отримувати доступ до даних у Workspace від імені користувачів.
Це в основному означає, що облікові записи служби всередині проектів GCP організації можуть мати можливість видавати себе за користувачів Workspace тієї ж організації (або навіть з іншої).
Для отримання додаткової інформації про те, як це працює, перегляньте:
Якщо зловмисник компрометував доступ до GCP і знає дійсну електронну адресу користувача Workspace (бажано супер адміністратора) компанії, він міг би перерахувати всі проекти, до яких має доступ, перерахувати всі облікові записи служби проектів, перевірити, до яких облікових записів служби має доступ, і повторити всі ці кроки з кожним обліковим записом служби, за яким він може видавати себе. З переліком всіх облікових записів служби, до яких він має доступ, і списком електронних адрес Workspace, зловмисник міг би спробувати видавати себе за користувача з кожним обліковим записом служби.
Зверніть увагу, що при налаштуванні делегування на рівні домену жоден користувач Workspace не потрібен, тому просто знати одного дійсного достатньо і необхідно для видавання себе. Однак, привілеї виданого користувача будуть використані, тому якщо це супер адміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
Цей простий скрипт згенерує токен OAuth як делегований користувач, який ви можете використовувати для доступу до інших Google API з gcloud або без нього:
Це інструмент, який може виконати атаку, слідуючи цим крокам:
Перерахувати GCP проекти за допомогою API Resource Manager.
Ітерація по кожному ресурсу проекту та перерахування ресурсів облікових записів сервісу GCP, до яких має доступ початковий IAM користувач, використовуючи GetIAMPolicy.
Ітерація по кожній ролі облікового запису сервісу та знаходження вбудованих, базових і кастомних ролей з дозволом serviceAccountKeys.create на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль редактора за замовчуванням має цей дозвіл.
Створення нового KEY_ALG_RSA_2048 приватного ключа для кожного ресурсу облікового запису сервісу, який знайдено з відповідним дозволом у політиці IAM.
Ітерація по кожному новому обліковому запису сервісу та створення об'єкта JWT для нього, який складається з облікових даних приватного ключа SA та області OAuth. Процес створення нового об'єкта JWT буде ітерацією по всім існуючим комбінаціям областей OAuth з списку oauth_scopes.txt, щоб знайти всі можливості делегування. Список oauth_scopes.txt оновлюється всіма областями OAuth, які ми вважаємо релевантними для зловживання ідентичностями Workspace.
Метод _make_authorization_grant_assertion вказує на необхідність оголосити цільового користувача робочого простору, відомого як subject, для генерації JWT під DWD. Хоча це може здаватися, що вимагає конкретного користувача, важливо усвідомити, що DWD впливає на кожну ідентичність у домені. Відповідно, створення JWT для будь-якого користувача домену впливає на всі ідентичності в цьому домені, відповідно до нашої перевірки комбінацій. Простими словами, одного дійсного користувача Workspace достатньо для продовження.
Цей користувач може бути визначений у файлі config.yaml DeleFriend. Якщо цільовий користувач робочого простору ще не відомий, інструмент полегшує автоматичну ідентифікацію дійсних користувачів робочого простору, скануючи користувачів домену з ролями на GCP проектах. Важливо зазначити (знову), що JWT є специфічними для домену і не генеруються для кожного користувача; отже, автоматичний процес націлений на одну унікальну ідентичність на домен.
Перерахувати та створити новий токен доступу для кожного JWT та перевірити токен за допомогою API tokeninfo.
Gitlab створив цей скрипт Python, який може виконати дві речі - перерахувати каталог користувачів та створити новий адміністративний обліковий запис, вказуючи json з обліковими даними SA та користувачем, якого потрібно наслідувати. Ось як ви можете його використовувати:
Можна перевірити делегації на рівні домену в https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Зловмисник, який має можливість створювати облікові записи служби в проекті GCP та привілеї супер адміністратора в GWS, може створити нову делегацію, що дозволяє СА наслідувати деяких користувачів GWS:
Генерація нового облікового запису служби та відповідної пари ключів: У GCP нові ресурси облікових записів служби можуть бути створені або інтерактивно через консоль, або програмно за допомогою прямих API викликів та CLI інструментів. Це вимагає ролі iam.serviceAccountAdmin або будь-якої кастомної ролі, оснащеної дозволом iam.serviceAccounts.create. Після створення облікового запису служби ми перейдемо до генерації пов'язаної пари ключів (дозвіл iam.serviceAccountKeys.create).
Створення нової делегації: Важливо розуміти, що тільки роль супер адміністратора має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace і делегацію на рівні домену не можна налаштувати програмно, її можна створити та налаштувати вручну через консоль Google Workspace.
Створення правила можна знайти на сторінці API controls → Manage Domain-Wide delegation in Google Workspace Admin console.
Прикріплення привілеїв OAuth scopes: При налаштуванні нової делегації Google вимагає лише 2 параметри: ідентифікатор клієнта, який є OAuth ID ресурсу облікового запису служби GCP, та OAuth scopes, які визначають, які API виклики потрібні для делегації.
Повний список OAuth scopes можна знайти тут, але ось рекомендація: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Дії від імені цільової особи: На цьому етапі у нас є функціонуючий делегований об'єкт у GWS. Тепер, використовуючи приватний ключ облікового запису служби GCP, ми можемо виконувати API виклики (в межах, визначених у параметрі OAuth scope), щоб активувати його та діяти від імені будь-якої особи, яка існує в Google Workspace. Як ми дізналися, обліковий запис служби генеруватиме токени доступу відповідно до своїх потреб і згідно з дозволами, які він має для REST API додатків.
Перевірте попередній розділ для деяких інструментів для використання цієї делегації.
OAuth SA ID є глобальним і може бути використаний для крос-організаційної делегації. Не було впроваджено жодних обмежень, щоб запобігти крос-глобальній делегації. Простими словами, облікові записи служби з різних організацій GCP можуть бути використані для налаштування делегації на рівні домену в інших організаціях Workspace. Це призведе до необхідності лише доступу супер адміністратора до Workspace, а не доступу до того ж облікового запису GCP, оскільки противник може створювати облікові записи служби та приватні ключі на своєму особисто контрольованому обліковому записі GCP.
За замовчуванням користувачі Workspace мають дозвіл на створення нових проектів, і коли новий проект створюється, творець отримує роль власника.
Отже, користувач може створити проект, увімкнути API для перерахунку Workspace у своєму новому проекті та спробувати перерахувати його.
Щоб користувач міг перерахувати Workspace, йому також потрібні достатні дозволи Workspace (не кожен користувач зможе перерахувати каталог).
Перевірте більше перерахування в:
Ви можете знайти додаткову інформацію про потік gcloud для входу в:
Як пояснено там, gcloud може запитувати область https://www.googleapis.com/auth/drive, що дозволить користувачу отримати доступ до диска користувача.
Як зловмисник, якщо ви фізично скомпрометували комп'ютер користувача і користувач все ще увійшов зі своїм обліковим записом, ви могли б увійти, згенерувавши токен з доступом до диска, використовуючи:
Якщо зловмисник отримує доступ до комп'ютера користувача, він також може змінити файл google-cloud-sdk/lib/googlecloudsdk/core/config.py і додати в CLOUDSDK_SCOPES область 'https://www.googleapis.com/auth/drive':
Отже, наступного разу, коли користувач увійде в систему, він створить токен з доступом до drive, який зловмисник може зловживати для доступу до drive. Очевидно, браузер вказуватиме, що згенерований токен матиме доступ до drive, але оскільки користувач сам викликатиме gcloud auth login, він, ймовірно, не запідозрить нічого.
Щоб перерахувати файли на drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Якщо зловмисник має повний доступ до GWS, він зможе отримати доступ до груп з привілейованим доступом до GCP або навіть до користувачів, тому перехід від GWS до GCP зазвичай є більш "простим" лише тому, що користувачі в GWS мають високі привілеї над GCP.
За замовчуванням користувачі можуть вільно приєднуватися до груп Workspace Організації і ці групи можуть мати призначені дозволи GCP (перевірте свої групи на https://groups.google.com/).
Зловживаючи google groups privesc, ви можете мати можливість підвищити привілеї до групи з якимось видом привілейованого доступу до GCP.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
