Малварь как искусство Эволюция ботов. Приват с Хакера

Тема в разделе "Технологии создания невидимой малвари", создана пользователем virt, 8 окт 2017.

↑ ↓
  1. virt Уважаемый пользователь
    virt
    Ответить в чате

    Форумчанин

    Регистрация:
    24.11.2016
    Сообщения:
    289
    Симпатии:
    74
    Пол:
    Мужской
    Репа:
    +126 / 4 / -2
    Оригинал и поблагодарить редакцию за статью можно тут:Эволюция ботов. Как владельцы ботнетов скрывают свои сети и обходят ограничения - «Хакер»

    В мире существуют разные боты. Например, боты, которые бороздят просторы морей, или просто стоят на месте — как, например, буддистские боты (если что, это такая религиозная постройка). Но если ты читаешь ][, то наверняка догадался, что речь пойдет не про вышеописанных ботов и даже не про ископаемые бабушкины чеботы, а про автономно действующие вредоносные программы, способные выполнять поступающие извне команды и объединяться в ботнеты.
    Одним из первых крупнейших ботнетов принято считать сеть, созданную в 2004 году с помощью почтового червя Beagle. Этот червь имел собственную реализацию протокола SMTP, с помощью которой рассылал себя по электронной почте. Заодно в нем был руткит-модуль, который позволял ему скрывать свое присутствие на зараженной машине.

    С тех пор человечество пережило множество нашествий бот-сетей различного калибра. Ушел в историю и Rustock, спамивший с пулеметной скоростью в 192 письма за минуту, и Conficker, заразивший 10,5 млн машин по всему миру. Это, к слову, был первый в истории ботнет, за любые сведения о создателях которого парни из Microsoft предложили награду в 250 000 долларов. «Wanted, dead or alive», как пел когда-то старик Бон Джови.


    Немного об авторе
    Как ты знаешь, в ][ пишут не журналисты, а IT-спецы. Павел Шалин — один из таких. Он работает аналитиком в компании Dr.Web, и при этом ухитряется плодотворно писать под псевдонимом «Валентин Холмогоров», и не только на тему малвари и хакерства, но и довольно популярную фантастику. Из книг Павла, написанных на близкие любому хакеру темы, мы бы тебе посоветовали прочесть «Бумажное небо» и «PRO Вирусы».


    Первые бот-сети были примитивными. Они имели простую звездообразную структуру, в центре которой располагался управляющий сервер (Command and Control Server, C&C), а на вершинах лучей звезды — инфицированные хосты. Команды и конфиги передавались ботам по стандартным протоколам, например, через старый добрый IRC. В этом случае трой подключался к определенному каналу и начинал слушать команды, которые ботовод отправлял прямо в чат. Самое слабое место такой архитектуры очевидно: достаточно грохнуть центральный сервер, и сеть становится неуправляемой, а отдать ботам команду на смену C&C уже не получится.

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

    На этом домене и поднимается управляющий сервер. Если этот сервак однажды прикажет долго жить, нужно лишь зарегистрировать следующий и запустить на нем админку. В свою очередь, бот, не получив отклика от своего C&C, генерирует несколько новых адресов и начинает опрашивать их по очереди, пока не найдет работающий.

    Живучесть ботнета, таким образом, заметно повышается, да и ботовод получает уникальную возможность сберечь пару шекелей: некоторые регистраторы в погоне за прибылью позволяют своим клиентам регистрировать домены сейчас, а платить за это потом. Если деньги не поступают, домен через какое-то время просто отрубается. Используя этот лайфхак, некоторые особо прижимистые ботоводы меняют C&C раз в пару недель, экономя себе копеечку на пиво.

    Некоторые ботоводы параллельно использовали сразу несколько управляющих серверов на отдельных доменах, разбивая свой ботнет на подсети. Вот так, например, выглядит дизассемблированный фрагмент модуля DGAвируса Win32.Rmnet (для генерации доменных имен используется алгоритм LCG, линейный конгруэнтный метод).

    seg074:2001A91C create_next_domain proc near
    thread_start+36 p
    seg074:2001A91C
    seg074:2001A91C seed = dwordptr -4
    seg074:2001A91C initial_seed = dwordptr 8
    seg074:2001A91C hostname = dwordptr 0Ch
    seg074:2001A91C
    seg074:2001A91C push ebp
    seg074:2001A91D movebp, esp
    seg074:2001A91F add esp, 0FFFFFFFCh
    seg074:2001A922 push ebx
    seg074:2001A923 push ecx
    seg074:2001A924 push edx
    seg074:2001A925 push esi
    seg074:2001A926 push edi
    seg074:2001A927 push 12
    seg074:2001A929 push [ebp+initial_seed]
    seg074:2001A92C call rand_int_modulus
    seg074:2001A931 mov [ebp+seed], edx
    seg074:2001A934 add eax, 8
    seg074:2001A937 movecx, eax
    seg074:2001A939 movesi, [ebp+hostname]
    seg074:2001A93C
    seg074:2001A93C loc_2001A93C: create_next_domain+2Dj
    seg074:2001A93C push 25
    seg074:2001A93E push edx
    seg074:2001A93F call rand_int_modulus
    seg074:2001A944 add al, 'a'
    seg074:2001A946 mov [esi], al
    seg074:2001A948 incesi
    seg074:2001A949 loop loc_2001A93C
    seg074:2001A94B mov byte ptr [esi],
    seg074:2001A94E push offset tld_com
    seg074:2001A953 push [ebp+hostname]
    seg074:2001A956 call j_lstrcatA
    seg074:2001A95B xoredx, edx
    seg074:2001A95D moveax, [ebp+initial_seed]
    seg074:2001A960 movebx, [ebp+seed]
    seg074:2001A963 mulebx
    seg074:2001A965 add eax, edx
    seg074:2001A967 pop edi
    seg074:2001A968 pop esi
    seg074:2001A969 pop edx
    seg074:2001A96A pop ecx
    seg074:2001A96B pop ebx
    seg074:2001A96C leave
    seg074:2001A96D retn 8
    seg074:2001A96D create_next_domain end


    Очевидно, что и такой подход имеет свою слабую сторону, а именно, он позволяет засинкхолить домен.

    Sinkhole (англ., «выгребная яма») — этим звучным термином именуется методика перехвата управления ботнетом, подразумевающая получение полного контроля над бот-сетью с возможностью не только осуществлять мониторинг и отслеживать состояние сети, но и отдавать команды ботам.


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

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

    Для защиты от такого беспредела со стороны антивирусных компаний вирмейкеры придумали разные ухищрения — протоколы обмена данными между ботом и C&C стали снабжать шифрованием. Впрочем, подобные механизмы используются в малвари и без DGA. Да и вирусописателям это, в общем-то, не помогло: против дизассемблера, как и против лома, нет надежного приема.

    Поэтому следующим этапом развития бот-сетей стало использование технологии P2P (Peer-To-Peer) или построение пиринговых одноранговых сетей. Такие сети вовсе не используют управляющих серверов, вместо этого они «общаются» с другими инфицированными компьютерами, передавая команды по сети от «точки к точке», по тому же принципу, что и торренты.

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

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

    Подключенный к интернету компьютер может не иметь собственного внешнего IP-адреса, если в сети используется NAT (Network AddressTranslation). Поэтому заразив компьютер, Win32.Sector проверяет, есть ли у машины внешний айпишник. Если есть, то тогда бот становится нодой (Node), то есть начинает играть роль маршрутизатора для других зараженных машин (Bot), не имеющих реального внешнего IP-адреса.

    Инфицированные компьютеры типа Bot начинают «общаться» с интернетом и другими зараженными узлами через ноду. Каждый инфицированный узел такой сети получает начальный список из ста IP-адресов других ботов, с которыми он пытается установить соединение, причем этот список периодически обновляется. При подобной структуре сети потеря одной ноды (например, если владелец компьютера вылечит его от вируса) ничем не грозит всей системе в целом: бот просто подключится к другой ноде для получения дальнейших управляющих команд.
    [​IMG]
    Существуют и более сложные ботнеты, которые можно отнести к смешанному типу. Например, Trojan.Dridex.49 для связи с управляющими серверами использует сложную одноранговую бот-сеть, которая состоит из двух промежуточных слоев прокси. Заразив компьютер, Trojan.Dridex.49 может принять на себя одну из трех возможных ролей:

    • Bot — трояны этого типа работают на компьютерах, не имеющих внешнего IP-адреса. Bot осуществляет связь с управляющим сервером через троянов с ролью Node.
    • Node — трояны этого типа работают на компьютерах с внешним IP-адресом и передают данные от ботов выше — к троянам с ролью AdminNode, а также в обратном направлении.
    • AdminNode — как ты мог догадаться, «админская нода». Высшая ступень, на которой экземпляры трояна осуществляют связь друг с другом, а также непосредственно с управляющим сервером.
    Таким образом, цепочка связи инфицированного компьютера без внешнего IP с управляющим сервером ботнета, выглядит в общем случае следующим образом: Bot → Node → AdminNode → другие AdminNode → C&C. При этом для обеспечения безопасности соединения экземпляры трояна обмениваются между собой цифровыми ключами. Структура этой сети показана на иллюстрации.

    [​IMG]
    [​IMG]
    Чтобы получить с управляющего сервера новый перечень IP-адресов ботов с ролью Node или конфигурационных данных, необходимых для выполнения веб-инжектов, трояны с ролью Bot передают запрос экземпляру с ролью Node, и тот переправляет его админской ноде. Она в свою очередь может перебрасывать его другим AdminNode до тех пор, пока запрос не достигнет управляющего сервера.

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

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

    Например, запустившись на целевом компьютере, такой троян может расшифровать из собственного конфигурационного файла список других ботов с ролью Node и попытаться установить с ними соединение. А если наладить связь не удалось, он сгенерирует перечень доменов по алгоритму DGS и попытается получить актуальный список нод оттуда.

    При этом ресурсы на этих доменов — это не управляющие серверы. Они просто хранят перечни IP-адресов нод, которые и отдают ботам по запросу. Связь с истинным управляющим происходит через отдельные ноды, которые работают как туннелирующий сервер. Сам злоумышленник, управляющий ботнетом, тоже передает команды C&C не напрямую, а через туннель — чтобы лучше замести следы.
    [​IMG]
    В последние годы стали появляться новые схемы ботнетов — с использованием Tor и облачных технологий. Еще в 2008 году были выявлены трояны, которые получали команды с определенной учетной записи в Twitter и в специально созданной вирусописателями ветке Google Groups.

    Для хранения компонентов вредоносных программ, которые могут быть загружены и установлены на инфицированной машине, нередко используются облачные сервисы Google Docs и Google Drive. Например, Google Docs для обмена данными с C&C использовала обнаруженная в 2012 году вредоносная программа-бэкдор BackDoor.Makadoc.

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

    В процессе обработки запросов Google Docs Viewer даже не требовал у клиента авторизации в Google Docs — он просто перенаправлял их на командный сервер, что еще больше облегчило задачу киберпреступникам.

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