Программа Tor бесплатна и доступна для большинства вычислительных платформ. В Ubuntu её можно установить командой apt-get install tor. Для других платформ, например Windows или Mac OS X, подходящий пакет можно загрузить со страницы загрузки Tor.^[1] В большинстве случаев следует устанавливать пакет «Installation Bundle» для своей операционной системы. Если вам потребуется дополнительная помощь, на веб-сайте также имеются пошаговые инструкции и видеоролики.

Далее в этом рецепте предполагается, что вы устанавливаете Tor в Windows, хотя для других платформ действия в основном совпадают. Сразу после установки Tor можно применять для анонимизации своей деятельности в Интернете. Вероятно, значительная часть ваших исследований будет проводиться через веб-браузер, поэтому необходимо направить веб-запросы через Tor. Сделать это довольно просто, поскольку в состав последних версий комплектов Tor входит расширение Firefox под названием Torbutton.^[2] На рисунке 1-2 показано, как выглядит эта кнопка во включённом и выключенном состояниях. После установки она находится в правом нижнем углу окна браузера.

Рисунок 1-2. Кнопка Torbutton в Firefox

Одним щелчком мыши можно включить или отключить использование Tor в браузере.

Если вы пользуетесь не Firefox либо решили не применять дополнение Torbutton, потребуется настроить браузер на работу с Tor в качестве прокси-сервера SOCKS4 или SOCKS5. При стандартной конфигурации Tor должен привязаться к локальному узлу (127.0.0.1) на TCP-порту 9050. Это означает, что он принимает подключения только с локального компьютера, но не от других систем вашей сети или из Интернета.

Чтобы настроить Internet Explorer (IE) для работы через Tor, выполните следующие действия:

1. Выберите Tools > Internet Options > Connections > LAN settings > [x] Use a proxy server for your LAN > Advanced. Откроется диалоговое окно Proxy Settings.

2. В строке Socks в первом поле адреса прокси-сервера укажите localhost, а в поле Port введите 9050.

На рисунке 1-3 показано, как должна выглядеть настроенная страница Proxy Settings в IE.

Рисунок 1-3. Параметры прокси-сервера Internet Explorer

Firefox можно настроить для использования Tor в качестве прокси-сервера SOCKS следующим образом:

1. Выберите Tools > Options > Advanced > Network > Settings > Manual proxy configuration. Откроется диалоговое окно Connection Settings.

2. В поле SOCKS Host введите localhost, а в поле Port - 9050 (можно выбрать как SOCKS v4, так и SOCKS v5).

На рисунке 1-4 показано, как должна выглядеть настроенная страница Connection Settings в Firefox.

Рисунок 1-4. Параметры подключения Firefox

Теперь всё готово: можно просматривать веб-страницы, проводить исследования и обращаться к содержимому анонимно. Чтобы убедиться, что ваши действия действительно стали анонимными, рекомендуем быстро открыть сайт наподобие www.ipchicken.com или www.whatsmyip.org и проверить, что возвращённый им IP-адрес не совпадает с IP-адресом вашей системы. Если адреса различаются, всё работает правильно и вы можете анонимно заниматься своими делами.

Tor представляет собой прекрасную службу, однако и у неё есть недостатки. Они могут влиять на скорость просмотра веб-страниц, безопасность и целостность передаваемых по сети данных, а также на возможность доступа к ресурсам. Не позволяйте этим проблемам остановить вас, но обязательно помните об их существовании.

На момент написания книги главная претензия к Tor состояла в том, насколько медленным мог оказаться просмотр веб-страниц для конечного пользователя. Это очень хорошо известная проблема, возникающая по нескольким причинам. Ваше соединение может проходить через самые разные точки земного шара, накапливая задержки по пути; кроме того, у некоторых узлов Tor может быть малая пропускная способность либо их каналы уже могут быть полностью загружены. К счастью, в настоящее время разрабатываются меры по повышению скорости и производительности сети Tor. Но ведь жаловаться нельзя, верно? В конце концов, служба бесплатна. Разумеется, можно: это Интернет, а в Интернете жалуются все!

Известны случаи, когда выходными узлами Tor управляли недобросовестные люди. Что это означает для вас? Оператор Tor может запустить выходной узел специально для наблюдения за вашим трафиком, а в некоторых случаях и для его изменения в собственных интересах. Если вы входите в приложение, которое не шифрует пароли или данные сеанса посредством SSL, учётные данные могут оказаться доступны оператору выходного узла, ведущему перехват.

Кроме того, помните, что оператор выходного узла Tor, имея возможность действовать как посредник, способен внедрять трафик в незашифрованные сеансы. Например, когда вы просматриваете обычный веб-сайт, недобросовестный оператор выходного узла может внедрить элемент iframe или ссылку на JavaScript, указывающую на вредоносный сайт с эксплойтом. Если этот код попытается воспользоваться уязвимостью вашей системы, она может оказаться заражена вредоносной программой.

Некоторые веб-сайты и интернет-службы специально отслеживают системы, работающие в качестве выходных узлов Tor. Поэтому при использовании Tor в ходе исследования вы можете обнаружить, что определённые веб-сайты недоступны. Большая часть применения Tor может быть законной, однако люди способны пользоваться этой сетью и для сокрытия незаконных либо незрелых поступков. Поэтому некоторые администраторы сайтов блокируют доступ с таких IP-адресов, чтобы уменьшить подобную активность.

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

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

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

• Самое важное: между вами и прокси-сервером нет конфиденциальности. Прокси-сервер знает, кто вы, и знает, что каждый полученный им запрос в действительности исходит от вас. Сравните это с Tor, где выходному узлу неизвестно, откуда пришёл первоначальный запрос.

Важно знать, что существует несколько типов прокси. Хотя прокси и выступают посредниками, они не обязательно обеспечивают полную анонимность. На рисунке 1-5 показан принцип работы прокси-серверов.

Рисунок 1-5. Схема прокси-сервера

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

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

SOCKS4 - протокол, предназначенный для передачи трафика между клиентом и сервером через промежуточный прокси. SOCKS4 поддерживает только протокол связи TCP. В нём отсутствует способ аутентификации. SOCKS4 не является новейшей версией протокола SOCKS, однако по-прежнему широко применяется и поддерживается. Стоит отметить, что SOCKS4A представляет собой расширение SOCKS4, в котором была добавлена поддержка разрешения DNS-имён.

SOCKS5 является текущей версией протокола SOCKS и расширением протокола SOCKS4. Для связи он поддерживает как TCP, так и UDP. Кроме того, в нём добавлены способы аутентификации клиента на прокси-сервере.

Прежде чем настраивать и использовать прокси, необходимо найти работоспособный сервер. Для этого можно обратиться к нескольким веб-сайтам со списками бесплатных прокси. Обычно на таких сайтах указываются IP-адрес прокси, его порт, протокол и тип. Ниже перечислено несколько сайтов со списками бесплатных прокси, которыми можно воспользоваться:

• http://www.xroxy.com

• http://www.proxy4free.com

• http://aliveproxy.com/

• http://www.freeproxylists.com

Найдя прокси, можно настроить веб-браузер для работы с ним, выполнив действия по настройке Tor из рецепта 1-1. Просто укажите IP-адрес прокси и порт, на котором он принимает подключения. Работу прокси можно проверить так же, как работу Tor: открыть веб-сайт, возвращающий ваш IP-адрес, например http://www.ipchicken.com.

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

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

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

Если запросить этот файл из веб-браузера, он вернёт сделанный вами запрос вместе со всеми заголовками HTTP. С помощью переменной REMOTE_ADDR он также может вывести IP-адрес клиентской машины.

В следующих примерах ради конфиденциальности мы скрыли настоящие IP-адреса использованных прокси. Ниже приведён справочный список:

• 192.168.5.88 - IP-адрес системы, из которой отправляются запросы.

• 10.20.30.40 - IP-адрес прозрачного прокси.

• 10.20.30.50 - IP-адрес анонимного прокси.

• 10.20.30.60 - IP-адрес высокоанонимного прокси.

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

Этот запрос вернул исходные сведения о заголовках, с которыми можно сравнивать остальные запросы, отправленные при включённых прокси. Так мы увидим, какие элементы могут добавляться прокси разных типов. Как следует из вывода, сервер считает, что соединение пришло с нашего настоящего IP-адреса.

RFC 2617 определяет прозрачный прокси как прокси, который не изменяет запрос или ответ сверх того, что необходимо для аутентификации и идентификации прокси. Иными словами, большинство полей изменяться не должно. Однако прозрачные прокси, по крайней мере большинство из доступных в Интернете, зачастую не скрывают сведения об источнике запросов. Когда клиент использует прозрачный прокси, все запросы к серверу по-прежнему приходят с IP-адреса прокси-сервера. Однако прокси-сервер добавляет дополнительный заголовок HTTP с указанием первоначального источника запроса.

Ниже показан запрос, который видит веб-сервер от браузера, использующего прозрачный прокси:

Для целевого веб-сервера наше соединение выглядит пришедшим с IP-адреса прокси. Именно адрес 10.20.30.40 появится в журналах веб-доступа. Однако, как видите, к запросу было добавлено несколько полей заголовка HTTP. В частности, заголовки X-Forwarded-For и Via раскрывают наш настоящий IP-адрес и используемое программное обеспечение прокси. Такая схема почти не обеспечивает анонимности.

Анонимные прокси не раскрывают ваш IP-адрес серверу, к которому вы обращаетесь. Однако обычно они добавляют какие-либо дополнительные сведения, указывающие, что запрос поступил от прокси-сервера. В запросе всё ещё может присутствовать заголовок X-Forwarded-For, но указанным в нём адресом, скорее всего, будет IP-адрес прокси-сервера либо иное значение, не совпадающее с вашим IP-адресом. Если переданное значение является настоящим IP-адресом, но не принадлежит ни вам, ни прокси-серверу, такой прокси называют искажающим.

Сравните следующий запрос, видимый веб-серверу от браузера с анонимным прокси, с исходным запросом, отправленным без прокси.

Теперь видно, что ваш IP-адрес не был передан в этом запросе. Однако в запрос добавлен заголовок HTTP Via, который сообщает об используемом программном обеспечении прокси (x81prx00). Некоторые идентификаторы, передаваемые анонимными прокси, могут быть уникальными для вас. Поэтому даже если целевой веб-сервер не способен преобразовать эти сведения обратно в ваш IP-адрес, он всё же может отличать все ваши запросы от запросов других пользователей.

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

Сравнив этот запрос с отправленным без прокси, вы заметите, что они выглядят одинаково. Единственное различие состоит в том, что веб-сервер увидел соединение с IP-адреса прокси, а не с вашего адреса. Это не означает, что высокоанонимные прокси вообще не изменяют заголовки, однако изменения не должны раскрывать ни вас, ни тот факт, что сервер является прокси.

Прекрасный способ проксировать соединения - перенаправлять порты через туннель SSH. Туннель SSH позволяет открыть порт, принимающий подключения на локальной рабочей станции, соединиться со своим сервером по SSH, а затем использовать этот сервер как прокси SOCKS4/5. После этого любое приложение с поддержкой прокси SOCKS4/5 сможет обращаться к ресурсам с IP-адреса сервера, на который вы вошли по SSH.

Первым делом потребуется учётная запись с командной оболочкой на удалённом сервере SSH, который вы хотите использовать для туннелирования. Несколько компаний предлагают недорогие учётные записи, пригодные для этой цели. Общедоступная UNIX-система Super Dimension Fortress (SDF)^[5] предоставляет туннелирование SSH и перенаправление портов в рамках членства MetaARPA стоимостью 36 долларов в год.

Настроить в Linux или Mac OS X туннель SSH, используемый как прокси SOCKS4/5, несложно. Выполните следующие действия:

1. В командной оболочке рабочей станции запустите ssh для подключения к серверу с параметром -D.

Эта команда настраивает динамическое перенаправление портов прикладного уровня, привязывая принимающий сокет к TCP-порту 1080 вашей системы. Если соединение установлено успешно, клиент SSH должен ожидать подключения на указанном порту.

2. Теперь приложения с поддержкой прокси SOCKS4/5 можно настроить на соединение с вашей рабочей станцией (localhost или 127.0.0.1) через TCP-порт 1080. Ваш сервер SSH фактически станет прокси SOCKS, доступным локальной системе.

3. Туннелирование SSH можно настроить точнее, перенаправляя соединения с определённого локального порта на конкретное сочетание IP-адреса и порта. Например, если требуется проксировать только соединения с unlockedworkstation.com на TCP-порту 80, выполните следующую команду:

4. Теперь соединения с локальным узлом на TCP-порту 2080 будут проксироваться через сервер SSH на IP-адрес unlockedworkstation.com и TCP-порт 80.

При создании туннеля командой ssh открывается командная оболочка на сервере SSH. Возможно, вы не захотите постоянно держать это окно открытым, однако после его закрытия туннель перестанет существовать. Эту проблему можно решить, сохранив соединение активным и переведя его в фоновый режим. Ниже приведён изменённый вариант одного из предыдущих примеров.

Параметр -f предписывает клиентскому процессу SSH перейти в фоновый режим непосредственно перед выполнением команды. Параметр -N указывает SSH не выполнять удалённых команд, а лишь поддерживать открытый туннель.

Действия по созданию туннеля SSH на рабочей станции Windows заметно отличаются, однако их также легко выполнить с помощью клиента SSH PuTTY.^[6] На сайте Web Hosting Talk опубликовано хорошее сообщение с пошаговыми инструкциями^[7] по настройке PuTTY.

Если вы хотите повысить конфиденциальность при работе в Интернете независимо от необходимости анонимности, стоит обратить внимание на Privoxy.^[8] Privoxy - это веб-прокси без кэширования, который отфильтровывает рекламу и другое нежелательное содержимое. Программа обладает широкими возможностями настройки, но уже при стандартной конфигурации умеет:

• фильтровать рекламные баннеры, веб-жучки и раздражающие элементы HTML;

• обходить сценарии отслеживания щелчков и перенаправления;

• удалять анимацию из GIF-файлов.

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

В Ubuntu Privoxy устанавливается командой apt-get install privoxy. Затем его можно запустить командой service либо посредством /etc/init.d/privoxy.

Если служба запустилась правильно, вы увидите процесс, ожидающий подключения на порту 8118 локального узла (127.0.0.1).

Как уже упоминалось, Privoxy можно настроить в качестве сервера, доступного нескольким клиентам. Для этого измените параметр listen-address в конфигурационном файле Privoxy (в большинстве систем это /usr/local/etc/privoxy/config). Ниже показано стандартное значение:

Замените 127.0.0.1 на IP-адрес сервера, доступный другим клиентам вашей сети. Если сервер имеет адрес 192.168.1.200, конфигурация должна выглядеть следующим образом:

После того как клиенты укажут 192.168.1.200:8118 в качестве HTTP-прокси в настройках своих браузеров, все веб-запросы будут проходить через Privoxy. При желании Privoxy можно использовать и совместно с Tor. Для этого достаточно изменить конфигурационный файл Privoxy, указав принимающий узел Tor как прокси SOCKS5. Если в системе с Privoxy также работает Tor, раскомментируйте в конфигурационном файле следующую строку:

После раскомментирования Privoxy станет направлять все исходящие запросы через Tor при условии, что Tor запущен и локально привязан к порту 9050 сервера. Это обеспечит одновременно анонимность и более высокий уровень конфиденциальности.

Существует ещё несколько способов оставаться относительно анонимным во время исследования. В частности, прекрасными вариантами могут стать сотовое подключение к Интернету и виртуальные частные сети (VPN). За каждое из этих решений, возможно, придётся немного заплатить, но в конечном счёте расходы могут полностью себя оправдать. С точки зрения внешнего мира оба решения обеспечивают определённый уровень анонимности. Ни при одном из них не потребуется беспокоиться об утечке DNS-запросов или настраивать браузеры и приложения для работы с прокси.

Главное преимущество сотового подключения к Интернету для сохранения анонимности состоит в том, что никакая внешняя сторона не может по одному лишь IP-адресу связать соединение непосредственно с вами. Разумеется, оператор сотовой связи способен установить такую связь. При каждом подключении вы, вероятнее всего, будете получать новый динамически назначенный IP-адрес. Если кто-либо отслеживал прежнюю деятельность по IP-адресу, у него возникнут затруднения, поскольку для смены IP достаточно подключиться заново.

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

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

Nepenthes работает в различных операционных системах, включая Windows через Cygwin, Mac OS X, Linux и BSD. В подробном файле readme^[1] объясняется, как загрузить готовые двоичные файлы или установить nepenthes из исходного кода в любой из перечисленных систем. Однако инструкции этого рецепта относятся именно к использованию nepenthes в Ubuntu.

Чтобы приступить к установке, введите следующую команду:

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

После запуска nepenthes привязывается к нескольким портам системы. На этих портах nepenthes ожидает распространённых попыток удалённой эксплуатации. Как видно из следующего вывода netstat, идентификатор процесса nepenthes равен 14243. Каждая строка представляет отдельный сокет в состоянии LISTEN, то есть ожидающий входящих соединений. Верхняя строка показывает, что nepenthes принимает подключения на порту 80 всех IPv4-адресов машины (0.0.0.0), а к сокету в данный момент не подключён удалённый узел (0.0.0.0:*).

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

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

• /var/log/nepenthes/: стандартный каталог журналов.

• /var/log/nepenthes/logged_downloads: список всех попыток загрузки.

• /var/log/nepenthes/logged_submissions: список всех успешных попыток загрузки.

• /var/log/nepenthes/binaries/: хранилище загруженных двоичных файлов. Имя каждого файла совпадает с его хешем MD5; файл сохраняется только при первом получении и не загружается повторно при последующих атаках.

• /var/log/nepenthes.log: основной файл журнала nepenthes со всеми событиями, включая обнаружение повторных атак и другие сообщения о работоспособности и состоянии nepenthes.

Чтобы узнать, какие атаки принял ханипот и какие вредоносные программы пытались распространять атакующие системы, просмотрите файл logged_downloads. В следующем выводе авторы заменили IP-адрес своего ханипота на 10.1.84.6.

Формат этого файла журнала выглядит следующим образом:

В выводе видны атаки с девяти уникальных исходных IP-адресов за 15 часов. Хотя адреса источников различаются, кроме 74.109.128.237, который зондировал нас дважды, инструкции загрузки похожи. Например, используется протокол FTP или TFTP, а файл всегда называется ssms.exe. При использовании FTP передаются имя пользователя и пароль 1:1. Эти закономерности указывают, что атакующие IP-адреса могут принадлежать одному ботнету либо по меньшей мере использовать сходный код распространения вредоносных программ.

На этом этапе нельзя определить, размещают ли все удалённые системы одну и ту же версию smss.exe. Несмотря на одинаковое имя файла, в каждой системе может находиться иной вариант вредоносной программы. Для получения дополнительных сведений о записях logged_downloads можно в любое время выполнить grep по файлу nepenthes.log, как показано ниже:

Видно, что в результате атаки был загружен файл ssms.exe с хешем MD5 ecfbf321d3dea3ec732e7957b1bb7b1a. Теперь проверим временную метку соответствующего файла в каталоге загрузок nepenthes:

Вы заметили несоответствие в данных? Согласно logged_downloads, узел 74.51.226.134 велел ханипоту загрузить smss.exe 8 июля 2010 года, тогда как временная метка соответствующего файла относится к 11 июня 2010 года. Это не ошибка. Как уже упоминалось, nepenthes не сохраняет дубликаты файлов, уже находящихся в каталоге загрузок. По временной метке первого появления можно приблизительно понять, распространяют ли боты новые или старые образцы вредоносных программ. Ботнеты и черви часто пытаются многократно распространять один и тот же файл в течение долгого времени, поэтому наблюдаемое поведение вполне обычно.

Следующая команда ищет в каталоге загрузок любые события за 8 июля 2010 года:

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

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

• Программа написана на C, но предоставляет интерфейс Python, поэтому новые модули легко добавлять без повторной компиляции основы.

• Она поддерживает IPv6 и TLS и использует libemu (см. рецепт 6-10) для обнаружения шелл-кода.

• В ней реализована написанная на Python версия протокола Windows Server Message Block (SMB), что позволяет правильно устанавливать сеансы до эксплуатации атакующими машинами. Другие ханипоты с низким уровнем взаимодействия имитируют лишь отдельные уязвимые функции. Поскольку атаки через SMB, вероятно, будут составлять большую часть наблюдаемого ханипотом трафика, это даёт dionaea значительное преимущество перед другими ханипотами.

• Она может отправлять уведомления в реальном времени по протоколу XMPP (см. рецепт 2-6).

• Она записывает сведения об атаках в базу данных SQLite3, благодаря чему можно легко рассчитывать статистику и строить её графики (см. рецепт 2-9).

Для правильной настройки dionaea необходимо установить множество пакетов. Вместо подробного описания каждого шага мы отсылаем вас к странице проекта dionaea,^[3] где процесс установки хорошо документирован. Несколько пакетов потребуется скомпилировать из исходного кода, поскольку dionaea нужны версии, которых, вероятно, нет в вашем диспетчере пакетов. Рекомендуемая операционная система для установки dionaea - Ubuntu или Debian Linux, однако настроить программу должно быть возможно на большинстве платформ семейства Unix.

После успешной установки dionaea все файлы должны находиться в /opt/dionaea. В следующих нескольких рецептах этот каталог обозначается как $DIONAEA_HOME. В первую очередь следует определить базовые параметры, находящиеся в основном конфигурационном файле dionaea: $DIONAEA_HOME/etc/dionaea/dionaea.conf.

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

Таблица 2-1. Рекомендуемые изменения уровней журналирования

Подобно nepenthes, dionaea поддерживает отправку файлов по HTTP. Стандартная конфигурация настроена на передачу двоичных файлов в сетевые песочницы Anubis, Norman и экземпляр CWSandbox Мангеймского университета (см. рецепт 4-6). Если вы не хотите отправлять файлы в эти песочницы, соответствующие части конфигурационного файла необходимо закомментировать. В разделе журналирования dionaea можно также настроить на отправку кода в Joebox или даже в собственный обработчик HTTP, подробнее описанный в рецепте 2-5.

По умолчанию dionaea привязывается ко всем IP-адресам как по IPv4, так и по IPv6. В зависимости от числа IP-адресов, настроенных в системе-ханипоте, инициализация dionaea может занять некоторое время. Если требуется быстро привязать dionaea ко всем IP-адресам без перебора каждого из них либо ограничить список адресов привязки, в конфигурационный файл можно внести следующие изменения:

В этом примере режим изменён на "manual", тогда как стандартное значение равно "getifaddrs". При ручном режиме в конфигурационном файле необходимо указать интерфейсы и IP-адреса, к которым должна привязываться dionaea. Ниже приведено пять возможных вариантов настройки датчика.

Чтобы привязаться ко всем адресам IPv4 интерфейса, используйте 0.0.0.0; ко всем адресам IPv4 и IPv6 - ::; для отдельных адресов просто перечислите их через запятую. Для разных интерфейсов можно в любых сочетаниях применять разные настройки и протоколы.

В разделе модулей можно включать, отключать и настраивать различные функции и инструменты dionaea. Особый интерес представляют два его подраздела: ihandlers и services. Их стандартные настройки показаны ниже:

Dionaea умеет использовать базу данных SQLite, то есть обработчик logsql, и эта возможность включена по умолчанию. Если хранить в SQLite сведения об активности датчика не требуется, соответствующую строку можно закомментировать. Работе с обработчиками logxmpp и p0f посвящены соответственно рецепты 2-6 и 2-8. Что касается раздела служб, возможно, стоит удалить несколько перечисленных служб, например http, https и ftp. Решить, какие службы dionaea отключить, помогут следующие сведения:

• smb и epmap: необходимы для сбора вредоносных программ посредством dionaea, поскольку большая часть таких программ наблюдается при атаках на службы smb и epmap.

• tftp: работает как сервер TFTP, принимающий произвольные передачи файлов, а также обнаруживает попытки эксплуатации уязвимостей службы TFTP.

• http и https: работают как веб-сервер и обслуживают файлы из $DIONAEA_HOME/var/dionaea/wwwroot/.

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

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

Чтобы запустить dionaea, выполните следующую команду:

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

Один из самых интересных и новаторских модулей dionaea работает с протоколом Extensible Messaging and Presence Protocol (XMPP), который можно применять для обмена данными в реальном времени. Если вы когда-либо пользовались сервером Jabber или Google Talk, значит, вы уже использовали XMPP. Но модуль XMPP в dionaea выводит обмен данными и двоичными файлами в реальном времени на совершенно новый уровень. Dionaea не ограничивается записью сведений в каналы чата, а делится полученными двоичными файлами с другими клиентами канала. Если у вас есть друзья или партнёрские компании, также использующие dionaea, это даёт возможность организовать распределённый сбор вредоносных программ.

Для использования XMPP прежде всего нужен доступ к серверу мгновенного обмена сообщениями с поддержкой протоколов Jabber/XMPP. Разработчики dionaea применяют изменённую версию Prosody,^[4] однако, возможно, подойдёт и ejabberd.^[5] Какую бы программу вы ни выбрали, разумно использовать сервер, специально настроенный для работы ханипотов. Объём данных и размер файлов могут оказаться недопустимыми для общедоступных серверов, из-за чего вас могут заблокировать или удалить с сервера за злоупотребление. Подробнее об XMPP можно прочитать в блоге разработчиков dionaea.^[6]

Чтобы dionaea могла использовать модуль XMPP, сначала включите logxmpp в разделе ihandlers файла dionaea.conf. Стандартная конфигурация использует сервер Prosody разработчиков и анонимно передаёт двоичные файлы другим клиентам. Это означает, что при отправке данных в комнаты чата идентифицирующие сведения об узле удаляются. Объём передаваемых сведений настраивается в разделе logxmpp файла dionaea.conf посредством директивы events.

Для регистрации данных атак из канала XMPP можно использовать сценарий Python $DIONAEA_HOME/modules/python/util/xmpp/pg_backend.py. Он входит на указанный сервер XMPP и разбирает все XML-сообщения, передаваемые в комнаты чата, к которым вы присоединились. Эти XML-данные содержат сведения об атаках и вредоносные двоичные файлы, замеченные датчиками dionaea. При запуске pg_backend.py можно указать путь для сохранения двоичных файлов. Если предоставить учётные данные базы данных, вся активность атак с различных датчиков может регистрироваться в центральной базе. Следующая команда показывает синтаксис подключения к двум каналам, записи данных в базу и сохранения двоичных файлов в каталоге /tmp.

В таблице 2-2 кратко объясняются параметры.

Таблица 2-2. Параметры pg_backend.py

Если включить logsql, чтобы активность dionaea сохранялась в базе SQLite, вам может понадобиться представить данные в виде графика. В этом рецепте показано, как с помощью gnuplot^[9] строить графики по базе SQLite dionaea. В декабре 2009 года команда разработчиков dionaea опубликовала две довольно большие базы данных, названные berlin и paris,^[10] с огромным объёмом сведений об атаках. Для построения графика в этом рецепте используется база berlin. Вы можете загрузить её и в точности повторить описанные действия.

База berlin обладает следующими характеристиками:

• содержит данные за один месяц, с 5 ноября по 7 декабря 2009 года;

• содержит 600 000 зарегистрированных атак, приведших к 2700 загрузкам двоичных файлов;

• не содержит атак узлов Conficker, поскольку их IP-адреса не входили в диапазон сканирования;

• включает журнал p0f.

Характеристики базы paris:

• содержит данные немногим более чем за неделю, с 29 ноября по 7 декабря 2009 года;

• содержит 7,8 миллиона зарегистрированных атак, приведших к 750 000 загрузкам двоичных файлов;

• содержит большой объём трафика Conficker.

Чтобы построить графики по базе dionaea, выполните следующие действия:

1. Загрузите базу berlin с адреса, указанного в следующей команде. Вместо неё можно использовать paris или базу, созданную собственными датчиками dionaea.

Сайт ftp.carnivore.it использует активный FTP, поэтому при работе с wget необходимо добавить параметр --no-passive-ftp.

2. Создайте SQL-запрос, получающий интересующие сведения. В следующем листинге запрос извлекает число загрузок двоичных файлов и атак за каждый день в базах данных. Сохраните его в файле query.sql.

3. Выполните запрос к целевой базе данных и сохраните вывод в текстовом файле.

4. Завершите SQLite сочетанием клавиш Ctrl+D. Файл data.txt должен выглядеть следующим образом:

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

5. Постройте по данным график в gnuplot. Следующие команды показывают установку gnuplot в Ubuntu и последующую настройку параметров графика.

Теперь в текущем рабочем каталоге должен находиться PNG-файл berlin.png с графиком данных, похожим на рисунок 2-2.

Рисунок 2-2. Атаки и двоичные файлы из базы berlin

На графике число атак показано пунктирной линией и отложено по оси Y справа. Число загруженных двоичных файлов показано сплошной линией и отложено по оси Y слева. Как видно, число загруженных файлов растёт и падает вместе с количеством атак, что вполне логично.

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

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

Чтобы создать простую сигнатуру на основе ASCII, текст можно преобразовать в шестнадцатеричный вид посредством sigtool. Для этого запустите sigtool с параметром --hex-dump. Инструмент ожидает текст в стандартном вводе и выводит шестнадцатеричное представление в стандартный вывод. Распространённая ошибка при вводе через STDIN - забыть удалить завершающий символ перевода строки, который добавляется после нажатия клавиши Enter.

В следующем примере sigtool создаёт шестнадцатеричное представление строки hello world. Обратите внимание на завершающее значение 0a, которое необходимо удалить, чтобы сигнатура совпадала с первоначальным шаблоном.

Чтобы превратить результат в пригодную сигнатуру, его необходимо оформить в соответствии с синтаксисом сигнатур ClamAV. Начиная с ClamAV 0.96 основной формат сигнатур считается устаревшим в пользу расширенного. В этом рецепте рассматривается только расширенный формат, состоящий из четырёх полей, разделённых двоеточиями:

Поле SigName содержит уникальное описательное имя сигнатуры. Параметр Target может принимать любое из следующих значений:

Если требуется обнаруживать любой файл со строкой hello world, создайте следующую сигнатуру:

Это простой текстовый пример, но с помощью подстановочных символов можно создавать более сложные сигнатуры. Предположим, требуется обнаружить слова hello и world, между которыми не обязательно находится пробел. Это позволяет сделать следующая сигнатура, где подстановка ?? соответствует любому значению байта от 00 до FF.

Можно также потребовать, чтобы строка hello world находилась в файле по фиксированному смещению.

Можно указать и диапазон смещений. Следующая сигнатура сработает, только если ClamAV обнаружит hello world между смещениями 200 и 250 файла.

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

Чтобы использовать эти сигнатуры, поместите их в файл с расширением .ndb. Для удобства мы добавили сигнатуры в файл clam_helloworld.ndb на DVD книги. В целях проверки был создан файл со следующим содержимым:

При использовании собственной базы сигнатур её расположение необходимо передать clamscan в командной строке посредством параметра -d.

Обратите внимание: любая созданная и использованная сигнатура, отсутствующая в базе проекта, отображается с расширением .UNOFFICIAL. ClamAV добавляет это расширение ко всем сигнатурам, которые не входят в стандартный набор проекта. Если у вас имеется несколько собственных баз, все файлы .ndb можно поместить в один каталог и вызвать clamscan с аргументом -d DIRNAME.

На основе уже рассмотренных базовых элементов можно обнаруживать более сложные вредоносные следы, например шелл-код. Рассмотрим следующий дизассемблированный шелл-код из вредоносного документа Microsoft Office:

Значения байтового кода можно использовать для создания двоичной сигнатуры:

Эта сигнатура обнаруживает конкретный блок шелл-кода, но не находит его варианты с иным значением длины в CX или другой маской XOR. Сигнатуру можно расширить, вставив подстановки вместо значения длины, маски XOR и длины перехода. Окончательная сигнатура выглядит так:

Эта сигнатура обнаруживает шелл-код, выполняющий следующие действия:

• обнуляет регистр CX (33c9);

• помещает значение длины в CX (66b9????);

• посредством XOR изменяет данные по адресу [edx+ecx] (80340a??);

• возвращается циклом к началу (e2??);

• после завершения цикла выполняет переход к полученным данным (eb).

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

Чтобы использовать сигнатуру, просто добавьте её в собственную базу сигнатур, то есть файл .ndb, и передайте clamscan параметр -d.

Одна из самых мощных новых возможностей последних версий ClamAV - поддержка сложных сигнатур на основе логических выражений. Благодаря ей можно создавать сигнатуры с необязательными значениями или выдавать предупреждение лишь при одновременном выполнении нескольких условий. Формат логической сигнатуры выглядит так:

Поля SigName и Target имеют тот же смысл, что и в рассмотренном ранее расширенном формате сигнатур. Поле Expression состоит из логического выражения, в котором каждая сигнатура представлена своим индексом. Таким образом, число 0 обозначает Sig0, число 1 - Sig1 и так далее. Сигнатуры можно объединять логическими операторами OR (|) и AND (&). Кроме того, операторы =, < и > позволяют задать число появлений каждой сигнатуры, которое должно быть найдено в файле до выдачи предупреждения. Например, выражение (0>5)&(1=3) сработает, когда сигнатура 0 встретится более пяти раз, а сигнатура 1 - ровно три раза.

На основе первоначального примера hello world можно создать сигнатуру, обнаруживающую присутствие как hello, так и world независимо от их порядка и положения.

У этой сигнатуры две подсигнатуры: 68656c6c6f (hello) и 776f726c64 (world), а также логическое выражение 0&1. Значения 0 и 1 представляют индексы подсигнатур. Следует также указать значение целевого типа файла 0, при котором сканируются файлы любого типа.

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

• строки WriteProcessMemory и CreateRemoteThread: имена функций API, используемых для внедрения;

• строка SeDebugPrivilege: имя системной привилегии отладки, которую процесс должен включить до вызова любой из двух указанных функций API;

• строка наподобие iexplore.exe или explorer.exe: имя целевого процесса.

Логически этот сценарий можно выразить как поиск любого исполняемого файла, содержащего строку iexplore.exe или explorer.exe, обе строки WriteProcessMemory и CreateRemoteThread, а также строку SeDebugPrivilege. Иными словами, требуется следующее совпадение:

В синтаксисе логических сигнатур это правило можно записать так:

Эта сигнатура называется clam_inject.ldb и находится на прилагаемом к книге DVD. Чтобы получать предупреждение о вредоносной программе, внедряющейся в другой целевой процесс, сигнатуру потребуется изменить. Кроме того, помните, что это лишь простой пример. Если вредоносная программа упакована, используемые для обнаружения строки могут быть невидимы ClamAV.

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

Или так:

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

В Linux тип файла можно определить командой file. Вывод следующей команды показывает, что ack388 является исполняемым PE-файлом, несмотря на отсутствие расширения.

В Python тип файла можно определить с помощью пакета python-magic, устанавливаемого командой apt-get install python-magic. После установки в сценарии Python можно выполнить следующие команды:

В качестве альтернативы можно написать сигнатуры YARA для определения типов файлов. На DVD книги находится файл magic.yara, содержащий, в частности, следующие сигнатуры:

Пример определения типа файла посредством правил YARA:

В Linux для вычисления хешей файлов можно использовать такие команды, как md5sum, sha1sum, sha256sum и sha512sum.

В Python можно воспользоваться встроенным модулем hashlib либо модулем PyCrypto, подробнее рассматриваемым в главе 12. Пример:

Нечёткие хеши помогают определять сходство файлов. Различные сценарии их применения представлены в рецепте 3-9, поэтому пока мы лишь покажем вычисление таких хешей. Команду ssdeep, устанавливаемую посредством apt-get install ssdeep, можно использовать следующим образом:

После установки модуля pyssdeep,^[3] то есть привязок Python для ssdeep, нечёткие хеши можно вычислять и в сценариях Python, как показывают следующие команды:

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

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

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

Таблица 3-1. Производители антивирусов с бесплатными персональными сканерами командной строки

Ссылки из таблицы: http://www.clamav.net; http://www.free-av.com/en/products/index.html; http://free.avg.com/us-en/download?prd=afl; http://www.bitdefender.com/PRODUCT-14-en--BitDefender-Free-Edition.html; http://research.pandasecurity.com/free-commandline-scanner/; http://www.f-prot.com/products/home_use/linux/.

Многие другие производители, например Sophos и McAfee, предлагают бесплатные 30-дневные пробные версии своих антивирусов. Если вы хотите испытать подобный сценарий, пробный период позволит настроить параметры и отчёты, прежде чем принимать решение о покупке.

Операционная система для запуска мультисканера также может ограничить выбор. Практически все производители поддерживают Windows, некоторые - Linux и совсем немногие - Mac OS X. В отдельных случаях некоторые сканеры можно запускать в Linux или Mac OS X посредством Wine. Wine эмулирует вызовы API Windows; в этом рецепте мы покажем, как им пользоваться.

На DVD книги находится пример мультисканера на Python под именем av_multiscan.py. Эта версия не является исчерпывающим сканером, а служит отправной точкой для добавления собственных антивирусных продуктов. Версия на DVD позволяет использовать:

• ClamAV со стандартными сигнатурами;

• ClamAV с собственными сигнатурами;

• YARA;

• F-Prot со стандартными сигнатурами;

• OfficeMalScanner;

• оценку Team CYMRU MHR^[4] (Malware Hash Registry).

Важнейшая часть мультисканера - выполнение программ командной строки и интерпретация их результатов. Эту задачу решает модуль Python subprocess,^[5] позволяющий порождать новый процесс, задавать параметры командной строки и перенаправлять STDIN, STDOUT и STDERR. Мультисканер запускает различные программы с подходящими параметрами и перехватывает STDOUT. После выполнения этот поток требуется разобрать, чтобы получить результаты сканирования.

Если файл совпадает с сигнатурой базы ClamAV, clamscan выводит строку с именем файла и именем сигнатуры, разделёнными двоеточием:

Следующая функция показывает, как av_multiscan.py обрабатывает результаты механизма ClamAV.

Перед использованием измените сценарий av_multiscan.py, правильно задав переменные path_to_clamscan, то есть путь к двоичному файлу clamscan, и clam_conf_file, то есть расположение собственной базы сигнатур.

После установки Wine^[6] командой apt-get install wine многие антивирусные сканеры командной строки для Windows можно запускать непосредственно в Linux или Mac OS X. Например, при разработке мультисканера не в Windows программу OfficeMalScanner.exe всё равно можно интегрировать посредством Wine. Следующая функция показывает, как это сделать.

Чтобы подавить стандартные отладочные сообщения Wine, код создаёт переменную среды WINEDEBUG со значением -all. Благодаря этому вывод команды содержит только результаты OfficeMalScanner.exe. В частности, код извлекает рассчитанный OfficeMalScanner индекс вредоносности, то есть числовую оценку того, насколько вредоносен файл. Подробнее об OfficeMalScanner и его системе оценивания рассказывается в рецепте 6-11.

Сценарий av_multiscan.py принимает один параметр -f, задающий сканируемый файл. Использовать его можно следующим образом:

Как видно, sample.exe упакован AsPack. Файл не совпал ни с одной сигнатурой ClamAV, но оценка MHR Team Cymru равна 60, что означает обнаружение 60 процентами используемых службой антивирусных сканеров.

Параметр -v программы av_multiscan.py формирует более подробный вывод. Следующий пример показывает сканирование документа Microsoft Word с этим параметром.

Результаты показывают, что bad.doc не совпал с сигнатурами стандартной базы ClamAV, а хеш файла не известен MHR. Однако он совпал с собственной сигнатурой ClamAV из рецепта 3-2, а OfficeMalScanner присвоил ему индекс вредоносности 31, что довольно много. Ниже приведено несколько полезных идей для реализации в мультисканере:

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

• Добавить в механизм сканирования другие антивирусные продукты.

• Выполнять дополнительные действия в зависимости от типа файла, например проверять исполняемые файлы сканером PE-файлов из рецепта 3-8.

Исполняемые файлы Windows должны соответствовать спецификации PE/COFF (Portable Executable/Common Object File Format). К ним, помимо прочего, относятся консольные приложения и приложения с графическим интерфейсом (.exe), динамически подключаемые библиотеки (.dll), драйверы ядра (.sys) и элементы управления ActiveX (.ocx). Основы PE-файлов здесь не рассматриваются, поскольку они описаны во множестве других книг и сетевых статей. Хорошим введением служит серия Мэтта Пьетрека из двух частей: Peering Inside the PE^[7] и An In-Depth Look into the Win32 Portable Executable File Format.^[8]

В этом рецепте авторы показывают несколько способов обнаруживать подозрительные файлы по значениям заголовка PE. Таким образом, независимо от антивирусных сканеров можно применять эвристики для быстрого выявления файлов с подозрительными признаками. Код рецепта использует pefile Эро Карреры,^[9] модуль Python для разбора заголовков PE. Сценарий под именем pescanner.py находится на DVD книги. В настоящее время он обнаруживает следующие признаки:

• Файлы с записями TLS. Записи TLS представляют функции, выполняющиеся до основного потока программы, а значит, до первоначальной точки останова, установленной отладчиком. Вредоносные программы часто используют записи TLS для запуска кода до получения управления отладчиком. Сценарий pescanner.py выводит адреса всех функций обратного вызова TLS.

• Файлы с каталогами ресурсов. Каталоги ресурсов могут содержать произвольные типы данных, например значки, курсоры и конфигурации. При сканировании всего каталога system32 вы, скорее всего, получите множество ложных срабатываний, поскольку каталоги ресурсов законны. Однако в каталоге с вредоносными программами наличие ресурсов, вероятно, указывает, что при выполнении файл сбрасывает другой исполняемый файл. Сценарий pescanner.py извлекает все ресурсы PE-файла и определяет тип каждого из них способом, описанным в рецепте 3-6.

• Подозрительные записи IAT. Импортируемые функции могут указывать на поведение программы во время выполнения. Можно составить список подозрительных функций API и выдавать предупреждение всякий раз, когда образец вредоносной программы импортирует функцию из этого списка. В pescanner.py имеется стандартный список приблизительно из 15 API, но дополнять его предстоит вам.

• Подозрительные разделы точки входа. Разделом точки входа называется раздел PE, содержащий AddressOfEntryPoint. В законных, или неупакованных, пользовательских программах значение AddressOfEntryPoint обычно находится в разделе .code или .text, а в драйверах ядра - в PAGE или INIT. Поэтому потенциально упакованные файлы можно выявлять, если точка входа находится в разделе, отсутствующем в списке известных безопасных разделов.

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

• Разделы с чрезвычайно низкой или высокой энтропией. Энтропия - значение от 0 до 8, описывающее случайность данных. Зашифрованные или сжатые данные обычно имеют высокую энтропию, а длинная строка из одинаковых символов - низкую. Вычислив энтропию, можно довольно точно понять, какие разделы PE-файла содержат упакованный или аномальный код.

• Недопустимые временные метки. Поле TimeDateStamp представляет собой 32-разрядное значение, то есть число секунд с 16:00 31 декабря 1969 года, и указывает, когда компоновщик или компилятор создал PE-файл. Авторы вредоносных программ и упаковщиков искажают это значение, скрывая настоящую дату сборки. Если pescanner.py обнаруживает недопустимую дату, он выдаёт предупреждение.

• Сведения о версии файла. В сведениях о версии PE-файла могут находиться имя человека или компании, создавших файл, описание файла, номер версии и/или сборки, первоначальное имя файла и другие комментарии. Такие сведения присутствуют не во всех PE-файлах, однако авторы вредоносных программ нередко случайно оставляют их либо намеренно подделывают значения. В обоих случаях они дают интересные криминалистические доказательства.

Следующая команда показывает пример вывода для образца вредоносной программы, упакованного UPX. Точка входа (EP) равна 0x4292e0 и попадает в раздел UPX1, поэтому pescanner.py добавляет к строке метку [SUSPICIOUS]. Сигнатуры PEiD позволяют сообщить точную версию UPX: 2.90. Под заголовком разделов UPX0 и UPX1 помечены как подозрительные, но по разным причинам. У UPX0 исходный размер равен нулю. У UPX1 чрезвычайно высокая оценка энтропии: 7,91 из 8,00.

Следующая команда показывает вывод pescanner.py для троянского дроппера. Файл совпал с нашим правилом YARA для встроенных PE-файлов. Сведения в разделе ресурсов подтверждают результат: ресурс с именем BIN по относительному виртуальному адресу 0x3580 имеет тип исполняемого файла. Можно ожидать, что при выполнении в системе эта вредоносная программа сбросит файл размером 0x4200 байт.

Имена записей ресурсов сходны с именами разделов PE в том смысле, что их легко подделать. Если раздел называется .rdata, это ещё не означает, что в нём находятся данные только для чтения. Аналогично, злоумышленники могут поместить исполняемый файл в ресурс с одним из стандартных имён, например RT_ICON, RT_STRING или RT_CURSOR. Поэтому мы сканируем сигнатурами YARA весь файл и отдельно определяем тип каждой записи ресурса.

Следующая команда показывает вывод для образца Zeus 2007 года, если судить по временной метке. Видно, что файл импортирует функции API, связанные с внедрением кода (WriteProcessMemory) и запуском процессов (CreateProcess, WinExec). Сведения о версии явно искажены или рандомизированы. Для краткости мы удалили разделы PE и ресурсы.

Ниже приведены дополнительные факты о pescanner.py и признаках вредоносных PE-файлов, которые могут оказаться полезными:

• Вместо имени отдельного файла pescanner.py можно передать каталог. Сценарий рекурсивно разберёт все PE-файлы, найденные в каталоге и его подкаталогах.

• Основной код pescanner.py реализован в виде класса Python PEScanner. Поэтому вместо вызова из командной строки модуль можно импортировать в собственные сценарии Python. В рецепте 8-7 показано, как импортировать PEScanner в автоматизированную песочницу.

• Для обнаружения вредоносных PE-файлов можно применять несколько дополнительных эвристик. Другие идеи приведены в документе исследователей Sunbelt Software Parsing Malicious and Malformed Executables.^[10]

Ssdeep^[11] - программа Джесси Корнблюма, вычисляющая контекстно-зависимые кусочные хеши, также называемые нечёткими хешами. Команда ssdeep позволяет определить процент сходства между двумя или несколькими файлами. Например, с её помощью можно решать следующие задачи:

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

• Поиск родственных вредоносных программ. Имея хеш ssdeep образца, можно находить варианты того же семейства.

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

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

• Обнаружение самомодифицирующегося кода. Имея хеш ssdeep файла на диске, можно сравнить его с хешем ssdeep файла, выполняющегося в памяти. Если сходство двух хешей меньше 75-80 процентов, файл, вероятно, упакован или самомодифицируется.

Следующие команды показывают, как посредством ssdeep сравнить два произвольных двоичных файла. Как видно, несмотря на разные контрольные суммы MD5, файлы сходны на 49 процентов.

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

Следующий пример показывает, как извлечь подозрительные сегменты памяти подключаемым модулем Volatility malfind (см. рецепт 16-6), а затем сравнить их посредством ssdeep. Первая команда сохраняет подозрительные сегменты памяти в каталоге samples. Вторая выводит содержимое каталога и показывает, судя по имени файла, что модуль обнаружил подозрительное содержимое в диапазоне памяти 1f00000-1f27fff процесса с PID 1064 и так далее. Третья команда показывает, что большинство сегментов памяти одного процесса сходны по меньшей мере на 50 процентов с сегментами, извлечёнными из всех остальных процессов. Это указывает на вредоносную программу, внедряющую одно и то же тело кода в несколько процессов.

При запуске ssdeep можно передать параметр наподобие -t 60, чтобы показывать лишь совпадения выше заданного порога. Если 60 процентов вам не подходят, значение придётся изменить в зависимости от целей.

В этом рецепте показано, как посредством ssdeep сравнивать процессы в памяти с соответствующими файлами на диске. Небольшие изменения процесса во время выполнения нормальны, например когда программа изменяет глобальные переменные. Однако упакованный или самомодифицирующийся код, такой как полиморфные вирусы, во время выполнения изменяется значительно. Поэтому копия кода в памяти будет сильно отличаться от кода на диске.

Чтобы воспользоваться сценарием ssdeep_procs.py с DVD книги, в целевой системе необходимо установить модули Python ctypes и pywin32.^[12] pywin32 предоставляет оболочки функций API Windows, позволяющие вызывать их из Python. Если вы хотите запускать сценарий с USB-накопителя, ssdeep_procs.py можно преобразовать в исполняемый файл посредством py2exe.^[13]

Следующая команда показывает использование ssdeep_procs.py. Испытательный стенд представлял собой систему XP с процессами, упакованными VMProtect, FSG, Neolite и UPX. Обратите внимание, что эти четыре процесса сходны со своими файлами на диске соответственно на 55, 72, 75 и 0 процентов. Все остальные процессы сходны со своими файлами на диске на 83-99 процентов.

Сценарий ssdeep_procs.py способен обнаруживать и другое вредоносное поведение, называемое «опустошением процессов», подробнее рассматриваемое в рецепте 15-8. Опустошённые процессы - законные программы, например notepad.exe, которые запускает вредоносная программа. После запуска она заменяет тело, то есть исполняемые инструкции, законной программы вредоносными инструкциями. Это разновидность внедрения кода, обнаруживаемая посредством ssdeep, поскольку файл notepad.exe на диске будет значительно отличаться от находящегося в памяти.

Сравнение двоичных файлов - фундаментальный метод обратной разработки. Особенно популярен он при исследовании уязвимостей, например для анализа исправлений производителей, однако полезен и при изучении вредоносных программ. Ssdeep помогает определить варианты одного семейства, но не сообщает, что именно изменилось. Если два файла сходны на 75 процентов, до завершения анализа ещё предстоит работа. Удалили ли злоумышленники код перебора паролей? Добавили ли компонент руткита для сокрытия файлов на диске? Возможно, оба файла ведут себя совершенно одинаково, но упакованы разными упаковщиками. В этом рецепте показано, как отвечать на такие вопросы посредством BinDiff,^[14] подключаемого модуля IDA Pro для сравнения двоичных файлов.

BinDiff исследует файлы после их загрузки в IDA Pro. Он определяет функции, присутствующие в обоих файлах, по таким признакам, как CRC или хеш функции, число инструкций в каждом базовом блоке, число перекрёстных ссылок на функцию и из неё, а также с помощью множества других алгоритмов; подробности приведены в сетевом руководстве BinDiff.^[15] Определив общие функции, можно воспользоваться цветовым графическим интерфейсом BinDiff, увеличить нужные участки и изучить изменения на уровне инструкций.

Следующее краткое описание объясняет контекст и цель демонстрации из этого рецепта.

В ноябре 2006 года авторы написали исследовательскую статью^[16] об одном из первых замеченных вариантов Zeus. Во время обратной разработки мы загрузили двоичный файл Zeus в IDA Pro и присвоили имена максимально возможному числу функций, исходя из их поведения. Zeus крал сведения с компьютеров жертв, сжимал и шифровал их, а затем отправлял злоумышленникам по сети. На основе замеченного в двоичном файле алгоритма мы написали средство расшифровки для восстановления похищенных данных. Однако через некоторое время оно перестало работать. Очевидно, авторы Zeus каким-то образом обновили код, из-за чего старый алгоритм расшифровки больше не действовал, и нам предстояло понять, как его исправить.

Следующие действия показывают, как с помощью BinDiff быстро найти функцию расшифровки и точно определить внесённые в неё изменения.

1. Создайте базу IDA (IDB) для каждого из двух сравниваемых файлов. Назначьте одну основной, а вторую дополнительной. В нашем случае основной будет new_zeus.idb, образец декабря 2008 года, а дополнительной - old_zeus.idb, первоначальный образец ноября 2006 года.

2. Откройте основную IDB в IDA, оставив дополнительную закрытой, и выберите Edit > Plugins > zynamics BinDiff 3.0 либо нажмите Shift+D.

3. Когда появится запрос, показанный на рисунке 3-1, нажмите Diff Database и выберите дополнительную IDB.

Рисунок 3-1. Главное меню выбора BinDiff

После завершения сравнения в IDA появятся следующие новые вкладки:

◦ Statistics: сводка общего сходства двух файлов.

◦ Matched functions: функции, имеющиеся в обоих файлах. На вкладке показаны степень сходства от 0 до 1,00, степень уверенности от 0 до 1,00, адреса и имена функций в обоих файлах, алгоритм сопоставления BinDiff и статистика точного числа совпавших базовых блоков, инструкций и рёбер.

◦ Primary unmatched: функции основного файла, для которых не нашлось соответствующих функций в дополнительном.

◦ Secondary unmatched: функции дополнительного файла, для которых не нашлось соответствующих функций в основном.

4. Изучите вкладку совпавших функций. Как видно на рисунке 3-2, функции в столбце name secondary из old_zeus.idb названы в соответствии с назначением. BinDiff нашёл возможное соответствие функции, которую мы в 2006 году назвали DecodeData. Оценка сходства равна 0,70 из 1,00, а степень уверенности - 0,98 из 1,00.

Рисунок 3-2. Вызов визуального сравнения со вкладки Matched Functions

5. Чтобы подробнее рассмотреть две функции, щёлкните строку правой кнопкой и выберите Visual Diff. Откроется графический интерфейс BinDiff, показанный на рисунке 3-3. Окно разделено на две части. Слева находится потенциальное соответствие функции DecodeData, справа - сама функция DecodeData.

Рисунок 3-3. Расположенные рядом графы потока двух функций в BinDiff

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

7. Две функции можно рассмотреть с другой точки зрения, выбрав вкладку Assembler в графическом интерфейсе BinDiff, как показано на рисунке 3-4. Для навигации используйте полосу прокрутки посередине.

Рисунок 3-4. Дополнительная функция применяет сжатие, основная нет

На рисунке 3-4 видно, что функция из дополнительной IDB вызывает RtlDecompressBuffer, а функция из основной IDB - нет. Обе функции реализуют сходный алгоритм, включающий прибавление 5 к числу и вычитание 0xF9 из числа. Несмотря на использование разных регистров для временного хранения, алгоритмы выполняют одинаковые задачи. Таким образом, единственное видимое различие между функциями - удаление RtlDecompressBuffer. Действительно, образец Zeus 2006 года использует сжатие, а образец 2008 года - нет. Это и стало ключом к исправлению нашего средства расшифровки.

Среди общедоступных антивирусных сканеров VirusTotal^[1] является ведущей службой. Её сайт позволяет отправлять подозрительные файлы размером до 20 Мбайт и сканирует их 42 антивирусными продуктами, именно столько их было на момент написания книги. VirusTotal можно использовать следующими способами:

• Отправка через веб-сайт. Самый распространённый способ - сайт VirusTotal. Откройте его, нажмите кнопку Browse и выберите отправляемый файл. Если вы работаете в корпоративной среде и не хотите вызывать срабатывания системы обнаружения вторжений или фильтра содержимого, файл можно отправить через SSL-соединение.

• Отправка по электронной почте. Создайте сообщение на адрес scan@virustotal.com, введите scan в поле темы и прикрепите проверяемый файл. VirusTotal вернёт результаты в ответном электронном письме.

• Поиск по хешу. Сайт VirusTotal позволяет искать в существующей базе просканированных файлов по хешу MD5, SHA1 или SHA256. Эта возможность удобна, если значение хеша известно, но копии самого файла у вас нет.

• Отправка из оболочки Explorer. VirusTotal Uploader - инструмент только для Windows, позволяющий отправлять файлы непосредственно из Windows Explorer. Его можно загрузить и установить по инструкциям на странице http://www.virustotal.com/advanced.html. После установки любой файл можно отправить в VirusTotal, щёлкнув его правой кнопкой мыши, как показано на рисунке 4-1.

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

Рисунок 4-1. Отправка файлов посредством VirusTotal Uploader

На странице результатов показаны название и версия антивирусного продукта, дата последнего обновления его сигнатур и, при наличии, имя обнаруженной угрозы. Пример результата сканирования приведён на рисунке 4-2.

Рисунок 4-2. Страница результатов сканирования VirusTotal

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

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

• хеши MD5, SHA1, SHA256 и ssdeep файла;

• тип файла, определённый TrID^[2];

• временная метка, точка входа, разделы, импорт и экспорт файла, полученные посредством pefile^[3];

• ссылка на анализ в песочнице ThreatExpert,^[4] если он существует;

• уведомление о действительности цифровой подписи файла, полученное посредством SigCheck^[5];

• ссылка на анализ Prevx,^[6] если он существует;

• имена упаковщиков, использованных для сокрытия файла, определённые PEiD^[7];

• краткое описание файла, если его хеш найден в эталонном наборе данных RDS Национальной библиотеки эталонного программного обеспечения NSRL;

• сводка тегов PDF, полученная посредством PDFiD Дидье Стивенса,^[8] только для PDF-файлов.

Часть дополнительных сведений VirusTotal показана на рисунке 4-3.

Рисунок 4-3. Раздел дополнительных сведений VirusTotal

Сканер вредоносных программ Jotti^[9] доступен более чем на десяти языках и в настоящее время проверяет отправленные файлы 20 антивирусными продуктами. Если продукт существует для Linux, скорее всего, Jotti использует его на своём сайте. Отправить файл в Jotti можно через веб-интерфейс на главной странице сайта.

На странице результатов отображается положение в очереди, если она есть, после чего страница начинает в реальном времени обновляться результатами каждого антивирусного продукта. Jotti показывает дату последнего обновления вирусных определений и либо зелёную надпись Found nothing, либо красное имя совпавшей вирусной сигнатуры. Внешний вид страницы результатов Jotti показан на рисунке 4-4.

Рисунок 4-4. Результаты сканирования вредоносной программы в Jotti

Кроме того, Jotti показывает хеши MD5 и SHA1 отправленного файла. Искать в базе Jotti по хешу MD5 или SHA1 можно посредством следующего URL: http://virusscan.jotti.org/hashsearch.php.

Мультидвижковый антивирусный сканер NoVirusThanks^[10] в настоящее время проверяет отправленные файлы 24 антивирусными продуктами. Службу NoVirusThanks можно использовать следующими способами:

• Отправка через веб-сайт, загрузка файла. На сайт NoVirusThanks можно загружать файлы размером до 20 Мбайт. Преимущество этой службы состоит в возможности запретить передачу файлов другим производителям антивирусов и третьим сторонам. Для этого при загрузке установите флажок Do not distribute this sample.

• Отправка через веб-сайт, URL. NoVirusThanks позволяет отправлять URL, поэтому потенциально вредоносный файл не требуется сначала загружать на свой компьютер. Откройте вкладку Scan Web Address, введите URL и нажмите кнопку Submit Address. Система NoVirusThanks получит содержимое указанного URL и вскоре начнёт сканирование файла так же, словно вы загрузили его непосредственно.

• Отправка посредством NoVirusThanks Uploader. NoVirusThanks Uploader^[11] - приложение только для Windows, позволяющее без веб-браузера отправлять файлы размером до 5 Мбайт со своего компьютера. Оно также умеет локально загружать файлы по URL, а затем отправлять их. У приложения имеется множество других возможностей, включая перечисление запущенных служб, ключей реестра автоматического запуска, загруженных динамически подключаемых библиотек (DLL), загруженных драйверов и многое другое. Приложение NoVirusThanks Uploader показано на рисунке 4-5.

Рисунок 4-5. Приложение NoVirusThanks Uploader

Вскоре после отправки файла любым из перечисленных способов NoVirusThanks назначит ему уникальный URL. Обратите внимание: URL уникален для каждой загрузки, а не для каждого файла. Если отправить один файл дважды, будут получены два разных URL. Для каждого продукта на странице отображаются название антивируса, идентификатор базы или вирусных определений, версия антивирусного механизма и, при наличии, имя обнаруженной угрозы. Вид результатов показан на рисунке 4-6.

К сожалению, хотя NoVirusThanks показывает на странице результатов хеши MD5 и SHA1, впоследствии искать их на сайте невозможно. Для просмотра прежнего анализа необходимо сохранить URL; иначе файл придётся отправить повторно, чтобы получить новый анализ.

Рисунок 4-6. Страница результатов сканирования NoVirusThanks

NoVirusThanks предлагает ещё несколько продуктов и служб, которые также могут вас заинтересовать:

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

• Hijack Hunter - средство поиска распространённых признаков заражения, например изменений файла HOSTS, объектов Browser Helper Object, DNS-серверов и мест автоматического запуска в реестре.

• URLVoid - сетевая служба, определяющая вредоносность домена по результатам Google Diagnostic, McAfee SiteAdvisor, Norton SafeWeb и других источников, всего их сейчас 17.

В этом рецепте представлен интерфейс командной строки для VirusTotal, Jotti и NoVirusThanks. Сценарий позволяет анализировать файлы несколькими службами без веб-браузера или специального клиента. Поскольку он написан на Python, его можно использовать в Linux, Mac OS X и Windows. Запрещается применять этот сценарий в коммерческих целях или способом, нарушающим правила допустимого использования производителя.

Возможность отправлять файлы из командной строки облегчает автоматизацию загрузки и получения результатов. Например, можно создать второй сценарий для извлечения потенциально опасных вложений из локального файла MBOX или удалённой учётной записи POP3/IMAP, а затем передавать вложения avsubmit.py. Этот сценарий можно включить в рабочий процесс ханипота, описанный в главе 2, либо применять для автоматической отправки процессов, сохранённых из памяти посредством Volatility. Возможности практически безграничны.

Справка по использованию avsubmit.py выглядит следующим образом:

Если один раз вызвать avsubmit.py с параметром --init, сценарий создаст пустой файл virus.db, то есть базу SQLite. При каждом последующем использовании он будет автоматически наполнять базу результатами антивирусного сканирования. Если отслеживать результаты анализа посредством SQLite не требуется, просто не инициализируйте базу.

Файлы можно загружать в VirusTotal посредством параметра -v. Сценарий avsubmit.py вычисляет хеш входного файла и выполняет поиск по хешу в VirusTotal, проверяя наличие готовых результатов. Если они есть, сценарий запрашивает список обнаружений. В противном случае он отправляет файл, ждёт завершения обработки, а затем возвращает список обнаружений. Перед использованием сценария необходимо получить ключ API VirusTotal^[12] и вставить его в начало avsubmit.py.

При указании параметра -j сценарий проверяет, имеется ли файл в базе Jotti. Если нет, он отправляет файл. В командной строке будет получен список обнаружений и URL страницы результатов.

NoVirusThanks не поддерживает поиск файлов по хешу, поэтому avsubmit.py всегда отправляет файл, не проверяя, загружался ли он прежде. Сценарий дождётся завершения работы сканеров, выведет результаты в STDOUT и предоставит ссылку для просмотра анализа в браузере.

Обработав несколько образцов, можно приступать к выполнению запросов к базе virus.db. API SQLite доступен для многих языков, включая PHP, Perl, Python и C, поэтому всего несколько строк кода позволяют получить полезные тенденции и статистику коллекции вредоносных программ. В следующем примере мы просто используем клиент командной строки sqlite3, чтобы найти в базе все образцы Rustock.

Дополнительные замечания о сценарии avsubmit.py:

• Чтобы одновременно использовать все поддерживаемые службы, передайте параметр -jevn.

• avsubmit.py можно импортировать в собственные сценарии Python, что позволит форматировать вывод любым способом. Именно так работает сценарий из рецепта 8-7. Ниже приведён пример импорта класса VirusTotal из другого сценария Python:

Joebox,^[17] созданная Штефаном Бюльманом, - песочница, ориентированная на гибкость и настройку. Файлы можно отправлять через веб-интерфейс Joebox либо связаться с Joe Security и узнать о приобретении собственного экземпляра. Преимущество Joebox состоит в том, что для наблюдения за поведением вредоносной программы система применяет перехват SSDT и EAT в ядре, а не перехватывает функции API Windows в пользовательском режиме, как другие песочницы. Поэтому анализ Joebox теряет небольшую часть высокоуровневого контекста, например сведения о том, была ли новая программа запущена посредством ShellExecute или WinExec. Однако существенно снижается вероятность, что вредоносная программа обойдёт наблюдение, вызывая собственные API в пользовательском режиме или непосредственно функцию режима ядра из загруженного драйвера. Joebox обладает следующими дополнительными возможностями:

• поддерживает анализ исполняемых файлов, DLL, драйверов ядра, документов Word, PDF и других типов;

• позволяет выполнять вредоносную программу в Windows XP по умолчанию, Windows Vista и/или Windows 7;

• может выполнять программу в невиртуальной и неэмулируемой системе; Joebox использует решение создания образов FOG^[18] (см. также рецепт 7-7), чтобы после каждого заражения возвращать систему в исходное состояние;

• позволяет получить полный перехват пакетов отправленной программы и анализировать сетевой трафик выбранным инструментом;

• предоставляет загружаемые модули для ханипотов amun и nepenthes, автоматически отправляющие новые образцы в Joebox;

• позволяет писать сценарии на языке AutoIT^[19] для настройки среды выполнения вредоносной программы.

Сценарии Joebox представляют собой текстовые файлы с расширением .jbs. Их можно писать в любом текстовом редакторе или в SciTE4AutoIt3, редакторе AutoIT. На сайте Joebox имеется несколько примеров сценариев и документация по API. В настоящее время доступны сценарии со следующими назначениями:

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

• извлечение URL с веб-страницы и последовательное посещение каждого в браузере, то есть простой веб-краулер;

• вычисление различий поведения для уменьшения шума стандартных журналов наблюдения за API: например, можно записать действия IE при посещении законного URL, затем действия при посещении вредоносного URL и сообщить о различиях.

Ниже приведён пример минимального сценария Joebox:

Сценарий выбирает Windows XP в качестве целевой среды, передавая xp функции _JBSetSystem. При желании xp можно заменить на vista для Windows Vista или w7 для Windows 7. Затем он начинает анализ, запускает анализатор сетевого трафика, выполняет вредоносную программу, загруженную вместе со сценарием, и позволяет ей работать 120 секунд. Общее время выполнения сценария в общедоступных системах Joebox не может превышать четырёх минут. На рисунке 4-11 показана форма отправки Joebox, в которой выбираются загружаемые файл вредоносной программы и сценарий.

Рисунок 4-11. Отправка сценариев в Joebox

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

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

Сценарии dbmgr.py и artifactscanner.py с DVD служат примером универсальной многократно используемой среды сканирования. В примерах этого рецепта показано, как перечислять артефакты из отчётов ThreatExpert. Коллекцию можно наполнять вручную или написать дополнительные модули для других сетевых песочниц. Основная идея состоит в том, чтобы начать со схемы базы SQLite, описывающей все собираемые данные: файлы, ключи реестра и прочее. Затем можно написать подключаемые модули, которые собирают эти артефакты из разных источников и помещают их в базу. Когда придёт время расследования, вы сможете быстро проверить, заражена ли целевая система какой-либо ранее проанализированной вами вредоносной программой.

Следующий вывод показывает синтаксис dbmgr.py, интерфейса для добавления, удаления и запросов данных в базе артефактов.

Первым делом следует инициализировать новую базу артефактов. Для этого передайте флаг --init следующим образом:

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

Таблица samples содержит столбцы с MD5-хешем всех вредоносных программ в базе, а также автоматически увеличиваемым уникальным идентификатором каждого образца. В таблицах files, mutants и regkeys имеется столбец sid, соответствующий уникальному идентификатору образца вредоносной программы, создавшей артефакт. Чтобы добавить артефакты из существующего отчёта ThreatExpert, передайте MD5-хеш образца и флаг --add следующим образом:

Сценарий dbmgr.py импортирует класс ThreatExpert из модуля avsubmit.py (см. рецепт 4-4), чтобы получить доступ к HTML, возвращаемому сайтом ThreatExpert для заданного файла. Всего сценарий добавил в базу восемь артефактов: пять ключей реестра, два файла и один мьютекс.

С помощью флага --bulk=1 можно добавить 20 последних отчётов ThreatExpert. При каждом увеличении целого числа сценарий получает следующие 20 последних отчётов.

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

SQLite Database Browser^[20] предоставляет графический интерфейс для работы с базами SQLite. Поэтому даже без знания SQL вы сможете добавлять, удалять и изменять артефакты. В Ubuntu программа устанавливается следующей командой:

С сайта инструмента также можно загрузить двоичные файлы для Windows или Mac OS X. После установки запустите его следующим образом:

На рисунке 4-12 показан графический интерфейс инструмента.

Рисунок 4-12. Просмотр артефактов посредством SQLite Database Browser

Последний шаг этого рецепта - взять artifacts.db и использовать её для обнаружения артефактов в потенциально заражённой системе. В следующем примере применяется сценарий artifactscanner.py, предназначенный для выполнения на работающей машине Windows. Если в целевой системе не установлен Python, можно скомпилировать artifactscanner.py посредством py2exe либо написать аналогичную программу на C с использованием API SQLite для C. Однако и в этом случае руткиты, скрывающие файлы и ключи реестра, могут привести к неверным результатам artifactscanner.py. Более надёжный с криминалистической точки зрения способ состоит в получении образов диска и памяти с последующим применением базы артефактов одним или несколькими из следующих способов:

• написать подключаемый модуль для The Sleuth Kit (см. рецепт 10-2), который сканирует смонтированный только для чтения жёсткий диск в поисках файлов из базы;

• написать подключаемый модуль RegRipper (см. рецепт 10-8), который ищет в файлах кустов ключи реестра из базы;

• написать подключаемый модуль Volatility (см. рецепт 17-11), который ищет в дампе памяти мьютексы из базы.

При выполнении artifactscanner.py можно за один раз искать один тип артефактов, передав --files, --regkeys или --mutants. Можно также искать все типы артефактов, передав их краткие обозначения, например -frm. Единственный модификатор поиска - флаг --strict, применимый при поиске файлов. В строгом режиме предупреждение выдаётся только при обнаружении на подозреваемом носителе файла, полный путь к которому совпадает с путём файла в базе и MD5-хеш которого также совпадает. В противном случае сценарий работает в нестрогом режиме и выдаёт предупреждения для любых файлов с совпадающим полным путём независимо от MD5-хеша.

На рисунке 4-13 показан пример работы сканера артефактов.

Рисунок 4-13. Сканер артефактов обнаружил следы трёх различных заражений вредоносными программами

На основе сведений в базе артефактов сканер обнаружил заражения тремя уникальными образцами вредоносных программ. Он выявил файлы herss.exe, captcha.dll и winlogin.exe в определённых путях, куда предыдущие образцы вредоносных программ сбрасывали файлы с такими же именами. Кроме того, он обнаружил подозрительный мьютекс, имя которого начинается с CAPTCHA, что напоминает captcha.dll. Как вы, возможно, помните из рецепта 4-7, вариант Koobface создавал catpcha.dll. Поэтому весьма вероятно, что Koobface создал и этот мьютекс. Если в будущем сканер артефактов обнаружит тот же мьютекс на другой машине, вы автоматически узнаете, что она заражена.

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

Одно из первых действий при исследовании домена - получение его сведений WHOIS (произносится как who is). Обычно WHOIS содержит контактные данные владельца домена и лиц, отвечающих за административные, технические вопросы и/или оплату. Среди них могут быть имя, организация, адрес, номер телефона и адрес электронной почты. Иногда данные всех контактных лиц точны, в других случаях они пусты или ложны. Запросы WHOIS также возвращают DNS-серверы домена, дату его создания и дату окончания регистрации. Всё это помогает первично оценить контактные сведения и определить, являются ли они подлинными.

Утилита whois присутствует на большинстве платформ семейства Unix. В Linux и Mac OS X файл обычно находится по пути /usr/bin/whois. Если на машине Ubuntu его нет, установите утилиту командой apt-get install whois. В следующем примере предположим, что вы отправили образец вредоносной программы в одну из песочниц главы 4. В результатах сетевого трафика видно, что программа связывалась с www.my-traff.net. Теперь требуется выполнить запрос WHOIS и узнать больше об этом домене. Обратите внимание: вредоносная программа использовала www.my-traff.net, но в запросе WHOIS можно искать только сам домен, без предшествующих компонентов вроде www или ftp.

Из вывода видно, что домен зарегистрирован через компанию Namebay (регистратора) 15 июля 2006 года. Он обновлён 29 июня 2009 года, а срок регистрации истекает 15 июля 2010 года. Однако сведений о владельце и контактных лицах, отвечающих за технические, административные вопросы или оплату, здесь нет. Причина в том, что команда whois по умолчанию использовала whois.verisign-grs.com, тогда как Namebay хранит контактные сведения на собственном сервере WHOIS (whois.namebay.com).

Чтобы обратиться непосредственно к определённому серверу WHOIS, укажите программе whois параметр сервера (-h HOST, --host=HOST). Пример команды:

Теперь в вашем распоряжении гораздо больше сведений. В данном случае очевидно, что домен зарегистрирован на лицо из Москвы, Россия, с адресом электронной почты igor@pipen.net. Имя владельца указано как INSORG, что, по-видимому, не имеет ясного смысла, однако оба сервера имён входят в домен INSORG.NET. Сразу определить подлинность этих сведений невозможно. Не исключено, что злоумышленники приобрели домен с помощью кредитной карты, а затем внесли в базу WHOIS данные её жертвы.

Cygwin^[1] - бесплатное программное обеспечение, предоставляющее пользователям Microsoft Windows среду, подобную Linux. Для начала загрузите установочный файл Cygwin. На экране выбора пакетов введите whois в поле поиска. Если слева от имени пакета, как на рисунке 5-1, показано слово Skip, пакет установлен не будет. В таком случае щёлкните Skip, чтобы изменить настройку и выбрать установку. После этого вместо слова Skip в окне установки должен отображаться номер версии пакета GNU Whois.

Рисунок 5-1. Установка пакета whois в Cygwin

По завершении установки можно запустить оболочку Cygwin из меню Start и выполнять команды так, словно вы вошли в систему Linux. На рисунке 5-2 показан результат запроса WHOIS, выполненного командой whois из оболочки Cygwin.

Рисунок 5-2. Запрос WHOIS в Windows посредством Cygwin

Если вам не нужны все функции и дополнительные пакеты Cygwin, можно воспользоваться утилитой Sysinternals WHOIS^[2] Марка Руссиновича. Поместите двоичный файл whois.exe в переменную PATH командной оболочки, например в каталог system32, а затем вызовите его следующим образом:

Инструмент принимает только два возможных параметра: имя узла и необязательный сервер WHOIS, к которому следует обратиться. Вместо флагов -h или --host, обязательных в Linux, достаточно ввести имя сервера после исследуемого домена.

Ниже перечислены дополнительные инструменты Windows для поиска сведений WHOIS:

• SuperScan от Foundstone^[3]. Этот инструмент предназначен главным образом для сканирования портов, но обладает дополнительными функциями, аналогичными ping, traceroute, whois и другим распространённым сетевым инструментам.

• UnxUtils (GNU Utilities for Win32)^[4]. Набор более чем 50 распространённых утилит GNU, перенесённых в Windows, в том числе, разумеется, whois.exe.

Большинство регистраторов предоставляет веб-инструменты поиска по базе WHOIS. Например, можно прокрутить сайт GoDaddy (www.godaddy.com) до нижней части страницы и выбрать WHOIS Search. В большинстве случаев результаты поиска не ограничиваются доменами, зарегистрированными через сайт данного регистратора. Поэтому вы сможете получить сведения WHOIS практически о любом домене.

Некоторые другие сайты специализируются на различных инструментах DNS, включая поиск по базе WHOIS. Большинство из них работает сходным образом, но возможны небольшие различия: необходимость заполнить CAPTCHA, ограниченный набор доменов верхнего уровня (.com, .net, .org, .uk и так далее) или фильтрация результатов поиска с целью скрыть адреса электронной почты. Ниже перечислены сайты, с помощью которых можно выполнять запросы WHOIS:

• http://www.dnstools.com

• http://swhois.net

• http://www.whois-search.com

• http://www.betterwhois.com

• http://who.is

• http://www.domaintools.com

• http://www.allwhois.com

В этом рецепте рассматривается несколько способов определить IP-адрес имени узла из командной строки Linux и Windows, а также на любой платформе посредством веб-браузера. В ходе исследования вас в основном будут интересовать A-записи заданного имени узла. В A-записях хранятся IP-адреса. Другие часто встречающиеся типы записей: сервер имён (NS), почтовый обменник (MX) и указатель (PTR). Подробнее о них см. в материале DNS Resource Records.^[5]

Существует несколько способов быстро получить IP-адрес имени узла с помощью инструментов, зачастую уже встроенных в операционную систему. В системах семейства Unix можно пользоваться командами host или dig. Если в Ubuntu нет ни одного из этих инструментов, установите их командой apt-get install dnsutils. В Windows можно пользоваться командами nslookup и ping. Обратите внимание, что nslookup и ping также доступны в системах семейства Unix.

Команда host предназначена для поиска DNS в системах семейства Unix. Чтобы получить IP-адрес посредством host, введите:

Вывод показывает, что IP-адрес my-traff.net - 85.17.139.54, то есть A-запись. По умолчанию команда host возвращает записи A, AAAA и MX. Чтобы показать DNS-записи всех типов, воспользуйтесь флагом -t ANY.

Ещё одна полезная утилита поиска DNS для систем семейства Unix - dig. Чтобы получить IP-адрес посредством dig, выполните в командной строке следующее:

Здесь видно, что IP-адрес 85.17.139.54 возвращён как A-запись. Если требуется получить только IP-адрес сайта и ничего более, добавьте к команде параметр запроса +short.

nslookup - административный инструмент для проверки и устранения неполадок DNS-серверов. Утилита принимает имя узла в качестве аргумента и возвращает связанный IP-адрес, как показано в следующей команде:

Основное назначение команды ping - проверять, включён ли компьютер и доступен ли он по сети. Она отправляет пакет данных на IP-адрес удалённого компьютера, а затем ожидает ответа. Команде ping можно передать как IP-адрес, так и имя узла удалённого компьютера. Если указать имя узла, ping разрешит его посредством DNS и выведет связанный IP-адрес. Пример приведён ниже.

Команду ping следует применять осторожно: она пытается связаться с удалённой системой, а значит, если злоумышленники наблюдают за трафиком, им станет известен ваш IP-адрес. Удобный способ воспользоваться ping, не отправляя трафик узлу назначения, - установить время жизни пакета (TTL) равным 1. Именно это сделано выше добавлением параметра -i 1. Он гарантирует, что маршрутизатор не передаст трафик дальше. В Linux для установки TTL в 1 используется -t 1.

Ниже приведены примеры сайтов, с помощью которых можно разрешить IP-адрес домена:

• http://www.dnstools.com

• http://www.hcidata.info/host2ip.htm

• http://dns-tools.domaintools.com

• http://domaintoip.com/ip.php

• http://www.ipaddressreport.com

Сведения WHOIS об IP-адресе обычно включают:

• диапазон IP-адресов, в который он входит;

• имя организации, а также её адрес и номер телефона;

• контактные данные технических специалистов: номер телефона и электронную почту;

• другие контакты и комментарии, например порядок сообщений о злоупотреблении IP-адресами.

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

Представленный ранее в этой главе инструмент whois также способен выполнять запросы по IP-адресам. Поиск сведений об IP-адресе посредством whois ничем не отличается от поиска доменного имени. Следующий пример показывает выполнение такого запроса и вид его результатов. В рецепте по-прежнему используется IP-адрес 85.17.139.54, который был обнаружен во время поиска DNS для my-traff.net.

Запрос WHOIS для IP-адреса предоставил следующие сведения:

• IP-адрес расположен у нидерландского поставщика веб-хостинга LeaseWeb;

• IP-адрес входит в принадлежащий LeaseWeb диапазон 85.17.0.0/16;

• имеется адрес электронной почты для отправки жалоб о злоупотреблениях.

Кроме того, запрос был направлен на whois.ripe.net, один из пяти региональных интернет-регистраторов (RIR), который обрабатывает запросы для Европы. Подробнее это объясняется в следующем разделе.

Как и для доменов, сведения WHOIS об IP-адресах можно искать через веб-браузер. Однако некоторые сайты, перечисленные в рецепте 5-1, не умеют искать IP-адреса. За ведение сведений об IP-адресах отвечает региональный интернет-регистратор (RIR). Администрация адресного пространства Интернета (IANA) передаёт все IP-адреса одному из пяти RIR в зависимости от местоположения. Поэтому для поиска IP-адреса можно обратиться непосредственно к сайту любого RIR. Например, сведения об IP-адресе в Африке следует искать у RIR, обслуживающего Африку. Если требуется определить регион или страну, где расположен IP-адрес, см. рецепт 5-13. В таблице 5-1 перечислены RIR и обслуживаемые ими регионы. Дополнительные сведения см. по адресу https://www.arin.net/knowledge/rirs.html.

Таблица 5-1. RIR и их функции

Ссылки из таблицы: https://www.arin.net/.

Фонд Shadowserver^[10] и Team Cymru^[11] обслуживают собственные службы WHOIS, запросы к которым позволяют узнать различные сведения, например сопоставить IP-адрес с ASN. Автономная система (AS) - группа блоков IP-адресов, назначенных поставщику интернет-услуг (ISP). Поставщику также должен быть назначен номер автономной системы (ASN), уникально идентифицирующий его сети для маршрутизации. По ASN можно выяснить, какие диапазоны IP-адресов принадлежат поставщику.

Службы Shadowserver и Team Cymru предоставляют следующие сведения об IP-адресе:

• ASN;

• блок IP-адресов;

• страну расположения IP-адреса;

• поставщика интернет-услуг, которому он принадлежит;

• пиринговые сети;

• всех прочих поставщиков, которым могло быть передано адресное пространство IP.

Следующий пример показывает, как посредством службы WHOIS Shadowserver по адресу asn.shadowserver.org узнать больше об IP-адресе 67.212.65.105 из рецепта 5-7.

Вывод имеет следующий формат:

Из вывода видно, что подозрительный IP-адрес связан с ASN 10929 и входит в блок IP-адресов 67.212.64.0/19 в России. Имя AS NETELLIGENT представляет поставщика интернет-услуг, которому принадлежит ASN. Однако блок IP-адресов был далее передан компании QNIX LTD WORLD DEDICATED. Небольшое дополнительное исследование в Интернете показывает, что канадская Netelligent Hosting Services Inc., по-видимому, передала диапазон 67.212.64.0/19 российской компании Qnix Ltd, World Dedicated. Обратите внимание: ни одна из этих компаний не считается вредоносной, мы лишь используем реальный пример определения связей.

Теперь можно выполнить ещё один запрос и узнать, какие другие блоки IP-адресов охватывает ASN 10929.

Вывод показывает, что у Netelligent Hosting Services имеется несколько различных блоков IP-адресов, охватывающих тысячи адресов. Чтобы выяснить, кто является её пиринговыми партнёрами, выполните следующую команду:

Результаты показывают, что Tinet и Level 3 Communications, вероятно, являются пиринговыми партнёрами, в данном случае вышестоящими поставщиками, поскольку каждая AS непосредственно соединена с Netelligent. Это помогает понять соединение сетей и даёт потенциальные точки контакта при трудностях с сообщением о злоупотреблениях определённому поставщику интернет-услуг.

Посредством Netcat можно одновременно запросить ASN тысяч IP-адресов. Netcat доступен для Linux и Windows. В Ubuntu он устанавливается командой apt-get install netcat; можно также загрузить версию для Windows.^[12] Для этого способа создайте текстовый файл с IP-адресами для запросов в следующем формате:

Если файл сохранён под именем ip.txt, выполните:

Весь вывод для каждого IP-адреса будет сохранён в файл asn.txt. Дополнительные сведения о службах приведены на страницах Shadowserver IP/BGP Whois Service и Team Cymru IP to ASN Mapping.

Разные люди и организации ведут несколько чёрных списков, или списков блокировки. В них отмечается, считается ли IP-адрес, диапазон IP-адресов или домен вредоносным либо используемым для злоупотреблений. Если списки содержат актуальные сведения об IP-адресах и именах узлов, их часто называют чёрными списками реального времени (RBL). Например, IP-адрес, замеченный в рассылке спама, часто попадает в Spamhaus Block List,^[13] а адрес системы, входящей в ботнет, может попасть в abuse.ch DNS Block List.^[14] Поиск по этим спискам может дать превосходные сведения, но в то же время занять немало времени. К счастью, существует сетевая служба, которая проверяет IP-адрес или домен сразу в десятках таких источников и возвращает найденные совпадения.

Проект Anti-Abuse создал сайт,^[15] автоматически проверяющий IP-адреса и домены более чем по 50 различным спискам блокировки. Функция Multi-RBL Check позволяет быстро получить представление о том, сообщалось ли об участии IP-адреса или домена в подозрительных действиях. Если IP-адрес присутствует в десяти различных списках блокировки, это веское основание считать его вредоносным. В то же время отсутствие IP-адреса или домена во всех списках ещё не означает, что он безопасен.

При поиске IP-адреса или домена посредством Multi-RBL Check отображается перечень всех проверяемых списков. В следующем примере выполняется поиск IP-адреса 218.61.202.66. Это известный открытый прокси, расположенный в Китае. Результаты показаны на рисунке 5-8.

Рисунок 5-8. IP-адрес 218.61.202.66 присутствует в нескольких списках блокировки

Видно, что IP-адрес входит в 11 списков блокировки. Это тревожный признак возможной вредоносности домена или его применения для злоупотреблений. Следует посетить списки, в которых присутствует IP-адрес, и проверить наличие дополнительных сведений. Названия некоторых списков говорят сами за себя и сразу дают общее представление о причине включения адреса. Например, 218.61.202.66 присутствует в SpamCop Blocking List,^[16] а значит, недавно был зарегистрирован как источник спама. За дополнительными сведениями всё равно можно обратиться к сайту SpamCop и выполнить поиск IP-адреса. Результат поиска в SpamCop Blocking List показан на рисунке 5-9.

Рисунок 5-9. Поиск причин включения IP-адреса в чёрный список

SpamCop удаляет запись через 24 часа после последнего сообщения, поэтому видно, что об отправке спама с этого IP-адреса сообщили в течение последних семи часов: осталось 17 часов. Также сообщается, что спам получен и зарегистрирован как спам-ловушками SpamCop, так и его пользователями.

В рецепте 5-2 подробно описан поиск IP-адреса домена командами host и dig. В этом рецепте применяются те же основные действия и объясняется обнаружение возможных сетей fast flux. Подавляющее большинство доменов fast flux при разрешении возвращает несколько IP-адресов: от нескольких до десятков. Другие при разрешении могут вернуть только один IP-адрес, но часто менять его, чтобы каждый запрос получал новый. Следующий пример показывает разрешение DNS для связанного с клавиатурным шпионом домена, который мы подозреваем в принадлежности к сети fast flux.

Как видно, доменное имя wooobo.cn вернуло пять различных IP-адресов. Само по себе это не означает, что домен относится к fast flux. Однако если уже известно или предполагается, что домен вредоносный, вероятность случайного одновременного размещения на нескольких IP-адресах снижается. Обратите также внимание, что IP-адреса не входят в одну сеть. Некоторые поставщики хостинга, например Yahoo!, возвращают для размещённого у них домена несколько IP-адресов. Однако в таких случаях адреса часто близки друг к другу и входят в одну сеть. Адреса из приведённого запроса, по-видимому, никак между собой не связаны.

Если спустя несколько мгновений снова разрешить домен wooobo.cn, станет видно применение циклического DNS.

Порядок IP-адресов изменился, но запрос по-прежнему вернул те же пять адресов. Большинство приложений пытается соединиться с первым возвращённым адресом и переходит к последующим, только если соединение не установлено за отведённое время. Циклический метод помогает распределять нагрузку соединений и не позволяет неисправному IP-адресу всегда оказываться первым.

Теперь можно быть достаточно уверенным, что домен wooobo.cn входит в сеть fast flux, хотя он всё ещё может просто оказаться размещённым у нескольких поставщиков. Для дальнейшего исследования можно командой host выполнить обратный поиск, то есть запрос PTR-записи, этих IP-адресов и узнать место их размещения. Другой вариант - выполнить запросы WHOIS и выяснить владельцев адресов.

Судя по выводу, это главным образом IP-адреса кабельных модемов из разных штатов США. Крайне маловероятно, что эти системы законно размещают содержимое, а вероятность работы с сетью fast flux возрастает.

Поскольку сети fast flux часто ротируют и меняют IP-адреса, при разрешении домена в какой-то момент следует ожидать других адресов. Для демонстрации мы подождали несколько часов и снова разрешили домен wooobo.cn. Результаты:

Разрешение домена вернуло пять совершенно новых IP-адресов. Теперь можно подтвердить, что это домен fast flux: он возвращает несколько адресов из разных сетей, которые со временем часто меняются.

Ещё один способ обнаружить fast flux - проверить, имеет ли имя узла очень низкое значение TTL и постоянно ли возвращает новые IP-адреса. При TTL, равном 0, DNS-серверы не кешируют возвращённый IP-адрес, поэтому каждая последующая попытка связаться с именем узла приводит к новому поиску DNS. Тем временем злоумышленники постоянно обновляют IP-адрес, в который разрешается домен. Известно, что такой метод применяли ботнеты Storm Worm^[17] и Waledac.^[18] Когда эти ботнеты действовали, за час можно было обнаружить сотни их IP-адресов, просто непрерывно разрешая связанные с соответствующим семейством вредоносных программ домены.

Значение TTL домена можно узнать командой dig.

Выделенная в исходном ответе A-записи часть - значение TTL в секундах. Это означает, что серверы имён должны кешировать IP-адрес домена 14 400 секунд, или 4 часа. Даже если адрес обновляется несколько раз в час, его изменение, скорее всего, станет видно лишь через четыре часа после первоначального поиска DNS. При запросе домена fast flux Storm Worm или Waledac вместо 14 400 отображалось бы значение 0.

Результаты поиска в пассивном DNS, скорее всего, вернут десятки IP-адресов для домена, входящего в сеть fast flux. В расследовании поможет служба пассивного DNS BFK (см. рецепт 5-4). Но на этот раз вместо IP-адреса следует искать домен wooobo.cn. Результаты показаны на рисунке 5-10.

Рисунок 5-10. Пассивный DNS BFK помогает выявлять fast flux

Результаты поиска вернули более 170 различных IP-адресов, связанных с wooobo.cn. По ним сразу видно, что перед нами домен fast flux, использующий для размещения своей деятельности десятки взломанных компьютеров.

В этом рецепте показано, как посредством бесплатных баз GeoLite Country или GeoLite City от MaxMind^[20] определить примерное географическое местоположение IP-адреса. Базы представляют собой обычные файлы с организованными данными, а не сетевые серверы вроде PostgreSQL и MySQL. Для доступа к данным MaxMind предоставляет API на C, Perl, PHP, Python (требует библиотеку C), Ruby и JavaScript. Однако в этом рецепте используется сторонний API pygeoip.^[21] Pygeoip написан целиком на Python и не зависит от библиотек C. Для каждого IP-адреса в базах MaxMind можно найти следующие сведения:

• долготу и широту;

• полное название страны и двухбуквенный код страны;

• регион, например штат;

• код телефонной зоны;

• название города;

• почтовый индекс.

MaxMind предлагает коммерческие версии баз с немного более точными сведениями. Например, заявленная точность бесплатной GeoLite City составляет 99,5 процента на уровне страны и 79 процентов на уровне города. Точность коммерческой версии - 99,8 процента на уровне страны и 83 процента на уровне города.

Для начала выполните следующие действия:

1. Загрузите базу GeoLite City или GeoLite Country с сайта MaxMind. Базы обновляются в начале каждого месяца, поэтому можно настроить задание cron для автоматической загрузки новых версий по мере их появления. Укажите wget параметр -N, чтобы загружать базу, только если она обновилась после последнего получения.

2. Установите API pygeoip. На сайте инструмента приведено несколько способов установки, однако из-за жёстко заданных версий в исходном коде pygeoip могут возникнуть проблемы. Обойти их позволяют следующие команды:

3. Если всё прошло успешно, запрос к базе MaxMind можно выполнить из оболочки Python следующим образом:

Чтобы использовать API более автоматизированно и наносить IP-адреса на карту, выполните следующие действия:

1. Установите пакет matplotlib^[22] и его зависимости. Его можно собрать из исходного кода, загрузив соответствующий пакет, либо ввести в Ubuntu следующие команды:

2. Matplotlib - лишь базовый пакет. Для нанесения точек на карту необходимо также установить модуль basemap. Обратите внимание: URL разделён на несколько строк для печати.

3. Теперь можно создавать изображения карт. На DVD книги находится сценарий Python mapper.py. Его можно применять тремя способами:

◦ передать в командной строке список IP-адресов, разделённых запятыми;

◦ передать имя файла со списком IP-адресов;

◦ импортировать модуль в собственные сценарии Python.

Синтаксис mapper.py для командной строки:

Следующий пример показывает нанесение на карту нескольких IP-адресов из сети fast flux, описанной в рецепте 5-11.

По умолчанию сценарий создаёт PNG-изображение map.png с цилиндрической проекцией Миллера; другие карты см. на сайте basemap.^[23] Оно должно выглядеть как на рисунке 5-11.

Рисунок 5-11. Статическая карта PNG с различными IP-адресами

Следующий пример показывает импорт модуля mapper.py в собственные программы Python для создания пользовательских карт.

SpiderMonkey^[1] - реализация JavaScript на C от Mozilla. По существу, это интерпретатор JavaScript без браузера и подключаемых модулей, которым можно пользоваться из командной строки Linux. Поэтому он создаёт гораздо более безопасную среду для выполнения и анализа неизвестного кода JavaScript. Предположим, например, что в конце исследуемой страницы обнаружен следующий сценарий:

При просмотре страницы в браузере сообщение 404 Not Found может заставить вас решить, что сервер не нашёл файл. Однако из исходного кода видно: сценарий в нижней части страницы посредством функции eval вычисляет дополнительный код JavaScript, переданный ей как параметр. В законных случаях вычисляемый JavaScript виден, но злоумышленники создали функцию CRYPT.obfuscate, преобразующую последовательность чисел в блок кода JavaScript. Так они не дают просматривающему исходный код человеку понять, что именно делает программа.

SpiderMonkey можно собрать из исходного кода по следующим инструкциям либо установить в Ubuntu командой apt-get install spidermonkey-bin.

Чтобы выяснить, какие инструкции JavaScript вычисляются в этом или похожем встретившемся на практике случае, выполните следующие действия:

1. Изолируйте блок JavaScript, то есть всё содержимое тегов <script>, не включая сами теги, и поместите его в отдельный файл.

2. Добавьте первой строкой сценария eval = print;. Это переопределит eval, чтобы функция выводила переданный ей параметр, а не выполняла его.

3. Выполните сценарий посредством SpiderMonkey следующей командой:

SpiderMonkey выполняет функцию CRYPT.obfuscate, но вместо передачи результата в eval выводит его. Теперь истинные намерения злоумышленника видны, и можно приступить к анализу применения браузера Internet Explorer, подключаемого модуля Adobe Reader и элемента управления ActiveX Winamp.

В этом разделе вы научитесь пользоваться Jsunpack, то есть сайтом, и Jsunpack-n, версией для командной строки, чтобы автоматически декодировать сильно обфусцированный JavaScript. Jsunpack - инструмент, написанный Блейком Хартстайном, одним из авторов этой книги, и впервые представленный на Shmoocon 2009.^[2] На Shmoocon 2010 Блейк представил обновления Jsunpack и показал применение инструмента к сетевому трафику, а также использование URL и заголовков HTTP для более точного декодирования файлов.^[3]

На рисунке 6-1 показана главная страница Jsunpack.

Рисунок 6-1. Страница ввода и последние отправления Jsunpack

Сайт Jsunpack обладает следующими возможностями:

• декодирует JavaScript из указанного URL или фрагмент закодированного JavaScript, вставленный в веб-форму;

• принимает в качестве входных данных перехваты пакетов, PDF, HTML-файлы и файлы JavaScript;

• позволяет загрузить ZIP-файл с шелл-кодом и файлами, извлечёнными из входных данных;

• безопасно отображает декодированный JavaScript на веб-странице результатов;

• содержит специальный набор правил YARA (введение в YARA см. в главе 3), обнаруживающих попытки эксплуатации определённых записей CVE во входных данных;

• предоставляет RSS-канал новых отправлений;

• позволяет искать среди всех отправлений строки или критерии, связанные с исследуемой атакой.

Инструмент командной строки Jsunpack-n обладает следующими возможностями:

• модифицированная версия SpiderMonkey для декодирования и выполнения JavaScript;

• несколько режимов ввода: можно активно прослушивать интерфейс и сканировать входящий и исходящий трафик либо передать файл перехвата пакетов;

• декодеры локальных PDF, HTML-файлов и файлов JavaScript, а также возможность указать URL для загрузки и декодирования;

• несколько режимов вывода для перехватов пакетов: один извлекает все переданные по HTTP файлы и сохраняет их по отдельности, другой создаёт граф связей URL;

• модуль html.py, преобразующий переменные HTML в переменные JavaScript для сложного декодирования (см. рецепт 6-4);

• модуль pdf.py, извлекающий JavaScript из PDF;

• модуль swf.py, извлекающий JavaScript из SWF;

• параметры в options.config, позволяющие изменять настройки декодирования и вывода;

• тот же набор правил YARA для обнаружения эксплойтов, что и на сайте; возможности можно расширить собственными правилами.

Чтобы установить Jsunpack-n, получите последнюю версию из SVN следующими командами, а затем выполните инструкции в файле INSTALL.

Синтаксис Jsunpack-n выводится параметром -h:

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

Механизм SpiderMonkey не обрабатывает HTML. Он разбирает и выполняет чистый код JavaScript. Поэтому при обнаружении JavaScript внутри HTML-страницы, PDF или SWF необходимо извлечь его в отдельный файл перед интерпретацией посредством SpiderMonkey. Следующий короткий пример поясняет сказанное. SpiderMonkey не может интерпретировать первый файл, поскольку JavaScript заключён в теги HTML.

Со вторым файлом у SpiderMonkey проблем нет, поскольку тот содержит чистый JavaScript:

Обсуждаемая проблема сама по себе не является ограничением SpiderMonkey. В конце концов, SpiderMonkey - интерпретатор JavaScript, а не синтаксический анализатор HTML. Однако из этого следует, что передаваемый SpiderMonkey файл не может содержать код HTML. Обычно это не мешает, но злоумышленники способны быстро превратить особенность в проблему. Например, код JavaScript внутри HTML-документа имеет полный доступ к объектной модели документа (DOM). Поэтому JavaScript может обратиться ко всему коду HTML на странице, например получить её заголовок через document.title. Начнём с простого теоретического примера. Представьте следующий код: JavaScript обращается к document.title, использует заголовок для расшифровки строки, а затем вычисляет её посредством eval.

Чтобы выяснить, какие инструкции JavaScript вычисляются после расшифровки, можно попытаться заменить eval на print, как описано в рецепте 6-1, и проанализировать код посредством SpiderMonkey:

Как и ожидалось, возникла ошибка ссылки, поскольку объект document не определён в контексте SpiderMonkey. Он доступен только коду JavaScript, который выполняется в контексте браузера. Правильную расшифровку всё же можно вызвать, заменив document.title на "MyEncrypti0nK3y" и снова запустив код посредством SpiderMonkey. Но это ручная работа, и помните: перед вами простой пример. Нужные значения не всегда находятся в таком заметном месте, как заголовок страницы.

Jsunpack-n умеет разбирать содержимое HTML-страницы и преобразовывать теги, заголовки и другие элементы в переменные JavaScript. При интерпретации извлечённого со страницы JavaScript эти переменные автоматически передаются SpiderMonkey. Поэтому все значения HTML-страницы, на которые ссылается JavaScript, становятся доступны. Способ разбора HTML в Jsunpack-n настраивается в файле htmlparse.config. Например, для определения document.title добавьте следующие строки:

Когда Jsunpack-n встречает HTML-файл с содержимым:

он создаёт следующую переменную JavaScript:

Стандартные правила htmlparse.config извлекают JavaScript из многих полей HTML, часто используемых злоумышленниками. Новые правила понадобятся только в том случае, если JavaScript встречается в новом месте, ещё не описанном в htmlparse.config.

Теперь рассмотрим похожий случай с настоящим вредоносным кодом. Мы обнаружили следующую HTML-страницу (fetch_bd29f.html), содержавшую закодированный JavaScript:

Код вызывает document.getElementById и получает значение тега HTML с идентификатором __V_n_. Значение используется в формуле, которая, предположительно, раскрывает дополнительные инструкции JavaScript для выполнения. Интерпретация JavaScript посредством SpiderMonkey приводит к такой же ошибке ссылки, как и ранее. Однако следующее правило из htmlparse.config Jsunpack-n преобразует все теги HTML в доступные переменные JavaScript.

Это правило имеется в стандартном файле htmlparse.config. Если отключить его для демонстрации, результат будет следующим:

При включении одного этого правила результаты декодирования радикально меняются:

За кулисами Jsunpack-n разобрал HTML и создал из __V_n переменную JavaScript. Это удовлетворило зависимость вредоносного JavaScript и позволило ему завершить выполнение. Когда на практике встречается «упрямый» JavaScript, который никак не хочет выполняться, не забывайте проверить, не зависит ли он от элементов DOM браузера. Если зависит, теперь вы знаете, как настроить Jsunpack-n для подобных случаев.

Adobe Reader выполняет обнаруженный в PDF JavaScript посредством модифицированной версии SpiderMonkey.^[5] JavaScript внутри PDF часто сжимают, чтобы скрыть его назначение от аналитиков и систем обнаружения вторжений. В этом рецепте показано автоматическое извлечение и распаковка JavaScript посредством модуля pdf.py из Jsunpack-n.

Если в рецепте 6-2 вы уже получили Jsunpack-n из SVN, сценарий командной строки находится по пути ./jsunpack-n/pdf.py. Для pdf.py, как также указано в INSTALL, требуются BeautifulSoup и PyCrypto. В Ubuntu они устанавливаются следующей командой:

Как уже отмечалось, данные внутри объектов PDF можно сжимать множеством способов. На рисунке 6-2 показан вид PDF с потоком FlateDecode (zlib) в шестнадцатеричном редакторе. Выделенные байты отмечают начало сжатых данных.

Рисунок 6-2. PDF со сжатыми данными, загруженный в шестнадцатеричный редактор

Сценарий pdf.py создаёт выходной файл со всем распакованным JavaScript. Эта программа извлечения из PDF применяет несколько библиотек Python для обработки фильтров PDF, в том числе FlateDecode (zlib), ASCIIHexDecode, ASCII85Decode, LZWDecode и RunLengthDecode. Следующий код показывает, как pdf.py преобразует сжатые данные в распакованный текст. Полный алгоритм можно посмотреть в pdf.py.

Каталог samples в составе Jsunpack-n содержит несколько полезных для проверки файлов. Следующий вывод показывает результат выполнения pdf.py для PDF из каталога samples.

Как видно, если входной файл содержит JavaScript, сжатый или нет, pdf.py извлекает его в отдельный файл. При изучении выходного файла можно заметить JavaScript, которого изначально не было в PDF.

В этом случае всё выше комментария //jsunpack End PDF headers было добавлено pdf.py. Весь JavaScript ниже комментария извлечён из исходного файла. Почему pdf.py добавил в выходной файл дополнительный JavaScript, в частности строку info.creator? Это одна из уникальных и чрезвычайно мощных возможностей pdf.py. При разборе PDF сценарий обнаружил объект с тегом /Creator. Обычно объекты этого типа содержат строку, идентифицирующую создателя PDF, но здесь злоумышленники сохранили в ней закодированные инструкции JavaScript. При выполнении JavaScript «первого этапа» он обращается к строке info.creator PDF, преобразует её в инструкции и передаёт функции eval.

Вернёмся к вопросу: зачем pdf.py добавил info.creator в выходной файл? Потому что при попытке выполнить JavaScript «первого этапа» в таком инструменте, как SpiderMonkey, info.creator будет недоступна и JavaScript второго этапа никогда не вычислится. Сценарий pdf.py увидел в PDF тег /Creator, предположил, что встроенный JavaScript может попытаться к нему обратиться, и автоматически добавил его в выходной файл. Если вы прочитали рецепт 6-4 о предоставлении JavaScript, выполняющемуся вне браузера, доступа к переменным HTML, эта концепция должна быть знакома.

Теперь выходной файл можно запустить посредством SpiderMonkey. В следующем примере SpiderMonkey применяется немного иначе, чем в рецепте 6-1. В частности, параметр -f позволяет интерпретировать несколько файлов в одном контексте. Первым выполняется pre.js, входящий в исходный код Jsunpack-n и содержащий специальный набор определений и перехватчиков функций JavaScript. Вместо того чтобы каждый раз добавлять eval=print; в начало сценария перед выполнением посредством SpiderMonkey, эту строку можно добавить в pre.js, а затем указать в командной строке -f pre.js. Однако настоящее преимущество pre.js состоит в переопределении уязвимых функций JavaScript, чтобы при их вызове можно было выполнять определённые действия. Ниже приведён фрагмент pre.js, перехватывающий util.printf и util.printd.

Вывод перехватчика должен показывать предупреждения с идентификатором соответствующей CVE и длиной параметров, переданных функциям печати. Продолжая анализ pdf-thisCreator.file.out, получаем:

Сразу можно определить, что сжатый JavaScript содержит код распыления кучи. Благодаря определениям и перехватчикам в pre.js видно также, что JavaScript эксплуатирует уязвимость функции util.printf Adobe Reader, подробнее рассматриваемую в рецепте 6-8. При ложных срабатываниях можно изменить правило pre.js, чтобы перед выдачей предупреждения проверять длину параметров, переданных util.printf. Текущий перечень файлов, которые Jsunpack отметил как вредоносные по этому правилу, находится по адресу http://jsunpack.jeek.org/dec/go?list=1&search=CVE-2008-2992. Там можно подписаться на RSS-канал всех последних обнаружений, вызвавших правило.

Дидье Стивенс создал несколько полезных инструментов анализа и извлечения вредоносного содержимого из PDF.^[6] В этом рецепте рассматривается тот же вредоносный PDF, что и в рецепте 6-5, но применяются pdfid.py и pdf-parser.py из коллекции Дидье.

С помощью pdfid.py можно вывести тип и количество всех тегов PDF. Обычно это даёт хорошее представление о том, скрывает ли файл данные других типов. Более того, VirusTotal показывает вывод pdfid.py в разделе дополнительных сведений на странице результатов сканирования.

Следующий вывод показывает, что файл содержит встроенные сжатые потоки и объекты JavaScript. В памятке Ленни Зельцера Analyzing Malicious Documents Cheat Sheet^[7] приведён пополняемый перечень потенциально опасных тегов.

Теперь известно, что файл содержит объекты JavaScript, и требуется определить их идентификаторы. Для этого вызовите pdf-parser.py с параметром --search=javascript:

Согласно выводу, идентификаторы объектов - 3 и 6. Однако ни один не содержит самого кода JavaScript. Более того, очевидной связи между ними нет. Пока это лишь части головоломки, которую требуется собрать. Оба объекта ссылаются на другие объекты, подобно символическим ссылкам в файловой системе, но объекты назначения в выводе не показаны. В частности, объект 3 ссылается на объект 5, а объект 6 - на объект 111611. Содержимое объекта, на который ссылается объект 3, можно вывести посредством pdf-parser.py:

Теперь видна связь между несколькими объектами. Объект 3 ссылается на объект 5, тот - на объект 6, а объект 6 - на объект 111611; никто не говорил, что номера обязаны идти последовательно. При исследовании объекта 111611 видно, что он больше ни на что не ссылается, то есть, образно говоря, это конец цепочки. Следующая команда показывает, что объект 111611 содержит 142 байта сжатых zlib данных, на что указывает /FlateDecode. Параметр -f автоматически распаковывает содержимое:

JavaScript найден. Любопытно, сколько уровней косвенности применяют злоумышленники, усложняя анализ файлов. Чтобы вывести посредством pdf-parser.py весь файл и связанные потоки, можно использовать параметр -f без -o и исследовать все распакованные потоки одновременно.

После извлечения и декодирования JavaScript из PDF может потребоваться выяснить, на какую уязвимость или уязвимости он нацелен. Это важно для оценки риска: с учётом версии Adobe Reader можно определить, сработал бы PDF на конкретной машине. В таблице 6-1 показаны наиболее распространённые на практике эксплойты PDF и приведён столбец с уязвимым «условием», которое следует искать при анализе подозрительного файла.

Таблица 6-1. Уязвимости PDF

При определении целевой уязвимости помните о следующих моментах:

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

• Многие вредоносные PDF пытаются эксплуатировать более одной уязвимости. Злоумышленник может проверить переменную app.viewerVersion, содержащую версию Adobe Reader. Если версия указывает, что программа неуязвима, он может попытаться применить другую уязвимость.

Collab.collectEmailInfo() - одна из наиболее распространённых на практике уязвимостей. В начале февраля 2008 года группа исследователей iDefense обнаружила,^[8] что эта прежде неизвестная уязвимость эксплуатировалась через рекламные баннеры для установки трояна Zonebac. Ниже приведены фрагменты вредоносного JavaScript, эксплуатирующего уязвимость:

Эта уязвимость одной из первых использовала недостатки механизма JavaScript в продуктах Adobe. iDefense обнаружила, что злоумышленники применяли её не менее двух недель до объявления Adobe об исправлении. Так началась длинная череда проблем с уязвимостями JavaScript, которыми злоупотребляли для установки вредоносного кода.

Эксплойты, нацеленные на уязвимость функции util.printf(), выполняют распыление кучи перед вызовом уязвимости. Для этого злоумышленники вызывают функцию с аргументами, похожими на приведённые ниже. util.printf() может встречаться в законных PDF, поэтому следует внимательно исследовать второй параметр. Уязвимость представляет собой переполнение буфера в стеке, а значит, во вредоносных случаях второй параметр будет чрезмерно длинным.

PDF, эксплуатирующие эту уязвимость, можно определить по чрезмерно длинной строке, переданной функции Collab.getIcon(), как в следующем коде.

Adobe исправила уязвимость в конце марта 2009 года. Впервые на практике её обнаружили несколькими неделями позже, в апреле 2009 года, и сегодня она остаётся одной из наиболее часто эксплуатируемых уязвимостей при скрытых загрузках и целевых атаках. Некоторые исследователи безопасности предполагают, что злоумышленники провели обратную разработку исправления, чтобы написать эксплойт именно для этой уязвимости. Согласно опубликованному ZDI описанию,^[9] Tenable Network Security обнаружила её в июле 2008 года.

Чтобы обнаружить PDF, эксплуатирующие эту уязвимость, ищите вызовы getAnnots() с четырьмя отрицательными параметрами, вызывающими повреждение памяти.^[10]

Вызов getAnnots() может быть подозрительным и без этих параметров, поскольку функция применяется для загрузки содержимого из другого раздела PDF. После декодирования и расшифровки содержимого аннотации JavaScript может выполнить его такой функцией, как eval().

Чтобы найти этот эксплойт, ищите объекты со следующим фильтром JBIG2Decode:

PDF, нацеленные на уязвимость JBIG2, иногда применяют распыление кучи посредством JavaScript. Однако для эффективности уязвимости JBIG2 JavaScript не обязателен. На рисунке 6-3 показан пример вредоносного PDF-документа. Объект 3 содержит тег /OpenAction, предписывающий Adobe выполнить содержимое объекта 2, когда жертва откроет PDF. Объект 2 содержит JavaScript в восьмеричной кодировке, который выполняет распыление кучи, заполняя большие участки памяти процесса перед загрузкой объекта 7.

Рисунок 6-3. Вредоносный PDF-документ, эксплуатирующий уязвимость JBIG2

Видно, что объект 7 содержит некорректный поток изображения JBIG2, из-за которого EIP передаёт управление в память, заполненную распылением кучи. Достигнув шелл-кода, EIP декодирует остальную часть объекта 7 посредством маски XOR, извлекает и выполняет исполняемый файл Windows PE.

Злоумышленники могут встроить вредоносный Flash-ролик (SWF) в PDF посредством тегов /EmbeddedFile или /RichMediaActivation. В таких случаях целевым приложением является Flash Player, а не Adobe Reader, хотя атака проводится распространением PDF. Пример встроенного Flash-ролика:

Чтобы извлечь встроенные Flash-ролики, распакуйте все фильтры PDF и найдите в начале объекта PDF заголовки файлов SWF CWS (сжатый) или FWS (несжатый). Для этого можно воспользоваться pdf-parser.py Дидье Стивенса.

U3D, сокращение от Universal 3D, применяется в анимации. Для обнаружения вредоносных PDF, пытающихся эксплуатировать разбор потоков данных U3D, ищите содержимое, похожее на следующее:

Длина вредоносных файлов, эксплуатирующих U3D, обычно составляет от 172 000 до 172 500 байт. Значение 172417 в приведённом объекте попадает в этот диапазон. Эксплойт также может применять распыление кучи посредством JavaScript, как в модуле Metasploit.^[17]

Критический компонент этого эксплойта - большое целое число, переданное аргументу /Colors. Инструмент pdfid.py Дидье Стивенса обнаруживает эксплойт, показывая значение /Colors больше 2^24. Пример:

Попытки эксплуатации этой уязвимости содержат вызовы media.newPlayer, как в следующем коде. Перед эксплуатацией злоумышленник, вероятно, выполнит распыление кучи посредством JavaScript.

Этим типам файлов не назначена CVE, поскольку поведение тегов /Launch является проектным решением. Встретив /Launch с командой, Adobe Reader показывает предупреждение, предлагая пользователю выбрать Open или Do not open. CVE-2009-0836 применяла тот же метод против Foxit, альтернативной программы чтения PDF. Злоумышленники посредством тега непосредственно встраивают исполняемый файл в PDF, а затем запускают его похожим тегом:

Если тег встроен в PDF и пользователь выбирает Open, выполняется cmd.exe. Дополнительные сведения и демонстрационный PDF, запускающий команды посредством /Launch, приведены в блоге Дидье Стивенса.^[18]

При анализе PDF или JavaScript посредством Jsunpack-n модуль detection.py применяет YARA для сканирования закодированных и декодированных данных специальным набором сигнатур. Например, следующее правило обнаруживает CVE-2008-2992:

Следующее правило обнаруживает CVE-2009-4324:

Самые свежие правила YARA, применяемые Jsunpack-n, находятся в файле rules его исходного кода.^[19]

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

Функция rep создаёт строку повторяющихся байтов, в которой значение what повторено count раз. Это верный признак находящегося рядом шелл-кода, поскольку единственная причина использовать такую функцию - создание заполнителя или последовательности вокруг шелл-кода в памяти. Обычно шелл-код находится в JavaScript как строка в кодировке Unicode, которая затем преобразуется функцией unescape в двоичное содержимое. Пример:

Иногда злоумышленники облегчают вам работу, выбирая понятные имена переменных вроде shellcode или sc, но так бывает не всегда. Следующий пример использует один или несколько знаков подчёркивания как имена переменных и функций. Мы добавили несколько комментариев для пояснения. Обратите внимание: несмотря на загадочные имена, функция rep всё ещё узнаваема.

Чтобы анализировать шелл-код в кодировке Unicode, его необходимо преобразовать в двоичный формат. Именно это делает unescape, но лучше воспользоваться Python или Perl. В обоих языках регулярное выражение может преобразовать каждое вхождение символов вроде %u3AFC в двоичное представление \xfc\x3a. Затем данные можно сохранить в файл или выполнить над ними дополнительные действия, например дизассемблирование.

Следующий пример показывает преобразование в Python и дизассемблирование результата посредством DiStorm. DiStorm^[20] - инструмент дизассемблирования двоичных потоков, написанный Гилом Дабахом. Для начала установите DiStorm в Linux; его также можно установить в Windows и Mac OS X.

Теперь можно создать сценарий, который преобразует шелл-код в двоичный вид, сохраняет копию двоичных данных на диске как shellcode.bin, а затем дизассемблирует её:

Инструкция print показывает смещение, размер, шестнадцатеричные байты и мнемонику каждой инструкции. Передайте сценарию строку шелл-кода в кодировке Unicode в командной строке. Пример вывода:

В дизассемблированном коде видно следующее:

• По смещению 0x4 инструкция JMP передаёт управление по адресу 0x17.

• По смещению 0x17 инструкция CALL передаёт управление обратно по адресу 0x7. При выполнении вызова адрес возврата, смещение 0x1c, помещается на вершину стека. По адресу 0x1c находится пока ещё закодированная полезная нагрузка второго этапа.

• По смещению 0x7 инструкция POP EBX извлекает значение 0x1c со стека и помещает его в регистр EBX.

• По смещению 0x9 инструкция XOR ECX, ECX очищает регистр, который будет счётчиком цикла.

• По смещению 0xb инструкция MOV CX, 0x1b0 устанавливает счётчик цикла равным длине полезной нагрузки второго этапа, 432 байтам.

• По смещениям 0xf и 0x13 инструкции XOR и LOOP декодируют каждый байт полезной нагрузки второго этапа значением 0xf9. Инструкция LOOP принимает один аргумент - адрес выполнения. При каждом выполнении она уменьшает регистр цикла CX на единицу, пока CX не станет равен нулю.

• По смещению 0x15 инструкция JMP передаёт управление только что декодированной полезной нагрузке второго этапа.

Чтобы понять дизассемблированные инструкции за смещением 0x1c, необходимо применить XOR к этим данным и снова их дизассемблировать. Для этого расширьте sc_distorm.py библиотекой xortools, представленной в рецепте 12-1. В частности, вставьте следующий код непосредственно перед дизассемблированием буфера bin_sc. Он применит XOR со значением 0xf9 к 0x1b0 байтам и раскроет полезную нагрузку второго этапа.

После изменения и повторного дизассемблирования шелл-кода можно анализировать полезную нагрузку второго этапа. Она начинается по адресу 0x1c, но для краткости часть кода опущена и показано содержимое сразу за этим адресом, начиная с 0xc6:

Второй этап шелл-кода сканирует память процесса в поисках заголовка вредоносного PDF. Затем он ищет в содержимом PDF начало шелл-кода третьего, последнего этапа, отмеченное строкой PdPD. С помощью ключа XOR 0xeffefeee он декодирует 0x600 байт от начала маркера и передаёт управление туда. Шелл-код последнего этапа, здесь не показанный, сбрасывает и выполняет исполняемый файл, завершая атаку.

OfficeMalScanner Франка Болдевина^[21] - инструмент командной строки для обнаружения вредоносного кода в документах Microsoft Office. Он предназначен для Windows, но хорошо работает и посредством Wine в Linux (см. рецепт 3-7). В этом рецепте описана работа OfficeMalScanner и показано определение наличия эксплойтов в документах Word, PowerPoint и Excel.

При использовании OfficeMalScanner указывается желаемый режим или уровень сведений. Возможные режимы:

• scan сканирует входной файл в поисках типовых шаблонов шелл-кода;

• brute декодирует содержимое входного файла операциями XOR и ADD со значениями от 0x00 до 0xFF; после каждого раунда OfficeMalScanner ищет встроенные сигнатуры OLE и PE-файлы, автоматически извлекая найденное в отдельные файлы;

• debug выводит дизассемблированный код для шелл-кода или шестнадцатеричный дамп для строк, данных OLE и PE-файлов;

• info выводит найденные во входном файле структуры OLE, смещения и длины, а также извлекает на диск все макросы Visual Basic;

• inflate распаковывает содержимое документов Office 2007, то есть файлов с расширением .docx, во временный каталог.

Ниже перечислены шаблоны шелл-кода и другие сигнатуры, обнаруживаемые режимом scan:

• Поиск EIP (четыре метода). Эти последовательности инструкций указывают на попытки найти EIP. Шелл-код применяет приём, чтобы после загрузки в память определить свой фактический адрес, обычно для поиска строки или полезной нагрузки второго этапа. В следующем коде reg обозначает любой 32-разрядный регистр общего назначения.

• Поиск базы kernel32 (три метода). Эти последовательности инструкций указывают на попытки найти базовый адрес kernel32.dll. Если шелл-код способен найти этот модуль, который экспортирует GetProcAddress и LoadLibrary, то сможет найти в памяти любые другие функции API.

• Поиск обработчиков SEH. Головной элемент списка структурированных обработчиков исключений (SEH) находится по нулевому смещению сегмента FS. Шелл-код часто регистрирует собственный обработчик, а затем намеренно вызывает исключение, чтобы управление немедленно перешло его функции. Это лишь уловка для сокрытия потока выполнения, затрудняющая аналитику определение следующего участка кода.

• Хеширование API. Эти последовательности инструкций указывают на хеширование API - приём, которым шелл-код находит функции API в памяти, не раскрывая их имён; иначе аналитики могли бы исследовать их посредством строк.

• Косвенные вызовы функций. Эти инструкции указывают на попытки передать управление функции, адрес которой хранится в переменной на стеке. Такое часто встречается в шелл-коде, который разрешает сразу все функции API и сохраняет их адреса в локальных переменных.

• Подозрительные строки. OfficeMalScanner обнаруживает следующие строки, поскольку они часто встречаются в шелл-коде, который сбрасывает или загружает другие вредоносные программы:

◦ UrlDownloadToFile

◦ GetTempPath

◦ GetWindowsDirectory

◦ GetSystemDirectory

◦ WinExec

◦ ShellExecute

◦ IsBadReadPtr

◦ IsBadWritePtr

◦ CreateFile

◦ CreateHandle

◦ ReadFile

◦ WriteFile

◦ SetFilePointer

◦ VirtualAlloc

◦ GetProcAddress

◦ LoadLibrary

• Циклы декодирования. Эта последовательность инструкций представляет простой, но часто применяемый алгоритм декодирования. Например, шелл-код может посредством LODSB загрузить символ строки в регистр AL, выполнить над AL операцию XOR, ADD, SUB, ROL или ROR, а затем посредством STOSB вернуть изменённое значение в строку.

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

• Сигнатуры файлов OLE и PE. OfficeMalScanner обнаруживает встроенные данные OLE по сигнатуре \xD0\xCF\x11\xE0\xA1\xB1\x1a\xE1, расположенной в начале документов Office. PE-файлы обнаруживаются по хорошо известному заголовку MZ, за которым по соответствующему смещению следует заголовок PE.

Ниже приведён пример анализа вредоносной презентации PowerPoint посредством OfficeMalScanner:

Из вывода можно определить следующее:

• файл содержит шелл-код, который пытается найти базовый адрес kernel32, применяет хеширование API и косвенные вызовы для доступа к функциям API;

• имеется встроенный документ OLE, который OfficeMalScanner извлёк в отдельный файл;

• имеются два встроенных исполняемых файла PE, закодированных посредством XOR со значением 0x85; оба извлечены в отдельные файлы;

• рейтинг индекса вредоносности равен 151.

По индексу вредоносности OfficeMalScanner можно определить файлы с наибольшим числом вредоносных признаков. Если в каталоге находятся тысячи документов и неизвестно, какие из них вредоносны, тем более какие наиболее опасны, входящий в OfficeMalScanner сценарий ScanDir.py, оболочка Python над OfficeMalScanner.exe, позволит просканировать все документы сразу. Затем по индексу вредоносности можно определить, на каких файлах сосредоточиться в первую очередь. В таблице 6-2 показан расчёт оценки.

Таблица 6-2. Расчёт рейтинга индекса вредоносности

После обнаружения и извлечения вредоносного содержимого из файла Office можно проверить типы файлов:

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

Хотя OfficeMalScanner автоматически извлёк встроенные файлы OLE и PE, шелл-код всё ещё может потребовать анализа. Именно он выполняет декодирование XOR, а затем определяет, куда сбросить остальные файлы на диск. Без анализа шелл-кода важные аспекты эксплойта останутся незамеченными.

OfficeMalScanner не извлекает шелл-код в отдельные файлы, поскольку автоматически определить его начало или длину нелегко. Однако анализу шелл-кода внутри документов Office помогают два дополнительных инструмента из состава OfficeMalScanner:

• DisView.exe - дизассемблер командной строки, позволяющий найти начало блока шелл-кода;

• MalHost-Setup.exe - по вредоносному файлу Office и смещению шелл-кода внутри него создаёт исполняемую оболочку вокруг шелл-кода, чтобы его можно было запустить или отладить.

В рецепте 6-11 OfficeMalScanner выявил три блока шелл-кода по разным смещениям: сигнатуру базового адреса kernel32 по 0xa6e, сигнатуру хеширования API по 0xd3a и косвенный CALL по 0xb58. Судя по сигнатурам, лучше начать с 0xa6e: не потому, что это наименьший адрес, а потому, что поиск kernel32 логически предшествует хешированию API и косвенным вызовам API. Вместо дизассемблирования инструкций по 0xa6e, содержимое которого уже известно, попробуйте дизассемблировать код с меньшего смещения и найти начало.

После нескольких проб и ошибок начало шелл-кода обнаружится по адресу 0xa04, как показано ниже. В исходнике первые два байта \x81\xEC выделены полужирным. Откуда известно, что это начало? Полной уверенности нет, но инструкция sub esp резервирует пространство на стеке. Обычно она встречается в начале функции, освобождая место для локальных переменных.

Найдя возможное начало шелл-кода, преобразуйте его в исполняемый файл посредством MalHost-Setup.exe. Необязательный параметр wait перезаписывает первые два байта шелл-кода (\x81\xEC) инструкциями бесконечного цикла. Затем можно подключиться к процессу отладчиком, заменить инструкции цикла первоначальными двумя байтами и начать отладку. Пример синтаксиса; исходные байты записаны в выводе консоли:

Если инструменты OfficeMalScanner запускались посредством Wine, созданный MalHost-Setup.exe исполняемый файл, в данном случае out.exe, необходимо скопировать в Windows. Затем запустите его:

Теперь к процессу out.exe можно подключиться отладчиком. Подключение к работающим процессам рассматривается в рецепте 11-1. Единственное отличие этого примера: исправленные байты \xeb\xfe следует заменить исходными \x81\xec. В результате должно получиться изображение, похожее на рисунок 6-5.

Рисунок 6-5. Шелл-код, загруженный в отладчик

Некоторый шелл-код чрезвычайно чувствителен к среде выполнения. Злоумышленники могут добавить защиту, чтобы он правильно выполнялся только в целевом процессе, например WINWORD.EXE или EXCEL.EXE. Попытка запустить тот же шелл-код в другом контексте, например в отладчике или исполняемом файле, созданном MalHost-Setup.exe, приведёт к неудаче.

Коротко рассмотрим создание шелл-кода, работающего в одном процессе и не работающего в другом. Большинство эксплойтов предназначено для конкретной версии или сборки уязвимого приложения. С помощью небольшой обратной разработки злоумышленники могут определить, хранится ли в регистре или ячейке стека определённое значение, например EDI=0x49181762, в момент вызова уязвимости. Вместо жёстко заданного ключа XOR для раскрытия полезной нагрузки второго этапа шелл-код может использовать как ключ текущее значение EDI. Если код выполняется не внутри уязвимой программы, EDI будет содержать другое значение и байты декодируются неверным ключом XOR.

Отладить шелл-код всё же можно, но, вероятно, придётся выяснить, на какую версию уязвимого приложения он нацелен. Затем выполните следующие действия:

1. В шестнадцатеричном редакторе замените байт в начале шелл-кода на 0xcc, программную точку останова.

2. Убедитесь, что настроен JIT-отладчик (см. рецепт 11-2).

3. Дважды щёлкните вредоносный файл, чтобы выполнить его, и дождитесь, пока приложение достигнет байта 0xcc. В этот момент запустится JIT-отладчик и передаст вам управление.

На машине, выступающей контроллером по рисунку 7-1, определите IP-адрес посредством ifconfig. Затем сделайте то же на целевых системах Windows посредством ipconfig. Убедитесь, что все машины находятся в одной подсети и целевые системы Windows могут послать ping контроллеру. Для справки в таблице 7-2 приведены соответствующие значения тестовой сети, упоминаемые в следующих рецептах.

Таблица 7-2. Значения тестовой сети

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

Если DNS-имя серверов, с которыми связывается вредоносная программа, уже известно, файл hosts можно изменить так, чтобы соединения направлялись на IP-адрес контроллера. Обычно файл находится в каталоге %SYSTEMROOT%\config\drivers\etc и имеет следующий формат:

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

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

Другой вариант - создать внутренний DNS-сервер и настроить его на возврат IP-адреса контроллера для некоторых или всех имён узлов, которые пытается разрешить целевая система. Тогда вручную менять hosts не требуется, но вредоносная программа всё ещё может обойти настройку, не выполняя поиск DNS и обращаясь к системе по IP-адресу. Она может также игнорировать настройки DNS целевой машины и разрешать имена через общедоступный DNS-сервер, например открытый DNS Google.

Если изменить сетевые настройки целевой системы и указать контроллер как её стандартный шлюз, весь трафик будет поступать контроллеру независимо от того, обращается ли вредоносная программа к системе по имени DNS или IP-адресу. Теперь необходимо принять важное решение: регистрировать и пересылать пакеты настоящим серверам в Интернете либо перенаправлять их системе-ханипоту или набору служб имитации?

Пересылка пакетов настоящим серверам позволяет точнее оценить поведение вредоносной программы на практике, но создаёт риск сообщить злоумышленникам о проводимом анализе и раскрыть им свой IP-адрес; способы сохранения анонимности см. в главе 1. Ханипот или набор имитации позволяют создать полностью автономную песочную сеть, но вредоносная программа не будет наблюдаться в родной среде.

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

1. На контроллере Linux включите IP-пересылку в ядре, выполнив следующие команды от имени root:

2. Убедитесь, что стандартная политика межсетевого экрана iptables на контроллере разрешает пересылку пакетов:

3. На целевой системе настройте сеть так, чтобы стандартный шлюз указывал на контроллер. Это можно сделать двумя способами. Первый - ввести следующую команду в cmd.exe:

Второй способ - настроить интерфейс посредством графического инструмента Windows, как показано на рисунке 7-2.

Рисунок 7-2. Маршрутизация трафика Windows через контроллер Linux

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

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

Wireshark^[1] - анализатор сетевых протоколов для Windows, Linux, Mac OS X и других платформ. Помимо перехвата пакетов Wireshark выполняет глубокий анализ сотен протоколов и экспортирует результаты в двоичный pcap, CSV или XML. Он также обладает мощными средствами фильтрации. Если Wireshark ещё не установлен на контроллере, выполните:

На рисунке 7-3 показан графический интерфейс Wireshark. Адрес источника запросов DNS - 172.16.176.138, то есть целевая ВМ. Ответивший DNS-сервер - 172.16.176.2, согласно конфигурации предыдущего рецепта. Видно, что для связи с серверами по HTTP целевая система разрешала имена узлов в доменах wikipedia.org и google.com.

Рисунок 7-3. Анализ трафика посредством Wireshark

Если вы предпочитаете инструменты командной строки, что рекомендуется для автоматизированного анализа, воспользуйтесь tshark, версией Wireshark без графического интерфейса. Установка:

Следующая команда перехватывает пакеты на интерфейсе eth0, автоматически завершает работу через 60 секунд и сохраняет пакеты в output.pcap:

Чтобы прочитать пакеты теми же анализаторами протоколов, что и графическая версия Wireshark, выполните:

В tcpdump^[2] нет обширных анализаторов протоколов, имеющихся в Wireshark и tshark, но инструмент выдержал испытание временем и надёжно предоставляет мощные функции перехвата и повторного чтения пакетов. Для установки выполните:

Следующая команда перехватывает на интерфейсе eth0 пакеты, направленные адресу 172.16.172.138 или исходящие от него, и сохраняет в output.pcap все байты пакета, установив длину снимка равной 0:

Ключевое слово host - один из множества фильтров в стиле BPF, позволяющих точно управлять пакетами, сохраняемыми в файл. Подробнее о фильтрах BPF см. в man tcpdump.

Передав tcpdump флаг -r, можно разобрать сохранённый файл перехвата пакетов.

Рекомендуем также передавать флаг -n, чтобы запретить tcpdump постоянно выполнять поиск DNS, который может занимать много времени. Разумеется, если вместо IP-адресов требуется видеть имена DNS, не используйте -n.

На контроллере можно установить IDS Snort,^[3] чтобы получать предупреждения обо всём подозрительном трафике, входящем в целевые машины или исходящем от них во время выполнения вредоносной программы. Если IDS применяется в рабочей среде, это даст хорошее представление о предупреждениях, которые появятся при наличии в корпоративной сети такой же или похожей вредоносной программы. Следующие команды создают на контроллере простую конфигурацию Snort с сигнатурами Emerging Threats:^[4]

Чтобы проверить успех или увидеть параметры командной строки, передаваемые Snort сценарием запуска, просмотрите их так:

Параметры объясняются в таблице 7-3.

Таблица 7-3. Параметры Snort

На основе этих сведений файлы журналов всегда можно искать в /var/log/snort. По умолчанию там находится файл alert с основными сведениями о пакетах, вызвавших сигнатуры IDS. Также будет файл tcpdump.log.XX, где XX - уникальное число, основанное на времени запуска Snort, содержащий копию вызвавших сигнатуру пакетов в формате tcpdump.

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

• включение и отключение отдельных сигнатур или целых наборов правил;

• настройка oinkmaster^[5] для поддержания сигнатур в актуальном состоянии;

• компиляция Snort с флагами --with-mysql для записи журналов и предупреждений в базу MySQL, после чего их можно просматривать и анализировать через веб-интерфейс BASE;^[6]

• настройка препроцессоров и различных параметров в snort.conf.

Deep Freeze^[17] от Faronics предотвращает постоянные изменения файловой системы компьютера. Решение поддерживается большинством платформ Mac OS X и Windows, а также доступно для некоторых дистрибутивов Linux. Продукт предлагается в двух редакциях:

• Standard - скорее персональная лицензия для одного компьютера;

• Enterprise - позволяет удалённо обращаться к нескольким клиентам Deep Freeze в сети, настраивать, администрировать и обновлять их.

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

Все возможности Deep Freeze можно бесплатно оценивать 30 дней, но для дальнейшего применения продукт придётся приобрести. Для этого рецепта мы загрузили ознакомительную редакцию Deep Freeze Standard Edition для Windows. Ссылка загрузки ведёт на ZIP-файл с исполняемой программой установки Deep Freeze (Faronics_DFS.exe). Распакуйте файл и запустите его.

Во время установки необходимо выбрать диски, которые будут «заморожены», то есть защищены Deep Freeze. Этот экран показан на рисунке 7-6.

Рисунок 7-6. Выбор защищаемых дисков

Чтобы сохранять файлы во время работы Deep Freeze, необходимо назначить незащищённый диск; обратите внимание, что диск F не выбран. Либо файлы можно сохранять на внешних носителях, например USB-накопителе, или сетевых ресурсах.

После установки компьютер перезагрузится. Вам предложат создать пароль для будущего изменения Deep Freeze или его удаления.

Deep Freeze помещает в область уведомлений значок, показывающий текущее состояние компьютера: Frozen или Thawed. В состоянии Frozen все выбранные при установке диски защищены от изменений. В состоянии Thawed они не защищены. Для изменения состояния необходимо знать установленный пароль и перезагрузить компьютер.

Вид значка в области уведомлений показан на рисунке 7-7. Слева состояние Frozen, справа - Thawed.

Рисунок 7-7. Маленький красный крестик в правом нижнем углу значка Deep Freeze указывает на состояние Thawed

Для изменения Deep Freeze удерживайте клавишу Shift и дважды щёлкните значок в области уведомлений. После входа появится консоль на рисунке 7-8.

Рисунок 7-8. Консоль администрирования Deep Freeze

В консоли администрирования можно выбрать загрузку системы в состоянии Thawed на неопределённый срок или до заданного числа перезагрузок. Состояние Thawed полезно при установке исправлений или внесении изменений, которые должны сохраниться после дальнейших перезагрузок. В Deep Freeze Enterprise имеется множество других параметров, включая ThawedSpace - выделенное на жёстком диске пространство, в которое разрешено вносить изменения. Enterprise также позволяет централизованно управлять клиентами Deep Freeze в сети, что отлично подходит для автоматизации. Например, посредством планировщика задач командной строки можно удалённо принудить машины перезагрузиться в состоянии Thawed или Frozen.

Пока Deep Freeze находится в состоянии Frozen, можно выполнять вредоносные программы или посещать вредоносные сайты, не опасаясь необратимо заразить или повредить систему. Можно вручную удалять файлы или вносить любые изменения для проверки. Достаточно перезагрузить машину, чтобы удалённые файлы вернулись, а все изменения были отменены.

Если вредоносная программа пытается обнаружить виртуальную среду, проблем нет, поскольку она выполняется на физической системе. Однако у Deep Freeze есть ограничения. Как описано на общедоступном форуме,^[18] Deep Freeze не позволяет программам получать некоторые привилегии, например SeDebugPrivilege или SeSystemtimePrivilege. Если злоумышленник эксплуатирует недостаток ядра Windows или Deep Freeze и получает эти привилегии, он может внести постоянные изменения в систему. Инструмент Deep Unfreezer^[19] демонстрировал такую атаку, но с тех пор модель безопасности Deep Freeze была усилена, и атака больше не работает.

FOG^[20] - свободное решение с открытым исходным кодом для клонирования компьютеров и создания образов, разработанное Чаком Сыперски и Цзянь Чжаном. Хотя оно не предназначено специально для анализа вредоносных программ, его можно использовать для восстановления Windows XP, Vista или Windows 7 на физических компьютерах после работы в лаборатории. Именно для этого FOG применяется Joebox, описанной в главе 4. FOG работает в Linux и обладает веб-интерфейсом управления. Основную работу выполняют загрузка PXE и Partimage, свободная программа резервного копирования дисков.

В этом рецепте рассматриваются основные этапы применения FOG. За подробностями следует обратиться к пользовательскому руководству FOG,^[21] которое занимает более 50 страниц и, вероятно, освещает всё, что не рассмотрено авторами. Для начала требуются не менее двух физических машин в одной подсети.

На первой физической машине, где будет работать FOG, установите операционную систему Linux. В пользовательском руководстве имеются отдельные инструкции для Fedora, Ubuntu и CentOS. Если вы лишь хотите узнать принцип работы FOG или пока не располагаете нужным оборудованием, загрузите готовый образ VMware. Возможно снижение производительности, и FOG всё равно потребуется настроить в соответствии с сетью: указать адрес маршрутизатора, DNS и сервер DHCP. Большинство параметров понятно само по себе, а сценарий установки проведёт вас через процесс. На рисунке 7-9 показана сводка необходимых сведений.

Рисунок 7-9. Для настройки FOG требуются основные сетевые параметры

Перед клонированием и восстановлением машин необходимо создать определение образа. Оно описывает тип используемого образа, например один раздел NTFS, несколько разделов на одном диске, несколько разделов на всех дисках и так далее. Чтобы добавить определение, откройте в браузере IP-адрес сервера FOG и выберите Image Management -> New Image. Как показано на рисунке 7-10, в рецепте выбрано имя myimage, стандартная группа хранения и один раздел NTFS.

Первое созданное определение получит идентификатор образа 1. В дальнейшем можно добавлять любое число образов: один для Windows XP SP1 с Adobe Reader 8.1, другой для Windows Vista с Adobe Reader 9.1, третий для Windows 7 и так далее.

Рисунок 7-10. Добавление определения образа через веб-интерфейс

Установите Windows XP, Vista или 7 на клиенты FOG. На этом этапе установите также все программы для анализа вредоносных программ или регистрации их поведения. Помните, что всё добавленное может быть обнаружено вредоносной программой и сообщить ей о выполнении в контролируемой среде.

Для каждого клиента FOG включите сетевую загрузку, то есть PXE, в BIOS. Точное название и расположение настройки зависят от оборудования, но основная идея показана на рисунке 7-11: сетевая загрузка должна быть первой в порядке загрузки.

Рисунок 7-11. Включение сетевой загрузки в BIOS

После сохранения изменений и выхода из BIOS клиент FOG получает IP-адрес от сервера DHCP. Если сервер FOG не настроен как сервер DHCP и существующий DHCP в подсети не настроен на обработку загрузки PXE, этот этап завершится неудачей; см. пользовательское руководство. При успехе клиент FOG покажет экран загрузки, похожий на рисунок 7-12.

Рисунок 7-12. Регистрация клиента на сервере FOG после загрузки PXE

Выберите full host registration and inventory. На сервер FOG будут отправлены сведения о MAC-адресе, имени узла и оборудовании клиента. Вам предложат связать клиент FOG с существующим идентификатором образа; выберите идентификатор 1. Затем образ диска клиента FOG, в данном случае одного раздела NTFS, отправляется на сервер и связывается с образом 1. Ход процесса виден на клиенте (см. рисунок 7-13) и в разделе Active Tasks HTTP-сайта сервера FOG.

Рисунок 7-13. Передача образа диска клиента

Теперь начинается самое интересное. На клиенте FOG можно выполнять вредоносные программы и применять любые динамические и/или статические методы анализа, не беспокоясь о заражении компьютера. После анализа образца разверните на клиенте чистый образ и восстановите первоначальное состояние. Если подготовлены другие образы, можно развернуть на клиенте другую версию Windows и определить, как это влияет на поведение вредоносной программы. На рисунке 7-14 показаны основные задачи работы с образами: восстановление клиента FOG (deploy) или получение образа с клиента (upload).

Рисунок 7-14. Меню основных задач создания образов в веб-интерфейсе

С одного сервера FOG можно управлять тысячами физических машин, а при слишком высокой нагрузке распределить обязанности, например HTTP-сервер, DHCP и создание образов, между несколькими серверами FOG.

VirtualBox^[1] - свободный универсальный виртуализатор оборудования x86. У него много прекрасных возможностей для анализа вредоносных программ: интерфейс командной строки с привязками Python, удалённый доступ и администрирование и, разумеется, базовые функции вроде изоляции узла, виртуальной сети, общих каталогов и снимков. В рецепте представлен один из способов построить на основе VirtualBox пользовательскую многократно используемую песочницу. Вы настроите виртуальную машину Windows и автоматизируете её посредством утилиты командной строки VBoxManage или API Python vboxapi; оба инструмента входят в VirtualBox.

Настройте среду следующим образом:

1. Установите последнюю версию VirtualBox. Её можно получить с сайта virtualbox.org или следующими командами в Ubuntu Linux:

2. Создайте ВМ под управлением Windows. Загрузите её и настройте как любую песочницу: не указывайте идентифицирующие личные сведения, отключите межсетевой экран, установите необходимые для анализа инструменты. Для общих каталогов установите гостевые дополнения VirtualBox, выбрав Devices -> Install Guest Additions. Также задайте пароль учётной записи, от имени которой будет выполняться вредоносная программа, и включите автоматический вход пользователя.

3. Создайте общий каталог только для чтения. Это можно сделать в графическом интерфейсе VirtualBox, как показано на рисунке 8-2. Обязательно установите флажок Read-only, чтобы вредоносная программа в ВМ не могла менять узел. Запомните имя ресурса, поскольку оно понадобится позднее.

Рисунок 8-2. Настройка общего каталога только для чтения

Если вы предпочитаете командную строку, общий каталог можно добавить посредством VBoxManage:

4. Подключите общий каталог как диск. Войдите в ВМ и добавьте постоянное сопоставление общего каталога букве диска. Проще всего открыть командную оболочку и ввести:

Теперь файл можно скопировать в общий каталог и обратиться к нему внутри ВМ как X:\filename.exe.

5. Запишите IP-адрес. Не закрывая командную оболочку, выполните ipconfig и запишите IP-адрес ВМ, чтобы отличать её трафик в перехватах пакетов.

6. Создайте снимок. Это можно сделать в графическом интерфейсе VirtualBox или командной строке. Во втором случае укажите имя ВМ и имя нового снимка.

Файл vmauto.py содержит класс Python VBoxAuto, специально предназначенный для автоматизации анализа вредоносных программ. Мы предоставляем сценарий в надежде упростить создание пользовательской песочницы и сократить объём кода, который придётся написать самостоятельно. Класс VBoxAuto поддерживает следующие методы:

• VBoxAuto(machine) создаёт экземпляр класса, связанный с ВМ по имени machine;

• VBoxAuto.check() возвращает True, если указанная машина допустима, иначе False; функцию можно вызывать перед автоматизированными задачами как проверку правильности выбранной ВМ;

• VBoxAuto.revert(snapname) возвращает ВМ к снимку с именем snapname;

• VBoxAuto.start(nsec) запускает ВМ и ожидает nsec секунд загрузки системы;

• VBoxAuto.winexec(user, pass, args) выполняет в ВМ программу от имени учётной записи user с паролем pass; учётные данные должны быть действительны в ВМ, полный путь к выполняемой программе, вредоносной или инструменту наблюдения, должен быть первым элементом массива args и доступен внутри ВМ;

• VBoxAuto.stop() останавливает и выключает ВМ.

Класс VBoxAuto можно импортировать в собственные сценарии Python и выполнять действия в произвольном порядке. Кроме того, собственный сценарий позволяет выполнять любые желаемые задачи до, во время и после вредоносной программы. Следующий код из файла myvbox.py на DVD показывает применение VBoxAuto. Сценарий копирует каждый исследуемый образец в общий с ВМ каталог, затем предписывает ВМ выполнить образец в течение указанного времени.

Как видно, отмечены лишь места для задач анализа до и после выполнения. Остальное вам предстоит реализовать самостоятельно, но далее в этой главе будут рассмотрены различные методы и инструменты, которые можно включить. С другой стороны, возможно, ничего больше добавлять не потребуется. Сценарий myvbox.py прекрасно подходит для простой многократно используемой песочницы, где достаточно перехватывать сетевой трафик и наблюдать, какие окна, если они есть, создают образцы при выполнении.

Если образцы находятся в каталоге ./samples/, сценарий можно использовать так:

На рисунке 8-3 показан результат настройки. На DVD имеется видео со всеми этапами рецепта, включая настройку VirtualBox и применение myvbox.py. На рисунке видно, что трафик вредоносной программы в ВМ появляется в Wireshark, работающем на узле. Одновременно видно окно, созданное программой в ВМ. После анализа всех файлов каталога перехват Wireshark можно сохранить. Однако определить, какой образец создал конкретный запрос, будет невозможно, поскольку весь трафик объединён в одном файле. В зависимости от целей это может быть проблемой или не иметь значения. Создание отдельного перехвата для каждого образца рассматривается в рецепте 8-4.

Рисунок 8-3. Автоматизация анализа вредоносных программ в VirtualBox на Mac OS X

Последние этапы цикла анализа на рисунке 8-1 предусматривают доступ к памяти и файловой системе целевой машины. Лучше всего анализировать эти два ресурса, монтируя их только для чтения на узловой системе, пока целевая машина приостановлена или выключена. VirtualBox хранит файлы диска и памяти ВМ на узле в закрытых форматах с расширениями .vdi и .sav соответственно. В рецепте описаны связанные с ними трудности и приведены советы по их преодолению.

Анализ VDI проблематичен, поскольку лишь немногие инструменты понимают закрытый формат заголовка VirtualBox. Руководство All about VDIs^[3] на форуме VirtualBox описывает заголовок VDI версии 1.1. Пример полей:

В ранних версиях VirtualBox, примерно 2008 года, VDI можно было монтировать на узловой операционной системе утилитой vditool. Позднее VirtualBox заменил её на VBoxManage, но возможность монтировать VDI при переходе была утрачена. Кроме того, формат VDI изменился после создания vditool, поэтому даже найденная копия инструмента не поможет монтировать образы свежих версий VirtualBox.

Закрытый формат дисков создаёт проблему не только для автоматизированного анализа, но и для криминалистических исследователей, которым требуется извлечь файлы из заражённой ВМ, не включая её. VirtualBox, VMware, Parallels, VirtualPC и другие продукты применяют разные заголовки, форматы и способы хранения образов диска. Обходной путь - преобразовать закрытый файл диска в формат, понятный криминалистическим инструментам и средствам системного администрирования. Например, VDI можно преобразовать функцией clonehd программы VBoxManage в образ диска в стиле dd, то есть сырой. Затем диск монтируется модулем NTFS-3g, позволяющим подключать NTFS в Linux и обычно уже установленным в Ubuntu.

Синтаксис и пример применения clonehd:

После преобразования VDI в сырой образ команда fdisk или mmls из Sleuth Kit (см. главу 10) поможет найти расположение раздела NTFS внутри образа. Следующий вывод показывает, что раздел начинается с сектора 63, а размер сектора равен 512 байтам.

Умножив 63 на 512, получаем 32256 - смещение начала раздела NTFS в сыром образе. Передайте его модулю NTFS-3g:

Вот и всё. Теперь содержимое диска ВМ выводится командой ls /mnt/vmware. Главный недостаток метода: преобразовывать VDI после каждого цикла автоматизации слишком долго. Если задержка приемлема, объедините команды clonehd, mmls и mount в сценарий.

Анализ файлов памяти VirtualBox также проблематичен. Каждый .sav имеет закрытый заголовок. Более того, VirtualBox записывает в файл только объём памяти, который сейчас используется ВМ. Иными словами, если ВМ выделен 1 Гбайт ОЗУ, но используется лишь 300 Мбайт, файл .sav будет размером 300 Мбайт. Это хорошо для производительности, но плохо с точки зрения криминалистического анализа. Сейчас есть два варианта: выполнить над .sav команду strings либо на работающей ВМ сбросить память программой, примеры см. в рецепте 15-1, а затем скопировать дамп на узел.

VMware чрезвычайно гибок в автоматизации задач. Существует несколько способов управлять виртуальными машинами VMware из командной строки или собственных программ:

• API VIX^[7] от VMware даёт полный контроль над гостевыми системами и имеет привязки для C, Perl и COM;

• команда VMware vmrun, поставляемая с продуктами VMware, основана на VIX и предоставляет большую часть функций, необходимых для автоматизации;

• vmcontrol.py Педрама Амини,^[8] входящий в его среду фаззинга Sulley, представляет собой оболочку над vmrun, похожую на представленную в рецепте.

Мы предпочитаем команду vmrun, поскольку она обладает всеми возможностями автоматизации анализа вредоносных программ и работает с Workstation, Server, Player, ESX и Fusion. Для управления ВМ посредством vmrun на каждой автоматизируемой машине должны быть установлены VMware Tools. Синтаксис:

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

Следующие команды показывают передачу и выполнение образца в ВМ посредством vmrun. Предполагается VMware Workstation, снимок cleanimg и образец /data/mal.exe. Для автоматизации команды можно поместить в сценарий и запускать локально, через SSH или даже как задание cron.

Для копирования файлов или запуска программ в ВМ необходимо передать действительные учётные данные её пользователя. Дополнительные параметры runProgramInGuest разрешают выполненной программе создавать окна и взаимодействовать с пользователями на рабочем столе (-activeWindow, -interactive) и запрещают vmrun ожидать завершения процесса в ВМ (-noWait).

Файл vmauto.py на DVD содержит класс Python VMwareAuto, автоматизирующий выполнение вредоносных программ внутри ВМ VMware. Он поддерживает следующие методы:

• VMwareAuto(vmx_path) создаёт экземпляр класса, связанный с ВМ, файл конфигурации которой находится по пути vmx_path;

• VMwareAuto.revert(snapname) возвращает ВМ к снимку snapname;

• VMwareAuto.start() запускает ВМ;

• VMwareAuto.setuser(user, pass) задаёт учётные данные пользователя ВМ для копирования файлов и выполнения программ;

• VMwareAuto.copytovm(src, dst) копирует файл src с узла по пути dst в ВМ;

• VMwareAuto.copytohost(src, dst) копирует файл src из ВМ по пути dst на узле;

• VMwareAuto.suspend() приостанавливает ВМ;

• VMwareAuto.winexec(exe_path, args) выполняет программу exe_path в ВМ с необязательными аргументами args; предварительно необходимо вызвать setuser;

• VMwareAuto.scrshot(out_file) сохраняет снимок рабочего стола ВМ в out_file в файловой системе узла;

• VMwareAuto.findmem() находит связанный с ВМ файл виртуальной памяти .vmem;

• VMwareAuto.stop() останавливает и выключает ВМ.

Следующий код показывает применение VMwareAuto в собственном сценарии Python. Он выполняет те же задачи, что и последовательность команд vmrun выше.

В следующих рецептах показано расширение сценария перехватом пакетов, имитируемым Интернетом и анализом памяти. В рецепте 8-7 приведена обновлённая версия кода со многими дополнительными функциями.

ZeroWine^[11] Джоксиана Корета (Joxean Koret) - песочница вредоносных программ с открытым исходным кодом, распространяемая как заранее собранная виртуальная машина QEMU под управлением Debian. Система Debian содержит веб-интерфейс для загрузки образцов вредоносных программ, которые затем выполняются посредством Wine. Wine эмулирует вызовы Windows API и позволяет вредоносной программе взаимодействовать с файловой системой, реестром и сетью, как на настоящей машине Windows. В режиме отладки Wine может регистрировать вызовы API, создавая записи о действиях вредоносной программы. Среди дополнительных возможностей - обнаружение нескольких приёмов против эмуляторов и виртуализации, вывод строк и сведений о заголовке PE-файла.

Проект ZeroWine Tryouts^[12], сопровождаемый Чхэ Чон Бином (Chae Jong Bin), основан на исходном пакете ZeroWine. Он добавляет несколько новых функций, включая обновлённый образ QEMU, обработку PDF-файлов, поиск ранее созданных отчётов по контрольной сумме, перехват пакетов посредством tcpdump и определение изменений реестра и файловой системы.

Оба проекта можно быстро настроить. Даже с учётом загрузки пакета систему, вероятно, удастся запустить менее чем за 10 минут. Начать работу с ZeroWine Tryouts можно следующим образом:

1. Установите QEMU на узловую машину, где будет выполняться ZeroWine. Теоретически узлом может служить Windows или Mac OS X, поскольку QEMU устанавливается в обеих системах, однако в демонстрациях далее используется Ubuntu. Для установки введите:

2. Загрузите со страницы ZeroWine Tryouts на SourceForge и распакуйте архив с заранее собранной виртуальной машиной QEMU.

3. Запустите виртуальную машину QEMU прилагаемым сценарием:

4. Некоторые процессоры не поддерживают KVM, например процессоры Intel без технологии VT, из-за чего при запуске QEMU могут возникнуть проблемы. В таком случае следует либо использовать изменённую версию QEMU без KVM, либо преобразовать образ QEMU в образ VMware. Для второго варианта QEMU всё равно должен быть установлен на узле, чтобы выполнить преобразование:

Теперь откройте VMware и создайте новую виртуальную машину. Во время настройки выберите use existing virtual disk file, а затем файл zerowine.vmdk.

5. Загрузите виртуальную машину и войдите в консоль. Имена пользователей и пароли двух заранее настроенных учётных записей: root/zerowine1 и malware/malware1. Узнайте IP-адрес машины командой ifconfig, затем откройте его порт 8000 в веб-браузере. Должна появиться форма загрузки, показанная на рисунке 8-5.

В форме можно выбрать, как долго вредоносная программа будет выполняться до начала анализа и сколько секунд следует ждать перед попыткой выгрузить память процесса. ZeroWine обращается к сегментам памяти посредством Python ptrace, что должно дать распакованную копию образца. На рисунке 8-6 показана страница с результатами образца после завершения анализа.

Рисунок 8-5. Веб-интерфейс ZeroWine Tryouts

Рисунок 8-6. Просмотр результатов анализа

В этом разделе показаны результаты выполнения Wine в режиме отладки: функции API и параметры, использованные вредоносной программой во время выполнения.

В этом разделе показаны результаты определения типа файла посредством TrID, определения упаковщика посредством PEiD и значения заголовков PE/COFF, включая импорты, экспорты и каталоги ресурсов, полученные посредством pefile.

Здесь показаны все удобочитаемые строки, извлечённые из образца. Если образец упакован, строк может быть немного, но при необходимости можно загрузить выгруженный процесс, как показано на рисунке 8-6, и вручную запустить для него strings.

В этом разделе находится сокращённая версия журналов API, содержащая только записи, обозначенные как подозрительные. Можно заранее настроить список подозрительных терминов в форме регулярных выражений, совпадающих с именами DLL, именами API или любыми параметрами API. Для этого откройте файл /home/malware/zerowine/cgi-bin/calls.py. В следующем примере вывода видны вызовы API, отмеченные стандартным списком подозрительных терминов из calls.py.

В этом разделе показаны изменения файловой системы и реестра, вызванные вредоносной программой. Перед её запуском ZeroWine создаёт список файлов на эмулируемом диске Windows, сохраняя вывод ls для каталогов ~/.wine/drive_c и ~/.wine/drive_d. После выполнения вредоносной программы ZeroWine снова применяет ls и командой diff определяет, какие файлы были добавлены или удалены. Перед следующим анализом система распаковывает /home/malware/backup/backup.tar.gz и перезаписывает всё содержимое ~/.wine, восстанавливая файловую систему. В следующем примере видно, что вредоносная программа создала 15870.exe и jzoucpymqng.sys, а затем зарегистрировала файл .sys как службу.

В среде Wine сетевые API Windows полностью работоспособны. ZeroWine посредством tcpdump перехватывает пакеты, созданные вредоносной программой, а затем выводит результаты на веб-странице с параметром -vvv, то есть с максимальной подробностью. Полный файл pcap также можно загрузить со страницы анализа, как показано на рисунке 8-6.

ZeroWine и ZeroWine Tryouts способны предоставить полезную информацию. Они объединяют две интересные технологии, QEMU и Wine, и позволяют выполнять дополнительные задачи сценариями Python. Однако на этой платформе песочницы вредоносная программа находится далеко от своей естественной среды. Получить хорошие результаты для руткитов уровня ядра или полные дампы системной памяти не удастся.

Sandboxie^[13] - приложение для Windows, которое выполняет программы в изолированной среде и предотвращает постоянные изменения компьютера. Инструмент предназначен для безопасного просмотра веб-страниц и повышения конфиденциальности, но многие его свойства подходят для анализа вредоносных программ. В этом рецепте показано совместное применение Sandboxie и Buster Sandbox Analyzer^[14], который обеспечивает автоматизированный анализ и создание отчётов. Хотя Sandboxie должна предотвращать изменения системы, всё же рекомендуется выполнять её внутри виртуальной машины на случай, если образцу вредоносной программы удастся выйти из песочницы.

Создаваемая Sandboxie песочница похожа на окружение chroot в Unix. Программы в песочнице могут создавать файлы и изменять ключи реестра, но изменения прозрачно перенаправляются в специально назначенное место. Вот некоторые важные особенности песочницы:

• Изоляция файловой системы. Стандартная песочница пользователя Administrator находится, например, по пути C:\Sandbox\Administrator\DefaultBox. Если вредоносная программа пытается поместить файл в C:\WINDOWS\system32\bad.exe, песочница сохраняет его в C:\Sandbox\Administrator\DefaultBox\drive\C\WINDOWS\system32\bad.exe. Тот же принцип применяется к записи по любым другим путям, включая удалённые и сетевые диски, а также к попыткам прямой записи в \\.\PhysicalDrive0.

• Изоляция реестра. Песочница перехватывает попытки изменить реестр и перенаправляет изменения в файл куста реестра C:\Sandbox\Administrator\DefaultBox\RegHive, не затрагивая рабочий реестр.

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

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

Buster Sandbox Analyzer работает поверх Sandboxie и позволяет анализировать вредоносные программы вручную или автоматически. Buster можно применять для следующих целей:

• Обнаружение изменений. По журналам Sandboxie обнаруживаются изменения файловой системы, реестра и сети, например открытые порты.

• Наблюдение за API. Sandboxie позволяет указать DLL для внедрения в процессы песочницы. Buster использует эту возможность и включает файл log_api.dll, выполняющий регистрацию.

• Создание отчётов. Buster содержит несколько эвристик, интерпретирующих журналы Sandboxie и создающих нетехнический отчёт о поведении вредоносной программы.

• Исследование системы. Buster включает полный набор утилит для исследования системы и (или) компонентов анализируемой вредоносной программы: обозреватель памяти, обозреватель перехваченных пакетов, обозреватель PE-файлов, обозреватель процессов, дизассемблер файлов, утилиту хеширования, шестнадцатеричный редактор, сканер сигнатур упаковщиков и утилиту строк.

Чтобы начать работу с инструментами, выполните следующие действия:

1. Установите Sandboxie и Buster Sandbox Analyzer на виртуальную машину по ссылкам в начале рецепта. Для установки Buster достаточно распаковать архив на диск; рекомендуется C:\bsa.

2. Откройте панель управления Sandboxie и выберите Configuration > Edit Configuration. Добавьте следующие две строки в раздел [DefaultBox] файла Sandboxie.ini:

На рисунке 8-7 показано, как открыть файл Sandboxie.ini и как должны выглядеть внесённые изменения.

Рисунок 8-7. Настройка Sandboxie для внедрения DLL наблюдения за API

3. Дважды щёлкните BSA.EXE, чтобы открыть Buster Sandbox Analyzer. Укажите путь к каталогу песочницы, как на рисунке 8-8, и нажмите Start Analysis.

Рисунок 8-8. Настройка Buster Sandbox Analyzer

4. С помощью панели управления Sandboxie выполните образцы вредоносных программ, которые требуется проанализировать. Все дочерние процессы, созданные вредоносной программой, автоматически выполняются в той же изолированной песочнице. Чтобы выбрать процесс, щёлкните имя песочницы и выберите Run Sandboxed > Run Any Program, как показано на рисунке 8-9.

5. Позвольте вредоносной программе выполняться столько, сколько требуется. На рисунке 8-10 видно, что дочерние процессы sup.exe, cmd.exe и a_friend.exe, созданные вредоносной программой, также удерживаются в песочнице. Один из исполняемых файлов создал окно, замаскированное под Macromedia Flash Player. Кроме того, в журналах API Buster видно создание различных других файлов в системе.

Рисунок 8-9. Выбор процесса для выполнения в песочнице

Рисунок 8-10. Buster регистрирует вызовы API, а Sandboxie удерживает новые процессы

6. Завершив выполнение вредоносной программы, выберите в панели управления Sandboxie Sandbox DefaultBox > Terminate Programs, а в приложении Buster нажмите Stop Analysis.

7. Для просмотра отчётов нажмите Malware Analyzer в приложении Buster, чтобы увидеть список обнаруженных действий, или выберите Viewers > View Report. Вид отчёта показан на рисунке 8-11.

Рисунок 8-11. Отчёт Buster об анализе вредоносной программы

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

Главное преимущество Sandboxie и Buster заключается в том, что система фактически не заражается. На этом этапе возвращать виртуальную машину к чистому состоянию не требуется, если, конечно, вредоносная программа не вышла из песочницы. Если открыть каталог песочницы, как показано на рисунке 8-12, там сохраняются все сброшенные файлы. Более того, после каждого анализа можно создавать ZIP-архив всего содержимого C:\Sandbox\Administrator\DefaultBox\drive\C, быстро собирая все файлы, созданные или изменённые вредоносной программой.

Sandboxie также прекрасно подходит для совместного применения с браузером при исследовании потенциально опасных веб-сайтов. Если система будет успешно скомпрометирована через уязвимости браузера, можно будет получить копии всех загруженных в неё вредоносных программ. Дополнительные сведения об автоматизации анализа средствами этого рецепта приведены в публикации о Buster Sandbox Analyzer^[15] на форумах Sandboxie и в руководстве на сайте Raymond^[16].

Рисунок 8-12. Sandboxie сохраняет все файлы, созданные во время выполнения вредоносной программы

Process Monitor^[1] объединяет известные инструменты Filemon и Regmon от Sysinternals. Он регистрирует подробные сведения о действиях, связанных с файловой системой, реестром, сетью, процессами и потоками. Process Monitor сочетает подходы на основе перехватов и уведомлений. Он загружает драйвер ядра, перехватывающий такие функции, как ZwDeleteKey и ZwSetValueKey, для наблюдения за реестром. Однако сетевую активность он фиксирует посредством Event Tracing for Windows (ETW), то есть без перехватов. Для наблюдения за процессами и потоками также применяются процедуры уведомления; подробнее см. рецепт 9-10.

По умолчанию Process Monitor показывает следующие столбцы:

• Time of day: время зарегистрированного действия; столбец можно переключить на интервал с предыдущего действия;

• Process: имя процесса, выполнившего регистрируемое действие;

• PID: идентификатор процесса;

• Operation: вызванная функция API или, в некоторых случаях, краткое описание действия, например Process Create;

• Path: путь к объекту, файлу или ключу реестра, над которым выполняется действие;

• Result: состояние успешного или неудачного завершения операции;

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

На рисунке 9-1 показано создание фильтра, при котором Process Monitor регистрирует только изменения, внесённые процессами с именем cmd.exe. Фильтры можно задавать и по другим критериям, например идентификатору процесса или выполняемой операции.

Применив фильтр, нажмите значок увеличительного стекла, чтобы начать захват. Затем выполните анализируемую вредоносную программу. Для поиска признаков определённого поведения можно использовать графический интерфейс Process Monitor. Другой вариант - экспортировать результаты в текстовый файл и применить findstr в Windows или grep в Unix.

Вредоносные программы разными способами переживают перезагрузку, сохраняя присутствие на заражённой машине. Автоматический запуск при загрузке системы осложняет анализ: вредоносная программа может завершить свои действия до запуска средств наблюдения. Если выбрать Options > Enable Boot Logging, Process Monitor начнёт фиксировать API при следующей перезагрузке. Это важно, поскольку действия регистрируются с момента создания smss.exe, первого пользовательского процесса.

Это позволяет записать происходящее в системе ещё до запуска таких процессов, как csrss.exe, winlogon.exe и explorer.exe. На рисунке 9-2 показан пример регистрации загрузки.

Рисунок 9-1. Фильтрация вызовов API по имени процесса

Рисунок 9-2. Регистрация последовательности загрузки

Ещё один пример применения Process Monitor приведён в рецепте 13-4. Там же имеется видео на DVD, показывающее настройку фильтров Process Monitor, выделение и изоляцию определённых действий.

Regshot^[2] - инструмент обнаружения изменений на основе различий, ориентированный на файловую систему и реестр. Среди аналогов Regshot - InCtrl5^[3] и Winalysis^[4]. Regshot обладает несколькими преимуществами: имеет открытый исходный код, обычно работает значительно быстрее и представляет собой отдельный исполняемый файл, не требующий установки. Regshot применяет следующий метод:

• При создании первого, базового, снимка Regshot посредством RegEnumValue и RegEnumKeyEx строит в памяти список существующих ключей и значений реестра.

• Для файловой системы инструмент рекурсивно обходит любое число каталогов верхнего уровня и посредством FindFirstFile и FindNextFile строит в памяти список файлов. Для каждого файла записываются размер в байтах, атрибуты, например скрытый, системный и архивный, а также время последней записи.

• После создания второго снимка и сравнения Regshot сообщает обо всех созданных, изменённых или удалённых ключах и значениях реестра и файлах.

Чтобы использовать Regshot, укажите разделённые точкой с запятой каталоги верхнего уровня, за которыми требуется наблюдать. Для наиболее полных результатов необходимо включить корневой каталог диска C. Чтобы обнаружить попытки вредоносной программы распространяться посредством автозапуска, к анализируемой машине можно подключить USB-накопитель или дополнительный жёсткий диск и также наблюдать за ним, указав, например, корневые каталоги дисков C, F и G. Изменения реестра отслеживаются автоматически, поэтому этот компонент не требует настройки.

Для создания базового снимка нажмите first shot и дождитесь, пока Regshot закончит перечисление необходимых сведений. Затем выполните вредоносную программу, подождите требуемое время и нажмите second shot, как показано на рисунке 9-3.

Рисунок 9-3. Создание снимка файловой системы и реестра посредством Regshot

После завершения второго снимка нажмите compare, чтобы увидеть результаты. На рисунке 9-4 показан пример изменений, зарегистрированных Regshot.

Рисунок 9-4. Пример результатов Regshot

Каждый раздел отчёта Regshot содержит полезные сведения о поведении вредоносной программы. Из него можно сделать следующие выводы:

• Изменения реестра. Вредоносная программа изменяет параметр NoFolderOptions, запрещая пользователям управлять отображением папок в Проводнике Windows. В частности, пользователь больше не может настроить показ файлов со скрытым атрибутом. Она также изменяет DisableRegistryTools, не позволяя запускать стандартные редакторы реестра Windows и удалять добавленные ею записи.

• Добавленные файлы. Вредоносная программа добавляет файл csrssc.exe во временный каталог пользователя. В каталоге Prefetch появляются два новых файла, но это косвенные артефакты: их создала Windows, а не вредоносная программа. Файлы Prefetch являются ценными источниками криминалистических данных. Они показывают, что во время выполнения вредоносной программы в системе запускались файлы 944983008.exe и csrssc.exe. Без Prefetch можно было бы установить только создание csrssc.exe, но не факт его выполнения.

• Удалённые файлы. Вредоносная программа удаляет с рабочего стола пользователя файл 944983008.exe, то есть исходный образец. Следовательно, после выполнения она удаляет сама себя.

• Изменённые файлы или их атрибуты. Вредоносная программа непосредственно не изменяет файлы. Все показанные на рисунке 9-4 изменения косвенны. Например, файлы истории Internet Explorer, вероятно, изменились потому, что один из вредоносных процессов, 944983008.exe или csrssc.exe, использовал WinINet API. Функции WinINet автоматически обновили index.dat, файлы истории IE, указав посещённые сайты.

Инструменты на основе уведомлений могут обнаруживать изменения файловой системы, регистрируя функции обратного вызова. Функция обратного вызова - определённое программистом действие, которое Windows выполняет, когда любой процесс изменяет файлы в наблюдаемом каталоге. Представленный в этом рецепте инструмент RegFsNotify.exe, находящийся на DVD книги, наблюдает во всех каталогах верхнего уровня фиксированных, то есть локальных жёстких, и съёмных, то есть USB, дисков за новыми и удалёнными файлами, изменениями размера файлов и их атрибутов. В функции обратного вызова RegFsNotify.exe сообщает о произошедших действиях.

Для регистрации уведомлений об изменениях требуются следующие функции Windows API:

• FindFirstChangeNotification;

• FindNextChangeNotification;

• ReadDirectoryChangesW.

Первый аргумент FindFirstChangeNotification - имя наблюдаемого каталога. Второй указывает, нужно ли наблюдать за изменениями в подкаталогах, то есть рекурсивно. Третий представляет типы требуемых уведомлений. При успехе функция возвращает дескриптор. Её прототип API:

В таблице 9-2 приведены возможные значения параметра dwNotifyFilter.

Таблица 9-2. Возможные значения аргумента dwNotifyFilter

Если требуется зарегистрировать уведомления для нескольких каталогов с разными фильтрами, это также возможно. Например, можно обнаруживать созданные файлы в C:\WINDOWS\system32, но в C:\Users отслеживать только изменения существующих файлов. Для этого дважды вызывают FindFirstChangeNotification, а затем передают массив возвращённых дескрипторов функции WaitForMultipleObjects. Программа приостанавливается, пока какой-либо процесс не вызовет одно из уведомлений. Когда функция ожидания возвращает управление, программа посредством ReadDirectoryChangesW получает подробности изменения. Ниже приведены прототип этой функции API и структура возвращаемых данных.

Параметр hDirectory содержит дескриптор наблюдаемого каталога. Параметр lpBuffer - буфер для выходных данных. Выход представляет собой массив структур FILE_NOTIFY_INFORMATION, по одной для каждого изменения. Чтобы сообщить об изменениях, достаточно перебрать массив структур и вывести поля Action и FileName. Полный исходный код RegFsNotify.exe находится на DVD книги.

Для работы с RegFsNotify.exe просто вызовите его из командной строки: аргументы не требуются. Инструмент проверялся только в Windows XP и Windows 7, но может работать и в других версиях Windows. Чтобы остановить наблюдение, нажмите Ctrl+C в командной строке. Все журналы сохраняются в файл RegFsNotify.txt в текущем рабочем каталоге. Пример вывода RegFsNotify.exe показан на рисунке 9-5. На DVD книги также имеется видео о применении инструмента.

Рисунок 9-5. Анализ поведения вредоносной программы посредством RegFsNotify

Каждая строка вывода RegFsNotify.exe начинается с [ADDED], [REMOVED] или [MODIFIED], указывая вид произошедшего действия. По данным рисунка 9-5 можно сделать следующие выводы:

• Изменения реестра. Вредоносная программа несколько раз изменяет ключ реестра Image File Execution Options; наблюдение за реестром посредством уведомлений рассматривается в рецепте 9-4. Добавление новых значений в этот ключ вредоносной программой, скорее всего, является попыткой запретить выполнение антивирусных продуктов. Дополнительные сведения приведены в блоге McAfee.^[5]

• Добавленные файлы. Во время выполнения вредоносной программы были созданы следующие файлы:

◦ новый файл Prefetch C:\Windows\Prefetch\RUNDLL32.EXE; вероятнее всего, вредоносная программа сбросила или загрузила DLL, а затем выполнила её посредством rundll32.exe (см. рецепт 13-2);

◦ файл автозапуска C:\AUTORUN.INF, указывающий на попытку распространения на другие компьютеры.

• Удалённые файлы. Вредоносная программа удалила файл tete23418937t.dll. Судя по подозрительному имени, незадолго до удаления его создала сама вредоносная программа, то есть до её запуска файла в системе не было. Это пример временного файла из таблицы 9-1, который инструмент на основе различий, например Regshot, скорее всего, не обнаружил бы.

Помимо ограничений из таблицы 9-1, функции API для создания уведомлений иногда могут пропускать изменения. Например, при удалении каталога с 20 файлами уведомление может прийти только о самом каталоге и 12 его файлах. Это документированная слабость, проявляющаяся при множестве одновременных изменений. Кроме того, уведомления нельзя регистрировать для удалённых или общих сетевых дисков.

Уведомления об изменениях реестра работают несколько иначе, чем уведомления файловой системы. Можно получить уведомление об изменении ключа реестра или любого из его подразделов, но определить изменившийся ключ придётся самостоятельно. Иными словами, для реестра нет аналога ReadDirectoryChangesW. Эту проблему можно решить, заранее построив список в памяти, как Regshot, а затем определяя добавленные, изменённые и удалённые элементы, либо после уведомления рекурсивно разбирать реестр и проверять время последней записи.

Прототип API RegNotifyChangeKeyValue:

Параметр dwNotifyFilter может содержать одно или несколько значений из таблицы 9-3.

Таблица 9-3. Значения dwNotifyFilter

Авторы встроили код уведомлений реестра в RegFsNotify.exe, представленный в рецепте 9-3. По умолчанию он наблюдает за изменениями любого ключа в HKLM\Software и HKCU\Software. Можно добавить любое число ключей верхнего уровня. Некоторые антивирусные продукты используют такие уведомления, чтобы немедленно восстанавливать свои параметры реестра, если вредоносная программа пытается их удалить. Аналогично многие семейства вредоносных программ восстанавливают собственные параметры, удалённые антивирусом. Теперь этот метод можно добавить и в свои инструменты.

Рассмотренные до сих пор инструменты обнаруживают изменения постоянных, энергонезависимых данных, таких как файлы и ключи реестра. Если их не удалить, они сохраняются после перезагрузки. Однако другие виды данных, например объекты рабочего стола, мьютексы и события, более изменчивы. Без наблюдения за ними можно упустить важные аспекты поведения образца. В этом рецепте вводится сравнение таблиц дескрипторов и описывается созданный авторами инструмент HandleDiff.exe, находящийся на DVD книги.

Windows является объектно-ориентированной ОС: с точки зрения ядра всё представляет собой объект. Прежде чем приложение сможет выполнить операцию над объектом, например прочитать файл или записать в него данные, оно должно открыть дескриптор файлового объекта. На рисунке 9-6 показано применение инструмента Sysinternals WinObj^[6] для просмотра разных типов объектов в системе.

Рисунок 9-6. Просмотр типов объектов посредством WinObj

При анализе вредоносной программы о её поведении многое можно узнать по объектам каждого типа, к которым она обращается. Сам факт открытия дескриптора файла сообщает немного: важны имя файла и предоставленный доступ, например только чтение или запись. Один из инструментов для сбора сведений о дескрипторах - handle.exe от Sysinternals. Параметры -p и -a выводят все дескрипторы конкретного процесса, как показано на рисунке 9-7.

Рисунок 9-7. Открытые дескрипторы процесса с PID 1200

У некоторых объектов поле имени пусто. Это нормально для объектов вроде потоков и таймеров, у которых просто нет связанных имён. Другие объекты, например мьютексы, события и семафоры, могут быть именованными или неименованными: это зависит от того, разрешил ли создавший их процесс другим процессам системы обращаться к этим объектам. Ещё один инструмент проверки открытых дескрипторов процесса - Process Hacker.^[7] Как показано на рисунке 9-8, вкладка дескрипторов Process Hacker по умолчанию скрывает неименованные дескрипторы, но это можно изменить, сняв флажок.

Рисунок 9-8. Просмотр открытых дескрипторов посредством Process Hacker

Недостаток этих инструментов в том, что они показывают только дескрипторы, открытые процессом в текущий момент. Если при динамическом анализе вредоносная программа закроет дескриптор объекта до просмотра, часть действий будет пропущена. Другая проблема - огромное число дескрипторов, открытых каждым системным процессом в любой момент. Если другие процессы закрывают или открывают дескрипторы объектов вследствие действий вредоносной программы, как точно определить изменения?

Косвенные изменения, или побочные эффекты вредоносной активности, являются критически важными артефактами, которые следует фиксировать при анализе. Любая программа, вредоносная или нет, отвечает за несколько непреднамеренных и неконтролируемых изменений системы. Например, csrss.exe участвует в создании процессов пользовательского режима. Он открывает дескриптор каждого нового процесса, и тот остаётся открытым всё время работы процесса. Процесс может скрываться множеством способов, но его можно обнаружить, проверив открытые дескрипторы csrss.exe; это называется альтернативным перечислением процессов. Процесс может попытаться изменить таблицу дескрипторов csrss.exe (пример см. в рецепте 8-7), но для этого требуется открыть дескриптор самого csrss.exe. Таким образом, скрывая один артефакт, вредоносная программа вынуждена создавать другой.

Для решения проблемы авторы создали HandleDiff.exe. Программа сравнивает дескрипторы, открытые в каждом процессе до и после выполнения образца вредоносной программы. Иными словами, это инструмент обнаружения изменений на основе различий, но ориентированный на вновь открытые и закрытые дескрипторы. Ниже дано более техническое описание работы HandleDiff.exe; полный исходный код также находится на DVD книги.

• Перечисляет процессы системы посредством API CreateToolhelp32Snapshot с флагом TH32CS_SNAPPROCESS.

• Для каждого процесса вызывает NtQuerySystemInformation с классом SystemHandleInformation. Эта функция возвращает структуру SYSTEM_HANDLE_INFORMATION, содержащую массив структур SYSTEM_HANDLETABLE_ENTRY_INFO, по одной для каждого открытого в системе дескриптора. Поле UniqueProcessId указывает PID процесса-владельца.

• Открывает каждый процесс посредством OpenProcess, запрашивая разрешение PROCESS_DUP_HANDLE. HandleDiff.exe создаёт дубликаты открытых дескрипторов процесса вызовом API DuplicateHandle.

• Передаёт каждый дубликат в NtQueryObject с флагами ObjectTypeInformation и ObjectNameInformation. API возвращает тип дескриптора, например процесс, поток или файл, и имя описываемого им объекта.

• Записывает все собранные сведения о дескрипторах в вектор C++, то есть массив с динамическим размером, и повторяет все действия при втором снимке, создавая два вектора дескрипторов.

• Сравнивает, какие дескрипторы имеются в одном векторе, но отсутствуют в другом, точно определяя изменения.

Следующий синтаксис показывает применение HandleDiff.exe:

Чтобы перечислить все дескрипторы системы и вывести их в STDOUT:

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

Чтобы перечислить только именованные дескрипторы и сохранить их в файл:

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

Чтобы использовать режим сравнения с автоматическим таймером на 60 секунд и сохранить вывод в файл, что удобно для автоматизированных песочниц:

Следующие рецепты содержат практические примеры применения HandleDiff.exe для исследования таких вредоносных программ, как Zeus и Bankpatch.C. На DVD книги также имеется видео, пошагово показывающее работу с HandleDiff.exe и интерпретацию его вывода.

Zeus, также известный как Zbot, PRG, ntos и wsnpoem, - троян, активно использующий внедрение кода. Внедрённому Zeus в целевой процесс коду требуется доступ к DLL, от которых он зависит, файлам, ключам реестра, мьютексам и другим ресурсам. Поэтому целевой процесс открывает их дескрипторы. В этом рецепте показано применение HandleDiff.exe для исследования артефактов, создаваемых Zeus при заражении системы.

Чтобы точно определить, какие дескрипторы целевой процесс открывает вследствие работы внедрённого кода Zeus, можно настроить HandleDiff.exe с автоматическим таймером. До истечения таймера заразите систему Zeus. Ниже приведён фрагмент результатов:

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

До запуска Zeus у winlogon.exe было 516 открытых дескрипторов, после - 530. Без дополнительной проверки нельзя с уверенностью утверждать, что 14 новых дескрипторов непосредственно вызваны Zeus, но имена объектов позволяют дать более точную оценку:

• открытые дескрипторы файлов local.ds и user.ds непосредственно созданы Zeus: в этих файлах троян хранит конфигурацию и похищенные данные;

• открытый дескриптор ключа реестра Internet Settings - артефакт загрузки wininet.dll, сетевой DLL, используемой Zeus вместе с библиотекой Winsock wsock32.dll для связи с командно-управляющими сайтами;

• мьютекс _AVIRA_2109 создаётся Zeus для обозначения своего присутствия в системе;

• открытый дескриптор sdra64.exe, исполняемого файла Zeus на диске, удерживается заражённым процессом winlogon.exe, чтобы другие процессы не могли удалить файл.

Видео к этому рецепту на DVD книги показывает несколько других артефактов Zeus.

Microsoft Detours бесплатно доступна по некоммерческой лицензии, но поддерживает только x86. Для коммерческого использования или полной поддержки x64 требуется приобрести лицензию. Detours поддерживает разработку на C/C++, включает функции API для внедрения DLL в память целевого процесса и поставляется с множеством примеров исходного кода собственных программ. В этом рецепте показано создание монитора API посредством Detours и Microsoft Visual Studio.

1. Загрузите и установите Detours. Она поставляется как MSI-файл и по умолчанию располагается, например, в C:\Program Files\Microsoft Research\Detours Express 2.1; далее этот путь обозначается $DTHOME.

2. Создайте в Visual Studio новое решение. Выберите Win32 Console Application и задайте имя решения; в примере используется DetoursHooks, как показано на рисунке 9-10.

Рисунок 9-10. Создание нового проекта в Visual Studio

3. На странице мастера Application Settings выберите тип приложения DLL, как показано на рисунке 9-11, затем нажмите Finish.

Рисунок 9-11. Выбор DLL в качестве типа приложения

4. Скопируйте заголовочный файл Detours $DTHOME\include\detours.h и файлы библиотек $DTHOME\lib\detours.lib и $DTHOME\lib\detoured.lib в каталог проекта Visual Studio. В примере для них создан общий каталог, доступный другим проектам того же решения: C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\DetoursHooks\Shared.

5. Измените dllmain.cpp, подключив заголовочный файл detours.h и библиотеки detours.lib и detoured.lib.

6. Для каждой перехватываемой функции создайте переменную целевого указателя, хранящую адрес неизменённого API, и функцию-перехватчик, то есть собственный код. Прототип перехватываемой функции должен совпадать с определённым в заголовочных файлах Windows или показанным в MSDN. Следующий пример для DeleteFileA копирует удаляемый файл в выбранный каталог архива C:\archive.

7. В DLL необходимо добавить хотя бы одну экспортируемую функцию. Она может быть совершенно пустой. Это требование API Detours; для других библиотек перехвата этот шаг не нужен.

8. Измените функцию DllMain, чтобы при загрузке DLL процессом устанавливались перехваты, а при выгрузке снимались. Для этого применяются соответственно DetourAttach и DetourDetach. Например:

9. В Visual Studio выберите Build > Build Solution. Если ошибок нет, в каталоге Debug или Release появится скомпилированная DLL, названная по проекту, в нашем случае DetoursHooks.dll.

Теперь созданную DLL нужно поместить внутрь наблюдаемого процесса. Если целевой процесс уже выполняется, DLL можно внедрить несколькими способами, рассмотренными в главе 13. Если требуется создать новый процесс, например образец вредоносной программы, и внедрить DLL при запуске, до выполнения любого вредоносного кода, используйте описанный далее метод.

1. Добавьте новый проект в существующее решение Visual Studio. Так всеми проектами можно управлять в одном месте и компилировать их одновременно. В Solution Explorer щёлкните правой кнопкой имя существующего проекта, например DetoursHooks, и выберите Add > New Project, как показано на рисунке 9-12. Назовите программу внедрения; в примере используется DetoursInjection, затем нажмите Finish.

2. Добавьте в новый проект заголовочные файлы и библиотеки Detours. Код должен в точности совпадать с кодом шага 5 создания DLL.

Рисунок 9-12. Добавление нового проекта в Visual Studio

3. Используйте в программе внедрения DetourCreateProcessWithDll. Следующий простой пример принимает имя DLL и путь к выполняемому процессу. Всё, что указано в командной строке после имени процесса, передаётся создаваемому процессу как аргументы. Для простоты предполагается, что DetoursHooks.dll и detoured.dll находятся в одном каталоге с программой внедрения.

4. Выберите в Visual Studio Build > Build Solution. Теперь в каталоге Debug или Release должны находиться DetoursHooks.dll и DetoursInjector.exe. Скопируйте туда же $DTHOME\detoured.dll.

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

1. Как и прежде, добавьте в существующее решение новый проект. В примере он называется TestProject.

2. Вызовите из этой программы функции API, перехватываемые DLL. Пример проверочной программы:

3. Выберите в Visual Studio Build > Build Solution. Убедитесь, что в каталоге Debug или Release появился TestProject.exe.

4. Выполните проверочную программу под воздействием DLL перехвата API. Следующий вывод показывает, что все программы собраны в одном месте, а каталог C:\archive сначала пуст. После проверки он содержит копию notepad.exe, который проверочная программа пыталась удалить.

Вредоносные программы часто создают новые процессы. Новый процесс может быть сброшен или загружен вредоносной программой либо представлять собой экземпляр существующей программы, например Internet Explorer или cmd.exe. Такие процессы также необходимо сопровождать и наблюдать за ними, иначе будет зарегистрирована только часть поведения вредоносной программы. Рекурсивное внедрение DLL в новые процессы - одна из наиболее востребованных возможностей монитора API. В этом рецепте описаны методы сопровождения новых процессов.

Многие пользователи перехватывают функции API создания процессов, например CreateProcessW, и добавляют код внедрения DLL во вновь созданный процесс. Пример этого метода:

В большинстве случаев этот приём работает, но процессов может создавать множество функций API. На рисунке 9-13 показаны связи между 12 функциями API пользовательского режима из четырёх DLL: kernel32.dll, shell32.dll, advapi32.dll и ntdll.dll. Можно перехватить их все, но это весьма трудоёмко. Можно перехватить только NtCreateProcessEx, но тогда теряется часть контекста: например, нельзя будет легко определить, вызвала ли вредоносная программа сначала WinExec или ShellExecuteA. В зависимости от цели можно согласиться либо с дополнительной работой по перехвату всех функций, либо с потерей контекста высокого уровня. Кроме того, процессы могут создаваться особыми функциями API, такими как CreateProcessWithLogonW и CreateProcessWithTokenW, использующими RPC. В этих случаях одну из функций создания процесса вызывает сервер RPC, а не процесс с загруженной DLL наблюдения.

Рисунок 9-13. Возможные функции API для создания процессов

Вместо отдельного перехвата API создания процессов можно использовать значение реестра AppInit_DLLs в ключе HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows. Если ввести разделённые пробелами или запятыми пути к DLL, как показано на рисунке 9-14, новые процессы будут загружать DLL в указанном порядке.

Рисунок 9-14. Загрузка DLL посредством AppInit_DLLs

Недостаток AppInit_DLLs в том, что DLL загружаются только в процессы, которые также загружают user32.dll. Это делают все приложения с графическим интерфейсом и большинство образцов вредоносных программ, но некоторые программы командной строки не делают. Поэтому вредоносная программа всё ещё может создать процесс, который не удастся сопроводить и наблюдать.

Другой метод состоит в регистрации в ядре функции обратного вызова создания процесса, как описано в рецепте 9-10. Тогда создание нового процесса вредоносной программой обнаруживается независимо от способа. В рецепте 8-9 также показано автоматическое внедрение DLL в новые процессы посредством Sandboxie.

Процедура уведомления - функция обратного вызова, которую система выполняет при определённых событиях. В этом рецепте рассматриваются создание процессов и потоков и загрузка образов. В последние годы вредоносные программы с компонентами руткитов, такие как Mebroot^[10], BlackEnergy v2^[11], Rustock^[12] и TDL3^[13], эксплуатировали процедуры уведомления. Полезная нагрузка таких руткитов обычно заставляет новые процессы загружать вредоносную DLL, немедленно завершает процесс после запуска для противодействия отладке и обнаружению либо переключает SSDT нового потока на альтернативную таблицу (см. рецепт 17-6).

Процедуры уведомления имеют и законные применения. Многие антивирусные продукты регистрируют функции обратного вызова, проверяющие процессы на вредоносные строки, инструкции и известные сигнатуры. Так антивирус может предотвратить выполнение процесса или загрузку заражённой DLL. Другое законное применение - монитор событий для динамического анализа вредоносной программы. В этом рецепте показана реализация драйвера, который предупреждает о любых системных событиях во время выполнения образца. Следующие прототипы описывают функции API, применяемые драйверами для регистрации. Все необходимые заголовочные файлы входят в Windows Driver Kit (WDK).

Первый параметр каждой функции API - указатель на пользовательскую функцию обратного вызова указанного типа. Прототипы функций обратного вызова:

Для процедур уведомления действуют следующие правила:

• Создание процесса. При создании процесса функция обратного вызова выполняется в контексте потока, создавшего новый процесс. Параметры ProcessId и ParentId определяют процесс и его родителя.

• Создание потока. При создании потока функция обратного вызова выполняется в контексте потока, создавшего новый поток. Параметр ThreadId определяет идентификатор нового потока.

• Загрузка образа. Функция обратного вызова вызывается при каждой загрузке или отображении исполняемого образа в память. Образы загружаются при отображении основного исполняемого файла процесса, загрузке DLL процессом или загрузке драйвера ядра. Функция получает дисковый путь загружаемого образа и указатель на структуру IMAGE_INFO, содержащую базовый адрес образа в памяти и его размер.

Следующий код представляет пример драйвера, применяющего эти функции API для наблюдения:

После загрузки драйвера можно выполнить нужный образец вредоносной программы и наблюдать за его действиями в системе. Код рецепта выводит отладочные сообщения, которые можно перехватить посредством DebugView.^[14] В следующих рецептах показано, как объединить процедуры уведомления с другими приёмами динамического анализа и записывать результаты в файл. На рисунке 9-15 показаны отладочные сообщения после выполнения компонента трояна Koobface.

Рисунок 9-15. Процедуры уведомления, сработавшие при выполнении Koobface

Левый столбец DebugView содержит номер каждого отладочного сообщения. Эти номера соответствуют следующим событиям:

• № 14: запуск v2capcha.exe. Его родитель - explorer.exe, поскольку v2capcha.exe был запущен двойным щелчком в Проводнике Windows.

• № 16-25: исполняемые образы, отображённые в память вследствие запуска v2capcha.exe. Первая, немного сокращённая, запись № 16 содержит дисковый путь приложения v2capcha.exe; остальные относятся к загруженным им DLL.

• № 26-27: запуск cmd.exe программой v2capcha.exe. Не имеет значения, какой API, CreateProcess, ShellExecute, WinExec или другой, запустил cmd.exe, поскольку события отслеживаются без перехвата функций пользовательского режима. Функция обратного вызова создания процесса посредством PsLookupProcessByProcessId получает указатель на блок EPROCESS нового процесса. Поэтому вывод драйвера легко дополнить, например, параметрами командной строки нового процесса.

• № 28: завершение v2capcha.exe.

• № 29-39: запуск cmd.exe; его основной исполняемый файл и DLL отображаются в память.

• № 40-41: первый процесс cmd.exe запускает rundll32.exe.

• № 42-65: запуск rundll32.exe; его основной исполняемый файл и DLL отображаются в память.

• № 66-67: cmd.exe пытается удалить основной исполняемый файл v2captcha.exe и предполагаемый пакетный сценарий captcha.bat. Рассмотренные здесь процедуры уведомления не отвечают за наблюдение за удалением файлов; эти сведения получены методом из рецепта 9-11.

Процедуры уведомления чрезвычайно полезны для динамического анализа. События процессов и потоков, зарегистрированные Process Monitor в рецепте 9-1, также получены посредством таких процедур. Но Process Monitor не имеет открытого исходного кода, поэтому при срабатывании уведомлений нельзя выполнять собственные действия. Несколько изменений кода этого рецепта позволят драйверу активно реагировать на события, а не просто регистрировать их.

Командная оболочка Windows cmd.exe не имеет хорошего механизма хранения истории команд. Ранее введённые в конкретной оболочке команды можно исследовать командой DOSKEY /history, но после закрытия оболочки или перезагрузки системы это невозможно. В этом рецепте объясняется создание собственной командной оболочки, записывающей историю в файл. Регистрация команд сохраняет содержимое сброшенных вредоносной программой пакетных файлов, поскольку каждая их строка фактически проходит через командную оболочку, и показывает команды, вводимые злоумышленниками, даже если сетевой трафик зашифрован, что полезно для фиксации действий бэкдора.

Чтобы начать работу с ReactOS:

1. Загрузите и установите среду сборки ReactOS^[16] для систем, совместимых с Windows/NT. Можно попробовать среду для Linux-совместимых систем, но разработчики ReactOS предупреждают, что она может быть устаревшей.

2. Во время установки появится выбор компонентов, как на рисунке 9-20. Для этого рецепта нужны только Subversion Tools, остальные компоненты необязательны.

Рисунок 9-20. Установка среды сборки ReactOS

3. Чтобы открыть среду сборки, выберите Start > All Programs > ReactOS Build Environment > ReactOS Build Environment. При первом запуске программа предложит загрузить из SVN самый свежий исходный код ReactOS. Введите в приглашении ssvn create. По умолчанию файлы устанавливаются в C:\Documents and Settings\USERNAME\reactos; далее этот путь обозначается %ROSPATH%.

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

Выполните следующие действия. На DVD книги находится архив cmd_files.zip. При использовании исходного кода ReactOS версии 0.3.11 можно просто распаковать его файлы в %ROSPATH%\build\shell\cmd и перейти к шагу 7.

1. Создайте заголовочный файл %ROSPATH%\base\shell\cmd\proxy.h со следующим содержимым:

2. Измените %ROSPATH%\base\shell\cmd\precomp.h, подключив новый заголовочный файл:

3. Создайте исходный файл %ROSPATH%\base\shell\cmd\proxy.c. В нём находятся пользовательские функции из proxy.h. По умолчанию следующий код создаёт файл C:\commands.log, содержащий команды, выполненные пользователем, злоумышленником или образцом вредоносной программы через эту оболочку.

4. Добавьте следующую строку в %ROSPATH%\build\shell\cmd\cmd.rbuild, чтобы среда сборки компилировала proxy.c:

5. Измените %ROSPATH%\base\shell\cmd\cmd.c, добавив вызовы пользовательских функций. В частности, вызовите LogStart в самом начале функции Initialize. При желании измените приветствие с ReactOS Operating System[...] на Microsoft Windows[...], иначе злоумышленники могут заметить изменённую оболочку. Затем добавьте следующие строки в соответствующие места функции DoCommand:

6. Измените %ROSPATH%\base\shell\cmd\parser.c, добавив вызов пользовательской функции из процедуры ParseCommand, как показано ниже.

7. Пересоберите модуль cmd.exe, введя remake cmd в среде сборки ReactOS, как показано на рисунке 9-21.

Рисунок 9-21. Компиляция собственной командной оболочки

Теперь собственная командная оболочка находится в %ROSPATH%\output-i386\base\shell\cmd\cmd.exe. Осталось установить новый cmd.exe в honeypot или систему анализа вредоносных программ. Просто перезаписать исходный cmd.exe нельзя, поскольку он защищён WFP. Программа InstallCmdProxy.exe на DVD временно отключает WFP, создаёт резервную копию исходного cmd.exe, а затем заменяет его собственной оболочкой. Установщик работает только в Windows XP. Собственную оболочку можно использовать в Vista и 7, но для перезаписи cmd.exe WFP придётся отключить вручную. Установщик показан на рисунке 9-22.

Рисунок 9-22. Установка командной оболочки посредством InstallCmdProxy.exe

Теперь собственная оболочка готова. При каждом запуске нового экземпляра cmd.exe функция LogStart записывает идентификатор процесса. Когда вредоносная программа или злоумышленник в honeypot вводит команду в cmd.exe, LogCommand регистрирует действие. Следующий вывод получен от образца, известного антивирусным производителям как Pakes или Dogrobot. Видно, как вредоносная программа отключает службы безопасности, завершает процессы, задаёт права доступа к системному каталогу и удаляет себя.

Следующий вывод получен от образца, известного антивирусным производителям как вариант Rbot. Он устанавливает в систему несколько других исполняемых файлов, а затем запускает через cmd.exe пакетные файлы для удаления следов.

Вредоносные программы много лет скрываются в альтернативных потоках данных (ADS), и этот приём по-прежнему распространён. Проводник и вывод каталогов командной строки через cmd.exe не показывают данные ADS, поэтому файлы остаются скрытыми от пользователей без специальных средств просмотра. В этом рецепте рассматривается работа таких инструментов и применение TSK для обнаружения ADS как в работающих системах, так и на подключённых дисках.

Чтобы создать ADS, между именем файла-носителя и именем потока указывают двоеточие. Например, поток с именем stream можно присоединить к C:\host.txt так:

Команда dir покажет host.txt, но не поток. Размер host.txt также не увеличится. Поток по-прежнему можно читать и изменять, но для этого необходимо знать его имя:

Для обнаружения ADS в работающей системе можно использовать один из следующих инструментов командной строки:

• lads.exe^[1] Фрэнка Хейна (Frank Heyne);

• lns.exe^[2] Арне Видстрёма (Arne Vidstrom);

• sfind.exe^[3] от Foundstone;

• streams.exe^[4] Марка Руссиновича (Mark Russinovich).

Следует учитывать, что lns.exe и sfind.exe не обнаруживают потоки, присоединённые к папкам или дискам. В остальном инструменты действуют сходным образом. Они обходят файловую систему от заданного каталога верхнего уровня посредством функций API FindFirstFile и FindNextFile. Для каждого элемента вызывается BackupRead, чтобы найти связанные именованные потоки. Внутри BackupRead вызывает NtQueryInformationFile с классом FILE_INFORMATION_CLASS, равным FileStreamInformation. Исходный код перечисления ADS посредством BackupRead и прямого вызова собственного API NtQueryInformationFile находится на сайте Microsoft MVPs.^[5]

Слабость перечисленных инструментов в том, что они не перечисляют потоки, если скрыт файл или каталог-носитель. Например, если существуют host.txt и host.txt:stream, а руткит не позволяет FindNextFile показать host.txt, инструменты не смогут обнаружить host.txt:stream. Кроме того, некоторые средства поиска ADS подавляют потоки, связанные с нормальными действиями системы, например Zone.Identifier, который Internet Explorer присоединяет к загруженным файлам. Игнорирование таких потоков уменьшает шум, но способно скрыть свидетельства. Троян FFSearcher^[6] создавал поток Zone.Identifier, который на самом деле являлся вредоносной DLL и потому оставался невидимым для некоторых инструментов поиска ADS.

По этим причинам может потребоваться собственный инструмент обнаружения ADS в работающих системах либо способ находить потоки на подключённых дисках. Всё это позволяет сделать TSK. Он обходит файловую систему, разбирая MFT напрямую, поэтому перехват руткитом FindNextFile не мешает. MFT хранит сведения обо всех файлах и папках диска и является авторитетным источником данных об ADS. Фактически BackupRead и NtQueryInformationFile лишь косвенно читают структуры MFT.

Чтобы начать работу с TSK в работающей системе Windows, получите права администратора, необходимые для открытия физического диска, затем посредством mmls определите начальный сектор раздела NTFS. В следующем выводе это сектор 63.

Узнав смещение раздела NTFS, можно посредством fls перечислить файлы, а затем отфильтровать вывод по двоеточию в имени. Следующая команда выполняет рекурсивный поиск (-r) и выводит полные пути (-p). Авторы сократили результат до нескольких ADS, созданных для примера.

Первое число в каждой строке, 10815, - inode файла-носителя. Inode однозначно определяет каждый файл и каталог файловой системы. Следующее число, 128, - тип атрибута MFT, соответствующий $DATA. У каждого файла имеется хотя бы один атрибут $DATA с содержимым файла. Дополнительные атрибуты $DATA являются альтернативными потоками данных. У каждого атрибута есть идентификатор последовательности, позволяющий различать потоки:

• 10815-128-1 относится к стандартному атрибуту $DATA файла host.txt; идентификатор последовательности равен 1;

• 10815-128-3 относится к альтернативному потоку stream; идентификатор равен 3;

• 10815-128-4 относится к альтернативному потоку binary.exe; идентификатор равен 4.

Расширенные сведения о файле с inode 10815 выводятся командой istat:

Теперь виден размер каждого потока. Его содержимое извлекается с диска командой icat. Она читает MFT, определяет секторы с содержимым файла и восстанавливает файл. В результате получается копия без CreateFile, CopyFile и других API, которые руткиты часто перехватывают для сокрытия файлов или запрета доступа. Следующие команды извлекают содержимое host.txt и двух его альтернативных потоков.

Итак, обнаружение и извлечение ADS посредством TSK требует нескольких шагов. Однако приложение на основе API TSK может выполнять их автоматически (см. рецепт 10-2). В работающей системе TSK не неуязвим для руткитов, но прямые запросы к MFT позволяют обходить многие распространённые руткиты, перед которыми бессильны другие инструменты.

Полезный подход к обнаружению руткитов в работающих системах называется перекрёстным представлением. Такие инструменты получают сведения о системе двумя или несколькими способами, а затем ищут расхождения. Для обнаружения скрытых файлов это может быть низкоуровневое чтение MFT и высокоуровневый обход файловой системы посредством API Windows, таких как FindFirstFile и FindNextFile. Если файлы присутствуют в MFT, но не находятся через Windows API, их может скрывать руткит. В этом рецепте показан созданный авторами на основе TSK детектор скрытых файлов с перекрёстным представлением.

Одно из главных преимуществ TSK - это не просто набор заранее скомпилированных инструментов. TSK предоставляет API C для собственных приложений. В исходный код входят несколько примеров, которые можно скомпилировать в Microsoft Visual Studio или Linux посредством mingw32. Далее показаны необходимые начальные шаги. Дополнительные сведения доступны в интерактивном руководстве пользователя TSK и справочнике API.^[7]

1. Откройте образ диска и заключённую в нём систему томов:

2. Обойдите таблицу разделов тома, передав функцию обратного вызова в tsk_vs_part_walk. В примере функция part_act вызывается по одному разу для каждого раздела.

Функция обратного вызова получает структуру TSK_VS_PART_INFO со сведениями о типе раздела, например FAT или NTFS, его начальном секторе и размере.

3. В следующем коде разделы без файловой системы NTFS игнорируются, а остальные открываются посредством tsk_fs_open_img. Так автоматизируется применение mmls для поиска начального сектора NTFS, то есть параметра -o63, передававшегося инструментам TSK в рецепте 10-1.

4. Открыв NTFS, начните перечисление содержимого посредством tsk_fs_dir_walk. Параметры функции:

• первый, fs, - указатель на открытый объект файловой системы;

• второй, fs->root_inum, - номер inode каталога верхнего уровня, с которого начинается обход. Чтобы начать не с корня диска C, а с другого каталога, найдите его inode и передайте вместо fs->root_inum;

• третий, flags, управляет перечислением и включением файлов и каталогов в результат. Использованное сочетание игнорирует удалённые и специальные потерянные файлы и выполняет рекурсивный обход;

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

До выполнения xview_callback нужно посредством Windows API создать список файлов файловой системы. Это высокоуровневое представление для сравнения со списком MFT. В следующем коде вектор C++, то есть динамический массив, собирает полные пути всех файлов и каталогов. Функция win32_visible возвращает TRUE, если объект видим через Windows API, иначе FALSE.

Функция xview_callback вызывается для каждого файла или каталога системы. Она получает три аргумента: fs_file, указатель на структуру со сведениями о файле и метаданных; a_path, каталог файла; и необязательный ptr, передаваемый при вызове tsk_fs_dir_walk.

В начале выполняются проверки: объект должен быть файлом или каталогом, его метаданные должны быть доступны, и он не должен относиться к специальным файлам метаданных NTFS вроде $MFT и $Secure. Затем функция перебирает атрибуты файла, определяя наличие нескольких $DATA, то есть альтернативного потока, и находит атрибут $FILE_NAME_INFORMATION, позволяющий обнаруживать вредоносные программы, изменяющие временные метки; объяснение приведено далее. Главное для этого рецепта - полный путь каждого объекта передаётся в win32_visible. По возвращённому значению программа определяет, какие файлы скрыты от Windows API.

На рисунке 10-1 показан вывод tsk-xview.exe в системе со скрытыми объектами. Машина заражена Zeus, который скрывает файлы конфигурации перехватом NtQueryDirectoryFile.

Рисунок 10-1. Обнаружение скрытых файлов посредством tsk-xview.exe

Вывод содержит полный путь скрытого объекта, его inode, тип, то есть каталог или файл, размер и восемь временных меток: четыре из атрибута $STANDARD_INFORMATION (SIA) и четыре из $FILE_NAME (FNA). Все восемь показаны для обнаружения вредоносных программ, изменяющих временные метки, методом Лэнса Мюллера (Lance Mueller).^[8] Когда вредоносная программа посредством SetFileTime меняет время последнего доступа, записи или создания файла, изменение затрагивает только метки SIA. Поэтому если метки SIA предшествуют меткам FNA, возможно, программа пытается слиться со старыми файлами диска.

Следующий вывод получен на той же заражённой Zeus машине. Zeus не только скрывает sdra64.exe перехватом NtQueryDirectoryFile, но и приравнивает две временные метки файла к меткам ntdll.dll. Так sdra64.exe выглядит установленным одновременно с ntdll.dll, что может заставить администратора принять его за компонент Windows. В выводе время создания и последнего изменения SIA относится соответственно к 2008 и 2009 годам, а обе метки FNA - к 2010 году.

Описанный метод обнаруживает большинство способов сокрытия файлов, но не все. tsk-xview.exe неэффективен против следующих атак:

• вредоносная программа разрешает перечислить файл через Windows API, но перехватывает CreateFile, не позволяя его открыть;

• вредоносная программа разрешает перечислить и открыть файл, но перехватывает ReadFile и при попытке чтения возвращает ложные данные;

• вредоносная программа запрещает доступ к \\.\PhysicalDrive0, из-за чего инструмент не может прочитать MFT и просто не работает.

Дополнительные сведения о возможных атаках на обнаружение руткитов посредством перекрёстного представления приведены в работе Джоанны Рутковской (Joanna Rutkowska) Thoughts about Cross-View based Rootkit Detection.^[9]

Объединив TSK с автономным API реестра Microsoft^[11], можно создавать инструменты обнаружения скрытых данных реестра. В этом рецепте описано расширение инструмента перекрёстного представления из рецепта 10-2. Оно сравнивает данные в дисковых файлах кустов реестра с данными, которые, согласно Windows API, существуют в реестре. Расхождения могут указывать на попытку скрыть данные.

Для низкоуровневого представления реестра нужна копия дисковых файлов кустов. Её можно получить посредством TSK. Процесс System, PID 4 в Windows XP и 7, блокирует файлы кустов, не позволяя другим процессам обращаться к ним при включённой машине. Однако TSK открывает физический диск и извлекает содержимое файла куста сектор за сектором, обходя блокировки System. Затем копии разбираются автономным API реестра.

В рецепте 10-1 команда icat извлекала данные, скрытые в ADS. Те же действия можно выполнить API TSK и извлечь кусты реестра из работающей системы. Требуется лишь знать inode файлов, который находится функцией tsk_fs_ifind_path. Следующий код получает inode куста software по его дисковому пути. Параметр fs - указатель на открытый объект файловой системы, рассмотренный в рецепте 10-2.

Функция icat_dump, определённая в программе авторов и не входящая в API TSK, принимает inode извлекаемого файла и имя выходного файла. Посредством tsk_fs_open_meta она обращается к метаданным inode, содержащим список секторов с данными файла. Эти сведения и функция обратного вызова icat_action передаются в tsk_fs_file_walk. icat_action вызывается для каждого фрагмента содержимого и записывает его в выходной файл.

В примере куст software извлекается в software.bin, то есть получается его копия, как при копировании с подключённого диска. Тем же методом извлекаются кусты SAM, SECURITY, System и NTUSER.DAT.

Автономный API реестра позволяет читать и изменять куст вне активного системного реестра. Это именно то, что требуется для разбора файлов, извлечённых посредством TSK. API входит в Windows Driver Kit^[12] и реализован как распространяемая DLL offreg.dll. tsk-xview.exe динамически связывается с offreg.dll для доступа к необходимым функциям.

Если вы уже знакомы со стандартным Windows Registry API, автономный API почти не требует обучения. Функции принимают практически одинаковые параметры, но называются иначе. Например, сведения о ключе через Windows Registry API запрашиваются RegQueryInfoKey, а её автономный аналог - ORQueryInfoKey. Следующий код открывает файл куста и рекурсивно разбирает его ключи и значения.

При запуске программа выводит примерно следующее:

Авторы встроили поиск скрытых данных реестра в то же приложение tsk-xview.exe, которое в предыдущем рецепте искало скрытые файлы. На рисунке 10-2 показано его применение в системе, заражённой ранним вариантом руткита TDSS/TDL.^[13] Флаг -f пропускает анализ файловой системы. Флаг -k сохраняет извлечённые кусты вместо удаления, позволяя анализировать их другими инструментами из этой главы.

Рисунок 10-2. Обнаружение скрытых ключей реестра посредством TSK

Вывод показывает, что HKEY_LOCAL_MACHINE\Software\4DW4R3c был доступен автономному API реестра, но не перечислялся через Windows API; значений в ключе нет. В то же время скрытый HKEY_LOCAL_MACHINE\System\ControlSet001\Services\4DW4R3 содержит четыре значения конфигурации службы. Его подразделы injector и modules также невидимы через Windows API. Ключи и значения скрывает руткит, перехватывающий NtEnumerateKey и NtEnumerateValueKey.

Иногда сокрытие файлов и каталогов приносит больше проблем, чем пользы. Перехватывая API или загружая драйвер, изменяющий операции файловой системы, вредоносная программа создаёт множество дополнительных артефактов, способных выдать её присутствие. Попытка остаться незаметной может привести к противоположному результату. Помимо перехватов API существуют другие способы помешать копированию или удалению компонентов вредоносной программы. В этом рецепте показано исследование и обход заблокированных файлов Poison Ivy из командной строки без перезагрузки или выключения системы.

Некоторые варианты трояна Poison Ivy^[14] блокируют файлы, задавая ограничительный режим совместного доступа. Прототип API CreateFile:

Параметр dwShareMode задаёт режим совместного доступа: FILE_SHARE_DELETE, FILE_SHARE_READ, FILE_SHARE_WRITE, любое их сочетание либо ни одного. Для полного запрета совместного доступа CreateFile вызывается с dwShareMode, равным 0. При успехе функция возвращает дескриптор файла. Все последующие вызовы CreateFile любым процессом для того же файла будут завершаться неудачно, пока владеющий процесс не закроет свой дескриптор.

При выполнении Poison Ivy часто копирует себя в каталог system32; в примере используется имя toli.exe. Затем он внедряет код в другой процесс и из него открывает дескриптор toli.exe. Внедрённый процесс вызывает CreateFile примерно так:

В результате toli.exe невозможно скопировать на другую машину для анализа или удалить при очистке заражённой системы. При обеих операциях, где диск F: является USB-накопителем, вероятен следующий вывод:

Теперь причина подобных сообщений Windows понятна. Чтобы обойти ограничительный режим совместного доступа, сначала определите процесс, заблокировавший файл. Process Explorer и Process Hacker умеют искать DLL или файловый дескриптор по имени, но при удалённом расследовании может быть удобнее командная строка. Для этого подходит handle.exe от Sysinternals:

Виноват Explorer с PID 1592: он держит открытый дескриптор toli.exe со значением 204. Прежде чем получить доступ к файлу, посредством отладчика ядра выясним, что именно мешает.

Эти действия не нужны для копирования или удаления заблокированного файла; они лишь объясняют причину отказа. Настройка отладчика ядра описана в главе 14.

1. Первые две команды находят процесс Explorer и переключаются в его контекст.

2. Следующая команда выводит сведения о подозрительном дескрипторе Explorer. Это объект File с адресом 82261028 и именем toli.exe.

3. По адресу объекта примените поля структуры _FILE_OBJECT и просмотрите действующие режимы совместного доступа. Значения ShareRead, ShareWrite и ShareDelete равны 0, что объясняет невозможность обратиться к файлу.

Чтобы скопировать или удалить, далее совместно называемые доступом, заблокированный файл, доступны следующие варианты:

• принудительно завершить Explorer, надеясь, что Poison Ivy не заразит его снова после перезапуска, затем обратиться к файлу;

• загрузиться в безопасном режиме и обратиться к файлу до запуска Poison Ivy;

• загрузить компьютер с Live CD Linux, подключить диск Windows для чтения и записи, затем обратиться к файлу;

• использовать антируткит вроде GMER (см. рецепт 10-6).

Следующий код показывает ещё один способ, не завершающий процессы и не требующий перезагрузки. Это утилита командной строки, которую можно запускать удалённо через PsExec. Программа закрывает открытый дескриптор нужного файла, создавая его дубликат с правами DUPLICATE_CLOSE_SOURCE, после чего файл становится доступен.

Программе передаются PID владеющего процесса, здесь 1592 для Explorer, и значение дескриптора объекта. Следующие команды закрывают дескриптор toli.exe в Explorer, после чего файл можно скопировать и удалить.

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

Печально известный червь Conficker пошёл дальше Poison Ivy. Он помещал DLL в каталог system32, а затем изменял ACL файла так, что другим процессам разрешалось только его выполнение. Попытки чтения или записи DLL запрещались даже процессам с правами администратора. Это затрудняло удаление Conficker и позволяло червю уклоняться от некоторых антивирусов, не способных открыть DLL для проверки.

Чтобы продемонстрировать действие изменений ACL, сделаем копию kernel32.dll в корневом каталоге. В примере она имитирует двоичный файл Conficker. Инструмент AccessChk^[15] от Sysinternals выводит действующие разрешения DLL:

Администраторы имеют полный контроль над файлом (FILE_ALL_ACCESS). Чтобы изменить безопасность, Conficker вызовом AddAccessAllowedAce добавляет к DLL ACE, запись управления доступом внутри ACL. Особенность функции в том, что она не сохраняет существующие ACE автоматически: программист должен копировать их самостоятельно. Поэтому следующий код фактически заменяет все ACE одной записью, запрещающей чтение и запись всем пользователям, включая администраторов. Авторы восстановили этот код из двоичного файла Conficker.

После изменения параметров безопасности test.dll функцией снова проверим действующие разрешения:

Теперь процессы могут загружать DLL для выполнения, но не читать и не записывать её. Проверим чтение посредством more, запись посредством echo, затем выполним DLL через rundll32. Параметры tasklist находят процессы с загруженным модулем test.dll, подтверждая, что rundll32 способен выполнить DLL.

Получить доступ к защищённому файлу без перезагрузки или выключения можно посредством семантики резервного копирования. Программа передаёт FILE_FLAG_BACKUP_SEMANTICS в аргументе dwFlagsAndAttributes функции CreateFile. Этот специальный флаг сообщает, что процесс запрашивает доступ для резервного копирования или восстановления. Для этого у процесса должны быть включены привилегии SE_BACKUP_NAME и SE_RESTORE_NAME. В результате он получает сверхпользовательский доступ к файлу, даже если ACL обычно запрещает его.

Этот метод обходит изменения ACL Conficker, но с одной оговоркой: записывать DLL всё равно нельзя, пока она загружена в процесс. Теперь это уже не проблема ACL, а проблема ссылки на DLL. Необходимо завершить заражённый процесс или принудительно выгрузить DLL. Process Hacker умеет выгружать DLL из процесса; также можно создать собственный инструмент, удалённо вызывающий FreeLibrary (см. рецепт 13-4). Однако такая выгрузка рискованна и может привести к аварийному завершению процесса.

Другой вариант - поставляемая с Windows утилита cacls.exe или xcacls.exe.^[16] Она позволяет изменить ACL из командной строки и отменить изменения Conficker. В частности, можно удалить права выполнения у всех пользователей, а затем перезагрузить заражённую машину. После перезагрузки вредоносная программа не запустится, и DLL удастся скопировать или удалить.

1. Проверьте текущий доступ. Результат должен быть похож на вывод accesschk.exe.

2. Удалите все права пользователя Everyone.

3. Добавьте пользователю Administrator право чтения, но не выполнения.

4. Снова проверьте текущий доступ и убедитесь, что изменения применены.

5. Перезагрузите компьютер. DLL больше не активируется, поскольку не является исполняемой.

GMER^[17] - мощный самостоятельный инструмент обнаружения и удаления руткитов. Он работает в Windows NT, 2000, XP и Vista и способен обнаруживать большинство распространённых руткитов. Интерфейса командной строки нет, но с учётом возможностей это несущественный недостаток. GMER ищет:

• скрытые процессы, DLL, потоки, драйверы ядра, службы, файлы и ключи реестра;

• альтернативные потоки данных;

• перехваты Import Address Table (IAT), Export Address Table (EAT) и встроенные перехваты;

• перехваты System Service Dispatch Table (SSDT);

• перехваты Interrupt Descriptor Table (IDT);

• перехваченные процедуры I/O Request Packet (IRP) в драйверах ядра;

• подозрительные изменения Master Boot Record (MBR);

• подозрительные многоуровневые драйверы или присоединённые устройства;

• драйверы, точки входа которых находятся в подозрительных разделах PE, например .rsrc, что может указывать на изменение драйвера на диске руткитом;

• процессы с несоответствующими разрешениями разделов, например исполняемым разделом .rdata.

На рисунке 10-3 показан графический интерфейс GMER. Щёлкнув запись результата правой кнопкой, можно завершить подозрительный процесс, отключить или удалить службу и восстановить перехваты SSDT.

Рисунок 10-3. Поиск руткитов в системе посредством GMER

По результатам можно сделать следующие выводы:

• Вредоносная программа установила перехваты IAT. GMER показывает заражение процесса alg.exe с PID 2324; вероятно, заражены и другие процессы, не попавшие на изображение. Изменены IAT всех модулей, загруженных в alg.exe, включая ole32.dll, WS2HELP.dll, SHELL32.dll, SHLWAPI.dll и wininet.dll. Среди перехваченных функций API - GetClipboardData для кражи содержимого буфера обмена, TranslateMessage для кражи нажатий клавиш и NtQueryDirectoryFile для сокрытия файлов. Поле Value показывает адрес перенаправления вызовов: все значения находятся в диапазоне 00A1???? - 00AA????, поэтому код руткита следует искать по этим адресам в памяти alg.exe.

• Вредоносная программа установила драйвер ядра. Она использовала многоуровневую архитектуру драйверов Windows и загрузила вредоносный драйвер в стек TCP/IP. Руткит способен наблюдать за трафиком, перенаправлять соединения или скрывать подключения бэкдора к машине жертвы. Имя драйвера - windev-36cb-75e3.sys.

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

• Вредоносная программа скрывает ключи реестра. Скрытые данные содержат конфигурацию скрытой службы.

На вкладке Files GMER позволяет просматривать файловую систему на более низком уровне, чем Проводник Windows. Поэтому видны файлы, которые руткиты обычно скрывают от Проводника и других приложений пользовательского режима. Конечно, скрыться можно и от GMER, но загружаемый им драйвер доступа к файловой системе значительно повышает вероятность найти скрытые файлы. На рисунке 10-4 показан обозреватель файловой системы. Авторы установили флажок Only hidden и открыли каталог system32, быстро сократив результат до четырёх вредоносных файлов. Их можно скопировать, например на USB-накопитель, либо удалить.

Рисунок 10-4. Поиск и удаление скрытых файлов

Вкладка Registry позволяет просматривать реестр подобно Regedit, но показывает ключи и значения, скрытые руткитами или обычно недоступные из-за отсутствия разрешений, например SAM и ключи поставщика защищённого хранилища. Скрытые ключи выделяются красным. На рисунке 10-5 показано изменение данных скрытого значения для отключения автоматического запуска программ.

Рисунок 10-5. Поиск и удаление скрытых ключей реестра

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

• Rootkit Unhooker^[18];

• IceSword^[19];

• Kernel Detective^[20];

• XueTr^[21];

• RootRepeal^[22].

Внедрение HTML - распространённая атака банковских троянов, таких как Silent Banker, Limbo и Zeus. В этом рецепте представлены несколько способов внедрения HTML, объяснена их работа и показано обнаружение такой вредоносной программы на компьютере.

Цель атаки - вставить дополнительные поля в браузер пользователя при посещении страницы входа, обычно банковского, социального или почтового сайта. Дополнительные поля выглядят законными, поскольку сливаются с остальной формой. На рисунке 10-6 слева показана чистая система, справа - заражённая. Дополнительное поле запрашивает PIN, что некоторым пользователям не покажется необычным, особенно по защищённому SSL-соединению банка. После заполнения формы и нажатия Go вредоносная программа извлекает учётные данные вместе с PIN.

Рисунок 10-6. Атака с внедрением HTML вынуждает пользователя вводить дополнительные сведения

Внедрение HTML может выполняться традиционной атакой «человек посередине» (MITM), когда вредоносный узел располагается в сети между веб-сервером и компьютером жертвы. Это позволяет заменить или вставить данные в ответ сервера до его получения жертвой. Из-за сложностей SSL и необходимости особого положения в сети традиционный MITM встречается реже. Более распространены перехват API и изменение DOM Internet Explorer.

В рецепте 9-8 объяснялось создание DLL, перехватывающих API. Вредоносные программы используют тот же принцип, хотя и другие библиотеки перехвата. Обычно перехватываются InternetReadFile и HttpSendRequest. Internet Explorer вызывает InternetReadFile, чтобы получить указанное число байтов ответа сервера и вывести их в браузере. Перехват позволяет вредоносной программе изменить ответ до показа пользователю.

В обратном направлении HttpSendRequest отправляет веб-серверу запрос с необязательной полезной нагрузкой POST. Перехват позволяет извлечь из неё учётные данные. HTTPS не мешает: InternetReadFile получает данные после расшифровки, а HttpSendRequest - до шифрования, поэтому вредоносная программа видит открытый текст. Следующий код показывает применение перехватов API для внедрения HTML.

Вредоносные программы часто используют DOM, Document Object Model, Internet Explorer в разных целях, включая внедрение HTML. DOM можно представить как совокупность элементов веб-страницы. Каждым отдельным элементом, например ссылкой, формой, якорем, текстовым полем или таблицей, можно управлять через специальные интерфейсы. Подключившись к DOM экземпляра браузера, вредоносный код способен наблюдать за всеми посещаемыми URL, заставлять браузер отправлять POST на подконтрольный злоумышленнику сайт и удалять столбцы HTML-таблиц, скрывая операции в выписках интернет-банка.

Для управления DOM особенно важны интерфейсы IWebBrowser2^[23] и IHTMLDocument2.^[24] Вредоносная программа может обратиться к ним, загрузив DLL в Internet Explorer, например как Browser Helper Object, либо из отдельного процесса без внедрения кода в IE. Для демонстрации авторы создали простую страницу входа по адресу http://www.1234.org/login.php со следующим HTML; 1234 используется только как пример.

Метод формы - POST, действие - checklogin.php. Злоумышленник может заменить действие, чтобы при нажатии Login браузер отправлял данные на подконтрольный ему сайт. Следующая программа ждёт посещения http://www.1234.org/login.php, затем через интерфейсы DOM достигает элемента формы и меняет её действие на http://bad.com/creds.php.

Перехват API - простой и эффективный способ внедрения HTML, но его легко обнаружить: любой антируткит перечисляет перехваченные функции, а законных причин перехватывать InternetReadFile и HttpSendRequest немного. Изменение DOM хитрее, поскольку не перехватывает функции. Но при обоих методах изменения существуют только в памяти процесса браузера. Если браузер кэширует страницу, в каталоге Temporary Internet Files остаётся файл с исходным содержимым.

На рисунке 10-7 показан браузер после атаки через DOM. При выборе View > Source IE обращается к дисковому файлу кэша, а не к памяти. Поэтому по такому исходному HTML нельзя определить изменение представления страницы в браузере: действие формы всё ещё указывает checklogin.php.

Рисунок 10-7. При просмотре исходного кода IE получает содержимое из файла кэша

Для обнаружения внедрения HTML авторы создали HTMLInjectionDetector.exe, находящийся на DVD. Он работает следующим образом:

1. Запустите программу на предположительно заражённой машине из командной строки, передав текстовый файл со списком проверяемых сайтов.

2. Программа запускает новый процесс Internet Explorer для каждого сайта, открывает URL, ждёт завершения загрузки и ещё несколько секунд, чтобы вредоносная программа успела внедрить HTML.

3. Программа обращается к DOM браузера теми же API, но вместо изменений сохраняет содержимое страницы в файл рабочего каталога с суффиксом _dom.txt.

4. Посредством GetUrlCacheEntryInfo она проверяет наличие кэшированной копии страницы и, если та есть, копирует её из Temporary Internet Files в рабочий каталог с суффиксом _cache.txt.

5. Программа делает снимок окна IE и сохраняет его в рабочем каталоге, позволяя увидеть страницу в браузере.

Пример применения:

Созданы три файла:

• www.1234.org_dom.txt - копия HTML, показанного браузером IE;

• www.1234.org_cache.txt - копия HTML, первоначально возвращённого веб-сервером;

• www.1234.org.bmp - снимок отображения посещённого URL в браузере.

На рисунке 10-8 видно, что сравнение файлов легко выявляет изменения страницы.

Рисунок 10-8. Сравнение DOM и файла кэша обнаруживает расхождение

Даже если точно знать, как сайт должен выглядеть, и проверять действия форм и другие переменные через исходный код страницы, вредоносная программа всё равно могла изменить браузер. Проведённая для демонстрации атака является лишь проверкой концепции. Если злоумышленник заменит формы HTTPS-сайта так, чтобы они отправляли данные на HTTP-сайт, пользователь, вероятно, увидит предупреждение. Однако встречаются вредоносные программы, которые отключают такие предупреждения, изменяя режим ошибок Internet Explorer.

RegRipper^[25] Харлана Карви (Harlan Carvey) - среда криминалистического анализа реестра, быстро извлекающая ключи, значения, данные и временные метки из автономного файла куста. Она написана на Perl и основана на модуле Parse::Win32Registry Джеймса Макфарлейна (James McFarlane). RegRipper значительно отличается от просмотрщика или редактора вроде Regedit. Во-первых, он не предназначен для работы с кустами активной системы: их сначала нужно скопировать с подозрительной машины. Во-вторых, по выражению Харлана, RegRipper не используют для неспешного осмотра реестра. Он основан на подключаемых модулях, жёстко запрограммированных на извлечение данных из определённых мест.

RegRipper содержит более 75 модулей. Их список выводится вызовом rip.pl с флагом -l. Все перечислять не будем; в таблице 10-1 приведены особенно полезные при расследовании вредоносных программ.

Таблица 10-1. Некоторые подключаемые модули RegRipper

Следующие примеры показывают применение RegRipper и начало создания собственных модулей. Полный исходный код всех модулей рецепта и нескольких дополнительных находится на DVD. Чтобы сделать их доступными rip.pl, поместите файлы в каталог plugins.

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

По умолчанию маршруты команды route не сохраняются после перезапуска TCP/IP. Флаг -p делает их постоянными. Сведения сохраняются в реестре и загружаются при каждом запуске TCP/IP. Постоянные маршруты находятся в кусте system по ключу HKLM\System\ControlSet001\Services\Tcpip\Parameters\PersistentRoutes. Имя каждого значения - список network,netmask,gateway,metric, разделённый запятыми.

Тело модуля routes.pl, извлекающего постоянные маршруты:

Пример применения модуля routes. Постоянные маршруты сами по себе не доказывают заражение. Методами исследования IP и сетей из главы 5 определите, должна ли машина связываться с удалёнными системами.

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

Вредоносная программа часто следит за своими файлами и создаёт их снова, если пользователь или антивирус пытается удалить их. Если файл не исчезает, системе можно поручить удалить его при следующей перезагрузке. Для этого в параметре dwFlags функции MoveFileEx передаётся MOVEFILE_DELAY_UNTIL_REBOOT, а имя нового файла оставляется NULL.

MoveFileEx добавляет имена файлов в значение PendingFileRenameOperations куста System по ключу HKLM\System\ControlSet001\Control\Session Manager. При следующей загрузке диспетчер сеансов smss.exe читает значение и удаляет или перемещает файлы. Поскольку smss.exe является первым процессом пользовательского режима, он выполняет действия без помех других процессов, хотя драйверы ядра могут загрузиться раньше и вмешаться.

Как можно предположить, вредоносные программы используют MoveFileEx в своих целях, обычно для уничтожения сброшенных или загруженных временных файлов. Если после заражения машина не перезагружалась, исследуйте PendingFileRenameOperations. Тип данных этого значения - REG_MULTI_SZ, последовательность строк с завершающим NULL. Каждый вызов MoveFileEx добавляет две строки: исходное имя и имя назначения. Если исходный файл нужно удалить, назначение является пустой строкой.

Тело модуля pendingdelete.pl, разбирающего PendingFileRenameOperations:

Пример применения модуля к заражённой машине:

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

Этот пример показывает сопоставление значений разных ключей реестра. Цель - исследовать вредоносную программу, внедряющую код в другие процессы через расширения ShellExecute. API ShellExecute, как и CreateProcess, запускает новый процесс. Но вместо пути к исполняемому файлу ему можно передать, например, C:\info.txt. ShellExecute находит стандартное приложение для .txt и запускает Блокнот. Фактически каждый двойной щелчок в Проводнике приводит к вызову ShellExecute.

Расширения ShellExecute реализуются как DLL с пользовательскими процедурами специальной обработки открываемых или выполняемых объектов. Если выбрать Start > Run и ввести http://www.google.com, вызывающий ShellExecute процесс, в данном случае Explorer, загружает DLL специальной обработки. В большинстве систем заранее установлено хотя бы одно расширение, открывающее браузер, когда объект начинается с http:.

Многие семейства вредоносных программ устанавливают собственные расширения ShellExecute только для внедрения DLL в Explorer и любой другой процесс, вызывающий ShellExecute. Они регистрируют идентификатор класса CLSID, затем записывают его в значение ключа HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks. Значение имеет тип REG_SZ, данные в нём необязательны.

Модуль shellexecute.pl перечисляет расширения и ищет соответствующий CLSID в HKLM\Software\Classes\CLSID, чтобы также вывести связанную DLL.

В следующем примере первая запись shell32.dll с описанием URL Exec Hook является законным обработчиком HTTP. Вторая, softqq0.dll с описанием hook dll rising, вредоносна. Описание необязательно, но злоумышленники всё равно добавили его, причём крайне незаметным его не назовёшь. Microsoft называет это семейство Taterf.^[26]

RegRipper способен сэкономить огромное время расследования. Лучше коллекции часто изменяемых вредоносными программами ключей и значений может быть только возможность проверить все эти места одной-двумя командами. Применение RegRipper к дампам памяти показано в рецепте 18-7.

Инфраструктура открытых ключей (PKI) устанавливает доверие в Интернете. При посещении SSL-сайта браузер проверяет законность его сертификата, убеждаясь, что тот подписан центром сертификации (CA), которому браузер доверяет. Для этого браузер получает открытый ключ CA из реестра компьютера и выполняет проверку. Вредоносная программа может установить собственный созданный злоумышленниками сертификат CA, заставив компьютер доверять незаконным сайтам. В этом рецепте показано извлечение сертификатов из куста реестра и их проверка посредством OpenSSL.

Sophos опубликовала подробный анализ^[27] образца TROJ/BHO-QP, устанавливающего поддельный сертификат CA. Авторы вредоносной программы:

1. создали поддельный сертификат подписи кода VeriSign;

2. посредством поддельного VeriSign выдали поддельный сертификат Microsoft;

3. подписали вредоносную DLL поддельным сертификатом Microsoft.

4. установили DLL как Browser Helper Object (BHO) Internet Explorer на машине жертвы;

5. установили поддельный сертификат VeriSign как доверенный корневой CA на машине жертвы.

В результате компьютер полностью доверяет вредоносной DLL, поскольку она выглядит подписанной Microsoft.

Windows хранит сертификаты в нескольких местах реестра. Microsoft документировала их для Windows 2000, XP и Server 2003, а также применимых к Windows 7, в статье TechNet Certificates Tools and Settings.^[28] Наиболее интересны HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates и HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates. В них имеются следующие подразделы:

• AuthRoot - корневые сертификаты CA не от Microsoft;

• ROOT - доверенные корневые сертификаты CA;

• CA - промежуточные сертификаты CA;

• Disallowed - отклонённые или недоверенные сертификаты;

• trust - сертификаты корпоративного доверия;

• TrustedPublisher - сертификаты, явно принятые как доверенные;

• MY - личные сертификаты пользователя.

Каждый подраздел содержит Certificates, а тот - подраздел для каждого установленного сертификата данного типа. Сертификат хранится в двоичном значении Blob. Вредоносная программа, установившая поддельный VeriSign CA, создала Blob в HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\ROOT\Certificates\uniqueid. Поле uniqueid является хешем или отпечатком сертификата. На рисунке 10-9 показаны необработанные данные одного доверенного корневого CA.

Рисунок 10-9. Просмотр сертификатов в реестре

Реестр хранит сертификаты в формате DER со специальным заголовком Microsoft. На рисунке 10-9 выделено начало DER-кодированного сертификата в Blob. Здесь сертификат начинается со смещения 0x84, но оно неодинаково для всех сертификатов. При экспорте через оснастку MMC или программно посредством PFXExportCertStore заголовок удаляется автоматически. При извлечении необработанных данных реестра его нужно удалить самостоятельно. Вместо разбора заголовка Microsoft авторы написали регулярное выражение Perl, находящее начало DER-сертификата в двоичном блоке.

Сценарий dumpcerts.pl на DVD посредством Parse::Win32Registry автоматизирует эти действия. Он извлекает сертификаты из файла куста и сохраняет их в каталог. Параметры командной строки позволяют извлекать только определённые типы или сертификаты с заданным шаблоном в поле субъекта, то есть CN. Кроме того, сценарий преобразует DER в PEM для проверки OpenSSL.

Сначала выведем справку:

На рисунке 10-10 показаны синтаксис и вывод извлечения всех корневых CA, в поле субъекта которых без учёта регистра присутствует verisign class. Этот шаблон выбран по отчёту Sophos о вредоносном сертификате VeriSign Class 3 Code Signing.

Рисунок 10-10. Извлечение вредоносного сертификата посредством dumpcerts.pl

На первый взгляд законность сертификата на рисунке определить нельзя. Но сравнение с атрибутами из отчёта Sophos быстро подтверждает совпадение. Например, поддельный сертификат использует алгоритм подписи md5WithRSAEncryption, а настоящий - sha1WithRSAEncryption. Если заранее неизвестен шаблон поиска, лучше извлечь все сертификаты флагом -a и позволить OpenSSL вывести атрибуты для подробной проверки.

При проверке OpenSSL даже законные сертификаты иногда выглядят самоподписанными, вероятно потому, что открытому ключу выпустившего CA нет доступа. В Ubuntu команда apt-get install ca-certificates устанавливает открытые ключи многих распространённых CA. В /etc/ssl/certs появится более 200 отдельных сертификатов и объединённый PEM-файл /etc/ssl/certs/ca-certificates.crt. В openssl можно передать каталог через -CApath или файл через -CAfile. Подробнее см. публикацию Ричарда Бейтлиха (Richard Bejtlich) Using Root Certificates with OpenSSL on FreeBSD.^[29]

При вызове RegSetValue или RegSetValueEx приложение указывает тип записываемых данных. Допустимы строки с завершающим NULL (REG_SZ), несколько таких строк (REG_MULTI_SZ), двоичные данные (REG_BINARY) и беззнаковые длинные целые (REG_DWORD). Инструменты вроде Regedit форматируют данные по указанному типу для удобства чтения. Проблема возникает, когда вредоносная программа вставляет двоичные данные, но указывает REG_SZ: Regedit воспринимает их как строку и показывает только символы до первого завершающего NULL. Так данные можно скрыть «за» строкой в реестре.

В этом рецепте показан поиск двоичных данных, замаскированных под строку. Такие артефакты возникают по двум основным причинам. Очевидная - вредоносная программа намеренно записывает двоичные данные в значение типа REG_SZ. Менее очевидная и более интересная - она делает это случайно. Программа намеревается записать строку с NULL, но указывает длину значительно больше фактической. Тогда RegSetValueEx записывает строку и лишние байты памяти после неё. Ошибка вредоносной программы приводит к утечке изменчивых данных, способных содержать сведения о состоянии выполнения, в более постоянное хранилище - реестр.

Puzlpman^[30] и Mozipowp^[31] - примеры вредоносных программ, случайно утекающих данными в реестр. Для демонстрации авторы установили вариант Mozipowp на проверочную машину. На рисунке 10-11 показаны значения, созданные им в HKEY_CURRENT_USER\Identities. По Regedit невозможно догадаться, что за значениями Curr version, Inst Date, Last Date, Popup count, Popup date и Popup time скрыт значительный объём двоичных данных.

Рисунок 10-11. Исследование записей Mozipowp в реестре посредством Regedit

На DVD находится сценарий Perl somethingelse.pl, для которого авторам не удалось придумать более выразительного имени. Он основан на Parse::Win32Registry, рекурсивно обходит все ключи и помогает находить двоичные данные, замаскированные под строки, без предварительного знания места. Для проверки авторы скопировали NTUSER.DAT пользователя с заражённой Mozipowp машины. Тот же сценарий ищет во всём реестре строки base64, PE-файлы, IPv4-адреса и HTTP URL.

Сценарий нашёл те же значения в HKEY_CURRENT_USER\Identities. На рисунке 10-11 Regedit показывал в Last Date строку 26-6-2010, а здесь после неё видны лишние данные - другая строка Unicode mProc\lsass.exe. Откуда она взялась и что означает?

Значение Popup time содержит строку Unicode 0, то есть байты 30 00 00 00, слитно показанные как 30000000. Всё после первых четырёх байтов лишнее. Среди данных видно 7d 07 00 00, то есть 0x7D7, или 2007 в десятичной форме: возможно, год из структуры даты. Перед ним находятся 35 04 91 7c (0x7c910435) и 3e 04 91 7c (0x7c91043e). В XP ntdll.dll обычно отображается в этом диапазоне; на проверочной машине она занимала 0x7c900000 - 0x7c9b2000. Оба адреса из реестра входят в этот диапазон.

Автор вредоносной программы объявил несколько стековых буферов фиксированного размера для строк, которые затем записывались в реестр. Перед копированием строки буфер не обнулялся, например посредством memset. Строка была намного короче буфера, но RegSetValueEx записывала его целиком. Поэтому всё, что находилось в стеке после строки, попадало в конец буфера и становилось лишними данными реестра.

На рисунке 10-12 показана дизассемблированная в IDA Pro ntdll.dll. Значения 0x7c910435 и 0x7c91043e действительно являются адресами возврата, оставшимися в стеке после предыдущего вызова RtlAcquirePebLock. Такие функции Windows API, как GetEnvironmentVariable, вызывают RtlAcquirePebLock. Это особенно интересно: посмертный криминалистический анализ куста реестра обычно не должен показывать функции API, вызванные вредоносной программой перед созданием значения.

Рисунок 10-12. Дизассемблирование RtlAcquirePebLock показывает адреса, найденные в реестре

На рисунке 10-13 показана декомпиляция функции Mozipowp, создающей значения реестра, посредством Hex-Rays для IDA Pro. Авторы назвали её SetRegistryValues. Программа объявляет стековый буфер __int16 szLastDate[50]. Тип __int16 соответствует WCHAR, символу Unicode размером 16 бит, или 2 байта. Буфер занимает 100 байт стека. wsprintfW формирует строку даты вроде 26-6-2010 и копирует её в szLastDate. Десятисимвольная строка с завершающим NULL требует 20 байт, оставшиеся 80 не изменяются. При вызове RegSetValueEx программа указывает длину 50 байт. Следовательно, в реестр утекает 50 - 20 = 30 лишних байт.

Рисунок 10-13. Декомпиляция Hex-Rays функции создания значений реестра

Чтобы понять значение строки mProc\lsass.exe, авторы исследовали в IDA Pro функцию, вызывающую SetRegistryValues. Её локальные переменные оставались в стеке, если SetRegistryValues не обнуляла собственные буферы. На рисунке 10-14 вызывающая функция посредством GetEnvironmentVariable получает путь к данным приложений, например C:\Documents and Settings\Username\Application Data. Это объясняет адреса возврата из RtlAcquirePebLock. Затем она добавляет к пути \SystemProc\lsass.exe, объясняя строку mProc\lsass.exe.

Рисунок 10-14. Адреса возврата и строки lsass являются артефактами кода этой функции

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

• Reghide^[32] Марка Руссиновича - проверочный инструмент, использующий различия кодировок символов между Windows API и собственным API. Он создаёт ключ реестра с NULL в имени, который приложения пользовательского режима вроде Regedit не могут открыть.

• Халвар Флейк (Halvar Flake) представил доклад Attacks on Uninitialized Local Variables^[33] на Black Hat Federal 2006, объясняющий управление значениями стека программы, если та не инициализирует переменные или не обнуляет буферы.

• regview.pl из Parse::Win32Registry позволяет просматривать куст Windows в Linux. Поскольку он показывает шестнадцатеричный дамп независимо от типа данных, видны лишние байты, скрытые Regedit.

• Другой вид «свободного пространства» реестра описан в диссертации Йоланты Томассен (Jolanta Thomassen) Forensic Analysis of Unallocated Space in Windows Registry Hive Files.^[34]

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

При запуске нового процесса отладчик открывает его и приостанавливает на точке входа, первой инструкции. Точка вычисляется сложением значений ImageBase и AddressOfEntryPoint заголовка PE.

Чтобы передать процессу аргументы, откройте отладчик и выберите File > Open. Найдите исполняемый файл и введите аргументы в поле Arguments, как показано на рисунке 11-1.

Рисунок 11-1. Передача аргументов отлаживаемому процессу

Откройте отладчик и выберите File > Attach. Появится список процессов, показанный на рисунке 11-2. При присоединении отладчик приостанавливает процесс, давая время исследовать его ресурсы и определить точки останова до возобновления.

Рисунок 11-2. Выбор существующего процесса для отладки

После открытия процесса множество кнопок, цветов и чисел поначалу может ошеломить. Этот рецепт знакомит с основными частями интерфейса. Стандартное представление на рисунке 11-4 содержит четыре главных панели.

Рисунок 11-4. Главный графический интерфейс отладчика

Панель CPU показывает дизассемблированные инструкции выбранного модуля. Здесь модулем может быть исполняемый файл процесса, DLL или любой доступный диапазон памяти. Несколько строк с рисунка 11-4:

Слева указан адрес инструкции в памяти процесса. Вверху панели расположены меньшие адреса, внизу - большие. Далее в зависимости от инструкции виден символ вроде ^, показывающий направление перехода, или >, отмечающий назначение перехода. Условный короткий переход по адресу 010073E6 при выполнении ведёт к меньшему адресу 010073DA, поэтому показан ^.

Следующий столбец содержит одно или несколько шестнадцатеричных чисел, иногда разделённых пробелами: коды операций и операнды. Например, 83B9 обозначает сравнение CMP с операндами 84000000 и 0E. Условный переход имеет однобайтовый код 76 и один операнд F2. Инструкция по адресу 010073EB имеет двухбайтовый код 33C0 без операндов.

При работе с панелью CPU полезно помнить:

• Цветовое кодирование. Immunity Debugger показывает красным инструкции JMP и CALL, изменяющие поток управления, синим константы и жёстко заданные числа, белым регистры, жёлтым строки со ссылкой на адрес памяти.

• Навигация. Регистр EIP содержит следующую выполняемую инструкцию. Если вы потерялись, далеко прокрутив панель, дважды щёлкните адрес EIP либо нажмите Ctrl+G и введите EIP.

• Исправление кода. Пробел при курсоре на инструкции позволяет ввести собственные ассемблерные инструкции и применить исправление к программе.

Регистр - основная единица хранения CPU. Каждый поток процесса имеет собственное представление регистров, называемое контекстом. Когда CPU приостанавливает один поток ради другого, он сохраняет контекст предыдущего, а при возвращении восстанавливает значения. В таблице 11-1 показаны регистры общего назначения x86. У каждого 32-разрядного регистра есть 16-разрядная часть; некоторые делятся и на 8-разрядные.

Таблица 11-1. Регистры общего назначения x86

Некоторые регистры общего назначения имеют специальные применения, зависящие от компилятора:

• EAX: расширенный аккумулятор часто хранит результат умножения или деления и возвращаемое значение функции;

• ECX: счётчик часто хранит число итераций цикла;

• ESI и EDI: индексы источника и назначения часто применяются при быстрой передаче данных; перед memmove или memcpy указатель на исходный буфер может находиться в ESI, на выходной - в EDI;

• ESP: указатель стека выполняемой программы;

• EBP: указатель кадра, часто используемый функциями для поиска локальных переменных по смещению относительно EBP.

Помимо регистров общего назначения панель показывает:

• EIP: указатель инструкции с адресом следующей выполняемой инструкции;

• EFLAGS, сокращённо EFL: 32-разрядный регистр, отдельные биты которого управляют операциями CPU либо отражают результат предыдущей операции.

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

• регистр EIP выделяется после каждой инструкции, даже ничего не делающей, например NOP (no-operation), поскольку CPU должен обновить EIP, указав следующую инструкцию;

• большинство, хотя и не все, инструкции изменяют хотя бы один регистр общего назначения; исключения - NOP, MOV EDI, EDI и подобные инструкции, фактически не меняющие значение;

• если выполнить целую функцию за один раз (о переходе через функцию см. рецепт 11-5), отладчик выделит все изменившиеся регистры.

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

Перед вызовом функции программа копирует её аргументы в стек инструкциями PUSH. Следующая демонстрационная программа используется в дальнейшем объяснении. Исходный код и скомпилированная копия находятся на DVD книги.

Как показано на рисунке 11-5, программа stack.exe передаёт аргументы целевой функции, помещая их в стек в обратном порядке: первый аргумент функции помещается последним. На панели CPU видны две инструкции PUSH. Первое значение - указатель на ASCII-строку printme. В отладчике он отображается как stack.00415748, потому что строка находится внутри модуля stack.exe по адресу 00415748. Второе значение - 0x0A, то есть десятичное 10.

Рисунок 11-5. Аргументы функции переносятся в стек после выполнения инструкций PUSH

Если выполнить в отладчике обе инструкции PUSH и остановиться, когда EIP указывает на CALL, как на рисунке 11-5, картина будет очень похожей. В этот момент ESP, регистр указателя стека, содержит 0012FE94. Поэтому на вершине стека находится 0x0A - первый аргумент целевой функции. По адресу ESP+4 расположен указатель на printme - второй аргумент. Если бы функция принимала третий аргумент, он находился бы по адресу ESP+8.

Панель дампа позволяет исследовать содержимое любого допустимого участка памяти отлаживаемого процесса. Если регистр, позиция стека или инструкция на панели CPU содержит допустимый адрес памяти, к этому месту можно перейти, щёлкнув адрес правой кнопкой и выбрав Follow in Dump. На рисунке 11-6 показана синхронизация адреса из регистра EAX с панелью дампа.

Рисунок 11-6. Переход к адресу из регистра EAX с помощью Follow in Dump

В зависимости от выбранного адреса памяти и панели могут быть доступны дополнительные варианты. Щёлкнув инструкцию на панели CPU правой кнопкой и выбрав Follow in Dump > Selection, вы перейдёте на адрес текущей инструкции в панели дампа. Команды Follow in Dump > Memory address и Follow in Dump > Immediate Constant ведут на адрес одного из операндов инструкции.

Формат отображения данных в панели дампа можно менять. После щелчка правой кнопкой доступны, в частности, варианты hex, text, short, long, float, disassemble и special. Шестнадцатеричный формат на рисунке 11-7 показывает каждый байт вместе с его печатным ASCII-представлением.

Рисунок 11-7. Панель дампа в ASCII-представлении

При шестнадцатеричном или ASCII-представлении отладчик иногда подчёркивает некоторые значения. Например, на рисунке 11-8 подчёркнуты первые шесть 32-разрядных значений. Это означает, что значения содержат адрес известной функции, символа или строки. Чтобы исследовать их, щёлкните правой кнопкой и выберите Long > Address, как на рисунке 11-9.

Рисунок 11-8. Подчёркнутые значения шестнадцатеричного дампа обозначают адреса с известным содержимым

Рисунок 11-9. Панель дампа после выбора формата Long > Address

Нажав Ctrl+G (Go) на панели CPU, дампа или стека, можно показать данные по выбранному адресу. В таблице 11-2 описаны способы перехода. Хотя в примерах используется EAX, в выражениях допустим любой регистр, содержащий корректный адрес.

Таблица 11-2. Выражения для допустимых адресов

В правом верхнем углу окна отладчика находится ряд кнопок с одной буквой. Каждая открывает окно с данными для исследования ресурсов процесса. Краткое описание приведено в таблице 11-3.

Таблица 11-3. Кнопки открытия окон отладчика

Окно Executable modules показывает файлы, загруженные отлаживаемой программой в память. Это окно, пример которого дан на рисунке 11-10, можно использовать:

• чтобы проверить, какие DLL загрузил процесс, и узнать их полные пути на диске;

• чтобы точно определить расположение DLL в памяти процесса;

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

Рисунок 11-10. Окно исполняемых модулей

Окно Names показывает функции, которые программа импортирует или экспортирует. С его помощью можно точно определить, где функции находятся в памяти процесса. Чтобы открыть список имён, щёлкните правой кнопкой панель CPU и выберите Search for > Name либо нажмите Ctrl+N. Искать имена можно в модуле, который сейчас показан на панели CPU, или во всех модулях, загруженных в адресное пространство процесса, то есть во всех DLL. На рисунке 11-11 показан поиск определённой экспортированной функции посредством перечисления имён.

Рисунок 11-11. Окно Names

Панель дескрипторов показывает сведения обо всех открытых в данный момент дескрипторах: значение, тип, предоставленный доступ и имя объекта. Многие функции Windows API, например ReadFile и RegSetValue, принимают значение дескриптора, а не имя объекта. Поэтому, увидев число вроде 64, передаваемое в RegSetValue, можно найти его на панели дескрипторов и установить, что 64 соответствует, например, REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows. Подробнее об использовании дескрипторов при анализе см. рецепт 9-5.

Рисунок 11-12. Окно дескрипторов

Панель Memory map показывает сведения о выделенных сегментах памяти процесса. Каждый раз, когда программа загружает новый модуль через API LoadLibrary или выделяет дополнительную память с помощью VirtualAlloc, на панели появляются новые сегменты. В этом окне можно исследовать разрешения и типы данных в определённых областях процесса, как показано на рисунке 11-13.

Рисунок 11-13. Окно карты памяти

Как уже говорилось, загрузка нового PE-файла в память, будь то DLL или собственный исполняемый образ процесса, может создать несколько новых сегментов: один для заголовка PE и по одному для каждого раздела PE. На рисунке 11-13 показаны восемь сегментов памяти, принадлежащих программе stack.exe. Первый, по адресу 00400000, содержит заголовок PE. Следующие семь содержат разделы PE программы. Чтобы сравнить значения в памяти со значениями на диске, обратитесь к рисунку 11-14: на нём показаны имена, размеры и RVA (relative virtual addresses, относительные виртуальные адреса) разделов в заголовке PE stack.exe. Фактические размеры в карте памяти округлены вверх до ближайшего кратного 0x1000, минимального размера страницы.

Рисунок 11-14. Разделы согласно заголовкам разделов на диске

Двойной щелчок по любому сегменту памяти открывает окно, похожее на панель дампа, где содержимое сегмента отображается в выбранном формате. Можно также щёлкнуть карту памяти правой кнопкой, выбрать Search, а затем ввести ASCII-строку, Unicode-строку или последовательность шестнадцатеричных байтов для поиска во всей памяти процесса. На рисунке 11-15 показан чувствительный к регистру поиск префиксов URL.

Рисунок 11-15. Поиск ASCII-строки

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

Команда воспроизведения F9 выполняет все инструкции, пока не возникнет исключение, не сработает точка останова, не завершится программа или вы не приостановите её, вернув себе управление. Если перед нажатием F9 не установить точку останова, процесс может заразить систему и завершиться прежде, чем вы успеете вмешаться. Поэтому используйте F9 осторожно.

Команда одиночного шага F7 каждый раз выполняет одну инструкцию. Одиночный шаг с обходом F8 действует сходным образом. Если текущая инструкция - CALL, F8 выполняет все инструкции вызываемой функции. Для любой другой инструкции F8 ведёт себя точно так же, как F7.

Команда выполнения до возврата Ctrl+F9 исполняет все инструкции текущей функции до её возврата. Она полезна, если вы вошли в функцию, которая оказалась неинтересной. Достигнув конца функции, то есть инструкции RET или RETN, нажмите F7 либо F8, чтобы вернуться в вызывающую функцию.

Команда выполнения до пользовательского кода Alt+F9 похожа на выполнение до возврата, но позволяет выйти из глубоко вложенных подфункций. Она останавливается на диапазонах адресов, а не на инструкции возврата конкретной функции. Рассмотрим рисунок 11-16. Представьте, что вы отлаживаете программу, вызывающую ReadFile. Вы входите в вызов и оказываетесь внутри kernel32.dll, затем входите ещё в один вызов и оказываетесь внутри ntdll.dll. Теперь вы углубились на два модуля. Чтобы немедленно вернуться туда, где программа первоначально вызвала ReadFile, нажмите Alt+F9.

Рисунок 11-16. Возврат к пользовательскому коду с помощью Alt+F9

Установка новой точки начала позволяет принудительно выполнять функции или блоки кода, которые обычно не исполняются. Допустим, требуется отладить функцию, выполняемую только после получения вредоносной программой определённой команды. Если сервер управления недоступен, например из-за отладки в изолированной от Интернета лаборатории, программа не получит команду и нужная функция без вашего вмешательства не выполнится. В таких случаях её можно запустить, вручную переустановив EIP.

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

Точки останова - основополагающая часть любого отладчика. В этой главе они уже упоминались много раз, а теперь будут рассмотрены подробнее. С их помощью можно приостановить выполнение программы, когда она достигает определённой инструкции, вызывает функцию API либо читает, записывает или выполняет данные по заданному адресу или в диапазоне памяти. Чтобы установить разные виды точек останова, щёлкните инструкцию на панели CPU правой кнопкой и выберите меню Breakpoint, как показано на рисунке 11-17.

Рисунок 11-17. Доступ к меню Breakpoint

Программная точка останова заменяет байт по своему адресу значением 0xCC (INT 3). Её можно установить командой Breakpoint > Toggle, показанной на рисунке 11-17, или клавишей F2. На панели CPU инструкция не изменится на INT 3, поскольку отладчик маскирует замену. Когда отлаживаемая программа встречает INT 3, срабатывает обработчик исключений отладчика и передаёт вам управление. Перед продолжением программы отладчик заменяет 0xCC исходным байтом.

Главное преимущество программных точек останова - их можно установить в неограниченном количестве. Есть и недостатки:

• вредоносная программа может легко найти 0xCC в памяти процесса и соответствующим образом изменить поведение;

• программная точка останова, установленная не там, где нужно, до или во время распаковки способна неожиданно аварийно завершить программу. Представьте код, который читает каждый байт собственной памяти и прибавляет к нему 1, получая распакованный байт. Вместо исходного значения плюс 1 программная точка останова превратится в 0xCD (0xCC + 1). Это уничтожит и точку останова, и исходное значение.

Аппаратная точка останова использует отладочные регистры CPU DR0-DR7. Её можно настроить на приостановку программы при чтении, записи или выполнении по адресу памяти. В отличие от программных точек аппаратные не изменяют память процесса, поэтому надёжнее работают с упакованным кодом. Однако одновременно можно установить только четыре аппаратные точки. Кроме того, вредоносная программа способна обнаружить их, вызвав GetThreadContext с флагами CONTEXT_DEBUG_REGISTERS или CONTEXT_FULL.

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

Точку останова по памяти можно установить несколькими способами:

• для инструкции щёлкните нужный адрес на панели CPU правой кнопкой и выберите Breakpoint > Memory, On Access либо Breakpoint > Memory, On Write;

• для данных на панели дампа выделите группу байтов и щёлкните её правой кнопкой, как описано выше;

• для целого участка памяти откройте карту памяти Alt+M, щёлкните правой кнопкой и выберите Set Break-On-Access, Set Memory Breakpoint On Access или Set Memory Breakpoint On Write. Вид этого меню показан на рисунке 11-18.

Рисунок 11-18. Контекстное меню карты памяти

Точки останова по памяти работают, включая защиту PAGE_GUARD для страницы памяти. Когда отлаживаемый процесс пытается обратиться к защищённой странице, система возбуждает исключение STATUS_GUARD_PAGE_VIOLATION^[3]. Отладчик перехватывает его и приостанавливает программу для анализа.

Многие отладчики позволяют указывать имя функции вместо адреса. Например, точку останова можно поставить на функцию Windows API wsprintfW внутри user32.dll. Отладчик преобразует имя в адрес подобно функции Windows API GetProcAddress. Для этого DLL с нужной функцией уже должна быть загружена в процесс, иначе поиск завершится неудачей.

Чтобы ставить точки на ещё не загруженные функции, настройте остановку отладчика при загрузке новых модулей: выберите Options > Debugging Options > Events, отметьте Break on new module (DLL) и продолжите выполнение клавишей F9. Когда процесс загрузит новую DLL, отладчик приостановится. Тогда можно установить точку на нужной функции и лишь затем возобновить программу. В блоге cyberwart опубликован сценарий Python, автоматизирующий этот приём.^[4]

В командном поле Immunity Debugger можно вводить команды, например bp для программной точки останова или he для аппаратной. На рисунке 11-19 авторы устанавливают программную точку останова на CreateFileW. После продолжения выполнения и срабатывания точки параметры, передаваемые CreateFileW, видны на панели стека.

Рисунок 11-19. Установка точек останова через командное поле

Если требуется исследовать работу вредоносной программы с конфигурационным файлом, установите точку останова на CreateFileW и следите за стеком, пока параметр FileName не укажет на этот файл. Затем поставьте точки на ReadFile и/или WriteFile, чтобы исследовать операции ввода-вывода. В случае ReadFile в стеке будет указатель на входной буфер. Перейдите по этому адресу на панели дампа, обойдите вызов ReadFile клавишей F8 - и на панели появится содержимое конфигурационного файла. Чтобы остановиться на следующей инструкции, обращающейся к содержимому файла, установите в начале этих данных аппаратную точку останова по доступу или точку останова памяти по доступу, затем нажмите F9. Эти несколько шагов позволяют точно найти место, где вредоносная программа разбирает конфигурационный файл.

Как отмечалось в предыдущем рецепте, после установки точки останова на API переданные ему параметры можно исследовать в стеке. Однако некоторые API сотни раз вызываются другими модулями процесса, пока вы ждёте вызова из вредоносной программы. После каждого ложного срабатывания пришлось бы снова нажимать F9, что крайне утомительно. Условные точки останова помогают уменьшить этот шум.

Допустим, вы хотите поставить точку на CreateFileW, но приостанавливать отладчик лишь тогда, когда процесс пытается открыть файл с правом записи. Второй параметр CreateFileW, dwDesiredAccess, задаёт желаемый доступ, например GENERIC_READ, GENERIC_WRITE или GENERIC_ALL. Значения можно объединять логическим ИЛИ. GENERIC_READ равен 0x80000000, а GENERIC_WRITE - 0x40000000. Если вредоносная программа вызывает CreateFileW с правами чтения и записи, dwDesiredAccess будет равен 0xC0000000 (0x80000000 | 0x40000000 = 0xC0000000). Значит, в условной точке останова нужно проверить, установлен ли во втором параметре бит 0x40000000.

Сначала перейдите к адресу CreateFileW. Затем щёлкните первую инструкцию функции правой кнопкой и выберите Breakpoint > Conditional log (Shift+F4). В окне на рисунке 11-20 условие можно задать операторами логического И &, ИЛИ | и равенства =.

Рисунок 11-20. Параметры условной точки останова с журналированием

Чтобы правильно заполнить поля, необходимо понимать устройство стека при входе в функцию. Краткое напоминание дано в таблице 11-4.

Таблица 11-4. Устройство стека при входе в функцию

Как видно на рисунке 11-20, условие проверяет [ESP+8], то есть параметр dwDesiredAccess. Переключатели задают действие при срабатывании точки останова. Возможны три варианта:

• Pause program: приостановить выполнение, как при обычной точке останова;

• Log value of expression: записать в журнал значение и его пользовательский тип. На рисунке 11-20 выражение [ESP+4] обозначает первый параметр CreateFileW. В раскрывающемся списке отладчику предписано интерпретировать [ESP+4] как указатель на Unicode-строку. При срабатывании в журнале появится:

• Log function arguments: вывести в журнал все параметры функции, если отладчик распознаёт API. Это заранее настроенный вариант предыдущего действия.

Здесь вы научитесь командами Python устанавливать точки останова, изменять значения регистров, читать память процесса и искать в ней строки. Код Python в Immunity Debugger можно выполнять множеством способов, но мы рассмотрим только два: оболочку Python и PyCommands.

Оболочка Python - интерактивная командная среда, которую можно открыть при отладке любого процесса, щёлкнув значок на рисунке 11-21.

Рисунок 11-21. Открытие оболочки Python

Появится следующее приглашение:

В приглашении можно сочетать обычный код Python с функциями API Immunity Debugger. Например, чтобы начать отладку нового процесса и выполнять его до первого вызова CreateFileW, введите:

Чтобы выполнить код до завершения CreateFileW, а затем вывести возвращаемое значение:

Чтобы выгрузить 0x8000 байт памяти начиная с адреса 0x1001000 в файл на диске:

Чтобы перечислить загруженные модули и их базовые адреса:

Чтобы найти и вывести все вхождения подстроки Unicode:

Чтобы найти в заданном модуле все вхождения ассемблерной инструкции, в примере PUSH 20000013, и дизассемблировать окружающие её инструкции:

Как видно, вскоре после найденной инструкции PUSH следует CALL. Имя вызываемой функции можно получить командами:

PyCommands - многократно используемые сценарии с тем же кодом, который можно вводить в оболочке Python. В каталоге C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands уже есть множество примеров. В таблице 11-5 перечислены некоторые подключаемые модули, полезные при анализе вредоносных программ.

Таблица 11-5. Подключаемые модули PyCommand для Immunity Debugger и их применение

Чтобы выполнить PyCommand, введите в командном поле Immunity Debugger символ !, а затем имя команды. Например, подключаемый модуль nohooks.py запускается командой !nohooks <arguments>. Если модулю нужны аргументы, правильный синтаксис обычно выводится в журнале отладчика. Для установки собственного модуля создайте файл YourCommand.py, поместите его в каталог PyCommands и запускайте командой !YourCommand.

Одна из интересных задач анализа вредоносных программ, решаемых с помощью API Python Immunity, - обнаружение потоков шелл-кода в произвольных двоичных файлах. Представьте подозрительный файл изображения, офисный документ или данные из перехваченного сетевого обмена. Если вы предполагаете наличие шелл-кода, но не знаете, где он начинается и заканчивается, можно воспользоваться находящейся на DVD командой PyCommand scd.py (shellcode detect).

Краткая схема работы scd.py:

1. При запуске scd.py вы передаёте путь к подозрительному файлу.

2. Сценарий вызывает imm.openProcess и запускает экземпляр notepad.exe. Это фиктивный процесс-контейнер для загрузки шелл-кода.

3. Сценарий читает содержимое подозрительного файла, выделяет память в фиктивном процессе функцией imm.remoteVirtualAlloc и переносит туда данные с помощью imm.writeMemory.

4. С помощью imm.disasm он дизассемблирует содержимое файла и ищет инструкции CALL или JMP. В произвольном двоичном файле могут встретиться сотни ложных совпадений, но только шелл-код будет содержать CALL или JMP, ведущую в корректное место с несколькими другими допустимыми инструкциями. На рисунке 11-22 показано дерево решений, которым сценарий ограничивает число ложных срабатываний.

Рисунок 11-22. Дерево решений для обнаружения шелл-кода

По этому алгоритму scd.py выводит в собственное окно отладчика список возможных адресов с шелл-кодом. Ниже приведён исходный код scd.py.

Скопируйте сценарий с DVD книги в каталог PyCommands, затем выполните в командном поле отладчика:

В примере передан путь к вредоносному документу PowerPoint размером 230 Кбайт. Результат на рисунке 11-23 содержит следующие столбцы:

• Ofs: смещение внутри подозрительного файла, по которому может находиться шелл-код;

• Abs: абсолютный адрес возможного шелл-кода в памяти процесса, равный базовому адресу выделенной памяти плюс значение Ofs;

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

• Op2: дизассемблированная первая инструкция по адресу назначения;

• Op3: дизассемблированная вторая инструкция по адресу назначения.

Рисунок 11-23. Столбцы результатов обнаружения шелл-кода

Для интерпретации результатов изучите дизассемблированный код в столбцах Op2 и Op3. Если обе инструкции допустимы и осмысленны в своём контексте, вероятно, вы нашли шелл-код. Контекст здесь чрезвычайно важен: две инструкции вроде INC EDI и DEC EDI допустимы, но их последовательное выполнение лишено смысла. Это эквивалент записи i+=1;i-=1; в исходном коде.

Хотя scd.py устраняет множество ложных срабатываний - в примере 230 Кбайт данных сократились до 30 возможных мест с шелл-кодом, - оставшиеся варианты всё равно придётся разделить на шелл-код и мусорные инструкции. На рисунке 11-23 интересны примерно десять строк от абсолютного адреса 0x170E5F до 0x172012. Все они содержат JMP или CALL, ведущие в контекстно осмысленные места. Щёлкните любую такую строку правой кнопкой и скопируйте абсолютный адрес из столбца Abs. Затем на панели CPU нажмите Ctrl+G и вставьте адрес, чтобы получить более полное дизассемблирование окружающих инструкций. Щёлкнув строку 0x170E5F, содержащую переход JMP на 0x170E91, мы попадаем в область, показанную на рисунке 11-24.

Рисунок 11-24. Исследование ассемблерных инструкций подтверждает наличие корректного шелл-кода

Как видно, это привело непосредственно к шелл-коду. Потребовалось несколько мгновений визуальной проверки, что несравнимо быстрее просмотра 230 Кбайт двоичных данных в поисках небольшого фрагмента. Можно создать отдельный инструмент на основе любого потокового дизассемблера, например DiStorm из рецепта 6-9, однако после обнаружения шелл-кода в двоичном файле его всё равно нужно загрузить в отладчик. При использовании scd.py он уже находится в памяти, и отладку можно начать немедленно. Здесь снова пригодится установка новой точки начала, описанная в рецепте 11-5.

Отладчик полностью управляет отлаживаемым процессом и может исследовать всё его виртуальное адресное пространство. Как показано в рецепте 11-9, у отладчика есть и встроенный дизассемблер, на основе которого можно создавать инструменты. В этом рецепте представлен PyCommand, обнаруживающий вредоносные перехваты API в отлаживаемом процессе. Он позволяет просто пройти путь от обнаружения через отладку к полному пониманию назначения перехвата. Сценарий findhooks.py находится на DVD книги.

Сканеры руткитов, например GMER из рецепта 10-6, могут искать перехваты API во всей системе, включая режим ядра. Однако они не помогают определить назначение перехвата. Допустим, вы обнаружили перехват функции HttpSendRequestW внутри браузера. Это лишь половина истории: ещё требуется понять, зачем вредоносная программа перехватила HttpSendRequestW. Возможны, например, такие объяснения:

• программа отслеживает посещённые URL и поисковые запросы;

• программа крадёт учётные данные для сайтов, на которые входит пользователь.

• программа крадёт учётные данные лишь для нескольких британских банковских сайтов;

• программа одновременно отслеживает посещённые URL и крадёт учётные данные.

Причины, по которым конкретный образец перехватывает API, можно определить статическим анализом двоичного файла в IDA Pro. Другой способ - присоединить отладчик к браузеру, установить точку останова на перехваченных функциях API, вызвать её действиями в браузере и пошагово исследовать код руткита. Сценарий findhooks.py удобен тем, что обнаружить и отладить перехват можно, не покидая графического интерфейса отладчика. Он не предназначен для замены полноценных сканеров руткитов вроде GMER: это лишь экспериментальный сценарий, помогающий при отладке.

findhooks.py действует следующим образом:

• перечисляет все символы отлаживаемого процесса функцией imm.getAllSymbols. Она возвращает словарь, ключами которого служат имена модулей, например kernel32.dll, а значениями - другие словари. Во вложенном словаре ключами являются адреса символов, а значениями - их имена, например CreateFileW;

• для каждого символа каждого модуля выполняет поиск имени через imm.getAddress и проверяет, найден ли он в памяти процесса. В результате получаются адреса экспортируемых символов, то есть функций API;

• дизассемблирует первую инструкцию каждой функции API через imm.disasm, проверяет методами op.isCall и op.isJmp, является ли она CALL или JMP, и в таком случае получает адрес назначения через op.getJmpAddr;

• проверяет, находится ли адрес назначения CALL или JMP внутри содержащего функцию модуля. Если нет, функция API перехвачена.

Ниже приведён код findhooks.py.

Скопируйте подключаемый модуль findhook.py с DVD книги в каталог PyCommands, затем без аргументов введите !findhooks в командном поле отладчика. На рисунке 11-25 показан пример вывода сценария.

В примере отладчик присоединён к процессу Internet Explorer, заражённому образцом трояна Silent Banker. Поля окна результатов:

• Function: имя перехваченной функции API и содержащего её модуля;

• Address: адрес перехваченной функции API в памяти;

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

Рисунок 11-25. Поиск перехватов API Silent Banker

В процессе IE есть несколько перехватов, но не все они вредоносны. Обычно отличить вредоносный перехват от нормального можно по имени функции и адресу назначения. Например, ws2_32.WSAGetLastError перехвачена, но ведёт к kernel32.GetLastError: это всего лишь перенаправление экспорта. В то же время advapi32.CryptGenKey ведёт по адресу 01C10000. Многие перехваченные функции указывают в диапазон 01000000-02000000, причём у выполняемого там кода нет имени связанного модуля. Именно там, несомненно, и находится Silent Banker.

Зная, какие API перехвачены, можно установить на них точки останова и начать посещать сайты, передавать файлы по FTP и выполнять другие действия в отлаживаемом процессе. Разумеется, не используйте настоящие учётные данные. Ещё лучше проводить испытания в лаборатории с InetSim из рецепта 7-3, где утечка данных невозможна.

На рисунке 11-26 показано дизассемблирование кода перехвата ws2_32.send. Чтобы попасть сюда, мы установили точку останова на send и открыли веб-страницу в IE. Перехват ищет в исходящих пакетах строки USER, PASS и другие данные, передаваемые открытым текстом протоколами HTTP и FTP. Если вредоносная программа читает файл с диска, чтобы определить целевые учреждения, скорее всего, это также будет происходить внутри функции перехвата.

Рисунок 11-26. Руткит ищет в трафике имена пользователей и пароли

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

В этом рецепте создаётся монитор API на основе WinAppDbg. В сетевой документации WinAppDbg^[5] есть несколько примеров построения приложений, поэтому здесь рассматривается только каркас сценария монитора API и способы его настройки для анализа вредоносных программ. Основная идея - написать сценарий Python, служащий оболочкой класса отладчика. Вредоносная программа выполняется внутри отладчика без графического интерфейса и интерактивного управления. Установка точек останова, журналирование параметров и чтение или запись памяти во время выполнения реализуются в многократно используемом сценарии.

Следующий каркас монитора API перехватывает CreateFileW. В класс MyEventHandler можно добавить имена любых других интересующих функций Windows API. Вместе с именем функции необходимо указать число её аргументов, которое можно узнать в MSDN или заголовочных файлах Windows. Затем добавляются обработчики, выполняемые до или после перехватываемой функции API. Их имена должны следовать установленному шаблону. Обработчик при входе в CreateFileW, полезный для записи параметров, называется pre_CreateFileW, а обработчик при выходе, полезный для записи возвращаемого значения, - post_CreateFileW.

Функция __main__ создаёт объект Debug и передаёт ему экземпляр MyEventHandler. Метод execv запускает процесс, указанный пользователем в командной строке. Флаг bFollow=True заставляет WinAppDbg отслеживать все дочерние процессы. WinAppDbg автоматически устанавливает точки останова на функциях API из класса MyEventHandler. При их срабатывании среда вызывает обработчики pre_ и post_. Это похоже на условные точки останова с журналированием из рецепта 11-7, но гибкость Python даёт гораздо больше контроля над условиями и журналом.

Для испытания сценария вызовите его из командной строки, указав полный путь к запускаемому процессу. Если процесс принимает параметры, разместите их после пути. В примере запускается notepad.exe с именем редактируемого файла. Каркас выводит данные в STDOUT, поэтому вызовы CreateFileW видны сразу.

Разобрав основы создания монитора API, расширим пример. На DVD книги находится сценарий WinAppDbg pymon.py. В него включены следующие полезные возможности:

• наблюдение примерно за 200 функциями Windows API из более чем десяти DLL; по сравнению с другими мониторами API это немного, поскольку выбраны только наиболее информативные функции;

• создание отчётов HTML и автоматическое выделение подозрительных вызовов API;

• копирование в выходной каталог файлов, которые вредоносная программа пытается удалить через DeleteFile или MoveFileEx;

• отслеживание новых дочерних процессов на основе возможности WinAppDbg bFollow=True;

• попытка отслеживать использование дескрипторов, чтобы выводить осмысленные имена объектов вместо чисел вроде 0x44, например имя файла;

• предварительный просмотр в стиле шестнадцатеричного дампа двоичных данных, переданных функциям API. Например, отчёт показывает первые 128 байт записываемых в файл данных, причём объём настраивается. То же относится к чтению из файла, чтению и записи реестра, передаче по сети, а также расшифрованию и шифрованию криптографическими функциями.

По мнению авторов, лучшая возможность pymon - автоматическое выделение подозрительной активности. Заранее подготовленные критерии подозрительности и немедленное сосредоточение на соответствующем поведении в отчёте HTML значительно экономят время. Далее приведено несколько примеров. Список alert_file_content_write создаёт предупреждение при каждом вызове WriteFile, если записываемый буфер содержит одну из перечисленных строк. Так выявляются попытки сохранить исполняемые файлы, пакетные сценарии и сценарии автозапуска.

Список alert_file_write проверяется, когда вредоносная программа вызывает CreateFile с параметром dwDesiredAccess, разрешающим запись. Если lpFileName совпадает с элементом списка, pymon создаёт предупреждение. В список можно включать полные и частичные пути, расширения, файлы, именованные каналы, диски и другие объекты. Например, если USB-накопитель смонтирован как F:, а сетевой ресурс как E:, предупреждение о записи на любой из этих дисков укажет на способность программы распространяться.

Список alert_file_read проверяется при попытке открыть файл с правом чтения. Обычно предупреждения настраивают для файлов и каталогов с конфиденциальными сведениями, например паролями или cookie, которые читают банковские трояны, а также для признаков противодействия отладке.

Список alert_reg_write проверяется при вызовах вроде RegSetValue. Если изменяемый ключ совпадает с элементом списка, pymon создаёт предупреждение. Здесь указывают места автоматического запуска, ключи внедрения DLL, изменения брандмауэра, службы и прочее.

alert_reg_content_write похож на alert_file_content_write, но относится к данным, записываемым в любое значение любого ключа реестра. Распространённые строки вроде http могут вызвать ложные предупреждения, поэтому используйте их осторожно. Авторы начинают со списка расширений исполняемых файлов. Законных причин записывать в реестр данные со строкой .exe почти нет, поэтому такие случаи всегда помечаются. Благодаря множеству мест автозапуска указание расширений в alert_reg_content_write с большой вероятностью выявит попытки автоматического запуска без предварительного знания используемого ключа.

Список alert_loaded_dll проверяется при вызове функции вроде LoadLibrary. В отличие от kernel32.dll, содержащей функции разного назначения, такие библиотеки, как pstorec.dll, применяются только для чтения или записи защищённого хранилища. Если вредоносная программа загружает pstorec.dll, она, скорее всего, пытается украсть учётные данные. Аналогично, sfc_os.dll включает или отключает защиту файлов Windows. Если процесс пользовательского режима загружает ntoskrnl.exe, исполнительный модуль ядра, вероятнее всего, он собирает сведения для установки руткита уровня ядра.

Кроме того, pymon настроен предупреждать о следующих признаках вредоносной активности:

• попытках изменить временные метки файлов на даты в прошлом;

• попытках вызвать CreateFile для собственного файла, что обычно означает извлечение других двоичных файлов или конфигурационных данных из самого образца;

• попытках запустить или остановить службы Windows;

• попытках читать или записывать память любого другого процесса.

На рисунке 11-27 показан пример отчёта pymon. Настоящий HTML-отчёт содержит больше подробностей, но для размещения на странице его пришлось сократить. В нём видны имя функции API и основной объект, над которым вредоносная программа выполняет операцию. Если API принимает двоичные данные, как WriteFile и RegSetValueExA, выводится их предварительный шестнадцатеричный дамп. Строки с сработавшими предупреждениями pymon выделяет жёлтым. Успешные вызовы API показаны светло-серым, неудачные - тёмно-серым.

Рисунок 11-27. Pymon автоматически выделяет подозрительное поведение

По результатам на рисунке 11-27 видно, что вредоносная программа сохраняет WinCtrl32.dll в каталог system32. Она регистрирует DLL как пакет уведомлений Winlogon, чтобы winlogon.exe загружал библиотеку при запуске. Затем программа пытается открыть Wincl175.sys, но безуспешно: код возврата ffffffff равен INVALID_HANDLE_VALUE. Далее она через CreateProcessA запускает cmd.exe. Вызов успешен, поскольку отчёт показывает идентификаторы нового процесса и потока. Процессу cmd.exe поручено удалить один из временных файлов программы.

Таким образом, pymon чрезвычайно полезен для выявления поведения вредоносных программ. Это лишь один пример приложения, построенного расширением WinAppDbg. Недостаток pymon в том, что вредоносная программа действительно работает под отладчиком, поэтому приёмы противодействия отладке могут помешать анализу. Если при запуске процесса методом execv передать флаг bHostile=True, WinAppDbg внесёт несколько изменений для защиты от простейших способов обнаружения отладчика, однако полной защитой это не является.

XOR - пример симметричной операции: один и тот же ключ используется и для кодирования, и для декодирования данных. Следовательно, для обращения XOR нужно знать начальное значение, применённое злоумышленником при кодировании. В этом рецепте рассматривается декодирование различных вариантов XOR с помощью находящегося на DVD книги модуля Python xortools.py.

В таблице 12-1 показано действие XOR. Для каждой пары соответствующих битов двух операндов результат равен 0, если биты одинаковы, и 1, если различаются. В языках высокого уровня вроде C и Python операцию XOR обозначает символ ^.

Таблица 12-1. Основные вычисления XOR

Особое свойство XOR состоит в том, что повторное применение с тем же операндом обращает операцию. Если вычислить XOR значений X и Y, а затем применить XOR результата с Y, получится исходное X. Это показано в таблице 12-2.

Таблица 12-2. Обращение XOR

Если у вас есть образец вредоносной программы, выполняющий XOR, его можно дизассемблировать в IDA Pro и найти инструкции XOR. Выберите Search > Text и введите XOR. Не удивляйтесь сотням инструкций вида XOR reg, reg, где reg - любой регистр общего назначения: XOR значения с самим собой даёт ноль. Поэтому многие компиляторы представляют выражения исходного кода вроде int i=0 инструкцией XOR reg, reg. Такие случаи можно пропустить. Ищите инструкции XOR с жёстко заданными значениями или ссылками на адреса памяти, где хранится ключ XOR.

На рисунке 12-1 показана функция, применяющая XOR по одному байту с ключом 0xBC.

Рисунок 12-1. Функция однобайтового XOR

Судя по дизассемблированному коду, исходная программа автора выглядела примерно так:

Если строка, целый файл или байты перехваченного сетевого обмена закодированы однобайтовым XOR, декодируйте их следующим образом.

1. Скопируйте с DVD книги файл xortools.py. В нём находится функция:

2. В оболочке Python выполните следующие команды, предполагая, что in_buf содержит закодированные данные:

3. Чтобы применить XOR с 0xBC ко всем байтам файла input.txt и записать результат в output.txt, выполните:

Злоумышленники часто используют XOR с четырёхбайтовым ключом, поскольку он лучше защищает данные от декодирования аналитиком. Вместо 255 (0xFF) возможных однобайтовых ключей здесь существует 4 294 967 295 (0xFFFFFFFF) вариантов. Однако при наличии вредоносной программы, кодирующей данные, и нескольких минут работы в IDA Pro это не имеет значения. Найдя инструкцию вроде XOR EAX,0x49171661, вы сразу получите ключ.

Следующая функция из xortools.py показывает применение XOR с четырёхбайтовым ключом:

Используйте код так же, как для однобайтового XOR, но вызывайте four_byte_xor:

Ещё один распространённый вариант - циклический XOR. Злоумышленник задаёт последовательность байтов ключа. Байт по смещению 0 ключа применяется к байту по смещению 0 кодируемых данных, байт по смещению 1 - к байту по смещению 1 и так далее до конца ключа. Затем алгоритм возвращается к его началу и применяет байт по смещению 0 к следующему байту данных. На рисунке 12-2 показан алгоритм трояна Limbo, который обфусцирует украденные данные перед отправкой по сети.

Рисунок 12-2. Циклический ключ XOR трояна Limbo

Следующая функция из xortools.py реализует циклический XOR:

Чтобы декодировать украденные Limbo данные ключом с рисунка 12-2:

Если исходный ключ XOR неизвестен, его можно попытаться угадать полным перебором. Метод применяет к закодированным данным все возможные значения XOR, от 0 до 0xFF для однобайтовых ключей, пока не будет выполнено заданное условие. Здесь условиями служат строки или шаблоны байтов, которые вы ожидаете увидеть после правильного декодирования. Нужно хотя бы представлять, что искать в декодированном файле, иначе алгоритм не поймёт, когда остановиться.

Следующая функция из xortools.py реализует полный перебор однобайтовых ключей XOR. Ей передаются закодированный буфер, список строк-признаков успеха и необязательные начальное и конечное смещения, в пределах которых должна находиться строка.

Чтобы перебирать ключи для данных в in_buf, пока декодированный буфер не будет содержать http, www или MZ - заголовок DOS, обозначающий начало исполняемого файла, - используйте:

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

Авторы вредоносных программ любят base64, поскольку он упрощает передачу двоичных данных по текстовым протоколам. Часто встречаются HTTP-запросы к URL вроде /page.php?v=dGVzdGluZw==: так программа пытается вывести двоичные данные, закодированные base64. В этом рецепте показано, как распознавать и декодировать данные base64.

Алгоритм base64 преобразует каждые три байта двоичных данных в четыре символа из следующего 64-символьного набора, называемого алфавитом base64:

Данные base64 легко заметить визуально, поскольку строка состоит только из этих 64 символов. Есть одно исключение: 65-й символ = используется для заполнения. Если длина кодируемых данных не кратна четырём байтам, выход дополняется. Для обнаружения вредоносных программ, использующих base64, подойдёт следующее правило YARA, проверяющее наличие алфавита base64.

Положительное совпадение с такой сигнатурой, вероятно, указывает на использование base64. Откройте файл в IDA Pro и перейдите по одной из перекрёстных ссылок на строку: там вы найдёте алгоритм base64, как на рисунке 12-3. Для самого декодирования изучать алгоритм в IDA не требуется, но вредоносные программы часто сочетают base64 с шифрованием. Найдя функцию base64, вы, скорее всего, окажетесь всего в нескольких шагах от алгоритма шифрования.

Рисунок 12-3. Переход по перекрёстной ссылке на алфавит ведёт к алгоритму base64

Данные base64 можно декодировать модулями Python base64 и binascii. Для демонстрации используется следующий POST-запрос варианта DNS-подменщика Zlob.^[2]

Полезная нагрузка POST похожа на base64. Достаточно вставить её в оболочку Python:

После декодирования остаются IP-адрес заражённого компьютера, IP-адрес его шлюза, область базовой аутентификации маршрутизатора, имя пользователя и пароль маршрутизатора, если Zlob сумел их угадать, и IP-адрес DHCP-сервера. Функция standard_b64decode использовала стандартный 64-символьный алфавит. Однако не все реализации base64 следуют ему. Согласно RFC для base16, base32 и base64^[3], единого общепринятого алфавита нет. Символ / небезопасен в именах файлов и URL, а + и / старые средства текстового поиска и индексирования воспринимают как границы слов. Поэтому приложение может выбрать другой алфавит.

Это создаёт проблему: данные, закодированные вредоносной программой с нестандартным алфавитом, не удастся декодировать стандартным.

urlsafe_b64decode декодирует строку с небольшой вариацией стандартного алфавита: вместо + используется -, а вместо / - _, то есть изменены 63-й и 64-й символы. Эту функцию можно вызвать вместо standard_b64decode, чтобы замена выполнялась автоматически. Другие значения 63-го и 64-го символов передаются функции b64decode следующим образом:

В большинстве случаев этих приёмов достаточно. Однако встречается код с нестандартным символом заполнения, например . вместо =. До декодирования его можно заменить методом Python replace:

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

Порядок здесь полностью обращён. К сожалению, модуль Python base64 не позволяет легко декодировать такой вариант. Он использует алгоритмы встроенного в Python модуля binascii. Пришлось бы загрузить исходный код Python, изменить Modules/binascii.c, заново скомпилировать binascii.so и импортировать изменённый модуль. Это возможно, но неудобно. Практичнее найти реализацию base64 на C, например поиском base64.c или base64.cpp, изменить нужные строки и скомпилировать собственный декодер: