В один из солнечных дней, решил я накидать скриптец по web-crawling’y со своими блек-джеками фичами, а именно — со своим кастомным выводом той информации, которая мне необходима, да с подсветкой всего нарыбаченого добра. Волей судьбы тестирование скрипта выпало на Mail.ru, отсюда и начало этой поучительной истории…). В процессе выполнения скрипта, моему взору вдруг предстал домен, который немного выделяется среди остальных прочих, на то и была ставка при выполнении скрипта (см. скрин ниже)

Кто не любит PHP? Все любят PHP!

Как показывает практика, PHP-сайты по сей день хорошенько триггерят всех тех, кто имеет какое-либо отношение к offensive security в целом, и видимо не зря!

В нашем случае, на удочку попался https://allods.mail.ru на котором крутится какая-то онлайн игрулька, в компоненте регистрации которой имеется POST-запрос, который валидирует аутентифкационные данные из основной пользовательской базы данных.

Решено было отправить уязвимость через H1 (hackerone.com), на котором к сведению, Mail.ru касательно репортов связанных с брутфорсом написали следующее:

Special instructions for this weakness:

Before submitting bruteforce attacks, please note, that ABF (antibruteforce) used by Mail.Ru uses behavior-based heuristics and may react in different ways usually unexpected by researchers but confirmed to be good and reliable in practice. The only real way to confirm ABF bypass is to conduct real bruteforce attack on previously unaccessed account registered by somebody else with valid password among invalid ones in the dictionary. We do not accept burp logs, videos, etc for bruteforce reports. The only way to proof the bruteforce is to request real account with password pattern from security team and demonstrate attack and the chances you fail and report is marked as N/A are >99%.

Очень интересно! Выглядит это так — пруфы никакие мы не примаем, даём вам специальный акаунт, его и атакуйте, но мы Вас предупреждаем сразу, что >99% ваш репорт уйдёт в небытие, но когда это нас останавливало!)) xD

Далее, будет описан сам отчёт, который был отправлен в Mail.ru через платформу hackerone.com и процесс взаимодействия с представителями Mail.ru отвечающими за ББ-направление в компании, ну и впечатления от всего этого процесса.))

// ————-———- ОТЧЕТ ————————-//

Vulnerability Technical description 

По адресу https://allods.mail.ru/account.php находится форма регистрации нового пользователя в игре. В процессе заполнения формы, посылается Ajax POST-запрос в параметрах которого передаются пара логин-пароль на URL https://allods.mail.ru/ajaxreg.php

В теле POST-запроса передается функция verifyMruEmailPass, из названия которой очевидно, что функция имеет отношение к верификации, а в совокупности с передаваемыми логином и паролем — к процессу аутентификации.

В BurpSuite уязвимый запрос выглядит следующим образом (Pic.2-5)

Pic.1 Уязвимый POST-запрос

При успешной аутентификации пользователю возвращается:

{
  "Valid":"1",
   "Error":""
}

При неудачной:

{
  "valid": "",
  "error": "Неверно указан пароль от почты Mail.Ru!"
}
Pic.2 POST-запрос — успешная аутентификация (Burp Suite)
Pic.3 POST-запрос — ошибка аутентификации (Burp Suite)
Pic.4 POST-запрос — 500 ошибка (если пароль < 3 символов) (Burp Suite)

В первую же очередь уязвимость была проверена средствами Intruder, где за основу был взят словарь в ~100 срок, в разные участки которого было вставлено пять валидных паролей от учетной записи bug.bounty@list.ru. (passwd — hammer50!!)

Из результата выполнения запросов видно, что запросы 12, 37, 80, 93, 104 — вернули в теле респонса  { «Valid» : «1«, «Error» : «»}.

Pic.5 Успешный процесс выполнения атаки в Intruder

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

Также, хост и веб-приложение в целом никак не реагируют, и не привентируют попытки проведения Bruteforce-атаки, позволяя злоумышленнику брутфорсить с одного хоста используя несколько различных User-Agent’ов. Исходя из этого, можно предположить, что хост allods.mail.ru не имеет каких-либо защитных ABF-механизмов и последующую атаку можно представить в виде следующей схемы:

Pic.6 Схема Bruteforce-атаки

Vulnerability Exploitation

Для автоматизации Bruteforce-атаки, был разработан PoC shell-скрипт, который выполняет ряд следующих действий:

  • Отображает старт скрипта
  • Подгружает с Github небольшой словарь для атаки
  • Построчно читает словарь
  • Выполняет в цикле POST-запрос используя curl
  • Отображает процесс выполнения запросов и их количество
  • Парсит результат выполнения и выводит его в случае успешной атаки
  • Отображает завершение скрипта и количество выполненных запросов
Pic.7 PoC-скрипт для Brute-force (см. вложение в конце поста)

Скрипт запускается в терминале и в качестве аргумента передается атакуемый емейл, например:

user@linux:$ ./bruteforce_poc.sh bug.bounty@list.ru 

Далее, на емейле bug.bounty@list.ru был изменен пароль из словаря (выбрав рандомно из середины) и был запущен скрипт на подбор пароля, статус и результат выполнения отображены ниже (Pic.8-9)

Pic.8 Процесс Bruteforce-атаки
Pic.9 Успешно завершенная Bruteforce-атака

На Pic.9 можно увидеть, что  выполнение скрипта составило ~1 минуту и количество запросов составило 76, при однопоточном режиме. Исходя из этой информации — можно сделать простые расчеты по скорости выполнения атаки как в однопоточном, так и многопоточных режимах с распределенным типом атаки.

Также следует отметить, что во время проведения атаки при успешной аутентификации через сервис allods.mail.ru, пользователь не получает каких-либо нотификаций и уведомлений о том, что был произведён логон под данным емейлом. (Pic.10)

Pic.10 Отсутствие нотификаций об успешной аутентификации

Step to Reproduce

  1. Скачать скрипт bruteforce_poc.sh (из вложения или отчета) и установить права выполнения при необходимости (chmod +x).
  2. Открыть настройки почты по смене пароля.
  3. Открыть словарь https://raw.githubusercontent.com/xajkep/wordlists/master/discovery/user_field_names.txt и выбрать любой пароль из списка.
  4. Установить выбранный пароль из словаря в качестве нового пароля для почтового ящика.
  5. Запустить скрипт ./bruteforce_poc.sh username@mail.ru.
  6. Наблюдать за процессом брутфорса до получения ожидаемого результата.

P.S. Из очевидных вещей — PoC-скрипт по брутфорсу возможно переделать под любые требования, например, под распределенную атаку с использованием разных исходящих IP-адресов, User-agent’oв, таймаутов и тд. и тп.

//——————— КОНЕЦ ОТЧЕТА ————————//

Далее, отчет был отправлен и от представителей Mail.ru был получен следующий очевидный ответ:

При попытке сбрутить данный аккаунт, нас конечно же постигает облом. Решено было воспроизвести кейс с подобной маской пароля на своём аккаунте, и для этого была предпринята попытка установить подобный пароль (например — qweASD666) на свой аккаунт, но и тут нас постигает облом, т.к. установить подобный пароль на продакшене Mail.ru мы не можем по причине активной парольной политики, которая производит проверку по дефолтным словарям и дефолтным парольным маскам (qwerty, asdzxc, etc…), в результате чего, на продакшене пользователь просто не имеет возможность установить подобный пароль:

Подобная ситуация наводит на мысль, что тебе дают брутить какой-то не тот аккаунт, не из того окружения, или пароль на нём не тот установлен, мало ли! Не забываем, что почти все (>99!) брутфорс-репорты помечаются как False-positive. Пишу об этом представителям Mail.ru:

И тут, после этого коммента, отчёт закрывают как Not Applicable — вот это поворот!

Mail.ru’шники по всей красе показали, как они умеют менеджить уязвимости через их всюду (на всех конфах) распиаренную Баг-Баунти, а на практике всё как всегда. Разочароыввает тот, факт, что в твоем репорте никто не имеет желания разбираться, хотя тебя заранее и предупреждали о том, что твой репорт АВТОМАТИЧЕСКИ с вероятностью >99% будет помечен как N/A)) п-х-х-х… Про этикет общения-поведения я пожалуй вообще промолчу.

ИТОГ

После того, как отчет был отправлен, во время последующих тестирований стало заметно, что сервак стал реже отдавать респонсы при попртыках брута, так и сами попытки атаки стали уже мониториться и привентироваться. Быстренько фикисте, молодцы! =)

Я конечно понимаю, что ребята из Mail.ru хотят видеть максимальный Impact от уязвимости здесь и сейчас, и в неособо очевидных уязвимостях ну просто нет желания разбираться, да и тем более платить за это какие-то $$$.

Так вот, исходя из вышеизложенного, в следующие разы, я точно >99 раз подумаю, стоит ли относить обнаруженные уязвимости в Mail.ru. И тебе дорогой читатель, тоже советую, подумать насчёт уязвимотей Mail.ru, об их фиксах, и человеческих подходах, ну и о хранении собственной информации в подобных системах…

— ОПЯТЬ ПРИСЛАЛИ УЯЗВИМОСТЬ ПО БРУТФОРСУ!

3 комментария

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.