Атака на Google OAuth через заброшенные домены

Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.

Как работает аутентификация при использовании «Вход с аккаунтом Google»

Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.

Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.

Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:

В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник

При этом в Google рекомендуют сервисам ориентироваться на параметр sub, заявляя, что этот идентификатор, в отличие от адреса e-mail, уникален и постоянен для учетной записи. Однако на практике данный параметр оказывается не таким уж и постоянным. Для небольшого количества пользователей он меняется с течением времени, из-за чего аутентификация может сбоить. Поэтому сервисы предпочитают его не использовать и вместо него проверяют только домен и e-mail, вопреки рекомендациям Google.

«Вход с аккаунтом Google» через заброшенный домен

В результате возникает ситуация, в которой атакующий может получить несанкционированный доступ к принадлежащим компании сервисам, имея доступ всего лишь к почте в домене организации. Особенно легко это сделать в случае прекратившей свою деятельность компании, домен которой оказался заброшен — любой желающий может зарегистрировать его на себя.

Далее атакующий получает возможность создать произвольный почтовый ящик с данным доменом и войти с ним в один из сервисов, который с высокой вероятностью компания использовала. Некоторые из них при этом с готовностью покажут список настоящих пользователей, привязанных к рабочему пространству организации, — даже если адрес, введенный атакующим, на самом деле никогда не использовался.

Получив этот список и имея полный контроль над любыми почтовыми адресами в заброшенном домене, атакующий может воссоздать оригинальный состав Google Workspace прекратившей существование компании. Таким образом он получает возможность входить с соответствующими Google-аккаунтами в профили бывших сотрудников в тех сервисах, которые использовали Google OAuth.

Насколько масштабна данная проблема?

Дилан Эйри, обнаруживший данную уязвимость в Google OAuth (он же нашел и предыдущую, с фантомными аккаунтами), постарался продемонстрировать серьезность потенциальных последствий. Используя информацию Crunchbase, Эйри создал список из более 100 000 закрывшихся стартапов, чьи домены выставлены на продажу.

Эйри приобрел один из таких заброшенных доменов и проверил осуществимость атаки на практике. Среди корпоративных сервисов, к которым ему удалось получить доступ с помощью описанной уязвимости, были Slack, Zoom, Notion, ChatGPT, а также HR-системы.

Получается, что в результате несложной и не требующей сколько-нибудь серьезных ресурсов атаки в руках злоумышленника может оказаться масса конфиденциальной информации, от переписки и заметок сотрудников до персональных данных из HR-сервисов.

По оценке исследователя, примерно 50% стартапов используют Google Workspace. Если исходить из того, что в среднем в прекративших существование стартапах работали по десятку сотрудников, то речь может идти о сотнях тысяч людей и миллионах уязвимых аккаунтов.

Кто виноват и что делать?

Исследователь добросовестно уведомил Google о данной уязвимости через программу баг баунти. Он также предложил долгосрочное решение вопроса с помощью создания новых идентификаторов аккаунта Google и рабочего пространства Google Workspace, действительно постоянных и уникальных. Однако через некоторое время его заявка была закрыта с пометкой «не нуждается в исправлении» и классификацией «мошенничество или злоупотребление».

Тем не менее через несколько месяцев после того, как Дилан Эйри сделал доклад об описанной атаке на хакерской конференции, заявка была снова открыта и исследователю были выплачены $1337. Заметим, что та же самая минимальная награда была назначена ему и в прошлый раз, при обнаружении атаки с использованием фантомных Google-аккаунтов.

По словам исследователя, в Google пообещали когда-нибудь устранить обнаруженную им уязвимость в Google OAuth, правда, не уточнили, как именно они собираются это сделать.

Проблема в том, что пока этого не произошло, описанная недоработка в механизме «Входа с аккаунтом Google» остается проблемой, за которую фактически никто не отвечает. Потенциальными жертвами в случае атаки с использованием этого бана могут стать бывшие сотрудники более не существующих компаний, уже не имеющие контроля над своими учетными записями. Более того, на данном этапе предъявлять претензии и заботиться о безопасности аккаунтов уже некому.

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

При всем при этом защититься от атаки через уязвимость в Google OAuth достаточно просто, тут есть два не взаимоисключающих варианта:

• Используйте вместо «Входа с аккаунтом Google» старые добрые логин и пароль — и обязательно включайте двухфакторную аутентификацию.
• При прекращении деятельности компании не забрасывайте рабочие пространства в корпоративных сервисах, а удаляйте их. Тем более что это достаточно несложно сделать — вот, к примеру, инструкции для Slack и Notion.