Сервисы и организации порой полагаются на Google в вопросе аутентификации пользователей, используя Google OAuth. Как правило, они считают, что Google могуч и мудр, так что на его суждения относительно того, стоит ли давать пользователю доступ или нет можно полагаться.
Увы, это не совсем так: у опции «Вход с аккаунтом Google» есть серьезные проблемы. В декабре 2023 года исследователь Дилан Эйри из команды Truffle Security обнаружил в Google OAuth достаточно неприятную уязвимость, которая позволяет сотрудникам организации после увольнения сохранять доступ к корпоративным ресурсам. А в некоторых случаях эксплуатация этого бага вообще может приводить к получению доступа человеком со стороны.
В чем проблема входа с Google OAuth
У данной уязвимости есть несколько предпосылок. Первая — Google позволяет создавать Google-аккаунты с использованием любой почты, не только Gmail. В частности, для входа в корпоративный Google Workspace как раз обычно используются почтовые адреса с доменом организации. В качестве примера возьмем сотрудника организации Example с почтовым адресом alanna@example.com.
Аутентификация через Google OAuth используется многими рабочими сервисами во многих организациях. Вот, например, кнопка «Вход с аккаунтом Google» на slack.slack.com
Вторая предпосылка — Google (вместе с некоторым количеством других онлайн-сервисов) поддерживает так называемую субадресацию (sub-addressing). Данная система позволяет создавать вспомогательные адреса, добавляя что угодно к имеющемуся адресу почты после знака +. По задумке это может быть полезно для управления потоками почты.
Например, при регистрации аккаунта в онлайн-банке можно указать адрес alanna+bank@example.com, а при регистрации у провайдера связи alanna+telco@example.com. Формально это разные адреса, но письма будут приходить в один и тот же ящик alanna@example.com. А благодаря неодинаковому содержимому поля «Кому» можно по-разному обрабатывать входящие письма, создавая те или иные правила.
Пример логина в Slack через кнопку «Вход с аккаунтом Google» с использованием вспомогательного адреса почты с «плюсиком»
Третья предпосылка — авторизация во многих рабочих сервисах, таких как Zoom и Slack, с помощью кнопки «Вход с аккаунтом Google» происходит на основе домена в почтовом адресе, указанном при регистрации Google-аккаунта. То есть в нашем примере для входа в рабочий чат корпорации Example — example.slack.com — нужен адрес почты @example.com.
Наконец, четвертая предпосылка: адрес почты в имеющемся Google-аккаунте можно отредактировать. При этом можно использовать субадреса, изменив, например alanna@example.com на alanna+whatever@example.com. После этого можно заново зарегистрировать новый Google-аккаунт на адрес alanna@example.com.
Таким образом появляется два разных Google-аккаунта, которые могут быть использованы для входа в рабочие сервисы вроде Slack и Zoom компании Example с помощью Google OAuth. Проблема в том, что для администратора корпоративного Google Workspace второй адрес остается невидимым — поэтому администратор не может ни удалить его, ни отключить этот аккаунт. Таким образом, у уволенного сотрудника может оставаться доступ к корпоративным ресурсам.
Эксплуатация уязвимости в Google OAuth и доступ без доступа
Насколько это все осуществимо на практике? Вполне. Дилан Эйри проверил возможность эксплуатации уязвимости в Google OAuth на Slack и Zoom своей компании и убедился в том, что действительно можно создавать такие фантомные аккаунты. Причем воспользоваться уязвимостью может обычный пользователь — для этого не требуется никаких серьезных технических знаний или навыков.
Пример эксплуатации уязвимости в Google OAuth в результате которой получен доступ к Slack с аккаунта, зарегистрированного на субадрес почты. Источник
Следует заметить, что помимо упомянутых выше Slack и Zoom эта уязвимость также касается десятков менее известных корпоративных инструментов, которые используют аутентификацию через Google OAuth.
Кроме того, в некоторых случаях доступ к облачным инструментам организации может быть получен даже в том случае, если у атакующего не было изначального доступа к корпоративной почте атакуемой компании. Для этого, например, может использоваться сервис работы с заявками в поддержку Zendesk.
Идея тут в том, что сервис позволяет подавать заявки через e-mail. В том числе при этом для заявки создается почтовый адрес с доменом компании, а создатель заявки (то есть любой желающий) имеет возможность просматривать содержимое всей переписки по этой заявке. Получается, что на такой адрес можно зарегистрировать Google-аккаунт, получить через заявку письмо со ссылкой для подтверждения. И потом успешно проэксплуатировать уязвимость в Google OAuth для входа в те же Zoom или Slack атакуемой компании, не имея изначального доступа к ее ресурсам.
Как защититься от уязвимости в Google OAuth
Исследователь несколько месяцев назад уведомил Google об уязвимости через программу баг-баунти, компания признала ее проблемой (правда, с невысокими приоритетом и степенью опасности) и даже выплатила в качестве награды $1337. Также Дилан Эйри сообщил о проблеме некоторым онлайн-сервисам, включая Slack.
Однако исправлять эту уязвимость не торопятся, поэтому защита от нее, по всей видимости, ложится на плечи сотрудников компаний, которые администрируют рабочие сервисы. Собственно, в большинстве случаев это достаточно несложно сделать: для этого необходимо отключить опцию входа с аккаунтом Google.
Также, конечно же, полезно защищаться от возможного проникновения через сервисы вроде Slack глубже в информационную инфраструктуру организации. А для этого полезно следить за тем, что же в этой инфраструктуре происходит. Если внутренних ресурсов или экспертизы отдела информационной безопасности компании для этого недостаточно, можно воспользоваться внешним сервисом, таким как Kaspersky Managed Detection and Response.