Author: Nikolay Pleshakov

  • Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

    Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

    Уже не раз рассказывал о протоколе ТСР, так что повторятся особо не буду, напомню лишь основные положения: Transmission Control Protocol описывается в RFC 793 и преимуществом его является надежность передачи данных от одной машины к другому устройству по сети интернет. Это означает, что ТСР гарантирует надежность передачи данных и автоматически определит пропущенные или поврежденные пакеты. Что для нас важно из его конструкции?

    В общем виде заголовок ТСР пакета выглядит так:

    заголовок TCP-пакета

    Программа передает по сети некий буфер данных, ТСР разбивает данные на сегменты и дальше упаковывает сегменты в наборы данных. Из наборов данных формируются пакеты и уже они передаются по сети. У получателя происходит обратный процесс: из пакетов извлекаются набор данных, его сегменты, затем сегменты передаются в ТСР стек и там проверяются, потом собираются и передаются программе.

    Sequence numbers

    Данные разбиваются на сегменты, которые отдельными пакетами направляются по сети получателю. Возможна ситуация, когда пакеты прибудут в точку назначения не по порядку. Это поле – 32-битный номер, определяющий номер сегмента в последовательности, он с каждым пакетом увеличивается и позволяет собрать данные в правильном порядке. В общем смысле значение определяет принадлежит ли пакет активной сессии или нет.

    Window

    TCP так же предоставляет хостам механизм сказать друг другу сколько данных они хотят получить. Это и есть поле Window – 16 битное число в ТСР заголовке. Будучи однажды заданным, оно говорит хосту, что приниматься будет строго ограниченный объем данных, а остальные пакеты будут отброшены. Если очередь приема будет переполнена, то хост может выставить значение окна приема в 0 и таким образом сказать партнеру по обмену трафиком, что типа мол хорош.

    Контрольные биты – SYN, ACK, PSH, URG, RST и FIN, про них уже не раз говорили, так что повторяться не буду.

    Атака TCP RESET

    Главная идея – сфальсифицировать пакет и прекратить или скомпрометировать установленное ТСР соединение. Давай представим, что существует соединение от хоста А к хосту В. Третий хост С подделывает пакет в котором указывает исходный порт и IP адрес хоста А, порт назначения и адрес хоста В, и текущий sequence number активного ТСР соединения между А и В. Хост С устанавливает RTS бит на пакете, так что когда В получит пакет, он немедленно прекратит соединение. Это приведет к отказу от обслуживания до тех пор, пока соединение не будет восстановлено. На уровне приложения конечно трудно сказать что будет, это скорее зависит от самой программы.

    В такой ситуации конечно наиболее уязвимы приложения и протоколы поддерживающие продолжительные соединения. Например BGP (Border Gateway Protocol) от Cisco (см. RFC 1771), так как он основывается на постоянной ТСР сессии между компьютерами. Сбой в работе протокола может привести к “колебанию маршрута” (route flapping), довольно неприятному событию для маршрутизатора.

    Уязвимость

    Paul Watson, обнаруживший уязвимость, объясняет, что на самом деле такую атаку не так трудно организовать как казалось ранее. По предыдущим подсчетам выяснили, что брутфорс атака на sequence number потребует перебора всех чисел от 1 до 4.294.967.295. Однако это вовсе не так. Например, если ТСР стек на хосте А ограничен window в 16К, стек должен получать все пакеты в пределах этого “окна” и атакующему не обязательно посылать пакеты с установленным RTS во всей последовательности SN, а ограничится только каждым возможным окном, так как ТСР примет любой Sequence number в пределах некоторого диапазона, заданного величиной окна. Таким образом нападающему надо перебрать 4.294.967.295 / 16.384 = 262.143 что бы попасть во все доступные окна.

    Вероятно и 262 тысячи может показаться большим числом, однако это не так. Во-первых, при хорошем коннекте атакующий способен генерить десятки тысяч пакетов в секунду. Во-вторых, атаку можно распределить по нескольким хостам. Например на стандартной DSL линии можно производить 250 пакетов в секунду, что исчерпает все варианты за 17 минут, при подключении на скорости 2 МБит/С это уже 4.730 пакетов и всего лишь 60 секунд.

    В примере рассмотрен пример окна в 16К, однако по RFC это поле 16 битное, что дает до 64К. Еесли используется полный его размер, то атакующему достается всего 65.537 пакетов, 4 и 15 секунд соответственно. Причем имейте ввиду, что это максимальное время, в среднем оно будет наполовину меньшим (на практике это 3 минуты и 8 секунд). Что касается описанных в уязвимости 4 пакетов, то она возникает только при использовании window scaling, ТСР расширении (см. RFC 1323) где размер “окна” увеличен с 16 до 30 бит (реализовано, например, и в описанном выше BGP). В случае максимального размера атакующему действительно придется послать только 4 пакета что бы реализовать TCP Reset.

    Source Port

    Все приведенные выше примеры опираются на то, что атакующий знает порт назначения и IP адрес, порт исходный и исходный адрес. Первые два параметра доступны и известны, IP адрес получателя так же не составляет труда узнать – это адрес клиента которого спуфим. Единственный вопрос – исходный порт. Например если ОС случайным образом выдает порт из пула от 1025 до 49.152 (так как например делает OpenBSD), это увеличит количество попыток ровно в 48.127 раз, так как надо будет попробовать подловить номер SN с каждым номером порта. Хорошая новость в том, что большинство ОС, включая Linux и Windows, не используют такой механизм, что сводит на нет вероятность такой защиты.

    reset-tcp.c exploit или сплохи средь бела дня

    Paul Watson оказался на редкость щедрым и выложил в сеть написаный им reset-tcp.c эксплоит, который собирается достаточно просто даже на простеньком Debian Linux. 

    оператор ТрансТелеком перехват bgp-сессии в реальном времени

    Перед сборкой советую проверить наличие в системе необходимой библиотеки libnet-1.1.1 и доставить её в случае отсутствия:

    apt-get install libnet1-dev

    после успешной установки библиотеки в систему переходим к сборке бинарника сплоита:

    gcc reset-tcp.c -o reset-tcp /usr/lib/libnet.a
    или
    gcc -o reset-tcp reset-tcp.c -lnet

    ** можно также поменять предварительно MAC адрес (enet_src/enet_dst) в коде, во избежание лишних проблем со своим интернет-провайдером, которые могут возникнуть в процессе эксплуатации сплоита

    пример запуска:
    reset-tcp [interface] [src ip] [src port] [dst ip] [dst port] [window size]

    [root@orc EuroTransTelecom]# ./reset-tcp eth1 172.16.0.1 1 172.16.0.2 2 65536

    Packets sent: 8192 Sequence guess: 536805376
    Packets sent: 16384 Sequence guess: 1073676288
    Packets sent: 24576 Sequence guess: 1610547200
    Packets sent: 32768 Sequence guess: 2147418112
    Packets sent: 40960 Sequence guess: 2684289024
    Packets sent: 49152 Sequence guess: 3221159936
    Packets sent: 57344 Sequence guess: 3758030848
    packets sent: 65535

    SYN атака

    Reset атака может быть выполнена и без RST бита. Вместо него можно установить SYN бит выполнив точно такую же атаку, что была описана выше. На большинстве реализаций TCP стека в случае получения повторного SYN будет выслан RST с sequence number. Если SYN входит в “окно” текущей сессии, то вместо с RST ответом сессия будет прекращена, а система вероятно даже перезагружена.

    Blind data injection

    Наконец и третий, но далеко не последний вариант развития событий. Делается все так же как и в предыдущих случаях – брутфорсом подбирается sequence number, только вместо посылки пустых SYN или RST пакетов лепим нормальный пакет с данными. Соединение в таком случае не прервется, а вот что у пользователя соберется на компьютере – совершенно непонятный вопрос. Передаваемые данные будут катастрофически повреждены.

    Более подробно обсудить вопросы практического применения описанного в материале со мной можно в личных сообщениях. Контактные данные указаны в соответствующем разделе на сайте.

  • MyEtherWallet.com, BGP Hijacking Kullanarak Gerçekleştirilen Dolandırıcılık

    MyEtherWallet.com, BGP Hijacking Kullanarak Gerçekleştirilen Dolandırıcılık

    Daha önce bilinmeyen bir Bitcoin ve Ethereum yatırımcısı, BGP protokolünü, BGP sahtekarlığı komut dosyalarını ve bir BGP oturum ele geçirme uygulamasını kullanarak, Amazon Route 53 DNS trafiğini Rusya’daki web sunucusuna başarıyla yönlendirdi. Bu durum, meşru MyEtherWallet.com web sitesinin birkaç saatliğine farklı görünmesine ve kripto paranın üçüncü taraf bir Ethereum web cüzdanına aktarılmasına neden oldu. Bu taktik bazen “kötü ikizleme” olarak adlandırılır.

    Bir internet servis sağlayıcısının BGP oturumu ele geçirildiğinde önekin nasıl duyurulduğu

    MyEtherWallet web sitesinin bir klonunu kullanan bir kimlik avı saldırısı, iki saat içinde 215 ETH değerinde kripto paranın çalınmasına yol açtı.

    Sahte rota değişikliği, ABD’nin Columbus şehrinde bulunan büyük bir internet servis sağlayıcısı olan eNet AS10297 adına gerçekleştirildi. BGP oturumunun ele geçirilmesinin ve yeni BGP rota duyurularının yayınlanmasının ardından, Level3, Hurricane Electric, Cogent ve NTT gibi büyük sağlayıcılar da dahil olmak üzere eNet’e komşu tüm düğümler, trafiği saldırganlar tarafından belirtilen rota üzerinden Amazon Route 53’e yönlendirmeye başladı. Sahte BGP duyurusu nedeniyle, Amazon alt ağlarına (yaklaşık 1300 IP adresi) yapılan istekler iki saat boyunca saldırgan tarafından kontrol edilen ve Chicago’daki bir Equinix veri merkezinde bulunan bir sunucuya yönlendirildi; burada DNS yanıtlarını taklit etmek için bir “ortadaki adam” saldırısı gerçekleştirildi.

    Sahte DNS ayarları nedeniyle, MyEtherWallet.com kullanıcıları, kendinden imzalı bir HTTPS sertifikası kullanan sahte bir web sitesine yönlendirildi ve bu da tarayıcıda güvenlik sorunlarıyla ilgili uyarılara neden oldu. Bu durum, bilinmeyen bir yatırımcının mevcut döviz kuru üzerinden yaklaşık 137.000 dolarlık kripto parayı cüzdanlarına aktarmasını engellemedi. Eğer meşru kullanıcı kimlik avı sitesinde başarılı bir şekilde kimlik doğrulamasını tamamladıysa, tüm fonları MyEtherWallet’ten çekildi. Saldırganın veya işlemleri gerçekleştiren yatırımcı olarak kabul edilebilecek kişinin çok zengin bir birey olduğu ortaya çıktı: Saldırı sırasında transferlerin yönlendirildiği ETH cüzdanlarından birinde şu anda 24.276 ETH bulunuyor, bu da 15 milyon dolardan fazla bir değere denk geliyor.

    Saldırganlar, kurbanların bir uyarıya tıklamasını gerektiren özel bir sertifika yerine, tarayıcı tarafından güvenilen bir TLS sertifikası almış olsalardı, çalınan miktar muhtemelen daha yüksek olurdu.

    Bunlar, yakalanan adres alanına yerleştirilen DNS kayıtlarıdır

    Bazı siber güvenlik araştırmacıları, büyük bir internet servis sağlayıcısının BGP yönlendiricisine erişimin ve büyük miktarda DNS trafiğini yönetme kaynaklarının, saldırının MyEtherWallet.com dolandırıcılığıyla sınırlı olmadığını gösterebileceğine inanıyor; saldırıda kullanılan bilinmeyen bir yatırımcının ETH cüzdanına yapılan sürekli transferler de bu hipotezi destekliyor.

    Açıkçası, BGP oturum ele geçirme saldırıları sonucu IP adreslerinin kontrolünü kaybeden tek bulut operatörü Amazon değil. BGP’nin beceriksiz yapılandırma hatalarına ve açık dolandırıcılığa karşı savunmasızlığı yirmi yılı aşkın süredir ortada. Sonuç olarak, bu güvenlik eksikliği telekomünikasyon sektöründe sektör genelinde bir sorundur ve Amazon tek başına bunu çözemez.

    Bu konuyu benimle özel mesaj yoluyla daha detaylı olarak görüşebilirsiniz. İletişim bilgilerim bu web sitesinin ilgili bölümünde yer almaktadır.

  • Скам MyEtherWallet.com при помощи BGP Hijacking

    Скам MyEtherWallet.com при помощи BGP Hijacking

    Один пока никому не известный специалист по процессингу btc и eth, используя протокол BGP и сценарии bgp route hijacking вместе с реализацией захвата bgp-сессии, успешно перенаправил трафик DNS-сервиса Amazon Route 53 на свой сервер в России и несколько часов подменял (bgp route leaking) настоящий сайт MyEtherWallet.com с реализацией web-кошелька криптовалюты Ethereum. Такую тактику ещё иногда называют Атака Evil Twin.

    префикс 205.251.192.0/24 объявлялся из сети eNet в сети Hurricane Electric и TDS Telecom

    На подготовленном нарушителем клоне сайта MyEtherWallet была организована фишинг-атака, которая позволила за два часа угнать 215 ETH в криптовалюте на кошельки неразводных дропов.

    Подстановка фиктивного маршрута (bgp route injection) была осуществлена от имени крупного американского интернет-провайдера eNet AS10297 в Колумбусе штат Огайо. После перехвата BGP-сессии и осуществления кастомного BGP-анонса, все пиры (peering partners) сети eNet, среди которых такие крупнейшие операторы, как Level3, Hurricane Electric, Cogent и NTT, стали заворачивать трафик к Amazon Route 53 по заданному нарушителем маршруту через сеть eNet. Из-за фиктивного анонса BGP (bgp spoofing) запросы к 5 подсетям /24 Amazon (около 1300 IP-адресов) в течение двух часов перенаправлялись на подконтрольный нарушителю сервер, размещённый в дата-центре провайдера Equinix в Чикаго, на котором и была организована MiTM-атака по подмене ответов DNS.

    Через подмену параметров DNS (dns spoofing) пользователи MyEtherWallet.com перенаправлялись на поддельный сайт, на котором использовался самоподписанный HTTPS-сертификат, для которого браузеры выдают предупреждение о проблемах с защищённым соединением, что не помешало в ходе грубого фишинга слить криптовалюты на сумму около 137 тысяч долларов по текущему курсу на кошельки неразводных дропов (в случае аутентификации на фишинговом сайте у пользователя списывались все средства с кошелька). Примечательно, что нарушитель или как его ещё можно назвать трейдером процессинга, оказался очень состоятельным человеком – на одном его ETH-кошельке, на который в ходе атаки перенаправлялись переводы, в настоящее время находится 24276 ETH, что составляет более 15 млн долларов США.

    Достоверно известно, что в ходе атаки была осуществлена подмена DNS для сайта MyEtherWallet.com, тем не менее, могли пострадать и другие клиенты сервиса Amazon Route 53. По мнению некоторых исследователей безопасности, получение доступа к BGP-маршрутизатору крупного ISP и наличие ресурсов для обработки огромного DNS-трафика может свидетельствовать, что атака не ограничилась только лишь MyEtherWallet.com (в пользу данной гипотезы также говорит непрекращающийся поток переводов на ранее использованный в ходе атаки ETH-кошелёк).

    получение доступа к BGP-маршрутизатору крупного ISP и наличие ресурсов для обработки огромного DNS-трафика

    По другим предположениям, имел место лишь тестовый эксперимент перед проведением более массированных атак с применением bgp route hijacking.

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

  • Работа в процессинге с использованием CarberP

    Работа в процессинге с использованием CarberP

    С банковским ботом CarberP я познакомился не так давно, в первой половине прошлого года, и можно сказать, что этот финансовый троян процессинга фиата и крипты имеет отличный потенциал, он использует достаточно большое количество необычных функций для обхода эвристических алгоритмов современных антивирусов и сканеров. «Полезная» нагрузка же делает его сравнимым с Zeus’ом или SpyEye

    С чего же все началось?

    Когда я исследовал образец этого банковского бота, то из пяти экземпляров, посланных на VirusTotal.com, только один определялся многими антивирусами, а у остальных четырёх количество обнаружений было гораздо меньшим. Сравнив все экземпляры при помощи плагина BinDiff для IDA, я обнаружил, что код был идентичным. Посмотрев внимательнее на файлы в редакторе HIEW, картина стала проясняться. Во-первых, отличались некоторые поля PE-заголовка. Во-вторых, в первой секции «.text» не было кода вообще, а единственное, что там было прописано, — имена двух библиотек (kernel32.dll и advapi32.dll), а также название одной функции (EqualPrefixSid), которые окружены случайными последовательностями байтов. Эти данные используются при распаковке банковского бота, и наконец, отличались таблицы релокаций. Предпоследние секции «.reloc» были различного размера, и сами значения релоков также не совпадали. Именно эти три отличая позволяли банковскому боту успешно обходить сигнатуры безопасности антивирусов.

    сигнатуры банкера CarberP для работы процессинга

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

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

    Временные файлы

    При анализе мной этого банковского бота сначала было не понятно, зачем же он создает временные файлы, копируя в них стандартные библиотеки Windows (ntdll.dll, kernel32.dll и ws2_32.dll). Оказалось, что это делается для безопасности для самого банкера. После создания копии библиотеки, он отображает её к себе в память, находит нужные ему при работе функции и сравнивает первые 10 байт с теми, что находятся в импортированной библиотеке. Если они не совпадают, значит какая-то «недобрая» программа поставила хук на эту функцию, и банковский троян сразу восстанавливает эти 10 байт из оригинальной библиотеки, а точнее — из образа её копии. Поэтому с уверенностью могу сказать, что желающие поизучать внутренности Carberp’а могут отложить API Monitor на дальнюю полку своего жесткого диска 🙂 Он тут вам ничем не поможет.

    Вызовы API-функций также сделаны с изюминкой. В программе банкера присутствует механизм, который получает на вход константу, а на выходе высчитывает необходимый адрес. Конечно, этот подход значительно затрудняет статический анализ банковского бота, хотя также имеет и свои минусы — если поставить точку останова на конец функции расшифрования, то легко можно отследить последовательность вызова функций, а написав парочку сценариев для OllyDbg и IDA, можно восстановить их названия и без проблем статически исследовать код. В одной из исследуемых мной версий трояна также использовалось шифрование всех текстовых строк, используемых программой, что значительно затруднило анализ его возможностей процессинга  платежей в банковских системах SWIFT или SEPA для работы в еврозоне.

    Завоевание новых территорий

    Во многих троянах процессинга код «полезной нагрузки» не выполняется при первом запуске — он инжектируется в какой-то уже работающий процесс и начинает действовать уже там. Этот банковский бот — не исключение, и для внедрения он использует процесс explorer.exe. Только делает он это очень необычно.

    средства защиты от обнаружения CarberP бота процессинга

    Первым делом, процесс вызывает функцию CreateProcess с выставленным флагом CREATE_SUSPENDED, тем самым создавая новый, приостановленный дочерний процесс explorer. exe. Затем вызовом функции ZwCreateSection создается объект «секция» (SectionObject — это часть памяти, которая может разделяться между разными процессами) со всеми возможными правами (чтение, запись, исполнение). Далее секция мапится в контекст трояна функцией ZwMapViewOfSection и при помощи memcpy банковский бот процессинга копирует свою распакованную копию в эту область памяти. После этого, секция отображается в контекст дочернего explorer.exe, и тем самым туда заносится код банковского бота. Но это еще не конец, ведь код банкера должен также выполниться explorer’ом. Для этого функцией ReadProcessMemory из процесса explorer.exe копируется место, где находится спроецированный исходный файл, в контекст трояна процессинга. Создается ещё одна секция, которая сначала отображается в троянскую программу, а потом в неё с помощью memcpy копируется полученная из explorer’а часть памяти. Следующим шагом патчатся несколько байт на точке входа таким образом, чтобы происходил прыжок на функцию процессинга денежных средств холдера банковского счета. И наконец, секция отображается в контекст explorer’а на то место, где раньше находился исходный образ.

    Теперь все готово для запуска дочернего explorer’а. Троян вызывает ZwResumeThread, тем самым запуская исполняемый код, уже находящийся в другом процессе. Получив управление в новом месте, Carberp начинает работать в полную силу, запуская свои встроенные функции payload’а и внедряясь во все запускаемые процессы. Естественно, во всех новых захваченных территориях банковский бот также производит описанную выше проверку на наличие хуков в необходимых ему API-функциях.

    В более новой версии Carberp’а мной был обнаружен другой способ внедрения порожденного процесса explorer.exe. Первые шаги остались неизменными — сначала создается глобальная секция, которая мапится в дочерний процесс, и туда копируется исполняемый код. А дальше вызывается недокументированная функция ZwQueueApcThread, которая ставит в очередь на выполнение в explorer’е асинхронный вызов одной из функций процессинга, находящихся в образе секции. При вызове ZwResumeThread начинается выполнение банковского перевода в фиате.

    Игра в прятки

    Прежде чем обсуждать функции, которыми может похвастаться данный банковский троян, мне стоит разобрать ещё несколько интересных моментов его жизни. Конечно же, как и любой уважающий себя бот, Carberp прописывается в автозагрузку, причем банально копируя себя под случайным именем в директорию %HOMEDRIVE%%HOMEPATH%StartMenuProgramsStartUp. Тем не менее, не все так просто! В самом боте предусмотрен механизм, позволяющий скрыть присутствие файла в системе.

    После внедрения трояна в дочерний explorer.exe, вызываются механизмы, которые инжектируют его в исходный explorer. Сначала происходит поиск PID-процесса. Стоит отметить, что в программе заложено два способа поиска. Первый способ заключается в последовательном вызове функций FindWindow (“Shell_ TrayWnd”, 0) и GetWindowThreadProcessId (hWnd, &id), таким образом, в переменной id должен появиться нужный PID. Если же по какой-то причине функция вернула «id=0», то происходит обыкновенный перебор процессов и поиск нужного.

    именно такие команды от сервера получает CapberP бот процессинга

    Когда заветный PID найден, программа внедряется в explorer давно известным способом — ZwOpenProcess + WriteProcessMemory. Также бот процессинга делает хук двух функций в захваченном процессе — NtQueryDirectoryFile и NtResumeThread из библиотеки ntdll.dll. Чтобы уйти от обнаружения некоторыми антивирусами (например, RootkitUnhooker), хук делается не совсем стандартным способом. Троян подменяет не адрес нужной функции, а адрес функции KiFastSystemCall. Так для чего же подменяются функции? NtQueryDirectoryFile перебирает все файлы, находящиеся в директории. Она вызывается почти во всех программах (в том числе в explorer и cmd) при обзоре каталогов файловой системы. Её подмена необходима для того, чтобы скрыть факт присутствия файла. NtResumeThread вызывается explorer’ом при смене директории и при запуске приложения. Таким образом, если explorer заражен, то при запуске любого приложения программная «закладка» определяет PID запускаемого процесса и инжектится в него, также подменяя вышеупомянутые функции. Легко понять, что при старте системы троян автоматически запускается, внедряется в explorer, а соответственно и все порожденные им процессы.

    На этом заканчивается список средств защиты, используемых Carberp’ом. Полный список средств защиты, применяемый этим трояном, приведен в таблице 2.

    Начинка

    Разобравшись со всеми защитными механизмами трояна процессинга, я приступил к изучению вирусной начинки. Оказалось, что в нём имеет место вполне стандартный функционал сбора и копирования пользовательских данных и процессинга денежных средств на банковские счета неразводных дропов, сравнимый с функционалом того же IBank’а или Zeus’а, дополненный неплохим протоколом обмена данных между компьютерами холдеров и трейдера. Собирая по всей системе пользовательские сертификаты, пароли к учетным записям и прочей важной информации, добытые с помощью работающего кейлоггера и снятия скриншотов рабочего стола, бот процессинга упаковывает все найденное в cab-архив и готовит его к отправке.

    Общение с сервером трейдера

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

    Этап установки соединения

    1 — Заряженый компьютер или смартфон

    1. Установка соединения с сервером 1.
    2. Отправка строки GET-запросом, предусматривающей указание параметров:

    • uptime;
    • downlink;
    • uplink;
    • id (зашифрованная строка, содержащая информацию о зараженной системе);
    • statpass (начальный пароль);
    • comment.

    Вот пример такого запроса:

    /stat?uptime=<val1>&downlink=<val2>&uplink=<val3>
    &id=<val4>&statpass=<val5>&comment=<val6>

    3. Ожидание приема информации от сервера.

    2 – Сервер трейдера (оператора процессинга)

    1. Отправка информации заряженому компьютеру. Могут быть отправлены следующие коды:

    • ok;
    • badpass;
    • session: <№ сессии>.

    3 — Компьютер холдера (владельца банковского счёта)

    1. Распознавание полученной от сервера информации:

    • ok — соединение установлено;
    • badpass, session — повторная передача начальной информации от сервера.

    Этап передачи данных

    1 — Компьютер холдера (владельца банковского счёта)

    1. Отправка строки POST-запросом на сервер 2, предусматривающей указание параметров:

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

    Передаваемая строка может выглядеть так:

    1|palladin|05B45905A93F7D4B843D385AAE079AF1|0|0

    А зашифрованная следующим образом:

    a=e15e327af46a915c1b0014a284c052787ea7d63c8c40b1
    a3dcafea6bb8e7076b0f6601861783dff7cbca429eb76a47

    Шифрование строки сопровождается дополнением избыточности.

    2. Отправка сформированного .cab-файла с похищенной информацией серверу 2.

    3. Периодически происходит проверка установленного соединения. Данное действие аналогично предыдущему, за исключением того, что передается строка:

    0|check|00000000000000000000000000000000|

    2 — Сервер трейдера (оператора процессинга)

    1. На стороне сервера осуществляется расшифровка принятого сообщения. Отправка уведомления об успешном приеме проверочного пакета.

    2. Отправка информации зараженной машине. Вот что сервер может отправить в зависимости от версии троянца.

    3 — Компьютер холдера (владельца банковского счёта)

    1. Распознавание принятой информации.

    Надо сказать, что передачу информации Carberp осуществляет грамотно: инициализация связи сопровождается зашитым в троян паролем, состояние канала связи периодически проверяется специальными пакетами, передаваемая информация шифруется, а шифротекст при этом наполняется избыточностью. Более того, возможно удаленное управление ботом процессинга — в разбираемой версии присутствовал функционал по разбору команд от удаленного сервера трейдера.

    распознание принятой информации ботом процессинга

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

    Дополнительные возможности

    Дополнительную мощь трояну процессинга добавляют специальные плагины, которые он загружает вдобавок к основному функционалу. На момент моего исследования было три зашифрованных плагина с символичными именами miniav.plug, killav.plug и passw.plug (именно в таком виде их удалось достать с сервера трейдера, с которым Carberp и взаимодействовал).

    взаимодействие бота процессинга с сервером управления CarberP

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

    Действительно, miniav.plug занимается устранением конкурентов — если на компьютере или смартфоне холдера помимо Carberp’a присутствует другой бот процессинга, например, тот же самый Zeus, то последний безжалостно удаляется из системы. Плагин killav.plug нейтрализует работу антивирусных систем, ну а passw.plug способен перехватывать вводимые холдером пароли от любых сервисов.

    Более подробно обсудить со мной вопрос практического применения этого материала можно в личных сообщениях. Контактные данные указаны в соответствующем разделе этого сайта.