Предварительный захват аккаунта путем отмены слабого алгоритма токена подтверждения электронной почты

Я подделал доступ к электронной почте других людей, чтобы предварительно украсть учетные записи пользователей до их первой регистрации. Вот как я это сделал.

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

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

Анализ алгоритма генерации токена

Первое, что я тестирую при атаке любого веб-приложения с помощью программы bug bounty, - это создание учетной записи и функция аутентификации. В этом случае я обнаружил, что каждый раз, когда я создавал новую учетную запись пользователя, приложение не позволяло мне ничего делать, пока я не подтвердил право собственности на свой адрес электронной почты. Целевое приложение отправит мне ссылку для подтверждения по электронной почте и предложит проверить мой почтовый ящик, и это было все, что я мог

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

Поглощение до учетной записи

Современные веб-приложения часто имеют несколько способов входа в учетную запись пользователя. Они могут включать:

Имя пользователя и пароль
Адрес электронной почты и пароль
Oauth, например «Войти через Facebook» или «Войти через Twitter».
Система единого входа SAML от любого SAML-совместимого поставщика идентификационной информации (IdP)
Без пароля с использованием токенизированных «магических» ссылок

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

Приступ происходит следующим образом:

Злоумышленник создает учетную запись пользователя в веб-приложении, используя адрес электронной почты, которым он не владеет.
Приложение не проверяет, являются ли они владельцем адреса электронной почты.
Учетная запись неактивна в течение определенного периода времени.
Настоящий владелец адреса электронной почты выбирает «войти через Facebook», и Facebook предоставляет пользователям проверенные адреса электронной почты.
Адрес электронной почты Facebook совпадает с адресом электронной почты, с которым зарегистрировался злоумышленник, и две учетные записи связаны.
Теперь злоумышленник может войти в учетную запись жертвы с предоставленным им адресом электронной почты и паролем, и он может видеть все, что жертва делает в своей учетной записи каждый раз, когда она входит в систему через Facebook.

Проверка токена электронной почты Recon

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

Ссылка имела формат https://craighays.com/verify/?P1=randomString & P2 = randomString & P3 = staticText & P4 = staticText (без пробелов).

После создания нескольких проверочных писем для разных учетных записей я увидел, что P3 и P4 всегда были одним и тем же. Однако P1 и P2 всегда менялись каждый раз при отправке электронного письма. Открытие ссылки после удаления или изменения P1 или P2 привело к появлению сообщения об ошибке, а адрес электронной почты не был проверен. Таким образом, комбинация P1 и P2 вместе формирует двухчастный токен подтверждения владения адресом электронной почты.

Копать глубже

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

И P1, и P2 были строками в кодировке base64. Легкий способ определить это, когда случайная строка заканчивается одинарным = или двойным ==. Эти символы = используются в качестве заполнения, чтобы гарантировать, что предварительно закодированная строка соответствует минимальной длине бит. Это не всегда так, поскольку строка идеальной длины не нуждается в заполнении. Если есть сомнения, всегда пропускайте случайные строки через разные декодеры, чтобы посмотреть, не получится ли что-нибудь интересное.

После декодирования нескольких параметров P1 и P2 из разных ссылок я мог видеть, что P1 всегда имел формат из четырех статических символов, за которыми следовали 12 числовых символов, таких как TEXT000123456789, а P2 всегда имел формат из 9 числовых символов, таких как 123456789. Просматривая мой список После декодирования строк P1 и P2 я мог видеть, что числа увеличиваются, увеличиваясь большими шагами от одной ссылки для подтверждения электронной почты к другой. P1 и P2 никак не коррелировали, кроме того, что оба они выросли.

Сначала я пытался угадать пронумерованные строки на основе отметок времени в ответе HTTP, но это ни к чему не приводило. Вместо этого у меня была идея определить верхнюю и нижнюю границы, в которых будет находиться действительный токен для адреса электронной почты. При небольшом диапазоне, даже 9 или 12-значное число может быть использовано методом перебора для создания действительного токена.

Верхняя и нижняя границы

С математической точки зрения мне нужно было угадать два 9-значных числа. Двенадцатизначное число всегда начинается с 000, поэтому фактически оно состоит из 9 цифр. 9-значное число имеет 1 000 000 000 возможных комбинаций. Поскольку у меня их два, у меня есть 1 000 000 000 * 1 000 000 000 возможных комбинаций для каждого токена подтверждения электронной почты. Довольно безопасно.

Проблема с этим приложением заключалась в том, что в каждом сгенерированном токене P1 и P2 имели номера больше, чем предыдущие P1 и P2, но ниже, чем следующие P1 и P2. Если я могу создать токен, который я могу видеть, затем один токен, который я не могу, а затем третий, который я могу видеть, я могу значительно сократить диапазон возможных чисел. Я могу создать верхнюю и нижнюю границы для 9-значного числа, что намного меньше диапазона возможных комбинаций 1 000 000 000.

Поэтапная моя токен-атака выглядела так:

Создайте учетную запись с принадлежащим мне адресом электронной почты
Создайте учетную запись с адресом электронной почты, которым я не владею, но хочу подтвердить
Создайте учетную запись с принадлежащим мне адресом электронной почты

Применяем это на практике

Чтобы доказать, что я могу подтвердить любой адрес электронной почты, я решил проверить свое собственное имя в домене целевой компании, например [email protected]

Я открыл три профиля браузера и перенес процесс создания учетной записи на последнюю страницу во всех трех браузерах. Как можно быстрее (используя burp intruder для удержания запросов перед выпуском одного за другим) я отправил форму «создать учетную запись» во всех трех браузерах с [email protected] посередине. Это отправило мне два электронных письма со ссылкой для подтверждения адреса электронной почты в каждом. Среднее письмо было отправлено на адрес, к которому у меня не было доступа.

При извлечении параметров P1 и P2 из двух проверочных ссылок мои верхняя и нижняя границы выглядели следующим образом:

НижнийP1: 000148309914
ВерхнийP1: 000148309953

НижнийP2: 187633910
ВерхнийP2: 187634120

Диапазон P1: 39
Диапазон P2: 210

Возможные комбинации: 8 190. Намного лучше, чем 1 000 000 000 * 1 000 000 000 = 1.0e18

Затем я выполнил следующую логику на Python:

for P1 in range (LowerP1..UpperP1):
  for P2 in range (LowerP2..UpperP2): 
    P1 = "TEXT000" + string(P1) 
    P1 = base64encode(P1) 
    P2 = base64encode(P2) 
    url = buildURL(P1, P2) 
    getUrl(url)
# Note, this is pseudo code - it won't actually run but it summaries # the script logic into a readable form

В рамках buildURL () я добавил P3 и P4 и остальную часть URL. Затем я просто отправил HTTP-запрос GET всех 8190 возможных двухчастных токенов между верхней и нижней границами, пока мой адрес электронной почты не был проверен.

Полученные результаты

Благодаря этому я смог проверить [email protected], доказав, что мой обход проверки сработал. Поскольку основная функциональность веб-приложения уже связала учетные записи, созданные с помощью электронной почты и паролей, с учетными записями, созданными Facebook с соответствующим адресом электронной почты, мне не нужно было дополнительно доказывать это. Простое объяснение поведения - это все, что требовалось в моем отчете об ошибке.

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

Влияние

Мне удалось обойти требование проверки учетной записи и использовать приложение без привязки к реальному адресу электронной почты. Я также имел возможность провести предварительный захват любого адреса электронной почты, который еще не был зарегистрирован, чтобы ничего не подозревающая жертва впервые вошла в систему через Facebook, Twitter или что-то еще.