[Bug bounty | mail.ru] Доступ к админ панели партнерского сайта и раскрытие данных 2 млн пользователей



    Относительно недавно я перешёл от поиска уязвимостей на случайных сайтах к Bug Bounty площадкам, и для многих такой выбор кажется очевидным — в таких программах исследователь в 90% случаев получит не только хороший опыт, но и гарантированную награду за валидную уязвимость, в то время как на случайном сайте можно наткнуться на непонимание и угрозы. Собственно, для того, чтобы получить репутацию и «ускорение» на крупнейшей Bug Bounty — HackerOne, было принято решение сосредоточиться на поиске уязвимостей на одной из крупных bugbounty программ — mail.ru.

    В этой статье будет идти речь о нескольких багах на самом mail.ru, а так же об уязвимости на одном из поддоменов mail.ru, которая позволяла получить доступ к админ панели, в связи с чем возможно было просматривать личные данные 2 миллионов пользователей (такие как email адреса, номера телефонов, домашний адрес и др) с более чем 10 популярных интернет магазинов СНГ, а так же входить в их аккаунты без пароля.

    Для того, чтобы принять участие в bug bounty mail.ru на hackerone, было отсортировано 3 000 поддоменов и проверен каждый. На работу с этой Bug Bounty была выделена небольшая часть моего времени и за ~ 3 месяца мне удалось отправить 45 валидных уязвимостей (40 на данный момент исправлены, 5 со статусом «triaged»).

    Некоторое время назад я приступил к исследованию поддомена redacted_shop.mail.ru — это интернет магазин брендированных товаров.

    Чаще всего тестирование начинается с личного кабинета, этот случай так же не стал исключением. Авторизация на сайте происходит с помощью o2.mail.ru Oauth, или же способом ввода email адреса. Если брать во внимание второй способ, то авторизация проходит следующим образом: пользователь вводит email, ему присылают код на почту, он отправляет его через форму и входит в аккаунт. Здесь обнаружилась первая уязвимость, — Improper Authentication:

    Дело в том, что кроме самого кода, который нужно ввести в форму, присылается ещё и ссылка для входа вида redacted_shop.mail.ru/?login=hV8oUH, при посещении которой выполняется автоматический вход в аккаунт. Такую ссылку обычно называют «автологином», этот функционал присутствовал в старых WAP сайтах. Сейчас такой способ входа в аккаунт почти не используется ввиду его небезопасности.

    Impact этой уязвимости:

    • Можно осуществить brute-force атаку, узнать множество идентификаторов для автологина и войти в чужие аккаунты;
    • Ссылка для входа может индексироваться поисковиками и попадать в выдачу ответов google по сайту, злоумышленник может их спарсить. Иногда, даже при запрете в robots.txt, url-ы могут индексироваться без содержимого.

    После тщательного перебора директорий (для этого использую программу dirb с кастомным словарем) я начал тестировать формы изменения личных данных, адреса доставки и др. В формах присутствовали CSRF токены, и попытки обойти защиту не увенчались успехом. XSS и намёков на другие уязвимости не было (такой вывод был сделан после фаззинга).

    Напоследок, я изменил свои данные и адрес доставки на js payload-ы и сделал тестовый заказ товара, где в комментарий вписал ещё один js payload.

    В 00:10 я обнаружил, что мой blind xss скрипт выполнился в админ панели не известного мне сайта admin.undefined.com/index и мне пришли логи на сервер. В то время не было даже мысли о том, что будет возможность получить доступ к админ панели, так как чаще всего cookies защищаются флагом http only.



    Но, к моему удивлению, флага не было и я успешно вошёл в админку. Сам сайт выглядел как CMS 2000-2006 года с очень старым дизайном, плохой производительностью (страницы довольно долго загружались) и множеством ошибок php и sql.



    После просмотра главной страницы стало совершенно ясно, что админка связана с mail.ru и заказами на поддомене redacted_shop.mail.ru доверили управлять стороннему сайту (позже команда сообщила, что это партнер и redacted_shop.mail.ru разрабатывали не mail.ru). В админке можно было просматривать, редактировать и удалять заказы всех пользователей с 10-ти интернет магазинов (некоторые крупные), а также просматривать личные данные 2 017 271 пользователей. Вторая уязвимость Blind XSS подтверждена.

    Если у злоумышленника был бы доступ к админ панели, то он мог бы скачать базу с информацией о всех пользователях одним кликом, но в самом функционале присутствовала ошибка php, поэтому пришлось бы ограничиться перебором по id пользователей в админке и burp intruder.

    Кроме этого, к странице каждого юзера в админ панели была прикреплена ссылка для автологина. Может быть, кто-то из читателей помнит о небезопасных автологинах в старых русских социальных сетях, которые были популярны в 2007 году, — spaces.ru и др.



    Как только я получил доступ к админ панели и сделал пару скриншотов, то сразу же отправился писать репорт на hackerone.

    Отчёт с подробностями был отправлен в 00:20. Примерно в 00:43 в отчёте мне ответил глава информационной безопасности в компании mail.ru Сергей Белов. Он попросил прекратить пост эксплуатацию моей blind xss и немедленно выйти с админ панели, что я, естественно, и сделал.



    Следующим же утром я проверил баг, и так как на мой сервер не пришли логи, можно считать, что он был исправлен. Также к админ панели был закрыт доступ, на смену этого добавлен доступ только по IP (скорее всего).

    К сожалению, поддомен redacted_shop.mail.ru не находился в scope Bug Bounty программы mail.ru и уязвимость не могла претендовать на награду. Поэтому для того, чтобы усилия и время, потраченные на уязвимость, были вознаграждены, я связался с разработчиками самой админ панели и мне было выплачено вознаграждение.

    Также я отправил репорт с первой уязвимостью Improper Authentication в Bug Bounty, при этом прекрасно понимая, что баг трудно эксплуатируется и я получу только баллы репутации. Как PoC к уязвимости был отправлен автологин redacted_shop.mail.ru/?login=hV8oUH, который во время написания репорта исправно работал. Но, позже я получил сообщение от аналитика и том, что он не может воспроизвести баг, то есть, судя по всему, функционал автологина был отключен разработчиками и больше нельзя было восстановить пароль к аккаунту или войти, используя ссылку.



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

    Timeline:


    • April 12, 00:20:50 — Репорт отправлен через HackerOne.
    • April 12, 00:43:03 — Первый ответ.
    • April 12, 00:47:15 — Triaged.
    • April 26, 19:14:38 — Репорт помечен как «Resolved».
    • June 27, 00:59 — Выплачена награда за уязвимость.

    Большинство найденных багов — это XSS, Open Redirect и CSRF, но хотелось бы отдельно рассказать о наиболее интересных:

    1. IDOR в службе поддержки lootdog.io https://hackerone.com/reports/328337, который раскрывал несколько миллионов тикетов.

    2. Также я хотел бы рассказать о баге Double Authentication Bypass на mail.ru, но, к сожалению, уязвимость пока не была исправлена и помечена как «Informative», поэтому, увы, его здесь не будет. Могу только сказать, что защита обходится с помощью перехода на мобильную версию, в то время, когда в веб версии защита работает. И всё же, когда его исправят, вы сможете посмотреть информацию о нём на моём канале t.me/vulns.

    3. Blind XSS на pets.mail.ru в кличке питомца, которая позволяла взломать админ панель.



    4. На ****.mail.ru нашлась Stored XSS, с помощью которой можно было деанонимизировать любого пользователя mail.ru и узнать его email в случае, если он просто перейдет по ссылке. Нужно было только создать страницу с js.

    Из-за того, что юзер автоматически авторизуется на ****.mail.ru и в поле подписки автоматически подставляется email пользователя, мы можем узнать email адрес любого пользователя mail.ru, который перейдёт по ссылке нашей консультации. Возможно увидеть email адрес в html исходнике страницы, а также в local storage, значение которого придёт к нам на сниффер.

    5. Blind XSS на kayako.support.my.com/staff/index.php?/ (служба поддержки in-scope сайта lootdog.io), который позже был помечен как «Duplicate».



    6. Отсутствие Rate лимита во входе в аккаунт на am.ru. На сайте есть функционал входа с помощью otp, который пришёл на номер телефона, ограничений на перебор цифр не было, таким образом bruteforce атака помогла бы взломать любой аккаунт зная только номер телефона.

    7. Раскрытие email адресов со статей на ****.mail.ru с помощью картинки cp-filin.mail.ru/pic?email=********@mail.ru, аналогичный репорту Isaeva.

    Выводы из данной статьи:


    • НИКОГДА не используйте автологины в авторизации.
    • Закрывайте доступ к админ панели с помощью ошибки 403 через .htaccess (если у вас сервер apache), ограничивайте доступ по IP адресу, требуйте аутентификацию. Таким образом злоумышленнику будет труднее найти уязвимые места в админ панели, кроме того, если он узнает cookies или другие данные, он не сможет их задействовать.
    • Не используйте устаревшее программное обеспечение в админ панели.
    • Всегда фильтруйте запрещенные символы [ "<>'/ ] в информации, которая приходит в админку, чтобы избежать XSS.

    Советы для тестировщиков безопасности [Blind XSS]:


    • Пытайтесь найти все возможные места, где можно отправить ваш скрипт, например, жалоба на страницу / пользователя, оценка работы сайта, логирование (попробуйте заменить свой user agent на скрипт, возможно, он окажется в логах админ панели, где нету фильтрации) и тд.
    • Часто вы не получаете логи про успешную blind xss атаку из-за фильтрации или CSP настроек. Обходите фильтры в админ панели с помощью использования других скриптов (например meta, img — во многих случаях выполнения этих скриптов хватит для доказательства уязвимости), также закрывайте теги, чтобы они не помешали выполнению.
    • Если в админ панели стоит фильтрация на <>, попробуйте испытать удачу и выполнить js инъекцию "; alert(1);// .

    P.S: Рекомендую подписаться на мой telegram канал по информационной безопасности, ссылка внизу или в профиле. Также, если Вы хотите выявить уязвимые места на Вашем сайте и успешно их устранить — я готов сделать это качественно, по приемлемой цене и с сохранением полной конфиденциальности. Для первичной консультации свяжитесь со мной на сайте isec.one.
    • +48
    • 13,7k
    • 9
    Поделиться публикацией
    Комментарии 9
      +1

      Я бы поискал тут https://admin.mail.ru/Новая папка (3)/пароли.txt, да уже потерли все :/

        +6
        А за континентом за такую пост-эксплуатацию уже б давно выписали ремня. Особенно за слив пользователей :)
          0
          Может, в этом цель и была?
          image
          +4
          Ждем открытия новых уязвимостей и прочего уже со скриншотами с мэйла нового актуального дизайна.
            0
            Лучше всего для защиты от XSS использовать шаблонизатор с автоэкранированием, например, твиг.
              0
              «Также я хотел бы рассказать о баге Double Authentication Bypass на mail.ru, но, к сожалению, уязвимость пока не была исправлена и помечена как «Informative», поэтому, увы, его здесь не будет.» Если они не считают это уязвимостью — почему бы и не рассказать?
                +1
                уязвимость пока не была исправлена
                Bugbounty подразумевает что нельзя о ней рассказывать до фикса.
                0
                В 00:10 я обнаружил, что мой blind xss скрипт выполнился в админ панели не известного мне сайта admin.undefined.com/index и мне пришли логи на сервер. В то время не было даже мысли о том, что будет возможность получить доступ к админ панели, так как чаще всего cookies защищаются флагом http only.

                Расскажите, пожалуйста, подробнее о том, как вам XSS помог получить доступ. Я так понимаю, что для эксплуатации XSS кто-то с админ правами должен зайти на страницу с XSS injection или кликнуть на ссылку(например через фишинг письмо).


                Правильно ли я понимаю, что последовательность следующая:


                1. Скрипт куда-то отправил в какой-то форме XSS payload
                2. Кто-то из админов зашел на страницу где отображался XSS payload
                3. Браузер выполняя XSS payload выслал куки к вам
                  0
                  Браузер админа выполняя XSS payload выслал куки к вам
                  Именно так.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое