Скрытый сниффер, или же экономия $4OOO за лень или отсутствие серого вещества.

Всем привет, давно ничего не писал, не пополнял базу сия материалов, но совсем недавно на глаза мне упал замечательный тред про старый, добрый сниффер от Флераса, и увидел такую вещь как версия Hidden, а не обыкновенная за $2500, и разница заключается лишь в том, что ту самую версию спрятанную не видно в F12, в отличие от дешевенькой. Но для того чтоб ответить на этот вопрос, нужно для начала понять и заглянуть в историю как работал с технической стороны сниффер, так скажем его основные методы доставки, и проведем небольшой ликбез, для не особо посвященных. Поехали.
Окей, для начала маленькое введение для тех, кто не до конца понял о чём речь вообще. Сниффер - это штучка, которая если впрямом смысле "вынюхивает" какие-либо данные, зачастую это у нас идут банковские карточки, и прочее-прочее. Но чтоб понять более лучше, давайте вспомним, то о чём мы все знаем, знали, из далекого прошлого. Сама по себе идея воровства банковских данных не нова, вспомните скиммеры. Это была накладка поверх настоящих цифр, или камера, которая будет смотреть на то какие циферки ты ввёл, или накладка на штуку, куда мы пихаем карточку. Теперь проведем еще более лучшую аналогию, на сайте есть поле для ввода данных, сниффер делает накладку поверх настоящей формы, куда жертва вводит данные, и таким образом мы собираем, надеюсь, теперь это достаточно ясно. Если нет, то храни вас Господь Бог, я даже не знаю, что может вам помочь в понимании.

Так вот, теперь ближе к тому как вообще передавались/передаются данные в снифферах. Одной из массовых основ, которую как раз таки и использует Флерас в базовой версии, это websocket, быстро, удобно, надежно, легок в написании. Человек заходит на сайт, создаётся коннект, мы передаем свой JS, который надо исполнить (допустим на подмену фрейма), и там уже все изменения в данных, которые мы подхватываем и сохраняем. Но этот метод с моей точки зрения один из самых палящихся, владельцы шопов уже привыкли, к тому что зачастую это будет вебсокет, ведь он является самым распространённым на рынке, по этому это решение не ахти. Да и к тому же, большинство снифферов избито и побито иМеНнО первоклассным "шифрованием", зачастую используют простой b64, все называют шифрованием, кеки ведутся, а это простая обфускация (важно понимать разницу - google.com для незнающих), одним из смешных вариантов я видел за 1.5k$ на всё той же экспе - это было следующее string ~> base64 ~> reverse ~> base64. Но тут и стоит немного подумать, да? Я лично практически всегда придерживаюсь мнения, что если человек захочет, то он сделает, а в данном контексте отреверсит, учитывая тот факт как далеко сейчас заходят нейронки, дело будет как расплюнуть, хоть ты на WASM делай, только кредитов побольше потратят ресерчеры.


Второй вариант очень схож по своей натуре на вебсокет, но отображается он немного по другому, и гласится он HTTP Long-Polling, по сути всё тоже самое как, но тут каждое сообщение мы передаем не внутри как сообщение, а по HTTP, можете посмотреть картинку снизу, так будет больше понимания, ибо порой лучше глазами  взглянуть и понять, нежели просто из сообщения. Распинаться про него слишком много не имеет смысла, так же палится, отчасти даже посильнее нежели вебсокет, ведь он спамит-спамит без остановки запросами, а теперь давайте к тому самому "скрытому варианту", за который Флерас просит доплату в $4OOO.

WebRTC, WebRTC, и ещё раз вэбртэцэ..- Был он придуман изначально для аудио/видео-звонков. А если пройтись по бумажке, то технология с открытым исходным кодом, предназначенная для организации передачи потоковых данных между браузерами или другими поддерживающими его приложениями по соединению точка-точка. Но кто бы мог подумать, что мы можем не ограничиваться одним видео или аудио, мы точно так же можем передавать и текстовые данные, и жс скрипты, и всё-всё что угодно. И самая главная визитная карточка вебртц заключается в том, что он не отображается в инструментах разработчика, увидеть его можно лишь в chrome://webrtc-internals/.

То есть вот за незнание этой технологии надо отхлобучить сверху 4 тысячи американских рублей, хотя, я более чем уверен, что уже базовую версию флераса разработчик с экпы отбабахает под вебртц меньше чем за тысячу. Но ладно, не в этом суть и боль, вот так один из легитимных инструментов под звонки превратили в невидимый передатчик данных. И нам нужно отправить всего 1 запрос, чтоб наладить весь коннект целиком и полностью, больше ничего. Сразу прошу подметить, что да, это не будет работать стабильно на совсем старых браузерах по типу эксплорера (хотя я сомневаюсь, что в нём даже ордер можно нормально повешать), так же если человек насильно отключил себе webrtc, но тут снова возникает вопрос. А что лучше: прожить в шопе как можно, или потерять пару десятку сс взамен на жизнеспособность? Оставлю этот вопрос на размышление. Ну ладно, чё трындеть то, давайте склепаем минимально МВП работы и сбора данных через вебртц, и глянем.



Значит, чё нам нужно. На стороне "жертвы" (ну то есть шопа, куда мы впихнули наш жс) - нужен кусок кода, который при загрузке страницы поднимет WebRTC соединение к нашему серверу. А на нашей стороне - сервачок, который этот коннект примет и будет ловить всё что прилетит по DataChannel. Весь кайф в том, что нам нужен ровно ОДИН HTTP запрос для всего хэндшейка, дальше браузер и сервер общаются напрямую, peer-to-peer, и в F12 это выглядит как... никак.. Один POST на /connect и всё, тишина.

Давайте разберём клиентскую часть, то что мы вешаем на страничку:

Что тут происходит? RTCPeerConnection - это и есть тот самый объект, который рулит всем вебртц соединением. createDataChannel('data') - создаём канал для передачи данных (не видео, не аудио, а именно текст/бинарь). Дальше мы создаём offer - это наше предложение на коннект, в нём SDP (Session Description Protocol) со всей инфой о том как к нам подключиться. Ждём пока соберутся все ICE кандидаты (это такие штуки, которые помогают пробить NAT и найти путь между двумя точками). И отправляем этот offer одним единственным POST запросом на наш сервер. Сервер отвечает answer'ом - своим SDP. Всё, хэндшейк завершён, канал поднят.

После этого dc.send('любые данные') и они улетают на сервер по вебртц. Хоть карточки, хоть логины, хоть содержимое всех инпутов на странице - что хочешь, то и цепляй. И ни единого следа в Network табе.
Теперь серверная часть, тут чуть интереснее. Нам нужен был node-datachannel - это нативная имплементация WebRTC для ноды, потому что из коробки нода вебртц не умеет (это же браузерная технология, ёпт):
Сервер принимает offer, создаёт свой PeerConnection, устанавливает remote description (то что нам прислал клиент), и автоматически генерит answer. Этот answer мы возвращаем прямо в теле HTTP ответа на тот самый единственный POST. Всё. Дальше onDataChannel ловит канал, а onMessage ловит каждое сообщение. Хоть в файл пиши, хоть в телегу кидай, хоть в базу складывай - данные у тебя.
А теперь давайте ещё раз взглянем на то, что видит владелец шопа, когда открывает F12 и смотрит Network:
Один POST. На какой-нибудь /connect (который ты, естественно, замаскируешь под что-нибудь легитимное типа /api/analytics или /cdn/telemetry). Ответ пришёл - и всё. Больше ничего. Ни вебсокетов, ни бесконечных запросов, ни подозрительного трафика. Все данные летят по DTLS (это как TLS, только для UDP) внутри WebRTC, и увидеть их можно только через chrome://webrtc-internals/, куда ни один владелец шопа в жизни не полезет, потому что 99% даже не знают о существовании этой страницы.

Вот и вся магия за $4000 от Флераса. Двадцать строчек на клиенте, тридцать на сервере, один npm пакет. Посчитайте сами, сколько это стоит в реальности и сколько с вас просят за "Hidden версию". Думайте головой, учите матчасть, не ведитесь на маркетинг. Не болейте!