Предисловие от редакторов VM Guru: Уважаемые читатели! Хотим обратить ваше внимание на приведенную ниже статью от нового автора ресурса Андрея, ранее не публиковавшего свои материалы на страницах нашего сайта. Тема, затронутая автором, весьма и весьма интересная. Андрей серьезно занимается системным программированием и безопасностью информационных систем. Если у вас есть к нему вопросы - напишите об этом в комментариях. И да, мы не несем никакой ответственности за последствия работы программ на вашем оборудовании. Все операции рекомендуем выполнять в тестовых окружениях.
Когда произносится слово «виртуализация», сразу на ум приходят названия фирм VMware, Microsoft, Cisco… и разных продуктов стоящих за этими фирмами.
Виртуализация в нашем сознании прочно связана с понятиями гостевых ОС, гипервизорами, облачными вычислениями и прочими сложными программными комплексами. Мы уже привыкли, что все связанное с виртуализацией сложно, непонятно, имеет громоздкую программную инфраструктуру и создание таких систем - это удел крупных фирм, обладающих штатом программистов измеряемых сотнями, если не тысячами человек.
Однако это всего лишь миф, и системы виртуализации (после того, как аппаратная виртуализация появилась в процессорах и чипсете) вполне по силам создавать маленьким коллективам, более того продвинутым одиночкам.
Конечно, речь идет не о создании полномасштабных проектов глобальных систем виртуализации, а о довольно специфических продуктах, использующих аппаратную виртуализацию совсем не для разделения множественных виртуальных вычислительных ресурсов.
Первым таким общеизвестным проектом стала пресловутая «Голубая пилюля» (Blue Pill). Хотя она и является исследовательским проектом, выполняемым в интересах Хакерского сообщества, она продемонстрировала потенциал технологии аппаратной виртуализации применяемой в совсем другой сфере, нежели предполагали их разработчики.
К сожалению, больше в открытых публикациях упоминаний о системах использующих аппаратную виртуализацию не встречается, однако это не значит, что их нет.
Примером использования аппаратной виртуализации в «мирных целях» служит описываемая ниже система, состоящая из двух небольших программ. Этот программный комплекс доступен для скачивания с ресурса VM Guru, и, кроме демонстрационной цели, может быть использован в серьезной работе системного программиста-исследователя, к примеру, по поиску уязвимостей и реверса исполняемых компонент.
В противовес «Голубой пилюле», эта демонстрационная программа названа «Красной пилюлей», и в этом названии сразу несколько скрытых смыслов одновременно.
Принципы работы описываемой системы требуют специального пояснения, поскольку приходится писать об абсолютно новом классе программных продуктов. Введем новую терминологию:
ГиперДрайвер – программа резидентно находящаяся в Оперативной Памяти и осуществляющая контроль над аппаратурой и программной средой вычислительной системы. Для ее работы используется аппаратная виртуализация Центрального Процессора, с помощью которой создается виртуальная среда и в ней запускается операционная система.
Задачей гипердрайвера является :
сохранить работоспособность своего кода в любой программной среде
остаться незамеченным для любых программных средств, загруженных на вычислительную установку.
постоянно контролировать выбранные аппаратные и программные объекты в вычислительной среде.
обеспечивать связь с компонентами визуализации и управления его работой.
Гипердрайвер в рамках аппаратной платформы виртуализации моделенезависим и может поддерживать работоспособность в любой операционной системе.
ГиперАгент – программа, осуществляющая управление гипердрайвером и получение информации от гипердрайвера. Для краткости в дальнейшем будем называть его просто - «Агент». Агент является моделезависимой программой и разрабатывается с учетом конкретной Операционной системы. Для ОС Windows разработана простейшая программа, исполняемая из прикладного уровня.
Если гипердрайвер полностью работоспособен в любой момент работы ОС, включая процедуры загрузки, выгрузки операционной системы, то агент работоспособен только в рабочем режиме ОС, для регистрации событий которые происходят в прочее время, используется система дампирования контролируемых событий, которые можно в последующем просмотреть через агент.
Инициатор Гипердрайвера (файл Red_Pill.exe), запускается из реального режима и является обычным исполняемым файлом для старушки DOS, внутри него инкапсулирован код гипердрайвера. Данная версия гипердрайвера использует систему виртуализации в процессорах AMD (технология AMD-V), виртуализация от Intel (технология Intel VT) не поддерживается.
Внимание: запуск данной программы на процессорах Intel приведет к зависанию ОС!
Инициатор гипердрайвера переводит процессоры в виртуальный режим, а последний из них, изолирует от вычислительной установки. Последний (по номеру APIC) процессор используется исключительно для скоростного сканирования оперативной памяти внутри гипердрайвера.
После развертывания гипердрайвера, уже находясь в виртуальном режиме, инициатор выдает прерывания перезагрузки (int 19h) и дальнейшее зависит от БИОС вашего компьютера.
Если БИОС правильно написан, тогда система должна начать загрузку со следующего в ВООТ списке загрузочного устройства, в противном случае Вам придется либо поменять материнскую плату, либо пошевелить мозгами, обходя эту загвоздку. Универсальным методом будет разбиение винчестера на два логических раздела,- DOS, OS и использование мультизагрузчика.
Загрузка ОС происходит уже под контролем гипердрайвера в виртуальном режиме работы процессора. Операционная система может быть абсолютно любая, лиш-бы она была 32-битная, все остальное гипердрайверу - «по барабану».
После загрузки OS Windows нужно запустить гиперагент (файл Free_Eye.exe), которая организует интерфейс между гипердрайвером и пользователем системы. Эта программа выполняется на прикладном уровне и может работать в любой современной ОС Windows.
Данная программа может выполнять следующие функции:
действовать как редактор оперативной памяти, редактор памяти ввода/вывода (в адресном пространстве памяти), просматривать область БИОС.
выполнять дампирование в файл заданных областей адресного пространства.
быстро выполнять сложные поисковые операции в памяти, используя для этого специально зарезервированный процессор в гипердрайвере.
сохранять в дампе события, связанные с выполнением команды CPUID.
включать/выключать режим подстановок в блоках параметров, получаемых в результате выполнения команды CPUID.
После запуска программы весь её функционал и пользовательский интерфейс должен (я надеюсь) быть интуитивно понятен, а если это не так, то есть контекстные подсказки.
В данной версии гипердрайвера функция эмуляции команды CPUID реализована не случайно, поясню суть. На сайте IXBT.COM появилась статья "VIA Nano как инструмент для исследователя: дают ли эффект нечестные методы конкурентной борьбы?", где была попытка разобраться с моделезависимостью программных продуктов. Авторы использовали не лучший тестовый инструмент, и поскольку тема моделезависимости для меня тоже актуальна, то возникло желание поучаствовать в этом процессе и помочь инструментарием в дальнейших изысканиях, благо возможность такая у меня есть.
Для создания статических структур данных используемых в подстановках осуществляемых гипердрайвером используются специальные файлы с расширением .хар.
Такой файл загружается инициатором гипердрайвера и используется в частности для подстановок при эмуляции команды CPUID. Для создания такого «.хар» файла имеется программка CPUIDXAP.exe, надеюсь Вы догадались, что ее имя происходит от старинного русского слова «хапнуть», что полностью отражает сущность выполняемой с ее помощью работы. Программа выполняется из ДОС, и создает хар-файл в корневой директории диска С:, этот файл можно отредактировать в бинарном редакторе по своему усмотрению перед его загрузкой в гипердрайвер.
Структура файла состоит из двух последовательных блоков по 32 записи из 16 байт, первые 32 записи получены для результатов команды CPUID при ЕАХ=00000_00ххh, а второй блок получен при выполнении команды CPUID при ЕАХ=08000_00ххh.
После запуска агента можно редактировать «хар» область подстановок непосредственно в его редакторе, запускать с разными значениями подстановок исследуемые программы и регистрировать в дампе события выполнения команды CPUID.
Гипердрайвер грузит ОС с выключенным режимом подстановок в команде CPUID, включение режима подстановок происходит из агента (меню ДАМП).
Для связи между программными объектами системы используется универсальный механизм вызова. Универсальность метода объясняется его работоспособностью как в системе виртуализации AMD, так и в системе Intel. Кроме этого, это еще и уникальный по своей природе метод, поскольку только с его помощью можно быстро вызвать из пользовательского уровня гипердрайвер.
Для организации интерфейса используется машинная команда PAUSE – это очень специфическая команда, поскольку с одной стороны она относится к классу системных (меняет состояние процессора), но с другой стороны может выполняться на третьем кольце безопасности (пользовательский уровень) и, кроме того, не требует эмуляции.
Интерфейс получается несколько ущербным, поскольку инициатором обмена информацией всегда является агент, а ответ на запрос выдает гипердрайвер. В этом интерфейсе гипердрайвер инициатором обмена данными быть не может.
Данная программа является демонстрационной, а потому имеет рад ограничений; она не работает с 64битными ОС, не работает на процессорах Intel, не может работать с адресами большими 4 ГБ, длина строки поиска не может быть больше 8 байт. Больше в ней никаких ограничений нет.
Перспективы мирного использования Гипердрайверов
Гипердрайвер - это средство оперативного и тотального контроля за любым аппаратным и программным ресурсом вычислительной системы. Это свойство определяет область его основного применения - регистрацию интересующих программных и аппаратных событий, а также эмуляция несуществующего оборудования.
Особо нужно остановится на возможности гипердрайвера контролировать системы, которые сейчас невозможно проконтролировать в полном объеме – это, как ни странно, БИОС и режимы системного менеджмента (SM mode), процедуры загрузки, выгрузки, сна операционной системы.
Программные комплексы ядра гипервизоров от известных производителей также могут подвергаться исследованию и контролю с помощью гипердрайвера, поскольку не представляет сложности пропустить гипервизор любой известной системы виртуализации под управлением ранее запущенного гипердрайвера.
Виртуализация системы виртуализации – это реальная технология уже отработанная и реально существующая, возьмите хотя бы статьи Рутковской по этому поводу. Единственная проблема таких эмуляций – это право «первой ночи», кто первый сел на оборудование виртуализации, тот в состоянии для всех последующих желающих с ней поработать создать соответствующую программно-аппаратную среду. Именно этим обстоятельством объясняется несколько архаичный запуск гипердрайвера из реального режима процессора, более того он может с легкостью прописываться в любой БИОС сразу после инициализации ОП вычислительной системы.
У гипердрайвера, кроме всего прочего, есть уникальные возможности для активного противостояния вирусным атакам, поскольку любой сценарий такой атаки может быть проконтролирован гипердрайвером и заблокирован еще до активации самого вируса.
К примеру – атака с использованием переполнения локальных переменных и перезаписью этими данными точек возврата из процедур (ROP-атака) легко обнаруживается, если поставить на контроль записи в гипердрайвере адресов стека, выделенных для хранения точек возврата.
Любая другая атака, имеющая известный сценарий, также может быть проконтролирована в гипердрайвере в режиме «ONLINE». А для стендовых испытаний с применением фаззинг (Fuzzing ) программ возможно превентивное исследование кода на наличие уязвимостей.
Послесловие
Виртуальное ядро описываемого гипердрайвера разработано в 2007 году и к настоящему времени безнадежно устарело, однако и в таком убогом виде наглядно демонстрирует потенциал технологии.
Инициатор написан на старом добром Паскале для ДОС, а сам гипердрайвер подлинкован к нему из объектного модуля скомпилированного на Масме.
Желающим получить исходный текст «движка» этого гипердрайвера, достаточно запустить дизассемблер. В результате он получит ассемблерный текст, полностью совпадающий с исходными, единственное неудобство которого в отсутствии комментариев.
Собственно про демонстрационную программу на этом все.., теперь о грустном.
По роду своей основной работы приходится частенько сталкиваться с творчеством безвестных гениев, которые эксплуатируют в своих отнюдь не бескорыстных целях данную технологию, причем, все указывает на то, что они с восточных окраин Азиатского субконтинента. В основном эти творения беззаботно себя чувствуют на платформах, основанных на чипах фирмы Интел. Если вы подумали, что речь идет о Хакерах, то Вы ошиблись, все гораздо печальнее.
Хакеры последнее время превратились из «крутых программистов» в обычных «продвинутых пользователей», технологии аппаратной виртуализации им просто «не по зубам».
Приведенный выше пример использования технологии аппаратной виртуализации в боевых целях неприменим, поскольку легко обнаруживается при размещении его программного кода на дисках, но он обретает фатальную мощь, если подобный гипердрайвер разместить в БИОС и навесить на него функций из арсенала шпионских технологий.
Универсальные способы размещения дополнительных программных модулей во флеш-памяти БИОС уже давно отработаны и используются даже в легальных коммерческих продуктах типа Computrace, LoJack фирмы Absolute Software. Описание этой технологии бродит по Сети уже с начала 2007 года. Имеется даже русскоязычная статья «BIOS-ный троян от Absolute Software» на сайте Rom.by, с ее детальным описанием.
Размер боевого кода гипердрайвера позволяет прописываться в БИОС безболезненно, при этом он может быть обнаружен только на внешнем программаторе, в большинстве случаев только после выпаивания микросхемы ФЛЕШ-памяти из материнской платы.
И даже этот «ломовой» метод будет работать, только если в системе физически отсутствует ТРМ модуль (программно он может быть отключен,- в России это обязательное условие ввоза оборудования).
На современных серверных платформ Intel, используется три отдельных микросхемы флеш-памяти на своих выделенных SPI интерфейсах и присутствует аппаратура шифрования их содержимого. Обнаружить в них программный код гипердрайвера даже после выпаивания микросхемы флеш-памяти абсолютно невозможно без применения криптографических методов.
В заключении, для тех кто заинтересовался тематикой статьи, расскажу о дальнейших планах по выводу проблем аппаратной виртуализации на публичное обсуждение.
В ближайшее время выложу файлы и статью по проблеме ТРМ модулей, казалось бы, какое отношение имеет тема криптографических средств к теме виртуализации? – Для посвященных связь очевидна, но для большинства эта тема будет абсолютно неизвестной, «теневой» областью технологий виртуализации.
RSS
