Предварительный захват аккаунта

Предварительный захват аккаунта как класс уязвимостей был впервые выделен в 2022 году на основе исследования, финансированного Центром реагирования на инциденты в области безопасности Microsoft^[5].

Как поясняют авторы исследования, впервые описавшего феномен предварительного захвата: «Многие сервисы требуют идентификации пользователя, однако эта верификация часто носит асинхронный характер, что позволяет пользователям (или атакующим) изменить параметры учётной записи до завершения проверки личности. Это улучшает удобство пользования, но одновременно открывает уязвимость предзахвата аккаунта^[1]».

В ходе исследования было протестировано 75 популярных сервисов, включая облачные хранилища, социальные и профессиональные сети, платформы для блогов и сервисы видеоконференций. Из них уязвимыми оказались как минимум 35 (около 46,7 %)^[6][7].

Например, злоумышленник может создать аккаунт на сайте, используя электронную почту жертвы. Если позже жертва решает зарегистрироваться на том же сайте, но через систему единой идентификации (например, через сторонний сервис аутентификации), а сайт некорректно обрабатывает дублирующие записи, и злоумышленник, и жертва получают доступ к одной и той же учётной записи. Возможен и обратный сценарий — когда злоумышленник предварительно регистрируется через систему единой идентификации, а жертва — по адресу электронной почты. При этом злоумышленник может добавить в заранее созданный аккаунт дополнительный email или номер телефона, которые затем можно использовать для сброса пароля, когда аккаунт будет активен после регистрации жертвы. Этот метод также позволяет атакующему активировать cookies доступа к «запасённому» аккаунту^[6][8][1].

В 2022 году исследователи выделили пять основных типов атак предварительного захвата аккаунта:^[6][8]

• Classic-Federated Merge Attack — атакующий создаёт аккаунт классическим способом (с паролем), используя email жертвы. Когда жертва позже регистрируется через федеративный вход (например, SSO) с тем же email, сервис небезопасно объединяет учётные записи, предоставляя доступ к аккаунту им обоим^[6].^[8]
• Unexpired Session Identifier Attack (или Unexpired Session Attack) — атакующий создаёт аккаунт на email жертвы и поддерживает длительную активную сессию. Когда жертва восстанавливает доступ путём сброса пароля, сессия атакующего не аннулируется, и он сохраняет контроль над аккаунтом^[6].^[8][9]
• Trojan Identifier Attack — атакующий создаёт аккаунт на email жертвы и привязывает к нему дополнительный «троянский» идентификатор (скрытый вторичный email, номер телефона или федеративный аккаунт). После сброса пароля жертвой атакующий использует этот скрытый идентификатор для возврата доступа к учётной записи^[6].^[8][9]
• Unexpired Email Change Attack — атакующий создаёт аккаунт на email жертвы и запрашивает смену адреса на свой, получая ссылку для подтверждения, но не переходит по ней. Дождавшись, когда жертва восстановит аккаунт и начнёт им пользоваться, атакующий активирует ссылку, завершает смену email и перехватывает аккаунт^[6].^[8]
• Non-verifying IdP Attack — атакующий использует провайдера аутентификации (IdP), не проверяющего владение email, для создания аккаунта на адрес жертвы. Из-за отсутствия проверки email провайдером и слепого доверия целевого сервиса, когда жертва регистрируется классическим способом, происходит слияние аккаунтов, и атакующий получает доступ к учётной записи жертвы^[8].^[10]

Согласно исследованию, из 75 проверенных крупных интернет-сервисов уязвимыми оказались 35 разных платформ, причём уязвимость проявляется разными способами. Уязвимые сервисы включают, в частности, Dropbox, Instagram, LinkedIn, WordPress и Zoom^[11]. О наличии уязвимости все эти провайдеры были предупреждены до публикации научной статьи^[12].

По данным на 2022 год, Dropbox, Zoom и LinkedIn (изменивший логику инвалидации активных сессий после смены пароля) исправили выявленные уязвимости^[8]. В то же время платформа WordPress.com отклонила отчёт об уязвимости, при этом её self-hosted версия изначально не была уязвима^[8].

Для защиты от предварительного захвата аккаунта разработчикам рекомендуется применять ряд мер, разработанных компанией Microsoft^[13]:

• Обязательная верификация идентификаторов^[13].
• Безопасное слияние аккаунтов (с запросом пароля от классической учётной записи при попытке объединения с федеративной)^[13].
• Принудительное завершение всех сессий при сбросе пароля (включая аннулирование токенов и отмену ожидающих запросов на смену адреса электронной почты)^[13].
• Управление сменой email (ограничение срока действия ссылок или кодов подтверждения и количества запросов на их получение)^[13].

Отдельно выделяется необходимость синхронной верификации. При таком подходе до полного подтверждения владения почтой должны быть заблокированы любые дальнейшие действия пользователя и использование любых функций аккаунта^[14][15].