Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This post is the introduction of https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover which can be accessed for more details.
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, або зовнішньому додатку з Google Workspace Marketplace, або внутрішньому GCP Service Account, отримувати доступ до даних у Workspace від імені користувачів. Ця функція, яка є критично важливою для додатків, що взаємодіють з Google APIs або сервісами, які потребують імперсонації користувача, підвищує ефективність і мінімізує людські помилки шляхом автоматизації завдань. Використовуючи OAuth 2.0, розробники додатків і адміністратори можуть надати цим обліковим записам доступ до даних користувачів без індивідуальної згоди користувачів. Google Workspace дозволяє створення двох основних типів глобальних делегованих об'єктів ідентичності:
GWS Applications: Додатки з Marketplace Workspace можуть бути налаштовані як делегована ідентичність. Перед тим, як стати доступними в маркетплейсі, кожен додаток Workspace проходить перевірку Google для мінімізації потенційного зловживання. Хоча це не усуває ризик зловживання, це значно ускладнює можливість таких інцидентів.
GCP Service Account: Learn more about GCP Service Accounts here.
Ось як GCP Service Account може отримати доступ до Google APIs від імені інших ідентичностей у Google Workspace:
Ідентичність створює JWT: Ідентичність використовує приватний ключ облікового запису служби (частина файлу пари ключів JSON) для підписання JWT. Цей JWT містить заяви про обліковий запис служби, цільового користувача для імперсонації та OAuth області доступу до REST API, до якого запитується доступ.
Ідентичність використовує JWT для запиту токена доступу: Додаток/користувач використовує JWT для запиту токена доступу від сервісу OAuth 2.0 Google. Запит також включає цільового користувача для імперсонації (електронна пошта користувача Workspace) та області, для яких запитується доступ.
Сервіс OAuth 2.0 Google повертає токен доступу: Токен доступу представляє авторитет облікового запису служби діяти від імені користувача для зазначених областей. Цей токен зазвичай має короткий термін дії і повинен періодично оновлюватися (згідно з потребами додатка). Важливо розуміти, що області OAuth, зазначені в токені JWT, мають дійсність і впливають на результуючий токен доступу. Наприклад, токени доступу, що мають кілька областей, будуть дійсними для численних REST API додатків.
Ідентичність використовує токен доступу для виклику Google APIs: Тепер з відповідним токеном доступу служба може отримати доступ до необхідного REST API. Додаток використовує цей токен доступу в заголовку "Authorization" своїх HTTP запитів, призначених для Google APIs. Ці API використовують токен для перевірки імперсованої ідентичності та підтвердження, що вона має необхідну авторизацію.
Google APIs повертають запитувані дані: Якщо токен доступу дійсний і обліковий запис служби має відповідну авторизацію, Google APIs повертають запитувані дані. Наприклад, на наступному зображенні ми використали метод users.messages.list для переліку всіх ідентифікаторів повідомлень Gmail, пов'язаних з цільовим користувачем Workspace.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
