Stfw.RuЗверский взлом Windows Vista
Совершенные руткиты готовы атаковать новую винду Крис Касперски
🕛 28.08.2008, 16:21
Совершенствование stealth-технологий в конечном счете (в середине 2006 года) привело к созданию rootkit'ов принципиально нового типа, которых практически невозможно обнаружить, а тем более остановить. Стоит только компьютеру «проглотить» Голубую пилюлю, как операционная система погружается в виртуальный мир, полностью контролируемый rootkit'ом. Прежний, реальный, мир перестает существовать, и, чтобы увидеть его, необходимо «проглотить» Красную пилюлю, над созданием которой бьются лучшие хакерские умы, но... пока не слишком успешно.Введение
Не успела Windows Vista поступить в продажу, как была зверки взломана польской пани Жанной Рутковской (Joanna Rutkowska). На конференции SyScan в Сингапуре 21 июля она продемонстрировала результат своего взлома - руткит нового поколения, который практически невозможно обнаружить, а тем более взломать.Реакция представителей Microsoft оказалась на удивление спокойной. Подумаешь, подломали бету! Никто же и не утверждал, что взломать Висту/Longhorn невозможно! Идет нормальный процесс «обкатки» системы, и чем больше ошибок будет выявлено на стадии бета-тестирования, тем меньше их окажется в финальной версии продукта. Однако Vista RC1, выпущенная двумя месяцами позже, не претерпела никаких изменений и осталась по-прежнему уязвимой. Microsoft проанализировала ситуацию и, вместо того чтобы заткнуть дыру, сделала вид, что никакой дыры нет (смотри выступление одного из сотрудников Microsoft: http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/07/691441.aspx)!
Мол, с правами администратора (а Голубая Пилюля требует их) еще и не такое возможно! А что, собственно говоря, с ними возможно?! Загрузить неподписанный драйвер или каким бы то ни было другим легальным способом проникнуть на уровень ядра? Нельзя, и это доставляет множество проблем как самим администраторам, так и разработчикам. Если бы Microsoft заткнула все лазейки, во имя ее величества Безопасности с этим можно было бы и смириться. А так получается, что нас вынуждают поступиться частью свобод и удобств, предлагая взамен... ничего! Где логика?! Как всегда логика на стороне Microsoft, преуспевшей только в одном - в продвижении своих глюкодромов на рынок.
Голубая Пилюля базируется на двух основных концепциях - обходе цифровой подписи драйверов (обязательной в x86-64-редакциях Windows, начиная с Vista Beta 2 build 5384) и установке гипервизора (hyper-visor), использующего технологии аппаратной виртуализации AMD Pacifica/Intel Vanderpool. Эти технологии позволяют запускать операционную систему на эмуляторе, контролирующем все интересные события. В грубом приближении это можно проиллюстрировать на примере 80836 ЦП, поддерживающего режим «виртуального 8086» (он же V86), который обеспечивает одновременную работу нескольких сессий MS-DOS. А теперь появился режим «виртуального 386+», причем правильно спроектированный гипервизор (также называемый Монитором Виртуальных Машин - Virtual Machine Monitor, VMM) не позволяет гостевой системе определить, исполняется ли она на «живом» процессоре или нет.
Технология обхода цифровой подписи драйверов актуальна только для 64-битных версий Windows (в 32-битных загрузить неподписанный драйвер можно и так), а механизмы аппаратной виртуализации никак не связаны с конкретной осью и замечательно работают на Linux, BSD, Mac OS и т.д. (разумеется, при поддержке со стороны процессора). Любая ось, позволяющая хакеру пробиться на уровень ядра, может быть атакована. Таким образом, Голубая Пилюля состоит из двух компонентов, лишь один из которых по-настоящему «голубой». Он-то и отвечает за погружение операционной системы в виртуальный мир. Другой компонент - независимая «затравка», специально спроектированная для обхода защиты 64-битных версий Windows. Она забрасывает (точнее, сбрасывает) на ядерный уровень любую полезную нагрузку, в роли которой вполне может выступать и обычный rootkit.
Обход цифровой подписи
Механизм обхода цифровой подписи, предложенный Жанной, основан на модификации файла подкачки на секторном уровне (назовем его page file attack). Сама атака состоит из шести этапов:1. Находим в каталоге /WINNT/System32/Drives редко используемый драйвер (например: NULL.SYS), считываем его содержимое и выделяем уникальную последовательность байт (сигнатуру), позволяющую однозначно идентифицировать его. Сигнатура должна находиться в ветке IRP_MJ_DEVICE_CONTROL процедуры DeviceDispatcher (адрес последней легко определить путем дизассемблирования драйвера), причем она не имеет права пересекать границы страницы (в файле подкачки соседние страницы не всегда оказываются рядом друг с другом). То есть должно выполняться условие: (virtual_address_of_signature % 1000h) + sizeof(virtual_address_of_signature) < 1000h.
2. Запускаем программу memory-eater, «съедающую» всю доступную память (например путем вызова API-функции VirtualAlloc) и вынуждающую операционную систему свопиться на диск, вытесняя в том числе и ядерные компоненты. Внимание! Если параметр DisablePagingExecutive, находящийся в следующей ветке реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement, равен 1 (по умолчанию - 0), ядерные компоненты вытесняться не будут! Изменения вступают в силу только после перезагрузки.
3. Открываем устройство \\.\C: (логический диск) или \\.\PHYSICALDRIVE0» (физический диск) API-функцией CreateFile и читаем/пишем на секторном уровне API-функциями ReadFile/WriteFile соответственно. Также можно воспользоваться хорошо документированным интерфейсом SPTI, позволяющим передавать диску SCSI-команды через API-функцию DeviceIoControl, за что отвечает IOCTL-код IOCTL_SCSI_PASS_THROUGH_DIRECT (4D014h). Ось автоматически транслирует команды pseudo-SCSI в native-команды конкретного накопителя (например: IDE HDD). Два недокументированных IOCTL-кода IOCTL_IDE_PASS_THROUGH и SCSIOP_ATA_PASSTHROUGH позволяют передать IDE-накопителям команды native-ATA, что дает над ними неограниченную власть, но ухудшает совместимость (что если у жертвы установлен SCSI-диск?). Все вышеупомянутые интерфейсы требуют администраторских прав, которые не всегда у нас есть. Но ASPI-интерфейс, разработанный компанией Adaptec, не отягощен такими ограничениями! И хотя корректно установленный ASPI-драйвер (кстати говоря, исключенный из штатной поставки Windows много лет назад) дает доступ только к ATAPI-устройствам (таким как CD, DVD), достаточно часто в этот список попадают и жесткие диски, то есть атаку (теоретически) можно реализовать даже без администраторских прав! Если ASPI-драйвер на целевой машине не установлен, rootkit должен либо установить его самостоятельно (кстати, сам драйвер подписан и предоставляется бесплатно), либо поискать другие драйверы, установленные приложениями, работающими с HDD-, CD- или DVD-дисками на низком уровне (дисковые редакторы, копировщики защищенных дисков, программы для прожига CD/DVD). Многие из них позволяют манипулировать жесткими дисками, не требуя прав администратора (подробнее обо всем этом можно прочитать в моей книге «Техника защиты лазерных дисков от копирования», черновая версия которой находится на ftp://nezumi.org.ru).
4. Дожидаемся выгрузки драйвера на диск. Момент выгрузки легко определить эвристическим путем. При исчерпании оперативной памяти система вытеснит часть только что выделенных VirtualAlloc страниц, скачкообразно увеличивая количество доступной физической памяти, объем которой легко установить API-функцией VirtualQuery. Затем начинаем прочесывать диск на секторном уровне в поисках ранее обозначенной сигнатуры драйвера-жертвы.
5. Вычисляем адрес IRP_MJ_DEVICE_CONTROL и записываем поверх него shell-код, отключающий проверку цифровой подписи, что в дальнейшем позволит нам беспрепятственно загружать неподписанные драйверы, либо загружаем весь необходимый код на ядерный уровень самостоятельно.
6. Вызываем API-функцию CreateFile, передавая ей имя хакнутого драйвера (в данном случае NULL.SYS), и... операционная система тут же считывает модифицированные страницы с диска, вызывает IRP_MJ_DEVICE_CONTROL, передавая shell-коду управление. А дальше, как говорится, дело техники!
Успешно осуществив атаку, Жанна (как и положено «белому» хакеру) тут же предложила несколько контрмер. Самое простое, но не самое умное, что может сделать Microsoft, - это заблокировать выгрузку ядерных компонентов на диск. Все необходимые ингредиенты у нее уже есть, достаточно только убрать из реестра ключ DisablePagingExecutive, пожизненно установив его значение - «1». В результате мы потеряем некоторое количество физической памяти (по подсчетам Жанны, около 80 Мб, а по моим подсчетам, даже меньше). К примеру, совокупный объем драйверов на моей машине составляет 30 Мб, и я не думаю, что на висте их размер сильно больше, гарантируя при этом, что никакой драйвер не будет скомпрометирован. Если учесть, что сама виста требует не менее 1 Гб RAM (а для реальной работы понадобится как минимум 2), потеря 30-80 Мб вряд ли покажется значительной. Однако можно пойти другим путем, подсчитывая контрольную сумму каждой страницы перед вытеснением ее на диск и проверяя ее при загрузке. Но поскольку контрольные суммы надо где-то хранить (причем не на диске, а в невытесняемой оперативной памяти), мы не получим никакого выигрыша, впустую расходуя процессорное время. Можно, конечно, шифровать страницы каким-нибудь высокоскоростным криптоалгоритом, храня в памяти всего лишь ключ, случайным образом генерируемый при загрузке, но это уже чересчур. К тому же существует возможность модификации самого файла ядра операционной системы, отключающей все защитные механизмы и тут же инициирующей перезагрузку, против которой предложенные защитные меры бессильны!
Атака на файл подкачки - это действительно прорыв, который Microsoft закроет не скоро (во всяком случае, в Vista RC1 еще не закрыла). Важно отметить, что все вышесказанное относится исключительно к 64-битной версии Windows, поскольку только в ней администраторы лишены прав загружать неподписанные драйверы.
Погружение в виртуальный мир
Механизмы аппаратной виртуализации (известные под кодовым именем Pacifica) реализованы во всех процессорах семейства Athlon 64/Turion 64, выпущенных фирмой AMD после мая 2006 года. Также планируется поддержка виртуализации в Opteron'е. Но это все платформы x86-64, которые нам не сильно интересны, поскольку их рыночная доля крайне мала. AMD не смогла справиться с виртуализацией x86, сославшись на сложность реализации и непригодность этой архитектуры для подобных целей (читай: кишка тонка), а вот Intel смогла, за что ей честь и хвала!Технология с кодовым именем Vanderpool воплощена в процессорах Intel Pentium 4 6x2, Pentium D 9xx, Xeon 7xxx, Core Duo, Core 2 Duo, куда она перекочевала из Itanium'а (IA64), где была известна под именем Silvervale. Теперь во избежание путаницы она объединена с последней в обезличивающую официальную аббревиатуру VT-X (Virtualization Technology X - X-Tехнология Виртуализации). VT-X существенно отличается от Pacific'и, но по сути предоставляет те же самые возможности, а именно: запуск гипервизора, захватывающего контроль над операционной системой и переводящего ее в «гостевой» виртуальный режим, который, с ее точки зрения, ничем не отличается от «реального».
Гипервизор (в случае VT-X называемый Монитором Виртуальных Машин - Virtual Machine Monitor, VMM) передает гостевой операционной системе управление и получает его назад при наступлении определенных «интересных» событий: возбуждении аппаратного/программного прерывания, обращении к служебным регистрам процессора и т.д. Гипервизор не может непосредственно перехватывать API-функции гостевой операционной системы, но способен следить за обращениями к портам ввода-вывода или самостоятельно взаимодействовать с оборудованием в обход оси. Косвенный перехват API-функций осуществляется путем установки аппаратных точек останова на исполнение (которых, увы, всего 4) с последующим пресечением попыток гостевой системы «подсмотреть» истинное содержимое регистров DRx. Подробное описание технологии Pacifica содержится в техническом руководстве «AMD64 Architecture Programmer's Manual Vol. 2: System Programming», доступном на http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf.
В отличие от AMD, Intel не стала валить все в одну большую кучу и выпустила отдельный документ: ftp://download.intel.com/technology/computing/vptech/C97063-002.pdf. И хотя без руководства по системному программированию при написании собственного Монитора Виртуальных Машин все равно не обойтись, его основные положения большинству хакеров уже известны. Конечно, для тех, кто еще не знаком с защищенным режимом, создание Голубой Пилюли окажется настоящим испытанием, но… это уже их проблемы.
Рассмотрим устройство Голубой Пилюли, заточенной Жанной специально под процессоры AMD x86-64 (на процессорах Intel все будет точно так же, только немного по-другому). «Проглотив» Голубую Пилюлю (CALL bluepill), ядро передает управление главной функции rootkit'а (условно обозначенной PROC bluepill), которая создает виртуальную машину. Затем Пилюля подготавливает все необходимые структуры данных и вызывает машинную команду VMRUM (на Intel процессорах это будет VMXON), устанавливающую гипервизор/VMM, который погружает операционную систему в виртуальный мир и «одевает на ее глаза очки». После этого следует перехват всех каналов взаимодействия последней с «внешним миром»: с портами ввода-вывода, служебными регистрами процессора, физической оперативной памятью и т.д. Гипервизор будет «подсовывать» операционной системе только ту информацию, которую ей позволено видеть, надежно скрывая от ее глаз свое присутствие.
Гипервизор/VMM представляет собой достаточно сложную программу, которую не так-то просто написать и еще сложнее отладить, но ведь нам так хочется реализовать свою собственную Голубую Пилюлю, не правда ли? Сама Жанна, кстати, так и не справилась с этой задачей, о чем открыто признается в своем блоге в заметке «The Blue Pill Hype» («Слухи вокруг Голубой Пилюли») на theinvisiblethings.blogspot.com/2006/07/blue-pill-hype.html. Вот фрагмент из этой заметки в переводе: «Все началось со статьи Нарьяна Рьяна из eWeek. Статья вполне адекватная, за исключением одной маленькой детали, вводящей читателей в заблуждение. В статье утверждается, что я уже реализовала «прототип Голубой Пилюли, создающий на 100% не обнаруживаемую мальварь», что неправда. Если бы это было правдой, я бы не стала называть свою реализацию «прототипом», подразумевающим наличие опытного продукта... Прототип Голубой Пилюли, имеющийся у меня в настоящий момент, еще не полностью реализован, но это неважно, поскольку создание виртуальной машины для запуска операционной системы и реализация всех остальных фич - это всего лишь вопрос следования спецификациям на Pacific'у».
Чтобы приблизить себя к цели на несколько световых лет и не повторять уже сделанное, мы можем «выдрать» ядро из готового эмулятора и слегка доработать его «напильником» для наших хакерских нужд, дописав сравнительно небольшую порцию кода. Естественно, это должен быть эмулятор, распространяющийся в открытых исходных текстах на бесплатной основе. Например, XEN, поддерживающий обе архитектуры (Pacifica и Vanderpool одновременно) и абстрагирующий нас от конкретных аппаратных особенностей, хотя и не избавляющий нас от необходимости реализовывать отдельные версии rootkit'а для x86- и x86-64-платформ. Архив с исходными текстами третьей версии XEN'а (текущей стабильной версии на данный момент) можно слить с http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-3.0-testing-src.tgz, а сам сайт находится по адресу: http://www.cl.cam.ac.uk/Research/SRG/netos/xen.
В частности, ядро, отвечающее за поддержку x86-процессоров Intel, сосредоточено в файле /xen-3.0-testing/xen/include/asm-x86/hvm/vmx/vmx.с.
Красная Пилюля
В «Матрице», чтобы увидеть реальный мир, было достаточно принять красную пилюлю. А как на счет операционной системы? Может ли она каким-нибудь образом определить, что работает под виртуальным эмулятором? Программу, позволяющую обнаружить присутствие эмулятора, обычно называют Красной Пилюлей, и такие пилюли находят самое широкое применение как в хакерской, так и администраторской среде (первые используют их для детектирования VMWare или других программных эмуляторов, вторые - для обнаружения rootkit'ов). С аппаратной виртуализацией все намного сложнее...Первое, что приходит на ум, - попытаться вызвать VMCALL/VMXON, и, если мы находимся под эмулятором (процессор не поддерживает аппаратную виртуализацию, или она отключена в BIOS), вызов проваливается. Написать такую программу - плевое дело. Имея готовый скелет драйвера, это можно сделать меньше чем за минуту, вот только как отличить ситуацию «процессор не поддерживает» от «мы под эмулятором»? Существует лишь один путь - отодрать от кремния радиатор и физически посмотреть на его маркировку, сличив ее с «показаниями» машинной команды CPUID. Эмулятор, если только он не лось, возвратит подложные данные, убеждая нас в том, что поддержка аппаратной виртуализации на этом процессоре отсутствует. Но какой процент пользователей отважится на столь радикальный шаг?! Отодрать радиатор они, положим, отдерут, но вот приставят ли обратно :)? Тем более что путем некоторых ухищрений гипервизор может эмулировать выполнение команд VMCALL/VMXON, реализуя вложенную виртуализацию. Это как бы один виртуальный мир в другом, и уровень вложенности, в принципе, неограничен. Естественно, с каждой «проглоченной» Голубой Пилюлей мы будем терять производительность. Уже в первом виртуальном мире быстродействие операционной системы сокращается на десятки процентов (никто никогда и не утверждал, что аппаратная виртуализация дает 100% КПД).
Стоп! Стоп! Стоп! Производительность! Вот она, нить Ариадны! Замеряя время выполнения машинных инструкций, перехваченных гипервизором (и в первую очередь инструкции RDMSR EFER, читающей регистр EFER, 12-бит которого указывает на присутствие гипервизора), мы легко заметим, что в виртуальном мире они выполняются намного дольше, чем в реальном.
Вся проблема в том, что нам нечем измерять время их исполнения. Команда RDTSC (читающая значение регистра, увеличивающегося с каждым тактом процессора) отпадает сразу и однозначно, поскольку контролируется гипервизором, который корректирует ее показания так, как будто бы мы находится в реальном мире. Для упрощения решения этой задачи процессор поддерживает специальную «калибровочную» переменную VMCB.TSC_OFFSET, указывающую, сколько экстратактов ему следует вычитать при выполнении команды RDTSC. Так что корректировка показаний RDTSC происходит автоматически даже без вмешательства эмулятора.
Теоретически можно воспользоваться часами реального времени, атомными часами, доступными через Сеть, или даже внешним по отношению к компьютеру хронометром. Гипервизор способен «подкручивать» часы реального времени (правда, при этом они начнут отставать, что пользователь сможет заметить), перехватывать и корректировать сетевой трафик, если в нем присутствует атомное время (хм, а не надорвется он это делать?). Но на хронометр, сжимаемый ладонью пользователя, он воздействовать не в состоянии, если, конечно, пользователь сам не находится в виртуальном мире ;-).
Отличная Красная Пилюля получилась, нечего сказать... «Сейчас будет запущена тестовая программа. Пожалуйста, воспользуйтесь своими электронными часами и определите время ее выполнения. Для уменьшения погрешности продолжительность теста составит около 60 секунд». Ну и кто это будет делать? А с чем сравнивать полученные показания мы подумали? Чтобы обнаружить присутствие гипервизора, необходимо иметь эталонный компьютер с таким же точно процессором, погруженным в термостат, поскольку многие процессоры меняют свою тактовую частоту в зависимости от температуры. Но даже в этом случае гипервизор может распознать команду RDMSR EFER, выполняющуюся в цикле, и пропускать некоторые итерации для достижения идентичного времени выполнения.
Некоторые горячие головы предлагают читать содержимое оперативной памяти через DMA, записывая ее на диск, а потом искать в этой куче следы присутствия гипервизора. Ну, во-первых, они очень сильно переоценивают возможности контроллеров DMA по чтению памяти, во-вторых, гипервизор, контролируя обращения к портам ввода-вывода, легко это отследит, а в-третьих, даже если и не отследит, что искать-то? При условии, что сигнатура Голубой Пилюли неизвестна (или она построена на полиморфной основе), мы ни за что не обнаружим ее!