Компания
240,78
рейтинг
12 февраля 2013 в 12:02

Разработка → Современные буткит-технологии и детальный анализ Win32/Gapz

В последние несколько лет увеличилось распространение вредоносных программ (буткитов), модифицирующих загрузочные сектора в процессе заражения системы. Среди самых видных представителей — TDL4, Olmasco и Rovnix. Каждый из них использует различные способы заражения жесткого диска, это либо модификация главной загрузочной записи (MBR), либо модификация первых секторов загрузочного раздела, т. е. VBR или IPL (первые сектора тома, куда передается управление из MBR — Volume Boot Record/Initial Program Loader). Наглядно эти семейства показаны на рисунке ниже.


Рис. 1. Схема различных семейств буткитов и методов заражения диска.

Существует несколько причин использования буткитов в современных угрозах:
● Возможность запуска вредоносного кода раньше кода ОС, что дает неоспоримые преимущества и позволяет контролировать процесс загрузки ОС.
● Как следствие первого пункта, позволяет обходить систему мониторинга целостности ключевых компонентов ядра — PatchGuard (практически единственный способ обеспечить выживаемость руткита в x64-среде).
● Возможность глубоко скрывать свой код и, таким образом, делать его невидимым для AV-сканеров.
● Буткит имеет посекторную архитектуру хранения своего тела на диске, что дает возможность выносить свой вредоносный код и код полезной нагрузки далеко за пределы файловой системы и даже разделов диска, делая почти невозможным его обнаружение.
● Безопасная установка руткита в системе.

В отчете ESET по угрозам и трендам за 2012 г., мы указали, что буткиты являются одним из ключевых технических трендов прошедшего года. Наши эксперты отслеживают появление новых сложных угроз. Мы также не обошли стороной и Win32/Gapz, так как он содержит ряд технических особенностей, которые делают его действительно интересным. Александр Матросов и Евгений Родионов проделали большую работу, занимаясь анализом этого буткита. Сегодняшний наш пост посвящен этому анализу.

Дроппер

Начнем с дроппера — компонента, который является изначальным носителем кода буткита и отвечает за его установку в системе. Мы детектируем его как: Win32/Gapz.X, X-версия. Мы обнаружили три его версии, A, B и C. Ниже в таблице приведены их характеристики:


Рис. 2.

В соответствии с нашими наблюдениями, первая известная версия дроппера была скомпилирована в апреле прошлого года и содержала много отладочной информации, т. е. не подразумевалась для массового распространения. Вполне вероятно, что Win32/Gapz начали массово распространять в конце лета или начале сентября прошедшего года. Для поднятия своих привилегий в системе Win32/Gapz использует LPE-эксплойты и COM Elevation метод.
В процессе анализа мы обнаружили, что заражению Win32/Gapz подвержены: 32-битные Windows XP SP2 и выше (исключая Windows Vista и Vista SP1) и 64-битные Windows XP SP2 и выше. Обсуждаемая версия дроппера Win32/Gapz способна заражать Windows XP и Windows 7, включая x64 версии, однако на Windows 8 буткит-часть не работает должным образом и после заражения часть, надлежащая к исполнению в режиме ядра, не исполнялась.


Рис. 3. Часть кода дроппера, проверяющая версию ОС.

Дроппер, устанавливающий буткит в систему, тщательно продуман и способен обойти современные проактивные защиты (HIPS), а также поднимать свои привилегии до уровня системы. Кроме того, он содержит хитрый метод внедрения кода в адресное пространство процесса. Файл дроппера экспортирует из себя несколько функций, которые указаны ниже на рисунке.


Рис. 4. Функции, экспортируемые исполняемым файлом дроппера.

Есть три экспортируемые функции, на которые следует обратить внимание: start, icmnf и isyspf. Краткое описание:
● start — точка входа в дроппер, осуществляет его внедрение в адресное пространство доверенного процесса explorer.exe;
● icmnf — отвечает за повышение (эскалацию) привилегий;
● isyspf — выполняет заражение жертвы кодом буткита.

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


Рис. 5. Стадии выполнения дроппера и заражения жертвы кодом буткита.

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

Вредоносный код MBR

Мы обнаружили две модификации буткита Win32/Gapz, которые различаются методами заражения диска жертвы. Самая ранняя модификация появилась в начале лета 2012 г., эта версия была нацелена на заражение MBR. Другая, более поздняя модификация, которая заражает VBR, была замечена в конце осени 2012 г.


Рис. 6. Две модификации Win32/Gapz, нацеленные на заражения MBR и VBR.

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

Вредоносный код сохраняет свой код режима ядра и полезную нагрузку либо перед самым первым разделом, либо после последнего раздела на жестком диске. Такой подход очень похож на тот, который использовался в бутките Rovnix, за исключением того, что Rovnix заражает VBR.
Что касается буткит части Win32/Gapz, то в ней нет ничего необычного: как только код из вредоносного MBR исполнился, он восстанавливает оригинальный код в памяти и читает следующие секторы жесткого диска, содержащие код для последующего исполнения, на который и передается управление. Код буткита перехватывает обработчик прерывания 0x13, int 13h и отслеживает, таким образом, загрузку ниже перечисленных модулей ОС для установки туда перехватов:
ntldr (на системах до Windows Vista)
bootmgr (на системах Vista+)
winload.exe (на системах Vista+)

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



Как только вредоносный код обнаруживает, что конкретный модуль читается с жесткого диска, он модифицирует его таким образом, чтобы вернуть себе контроль после того, как процессор переключится в защищенный режим. Буткит устанавливает перехваты на загрузчик ядра ОС: это либо ntldr в устаревших системах до Windows Vista, либо bootmgr в Vista и выше. В случае с bootmgr, он также перехватывает функцию OslArchTransferToKernel в winload.exe.


Рис. 7. Перехватчик функции OslArchTransferToKernel в winload.exe.

Следующий этап, это установка перехвата на функцию IoInitSystem, которая вызывается в процессе инициализации ОС. Она перехватывается вредоносным кодом либо из ntldr, либо из winload.exe, в зависимости от версии ОС.


Рис. 8. Код перехвата, устанавливаемого на функцию IoInitSystem.

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

Вредоносный код VBR

Как мы уже упоминали, последняя модификация Win32/Gapz заражает VBR тома, который помечен как активный в MBR (Volume Boot Record — первые сектора тома, в которых прописана служебная информация, а также VBR-код, на который передается управление из MBR и который отвечает за дальнейшую загрузку ОС). Буткит использует оригинальный подход для заражения VBR с последующей передачей управления своему коду. Для того чтобы быть более скрытным и незаметным, он модифицирует только несколько байт оригинальной VBR. Суть такого подхода заключается в том, что он модифицирует значение поля «Hidden Sectors» в поле служебной структуры VBR, при этом оставляя код VBR и код IPL нетронутым! IPL, Initial Program Loader — код, на который передается управление после исполнения кода VBR, он отвечает за поиск загрузчика в рамках файловой системы тома и передает на него управление. В состав VBR включены следующие части:
● Bootstrap-код (VBR-код), отвечающий за загрузку IPL.
● BIOS Parameter Block (BPB) — структура данных, хранящая блок параметров NTFS.
● Текстовые строки, отображаемые пользователю в случае ошибки.
● 0xAA55 — стандартная двухбайтовая сигнатура, маркер служебного сектора.


Рис. 9. Схема первого сектора VBR.

В случае с Win32/Gapz, наиболее интересным местом для анализа является BPB и особенно поле «Hidden Sectors». Это поле содержит количество секторов, предшествующих IPL (т. е. смещение до IPL в секторах, с помощью которого код из VBR определяет, куда передавать управление далее) и хранящихся на NTFS-томе, как показано ниже.


Рис. 10. Структура NTFS-тома.

Таким образом, в процессе загрузки на чистой системе, VBR-код считывает 15 секторов, начиная со смещения, указанного в «Hidden Sectors», и передает туда управление. Этим и пользуется буткит для передачи управления на себя. Он перезаписывает это значение, указывая смещение в секторах до своего вредоносного кода, хранящегося на диске. После заражения том выглядит так:


Рис. 11. Модифицированное буткитом значение «Hidden Sectors» приводит к тому, что код VBR передает управление на код буткита, а не на IPL.

В случае заражения системы, VBR-код вызывает на исполнение код буткита вместо легального IPL. Код буткита, как уже упоминалось, записывается либо перед самым первым разделом диска, либо после последнего. В остальном код буткита, по существу, ничем не отличается от версии с MBR-инфектором.

Вредоносный код режима ядра

Основное предназначение непосредственно той части, которая и называется буткитом, описанной выше, заключается в загрузке вредоносного кода режима ядра или руткита в системное адресное пространство, обходя ограничения, накладываемые ОС для такого привилегированного кода. Мы уже упоминали, что этот загружаемый буткитом код, содержит в себе руткит для скрытия своего присутствия, механизм работы с управляющим сервером C&C, а также полезную нагрузку (payload), которая предназначена для внедрения в процессы.
В отличие от Rovnix, TDL4 и других распространенных буткитов, вредоносный код режима ядра в Win32/Gapz не имеет структуры исполняемого PE-файла. Вместо этого он структурирован особым образом. Код состоит из 12 объединенных между собой блоков, каждый из которых имеет заголовок — структуру, которая хранит служебную информацию о нем. Она имеет следующий вид:



Каждый из блоков реализует определенный функционал: внедрение полезной нагрузки, взаимодействие с C&C серверами, самозащиту и так далее. Функционал кода режима ядра является достаточно сложным и может быть рассмотрен отдельно (выходит за рамки этого поста).

Bootkits vs. Microsoft ELAM

В этой части нашего поста мы хотим остановиться на специальном средстве, которое Microsoft решили использовать для борьбы с различного рода угрозами, особенно, руткитами и буткитами, которые пытаются загрузить себя раньше других драйверов в системе. Средство называется ELAM, Early Launch Anti-Malware Module и поставляется в составе ОС, начиная с Windows 8. По сути ELAM – это драйвер, предоставляемый антивирусным вендором, которому гарантирован приоритет при загрузке драйверов режима ядра. С точки зрения же ядра ОС, ELAM представляет собой API для антивирусных драйверов, а также набор правил, которых такому драйверу следует придерживаться. Одна из главных возможностей этого средства заключается в том, что он гарантированно позволяет AV-драйверу загружаться раньше остальных драйверов в системе и, таким образом, выходить за рамки обычных правил автозагрузки, регламентируемых для остальных драйверов.

Мы отмечаем, что ELAM сам по себе не может быть так эффективен для борьбы с буткитами, поскольку это часть ядра ОС, а буткит получает управление гораздо раньше.


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

В то же время, следует отметить, что ELAM является частью декларируемой Microsoft концепции или схемы «Безопасной загрузки» — Secure Boot. В случае с Secure Boot, программное обеспечение, встроенное в UEFI (такое ПО получает управление как только компьютер начал свою работу) может контролировать целостность и легитимность кода, на который передается управление в процессе выполнения кода, предшествующего выполнению основного кода ОС. Концепция Secure Boot, совместно с новым стандартом UEFI, призвана предотвратить компрометацию критичных структур данных ОС/UEFI со стороны буткитов.
Автор: @esetnod32
ESET NOD32
рейтинг 240,78

Комментарии (26)

  • +11
    Наконец-то настоящий вирус. Поделки на Дельфи именуемые «троян» — это было так уныло.
  • +1
    Надеюсь, что борьба противоположных сторон не приведет к еще большим осложнениям для OpenSource (как это получается с UEFI).
    • +1
      UEFI (а точнее его secure boot) — отключаемая опция. В случае linux и прочего opensource secureboot может быть отключен, в силу своей неактуальности, а при использовании win8 далее — включен и обеспечивать соответствующую защиту. Имхо — вполне актуальное по логике решение.
      • +1
        по умолчанию то он не включен, что не позволит хомячкам установить дистр той же убунты. Предвещаю ответ в стиле «linux» хомячкам не нужен — cannonical с вами не согласна. Имхо secure boot помимо основной нагрузки это еще и палки в колеса остальных «домашних» ОС.
        • 0
          Именно что по-умолчанию он (secure boot) не включен. По крайней мере в последней материнке которую я покупал — он он был выключен. И никаких проблем с установкой арча не возникло.
        • –1
          Только что специально включил Secure Boot на ноуте (Lenovo Yoga), и загрузился штатными средствами с флешки с Ubuntu 12.10 x86-64. Secure Boot этому не помешал, также как и установке и запуску на ноуте друга, тоже со специально включеной опцией.
          • 0
            Вы вообще понимаете, что такое Secure Boot?
            • 0
              Прекрасно понимаю. Выше утверждали, что введение Secure Boot повредит свободным ОС и прочему homebrew, но вот этот пример показывает, что этого не происходит. (Загружался также и с жесткого диска)
  • +1
    На мой взгляд, по логике было бы актуальным решение производителей BIOS, которое бы позволило сохранять в CMOS-памяти контрольную сумму нулевого и некоторых других секторов конкретного дискового устройства по вызову админа, установившего ОС, и проверять её перед загрузкой компа с этого устройства.
    • 0
      На моем первом компе биос контролировал МБР, и при попытке записи туда выдавал соответствующее предупреждение.
      • +1
        У меня на стареньких машинах тоже это было. Однако контролировал это дело биос на уровне INT 13h, а в protected-mode BIOS не используется. Но читать секторы на диске, считать и сверять контрольные суммы BIOS по-прежнему может.
        • 0
          Кто мешает вирусу править сохраненное в биос значение?
          • +1
            Например, неизвестный вирусу алгоритм или закрытый ключ для вычисления нового значения.
          • 0
            В те же далекие годы — годы расцвета чернобыля и последователей, были популярны биосы с физической защитой от записи с помощью спец. джампера.
            • +1
              Помню — в т. ч. про Win95.CIH. Но до внедрения вирусного кода в BIOS не добрались ни тогда, ни сейчас — научились только валить систему так, чтобы для восстановления требовались ниточки или программатор. А загрузочные области джампером защищать, похоже, проблематично.
    • +1
      Тогда встаёт проблема, как легитимно обновить в BIOS контрольную сумму после обновления загрузчика, то есть по сути возвращаемся к проблеме Secure Boot.
      • +1
        В общих чертах — так (исходно проверка отключена):
        1. В BIOS Setup подключается настройка — контролировать критически важные секторы при загрузке — и ставится действие — Рассчитать значение для контроля. Для экспертов можно сделать редактирование списка контролируемых секторов (по умолчанию, возможно, хватит нулевого).
        2. Админ ставит систему, потом в BIOS Setup заполняет список контролируемых секторов (если хочет), рассчитывает контрольные значения и ставит опцию контроля.
        3. Если после перезагрузки BIOS вычисляет несоответствие, он ругается — мол, на диск внесены изменения куда не надо. Возможно, это вирус. Обратитесь к специалисту.


        Разумеется, надо как-то сделать так, чтобы вирус не смог отключить опцию контроля — это можно было бы сделать только через BIOS Setup.
        • 0
          По-умолчанию схема включена и активна? Если да, то какие преимущества по сравнению с secure boot для обычного пользователя?
          • +1
            Для обычного пользователя никаких. Для специалистов — отсутствие необходимости подписывать загрузчик: все действия для обеспечения безопасной загрузки выполняются админом в ходе начальной установки ПО на компьютер.
            • 0
              Загрузчик от Linux foundation всё равно в итоге подпишут, и это будет удобнее, чем контрольные суммы в биосе. Тем более, что далеко не все специалисты знают, в каких секторах располагается загрузчик.
              • +1
                Проблема в том, что помимо Microsoft и Linux есть ещё и другие операционные системы, а также мелкие системные разработчики. Им что делать?
                • 0
                  А другие операционные системы и мелкие системные разработчики обязательно должны писать свой uefi загрузчик? Мне всегда казалось, что грузить своё ядро через какой нибудь grub намного эффективнее в плане затраченных на разработку ресурсов.
                  • 0
                    Ну так кому-то grub не нравится… мало ли.
                    • 0
                      Написать stage 2 загрузчик для своей собственной системы (или сразу ядро грузить) намного проще, чем написать загрузчик с нуля, который будет поддерживать хотя бы линукс и винду в дополнение к своей системе. Если кто-то пишет свой загрузчик — то совершенно определённо, меинстримом этот загрузчик станет, если станет, только через много лет, так что говорить в этом контексте о Secure Boot, который разработчик может отключить на своей машине, как-то глупо.
        • 0
          Вобщем-то, secure boot примерно так и работает, за исключением того что проверяются не просто контрольные суммы, а подписи доверенными сертификатами.
  • 0
    «And we need to go deeper»:

    Для сносного противодействия буткитам нужно контролировать ВЕСЬ процесс загрузки, используя устойчивое шифрование вкупе с цифровыми подписями. А начинать нужно с контроля записи BIOS на аппаратном уровне, продолжая до подписанного MBR загрузчика и далее.
    Да, это создаст дикие неудобства для «нестандартных» ОС, и ограничит их количество. Да, это замедлит загрузку.

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

Самое читаемое Разработка