Как я взломал мошенников, или просто внутренности фишинг-панелей
INTRO
Недавно столкнулся с обычной для интернета ситуацией — классической просьбой от родственника отдать свой голос за него в каком-то голосовании. Оказалось, человека «взломали» мошенники, а ссылки на голосование вели на фишинговые ресурсы.
Я увлекаюсь безопасностью, поэтому решил из интереса проверить безопасность фишингового ресурса.
«Админку» мошенников удалось успешно взломать, внутри нашлось n-количество украденных учеток. Их логины были переданы в службу безопасности VK, плюс соответствующие «abuse» жалобы были направлены регистраторам, хостерам.
А теперь расскажу как и какие оказываются бывают Phishing-as-Service панели.
Началось все как обычно просьба от родственника отдать свой голос за него в каком-то голосовании:
Родственник:
Привет, просто хочу выиграть 🙂 http://x-vote.ru/votes/701738#vote
На самом деле, большинство скорее всего проигнорирует подобную просьбу, но с точки зрения безопасности возникла заинтересованность в проверке на Race condition само голосование — удастся ли 1 аккаунту отдать по факту несколько голосов, отправив их несколько в один короткий промежуток времени.
К сожалению, проверить это так и не удалось. Ввиду, судя по всему, отсутствия всякого голосования, и к тому же не совсем той Oauth формой, которую хотелось бы увидеть.
Становится уже совсем очевидно, что это просто фишинг, и ничего более.
Однако просто покидать сайт, отказавшись от удовольствия проверить на Race Condition было бы поражением, сканирование портов и поиск директорий на предмет админки или интересных файлов ни к чему не привели, поэтому, быстро прикинув, я решил не писать в форму гадости, которые могли бы вызвать у хозяев фишинг-сайта колоссально-нравственные страдания.
Вместо этого я предположил, что данные, которые жертвы отправляют в форму, затем где-то отображаются, и фильтрация там отсутствует, и, значит, что вместо логина/пароля можно отправить «вредоносный» HTML+JS, или в простонародье Blind XSS. Слепой она называется, потому как факт его отрабатывания мы зафиксировать сразу не можем — только если на неё наткнется администратор/модератор по ту сторону.
Спустя день изучаем наш xsshunter — будничное действие для многих багбаунти хантеров. Это довольно простой и понятный ресурс для проверки на слепые XSS, который сразу может предоставить тебе:
Нас интересует тот факт, что blind XSS-таки отработала успешно.
Исторически, упоминая XSS всегда предлагалось «красть сессию» (содержимое document.cookie).
Но в современном мире, как правило такое уже не работает — сессионные куки выставляются с заголовком «httpOnly», что делает их недоступными для вредосного JS.
Но XSS все еще опасны, по-прежнему можно обращаться к API сайтов в контексте уязвимого сайта, воровать данные со страницы (токены), хоть это и чуть более сложно.
Но злоумышленники не озаботились безопасностью сессии, поэтому мне удалось «угнать» сессию целиком.
Заходим на хост, меняем сессионную куку, попадаем внутрь.
Здесь в глаза бросаются, помимо логинов и паролей, тот факт, что панель не рассчитана на одного человека — а монетизируется продажей доступа туда.
К созданию подошли почти с душой. Не забыли добавить bootstrap с кнопочками, а также весьма расширенный функционал, а именно:
Выгрузка с различных форматах:
Логи выгрузов с IP.
Также такие панельки позволяют автоматически создавать хосты с выбранным содержанием, которое может привлечь пользователей, а именно:
Пример добавления и существующие хосты на аккаунте:
А вот, как выглядят классические сгенерированные страницы:
Разработчики фишинговой панели активно используют имеющееся API Вконтакте, например выгружают количество друзей, подписчиков, проверяют права администрирования в пабликах, и.т.д, например такие как execute.getDialogsWithProfilesNewFixGroups.php, примеры методов:
https://vk.com/dev/execute
Довольно примечательным являлась следующая ситуация.
Если зайти в аккаунт Вконтакте используя логин и пароль — велика вероятность словить подозрение от VK с просьбой ввести отправленный в личные сообщения код.
Однако при помощи их методов и access-токена, никаких проблем с этим не было, и тот же самый код можно было прочитать через этот функционал.
Выглядело это примерно так:
ВК помнит, откуда пользователь обычно заходит на сайт. Предположительно, поэтому мошенники такое тоже предусмотрели и использовали различные прокси