Вторжение в ядро Висты, спроси меня - как?

Автор: (c)Крис Касперски ака мыщъх

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

Введение

Чем отличается Виста от XP? Если отбросить интерфейс, разработанный для блондинок и прочих пионерок, мы получим ядро, доставшееся в наследство от Windows Server 2003 и претерпевшее ряд существенных изменений, вылившихся в принципиально новую драйверную модель (и потому драйвер, написанный с учетом особенностей Висты, под XP работать просто не будет и разработчики к своей огромной "радости" вынуждены поддерживать сразу две независимых ветки драйверов - для Висты и XP, они-то наивные думали, что этот кошмар кончился еще со смертью 9x).

Но в контексте безопасности (о котором мы, собственно, и говорим), изменения 32-разрядной версии Висты настолько невелики, что о них не стоит даже и говорить. Ну, закрыли доступ к псевдоустройству \Device\PhysicalMemory с прикладного уровня - так это еще в Server 2003 SP1 было сделано. Толку с того? \Device\PhysicalMemory редко использовался хакерами и в основном пострадали легальные программисты.

Заблокировали прямую секторную запись на неразмонтированный том. И между прочим - правильно сделали. Кроме Рутковской ее все равно никто не использовал. Но даже сейчас остается куча путей для обхода блокировки, которые Microsoft не закрыла и судя по всему, закрывать и не собирается, так что хакеры продолжают пребывать в нирване, собираясь нанести очередную серию атак. Вот только покурят сначала.

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

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

32-битная версия Висты не требует обязательной цифровой подписи

Рисунок 1. 32-битная версия Висты не требует обязательной цифровой подписи для драйверов.

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

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

32-битная версия Висты не проверяет целостность ядра

Рисунок 2. 32-битная версия Висты не проверяет целостность ядра (во всяком случае - пока).

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

Что в имени твоем?

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

Основные "хакерские" отличия Висты от XP

Немного истории или блокировка записи на диск как ответ MS Рутковской

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

Жанна Рутковская
Жанна Рутковская

Рисунок 3. Жанна Рутковская демонстрирует "Голубую Пилюлю" на конференции Black Hat.

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

Кушаем память

Рисунок 4. "Кушаем" память, чтобы вытеснить ядро на диск.

Поначалу Microsoft послала Жанну с ее "атакой" в /dev/nul, поскольку с правами администратора еще не такое можно сделать, однако Жанна продолжала упорствовать, раздавая интервью и давая советы разработчикам ядра, что им глупым делать (см. блог Жанны на http://theinvisiblethings.blogspot.com/2006/10/vista-rc2-vs-pagefile-attack-and-some.html).

Конкретно, она предлагала следующее:

  1. Заблокировать посекторный доступ к диску из пользовательского режима;
  2. Зашифровать файл подкачки или хотя бы проверять его целостность, как на NetBSD;
  3. Запретить выгрузку ядерных компонентов на диск, пожертвовав ~80Мб памяти;

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

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

Под Vista RC2

Рисунок 5. Под Vista RC2 "Голубая Пилюля" Рутковской уже не работает, выдавая сообщение об ошибке "Write File failed (err = 0x5)".

На самом деле 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

Рисунок 6. RawDisk - сторонний драйвер для Висты, обеспечивающий возможность прямой записи на любой диск, включая системный.

Наконец, можно не париться, а воспользоваться нормальным драйвером RawDisk от компании ELDOS (http://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: http://www.symantec.com/avcenter/reference/Windows_Vista_Kernel_Mode_Security.pdf

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

Отсюда можно (было) бесплатно скачать драйвер для x86-64 Висты

Рисунок 7. Отсюда можно (было) бесплатно скачать драйвер для x86-64 Висты, позволяющий загружать неподписанные драйвера.

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

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

"Как бы" потому что остается без ответа вопрос, поставленный лабораторий Linchpin Labs: "A signed file uniquely identifies the company that developed that file, but when companies can be created and registered in jurisdictions known for protecting the privacy of company founders and directors, you have to ask what does driver signing actually represent? Signed drivers can be signed by an arbitrary legally registered company. Absent any control over what the driver actually is or does, this provides no real additional security, other than removing author anonymity" ("Подписанный файл однозначно идентифицирует компанию, разработавшую его, но когда компании создаются и регистрируются таким образом, что истинные основатели и директоры фирмы остаются в тени, спрашивается: что же в действительности представляет собой цифровая подпись? Отсутствие реального контроля за поведением драйвера не обеспечивает никакой реальной безопасности, за исключением невозможности распространения анонимных драйверов").

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

Основные дефекты цифровой подписи

Пурпурная пилюля и другое в ассортименте

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

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

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

Пурпурная Пилюля

Рисунок 8. Пурпурная Пилюля от Alex Ionescu.

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

Дырявый драйвер от AMD/ATI

Рисунок 9. Дырявый драйвер от AMD/ATI.

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

Пурпурная Пилюля в открытом доступе

Рисунок 10. Пурпурная Пилюля в открытом доступе.

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

Все что нам нужно - это отладчик и дизассемблер. Список наиболее "соблазнительных" драйверов с краткими пояснениями приведен ниже (примечание: для упрощения анализа рекомендуется загрузить отладочные символы с серверов Microsoft, которые распространяются бесплатно):

Основные вектора атаки на драйвера

Заключение

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

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

Логотип Висты

Рисунок 11. Логотип Висты.

Полезные ссылки