GCP - Understanding Domain-Wide Delegation

Вивчайте хакінг AWS від нуля до героя з htARTE (Експерт з червоної команди HackTricks AWS)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити вашу компанію в рекламі HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДПИСКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за мною на Twitter 🐦 @carlospolopm.

• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв.

Цей пост є вступом до https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover, до якого можна отримати доступ для отримання додаткових відомостей.

Розуміння делегування на рівні домену

Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, будь то зовнішній додаток з Google Workspace Marketplace або внутрішній Службовий обліковий запис GCP, отримувати доступ до даних по всьому робочому простору від імені користувачів. Ця функція, яка є важливою для додатків, що взаємодіють з API Google або потребують імітації користувача, підвищує ефективність та мінімізує людські помилки, автоматизуючи завдання. Використовуючи OAuth 2.0, розробники додатків та адміністратори можуть надавати цим службовим обліковим записам доступ до даних користувачів без окремої згоди користувача. Google Workspace дозволяє створювати два основних типи глобальних делегованих об'єктів ідентичності:

• Додатки GWS: Додатки з Marketplace Workspace можуть бути налаштовані як делегована ідентичність. Перш ніж стати доступними на ринку, кожен додаток Workspace проходить перегляд Google для мінімізації можливого зловживання. Хоча це не повністю усуває ризик зловживання, це значно ускладнює можливість виникнення таких випадків.

• Службовий обліковий запис GCP: Дізнайтеся більше про Службові облікові записи GCP тут.

Делегування на рівні домену: Під капотом

Ось як Службовий обліковий запис GCP може отримати доступ до API Google від імені інших ідентичностей в Google Workspace:

1. Ідентичність створює JWT: Ідентичність використовує приватний ключ службового облікового запису (частина файлу пари ключів JSON) для підпису JWT. Цей JWT містить вимоги щодо службового облікового запису, цільового користувача для імітації та областей OAuth для доступу до REST API, яке запитується.

2. Ідентичність використовує JWT для запиту токена доступу: Додаток/користувач використовує JWT для запиту токена доступу від служби OAuth 2.0 Google. Запит також включає цільового користувача для імітації (електронна пошта користувача Workspace) та області, для яких запитується доступ.

3. Служба OAuth 2.0 Google повертає токен доступу: Токен доступу представляє повноваження службового облікового запису діяти від імені користувача для вказаних областей. Цей токен зазвичай має обмежений термін дії і повинен періодично оновлюватися (згідно потреб додатка). Важливо розуміти, що області OAuth, вказані в токені JWT, мають валідність та вплив на отриманий токен доступу. Наприклад, токени доступу з декількома областями будуть мати валідність для численних застосунків REST API.

4. Ідентичність використовує токен доступу для виклику API Google: Тепер з відповідним токеном доступу служба може отримати доступ до необхідного REST API. Додаток використовує цей токен доступу в заголовку "Authorization" своїх HTTP-запитів, призначених для API Google. Ці API використовують токен для перевірки імітованої ідентичності та підтвердження наявності необхідного дозволу.

5. API Google повертають запитані дані: Якщо токен доступу є дійсним, а службовий обліковий запис має відповідний дозвіл, API Google повертають запитані дані. Наприклад, на наступному зображенні ми використали метод users.messages.list для переліку всіх ідентифікаторів повідомлень Gmail, пов'язаних з користувачем робочого простору.