Уязвимость захвата домена в Google OAuth (Truffle Security, январь 2025)

Опубликовано Truffle Security в январе 2025 года. Архитектурная предпосылка "Sign in with Google" состоит в том, что утверждение о домене (domain claim) вместе с адресом электронной почты однозначно идентифицируют пользователя. Это утверждение верно в конкретный момент времени - но ни Google, ни использующие его SaaS-приложения не отслеживают смену владельца домена во времени. Поэтому при смене владельца домена идентификационные данные незаметно переходят к новому владельцу.

Атака

1. Стартап закрывается. Его домен (deadstartup.com) попадает в открытую продажу.
2. Атакующий покупает домен примерно за $12.
3. Атакующий разворачивает Google Workspace на deadstartup.com - Workspace позволяет подтвердить права на домен через DNS-запись или HTML-файл точно так же, как это делали исходные владельцы.
4. Атакующий заново создаёт почтовые ящики сотрудников закрытого стартапа: alice@deadstartup.com, bob@deadstartup.com и так далее. (Имена часто легко найти в LinkedIn, GitHub или на старых маркетинговых страницах компании.)
5. Атакующий открывает Slack, Notion, Zoom, ChatGPT и другие сервисы и нажимает "Sign in with Google", входя как alice@deadstartup.com.
6. SaaS-сервис видит: валидное утверждение Google OAuth, совпадающий email, совпадающий домен. Сервис авторизует атакующего в аккаунте закрытой компании - со всеми историческими данными, поскольку SaaS-приложения не удаляют данные заранее, когда у компании истекает подписка на Workspace.

Архитектурная проблема в том, что ни одна из сторон не проверяет привязку идентификатора ко времени. Google выдаёт свежий OAuth claim для того адреса, который видит прямо сейчас. SaaS-приложения доверяют кортежу (email, domain) как неизменному идентификатору. Нет механизма, который сказал бы: "в 2023 году этот адрес принадлежал другому tenant'у Workspace". Поэтому, когда почту пересоздают в новом Workspace, все зависимые SaaS-сервисы считают нового владельца старым пользователем.

К чему это открывает доступ

Ко всему, куда закрытая компания входила через SSO и что не закрыла до конца. На практике это охватывает большую часть современного SaaS: workspace'ы Slack (история переписки, файлы), команды в Notion (спецификации, контракты, заметки о клиентах), Zoom (записи звонков), HR-системы, workspace'ы ChatGPT, организации в GitHub с разрешённым Google SSO, трекеры задач, CRM. Формулировка автора треда: покупки домена за $12 достаточно, чтобы получить доступ к HR-системе бывшей компании.

Масштаб уязвимости зависит от того, сколько вокруг закрытых или поглощённых стартапов с заброшенными доменами и неочищенными SaaS-аккаунтами. В треде нет количественной оценки их числа, но неявно утверждается, что их много.

Реакция Google

Именно эта часть превратила публикацию отчёта в громкую историю.

• Первичная оценка (triage): Google закрыла репорт со статусом "won't fix" и переквалифицировала проблему из бага в OAuth в категорию "fraud and abuse" (мошенничество и злоупотребления).
• Повторное открытие: Только после того, как доклад исследователей приняли на конференцию Shmoocon, а информация стала публичной.
• Итоговое вознаграждение: $1337. Мемная сумма (leet) за то, что в треде the_smart_ape названо "дефектом масштаба всей индустрии".

В треде это расценивается как тревожный сигнал шире одного конкретного бага: если доступ к HR-системе чужой компании за $12 команда OAuth изначально сочла "не нашей проблемой", то и остальные архитектурные решения этой команды имеет смысл пересмотреть с нуля.

Почему "Sign in with Google" не может исправить это в одиночку

Даже при идеальном исправлении на стороне Google фундаментальная проблема остаётся и на стороне SaaS-приложений. Они могли бы проверять преемственность tenant'а Workspace (идентификатор клиента customer ID, который Google выдаёт организации), но большинство полагающихся сторон (relying parties) смотрят только на email и claim hd (hosted domain). Исправление только силами Google - например, отказ выдавать OAuth claims для недавно подтверждённых доменов на период карантина или передача сигнала "владелец этого домена недавно сменился" - смягчило бы проблему, но не устранило бы этот класс уязвимостей полностью.

Для полного исправления нужны шаги с обеих сторон: Google должен отдавать информацию о преемственности tenant'а, а SaaS-приложения должны её проверять. Более широкая рекомендация из треда (sso-concentration-risk) - не завязывать через SSO критически важные для бизнеса или финансов аккаунты на одного IdP - остаётся защитной мерой на стороне пользователя, пока платформенное исправление не внедрено.

См. также

• smart-ape-dont-sign-in-with-google - исходный тред.
• sso-concentration-risk - почему это раскрытие уязвимости является частью более общей закономерности.
• oauth-token-theft - смежный класс атак с другим механизмом (кража токенов и consent phishing вместо передачи идентификатора).