Ал Эк говорит, что у него даже есть рабочие исходники

Сегодня развитие малвари и антивирусных технологий переживает спад — идеи закончились. В середине 2000-х годов прорывной идеей казался переход вредоносного кода на уровень ядра, но теперь на пути честных малварщиков выросли новые препоны, и прямой доступ в ядро был зарублен. Сегодня приходится серьезно изворачиваться, чтобы подобраться к ring 0.

Приходится констатировать факт, что с обнаружением семейства TDL/TDSS борьба добра и зла все-таки протекает с небольшим перевесом в сторону зла. Антивирусы толком не научились (или не хотят учиться?) бороться с современной малварью, а на горизонте уже маячит вирусня с элементами гипертрейдинга и искусного манипулирования железом.

Как устроен файрвол?

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

Создание нового соединения довольно успешно отслеживается путем перехвата соответствующих сетевых WinAPI-функций или внедрением собственных сетевых объектов в сетевой стек. Этим решается вторая, не менее важная задача файрволов — контроль за самим сетевыми соединениями. Например, предполагается, что если внедрение кода в доверенный процесс (например, svchost.exe) прошло успешно, то некоторые файры спокойно относятся к новым соединениям, устанавливаемым данным процессом. Однако приходится следить за тем, к каким именно внешним IP-адресам идет обращение процесса, ведь, если доверенному процессу разрешено по правилам файрвола устанавливать соединения, этим пользуются разработчики централизованных ботнетов, того же самого ZeuS, SpyEye и других. В этой связи файрвол должен иметь список «черных» IP-адресов (де)централизованных серверов управления. Ведь стоит один раз такому серверу попасть в черный список, и ботнет можно хоронить. Неудивительно поэтому, что в настоящее время ботоводы пытаются создать некую систему децентрализованного управления ботнетами, стараясь создать некое подобие самообучаемости бота, когда сведения о центральном сервере добываются через рандомные источники, например от соседних ботов, или файлообменников. Как мне рассказывали, есть довольно любопытные примеры реализации такой децентрализованной системы… но это так, в качестве лирического отступления. Как действует файрвол и для чего это нужно, мы уже определились, едем дальше.

Немного истории

Как я уже говорил, процесс развития вирусных и антивирусных технологий всегда состязательный. И в роли догоняющего всегда остаются антивирусы. Вопрос обхода файрволов не исключение. Например, когда малварь лет этак пять назад начала плавно перемещаться в ядро системы, встал вопрос о сетевом управлении зверушками непосредственно из ядра. Это можно было сделать двумя способами, предоставленными сетевой инфраструктурой самой операционной системы: TDI и NDIS.

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

Однако с течением времени файры все же научились отслеживать сетевые соединения, созданные на уровне TDI (такое сетевое соединение будет выглядеть как установленное от имени процесса System).

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

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

Тем более что файрвол, реализованный на уровне NDIS, позволяет контролировать все сетевые соединения, и глубже уже некуда (ну, если не принимать во внимание закладки в EEPROM сетевой карты).

Вдобавок отмечу, что с появлением технологии PatchGuard возможность перехвата сетевых функций в ядре практически скатилась к нулю (PatchGuard’ом защищены файлы ndis.sys и tcpip.sys).

Тупик? Нет, начало!

Что остается делать честному малварщику?

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

И все-таки решение проблемы обхода файрволов есть.

Красивое, элегантное и самое главное — простое до одури (готов поспорить на то вино, которое ты обещал мне прислать, что ты гонишь насчет простоты. — Прим. ред.).

И заключается оно в том, что разработчики малвари его тупо не видят, да простят они меня, грешного пьяницу.

Как-то давным-давно, лет так пять назад, сидел я за компом, пил «Ахтамар» и экспериментировал с редиректом сетевых соединений в ядре, разрабатывая небольшой TDI-based драйвер (редирект по сути своей заключается в простой смене IP-адреса сетевого пакета).

В процессе экспериментов я пытался перенаправить сетевой пакет, направленный браузером на веб-сервер site1.xxx, на другой сайт — site2.xxx. С крайним для себя удивлением, граничившим с полным о[censored]ванием, я обнаружил, что, несмотря на подтвержденную смену айпишника пакета, пакет почему-то возвращался с первоначального веб-сервера site1.xxx. И только потом мою тупую голову осенило: пакет и в самом деле уходил на site2.xxx, и ключевым здесь оказалось именно то, что я посылал пакет на стандартный веб-сервер, которых в Сети миллионы.

Веб-сервер site1.xxx повел себя совершенно восхитительно — он принял пакет, переслал его на site1.xxx и результаты вернул мне! В процессе дальнейших изысканий обнаружилось, что так ведут себя 99,9% всех веб-серверов!

Итак, следи за рукой…

Как выглядит стандартный сетевой запрос браузера?

Примерно вот так:
"GET /page.html HTTP/1.1"
"Host: superhost.ru"
"User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5"
"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8"
"Accept-Language: ru,en-us;q=0.7,en;q=0.3"
"Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7"
"Keep-Alive: 300"
"Connection: keep-alive"
Примечание: Более подробную спецификацию всех полей стандартных запросов GET/POST ты сможешь найти в Сети.

Так вот, IP-адрес нужен фактически только для отправки пакета, самому веб-серверу он абсолютно неинтересен, сервер висит на 80-м порту и тупо анализирует весь сетевой поток, который приходит на этот порт.

Его интересуют прежде всего два поля: Host и то, что идет после GET. Веб-сервер, в случае если поле Host отличается от его «родного», сработает как прозрачный прокси, перенаправив сетевой пакет по указанному хосту, получит ответ и вернет его обратно нам!

В поле Host можно, кстати, указывать просто нужный IP-адрес, без имени хоста.

Итак, подведу промежуточный итог: чтобы средиректить сетевой пакет на нужный нам IP-адрес и скачать зверушку, изменять сам IP-адрес пакета не надо!

Нужно просто изменить поле Host на нужное и подправить поле GET, типа “GET /papkasvirusom/virus.exe HTTP/1.1rn”".

И файры на это покупаются, как дешевые портовые самые знаете кто :).

Как это происходит? Да очень просто — файрволу глубоко фиолетово, что там в полях сетевого запроса написано. 99% сетевых соединений — это сетевые шняги браузера, торрентов, менеджеров закачек, обновлений системы, которые то и дело что-то там GET’ят. GET! GET!GET! Таких запросов — тысячи, мы их просто не видим, потому что на стандартной новостной странице какого-то среднего сайта браузеру нужно закачать десятки картинок, гифок, анимации, скриптов и прочей фигни, о закачке которой нас никто не спрашивает.

Рекомендуем почитать:

Xakep #299. Sysmon

• Содержание выпуска
• Подписка на «Хакер»-60%

Все, что интересует файрвол в данном случае (доверенного соединения), — какой IP-адрес у пакета, чтобы сверить его с черным списком. Но так как сам IP мы оставляем в неприкосновенности, в итоге получаем потрясающую возможность скачивать то, что нам надо, с любого другого IP: тупой веб-сервер сам скачает все, что угодно.

Собираем все вместе

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

НЕ НУЖНО, в том-то и дело! Достаточно тихонечко сидеть где-то в системе, парсить новые контакты и при отлове выгодного для нас, то бишь 100%-но доверенного соединения подменить поле Host, скачать с какого-то левого адреса по описанной выше технике зловред и запустить его на исполнение. Как я уже говорил, ни один файр на такую хитрость не покупается!

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

Закачка скриптов и бинарников

Это вообще праздник. Суть в том, что сегодня практически на каждой интерактивной странице есть веб-скрипты. Что стоит отследить момент начала его скачки и подменить «законный» скачиваемый скрипт своим? В том-то и дело, что ничего! Невинный веб-сервер это легко позволит! Например, возьмем те же самые социальные сети, где зависает треть населения планеты Земля Солнечной системы, что в галактике Млечный Путь. Скриптов на страницах — мама не горюй, и каждый из них можно скомпрометировать! Вариант сигнатурного детекта не пройдет — скрипт (или тот же самый бинарник) может быть зашифрован. Делайте выводы, господа!

Pros & Cons, или вместо заключения

Техника довольно непростая (ты проспорил, она-таки непростая. — Прим. ред.), скажем прямо, она требует хорошего знания ТCP/IP-стека и сетевого программирования. Однако абсолютно рабочая, что могу засвидетельствовать лично. Выходов в такой ситуации для файров два. Во-первых, для доверенных соединений контролировать соответствие IP-адреса и соответствие доменного имени в поле Host данному IP-адресу. Однако, это очень трудозатратно и чревато сильными тормозами, потому что покаааааааа тааааааам DNS проверим, покаааа тааааам с IP-адреcом сверим…

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

Для полноты картины — чтобы «обезопасить» DNS-запросы аверов для реализации своих нехороших планов, если есть доступ к ядру, вполне можно осуществить подмену DNS-выдачи. В результате файр при попытке определить положительную корреляцию IP-адреса и DNS-запроса вполне может впасть в прострацию, что можно легко использовать в своих злобных планах.

Засим закончу. Удачного компилирования и да пребудет с тобой Сила!