Рассказываем об уязвимости в Google OAuth, которая позволяет атаковать аккаунты прекративших деятельность организаций через заброшенные домены.
Чуть больше года назад в посте мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга.
Недавно , что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты
При этом в Google рекомендуют сервисам ориентироваться на параметр sub, заявляя, что этот идентификатор, в отличие от адреса e-mail, уникален и постоянен для учетной записи. Однако на практике данный параметр оказывается не таким уж и постоянным. Для небольшого количества пользователей он меняется с течением времени, из-за чего аутентификация может сбоить. Поэтому сервисы предпочитают его не использовать и вместо него проверяют только домен и e-mail, вопреки рекомендациям Google.
Далее атакующий получает возможность создать произвольный почтовый ящик с данным доменом и войти с ним в один из сервисов, который с высокой вероятностью компания использовала. Некоторые из них при этом с готовностью покажут список настоящих пользователей, привязанных к рабочему пространству организации, — даже если адрес, введенный атакующим, на самом деле никогда не использовался.
Получив этот список и имея полный контроль над любыми почтовыми адресами в заброшенном домене, атакующий может воссоздать оригинальный состав Google Workspace прекратившей существование компании. Таким образом он получает возможность входить с соответствующими Google-аккаунтами в профили бывших сотрудников в тех сервисах, которые использовали Google OAuth.
Эйри приобрел один из таких заброшенных доменов и проверил осуществимость атаки на практике. Среди корпоративных сервисов, к которым ему удалось получить доступ с помощью описанной уязвимости, были Slack, Zoom, Notion, ChatGPT, а также HR-системы.
По оценке исследователя, примерно 50% стартапов используют Google Workspace. Если исходить из того, что в среднем в прекративших существование стартапах работали по десятку сотрудников, то речь может идти о сотнях тысяч людей и миллионах уязвимых аккаунтов.
Тем не менее через несколько месяцев после того, как Дилан Эйри сделал доклад об описанной атаке на хакерской конференции, заявка была снова открыта и исследователю были выплачены $1337. Заметим, что та же самая минимальная награда была назначена ему и в прошлый раз, при обнаружении атаки с использованием фантомных Google-аккаунтов.
Проблема в том, что пока этого не произошло, описанная недоработка в механизме «Входа с аккаунтом Google» остается проблемой, за которую фактически никто не отвечает. Потенциальными жертвами в случае атаки с использованием этого бана могут стать бывшие сотрудники более не существующих компаний, уже не имеющие контроля над своими учетными записями. Более того, на данном этапе предъявлять претензии и заботиться о безопасности аккаунтов уже некому.
В теории о предотвращении последствий стоит позаботиться заранее. Но, опять-таки, вряд ли многие стартапы всерьез продумывают свою будущую кончину, не говоря уже о том, что будет происходить после нее.
При всем при этом защититься от атаки через уязвимость в 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-системы.
По оценке исследователя, примерно 50% стартапов используют Google Workspace. Если исходить из того, что в среднем в прекративших существование стартапах работали по десятку сотрудников, то речь может идти о сотнях тысяч людей и миллионах уязвимых аккаунтов.
Кто виноват и что делать?
Исследователь добросовестно уведомил Google о данной уязвимости через программу баг баунти. Он также предложил долгосрочное решение вопроса с помощью создания новых идентификаторов аккаунта Google и рабочего пространства Google Workspace, действительно постоянных и уникальных. Однако через некоторое время его заявка была закрыта с пометкой «не нуждается в исправлении» и классификацией «мошенничество или злоупотребление».Тем не менее через несколько месяцев после того, как Дилан Эйри сделал доклад об описанной атаке на хакерской конференции, заявка была снова открыта и исследователю были выплачены $1337. Заметим, что та же самая минимальная награда была назначена ему и в прошлый раз, при обнаружении атаки с использованием фантомных Google-аккаунтов.
Проблема в том, что пока этого не произошло, описанная недоработка в механизме «Входа с аккаунтом Google» остается проблемой, за которую фактически никто не отвечает. Потенциальными жертвами в случае атаки с использованием этого бана могут стать бывшие сотрудники более не существующих компаний, уже не имеющие контроля над своими учетными записями. Более того, на данном этапе предъявлять претензии и заботиться о безопасности аккаунтов уже некому.
В теории о предотвращении последствий стоит позаботиться заранее. Но, опять-таки, вряд ли многие стартапы всерьез продумывают свою будущую кончину, не говоря уже о том, что будет происходить после нее.
При всем при этом защититься от атаки через уязвимость в Google OAuth достаточно просто, тут есть два не взаимоисключающих варианта:
- Используйте вместо «Входа с аккаунтом Google» старые добрые логин и пароль — и обязательно включайте двухфакторную аутентификацию.
- При прекращении деятельности компании не забрасывайте рабочие пространства в корпоративных сервисах, а удаляйте их. Тем более что это достаточно несложно сделать.
