Руткиты: проблемы безопасности и тенденции развития

    В настоящее время очевидно смещение вектора компьютерных атак от массового заражения к целевым, точечным атакам. Как сказал Е. Касперский: «Девяностые были десятилетием киберхулиганов, двухтысячные были десятилетием киберпреступников, сейчас наступила эра кибервойн и кибертеррора». Иллюстрацией этому являются всем известные примеры: Stuxnet, Duqu, Flamer, Gauss, которые многие антивирусные компании причисляют к кибероружию.



    Основные тенденции в компьютерной безопасности


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


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

    Казалось бы, разработчики ОС должны всеми силами противостоять сокрытию нелигитимного ПО, однако появление новой версии Windows не изменило ситуацию в лучшую сторону. Восьмерка переняла от своих предшественников часть уже знакомых механизмов защиты (UAC, ASLR, DEP, PatchGuard, цифровые подписи для драйверов), для которых существует возможность обхода. И представила несколько новых — Secure Boot, SMEP и ELAM, которые, однако, не сильно повысили уровень защищенности. О чем свидетельствуют демообразец буткита Stoned Lite Питера Кляйсснера и UEFI bootkit Андреа Аллиеви. А о возможности обхода технологии SMEP на Windows 8 уже писал А. Шишкин из компании Positive Technologies.

    INFO

    Согласно недавнему отчету британской Национальной аудиторской службы (NAO), наблюдается рост числа киберпреступлений, которые одной Великобритании обходятся в 18–27 миллиардов фунтов стерлингов ежегодно (bit.ly/14O9xy5).


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

    Механизмы сокрытия в системе


    Для сокрытия ВПО могут применяться различные методы. Впервые классификация механизмов сокрытия была выполнена Йоанной Рутковской в работе Introducing Stealth Malware Taxonomy. Предложенная ей классификация может быть расширена следующим образом (см. рис. 1).

    Рис. 1. Схема классификации механизмов сокрытия программного обеспечения

    Стеганографические механизмы скрывают истинное предназначение внедренных объектов маскировкой их под легитимные, например схожестью их имен с именами системных файлов. В результате вредоносные файлы видны пользователю, но не вызывают у него подозрения. Пример стеганографического сокрытия — использование сертификатов доверенных компаний для подписи вредоносных драйверов. Благодаря действительным сертификатам компаний Realtek и JMicron червь Stuxnet долгое время оставался незамеченным, а компоненты червя Flame имели цифровую подпись самой компании Microsoft.

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

    Ко второй группе относятся технические механизмы сокрытия, в результате работы которых информация о скрываемом объекте становится недоступной средству обнаружения («не виден объект, значит, его и нет»). Эти механизмы можно разделить на руткит-механизмы, работающие «внутри» и «вне» ОС.

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

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

    Вторая подгруппа руткит-механизмов, работающих «внутри» ОС, не добавляет новых обработчиков в систему, а особым образом изменяет структуры памяти, хранящие информацию о скрываемом объекте. Примеры таких структур, расположенных в системном адресном пространстве и представляющих интерес для руткитов: KRPCB, ETHREAD, EPROCESS, MODULE_ENTRY, _DRIVER_OBJECT, плюс БД зарегистрированных драйверов и служб, расположенная в пользовательском пространстве процесса SERVIСES.EXE.

    Руткит-механизмы «вне ОС» основаны на установке собственного или модификации существующего обработчика событий в том или ином режиме работы процессора либо дополнительного аппаратного обеспечения. Для работы этих механизмов зачастую необходимо наличие набора микросхем с поддержкой требуемой технологии. Можно выделить руткит-механизмы, построенные на основе режима аппаратной виртуализации, режима системного управления и кода, использующего технологии Active Management Technology и V-PRO. Широко известный в узких кругах автор R_T_T в своих работах «Кремневый беспредел» описывает возможности и угрозы информационной безопасности не только от указанных технологий, но и от механизма обновления микрокода процессора (bit.ly/VRQD6O и bit.ly/104EsRB).

    Интересная техника сокрытия руткитов

    На конференции ZeroNight в 2012 году была представлена работа Д. Олексюка (aka Cr4sh) в которой описывался интересный способ размещения руткита не в файлах, а в реестре с помощью Differentiated System Description Table (DSDT). Преимущество данного способа в том, что ни одно средство для обнаружения руткитов не учитывает такую возможность.


    Антируткиты


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

    Из популярных внештатных средств, поддерживающих работу с Windows 8, можно выделить следующие: Gmer, XueTr, PowerTool, TDSSKiller (Kaspersky Labs).

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

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

    Программно-аппаратные руткиты


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

    С 2006 года компании Intel и AMD начали выпускать процессоры с поддержкой технологии аппаратной виртуализации. ПО, использующее технологию аппаратной виртуализации (или просто гипервизор), работает в новом режиме, более привилегированном, чем ОС. Технология аппаратной виртуализации позволяет запускать во вложенном виде несколько различных гипервизоров.

    Исходные коды гипервизоров — драйверов для ОС Windows x86

    Быстрее и проще всего создать свой гипервизор, взяв за основу один из существующих. На диске, прилагаемом к журналу, ты сможешь найти следующие исходники:
    1. BluePill (версии 0.11 и 0.32) — демонстрационный образец гипервизора для систем AMD, после публикации которого и началось широкое обсуждение угроз ИБ от аппаратной виртуализации.
    2. vmxcpu — исходный код заглушки гипервизора Ш. Эмблтона (Sh. Embleton) для процессоров Intel, который уже готов к использованию.
    3. Invisible Lane (il) — исходный код авторского скрытого гипервизора, построенного на основе vmxcpu. Сокрытие осуществляется путем компрометации процессорного счетчика тактов TSC, величина компрометации может задаваться с точностью до одного такта.


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

    Рис. 2. Схема взаимодействия операционной системы с аппаратным обеспечением при отсутствии (присутствии) двух гипервизоров: легитимного с функциями монитора виртуальных машин и нелегитимного, находящихся во вложенном виде

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

    В открытом доступе имеются два программных средства — BluePill и Vitriol, реализованные в виде драйверов, которые устанавливают гипервизор прозрачно для пользователя.

    Обнаружением гипервизоров занимались как целые компании (Komoku, North Security Labs и другие), так и отдельные специалисты. Даже сама компания Microsoft опубликовала интерфейс для обнаружения гипервизоров, согласно которому необходимо выполнить инструкцию CPUID, предварительно записав в регистр EAX единицу. Далее необходимо проверить значение 31 бита регистра ECX; если он выставлен, то в системе присутствует гипервизор, а информация о его возможностях передается в структуре HV_CPUID_RESULT. Однако такой способ не защищен от компрометации.

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

    Средства отладки гипервизоров

    Специфика работы гипервизора не всегда позволяет использовать популярные средства отладки, такие как vBox (VMware) вместе с WinDbg, вместо этого можно использовать эмуляторы Bochs или AMD SimNow, однако они достаточно сложны в настройке.

    Что же можно использовать:

    1. Вывод отладочных сообщений через DbgPrint и просмотр их с помощью DbgView. Правда, такой метод можно использовать скорее для демонстрации корректной работы гипервизора, чем для его отладки.
    2. Отправлять отладочные сообщения на COM-порт. Этот способ использовали авторы BluePill, сохранив в исходнике реализации этих функций.
    3. Использовать отладочную плату, например «PTI8 Diagnostic Post Test Card Debug Card PCI Analyzer». При включении компьютера на LCD-дисплее этой платы можно будет увидеть POST-сообщения BIOS.


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

    Обзор и классификация способов обнаружения гипервизоров


    Вопрос обнаружения гипервизоров уже неоднократно обсуждался. На рис. 3 представлена классификация способов обнаружения гипервизоров, согласно которой все способы делятся на проактивные и сигнатурные.

    Рис. 3. Классификация способов обнаружения гипервизоров

    Временны́е способы обнаружения основаны на том, что статистики времени обработки заданных событий гостевой ОС существенно зависят от того, загружен гипервизор или нет: в присутствии гипервизора длительность обработки событий значительно больше. Данная особенность была использована товарищем R_T_T при обнаружении китайского гипервизора (xakep.ru/post/58104). Она позволяет сравнительно просто выявлять гипервизоры только в тех случаях, если нарушитель не предпринял меры для их сокрытия. В ситуациях, когда осуществляется целенаправленная компрометация счетчика либо временная выгрузка гипервизора из памяти (так называемая технология BlueChicken, которая использовалась в BluePill), известные временны́е способы не позволяют обнаружить гипервизор.

    Детальное описание и сравнительный анализ указанных способов обнаружения представлен в работе bit.ly/ik_volume. Мы же уделим внимание временному способу обнаружения с использованием списка демаскирующих событий.

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

    Чтобы оценить каждый из методов, были проанализированы средства обнаружения гипервизоров, результаты сравнения которых представлены в табл. 1. Под не скрытым гипервизором подразумевается отсутствие в этом образце компонента, обеспечивающего противодействие обнаружению. Под скрытым образцом подразумевается наличие в этом образце такого компонента. В табл. 1 знаки «+» и «–» показывают наличие (отсутствие) указанной характеристики соответственно.

    Таблица 1. Сравнение средств обнаружения гипервизоров

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

    • временны́е способы не позволяют выявить гипервизоры в случае использования компрометации счетчика тактов либо временной выгрузки из памяти;
    • поведенческие способы не могут обнаруживать новые гипервизоры и неработоспособны на новых моделях процессоров;
    • способы на основе доверенного монитора виртуальных машин уязвимы к атаке «человек посередине» («man-in-the-middle»);
    • сигнатурные аппаратные средства неудобны в использовании и тиражировании, а программные средства нестойки к противодействию гипервизора;
    • все опубликованные способы и средства обнаружения не позволяют обнаружить несколько вложенных гипервизоров.


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

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


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

    Предпосылки для обнаружения


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

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

    В случае присутствия гипервизора возрастает не только абсолютное время выполнения трассы, но и значения статистических характеристик длительности выполнения, например дисперсии. Эта отличительная особенность и легла в основу предлагаемой методики обнаружения (подробный анализ схем переключения между режимами работы процессора и математическое обоснование можно посмотреть тут bit.ly/10nPPlY.

    Методика обнаружения и ее анализ


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

    Измерение длительности выполнения трассы проводилось для десяти инструкций CPUID с помощью процессорного счетчика тактов TSC на повышенном 31-м уровне приоритета IRQL. Результатами опытов являлись матрицы размером 1000 х 10, содержащие данные измерений длительности выполнения трассы, по которым рассчитывались различные статистические характеристики.

    Для иллюстрации в табл. 2 приведены пороговые значения последовательной комбинации таких показателей, как дисперсии D ̅f и момента 4-го порядка M ̅f, полученных на различных ПК, для случаев отсутствия (ОТ) и присутствия (ПР) гипервизоров.

    Таблица 2. Пороговые значения тест-статистик длительности трассы и их доверительная вероятность, полученные на различных ПК

    В первом столбце табл. 2 номерами обозначены модели процессоров обследованных ПК:

    1. Intel Core 2 Duo E8200 с ОС Windows 7,
    2. Intel Core 2 Duo E6300 с ОС Windows 7,
    3. AMD Phenom X4 945 с ОС Windows Live CD XP (DDD).


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

    Предлагаемая методика обнаружения нелегитимного гипервизора состоит из двух этапов: предварительного и оперативного, как представлено в табл. 3 (детальное описание методики: bit.ly/ik_volume).

    Таблица 3. Пошаговая методика обнаружения нелегитимного гипервизора

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

    Правда, данная методика не лишена и недостатков (табл. 4).

    Таблица 4. Недостатки и возможные решения методики обнаружения

    Взгляд в будущее


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

    1. Руткиты в облаках и суперкомпьютерах. Зачастую для повышения производительности облачных вычислений используют аппаратную виртуализацию. При этом отсутствует информация о проверке таких систем на отсутствие нелегитимных гипервизоров.
    2. Руткиты во встраиваемых системах. Различные встраиваемые системы получают огромную популярность, это системы «Умный дом», «Умный город», системы в автомобилях и многие другие. Новая инициатива IBM Smarter Cities требует особого внимания, так как многочисленные компоненты системы обеспечивают жизнедеятельность большого количества людей, при этом представляя собой добычу для нарушителей.
    3. Руткиты в мобильных ОС. Внедрение руткитов в мобильные операционные системы уже давно не новинка.
    4. Руткиты в виде предустановленного ПО в планшетах


    Не могу снова не упомянуть работу R_T_T, посвященную закладкам в военных ноутбуках Getac (bit.ly/Sf23yP). Там программные закладки были выполнены в виде софта от компании Compuware, именно той, которая выпускала мощный отладчик SoftICE. В настоящее время аналогичные закладки этой компании можно встретить в планшетах. К примеру, новые ThinkPad 2 с продвинутым уровнем защиты продаются уже с предустановленным ПО — «Enterprise-level security, with Trusted Platform Module and Computrace Mobile».

    WWW

    Интересную работу, посвященную EFI-руткитам, но под OS Х, выполнил Loukas K: bit.ly/Pe1Dkl.


    Итоги


    Как видишь, технологии создания руткитов не стоят на месте, делая задачу их обнаружения все сложнее. Это превращает их в очень опасное кибероружие, способное оставаться незамеченным, но в нужный момент нанести точный и смертельный удар. Понимая всю их опасность, за рубежом создали специальные компании, занимающиеся исследованиями в области сокрытия и обнаружения программных закладок, такие как: DARPA и IARPA (США), DSTL (Великобритания), DRDC (Канада), COSTIND (Китай). Будем надеяться, что скоро и в нашей стране появятся полноценные кибервойска, пока же уровень безопасности (читай обороноспособность) в военных ведомствах оставляет желать лучшего.

    Об авторе

    Игорь Коркин (igor.korkin@gmail.com) — кандидат технических наук по специальности 05.13.19 «Методы и системы защиты информации, информационная безопасность». Работает в МИФИ, руководит научной работой студентов, готовит аспирантов. Занимается обнаружением программных закладок более шести лет, автор более десяти научных работ, победитель конкурса «Хакеры против форензики» на форуме Positive Hack Days 2012.



    Впервые опубликовано в журнале «Хакер» от 05/2013.

    Публикация на ISSUU.com

    Подпишись на «Хакер»




    P.S. Можете поделиться знаниями и интересными идеями, написав для ][? Дайте знать :). Мы платим гонорары, но это не должно быть главной мотивацией.
    Журнал Хакер
    0,00
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 14

      0
      Страшно жить на свете белом, ведь если включить режим паранойи и пофантазировать на тему хардварных закладок в самих процессорах и мостах… Даже не в смысле виртуализации и средств удалённого администрирования, а в смысле никак не документированной НЁХ, на случай ядрёного припадка терроризма или восстания машин >;-)
        +1
        Быстрее и проще всего создать свой гипервизор, взяв за основу один из существующих. Поэтому на диске ты сможешь найти следующие исходники

        Так, а где диск?????!!!
          +1
          Ссылки на материалы с диска чуть позже выложим в конце статьи.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            мы все погибнем! ))))
            или перейдем на *nix-подобные системы…
              +1
              А что, *nix-подобные системы защищены от руткитов или злонамеренных гипервизоров?
                0
                nix-подобных системах нет практики ставить бинарники из непонятных источников, есть репозитории с подписанными пакетами, куда непросто попасть и непросто скрыть потом левый код
                  0
                  Индеец и неуловимый, потому, что он мало кому пока массово интересен и нужен…
                  Как только % пользователей *nix систем поднимется выше арифметической погрешности и на *nix перейдут толпы простых смертный, далёких от IT (что сейчас есть творится в win) все ставить начнут откуда угодно, запускать что угодно и сидеть все будут только под root-ом. Соответственно и вирусоносителям всех мастей станет интересна система.
                  Тогда можно будет вернуться к мифу о супер-защищённости :).
                  +1
                  Гипервизору до лампочки какая ОС стоит, он работает вне контекста ОС и занимает память которую ОС не видит. Так что все ОС не защищены от гипервизора
                    0
                    «Все ОС не защищены от гипервизора» — к этому и сводилась суть моего комментария. По реплике же sirinbird складывается ощущение, что он уверен в защищенности *nix-ов от злонамеренных гипервизоров, злонамеренных thunderbolt/pcie-устройств и злонамеренных плат расширения.

                    По поводу «до лампочки, какая ОС стоит» — да, до тех пор, пока он не собирается вмешиваться в ее работу на более тонких уровнях.
                      0
                      Значит я просто немного не дополнял. А так да, я согласен.
                +1
                Bochs сложен в настройке? Свежо предание.

                Если человек пишет гипервизор или хотя бы модифицирует существующий, bochs у него затруднений не вызовет никаких. Неудобен — возможно, хотя это дело вкуса. А вот сложен…
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Я как-то уже описывал возможную схему атаки на сервера с использованием IPMI-плат. В этом случае вредоносный код хранится на сервере в IPMI устройстве (которое может переживать перезагрузку), и имеет возможность контролировать процесс загрузки (например, отсылая команды на клавиатуру и взаимодействуя с системой через com-порт). Вся драма состоит в том, что проникновение в IPMI возможно через хост-систему, а вот обнаружение (в общем случае) нет.

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

                    Самое читаемое