Атака на ядро в 64-битных системах
Воспользовавшись появлением новых процессорных архитектур x86-64 (AMD) и IA64 (Intel), Microsoft перенесла на них свои системы: XP, висту, Server2003 и Server Longhorn, провозгласив новую политику модификации ядра — то есть, никакой модификации. Действуйте только через легальные средства или до свидания! В добавок к этому, Microsoft заблокировала загрузку драйверов без цифровой подписи, пообещав, что никакой неавторизованный код не сможет проникнуть на уровень ядра. Типа, никаких червей и rootkit'ов отныне не будет, спите спокойно! (Более подробно об этом рассказывают следующие официальные документы: http://download.microsoft.com/download/c/2/9/c2935f83-1a10-4e4a-a137-c1db829637f5/windowsvistasecuritywp.doc, http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/KMCS_Walkthrough.doc,
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/kernel-en.doc и др.).
Какая трогательная забота о пользователях! И какое пренебрежительное отношение к разработчикам! Microsoft делает вид, что проблемы обратной совместимости для 64-битных систем не существует в природе, как не существует готовых программ для них. Это неправда. Большинство программ (в том числе и драйверов!) переносятся путем простой перекомпиляции с легкой ретушью, учитывающей специфику 64-битных архитектур.
Естественно, чем глубже вгрызается драйвер в 32-битное ядро, тем сложнее его отдирать, так что переход на 64-битные системы затянется надолго, а некоторые системные утилиты придется переписывать с чистого листа. Самое обидное, что ни вирусов, ни rootkit'ов это никак не коснется. Механизм обхода цифровой подписи путем модификации файла подкачки на секторном уровне был предложен Жанной Рутковской еще до появления висты на прилавках и заткнуть его Microsoft не в силах. Но даже если ей это удастся, в системе полно драйверов от сторонних разработчиков, позволяющих атакующему делать с ядром все что угодно, плюс дыры самой системы. Наконец, ничего не мешает написать драйвер, отключающий проверку цифровой подписи, и подписать его, воспользовавшись поддельным удостоверениями личности.
Конечно, это большой геморрой и вообще незаконно, но мы же не о законности говорим, а рассматриваем степень (не)защищенности.
Осознавая все это, Microsoft внедрила в свои 64-битные системы (XP, виста, Server 2003 SP1, Server Longhorn) специальный механизм, контролирующий целость ядра и титулованный гордым званием Patch-Guard. Стражник, значит. Между прочим, не претерпевшим никаких значительных изменений со времен Server 2003 S1, где он, впервые, собственно говоря, и появился. Как говорил пра-пра-пра-пра-дедушка Билла Гейтса "полковник Кольт уравнял людей в правах" и Patch-Guard, обладающий теми же самыми привилегиями, что и зловредные драйвера, имеет все шансы быть пропатченным прежде, чем успеет сказать "мяу".
Подробное описание внутреннего устройства Patch-Guard'а можно найти в статье "Bypassing PatchGuard on Windows x64" от skape и Skywing (на самом деле, в операции по трепанации этой твари было задействовано гораздо больше людей, упомянутых в статье): http://uninformed.org/index.cgi?v=3&a=3&t=sumry. Так же не помешает ознакомится с официальными документами от самой Microsoft: www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx и www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx.
Рисунок 2 они первыми взлома Patch-Guard
Patch-Guard инициализируются _только_ в отсутствии системного отладчика, подключающегося при загрузке (или его имитации в виде "затычки"), в противном случае отладчик не смог бы устанавливать программные точки останова (представляющие собой однобайтовую машинную команду CCh) и делать массу других жизненно важных вещей.
Будучи инициализированным, Patch-Guard в случайные промежутки времени (приблизительно один раз в 5-10 минут) запускает процедуру проверки целостности ядра, наводящую в системе настоящий шмон. Текущие версии создают копии всех критических структур данных и подсчитывают контрольные суммы NTOSKRNL.EXE (ядро), HAL.DLL (библиотека абстрагирования от оборудования) и NDIS.SYS (один из самых низкоуровневых сетевых драйверов).
Почему Patch- Guard работает по принципу обходчика а-la "в Багдаде все спокойно", вместо того, чтобы пресекать всякую попытку модификации в момент ее появления? Некоторые утверждают, что во всем виноват процессор, не предоставляющих таких возможностей. Ну, на самом деле, процессор предоставляет, только парни из Рэйдмонда воспользоваться этим не умеют, во всяком не в той мере, в какой это необходимо.
Полный список контролируемых элементов приведен ниже (естественно, в последующих версиях висты он может измениться):
q таблица глобальных дескрипторов —GDT;
q таблица дескрипторов прерываний — IDT;
q стек ядра, выделенный не ядром, а кем-то еще;
q таблица дескрипторов системных сервисов — SSDT;
q образы следующих системных файлов: NTOSKRNL.EXE, NDIS.SYS, HAL.DLL;
q служебные MSR регистры STAR/LSTAR/CSTAR/SFMASK, отвечающие за syscall'ы;
q [AMD x86-64 предоставляет возможность контроля за образом ядра без расчета CRC]
Контроль целостности системных файлов уже не позволяет перехватывать функции путем внедрения в них начало jump'а на хакерский обработчик, а слежение за SSDT препятствует подмене адресов сервисных функций на хакерские переходники к ним. Так же хакер не может вмешиваться в работу менеджера исключений или воздействовать на внутренние аргументы команды SYSCALL, хранящиеся в MSR-регистрах.
Рисунок 3 MSR регистры, обеспечивающие работу машинной команды syscall на x86-64
Вот с таким противникам нам придется сразится. Но так ли он страшен, как кажется?! Чтобы не пересказывать своими словами статью "Bypassing PatchGuard on Windows x64" (чего лишний раз повторяться?), авторы который раздербанили Patch-Guard в пух и прах, мыщхъ сосредоточится на том, чего в этой статье не было.
Рисунок 4 а первый взгляд Patch-Guard кажется неприступным…
Рисунок 5 …но на самом деле его очень легко одолеть (пускай даже придется побуреть и разметать кал от натуги)
