Вторжение в ядро Висты

Все о внутренних атаках в OS Vista Крис Касперски

🕛 28.08.2008, 14:08

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

Чем отличается Виста от XP? Если отбросить интерфейс, разработанный для блондинок, мы получим ядро, доставшееся в наследство от Windows Server 2003 и претерпевшее ряд существенных изменений, вылившихся в принципиально новую драйверную модель (и потому драйвер, написанный с учетом особенностей Висты, под XP работать просто не будет). Но в контексте безопасности (о котором мы, собственно, и говорим) изменения 32-разрядной версии Висты настолько невелики, что на них не стоит даже и отвлекаться. Ну закрыли доступ к псевдоустройству \Device\PhysicalMemory с прикладного уровня - так это еще в Server 2003 SP1 было сделано. Толку с того? \Device\PhysicalMemory редко использовался хакерами, и в основном пострадали легальные программисты. Заблокировали прямую секторную запись на неразмонированный том. И, между прочим, правильно сделали. Кроме Рутковской, ее все равно никто не использовал. Но даже сейчас остается куча путей для обхода блокировки, которые Microsoft не закрыла и, судя по всему, закрывать не собирается, так что хакеры продолжают пребывать в нирване, собираясь нанести очередную серию атак.

Другое дело - x86-64 версия Висты, ставящая всех разработчиков раком. Она снабжена нереально крутыми защитными механизмами, такими, что, почитав мануал, можно понять: крыша у Microsoft сорвана и назад уже не воротится.

Первое и главное - все драйверы в обязательном порядке должны быть снабжены цифровой подписью, и загрузить драйвер, даже обладая правами администратора, у нас не получится! К 32-битной версии Висты (и к 64-битной версии под Itanium) это не относится, и мы по-прежнему можем загружать неподписанные драйверы функцией ZwLoadDriver или любым другим способом.

Второе - x86-64 версия Висты препятствует модификации ядра, предотвращая сплайсинг (то есть перехват системных вызовов), подмену обработчиков в таблице прерываний и т.д. За это отвечает механизм PatchGuard, который хакеры взломали еще до того, как Виста попала на прилавок. Атаки на ядро все еще продолжаются, а вот легальные разработчики сильно страдают, поскольку без модификации ядра невозможно написать ни нормальный антивирус, ни брандмауэр, ни другой продукт подобного типа.

К счастью, огромное количество драйверов, написанных под W2K/XP, модифицирует ядро в целях производственной необходимости, и по соображениям обратной совместимости x86-версия Висты (и 64-битная Виста под Itanium) никак не препятствует модификации ядра, хоть Microsoft и грозится, что скоро все будет не так. Но это навряд ли, поскольку операционная система, на которой не запускаются любимые (и к тому же легально купленные) приложения, идет в топку.

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

Экспериментируя с бета-версией Висты, Жанна Рутковская предложила не слишком изящный, но все-таки пригодный для «промышленных» атак метод обхода цифровой подписи драйверов, который вошел в состав знаменитой «Голубой пилюли» и был продемонстрирован ею на хакерских конференциях SyScan (Сингапур) и BlackHat (Лас-Вегас) жарким летом 2006 года.

Полный текст презентации лежит на http://invisiblethings.org/papers/joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt, а в двух словах суть идеи можно обрисовать так: если «скушать» всю доступную память (например, при помощи функции VirtuallAlloc), то ядро (в конфигурации по умолчанию!) начнет вытеснять драйверы на диск в файл подкачки. До этого файла можно дотянуться, открыв диск как логическое устройство функцией CreateFile (требует прав администратора) и модифицировав выгруженные драйверы через WriteFile, внедрив в них shell-код, отключающий проверку цифровой подписи. Например, после этого вредоносный драйвер может быть загружен обычный путем, то есть через ZwLoadDriver.

Поначалу Microsoft послала Жанну с ее «атакой» в /dev/nul, поскольку с правами администратора еще не такое можно сделать. Однако Жанна продолжала упорствовать, раздавая интервью и советуя разработчикам ядра, что им, глупым, делать. Конкретно, она предлагала следующее:
1. заблокировать посекторный доступ к диску из пользовательского режима; 2. зашифровать файл подкачки или хотя бы проверять его целостность, как на NetBSD; 3. запретить выгрузку ядерных компонентов на диск, пожертвовав ~80 Мб памяти.

Кстати говоря, последний механизм уже реализован в Висте, кажется, еще со времен NT 4.0, и переписывать ядро не нужно. Достаточно запустить редактор реестра, зайти в ветку HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement, найти там параметр DisablePagingExecutive (по умолчанию равный нулю) и установить его в единицу. Вот и все! После перезагрузки мы получим невыгружаемое ядро. Кстати говоря, это полезно сделать уже хотя бы для того, чтобы избежать проблем с некоторыми бажными драйверами, разработчики которых забыли, что на уровне обработки прерываний диспетчер подкачки не работает. И если драйвер попытается вызвать код, выгруженный на диск, система рухнет в голубой экран.

К большому удивлению окружающих, Microsoft пошла по первому пути, заблокировав прямую запись на неразмонтированный дисковый том (а системный том размонтировать нельзя, иначе как потом работать?). Это вызывало шквал негодования в лагере поклонников Рутковской, сочинивших кучу историй, например, о том, как писать утилиты для восстановления ошибочно удаленных файлов.

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

Доказательством того, что Microsoft действительно исправила баг, а вовсе не кинулась в бой с Рутковской, служит тот факт, что открытие дискового устройства функцией CreateFile происходит вполне успешно, а вот функция WriteFile клеит ласты независимо от того, какой сектор она обновляет - принадлежащий или непринадлежащий файлу подкачки. Исключение составляют первые 8 Кб тома, которые соответствуют 16 секторам; в них запись по-прежнему разрешена.

Несистемный том размонтируется в два приема: вызывается CreateFile и передается полученный обработчик функции DeviceIoControl, запущенной с флагом FSCTL_LOCK_VOLUME или FSCTL_DISMOUNT_VOLUME. Однако если даже файл подкачки расположен на другом томе, размонтировать его все равно не удастся. Тупик? Вовсе нет. Существует множество других методов низкоуровневой работы с диском (как документированных, так и нет).

Прежде всего, это интерфейс SPTI (SCSI Pass-Through Interface), присутствующий во всех NT-подобных системах и позволяющий посылать дисковым устройствам SCSI-команды, преобразуемые операционной системой в нативные команды этого устройства, в роли которого может выступать хоть флешка, воткнутая в USB, хоть IDE-винт. Достаточно изучить MSDN - поиск по IOCTL-командам SCSI_PASS_THROUGH, IOCTL_SCSI_PASS_THROUGH и IOCTL_SCSI_PASS_THROUGH_DIRECT выдает много интересного, в том числе и готовые демонстрационные примеры (включенные в DDK).

Эксперимент показывает, что низкоуровневая запись на системный том через SPTI до сих пор не заблокирована (хоть и требует прав администратора).

Еще существует большое количество недокументированных IOCTL-кодов. Например, следующие команды предназначены для прямой работы с IDE-дисками: SCSIOP_ATA_PASSTHROUGH/IOCTL_IDE_PASS_THROUGH, и они также не заблокированы (во всяком случае, пока).

Кроме того, хочется вспомнить о ASPI-драйвере от компании Adaptec, через который работают многие программы, пишущие или копирующие CD/DVD. Это очень глючный драйвер, и при определенных обстоятельствах он дает прямой доступ не только к оптическим приводам, но и к жестким дискам, причем без прав администратора. Впрочем, совсем не факт, что он вообще заработает.

Наконец, можно не париться, а воспользоваться нормальным драйвером RawDisk от компании ELDOS (www.eldos.com/rawdisk), позволяющим писать куда угодно в любой версии Висты. Естественно, если мы точим вирус, а не утилиту для восстановления ошибочного удаленных файлов, этот драйвер придется всюду таскать за собой и к тому же платить за него деньги, поскольку он не бесплатен.
Подпись драйверов

Механизм подписи драйверов, реализованный компанией Microsoft еще в Windows 2000, изначально не предназначался для защиты системы от вторжения и просто информировал администратора о потенциальных проблемах, предотвращая установку драйверов, написанных мелкими фирмами, даже не позаботившимися о получении подписи.

В x86-64 версиях Висты подпись драйверов стала обязательной. Ну и что с того? Механизм подписи драйверов есть, а вот процедуры отзыва подписи нет. Представим себе, что сотрудник некоторой компании (занимающейся разработкой драйверов) крадет и выкладывает в открытый доступ секретный ключ, после чего драйверы может подписывать кто угодно и Microsoft ничего не может сделать.

Антивирусная пародия с гордым названием Defender (если только она не выключена пользователем за ненадобностью) получает из Сети свежие сигнатуры и потому потенциально способна пресечь загрузку драйверов, подписанных украденной цифровой подписью. Однако это воздействует только на драйверы, загружаемые после WINLOAD.EXE. А первичные драйверы, загружаемые на ранней стадии загрузки операционной системы, ни Defender, ни какой-либо другой механизм прищемить не в состоянии. Но что делать с легальными драйверами, подписанными украденной подписью? Если они перестанут работать, система рухнет, что само по себе является нехилой распределенной атакой. Просто крадем секретный ключ крупной компании и выкладываем его в Сеть. Затем фирма получает другой секретный ключ, заново подписывает все ранее выпущенные драйверы, а пользователи их качают.

Но это все ерунда. Дизассемблирование показывает, что проверка цифровой подписи осуществляется всего в двух местах - в файлах NTOSKRNL.EXE и WINLOAD.EXE, которые можно хакнуть прямо на диске. Доступ к этим файлам заблокирован, но мы тоже не лыком шиты! Переименуем файл NTOSKRNL.EXE в NTOSKRNL.HCK (система это разрешает), тут же скопируем его в NTOSKRNL.EXE, который уже и отпатчим. То же самое сделаем и с WINLOAD.EXE. Естественно, для этого придется предварительно усмирить Windows Resource Protection (она же WRP), устанавливающую права доступа к системным файлам в TrustedInstaller, что повыше администратора будет. Однако весь фокус в том, что, обладая правами администратора, можно заполучить и TrustedInstaller. Подробнее о том, как это сделать, рассказывается в отчете корпорации Symantec: www.symantec.com/avcenter/reference/Windows_Vista_Kernel_Mode_Security.pdf.

А теперь самое интересное! Лаборатория Linchpin Labs (занимающаяся разработкой системных утилит для Windows) совершила первую реальную атаку на Висту, доказав полную практическую бесполезность процедуры цифровой подписи. Зарегистрировав «левую» фирму, она получила секретный ключ, которым подписала драйвер Atsiv, позволяющий загружать неподписанные драйверы. И не просто загружать, а еще и скрывать их присутствие в системе, что достигается путем исключения драйвера из списка PsLoadedModuleslist. То есть Atsiv фактически представляет собой самый настоящий rootkit, образующий огромную дыру в безопасности. Сам-то он подписан, а вот загружаемые им драйверы - нет.

Получение секретного ключа - чисто формальная процедура, и «нотариально» заверить драйвер - не проблема. Лабораторию Linchpin Labs вообще сильно удивило, насколько просто делаются такие вещи. Но ведь иначе и быть не может! Драйверы создаются тысячами фирм, и если каждую фирму подвергать строгой проверке на предмет ее появления и рода деятельности, то Виста сильно рискует остаться без свежих драйверов. Разработчики забьют на нее и пересядут на Linux. А без драйверов Виста никому не нужна. Даже даром.

Реакция Microsoft последовала незамедлительно, и в базе Defender'а появилась новая сигнатура, блокирующая запуск Atsiv'а (при условии, что пользователь держит Defender включенным и своевременно обновляет базу сигнатур), а сам Atsiv внезапно исчез с сайта разработчиков (www.linchpinlabs.com/resources/atsiv/usage-design.htm), хотя до этого он распространялся бесплатно. То есть Microsoft как бы разрулила ситуацию.

«Как бы» - потому что остается без ответа вопрос, поставленный лабораторией Linchpin Labs: «Подписанный файл однозначно идентифицирует компанию, разработавшую его, но когда компании создаются и регистрируются таким образом, что истинные основатели и директоры фирмы остаются в тени, спрашивается: что же в действительности представляет собой цифровая подпись? Отсутствие реального контроля за поведением драйвера не обеспечивает никакой реальной безопасности, за исключением невозможности распространения анонимных драйверов».

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

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

Все очень просто - драйвер работает в режиме ядра и взаимодействует с прикладными программами через те или иные механизмы, зачастую даже не требуя прав администратора. Допустим, в драйвере есть ошибка типа переполнения буфера, позволяющая впрыснуть shell-код в ядерное пространство, повысить уровень своих привилегий или выполнить руками драйвера действие, которое (при нормальном развитии событий) недоступно с прикладного уровня. Учитывая, что многие драйверы создаются вовсе не для управления какими-то устройствами, а как раз для выполнения действий, необходимых разработчику, но недоступных с прикладного уровня (такие драйверы часто называются «псевдодрайверами»), угроза атаки становится вполне реальной. Теоретически разработчик псевдодрайвера должен предотвратить его «неавторизованное» использование посторонними программами, практически же нас окружает куча дырявых драйверов, часть из которых уже работает в Висте.

В середине августа 2007 года Alex Ionescu обнаружил ошибку в видеодрайвере AMD ATI ATIDSMXX.SYS, позволяющую локальному пользователю читать/писать ядерную память с прикладного уровня, впрыскивая shell-код или отключая механизм проверки цифровой подписи. Для демонстрации атаки он написал «Пурпурную пилюлю» (Purple Pill) и выложил ее в открытый доступ 7 августа, а через 78 часов по соображениям хакерской этики убрал, но 39 человек уже успели ее скачать.

Дыра в уязвимом драйвере была оперативно исправлена, но как заставить пользователей скачать обновления? Microsoft, перебрав несколько вариантов, решила ничего не предпринимать, поскольку уязвимые драйверы установлены на миллионах машин, и, если забанить их в Defender'е, пользователи просто завопят и судьба Висты будет предрешена. Кому нужна система, которая в обязательном порядке требует установки обновлений, принудительно переводя монитор в позорный VGA-режим?

Дыра в AMD/ATI-драйвере первая, но уж точно не последняя, и «пилюли» разных цветов будут появляться и дальше, поскольку намного проще и дешевле использовать брешь в чужом драйвере, чем регистрировать «левую» фирму для подписи своего собственного. Естественно, наибольший интерес представляют драйверы, входящие в штатный комплект поставки Висты и работающие с сетевым стеком, позволяя осуществлять не только локальные, но и удаленные атаки.

Все, что нам нужно, - это отладчик и дизассемблер. Список наиболее «соблазнительных» драйверов с краткими пояснениями приведен ниже (примечание: для упрощения анализа рекомендуется загрузить отладочные символы с серверов Microsoft, которые распространяются бесплатно):
* NETIO.SYS - реализует сетевой стек IPv4/IPv6. * HTTP.SYS - обрабатывает HTTP-запросы. * MRXSMB10.SYS - отвечает за поддержку SMB версии 1. * MRXSMB20.SYS - отвечает за поддержку SMB версии 2. * MRXDAV.SYS - обрабатывает WebDAV. * MSRPC.sys - реализует механизм удаленного вызова процедур MS RPC.

Заключение

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

Разумеется, мы рассмотрели лишь некоторые, наиболее интересные атаки на ядро Висты, оставив за кадром огромный пласт материала (включая механизм Patch-Guard, заслуживающий отдельной статьи). Однако какие бы пакеты обновлений ни выходили, хакеры прорвали стратегические рубежи обороны ядра и вышли на оперативный простор. Естественно, Microsoft это дело так не оставит и будет нам всячески противостоять, так что читай журнал «Хакер», чтобы быть в курсе последних событий, которые мы обязуемся освещать.
Что в имени твоем?

В переводе с английского Vista - «перспектива», «перспективы, возможности, виды (на будущее)», что выглядит очень странно в свете решения Microsoft похоронить эту перспективу через два года, заменив ее новой системой. Существует мнение, что Виста окажется чем-то вроде Windows Me - плохо продуманной, сделанной на скорую руку системой, выброшенной на рынок лишь затем, чтобы заполнить образовавшийся вакуум хоть чем-нибудь.
Основные «хакерские» отличия Висты от XP

x86-версия и 64-битная версия под Itanium:
* Заблокирован доступ к псевдоустройству \Device\PhysicalMemory с прикладного уровня. Защита взломана хакером по кличке crazylord. Но вообще это не слишком большая потеря для кодокопателей. * Заблокирован прямой доступ к неразмонированным томам, что обходится через документированный интерфейс SPTI, недокументированные IOCTL-коды SCSIOP_ATA_PASSTHROUGH и IOCTL_IDE_PASS_THROUGH, а также драйверами сторонних производителей: ASPI, RawDisk и др.

x86-64-версия:
* Требование цифровой подписи для всех драйверов. Обходится утилитой Atsiv от Linchpin Labs. * Нет защиты от уязвимых драйверов. * Отсутствует механизм отзыва цифровой подписи для драйверов начального уровня. * Запрет на модификацию ядра, обеспечиваемый механизмом Patch-Guard.

WWW
* Официальный сайт Жанны Рутковской с кучей интересных материалов и ворохом хакерских утилит: http://theinvisiblethings.org. * Официальный блог Жанны Рутковской: http://theinvisiblethings.blogspot.com. * Текст презентации, посвященной «Голубой пилюле»: http://invisiblethings.org/papers/joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt. * Анализ ядра Висты с точки зрения безопасности, выполненный сотрудниками исследовательского центра корпорации Symantec: www.symantec.com/avcenter/reference/Windows_Vista_Kernel_Mode_Security.pdf. * Утилита командной строки, позволяющая загружать неподписанные драйверы: www.linchpinlabs.com/resources/atsiv/usage-design.htm. * Обзорная статья, посвященная проблемам поиска дырявых драйверов: www.piotrbania.com/all/articles/ewdd.pdf.