5 March

Как я взломал мошенников, или просто внутренности фишинг-панелей

Information Security
From Sandbox

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, который сразу может предоставить тебе:


  1. url, где произошло срабатывание;
  2. IP;
  3. Cookie;
  4. Dom-страницы;
    … и еще по мелочи. Но в целом все тоже самое можно организовать, отправляя эти данные к себе, скажем, на VPS.

Нас интересует тот факт, что blind XSS-таки отработала успешно.



Исторически, упоминая XSS всегда предлагалось "красть сессию" (содержимое document.cookie).


Но в современном мире, как правило такое уже не работает — сессионные куки выставляются с заголовком "httpOnly", что делает их недоступными для вредосного JS.


Но XSS все еще опасны, по-прежнему можно обращаться к API сайтов в контексте уязвимого сайта, воровать данные со страницы (токены), хоть это и чуть более сложно.


Но злоумышленники не озаботились безопасностью сессии, поэтому мне удалось "угнать" сессию целиком.


Заходим на хост, меняем сессионную куку, попадаем внутрь.


Здесь в глаза бросаются, помимо логинов и паролей, тот факт, что панель не рассчитана на одного человека — а монетизируется продажей доступа туда.




К созданию подошли почти с душой. Не забыли добавить bootstrap с кнопочками, а также весьма расширенный функционал, а именно:


Выгрузка с различных форматах:



Прокси:



Ключи для API:



Логи выгрузов с IP.



Также такие панельки позволяют автоматически создавать хосты с выбранным содержанием, которое может привлечь пользователей, а именно:




Пример добавления и существующие хосты на аккаунте:




А вот, как выглядят классические сгенерированные страницы:





… и многие другие.


Разработчики фишинговой панели активно используют имеющееся API Вконтакте, например выгружают количество друзей, подписчиков, проверяют права администрирования в пабликах, и.т.д, например такие как execute.getDialogsWithProfilesNewFixGroups.php, примеры методов:
https://vk.com/dev/execute


Довольно примечательным являлась следующая ситуация.


Если зайти в аккаунт Вконтакте используя логин и пароль — велика вероятность словить подозрение от VK с просьбой ввести отправленный в личные сообщения код.


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


Выглядело это примерно так:


GET /method/execute.getDialogsWithProfilesNewFixGroups?access_token=****b750be150c961c******ace8d9dd54e448d5f5e5fd2******7e21388c497994536a740e3a45******&lang=ru&https=1&count=40&v=5.69 HTTP/1.1
Host: vk-api-proxy.xtrafrancyz.net

HTTP/1.1 200 OK
Date: Tue, 03 Mar 2020 09:57:08 GMT
Content-Type: application/json; charset=utf-8
Connection: close
Vary: Accept-Encoding
Server: vk-proxy
X-Powered-By: PHP/3.23359
Cache-Control: no-store
X-Frame-Options: DENY
Access-Control-Allow-Origin: *
Content-Length: 57453

{"response":{"a":{"count":271,"unread_dialogs":151,"items":[{"message":{"id":592***,"date":1583222677,"out":0,"user_id":14967****,"read_state":1,"title":"","body":"Код подтверждения входа: 063725.","owner_ids":[]},"in_read":592***,"out_read":592***}

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


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


На самом деле, один из возникающих вопросов, это что делать дальше в таких ситуациях?


В общем-то, я собрал те фишинговые хосты и утёкшие аккаунты, помимо тех, что были видны в интерфейсе, также те, что были видны по эндпоинту с кучей мусора: непроверенный акков, оскорблений в сторону фишеров, и тихой записью с blind xss пейлоадом, что в дальнейшем было передано ребятам из VK по рекомендации и помощи Bo0oM, которые, скорее всего, в свою очередь проводят стандартную процедуру внесения этих сайтов в запрещенные, и сбросы паролей.


Также пошел процесс complaint'ов в сторону фишинговых хостов и панельки. Подавляющая часть была скрыта за cloudflare'ом, поэтому пришлось написать им. Этот процесс, к слову, весьма неудобный и отбивающий желание репортить такие сайты, т.к почему-то Cloudflare не хочет принимать жалобу на почту, но хочет принимать жалобу через https://www.cloudflare.com/abuse/form, причем не несколько хостов за раз — а каждый раз отдельно на 1 url ¯ \ (ツ) / ¯


Но все же в их пользу стоит сказать — что бан они выдавали за 10 минут.



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


UPD: Также была передана соответствующая информация и в QIWI с Yandex, для проверки уже кошельков.

Tags:мошенничествофишингинформационная безопасность
Hubs: Information Security
+137
45.4k 178
Comments 37
Ads