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

 

Stuxnet

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

 

Легальные сертификаты

Ряд компонентов червя Stuxnet (в том числе и драйверы) имели легальные цифровые подписи. Это позволяло беспрепятственно обойти ряд HIPS-систем, а в некоторых случаях – избежать обнаружения антивирусным монитором или сканером. Сертификаты, которые были использованы, принадлежали таким компаниям, как Realtek и JMicron. А самое главное – предоставляли возможность подписи исполняемых модулей без отправки их на верификацию в Microsoft, что позволило беспрепятственно подписать драйверы, использующие руткит-технологии. Как же так? Ведь весь процесс подписания драйверов контролирует сама MS! Все верно, но существует возможность получения от MS цифрового сертификата, позволяющего на своей стороне осуществлять процедуру подписи. Например, для компаний, занимающихся разработкой железа, это довольно приятная опция. Вот и в нашем случае были использованы именно такие сертификаты.

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

 

0-day вектора распространения и атаки

Использование сразу шести уязвимостей в одной вредоносной программе, из которых пять являются уязвимостями нулевого дня – беспрецедентный по количеству и стоимости клинический случай. Интересным представителем этого набора является уязвимость MS10-046, которая позволяла беспрепятственно распространяться через внешние носители, эксплуатируя уязвимость в обработке LNK/PIF-файлах.

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

MS10-061 – уязвимость в сервисе Print Spooler, которая позволяет удаленно выполнить произвольный код. Она была закрыта благодаря своевременной реакции со стороны нескольких антивирусных компаний.

MS08-067 – да, это та самая уязвимость, используемая червем Conficker. Авторы также сочли нужным использовать этот вектор атаки. Кроме того, и здесь злокодеры проявили свои навыки и разработали достаточно интересный шеллкод, имеющий существенные отличия от того, что был использован червем Conficker и имеется в публичном доступе.
Кроме всего прочего, Stuxnet не гнушается раскидыванием своего дропера по найденным сетевым шарам. В процессе запуска дропер проверяет много различных параметров, но сейчас нас интересует тот факт, что этот зверь использует для повышения привилегий еще две уязвимости нулевого дня. Далее в зависимости от операционной системы происходит выбор подходящего эксплойта для повышения привилегий. Всего их два: один предназначен для повышения привилегий в Win2000/XP, а второй – в Vista/Win7.

MS10-073 – уязвимость в драйвере win32k.sys, позволяющая повысить локальные привилегии под управлением Win2000/XP посредством выполнения произвольного кода в ядре. Уязвимость работает даже под гостевой учетной записью, но реализация шеллкода для режима ядра – задача весьма нетривиальная. Впрочем, авторы Stuxnet с ней успешно справились. Заплатка была выпущена только к середине октября.

(отсутствует Vendor-ID) – уязвимость в планировщике задач (Task Scheduler), позволяющая повысить локальные привилегии до уровня SYSTEM под управлением Vista/Win7/Win2008. Для повышения привилегии будет достаточно даже прав гостевой учетной записи. Уязвимость интересна тем, что она является концептуальной, то есть разработчики допустили ее на уровне архитектуры работы этого сервиса. Пока она не будет закрыта, мы не можем разглашать о ней информацию, но мы любезно предоставили результаты наших исследований (включая PoC) в Microsoft. Естественно, нас поблагодарили и обещали закрыть уязвимость как можно быстрее, но с этого момент прошел уже не один месяц :).

И напоследок осталась еще одна уязвимость нулевого дня – это CVE-2010-2772, которая была найдена в системах Siemens Simatic WinCC и PCS 7 SCADA, и заключается она в жестко прошитом пароле для доступа к базе данных Microsoft SQL из программы WinCC.

 

Внутреннее устройство

Продуманность архитектуры червя Stuxnet тоже уникальна, так как масштабы реализованного функционала поистине впечатляют – более мегабайта выверенного до мелочей объектно-ориентированного кода, скомпилированного одной из последних версий компилятора Microsoft Visual C++. И это только сам дропер, не считая драйверов с руткит-функционалом. Впрочем, в данном случае они ничем нас не поразили. И все-таки, какая сильная вещь: огромное число экспортируемых функций, каждая из которых отвечает за свой функционал, продумана каждая мелочь. Используется проверка различных ситуаций, которые могут повлиять на процесс выполнения кода червя, продумана каждая мелочь… сетевое взаимодействие с центром управления также выполнено на высоком уровне и реализовано в виде собственного протокола обмена.

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

Для того, чтобы описать все технические особенности Stuxnet, не хватит и целого журнала. Наш отчет «Stuxnet Under the Microscope» о проведенном исследовании занимает более 70 страниц, поэтому предлагаю остановиться и перейти к следующей части нашего повествования :).

 

TDL4

Я поставил этот руткит на второе место, потому что это единственный полноценный руткит для х64-систем, который уже успел получить широкое распространение. TDL4 представляет собой дальнейшее развитие вредоносной программы TDL3, которая уже не раз упоминалась на страницах журнала. TDL4 удается успешно обходить защитный механизм проверки цифровой подписи в х64-версиях Windows. Авторы его применили довольно изящный способ обхода, который заключается в использовании техник заражения MBR и старта вредоносного кода раньше самой операционной системы. Подобные методологии уже активно применялись такими вредоносными программами, как Mebroot, StonedBoot и др. А, например, TDL3 использовала для загрузки вредоносного функционала механизм инфицирования системных драйверов без изменения их размера, но так как в х64-системах при загрузке драйверов проверяется цифровая подпись, авторы от этого механизма отказались.

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

  • Открывается описатель физического устройства (в моем случае это был \\??\PhysicalDrive0), на котором располагается раздел с именем «C:»;
  • Подготавливается и записывается образ своей файловой системы в конец жесткого диска (унаследованный из TDL3 функционал);
  • Перезаписывается MBR-кодом, который осуществляет загрузку модулей в ранее подготовленной файловой системе;
  • После успешного заражения на x64-системах происходит перезагрузка при помощи вызова WinAPI функции ExitWindowsEx() или ZwRaiseHardError().

В целом этот процесс выглядит следующим образом:

  • BIOS считывает первый сектор загрузочного диска и передает управление на код главной загрузочной записи MBR. Таким образом начинается выполнение кода TDL4;
  • Далее происходит расшифровка кода для дальнейшего его выполнения, который предназначен для загрузки модуля с именем ldr16 из файловой системы руткита;
  • Загруженный модуль ldr16 осуществляет перехват прерывания 13h, которое отвечает за работу с жестким диском. Основная задача данного модуля – определить разрядность операционной системы (x32 или x64), и в зависимости от нее осуществляется загрузка ldr32 или ldr64;
  • Оба модуля ldr32 и ldr64 предназначены для загрузки основного драйвера TDL4, которая осуществляется без использования стандартного API, чтобы обойти механизм проверки цифровой подписи;
  • Сначала происходит размещение кода драйвера в памяти по адресам, предлежащим ядру ОС. Далее проводится его регистрация как драйвера ОС при помощи вызова недокументированной функции IoCreateDriver(). После этого драйвер можно считать загруженным;

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

 

TDL3

Этот участник нашего рейтинга должен быть уже хорошо знаком читателям, так как он представляет собой истинный шедевр из области системного программирования, претерпевший, к тому же, несколько реинкарнаций. Здесь речь пойдет о последней распространенной версии этого руткита, а точнее – о версии 3.273. Обновление своего функционала TDL3 получил в начале 2010 года, а весной был исправлено несколько ошибок (одна из них – несовместимость руткит-драйвера с одним из патчей от MS :)) и использован еще один ранее неизвестный прием обхода HIPS-систем. А теперь предлагаю перейти к описанию собственно технических изысков TDL3.

 

Обход HIPS-систем

Использование WinAPI-функций AddPrintProcessor и AddPrintProvidor, которые не контролировались большинством HIPS-систем, дало возможность беспрепятственной установки в систему злонамеренного кода в обход многих антивирусных систем и не только. Дело в том, что, как правило, защита основана на следующем принципе – прикрываются известные бреши, а остальное латается на ходу. Это, конечно, дает эффект защиты от распространенных типовых угроз, но, как показывает практика, вероятность появления технологичных вредоносных программ далеко не нулевая. Вот и в нашем случае авторам TDL3 удалось найти доверенные функции, которые никем не контролировались и давали возможность установить руткит в систему.

{
BOOL AddPrintProcessor(
__in LPTSTR pName,
__in LPTSTR pEnvironment,
__in LPTSTR pPathName,
__in LPTSTR pPrintProcessorName
);
}

и
BOOL AddPrintProvidor(
__in LPTSTR pName,
__in DWORD Level,
__in LPBYTE pProviderInfo
);
}

Процесс установки TDL3 можно разделить на две стадии:

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

Для того, чтобы зарегистрировать вспомогательную библиотеку службы печати, необходимо обладать привилегией SE_LOAD_DRIVER_PRIVILEGE, позволяющей загружать/выгружать драйверы. Чтобы получить данную привилегию, дропер вызывает WinAPI-функцию RtlAdjustPrivilge. Если вызов данной функции осуществлен успешно, дропер копирует себя в %PrintProcessor% каталог в качестве динамической библиотеки и осуществляет вызов функции AddPrintProcessor/AddPrintProvidor, передавая ей в качестве параметра имя скопированной библиотеки и строку “tdl”. Данный вызов посредством RPC-механизма заставляет службу печати загрузить указанную библиотеку и вызвать ее точку входа.

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

 

Инфицирование системных драйверов

И снова авторам TDL3 удалось удивить вирусных аналитиков. На самом деле ухищрение в виде заражения системного драйвера понадобилось для того, чтобы помочь руткиту выжить после перезагрузки системы, поскольку прописывать себя в явном виде в ветку автозапуска – это слишком большой риск быть обнаруженным еще до первой перезагрузки системы.

Ранние версии TDL3 заражали строго определенный файл – драйвер минипорта жесткого диска, на котором располагается ОС. Но авторы пошли дальше и решили усложнить процедуру удаления руткита из системы – теперь он заражает случайно выбранный драйвер.

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

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

 

Собственная файловая система

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

  • модулей для внедрения в процессы (tdlcmd.dll);
  • конфигурационной информации (config.ini);
  • тела руткита (tdl);
  • перезаписанных ресурсов зараженного драйвера (rsrc.dat);
  • дополнительных файлов загруженных по сети.

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

С целью автоматизации получения доступа к этой скрытой файловой системе у нас в вирлабе была разработана специальная утилита tfd.exe (TdlFsDumper http://j.mp/tdl_dump). Она распространяется свободно и весьма полезна для быстрого получения доступа к хитрой FS и извлечения из нее данных.

 

Dalixi

Под номером четыре у нас идет китайское народное творчество в области буткитостроения. Жители поднебесной в этом году не раз демонстрировали свои силы в этом нелегком деле, но именно Dalixi запомнился нам интересной технологией обхода HIPS при инсталляции в системе. Перед установкой своих компонентов эта вредоносная программа восстанавливает таблицу системных сервисов ядра, а также нейтрализует callback-процедуры, вызываемые ядром при создании потока или процесса и отображении исполняемых образов в его адресное пространство, которые активно используются различными HIPS и антивирусными продуктами для детектирования вредоносного кода (данные процедуры регистрируются с помощью соответствующих функций: PsSetLoadImageNotifyRoutine, PsSetCreateProcessNotifyRoutine, PsCreateThreadNotifyRoutine). Примечательным является тот факт, что данные действия совершаются кодом, работающим в пользовательском адресном пространстве. Для этих целей Dalixi использует недокументированную функцию ZwSystemDebugControl, экспортируемую модулем ntdll.dll.

NTSYSAPI
NTSTATUS
NTAPI
NtSystemDebugControl(
IN SYSDBG_COMMAND Command,
IN PVOID InputBuffer OPTIONAL,
IN ULONG InputBufferLength,
OUT PVOID OutputBuffer OPTIONAL,
IN ULONG OutputBufferLength,
OUT PULONG ReturnLength OPTIONAL
);

Забавно, что при поиске в интернете по ключевому слову «SysDbgCopyMemoryChunks_1» находятся одни китайские ресурсы и, кстати, хочу заметить – со вполне пристойным описанием.

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

typedef struct _CPY_MEM_CHUNCKS_BUFFER
{
void *Destination; // pointer to kernel-mode destination buffer
void *Source; // pointer to user-mode source buffer
ULONG Size; // size of the user-mode source buffer
}CPY_MEM_CHUNCKS_BUFFER, *PCPY_MEM_CHUNCKS_BUFFER;

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

 

Zeus 2.х.х

За свою универсальность и продолжительность жизни заслуженное пятое место получает вторая версия Zeus. Эволюция этой троянской программы продолжается уже несколько лет, а ее участие было официально подтверждено в достаточно большом количестве громких инцидентов с кражей кругленьких сумм с большим количеством нулей (чего стоит один только инцидент с британскими банками). Поражает своим многообразием и состав модулей, с которым распространяется Zeus, начиная от целевых расширений под конкретные платежные системы и заканчивая возможностью установки VNC или модуля отправки оповещений на указанную учетную запись Jabber. Еще одной интересной функциональной особенностью является наличие функционала для кражи X.509-сертификатов с соответствующими секретными ключами, которые, как правило, используются для осуществления процедуры цифровой подписи, в том числе и для исполняемых модулей. Работает это хозяйство с использованием стандартной функции CryptoAPI PFXImportCertStore для импорта сертификатов (этот же функционал присутствовал и в первой версии).

HCERTSTORE WINAPI PFXImportCertStore(
__in CRYPT_DATA_BLOB *pPFX,
__in LPCWSTR szPassword,
__in DWORD dwFlags
);
}

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

Ежедневно наша вирусная лаборатория обрабатывает несколько тысяч сэмплов, являющихся zeus-ботами. Все распространенные антивирусные средства успешно справляются с их обнаружением и деактивацией, но, тем не менее, количество ежедневных инцидентов по-прежнему велико. В общем, это настоящий комбайн для кражи персональных данных, а модули расширения делают его поистине универсальным инструментом в руках киберпреступников. Информации о второй версии Zeus в интернете уже достаточно много, но хотелось бы обратить внимание читателя на присутствие некоторых интересных нюансов, таких как обход фишинговых фильтров для MS Internet Explorer последних версий. Или, например, удаление всех файлов пользователя по команде из центра управления, а также снятие скриншота экрана в заданный момент времени. Главной особенностью является то, что покупатель может заказать разработку модуля, который будет заточен исключительно под его задачи. Именно за свою гибкость и продуманность с точки зрения коммерческого продукта Zeus попадает на пятое место в нашем рейтинге.

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

Zeus был уличен в большой любви к российским системам дистанционного банковского обслуживания (ДБО)

На данный момент дело, начатое Zeus, активно осваивается автором SpyEye, который набирает обороты, и кто знает, может быть, в следующем году именно он удивит нас чем-нибудь интересным. Количество активных C&C для этого бота растет с каждым днем, причем на данный момент большая их часть находится на Украине, в России и странах СНГ.

 

Заключение

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

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии