Пока я сижу здесь и пишу эту статью, на мой межсетевой экран обрушивается множество пакетов, которых я никогда не запрашивал. Почему так? За последние пару лет мы увидели, как интернет превратился в опасное место для непосвященных: черви и вирусы маячат почти повсюду и часто заражают системы без участия пользователя. Эта статья будет посвящена подклассу вредоносного ПО, обычно называемому червями, и представит несколько новых идей, связанных с концепцией сетей червей.

2. Векторы заражения червей

Существующих сегодня червей в основном можно отнести к одной из четырех категорий, обсуждаемых в следующих разделах.

2.1. Почта

Почтовый червь - самый простой тип червя. Его основной способ распространения основан на социальной инженерии. Рассылая большое количество писем с содержимым, которое обманывает людей и/или вызывает их любопытство, он заставляет получателей запускать вложенную программу. После выполнения программа рассылает копии самой себя по электронной почте получателям, найденным в адресной книге жертвы. Обычно этот тип червя быстро останавливают, когда антивирусные компании обновляют свои сигнатурные файлы, а почтовые серверы, использующие эти AV-продукты, начинают отфильтровывать письма червя. В целом пользователи все лучше осознают опасность такого типа вредоносного ПО, и многие уже не запускают вложения, присланные по почте. Тем не менее этот метод заражения все еще остается успешным.

2.2. Браузер

Браузерные черви, в первую очередь работающие против Internet Explorer, используют уязвимости, существующие в веб-браузерах. Обычно происходит следующее: когда пользователь посещает вредоносный сайт, эксплойт заставляет Internet Explorer загрузить и выполнить код. Поскольку в Internet Explorer в любой момент времени существуют широко известные уязвимости, которые еще не исправлены, у плохих парней обычно есть несколько дней или недель на распространение своего кода. Разумеется, скорость заражения сильно зависит от числа посетителей сайта, размещающего эксплойт.

Один подход, применявшийся в прошлом для получения доступа к более широкой "аудитории", заключался в рассылке писем тысячам пользователей с попыткой заставить их посетить вредоносный сайт. Другой подход включал взлом рекламных компаний и изменение их содержимого так, чтобы они раздавали эксплойты и вредоносное ПО на известных сайтах.

2.3. Одноранговые сети

Одноранговый червь похож на почтового: оба полагаются на социальную инженерию. Пользователь, ищущий музыку или фотографии знаменитостей, загружает программу с заманчивым именем. После запуска вредоносный код размещает себя в общей папке однорангового клиента. Свежий антивирус обычно успевает обнаружить такой файл до выполнения.

2.4. Активные

Этот тип червя самый опасный, поскольку вообще не требует никакого взаимодействия с пользователем. Он также требует наивысшего уровня навыков для написания. Активные черви распространяются, сканируя интернет в поиске одного или нескольких типов уязвимостей. Когда уязвимая цель найдена, выполняется попытка эксплуатации, которая при успехе приводит к загрузке червя на атакованный сайт, где распространение может продолжиться в той же форме.

Таких червей обычно сначала замечают по растущему числу хостов, сканирующих интернет, чаще всего по одному порту. Эти черви также обычно эксплуатируют слабости, которые публично известны уже часы, дни, недели или месяцы. Примеры этого типа червей включают Wank worm, Code Red, Sadmind, SQL Slammer, Blaster, Sasser и другие. По мере роста использования межсетевых экранов и NAT-маршрутизаторов, а также распространения антиэксплуатационных техник вроде той, что применена в Windows XP SP2, такие черви будут находить все меньше хостов для заражения. На момент написания этой статьи уже прошло некоторое время с тех пор, как последняя крупная активная волна червя ударила по сети.

Другие активные векторы используют отсутствующие или слабые пароли в общей файловой системе Интернета CIFS, через которую Windows предоставляет сетевые ресурсы, а также IRC, службы мгновенных сообщений, Usenet и почти любой другой протокол обмена данными.

3. Мотивы 3.1. Эго

Внимание СМИ часто является главным мотивом, стоящим за червем. Довольно часто встречается ситуация, когда кодеры подпитывают свое эго, видя сообщения о своем черве на крупных интернет-сайтах, а также в телевизионных новостях и газетах с паническими предупреждениями о новейшей угрозе конца света, которая может обрушить планету и привести к "цифровому Перл-Харбору". Огромное внимание СМИ обычно также означает огромное внимание правоохранительных органов, и на поимку виновника будут направлены большие усилия. Хотя особенно широко открытые публичные WIFI-сети могут сильно затруднить поимку виновника техническими средствами, хвастовство в IRC и, как в случае Sasser, вознаграждения могут быстро привести к задержанию автора червя.

3.2. DDoS

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

3.3. Спам

Здесь в конечном счете тоже речь о деньгах. Зараженные машины используются или злоупотребляются как спам-зомби. Каждая машина отправляет нежелательную почту своего хозяина множеству нежелающих получателей. Владельцы таких систем обычно предлагают свои услуги индустрии спама и таким образом зарабатывают деньги.

3.4. Рекламное ПО

Ещё одна причина — деньги от рекламы. Чем больше пользователей видит объявление, тем выше плата за его показ на заражённых компьютерах. Теоретически целью могли бы быть Linux и macOS, но рекламное ПО почти всегда ориентируется на Windows.

3.5. Взлом

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

Если одна машина уже скомпрометирована, расширить влияние внутри некоторой сети, разумеется, может быть намного проще. Возьмем, например, компанию с жесткой межсетевой защитой. Хакер не может попасть внутрь активным подходом, но замечает, что один из его сайтов, раздающих вредоносное ПО, заразил хост внутри этой сети. Используя connect-back-подход, при котором зараженный узел подключается к атакующему, можно построить туннель через межсетевой экран, позволяющий атакующему достигнуть внутренней сети.

4. Ботнеты

Хотя я уже упоминал DDoS и спам как причины заражения, до сих пор я не затронул инфраструктуру из сотен или тысяч скомпрометированных машин, которую обычно называют ботнетом. После того как червь заразил множество систем, атакующему нужен способ контролировать своих зомби. Чаще всего узлы заставляют подключаться к IRC-серверу и входить в защищенный паролем секретный канал. В зависимости от используемого вредоносного ПО атакующий обычно может отдавать команды одному или всем узлам, находящимся в канале: например, стереть хост с лица сети с помощью DDoS, поискать CD-ключи игр и сбросить их в канал, установить дополнительное ПО на зараженные машины или выполнить множество других операций. Хотя такой подход может быть весьма эффективен, у него есть несколько недостатков.

• IRC передаёт открытый текст. Без SSL-туннеля весь обмен канала виден каждому подключённому узлу. Анализ трафика заражённой системы-приманки раскрывает команды и пароли ботнета, что позволяет его украсть или уничтожить, например перенаправив узлы на IRCD по адресу 127.0.0.1.

• Это единая точка отказа. Что если IRCD упадет, потому что какая-нибудь жертва связалась с администратором IRC-сервера? Кроме того, IRC Op, администратор IRC, может сделать канал недоступным. Если атакующий останется без способа общаться со всеми зомби-хостами, они станут бесполезны.

Эту проблему решает динамический DNS, например <http://www.dyndns.org>. Заражённые узлы обращаются к постоянному имени, которое атакующий в любой момент направляет на новый IRC-сервер. Это повышает надёжность, но не делает IRC безопасным средством управления ботнетом.

Автор Phatbot пытался решить проблему одноранговой связью, встроив код проекта Waste. Но Waste не предоставлял простого обмена криптографическими ключами, поэтому тот же недостаток унаследовал Phatbot. Автору неизвестны подтверждённые случаи использования этой возможности, хотя они могли просто не стать публичными.

Чтобы поддерживать ботнет в рабочем состоянии, нужны надежность, аутентификация, скрытность, шифрование и масштабируемость. Как достичь всех этих целей? Какой базовой функциональности требовал бы идеальный ботнет? Рассмотрим следующие пункты:

• Простой способ быстро отправлять команды всем узлам.

• Невозможность отследить исходный IP-адрес команды.

• Невозможность по перехваченному командному пакету судить, какому узлу он был адресован.

• Схемы аутентификации, гарантирующие, что сетью зомби управляет только уполномоченный персонал.

• Шифрование для сокрытия коммуникации.

• Безопасные механизмы обновления ПО, позволяющие расширять функциональность.

• Изоляция, чтобы один скомпрометированный узел не подвергал опасности всю сеть.

• Надежность, чтобы сеть оставалась работающей, когда большинство ее узлов исчезли.

• Скрытность как на зараженном хосте, так и в сети.

На этом этапе следует различать несвязанные и связанные, или пассивные, ботнеты. Несвязанный означает, что каждый узел сам по себе. Узлы опрашивают некоторый центральный ресурс в поисках информации. Информация может включать команды загрузить обновления ПО, выполнить программу в определенное время или приказ устроить DDoS заданной целевой машине. Связанный ботнет означает, что узлы ничего не делают сами, а ждут командных пакетов. Оба подхода имеют преимущества и недостатки.

Хотя связанный ботнет может реагировать быстрее и может быть более скрытным, учитывая, что он не создает периодические сетевые соединения для поиска команд, он также не будет работать для зараженных узлов, находящихся за межсетевыми экранами. Такие узлы могут иметь возможность добраться до веб-сайта, чтобы искать команды, то есть несвязанный подход для них работал бы, но командные пакеты, как в связанном подходе, до них не дойдут, поскольку межсетевой экран их отфильтрует. Также рассмотрим попытку построить ботнет с помощью следующего Windows-червя. Зараженные Windows-машины обычно принадлежат домашним пользователям с динамическими IP-адресами. Машины конечных пользователей регулярно меняют IP или выключены, потому что владелец на работе или уехал на охотничьи выходные. Удачи в поддержании актуального списка зараженных IP. Поэтому в основном, в зависимости от назначения ботнета, нужно решать, какой подход использовать.

Комбинация обоих может быть лучшей. Узлы могли бы, например, раз в день опрашивать информационный ресурс, где их ждут команды, не требующие немедленного внимания. С другой стороны, если появляется что-то срочное, отправка командных пакетов определенным узлам все еще могла бы быть вариантом. Представьте разновидность несвязанного ботнета. Ни один узел не знает о другом узле и никогда не связывается ни с одним из своих братьев, что идеально достигает нашей цели изоляции. Эти узлы периодически связываются с тем, что автор назвал информационным ресурсом, чтобы получить последние распоряжения. Как мог бы выглядеть такой ресурс?

Желательны следующие свойства:

• Он не должен быть единой точкой отказа, как один хост, удаление которого разрушает всю систему.

• Он должен быть крайне анонимным, то есть подключение к нему не должно выглядеть подозрительной активностью. Напротив, чем больше людей запрашивают у него информацию, тем лучше. Так соединения узлов растворятся в общей массе.

• Система не должна принадлежать хозяину ботнета. В конце концов, анонимность - одна из основных целей ботнета.

• Там должно быть легко публиковать сообщения, чтобы команды ботнету можно было отправлять без труда.

Есть несколько вариантов достижения этих целей. Это может быть:

• Usenet: Сообщения, опубликованные в большой группе новостей, которые содержат стеганографически скрытые и криптографически подписанные команды, достигают всех перечисленных выше целей.

• P2P-сети: Узлы время от времени подключаются к серверу и, как сотни тысяч других людей, ищут определенный термин ("xxx") и находят командные файлы. Размер файла может быть для узлов индикатором того, что конкретный файл может быть командным.

• Сам веб: Этот вариант потенциально был бы медленным, но, разумеется, можно настроить сайт, содержащий команды, и зарегистрировать его в поисковой системе. Чтобы найти этот сайт, зомби подключались бы к поисковой системе и отправляли ключевое слово. Особый заголовок сайта позволил бы определить правильную страницу среди тысяч других совпадений по ключевому слову, не посещая каждую из них.

Используя такие методы, можно было бы администрировать даже крупные ботнеты, не зная IP-адресов узлов. "Расстояние" между владельцем ботнета и дроном ботнета было бы максимально большим, поскольку между ними не было бы прямого соединения. Однако эти подходы также сталкиваются с несколькими проблемами.

Как хозяин ботнета определит число зараженных хостов, которые подняты и работают? Только в случае веб-сайта оценка числа узлов возможна через просмотр журналов доступа, если журналирование вообще включено. В случае подхода с Usenet команда "DDoS Ebay/Yahoo/Amazon/CNN" может достигнуть только последних 5 оставшихся хостов, и атакующий останется лишь со знанием, что по какой-то причине это не сработало. Проблема, однако, в том, что атакующий не будет знать число зомби, которые фактически примут участие в атаке. Та же проблема возникает с типом и расположением зараженных хостов. Некоторые могут быть высокопрофильными, например подключающимися из крупных корпораций, компаний-разработчиков игр или финансовых учреждений. Атакующий мог бы быть заинтересован использовать их для чего-то помимо спама и DDoS, если бы знал о них конкретно.

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

4.1. Связанная сеть

Хотя я назвал этот подход пассивной сетью, поскольку узлы простаивают и ждут, когда к ним придут команды, этот тип ботнета на самом деле довольно активен. Механизмы, описанные сейчас, не будут легко работать, когда большинство узлов имеет динамические IP-адреса. Поэтому они более интересны для узлов, установленных после эксплуатации какого-либо серверного ПО. Конечно, хотя это не решает проблему времени работы, мошенническая учетная запись dyndns всегда может дать динамическому IP статическое имя хоста.

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

Чтобы "успешный" узел, заражающий множество хостов, не стал родителем всех этих хостов, узлы должны отклонять запросы связи от дочерних узлов после подключения определенного числа, скажем 5. Родитель вместо этого может сообщить потенциальному потомку, чтобы тот связался с одним из уже установленных детей. Отслеживая число узлов, связанных с каждым местом в дереве, родитель может даже пытаться поддерживать дерево, иерархически находящееся под ним, хорошо сбалансированным. Так конкретный узел будет знать о своем родителе и до 5 детях, удерживая число других хостов, которые узнает тот, кто скомпрометирует узел, довольно низким, но при этом сохраняя сеть настолько эффективной, насколько возможно. В зависимости от числа узлов во всей сети количество детей, которые могут связываться с родительским узлом, можно легко изменить для лучшего масштабирования сети. Поскольку каждый узел может быть как конечным звеном, так и родительским узлом, каждый хост запускает одну и ту же программу. Нет необходимости в специальных "клиентских" и "серверных" узлах.

Главная проблема дерева — отказ родителя, способный разделить сеть на несколько частей. Для надёжности каждый узел должен знать хотя бы один дополнительный вышестоящий адрес, например адрес «дедушки». Периодический опрос всей сети подтверждает его доступность, и дети используют этот резервный узел при исчезновении родителя.

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

Хотя этот тип ботнета может дать судебному эксперту или человеку со сниффером информацию о других узлах, являющихся частью сети, он также предлагает более быстрые времена реакции и большую гибкость в злоупотреблении сетью по сравнению с предыдущим подходом с несвязанными узлами. Это своего рода компромисс между максимально возможным уровнем анонимности с одной стороны и гибкостью с другой. Это огромный шаг вперед по сравнению со всеми зомби, сидящими сейчас на IRC-серверах, где один канал содержит зомби всего ботнета. Использование криптографии для хранения IP дочерних и родительских узлов, а также хранение этих IP только в RAM дополнительно смягчает проблему.

После того как сеть дронов такого типа создана с несколькими сотнями хостов, появляется множество возможностей ее использования. Чтобы скрыть исходный IP-адрес соединения, можно легко перепрыгивать через несколько узлов сети дронов к целевому хосту. Командный пакет сообщает одному узлу, что нужно привязать порт. Когда он получает соединение на этом порту, ему сообщают приказать второму узлу сделать то же самое, и с этого момента узел 1 пересылает весь трафик узлу 2. Узел 2 делает то же самое и пересылает к узлу 3, затем 4, возможно 5, пока наконец последний узел не подключится к предназначенному IP назначения.

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

Поскольку вручную обновлять несколько сотен или тысяч хостов - утомительная работа, в узлы следует встроить простую систему обновления. В основном есть два возможных способа это реализовать. Команда, распространяемая от узла к узлу по всей сети, могла бы заставить каждый узел заменить себя новой версией, которую он может загрузить с определенного HTTP-адреса. Другой способ - обновить серверное ПО на одном узле, который затем распространит это обновление на все узлы, с которыми связан, детей и родителя, а те сделают то же самое. Криптографические подписи, разумеется, обязательны, чтобы кто-нибудь не заменил все драгоценные узлы на SETI@home.

Vlad902 предложил простой и эффективный способ сделать это. Каждый узел получает жестко прошитый MD5-хэш. Когда кто-то предлагает обновление ПО, узел загружает первые X байтов и проверяет, дают ли они жестко прошитое значение хэша. Если дают, обновление устанавливается. Конечно, судебный эксперт может извлечь хэш из найденного узла. Однако из-за природы криптографических хэшей он не сможет определить, какая последовательность байтов порождает этот хэш. Это не позволит судебному эксперту создать вредоносное обновление для уничтожения сети. Поскольку значение, использованное для генерации хэша, после обновления должно считаться скомпрометированным, каждое обновление должно поставлять новое значение хэша, которое нужно ожидать.

Дополнительные механизмы безопасности могли бы включать превращение сети в полностью резидентную в памяти, а также отслеживание родителями детей и их повторное заражение при необходимости. То, что никогда не попадало на жесткий диск, очевидно, не может быть найдено судебной экспертизой. Кроме того, команды должны иметь временные метки, чтобы конкретная команда сработала только один раз, а replay-атаки, то есть отправка перехваченного командного пакета для вызова ответа от узла, проваливались. Использование криптографии с публичным ключом для подписи и шифрования данных и коммуникации всегда хорошая идея, но оно также имеет 2 недостатка:

• Обычно оно создает довольно большой overhead при включении в код.

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

Дополнительной функцией могло бы быть включение глобальных уникальных идентификаторов в сеть, предоставляя каждому узлу уникальный ID, задаваемый при установке на каждую новую жертву. Хотя хозяину сети пришлось бы отслеживать адреса хостов и уникальные ID, он мог бы использовать эту функцию в своих интересах. Представьте что-то вроде traceroute внутри сети узлов. Хозяин хочет узнать, где связан определенный хост. Каждый узел знает ID всех дочерних узлов, иерархически связанных под ним. Поэтому он просит верхний узел выяснить путь к интересующему его узлу. Верхний узел понимает, что тот где-то связан под ребенком 2, и, в свою очередь, спрашивает ребенка 2. Этот узел знает, что тот где-то связан под ребенком 4, и так далее. В итоге хозяин получает свою информацию, несколько ID, при этом ни один узел, не связанный напрямую с другим, не узнает IP дальнейших хостов, подключенных к сети.

Чтобы сканирование портов не выявляло скомпрометированный узел, командные пакеты следует принимать через сокет необработанных пакетов. Сами команды должны быть похожи на обычный фоновый трафик, например ответы DNS или определённые значения в TCP SYN.

4.2. Гибрид

Существует способ объединить анонимность несвязанной сети с быстрым временем реакции связанного подхода. Это можно сделать, применив технику, впервые описанную в концепции так называемого "Warhol Worm". Хотя ни один узел ничего не знает о других узлах, хозяин сети отслеживает IP зараженных хостов. Чтобы распространить команду на несколько или, возможно, все узлы, он прежде всего готовит зашифрованный файл, содержащий IP всех активных узлов, и объединяет его с командой для выполнения. Затем он отправляет этот командный файл первому узлу в списке. Этот узел выполняет команду, удаляет себя из списка и проходит список сверху вниз, пока не найдет другой активный узел, которому передает командный файл. Так каждый узел узнает о других узлах только при получении командных файлов, которые затем стираются после успешной передачи файла другому узлу.

Обращаясь к определенным узлам по их уникальным ID, можно даже заставить конкретные узлы выполнять действия, отличные от действий всех остальных. Если с самого начала подготовить разные файлы и отправить их разным узлам, можно добиться довольно быстрого времени распространения. Разумеется, если кому-то удастся не только перехватить командный файл, но и расшифровать его, он получит полный список зараженных хостов. Тот, кто снимает трафик на узле, все равно увидит входящее соединение откуда-то и исходящее соединение куда-то еще, а значит узнает еще о 2 узлах. Это ровно то же, что описано в пассивном подходе. Отличие в том, что бинарный анализ узла не раскроет информацию о другом хосте сети. Поскольку сниффинг, вероятно, представляет большую угрозу, чем бинарный анализ, а связанная сеть дает намного больше гибкости, гибрид, скорее всего, является худшим подходом.

5. Заключение

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

Библиография

The Honeypot Project. Know Your Enemy: Tracking Botnets.

<http://www.honeynet.org/papers/bots/>

Weaver, Nicholas C. Warhol Worms: The Potential for Very Fast Internet Plagues.

<http://www.cs.berkeley.edu/~nweaver/warhol.html>

Paxson, Vern, Stuart Staniford Nicholas Weaver. How to 0wn the Internet in Your Spare Time.

<http://www.icir.org/vern/papers/cdc-usenix-sec02/>

Zalewski, Michael. Writing Internet Worms for Fun and Profit.

<http://www.securitymap.net/sdm/docs/virus/worm.txt>

Аннотация: статья знакомит с понятиями и инструментами, необходимыми для анализа и изменения обычных Win32-приложений в Windows Debugger (WinDBG). Возможности отладчика демонстрируются на WinMine. Рассматриваются основы ассемблера IA-32, назначение регистров, защита памяти, стек, команды WinDBG, цепочки вызовов, порядок байтов и отдельные функции Windows API. В конце эти знания применяются для программы, находящей и удаляющей мины с игрового поля.

Благодарности: автор хотел бы поблагодарить thief, skape, arachne, H D Moore, h1kari, Peter, warlord, west и всех остальных, кто участвовал в первом выпуске Uninformed Journal.

2. Введение

Игры часто бывают очень раздражающими. Это раздражение проистекает из врожденного факта: игры по своей конструкции предъявляют игроку множество неизвестного. Например, сколько монстров прячется за дверью номер три, и хватит ли этих восьми обойм по 90 патронов 50-го калибра, чтобы убить этого парня? Десять жизней и сломанная клавиатура спустя возможность не просто уравнять шансы, но и отыграться, становится чрезвычайно привлекательной любой ценой. Некоторые рискуют репутацией и кармой, чтобы получить это преимущество, то есть читерят.

Многие разрабатывают читы именно по этой причине: чтобы получить нечестное преимущество. Однако у других совершенно другая мотивация - сам вызов, который в этом заключается. Если оставить мотивацию в стороне, цель этого документа - познакомить читателя с базовыми методологиями и доступными инструментами, помогающими в практике реверс-инжиниринга нативных Windows-приложений. В ходе статьи читатель познакомится с WinDBG, ассемблером IA-32 и частями Windows API. Эти понятия будут показаны на примере: через пошаговое прохождение по тем частям WinMine, которые важны для получения желанного нечестного преимущества.

3. Начало работы

Хотя этот документ написан на вводном уровне, предполагается, что читатель удовлетворяет следующим требованиям:

1. Понимание шестнадцатеричной системы счисления

2. Умение разрабатывать базовые C-приложения

3. Умение установить и правильно настроить WinDBG

4. Доступ к компьютеру с Windows XP и установленным WinMine

При чтении этого документа рекомендуется иметь под рукой следующие материалы:

1. IA-32 Instruction Set Reference A-M [7]

2. IA-32 Instruction Set Reference N-Z [7]

3. IA-32 Volume 1 - Basic Architecture [7]

4. Microsoft Platform SDK [4]

5. Debugger Quick Reference [8]

Сначала нужно правильно установить и настроить WinDBG и Symbol Packages <http://msdl.microsoft.com/download/symbols/packages/windowsxp/WindowsXP-KB835935-SP2-slp-Symbols.exe>. WinDBG входит в пакет Debugging Tools for Windows <http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.4.7.2.exe>.

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

3.1. Определение целей

Базовая стратегия WinMine состоит в определении расположения мин на заданной сетке и очистке всех незаминированных клеток за минимальное время. Игрок может отмечать предполагаемые места мин флажками или вопросительными знаками на подозрительных клетках. С учетом этого можно вывести следующие возможные цели:

1. Управлять информацией времени или изменять ее

2. Проверять точность размещения флажков и вопросительных знаков

3. Определять расположение мин

4. Удалять мины с игрового поля

Чтобы достичь этих целей, читатель должен сначала определить следующее:

1. Расположение игрового поля внутри процесса WinMine

2. Как интерпретировать игровое поле

3. Расположение часов внутри процесса WinMine

В рамках этой статьи фокус будет на поиске, интерпретации, обнаружении и/или удалении мин с игрового поля.

3.2. Символы и отладчики

Отладчик - это инструмент или набор инструментов, которые подключаются к процессу, чтобы контролировать, изменять или исследовать части этого процесса. Более конкретно, отладчик дает читателю возможность изменять поток выполнения, читать или записывать память процесса и менять значения регистров. По этим причинам отладчик необходим для понимания работы приложения, чтобы затем им можно было манипулировать в пользу читателя.

Обычно, когда приложение компилируется для выпуска, оно не содержит отладочной информации, которая может включать сведения об исходном коде и имена функций и переменных. В отсутствие этой информации понимание приложения при реверс-инжиниринге становится сложнее. Здесь на сцену выходят символы: помимо прочего, они предоставляют отладчику ранее недоступные имена функций и переменных. За дополнительной информацией о символах читателю рекомендуется обратиться к связанным документам в разделе ссылок.[3]

3.3. Сервер символов

Установите Debugging Tools for Windows и Symbols Packages в любом порядке, запомнив каталог символов. Затем запустите WinDBG через «Пуск» → «Программы» → Debugging Tools for Windows. В отладчике выберите File → Symbol File Path и введите следующее:

Например, если символы установлены в:

то читателю следует ввести:

Настройка сообщает WinDBG локальный каталог и адрес сервера, с которого загружаются отсутствующие символы. Подробнее см. ссылку [2].

4. Знакомство с WinDBG

Независимо от того, перемещается ли читатель по приложениям мышью или использует горячие клавиши, панель инструментов WinDBG кратко послужит ориентиром для обсуждения базовой отладочной терминологии, которая будет использоваться в документе. Слева направо доступны следующие опции:

Следующие четыре опции используются после того, как отладчику было сказано прерваться. Прерывание можно выдать предыдущей опцией, или пользователь может задать точки останова. Точки останова можно назначать на различные условия. Наиболее распространенные - когда процессор выполняет инструкции по конкретному адресу или когда был получен доступ к определенным областям памяти. Реализация точек останова будет подробнее обсуждаться далее в документе.

После достижения точки останова процесс выполнения отдельных инструкций или вызовов функций называется пошаговым прохождением процесса. WinDBG предоставляет несколько методов пошагового выполнения; четыре из них будут сразу обсуждены.

Кнопка Modify Breakpoints добавляет и изменяет точки останова. Остальные элементы панели показывают и настраивают окна WinDBG.

4.1. Окна WinDBG

В меню View перечислены информационные окна. Здесь понадобятся Registers («Регистры»), Disassembly («Дизассемблирование») и Command («Команды»).

Окно Registers содержит список всех регистров процессора и связанных с ними значений. Обратите внимание: когда значения регистров меняются во время выполнения, цвет такого значения станет красным как уведомление для читателя. Для целей этого документа мы кратко остановимся только на следующих регистрах: eip, ebp, esp, eax, ebx, ecx, edx, esi и edi.

Остальные перечисленные регистры предназначены для общего использования. То, как каждый из них используется, зависит от конкретной инструкции. За информацией об использовании регистров для конкретных инструкций читателю рекомендуется обращаться к IA-32 Command References [7].

Окно Disassembly будет содержать ассемблерные инструкции, находящиеся по заданному адресу, по умолчанию - по значению, сохраненному в регистре eip.

Окно Command показывает ответы отладчика, а поле внизу принимает команды. Небольшое поле слева пусто, когда WinDBG не подключён, обрабатывает запрос или исполняет процесс. При локальной отладке пользовательского процесса там появляется приглашение вроде 0:001>. Его формат описан в [9].

Команды делятся на обычные, служебные и команды расширений. Обычные управляют процессом. Служебные начинаются с точки и настраивают сам отладчик. Команды расширений начинаются с восклицательного знака и вызывают подключаемые модули WinDBG.

5. Поиск игрового поля WinMine

Запустите WinMine через «Пуск» → «Выполнить» → WinMine и задайте параметры:

Уровень (Level): особый (Custom); высота (Height): 900; ширина (Width): 800; мины (Mines): 300; метки (Marks): включены; цвет (Color): включён; звук (Sound): выключен.

После этого скомпилируйте и выполните вспомогательное приложение SetGrid[12], указанное в разделе ссылок. Это гарантирует, что игровое поле читателя будет совпадать с полем, использованным при написании этой статьи. Переключитесь в WinDBG и нажмите F6. Это покажет читателю список процессов. Выберите winmine.exe и нажмите Enter. WinDBG подключится к процессу WinMine. Читатель сразу заметит, что окна Command, Registers и Disassembly теперь содержат значения.

5.1. Загруженные модули

Если читатель обратит внимание на окно Command, он заметит, что загружена серия модулей, а процесс WinMine был прерван.

Читатель также должен заметить, что WinDBG по умолчанию показывает значения регистров в окне Command при достижении точки останова или после завершения каждого шага.

5.2. Загруженные символы

Мы потратили время на загрузку и установку Symbols Packages, так что посмотрим, какие подсказки они дают. Введите следующее в окне Command, чтобы получить список всех доступных символов для WinMine.

Команда e(x)amine интерпретирует все слева от восклицательного знака как маску регулярного выражения для имени модуля, а все справа - как маску регулярного выражения для имени символа. За дополнительной информацией о синтаксисе регулярных выражений читателю рекомендуется обратиться к связанным документам в разделе ссылок [10].

В окне Command прокрутится список символов.

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

5.3. Защита памяти

До сих пор обсуждения, связанные с памятью приложения, были достаточно пренебрежены. Теперь это изменится. Это не значит, что сейчас будут раскрыты внутренние механизмы управления памятью Windows; напротив, ради краткости и удовлетворения наших немедленных утилитарных потребностей будет применен довольно узконаправленный подход.

Когда приложение запрашивает память, при наличии свободного места ему выделяется область с определёнными правами доступа: чтение, запись и выполнение. По этим правам часто можно отличить функцию от переменной. Область с машинным кодом должна допускать выполнение, тогда как память обычных переменных — нет. WinDBG позволяет узнать защиту памяти по заданному адресу с помощью команды расширения !vprot. Для примера выберем символ с говорящим именем и введём в окне команд:

ShowBombs был выбран потому, что его имя подразумевает (для меня), что это функция. Посмотрим, что говорит !vprot:

Ожидается, что !vprot вернет защиту страницы, разрешающую только чтение и запись в эту область.

Так и есть. Префикс sz обычно обозначает строку; проверим это, выведя память по данному адресу. Введите в окне команд:

Модификатор u команды отображения памяти d задаёт интерпретацию данных как строку Юникода. Результат:

Я убежден.

5.4. Понимание ассемблера

Цель этой главы - просто найти, где находится игровое поле. С учетом этого вернемся к ранее найденной функции ShowBombs. Логически не так уж смело предположить, что эта функция приведет к игровому полю. Установите точку останова на этой функции, введя следующую команду:

WinDBG не дает положительной обратной связи о том, что точка останова успешно установлена. Однако WinDBG предупредит пользователя, если не сможет разрешить запрошенное имя или адрес. Чтобы получить список установленных точек останова, введите следующую команду:

Окно Command должно отразить:

Первая цифра — номер точки останова, на который могут ссылаться другие команды отладчика. Следующее поле показывает её состояние: включена (e, enabled) или отключена (d, disabled). Далее указаны виртуальный адрес, число срабатываний, оставшихся до остановки, и в скобках исходное значение этого счётчика. После них выводится внутренний номер процесса — не идентификатор процесса. За двоеточием находился бы идентификатор потока, если бы точка останова относилась только к одному потоку; три звёздочки означают, что такого ограничения нет. В конце показаны модуль и символ, на котором остановится WinDBG.

Запустите WinMine, нажав F5 (Go) или введя g в окне Command. Читатель должен заметить, что WinDBG сообщает пользователю "Debugee is running". Переключитесь в окно WinMine и нажмите на верхнюю левую клетку, что должно открыть число два. Затем нажмите клетку справа, и станет очень очевидно, что была выбрана мина, поскольку читатель больше не сможет взаимодействовать с WinMine. Это связано с тем, что WinDBG распознал выполнение условия точки останова и ждет указаний. Вернувшись в WinDBG, в окне Command будет выделена следующая инструкция:

Это первая инструкция внутри функции ShowBombs, соответствующая адресу, ранее обнаруженному при выводе текущих точек останова. Прежде чем пытаться понять эту инструкцию, сначала рассмотрим несколько функциональных и синтаксических аспектов ассемблера IA-32. Рекомендуется, чтобы читатель подготовил вышеупомянутые дополнительные материалы из главы 2.

Каждая строка дизассемблирования описывает инструкцию. Используем указанную выше инструкцию, чтобы определить основные компоненты инструкции, не отвлекаясь на то, как она относится к функции ShowBombs. Если свести ее к сути, предыдущую инструкцию можно абстрагировать и представить так:

<address> представляет виртуальное расположение <opcodes>. Опкоды - это буквальные инструкции, которые процессор интерпретирует для выполнения работы. Все справа от <opcodes> представляет перевод этих опкодов на язык ассемблера. <mnemonic> можно воспринимать как глагол или функцию, которая рассматривает каждый операнд как аргумент. Важно отметить, что в стиле Intel, в отличие от стиля ATT, используемого GCC-ассемблером, эти операции движутся справа налево. То есть при выполнении арифметики или перемещении данных результат обычно оказывается в <operand1>.

Возвращаясь к исходной инструкции, можно определить, что 32-битное значение, расположенное по адресу 0x01005338, копируется в регистр eax. Квадратные скобки ([]) разыменовывают адрес в операнде — примерно как звёздочка (*) в C. Если найти код операции варианта mov, загружающего значение в eax, получится 0xa1.

Первый байт <opcodes> не случайно равен 0xa1. Остаётся <operand2>, что приводит к вопросу о порядке байтов.

5.5. Порядок байтов

Значение <operand2> равно 0x01005338, а оставшиеся байты <opcodes> — 0x38530001. Если записать операнд от младшего байта к старшему, последовательности совпадут.

Теперь видно, как процессору задаётся перенос значения по адресу 0x01005338 в eax. Подробнее о порядке байтов см. [5].

5.6. Условия

Посмотрим, можно ли применить эту новую информацию для достижения цели - поиска игрового поля. Начните с нажатия F10 или ввода p в окне Command, чтобы выполнить текущую инструкцию и остановиться. Есть несколько вещей, на которые стоит обратить внимание. Во-первых, ранее пурпурная полоса, выделявшая изученную выше инструкцию, теперь стала красной, а инструкция сразу под ней теперь выделена синим. WinDBG по умолчанию обозначает инструкции, удовлетворяющие условию точки останова, красным выделением, а текущую инструкцию - синим. Кроме того, несколько значений в окне Registers подсвечены красным. Помните из главы 4, что это означает обновленное значение регистра. Как и ожидалось, регистр eax был обновлен, но что представляет его новое значение? 0x18, теперь находящееся в eax, можно выразить как 24 в десятичном виде. Обратите внимание: наше игровое поле, хотя ранее было задано как 800x900, было отрисовано как 30x24. Совпадение? Это можно проверить, перезапустив WinMine с разными размерами поля, но ради краткости пусть следующее утверждение считается истинным:

Следующие инструкции:

сравнивают максимальную высоту с числом 0x1. Инструкция cmp выставляет флаги EFLAGS по результату сравнения, а следующая за ней jl выполняет условный переход по адресу 0x01002fd8, если знаковое значение eax меньше единицы. Мнемоники, начинающиеся с j (кроме безусловного jmp), обозначают условные переходы; буква l здесь означает «меньше». Эту последовательность можно выразить привычнее:

Это покажет читателю инструкции, которые были бы выполнены при выполнении условия.

5.7. Стеки и фреймы

Команда u инструктирует WinDBG (u)nassemble, то есть перевести из опкодов в мнемоники с операндами, информацию, найденную по указанному адресу.

Из этого видно, что вызывается DisplayGrid, после чего ShowBombs возвращает управление вызывающей функции. Остаётся понять, куда возвращает ret и что означает 0x4. Код операции 0xe8 задаёт ближний вызов: процессор помещает в стек адрес следующей после call инструкции и передаёт управление по адресу назначения. Так начинается формирование кадра стека. При каждом вызове создаётся новый кадр, через который функция получает аргументы, размещает локальные переменные и впоследствии возвращает управление. Устройство кадра зависит от соглашения о вызовах; дополнительные сведения приведены в источнике [1]. Текущий стек вызовов — последовательность связанных кадров — показывает команда k.

С этим читатель может отслеживать поток приложения в обратном порядке. Читателю может быть проще перемещаться по стеку вызовов, нажав Alt-6, что откроет окно Call Stack. Там информация стека вызовов немного обработана и отображается в табличном виде. Имея информацию стека вызовов, можно ответить на второй вопрос о том, куда действительно направляется ret. Например, после возврата ShowBombs eip будет установлен в 0x010034b0. Наконец, значение 0x4 можно понять, прочитав определение инструкции ret, где сказано, что это значение представляет "...число байтов стека, освобождаемых после извлечения адреса возврата; по умолчанию отсутствует. Этот операнд можно использовать для освобождения параметров из стека, которые были переданы вызываемой процедуре и больше не нужны". Более конкретно, когда процессор встречает инструкцию ret, он извлекает адрес, сохраненный на вершине стека, куда указывает esp, и помещает это значение в регистр eip. Если у инструкции ret есть операнд, этот операнд представляет, сколько дополнительных байтов следует удалить с вершины стека. С этой информацией и зная, что 32-битные адреса имеют длину четыре байта, можно определить, что функция ShowBombs принимает один аргумент. Это зависит от соглашения вызова, которое будет обсуждаться далее в документе.

Возвращаясь к текущей задаче, следующее представляет текущее понимание того, что делает функция ShowBombs:

Начните с двух шагов WinDBG (нажав p дважды), чтобы eip был установлен в 0x1002f8a. Следующие две инструкции сохраняют регистры ebx и esi в стеке. Это можно продемонстрировать, сначала просмотрев память, на которую ссылается esp, определив значение, сохраненное в ebx, нажав p для выполнения push ebx и снова просмотрев значение, сохраненное по esp. Читатель найдет значение ebx, сохраненное по esp.

Значение esp уменьшилось на четыре байта — размер 32-битного указателя, — и по новому адресу оказалось значение ebx. То же произойдёт после push esi: указатель стека уменьшится ещё на четыре, а по новому адресу будет записано значение esi. Иными словами, стек растёт в сторону меньших адресов. Его границы можно узнать из блока окружения потока (Thread Environment Block, TEB). В WinDBG для этого есть команда расширения !teb.

Обратите внимание на значения StackBase и StackLimit, которые обозначают потолок и пол стека соответственно. За дополнительной информацией о TEB читателю рекомендуется обратиться к связанным документам в разделе ссылок [11]. Это было увлекательное отступление. Возвращаясь назад, читатель оказывается у следующей инструкции:

Если закономерность сохраняется, инструкция загрузит ширину игрового поля в esi. После одного шага (p) регистр esi будет выделен красным в окне «Регистры» (Registers) и получит значение 0x1e, то есть 30 — ширину текущего поля. Значит, xBoxMac, по всей видимости, хранит ширину поля. Следующая инструкция, push edi, сохраняет edi перед выполнением mov edi,0x1005360. Возможно, адрес 0x1005360 указывает на само игровое поле. Команда расширения !vprot показывает, что эта память доступна для чтения и записи (PAGE_READWRITE) и не относится к исполняемой области. Если здесь действительно хранится поле, в данных должен быть заметен повторяющийся узор. Введите 0x1005360 в окно «Память» (Memory):

6. Интерпретация игрового поля

Читатель может сразу заметить, что этот участок памяти заполнен ограниченным набором значений. Наиболее заметны 0x8f, 0x0f, 0x10, 0x42, 0xcc. Кроме того, можно заметить следующий повторяющийся паттерн:

Число 30 может показаться читателю знакомым, поскольку оно встречалось ранее при обнаружении ширины поля. Можно предположить, что каждое повторение паттерна представляет строку игрового поля. Чтобы помочь подтвердить это, переключитесь в WinDBG и возобновите WinMine, нажав g в окне Command. Переключитесь в WinMine и мысленно наложите информацию в окне Memory на игровое поле. Можно выявить корреляцию: каждая мина на игровом поле соответствует 0x8f, а каждая пустая позиция на игровом поле соответствует 0x0f. Кроме того, можно заметить, что взорванная мина на игровом поле представлена 0xcc, а число два представлено 0x42.

Чтобы подтвердить, что это действительно игровое поле, необходимо проверить нижнюю границу, выполнив простую арифметику и применив ту же технику, которая использовалась для определения предполагаемого начала. Текущая гипотеза состоит в том, что каждый вышеупомянутый паттерн представляет строку игрового поля. Если это верно, можно умножить 32, длину нашего паттерна, на число строк игрового поля, 24. Результат этого вычисления - 768, или 0x300 в шестнадцатеричном виде. Это значение можно добавить к предполагаемому началу поля, расположенному по 0x01005360, чтобы получить конечный адрес 0x01005660. Перезапустите WinMine, нажав желтый смайлик, заново запустите вспомогательное приложение SetGrid и нажмите нижнюю правую клетку игрового поля. По совпадению появится число два. Затем нажмите позицию непосредственно слева от числа два. Эта позиция содержит мину и вызовет точку останова в WinDBG. Переключитесь в WinDBG и обратите внимание на окно Memory. Нажмите Next в окне Memory дважды, чтобы привести этот диапазон в фокус.

Следуя тому же наложению, что и раньше, читатель заметит, что прежние соответствия можно провести между последней строкой игрового поля и информацией, расположенной по 0x01006540, началу ранее определенного 32-байтового паттерна. Снова обратите внимание, что каждая мина представлена 0x8f. С этой информацией читатель может разумно заключить, что это действительно игровое поле.

7. Удаление мин

Прежде чем обращаться к отдельной программе, познакомимся с командой WinDBG e — вводом значений в память. С её помощью можно изменять выбранные участки виртуальной памяти, в том числе удалять мины с поля WinMine. Сбросьте поле: возобновите WinMine в отладчике, нажмите жёлтый смайлик и запустите SetGrid. Откройте верхнюю левую клетку, затем прервите процесс сочетанием Ctrl+Break. По адресу 0x01005362, непосредственно справа от открытой двойки, находится мина. Выполните в окне команд:

Возобновите WinMine в WinDBG и нажмите позицию справа от двойки. Обратите внимание: вместо отображения мины открывается число два. Читатель мог бы выполнить утомительную задачу вручную по всему полю, или можно разработать приложение для обнаружения и/или удаления мин.

7.1. Виртуальный сапер

В этом разделе читатель познакомится с частями Windows API, которые позволят разработать приложение, выполняющее следующее:

1. Найти и подключиться к процессу WinMine

2. Прочитать игровое поле WinMine

3. Манипулировать полем, чтобы либо показать, либо удалить скрытые мины

4. Записать вновь измененное поле обратно в пространство приложения WinMine

Чтобы выполнить первую задачу, можно воспользоваться услугами Tool Help Library, открытой через Tlhelp32.h. Снимок выполняющихся процессов можно получить вызовом CreateToolhelp32Snapshot, имеющим следующий прототип. Эту информацию можно получить, обратившись к Platform SDK:

Как читатель наверняка заметил, обе эти функции возвращают LPPROCESSENTRY32, которая включает множество полезной информации:

Наиболее заметны szExeFile, которое позволит читателю найти процесс WinMine, и th32ProcessID, которое предоставляет ID процесса для подключения после нахождения процесса WinMine. После обнаружения процесса WinMine к нему можно подключиться через функцию OpenProcess, имеющую следующий прототип:

После открытия процесса WinMine читатель может прочитать текущее игровое поле из его виртуальной памяти через функцию ReadProcessMemory, имеющую следующий прототип:

После чтения поля в буфер читатель может пройти по нему, заменяя все экземпляры 0x8f либо на 0x8a, чтобы показать мины, либо на 0x0f, чтобы удалить их. Затем измененный буфер можно записать обратно в процесс WinMine с помощью функции WriteProcessMemory, имеющей следующий прототип:

С этой информацией у читателя есть инструменты, необходимые для разработки приложения, достигающего конечной цели этой статьи: обнаружить и/или удалить мины с игрового поля WinMine. Исходный код работающей демонстрации этого можно найти в разделе ссылок.[13]

8. Заключение

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

Ссылки

1. Calling Conventions <http://www.unixwiz.net/techtips/win32-callconv-asm.html>

2. Symbol Server <http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx>

3. Symbols ms-help://MS.PSDK.1033/debug/base/symbolfiles.htm

4. Platform SDK <www.microsoft.com/msdownload/platformsdk/sdkupdate/>

5. Endianness <http://www.intel.com/design/intarch/papers/endian.pdf>

6. EFLAGS ftp://download.intel.com/design/Pentium4/manuals/25366514.pdf Appendix B

7. Intel Command References <http://www.intel.com/design/pentium4/manuals/indexnew.htm>

8. Debugger Quick Reference <http://www.tonyschr.net/debugging.htm>

9. WinDBG Prompt: справка WinDBG, поиск по "Command Window Prompt"

10. Regular Expressions: справка WinDBG, поиск по "Regular Expression Syntax"

11. TEB <http://msdn.microsoft.com/library/en-us/dllproc/base/teb.asp>

12. SetGrid.cpp

13. MineSweeper.cpp

Аннотация: эта статья предназначена для описания ряда проблем, с которыми Blizzard Entertainment столкнулась на практике при реализации Battle.net, крупномасштабного онлайн-сервиса для подбора игровых матчей и чата. Статья дает немного исторического фона о проектировании и назначении Battle.net, а затем обсуждает ряд недостатков, замеченных в реализации системы. Читатели должны получить лучшее понимание проблем, которые легко внести при проектировании системы матчмейкинга/чата для работы в таком большом масштабе, а также некоторых серьезных последствий для безопасности, возникающих при отсутствии надлежащей проверки параметров от недоверенных клиентов.

2. Введение

Сначала немного исторической и фоновой информации, ведущей к сегодняшнему дню. Battle.net - это онлайн-сервис подбора матчей, который позволяет игрокам создавать онлайн-игры с другими игроками. Вполне возможно, это старейшая и крупнейшая система такого рода, существующая сейчас (запущена в 1997 году).

Базовые услуги, предоставляемые Battle.net, - подбор игр и чат. Система подбора игр позволяет создавать игры и присоединяться к ним почти без предварительной настройки или вовсе без нее, кроме выбора параметров игры, например карты и т. п. Чат-система похожа на урезанную версию Internet Relay Chat. Основные различия между IRC и Battle.net (для целей чат-системы) состоят в том, что Battle.net позволяет пользователю находиться только в одном чат-канале одновременно, а многие параметры канала, знакомые пользователям IRC (максимальное число пользователей в канале, кто имеет привилегии оператора канала), фиксируются сервером в четко определенные значения.

Battle.net поддерживает множество игр Blizzard: Diablo, StarCraft, Warcraft II: Battle.net Edition, Diablo II и Warcraft III, а также условно-бесплатные версии Diablo и StarCraft и дополнения к Diablo II, StarCraft и Warcraft III. Все они используют общий бинарный протокол, развивавшийся восемь лет, хотя набор доступных возможностей различается.

В некоторых случаях это связано с различными требованиями игровых клиентов, но обычно причина просто в том, что старые программы обновлялись не так часто, как новые версии. Короче говоря, существует несколько разных диалектов бинарного протокола Battle.net, одновременно используемых различными поддерживаемыми продуктами. Помимо поддержки недокументированного бинарного протокола, Battle.net уже некоторое время поддерживает текстовый протокол ("Chat Gateway", как он официально документирован). Этот протокол поддерживает ограниченное подмножество возможностей, доступных клиентам, использующим полный игровой протокол. В частности, в нем нет поддержки таких возможностей, как создание учетных записей и управление ими.

Оба этих протокола сейчас довольно хорошо поняты и документированы некоторыми людьми за пределами Blizzard. Хотя текстовый протокол документирован и довольно стабилен, присущие ему ограничения делают его нежелательным для многих применений. Более того, чтобы помочь сдержать поток спама в Battle.net, Blizzard изменила серверное ПО так, чтобы клиенты, использующие текстовый протокол, не могли входить почти ни в какие чат-каналы, кроме нескольких заранее определенных. В результате многие разработчики выполнили реверс-инжиниринг бинарного протокола Battle.net (или, что чаще, использовали работу тех, кто сделал это до них) и написали собственные клиенты-"эмуляторы" для различных целей, обычно как лучшую альтернативу ограниченным чат-возможностям игровых клиентов Blizzard. Такие клиенты эмулируют поведение конкретной игровой программы Blizzard, чтобы обманом заставить Battle.net предоставлять услуги, обычно предлагаемые только игровым клиентам; отсюда название "клиент-эмулятор". Большинство таких клиентов их разработчики и сообщество Battle.net в целом называют "ботами-эмуляторами" или "emubots". Фактически существуют и частично совместимые серверные реализации, которые с разной степенью точности реализуют серверную логику чата и подбора матчей, поддерживаемую Battle.net. Сегодня можно загрузить сторонний сервер, эмулирующий протокол Battle.net, и сторонний клиент, эмулирующий клиент Blizzard с поддержкой протокола Battle.net, и заставить их взаимодействовать.

3. Проблемы Battle.net

В силу поддержки такого большого числа разных игровых клиентов (сейчас существует 11 отдельных поддерживаемых Blizzard программ, подключающихся к Battle.net) у Blizzard есть значительная проблема контроля версий. Фактически эта проблема усугубляется несколькими обстоятельствами.

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

Кроме того, многие клиенты имеют очень значительные различия в поддержке функций. Например, в течение многих лет Diablo и Diablo Shareware одновременно поддерживались в Battle.net, при этом Diablo поддерживала пользовательские учетные записи, а shareware-версия - нет. Как можно представить, такие вещи способны породить огромное число проблем. Механизм контроля версий и обновления не отделен от остального протокола. Более того, для контроля версий используются тот же сервер и то же соединение, но для передачи клиентских патчей используется другое соединение к тому же серверу. В результате любой совместимый сервер Battle.net обязан поддерживать не только текущую версию протокола Battle.net, используемую текущим уровнем патчей каждого существующего клиента, но и первые несколько сообщений, используемых каждой версией каждого когда-либо выпущенного клиента Battle.net, по крайней мере до того момента, когда можно вызвать механизм проверки версии для распространения новой версии (а в некоторых старых итерациях протокола это не первая выполняемая задача).

Несмотря на все эти сложности, Blizzard сумела поддерживать Battle.net в рабочем состоянии почти десятилетие и заявляет о более чем миллионе активных пользователей. Однако путь к сегодняшнему дню не был для Blizzard "безоблачным плаванием". Это приводит нас к некоторым конкретным проблемам, стоявшим перед Battle.net до настоящего времени. Один из основных классов проблем, с которыми столкнулась Blizzard по мере роста Battle.net, состоит в том, что, по мнению автора, он просто не был спроектирован для обстоятельств, в которых в итоге оказался использован. Это видно по ряду событий последних лет:

Хотя трудно привести точные детали этих изменений, поскольку автор не работал в Blizzard, многие из них можно вывести.

3.1. Сетевые проблемы

Изначально Battle.net состоял из нескольких связанных серверов в разных регионах. Игроки взаимодействовали через них так же, как внутри одного сервера. С ростом нагрузки архитектура стала часто распадаться: отстающий узел временно терял связь с остальной сетью.

Позднее и эта система перестала справляться, поэтому сеть США и Европы разделили на подсети USEast, USWest, Europe и Asia. Считается, что серверы каждого кластера, или шлюза, физически находятся в одном центре обработки данных и соединены быстрой локальной сетью.

По мере появления новых требований игр потребовалась новая архитектура для Diablo II и Warcraft III. В этих случаях игры размещаются на серверах, управляемых Blizzard, а не на клиентских машинах, чтобы сделать их более устойчивыми к попыткам взлома игры для получения нечестного преимущества. В реализации этого для Diablo II и Warcraft III есть значительные различия, и это не используется для некоторых типов игр в Warcraft III. Это привело к существенному изменению того, как сервис выполняет свою основную функцию, то есть подбор игр.

3.2. Проблемы клиента/сервера

Помимо базовых проблем сетевого дизайна, другие проблемы возникли из-за того, что Blizzard не ожидала и не намеревалась, чтобы сторонние программы использовали ее протокол Battle.net. В результате для некоторых условий, которые не генерировались бы клиентским ПО Blizzard, не всегда присутствовала надлежащая проверка.

Как упоминалось ранее, многие разработчики в итоге начали использовать протокол Battle.net напрямую вместо текстового протокола, чтобы обойти определенные ограничения текстового протокола. Для этого есть несколько причин. Исторически клиенты, использующие протокол Battle.net, могли входить в уже заполненные каналы (частные каналы в Battle.net обычно имеют лимит 40 пользователей) и выполнять различные функции управления учетными записями, такие как создание учетных записей, смена паролей, управление информацией профиля пользователя и т. п., которые недоступны через текстовый протокол.

Помимо доступа к расширенной функциональности на уровне протокола, клиентам, использующим протокол Battle.net, разрешено открывать до восьми соединений с одной сетью Battle.net на IP-адрес, в отличие от текстового протокола, который разрешает только одно соединение на IP-адрес. Изначально этот лимит составлял четыре соединения на IP-адрес и был поднят после роста популярности NAT, особенно в киберкафе.

Это особенно привлекало пользователей сторонних чат-клиентов. В Battle.net, как и раньше в IRC, были распространены войны за контроль над каналами, а возможность подключить много клиентов с одного IP-адреса давала заметное преимущество.

Из-за войн за каналы появилось множество сторонних клиентов протокола Battle.net. Точное число пользователей неизвестно, но автор наблюдал одновременно несколько тысяч таких подключений.

Разработка и использование указанных сторонних клиентов привели к обнаружению ряда других проблем в Battle.net. Хотя большинство рассматриваемых здесь проблем уже исправлены или относительно незначительны, их все равно стоит обсудить.

3.2.1. Лимиты клиентских соединений

С помощью определенных сообщений протокола Battle.net можно было войти в канал сверх нормального лимита в 40 пользователей. Это было связано с тем, что метод, используемый игровым клиентом для возврата в чат-канал после выхода из игры, не проверял число пользователей надлежащим образом. После того как злоумышленники использовали эту уязвимость, чтобы поместить тысячи пользователей в один канал, что затем привело к падениям сервера, Blizzard наконец исправила эту уязвимость.

3.2.2. Переполнение сервера чат-сообщением

Серверное ПО часто предполагало, что клиент будет выполнять только "разумные" действия, и одно из этих предположений касалось того, насколько длинное чат-сообщение может отправить клиент. Судя по всему, сервер копировал чат-сообщение, указанное клиентом протокола Battle.net, в фиксированный 512-байтовый буфер без надлежащей проверки длины, так что клиент мог обрушить сервер, отправив достаточно длинное сообщение. Поскольку серверные бинарные файлы Blizzard публично недоступны, эксплуатировать этот недостаток для выполнения произвольного кода на сервере было бы непросто. Эта серьезная уязвимость была исправлена в течение дня после сообщения о ней.

3.2.3. Аутентификация клиентов

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

Первая схема использует протокол «запрос — ответ» и хеш SHA-1 пароля. Игровой клиент перед хешированием переводит пароль в нижний регистр, уменьшая пространство вариантов. Сторонний клиент может этого не делать и создать учётную запись, недоступную официальным клиентам. Хуже того, в реализации циклического сдвига ROL перепутаны аргументы, поэтому значительная часть хешируемых данных превращается в нулевые биты. Исправить ошибку без нарушения совместимости со старыми учётными записями трудно, и схема продолжает использоваться.

Вторая схема основана на протоколе безопасной удалённой проверки пароля SRP и применяется только в Warcraft III с дополнением. У этих игр отдельное пространство имён, поэтому совместимость со старой схемой SHA-1 не требуется; в чате пользователь из другой сети отображается, например, как User@USEast. Однако порядок байтов в вычислениях обращён, и часть кода при преобразовании большого целого в плоский буфер удаляет ведущие нулевые биты вместо завершающих. Кроме того, если число занимает меньше 32 ненулевых байтов, сервер не обнуляет остаток буфера и оставляет там неинициализированные данные. Из-за этого некоторые попытки входа случайно завершаются неудачей.

3.2.4. Подмена пространства имен клиента

С выпуском Warcraft III для пользователей этого продукта было предоставлено отдельное пространство имен учетных записей, как упоминалось выше. Внутренне сервер отслеживает имя учетной записи пользователя как xusername, где x - цифра, задающая альтернативное пространство имен (единственное известное сейчас обозначение пространства имен - w для Warcraft III). Это известно благодаря сообщению, которое раскрывает протокольным клиентам внутреннее уникальное имя пользователя. Хотя символ '' никогда не разрешался в именах учетных записей, если пользователь входит в одну и ту же учетную запись более одного раза, ему назначается уникальное имя формата accountnameserial, где serial - число, увеличиваемое в соответствии с количеством дублирующихся входов в ту же учетную запись. Из-за отсутствия проверки параметров в процессе создания учетной записи одно время можно было через сторонний клиент создавать учетные записи длиной в один символ (все официальные игровые клиенты не позволяют пользователю это делать). Некоторое время такие учетные записи сбивали сервер с толку, заставляя его думать, что пользователь на самом деле находится в другом, несуществующем пространстве имен, и тем самым позволяли пользователю, вошедшему в однобуквенную учетную запись более одного раза, стать невозможным для "нацеливания" любыми функциями управления пользователями. Например, такому пользователю нельзя было отправить личное сообщение, его нельзя было игнорировать, забанить или выгнать из канала, или иным образом затронуть любыми другими командами, работающими с конкретным пользователем. Разумеется, этим часто злоупотребляли для спама отдельных людей, причем жертвы не могли остановить спамера или даже игнорировать его. Эта проблема исправлена в текущей версии сервера.

3.2.5. Коллизии имен пользователей

Как упоминалось в предыдущем подразделе, некоторое время сервер разрешал клиентов Diablo Shareware. Эти клиенты не входили в учетные записи, а просто назначали себе имя пользователя. Если имя пользователя уже использовалось, применялись обычные процедуры: в конец добавлялся серийный номер, чтобы сделать имя уникальным. Помимо очевидной проблемы возможности выдать себя за кого-то перед пользователем, который был недостаточно внимателен, чтобы проверить, под каким типом игры кто-то вошел, это создавало дополнительную уязвимость, активно эксплуатировавшуюся в "войнах каналов". Если сервер отделялся от остальной сети из-за нагрузки, можно было войти на этот сервер с помощью Diablo Shareware и выбрать то же имя, что у кого-то, вошедшего в остальную сеть через другой тип игры. Когда разделение сервера разрешалось, сервер замечал, что теперь есть два пользователя с одним и тем же уникальным именем, и отключал обоих с сообщением "Duplicate username detected." (это синонимично старым "colliding"-эксплойтам, которые раньше мучили IRC). Это можно было использовать, чтобы принудительно выбрасывать пользователей из сети каждый раз, когда происходило разделение сервера. Возможность делать это была желанной в том смысле, что обычно в канале мог быть только один оператор канала одновременно, если не считать разделений серверов, которые можно было использовать для создания второго оператора, если канал был полностью опустошен и затем заново создан на отделенном сервере. Когда этот оператор уходил, следующий человек в очереди получал операторские разрешения, если оператор явно не "назначил" нового наследника операторских прав. Таким образом, можно было "захватить" канал, систематически отключая тех, кто находится "впереди" клиента в канале. Канал упорядочен по возрасту пользователя в канале.

3.2.6. Десинхронизация сервера

Одно время существовало состязание: если вредоносный пользователь одновременно входил на два связанных сервера, они переставали обмениваться данными и сеть распадалась. Вероятно, оба узла пытались одновременно синхронизировать одного пользователя и один из них переходил в недопустимое состояние. Обычно связь восстанавливалась через 10–15 минут.

3.2.7. Видимость невидимых пользователей

Администраторы Battle.net могут быть невидимыми для обычных пользователей. До исправления ошибки сервер раскрывал их при добавлении или удалении кого-либо из списка игнорирования, повторно отправляя состояния всех пользователей канала. Официальные клиенты отбрасывали неизвестные записи, поэтому увидеть скрытого администратора мог только сторонний клиент.

3.2.8. Обнаружение административных команд 3.2.9. Получение административных привилегий

Из-за недосмотра в том, как административные разрешения назначаются учетным записям Battle.net, одно время было возможно перезаписать учетную запись администратора новой учетной записью и сохранить специальные разрешения, иначе связанные с этой учетной записью. Учетная запись может быть перезаписана таким образом, если к ней не обращались 90 дней. Это почти могло привести к катастрофе для Blizzard, если бы более злонамеренный пользователь обнаружил эту уязвимость и злоупотребил такими привилегиями.

3.2.10. Получение паролей 4. Эмуляция сервера Battle.net

Blizzard "объявила войну" программистам серверов, реализующих протокол Battle.net, некоторое время назад, когда подала в суд на разработчиков "bnetd". Начиная с Warcraft III, она предприняла активные меры, чтобы усложнить жизнь разработчикам, пишущим сторонние Battle.net-совместимые серверы. В частности, стоит отметить два действия:

Во время бета-теста дополнения Warcraft III Blizzard шифровала трафик Battle.net поточным шифром RC4; в рабочей сети схема не применялась. Для каждого сообщения состояние шифра дополнительно изменяли разные жёстко заданные константы, которые по сети не передавались. Это усложняло стороннюю реализацию сервера. Однако модифицированный клиент мог обнулить параметры инициализации RC4, после чего весь «зашифрованный» поток превращался в открытый текст.

После нескольких патчей Blizzard реализовала схему, с помощью которой клиент Warcraft III мог проверять, что он действительно подключается к подлинному серверу Blizzard Battle.net. Эта схема работала так: сервер Battle.net подписывал свой IP-адрес и отправлял получившуюся подпись клиенту, который отказывался входить, если IP-адрес сервера не соответствовал подписи. Однако в исходной реализации игровой клиент проверял только первые четыре байта подписанных данных и не валидировал оставшиеся, обычно нулевые, 124 байта. Это позволяет легко перебрать подпись с заданным IP-адресом, поскольку для ее нахождения нужно проверить максимум 32 бита возможных подписей.

5. Заключение

Аннотация: почти все существующие векторы эксплуатации зависят от некоторого знания адресного пространства процесса до атаки, чтобы получить осмысленный контроль над потоком выполнения. В случаях, где это необходимо, авторы эксплойтов обычно используют статические адреса, которые могут быть переносимыми между разными версиями операционной системы и приложения, а могут и не быть. Этот факт может делать эксплойты ненадежными в зависимости от того, насколько хорошо были исследованы статические адреса на момент реализации эксплойта. Однако в некоторых случаях можно предсказывать и использовать определенные адреса в памяти, содержимое которых не является статическим. Этот документ вводит понятие временных адресов и описывает, как при определенных обстоятельствах их можно использовать, чтобы сделать эксплуатацию более надежной.

Благодарности: автор хотел бы поблагодарить H D Moore, spoonm, thief, jhind, johnycsh, vlad902, warlord, trew, vax, uninformed и всех друзей nologin!

Итак, продолжим шоу...

2. Введение

Обычное препятствие при реализации переносимых и надежных эксплойтов - местоположение адреса возврата. Часто требуется, чтобы конкретная инструкция, например jmp esp, находилась по предсказуемому адресу в памяти, чтобы поток управления можно было перенаправить в контролируемый атакующим буфер. Такой сценарий чаще встречается в Windows, но применимые сценарии существуют и в UNIX-производных. Однако часто расположение инструкций будет различаться между отдельными версиями операционной системы, тем самым ограничивая эксплойт набором целей, специфичных для версии, которые могут быть прямо определимы во время атаки, а могут и не быть. Чтобы сделать эксплойт независимым или хотя бы менее зависимым от версии операционной системы цели, нужно сменить фокус.

Сквозь туман рифмы и разума атакующий может сосредоточиться и понять, что не все пригодные адреса возврата будут существовать неопределенно долго в адресном пространстве целевого процесса. Фактически пригодные адреса возврата можно найти в переходном состоянии в ходе выполнения программы. Например, указатель может храниться в месте памяти, которое случайно содержит пригодную двухбайтовую инструкцию где-то внутри байтов, составляющих адрес указателя. Или целочисленное значение где-то в памяти может быть инициализировано значением, эквивалентным пригодной инструкции. Однако в обоих случаях содержимое и расположение значений почти наверняка будут изменчивыми и непредсказуемыми, что делает их непригодными для использования как адресов возврата.

Чтобы проиллюстрировать это, предположим, что атакующий пытается найти надежное расположение инструкции jmp edi. Атакующий знает, что эксплуатируемая программа имеет таймер, хранящий число секунд с 1 января 1970 года по предсказуемому адресу в памяти. Выполнив некоторый анализ, атакующий мог бы определить, что в среду, 27 июля 2005 года, в 15:39:12 CDT, jmp edi можно было бы найти внутри любого четырехбайтового таймера, хранящего число секунд с 1970 года. Однако окно возможности длилось бы только 4 минуты и 16 секунд, если предположить, что таймер обновляется каждую секунду.

Учитывая время как фактор выбора адресов возврата, атакующий получает варианты за пределами обычно видимых, когда адресное пространство процесса рассматривается как неизменное во времени. В этом свете документ разделен на три части. Сначала будут объяснены шаги, необходимые для поиска, анализа и использования временных адресов. Затем будут показаны и объяснены будущие пригодные opcode-окна, а также методы, которыми можно определить информацию о времени цели до эксплуатации. Наконец, будут описаны и проанализированы примеры часто встречающихся временных адресов в Windows NT+, чтобы дать реальные примеры темы этого документа.

Однако перед началом важно понять некоторую терминологию, которая будет использоваться или, возможно, злоупотребляться ради передачи концепций. Термин "временный адрес" используется для описания места в памяти, содержащего какой-либо таймер. Термин "opcode" используется взаимозаменяемо с термином "инструкция" для обозначения набора пригодных байтов, которые могут частично составлять заданное временное состояние. Термин "период обновления" описывает количество времени, необходимое для изменения содержимого временного адреса. Наконец, термин "шкала" описывает единицу измерения для заданного временного адреса.

3. Поиск временных адресов

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

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

Чтобы показать осуществимость такой программы, автор реализовал алгоритм, который концептуально должен быть переносим на все платформы, хотя сама реализация ограничена Windows NT+. В общих чертах подход состоит в многократном опросе адресного пространства процесса и анализе его изменений во времени. Чтобы сократить объём проверяемой памяти, программа пропускает недоступные области и области, содержимое которых берётся из файла образа.

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

После завершения как минимум двух циклов опроса программа может сравнить различия кэшированных областей памяти между самым свежим видом адресного пространства целевого процесса и предыдущим видом. Это выполняется проходом по содержимому каждой кэшированной области памяти с шагом в четыре байта, чтобы увидеть, есть ли различие между двумя видами. Если временный адрес существует, содержимое двух видов должно иметь разницу не больше максимального периода времени, прошедшего между двумя циклами опроса. Важно помнить, что максимальный период можно передать вплоть до наносекундной гранулярности. Например, если период цикла опроса был 5 секунд, любой участок памяти, изменившийся более чем на 5 секунд, 5000 миллисекунд или 5000000 микросекунд, очевидно, не является кандидатом во временный адрес. Соответственно, любая область памяти, вообще не изменившаяся, также скорее всего не является кандидатом во временный адрес, хотя возможно, что область памяти просто имеет период обновления длиннее цикла опроса.

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

Сначала delta между циклами опроса вычисляется до наносекундной гранулярности. В лучшем случае гранулярность цикла опроса, отделенного 5 секундами, будет равна 5000000000 наносекунд. Однако небезопасно предполагать эту константу, поскольку планирование потоков и другие непостоянные параметры могут влиять на delta между циклами опроса для заданной области памяти. Следующий шаг - итеративно сравнивать разницу между двумя видами с текущей delta, чтобы увидеть, больше или равна ли разница текущей delta. Если да, можно предположить, что разница находится в текущей единице измерения. Если нет, текущую delta следует разделить на 10, чтобы перейти к следующей единице измерения. В разобранном виде постепенный переход между единицами измерения описан на рисунке 3.1.

Рисунок 3.1: сокращения измерения delta

После определения единицы измерения периода обновления разница делится на текущую delta, чтобы получить период обновления для заданного кандидата во временный адрес. Например, если разница была 5 и текущая delta была 5, период обновления кандидата во временный адрес составит 1 секунду (5 обновлений за 5 секунд). После определения периода обновления следующий шаг - попытаться определить емкость хранения кандидата во временный адрес.

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

После определения емкости хранения кандидата во временный адрес в байтах следующий шаг - определить шкалу, которую может передавать временный адрес (единицу измерения таймера). Для этого программа вычисляет число секунд с 1970 и 1601 годов между текущим временем минус как минимум период цикла опроса и самим текущим временем. Текущее значение кандидата во временный адрес (как оно хранится в памяти) затем преобразуется в секунды с использованием определенного периода обновления и сравнивается с двумя диапазонами времени эпохи. Если преобразованное текущее значение кандидата находится внутри любого из диапазонов времени эпохи, скорее всего можно предположить, что шкала кандидата во временный адрес измеряется от времени эпохи: либо от 1970, либо от 1601 года, в зависимости от того, в каком диапазоне оно находилось. Хотя такое сравнение довольно простое, можно внедрить любой другой произвольно сложный набор логики для обнаружения других типов временных шкал. Если ни одна логика не совпадает, считается, что кандидат во временный адрес просто имеет шкалу счетчика, как было определено ранее в этой главе.

Наконец, после определения периода, шкалы и емкости кандидата во временный адрес остается только проверить, эквивалентны ли эти три компонента ранее собранным компонентам для данного кандидата. Если они отличаются на порядки величины, вероятно, безопасно предположить, что кандидат на самом деле не является временным адресом. С другой стороны, согласованные компоненты между циклами опроса для кандидата во временный адрес почти наверняка говорят, что это действительно временный адрес.

Когда все сказано и сделано, программа должна собрать каждый временный адрес в целевом процессе, имеющий период обновления меньше или равный периоду цикла опроса. Она также должна определить шкалу и размер временного адреса. При запуске в Windows против программы, которая каждую секунду сохраняет текущее время эпохи с 1970 года в секундах в переменной, выводится следующее:

Расположения временных адресов:

Этот вывод сообщает нам, что адрес переменной, хранящей время эпохи с 1970 года, можно найти по 0x0012FF7C, и что она имеет период обновления в одну секунду. Остальные найденные элементы будут обсуждаться далее в документе.

3.1. Определение длительностей по байтам

После определения периода обновления и размера временного адреса можно вычислить, сколько времени требуется для изменения каждой байтовой позиции во временном адресе. Например, если в памяти найден четырехбайтовый временный адрес с периодом обновления 1 секунда, первый байт (или LSB) будет изменяться раз в секунду, второй байт - раз в 256 секунд, третий байт - раз в 65536 секунд, а четвертый байт - раз в 16777216 секунд. Эти свойства проявляются потому, что каждая байтовая позиция имеет 256 возможностей (от 0x00 до 0xff включительно). Это означает, что каждая байтовая позиция увеличивает длительность на 256 в заданной степени. Это можно описать, как показано на рисунке 3.2. Пусть x равен индексу байта, начиная с нуля для LSB.

Рисунок 3.2: независимые от периода байтовые длительности

Следующий шаг после определения длительностей байтов, специфичных для периода, - преобразовать длительности в более удобно доступную меру, предполагая период более гранулярный, чем секунда. Например, рисунок показывает, что если каждая байтовая длительность измеряется в интервалах по 100 наносекунд для 8-байтового временного адреса, можно применить преобразование из 100-наносекундных интервалов байтовой длительности в секунды.

Рисунок 3.3: 100-наносекундные байтовые длительности в секундах

Эта фаза особенно важна при вычислении пригодных opcode-окон, потому что нужно знать, как долго будет существовать пригодный opcode; это напрямую зависит от направления байта opcode, ближайшего к LSB. Это будет подробнее обсуждаться в главе 4.

4. Вычисление пригодных opcode-окон

После обнаружения набора временных адресов следующий логичный шаг - попытаться вычислить временные окна, в которых один или несколько пригодных opcode можно найти внутри байтов временного адреса. Не менее важно вычислить длительность каждого байта внутри временного адреса. Это именно та информация, которая нужна, чтобы определить, когда часть временного адреса можно использовать как адрес возврата для эксплойта. Для этого применяется подход с использованием уравнений из предыдущей главы для вычисления числа секунд, требуемого для изменения каждого байта на основе периода обновления заданного временного адреса. Используя функцию tosec для каждого индекса байта, можно создать таблицу, как показано на рисунке 4.1 для 100-наносекундного 8-байтового таймера.

Рисунок 4.1: 8-байтовые 100ns длительности по байтам в секундах

Это показывает, что любые opcode, начинающиеся с индекса байта 4, будут иметь окно времени в 7 минут и 9 секунд. Остается только понять, когда ударить.

5. Выбор времени удара

Время атаки полностью зависит и от периода обновления временного адреса, и от его шкалы. В большинстве случаев наиболее полезны временные адреса, шкала которых относительна произвольной дате, например 1970 или 1601 году, потому что их можно предсказать или определить с некоторой степенью уверенности. Тем не менее обобщенный подход можно использовать для определения прогнозируемых временных интервалов, где появятся полезные opcode.

Для этого сначала нужно определить набор инструкций, которые могут быть полезны для заданного эксплойта, например jmp esp. После определения следующий шаг - разбить инструкции на их сырые opcode, например 0xff 0xe4 для jmp esp. После сбора всех сырых opcode необходимо начать вычислять прогнозируемые временные интервалы, в которых появятся эти байты. Метод для этого довольно прост.

Сначала начальный индекс байта должен быть определен с точки зрения минимального приемлемого временного окна, которое может использовать эксплойт. В случае 100-наносекундного таймера лучшим индексом байта для начала будет индекс 4, поскольку все предыдущие индексы имеют длительность меньше или равную одной секунде. Байты, появляющиеся на индексе 4, имеют длительность 7 минут и 9 секунд, что делает их пригодными для использования. После определения начального индекса байта следующий шаг - создать перестановки всех последующих комбинаций байтов opcode. Проще говоря, это означает создание всех возможных комбинаций байтовых значений, которые содержат сырые opcode заданной инструкции на индексе байта, равном или большем начального индекса. Чтобы визуализировать это, рисунок 5.1 дает небольшой пример комбинаций байтов jmp esp относительно 100-наносекундного таймера.

Рисунок 5.1: 8-байтовые 100ns комбинации байтов jmp esp

После генерации всех перестановок следующий шаг - преобразовать их в осмысленные абсолютные представления времени. Это делается путем преобразования всех перестановок, которые представляют прошлые, будущие или текущие состояния временного адреса, в секунды. Например, одна из перестановок для инструкции jmp esp, найденной внутри 64-битного 100-наносекундного таймера, - 0x019de4ff00000000 (116500949249294300). Преобразование этого в секунды выполняется так:

Это говорит нам число секунд, которое пройдет, когда звезды сойдутся и сформируют эту комбинацию байтов, но не передает шкалу, в которой измеряются секунды, например основаны ли они на абсолютной дате (1970 или 1601) или просто выступают таймером. В данном случае, если шкала определена как число секунд с 1601 года, общее число секунд можно скорректировать так, чтобы оно указывало число секунд, прошедших с 1970 года, вычитанием постоянного числа секунд между 1970 и 1601 годами:

Это показывает, что с 1970 года пройдет всего 5621324 секунды, когда 0xff будет найден по индексу байта 4, а 0xe4 - по индексу байта 5. Окно возможности составит 7 минут и 9 секунд, после чего 0xff станет 0x00, 0xe4 станет 0xe5, и инструкция больше не будет пригодной. Если преобразовать 5621324 в печатный формат даты на основе числа секунд с 1970 года, можно увидеть, что дата появления этой конкретной перестановки - Fri Mar 06 19:28:44 CST 1970.

Хотя теперь показано, что вполне возможно предсказывать конкретные моменты в прошлом, настоящем и будущем, когда заданную инструкцию или инструкции можно найти внутри временного адреса, такая способность бесполезна без возможности предсказать или определить состояние временного адреса на целевом компьютере в конкретный момент. Например, хотя эксплуатационный хрономант знает, что jmp esp можно найти 6 марта 1970 года около 19:30, также нужно знать, на какое системное время настроена целевая машина с гранулярностью всего в секунды или хотя бы минуты. Хотя угадывание всегда вариант, почти наверняка оно будет менее плодотворным, чем использование существующих инструментов и служб, которые более чем готовы предоставить потенциальному атакующему информацию о текущем системном времени на целевой машине. Некоторые подходы к сбору этой информации будут обсуждаться в следующем разделе.

5.1. Определение системного времени

Существует ряд техник, которые потенциально можно использовать для определения системного времени целевой машины с разной степенью точности. Техники, перечисленные в этом разделе, ни в коем случае не исчерпывающие, но служат хорошей базой. Каждая техника будет раскрыта в следующих подразделах.

5.1.1. DCERPC SrvSvc NetrRemoteTOD

Один подход для получения очень гранулярной информации о текущем системном времени целевой машины - использовать запрос NetrRemoteTOD службы SrvSvc. Чтобы передать этот запрос целевой машине, нужно установить NULL-сессию или аутентифицированную сессию с помощью стандартного SMB-запроса Session Setup AndX. После этого следует выдать Tree Connect AndX к ресурсу IPC. Затем можно выдать NT Create AndX-запрос к именованному каналу. После успешной обработки запроса возвращенный файловый дескриптор можно использовать для DCERPC bind-запроса к UUID SrvSvc. Наконец, после успешного завершения bind-запроса можно выполнить NetrRemoteTOD через именованный канал с помощью запроса TransactNmPipe. Ответ на этот запрос должен содержать очень гранулярную информацию, такую как день, час, минута, секунда, часовой пояс, а также другие поля, необходимые для определения системного времени целевой машины. Рисунок показывает пример ответа.

Этот вектор очень полезен, потому что предоставляет простой доступ к полному состоянию системного времени целевой машины, которое затем можно использовать для вычисления временных окон, когда временный адрес может применяться при эксплуатации. Минусы этого подхода в том, что он требует доступа к SMB-портам (139 или 445), которые скорее всего будут недоступны атакующему.

5.1.2. Временные метки ICMP

Запрос ICMP TIMESTAMP (13) можно использовать для получения измеренного машиной числа миллисекунд, прошедших с полуночи UT. Если атакующий может вывести или предположить, что системное время целевой машины установлено на конкретную дату и часовой пояс, можно вычислить абсолютное системное время с разрешением до миллисекунды. Это удовлетворило бы требованиям к таймингу и позволило бы использовать временные адреса со шкалой, измеряемой от абсолютного времени. Однако согласно RFC, если система не может определить число миллисекунд с UT, она может использовать другое значение, способное представлять время, хотя должна установить старший бит, чтобы указать нестандартное значение.

5.1.3. Опция временной метки IP

Как и запрос ICMP TIMESTAMP, протокол IP имеет опцию временной метки (тип 68), которая измеряет число миллисекунд с полуночи по всемирному времени. Её также можно использовать, чтобы с разрешением до миллисекунды определить показания часов удалённой системы. Поскольку измеряется та же величина, ограничения совпадают с ограничениями ICMP TIMESTAMP.

5.1.4. HTTP-заголовок Date сервера

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

5.1.5. IRC CTCP TIME

Возможно, один из более слабых подходов к получению времени целевой машины - отправить CTCP TIME-запрос через IRC. Этот запрос предназначен для того, чтобы заставить отвечающую сторону вернуть читаемую строку даты относительно ее системного времени. Если ответ не подделан, он должен быть эквивалентен системному времени удаленной машины.

6. Определение адреса возврата

После завершения всей предварительной работы по вычислению всех пригодных opcode-окон и определения системного времени целевой машины последний шаг - выбрать следующее доступное окно для совместимой группы opcode. Например, если следующее окно для инструкции, эквивалентной jmp esp, - Sun Sep 25 22:37:28 CDT 2005, то нужно определить индекс байта к началу эквивалента jmp esp на основе сгенерированной перестановки. В этом случае сгенерированная перестановка, при предположении 100-наносекундного периода с 1601 года, была бы 0x01c5c25400000000. Это означает, что эквивалент jmp esp на самом деле является push esp, ret, который начинается с индекса байта четыре. Если начало временного адреса было по 0x7ffe0014, то адрес возврата, который следует использовать для выполнения push esp, ret, будет 0x7ffe0018. Этот базовый подход общий для всех временных адресов с разной емкостью, периодом и шкалой.

7. Практический пример: Windows NT SharedUserData

После всего общего фона можно показать реальное практическое применение этой техники через анализ области памяти, которая присутствует в каждом процессе Windows NT+. Эта область памяти называется SharedUserData и имеет обратно совместимый формат для всех версий NT, хотя со временем в конец добавлялись новые поля. Сейчас структура данных, представляющая SharedUserData, - KUSERSHAREDDATA, которая в Windows XP SP2 определяется следующим образом:

Одна из целей SharedUserData - предоставить процессам глобальный и согласованный метод получения определенной информации, которая может часто запрашиваться, тем самым делая это эффективнее, чем платить цену системного вызова. Более того, начиная с Windows XP SharedUserData действует как косвенный перенаправитель системных вызовов, так что можно использовать наиболее оптимизированные инструкции системного вызова на основе поддержки текущего оборудования, например sysenter вместо стандартного int 0x2e.

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

Три наиболее интересных поля, связанных со временем, - TickCountLow, InterruptTime и SystemTime. Эти три поля будут отдельно объяснены далее в этой главе. Однако перед этим важно понять некоторые свойства SharedUserData и почему она довольно полезна применительно к временным адресам.

7.1. Свойства SharedUserData

У SharedUserData есть ряд важных свойств; одни делают её полезной с точки зрения временных адресов, а другие в зависимости от эксплойта и аппаратной поддержки ограничивают её применимость. SharedUserData находится по постоянному адресу 0x7ffe0000 во всех версиях Windows NT+ и отображается в каждый процесс. Причина в том, что NTDLL и, вероятно, некоторые сторонние приложения скомпилированы и собраны в расчёте на фиксированный адрес SharedUserData. Этим свойством часто злоупотребляют при передаче управления из режима ядра в пользовательский режим. Кроме того, структура SharedUserData должна сохранять обратную совместимость: смещения существующих полей не меняются, а новые поля лишь добавляются в конец. Наконец, некоторые продукты для Windows реализуют ту или иную разновидность ASLR. Однако SharedUserData практически невозможно рандомизировать — по крайней мере, автору неизвестен способ сделать это без серьёзного ущерба производительности.

С отрицательной стороны, и возможно одним из самых ограничивающих факторов при использовании SharedUserData, является то, что у нее есть null-байт на индексе байта один. В зависимости от уязвимости может быть возможно или невозможно использовать атрибут внутри SharedUserData как адрес возврата из-за ограничений на NULL-байты. Начиная с XP SP2 и 2003 Server SP1, SharedUserData больше не помечается как исполняемая и приведет к нарушению DEP, если DEP включена и если оборудование поддерживает PAE. Хотя это пока не очень распространено, со временем это наверняка станет нормой.

7.2. Поиск временных адресов

Как было видно ранее в документе, использование программы telescope для любого Windows-приложения приведет к отображению тех же двух или трех таймеров:

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

7.2.1. TickCountLow

Атрибут TickCountLow используется в сочетании с TickCountMultiplier, чтобы передавать число миллисекунд, прошедших с загрузки системы. Для вычисления числа миллисекунд с загрузки системы используется следующее уравнение:

Этот атрибут представляет временной адрес со шкалой счётчика. Отсчёт начинается в неизвестный момент, а значение растёт с постоянными интервалами. Главная проблема — именно величина этих интервалов: две стоящие рядом машины с разным оборудованием могут иметь разные периоды обновления TickCountLow. Поэтому использовать его как временной адрес трудно, поскольку период обновления нельзя надёжно предсказать. Возможно, время работы машины удастся определить по временным меткам TCP или иным способом, но без знания периода обновления TickCountLow всё равно мало пригоден.

Этот атрибут расположен по 0x7ffe0000 во всех версиях Windows NT+.

7.2.2. InterruptTime

Этот атрибут используется для хранения 100-наносекундного таймера, начинающегося при загрузке системы, который предположительно считает объем времени, потраченного на обработку прерываний. Сам атрибут хранится как структура KSYSTEMTIME, определенная так:

В зависимости от оборудования, на котором работает машина, период InterruptTime может быть точно равен 100 наносекундам. Однако тестирование, похоже, подтверждает, что это не всегда так. С учетом этого и период обновления, и шкалу атрибута InterruptTime следует считать ограничивающими факторами. Этот факт делает его менее полезным, поскольку он имеет те же ограничения, что и атрибут TickCountLow. В частности, без знания того, когда система загрузилась и когда счетчик стартовал, или сколько времени было потрачено на обработку прерываний, невозможно надежно предсказать, когда определенные байты окажутся на определенных смещениях. Кроме того, машина должна была бы быть загружена значительное время, чтобы некоторые полезные инструкции можно было практически найти внутри байтов, составляющих таймер.

Этот атрибут расположен по 0x7ffe0008 во всех версиях Windows NT+.

7.2.3. SystemTime

Атрибут SystemTime на сегодняшний день самый полезный с точки зрения качеств временного адреса. Сам атрибут - 100-наносекундный таймер, измеряемый от 1 января 1601 года и хранящийся как структура KSYSTEMTIME, как и атрибут InterruptTime. Определение структуры см. в подразделе InterruptTime. Это означает, что он имеет период обновления 100 наносекунд и шкалу, измеряемую от 1 января 1601 года. Шкала также измеряется относительно часового пояса, используемого машиной, исключая летнее время. Если атакующий способен получить информацию о системном времени на целевой машине, может быть возможно использовать атрибут SystemTime как действительный временный адрес для целей эксплуатации.

Этот атрибут расположен по 0x7ffe0014 во всех версиях Windows NT+.

7.3. Вычисление пригодных opcode-окон

После анализа SharedUserData на временные адреса должно стать ясно, что атрибут SystemTime на сегодняшний день самый полезный и потенциально осуществимый из-за своей шкалы и периода обновления. Однако чтобы успешно использовать его вместе с эксплойтом, нужно вычислить пригодные opcode-окна, чтобы выбрать время удара. Это можно сделать до определения фактической даты на целевой машине, но требуется знать емкость хранения (размер временного адреса в байтах), период обновления и шкалу. В данном случае размер атрибута SystemTime - 12 байтов, хотя в реальности третий атрибут, High2Time, точно такой же, как второй, High1Time, поэтому действительно важны только первые 8 байтов. Выполнение вычислений для длительностей по байтам дает результаты, показанные на рисунке. Это указывает, что стоит сосредоточиться только на перестановках opcode, начинающихся с индекса байта четыре, поскольку все предыдущие индексы байтов имеют длительность меньше или равную одной секунде. Применяя шкалу как измеряемую с 1 января 1601 года, можно вычислить все возможные перестановки для прошлого, настоящего и будущего, как описано в главе. Результаты этих вычислений для атрибута SystemTime описаны в следующих абзацах.

Чтобы вычислить пригодные opcode-окна, необходимо определить пригодный набор opcode. В этом практическом примере использовалось в общей сложности 320 пригодных opcode; напомним, что opcode в данном случае может означать одну или несколько инструкций. Эти пригодные opcode были взяты из Metasploit Opcode Database. После выполнения необходимых вычислений и генерации всех перестановок между 1 января 1970 года и 23 декабря 2037 года было найдено 3615 пригодных opcode-окон. Каждый пригодный opcode был разбит на группы похожих или эквивалентных opcode, чтобы упростить визуализацию.

При внимательном рассмотрении этих рисунков видно, что около 2002 и 2003 годов были два больших всплеска для группы опкодов [esp + 8] => eip, включающей последовательности pop/pop/ret, распространённые при перезаписи SEH. Более пристальный взгляд показывает, что в эти годы существовали два значительных периода, когда определённые эксплойты могли использовать SystemTime как временной адрес возврата. На рисунке эти всплески показаны подробнее. Жаль, что техника не была опубликована тогда: за время жизни читателей статьи такое событие больше не повторится.

Возможно, больший интерес, чем прошлые появления определенных групп opcode, представляет то, что случится в будущем. Таблица на рисунке 7.1 показывает предстоящие пригодные opcode-окна для 2005 года.

Рисунок 7.1: opcode-окна за сентябрь 2005 - январь 2006

8. Практический пример: пример приложения

Помимо того, что в процессах Windows присутствует SharedUserData, в зависимости от конкретного приложения также может быть возможно найти другие временные адреса по статическим расположениям в разных версиях операционной системы. Возьмем, например, следующую программу, которая просто каждую секунду вызывает time и сохраняет результат в локальной переменной на стеке с именем t:

Когда программа telescope запускается против работающего экземпляра этого примера, получаются такие результаты:

Судя по исходному коду примера приложения, кажется очевидным, что адрес 0x0012ff7c совпадает с локальной переменной t, используемой для хранения числа секунд с 1970 года. Действительно, переменная t также имеет период обновления в одну секунду, как указано программой telescope. Остальные находки могут быть либо неточными, либо бесполезными в зависимости от конкретной ситуации, но тот факт, что они были определены как счетчики, а не как значения относительно одной из двух эпох, скорее всего делает их непригодными.

Чтобы написать эксплойт, который может использовать временный адрес t, сначала нужно выполнить шаги, описанные в этом документе, относительно вычисления длительности каждого индекса байта и затем построить список всех пригодных перестановок opcode. Длительность каждого индекса байта для четырехбайтового таймера с периодом в одну секунду показана на рисунке 8.1.

Рисунок 8.1: 4-байтовые 1sec длительности по байтам в секундах

Начальный индекс байта для этого временного адреса - байтовый индекс один, поскольку он имеет наименьшее пригодное временное окно для запуска эксплойта (4 минуты 16 секунд). После определения этого начального индекса можно генерировать перестановки для всех пригодных opcode.

Почти все пригодные opcode-окна имеют окно в 4 минуты. Лишь немногие имеют окно в 18 часов. Чтобы лучше понять, что будущее готовит для такого таймера, таблица 8.2 показывает предстоящие пригодные opcode-окна для 2005 года.

Рисунок 8.2: opcode-окна за сентябрь 2005 - январь 2006

9. Заключение

Временные адреса - это места в памяти, связанные с каким-либо таймером, например переменная, хранящая число секунд с 1970 года. Как часы, временные адреса имеют период обновления, то есть скорость, с которой меняется их содержимое. Они также имеют врожденную емкость хранения, ограничивающую объем времени, который они могут передавать до переполнения и возврата к началу. Наконец, временные адреса всегда имеют связанную с ними шкалу, указывающую единицу измерения содержимого временного адреса: например, используется ли он просто как счетчик или измеряет число секунд с 1970 года. Эти три атрибута вместе можно использовать для предсказания того, когда определенные комбинации байтов появятся внутри временного адреса.

Этот тип предсказания полезен, потому что может дать эксплуатационному хрономанту возможность дождаться правильного времени и затем ударить, когда предсказанные комбинации байтов появятся в памяти на целевой машине. В частности, наиболее полезными комбинациями байтов будут те, которые представляют полезные opcode или инструкции, способные использоваться для получения контроля над потоком выполнения и позволить атакующему эксплуатировать уязвимость. Такая способность может дать дополнительное преимущество, предоставив атакующему универсальные адреса возврата в ситуациях, где временный адрес найден по статическому расположению в памяти в нескольких версиях операционной системы и приложения.

Эксплуатационный хрономант - это тот, кто способен предсказывать лучшее время для эксплуатации чего-либо на основе выравнивания определенных байтов, естественно возникающих в адресном пространстве процесса. Используя техники, описанные в этом документе, или, возможно, те, которые еще предстоит описать или раскрыть, те, кто еще не пробовал себя в области хрономантии, могут начать пробовать воду. Пригодные opcode-окна будут приходить и уходить, но полезность временных адресов останется навечно - или по крайней мере пока существуют компьютеры в известном нам виде.

Факт в том, что хотя обсуждаемая в этом документе тема может иметь внутреннюю ценность, вероятность ее использования для реальной эксплуатации стремится к нулю из-за вариативности и задержек между пригодными opcode-окнами для разных периодов и шкал временных адресов. Или это действительно настолько маловероятно? Vlad902 предложил сценарий, в котором атакующий мог бы скомпрометировать NTP-сервер и настроить его так, чтобы он постоянно возвращал время, содержащее полезный opcode для целей эксплуатации. Все машины, синхронизирующиеся со скомпрометированным NTP-сервером, в итоге получили бы предсказуемое системное время. Хотя это не полностью надежно, учитывая, что не всегда известно, как часто NTP-клиенты будут синхронизироваться (хотя можно использовать журналы), это тем не менее интересный подход. Независимо от осуществимости, рабыня-знание требует свободы, и так оно и будет.

Библиография

Mesander, Rollo, and Zeuge. The Client-To-Client Protocol (CTCP). <http://www.irchelp.org/irchelp/rfc/ctcpspec.html>; дата обращения: 5 августа 2005.

Postel, J. RFC 792 - Internet Control Message Protocol. <http://www.ietf.org/rfc/rfc0792.txt?number=792>; дата обращения: 5 августа 2005.

Аннотация: статья знакомит читателя с перенаправлением ассоциации и показывает, как с его помощью реализовать в обычной сети IEEE 802.11 аналог VLAN проводных сетей. Способ не требует нарушать стандарт на стороне клиента: достаточно немного изменить точку доступа (AP), не затрагивая протокол управления доступом к среде 802.11. Автор надеется не только объяснить конкретный приём, но и показать, как нестандартно использовать особенности протоколов.

2. Необходимые сведения

Спецификация IEEE 802.11 определяет три последовательных состояния клиента. Для подключения к точке доступа он переходит из состояния 1 в 2 после успешной аутентификации — даже если защита сети отключена, — а затем посредством ассоциации из состояния 2 в 3. Только после этого клиент может передавать данные через точку доступа.

В отличие от Ethernet, 802.3 и других протоколов канального уровня, заголовок 802.11 содержит не менее трёх адресов: источника, назначения и идентификатор базового набора служб (BSSID). Удобно понимать BSSID как поле «через кого». В пакете для самой точки доступа адрес назначения совпадает с BSSID. Если же получатель — другой узел той же беспроводной сети, BSSID указывает на точку доступа, а адрес назначения — на конечный узел.

Согласно диаграмме состояний стандарта, получив ответ на ассоциацию с новым BSSID, клиент должен переключиться на него. Отправка такого ответа называется перенаправлением ассоциации. Первоначальное назначение особенности неясно, но с её помощью можно динамически создавать персональную виртуальную мостовую сеть (PVLAN).

3. Введение

Главная причина виртуализировать точки доступа — безопасность. Известны два подхода, хотя на практике был развёрнут только один: технология виртуальных точек доступа компании Colubris.

Другой подход — общедоступная точка доступа (PAP) и персональные виртуальные мостовые сети (PVLAN) — описан в патентной заявке США № 20040141617 и рассматривается в статье.

3.1. Состояние дел

Устройство Colubris реализует для каждой виртуальной точки независимый уровень управления доступом 802.11, уникальный BSSID и собственную базу управляющей информации (MIB); общим остаётся лишь оборудование. Решение подходит для строго управляемой статической среды с заранее известными пользователями и группами. Каждый пользователь должен знать нужный SSID и учётные данные. Виртуальные точки можно сопоставлять сетям VLAN 802.1q.

PAP лучше подходит для слабо управляемых сетей. Она передаёт один кадр маяка, а при попытке ассоциации перенаправляет клиента на динамически созданный виртуальный BSSID (VBSSID), помещая его в отдельную PVLAN. Это удобно в публичной точке доступа, где пользователи не доверяют друг другу, а их число заранее неизвестно. Способ совместим с традиционными VLAN 802.1q, но его главное достоинство — низкая административная нагрузка при минимальной инфраструктуре и обычном канале общего доступа.

4. PVLAN и виртуальные BSSID

PVLAN называется персональной мостовой VLAN, потому что создаётся динамически для конкретного клиента. Его подключение определяет появление и срок жизни сети; обычно в одной PVLAN находится единственный клиент.

Точка доступа PAP намеренно перенаправляет каждого подключающегося клиента на собственный динамически созданный виртуальный BSSID (VBSSID).

В примере ниже AP транслирует публичный BSSID 00:11:22:33:44:55 и перенаправляет клиента на его собственный VBSSID 00:22:22:22:22:22.

5. Эксперимент

Эксперимент не являлся полноценной реализацией PAP. Его цель — проверить разные наборы микросхем, платы и драйверы на соответствие стандарту и реакцию на перенаправление ассоциации. Для каждой платы испытывались все разумные варианты трактовки стандарта.

Для опыта были внесены небольшие изменения в драйвер host-ap для Linux. Он способен работать и как точка доступа, и как клиент, но правки затронули только первый режим и не повлияли на работу клиентской части.

Опыт состоял из двух этапов. Сначала host-ap изменял во всех управляющих кадрах адрес источника, BSSID либо оба поля одновременно. Результаты приведены в первой таблице.

Затем ответы аутентификации стали передаваться без изменений, поскольку многие платы просто игнорировали искажённые ответы. Эти результаты находятся во второй таблице.

5.1. Результаты

Реакции в первой таблице варьируются от невозможности покинуть состояние 1 до успешного перенаправления. Особенно интересны три драйвера, достигшие состояния 3. Метка ORIGINALBSSID означает ожидаемое поведение: устройство игнорирует перенаправление и продолжает передачу через BSSID PAP. REDIRECTREASSOC означает успешный переход на VBSSID, но с периодическими запросами повторной ассоциации к исходному BSSID PAP.

Вариант SCHIZO тоже достигает состояния 3: плата принимает данные через BSSID PAP, но отправляет через VBSSID и, по-видимому, игнорирует всё, что приходит на VBSSID.

Во второй серии поля не изменялись до запроса ассоциации, поэтому клиенты уже не могли отбрасывать искажённые ответы аутентификации. Это выявило ещё несколько интересных реакций.

Apple AirPort Extreme ответила потоком кадров деаутентификации к нулевому BSSID с адресом точки доступа (DEAUTHFLOOD). Единственной другой платой, отправившей деаутентификацию, стала Atheros: один кадр к исходному BSSID (SIMPLEDEAUTHSTA).

При поведении DUALBSSID платы чередуют два BSSID в последовательных передаваемых пакетах. Неизвестно, продолжается ли это всё соединение либо является способом выбрать тот BSSID, с которого раньше придут данные.

Результаты оказались неожиданными. Предполагалось, что большинство плат либо не достигнет состояния 3, либо останется на исходном BSSID. На деле многие удалось перевести в режим двух BSSID, а два драйвера для набора микросхем Hermes успешно перенаправились.

6. Будущая работа

Перенаправление позволяет поддельной точке доступа незаметно для администратора перехватить ассоциацию клиента. Злоумышленник запускает изменённый host-ap на машине Linux без передачи маяков, ждёт запроса к законной точке и пытается первым отправить ответ. Он также может предварительно деаутентифицировать клиента, а затем выиграть эту гонку.

Другой вопрос — устойчивость PAP к отказу в обслуживании путём создания огромного числа VBSSID. По мнению автора, подходящий алгоритм может сделать атаку слишком затратной. Если завершать срок жизни PVLAN и VBSSID в зависимости от времени и трафика, атакующему придётся постоянно поддерживать каждую созданную сущность, а не просто порождать новые.

7. Заключение

Из-за различий между производителями метод вряд ли подходит для универсального развёртывания PVLAN. Зато решительный атакующий способен встроить результаты эксперимента в изменённый host-ap и незаметно перенаправлять трафик себе. В отличие от отравления ARP, это не создаёт подозрительной ARP-активности, а в отличие от обычной поддельной точки доступа — не требует легко обнаруживаемых кадров маяка.

8. Библиография

Volpano, Dennis. United States Patent Application 200403141617 July 22, 2003 <http://appft1.uspto.gov/netahtml/PTO/search-adv.html>

Institute of Electrical and Electronics Engineers.

Aboba, Bernard. Virtual Access Points (IEEE document IEEE 802.11-03/154r1) May 22, 2003 <http://www.drizzle.com/> aboba/IEEE/11-03-154r1-I-Virtual-Access-Points.doc

Colubris Networks. Virtual Access Point Technology Multiple WLAN Services <http://www.colubris.com/literature/whitepapers.asp>; дата обращения: 09 августа 2005.

DEP может работать в двух режимах. Первый — программная DEP — предоставляет довольно ограниченную защиту от эксплойтов, перезаписывающих структурированный обработчик исключений (Structured Exception Handler, SEH). Она применяется на компьютерах, которые из-за аппаратных ограничений не поддерживают настоящие невыполняемые страницы. Кроме того, программная DEP обеспечивается на этапе компиляции и потому обычно действует лишь в системных библиотеках и отдельных сторонних приложениях, пересобранных с её поддержкой. Обход этого режима уже обсуждался ранее и не является темой статьи.

Второй режим работы DEP называется аппаратно реализованной DEP. Этот режим является надмножеством программно реализованной DEP и используется на оборудовании, поддерживающем пометку страниц как невыполняемых. Хотя большая часть существующего оборудования на базе Intel не имеет такой возможности из-за исторической поддержки только пометки страниц как доступных для чтения или записи, более новые наборы микросхем начинают получать настоящую аппаратную поддержку через механизмы вроде Page Address Extensions (PAE). Аппаратно реализованная DEP является более интересным из двух режимов, поскольку ее можно рассматривать как реальный фактор смягчения большинства распространенных векторов эксплуатации. Техника обхода, описанная в этом документе, предназначена для использования именно против этого режима.

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

Реализуя поддержку DEP, Microsoft справедливо поняла, что многие существующие сторонние приложения могут столкнуться с серьезными проблемами совместимости из-за предположений о том, является ли выделенная область памяти выполняемой. Чтобы справиться с этой ситуацией, Microsoft спроектировала DEP так, чтобы ее можно было настраивать несколькими способами. На самом общем уровне DEP имеет параметр по умолчанию, указывающий, включена ли защита от выполнения только для системных процессов и специально определенных приложений (OptIn), или же она включена для всего, кроме явно исключенных приложений (OptOut). Эти два флага передаются ядру во время загрузки через параметр /NoExecute в boot.ini. Кроме того, как часть параметра NoExecute можно передать еще два флага, указывающие, что DEP должна быть AlwaysOn или AlwaysOff. Эти две настройки принудительно устанавливают для каждого процесса флаг, который навсегда включает или отключает DEP. Настройка по умолчанию в Windows XP SP2 — OptIn, а в Windows 2003 Server SP1 — OptOut.

Помимо общесистемного параметра, DEP можно включать или отключать отдельно для каждого процесса. Решение об отключении поддержки невыполняемых страниц (NX) принимается во время выполнения. Для этого в ntdll.dll добавлена внутренняя процедура LdrpCheckNXCompatibility. Она вызывается при каждой загрузке DLL в контекст процесса через LdrpRunInitializationRoutines и проверяет несколько условий. Сначала определяется, не загружается ли библиотека SafeDisc: если да, NX для процесса следует отключить. Затем база данных приложений проверяется на явное указание включить или отключить NX. Наконец, процедура ищет в загружаемой DLL секцию, несовместимую с NX, например .aspack, .pcle или .sforce.

В результате этих проверок поддержка NX включается или отключается через новый PROCESSINFOCLASS с именем ProcessExecuteFlags (0x22). Когда вызывается NtSetInformationProcess с этим классом информации, в качестве параметра буфера передается четырехбайтовая битовая маска. Эта битовая маска передается в nt!MmSetExecuteOptions, которая выполняет соответствующую операцию. Необязательно в составе битовой маски также может быть указан флаг MEM_EXECUTE_OPTION_PERMANENT, или 0x8, означающий, что будущие вызовы функции должны завершаться ошибкой, чтобы флаги выполнения больше нельзя было изменить. Чтобы включить поддержку NX, указывается флаг MEM_EXECUTE_OPTION_DISABLE (0x1). Чтобы отключить поддержку NX, указывается флаг MEM_EXECUTE_OPTION_ENABLE (0x2). В зависимости от состояния этих флагов конкретного процесса выполнение кода из невыполняемых областей памяти будет либо разрешено (MEM_EXECUTE_OPTION_ENABLE), либо запрещено (MEM_EXECUTE_OPTION_DISABLE).

Если бы атакующий каким-либо образом мог изменить флаги выполнения эксплуатируемого процесса, из этого следовало бы, что он смог бы выполнять код из ранее невыполняемых областей памяти. Однако для этого атакующему пришлось бы выполнить код из областей памяти, которые уже являются выполняемыми. По счастливому стечению обстоятельств полезные выполняемые области памяти существуют, причем они находятся по одному и тому же адресу в каждом процессе [2].

Чтобы воспользоваться этой возможностью, атакующий должен каким-то образом вызвать NtSetInformationProcess с информационным классом ProcessExecuteFlags. Кроме того, параметр ProcessInformation должен быть установлен в битовую маску, в которой установлен бит MEM_EXECUTE_OPTION_ENABLE, но не установлен бит MEM_EXECUTE_OPTION_DISABLE. Следующий код иллюстрирует вызов этой функции, который отключил бы поддержку NX для вызывающего процесса:

Один из способов добиться этого — использовать атаку, производную от ret2libc, при которой поток управления передается в функцию NtSetInformationProcess, а на стеке подготовлен кадр, контролируемый атакующим. В этом случае аргументы, описанные справа в приведенном выше фрагменте кода, пришлось бы разместить на стеке так, чтобы они были правильно интерпретированы при начале выполнения NtSetInformationProcess. Самый большой недостаток этого подхода в том, что он требует возможности использовать NULL-байты как часть буфера, применяемого для переполнения. В общем случае это невозможно, особенно при любом переполнении, вызванном использованием строковой функции. Однако когда это возможно, такой подход определенно может быть полезен.

Хотя прямой возврат в NtSetInformationProcess может быть не всегда применим, можно использовать другую технику, которая в большей степени подходит для общего случая. При таком подходе атакующий может воспользоваться уже существующим в ntdll кодом для отключения поддержки NX для процесса. Возвращаясь в конкретный фрагмент кода, можно отключить поддержку NX так же, как это сделала бы ntdll, и при этом все еще передать управление обратно в буфер, контролируемый пользователем. Единственное ограничение состоит в том, что атакующий должен иметь возможность управлять стеком способом, похожим на большинство атак в стиле ret2libc, но без необходимости управлять аргументами.

Первый шаг в этом процессе — заставить управление перейти в место памяти, выполняющее операцию, эквивалентную комбинации mov al, 0x1 / ret. Существует много экземпляров похожих инструкций (xor eax, eax / inc eax / ret; mov eax, 1 / ret и так далее). Один такой экземпляр можно найти в функции ntdll!NtdllOkayToLockRoutine.

Это устанавливает младший байт eax в единицу по причинам, которые станут понятны на следующем шаге. После передачи управления на инструкцию mov, а затем на последующую инструкцию ret, атакующий должен подготовить стек так, чтобы инструкция ret фактически вернулась в другой участок кода внутри ntdll. В частности, она должна вернуться в середину процедуры ntdll!LdrpCheckNXCompatibility.

В этом блоке выполняется проверка, установлен ли младший байт eax в единицу. Независимо от результата esi инициализируется значением 2. После этого выполняется проверка, установлен ли флаг нуля, что произошло бы, если младший байт eax равен 1. Поскольку этот код будет выполнен после первого набора инструкций mov al, 0x1 / ret, флаг ZF всегда будет установлен, и управление будет передано на 0x7c93feba.

Этот блок записывает содержимое esi в локальную переменную, в данном случае значение 2. Затем он передает управление на 0x7c91d403.

Этот блок, в свою очередь, сравнивает только что инициализированную значением 2 локальную переменную с 0. Если она не равна нулю, а она не равна, управление передается на 0x7c935d6d.

Именно здесь все становится интересным. В этом блоке выполняется вызов NtSetInformationProcess с информационным классом ProcessExecuteFlags. Передается указатель параметра ProcessInformation, который ранее был инициализирован значением 2 [3]. В результате поддержка NX для процесса отключается. После завершения вызова управление передается на 0x7c91d441.

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

Этот подход требует знания трех адресов. Во-первых, должен быть известен адрес эквивалента mov al, 0x1 / ret. К счастью, существует много вхождений такого типа блока, хотя они могут быть не столь простыми, как описанный в этом документе. Во-вторых, должен быть известен адрес начала блока cmp al, 0x1 внутри ntdll!LdrpCheckNXCompatibility. Поскольку используется зависимость от двух адресов внутри ntdll, можно ожидать, что эксплойт будет более переносимым, чем при зависимости от адресов из двух разных DLL. Наконец, третий адрес — это тот, который обычно использовался бы на целях без аппаратно реализованной DEP, например jmp esp или эквивалентная инструкция в зависимости от конкретной уязвимости.

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

Чтобы проверить этот подход, авторы изменили эксплойт warftpd_165_user из Metasploit Framework, написанный Fairuzan Roslan. Эта уязвимость представляет собой простое переполнение стека. До наших изменений эксплойт был реализован следующим образом:

Этот код создавал дорожку NOP длиной 1024 байта. По смещению 485 записывался адрес возврата, после чего добавлялся шеллкод [4]. При запуске против цели с аппаратной DEP эксплойт терпит неудачу на первой инструкции дорожки NOP, поскольку стек потока помечен как невыполняемая область памяти.

Применив описанную выше технику, авторы изменили эксплойт так, чтобы он отправлял буфер следующей структуры:

В этом случае был построен буфер, содержащий 485 инструкций int3. Затем буфер настраивался так, чтобы перезаписать адрес возврата указателем на ntdll!NtdllOkayToLockRoutine. Поскольку эта процедура выполняет retn 0x4, следующие четыре байта являются заполнением в роли фиктивного аргумента, который снимается со стека. После возврата из NtdllOkayToLockRoutine стек будет указывать на смещение 493 байта внутри создаваемого буфера evil, сразу после перезаписи адреса возврата 0x7c952080 и фиктивного аргумента. Это означает, что NtdllOkayToLockRoutine вернется в 0x7c91d3f8. Этот блок кода оценивает младший байт eax и в конечном итоге приводит к отключению поддержки NX для процесса. После завершения блок снимает со стека сохраненные регистры и выполняет инструкцию leave, перемещая указатель стека туда, куда в данный момент указывает ebp. В этом случае ebp находился на расстоянии 0x54 байта от esp, поэтому мы вставили 0x54 байта заполнения. После выполнения этого блока указатель стека будет указывать на смещение 577 байтов внутри буфера evil, сразу после 0x54 байтов заполнения. Это означает, что он вернется по тому адресу, который хранится в этой позиции. В данном случае буфер заполнен так, что он просто возвращается по указанному для цели адресу возврата, который является эквивалентом инструкции jmp esp. Далее выполняется инструкция jmp esp, передающая управление shellcode, который следует сразу за ней. После выполнения эксплойт работает так, будто ничего не изменилось:

Как видно, техника, описанная в этом документе, показывает практичный метод, который можно использовать для обхода защитных улучшений, предоставляемых аппаратно реализованной DEP в стандартных установках Windows XP Service Pack 2 и Windows 2003 Server Service Pack 1. Сам недостаток не связан с какой-либо конкретной неэффективностью или ошибкой, допущенной при фактической реализации поддержки аппаратно реализованной DEP, а является побочным эффектом проектного решения Microsoft предоставить механизм отключения поддержки NX для процесса изнутри процесса пользовательского режима. Если бы не существовало механизма, позволяющего отключать поддержку NX во время выполнения изнутри процесса, подходы, описанные в этом документе, были бы неприменимы.

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

Первую зависимость можно было бы разрушить, внедрив некоторую форму Address Space Layout Randomization, которая сделала бы расположение зависимых блоков кода неизвестным атакующему. Вторую зависимость можно было бы разрушить, перенеся логику, управляющую включением и отключением поддержки NX для процесса, в режим ядра, чтобы на нее нельзя было влиять настолько напрямую. Этот подход несколько сложен, поскольку модель, в которой это реализовано сейчас, требует возможности отключать поддержку NX при наступлении определенных событий, например при загрузке несовместимой DLL. Хотя это может быть сложнее, авторы считают такой подход наиболее осуществимым с точки зрения совместимости. Наконец, последняя зависимость в действительности не является тем, что Microsoft может контролировать. Помимо этих потенциальных решений, возможно, также удалось бы придумать способ устанавливать постоянный флаг раньше во время инициализации процесса, хотя авторы не уверены, как это можно сделать без поломки поддержки отключения при загрузке определенных DLL.

В заключение авторы хотели бы специально подчеркнуть, что Microsoft проделала отличную работу, подняв планку своими улучшениями безопасности в XP Service Pack 2. Технику, изложенную в этом документе, не следует рассматривать как случай, когда Microsoft не смогла реализовать что-то безопасно: средства для безопасного развертывания аппаратно реализованной DEP определенно присутствуют. Скорее ее можно считать уступкой, сделанной ради сохранения совместимости приложений в общем случае. Почти всегда существует компромисс между предоставлением новых возможностей безопасности и потенциальными проблемами совместимости, и, пожалуй, ни одна компания, кроме Microsoft, не известна сохранением обратной совместимости в такой степени.

Примечания

[1] Существуют и другие документированные техники обхода защит от выполнения кода, например возврат в ZwProtectVirtualMemory или цепочечная атака в стиле ret2libc, но такие подходы обычно сложнее и во многих случаях сильнее ограничены из-за необходимости использовать байты, которые в типичных ситуациях были бы недоступны, например NULL-байты.

[2] С несколькими параметрами, которые будут обсуждаться далее.

[3] Причина, по которой это должно указывать именно на 2, а не на какое-либо целое число, у которого только младший байт установлен в 2, состоит в том, что nt!MmSetExecutionOptions выполняет проверку, гарантирующую, что неиспользуемые биты не установлены.

[4] В действительности перезаписываться может не адрес возврата, а указатель на функцию. Тот факт, что он находится по невыровненному адресу, говорит в пользу этого предположения, хотя, конечно, не является явным указанием.

[5] Это возможно даже при использовании перезаписи SEH, если соблюдены нужные условия. Базовый подход состоит в том, чтобы найти набор инструкций pop reg, pop reg, pop esp, ret в области, не защищенной SafeSEH, например в сторонней DLL, которая не была скомпилирована с /GS. Инструкция pop esp сдвигает стек к началу EstablisherFrame, контролируемого атакующим, а ret возвращает управление по адресу, хранящемуся в перезаписанном указателе Next. Если установить указатель Next на расположение NtdllOkayToLockRoutine и подготовить стек описанным выше способом, техника обхода аппаратно реализованной DEP, описанная в этом документе, может заработать.

Библиография

The Metasploit Project. Переполнение USER в War-ftpd 1.65. <http://www.metasploit.com/projects/Framework/exploits.html#warftpd_165_user>; дата обращения: 2 октября 2005 г.

Microsoft Corporation. Data Execution Prevention. <http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/b0de1052-4101-44c3-a294-4da1bd1ef227.mspx>; дата обращения: 2 октября 2005 г.

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

Отказ от ответственности: этот документ написан в образовательных целях, и я не могу нести ответственность за любые последствия публикации данной информации.

Благодарности: #vax, nologin и jimmy haffa.

Введение

О целочисленных переполнениях написано немало, но их эксплуатацию внутри бинарных анализаторов рассматривают редко. Недавней волны уведомлений iDefense (Clam AV, Adobe Acrobat), eEye (Macromedia, Windows Metafile) и Алекса Уилера на Rem0te.com (несколько антивирусов) должно быть достаточно, чтобы всерьёз отнестись к ошибкам файловых форматов.

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

Файл хранения сертификатов

Следующий файловый формат был спроектирован и написан специально для этой статьи и не имеет реального практического применения. Общая идея реализации этого файлового формата состоит в создании одного бинарного файла, выступающего в роли доступной для поиска базы данных файлов сертификатов. Файл будет состоять из двух основных структур, которые будут хранить информацию, необходимую для разбора сертификатов в формате DER. Вот примерная схема того, как файл выглядит после компиляции:

Бинарная компоновка

В библиотеке-компиляторе этого файлового формата определены следующие структуры.

Первая структура данных состоит из двух беззнаковых целых: NumberOfCerts (short) и PointerToCerts (long). Они хранят общее число сертификатов в данном бинарном файле, NumberOfCerts, и смещение от начала файла до первой структуры данных сертификата CERTDATA, PointerToCerts. Уже можно предположить, что парсер будет проходить по образу файла NumberOfCerts раз, начиная с PointerToCerts и двигаясь порциями размером с CERTDATA. Вторая структура данных состоит из массива символов размером 8 байт, который используется для хранения первых 7 символов описания сертификата, за которым следуют два беззнаковых коротких целых. Они соответственно хранят длину сертификата, на который ссылается эта структура, и смещение до начала сертификата. Последний элемент является unsigned char, который компилятор использует для переноса тела сертификата.

Прикладные примеры

По мере уменьшения числа переполнений буфера растёт доля целочисленных переполнений и ошибок разбора файлов и бинарных протоколов. Запрос к открытой базе уязвимостей OSVDB хорошо показывает разнообразие затронутых приложений. Список короче реального числа публикаций за последние годы, но охватывает ядра, библиотеки, протоколы и файловые форматы.

<http://osvdb.org/searchdb.php?action=search_title&vuln_title=integer+overflow&Search=Search>

Для демонстрации я разработал библиотеку разбора описанного формата; код приведён в приложении A. Она объединяет сертификаты в один файл и намеренно содержит несколько ошибок, взятых из реальных открытых и закрытых приложений. Первая уязвимость находится в certextract.c: библиотека без проверки доверяет содержимому разбираемого файла.

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

Мы уже знаем, что должны изменить поле длины на что-то большее, чем MAX_CERT_SIZE, или, если смотреть конкретно в certlib.h, большее чем 2048 байт. Глядя на структуру заголовков, можно увидеть, что у каждого сертификата есть собственное поле длины. Поэтому создание корректного заголовка структуры и размещение его по правильному смещению вместе с соответствующей полезной нагрузкой должно решить задачу. Учитывая это, рассчитаем число байтов от начала файла до первого сертификата.

Похоже, мы можем поместить нашу поддельную структуру после 12-го байта. Структура сертификата будет выглядеть примерно следующим образом, в зависимости от размера используемой полезной нагрузки:

Обратите внимание, что длина является беззнаковым коротким целым, которое ограничивает нашу полезную нагрузку значением 0xFFFF (65535), чего должно быть более чем достаточно. Две самые важные части нашей структуры - это длина и значение, которое мы даем PointerToDer, поскольку оно будет указывать на начало нашей полезной нагрузки. Поскольку мы решили сделать наш поддельный сертификат первым в списке, все, что находится ниже него, можно перезаписать без особых опасений. По смещению 0x18 в dat-файле у нас есть 0x0853 байта символов A; обратите внимание, что проверки границ для этого значения нет. Ниже показан пример запуска с корректным файлом certsdb.dat и второй пример запуска с нашим вредоносным dat-файлом.

Фактическая эксплуатация этой уязвимости оставлена читателю в качестве упражнения: имея структуру файла, необходимую для построения атаки, завершить ее теперь тривиально.

Продолжение прикладных примеров

Утилита certdb2der.c, предоставленная в этом наборе примеров, проходит по dat-файлу и сбрасывает содержимое каждого сертификата в отдельные файлы. Структура CERTFF (Certificate File Format) содержит элемент NumberOfCerts типа unsigned int. Это целое число явно управляет итератором цикла, контролируя число структур CERTDATA, которые, как утверждается, находятся в теле dat-файла.

Состояние целочисленного переполнения может быть вызвано во время выделения памяти для массива структур pCertData. Если специально подготовленный dat-файл содержит достаточно большое значение во время выделения памяти, массив pCertData становится некорректным из-за умножения в строке 60: (pCertFF->NumberOfCerts + 1) * sizeof(CERTDATA). Максимальное значение беззнакового целого равно 4294967295, или 0xffffffff, поэтому когда значение NumberOfCerts умножается на sizeof(CERTDATA), то есть на 16 байт, происходит переполнение с заворачиванием значения, приводящее к вызову malloc() с отрицательным размером или malloc(0). Затем это можно использовать для выполнения произвольного кода в некоторых реализациях malloc, перезаписывая управляющие структуры в куче. И снова эксплуатация не рассматривается подробно, но подготовка к эксплуатации объяснена ниже. Обратитесь к разделу ссылок за статьями, посвященными эксплуатации переполнений кучи.

При подготовке эксплойта для файлового формата большая часть работы будет состоять в построении поддельного корректного фрагмента CERTFF и его правильном размещении в dat-файле. Первые 6 байт нашего файла останутся прежними, поэтому можно предположить, что наш эксплойт будет выглядеть примерно так:

Псевдокод ниже обозначает структуру оставшейся части бинарного dat-файла.

Кратко говоря, код копирует содержимое нашей второй структуры после 24-го байта до тех пор, пока не будет достигнут конец буфера. Ниже показана итерация корректного использования утилиты, за которой следует итерация по вредоносному файлу базы сертификатов.

Если восстановить наш вызов как memcpy(buf, edx (our fake certs), eax (-1)), значение, хранящееся в eax, равно -1; когда оно преобразуется внутри memcpy в беззнаковое, 4 ГБ данных копируются в наш целевой буфер размером всего 0x800 байт.

Практический разбор Заголовки Microsoft PE/COFF

Существует ряд документов и инструментов, объясняющих структуру печально известного PE (Portable Executable) Microsoft и старого Unix-style заголовка COFF (Common Object File Format). Поэтому я воздержусь от подробного описания назначения каждого элемента внутри каждой структуры. Вместо этого я сосредоточусь на критических секциях, которые могут позволить атакующему изменить содержимое элементов заголовка специально для нарушения реализаций парсеров PE/COFF.

С учетом этого мы можем начать наше путешествие в мир PE. По файловому смещению 0x3C, как указано в pecoff.doc Microsoft, находится четырехбайтовая сигнатура PE; сразу после сигнатуры файла образа располагается стандартный COFF-заголовок следующего формата:

Не выглядит ли что-нибудь похожим на наш гипотетический файловый формат, использованный в примерах выше?

NumberOfSections и NumberOfSymbols в контексте собственных файловых форматов являются аналогами NumberOfCerts. Эти элементы, наряду с SizeOfOptionalHeader, создают интересные векторы атаки. Прежде чем двигаться дальше по деталям COFF-заголовка, важно уделить чуть больше внимания смещению 0x3C, на которое ссылается документ PECOFF.doc. В нем сказано, что файловое смещение, указанное по смещению 0x3C от начала файла образа, указывает на PE-сигнатуру.

Если смещение по адресу 0x3c равно fstat(image).st_size + 1, анализатор обращается к недопустимой памяти. Ошибка встретилась в большинстве проверенных просмотрщиков PE. Изменённый файл уже не исполнится, но может обрушить программу предварительного анализа. Для этого достаточно поддельного заголовка MZ с неверным смещением. В начале EXE находится заглушка MS-DOS; стандартная версия при запуске выводит сообщение «Эту программу нельзя выполнить в режиме DOS».

Поле NumberOfSections задаёт число заголовков секций в файле. Подстановка случайных значений даёт интересные результаты в dumpbin.exe из MSVC, PEView, PE Explorer, msfpescan и других инструментах.

После заголовка COFF находится OPTIONAL_HEADER, также называемый заголовком PE; он состоит из следующих элементов:

Для краткости часть полей опущена; они помогают загрузчику определить тип файла и основные отображения. Подробности приведены в приложении. Здесь рассматривается только массив IMAGE_DATA_DIRECTORY: его первый элемент указывает на структуры, а NumberOfRvaAndSizes задаёт число записей DataDirectory. Это последняя структура, подвергнутая фаззингу в практическом разборе.

Таблица каталога экспорта содержит адресные данные для разрешения ссылок на точки входа внутри образа. Поля NumberOfFunctions и NumberOfNames говорят сами за себя; доверие этим числам без проверки приводит к неожиданным результатам.

Представляем breakdance.c

Хотя фаззинг файлов сравнительно прост, специальные инструменты ускоряют восстановление формата и доступ к глубоко вложенным структурам. Обычно я использую xxd -i, hd (hexdump) или шестнадцатеричный редактор shred для Windows и изменяю структуры вручную, но для PE написал отдельную программу со следующими параметрами:

[Предупреждение: если параметр -o не указан вместе с параметрами изменения, изменения отбрасываются.]

Ниже перечислены бинарные анализаторы, на которые влияют параметры фаззинга из breakdance.c. Список не исчерпывающий, а возможности программы скромны относительно сложности PE/COFF, но их достаточно, чтобы показать ненадёжность таких анализаторов.

Затронутые наборы инструментов

Хотя я почти могу гарантировать, что другие парсеры столь же ошибочны, эта выборка довольно известна и должна быть достаточной для демонстрации. Единственная проблема, на которой я остановлюсь подробнее, - атака отказа в обслуживании против OllyDebug. Эта проблема интересна тем, что даже после изменения PE-образа для DoS OllyDebug сам бинарный файл остается исполняемым. Это можно использовать как вектор атаки против специалистов по обратной разработке, которые полагаются на OllyDbg при анализе бинарных файлов. Ниже показан запуск breakdance против DLL.

Выводы

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

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

Библиография

OSVDB. OSVDB Advisory Descriptions <http://www.osvdb.org>

Microsoft Corporation. PECoff Specification <http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx>

blexim. Integer Overflows <http://www.phrack.org/show.php?p=60&a=10>

Взлом зашифрованных паролей давно интересует хакеров, а их защита всегда была одной из крупнейших проблем безопасности, с которыми сталкивались операционные системы; Microsoft Windows не является исключением. Из-за ошибок в проектировании схемы шифрования паролей, особенно в схеме LanMan (LM), Windows имеет плохую репутацию в этой области информационной безопасности. Особенно в последние пару лет, когда устаревший алгоритм шифрования DES, на котором основан LanMan, столкнулся со все большей вычислительной мощностью обычных домашних компьютеров в сочетании с постоянно растущим объемом жестких дисков, стало совершенно ясно, что LanMan сегодня не просто устарел, а уже архаичен.

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

2. Устройство LM и NTLM 2.1. Катастрофа LanMan

По умолчанию Windows хранит пароли всех пользователей с использованием двух разных алгоритмов хэширования: исторически слабого LanMan-хэша и более стойкого MD4. LanMan-хэш основан на DES и был описан в тираде Mudge на эту тему. Ниже приведено краткое напоминание о LM-хэше, хотя тем, кто не знаком с LM, вероятно, стоит прочитать первоисточник.

Сначала Windows берет пароль и гарантирует, что его длина составляет 14 байт. Если он короче 14 байт, пароль дополняется нулевыми байтами. Полный перебор до 14 символов может занять очень много времени, но два фактора сильно упрощают задачу. Во-первых, набор возможных символов довольно мал, и Microsoft дополнительно уменьшает его, сохраняя пароль только в верхнем регистре. Это означает, что "test" совпадает с "Test", совпадает с "tesT", совпадает с... ну... вы поняли идею. Во-вторых, пароль на самом деле не имеет размер 14 байт. Windows делит его на две части по 7 байт. Поэтому вместо перебора до 14 байт атакующему нужно взломать только 7 байт, два раза. Разница составляет (keyspace^14) против (keyspace^7)*2. Это огромная разница.

Что касается пространства ключей, эта статья фокусируется только на буквенно-цифровом наборе символов, но полный возможный набор допустимых символов таков:

Следующая проблема LM связана с полным отсутствием соли или сцепления блоков шифра в процессе хэширования. Чтобы хэшировать пароль, первые 7 байт преобразуются в 8-байтовый DES-ключ с нечетной четностью. Этот ключ используется для шифрования 8-байтовой строки "KGS!@". То же самое происходит со второй частью пароля.

Отсутствие соли создает два интересных следствия. Очевидно, это означает, что пароль всегда хранится одним и тем же способом, что буквально напрашивается на типичную атаку с таблицей поиска. Другое следствие состоит в том, что легко определить, больше ли пароль 7 байт. Если нет, последние 7 байт будут нулевыми и дадут постоянный DES-хэш 0xAAD3B435B51404EE.

Как я уже указывал, LM широко документирован. "L0phtcrack" и "John the Ripper" являются инструментами перебора, способными взламывать эти хэши, а Philippe Oechslin из ETH Zurich первым предвычислил таблицы поиска LM, позволяющие взламывать такие хэши за секунды.

2.2. NTLM

Microsoft попыталась устранить слабости LM с помощью более стойкого NTLM. Первая версия появилась в Windows NT, а в NT SP6 её усилили до NTLMv2. Для обмена файлами, сетевой печати и удалённых команд Windows использует общую файловую систему Интернета CIFS, которая выполняет аутентификацию через NTLM.

В NTLM клиент запрашивает новую сессию, затем предлагает поддерживаемые варианты SMB/CIFS. Сервер выбирает один из них и присылает восьмибайтовый случайный запрос проверки.

Чтобы теперь войти в систему, клиент отправляет имя пользователя открытым текстом (!) и также пароль, хэшированный в стиле NTLM. NTLM-хэш генерируется следующим образом:

К 16-байтовому LM-хешу добавляются пять нулевых байтов. Полученные 21 байт делятся на три группы по семь, каждая превращается в восьмибайтовый DES-ключ с нечётной чётностью. Три ключа отдельно шифруют запрос проверки, а три восьмибайтовых результата объединяются в 24-байтовый ответ клиента.

Как уже отметил Mudge, перехватчик трафика видит имя пользователя, запрос проверки и 24-байтовый ответ.

Во-первых, как было сказано ранее, если пароль короче 8 байт, вторая половина LM-хэша всегда равна 0xAAD3B435B51404EE. Для иллюстрации предположим, что первая часть хэша равна 0x1122AABBCCDDEEFF. Тогда весь LM-хэш выглядит так:

Первые восемь байтов ответа NTLM зависят только от первых семи байтов LM-хеша. Вторые восемь — от последнего байта первой половины LM и первых шести байтов второй. Оставшиеся два байта LM дополняются пятью нулями и шифруют запрос проверки, образуя третий фрагмент ответа. Поэтому дополненный LM-хеш выглядит так:

и превращается в 24-байтовый ответ NTLM. Для пароля короче восьми символов третий ключ всегда равен 0x04EE0000000000. Если зашифрованный им перехваченный запрос совпадает с последними восемью байтами ответа, пароль почти наверняка не длиннее семи символов. Это можно подтвердить перебором 256 вариантов неизвестного первого байта второго ключа. Для более длинного пароля перебор всех двухбайтовых окончаний с пятью нулевыми байтами раскрывает последние два байта LM-хеша максимум за 65 536 попыток.

2.3. Запрос проверки NTLM

Главное отличие NTLM от LM — случайный запрос проверки, действующий подобно криптографической соли. Он добавляет 2^64 вариантов и мешает использовать предвычисленные таблицы.

3.0. Взлом NTLM с предвычисленными таблицами 3.1. Атака на первую часть

Предвычислить NTLM для всех случайных запросов практически невозможно. Но поддельный CIFS-сервер может выдавать каждому клиенту один и тот же постоянный запрос. Тогда задача снова становится статической, а таблицы NTLM строятся почти так же просто, как таблицы LM.

На снимке показана демонстрационная реализация: она принимает CIFS-соединение, согласует протокол, отправляет постоянный запрос проверки и отключает клиента после получения имени пользователя и ответа NTLM. Дополнительные сведения клиента также записываются в журнал.

Это машина Windows XP, подключающаяся к поддельному серверу, работающему на Linux. Клиент подключается с IP-адреса 192.168.7.13. Имя пользователя - "Testuser", имя узла - "BarrierIce", и хэш пароля, конечно, тоже был захвачен.

3.2. Создание таблиц

Создание радужных таблиц для предвычисления хэшей теперь является хорошим подходом к простому взлому хэшей, но поскольку жесткие диски становятся все больше и при этом дешевеют, я решил сделать собственную схему таблиц. Как увидит читатель, мой подход требует намного больше места на жестком диске, чем радужные таблицы, поскольку они менее затратны вычислительно при создании и содержат определенный набор данных, в отличие от радужных таблиц с их вероятностью меньше 100% содержать конкретный пароль.

Чтобы создать такие таблицы, главный вопрос состоит в том, как эффективно хранить все данные. Чтобы оставаться в определенных границах, я решил ограничиться только буквенно-цифровыми таблицами. Буквенно-цифровой набор - это 26 символов от a до z, 26 символов от A до Z и еще 10 символов от 0 до 9. То есть 62 возможных значения для каждого символа, а значит, 62^7 перестановок, верно? Неверно. NTLM-хэши используют LM-хэш как входные данные. Алгоритм хэширования LM переводит входные данные в верхний регистр. Поэтому возможное пространство ключей сжимается до 36 символов, а число возможных перестановок уменьшается до 36^7. Единственные дополнительные входные данные, которые нужно учитывать, - используемые нулевые байты заполнения, доводящие общее число перестановок до значения чуть больше 36^7.

Принятый здесь подход для удобного хранения и восстановления хэшей и открытого текста по сути состоит в размещении каждого возможного пароля открытым текстом в одном из 2048 бакетов. Его легко можно расширить на большее число бакетов. Инструмент создания таблиц просто генерирует каждый допустимый буквенно-цифровой пароль, хэширует его и проверяет первые 11 бит хэша. Эти биты определяют, к какому из 2048 бакетов, реализованных в данном случае как файлы, относится пароль открытым текстом. Затем пароль открытым текстом добавляется в бакет. Теперь всякий раз, когда захвачен хэш, просмотр первых 11 бит хэша определяет правильный бакет, в котором нужно искать пароль. Все, что остается сделать, - хэшировать все пароли в бакете, пока не будет найдено совпадение. В среднем это займет ((36^7)/2048))/2, или 19131876 хэш-операций. На моей машине Pentium 4 2.8 ГГц это занимает примерно три минуты. Инструменту генерации NTLM-таблиц требуется 94 часа работы на моей машине. К счастью, мне пришлось сделать это только один раз :)

Вопрос в том, как хранить более чем 36^7 паролей открытым текстом, размер которых находится в диапазоне от 0, то есть пустого пароля, до 7 байт.

Подход 1: хранить каждый пароль, отделяя его новой строкой. Поскольку большинство паролей имеют размер 7 байт, а дополнительная новая строка увеличивает это до 8 байт, результат оказался бы где-то около (36^7)*8 байт. Это примерно 584 гигабайта для буквенно-цифрового пространства ключей. Должен быть способ лучше.

Подход 2: хранить каждый пароль в 7 байтах, короче он 7 байт или нет. Тогда среднее место, требуемое для каждого пароля, уменьшается с 8 до 7, поскольку можно избавиться от новых строк. Нет необходимости отделять пароли новыми строками, если все они одного размера. Однако (36^7)*7 все еще слишком много.

Подход 3: пароли открытым текстом генерируются 7 вложенными циклами. Первый символ меняется постоянно. Второй символ меняется каждый раз, когда первый исчерпал все пространство ключей. Третий увеличивается каждый раз, когда второй исчерпал пространство ключей, и так далее. Интересно то, что последние 3 байта меняются редко. Если хранить их только при изменении, можно хранить только первые 4 байта каждого пароля и время от времени маркер, сигнализирующий об изменении последних 3 байт, за которым следуют 3 байта, теперь формирующие конец каждого пароля открытым текстом до следующего маркера. Это примерно (36^7)*4 байта, то есть 292 гигабайта. Намного лучше. Все еще слишком много.

Подход 4: для каждого символа есть 37 возможных значений: A-Z, 0-9 и нулевой байт. 37 разных значений можно выразить 6 битами. Значит, мы можем упаковать 4 символа в 4*6 = 24 бита, то есть 3 байта. Как удобно! (37^7)*3 == 265 гигабайт. Все еще слишком много.

Подход 5: пароли генерируются и сохраняются последовательным образом. Хэш определяет, в какой бакет поместить каждый новый пароль открытым текстом, но он всегда "больше" предыдущего. При использовании 2048 бакетов тест показал, что внутри любого одного файла ни одно смещение между сохраняемым паролем и следующим паролем, сохраняемым в этот бакет, не превысило 55000. Если хранить смещения относительно предыдущего пароля вместо полного слова, каждый пароль можно сохранить как 2-байтовое значение.

Например, допустим, первый пароль, сохраняемый в один бакет, - односимвольное слово "A". Это индекс 10 в списке возможных символов, поскольку он начинается с 0-9. Теперь инструмент создания таблиц сохранит в бакет 10, поскольку это первый индекс от начала нового бакета и он на 10 больше нуля, стартового значения для каждого бакета. Теперь если по случайности односимвольный пароль "C" следующим должен быть сохранен в тот же бакет, будет сохранено число 2, поскольку "C" имеет смещение 2 относительно предыдущего пароля. Если следующим паролем для этого бакета был бы "JH6", смещение могло бы быть 31337.

В основном каждый пароль хранится в системе base36, поэтому первый 2-байтовый пароль, "00", имеет индекс 37, а все предыдущие смещения паролей и смещение самого "00" в бакете, в котором "00" сохраняется, в сумме дают 37. Чтобы извлечь пароль, сохраненный таким способом, требуется преобразовать десятичный индекс обратно в систему base36 и использовать получившиеся отдельные числа как индексы в символьное пространство ключей keyspace[].

Итоговый размер таблицы составляет (36^7)*2 == 146 гигабайт. Это все еще довольно много, но достаточно мало, чтобы легко поместиться на современных жестких дисках. Как я упоминал ранее, фактический итоговый размер немного больше, потому что нужно также сохранить набор паролей, которые заканчиваются нулевыми байтами. В итоге получается не 146 гигабайт, а 151.

3.3. Большая проблема

Теперь есть большая проблема, связанная с созданием таблиц поиска NTLM. Первые 8 байт финального хэша выводятся из первых 7 байт LM-хэша, которые выводятся из первых 7 байт пароля открытым текстом. Поэтому создание таблиц, сопоставляющих первые 8 байт NTLM-хэша с первыми 7 байтами пароля, возможно, но те же таблицы не работают для второго или даже третьего блока 24-байтового NTLM-хэша.

Второй 8-байтовый фрагмент хэша выводится из последнего байта первого LM-хэша и первых 6 байт второго LM-хэша. Этот первый байт добавляет 256 возможных значений ко второму LM-хэшу. В то время как первый 8-байтовый фрагмент 24-байтового LM-хэша происходит исключительно из LM-хэша пароля открытым текстом, второй 8-байтовый фрагмент происходит из неопределенного байта и дополнительных 6 байт LM-хэша.

Возможность посмотреть первые до 7 байт пароля уже является большим преимуществом. Вторую часть пароля, если он вообще длиннее 7 байт, теперь обычно можно легко угадать или перебрать. Например, установив, что пароль начинается с "ILLUSTR", чаще всего можно ожидать окончание "ATION" или "ATOR". С другой стороны, если после поиска первых 7 байт применить к этому примеру перебор, потребуется перебрать 4-5 символов, пока не будет раскрыт окончательный пароль. Даже готовое потребительское оборудование делает это за секунды. Хотя это займет немного дольше, перебор даже 6 байт - не то, что невозможно высидеть. Однако 7 байт требуют неудобно большого времени. Вот где возможность посмотреть и эту часть была бы действительно кстати. И, как можно догадаться, способ есть.

3.4. Взлом второй части пароля

Как и первая половина пароля, вторая шифрует известную строку и образует восьмибайтовый LM-хеш. Зная отправленный сервером запрос проверки, последние два байта LM-хеша можно вывести из третьего фрагмента ответа NTLM, как описано в разделе 2.2.

Итак, последние 2 байта LM-хэша второй половины исходного пароля известны. Если теперь применить подход, похожий на взлом первой половины пароля, становится вполне возможно посмотреть и вторую часть пароля.

Ключ здесь в создании набора предвычисленных LanMan-таблиц, отсортированных по последним 2 байтам LM-хэша. Поэтому как только последние 2 байта LM-хэша известны, тем самым определяется файл, содержащий пароли открытым текстом, которые при хэшировании дают совпадающую 2-байтовую последовательность в конце.

Второй фрагмент NTLM-хэша выводится из 6 байт, являющихся началом хэша одного из паролей открытым текстом из только что определенного файла, и одного байта - первого, который является последним байтом первого LM-хэша.

Считая первую часть пароля взломанной, этот байт известен. Поэтому все, что остается сделать, - хэшировать все возможные пароли в файле, поместить единственный известный байт в первую позицию строки и конкатенировать его с 6 байтами из только что созданного хэша, снова хэшировать эти 7 байт и сравнивать результат со вторым фрагментом NTLM-хэша. Если он совпадает, вторая часть пароля тоже взломана.

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

Второй набор, отсортированные LM-таблицы, в отличие от NTLM-таблиц не зависит от конкретного запроса проверки. Он работает с любым запросом, перехваченным вместе с именем пользователя и ответом аутентификации.

4. Как заставить жертву войти на поддельный сервер?

Главный вопрос: как заставить жертву войти на поддельный сервер, тем самым раскрывая атакующему имя пользователя и хэш пароля для последующего взлома.

Подход 1: отправка HTML-письма, включающего ссылку в форме UNC-пути, должна сработать. Это зависит главным образом от риторических способностей отправителя, способного заставить жертву нажать ссылку, и от того, поймет ли почтовый клиент, что от него ожидается. UNC-путь обычно имеет форму \\192.168.7.6\share, где IP-адрес очевидно задает узел, к которому нужно подключиться, а share является общим ресурсом на этом узле. Поскольку Microsoft всегда в первую очередь заботится об удобстве, после щелчка жертвы по ссылке на машине Windows произойдет следующее. ОС попытается войти в указанный ресурс. Когда сервер запросит имя пользователя и пароль, клиент охотно предоставит серверу имя текущего пользователя и его хэшированный пароль, пытаясь войти с этими учетными данными. Взаимодействие с пользователем не требуется. Это не шутка.

Подход 2: если заставить жертву посетить сайт, включающий UNC-путь, в Internet Explorer, результат будет тем же. Тег изображения с таким путем сделает свое дело. IE заставит Windows попытаться войти в ресурс, чтобы получить изображение. И снова взаимодействие с пользователем не требуется. Кстати, с Mozilla Firefox этот трюк не работает.

Подход 3: если поддельный сервер находится в локальной сети, достаточно рекламировать его как хранилище нелегального ПО, порнографии, музыки и фильмов — рано или поздно кто-нибудь попытается войти.

Есть множество других способов, которые автор оставляет воображению читателей.

5. Что нужно помнить

После получения и успешного взлома хэша это все еще может быть не правильный пароль и, соответственно, не позволит атакующему войти на машину жертвы. Это связано с тем, что для LM пароль хэшируется полностью в верхнем регистре, тогда как второй хэш на основе MD4 фактически чувствителен к регистру. Поэтому хэш, расшифрованный как "WELCOME", изначально мог быть "Welcome", или "welcome", или даже "wELCOME", или "WeLcOme", или... ну, вы поняли идею. С другой стороны, сколько пользователей действительно применяют необычные схемы написания?

6. Прикрытие следов

Прочитав эту статью, читатель к настоящему моменту должен понимать, что NTLM, механизм аутентификации, который, вероятно, поддерживает большинство компьютеров на этой планете, на самом деле представляет большую угрозу для узлов и целых сетей. Особенно с учетом недавно обнаруженных удаленных эксплойтов Windows, которым требуются действительные учетные записи на машинах жертв для первоначального входа атакующего, червь, заставляющий людей посетить сайт, который, в свою очередь, заставляет их войти на поддельный сервер, взламывает хэш и автоматически эксплуатирует жертву, является пугающим сценарием угрозы.

Библиография

Windows NT rantings from the L0pht <http://www.packetstormsecurity.org/Crackers/NT/l0phtcrack/l0phtcrack.rant.nt.passwd.txt>

Making a Faster Cryptanalytic Time-Memory Trade-Off <http://lasecwww.epfl.ch/oechslin/publications/crypto03.pdf>

Аннотация: в 64-битном ядре Windows появился механизм PatchGuard, запрещающий вредоносным программам и сторонним поставщикам изменять критические структуры операционной системы: отдельные системные образы, SSDT, IDT, GDT и некоторые важные регистры MSR. Защищая ядро от несанкционированных перехватов, PatchGuard повышает стабильность, но одновременно мешает работе некоторых легитимных продуктов. В статье подробно исследуется его внутреннее устройство, способы обхода и возможные контрмеры.

Благодарности: авторы хотели бы поблагодарить westcose, bugcheck, uninformed, Alex Ionescu, Filip Navara и всех, кого к обучению мотивирует собственный интерес.

Отказ от ответственности: предмет, обсуждаемый в этом документе, представлен в образовательных целях. Авторы не могут нести ответственность за то, как эта информация будет использована. Хотя авторы попытались провести анализ как можно более тщательно, возможно, они допустили одну или несколько ошибок. Если вы заметите ошибку, пожалуйста, свяжитесь с одним или обоими авторами, чтобы ее можно было исправить.

2. Введение

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

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

Именно так обстояло дело с операционными системами Microsoft. Еще начиная со времен Windows 95, а возможно и раньше, Microsoft поняла, что разрешение сторонним поставщикам подкручивать или иным образом использовать различные критические части ядра приводит только к головной боли и проблемам стабильности, хотя и обеспечивает максимальную гибкость. Хотя Microsoft заняла более жесткую позицию с Windows NT, все равно сложилась ситуация, в которой сторонние поставщики используют области ядра, представляющие особый интерес для достижения определенных целей, даже если применяемые для этого средства требуют использования недокументированных структур и функций.

Microsoft давно утратила возможность свободно менять внутреннее устройство ядра, не затрагивая сторонние продукты. Если бы обновление без подходящей замены сломало решения крупных поставщиков, компании грозили бы серьёзные антимонопольные последствия. Переход на x64 дал шанс вернуть часть этой свободы. В статье под x64 обычно понимается AMD64, хотя некоторые замечания относятся и к IA64. Поскольку ядро работает в собственном 64-битном режиме, драйверы также должны быть 64-битными; промежуточный слой преобразования вызовов для производительных драйверов был бы непрактичен.

Потребовав собственные 64-битные версии всех драйверов, Microsoft начала развитие новой платформы с чистого листа: совместимых старых продуктов ещё не существовало. При переносе драйверов любое неподдерживаемое поведение можно было объявить запрещённым на x64 и вынудить поставщика искать другой путь. Так возник замысел PatchGuard — системы защиты ядра от несанкционированных изменений; разумность самой цели выходит за рамки статьи.

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

Настоящая цель этого документа, однако, состоит в том, чтобы показать: невозможно безопасно защищать области кода и данных с помощью системы, которая включает мониторинг этих областей на уровне привилегий, равном уровню, на котором способен выполняться сторонний код. Этот факт хорошо известен как Microsoft, так и сообществу безопасности в целом, и он должен быть понятен без дополнительных объяснений. В будущем мир операционных систем, скорее всего, начнет смещаться к более детальному, аппаратно обеспеченному разделению привилегий через реализацию изолированных доверенных кодовых баз. Вопросы, которые это поднимет в отношении open-source операционных систем и проблем DRM, должны постепенно становиться все заметнее. Только время покажет.

3. Реализация

Механизм PatchGuard в ядре Windows x64 защищает критические структуры от любых изменений, кроме одобренных способов, например контролируемого Microsoft горячего исправления. На момент написания он охраняет следующие структуры:

• SSDT (System Service Descriptor Table)

• GDT (Global Descriptor Table)

• IDT (Interrupt Descriptor Table)

• Системные образы (ntoskrnl.exe, ndis.sys, hal.dll)

• MSR процессора (syscall)

На высоком уровне PatchGuard реализован в виде набора процедур, которые кэшируют заведомо корректные копии и/или контрольные суммы структур, затем проверяемые через определенные случайные интервалы времени, примерно каждые 5-10 минут. Причина, по которой PatchGuard реализован в режиме опроса, а не в событийной или аппаратно поддержанной форме, состоит в отсутствии родной аппаратной поддержки для того, чего PatchGuard пытается добиться. По этой причине ряд приемов, к которым прибегает PatchGuard, был применен по необходимости.

Разработчики PatchGuard понимали ограничения такой модели и усилили её сокрытием реализации: вводящими в заблуждение конструкциями, функциями с ложными именами и общей обфускацией кода. Сокрытие само по себе не обеспечивает абсолютной безопасности, но поднимает порог анализа и заметно сокращает круг людей, способных полностью разобраться в механизме.

Код инициализации PatchGuard начинает выполняться рано в процессе загрузки как часть nt!KeInitSystem. И именно там начинается самое интересное.

3.1. Инициализация PatchGuard

Инициализация PatchGuard состоит из нескольких этапов, а начинается в функции с совершенно посторонним именем KiDivide6432, которая на вид лишь выполняет деление:

Безобидный на вид код — первая попытка PatchGuard скрыть свои намерения. nt!KiDivide6432 получает делимое из nt!KiTestDividend и жёстко заданный делитель 0xcb5fa3, словно проверяя поддержку операции деления. Если результат отличается от 0x5ee0b7e5, nt!KeInitSystem аварийно останавливает систему с кодом 0x5d (UNSUPPORTED_PROCESSOR):

nt!KeInitSystem+0x158:

...

nt!KeInitSystem+0x170:

При локальной отладке значение nt!KiTestDividend равно 0x014b5fa3a053724c; деление на 0xcb5fa3 даёт 0x1a11f49ae, а не ожидаемое число. Однако при обычной загрузке аварийной остановки нет. Значит, здесь скрыт дополнительный механизм.

Ответ связан со старым добрым случаем изобретательности. Результат приведенной выше операции деления - значение больше 32 бит. Справочное руководство по набору инструкций AMD64 указывает, что инструкция div вызовет ошибку деления, если происходит переполнение частного. Это означает, что пока nt!KiTestDividend установлен в описанное выше значение, будет сгенерирована ошибка деления, вызывающая аппаратное исключение, которое должно быть обработано ядром. Именно эта ошибка деления фактически приводит к косвенной инициализации подсистемы PatchGuard. Однако прежде чем идти этим путем, важно понять один интересный аспект того, как Microsoft это сделала.

Одна из интересных особенностей nt!KiTestDividend состоит в том, что он фактически объединен в union с экспортируемым символом, который используется для указания, присутствует ли, собственно, отладчик. Этот символ называется nt!KdDebuggerNotPresent, и он перекрывается со старшим байтом nt!KiTestDividend, как показано ниже:

TestDividend L1

Глобальная переменная nt!KdDebuggerNotPresent будет установлена в ноль, если отладчик присутствует. Если отладчик отсутствует, значение будет равно единице (по умолчанию). Если описанная выше операция деления выполняется при подключенном во время загрузки системы отладчике, что соответствует делению 0x004b5fa3a053724c на 0xcb5fa3, полученное частное будет ожидаемым значением 0x5ee0b7e5. Это означает, что если отладчик подключен к системе до косвенной инициализации защит PatchGuard, эти защиты не будут инициализированы, потому что ошибка деления не будет сгенерирована. Это совпадает с документированным поведением и предназначено для того, чтобы разработчики драйверов по-прежнему могли устанавливать точки останова и выполнять другие действия, которые могут косвенно изменять отслеживаемые области ядра в отладочной среде. Однако это работает только в том случае, если отладчик подключен к системе во время загрузки. Если разработчик впоследствии подключает отладчик после инициализации PatchGuard, установка точек останова или выполнение других действий может привести к синему экрану из-за обнаружения изменений PatchGuard. Выбор Microsoft инициализировать PatchGuard таким способом позволяет прозрачно отключать защиты при подключенном отладчике и одновременно служит способом скрыть настоящий вектор инициализации.

Поняв объединенный характер nt!KiTestDividend, следующий шаг - понять, как ошибка деления фактически приводит к инициализации подсистемы PatchGuard. Для этого необходимо начать с места, куда попадают все ошибки деления: nt!KiDivideErrorFault.

Срабатывание nt!KiDivideErrorFault запускает цепочку вызовов до nt!KiOpDiv, обрабатывающей ошибки инструкции div, включая деление на ноль. Ниже приведена трассировка стека. Инициализацию PatchGuard, обычно отключённую при подключённом отладчике, можно вызвать искусственно: остановиться на div внутри nt!KiDivide6432 и обнулить r8d. Ошибка деления запустит нужные процедуры. Чтобы затем позволить системе загрузиться, следует поставить на nt!KiDivide6432 точку останова, автоматически восстанавливающую r8d в 0xcb5fa3:

Child-SP RetAddr Call Site

Первое, что делает nt!KiOpDiv перед обработкой фактической ошибки деления, - вызывает функцию с именем nt!KiFilterFiberContext. Это имя выглядит странным не только в общем смысле, но и в конкретном контексте процедуры, предназначенной для работы с ошибками деления. При взгляде на тело nt!KiFilterFiberContext ее намерения быстро становятся ясны:

nt!KiFilterFiberContext:

Похоже, этот фрагмент кода предназначен для проверки, равен ли адрес, по которому произошла ошибка, nt!KiDivide6432 + 0xb. Если прибавить 0xb к nt!KiDivide6432 и дизассемблировать инструкцию по этому адресу, результат будет таким:

nt!KiDivide6432+0xb:

Это совпадает с тем, чего следовало бы ожидать при возникновении условия переполнения частного. Согласно приведенному выше дизассемблированию, если адрес ошибки равен nt!KiDivide6432 + 0xb, вызывается безымянный символ по адресу nt!KiDivide6432 + 0x570. Далее этот безымянный символ будет называться nt!KiInitializePatchGuard, и именно он управляет настройкой подсистемы PatchGuard.

Сама процедура nt!KiInitializePatchGuard довольно велика. Она обрабатывает инициализацию контекстов, которые будут отслеживать определенные системные образы, SSDT, GDT/IDT процессора, некоторые критические MSR и некоторые процедуры, связанные с отладчиком. Самое первое, что делает процедура инициализации, - проверяет, загружается ли машина в безопасном режиме. Если она загружается в безопасном режиме, подсистема PatchGuard не будет включена, как показано ниже:

nt!KiDivide6432+0x570:

...

nt!KiDivide6432+0x580:

После прохождения проверки безопасного режима nt!KiInitializePatchGuard начинает инициализацию PatchGuard, вычисляя размер секции INITKDBG в ntoskrnl.exe. Она делает это, передавая адрес символа, найденного внутри этой секции, nt!FsRtlUninitializeSmallMcb, в nt!RtlPcToFileHeader. Эта процедура возвращает базовый адрес nt через выходной параметр, который затем передается в nt!RtlImageNtHeader. Этот метод возвращает указатель на структуру IMAGENTHEADERS образа. Затем вычисляется виртуальный адрес nt!FsRtlUninitializeSmallMcb путем вычитания из него базового адреса nt. Вычисленный RVA затем передается в nt!RtlSectionTableFromVirtualAddress, которая возвращает указатель на секцию образа, в которой находится nt!FsRtlUninitializeSmallMcb. Вывод отладчика ниже показывает, на что указывает rax после получения структуры секции образа:

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

После сбора информации о секции образа INITKDBG процедура инициализации PatchGuard выполняет первую из многих генераций псевдослучайных чисел. Этот код можно видеть во всех функциях PatchGuard, и он имеет форму, похожую на приведенный ниже код:

Генератор псевдослучайных чисел использует rdtsc как начальное значение, затем выполняет побитовые операции и умножения, оставляя результат в eax. Это число служит индексом массива тегов пула для выделений PatchGuard. Выбирая случайный настоящий тег, механизм маскирует свои структуры среди обычных выделений памяти. Ниже показаны обращение к массиву и его расположение:

Случайное число в rax индексирует массив тегов пула по адресу nt+0x430400. Косвенное обращение дополнительно скрывает назначение кода. Вывод массива в отладчике показывает все теги, которые может выбрать PatchGuard:

Выбрав маскировочный тег, инициализация выделяет случайный объём памяти: от виртуального размера секции INITKDBG плюс 0x1b8 до этого минимума плюс 0x7ff. Значение 0x1b8 — размер структуры с защитным контекстом PatchGuard. Тег и случайный размер используются для выделения из NonPagedPool:

Если выделение контекста успешно, процедура инициализации обнуляет его содержимое, а затем начинает инициализировать некоторые атрибуты структуры. Контекст, возвращенный выделением, далее будет называться структурой типа PATCHGUARD_CONTEXT. Первые 0x48 байт структуры фактически состоят из кода, скопированного из вводящего в заблуждение символа с именем nt!CmpAppendDllSection. Эта функция на самом деле используется для расшифровки структуры во время выполнения, что будет видно позже. После копирования nt!CmpAppendDllSection в первые 0x48 байт структуры данных процедура инициализации настраивает ряд указателей функций, хранящихся внутри структуры. Процедуры, адреса которых она сохраняет, и смещения внутри структуры данных контекста PatchGuard показаны ниже.

Причина, по которой PatchGuard использует указатели функций вместо прямого вызова символов, скорее всего связана с режимом относительной адресации, используемым в x64. Поскольку код PatchGuard динамически выполняется с непредсказуемых адресов, невозможно было бы использовать режим относительной адресации без необходимости исправлять инструкции, а это задача, которая, без сомнения, была бы болезненной и не стоила бы усилий. Авторы не видят особого выигрыша в обфускации от использования указателей функций, сохраненных в структуре контекста PatchGuard.

После настройки указателей инициализация выбирает ещё один тег пула для последующих выделений и сохраняет его по смещению 0x188 в контексте PatchGuard. Затем генерируются два числа для шифрования структуры: величина циклического сдвига по смещению 0x18c и начальное значение XOR по смещению 0x190.

Следующий шаг процедуры инициализации - получить число битов, которые могут использоваться для представления виртуального адресного пространства, запросив процессор через расширенную функцию cpuid ExtendedAddressSize (0x80000008). Результат сохраняется по смещению 0x1b4 внутри структуры контекста PatchGuard.

Наконец, последний крупный шаг перед инициализацией отдельных защитных подконтекстов - копирование содержимого секции INITKDBG в выделенную структуру контекста PatchGuard. Операция копирования выглядит примерно как псевдокод ниже:

После инициализации основных частей структуры контекста PatchGuard следующим логическим шагом является инициализация подконтекстов, специфичных для того, что фактически защищается.

3.2. Инициализация защищаемых структур

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

В этом разделе будет объяснено, как инициализируются защитные подконтексты каждой отдельной структуры. На момент написания структуры получают свои защитные подконтексты в порядке, описанном ниже:

• Системные образы

• SSDT

• GDT/IDT/MSR

• Отладочные процедуры

После инициализации всех подконтекстов родительский защитный контекст XOR'ится, а таймер инициализируется и устанавливается. Назначение этого таймера, как будет показано, состоит в запуске проверочной половины подсистемы PatchGuard на собранных данных. Помимо конкретных защитных подконтекстов, перечисленных в следующих подразделах, авторы наблюдали, что процедура, инициализирующая подсистему PatchGuard, также выделяла структуры подконтекстов типов, которые не удалось сразу определить. В частности, эти типы имели идентификаторы подконтекста 0x4 и 0x5.

3.2.1. Системные образы

Защита ключевых образов ядра — одна из главных задач PatchGuard. Если бы драйвер по-прежнему мог перехватывать функции в nt, ndis и других критических компонентах, механизм был бы почти бесполезен. Поэтому PatchGuard проверяет системные образы на подмену; таблица на рисунке перечисляет защищаемые образы.

Подход к защите каждого из этих образов одинаков. Для начала адрес символа, находящегося внутри образа, передается в подпрограмму PatchGuard, которую мы будем называть nt!PgCreateImageSubContext. Прототип этой процедуры показан ниже:

Для ntoskrnl.exe в качестве адреса символа передается адрес nt!KiFilterFiberContext. Для hal.dll передается адрес HalInitializeProcessor. Наконец, для ndis.sys передается адрес его точки входа, полученный через вызов nt!GetModuleEntryPoint.

nt!PgCreateImageSubContext создаёт несколько защитных подконтекстов. Первый хранит контрольные суммы секций образа, второй — таблицы адресов импорта (IAT), третий — каталога импорта. Общая процедура вычисляет контрольную сумму блока памяти, используя случайный ключ XOR и величину циклического сдвига из родительского контекста PatchGuard. Её прототип приведён ниже:

Подконтекст контрольной суммы блока сохраняет состояние контрольной суммы в конце PATCHGUARD_CONTEXT. Состояние контрольной суммы хранится в структуре BLOCK_CHECKSUM_STATE. Атрибут Unknown структуры инициализируется параметром Unknown из nt!PgCreateBlockChecksumSubContext. Назначение этого поля не было установлено, но во время отладки значение было установлено в ноль.

Алгоритм контрольной суммы, используемый процедурой, довольно прост. Псевдокод ниже показывает, как он работает концептуально:

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

Для инициализации контрольной суммы секций образа nt!PgCreateImageSubContext вызывает nt!PgCreateImageSectionSubContext, прототип которой выглядит так:

Сначала процедура проверяет nt!KiOpPrefetchPatchCount. Если значение ненулевое, создаётся контекст контрольной суммы, охватывающий не все секции образа; возможно, так учитываются установленные горячие исправления, хотя это не подтверждено. Иначе функция перебирает секции и вычисляет их контрольные суммы, пропуская INIT, PAGEVRFY, PAGESPEC и PAGEKD.

Для таблицы адресов и каталога импорта nt!PgCreateImageSubContext вызывает nt!PgCreateBlockChecksumSubContext, если соответствующие записи каталога существуют и корректны.

3.2.2. GDT/IDT

PatchGuard также защищает глобальную таблицу дескрипторов (GDT) и таблицу дескрипторов прерываний (IDT). GDT описывает используемые ядром сегменты памяти; изменение критических записей может позволить непривилегированному процессу менять память ядра. IDT интересна и вредоносным, и легитимным программам, желающим перехватить аппаратное или программное прерывание до передачи ядру. Ошибка в таком перехвате особенно опасна из-за ограничений контекста обработчика запроса прерывания.

Фактическая реализация защиты GDT/IDT достигается через использование функции nt!PgCreateBlockChecksumSubContext, которой передается содержимое обеих таблиц дескрипторов. Поскольку регистры, хранящие GDT и IDT, относятся к конкретному процессору, PatchGuard создает отдельный контекст для каждой таблицы на каждом отдельном процессоре. Чтобы получить адрес GDT и IDT для заданного процессора, PatchGuard сначала использует nt!KeSetAffinityThread, чтобы убедиться, что выполняется на конкретном процессоре. После этого он вызывает nt!KiGetGdtIdt, которая сохраняет базовые адреса GDT и IDT как выходные параметры, как показано в прототипе ниже:

Фактическая защита GDT и IDT выполняется в контексте двух отдельных функций, которые были обозначены как nt!PgCreateGdtSubContext и PgCreateIdtSubContext. Прототипы этих процедур показаны ниже:

Обе процедуры вызываются в контексте цикла, который проходит по всем процессорам машины с учетом nt!KeNumberProcessors.

3.2.3. SSDT

Сторонние драйверы часто перехватывают таблицу дескрипторов системных служб (SSDT). Она описывает таблицы, через которые операционная система диспетчеризует системные вызовы. В Windows x64 nt!KeServiceDescriptorTable содержит адрес таблицы и число записей нативного интерфейса. Сама nt!KiServiceTable представляет массив относительных смещений; абсолютные адреса служб вычисляются следующим образом:

Относительные адреса осложняют перенос 32-битного перехвата системных вызовов на x64. Простое решение — разместить переходную заглушку перехватчика в пределах доступного относительного диапазона 2 ГБ, например в выравнивающем заполнении между символами. Это грубый способ, требующий отключённого PatchGuard; существуют и более изящные варианты.

Что касается защиты таблицы системных сервисов, PatchGuard защищает как родную таблицу диспетчеризации системных сервисов, хранящуюся в nt!KiServiceTable, так и саму структуру nt!KeServiceDescriptorTable. Это делается с помощью процедуры nt!PgCreateBlockChecksumSubContext, упомянутой в разделе о системных образах. Следующий код показывает, как процедура контрольной суммы блока вызывается для обоих элементов:

Причина, по которой структура nt!KeServiceDescriptorTable также защищается, состоит в предотвращении изменения атрибута, указывающего на фактическую таблицу диспетчеризации.

3.2.4. MSR процессора

Современные процессоры ускоряют переход из пользовательского режима в ядро инструкциями syscall и sysenter, тогда как раньше для системных вызовов приходилось выделять программное прерывание. Адрес обработчика ядра хранится в модельно-зависимом регистре (MSR). На x64 это регистр LSTAR — регистр адреса цели длинного системного вызова — с номером 0xc0000082. При загрузке ядро записывает туда адрес nt!KiSystemCall64.

Чтобы сторонний драйвер не перехватил системные вызовы подменой LSTAR, PatchGuard сохраняет значение MSR в защитном подконтексте типа 7. Соответствующая процедура обозначена как PgCreateMsrSubContext:

Как и в случае защиты GDT/IDT, значение MSR LSTAR должно быть получено отдельно для каждого процессора, поскольку значения MSR по своей природе хранятся на отдельных процессорах. Для поддержки этого процедура вызывается в контексте цикла по всем процессорам, и ей передается идентификатор процессора, с которого нужно читать. Чтобы гарантировать, что значение MSR получено с правильного процессора, PatchGuard использует nt!KeSetAffinityThread, заставляя вызывающий поток выполняться на соответствующем процессоре.

3.2.5. Отладочные процедуры

PatchGuard создает специальный подконтекст (тип 6), используемый для защиты некоторых внутренних процедур, которые ядро использует в целях отладки. Эти процедуры, например nt!KdpStub, предназначены для использования как механизм, с помощью которого подключенный отладчик может обработать исключение до того, как ядро передаст его дальше. nt!KdpStub вызывается косвенно через глобальную переменную nt!KiDebugRoutine из nt!KiDispatchException. Процедура, инициализирующая защитный подконтекст для этих процедур, была обозначена как nt!PgCreateDebugRoutineSubContext, и ее прототип показан ниже:

Похоже, структура подконтекста инициализируется указателями на nt!KdpStub, nt!KdpTrap и nt!KiDebugRoutine. Судя по всему, этот подконтекст предназначен для защиты от изменения nt!KiDebugRoutine сторонним драйвером так, чтобы она указывала куда-то еще. Возможны и другие намерения.

3.3. Обфускация контекстов PatchGuard

Чтобы усложнить поиск контекстов PatchGuard в памяти, каждый из них шифруется операцией XOR со случайным 64-битным ключом. Функция nt!PgEncryptContext преобразует переданный буфер на месте и возвращает использованный ключ:

После того как nt!KiInitializePatchGuard инициализирует все отдельные подконтексты, следующее, что она делает, - шифрует основной контекст PatchGuard. Для этого она сначала создает копию контекста на стеке, чтобы к нему можно было обращаться в открытом виде после шифрования. Копия в открытом виде нужна потому, что проверочную процедуру необходимо поставить в очередь на выполнение, а для этого требуется обратиться к некоторым атрибутам структуры контекста. Это подробнее обсуждается в следующем разделе. После создания копии вызывается nt!PgEncryptContext, которой основной контекст PatchGuard передается первым аргументом. После постановки проверочной процедуры в очередь копия в открытом виде больше не нужна и снова обнуляется, чтобы гарантировать отсутствие ссылки в открытом виде. Псевдокод ниже иллюстрирует это поведение:

3.4. Выполнение проверочной процедуры PatchGuard

Сбор контрольных сумм и кэширование значений критических структур - это прекрасно, но все это не значит ровным счетом ничего, если нет способа выполнить проверку. Поэтому PatchGuard прилагает большие усилия, чтобы сделать выполнение проверочной процедуры как можно более скрытным. Это достигается за счет введения в заблуждение и обфускации.

После инициализации всех подконтекстов, но до шифрования основного контекста, nt!KiInitializePatchGuard выполняет одну из своих более критичных операций. На этой фазе процедура, которая будет косвенно использоваться для обработки проверки PatchGuard, случайно выбирается из массива указателей функций и сохраняется по смещению 0x168 в основном контексте PatchGuard. Функции в этом массиве имеют особое назначение, которое будет подробнее обсуждаться далее в этом разделе. Пока просто отметим факт выбора проверочной процедуры.

После выбора проверочной процедуры основной контекст PatchGuard шифруется. Затем nt!KiInitializePatchGuard через nt!KeInitializeTimer настраивает таймер, структура которого встроена в ранее выделенный подконтекст. Сразу за ней, по смещению 0x88, находится 16-битное значение 0x1131. При дизассемблировании это инструкция xor [rcx], edx; из тех же двух байтов начинается nt!CmpAppendDllSection. Сейчас совпадение несущественно, но пригодится далее.

После инициализации структуры таймера PatchGuard начинает процесс постановки таймера в очередь на выполнение, вызывая функцию, обозначенную как nt!PgInitializeTimer, прототип которой показан ниже:

Внутри процедуры nt!PgInitializeTimer происходит несколько странных вещей. Во-первых, инициализируется DPC, который использует случайно выбранную проверочную процедуру, описанную ранее в этом разделе, как DeferredRoutine. Указатель EncryptedContext, переданный как аргумент, затем XOR'ится с аргументом XorKey, чтобы получить полностью фиктивный указатель, который передается как аргумент DeferredContext в nt!KeInitializeDpc. Итоговый псевдокод выглядит примерно так:

После инициализации DPC вызывается nt!KeSetTimer, которая ставит DPC в очередь на выполнение. Аргумент DueTime генерируется случайно, чтобы усложнить сигнатурное обнаружение, но с заданной верхней границей, чтобы гарантировать выполнение в разумный срок. После установки таймера nt!PgInitializeTimer возвращается к вызывающему коду.

После инициализации таймера и его настройки на выполнение nt!KiInitializePatchGuard завершает свою работу и возвращается в nt!KiFilterFiberContext. Ошибка деления, которая запустила весь процесс инициализации, исправляется, и выполнение восстанавливается на инструкцию, следующую за div в nt!KiDivide6432, позволяя ядру загрузиться обычным образом.

Но это только половина веселья. Настоящий вопрос теперь в том, как выполняется проверочная процедура. Кажется очевидным, что это связано с DPC-процедурой, использованной при установке таймера, поэтому самое логичное место для изучения - именно там. Как мы помним из предыдущего обсуждения, nt!KiInitializePatchGuard случайно выбрала адрес проверочной процедуры из массива процедур. Этот массив можно найти, посмотрев на следующее дизассемблирование из процедуры инициализации PatchGuard:

Здесь применяется тот же приём обфускации, что и для массива тегов пула. Массив DPC-процедур находится по адресу базы nt плюс 0x430428:

Это сообщает нам возможные варианты DPC-процедур, которые может использовать PatchGuard, но не объясняет, как это фактически приводит к проверке защитных контекстов. Логически следующий шаг - попытаться понять, как работает одна из этих процедур с учетом передаваемого ей DeferredContext, поскольку из nt!PgInitializeTimer известно, что аргумент DeferredContext будет указывать на контекст PatchGuard, XOR'нутый с ключом шифрования. Из трех процедур nt!ExpTimeRefreshDpcRoutine проще всего понять. Ниже показано дизассемблирование первых нескольких инструкций этой функции:

Deferred-процедуры имеют прототип, принимающий первым аргументом указатель на связанный с ними DPC, а вторым аргументом указатель DeferredContext. Соглашение о вызовах x64 говорит нам, что это соответствует rcx, указывающему на структуру DPC, и rdx, указывающему на DeferredContext. Однако есть проблема. Четвертая инструкция функции пытается выполнить xadd с первой частью DeferredContext. Как говорилось ранее, DeferredContext, передаваемый DPC-процедуре, является результатом XOR-операции с указателем, создающей полностью фиктивный указатель. Это должно означать, что машина немедленно упадет при разыменовании указателя, верно? Очевидно, ответ - нет, и именно здесь виден еще один случай введения в заблуждение.

Дело в том, что nt!ExpTimeRefreshDpcRoutine, nt!ExpTimeZoneDpcRoutine и nt!KiScanReadyQueues - все это совершенно легитимные процедуры, напрямую не имеющие отношения к PatchGuard. Вместо этого они используются как косвенное средство выполнения кода, который действительно имеет отношение к PatchGuard. Уникальность этих трех процедур в том, что все они в какой-то момент разыменовывают свой указатель DeferredContext, как показано ниже:

Операция с DeferredContext вызывает исключение общей защиты, которое попадает в nt!KiGeneralProtectionFault, а затем — в обработчик функции, вызвавшей исключение, например nt!ExpTimeRefreshDpcRoutine. На x64 обработка устроена иначе, чем в 32-битных системах: обработчики задаются при компиляции и находятся через nt!RtlLookupFunctionEntry. Эта процедура возвращает структуру RUNTIMEFUNCTION с данными раскрутки стека, включая адрес обработчика исключения. Адрес обработчика для nt!ExpTimeRefreshDpcRoutine можно найти в отладчике так:

При определённом условии обработчик вызывает nt!KeBugCheckEx с кодом аварийной остановки 0x109, которым PatchGuard сообщает о подмене критической структуры. Значит, обработчик как минимум частично относится к PatchGuard.

Обработчики исключений для каждой из трех процедур примерно эквивалентны и выполняют одни и те же операции. Если DeferredContext не был неожиданно изменен, обработчики исключений в конечном итоге вызывают копию кода из INITKDB, находящуюся в защитном контексте, конкретно nt!FsRtlUninitializeSmallMcb. Эта процедура вызывает символ с именем nt!FsRtlMdlReadCompleteDevEx, который фактически отвечает за вызов различных процедур проверки подконтекстов.

3.5. Сообщение о несоответствиях проверки

Обнаружив изменение, PatchGuard вызывает копию nt!SdpCheckDll, а затем через таблицу функций контекста передаёт параметры в nt!KeBugCheckEx. Перед переходом nt!SdbpCheckDll обнуляет стек и регистры до текущего кадра, затрудняя перехват сообщения об аварийной остановке и восстановление. Если расхождений нет, создаётся новый контекст PatchGuard и заново устанавливается таймер с прежней проверочной процедурой.

4. Подходы к обходу

Разобрав основные механизмы PatchGuard, рассмотрим способы отключить или обмануть проверку. Очевидные варианты — собственный загрузчик до инициализации PatchGuard или модификация ntoskrnl.exe — требуют вмешательства и перезагрузки. Здесь же цель состоит в одной или нескольких функциях, которые можно встроить в драйвер и вызвать для отключения защиты, сохранив существующие способы перехвата критических структур.

Важно отметить, что некоторые из перечисленных здесь подходов не тестировались и являются чисто теоретическими. Те, которые были протестированы, будут отмечены. Однако прежде чем погружаться в конкретные подходы обхода, важно также рассмотреть общие техники для отключения PatchGuard на лету. Во-первых, нужно учитывать, как проверочная процедура настраивается на запуск и от чего она зависит для выполнения проверки. В данном случае проверочная процедура настроена на выполнение в контексте таймера, связанного с DPC, который выполняется из системного рабочего потока и в конечном итоге приводит к вызову обработчика исключений. Используемая DPC-процедура случайно выбирается из небольшого пула функций, а объекту таймера назначается случайный DueTime, чтобы усложнить обнаружение.

Известно также, что при расхождении PatchGuard вызывает nt!KeBugCheckEx с определённым кодом аварийной остановки. Это даёт ещё одну точку для обхода.

4.1. Перехват обработчика исключений

Проверки косвенно зависят от обработчиков исключений трёх таймерных DPC. Если заменить каждый обработчик пустой операцией, то после исключения общей защиты он не выполнит проверку. Этот подход проверен и работает на рассматриваемой версии PatchGuard.

Используемый для этого подход состоит в том, чтобы сначала найти список процедур, которые, как известно, связаны с PatchGuard. В нынешнем виде список содержит только три функции, но в будущем он может измениться. После нахождения массива процедур необходимо извлечь обработчик исключений каждой процедуры, а затем пропатчить его так, чтобы он возвращал 0x1, а затем выполнял return. Пример функции, реализующей этот алгоритм, приведен ниже:

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

Для противодействия достаточно переместить массив DPC-процедур подальше от массива тегов пула либо разбить сами теги так, чтобы они не образовывали легко обнаружимую непрерывную строку. Тогда адрес массива придётся жёстко задавать или вычислять иначе. Реализовать такую защиту сравнительно просто.

4.2. Перехват KeBugCheckEx

PatchGuard должен сообщать об обнаруженном изменении и останавливать систему, не позволяя стороннему коду продолжить работу. Для этого nt!KeBugCheckEx вызывает аварийную остановку с кодом 0x109, оставляя пользователю понятную причину сбоя вместо необъяснимого выключения или перезагрузки.

Первая идея — заставить nt!KeBugCheckEx вернуться не к непосредственному вызывающему коду, после которого компилятор обычно ставит отладочную ловушку, а на уровень выше. Но PatchGuard перед вызовом обнуляет стек, уничтожая ссылки на родительские кадры. На первый взгляд перехват nt!KeBugCheckEx поэтому кажется тупиком, однако это не так.

Можно не восстанавливать контекст из регистров и стека, а воспользоваться сохранённой точкой входа потока. У системных рабочих потоков она обычно указывает на nt!ExpWorkerThread; такие потоки лишь обрабатывают задания очереди и просроченные DPC, поэтому исходный параметр контекста несущественен. Перехватчик nt!KeBugCheckEx пропускает обычные коды в настоящую функцию, а при 0x109 устанавливает указатель стека в границу стека минус восемь и переходит на StartAddress. Поток возвращается к нормальной обработке заданий и DPC.

Хотя более очевидный подход состоял бы в простом завершении вызывающего потока, сделать это было бы невозможно. Операционная система отслеживает системные рабочие потоки и обнаружит, если один из них завершится. Завершение системного рабочего потока приведет к синему экрану системы - именно к тому, чего пытаются избежать.

Следующий код реализует описанный выше алгоритм. Он довольно велик по причинам, которые будут обсуждаться после фрагмента:

Подход проверен на актуальной на момент написания версии PatchGuard. Он не зависит от неэкспортируемых символов и сигнатур, не создаёт накладных расходов — nt!KeBugCheckEx вызывается лишь перед падением — и не страдает от состязаний. Главный недостаток — предположение, что системный рабочий поток всегда можно безопасно перезапустить с его точки входа и контекстом NULL.

Чтобы устранить этот подход как возможную технику обхода, Microsoft могла бы сделать одно из нескольких действий. Во-первых, она могла бы создать новый защитный подконтекст, который хранит контрольную сумму nt!KeBugCheckEx и вызываемых ею функций. Если будет обнаружено, что nt!KeBugCheckEx была изменена, PatchGuard мог бы выполнить жесткую перезагрузку без вызова внешних функций. Хотя это менее желательное поведение, похоже, это один из немногих способов, которыми Microsoft могла бы надежно решить проблему. Любой другой подход, полагающийся на вызов внешней функции, которую можно найти по детерминированному адресу, создавал бы возможность для похожей техники обхода.

Менее полезная контрмера — обнулить часть полей потока перед вызовом nt!KeBugCheckEx. Она сломает именно описанную реализацию, но не другие способы вернуть рабочий поток к нормальной обработке заданий очереди.

4.3. Поиск таймера

Непроверенный теоретический способ — найти таймер PatchGuard эвристически. Его DeferredRoutine указывает на nt!KiScanReadyQueues, nt!ExpTimeRefreshDpcRoutine или nt!ExpTimeZoneDpcRoutine; адреса не экспортируются, но остаются полезным признаком. DeferredContext содержит недопустимый указатель, а по смещению 0x88 от начала таймера находится 16-битное значение 0x1131. Дополнительные признаки могли бы позволить однозначно распознавать нужный таймер.

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

Можно просматривать память от nt!MmNonPagedPoolStart, проверяя эти признаки, и тем самым обойтись без неэкспортируемых символов. При хорошем наборе условий таймер, вероятно, удастся находить надёжно. Остаётся состязание: DPC может запуститься между обнаружением таймера и его отменой. Поэтому ищущий поток должен повысить IRQL и, возможно, временно остановить остальные процессоры.

Найдя таймер, достаточно вызвать nt!KeCancelTimer, прервать проверку и полностью отключить PatchGuard без изменения кода.

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

4.4. Гибридный перехват

До сих пор использовались две точки перехвата. Обработчик исключений не даёт проверке запуститься — это вмешательство «до события». Перехват nt!KeBugCheckEx подавляет сообщение уже обнаруженной ошибки — вмешательство «после события». Их можно объединить для более надёжного обнаружения выполнения PatchGuard.

Один вариант — вместо отдельных обработчиков DPC перехватить центральную точку входа для исключений C, экспортируемую процедуру nt!__C_specific_handler. Тогда можно отслеживать и фильтровать исключения, при необходимости сопоставляя их с признаками «после события» и определяя запуск PatchGuard.

4.5. Имитация горячего исправления

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

5. Заключение

Разработка решения, предназначенного для смягчения несанкционированной модификации различных критических частей ядра, может рассматриваться как довольно сложная задача, особенно с учетом необходимости гарантировать, что сами процедуры, используемые для проверки ядра, не могут быть подделаны. Этот документ показал, как Microsoft подошла к проблеме в своей реализации PatchGuard в версиях ядра Windows на базе x64. Подробно объяснены реализации подходов, используемых для защиты различных критических структур данных, связанных с ядром, таких как системные образы, SSDT, IDT/GDT и MSR.

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

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

Запрет изменений ядра ради стабильности имеет цену. Windows — закрытая система, и сторонним поставщикам иногда приходится выходить за рамки документированных интерфейсов, особенно разработчикам средств защиты, которые стремятся внедриться глубже вредоносного кода. Легитимные компании могут отказаться от обхода PatchGuard по деловым соображениям, тогда как вредоносная программа ограничивать себя не станет и получит преимущество. Поэтому Microsoft приходится предлагать поставщикам приемлемые документированные альтернативы.

Еще один важный вопрос состоит в том, действительно ли Microsoft сломает поставщика, развернувшего на миллионах систем решение, которое отключает PatchGuard через технику обхода. Вполне можно представить, что McAfee или Symantec сделают нечто подобное, хотя Microsoft надеялась бы использовать свои деловые связи, чтобы McAfee и Symantec не пришлось прибегать к такой технике. Тот факт, что McAfee и Symantec являются очень крупными компаниями, дает им определенный рычаг в переговорах с Microsoft, но меньшие компании, скорее всего, не получат такого же уровня уважения и внимания.

Остаётся вопрос, верно ли выбран сам подход. Если обновления будут намеренно ломать способы обхода, поставщики могут перейти к всё более рискованным решениям, снизив стабильность. Даже при наличии одобренных точек перехвата всегда найдётся задача, требующая помощи Microsoft. Сторонним драйверам нужна совместимость со всеми выпущенными версиями x64; решение, работающее лишь на части систем, для большинства компаний непригодно.

Возможной альтернативой была бы чётко определённая и одобренная модель перехвата, подобная перехвату служб VxD в Windows 9x. Легитимные продукты обычно вставляют слой между крупными подсистемами — оборудованием и ядром либо пользовательским режимом и ядром. Многие сбои вызваны неверными предположениями в самих перехватчиках, поэтому Microsoft могла бы документировать ограничения каждой доступной для перехвата функции.

Сначала такую модель можно ограничить экспортируемыми процедурами и использовать существующую документацию об их поведении, IRQL и правилах вызова. Позднее похожий интерфейс можно предоставить для распространённых неэкспортируемых операций. Это несколько ограничит свободу развития ядра, но документированные экспорты и без того нельзя произвольно удалять или менять после выпуска. Поэтому официальная модель перехвата для них была бы осуществимой и сравнительно безопасной.

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

Библиография

AMD. The AMD x86-64 Architecture Programmers Overview. <http://www.amd.com/us-en/assets/contenttype/whitepapersandtechdocs/x86-64overview.pdf>; дата обращения: 30 ноября 2005 г.

AMD. AMD64 Architecture Programmer's Manual Volume 3. <http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594.pdf>; дата обращения: 1 декабря 2005 г.

Microsoft Corporation. Patching Policy for x64-Based Systems. <http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx>; дата обращения: 28 ноября 2005 г.

Аннотация: статья рассматривает теорию и практику создания полезной нагрузки для режима ядра Windows. На момент написания эта область известна немногим исследователям; авторы надеются способствовать её вдумчивому развитию. Описаны общие методы и алгоритмы, а сама нагрузка разделена на четыре функциональных компонента. В результате читатель должен понять, как устроен и работает исполняемый код эксплойта в ядре Windows.

Благодарности: авторы благодарят Барнаби Джека и Дерека Содера из eEye за превосходную статью о полезной нагрузке кольца 0, а также jt, spoonm, vax и всех участников nologin.

Отказ от ответственности: предмет, обсуждаемый в этом документе, представлен в образовательных целях. Авторы не могут нести ответственность за то, как эта информация будет использована. Хотя авторы попытались провести анализ как можно более тщательно, возможно, они допустили одну или несколько ошибок. Если вы заметите ошибку, пожалуйста, свяжитесь с одним или обоими авторами, чтобы ее можно было исправить.

Примечания: в большинстве случаев тестирование выполнялось на Windows 2000 SP4 и Windows XP SP0. Совместимость с другими версиями операционных систем, такими как XP SP2, выводилась путем анализа смещений структур и дизассемблирования. Теоретически многие реализации, описанные в этом документе, также совместимы с Windows 2003 Server SP0/SP1, но из-за отсутствия рабочей установки 2003 тестирование выполнить не удалось.

2. Введение

За предыдущие годы эксплуатация ошибок пользовательского режима и нужные для неё нагрузки были подробно изучены. Средства защиты начали применять разнообразные способы противодействия, и внимание атакующих постепенно сместилось к ядру. Такие уязвимости дают более высокие привилегии и остаются сравнительно малоисследованными, что особенно привлекает специалистов.

Статья помогает перенести знания из пользовательского режима в ядро Windows. Полезная нагрузка превращает простой захват управления в осмысленное действие; без неё уязвимость обычно позволяет лишь вызвать отказ в обслуживании. Начало публичному исследованию этой темы положили Барнаби Джек и Дерек Содер из eEye.

Нагрузки пользовательского режима и ядра используют повторяющиеся методы и алгоритмы, рассмотренные в главе 3. Их удобно собирать из самостоятельных компонентов с конкретным назначением. Например, необязательный загрузчик первого этапа получает и запускает основной этап. Но код ядра должен учитывать дополнительные ограничения, отсутствующие у пользовательского кода, поэтому его устройство включает ещё несколько компонентов, подробно разобранных в главе 4.

Цель документа — дать отправную точку для понимания свойств, общих почти всем таким нагрузкам. Далее код режима ядра обозначается R0 — от кольца 0 процессора x86, а код пользовательского режима — R3, от кольца 3. Читателю понадобятся базовые знания программирования ядра Windows.

Конкретные способы захватить управление при разных уязвимостях здесь не разбираются: общая реализация нагрузки от них обычно не зависит. Ссылки на соответствующие исследования приведены в библиографии. За рамками остаются и более сложные задачи вроде перехвата клавиатурного ввода. Авторы надеются, что описание базовых элементов упростит дальнейшую разработку таких возможностей.

Начнём с общих методов, применимых к коду режима ядра.

3. Общие техники

В этой главе описаны методы, общие для большинства нагрузок: например, поиск адресов экспортируемых функций, необходимый и в пользовательском режиме.

3.1. Поиск базового адреса Ntoskrnl.exe

Почти любая нагрузка пользовательского режима сначала находит базовый адрес kernel32.dll. В ядре её логическим аналогом служит ntoskrnl.exe, далее сокращённо nt: он реализует основную часть ядра и предоставляет библиотечный интерфейс драйверам. Его экспортируемые процедуры полезны нагрузке, поэтому прежде всего нужно определить базовый адрес образа. Ниже рассмотрено несколько способов.

Распространённый способ — получить надёжный указатель внутрь nt и двигаться к меньшим адресам до сигнатуры MZ. Далее он называется нисходящим сканированием; это тот же приём, который eEye называет mid-delta, но с явно указанным направлением. Примеры проверяют адреса с шагом PAGESIZE. Такая оптимизация увеличивает код на четыре байта; при жёстком ограничении размера можно сканировать побайтно, как в статье eEye.

Еще одна вещь, которую нужно помнить о некоторых из этих реализаций: они могут отказать, если указан загрузочный флаг /3GB. Обычно это не очень распространено, но в реальном мире такое может встретиться.

3.1.1. Нисходящее сканирование от IDT

В статье eEye предлагается получить адрес обработчика из таблицы дескрипторов прерываний (IDT), указывающий внутрь nt, а затем побайтно двигаться вниз до сигнатуры MZ. Приём показан в следующем листинге:

Есть риск принять за заголовок случайное совпадение с сигнатурой внутри образа; он присущ всем вариантам mid-delta. Побайтный поиск теоретически особенно уязвим к такому совпадению, хотя авторам неизвестны реальные отказы. Он также зависит от очищенного флага направления и может содержать нежелательный нулевой байт. Проверка по одной странице устраняет обе последние проблемы. Шаг в шестнадцать страниц использовать нельзя, поскольку такое выравнивание образа в ядре не гарантируется. Улучшенный вариант занимает 20 байт:

3.1.2. Нисходящее сканирование от KPRCB IdleThread

Поле IdleThread структуры KPRCB текущего процессора, по наблюдениям, всегда указывает на глобальную переменную внутри nt. Его можно взять как начальную точку и двигаться вниз до заголовка MZ:

Этот подход откажет, если окажется, что атрибут IdleThread не указывает куда-то внутрь nt, но до сих пор такой сценарий не наблюдался. Он также отказал бы, если бы атрибут Kprcb не находился непосредственно после Kpcr, но в тестировании этого не наблюдалось.

3.1.3. Нисходящее сканирование от SYSENTER_EIP_MSR

На процессорах с регистром системного вызова 0x176 (SYSENTER_EIP_MSR) можно прочитать адрес обработчика, а затем найти базу тем же нисходящим поиском:

3.1.4. Сканирование от известного переносимого адреса

Сравнение крупных выпусков показывает общий диапазон отображения nt; исключением оказался Windows Server 2003 SP1. Поэтому можно начать с адреса, заведомо попадающего внутрь образа во всех остальных версиях. Диапазоны приведены в таблице:

Адрес 0x8050babe находится внутри nt во всех перечисленных системах, кроме Windows Server 2003 SP1. Следующий код использует это свойство:

3.2. Разрешение символов

Почти любой машинный код для Windows обходит каталог экспорта образа, чтобы найти адрес функции. Этот старый приём в ядре работает так же. Барнаби в статье eEye использует двухбайтовый хэш XOR/ROR. Четырёхбайтовое значение уменьшает риск коллизий, но напрасно увеличивает код, если двух байт достаточно.

Реализация принимает двухбайтовый хэш в ebx и базу образа в ebp. После нахождения адреса она сразу передаёт управление функции, объединяя поиск и вызов и не сохраняя адрес отдельно. Обычно это уменьшает размер.

Рассмотрим поиск nt!ExAllocatePool. Хэш строки «ExAllocatePool» по тому же алгоритму равен 0x0311b83f; его вычисляет команда perl -Ilib -MPex::Utils -e "printf .8x, Pex::Utils::Ror(Pex::Utils::RorHash("ExAllocatePool"), 13);". Реализации нужны только младшие два байта 0xb83f, помещаемые в bx, а база nt передаётся в ebp. Аргументы ExAllocatePool следует заранее положить в стек, поскольку после успешного поиска процедура сразу переходит к найденной функции.

Недостаток — невозможность получать адреса экспортируемых данных: процедура пытается перейти по найденному адресу. Для данных следует убрать jmp и вернуть значение вызывающему коду. Перед поиском также важно очистить флаг направления командой cld.

4. Компоненты полезной нагрузки

Полезная нагрузка ядра складывается из четырёх компонентов. После захвата управления нужно учесть уровень запросов прерываний (IRQL), подготовить среду для кода, безопасно продолжить работу системы и выполнить собственно полезное действие. Часть этих задач имеет аналоги в пользовательском режиме, часть специфична для ядра.

Первый вопрос — подходящий ли IRQL имеет процессор. Если нужная функция разрешена только на PASSIVE_LEVEL, исполнение необходимо перенести в безопасный контекст. Нужда в этом зависит от уязвимости; соответствующий компонент далее называется переносом выполнения.

Вторая задача — разместить и запустить основной этап R3 либо дополнительный этап R0 в другом месте. Её выполняет небольшой загрузчик, похожий на пользовательские аналоги, но обычно переносящий код в другой процесс или поток ядра. Если такой перенос одновременно обеспечивает безопасный IRQL, загрузчик включает в себя и функцию переноса выполнения.

Третья задача — восстановить штатное выполнение после завершения нагрузки. Этот компонент должен не дать ядру упасть или остаться в повреждённом состоянии. Иначе основной код может даже не успеть отработать. Восстановление — одна из самых сложных и критичных частей.

Четвёртый компонент — основной этап, выполняющий полезное действие. Он может, например, дождаться контекста lsass.exe и создать обратную командную оболочку в пользовательском режиме. В демонстрации eEye другой вариант перехватывал клавиатуру и отправлял нажатия в ответах ICMP Echo. Определение этапа намеренно широко.

Следующие разделы подробно разбирают четыре компонента и подходящие для разных ситуаций реализации.

4.1. Перенос выполнения

Ядро Windows работает на разных уровнях запросов прерываний (IRQL). Текущий уровень маскирует прерывания с меньшим приоритетом и гарантирует, что критический код не будет прерван менее важным потоком либо аппаратным или программным событием. Модель драйверов запрещает некоторые действия на высоких уровнях. На DISPATCH_LEVEL и выше нельзя блокировать поток или обращаться к выгруженной странице памяти.

IRQL в момент срабатывания зависит от уязвимого участка. Часто его приходится прямо или косвенно снизить, прежде чем вызывать обычные вспомогательные функции драйверов. Например, nt!KeInsertQueueApc разрешена только на PASSIVE_LEVEL.

Ниже рассмотрены способы перенести выполнение на уровень, где доступны выгружаемая память и стандартные функции поддержки драйверов. Они различаются простотой и надёжностью, поэтому выбор зависит от конкретной задачи.

4.1.1. Прямая настройка IRQL

Самый прямой способ перейти на безопасный IRQL — принудительно снизить текущий уровень. eEye предложила найти и вызвать hal!KeLowerIrql, передав, например, PASSIVE_LEVEL. Это опасно: код мог войти на высокий уровень с удерживаемыми блокировками и другими предположениями, нарушение которых приводит к взаимной блокировке или падению системы.

Можно повторить действие hal!KeLowerIrql напрямую. Это оболочка над hal!KfLowerIrql, которая меняет поле Irql структуры KPCR текущего процессора и вызывает обработчики накопившихся программных прерываний. Для минимальной нагрузки достаточно записать PASSIVE_LEVEL по адресу fs:0x24, поскольку в режиме ядра fs указывает на KPCR.

Прямая запись не вызывает обработчики программных прерываний, накопленных при высоком IRQL. Теоретически это способно вызвать взаимную блокировку. В опыте драйвер поднимал уровень до HIGHLEVEL, некоторое время удерживал его при поступающих событиях клавиатуры и мыши, а затем напрямую снижал описанным способом. Видимых последствий не возникло, но безопасность метода не доказана.

Помимо рисков, этот подход хорош тем, что он очень мал, всего 6 байт, поэтому при отсутствии серьезных проблем его использование было бы очевидным выбором при правильном наборе обстоятельств уязвимости.

4.1.2. Перехват системных вызовов через MSR или IDT

Относительно простой способ — перехватить диспетчер системных вызовов. На новых процессорах его адрес хранится в специальном регистре модели STAR с номером 0x176 и получает управление при системном вызове.

В Windows XP и новее сначала читают и сохраняют исходный адрес из MSR. Второй этап R0 копируют в общедоступную свободную область, например SharedUserData или KPRCB, а регистр направляют на него. При следующем системном вызове этап выполнится на PASSIVE_LEVEL, после чего сможет передать управление штатному диспетчеру.

В Windows 2000 и на старом оборудовании XP применяется эквивалентный перехват записи IDT для программного прерывания 0x2e. Каждый системный вызов запускает перенесённый код; копирование второго этапа выполняется так же.

Ниже приведён один вариант загрузчика для Windows 2000 и XP.

1. Определить способ перехвата системного вызова.

Нулевой KUSER_SHARED_DATA.NtMinorVersion по адресу 0xffdf0270 указывает на Windows 2000, где нет syscall/sysenter и нужно менять IDT. Иначе перехватывается MSR:0x176, хотя в редких конфигурациях XP этот путь может не использоваться. Предполагается, что NtMajorVersion равен 5.

2. Сохранить адрес штатной процедуры.

Для MSR текущее значение читается командой rdmsr при ecx = 0x176 и возвращается в edx:eax. Для записи IDT 0x2e команда sidt получает базу таблицы, а нужная KIDTENTRY находится по смещению 0x170. Адрес обработчика составляется из младшего слова Offset и старшего ExtendedOffset. Определение структуры приведено ниже.

3. Перенести полезную нагрузку.

Относительно безопасное место — свободная область после KPCR первого процессора. По адресу 0xffdffd80 сохраняется штатный обработчик, код копируется с 0xffdffd84, а завершение выполняет jmp [0xffdffd80]. Нагрузка обязана сохранить все регистры и не пересечь границу страницы, что ограничивает её 630 байтами. Исторически код R0 размещали после SharedUserData, доступной всем процессам R3, но это лишнее, если пользовательский доступ не нужен. Недостаток области KPCR — меньший размер.

4. Установить перехват.

Установка использует те же адреса. Для изменения Offset и ExtendedOffset записи IDT прерывания текущего процессора временно отключаются; в многопроцессорной системе это безопасно, поскольку у каждого процессора своя IDT. Для MSR новый адрес (0x0:0xffdffd84) помещается в edx:eax, номер 0x176 — в ecx, после чего выполняется wrmsr.

Следующая реализация загрузчика занимает около 97 байт без основного этапа и восстановления. Если убрать поддержку IDT, размер уменьшается примерно до 47 байт.

4.1.3. Уведомление о создании потока

Другой способ — зарегистрировать уведомление о создании потока, штатно через nt!PsSetCreateThreadNotifyRoutine. Документация разрешает вызывать её только на PASSIVE_LEVEL, но запись можно вручную добавить в глобальный массив обработчиков. Массив не экспортируется, однако ссылка на него находится внутри nt!PsSetCreateThreadNotifyRoutine или nt!PsRemoveCreateThreadNotifyRoutine. Обработчик будет вызван при создании или удалении потока уже на безопасном уровне.

Более подробно: чтобы это корректно работало на 2000 и XP, нужно выполнить несколько шагов. Шаги для 2003 должны быть почти такими же, как для XP, но они не тестировались.

1. Найти базовый адрес nt.

Базовый адрес nt нужно определить, чтобы можно было разрешить экспортируемый символ.

2. Определить текущую операционную систему.

Поскольку регистрация уведомления различается в Windows 2000 и XP, версия определяется по NtMinorVersion в KUSER_SHARED_DATA по адресу 0xffdf0270.

3. Настроить edi на буфер хранения.

Исходный буфер может исчезнуть до уведомления, поэтому основной этап копируется в постоянную область с адреса 0xffdf04e0.

4. Вариант для XP.

В XP нужно создать структуру обратного вызова в общей памяти и вручную вставить её в nt!PspCreateThreadNotifyRoutine. Поддельная структура размещается по 0xffdf04e0, а исполняемый код — по 0xffdf04e8. Указатель функции находится по смещению 0x4, но для экономии оба первых поля направляются на код.

В XP нужно увеличить nt!PspCreateThreadNotifyRoutineCount, иначе обработчик не вызовется. В проверенных версиях счётчик находится через 0x20 байт после массива.

5. Вариант для Windows 2000.

В Windows 2000 nt!PspCreateThreadNotifyRoutine — простой массив указателей. Можно безопасно вызвать экспортируемую nt!PsSetCreateThreadNotifyRoutine: она не выделяет дополнительную память и сама обновляет счётчик, расположенный далеко от массива.

6. Разрешить экспортируемый символ.

Поиск сравнивает часть имени экспорта со строкой dNot. В XP ссылка на nt!PspCreateThreadNotifyRoutine извлекается из тела nt!PsRemoveCreateThreadNotifyRoutine, а в Windows 2000 напрямую вызывается nt!PsSetCreateThreadNotifyRoutine. Поэтому смещение сравниваемой подстроки равно соответственно 0x13 и 0x10. В результате eax получает адрес нужной функции для выбранной системы.

7. Скопировать второй этап.

После поиска символа второй этап копируется в выбранную ранее область.

8. Установить запись уведомления.

В XP поддельная структура вручную добавляется в nt!PspCreateThreadNotifyRoutine, а счётчик увеличивается. В Windows 2000 вызывается nt!PsSetCreateThreadNotifyRoutine с адресом скопированного второго этапа.

Реализация показана ниже:

Этап R0 вызывается как обратный обработчик, поэтому должен завершаться ret 0xc или эквивалентом и быть безопасным при повторном входе. Вероятна совместимость с Server 2003, но она не проверялась. Код можно сильно уменьшить для одной версии ОС. Главное преимущество — готовые аргументы ProcessId и ThreadId, полезные для внедрения R3.

Недостатки — большой размер, зависимость от нестабильных смещений, особенно в XP, и необходимость присутствия страниц массива в физической памяти. Если страница выгружена, код на повышенном IRQL не сможет обработать страничное нарушение и завершится неудачей.

4.1.4. Перехват процедур инициализации типов объектов

Теоретически можно перехватить одну из процедур типа объекта, например nt!PsThreadType или nt!PsProcessType, адреса которых находятся в OBJECTTYPEINITIALIZER. Найдя экспортируемый тип, поле вроде OpenProcedure направляют на буфер нагрузки. Код проверяет текущий IRQL или полагается на то, что конкретная процедура вызывается на PASSIVE_LEVEL. Мэтт Коновер описал этот подход в статье «Malware Profiling and Rootkit Detection on Windows»; идею также предложил Дерек Содер.

4.1.5. Перехват KfRaiseIrql

Дерек Содер предложил перехватить hal!KfRaiseIrql. Обработчик проверяет, находится ли процессор на PASSIVE_LEVEL, и при подходящем уровне запускает остальную нагрузку. Главная трудность — дорогой по размеру перехват пролога в стиле Detours, хотя защиту записи кода отключить нетрудно. Идея остаётся перспективным способом дождаться безопасного IRQL.

4.2. Загрузчики этапов

Загрузчик подготавливает отдельный этап R0 или R3. В пользовательском режиме он часто читает код из сети, но в ядре основной этап обычно уже присоединён: компактно реализовать сетевое чтение трудно. Ниже рассмотрены способы запуска этапа на обоих уровнях; чисто теоретические варианты отмечены отдельно.

Вместо сетевого чтения можно использовать поиск метки в адресном пространстве. Если второй этап удаётся надолго разместить в памяти вместе с узнаваемым маркером, небольшой начальный код найдёт его самостоятельно. Это уменьшает объём данных, которые нужно доставить через уязвимость.

4.2.1. Перезапись адреса возврата системного вызова

Теоретически MSR системного вызова можно перехватить и заменить пользовательский адрес возврата адресом этапа R3. Тогда каждый возврат из ядра сначала проходит через код атакующего, который способен фильтровать результаты системных вызовов, а затем продолжает по настоящему адресу. Это основа простого резидентного руткита с небольшими накладными расходами.

Сначала основной этап копируется в общую область, например SharedUserData, затем перехватывается MSR системного вызова. Обработчик заменяет пользовательский адрес возврата адресом этапа и сохраняет настоящий адрес. После штатного системного вызова этап выполняется, восстанавливает регистры, включая eax, и продолжает работу по исходному адресу.

Такой способ почти незаметен и должен быть надёжным, а возможность фильтровать результаты особенно полезна для резидентного руткита.

4.2.2. APC потока

Естественный способ перейти из R0 в R3 — асинхронный вызов процедуры (APC), выполняющий код в контексте существующего потока без нарушения обычного хода работы. Эту технику подробно разбирает статья eEye.

Сначала этап R3 копируют в доступную процессу область, например SharedUserData. Затем выбирают поток привилегированного процесса, находящийся в состоянии прерываемого ожидания; иначе добавить APC в очередь не удастся.

Найдя подходящий поток, структура APC инициализируется через nt!KeInitializeApc, пользовательский обработчик получает адрес этапа, а nt!KeInsertQueueApc добавляет вызов в очередь. Затем код исполнится в контексте выбранного потока.

Главный недостаток — зависимость от недокументированных и меняющихся смещений EPROCESS и ETHREAD. Переносимый вариант возможен, но увеличится из-за определения версии и таблиц смещений.

Реализация eEye хорошо продумана; здесь предлагаются лишь оптимизации. Вызов nt!PsLookupProcessByProcessId можно убрать, если уязвимость срабатывает не в контексте процесса бездействия: текущий процесс извлекается прямо из KPRCB. Способ небезопасен, если KPRCB не расположен сразу после KPCR:

После извлечения процесса перечисление для поиска привилегированного системного процесса можно выполнить точно так же, как описано в статье, то есть перечисляя ActiveProcessLinks.

Ещё одна оптимизация — хранить KAPC в SharedUserData, не находя и не вызывая nt!ExAllocatePool. Эта область так же безопасна на любом IRQL и уменьшает код.

4.2.3. Перехват пользовательского указателя на функцию

Если уязвимость срабатывает в контексте процесса, можно подменить его пользовательские указатели. Например, FastPebLockRoutine направляют на код в SharedUserData, который затем вызывает настоящую процедуру блокировки. Это лишь один из множества вариантов.

4.2.4. Перехват SystemCall в SharedUserData

Особенно полезно перехватить пользовательский диспетчер системных вызовов. В Windows 2000 они выполняются через программное прерывание 0x2e, поэтому способ неприменим. Начиная с XP интерфейс использует специальные инструкции процессора sysenter или syscall.

Чтобы поддержать это, Microsoft добавила поля в структуру KUSER_SHARED_DATA, символически известную как SharedUserData, которые содержали инструкции для выполнения системного вызова. Эти инструкции размещались ядром по смещению 0x300 и имели вид, похожий на код ниже:

Каждая короткая процедура системного вызова в ntdll.dll обращалась к коду по этому адресу.

Изначально SharedUserData содержала инструкции и потому была исполняемой. При внедрении предотвращения выполнения данных (DEP) в XP SP2 и Server 2003 SP1 Microsoft заменила код в KUSER_SHARED_DATA указателями на функции внутри ntdll.dll, устранив ненужную возможность исполнения. Изменение видно ниже:

После изменения каждая короткая процедура выполняет косвенный вызов через указатель SystemCall:

Манипулируя интерфейсом диспетчеризации, можно с малыми затратами перейти из R0 в R3. Пользовательский этап помещается между короткими процедурами системных вызовов и ядром и запускается перед настоящим вызовом в контексте любого процесса.

Преимущества — малый размер без разрешения символов и планирования конкретного процесса, а также безопасность на любом IRQL: SharedUserData не выгружается. Отдельный перенос на безопасный уровень не нужен.

Недостаток — зависимость от исполняемости SharedUserData. При необходимости в записи таблицы страниц можно разрешить исполнение, обойдя DEP.

Этап R3 должен допускать повторный вход: он будет вызываться многократно в разных процессах и обязан сам решать, когда выполнять полезное действие.

Один вариант реализации состоит из следующих шагов.

1. Получить адрес этапа R3.

Сначала любым доступным способом определяется адрес этапа R3.

2. Скопировать этап в общую область.

Затем этап копируется в общую исполняемую область, например SharedUserData.

3. Определить версию ОС.

Способ перехвата различается между XP SP0/SP1 и XP SP2/Server 2003 SP1. Первые два байта по 0xffdf0300 сравниваются с 0xd48b, кодом mov edx, esp. Совпадение означает XP SP0/SP1, иначе предполагается XP SP2 или новее.

4. Установить перехват в XP SP0/SP1.

В XP SP0/SP1 первые два байта по 0xffdf0300 заменяются коротким переходом в свободную область SharedUserData, например 0xffdf037c. К этапу добавляются команды восстановления mov edx, esp / mov ecx, 0x7ffe0302 / jmp ecx, чтобы настоящий системный вызов всё же выполнился.

5. Установить перехват в XP SP2 и новее.

В XP SP2 подменяется указатель по смещению 0x300 в SharedUserData. Исходное значение сохраняется в неиспользуемом поле по 0xffdf0308, а этап завершается косвенным jmp через пользовательское отображение 0x7ffe0308, сохраняя работу системных вызовов.

Следующая реализация занимает около 68 байт без этапа R3 и кода восстановления.

4.3. Восстановление

В ядре нельзя просто допустить сбой: машина покажет синий экран, а доставленный код может даже не успеть выполниться. Поэтому после срабатывания уязвимости необходимо возобновить штатную работу. Способ сильно зависит от конкретной ошибки; перечисленные ниже варианты не охватывают все случаи и не всегда оптимальны. Автору эксплойта следует искать наиболее подходящий путь для своего контекста.

4.3.1. Удержание потока в цикле

Если уязвимость срабатывает в некритичном потоке ядра, его можно навсегда заблокировать или оставить в цикле, вообще не восстанавливая прежний путь выполнения.

4.3.1.1. Задержка выполнения потока

eEye предложила блокировать поток через nt!KeDelayExecutionThread без загрузки процессора. Если функция завершается или возвращает ошибку, запасной цикл вызывает nt!KeYieldExecution. Метод допустим при двух условиях:

• поток ядра не является критическим;

• вызывающий код не удерживает исключительных блокировок, например спин-блокировок.

Иначе блокировка способна вызвать взаимную блокировку системы. Реализация требует найти nt!KeDelayExecutionThread, а для надёжного запасного пути ещё и nt!KeYieldExecution; если механизма разрешения символов ещё нет, нагрузка заметно увеличится.

4.3.1.2. Вращение вызывающего потока

Альтернатива — бесконечный цикл на PASSIVE_LEVEL. При подходящем контексте взаимной блокировки не будет, но производительность пострадает. Зато цикл занимает всего два байта:

4.3.2. Создание исключения

Если уязвимая функция защищена обработчиком исключений, достаточно намеренно создать исключение и позволить штатному коду продолжить работу. Такой контекст встречается редко. Проверка проста: вызвать ошибку памяти и посмотреть, переживёт ли её система. Если да, завершающий нагрузку код будет минимальным.

4.3.3. Перезапуск потока

Системный рабочий поток иногда можно безопасно перезапустить с точки входа, не восстанавливая текущую цепочку вызовов. Адрес берётся из недокументированного поля StartAddress структуры ETHREAD, поэтому смещение зависит от версии. Значения приведены в таблице:

Ниже показана реализация для всех перечисленных смещений; испытана она только в XP SP0:

Реализация получает текущий поток через fs:0x124 и определяет версию по KUSER_SHARED_DATA.NtMinorVersion, поскольку смещения StartAddress и восстанавливаемого стека различаются. Затем указатель стека приводится к состоянию при первоначальном вызове, и управление передаётся в StartAddress.

Этот подход, по крайней мере в данной конкретной реализации, может быть тесно связан с уязвимостями, возникающими в процедурах системных рабочих потоков, особенно тех, которые начинаются с nt!ExpWorkerThread. Однако принципы можно применить к другим системным рабочим потокам, если показанная реализация окажется ограниченной. Также важно понимать, что поскольку этот метод зависит от недокументированных версионно-специфичных смещений, весьма вероятно, что он может быть непереносим на новые версии ядра. Этот подход также должен быть совместим с Windows 2003 Server SP0/SP1, но смещения, скорее всего, отличаются, и на данный момент они не были получены или протестированы.

4.3.4. Освобождение блокировок

Главное ограничение многих способов — блокировки, удерживаемые в момент сбоя. Универсальное освобождение разных типов блокировок позволило бы применять более изящное восстановление, но авторы не знают практической общей реализации. Эту задачу разумнее решать отдельно для каждой уязвимости.

Без этого даже успешно вызванная ошибка может закончиться взаимной блокировкой. Риск зависит от контекста и вполне практичен.

4.4. Основные этапы

Основной этап выполняет конечную задачу: перехватывает клавиатуру и передаёт нажатия атакующему, запускает обратную оболочку в пользовательском процессе или делает что-либо ещё. Поэтому раздел не навязывает конкретную реализацию. Примеры для ядра есть в статье eEye, а многочисленные пользовательские нагрузки можно запускать через описанные загрузчики. Вероятно, именно основные этапы станут центром дальнейших исследований.

5. Заключение

Документ представил общие методы создания полезной нагрузки ядра: поиск базового адреса nt, разрешение символов и построение из четырёх самостоятельных компонентов.

Компонент переноса обеспечивает безопасный IRQL. Загрузчик при необходимости перемещает код в другой поток или область памяти. Основной этап выполняет конечную задачу, а компонент восстановления не позволяет ядру упасть после эксплуатации. Вместе они образуют законченную нагрузку.

Хотя конкретные способы захвата управления не рассматривались, исследования наверняка продолжатся. По мере роста интереса ядро пройдёт тот же цикл изучения и защиты, что ранее пользовательский режим. Пока производители сосредоточены на обычных приложениях, здесь остаётся широкое поле для открытий.

Библиография

Conover, Matt. Malware Profiling and Rootkit Detection on Windows. <http://xcon.xfocus.org/archives/2005/Xcon2005_Shok.pdf>; дата обращения: 12 декабря 2005 г.

eEye Digital Security. Remote Windows Kernel Exploitation: Step into the Ring 0. <http://www.eeye.com/data/publish/whitepapers/research/OT20050205.FILE.pdf>; дата обращения: 8 декабря 2005 г.

skape. Safely Searching Process Virtual Address Space. <http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf>; дата обращения: 12 декабря 2005 г.

SoBeIt. How to Exploit Windows Kernel Memory Pool. <http://packetstormsecurity.nl/Xcon2005/Xcon2005_SoBeIt.pdf>; дата обращения: 11 декабря 2005 г.

System Inside. Sysenter. <http://system-inside.com/driver/sysenter/sysenter.html>; дата обращения: 23 ноября 2005 г.

Статья сочетает заражение работающего процесса с пользовательским планировщиком. Первый механизм внедряет вирус в чужой процесс, второй позволяет его коду поочерёдно выполняться вместе с исходной программой. Благодаря этому вирус остаётся скрытым и активным внутри жертвы.

2. Что такое планировщик

Планировщик процессов — компонент ядра, выбирающий, какой процесс выполнить следующим. Он лежит в основе многозадачности Linux, распределяет ресурсы и создаёт впечатление одновременной работы программ. Вирус мог бы вызвать fork() и работать в дочернем процессе, но тот появится в системном списке и привлечёт внимание.

3. Пользовательский планировщик

В отличие от ядра, пользовательский планировщик действует внутри приложения и управляет его потоками, оставаясь подчинённым системному планировщику. Одна из его задач — переключать контекст и передавать процессорное время между потоками. Импровизированный вариант позволяет незаметно чередовать исходный код заражённого процесса с вирусом.

4. Импровизация пользовательского планировщика

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

Можно перехватить функцию и запускать вирус при каждом её вызове, после чего возвращать управление программе. Но функция может вызываться редко или перестать использоваться. Более универсальный механизм дают сигналы.

Сигнал похож на прерывание: ядро в любой момент передаёт управление обработчику, а после его завершения продолжает исходный поток. Поэтому функцию вируса можно зарегистрировать как обработчик SIGALRM и получить почти готовое переключение контекста.

Системный вызов alarm() поручает ядру доставить SIGALRM через заданное время. Периодически планируя сигнал, вирус получает ответ на второй вопрос — когда запускаться. Пример демонстрирует совместную работу alarm() и SIGALRM:

Концепция программы довольно проста: она печатает символ из цикла, выбирая символ через индексную переменную. Примерно каждые пять секунд планируется доставка SIGALRM с помощью системного вызова alarm(). Как только сигнал обработан, вызывается обработчик сигнала, в данном случае функция shapebreaker(), и она разрывает последовательность символов. Затем программа продолжает работу так, будто ничего не произошло. Изнутри функции обработчика сигнала может работать вирус, а после его возврата программа продолжит выполняться без сбоев.

5. Заражение работающего процесса

Заражение выполняется через ptrace(), позволяющий присоединиться к процессу при наличии прав root либо подходящей связи родителя и потомка. В режиме отладки можно менять регистры и читать или записывать память жертвы — именно это нужно для внедрения и запуска вируса. Подробности инъекции приведены в статье «Building ptrace Injecting Shellcodes» из Phrack 59 [1].

5.1. Алгоритм

Имея мотивы, инструменты и знания, получаем план:

Заражатель внедряет основной вирус и небольшой подготовительный фрагмент, затем направляет EIP на последний. Подготовительный код регистрирует обработчик SIGALRM, вычисляет адрес вируса, планирует сигнал и возвращает управление процессу. При доставке сигнала вирус запускается как обработчик.

5.2. Знакомьтесь: Fluffy

Код, реализующий описанную выше теорию:

Несколько замечаний о коде:

Ассемблерная часть собрана единым блоком: подготовительный код расположен перед основным. Она написана как компактный машинный код без нулевых байтов, чтобы уменьшить объём внедрения.

Код вируса предполагает, что он будет выполняться внутри данного зараженного процесса больше одного раза. Это означает, что действия самомодифицирующегося кода, такие как исправление NULL-байтов во время выполнения, сначала проверяют, нужно ли это в текущей итерации вируса.

Каждые 14 секунд вирус проверяет /tmp/fluffy и при отсутствии файла через execve() запускает встроенный сценарий, создающий оболочку с битом SUID.

Системный вызов signal() имеет привычку сбрасывать обработчик сигнала к значению по умолчанию после его вызова. Это означает, что вирус должен заново регистрироваться на сигнал каждый раз. Альтернативное решение - настроить обработчик сигнала с помощью других связанных с сигналами системных вызовов, таких как sigaction() или rtsigaction(), именно так реализована libc-функция signal(). Выбор signal() вместо этих системных вызовов был основан на вопросах размера.

5.3. Дальнейшие вопросы проектирования

Помимо того, что касается самого кода:

Инъекция в верхний адрес предыдущей страницы стека является мерой безопасности, гарантирующей, что код вируса не перезапишет данные программы на стеке. Тестирование вируса на демоне syslogd показало, что это имеет смысл, поскольку syslogd в какой-то момент сумел частично перезаписать код вируса. Распространенная ловушка - NULL-байты: перезапись двумя NULL-байтами, например \x00\x00, создает допустимую ассемблерную инструкцию ADD AL,(EAX), что легко приводит к падению.

Помимо стека, код можно внедрить в секцию .text. На x86 IA-32 страницы выровнены по 4 Кбайт, а программа часто не заполняет последнюю целиком. Образовавшаяся «пещера кода» подходит для небольшого вируса. Поскольку .text защищена от записи, перед самомодификацией придётся вызвать mprotect() для текущей страницы.

Простой автоматический поиск начинается с PID 0 и идёт вверх. При переходе системы на уровень init 3 запускаются демоны, поэтому их PID обычно невелики; примеры — crond, syslogd и inetd.

6. Заключение

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

Ссылки

[1] Building ptrace Injecting Shellcodes. anonymous. <http://www.phrack.org/show.php?p=59&a=12>; дата обращения: 29 декабря 2005 г.

Аннотация:

После появления FU руткиты перестали полагаться на перехват системных функций для сокрытия своего присутствия. Изменение методов атаки потребовало новых средств защиты. Современные детекторы, например BlackLight, ищут скрытые руткитом объекты, а не только следы перехватов. В статье разобран алгоритм обнаружения скрытых процессов в BlackLight и IceSword, описаны слабости современных детекторов и представлена более полная техника сокрытия, прототипом которой служит FUTo.

Благодарности:

Питер благодарит bugcheck, skape, thief, pedram и F-Secure за прекрасные исследования, а также всех участников nologin/research, поддерживающих развитие идей.

C.H.A.O.S. хотел бы поблагодарить Amy, Santa (эта работа заняла три часа в день Рождества), lonerancher, Pedram, valerino и HBG Unit.

2. Введение

За последние год-два мир руткитов заметно изменился. Появился FU, применяющий прямое изменение объектов ядра (DKOM); VICE стал одним из первых детекторов; Sysinternals Rootkit Revealer и F-Secure BlackLight — первыми массовыми средствами поиска руткитов в Windows. Затем появился Shadow Walker, перехватывающий диспетчер памяти и буквально скрывающийся на виду.

Авторы исследовали BlackLight и IceSword, поскольку многие специалисты считают их лучшими детекторами. Разработанный финской компанией F-Secure BlackLight сосредоточен на скрытых процессах и не ищет перехваты системных функций. IceSword применяет очень похожий метод, но предоставляет больше возможностей: показывает перехваченные системные вызовы, скрытые драйверы и открытые порты TCP/UDP, невидимые для программ вроде netstat.

3. Blacklight

Основное внимание уделено BlackLight. Анализ показал, что IceSword использует почти тот же алгоритм, поэтому найденная слабость, скорее всего, относится к обоим продуктам.

BlackLight обнаруживает процессы из пользовательского режима. Его простой алгоритм удивительно эффективен, а анализ осложняют серьёзные средства против отладки. В таблице обработчиков локального хранилища потока (TLS) регистрируется процедура, которая пытается запутать отладчик, раздваивая основной процесс ещё до полной инициализации его объекта. Другие проверки выявляют уже подключившийся отладчик. Авторы не стали обходить каждую меру, а через редактор PE-файлов LordPE обнулили таблицу обработчиков TLS. Это отключило раннюю процедуру и позволило запустить Rohitab API Monitor. Подключить отладчик после этого можно, но при нажатии кнопки сканирования BlackLight всё равно обнаруживал его и завершался, поэтому дальнейший анализ проводился по вызовам API.

Во время проверки видны неудачные вызовы OpenProcess: BlackLight пытается открыть процессы с PID 0x1CC, 0x1D0, 0x1D4, 0x1D8 и так далее. Авторы назвали метод перебором PID (PIDB). Программа последовательно вызывает OpenProcess для всех значений от 0x0 до 0x4E1C и сохраняет успешно открытые процессы. Затем CreateToolhelp32Snapshot создаёт второй список. Процесс, найденный перебором, но отсутствующий в снимке, считается скрытым и показывается пользователю.

3.1. Windows OpenProcess

В Windows функция OpenProcess является оберткой над процедурой NtOpenProcess. NtOpenProcess реализована в ядре в NTOSKRNL.EXE. Прототип функции NtOpenProcess:

Параметр ClientId содержит PID, переданный OpenProcess. Формально он необязателен, но во всех наблюдавшихся вызовах NtOpenProcess был задан.

NtOpenProcess выполняет три основные функции:

1. Проверяет, существует ли процесс, вызывая PsLookupProcessByProcessId.

2. Пытается открыть дескриптор процесса через ObOpenObjectByPointer.

3. При успехе возвращает дескриптор вызывающему коду.

PsLookupProcessByProcessId был следующим очевидным местом для исследования. Один из открытых вопросов состоял в том, как PsLookupProcessByProcessId узнает, что заданный PID является частью действительного процесса. Ответ становится ясен в первых строках дизассемблирования:

Из дизассемблирования видно, что ExMapHandleToPointer ищет запись в PspCidTable по идентификатору процесса.

Теперь у нас есть полная картина того, как Blacklight обнаруживает скрытые процессы:

1. BlackLight перебирает допустимые идентификаторы процессов от 0 до 0x41DC.

2. Blacklight вызывает OpenProcess для каждого возможного PID.

3. OpenProcess вызывает NtOpenProcess.

4. NtOpenProcess вызывает PsLookupProcessByProcessId, чтобы проверить существование процесса.

5. PsLookupProcessByProcessId использует PspCidTable, чтобы проверить существование процесса.

6. NtOpenProcess через ObOpenObjectByPointer получает дескриптор процесса.

7. Если OpenProcess успешен, Blacklight сохраняет информацию о процессе и продолжает цикл.

8. После создания списка процессов путем исчерпания всех возможных PID Blacklight сравнивает список PIDB со списком, созданным вызовом CreateToolhelp32Snapshot. CreateToolhelp32Snapshot - это Win32 API, который делает снимок всех запущенных процессов в системе. Расхождение между двумя списками означает наличие скрытого процесса. Этот случай Blacklight сообщает пользователю.

3.2. PspCidTable

PspCidTable — таблица дескрипторов клиентских идентификаторов процессов и потоков. PID каждого процесса соответствует позиции в этой таблице, а сама переменная указывает на структуру HANDLE_TABLE.

Windows содержит ряд неэкспортируемых функций для изменения PspCidTable и чтения сведений из неё:

• [ExCreateHandleTable] создаёт таблицы дескрипторов, не принадлежащие процессам. Во всех таких таблицах, кроме PspCidTable, записи указывают на заголовки объектов, а не на сами объекты.

• [ExDupHandleTable] вызывается при порождении процесса.

• [ExSweepHandleTable] используется при завершении процесса.

• [ExDestroyHandleTable] вызывается при завершении процесса.

• [ExCreateHandle] создаёт новые записи таблицы дескрипторов.

• [ExChangeHandle] меняет маску доступа дескриптора.

• [ExDestroyHandle] реализует функциональность CloseHandle.

• [ExMapHandleToPointer] возвращает адрес объекта по дескриптору.

• [ExReferenceHandleDebugIn] трассирует дескрипторы.

• [ExSnapShotHandleTables] ищет дескрипторы, например для oh.exe.

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

Поскольку PspCidTable учитывает все процессы и потоки, детектору естественно искать скрытые процессы именно там. Но опора на единственную структуру ненадёжна: изменив её, руткит скрывает процесс и от ОС, и от других программ. Новые алгоритмы должны сверять несколько независимых источников, чтобы одного изменения было недостаточно.

4. FUTo

Для демонстрации слабости BlackLight и IceSword авторы создали FUTo — новую версию руткита FU. Она напрямую изменяет PspCidTable, не вызывая служебные функции, и средствами DKOM скрывает отдельные записи таблицы.

Первая трудность реализации: как и функции семейства ExMapHandleXXX, переменная PspCidTable не экспортируется ядром. FUTo находит PsLookupProcessByProcessId, дизассемблирует её и исследует первый вызов. На момент написания он всегда вёл к ExMapHandleToPointer, первым параметром которой служит PspCidTable. Этого достаточно для обнаружения таблицы.

Способ ненадёжен: даже простая оптимизация ядра может изменить порядок вызовов. Opc0de предложил устойчивый поиск неэкспортируемых переменных PspCidTable, PspActiveProcessHead, PspLoadedModuleList и других без сканирования памяти. Поле KdVersionBlock в области управления процессором указывает на структуру KDDEBUGGER_DATA32 следующего вида:

Структура содержит указатели на многие часто используемые неэкспортируемые переменные и позволяет надёжнее находить PspCidTable и сходные данные.

Вторая трудность серьёзнее. После удаления объекта FUTo заполняет соответствующую HANDLE_ENTRY нулями, обозначая отсутствие процесса. Когда скрытый процесс завершается, система обращается к записи в PspCidTable, разыменовывает нулевой указатель и показывает синий экран. Решение простое, хотя и неэлегантное. Через PsSetCreateProcessNotifyRoutine FUTo регистрирует обработчик создания и удаления процессов. Он вызывается до окончательного завершения скрытого процесса и успевает предотвратить сбой. Удаляя записи вредоносного процесса, FUTo сохраняет их значения и индексы, а перед закрытием восстанавливает, чтобы система разыменовала правильные объекты.

5. Заключение

Крылатая фраза 2005 года звучала так: «Мы снова поднимаем планку обнаружения руткитов». Надеемся, читатель теперь лучше понимает, как ведущие детекторы находят скрытые процессы и как улучшить их алгоритмы. Самый надёжный совет — не подключаться к Интернету, но совместное применение BlackLight, IceSword и Rootkit Revealer заметно повышает шансы сохранить систему чистой. В ближайшие месяцы на Black Hat Amsterdam будет представлен RAIDE (Rootkit Analysis Identification Elimination), лишённый описанных здесь недостатков.

Библиография

Blacklight Homepage. F-Secure Blacklight. <http://www.f-secure.com/blacklight/>

FU Project Page. FU. <http://www.rootkit.com/project.php?id=12>

IceSword Homepage. IceSword. <http://www.xfocus.net/tools/200505/1032.html>

LordPE Homepage. LordPE Info. <http://mitglied.lycos.de/yoda2k/LordPE/info.htm>

Opc0de. 2005. How to get some hidden kernel variables without scanning. <http://www.rootkit.com/newsread.php?newsid=101>

Rohitabs API Monitor. API Monitor - Spy on API calls. <http://www.rohitab.com/apimonitor/>

Russinovich, Solomon. Microsoft Windows Internals Fourth Edition.

Silberman. RAIDE: Rootkit Analysis Identification Elimination. <http://www.blackhat.com/html/bh-europe-06/bh-eu-06-speakers.htmlSilberman>

Аннотация: по мере распространения Windows x64 возрастает потребность в методах, упрощающих анализ машинного кода. Особенно полезны автоматические процедуры, которые ещё до анализа потока команд и данных помогают понять устройство исполняемого файла. В статье кратко описаны изменения, внесённые для поддержки 64-разрядных программ Windows, а затем показаны способы находить функции, размечать их стековые кадры и устанавливать связи с обработчиками исключений. В приложение включён исходный код подключаемого модуля IDA, реализующего эти способы.

Благодарности: автор хотел бы поблагодарить bugcheck, sh0k, jt, spoonm и Skywing.

Обновление: уже после подготовки этого материала в MSDN Magazine вышла статья Мэтта Питрека. В ней много полезных сведений по темам, затронутым в справочной главе настоящей статьи: <http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx>.

Перейдём к делу.

2. Введение

По мере распространения Windows x64 спрос на средства анализа её исполняемых файлов будет только расти. Методы исследования потока команд и данных для архитектуры x64 описаны достаточно хорошо. Гораздо меньше разработаны способы автоматически подготовить программу к анализу: распознать функции и восстановить устройство их стековых кадров. Поэтому сначала рассмотрим изменения, появившиеся в 64-разрядных исполняемых файлах Windows, а затем на их основе улучшим эти начальные этапы анализа. Далее для краткости такие файлы называются исполняемыми файлами x64.

3. Необходимые сведения

Перед разбором методов анализа нужно познакомиться с некоторыми изменениями, внесёнными ради архитектуры x64. Эта глава даёт лишь краткий обзор и не претендует на роль исчерпывающего справочника.

3.1. Формат файла образа PE32+

Формат образа для платформы x64 называется PE32+. Он почти полностью унаследован от PE. Например, 64-разрядные файлы содержат структуру IMAGE_OPTIONAL_HEADER64 вместо IMAGE_OPTIONAL_HEADER. Различия между ними приведены в таблице:

В PE32+ все поля структур, содержавшие непосредственный 32-разрядный виртуальный адрес, а не относительный виртуальный адрес (RVA), были расширены до 64 разрядов. Это относится, например, к структурам IMAGE_TLS_DIRECTORY и IMAGE_LOAD_CONFIG_DIRECTORY.

За исключением некоторых смещений полей в конкретных структурах, формат файла образа PE32+ в основном обратно совместим с PE как по использованию, так и по форме.

3.2. Соглашение о вызовах

Соглашение о вызовах x64 значительно проще набора соглашений x86 (stdcall, cdecl, fastcall): на платформе x64 оно одно. Первые четыре параметра функции передаются в регистрах RCX, RDX, R8 и R9, остальные — через стек. Каждое место под параметр имеет размер 64 бита (8 байт). Для значений, передаваемых целиком и не помещающихся в один 64-разрядный регистр, действуют особые правила, описанные в [4].

3.2.1. Устройство стекового кадра

Стековый кадр функции x64 похож на кадр x86, но имеет несколько важных отличий. Он также состоит из параметров, адреса возврата и локальных данных. Главное правило x64 — указатель стека во время работы функции остаётся постоянным и обычно изменяется только в прологе; конструкции вроде alloca обрабатываются особо [7]. При каждом вызове параметры не добавляются в стек и не удаляются из него. Вместо этого функция заранее выделяет место для всех аргументов, которые передаст вызываемым функциям. Помимо прочего, это упрощает раскрутку стека при исключении. Ниже показан типичный стековый кадр:

Параметры

Первые четыре параметра функции x64 передаются через регистры, а начиная с пятого — через стек. Но пятый параметр не соседствует с адресом возврата. Если функция вызывает другие функции, она обязана выделить в стеке место и для четырёх регистровых параметров. Поэтому сразу после адреса возврата находятся 0x20 байт неинициализированного хранилища, а уже за ними — параметры с пятого и далее. Первую область называют областью регистровых параметров, вторую — областью стековых параметров. В таблице показана часть стекового кадра после вызова функции:

Область регистровых параметров выделяется всегда, даже если у вызываемой функции меньше четырёх аргументов. Она принадлежит вызываемой функции и может служить временным хранилищем на время вызова. Чаще всего туда сохраняют значения параметров из регистров, поэтому соответствующие ячейки также называют их «домашними» адресами; иногда там сохраняют и регистры, которые функция обязана восстанавливать. Знакомого с x86 может удивить, что функция изменяет память выше адреса возврата. Следует помнить: соседние с ним 0x20 байт принадлежат вызываемой функции. Поэтому любая функция, вызывающая другие функции, выделяет в стеке как минимум 0x20 байт.

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

Дополнительную информацию о передаче параметров см. в документации MSDN [4,7].

Адрес возврата

Поскольку указатели x64 имеют ширину 64 бита, адрес возврата занимает в стеке восемь байт вместо четырёх.

Локальные данные

Область локальных данных стекового кадра содержит локальные переменные и сохранённые энергонезависимые регистры. В x64 к таким регистрам общего назначения относятся RBP, RBX, RDI, RSI и R12–R15 [5].

3.3. Обработка исключений на x64

В x86 каждый поток обрабатывает исключения с помощью цепочки записей регистрации. При входе в функцию с обработчиком она создаёт в стеке запись из указателя на обработчик и указателя на следующую запись. Начало цепочки доступно через fs:[0]. При исключении диспетчер обходит цепочку и поочерёдно вызывает обработчики, пока один из них не примет исключение. Такой подход работоспособен, но имеет недостатки. Добавление и удаление записей с неизменными для данного пути выполнения данными создаёт лишние накладные расходы. Указатель на вызываемую функцию хранится в доступном для перезаписи стеке, что особенно опасно при исключениях вроде нарушения доступа. Наконец, раскрутка цепочки вызовов получается сложнее, чем могла бы быть [6].

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

3.3.1. Каталог исключений

Каталог исключений PE32+ содержит полный список функций, которые могут встретиться при раскрутке стека. К ним относятся нелистовые функции — те, которые выделяют место в стеке либо вызывают другие функции. Каждая такая функция описывается структурой IMAGE_RUNTIME_FUNCTION_ENTRY [1]:

Поля BeginAddress и EndAddress содержат относительные виртуальные адреса начала и конца нелистовой функции. Поле UnwindInfoAddress рассмотрено в следующем подразделе. Сам каталог представляет собой массив структур IMAGE_RUNTIME_FUNCTION_ENTRY. При исключении диспетчер ищет в нём нелистовую функцию, содержащую нужный адрес — обычно адрес возврата.

3.3.2. Сведения о раскрутке

Для раскрутки цепочки вызовов и диспетчеризации исключений с каждой нелистовой функцией связаны сведения о раскрутке. Поле UnwindInfoAddress структуры IMAGE_RUNTIME_FUNCTION_ENTRY содержит относительный виртуальный адрес структуры UNWIND_INFO, определённой следующим образом [8]:

Эта структура описывает нелистовую функцию: размер её пролога, использование регистра кадра и изменения стека в прологе. Последовательность изменений хранится в массиве UnwindCode, состоящем из структур UNWIND_CODE [8]:

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

Помимо устройства стекового кадра, UNWIND_INFO может задавать обработчик, вызываемый при исключении. Его адрес и дополнительные данные находятся в полях ExceptionHandler и ExceptionData, присутствующих только при флаге UNW_FLAGE_HANDLER в поле Flags.

Формат структур и полный порядок раскрутки описаны в документации MSDN [2].

4. Техники анализа

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

4.1. Обход каталога исключений

Как видно из устройства каталога исключений PE32+, исполняемый файл x64 содержит немало полезных метаданных. Их можно использовать для более точной разметки и понимания программы. Ниже показано, что удаётся узнать при подробном разборе каталога.

4.1.1. Функции

Самое очевидное применение каталога — поиск всех нелистовых функций без отладочных символов. Достаточно обойти массив IMAGE_RUNTIME_FUNCTION_ENTRY: поле BeginAddress обычно указывает начало функции. Однако отдельные записи могут описывать не точку входа, а участки одной функции, где изменения стека отложены до момента необходимости. В таком случае сведения о раскрутке одной записи образуют цепочку с другой записью.

Документированный признак цепочки — флаг UNW_FLAG_CHAININFO в поле Flags структуры UNWIND_INFO. При нём сразу после последнего UNWIND_CODE располагается структура IMAGE_RUNTIME_FUNCTION_ENTRY, чьё поле UnwindInfoAddress указывает на продолжение сведений о раскрутке. Есть и недокументированный признак в младшем бите UnwindInfoAddress. Если этот бит установлен, оставшиеся биты задают относительный адрес связанной IMAGE_RUNTIME_FUNCTION_ENTRY. Использовать младший бит можно потому, что сведения о раскрутке выровнены по границе четырёх байт и их настоящий адрес всегда имеет там ноль.

Следовательно, запись без продолжения цепочки можно считать относящейся к точке входа функции. Так однозначно находятся все нелистовые функции. Листовые функции затем можно выявить по вызовам из нелистовых, но для этого уже потребуется анализ потока команд.

4.1.2. Разметка стекового кадра

Сведения о раскрутке каждой нелистовой функции содержат полезные данные об устройстве её стека: размер выделенной области, расположение сохранённых энергонезависимых регистров, наличие регистра кадра и его связь с указателем стека. Для каждой операции указан и адрес выполняющей её инструкции. Рассмотрим пример, полученный командой dumpbin /unwindinfo:

Сразу видно, что пролог функции resetstkoflw занимает 0x47 байт и включает все операции из массива кодов раскрутки. Функция использует rbp как указатель кадра; в момент его установки он отстоит от текущего указателя стека на 0x20 байт.

Коды раскрутки хранятся в порядке, обратном выполнению соответствующих операций. Это необходимо, поскольку каждая операция может менять стек. При неверном порядке будут прочитаны неверные данные: например, результат pop rbp зависит от того, выполнена команда до или после add rsp, 0xb0.

Для разметки стекового кадра те же коды нужно обрабатывать в прямом порядке выполнения, а не в порядке хранения. Если сведения о раскрутке образуют цепочку, сначала следует пройти её целиком и составить единый список операций в порядке исполнения.

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

1. UWOP_PUSH_NONVOL

При сохранении энергонезависимого регистра, например командой push rbp, текущее значение указателя стека уменьшается на 8 байт.

2. UWOP_ALLOC_LARGE и UWOP_ALLOC_SMALL

При выделении памяти указатель стека изменяется на указанный размер.

3. UWOP_SET_FPREG

При установке указателя кадра сохраняется его смещение от основания стека, вычисленное по текущему указателю стека.

Во время обхода можно пометить ячейки, где сохраняются энергонезависимые регистры. В приведённом примере R15 записывается по адресу [rsp + 0x98], поэтому эту ячейку можно обозначить как [rsp + SavedR15].

Размечать можно и сами инструкции, изменяющие стек. Например, у push rbp следует отметить сохранение rbp. Адрес операции получается сложением BeginAddress соответствующей записи и поля CodeOffset структуры UNWIND_CODE. Однако CodeOffset указывает на первый байт следующей инструкции, поэтому начало нужной команды приходится искать в обратном направлении.

В результате этого анализа можно взять пролог функции resetstkoflw и автоматически преобразовать его из:

в версию с лучшими аннотациями:

Такая разметка сама по себе не объясняет поведение программы, но заметно упрощает понимание устройства стека.

4.1.3. Обработчики исключений

Сведения о раскрутке нелистовой функции описывают и диспетчеризацию исключений внутри неё. Флаг UNW_FLAG_EHANDLER или UNW_FLAG_UHANDLER означает наличие обработчика. Его адрес хранится в поле ExceptionHandler, расположенном сразу после массива кодов раскрутки. Это общий обработчик, реализующий правила конкретного языка программирования, например C или C++ [3]. Для языка C он называется __C_specific_handler.

Но если все функции C используют один общий обработчик, где находится код для конкретной функции? Его адрес записан в таблице областей, на которую указывает часть ExceptionData структуры UNWIND_INFO. Другие языки могут трактовать ExceptionData иначе. Для C таблица задаётся следующими структурами:

Записи таблицы связывают обработчики конкретной функции с участками кода, для которых они действуют. Все поля C_SCOPE_TABLE_ENTRY содержат относительные виртуальные адреса. Поле Target задаёт адрес, куда передаётся управление после обработки исключения.

Эти сведения позволяют отметить обработчики, способные вызываться при работе функции, и обнаружить функции-обработчики, которые иначе остались бы незамеченными из-за косвенного вызова. Например, функцию CcAcquireByteRangeForWrite из ntoskrnl.exe можно разметить так:

4.2. Разметка области регистровых параметров

Поскольку функция, вызывающая другие функции, обязана выделить область регистровых параметров, соответствующие части её стекового кадра можно разметить статически. Можно отметить как область, принадлежащую вызывающей функции, так и область, подготовленную ею для дочерних вызовов.

Эта область всегда находится сразу после адреса возврата. Пометки CallerRCX по смещению 0x8, CallerRDX по 0x10, CallerR8 по 0x18 и CallerR9 по 0x20 делают устройство кадра нагляднее и показывают, как функция использует выделенную память. Например, CcAcquireByteRangeForWrite из ntoskrnl.exe сохраняет там первые четыре параметра:

5. Заключение

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

Библиография

[1] Microsoft Corporation. ntimage.h. 3790 DDK header files.

[2] Microsoft Corporation. Exception Handling (x64). <http://msdn2.microsoft.com/en-us/library/1eyas8tf(VS.80).aspx>; дата обращения: 25 апреля 2006 г.

[3] Microsoft Corporation. The Language Specific Handler. <http://msdn2.microsoft.com/en-us/library/b6sf5kbd(VS.80).aspx>; дата обращения: 25 апреля 2006 г.

[4] Microsoft Corporation. Parameter Passing. <http://msdn2.microsoft.com/en-us/library/zthk2dkh.aspx>; дата обращения: 25 апреля 2006 г.

[5] Microsoft Corporation. Register Usage. <http://msdn2.microsoft.com/en-us/library/9z1stfyw(VS.80).aspx>; дата обращения: 25 апреля 2006 г.

[6] Microsoft Corporation. SEH in x86 Environments. <http://msdn2.microsoft.com/en-US/library/ms253960.aspx>; дата обращения: 25 апреля 2006 г.

[7] Microsoft Corporation. Stack Usage. <http://msdn2.microsoft.com/en-us/library/ew5tede7.aspx>; дата обращения: 25 апреля 2006 г.

[8] Microsoft Corporation. Unwind Data Definitions in C. <http://msdn2.microsoft.com/en-us/library/ssa62fwe(VS.80).aspx>; дата обращения: 25 апреля 2006 г.

Аннотация:

По мере совершенствования руткитов должны развиваться и способы обнаружения скрытых объектов. Для надёжного сравнения представлений уже недостаточно перечислять поддерживаемые системой списки через штатные API. Сканирование виртуальной памяти по сигнатурам объектов даёт полезные, хотя и ограниченные результаты. В статье разобраны теория и практика такого поиска. Метод требует безопасного доступа к виртуальному адресному пространству Windows и умения строить эффективные сигнатуры памяти. Также рассмотрены действия после обнаружения объекта и приведён простой пример общей сигнатуры, пригодной для поиска нескольких видов объектов ядра во всех версиях Windows семейства NT. Из-за нехватки времени сопутствующий исходный код будет опубликован позднее.

Благодарности:

Спасибо skape, Питеру и остальным хулиганам из uninformed — вы крутые!

Отказ от ответственности:

Автор не несет ответственности за то, как содержимое статьи используется или интерпретируется. Некоторая информация может быть неточной или неправильной. Если читатель считает, что какая-либо информация неверна или не была должным образом атрибутирована, пожалуйста, свяжитесь с автором, чтобы можно было внести исправления. Все содержимое относится к платформе Windows XP Service Pack 2, если не указано иное.

2. Введение

По мере распространения и усложнения руткитов совершенствуются и средства обнаружения. Руткиты давно вышли за пределы простого перехвата API, а защитные программы — за пределы поиска таких перехватов. Первые версии FU обнаруживали утилиты вроде Blacklight, использовавшие слабости его демонстрационной реализации. В FUTo эти недостатки исправлены, хотя другие слабости остались; они не относятся к теме статьи.

Средство обнаружения руткитов RAIDE ищет скрытые FUTo блоки EPROCESS по сигнатурам в памяти. Реализация работает, но тоже имеет слабости. Здесь рассматриваются общие принципы построения надёжного обнаружения руткитов по сигнатурам памяти.

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

После прочтения читатель должен понимать принципы и ограничения поиска объектов ядра по сигнатурам памяти. Автор считает этот способ пригодным для обнаружения руткитов, но, как обычно в информационной безопасности, универсального решения нет: его следует применять вместе с другими известными методами.

3. Сканирование памяти

Обход произвольных участков системной памяти нельзя считать точной процедурой: их состояние способно измениться прямо во время обращения. Однако память вокруг исполнительных объектов ядра должна оставаться достаточно согласованной. При должной осторожности доступ можно сделать безопасным, а число ложных совпадений и пропусков — свести к минимуму. Ниже описан безопасный обход системных пулов PagedPool и NonPagedPool.

3.1. Получение диапазонов пула

Для поиска в пулах не нужно обходить всё системное адресное пространство. Глобальные переменные nt!MmPagedPoolStart, nt!MmPagedPoolEnd и соответствующие переменные NonPagedPool задают нужные диапазоны, ускоряя поиск и уменьшая число ложных совпадений. Эти символы не экспортируются, но получить их значения можно несколькими способами.

В современных на момент написания системах (Windows XP с пакетом обновления 2 и новее) надёжнее всего использовать указатель KPCR->KdVersionBlock по адресу fs:[0x34]. Он ведёт к структуре KDDEBUGGER_DATA64, определённой в заголовке wdbgexts.h комплекта Debugging Tools for Windows. Вредоносные программы нередко используют её для доступа к неэкспортируемым глобальным переменным и изменения работы системы.

Второй способ — обратиться к структуре сеанса nt!_MM_SESSION_SPACE, на которую указывает EPROCESS->Session. Она содержит сведения о сеансе процесса, включая границы и другие параметры PagedPool:

Если границы пулов получить не удаётся, остаётся обход всего системного адресного пространства. Его можно начинать сразу после nt!MmHighestUserAddress, но ещё безопаснее — после большой страницы, в которой отображены ntoskrnl.exe и hal.dll. Для этого берут любой экспортированный адрес из hal.dll и округляют вверх до границы большой страницы.

3.2. Блокировка памяти

Перед обращением к произвольной памяти её страницы следует зафиксировать. Иначе между проверкой адреса и чтением страница может быть освобождена, что приведёт к исключению из-за состояния гонки. Процедура nt!MmProbeAndLockPages фиксирует как выгружаемую, так и невыгружаемую память. Физические страницы имеют счётчик ссылок в nt!MmPfnDatabase, поэтому после фиксации посторонний код не сможет выгрузить их на диск или сделать недействительными.

Для вызова MmProbeAndLockPages сначала создают MDL с помощью nt!IoAllocateMdl или nt!MmInitializeMdl, передавая виртуальный адрес и размер нужного блока. После успешной фиксации описанный MDL диапазон можно безопасно читать. Когда он больше не нужен, страницы освобождают процедурой nt!MmUnlockPages.

При обходе NonPagedPool число фиксируемых страниц можно дополнительно уменьшить. Документация разрешает вызывать MmProbeAndLockPages на уровне DISPATCH_LEVEL, но тогда фиксируются только уже находящиеся в физической памяти страницы. Для остальных вызов завершится ошибкой, что в данном случае как раз желательно.

4. Обнаружение исполнительных объектов

Все исполнительные компоненты ядра NT поручают управление выделенными объектами диспетчеру объектов. Каждый такой объект имеет общий заголовок OBJECT_HEADER и, при необходимости, дополнительные заголовки — например OBJECT_HEADER_NAME_INFO, сведения о квоте процесса или трассировке дескриптора. Сначала рассмотрим общие признаки объектов и заголовок блока пула, а затем — поля конкретных типов, из которых можно составлять сигнатуры.

4.1. Общая информация об объектах

Поскольку OBJECT_HEADER присутствует у всех объектов, рассмотрим его подробнее. Здесь «постоянным» называется поле, одинаковое у всех объектов одного типа, а не у всех исполнительных объектов системы.

Наиболее надёжной и уникальной сигнатурой выглядит поле Type структуры OBJECT_HEADER: по нему можно различать EPROCESS, ETHREAD, DRIVER_OBJECT, DEVICE_OBJECT и другие типы.

4.2. Проверка заголовка блока пула

Управление пулом ядра несколько отличается от управления кучей пользовательского режима, но для выделений меньше PAGE_SIZE механизмы похожи. Перед буфером, возвращаемым ExAllocatePoolWithTag(), находится следующий заголовок:

Ниже отмечены поля, полезные при поиске объектов. Слово «постоянное» снова означает одинаковое для сходных исполнительных объектов, а не для всех структур POOL_HEADER.

Поля BlockSize, PoolType и PoolTag структуры POOL_HEADER обычно совпадают у объектов одного вида и потому помогают подтвердить предполагаемый тип найденного объекта.

Поля PreviousSize и BlockSize позволяют проверить, похож ли предполагаемый POOL_HEADER на настоящий выделенный блок и входит ли он в одну из цепочек диспетчера пула. Оба размера кратны минимальному выравниванию пула: 8 байтам в 32-разрядной системе и 16 байтам в 64-разрядной. Эти значения задают смещения до соседних блоков.

Нулевой PreviousSize означает, что текущий заголовок принадлежит первому блоку непрерывной области пула. Иначе значение должно совпадать с BlockSize предыдущего заголовка. Сам BlockSize не бывает нулевым и должен совпадать с PreviousSize следующего блока.

Следующая функция проверяет заголовок выделенного блока пула.

4.3. Сигнатуры конкретных типов объектов

До сих пор рассматривались общие для всех исполнительных объектов признаки. Иногда их достаточно, но порой для уверенного распознавания приходится проверять и тело объекта. Одни интересующие структуры хорошо определены и документированы, другие — нет; кроме того, их устройство меняется между версиями Windows. Ниже приведены очевидные сигнатуры нескольких типов, важных при поиске поведения руткитов, а также примеры признаков, использовавшихся в прежних работах.

4.3.1. Объекты процессов

Простую сигнатуру EPROCESS можно составить из нескольких базовых полей с предсказуемыми постоянными значениями, одинаковыми для всех процессов одной системы.

В структуру входят и другие DISPATCH_HEADER для блокировок, событий, таймеров и прочих объектов; их поля Header.Type и Header.Size также предсказуемы.

4.3.2. Объекты потоков

Аналогично, простую сигнатуру ETHREAD образуют базовые поля с постоянными значениями, одинаковыми для всех потоков одной системы.

В эту структуру тоже встроены DISPATCH_HEADER блокировок, событий, таймеров и других объектов с предсказуемыми Header.Type и Header.Size.

4.3.3. Объекты драйверов

Утилита MODGREPPER Йоанны Рутковской с invisiblethings.org обнаруживала скрытые DRIVER_OBJECT по сигнатуре. Позднее valerino показал способ её обойти в статье rootkit.com «Please don't greap me!». Ниже перечислены поля, пригодные для построения сигнатуры DRIVER_OBJECT.

Следующие поля DRIVER_OBJECT можно проверить по принадлежности диапазону загруженного образа драйвера:

4.3.4. Объекты устройств

У структуры DEVICE_OBJECT немного пригодных постоянных признаков. Наиболее очевидны следующие.

Для работы устройства поле DriverObject должно указывать на действительный объект.

4.3.5. Прочие признаки

До сих пор сигнатуры сводились в основном к простому двоичному сравнению с заданным значением. Позднее будет рассмотрена проверка цепочки указателей глубины N, позволяющая усложнить обход сигнатур, основанных на указателях.

Поле объекта можно проверять не по точному значению, а по его свойствам. Распространённый пример — проверка связности структуры LIST_ENTRY:

Указатель на объект или выделенную область можно проверить показанной выше функцией ValidatePoolBlock. Так же проверяется UNICODE_STRING.Buffer, если размер выделения меньше PAGE_SIZE.

5. Объект найден, что дальше?

Действия после предполагаемого обнаружения исполнительного объекта зависят от цели. Демонстрационная утилита из статьи просто выводит сведения о каждом совпадении.

Средству обнаружения руткитов требуется гораздо больше проверок. Например, оно может искать EPROCESS, удалённые из системного списка процессов, или модуль драйвера, скрытый от системного API. Для этого найденные непосредственно в памяти объекты сравнивают с результатами API или штатного обхода списков. Нужно учитывать и состояние гонки: объект способен появиться или исчезнуть между сканированием памяти и получением системного представления.

Помимо сигнатуры полезны дополнительные проверки согласованности. Содержат ли поля x, y и z допустимые указатели? Должны ли совпадать поля c и b? Выглядит ли объект в целом настоящим, но несёт признаки намеренной подделки? Совпадает ли число находок с глобальным счётчиком, например из OBJECT_TYPE? Ниже перечислены возможные проверки четырёх типов объектов из главы 4.

5.1. Объекты процессов

Краткий список вещей, которые нужно проверить при сканировании объектов EPROCESS:

1. Сравнить с высокоуровневым API, например kernel32!CreateToolhelp32Snapshot.

2. Сравнить с системным вызовом, например nt!NtQuerySystemInformation.

3. Сравнить со списком EPROCESS->ActiveProcessLinks.

4. Корректен ли список потоков процесса?

5. Может ли PsLookupProcessByProcessId открыть его UniqueProcessId?

6. Содержит ли ImageFileName допустимую строку, нули или мусор?

5.2. Объекты потоков

Краткий список вещей, которые нужно проверить при сканировании объектов ETHREAD:

1. Сравнить с высокоуровневым API, например kernel32!CreateToolhelp32Snapshot.

2. Сравнить с системным вызовом, например nt!NtQuerySystemInformation.

3. Указывает ли поток на действительный процесс-владелец?

4. Может ли PsLookupThreadByThreadId открыть его Cid.UniqueThread?

5. На что указывает Win32StartAddress? Принадлежит ли адрес загруженному модулю?

6. Каково значение ServiceTable?

7. Если поток ожидает, как долго длится ожидание?

8. Где находится его стек и как выглядит цепочка вызовов?

5.3. Объекты драйверов

Краткий список вещей, которые нужно проверить при сканировании объектов DRIVER_OBJECT:

1. Сравнить со службами из базы диспетчера управления службами.

2. Сравнить с системным вызовом, например nt!NtQuerySystemInformation.

3. Находится ли объект в глобальном пространстве имён системы?

4. Владеет ли драйвер действительными объектами устройств?

5. Указывает ли базовый адрес драйвера на допустимый заголовок MZ?

6. Корректны ли указатели на функции в объекте?

7. Указывает ли DriverSection на действительную nt!LDRDATATABLEENTRY?

8. Содержат ли DriverName и LDR_DATA_TABLE_ENTRY допустимые строки, нули или мусор?

5.4. Объекты устройств

Краткий список вещей, которые нужно проверить при сканировании объектов DEVICE_OBJECT:

1. Указывает ли устройство на действительный объект драйвера-владельца?

2. Есть ли у устройства имя и присутствует ли оно в глобальном пространстве имён?

3. Является ли оно частью корректного стека устройств?

4. Корректны ли его поля Type и Size?

6. Нарушение сигнатур

Сигнатуры памяти позволяют распознавать выделенные объекты на низком уровне, независимо от конкретного способа их сокрытия. Но у метода есть собственные слабости: многие сигнатуры обходятся несколькими приёмами, а существование признаков, которые нельзя подделать, ещё предстоит доказать. Ниже рассмотрены способы разрушения сигнатур и возможные ответные меры.

6.1. Сигнатуры на основе указателей

Допустимый указатель на общий объект или неизменяемые данные кажется надёжной сигнатурой, но её легко обойти. Следующий код показывает простейшую подмену OBJECT_HEADER->Type, использованного выше как общий признак объекта. Атака возможна потому, что OBJECT_TYPE — всего лишь выделенная структура с достаточно постоянным содержимым. Таким же способом обходятся многие другие сигнатуры на основе указателей.

6.2. Проверка указателей глубины N

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

Алгоритм предполагает, что заданный адрес принадлежит исполнительному объекту, и проверяет гипотезу так:

1. Вычисляет предполагаемый OBJECT_HEADER.

2. Предполагает, что pObjectHeader->Type является OBJECT_TYPE.

3. Вычисляет предполагаемый OBJECT_HEADER для OBJECT_TYPE.

4. Предполагает, что pObjectHeader->Type является nt!ObpTypeObjectType.

5. Проверяет pTypeObject->TypeInfo.DeleteProcedure == nt!ObpDeleteObjectType.

6.3. Прочие способы обхода

Очевидный способ скрыться от сканирования — применить подмену представления памяти по методу Shadow Walker. Нечитаемая виртуальная память останется вне результатов. Однако применить это к пулу непросто: он может выглядеть повреждённым, вызывая сбои и аварийную остановку системы. Зато можно перехватить nt!MmProbeAndLockPages или IoAllocateMdl глобально либо только в таблице импорта самого средства обнаружения.

Поля с постоянными или предсказуемыми значениями иногда можно обнулить либо изменить без нарушения работы системы. Например, в доработках автора к FUTo поле EPROCESS->UniqueProcessId безопасно сбрасывается в ноль. В статье rootkit.com «Please don't greap me!» для обхода MODGREPPER очищаются DRIVER_OBJECT->DriverName и связанный буфер.

Для некоторых сигнатур указателя простого сравнения адресов недостаточно. Например, проверку nt!ObpDeleteObjectType можно обмануть, направив pTypeObject->TypeInfo.DeleteProcedure на размещённый в другом месте переходник, который сразу передаст управление настоящей nt!ObpDeleteObjectType.

7. GrepExec: инструмент

К статье прилагается демонстрационная утилита с исходным кодом, которая сканирует пул и находит исполнительные объекты DRIVER_OBJECT, DEVICE_OBJECT, EPROCESS и ETHREAD. Она не определяет, пытались ли скрыть объект, а просто выводит все находки. Автор не планирует развивать именно эту программу, но намерен встроить сканирование памяти в другой проект. Код легко приспособить к иным сигнатурам и типам объектов.

7.1. Сигнатура

Для демонстрации используется простая сигнатура. Все искомые объекты выделены в NonPagedPool, поэтому обходится только невыгружаемая память:

1. Каждый проверяемый адрес считается началом блока пула.

2. К нему прибавляется смещение сигнатуры.

3. Полученное значение сравнивается с OBJECT_HEADER->Type искомого типа.

4. Предполагаемый POOL_HEADER->PoolType сравнивается с известным типом пула объекта.

5. Предполагаемый POOL_HEADER проверяется с помощью функции из раздела 4.2, ValidatePoolBlock.

Следующая функция задаёт параметры обхода пула и проверяет блок по одной сигнатуре типа PVOID. При совпадении вызывается функция обратного вызова с указателем на начало блока. Код poolgrep.c легко изменить, чтобы вместо одной PVOID принимать структуру из нескольких сигнатур и смещений либо указатель на проверяющую функцию.

7.2. Использование

Использование GrepExec не требует пояснений. Ниже показана встроенная справка.

7.3. Пример вывода

Ниже приведены примеры вывода для каждой поддерживаемой команды.

8. Заключение

Теперь читатель должен понимать принципы и ограничения поиска объектов системного пула по сигнатурам. Описанные приёмы позволяют безопасно обходить системную память, строить собственные сигнатуры, находить совпадения и реализовать нужный способ представления результатов.

Обнаружение объектов сканированием памяти нельзя считать точной наукой. Зато оно почти не зависит от штатных механизмов системы и минимально с ними взаимодействует. По мнению автора, при аккуратной реализации метод даёт приемлемые результаты при поиске объектов, скрытых руткитами.

Библиография

Blackhat.com. RAIDE: Rootkit Analysis Identification Elimination. <http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Silberman-Butler.pdf>; дата обращения: 30 мая 2006 г.

F-Secure. Blacklight. <http://www.f-secure.com/blacklight/>; дата обращения: 30 мая 2006 г.

Invisiblethings.org. MODGREPPER. <http://www.invisiblethings.org/tools.html>; дата обращения: 30 мая 2006 г.

Phrack.org. Shadow Walker. <http://www.phrack.org/phrack/63/p63-0x08_Raising_The_Bar_For_Windows_Rootkit_Detection.txt>; дата обращения: 30 мая 2006 г.

Rootkit.com. FU. <http://rootkit.com/project.php?id=12>; дата обращения: 30 мая 2006 г.

Rootkit.com. Please don't greap me!. <http://rootkit.com/newsread.php?newsid=316>; дата обращения: 30 мая 2006 г.

Uninformed.org. futo. <http://uninformed.org/?v=3&a=7&t=sumry>; дата обращения: 30 мая 2006 г.

Windows Hardware Developer Central. Debugging Tools for Windows. <http://www.microsoft.com/whdc/devtools/debugging/default.mspx>; дата обращения: 30 мая 2006 г.

Аннотация: эта статья обсуждает последствия для безопасности, возникающие из-за интеграции Mach с ядром Mac OS X. Несколько примеров иллюстрируют, как поддержку Mach можно использовать для обхода некоторых BSD-механизмов безопасности, таких как securelevel. Кроме того, приведены примеры, показывающие, как функции Mach могут дополнять ограниченную функциональность ptrace, включенную в Mac OS X.

Привет, читатель. Я пишу эту статью по двум причинам. Первая - предоставить некоторую документацию по Mach-стороне Mac OS X для людей, которые с ней не знакомы, но хотят разобраться. Вторая - задокументировать собственное исследование, поскольку у меня довольно мало опыта в программировании Mach. Из-за этого статья может содержать ошибки. Если это так, пожалуйста, напишите мне на nemo@felinemenace.org, и я постараюсь исправить их.

2. Введение

Эта статья попытается дать базовое введение в ядро Mach, включая его историю и общий дизайн. Затем будут приведены подробности о том, как эти концепции реализованы в Mac OS X. Наконец, статья проиллюстрирует некоторые проблемы безопасности, возникающие при попытке смешать UNIX и Mach. В этом контексте мне попалась интересная цитата с сайта Apple(.com) [2].

> «Этому порту можно отправлять сообщения, чтобы запускать и останавливать задачу, завершать её, изменять её адресное пространство и так далее. Поэтому владелец права отправки в порт задачи фактически владеет самой задачей и может менять её состояние независимо от политик безопасности BSD и любых политик более высокого уровня».

>

> «Иными словами, специалист по программированию Mach с локальными правами администратора на компьютере Mac OS X может обойти средства безопасности BSD и более высокого уровня».

Звучит как надежная модель для построения серверной платформы...

3. История Mach

Ядро Mach возникло в Университете Карнеги — Меллона (CMU) [1] и первоначально основывалось на ОС Accent. Его создавали внутри ядра 4.2BSD, постепенно заменяя компоненты BSD новыми компонентами Mach. Поэтому ранние версии представляли собой монолитные ядра, подобные xnu, где код BSD и Mach объединён.

Mach проектировался прежде всего для многопроцессорных систем и как микроядро. Однако используемая Mac OS X реализация xnu микроядром не является: код BSD и другие подсистемы включены непосредственно в ядро.

4. Базовые концепции

Ниже кратко изложены основные понятия Mach. Они гораздо лучше описаны в других работах, поэтому стоит обратиться к ссылкам в конце статьи.

Mach представляет компоненты системы собственными абстракциями, непривычными разработчику из мира UNIX. Сначала определим их.

4.1. Задачи

Задача — логическое представление среды выполнения, отделяющее ресурсы каждой работающей программы. У неё есть собственное виртуальное адресное пространство и уровень привилегий. Задача содержит один или несколько потоков, совместно использующих её адресное пространство и ресурсы.

В Mac OS X новую задачу создают функцией task_create() или системным вызовом BSD fork().

4.2. Потоки

Поток Mach — независимая единица выполнения со своими регистрами и политикой планирования. Он имеет доступ ко всем ресурсам содержащей его задачи.

В Mac OS X список потоков задачи возвращает функция task_threads():

API Mach в Mac OS X позволяет создавать потоки, читать и изменять их регистры и выполнять другие операции.

4.3. Сообщения

Сообщения обеспечивают связь между потоками Mach и состоят из набора объектов данных. Созданное сообщение отправляется в порт, на который у вызывающей задачи есть соответствующие права. Сами права на порт тоже можно передавать между задачами в сообщении. Получатель ставит сообщения в очередь, а принимающий поток обрабатывает их по своему усмотрению.

В Mac OS X функция mach_msg() отправляет сообщения в порт и принимает их оттуда:

4.4. Порты

Порт — управляемый ядром канал связи для передачи сообщений между потоками. Поток с правом отправки может помещать в него сообщения; таким правом одновременно способны обладать несколько сторон. Однако принимать сообщения из конкретного порта в каждый момент может лишь одна задача. У порта есть собственная очередь.

4.5. Набор портов

Набор портов объединяет несколько портов Mach с общей очередью сообщений.

5. Ловушки Mach (системные вызовы)

Для объединения Mach и BSD в xnu номера системных вызовов разделены между таблицами. На PowerPC инструкция sc берёт номер из r0. Положительное значение меньше 0x6000 считается вызовом FreeBSD: по нему индексируется таблица sysent и выбирается указатель на функцию.

Значения больше 0x6000 относятся к специфичным для PowerPC вызовам из PPCcalls, а отрицательные индексируют mach_trap_table.

Код ниже взят из исходников xnu и показывает этот процесс.

На Intel ловушки Mach вызываются инструкцией int 0x81 (cd 81), а службы BSD — sysenter. Соглашение о номерах сохраняется; в обоих случаях номер находится в eax.

Большинство авторов шелл-кода для Mac OS X используют вызовы FreeBSD, вероятно, из-за слабого знакомства с ловушками Mach. Ниже приведён их список из mach_trap_table ядра xnu 792.6.22.

5.1. Список ловушек Mach в xnu 792.6.22

Для вызова на Intel левое число с обратным знаком помещается в eax, а аргументы — в стек в обратном порядке. Низкоуровневая отправка сообщений Mach уже гораздо лучше разобрана в одной из работ из списка литературы; заинтересованному читателю стоит обратиться к ней.

6. MIG

Поскольку Mach задумывался как микроядро для нескольких процессоров и компьютеров, значительная часть функций реализована сообщениями между задачами. Для этого требуются формально определённые интерфейсы IPC.

Mach и Apple используют язык Mach Interface Generator (MIG), подмножество Matchmaker, создающее интерфейсы C и C++ для обмена сообщениями между задачами.

Интерфейс описывается в файле .defs, который утилита /usr/bin/mig преобразует в исходный файл .c или .cpp и заголовок .h. Созданные заготовки C/C++ обрабатывают сообщения из определения.

Разработчику из мира UNIX или Windows это устройство поначалу непривычно. Многие рассматриваемые функции Mach фактически определены в .defs; эти файлы входили в исходники xnu, которые больше недоступны.

Пример из одного из таких файлов (osfmk/mach/mach_vm.defs), показывающий определение функции vm_allocate(), приведен ниже.

Чтобы понять написание шелл-кода с ловушкой mach_msg, полезно обработать .defs через /usr/bin/mig и изучить полученный код C.

Дополнительную информацию о MIG см. в [6]. Richard Draves также делал доклад о MIG, его слайды доступны в [7].

7. Замена ptrace()

Пользователи, пришедшие в Mac OS X из Linux или BSD, ожидают полноценного системного вызова ptrace(). Но Apple оставила его урезанным: он годится лишь для слабой защиты от отладки и пошагового выполнения процесса.

Команда защиты от отладки PT_DENY_ATTACH запрещает только будущие подключения через ptrace(). При ограниченных возможностях самого вызова и неограниченном task_for_pid() такая мера фактически бесполезна.

Ниже отсутствующие возможности ptrace воспроизводятся другими средствами Mac OS X.

Сначала нужно получить порт задачи. При достаточных привилегиях task_for_pid() принимает идентификатор процесса UNIX и возвращает его порт.

Эта функция довольно проста в использовании и работает так, как ожидается.

При успехе порт возвращается в переменной port и используется последующими вызовами API для управления ресурсами целевой задачи. По смыслу это аналог PTRACE_ATTACH.

В Mac OS X команды PTRACE_GETREGS и PTRACE_GETFPREGS больше не дают привычного доступа к регистрам, но его легко восстановить через API Mach.

Функция task_threads() по порту возвращает список потоков задачи.

Затем thread_get_state() позволяет перебрать потоки и прочитать регистры каждого.

Ниже показано чтение регистров первого потока из массива thread_act_port_array_t.

Примечание: код предназначен для PowerPC; на Intel используется тип i396_thread_state_t.

Для PPC-машин затем можно вывести содержимое нужного регистра так:

Теперь рассмотрим изменение регистров потока.

Аналогами PTRACE_SETREGS и PTRACE_SETFPREGS служит вызов Mach thread_set_state. Следующая небольшая программа объединяет рассмотренные приёмы.

Следующий небольшой ассемблерный код продолжает цикл, пока регистр r3 не станет ненулевым.

C-код ниже присоединяется к процессу и изменяет значение регистра r3 на 0xdeadbeef.

Пример запуска этих двух программ выглядит так:

Программа C меняет r3 процесса ./tst, после чего цикл заканчивается и выполняется trap.

Удалённые из ptrace() чтение и запись памяти также заменяет API Mach. Функции vm_read() и vm_write() работают с адресным пространством целевой задачи.

Эти вызовы работают примерно так, как ожидается. Однако в оставшейся части статьи есть примеры, использующие эти функции. Функции определены следующим образом:

Они соответствуют запросам PTRACE_POKETEXT, PTRACE_POKEDATA и PTRACE_POKEUSR.

Для операции нужны подходящие права страницы; перед чтением или записью их легко изменить вызовом vm_protect().

В Linux запрос PTRACE_SYSCALL пошагово выполняет процесс до системного вызова, что позволяет strace отслеживать обращения приложения к ядру. В Mac OS X этой возможности нет, хотя API Mach предусматривает подходящую функцию.

Она могла бы назначить пользовательский обработчик системных вызовов и вести журнал, но в Mac OS X не реализована.

8. Внедрение кода

Внедрение кода через API Mach демонстрировалось неоднократно; самая известная реализация — machinject. Она получает порт выбранного PID через task_for_pid(), а thread_create_running() создаёт в задаче поток с заданным состоянием регистров, передавая управление внедрённому коду. Тем же способом реализацию перенесли на Intel.

Начальное состояние потока можно направить на dlopen() для загрузки динамической библиотеки с диска. Другой вариант — вручную отобразить объектный файл в адресное пространство через vm_map() и применить перемещения.

9. Переход в ядро

В Mac OS X 10.4.6 для Intel — последнем выпуске на момент статьи — устройства /dev/kmem и /dev/mem удалены, поэтому для доступа к памяти ядра нужен другой путь.

Ловушка Mach task_for_pid() с pid=0 возвращает порт задачи ядра; разумеется, для этого нужны права суперпользователя.

Через этот порт функции vm_read() и vm_write() напрямую читают и изменяют память ядра, а vm_map() и vm_remap() отображают туда файлы и области памяти.

Автор использует возможность в новой версии руткита WeaponX, но у неё немало других применений.

10. Безопасность гибридной системы UNIX и Mach

Сочетание UNIX и Mach в одной системе создаёт множество проблем. Как сказано в цитате Apple из введения, опытный разработчик Mach способен через API и ловушки Mach обойти средства безопасности BSD более высокого уровня.

Ниже приведено несколько таких обходов; найти остальные предлагается читателю.

Первый пример — параметр sysctl kern.securelevel, ограничивающий возможности суперпользователя. Значение -1 снимает ограничения. В обычных условиях суперпользователь может повышать уровень безопасности, но не снижать его.

Демонстрация:

Поведение sysctl соответствует описанию, но доступ к задаче pid=0 и запись в память ядра позволяют его обойти.

Сначала утилитой nm находится адрес переменной ядра, хранящей уровень безопасности.

Затем task_for_pid() получает порт задачи ядра, а vm_write() записывает по найденному адресу.

Пример использования:

То же можно сделать расширением ядра, но данный вариант аккуратнее и лучше соответствует теме.

Вызов chroot() — механизм UNIX, часто используемый, иногда неправильно, для изоляции. API Mach позволяет обойти и его: процесс внутри окружения chroot() способен через task_for_pid() подключиться к любому внешнему процессу с подходящими правами. Эти примеры невелики сами по себе, но демонстрируют общий класс обходов UNIX средствами Mach.

Следующий код перебирает PID начиная с 1 и пытается внедрить небольшую заготовку в новый поток. Основная версия написана для PowerPC; также приведён шелл-код Intel.

Пример на обычном Mac mini с Mac OS X 10.4.6 показывает, что непривилегированный пользователь внутри chroot() подключается к процессу с теми же правами снаружи. Затем в него внедряется шелл-код, открывающий командную оболочку на сетевом порту.

Замечание о программе ./dropprivs: пришлось отдельно вызвать seteuid() и setuid() вместо setreuid(). По-видимому, setreuid() и setregid() вообще не работают. Andrewg хорошо подытожил ситуацию:

Другой выход из chroot() — получить через task_for_pid() задачу с PID 0 и изменить память ядра. Это требует прав суперпользователя, поэтому автор не стал реализовывать вариант; его несложно оформить как шелл-код.

ptrace

Как уже говорилось, урезанный ptrace() почти бесполезен. При этом появилась команда PT_DENY_ATTACH, запрещающая другим процессам подключаться через ptrace.

Следующий пример кода показывает ее использование:

Программа бесконечно проверяет неизменяемую глобальную переменную. Попытка подключить к ней использующий ptrace отладчик gdb приводит к SIGSEGV.

Но API Mach по-прежнему позволяет подключиться. Команда nm выдаёт адрес статической переменной changeme.

Следующий пример получает задачу через task_for_pid() и меняет содержимое переменной.

Как видно ниже, это приводит к завершению цикла, как и ожидалось.

11. Заключение

Вы действительно дочитали статью до конца — надеюсь, она не была слишком скучной. В новых выпусках Mac OS X для Intel, начиная с 10.4.6, вызов task_for_pid() ограничен: пользователь должен состоять в группе procmod или обладать правами суперпользователя. К счастью, эти ограничения легко обходятся.

Ходят и противоречивые слухи о будущем полном удалении Mach из Mac OS X; насколько они правдивы, автор не знает.

Если вы заметили какие-либо проблемы в содержимом, как я упоминал ранее, пожалуйста, напишите мне на nemo@felinemenace.org и сообщите. Только без бессмысленной неконструктивной критики.

Спасибо всем в felinemenace и pulltheplug за постоянную поддержку и дружбу. Также спасибо всем, кто вычитывал эту статью для меня, и команде uninformed за возможность ее опубликовать.

Библиография

[1] CMU. The Mach Project. <http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html>

[2] Apple. Apple Security Overview. <http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html>

[3] Mach. Mach Man-pages. <http://felinemenace.org/nemo/mach/manpages>

[4] Rentzsch. Mach Inject. <http://rentzsch.com/mach_inject/>

[5] Guiheneuf. Mach Inject. <http://guiheneuf.org/Site/mach>

[6] Richard P. Draves/Michael B. Jones and Mary R. Thompson. Mach Interface Generator. <http://felinemenace.org/nemo/mach/mig.txt>

[7] Richard P. Draves. MIG Slides. <http://felinemenace.org/nemo/mach/Slides>

[8] Wikipedia. Mach Kernel. <http://en.wikipedia.org/wiki/Mach_kernel>

[9] Feline Menace. The Mach System. <http://felinemenace.org/nemo/mach/Mach.txt>

[10] OSX Code. Mach. <http://www.osxcode.com/index.php?pagename=Articles&article=10>

[11] CMU. A Programmer's Guide to the Mach System Calls. <http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/abstracts/machsys.html>

[12] CMU. A Programmer's Guide to the Mach User Environment. <http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/abstracts/machuse.html>

Аннотация: антивирусное программное обеспечение становится все распространеннее на пользовательских компьютерах. Крупные производители, например Dell, включают антивирусы и другие защитные комплексы в стандартную поставку новых систем. Поэтому особенно важно, чтобы такое ПО было хорошо спроектировано, безопасно по умолчанию и совместимо со сторонними приложениями: автоматически установленная и запущенная программа становится первоочередной целью атаки. В статье рассмотрены ошибки известных антивирусов — от неправильной проверки недоверенных входных данных в драйвере ядра до нарушения контрактов API при перехвате функций и создании промежуточных слоев. В широко распространенном или предустановленном ПО такие дефекты угрожают стабильности и безопасности системы и мешают независимым разработчикам поставлять работоспособные приложения.

1. Введение

В современной вычислительной среде компьютерная безопасность играет всё более важную роль. Интернет создаёт уникальные опасности для подключённых к сети компьютеров, поскольку угрозы вроде вирусов, червей и другого вредоносного ПО становятся всё более распространёнными.

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

Можно было бы ожидать от него высокого качества: для многих людей межсетевой экран и антивирус служат первой, а слишком часто и единственной линией обороны.

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

Статья рассматривает два пакета, проблемы которых вызваны упрощениями и небезопасными предположениями разработчиков:

• Kaspersky Internet Security Suite 5.0

• McAfee Internet Security Suite 2006

Оба включают несколько средств защиты, в том числе межсетевой экран и антивирус.

2. Проблема: Kaspersky Internet Security Suite 5.0

Kaspersky Internet Security Suite 5.0 объединяет несколько защитных программ, включая межсетевой экран и антивирус.

Основное внимание уделено Kaspersky Anti-Virus, поддерживающему ручное сканирование и проверку в реальном времени.

Компоненты KAV режима ядра применяют небезопасные приемы, способные привести к компрометации системы.

2.1. Изменение системных служб во время выполнения

Хотя KAV использует фильтр файловой системы — штатный механизм Windows для перехвата файловых операций, предназначенный в том числе для антивирусов, — разработчики дополнительно перехватывают ряд функций API. Перехват в ядре опасен: все параметры доступной из пользовательского режима функции необходимо тщательно проверять, иначе непривилегированная программа сможет скомпрометировать систему. Небезопасно и удалять такие перехваты, поскольку трудно гарантировать, что в этот момент ни один поток не выполняет измененный участок. Кроме того, KAV перехватывает несколько системных служб в ошибочной попытке защитить свои процессы от отладки и завершения.

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

KAV перехватывает перечисленные ниже системные службы. Это легко обнаружить в WinDbg, сравнив nt!KeServiceDescriptorTableShadow в чистой системе и после загрузки антивируса:

KAV также создает новые системные службы, изменяя таблицу дескрипторов ради упрощенного входа в ядро. Это неподходящий способ связи приложения с драйвером. Следовало использовать обычный интерфейс IOCTL, не требующий изменения структур ядра и не зависящий от номеров служб, меняющихся между выпусками ОС.

2.2. Неправильная проверка пользовательских указателей и размера адресного пространства ядра

Многие перехваты и собственные системные службы KAV содержат опасные дефекты.

Например, измененная NtOpenProcess проверяет пользовательский адрес сравнением с жестко заданным 0x7FFF0000. В обычной 32-разрядной Windows это близко к верхней границе пользовательского пространства 0x7FFEFFFF, но фиксировать границу нельзя: параметр загрузки /3GB меняет разделение с 2 Гбайт для ядра и 2 Гбайт для приложений на 1 и 3 Гбайт. В такой системе NtOpenProcess и вызывающая ее Win32-функция OpenProcess могут ошибочно отклонять параметры, расположенные выше первых 2 Гбайт:

Следовало использовать документированную ProbeForRead в кадре SEH: она автоматически создает исключение нарушения доступа для недопустимого пользовательского адреса.

Кроме того, собственные службы KAV неправильно проверяют пользовательские указатели, позволяя вызвать сбой системы:

2.3. Неправильная проверка пользовательских структур и указателей, скрытие потоков от пользовательского режима

Ошибки в перехватчиках KAV не ограничиваются NtOpenProcess. Антивирус также перехватывает системную службу NtQuerySystemInformation. При запросе класса сведений SystemProcessesAndThreads изменённая служба иногда удаляет потоки из списка некоторых процессов. Через этот низкоуровневый механизм приложения получают перечень всех работающих процессов и потоков, поэтому KAV фактически может скрывать их от пользовательского режима. Само наличие подобного кода примечательно: сокрытие выполняемого кода обычно связывают с руткитами, а не с антивирусами.

Помимо сомнительной возможности скрывать работающий код, этот перехватчик содержит несколько уязвимостей:

1. После того как настоящая реализация ядра заполнит выходной буфер NtQuerySystemInformation, перехватчик продолжает работать с ним, не учитывая, что вредоносное пользовательское приложение может успеть изменить или освободить этот буфер. Функция не защищена кадром SEH, поэтому приложение способно заставить KAV обратиться к уже освобождённой памяти.

2. В возвращённом буфере не проверяются смещения и не гарантируется, что они остаются в его пределах. Буфер представляет собой список вложенных структур: адрес следующей структуры получают, прибавляя к адресу текущей указанное в ней смещение. Пользовательское приложение может изменить смещение так, чтобы оно указывало в память ядра. Поскольку перехватчик иногда записывает данные по адресу, который считает частью пользовательского буфера, эту ошибку потенциально можно использовать для повышения привилегий из непривилегированного приложения.

2.4. Неправильная проверка типов объектов ядра

Многие возможности ядра Windows представлены объектами, с которыми приложения работают через дескрипторы. Дескриптор — это целое число, по которому ядро находит указатель на нужный объект; затем системная служба выполняет над объектом операцию от имени вызвавшего её кода. Для объектов всех типов используется единое пространство дескрипторов.

Поэтому системная служба обязана убедиться, что полученный дескриптор относится к объекту ожидаемого типа. Обычно для этого вызывают функцию диспетчера объектов ObReferenceObjectByHandle: она преобразует дескриптор в указатель и при необходимости сравнивает поле типа в стандартном заголовке объекта с переданным типом.

Перехватывая системные службы, KAV неизбежно работает с дескрипторами ядра, но делает это неправильно. В ряде случаев он использует указатель, не проверив тип объекта. Если передать такой службе дескриптор объекта другого типа, возможны повреждение данных и аварийное завершение системы.

Один из примеров — перехватчик NtResumeThread, с помощью которого KAV отслеживает состояние потоков. В данном случае дескриптор неверного типа, по-видимому, не позволяет приложению обрушить систему: возвращённый указатель используется лишь как ключ в таблице, заранее заполненной указателями на объекты потоков. Для той же цели KAV перехватывает NtSuspendThread, и там допущена аналогичная ошибка проверки типа.

Однако не все перехватчики KAV столь безобидны. Перехватчик NtTerminateProcess читает тело объекта, заданного дескриптором процесса, чтобы определить имя завершаемой программы. При этом он не проверяет, что переданный из пользовательского режима дескриптор действительно относится к объекту процесса.

Это небезопасно по нескольким причинам, которые могут быть хорошо известны читателю, если он имеет опыт программирования ядра Windows.

1. Определение структуры процесса ядра (EPROCESS) часто меняется между выпусками ОС и даже пакетами обновлений. Поэтому напрямую обращаться к её полям в общем случае небезопасно.

2. Из-за отсутствия проверки типа можно передать дескриптор другого объекта ядра, например мьютекса. Его внутреннее устройство несовместимо со структурой процесса, и KAV может обрушить систему.

Первую проблему KAV пытается обойти, определяя во время выполнения смещение поля с именем процесса в структуре EPROCESS. Алгоритм последовательно просматривает память по одному байту от начала объекта процесса, пока не найдёт последовательность, соответствующую имени исходного системного процесса. Эта процедура вызывается в контексте системного процесса.

Если передать дескриптор объекта неверного типа, KAV попытается прочитать имя процесса по указателю на тело этого объекта. Для объекта, не являющегося процессом, чтение обычно выйдет за пределы структуры: объект процесса значительно крупнее, например, мьютекса, а поле имени находится в нескольких сотнях байтов от его начала. Поэтому неверный дескриптор в NtTerminateProcess закономерно приводит к падению системы.

Сомнительна и сама цель этого перехватчика. Он не позволяет даже законному администратору завершать некоторые процессы KAV — поведение, которое обычно связывают с руткитами, а не с коммерческими приложениями. Возможно, так разработчики пытались помешать вирусам завершать процессы антивируса. Однако неясно, зачем это требуется, если заявленные средства проверки в реальном времени действительно работают.

Кроме того, непосредственно перед завершением процесса KAV, по-видимому, обновляет внутреннее состояние через тот же перехватчик. Для этого следовало использовать документированную функцию ядра PsSetCreateProcessNotifyRoutine, позволяющую драйверу зарегистрировать обработчик создания и завершения процессов.

2.5. Изменение неэкспортируемых функций ядра, не являющихся системными службами

Изменения KAV не ограничиваются системными службами. Один из самых опасных перехватчиков внедрён в середину неэкспортируемой функции nt!SwapContext. Поскольку это не системная служба, код драйвера может найти её лишь по сигнатуре машинных команд — надёжного интерфейса для этого нет. Ядро вызывает nt!SwapContext при каждом переключении контекста для выполнения внутренних служебных операций.

Изменять столь важную неэкспортируемую функцию, находя её вслепую по сигнатуре кода, крайне рискованно. Более того, KAV встраивается не в начало nt!SwapContext, а в её середину и тем самым полагается на недокументированное использование регистров и стека внутри функции.

Немодифицированная nt!SwapContext содержит код примерно такого вида:

Такое изменение крайне опасно по нескольким причинам:

1. nt!SwapContext находится на одном из самых нагруженных путей выполнения: она вызывается при каждом переключении контекста. Безопасно изменить её во время работы системы сложно, особенно на многопроцессорной машине. На однопроцессорных системах KAV пытается синхронизировать изменение полным отключением прерываний, но на многопроцессорных это не обеспечивает защиту. Никаких дополнительных мер KAV не принимает, поэтому при его загрузке возможен случайный сбой системы.

2. Невозможно надёжно находить эту функцию и рассчитывать на одинаковое расположение команд, использование регистров и стека во всех существующих и будущих версиях Windows. Тем не менее KAV именно так и поступает. Очередное обновление Windows может нарушить одно из заложенных предположений о переключении контекста и привести к сбою при загрузке.

Чтобы изменять код ядра, KAV также делает его страницы доступными для записи, напрямую меняя атрибуты PTE. Документированные функции обеспечили бы правильную синхронизацию при доступе к внутренним структурам диспетчера памяти, но здесь они не используются.

Изменение nt!SwapContext в KAV:

Подпрограмма KavSpinLockAcquire, отключающая прерывания:

Подпрограмма KavSpinLockRelease, снова включающая прерывания:

Подпрограмма ModifyPteAttributes:

2.6. Прямой доступ пользовательского кода к памяти ядра и неправильная проверка пользовательских структур

Один из важнейших принципов современных операционных систем состоит в том, что пользовательский режим не должен иметь прямого доступа к памяти ядра. Это необходимо для устойчивости системы: иначе ошибка в обычном приложении могла бы повредить ядро и обрушить весь компьютер.

Разработчики KAV, по-видимому, не считают это разделение обязательным.

Одна из самых странных и небезопасных особенностей KAV позволяет пользовательскому коду напрямую вызывать части драйвера, расположенные в адресном пространстве ядра. Вместо этого можно было загрузить пользовательскую DLL или внедрить обычный пользовательский код в целевой процесс.

Судя по всему, механизм служит для проверки DLL при их загрузке. Эту задачу гораздо безопаснее решать через PsSetLoadImageNotifyRoutine.

При создании процесса KAV изменяет kernel32.dll: записи таблицы экспорта для функций загрузки DLL, например LoadLibraryA, перенаправляются на переходник, вызывающий код драйвера в режиме ядра. Кроме того, KAV меняет защиту части своих секций кода и данных, разрешая читать их из пользовательского режима.

KAV регистрирует обработчик через PsSetLoadImageNotifyRoutine, чтобы обнаружить загрузку kernel32.dll и вовремя изменить её таблицу экспорта. Непонятно, почему нужная работа не выполняется прямо в этом обработчике, без сложного механизма перехода из пользовательского режима в ядро ради перехвата LoadLibrary.

Когда новый процесс загружает образ, вызывается CheckInjectCodeForNewProcess. Функция проверяет, не является ли этот образ kernel32.dll; если является, она ставит в очередь APC, которая и внесёт изменения.

Сама процедура APC изменяет таблицу экспорта kernel32.dll, создаёт переходники для вызова режима ядра и меняет атрибуты PTE образа драйвера KAV, разрешая доступ из пользовательского режима.

При изменении образа KAV сначала снимает защиту с таблицы экспорта kernel32.dll, затем перенаправляет записи адресов семейства LoadLibrary* на переходник в свободной области образа и записывает туда код самого переходника:

Код KAV, меняющий защиту таблицы экспорта, без проверки предполагает, что пользовательский заголовок PE сформирован правильно и его смещения не ведут по адресам ядра:

Не лучше устроен и механизм изменения защиты пользовательского кода. KAV динамически определяет номер системного вызова NtProtectVirtualMemory, а затем вызывает службу через собственный переходник с инструкцией int 2e.

Код поиска экспортируемых функций KAV недостаточно проверяет смещения, прочитанные из заголовка PE:

Пользовательский режим напрямую вызывает код ядра KAV без перехода в кольцо 0:

При пошаговом выполнении кода ядра KAV, вызванного из пользовательского режима, система падает; очевидно, механизм не столь надёжен:

2.7. Решение

Антивирус KAV опирается на множество небезопасных приёмов в режиме ядра, угрожающих устойчивости системы. Первым шагом к исправлению должно стать удаление таких решений, как изменение неэкспортируемых функций ядра и перехват системных служб без надлежащей проверки параметров.

Большинство задач, ради которых KAV прибегает к перехватам и другим рискованным средствам, можно решить через документированные безопасные API и соглашения, описанные в Windows Device Driver Kit (DDK) и Installable File System Kit (IFS Kit). Разработчикам стоило бы следовать этим способам работы с ядром Windows, а не применять грубые обходные приёмы, создающие риск падения системы и даже повышения привилегий.

Многие используемые KAV приёмы на x64 блокирует PatchGuard. Поэтому выпуск 64-разрядной версии антивируса неизбежно осложнится, а её значение будет расти по мере распространения компьютеров и Windows для x64. В 64-разрядную Windows нельзя загрузить 32-разрядный драйвер, значит KAV придётся перенести свой драйвер на x64 и учитывать PatchGuard. Быстро устаревает и расчёт исключительно на однопроцессорные компьютеры: большинство новых систем поддерживают Hyper-Threading или несколько ядер.

3. Проблема: McAfee Internet Security Suite 2006

Пакет McAfee Internet Security Suite 2006 включает антивирус, межсетевой экран, средство борьбы со спамом и другие программы. Здесь рассматривается только один его компонент — McAfee Privacy Service.

Компонент должен перехватывать исходящий трафик и удалять из него заранее заданные конфиденциальные сведения до отправки в сеть.

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

Но основная проблема глубже. Для перехвата и возможного изменения исходящего сетевого трафика пакет использует характерный для Windows механизм LSP — многоуровневого поставщика услуг.

LSP представляет собой пользовательские DLL, подключаемые к Winsock, то есть к интерфейсу сокетов Windows. Они вызываются при каждом обращении приложения к сокетному API. Это позволяет просматривать и менять трафик без полноценного драйвера ядра. DLL поставщика загружается и выполняется в контексте приложения, сделавшего исходный вызов.

Следовательно, у большинства программ все пользовательские обращения к сокетам проходят через LSP пакета и могут быть изменены.

Уже здесь возникает серьёзная проблема: DLL поставщика находится в том же адресном пространстве и обладает теми же правами, что и вызвавшая её программа. Поэтому вредоносное приложение технически может изменить код DLL, исключить себя из обработки или вовсе обойти LSP.

Недостатки McAfee Privacy Service этим не исчерпываются. Однако уже ограничения LSP делают этот подход непригодным для надёжной защиты личных данных от вредоносных программ.

В реализации LSP также есть ошибки обработки некоторых вызовов сокетного API. Из-за них исправные программы могут давать сбои под McAfee Internet Security Suite 2006, а их разработчикам приходится отдельно обеспечивать совместимость с широко распространённым защитным пакетом.

Windows Sockets поддерживает многопоточность и позволяет одновременно обращаться к API из разных потоков без повреждения данных и потери устойчивости. LSP McAfee нарушает это требование. При создании и уничтожении сокетов он неправильно синхронизирует доступ к внутренним структурам. В результате только что созданный сокет иногда успевает быть ошибочно закрыт поставщиком ещё до того, как приложение начнёт им пользоваться.

Похожая ошибка синхронизации наблюдается и в реализации select. Эта функция опрашивает набор сокетов, например проверяет наличие данных для чтения или свободного места для отправки. Когда несколько потоков одновременно вызывают select, LSP McAfee иногда подменяет указанный приложением дескриптор сокета совершенно другим. В Windows сокеты, файлы, процессы, потоки и прочие объекты ядра используют общее пространство дескрипторов. Поэтому последующие вызовы select либо необъяснимо завершаются ошибкой, либо сообщают о данных на одном сокете, хотя в действительности они пришли на другой.

Обе ошибки приводят к периодическим сбоям правильно написанных сторонних приложений при работе вместе с McAfee Internet Security Suite 2006.

3.2. Решение для поставщиков ПО

Если программе необходимо работать под McAfee Internet Security Suite 2006, один из возможных обходов — вручную последовательно выполнять все вызовы select, а также функций создания и уничтожения сокетов, включая socket и семейство WSASocket. На практике такой подход работает и, вероятно, требует наименьших изменений для обхода дефекта LSP.

Другой вариант — полностью миновать LSP и обращаться непосредственно к драйверу сокетов ядра AFD.sys. Но тогда придётся определить настоящий дескриптор сокета, поскольку значение, возвращаемое LSP McAfee, не является нижележащим дескриптором, а также использовать официально не документированный интерфейс IOCTL драйвера AFD.

3.3. Решение для McAfee

Для McAfee решение довольно простое: правильно синхронизировать доступ к внутренним структурам данных при одновременных вызовах из нескольких потоков.

4. Заключение

По мере того как Интернет становится всё более враждебной средой, пользователи всё чаще полагаются на защитные пакеты — как дополнение к грамотному администрированию или даже как его замену. Поэтому их производителям особенно важно следить, чтобы собственные программы не нарушали нормальную работу системы. Автор понимает, насколько это трудно с учётом требований к современным средствам защиты, и надеется, что разбор ошибок существующих продуктов поможет новым программам их не повторять.

Аннотация: в статье описан способ, позволяющий в определенных обстоятельствах добиться выполнения произвольного кода через ошибки, которые обычно считаются неэксплуатируемыми, например разыменование нулевого указателя. Атакующий косвенно получает управление главным фильтром необработанных исключений процесса. Ранее уже была показана полезность контроля над таким фильтром [1, 3], поэтому в Windows XP SP2 и более новых системах Microsoft стала кодировать указатель функции [4], мешая атакующему напрямую перезаписать его. Это существенное улучшение, но архитектурный недостаток неявной цепочки фильтров все еще позволяет захватить управление. Для атаки необходимо управлять порядком включения и исключения фильтров, например путем загрузки и выгрузки DLL. Условие ограничивает область применения, однако существуют важные практические случаи, в том числе Internet Explorer.

Отказ от ответственности: документ предназначен для образовательных целей. Авторы не отвечают за применение обсуждаемых методов.

Благодарности: авторы хотели бы поблагодарить H D Moore и всех, кто учится потому, что это интересно.

Обновление: проблема исправлена обновлением MS06-051. Полный анализ всех потенциальных векторов после установки исправления пока не проводился.

Итак, шоу начинается...

2. Введение

С точки зрения безопасности программные ошибки в целом делятся на эксплуатируемые и неэксплуатируемые. Первые можно использовать в интересах атакующего, например для выполнения произвольного кода; вторые обычно позволяют лишь аварийно завершить приложение. Ошибка часто считается неэксплуатируемой потому, что связана с неверным предположением, не имеющим прямого отношения к управлению буферами или границам циклов. При аудите продукта такие находки разочаровывают, поэтому естественно искать способы превратить их в пригодные для эксплуатации.

Сначала нужно найти путь выполнения, который после срабатывания такой ошибки можно перенаправить в код атакующего. Разыменование нулевого указателя вызывает исключение нарушения доступа. Диспетчер пользовательского режима последовательно вызывает зарегистрированные обработчики потока. Если ни один не справляется, через kernel32!UnhandledExceptionFilter вызывается главный фильтр необработанных исключений (UEF), если он установлен. Поведение зарегистрированной функции определяется приложением, но обычно она передает неизвестные ей исключения ранее установленному фильтру, образуя неявную цепочку UEF. Далее этот процесс рассматривается подробнее.

Без дополнительных, зависящих от конкретной ситуации условий других управляемых путей выполнения обычно нет. Поэтому точку перенаправления следует искать в самой диспетчеризации исключений: это даст общий способ получить управление для любой ошибки, способной аварийно завершить приложение.

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

Если обработчики потока недоступны, остается главный фильтр. Раньше можно было заменить его указатель адресом управляемого кода [1, 3], но Windows XP SP2 кодирует этот указатель [4], и прямое изменение глобальной переменной стало непрактичным. Следовательно, нужно изучить саму функцию фильтра и возможность косвенно перенаправить ее выполнение.

На первый взгляд остается лишь зависящий от приложения анализ существующих обработчиков и UEF, полезный только в редких случаях. Поэтому следует глубже рассмотреть диспетчеризацию исключений. Следующий раздел объясняет работу фильтров, затем описывает косвенный захват главного UEF, а в заключение приводится рабочий эксплойт одного из многочисленных разыменований нулевого указателя в Internet Explorer.

3. Фильтры необработанных исключений

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

3.1. Установка главного UEF

Для обработки исключений на уровне всего процесса диспетчер предоставляет интерфейс регистрации фильтра. Приложение может записывать дополнительные сведения, выполнять сложное восстановление, обрабатывать специфичные для языка исключения или решать другие задачи. Главный фильтр задается функцией kernel32!SetUnhandledExceptionFilter [6]:

Функция кодирует переданный указатель lpTopLevelExceptionFilter через kernel32!RtlEncodePointer и сохраняет результат в глобальной переменной kernel32!BasepCurrentTopLevelFilter, заменяя прежний фильтр. Старое значение декодируется через kernel32!RtlDecodePointer и возвращается вызывающему. Кодирование мешает перенаправить указатель произвольной записью в память, как это делалось до XP SP2.

Возврат прежнего указателя позволяет позднее восстановить фильтр и создать неявную цепочку UEF. Каждый новый фильтр может вызвать ранее зарегистрированный примерно так:

Чтобы снять регистрацию, код устанавливает главным UEF значение, возвращенное при его регистрации. Настоящего списка фильтров система не ведет. Отсюда следует ключевое свойство: регистрация и снятие регистрации должны выполняться в симметричном порядке.

Например, при регистрации Fx возвращается прежний фильтр Nx, а при последующей регистрации Gx — Fx. Сначала снимается Gx восстановлением Fx, затем Fx восстановлением Nx.

3.2. Обработка необработанных исключений

Если ни один зарегистрированный обработчик потока не принял исключение, диспетчер делает последнюю попытку перед принудительным завершением приложения. При подключенном отладчике исключение передается ему; иначе вызывается связанный с процессом фильтр [5], то есть kernel32!UnhandledExceptionFilter получает сведения об исключении.

Без отладчика kernel32!UnhandledExceptionFilter вызывает главный UEF. Тот может восстановить состояние и вернуть EXCEPTION_CONTINUE_EXECUTION, завершить процесс через EXCEPTION_EXECUTE_HANDLER либо разрешить стандартное сообщение об ошибке, вернув EXCEPTION_CONTINUE_SEARCH. При наличии отладчика исключение передается ему, а главный UEF не вызывается — важное для дальнейшей атаки условие.

Без отладчика функция декодирует указатель главного UEF из kernel32!BasepCurrentTopLevelFilter через kernel32!RtlDecodePointer:

Если результат не равен NULL, декодированный главный фильтр вызывается со сведениями об исключении:

Возвращаемое значение определяет, продолжит ли приложение работу, завершится сразу или сначала сообщит об ошибке.

3.3. Назначение фильтров необработанных исключений

Чаще всего фильтры обеспечивают специфичную для языка обработку прозрачно для программиста. Например, среда C++ регистрирует UEF через CxxSetUnhandledExceptionFilter при инициализации CRT из точки входа программы или динамической библиотеки, а при завершении либо выгрузке восстанавливает прежний фильтр через CxxRestoreUnhandledExceptionFilter.

Другие программы используют механизм для расширенных отчетов об ошибках и сбора сведений перед аварийным завершением.

4. Получение управления фильтром необработанных исключений

Поскольку глобальная переменная содержит кодированный указатель, единственный практический путь к управлению главным UEF — воздействовать на вызовы kernel32!SetUnhandledExceptionFilter. Прямое перенаправление самой функции потребовало бы другой эксплуатируемой уязвимости и потому здесь неинтересно.

Следует подробнее рассмотреть неявную цепочку регистрации. Ее можно привести в поврежденное состояние, нарушив обязательную симметрию. Предположим, что Fx и Gx устанавливаются и удаляются в разном порядке.

Сначала регистрируются Fx, затем Gx. Если первым снять Fx, главным фильтром станет Nx, хотя Gx все еще должен присутствовать. Последующее удаление Gx восстановит Fx, уже снятый с регистрации. Код Gx не знает об этом из-за неявной природы цепочки.

Если регистрация происходит при загрузке DLL, а снятие — при выгрузке, после асимметричной последовательности главный UEF останется равен Fx, указывающему в освобожденную память библиотеки. При следующем необработанном исключении и отсутствии отладчика система вызовет недействительный указатель, что приведет к сбою или более опасным последствиям.

Висячий указатель на освобожденную память особенно выгоден атакующему. Он может занять эту область и разместить по прежнему адресу функции собственный код. Вызов UEF выполнит уже его; для запуска достаточно создать необработанное исключение, например разыменовать нулевой указатель.

Практическая атака требует трех действий: асимметрично выгрузить не менее двух DLL с UEF, оставив главный фильтр в освобожденной памяти; занять эту память управляемым кодом; вызвать необработанное исключение, запускающее подмененный фильтр.

Остается понять, насколько реально управлять регистрацией и снятием UEF. Следующий раздел показывает, что Internet Explorer предоставляет такую возможность.

5. Практический пример: Internet Explorer

Internet Explorer снова оказывается удобной средой для превращения неэксплуатируемых ошибок в выполнение произвольного кода. Браузер позволяет загружать и выгружать DLL, которые регистрируют и снимают главные UEF. Атакующий управляет этим через создание объектов COM конструкцией new ActiveXObject в JavaScript либо тегом HTML OBJECT.

При создании внутрипроцессного объекта COM соответствующая DLL загружается в память и вызывается ее DllMain. Если библиотека имеет фильтр необработанных исключений, он может регистрироваться при инициализации CRT из точки входа. Остается лишь найти подходящие объекты COM.

Для снятия регистрации соответствующие DLL необходимо выгрузить. При закрытии окна Internet Explorer, содержавшего объект COM, вызывается ole32!CoFreeUnusedLibrariesEx, а для загруженных библиотек — DllCanUnloadNow. Если функция возвращает S_OK, например при отсутствии оставшихся ссылок на объекты, DLL может быть выгружена.

Таким образом, загрузкой и выгрузкой библиотек с UEF можно управлять. Ниже показана асимметричная последовательность.

Регистрация:

1. Открыть окно #1

2. Создать экземпляр COMObject1

3. Загрузить DLL 1

4. SetUnhandledExceptionFilter(Fx) => Nx

5. Открыть окно #2

6. Создать экземпляр COMObject2

7. Загрузить DLL 2

8. SetUnhandledExceptionFilter(Gx) => Fx

Первое окно создает COMObject1 из DLL 1, регистрирующей Fx. Второе создает COMObject2 из DLL 2, регистрирующей Gx. Обе библиотеки остаются в памяти, а главным UEF становится Gx.

Для захвата управления DLL 1 выгружается раньше DLL 2: сначала закрывается окно с COMObject1, затем окно с COMObject2. Оба раза ole32!CoFreeUnusedLibrariesEx освобождает соответствующую библиотеку.

Снятие регистрации:

1. Закрыть окно #1

2. CoFreeUnusedLibrariesEx

3. Выгрузить DLL 1

4. SetUnhandledExceptionFilter(Nx) => Gx

5. Закрыть окно #2

6. CoFreeUnusedLibrariesEx

7. Выгрузить DLL 2

8. SetUnhandledExceptionFilter(Fx) => Nx

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

Теперь атакующему нужно разместить свой код по прежнему адресу Fx. Для этого подходит распыление кучи [8, 7], широко применяемое против браузеров: куча заполняется управляемыми данными, пока не достигнет нужного диапазона адресов. При последующем исключении вызывается размещенный там код.

Практичность зависит от расстояния между кучей и адресом DLL. Если куча растет от 0x00480000, а библиотека загружена по 0x7c800000, потребуется около 1,988 Гбайт данных, достаточный объем оперативной памяти и файла подкачки и очень много времени. Поэтому DLL с Fx должна отображаться как можно ближе к началу роста кучи.

Библиотеки COM Microsoft в XP SP2 предпочитают высокие адреса, что затрудняет распыление. Многие сторонние DLL используют стандартную базу 0x00400000 и потому подходят лучше. Предпочтительный адрес не обязателен: если диапазоны двух библиотек пересекаются, одна будет перемещена, обычно вниз и ближе к куче. Загрузка конфликтующих DLL позволяет принудительно переместить библиотеку с UEF.

Объект COM не обязан успешно создаваться: Internet Explorer все равно загружает DLL и опрашивает интерфейсы, чтобы проверить доступность и совместимость класса. Поэтому подходят библиотеки любых объектов COM, а не только разрешенных к созданию из браузера.

На этой основе создан рабочий демонстрационный эксплойт для полностью обновленных до MS06-051 Windows XP SP2 и Internet Explorer. На цели требуется Adobe Acrobat, хотя можно использовать другие сторонние DLL и даже библиотеки Microsoft, если их адрес достижим распылением кучи. Эксплойт превращает разыменование нулевого указателя в выполнение произвольного кода и оформлен модулем Metasploit Framework 3.0.

Следующий пример показывает демонстрационную реализацию в действии:

6. Методы смягчения

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

Помимо исправления архитектуры, атаку смягчают обычные меры защиты от эксплуатации, такие как NX и ASLR.

6.1. Изменение поведения SetUnhandledExceptionFilter

Microsoft могла бы изменить kernel32!SetUnhandledExceptionFilter, добавив настоящие операции регистрации и снятия вместо неявного восстановления старого указателя. Функция должна различать эти два действия.

При регистрации функция могла бы возвращать динамически созданный контекст, вызывающий предыдущий обработчик. Повторный вызов с таким контекстом означал бы снятие регистрации, а с обычным указателем — новую регистрацию.

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

6.2. Запрет установки UEF вне образа

Другой вариант — разрешать kernel32!SetUnhandledExceptionFilter только указатели в области загруженного образа. Это смягчит атаку, но может нарушить обратную совместимость: легитимные приложения иногда устанавливают фильтры в иной памяти. Недействительный указатель не обязательно приводит к сбою, поскольку фильтр может никогда не вызываться, а новая проверка сломает ранее работавшую программу сразу.

6.3. Запрет выполнения UEF вне образа

Можно запретить kernel32!UnhandledExceptionFilter выполнять главный UEF вне образа, но этого недостаточно. После асимметричного удаления недействительного фильтра приложение может установить новый допустимый UEF. Система вызовет его, а тот передаст неизвестное исключение прежнему, уже недействительному обработчику, который может указывать на код атакующего. Проверка только первой функции не контролирует дальнейшую неявную цепочку.

7. Будущие исследования

Будущие исследования могут искать более удобные способы асимметричного удаления. Вместо дочерних окон Internet Explorer, возможно, существует другой путь вызвать ole32!CoFreeUnusedLibrariesEx. По умолчанию функция выполняется каждые десять минут, но это мало помогает надежной эксплуатации. Можно также усовершенствовать распыление кучи для более точного размещения кода по адресу исчезнувшего UEF.

Стоит исследовать и другие приложения. Обычно атакующий не управляет загрузкой и выгрузкой DLL, но при наличии такого интерфейса атака становится возможной.

Особенно интересен IIS. Если удаленный атакующий сможет заставлять сервер загружать и выгружать DLL с UEF в нужном порядке, например обращаясь к сайтам, создающим объекты COM, вектор станет удаленным. Авторам известны лишь функции удаленной отладки ASP.NET, разрешающие создавать объекты из определенного белого списка. Такая конфигурация редка и сильно ограничена, но могут существовать более практичные способы.

Вектор может затронуть Excel, Word и другие приложения Microsoft Office, позволяющие создавать и встраивать в документы произвольные объекты COM. Если через них удастся управлять библиотеками, описанный недостаток станет эксплуатируемым. Возможный путь — макросы, хотя необходимость разрешения пользователем снижает опасность.

Еще одна возможная цель — Microsoft SQL Server, способный загружать и выгружать DLL. SQL-инъекция теоретически может управлять главным UEF через эти операции, хотя сама возможность загрузки библиотек, вероятно, открывает и более прямые пути выполнения кода. Большой запрос с предсказуемым результатом способен распылить кучу. Атака может проходить даже через обычный сайт поверх SQL Server: векторы не всегда прямолинейны.

8. Заключение

Статья показала, как превратить обычно бесполезную ошибку, например разыменование нулевого указателя, в выполнение кода. Асимметричная регистрация и снятие позволяют направить главный UEF в освобожденную память, а распыление кучи — разместить там код атакующего. После этого достаточно вызвать необработанное исключение.

Ключевой недостаток — предположение о симметричных вызовах kernel32!SetUnhandledExceptionFilter. Библиотеки с фильтрами не всегда загружаются и выгружаются в таком порядке. Управляя этими операциями, атакующий получает выполнение произвольного кода, как показано на примере Internet Explorer.

В большинстве программ атака непрактична, но ее работоспособность доказана для критически важного Internet Explorer. В будущем подходящие условия могут обнаружиться и в других приложениях, например IIS.

Библиография

[1] Conover, Matt and Oded Horovitz. Reliable Windows Heap Exploits. <http://cansecwest.com/csw04/csw04-Oded+Connover.ppt>; дата обращения: 6 мая 2006 г.

[2] Kazienko, Przemyslaw and Piotr Dorosz. Hacking an SQL Server. <http://www.windowsecurity.com/articles/HackinganSQLServer.html>; дата обращения: 7 мая 2006 г.

[3] Litchfield, David. Windows Heap Overflows. <http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt>; дата обращения: 6 мая 2006 г.

[4] Howard, Michael. Protecting against Pointer Subterfuge (Kinda!). <http://blogs.msdn.com/michael_howard/archive/2006/01/30/520200.aspx>; дата обращения: 6 мая 2006 г.

[5] Microsoft Corporation. UnhandledExceptionFilter. <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/unhandledexceptionfilter.asp>; дата обращения: 6 мая 2006 г.

[6] Microsoft Corporation. SetUnhandledExceptionFilter. <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/setunhandledexceptionfilter.asp>; дата обращения: 6 мая 2006 г.

[7] Murphy, Matthew. Windows Media Player Plug-In Embed Overflow. <http://www.milw0rm.com/exploits/1505>; дата обращения: 7 мая 2006 г.

[8] SkyLined. InternetExploiter. <http://www.edup.tudelft.nl/bjwever/exploits/InternetExploiter2.zip>; дата обращения: 7 мая 2006 г.

Аннотация: в статье предлагается способ предотвращать эксплуатацию перезаписи SEH в 32-разрядных приложениях Windows без их перекомпиляции. Microsoft пыталась закрыть этот вектор атаки изменениями в диспетчере исключений и дополнительными средствами компилятора, такими как /SAFESEH и /GS, однако эти меры в основном защищают лишь модули, собранные с соответствующими параметрами. Если хотя бы один загруженный модуль такой защиты не имеет, перезапись SEH по-прежнему может позволить выполнить код. Поэтому даже в новых версиях Windows многие сторонние приложения остаются уязвимыми: их просто не пересобрали. Предлагаемый способ не требует поддержки со стороны компилятора и применяется к уже существующим приложениям во время выполнения, почти не влияя на быстродействие. Он совместим со всеми версиями Windows семейства NT и потому подходит в том числе для защиты устаревших установок.

Благодарности: автор хотел бы поблагодарить всех, кто помогал отзывами и идеями по этой технике. В частности, автор благодарит spoonm, H D Moore, Skywing, Richard Johnson и Alexander Sotirov.

2. Введение

Как и другие операционные системы, Windows подвержена стековым переполнениям буфера, переполнениям буфера в куче и другим распространённым классам ошибок. Различаются платформы прежде всего тем, как подобные ошибки превращают в возможность выполнить произвольный код. При обычном стековом переполнении самый очевидный и универсальный приём — перезаписать адрес возврата. Но в Windows существует особый вектор, который во многих случаях позволяет надёжнее захватить управление через перезапись обработчика структурированных исключений (SEH). Насколько известно автору, впервые публично этот приём описал Дэвид Литчфилд в статье «Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server». Впрочем, эксплойты применяли его и до публикации, поэтому имя первооткрывателя неизвестно.

Чтобы понять защиту от перезаписи SEH, сначала нужно разобраться в назначении механизма и в том, как им злоупотребляют для захвата управления. Ниже приведены необходимые сведения о структурированной обработке исключений, а затем разобран сам способ эксплуатации. Знакомый с ним читатель может пропустить эту часть. Устройство предлагаемой защиты описано в главе 3, опытная реализация — в главе 4, а возможные проблемы совместимости — в главе 5.

2.1. Структурированная обработка исключений

Структурированная обработка исключений (SEH) — единая система диспетчеризации и обработки исключений, возникающих при выполнении программы. По назначению она напоминает сигналы SIGPIPE, SIGSEGV и им подобные в UNIX-системах, но, по мнению автора, устроена более универсально и предоставляет больше возможностей. Microsoft использует SEH как в пользовательском режиме, так и в режиме ядра; эта система представляет собой лицензированную реализацию метода, описанного в патенте Borland. Наличие патента стало одной из причин, по которым операционные системы с открытым исходным кодом не переняли такой способ диспетчеризации исключений.

На уровне реализации SEH задаёт единый порядок обработки всех исключений, возникающих при работе процесса. Здесь исключением называется событие, требующее особой обработки. Исключения делятся на два основных вида. Аппаратные исключения порождает процессор: например, обращение программы к недопустимому адресу памяти вызывает прерывание и передаёт операционной системе возможность обработать ошибку. К ним также относятся попытки выполнить недопустимую инструкцию, ошибки выравнивания и другие зависящие от архитектуры сбои. Программные исключения, напротив, порождаются программным обеспечением. Например, операционная система может создать исключение, если процесс попытается закрыть недопустимый дескриптор.

Слово «структурированная» в названии подчёркивает, что одна система диспетчеризует как аппаратные, так и программные исключения. Благодаря этому приложение обрабатывает ошибки разных видов единообразно и получает больше свободы в выборе реакции на них.

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

Большинство сгенерированных компилятором функций C/C++ регистрируют обработчики исключений в прологе и удаляют их в эпилоге. Поэтому цепочка обработчиков повторяет устройство стека потока: обе структуры работают по принципу «последним вошёл — первым вышел» (LIFO). Последний зарегистрированный обработчик удаляется первым, как и последняя вызванная функция возвращает управление первой.

Чтобы увидеть регистрацию обработчика на практике, разберём программу, использующую SEH. Следующий фрагмент перехватывает все исключения и выводит код возникшего исключения:

Если исключение возникает внутри блока try / except, будет выполнен вызов printf, а GetExceptionCode вернет фактическое возникшее исключение. Например, если код обратится к недопустимому адресу памяти, код исключения будет 0xc0000005, или EXCEPTION_ACCESS_VIOLATION. Чтобы полностью понять, как это работает, нужно погрузиться глубже и посмотреть на ассемблер, сгенерированный из приведенного C-кода. После дизассемблирования код выглядит примерно так:

В исходном коде C регистрация обработчика скрыта от программиста. В ассемблерном листинге она начинается по адресу 0x0040100a и занимает четыре инструкции. Они добавляют структуру EXCEPTION_REGISTRATION_RECORD в начало списка обработчиков текущего потока. Указатель на первую уже зарегистрированную запись хранится в поле ExceptionList структуры NT_TIB; если список пуст, там находится 0xffffffff. NT_TIB образует начало TEB (блока окружения потока) — недокументированной структуры, с помощью которой Windows хранит состояние отдельного потока в пользовательском режиме. Доступ к TEB не зависит от расположения программы в памяти и выполняется через адреса относительно сегментного регистра fs. В частности, начало цепочки обработчиков находится по адресу fs:[0].

Разберём по отдельности четыре инструкции, регистрирующие обработчик исключений. Для справки, структура EXCEPTION_REGISTRATION_RECORD выглядит так:

1. push 0x4011a4

Первая инструкция помещает в стек адрес созданного библиотекой времени выполнения символа excepthandler3. Эта процедура диспетчеризует общие исключения, зарегистрированные с помощью встроенной конструкции компилятора except. Главное здесь то, что в стек записывается виртуальный адрес функции, вызываемой при исключении. Операция push начинает динамическое построение EXCEPTION_REGISTRATION_RECORD в стеке, задавая поле Handler.

2. mov eax, fs:[00000000]

Вторая инструкция берет текущий указатель на первый EXCEPTION_REGISTRATION_RECORD и сохраняет его в eax.

3. push eax

Третья инструкция помещает в стек указатель на первую запись списка исключений. Так задаётся поле Next динамически создаваемой записи. После выполнения инструкции в стеке находится заполненная структура EXCEPTION_REGISTRATION_RECORD:

4. mov fs:[00000000], esp

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

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

Когда возникает исключение, операционная система начинает его диспетчеризацию. Для исключения в пользовательском потоке ядро собирает сведения в структуре EXCEPTION_RECORD, а снимок состояния потока — в структуре CONTEXT. Затем оно возвращает эти данные в пользовательский режим и переносит выполнение с места сбоя на ntdll!KiUserExceptionDispatcher. Важно, что диспетчер исключений работает в контексте того же потока, который породил исключение.

Задача ntdll!KiUserExceptionDispatcher, как следует из имени, — диспетчеризовать исключения пользовательского режима. Функция обходит цепочку зарегистрированных обработчиков текущего потока и вызывает обработчик из каждой записи. Тот может обработать исключение, завершиться с ошибкой либо передать его дальше.

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

2.2. Получение выполнения кода

Для эксплуатации перезаписи SEH решающим оказывается то, что каждая запись регистрации исключения лежит в стеке. Поэтому обычное стековое переполнение может затронуть и её. Как показано выше, запись состоит из указателя Next и указателя на функцию Handler. Поле Handler особенно интересно атакующему: диспетчер исключений воспринимает его как адрес функции, а значит, подмена этого значения позволяет захватить управление. Есть лишь одна дополнительная оговорка.

При обычном стековом переполнении перезаписывают адрес возврата, а при атаке на SEH — поле Handler хранящейся в стеке записи. В первом случае управление захватывается при возврате из функции. Во втором подменённый адрес не используется до возникновения исключения: именно исключение заставляет диспетчер вызвать подменённый Handler.

Может показаться, что необходимость исключения усложняет атаку, однако обычно вызвать его совсем нетрудно. Достаточно, например, перезаписать адрес возврата недопустимым значением. При возврате процессор попытается выполнить код по неверному адресу и создаст исключение нарушения доступа. Диспетчер получит его и вызовет подменённый Handler.

Возникает вопрос: чем перезапись SEH лучше подмены адреса возврата? В Windows адрес стека потока нередко меняется между выпусками системы и даже между запусками процесса. В большинстве UNIX-систем того времени он был предсказуемее. Поэтому Windows-эксплойты часто передают управление в стек косвенно: сначала переходят на инструкцию в более стабильно расположенной исполняемой области модуля, а уже она возвращает управление в стек независимо от его адреса. Типичный пример — jmp esp. Приём работает хорошо, но требует найти подходящую инструкцию по надёжному и переносимому адресу. Здесь и проявляется преимущество перезаписи SEH.

При подмене адреса возврата атакующему подходит лишь небольшой набор инструкций, которые не всегда удаётся найти по стабильному адресу. Перезапись SEH позволяет использовать гораздо более распространённую последовательность pop/pop/ret. Такая возможность связана с тем, как диспетчер вызывает обработчики исключений. Чтобы разобраться в ней, посмотрим на точный прототип функции из поля Handler структуры EXCEPTION_REGISTRATION_RECORD:

Главный для атаки параметр — EstablisherFrame: он указывает на адрес помещённой в стек записи регистрации исключения и при вызове Handler находится по адресу [esp+8]. Если заменить Handler адресом последовательности pop/pop/ret, выполнение перейдёт к содержимому поля Next текущей записи. Обычно там лежит адрес следующей записи, но атакующий может поместить туда четыре байта машинного кода. Поскольку перед полем Handler доступны лишь четыре последовательных байта, обычно в них записывают короткий переход через Handler к расположенному далее коду атакующего.

3. Дизайн

Главное требование к защите от перезаписи SEH состоит в следующем: атакующий не должен иметь возможности подставить в поле Handler записи регистрации исключения значение, которое диспетчер затем без проверки использует при исключении. Защиту, выполняющую это требование, можно считать безопасной.

Решение Microsoft безопасно лишь тогда, когда все загруженные в адресное пространство модули собраны с /SAFESEH, да и в этом случае остаётся возможность найти исполняемую область вне какого-либо модуля. Если же хотя бы один модуль собран без /SAFESEH, атакующий может направить Handler на инструкцию внутри него. SafeSEH устроен так: перед вызовом обработчика диспетчер сверяет его адрес с таблицей разрешённых обработчиков соответствующего модуля. Такая таблица присутствует в исполняемом файле, собранном с /SAFESEH, но не защищает остальные модули. Для сторонних программ и даже некоторых программ Microsoft подобная неполная защита, по мнению автора, скорее правило, чем исключение. Иными словами, механизм Microsoft действует на этапе сборки, тогда как здесь требуется защита во время выполнения.

Защита во время выполнения должна перехватить исключение раньше, чем диспетчер передаст его зарегистрированным обработчикам. Способ такого перехвата рассмотрен ниже. После него нужно определить, допустим ли очередной обработчик и не был ли он подменён. Можно, например, вести отдельный «безопасный» список всех зарегистрированных обработчиков, но это неэффективно. Автор предлагает более подходящий способ.

При перезаписи SEH атакующий обычно затирает и поле Next той же записи. В памяти оно расположено перед Handler, поэтому обычное переполнение буфера достигает его первым. В результате все последующие записи регистрации исключений становятся недостижимы при обходе цепочки. Именно это последствие лежит в основе предлагаемой защиты.

Представим, что при запуске потока защита помещает собственную запись регистрации исключения в самый конец цепочки. Назовём её контрольной записью. Перед диспетчеризацией каждого исключения защита обходит цепочку и проверяет, можно ли дойти до этой записи. По назначению она напоминает стековую «канарейку»: достижимость контрольной записи означает, что цепочка обработчиков не повреждена. Как уже отмечалось, подмена Handler обычно сопровождается перезаписью Next. Если новое значение Next не сохраняет целостность цепочки, защита обнаружит это до вызова подменённого обработчика.

Таким образом, контроль целостности цепочки позволяет предотвращать перезапись SEH. У способа, конечно, есть ограничения. Самый очевидный вопрос: почему атакующий не может записать в Next прежнее значение? Во-первых, обычно он этого значения не знает. Во-вторых, необходимость сохранить Next лишает атаку главного преимущества — возможности использовать pop/pop/ret. Даже если прежнее значение известно, в Handler придётся указывать на инструкции, которые косвенно вернут управление к коду атакующего. Простая команда вроде jmp esp не поможет, поскольку обработчик вызывается в контексте диспетчера исключений. Выгода от атаки резко уменьшается, и при наличии возможности проще перезаписать адрес возврата.

Другой вопрос: почему не записать в Next адрес самой контрольной записи или просто 0xffffffff? Ответ тот же: отказ от pop/pop/ret почти уничтожает преимущество перезаписи SEH перед подменой адреса возврата. Тем не менее для надёжности автор рекомендует случайным образом менять расположение контрольной записи.

По мнению автора, описанное решение удовлетворяет требованию, сформулированному в начале главы, и поэтому является безопасным. Однако всегда есть шанс, что что-то упущено. По этой причине автор с радостью примет доказательство своей неправоты.

4. Реализация

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

Более подходящей точкой была бы ntdll!RtlDispatchException. Программные исключения, созданные через ntdll!RtlRaiseException, иногда передаются прямо туда, минуя ntdll!KiUserExceptionDispatcher; это зависит от того, подключён ли к процессу отладчик. Опытная реализация не перехватывает ntdll!RtlDispatchException, поскольку функция напрямую не экспортируется, хотя её адрес можно найти достаточно надёжными способами. Насколько известно автору, из-за выбора ntdll!KiUserExceptionDispatcher защита способна пропустить только программные исключения, которые атакующему гораздо сложнее, а чаще всего невозможно вызвать.

В начале ntdll!KiUserExceptionDispatcher можно записать косвенный переход на функцию проверки. После проверки она выполнит заменённые инструкции и вернётся в штатный диспетчер по адресу следующей инструкции. Для стороннего решения это достаточно аккуратный способ с ничтожными накладными расходами.

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

После установки перехвата нужна сама функция проверки. Она получает начало списка из fs:[0] и последовательно обходит записи. Для каждой записи проверяется, указывает ли Next на допустимую область памяти. Недопустимый адрес означает повреждение цепочки. Если адрес допустим, он сравнивается с адресом контрольной записи, заранее помещённой в конец цепочки потока. Совпадение подтверждает целостность, после чего исключение можно передать штатному диспетчеру.

Если встречается недопустимый указатель Next либо значение 0xffffffff до контрольной записи, цепочка считается повреждённой. Защита может отклонить исключение, записать в журнал сведения о возможной попытке эксплуатации и выполнить другие нужные действия. В конечном счёте поток или весь процесс следует завершить. Алгоритм приведён в псевдокоде:

Алгоритм охватывает диспетчеризацию исключения, но остаётся заранее зарегистрировать контрольную запись — до первого исключения в потоке. В опытной реализации проще всего использовать DLL, которая после загрузки в процесс получает уведомления о создании потоков через DllMain; для статически скомпонованной библиотеки подойдёт обратный вызов TLS. Оба варианта позволяют установить контрольную запись в начале работы потока. Однако если исключение произойдёт ещё раньше, защита ошибочно сочтёт цепочку повреждённой.

Можно хранить для каждого потока признак того, установлена ли контрольная запись, но это создаёт новую слабость. Если атакующий сумеет сбросить такой признак и вызвать исключение, защите придётся отказаться от проверки, считая, что контрольная запись ещё не установлена. Кроме того, потребуется отдельное хранилище состояния каждого потока, например TLS, а оно подвержено той же угрозе подмены.

Более радикальный вариант — встроиться в выполнение потока совсем рано, возможно ещё до перехода к его точке входа. Автор знает удачный способ, но предлагает читателю найти его самостоятельно. Для Microsoft такой вариант мог бы стать простым и изящным способом добавить встроенную поддержку защиты.

Последний практический вопрос — как защитить существующие приложения без перекомпиляции. В опытном варианте механизм проще всего оформить как DLL, динамически загружаемую в адресное пространство процесса. После загрузки её DllMain выполнит настройку. Загрузку можно организовать через AppInitDLLs, хотя у этого механизма есть ограничения. Возможны и более глубокие способы загрузить и инициализировать DLL на раннем этапе создания процесса.

Хотя подход задуман как защита во время выполнения, его можно подключать и при сборке приложения. В отличие от механизма Microsoft, он сохранит силу даже при наличии сторонних модулей, собранных без такой поддержки. Реализовать это можно статической библиотекой, которая получает уведомления о создании потоков через обратные вызовы TLS, подобно тому как вариант в виде DLL использует DllMain.

В целом описанная реализация предоставляет сравнительно простую защиту от перезаписи SEH во время выполнения с минимальными накладными расходами. Вариант из статьи рассчитан прежде всего на демонстрацию идеи или на конкретное приложение, но существуют и более надёжные практические реализации — например, продукт WehnTrust компании Wehnus, коммерческий побочный проект автора. Прошу простить эту бесстыдную рекламу.

5. Совместимость

Как и у большинства решений безопасности, всегда есть проблемы совместимости, которые нужно учитывать. Для решения из этой статьи важно помнить пару вещей.

Первая возможная проблема возникает, если приложение само намеренно нарушает обычное устройство цепочки обработчиков. Автору неизвестны ситуации, где это действительно необходимо, однако некоторые программы, например Cygwin, выполняют с цепочкой необычные операции, способные вступить в конфликт с защитой. Если приложение сделает цепочку некорректной, защита может ошибочно принять это за перезапись SEH, потому что не сумеет дойти до контрольной записи.

Вторая проблема связана с перехватом функции. Такой перехват почти всегда нежелателен, но в среде с закрытым исходным кодом альтернативы часто нет. Возможен конфликт с другой программой, которая тоже изменяет ntdll!KiUserExceptionDispatcher. Кроме того, защитное ПО может обнаружить подмену начала функции и принять её за вредоносное поведение. Эти недостатки относятся не к самой идее проверки цепочки, а к способу, которым сторонняя реализация вынуждена встраиваться в систему.

6. Заключение

Программные уязвимости встречаются во множестве операционных систем, но некоторые особенности конкретной платформы облегчают их эксплуатацию. Один из примеров — перезапись SEH в 32-разрядных приложениях Windows. Атакующий подменяет поле Handler записи регистрации исключения, а затем вызывает исключение, чтобы диспетчер обратился по подставленному адресу. Контекст вызова обработчика делает последующий захват управления особенно удобным.

Microsoft пыталась решить эту проблему изменениями в диспетчере исключений, механизмом SafeSEH и параметром компилятора /GS. Но такие меры требуют перекомпиляции и защищают только собранные с ними модули. Microsoft осознаёт это ограничение; вероятно, такой компромисс был выбран ради снижения риска несовместимости.

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

Защита опирается на то, что при переполнении поле Next перезаписывается раньше поля Handler. Атакующие обычно хранят в Next короткую команду перехода, поэтому не могут одновременно сохранить целостность списка и использовать эти четыре байта как код. Это противоречие и позволяет обнаруживать и предотвращать захват управления через SEH.

По мере распространения 64-разрядных версий Windows полезность решения будет снижаться: благодаря иному устройству обработка исключений в 64-разрядном коде изначально защищена от этой атаки. Но это относится лишь к 64-разрядным модулям. Старые 32-разрядные программы продолжают работать и в 64-разрядной Windows, используя прежний механизм исключений, поэтому их уязвимость зависит от параметров, с которыми они были собраны. Кроме того, современные 32-разрядные процессоры x86 поддерживают аппаратный запрет исполнения (NX), затрудняющий запуск кода из стека. И всё же необходимость защищать устаревшие 32-разрядные программы сохранится, а предложенный способ позволяет это сделать.

A. Ссылки

Borland. United States Patent: 5628016.

<http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=2Fnetahtml2FPTO2Fsrchnum.htm&r=1&f=G&l=50&s1=5,628,016.PN.&OS=PN/5,628,016&RS=PN/5,628,016>;

дата обращения: 5 сентября 2006 г.

Litchfield, David. Defeating the Stack based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server.

<http://www.blackhat.com/presentations/bh-asia-03/bh-asia-03-litchfield.pdf>;

дата обращения: 5 сентября 2006 г.

Microsoft Corporation. Structured Exception Handling.

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/structured_exception_handling.asp>;

дата обращения: 5 сентября 2006 г.

Microsoft Corporation. Working with the AppInitDLLs registry value.

<http://support.microsoft.com/default.aspx?scid=kb;en-us;197571>;

дата обращения: 5 сентября 2006 г.

Microsoft Corporation. /GS (Buffer Security Check)

<http://msdn2.microsoft.com/en-us/library/8dbf701c.aspx>;

дата обращения: 5 сентября 2006 г.

Nagy, Ben. SEH (Structured Exception Handling) Security Changes in XPSP2 and 2003 SP1.

<http://www.eeye.com/html/resources/newsletters/vice/VI20060830.html#vexposed>;

дата обращения: 8 сентября 2006 г.

Pietrek, Matt. A Crash Course on the Depths of Win32 Structured Exception Handling.

<http://www.microsoft.com/msj/0197/exception/exception.aspx>;

дата обращения: 8 сентября 2006 г.

skape. Improving Automated Analysis of Windows x64 Binaries.

<http://www.uninformed.org/?v=4&a=1&t=sumry>; дата обращения: 5 сентября 2006 г.

Wehnus. WehnTrust.

<http://www.wehnus.com/products.pl>; дата обращения: 5 сентября 2006 г.

Wikipedia. Matryoshka Doll.

<http://en.wikipedia.org/wiki/Matryoshka_doll>;

дата обращения: 18 сентября 2006 г.

Wine. CompilerExceptionSupport.

<http://wiki.winehq.org/CompilerExceptionSupport>;

дата обращения: 5 сентября 2006 г.

Аннотация: в этой статье описывается процесс реализации пользовательского энкодера для архитектуры x86. Чтобы задать контекст, в качестве примера уязвимости, требующей реализации специального энкодера, будет использоваться уязвимость ActiveX-компонента McAfee Subscription Manager, обнаруженная eEye. В частности, эта уязвимость не допускает использования символов верхнего регистра. Чтобы сделать задачу интереснее, энкодер, описанный в этой статье, также будет избегать всех символов выше 0x7f. Это сделает энкодер одновременно безопасным для UTF-8 и безопасным относительно tolower.

Задача: автор считает, что энкодер, безопасный для UTF-8 и tolower, скорее всего, можно реализовать намного более оптимально, с гораздо меньшими накладными расходами по размеру. Если у кого-либо из читателей есть идеи, как к этому подойти, автор будет рад письму. Дополнительная задача - найти технику geteip, которую можно использовать при таких ограничениях символов.

2. Введение

В августе eEye опубликовала уведомление об уязвимости переполнения стека в ActiveX-компоненте McAfee Subscription Manager. Причиной был небезопасный вызов vsprintf, доступный через вызываемые из сценария процедуры. На первый взгляд такое переполнение легко эксплуатировать, однако передаче полезной нагрузки и даже адреса возврата мешают ограничения допустимых символов. В статье на реальном примере McAfee Subscription Manager показана реализация собственного кодировщика, обходящего эти ограничения.

Сначала воспроизведём условия из уведомления. Обычно для проверки переполнения отправляют повторяющиеся байты, например A. Но здесь последовательность A (0x41) перезаписывает адрес возврата байтами 0x61, то есть строчными a. Следовательно, входная строка проходит через tolower, поэтому полезная нагрузка и адрес возврата не могут содержать символы верхнего регистра.

Для первоначальной демонстрации выполнения кода поместим сразу после адреса возврата несколько инструкций int3 с кодом операции 0xcc. Адрес возврата направим на push esp / ret или другую последовательность, передающую управление этим байтам. Казалось бы, отладчик должен остановиться на int3, но вместо этого он останавливается на другой инструкции:

Буфер явно подвергается дополнительному преобразованию: 0xcc + 0x20 = 0xec. Так же A (0x41) превращается в a (0x61). Значит, функция понижения регистра ошибочно прибавляет 0x20 и к части байтов расширенного диапазона ASCII.

На самом деле происходит следующее: компонент Subscription Manager вызывает mbslwr из статически слинкованной CRT на копии исходной входной строки. Внутри mbslwr вызывает crtLCMapStringA. В итоге это приводит к вызову kernel32!LCMapStringW. Второй параметр этой процедуры, dwMapFlags, описывает, какие преобразования, если они есть, должны быть выполнены над буфером. Процедура mbslwr передает 0x100, то есть LCMAP_LOWERCASE. Именно это и приводит к приведению строки к нижнему регистру.

Таким образом, нельзя использовать байты от 0x41 до 0x5a, а для простоты также 0xc0 и 0xe0. Это мешает многим существующим кодировщикам полезной нагрузки для x86, включая модули Metasploit: запрещённые байты встречаются и в декодирующей заглушке, и в закодированных данных. Поэтому потребуется собственный кодировщик.

Хотя уязвимость допускает многие байты выше 0x80, ограничимся приведённым ниже набором. Он одновременно совместим с UTF-8 и не изменяется функцией tolower. Нулевые байты кодировщик также исключает.

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

3. Реализация декодера

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

В допустимый набор входят полезные инструкции add, xor, push, pop и несколько вариантов jcc. Недоступную mov при необходимости можно заменить сочетанием push и pop. Декодирование выполняется в три этапа: определяется базовый адрес заглушки, закодированные данные восстанавливаются в исполняемую форму, затем управление передаётся полученной полезной нагрузке.

Общий подход таков: заголовок заглушки подготавливает состояние, затем последовательность четырёхбайтовых блоков преобразуется на месте, и выполнение продолжается с первого восстановленного байта.

3.1. Определение базового адреса заглушки

Большинству декодирующих заглушек сначала нужен код geteip, определяющий текущее значение указателя команд. Закодированные данные обычно расположены сразу после заглушки; зная собственный адрес, она может независимо от размещения вычислить их адрес. Ограничения набора символов заметно усложняют этот шаг.

На x86 значение указателя команд можно получить несколькими способами. Большинство использует call, но её коды операций 0xe8 и 0xff лежат в запрещённом расширенном диапазоне. Инструкция сопроцессора fnstenv также содержит недопустимый байт 0xd9. Ещё один вариант — зарегистрировать обработчик структурированных исключений и после исключения извлечь Eip из структуры CONTEXT. SkyLined реализовал для Windows полностью буквенно-цифровой вариант, но он использует запрещённые здесь заглавные символы.

Поскольку известные варианты geteip не подходят, базовый адрес придётся передать через регистр. Так работают и буквенно-цифровые кодировщики вроде Alpha2 от SkyLined. Заглушку уже нельзя без подготовки вставить в любой эксплойт: нужно найти регистр, указывающий на неё или на соседний адрес.

Автору неизвестна техника geteip, одновременно совместимая с семибитным диапазоном и tolower. Поэтому декодировщик предполагает, что ecx содержит адрес рядом с началом заглушки; вместо него можно использовать и другой регистр.

Получение базового адреса — лишь первая часть заголовка. Затем регистр нужно сдвинуть к первому закодированному блоку, прибавив длину самого заголовка и всех процедур преобразования.

Следующий дизассемблированный фрагмент показывает один вариант заголовка; предполагается, что ecx указывает на его начало:

Первые две инструкции вычисляют общую длину процедур декодирования: размер одной процедуры (0xb байт) умножается на их число (0x12 в примере), и результат 0xc6 сохраняется в edi. Одна процедура восстанавливает четыре исходных байта, поэтому этот вариант поддерживает полезную нагрузку длиной до 508 байт. Для большего объёма можно подобрать другие операнды imul.

После вычисления размера преобразований декодирования выполняется pusha, чтобы поместить регистр edi на вершину стека. Когда значение edi находится на вершине стека, его можно прибавить к регистру базового адреса ecx, тем самым учтя число байтов, занятых преобразованиями декодирования. Внимательный читатель может спросить, почему значение edi добавляется к ecx косвенно. Почему не прибавить его напрямую? Ответ, конечно, в плохих символах:

Нельзя и просто поместить edi в стек, поскольку инструкция push edi тоже содержит плохие символы:

Начиная с пятой инструкции к базовому адресу прибавляются длина заголовка и дополнительные смещения, после чего ecx указывает на закодированные данные. Нужное число помещается в стек и косвенно прибавляется к ecx через [esp].

После этого ecx указывает на начало закодированных данных. Последняя инструкция заголовка, push byte 0x4, подготавливает значение, которое процедуры декодирования будут использовать для перехода к следующему четырёхбайтовому блоку.

3.2. Преобразование закодированных данных

Главная часть декодировщика — восстановление исходных данных. Многие декодировщики Metasploit складывают закодированные блоки с ключом операцией xor, получая исходные байты полезной нагрузки. При заданных здесь ограничениях этот способ неприменим.

Чтобы преобразовать закодированные данные обратно в исходную форму, нужно уметь получить любой байт от 0x00 до 0xff с помощью любого числа комбинаций байтов из допустимого набора символов. Это означает, что декодер будет ограничен комбинациями символов из диапазонов 0x01-0x40 и 0x5b-0x7f. Чтобы найти лучший способ выполнить преобразование, разумно исследовать каждую полезную инструкцию, найденную ранее в этой главе.

Побитовые инструкции, такие как and, or и xor, не будут особенно полезны для этого декодера. Главная причина в том, что они не могут производить значения за пределами допустимых наборов символов без помощи инструкции битового сдвига. Например, невозможно применить побитовое and к двум ненулевым значениям из допустимого набора и получить 0x00. Хотя xor мог бы сделать это, примерно этим его возможности и ограничиваются, не считая получения других значений ниже границы 0x80. Эти ограничения делают побитовые инструкции непригодными.

Инструкция imul могла бы быть полезна, поскольку можно перемножить два символа из допустимого набора и получить значения вне допустимого набора. Например, умножение 0x02 на 0x7f дает 0xfe. Хотя этому можно найти применение, остаются две инструкции, которые на деле полезнее всего.

Инструкция add может использоваться для получения почти всех возможных символов. Однако она не может произвести несколько конкретных значений. Например, невозможно сложить два допустимых символа и получить 0x00. Также невозможно сложить два допустимых символа и получить 0xff или 0x01. Хотя это ограничение может создать впечатление, что инструкция add непригодна, ее спасает инструкция sub.

Как и add, инструкция sub способна производить почти все возможные символы. Она определенно способна производить значения, с которыми не справляется add. Например, она может получить 0x00, вычитая 0x02 из 0x02. Она также может получить 0xff, вычитая 0x03 из 0x02. Наконец, 0x01 можно получить вычитанием 0x02 из 0x03. Однако, как и у add, у sub тоже есть символы, которые она не может получить. К ним относятся 0x7f, 0x80 и 0x81.

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

Поэтому вместо цикла используется последовательность отдельных преобразований — по одному для каждого закодированного блока. Такой приём уже применялся в сходных условиях, но заметно увеличивает итоговый размер. Чтобы понять реализацию, обратимся к дизассемблированному коду.

Каждое преобразование устроено одинаково. Четырёхбайтовое значение помещается в стек и извлекается в edi, заменяя недоступную инструкцию mov. Затем оно прибавляется к соответствующему закодированному блоку либо вычитается из него; результат записывается на место исходных закодированных байтов. Значение 0x4, подготовленное заголовком на вершине стека, сдвигает указатель к следующему блоку.

Такое преобразование использует только допустимые байты, но на каждые четыре исходных байта добавляет 11 служебных. Кроме того, блок невозможно закодировать, если в нём одновременно встречаются байты, не подходящие для add (например 0x00) и для sub (например 0x80).

3.3. Передача управления декодированным данным

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

4. Реализация энкодера

Кодировщик выполняется на машине атакующего до эксплуатации цели. Он преобразует полезную нагрузку в допустимый формат и передаёт полученные данные цели. Уже там описанный выше декодировщик восстанавливает исходные байты и исполняет их.

Для статьи кодировщик реализован в Metasploit Framework 3.0 как модуль кодирования x86. В этой главе описано его устройство.

Сначала создаётся файл в каталоге modules/encoders/x86 и определяется загружаемый платформой класс. Ссылочное имя модуля образуется из имени файла: avoidutf8tolower.rb становится x86/avoidutf8tolower. Затем класс сообщает платформе сведения о модуле.

Класс помещается в пространство имён Msf::Encoders::X86, соответствующее расположению файла. Его имя может быть любым уникальным, но класс должен наследовать Msf::Encoder, который предоставляет необходимый интерфейс кодировщика.

На этом этапе определение класса должно выглядеть примерно так:

Затем конструктор передаёт базовому классу хеш info с именем, версией, авторами, типом кодировщика, размером блока и размером ключа. Для этого модуля конструктор выглядит так:

После шаблонной части остаётся переопределить несколько методов Metasploit Framework 3.0. Полный интерфейс описан в руководстве разработчика; здесь рассматриваются только методы, нужные этому кодировщику.

4.1. decoder_stub

Метод decoder_stub динамически создаёт заголовок декодирующей заглушки. Он возвращает буфер с машинным кодом, который настраивает выбранный регистр так, чтобы тот указывал на первый закодированный блок. Полная реализация выглядит так:

Длина исходного буфера из state.buf.length округляется вверх до четырёхбайтовой границы и делится на четыре. Необязательное значение BufferOffset, сохранённое в off, позволяет эксплойту учесть дополнительное смещение относительно ecx. По вычисленным длине и смещению создаётся и возвращается заголовок заглушки.

4.2. encode_block

Метод encode_block кодирует один блок и возвращает результат. Размер блока — четыре байта — задан в информационном хеше модуля. Реализация поочерёдно пытается подобрать преобразование через add или sub; выбор зависит от исходных байтов.

Первое, что пробует encode_block, - это add. Метод try_add реализован так:

Процедура try_add для каждого исходного байта ищет два допустимых случайных байта, сумма которых даёт нужное значение. Один становится частью 32-битного непосредственного операнда push в процедуре декодирования, второй — соответствующим байтом закодированного блока. После обработки всех четырёх байтов процедура декодирования возвращается платформе, а закодированный блок добавляется к накопленным данным.

Если любой байт блока, кодируемого try_add, равен 0x00, 0x01 или 0xff, процедура возвращает nil. Когда это происходит, encode_block пытается закодировать блок с помощью инструкции sub. Реализация try_sub показана ниже:

Процедура try_sub сложнее, потому что при вычитании 32-битных значений нужно учитывать заём между соседними байтами. Если исходный байт больше 0x80, вычисляется его дополнение до 0x100. Затем выбирается случайное y в допустимом диапазоне, а x вычисляется как 0x100 минус исходный байт и y, с учётом текущего флага займа. Рассмотрим пример.

Пусть исходный байт равен 0x84, а его дополнение до 0x100 — 0x7c. Допустим, выражение rand(0x80 - 0x7c - 1) + 1 выбрало y = 0x3. При нулевом флаге займа получится x = 0x7f; вычитание 0x7f из 0x3 по модулю 256 даёт 0x84.

Для байта меньше 0x80 вычисляется разница между 0x7f и исходным значением. Случайное x выбирается между единицей и этой разницей, а y равно сумме исходного байта, x и флага займа. Например, для 0x24 вычисления выглядят так.

Сначала разница между 0x7f и 0x24 равна 0x5b. Значение x могло бы быть 0x18, полученное из rand(0x5b - 1) + 1. Затем y вычислялось бы как 0x3c через 0x24 + 0x18. Следовательно, 0x3c - 0x18 дает 0x24.

С помощью этих двух методов вычисления отдельных байтовых значений можно закодировать любой байт, кроме 0x7f, 0x80 и 0x81. Если встречается любой из этих трех байтов, try_sub возвращает nil, и кодирование завершается ошибкой. В противном случае процедура завершается аналогично try_add. Однако вместо инструкции add она использует инструкцию sub.

4.3. encode_end

Последний переопределяемый метод — encode_end. Он дописывает state.context, где накоплены закодированные блоки, к state.encoded, уже содержащему заголовок и процедуры декодирования. В результате получается полная заглушка с данными.

После завершения кодирования результат может быть дизассемблирован примерно так:

5. Применение энкодера

Изначально этот энкодер понадобился, чтобы воспользоваться уязвимостью в ActiveX-компоненте McAfee Subscription Manager. Теперь, когда энкодер реализован, остается попробовать его и посмотреть, работает ли он. Для проверки против цели Windows XP SP0 буфер переполнения можно построить следующим образом.

Сначала нужно сгенерировать строку из 2972 случайных текстовых символов. За случайной строкой должен следовать адрес возврата. Пример допустимого адреса возврата для этой цели - 0x7605122f, расположение инструкции jmp esp в shell32.dll. Сразу после адреса возврата в буфере переполнения должна находиться серия из пяти инструкций:

Эта последовательность извлекает в ecx значение esp, сохранённое инструкцией pusha. Регистр ecx служит базовым адресом заглушки, но фактически указывает на восемь байт раньше нужного места. Поэтому кодировщику передаётся BufferOffset = 8. Сразу после пяти инструкций размещается закодированная полезная нагрузка:

Когда буфер переполнения готов, остается только запустить попытку эксплуатации, заставив машину перейти на вредоносный сайт:

6. Заключение

Статья показала реализацию собственного кодировщика x86, создающего полезную нагрузку, совместимую с UTF-8 и не изменяемую функцией tolower. Практическим примером стала уязвимость ActiveX-компонента McAfee Subscription Manager, запрещающая заглавные символы. Даже если читателю не придётся писать такой модуль самостоятельно, понимание этих приёмов важно для исследования эксплуатации уязвимостей.

A. Ссылки

eEye. McAfee Subscription Manager Stack Buffer Overflow.

<http://lists.grok.org.uk/pipermail/full-disclosure/2006-August/048565.html>;

дата обращения: 26 августа 2006 г.

Metasploit Staff. Metasploit 3.0 Developer's Guide.

<http://www.metasploit.com/projects/Framework/msf3/developers_guide.pdf>;

дата обращения: 26 августа 2006 г.

Spoonm. Recent Shellcode Developments.

<http://www.metasploit.com/confs/recon2005/recent_shellcode_developments-recon05.pdf>;

дата обращения: 26 августа 2006 г.

SkyLined. Alpha 2.

<http://www.edup.tudelft.nl/~bjwever/documentation_alpha2.html.php>;

дата обращения: 26 августа 2006 г.

Аннотация: в этой статье я раскрою обмен информацией в том, что можно отнести к одной из самых прибыльных схем, координируемых "организованной преступностью". Я подробно изложу сведения, полученные от третьего лица, напрямую вовлечённого во все аспекты рассматриваемой схемы. Я объясню происхождение этого рынка, а затем кратко опишу некоторые действия, которые эти люди стратегически выполняли, чтобы обеспечить себе успех. Наконец, я разберу реальные примеры того, как один человек может быть одновременно назван спамером, автором вредоносного ПО, взломщиком и предпринимателем, ставшим вором. Чтобы избежать юридических проблем и нежелательного внимания СМИ, я воздержусь от упоминания имён людей и компаний, вовлечённых в схемы, описанные в этой статье.

Отказ от ответственности: этот документ написан в образовательных целях, и я не могу нести ответственность за любые последствия опубликованной информации.

Благодарности: vax, Shannon и Katelynn.

2. Введение

Любому владельцу компьютера очевидно, что интернет серьёзно изменил мир вокруг нас. От бесчисленного множества профессий до всемирного открытого рынка - он радикально повлиял почти на всё. Не беспокойтесь, я не собираюсь утомлять вас ещё одной статьёй в духе "будущее будет выглядеть вот так...". За этим я лучше отправлю вас к замечательной книге Michio Kaku "Visions", которая поразительно точна, учитывая, что была написана в середине 90-х. Но зачем я повторяю очевидное? Чтобы сосредоточиться на не столь очевидном сегменте уже существующего рынка, развитого корпорацией, которая ранее подала заявление о банкротстве. Я расскажу, как она "изобрела заново" один конкретный рынок и как это изменение породило волну бедствий и жадности. Рынок - недвижимость, а мой фокус - ипотечные лиды.

Идея находить, продавать и красть лиды совсем не нова. Фактически Hollywood снял фильм, полностью построенный вокруг важности торговых лидов, - "Boiler Room" с Giovanni Ribisi, Ben Affleck и Vin Diesel. Этот фильм отлично показывает, насколько значимым может быть даже один крупный лид.

Я начну с объяснения, что такое ипотечные лиды, почему о них стоит писать статью и как некоторые люди заработали на них миллионы. Затем я обсужу роли связанных между собой участников и то, как они продолжают работать, когда доверие является единственной точкой отказа. Моё решение написать эту статью носит исключительно информационный характер: я не собираюсь разрушать жизни людей, которые зарабатывают на том, о чём я собираюсь рассказать. Насколько мне известно, это вообще не большой секрет, но я нашёл тему увлекательной и хочу поделиться своим опытом со всеми, кто готов слушать.

3. Наставление

Когда я рос, родители отговаривали меня работать во время учёбы. Они искренне старались дать мне поддержку, необходимую для того, чтобы я мог сосредоточиться исключительно на учёбе. Их логика была простой: как только ты начнёшь зарабатывать деньги, ты забудешь, что в жизни важно, и просто захочешь идти по этому пути. Пока вы читаете эту статью, спросите себя, насколько это на самом деле верно.

Финансовая выгода движет каждым рынком в мире, и, честно говоря, осталось очень мало вещей, которых мир в целом ещё не сделал ради денег. Чтобы прояснить убеждение моих родителей, я опишу, насколько жизнь вовлечённых людей отличается от той, которой они когда-то жили, и от жизни человека, работающего с девяти до пяти.

4. Сущность

Ипотечные лиды, далее просто лиды, - это не более чем выбранный набор сведений, состоящий из следующих полей:

• Имя

• Фамилия

• Телефон

• Город

• Штат

• Почтовый индекс

• Электронная почта

• Тип кредита

• Сумма кредита

• Идентификатор партнёра

• Ссылка на домен

• Дата

Чтобы лид имел какую-либо ценность для покупателя, он должен содержать как минимум перечисленные выше данные, возможно за исключением идентификатора партнёра и ссылки на домен. Более того, чем надёжнее набор лидов, тем больше он стоит покупателю. Покупателю? - спросите вы. Финансовые компании косвенно вовлечены в эту схему: они берут проданную им информацию и связываются с людьми, которые якобы заинтересованы в покупке дома, рефинансировании или подаче заявки на ипотечный кредит.

4.1. Предыстория

Чтобы полностью понять, кто продаёт собранную информацию и кто покупает перечисленные выше данные, я введу гипотетическую "Корпорацию A", которая будет играть роль реальной компании. Корпорация A - ипотечная компания в падении: она не только на грани закрытия, но уже подала заявление о банкротстве по главе 11 и исчерпала жизнеспособные варианты восстановления. В качестве последней меры она решает предлагать деньги в обмен на лиды возможных кандидатов на получение кредита. Это быстро набрало обороты, поскольку интернет оказался отличным местом для накопления такой информации. В итоге план рухнул, но прежде чем перейти к результатам, я объясню, как это действительно стало отдельным рынком.

4.2. Цифры

Изначально каждый сборщик в среднем продавал около 200 лидов за одну сделку, что давало ровно столько прибыли, сколько было нужно, чтобы удерживать компанию на плаву. Термин "сборщик" в этой статье в самом широком смысле означает человека, который собирает ипотечные лиды ради прибыли. Сначала один лид покупался по фиксированной ставке 10 долларов США; при среднем объёме 200 лидов за сделку сборщик получал комфортные 2 000 долларов США. С другой стороны, корпорация A успешно вела дела, получая в среднем около 10 продаж на каждые 100 купленных лидов. При таких показателях корпорация A получала около 10 000 долларов США прибыли с каждой успешной продажи. Небольшая арифметика показывает соотношение доходности инвестиций:

На основе сбора ничтожного объёма информации сборщики начали агрессивно изобретать новые методы сбора. Я вскоре объясню, что имею в виду. Пока сосредоточусь на том, что произошло сразу после этого.

Новые методы сбора вывели доставку лидов из-под контроля, и вскоре корпорация A была завалена таким количеством лидов, что ей пришлось начать отказываться от них, пока она не поняла, как обрабатывать такой объём. Чтобы справиться с количеством лидов, которое теперь поступало, компания решила сотрудничать с более мелкими компаниями и продавать им излишек. Корпорация A стала расти экспоненциально быстро, и примерно за пять-шесть лет эта простая идея вывела её из банкротства в многомиллиардную корпорацию. Ходили даже слухи, что в какой-то момент эта компания поглощала 100 процентов ипотечных лидов, когда-либо обработанных в США.

Люди и жадность плохо сочетаются, и, как я уже упоминал, сборщики и партнёры хотели больше денег. Поэтому вскоре другие компании тоже начали покупать лиды у сборщиков. Я утверждаю, что в то время ипотечная отрасль была достаточно большой, чтобы все могли хорошо на ней зарабатывать, однако жадные сборщики начали продавать фиктивные или неэксклюзивные лиды. Это вынудило ипотечные компании разработать свободную модель классификации качества лида в дополнение к классификации самих лидов.

• Эксклюзивный

Эксклюзивный лид - это лид, который продаётся только одной ипотечной компании и больше никогда не распространяется повторно. Ценность таких лидов часто была выше, чем у неэксклюзивных, или, как их решили назвать, полуэксклюзивных лидов.

• Полуэксклюзивный

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

Надёжность оптового набора оценивается человеком, который покупает его в момент продажи. Покупатель лидов берёт случайную выборку из получаемой партии и лично проверяет её действительность. Затем оценка выставляется в зависимости от количества пропущенных плохих лидов, которые он находит. У каждого контрагента шкала может отличаться, но вкратце лид считается зелёным только в том случае, если он подтверждён. Подтверждённый лид - это лид, который подтверждён самим человеком, чья информация была изначально продана, то есть кандидатом на ипотечную заявку, и по которому процесс проходит дальше. Жёлтый лид - это лид, в котором вся информация точна, но кандидат либо не был дома, либо по какой-то причине был недоступен. Наконец, красный лид - это подтверждённо недействительный или фиктивный лид. Плохой лид может выдать множество вещей: например, несоответствие почтового индекса и штата, либо имя John Doe при адресе на Elm Street, вероятно, указывают на плохой лид.

5. Война

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

5.1. Самостоятельный путь

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

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

5.2. Воровство

Воровство, очевидно, означает кражу, а чтобы красть, сборщик должен выбирать из множества целей. По сути, любой, кто строит собственную среду для сбора лидов, является возможной целью. Для сборщика, желающего найти больше целей, всё складывается довольно легко: вспомните, что сборщики используют рассыльщиков как ресурс для рекламы своих сайтов. Это вполне жизнеспособный метод сбора, однако существуют и альтернативные методы, а сборщики используют любые способы перечисления и поиска, какие только могут придумать. Сначала давайте углубимся в детали того, что должны сделать сборщики, желающие строить сайты, перед наймом рассыльщиков, поскольку это напрямую связано с перечислением целей.

5.3. Развёртывание инфраструктуры

Сборщик поднимает сервер для ипотечных заявок, а рассыльщики получают комиссию за привлечённые спамом лиды. Чтобы сайт работал круглосуточно и не закрывался из-за жалоб, используют так называемый неуязвимый для претензий хостинг: провайдер с крайне мягкими правилами, допускающий спам и почти любое содержимое. Такая услуга стоит около 2500 долларов в месяц. Более дешёвая альтернатива — бот-сеть, но заражённые узлы нестабильны; если сервер исчезнет в первую ночь оплаченной кампании, сборщик потеряет значительную часть вложений. Поэтому опытные участники предпочитают надёжный хостинг.

Поставщики неуязвимого для претензий хостинга и их диапазоны IP-адресов часто хорошо известны. Поэтому серверы ипотечных заявок можно искать простым сканированием подходящих сегментов. На таких узлах обычно открыты http, ssh, ftp, mysql, mssql и иногда административный веб-интерфейс. Чем больше трафика получает цель, тем больше времени атакующие готовы потратить; некоторые даже арендуют сервер в том же сетевом сегменте. Ниже перечислены обычные способы атаки.

• Перебор

Атакующий пытается угадать пары логина и пароля на любом из этих сервисов, а иногда и на всех сразу. Обычно такая атака не слишком скрытна, но помните: поводов для беспокойства немного. В конце концов, жертва ведь не может просто поднять телефон и позвонить своему адвокату, верно?

• SQL-инъекция

Если через сайт доступны какие-либо веб-интерфейсы, SQL-инъекции становятся ещё одним вектором входа. Хотя доля успешных SQL-инъекций сейчас относительно низка, всё ещё остаются лёгкие цели, и будьте уверены: достаточно жадный и амбициозный человек их найдёт.

• Классические атаки

Из-за огромного числа эксплойтов, ежедневно разрабатываемых и публикуемых для широкой аудитории, поиск и запуск атак является частым действием. Иногда это открывает новый рынок для авторов эксплойтов, желающих быстро заработать. Сборщики могут объявлять, что им нужен эксплойт, и назначать цену за конкретное приложение. Существуют даже онлайн-аукционы, построенные специально для этой цели.

• Пассивные и пассивно-агрессивные методы

Если удалённый взлом не удался, атакующий может арендовать машину в том же сегменте. Отравление таблиц ARP позволит перехватывать входящий трафик, перенаправлять клиентские запросы на свой узел или провести атаку посредника при входе жертвы и пассивно собрать учётные данные.

6. Ещё о деньгах

Рассыльщик распространяет рекламу, а сборщик платит ему за полученные лиды. Каждому рассыльщику назначается уникальный номер, который включается в ссылки и затем возвращается вместе с заявкой клиента. Так сборщик считает вклад каждого партнёра. Этот способ широко применяется в онлайн-индустриях, связанных со спамом и рекламой, включая поставщиков шпионского и рекламного ПО.

Один спам-прогон может достигать двух миллионов писем. Время, необходимое для выполнения такого большого прогона, зависит от нескольких ключевых факторов: используемого метода распространения и применяемого спам-софта. Если использовать достаточно большой список прокси, с помощью Dark Mailer можно отправлять в среднем около сорока тысяч писем за полчаса. Небольшая арифметика показывает, что передача двух миллионов писем заняла бы около двадцати пяти часов. Более того, если я возьму заниженную оценку и скажу, что 0.01 процента из двух миллионов писем одного спам-прогона действительно сработали, то отдача для сборщика на эксклюзивных лидах составит около 200 лидов на рассыльщика по 10 долларов за лид, то есть примерно 2 000 долларов США. Рассыльщики получают в среднем около 8 долларов за реферал и обычно могут отслеживать статистику через веб-интерфейс, наблюдая отдачу от вложенного времени в реальном времени.

7. Катастрофа

До сих пор я довольно подробно описывал структуру того, как некогда падающая корпорация развернулась на 180 градусов и снова поднялась на вершину. Однако слишком хорошо известно, что всё, что поднимается, должно упасть, причём вдвое быстрее, чем поднималось.

Суть проблем проявилась, когда рассыльщики начали подделывать содержание спама для своих сборщиков. Рассыльщики заметили, что чем более низкую ставку они рекламировали, тем больше трафика направляли на сайт сборщика. Больше трафика означало больше собранных лидов, что приносило больше денег. Знали ли рассыльщики о законах до того, как сделали то, что сделали, мне неизвестно, но их ложь привела к искам со всех сторон. Недовольные люди, которым обещали процентную ставку по кредиту в 1.9-2.5 процента, начали подавать иски против сборщиков. Это привело к довольно большой цепочке рассерженных партнёров. Иерархия ниже показывает возникшую волну бедствий.

8. Заключение

Справедливо сказать, что амбиции могут взять верх над людьми. Действительно, я уверен, что эти люди стараются извлечь прибыль из этого предприятия. К сожалению, это не самый подходящий способ зарабатывать на жизнь; однако он показывает, что их восприятие несколько отличается. Большинство из них считает, что, держась подальше от онлайн-продажи наркотиков и порнографии, они никому не вредят и просто используют хороший способ заработать деньги. Оглядываясь назад, я с этим согласен, но отказываюсь оправдывать спам по любой причине: он пожирает бесчисленные корпоративные человеко-часы и является обычной помехой для всех, кто получает электронную почту.

A. Ссылки

Spammer-X, "Inside the spam cartel." <http://www.oreilly.com/catalog/1932266860/>.

Boiler Room. <http://www.imdb.com/title/tt0181984/>.

Аннотация: Windows Vista x64 и недавно обновлённые исправлениями версии ядра Windows Server 2003 x64 содержат обновлённую версию технологии Microsoft, предназначенной для предотвращения модификации кода в режиме ядра и известной как PatchGuard. Эта новая версия PatchGuard улучшает предыдущую несколькими способами, главным образом пытаясь усложнить обход PatchGuard с точки зрения независимого поставщика ПО (ISV), развёртывающего драйвер, который модифицирует ядро. Набор возможностей PatchGuard версии 2 в остальном достаточно похож на PatchGuard версии 1: SSDT, IDT/GDT, различные MSR, несколько глобальных переменных ядра с указателями на функции, а также код ядра защищаются от несанкционированного изменения. В этой статье предлагается несколько методов, которые можно использовать для полного обхода PatchGuard версии 2. Также предлагаются возможные решения против этих методов обхода. Кроме того, статья описывает механизм, с помощью которого PatchGuard версии 2 можно подорвать так, чтобы он запускал пользовательский код вместо кода проверки целостности системы PatchGuard, не оставляя после подрыва PatchGuard следов модификации ядра или пользовательских драйверов ядра, загруженных в систему. Это особенно интересно с точки зрения использования защит PatchGuard для сокрытия кода режима ядра - цели, которая во многих отношениях полностью противоположна тому, для чего был разработан PatchGuard.

Благодарности: автор хотел бы поблагодарить skape, bugcheck и Alex Ionescu.

Отказ от ответственности: эта статья представлена в образовательных целях и ради расширения общедоступных знаний. Автор не может нести ответственность за возможное использование или злоупотребление сведениями, раскрытыми в этой статье. Хотя автор старался быть максимально внимательным к точности статьи, возможно, что в ней остались одна или несколько ошибок. Если будет обнаружена такая неточность или ошибка, автор будет признателен за уведомление, чтобы можно было внести соответствующие исправления.

2. Введение

В x64-версиях ядра Windows Microsoft попыталась занять жёсткую позицию [1] против использования определённого класса техник, которые в предыдущих версиях Windows часто применялись для "расширения" ядра потенциально небезопасными способами. Сюда относятся модификация самого ядра, перехват таблиц системных сервисов ядра, перенаправление обработчиков прерываний и несколько других, менее распространённых техник перехвата управления до того, как выполнение доходит до ядра, например изменение целевого MSR для системного вызова.

Технология, которую Microsoft применяет для предотвращения несанкционированной модификации ядра, исторически широко распространённой на x86, известна как PatchGuard. Она впервые была выпущена вместе с Windows Server 2003 x64 Edition и Windows XP x64 Edition; это была PatchGuard версии 1. x64-редакции Windows Vista и недавно обновлённые исправлениями версии ядра Windows Server 2003 x64 содержат более новую версию технологии PatchGuard, известную как PatchGuard версии 2. Новая версия создана для того, чтобы независимым поставщикам ПО (ISV) было значительно труднее развёртывать в полевых условиях решения, которые модифицируют ядро после отключения механизмов защиты ядра, предоставляемых PatchGuard. Внутренние детали самого PatchGuard в основном такие же, как в PatchGuard версии 1, и поэтому в этой статье подробно обсуждаться не будут, за исключением улучшенных технологий защиты от отладки и защиты от модификации в версии 2. Достаточно заинтересованный читатель, которому нужны вводные сведения по теме, может узнать больше о работе PatchGuard версии 1 из предыдущей статьи Uninformed [2], "Bypassing PatchGuard on Windows x64".

PatchGuard версии 2 берёт исходный выпуск PatchGuard и пытается закрыть различные дыры в его основанной на обфускации системе защиты от модификации. В этом отношении результат смешанный: есть и успехи, и неудачи. Хотя новая версия PatchGuard на первый взгляд отключает большинство техник обхода, предложенных [2] как способы отключить исходный выпуск PatchGuard, по крайней мере несколько этих техник можно довольно тривиально снова включить небольшими изменениями или дополнительным новым кодом. Более того, PatchGuard версии 2 всё ещё можно обойти без опоры на опасные конструкции, специфичные для конкретной версии, такие как жёстко заданные смещения или снятие отпечатков часто меняющегося кода. Помимо техник, основанных на отключении самого PatchGuard, существует несколько потенциальных механизмов обхода с хорошими шансами оставаться совместимыми с будущими версиями, потому что они вообще не дают PatchGuard обнаружить несанкционированные изменения ядра и тем самым изолируют себя от основанных на обфускации изменений в том, как вызывается проверка целостности системы PatchGuard. К чести Microsoft, устойчивость PatchGuard к отладке и анализу была существенно улучшена, по крайней мере в отношении некоторых ключевых этапов, например инициализации во время загрузки.

3. Примечательные механизмы защиты

PatchGuard версии 2 реализует ряд механизмов защиты от отладки, защиты от анализа и обфускации, которые стоит рассмотреть. В этой статье подробно рассматриваются не все защиты PatchGuard; механизмы вроде обфускации внутренних структур данных PatchGuard, которые по крайней мере в принципе совпадают с предыдущим выпуском PatchGuard и уже раскрыты в предыдущей статье Uninformed [2], здесь также не разбираются.

3.1. Антиотладочный код во время инициализации

Тем не менее в механизмах защиты PatchGuard всё ещё есть несколько интересных вещей для изучения. Многие из этих техник сами по себе заслуживают обсуждения просто с точки зрения их ценности как общих механизмов защиты от отладки и анализа. PatchGuard версии 2 начинается как добавление к процедуре nt!SepAdtInitializePrivilegeAuditing в ядре; PatchGuard версии 2 продолжает тактику вводящих в заблуждение и/или фиктивных имён функций, введённую PatchGuard версии 1. Эта процедура отвечает за основную инициализацию PatchGuard, включая настройку зашифрованных контекстных структур PatchGuard. В отличие от PatchGuard версии 1, процедура инициализации усеяна инструкциями, предназначенными для затруднения отладки, например следующей конструкцией, которая входит в бесконечный цикл, если подключён отладчик. Эта конкретная конструкция используется во многих местах во время инициализации PatchGuard:

Этот конкретный подход в текущей реализации PatchGuard версии 2 не особенно надёжен. Всё ещё относительно легко заранее обнаружить обращения к nt!KdDebuggerNotPresent и отключить их. Если бы Microsoft решила при каждом появлении такой конструкции творчески повреждать контекст выполнения, например обнуляя некоторые регистры или иначе подготавливая отказ значительно позже, если отладчик подключён, а уже затем входить в бесконечный цикл, такие конструкции могли бы быть немного эффективнее как защита от отладки.

Другие конструкции включают сильно обфусцированный выбор случайного набора фиктивных тегов пула, используемых для выделения структур данных PatchGuard. Как и PatchGuard версии 1, PatchGuard версии 2 использует случайно выбранный фиктивный тег пула и случайно скорректированные размеры выделений, пытаясь затруднить простое обнаружение контекста PatchGuard в памяти через сканирование выделений пула. Ниже приведён пример одного из участков кода, который PatchGuard использует для случайного выбора тега пула и случайной добавки к размеру выделения из списка возможных тегов пула. Фактический размер выделения равен случайной добавке плюс минимальный размер контекстной структуры PatchGuard и ограничивается 2048 байтами. Здесь инструкция rdtsc используется для генерации случайных чисел. Читатели, изучавшие предыдущую статью [2] о PatchGuard, могут узнать эту конструкцию генерации случайных чисел; она используется по всему PatchGuard везде, где требуется случайная величина.

3.2. Расширенный набор DPC-процедур

Другие механизмы защиты, используемые в PatchGuard версии 2, включают расширенный набор DPC-процедур, которые применяются для организации выполнения процедуры проверки целостности PatchGuard. Напомним, что в PatchGuard версии 1 существовал набор из трёх возможных DPC-процедур. В PatchGuard версии 2 этот набор потенциальных DPC-процедур, которые можно перепрофилировать для использования PatchGuard, расширен до десяти вариантов. Одна DPC-процедура выбирается из этих десяти во время загрузки и затем используется для всех дальнейших операций PatchGuard в течение жизни сеанса. Тот факт, что в конкретном сеансе Windows используется только одна DPC-процедура, является слабостью, унаследованной от предыдущей версии PatchGuard; как читатель позже увидит, это оказывается полезным, если цель состоит в обходе PatchGuard. DPC-процедура для текущего загрузочного сеанса выбирается в nt!SepAdtInitializePrivilegeAuditing примерно так же, как фиктивный тег пула для всех выделений PatchGuard:

Как и в PatchGuard версии 1, каждая DPC, выбранная для запуска проверок целостности PatchGuard, имеет легитимную функцию. Более того, DPC-процедуры важны для нормальной работы системы, поэтому нельзя просто обнаружить все DPC, которые ссылаются на эти процедуры, и отменить их. Вместо этого, как и в PatchGuard версии 1, если кто-то хочет пойти путём блокировки DPC PatchGuard, необходимо разработать механизм, который обнаруживает конкретную DPC PatchGuard, а не легитимные системные вызовы той же процедуры. Этот аспект механизмов обфускации PatchGuard относительно похож на версию 1, за исключением логического расширения до десяти DPC вместо трёх.

3.3. Саморасшифровывающаяся и мутирующая процедура проверки целостности системы

PatchGuard версии 2 также наследует от версии 1 способность шифровать свои структуры данных и исполняемый код в памяти. Это защитный механизм, призванный затруднить атакующему классический поиск по заранее известной сигнатуре, при котором атакующий заранее подбирает узнаваемую сигнатуру структур данных PatchGuard и затем использует её для исчерпывающего сканирования памяти невыгружаемого пула. С этой точки зрения обфускация и шифрование динамически выделяемого кода и структур данных PatchGuard всё ещё остаются достаточно сильным защитным механизмом. К несчастью для Microsoft, часть структур, указывающих на PatchGuard, является внутренними системными структурами, такими как KDPC и связанный с ним KTIMER, используемые для запуска исполнения PatchGuard. Это создаёт слабое место, которое потенциально можно использовать для обнаружения структур PatchGuard в памяти. Позже этот вопрос будет рассмотрен подробнее.

Шифрование внутренних контекстных структур PatchGuard было разобрано в исходной статье Uninformed [2] на эту тему. Однако механизм, с помощью которого PatchGuard обфусцирует свои процедуры проверки и валидации целостности системы, тогда не обсуждался. Этот механизм достаточно интересен, чтобы объяснить его отдельно. Техника, используемая для обфускации исполняемого кода PatchGuard в памяти, включает два слоя функций расшифровки и деобфускации, каждый из которых расшифровывает следующий слой. После прохождения обоих слоёв процедуры валидации PatchGuard оказываются в памяти в открытом виде и затем выполняются напрямую.

Первый слой расшифровки - это блок кода, вызываемый из перепрофилированной DPC-процедуры, выбранной PatchGuard во время загрузки. Его задача состоит в том, чтобы расшифровать самого себя: по 8 байт за раз, начиная со второй инструкции функции. Когда расшифровка этого блока кода завершается, дешифрующая заглушка продолжает работу и расшифровывает второй блок кода, то есть фактическую процедуру проверки PatchGuard. После завершения второго цикла расшифровки и деобфускации заглушка выполняет настоящую процедуру проверки целостности системы PatchGuard.

Как было отмечено выше, первая задача дешифрующей заглушки - расшифровать саму себя. За исключением первой инструкции заглушки, при входе вся процедура зашифрована. Первая инструкция шифрует саму себя и расшифровывает следующую инструкцию. Следующая инструкция расшифровывает следующие две инструкции, и так далее. Это достигается серией инструкций длиной четыре байта, которые выполняют xor восьмибайтового значения с ключом расшифровки. Изначально адресация начинается с текущего указателя инструкций; в этом примере rcx и rip всегда имеют одно и то же значение. Ниже показано, как работает этот процесс:

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

3.4. Обфускация вызовов проверки целостности системы через Structured Exception Handling

Как и PatchGuard версии 1, эта версия PatchGuard использует поддержку structured exception handling (SEH) как неотъемлемую часть процесса, запускающего выполнение процедуры проверки целостности системы. Способ, которым это достигается, несколько изменился по сравнению с предыдущей версией PatchGuard. В частности, в каждой DPC PatchGuard есть несколько слоёв обфускации, скрывающих фактический вызов процедуры проверки целостности. Чтобы усложнить жизнь потенциальным атакующим, точные детали используемой обфускации различаются для каждой из десяти DPC-процедур, которые могут быть перепрофилированы для PatchGuard. Однако все они имеют общую схему, которую можно описать на высоком уровне.

Первый шаг вызова процедуры проверки целостности системы PatchGuard - это KTIMER, с которым связан KDPC, то есть обратный вызов DPC, вызываемый при срабатывании таймера. Этот таймер подготавливается к однократному выполнению через интервал порядка нескольких минут. К интервалу добавляется случайный разброс, чтобы усложнить классическую атаку поиска по заранее известной сигнатуре, пытающуюся найти KTIMER в невыгружаемом пуле. DPC-процедура, указанная в KDPC, связанном с KTIMER PatchGuard, выбирается из набора десяти легитимных DPC-процедур, которые могут быть перепрофилированы для PatchGuard. Отличие именно этого вызова DPC-процедуры от легитимного системного вызова той же процедуры обеспечивается тем, что одним из аргументов DPC-процедуры передаётся заведомо некорректный указатель ядра.

Прототип DPC-процедуры описывается типом PKDEFERRED_ROUTINE:

По сути, DPC - это процедура обратного вызова с набором пользовательских контекстных параметров, интерпретация которых полностью остаётся на усмотрение самой DPC-процедуры. Стандартный способ использования контекстных аргументов в функциях обратного вызова состоит в том, чтобы указывать ими на более крупную структуру, содержащую сведения, необходимые процедуре обратного вызова для работы. Именно так десять DPC-процедур, которые может использовать PatchGuard, относятся к аргументу DeferredContext при легитимном исполнении. Это использование DeferredContext и позволяет PatchGuard запускать своё исполнение для каждой из десяти DPC-процедур через исключение: PatchGuard организует передачу фиктивного значения DeferredContext при вызове DPC-процедуры. Когда DPC-процедура впервые пытается разыменовать структуру, специфичную для DPC, на которую якобы указывает DeferredContext, возникает исключение. Оно передаёт управление системе диспетчеризации исключений, а в итоге - процедуре проверки целостности PatchGuard.

На первый взгляд это может показаться простым, но если читатель знаком с программированием в режиме ядра, в таком описании должны сразу появиться тревожные признаки. Обычно невозможно перехватывать ошибочные обращения к памяти на DISPATCH_LEVEL или выше с помощью SEH; как правило, будет вызвана одна из аварийных остановок: PAGE_FAULT_IN_NON_PAGED_AREA или IRQL_NOT_LESS_OR_EQUAL, в зависимости от того, относилось ли ошибочное обращение к зарезервированной невыгружаемой области или к выгружаемой памяти. В результате можно было бы ожидать, что PatchGuard подвергает систему риску случайной аварийной остановки, передавая фиктивные указатели, которые разыменовываются на DISPATCH_LEVEL, то есть на IRQL, где работают DPC-процедуры.

Однако у PatchGuard есть несколько приёмов. Он использует зависящую от реализации особенность текущего поколения x64-процессоров AMD, чтобы формировать адреса режима ядра, которые являются фиктивными, но при обращении не вызывают страничную ошибку. Вместо этого такие фиктивные адреса приводят к исключению общей защиты, которое в итоге проявляется как SEH-исключение STATUS_ACCESS_VIOLATION. Этот путь генерации STATUS_ACCESS_VIOLATION действительно работает даже на DISPATCH_LEVEL, что позволяет PatchGuard безопасно передавать фиктивные значения указателя для DeferredContext и запускать диспетчеризацию SEH без риска немедленно обрушить систему аварийной остановкой.

Конкретная особенность реализации, на которую опирается PatchGuard, связана с ограничением 48-битного адресного пространства в семействе процессоров AMD Hammer [4]. Современные процессоры AMD реализуют только 48 бит из 64-битного адресного пространства, представленного архитектурой x64. Это достигается требованием, чтобы биты с 63-го до старшего реализованного процессором бита любого адреса были установлены либо все в единицы, либо все в нули. Адрес такой формы называется каноническим адресом, или корректно сформированным адресом. Попытки обратиться к адресам, которые не являются каноническими по этому определению, приводят к немедленной генерации исключения общей защиты процессором. Это ограничение фактически делит используемое адресное пространство на две половины: одну область в верхней части адресного пространства и одну область в нижней, с "ничейной землёй" между ними. Windows использует это разделение для отделения пользовательского режима от режима ядра: верхняя часть адресного пространства резервируется для режима ядра, нижняя - для пользовательского режима. PatchGuard использует эту навязанную процессором "ничейную землю", чтобы создавать фиктивные значения указателей, которые можно безопасно разыменовать и поймать через SEH даже на высоких IRQL.

Все DPC-процедуры из набора, который может быть перепрофилирован PatchGuard, разыменовывают аргумент DeferredContext как первую часть работы, не считая перекладывания переменных стека. Иными словами, первая реальная работа любой DPC-процедуры, совместимой с PatchGuard, состоит в обращении к структуре или переменной, на которую указывает DeferredContext. На пути исполнения, где PatchGuard пытается запустить проверку целостности системы, аргумент DeferredContext недействителен, что в итоге приводит к исключению нарушения доступа, направляемому к SEH-регистрациям DPC-процедуры. Если изучить любую из DPC-процедур PatchGuard, видно, что все они имеют несколько перекрывающихся SEH-регистраций; обычно такая конструкция указывает на несколько уровней вложенных try/except и try/finally:

Эти SEH-регистрации являются важной частью работы проверок целостности системы PatchGuard. Точные детали работы каждой регистрации обработчика различаются для каждой DPC-процедуры, что сделано для затруднения обратного инжиниринга, но общая идея состоит в том, что каждый зарегистрированный обработчик выполняет часть работы, необходимой для подготовки вызова процедуры проверки целостности PatchGuard. Эта работа разделена между четырьмя разными обработчиками исключений/раскрутки, чтобы усложнить понимание происходящего, но конечный результат у каждой из DPC-процедур один: один из обработчиков исключений/раскрутки в итоге напрямую вызывает находящуюся в памяти дешифрующую заглушку проверки целостности системы. Заглушка расшифровывает себя, затем проверочную процедуру PatchGuard и передаёт ей управление, чтобы PatchGuard мог проверить различные защищённые регистры, MSR и образы ядра, например само ядро, на несанкционированные изменения.

Кроме того, все DPC PatchGuard были дополнены обфускацией аргументов DPC-процедуры в переменных стека. Точные смещения на стеке различаются от одной DPC-процедуры к другой, а также между разными вариантами ядра; например, многопроцессорные и однопроцессорные сборки ядра имеют разную компоновку стекового кадра для многих DPC-процедур PatchGuard. Напомним, что в x64-соглашении о вызовах первые четыре аргумента передаются через регистры rcx, rdx, r8 и r9. Каждая DPC-процедура PatchGuard специально сохраняет важные регистровые аргументы на стек в обфусцированном виде. Несколько аргументов остаются обфусцированными почти до самого вызова дешифрующей заглушки процедуры проверки целостности системы. Это затрудняет третьим сторонам модификацию середины конкретной DPC-процедуры с лёгким доступом к исходным аргументам DPC. Предположительно это сделано, чтобы сложнее было отличать вызовы DPC, выполняющие легитимную функцию процедуры, от вызовов DPC, которые вызовут PatchGuard. Это также усложняет, хотя и не делает невозможным, обобщённое восстановление исходных аргументов DPC-процедуры из контекста любого обработчика исключений, зарегистрированного для DPC-процедуры.

Эту обфускацию аргументов легко увидеть, дизассемблировав любую из DPC-процедур PatchGuard. Например, в ExpTimeRefreshDpcRoutine видно, что процедура сохраняет аргументы Dpc (rcx) и DeferredContext (rdx) на стек, вращает их на магическую константу (эта константа отличается для каждой разновидности DPC-процедуры и дополнительно усложняет обобщённое восстановление исходных DPC-аргументов), а затем затирает исходные регистры аргументов:

В этот момент необходимо исследовать различные обработчики исключений/раскрутки, зарегистрированные для DPC-процедуры, чтобы определить, что происходит дальше. Большую часть этих обработчиков можно пропустить: они представляют собой лишь небольшие слои обфускации, которые заметно отличаются между DPC-процедурами, но приводят к одному и тому же результату. Однако один из обработчиков исключений/раскрутки выполняет вызов проверки целостности PatchGuard, и именно он заслуживает более подробного обсуждения. Поскольку регистрации исключений для всех DPC-процедур PatchGuard используют nt!_C_specific_handler, обработчики области видимости соответствуют стандартному прототипу, определённому ниже:

В случае nt!ExpTimeRefreshDpcRoutine четвёртая регистрация обработчика области видимости выполняет вызов процедуры проверки целостности PatchGuard. Здесь процедура выполняет проверку целостности только если переменная состояния, сохранённая в [rsp+20h] в DPC-процедуре, установлена в определённое значение. Эта переменная состояния изменяется по мере того, как исключение нарушения доступа проходит через каждый из обработчиков области видимости для исключений/раскрутки, пока не добирается до данного обработчика, что в итоге приводит к исполнению проверки целостности системы PatchGuard. Пока что проще считать, что эта процедура вызывается с [rsp+20h] в DPC-процедуре, установленным в значение, отличное от 0x15. Это означает, что PatchGuard должен быть выполнен.

Это действительно значительный уровень обфускации, но он не является непреодолимым. Существует несколько простых способов, с помощью которых атакующий может полностью обойти все эти слои.

3.5. Нарушение точек останова на базе регистров отладки

PatchGuard версии 2 пытается защитить себя от точек останова, установленных с помощью аппаратных регистров отладки. Такие точки останова работают через настройку до четырёх интересующих адресов памяти. Каждую такую область памяти можно настроить так, чтобы она вызывала отладочное исключение при чтении, записи или исполнении. Поскольку точки останова такого типа не видны проверкам целостности кода PatchGuard, в отличие от обычных точек останова, где целевые инструкции заменяются опкодами int 3 (0xcc), точки останова на основе регистров отладки, иногда называемые точками останова памяти или аппаратными точками останова, представляют угрозу для PatchGuard. PatchGuard пытается противостоять этой угрозе, отключая все такие точки останова на основе регистров отладки как первый шаг после расшифровки процедуры проверки целостности системы в памяти:

3.6. Вводящие в заблуждение имена символов

Один из факторов, который Microsoft нужно было учитывать при реализации PatchGuard, состоит в том, что потенциальные атакующие имеют доступ к символам операционной системы. В качестве помощи при отладке Microsoft публично предоставляет символы для всей операционной системы. Убрать символы операционной системы из публичного доступа практически невозможно: это серьёзно помешало бы ISV при отладке собственных драйверов. Поэтому Microsoft пошла путём использования вводящих в заблуждение имён функций, чтобы скрыть процедуры PatchGuard от поверхностного просмотра. Многие внутренние процедуры PatchGuard имеют имена, которые на первый взгляд звучат вполне легитимно; без глубокого знания ядра или фактической проверки этих процедур было бы трудно просто посмотреть на список всех символов в ядре и найти процедуры, отвечающие за настройку PatchGuard.

Ниже приведён список некоторых вводящих в заблуждение символов, используемых во время инициализации PatchGuard:

1. RtlpDeleteFunctionTable

2. FsRtlMdlReadCompleteDevEx

3. RtlLookupFunctionEntryEx

4. SdbpCheckDll

5. FsRtlUninitializeSmallMcb

6. KiNoDebugRoutine

7. SepAdtInitializePrivilegeAuditing

8. KiFilterFiberContext

3.7. Проверки целостности во время инициализации системы

Во время инициализации системы PatchGuard выполняет проверки целостности нескольких своих антиотладочных механизмов. Если эти механизмы изменены на диске, PatchGuard обнаружит изменения. Например, PatchGuard проверяет, что процедура, отвечающая за очистку точек останова на основе регистров отладки, содержит правильные байты опкодов, соответствующие инструкциям, которые фактически обнуляют Dr7:

3.8. Перезапись кода инициализации PatchGuard после загрузки

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

После загрузки многие процедуры, связанные с PatchGuard, содержат одни нули:

Большая часть кода инициализации PatchGuard находится в секции INITKDBG файла ntoskrnl. Части этой секции обнуляются во время инициализации.

4. Техники обхода

Несмотря на множество техник защиты от обратного инжиниринга и отладки, применяемых PatchGuard версии 2, его вряд ли можно назвать неуязвимым для обхода сторонним кодом. Вопреки тому, чего можно было бы ожидать после описаний в начальной части этой статьи, в броне PatchGuard есть несколько дыр, которые может использовать стороннее ПО. Ниже описано несколько потенциальных техник обхода PatchGuard версии 2, включая одну технику с рабочим кодом подтверждения концепции. Эти техники применимы к версии PatchGuard, которая на момент написания статьи поставлялась с Windows XP x64 Edition со всеми исправлениями, Windows Server 2003 x64 Edition со всеми исправлениями и Windows Vista x64 со всеми исправлениями. Автор написал полную реализацию только первой предложенной техники обхода, хотя предполагается, что остальные предложенные подходы к обходу в принципе жизнеспособны.

4.1. Перехват _C_specific_handler

Самый простой путь отключения PatchGuard версии 2, по мнению автора, состоит в перехвате выполнения на _C_specific_handler. Процедура _C_specific_handler отвечает за диспетчеризацию исключений для процедур, скомпилированных компилятором Microsoft C/C++ и использующих блоки try/except, try/finally или try/catch. В этот набор функций входят все десять DPC-процедур PatchGuard и большинство других C/C++ функций в ядре. Туда же входят многие процедуры сторонних драйверов: _C_specific_handler экспортируется, и компилятор ссылается на эту функцию для всех C/C++ образов, которые в какой-либо форме используют SEH, импортируя её из ntoskrnl. Из-за этого Microsoft вынуждена постоянно экспортировать _C_specific_handler из ядра, что затрудняет запрет доступа к адресу этой процедуры с точки зрения сторонних драйверов. Более того, поскольку _C_specific_handler экспортируется из ядра, получить её адрес во всех версиях ядра из контекста стороннего драйвера тривиально. Этот подход использует тот факт, что PatchGuard применяет SEH для обфускации вызова процедуры проверки целостности системы, фактически превращая этот механизм обфускации в удобный способ перехватить управление выполнением до того, как проверка целостности системы действительно будет выполнена.

Этот подход можно реализовать несколькими разными способами, но базовая идея состоит в том, чтобы перехватить выполнение где-то между инструкцией, вызвавшей исключение в DPC PatchGuard, выбранной во время загрузки, и обработчиками исключений, связанными с DPC-процедурой, которые вызывают процедуру проверки целостности системы PatchGuard. С этой точки зрения _C_specific_handler даёт именно то, на что можно было бы надеяться: _C_specific_handler вызывается, когда возникает безвредное нарушение доступа, спровоцированное фиктивным значением DeferredContext для DPC-процедуры PatchGuard. Кроме того, поскольку процедура экспортируется, нет проблем совместимости с будущими версиями ядра или разными вариантами ядра, такими как PAE против non-PAE, MP против UP и так далее.

Хотя перехват _C_specific_handler даёт удобный способ получить управление на пути выполнения проверочной процедуры PatchGuard, остаётся проблема: как безопасно обезвредить проверочную процедуру и возобновить выполнение в безопасной точке, чтобы система продолжала своевременно обрабатывать DPC. На x86 это создало бы серьёзную проблему, поскольку в таком контексте мы, как атакующий, пытающийся обойти PatchGuard, получили бы управление в обработчике исключений с записью контекста, описывающей состояние в середине DPC-процедуры PatchGuard, без хорошего способа раскрутить контекст обратно к вызывающему коду DPC-процедуры, то есть к диспетчеру DPC таймера ядра.

Иронично, но именно потому, что это происходит только на x64, а не на x86, проблема становится тривиальной там, где на x86 её было бы трудно решить обобщённым способом. Конкретно, в Windows в основу соглашения о вызовах x64 встроена обширная поддержка раскрутки стека, так что существуют метаданные, описывающие, как раскрутить любую функцию, которая манипулирует стеком в любой момент своей жизни выполнения. Эти метаданные используются для реализации семантики раскрутки, позволяющей чисто раскручивать функции без необходимости вызывать обработчики исключений/раскрутки, реализованные в коде и зависящие от контекста выполнения связанной с ними процедуры. Эти обширные метаданные раскрутки можно использовать здесь в нашу пользу, поскольку они дают чистый механизм раскрутки за пределы DPC-процедуры, к диспетчеру DPC, полностью совместимым и независимым от версии ядра способом. Более того, у Microsoft нет хорошего способа отключить эти метаданные раскрутки, учитывая, насколько глубоко они связаны с соглашением о вызовах x64.

Процесс использования метаданных раскрутки функции для раскрутки контекста выполнения известен как виртуальная раскрутка, и для реализации этого механизма существует документированная экспортируемая процедура [5]: RtlVirtualUnwind. С помощью RtlVirtualUnwind можно изменить контекст выполнения, передаваемый как аргумент в _C_specific_handler, а значит и в перехват _C_specific_handler. Этот контекст выполнения описывает состояние машины в момент нарушения доступа в DPC-процедуре PatchGuard. После выполнения виртуальной раскрутки над этим контекстом остаётся только вернуть именованную константу ExceptionContinueExecution в диспетчер исключений режима ядра, чтобы материализовать изменённый контекст. Это полностью обходит проверку целостности системы PatchGuard. Дополнительный бонус состоит в том, что перехват _C_specific_handler нужен только до первого вызова PatchGuard. Причина в том, что таймер PatchGuard является одноразовым, а поскольку код повторной постановки таймера в очередь пропускается виртуальной раскруткой, PatchGuard фактически навсегда отключается до конца текущего загрузочного сеанса Windows.

Последнее оставшееся препятствие для этой техники обхода - отфильтровать конкретные исключения нарушения доступа PatchGuard от легитимных нарушений доступа, которые может производить код режима ядра. Это важно, поскольку нарушения доступа в режиме ядра являются нормальной частью валидации параметров, то есть модели проверки и закрепления, используемой для проверки указателей пользовательского режима драйверами и системными сервисами. К счастью, такое различение сделать легко, поскольку обычно из режима ядра разрешено использовать try/except только для перехвата нарушения доступа, относящегося к адресу пользовательского режима, как уже описывалось ранее. PatchGuard является редким исключением из этого правила: у него есть хорошо определённая область "ничейной земли", где можно пытаться выполнять обращения без риска аварийной остановки системы. Поэтому безопасно предположить, что любое нарушение доступа, связанное с адресом режима ядра, является либо запуском собственного выполнения PatchGuard, либо очень плохо ведущим себя сторонним драйвером, грубо нарушающим правила для драйверов режима ядра Windows. По мнению автора, второй случай не стоит рассматривать как блокирующий фактор, особенно потому, что если бы такой полностью сломанный драйвер существовал, он уже случайным образом обрушивал бы систему аварийной остановкой. В качестве дополнения стоит отметить, что адрес, на который ссылается блок информации об исключении, переданный обработчику исключения, всегда будет 0xFFFFFFFFFFFFFFFF из-за того, как процессор сообщает нарушения на неканонических адресах. Однако это не влияет на жизнеспособность этой техники как корректного способа обойти PatchGuard независимым от версии способом.

Стоит отметить, что тот факт, что эта техника включает модификацию ядра, не является проблемой, если не считать внутренне присущих состояний гонки при безопасной модификации работающего бинарного кода. Перехват отключит PatchGuard до того, как PatchGuard получит шанс заметить этот перехват из контекста процедуры проверки целостности системы.

У этого предложенного подхода есть несколько преимуществ перед подходом, ранее предложенным в исходной статье Uninformed о PatchGuard [2]. В частности, он не требует находить каждую отдельную DPC-процедуру и вообще не опирается на снятие отпечатков кода: используются только экспортируемые символы. Это повышает как надёжность предлагаемого подхода, поскольку снятие отпечатков кода всегда добавляет дополнительную вероятность ложных срабатываний, так и его устойчивость к противодействию со стороны Microsoft. Поскольку эта техника опирается исключительно на экспортируемые функции и не зависит ни от количества возможных DPC, доступных PatchGuard, ни от их поиска во время выполнения, заблокировать такой подход было бы значительно сложнее, чем просто добавить ещё одну возможную DPC-процедуру или изменить атрибуты существующей DPC-процедуры, чтобы помешать сторонним драйверам, которые используют сигнатурный подход к поиску DPC-процедур для модификации.

Хотя эта техника достаточно устойчива к изменениям ядра, которые напрямую не затрагивают базовые механизмы работы самого PatchGuard, что подтверждается её способностью работать без изменений и на Windows Server 2003 x64, и на Windows Vista x64, у Microsoft есть несколько разных способов заблокировать эту атаку в будущем обновлении PatchGuard. Самое очевидное решение - полностью отказаться от SEH как базового механизма, участвующего в организации проверки целостности системы PatchGuard. Отказ от SEH убирает удобный механизм, то есть перехват _C_specific_handler, который здесь представлен как независимый от версии способ встроиться в путь выполнения проверки целостности системы PatchGuard. Если Microsoft пойдёт этим путём, потенциальному атакующему придётся разработать другой механизм получения управления выполнением до запуска проверки целостности системы. Если предположить, что Microsoft правильно разыграет свои карты, будущая редакция PatchGuard не будет иметь столь легко доступного механизма для универсального перехвата процесса выполнения, что в значительной степени нейтрализует предложенный подход. Microsoft также могла бы использовать какую-либо предварительную валидацию пути обработчика исключений до того, как DPC вызывает исключение, хотя, учитывая, что это не самый простой и элегантный способ противодействовать такой технике, автор считает такое решение маловероятным.

4.2. Перехват регистрации исключений DPC

В настоящее время все пути выполнения, ведущие к запуску DPC-процедур PatchGuard, включают обработчик исключений/раскрутки. Это ещё одна слабость типа единой точки отказа, которую могут использовать сторонние разработчики, пытающиеся отключить PatchGuard. В качестве ещё одного способа победить PatchGuard предлагается подход, включающий обнаружение всех DPC-процедур PatchGuard с последующим перехватом регистраций обработчиков исключений для каждой DPC.

Хотя эта техника не так чиста и прямолинейна, как техника, предложенная в 4.1, автор считает её жизнеспособным механизмом обхода PatchGuard версии 2. По сути, техника предполагает модификацию регистраций исключений для каждой возможной DPC-процедуры, которую PatchGuard может использовать, так чтобы каждая регистрация исключения указывала на процедуру, применяющую виртуальную раскрутку для безопасного выхода из DPC PatchGuard без вызова проверки целостности системы. Однако любой такой подход сталкивается с несколькими препятствиями.

Первая серьёзная трудность этой техники - найти каждую DPC PatchGuard. Поскольку ни одна из DPC-процедур PatchGuard не экспортируется, для поиска мест модификации требуется немного более творческое мышление. Автор считает, что для этой цели лучше всего подойдёт сочетание сопоставления шаблонов и снятия отпечатков кода; между различными DPC-процедурами PatchGuard существует ряд общих черт, которые можно использовать, чтобы найти их в PatchGuard версии 2 с относительно высокой степенью уверенности. Конкретно автор считает следующие критерии приемлемыми для обнаружения DPC-процедур PatchGuard:

1. Каждая DPC-процедура имеет одну регистрацию, помеченную как исключение/раскрутка, с _C_specific_handler.

2. Каждая DPC-процедура имеет ровно четыре области видимости для _C_specific_handler.

3. Каждая DPC-процедура упоминается в виде сырого адреса, то есть 64-битного указателя, в исполняемых секциях кода, составляющих ntoskrnl, как минимум дважды.

4. Каждая DPC-процедура имеет как минимум две области видимости _C_specific_handler со связанным обработчиком раскрутки/исключения.

5. Каждая DPC-процедура имеет ровно одну область видимости Cspecifichanlder с вызовом общей подфункции, которая ссылается на RtlUnwindEx, экспортируемую процедуру.

6. Каждая DPC-процедура имеет несколько наборов характерных, обычно редких инструкций, таких как ror/rol.

При наличии нескольких или даже всех этих критериев должно быть возможно точно найти все десять DPC-процедур через сканирование неперемещаемого кода в ядре. Информацию о регистрации исключений для DPC-процедур можно найти через обработку каталога исключений ядра; собственно, большинство критериев требует сделать это как предварительный шаг. Найти базу образа ядра тоже довольно тривиально: можно взять адрес экспортируемой процедуры и округлить его вниз до области 64 КБ. После этого остаётся только выполнять поиск вниз с шагом 64 КБ по сигнатуре DOS-заголовка, а затем проверить наличие заголовка PE32+.

Ещё одно препятствие, которое нужно решить для этого подхода, - размещение замещающих процедур обработчиков исключений. Эти процедуры должны находиться в пределах 4 ГБ от базы образа ядра, потому что в метаданных раскрутки есть только 32-битный RVA. Это означает, что в общем случае непрактично просто хранить их в бинарном файле драйвера или выделении пула: по умолчанию такие адреса обычно находятся гораздо дальше 4 ГБ от базы образа ядра. Насколько известно автору, документированных и экспортируемых процедур для выделения виртуальной памяти режима ядра по конкретному виртуальному адресу нет. Однако теоретически можно применить другие, менее приятные подходы, например выделить физическую память и напрямую изменить структуры страничной адресации, чтобы создать допустимую область памяти в пределах 4 ГБ от базы образа ядра.

После решения этих трудностей остальная часть подхода довольно тривиальна и похожа на части техники, описанной в 4.1. Конкретно заменённые обработчики исключений должны вызвать RtlVirtualUnwind, чтобы раскрутиться назад к диспетчеру DPC ядра, а затем запросить возобновление выполнения в раскрученном контексте.

С точки зрения автора, этот механизм далеко не так надёжен, как первый, хотя оба подхода можно отключить, полностью отказавшись от SEH как критического пути выполнения процедуры проверки целостности системы PatchGuard. Конкретно Microsoft могла бы изменить характеристики DPC-процедур, пытаясь затруднить снятие их отпечатков и обнаружение во время выполнения. Для поражения этой техники также можно было бы использовать предварительную валидацию метаданных раскрутки или дополнительные проверки в самом диспетчере исключений, гарантирующие, что все SEH-процедуры, зарегистрированные как часть образа, находятся в пределах этого образа в памяти. Есть и другие преимущества безопасности от проверки того, что SEH-процедуры на x64, зарегистрированные как часть образа, действительно существуют внутри образа; это будет обсуждаться ниже. Поэтому автор ожидал бы появления такого механизма в будущей версии Windows.

4.3. Перехват PsInvertedFunctionTable

Ещё один вариант перехвата PatchGuard в пути SEH-кода, критичном для процедуры проверки целостности системы, использует оптимизацию, существующую в диспетчере исключений x64. Конкретно можно использовать тот факт, что диспетчер исключений на x64 применяет кэш для повышения производительности обработки исключений. За счёт этого кэша может оказаться возможным перехватить управление выполнением в момент, когда DPC-процедура PatchGuard намеренно создаёт исключение нарушения доступа, чтобы запустить проверку целостности системы. Предложенная техника использует глобальную переменную ядра nt!PsInvertedFunctionTable, представляющую кэш для быстрой трансляции значений RIP в связанную базу образа и указатель на каталог исключений без необходимости выполнять медленный поиск по связному списку загруженных модулей ядра.

Эта техника довольно похожа на описанную в 4.2. Вместо изменения фактических записей каталога исключений, соответствующих каждой DPC-процедуре PatchGuard в образе ядра в памяти, эта техника изменяет кэшированный указатель на каталог исключений, хранящийся внутри PsInvertedFunctionTable. PsInvertedFunctionTable используется RtlLookupFunctionTableEntry, чтобы преобразовать значение RIP в связанный образ и блок метаданных раскрутки. Логика внутри RtlLookupFunctionTable по сути ищет среди кэшированных записей, находящихся в PsInvertedFunctionTable, образ, соответствующий заданному значению RIP. Если найдено совпадение, указатель на каталог исключений загружается напрямую из кэша PsInvertedFunctionTable, а не через более медленный процесс разбора PE-заголовка данного образа. Если совпадение не найдено, выполняется поиск по связному списку загруженных модулей. Если в списке загруженных модулей найдено совпадение, PE-заголовок связанного модуля обрабатывается для поиска каталога исключений этого модуля. Затем каталог исключений просматривается, чтобы найти блок метаданных раскрутки, соответствующий функции, содержащей указанное значение RIP.

Структуру, лежащую в основе PsInvertedFunctionTable (RTL_INVERTED_FUNCTION_TABLE), можно описать на C следующим образом:

В Windows Server 2003 в массиве внутри PsInvertedFunctionTable зарезервировано место максимум для 160 загруженных модулей. В Windows Vista это число расширено до 512 записей модулей. Массив загруженных модулей поддерживается системным загрузчиком модулей так, что при загрузке или выгрузке модуля соответствующая запись внутри PsInvertedFunctionTable соответственно создаётся или удаляется. Исчерпание массива модулей внутри PsInvertedFunctionTable не является фатальной ошибкой: в этом случае производительность диспетчеризации исключений, связанных с дополнительными модулями, будет ниже, но система всё равно продолжит работать.

Поскольку кэш преобразования RIP в каталог исключений, описываемый PsInvertedFunctionTable, хранит полный 64-битный указатель на каталог исключений связанного модуля, можно отделить кэшированный указатель каталога исключений от соответствующего образа. Иными словами, можно изменить член ExceptionDirectory конкретной кэшированной RTL_INVERTED_FUNCTION_TABLE_ENTRY так, чтобы он указывал на произвольное место вместо каталога исключений этого модуля. Нет проверок безопасности или целостности, которые подтверждают, что член ExceptionDirectory указывает внутрь данного образа. Сторонний драйвер мог бы использовать это, чтобы получить контроль над диспетчеризацией исключений для любого из первых 160, а в Windows Vista - 512, модулей ядра. Этот список загруженных модулей включает критически важные образы, такие как HAL, обычно первая запись в кэше, и само ядро, обычно вторая запись в кэше. В отношении обхода PatchGuard это позволяет стороннему драйверу скопировать данные каталога исключений ядра в динамически выделенную память и изменить их так, чтобы обработчики исключений для DPC-процедур PatchGuard указывали на заглушку, вызывающую виртуальную раскрутку, как описано в технике 4.2. После настройки изменённой теневой копии каталога исключений для ядра стороннему драйверу достаточно заменить указатель ExceptionDirectory внутри записи кэша PsInvertedFunctionTable для ядра указателем на теневую копию. После этого подход по сути совпадает с предложенным подходом из 4.2. У него есть дополнительное преимущество: его труднее обнаружить с точки зрения проверки целостности пути диспетчеризации исключений, поскольку каталог исключений, связанный с образом ядра в памяти, фактически не изменяется; меняется только указатель на каталог исключений в кэше.

Однако этот подход требует надёжного механизма обнаружения PsInvertedFunctionTable, которая не экспортируется, во время выполнения. Автор считает, что это не особенно сложная задача, поскольку первые несколько членов PsInvertedFunctionTable, а именно максимальное количество записей и записи для HAL и ядра, будут иметь предсказуемые значения, которые можно использовать в классическом поиске по заранее известной сигнатуре в пространстве глобальных переменных ядра. Для повышения точности можно также применять дополнительные эвристики, например требовать наличия нескольких ссылок из кода ядра на предполагаемое местоположение PsInvertedFunctionTable.

Этому предложенному подходу можно противодействовать многими из контрмер, предложенных против техник 4.1 и 4.2. Дополнительно эту технику можно заблокировать проверкой указателей каталога исключений внутри PsInvertedFunctionTable, например удостоверяясь, что такие указатели каталога исключений находятся в пределах предполагаемого связанного образа. Хотя такая валидация не идеальна, поскольку всё ещё может быть возможно переместить указатель каталога исключений в другое место внутри образа, которое можно безопасно изменить во время выполнения, например наложив его на большой массив глобальных переменных или что-то подобное, она определённо повысила бы сложность подрыва кэша трансляции RIP в диспетчер исключений. Аналогично можно принять дополнительные техники валидации, например требовать, чтобы каталог исключений указывал на память только для чтения, уменьшая шанс того, что сторонний драйвер сможет осмысленно подорвать кэш с результатом, отличным от падения системы.

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

4.4. Перехват KiDebugTrapOrFault

Хотя многие из предложенных техник блокировки PatchGuard до сих пор опирались на то, что PatchGuard использует SEH для запуска проверки целостности системы, существуют и другие подходы, не зависящие от этой конкретной детали реализации PatchGuard. Одна из таких альтернативных техник обхода PatchGuard включает подрыв обработчика отладочного сбоя в ядре: KiDebugTrapOrFault. Этот обработчик является точкой входа для всех отладочных исключений, например так называемых аппаратных точек останова, и поэтому представляет собой привлекательную цель для обхода PatchGuard.

Основа этой предложенной техники состоит в использовании набора аппаратных точек останова для перехвата выполнения в удобном критическом месте на пути выполнения PatchGuard, ведущем к проверке целостности системы. У этой техники больше гибкости, чем у многих ранее описанных техник, хотя эта гибкость даётся ценой значительно более сложной и трудной реализации. Конкретно предложенную технику можно использовать для перехвата управления в любой точке, критичной для выполнения проверки целостности системы PatchGuard: например, в диспетчере DPC ядра, в одной из DPC-процедур PatchGuard или в удобном месте в пути диспетчеризации исключений, таком как _C_specific_handler.

Перехват выполнения может быть достигнут через получение контроля над обработкой отладочных исключений. Это можно сделать несколькими разными способами; например, можно поставить перехват на KiDebugTrapOrFault или изменить каталог IDT, чтобы просто перенаправить отладочное исключение на код, предоставленный драйвером, полностью обходя KiDebugTrapOrFault. Есть даже способы сделать этот перехват прозрачным для текущей реализации PatchGuard, например через перехват PsInvertedFunctionTable, описанный в технике 4.3. Затем драйвер мог бы изменить метаданные раскрутки для KiDebugTrapOrFault и создать обработчик исключения для этой процедуры. Этот шаг дал бы прозрачный доступ первого шанса ко всем отладочным сбоям, потому что KiDebugTrapOrFault внутри себя создаёт и диспетчеризует исключение STATUS_SINGLE_STEP, описывающее отладочный сбой. Обычно такое исключение STATUS_SINGLE_STEP было бы передано отладчику, но нет технической причины, по которой стандартный обработчик исключений в стиле SEH не мог бы его поймать. Независимо от того, как получено управление выполнением на обработчике отладочного исключения, следующий шаг предлагаемого подхода состоит в изменении выполнения в выбранной интересующей точке, будь то диспетчер DPC таймера ядра, который легко найти, поставив DPC в очередь и выполнив виртуальную раскрутку, DPC-процедура PatchGuard, _C_specific_handler или любое другое интересующее место в критическом пути выполнения PatchGuard, чтобы предотвратить запуск проверки целостности системы PatchGuard.

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

У этого подхода есть три преимущества перед прямой модификацией кода ядра, то есть заменой опкодов. Во-первых, он более гибок, потому что не возникает трудностей с размещением абсолютного 64-битного перехода в произвольном месте. На x64 для этого обычно требуется около 12 байт опкодов из любого произвольного места в памяти. Например, не нужно беспокоиться о том, что пространство опкодов, перезаписанное переходом, может перекрыть целую границу инструкции, являющуюся целью перехода, что могло бы привести к выполнению недопустимого кода. Во-вторых, этот подход позволяет избежать необходимости реализовывать дизассемблер или схожие формы анализа кода в режиме ядра, поскольку аппаратные точки останова позволяют получить управление выполнением в точном месте без необходимости освобождать достаточно места для модификации переходом, а затем помещать исходные инструкции обратно в заглушку перехода, чтобы при желании позволить выполнению продолжиться в исходном эффективном потоке инструкций. Наконец, при правильной реализации эта техника может быть выполнена совершенно без состояний гонки, поскольку единственная модификация, которую нужно выполнить, - это атомарная 8-байтовая замена выровненного по указателю значения в PsInvertedFunctionTable, если выбран такой подход.

Этот подход требует, чтобы реализующий выбрал место или несколько мест в ядре, где будут установлены точки останова для получения управления выполнением. Возможностей много: диспетчер DPC, где можно отфильтровать DPC PatchGuard, например обнаруживая недействительные указатели ядра в DeferredContext; путь диспетчеризации исключений, где можно раскрутиться за пределы исключения нарушения доступа DPC PatchGuard; сама DPC PatchGuard, где можно снова выполнить раскрутку через RtlVirtualUnwind, обходя PatchGuard, если DPC вызывается PatchGuard; или любая другая выбранная область. Одно из преимуществ этого подхода состоит в том, что он сравнительно легко перехватывает выполнение в любом месте ядра, которое можно надёжно найти в разных версиях ядра, что потенциально делает его значительно более гибким для адаптации к будущим реализациям PatchGuard, чем некоторые ранее обсуждённые техники обхода.

Обычно в ядре есть логика, не позволяющая коду пользовательского режима помещать случайные адреса ядра в регистры отладки через NtSetContextThread. Может потребоваться внести дополнительные изменения, чтобы гарантировать сохранение пользовательских значений в регистрах отладки при переключениях контекста через те же механизмы, которые отладчик ядра использует для сохранения регистров отладки.

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

Обработчик отладочного исключения можно использовать не только для обхода PatchGuard ради разрешения обычных модификаций кода ядра через замену опкодов. Его также можно использовать, чтобы полностью устранить необходимость выполнять основанные на замене опкодов модификации ядра для получения управления выполнением. В этом направлении, получив контроль над обработчиком отладочного исключения способом, прозрачным для PatchGuard, например через предложенный подход на основе PsInvertedFunctionTable, можно установить точки останова на основе регистров отладки по каждому интересующему адресу, при условии что регистров отладки достаточно, чтобы покрыть все интересующие места. Из обработчика отладочного исключения можно полностью изменить контекст выполнения в точке отладочного исключения, что в точности соответствует тому, что можно сделать через традиционную модификацию на основе замены опкодов для заданного места. Microsoft было бы чрезвычайно трудно обнаружить такую прозрачную модификацию, потому что регистры отладки должны оставаться доступными для отладчика ядра. Без полного ограничения способности отладчика ядра устанавливать точки останова, если он не был подключён до инициализации PatchGuard, автор не видит для Microsoft особенно жизнеспособного способа, то есть способа без тривиального обхода, предотвратить использование регистров отладки для изменения контекста выполнения в выбранных точках ядра сторонним драйвером. Поскольку такой подход использовал бы тот факт, что Microsoft с деловой точки зрения должна дать IHV и ISV возможность отлаживать свой код на Windows, автор считает маловероятным, что Microsoft сможет успешно отключить его. Более того, поскольку такие техники можно реализовать даже без базового требования отключения PatchGuard, они по своей природе гораздо вероятнее будут работать с будущими редакциями PatchGuard. В конце концов, если PatchGuard даже не может обнаружить изменения ядра, потому что код ядра не модифицируется, то нет причин возиться с попытками отключить его; это выводит атакующего из сравнительно грязного дела догонять Microsoft с каждой новой редакцией PatchGuard.

4.5. Перехват бита общего обнаружения

Один из антиотладочных механизмов PatchGuard связан с регистрами отладки. В начале проверки целостности PatchGuard обнуляет управляющий регистр Dr7, отключая аппаратные точки останова. Однако процессор умеет обнаруживать прямые обращения к регистрам отладки. Эта возможность появилась ради внутрисхемных эмуляторов (ICE) — аппаратных отладчиков, управлявших процессором извне операционной системы. За неё отвечает бит общего обнаружения в Dr7: если он установлен, успешное обращение к регистру отладки вызывает отладочное исключение. Поэтому атакующий может перехватить попытку PatchGuard обнулить Dr7, определить начало проверки целостности и сразу изменить контекст выполнения — например, принудительно вернуть управление без проверки. Так ещё один защитный механизм PatchGuard обращается против него самого.

Общая идея похожа на технику 4.4: сначала нужно получить контроль над обработчиком отладочного исключения, затем установить в Dr7 бит общего обнаружения и дождаться обращения PatchGuard к регистрам отладки. Ядро законно обращается к ним при переключении контекста и во время вызовов NtSetContextThread/NtGetContextThread, поэтому такие обращения нужно отличать от PatchGuard. Достаточно проверить значение RIP в момент исключения: код PatchGuard находится в динамически выделенном невыгружаемом пуле, а обычный код ядра — внутри загруженного образа.

Когда обработчик отладочного исключения вызывается в результате обнуления Dr7 PatchGuard, сторонний драйвер, желающий отключить PatchGuard, может выполнить соответствующее действие, которое может быть столь же тривиальным, как жёсткий возврат из процедуры проверки целостности системы.

Как и техники, использующие применение SEH в PatchGuard для обфускации вызова процедуры проверки целостности системы, этот подход полагается на использование одного из защитных механизмов PatchGuard против него самого. Самой очевидной контрмерой было бы удалить поведение, обнуляющее регистры отладки. Однако отключение этого поведения может быть нежелательным, поскольку тогда PatchGuard было бы очень легко обнаружить: например, установив точку останова на чтение кода ядра и ожидая, пока PatchGuard выполнит чтение. Поскольку чтения кода ядра, в отличие от выборки инструкций для исполнения, довольно нетипичны, это открыло бы ещё один простой механизм обхода PatchGuard.

Лучший ход для Microsoft здесь состоял бы в том, чтобы максимально усложнить различение легитимных обращений к регистрам отладки и собственных обращений PatchGuard, хотя это, вероятно, не слишком осуществимо. Усиление пути отладочного исключения против перехвата через размещение дополнительных проверок валидации на этом пути кода также могло бы быть полезно для противодействия этой технике, хотя, вероятно, лишь в ограниченной и легко обходимой степени.

4.6. Модификация диспетчера DPC таймера ядра

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

Для этого нужно найти в диспетчере таймерных DPC ядра инструкцию, вызывающую связанную с таймером процедуру. Драйвер может поставить собственную таймерную DPC в очередь и при её вызове извлечь из стека адрес возврата в диспетчер. По нему нетрудно найти инструкцию call, выполняющую вызов процедуры из объекта DPC.

Остаётся изменить эту инструкцию call, направив управление в код драйвера. Тот сможет проверять каждую таймерную DPC — например, искать фиктивный адрес ядра в DeferredContext при указателе процедуры внутри образа ядра. Обнаружив DPC PatchGuard, драйвер не вызывает её, а возвращает управление в диспетчер сразу после перехваченной инструкции. Проверка целостности так и не запускается.

Лучшая защита — запускать PatchGuard несколькими независимыми способами: например, из отдельного ожидающего потока и из часто вызываемой системной процедуры. Пока все вызовы проходят через единственный диспетчер таймерных DPC, одного перехвата достаточно для обхода всей защиты.

4.7. Поиск DPC PatchGuard

Для периодического запуска PatchGuard использует объект KTIMER со связанным KDPC; оба находятся в невыгружаемом пуле. Если найти таймер в памяти и отменить его, PatchGuard не выполнится.

Реализация этой техники по сути является классическим поиском по заранее известной сигнатуре в невыгружаемом пуле с некоторыми специально заданными ограничениями на поиск цели. Конкретно нужно искать область памяти, соответствующую следующим критериям:

1. Память должна содержать корректный объект KTIMER: элементы связного списка указывают на другие правдоподобные таймеры либо на голову списка, а поле типа соответствует таймеру.

2. Интервал должен составлять несколько минут. PatchGuard добавляет небольшое случайное отклонение, поэтому верхней границы в семь-восемь минут достаточно для предварительной проверки.

3. У таймера должна быть связанная KDPC, и указатель должен быть допустимым указателем в невыгружаемый пул.

4. Поле типа связанной KDPC должно иметь правильное значение.

5. Связанная KDPC должна иметь DPC-процедуру, находящуюся в пределах образа ядра в памяти.

6. Связанная KDPC должна иметь значение DeferredContext, являющееся неканоническим адресом ядра.

Обнаруженную DPC можно отменить, отключив PatchGuard. Контрмера та же, что в разделе 4.6: несколько независимых путей запуска сделают атаку на один диспетчер менее эффективной.

4.8. Десинхронизация TLB (Split TLB)

Все x86-процессоры, поддерживающие защищённый режим и страничную адресацию, используют схему кэширования для ускорения трансляции виртуальных адресов в физические. Эта схема реализована через набор буферов ассоциативной трансляции, или TLB, которые кэшируют содержимое атрибутов страницы и связанного физического адреса для заданного виртуального адреса. Современные x86-процессоры, начиная с класса Pentium II и позднее, используют несколько наборов TLB, например один набор TLB для обращений к данным и один набор TLB для обращений к инструкциям. При нормальной работе системы оба TLB, если процессор поддерживает несколько TLB, поддерживают согласованные представления атрибутов конкретной страницы. Однако можно намеренно десинхронизировать содержимое этих TLB, тем самым поддерживая иллюзию, что одна страница имеет разные атрибуты в зависимости от того, обращаются ли к ней как к данным или как к исполняемому коду. У такой намеренной десинхронизации TLB много применений: от реализации поддержки запрета исполнения, используемой PaX/GRsec на GNU/Linux [6], до маскировки памяти - техники, часто применяемой руткитами для предоставления одного представления памяти, когда память читается как данные, и другого представления, когда память используется при выборке инструкции. Та же техника маскировки памяти, привлекательная для разработчиков руткитов как способ скрывать руткит от обнаружения, может использоваться и для сокрытия модификации ядра от проверки целостности PatchGuard. Строго говоря, предложенная техника не является механизмом обхода PatchGuard; скорее это механизм сокрытия модификации ядра от PatchGuard, делающий PatchGuard безвредным для сторонних участников, модифицирующих ядро.

Детали этого подхода по существу во многих отношениях похожи на любую программу, реализующую подход с разделёнными TLB для изменения атрибутов или содержимого страниц на основе выборки для исполнения или чтения. Точные детали того, как этого можно добиться, выходят за рамки этой статьи и обсуждаются в других местах: командой PaX в контексте реализации запрета исполнения на устаревших платформах [6], а также Sherri Sparks и Jamie Butler в контексте реализации Windows-руткита, использующего разделённые TLB для реализации так называемой маскировки памяти [7]. Заинтересованным читателям рекомендуется изучить эти ссылки для получения низкоуровневых деталей общей реализации концепции разделённых TLB. Хотя указанные статьи напрямую применимы к x86, концепции в принципе применимы и к x64 и, вероятно, могут быть заставлены работать на x64 с минимальными изменениями.

После установления механизма десинхронизации TLB, например через перехват обработчика страничных ошибок, рекомендуемый подход для этой техники состоит в десинхронизации TLB для всех областей ядра, где выполняется традиционная модификация или перехват на основе замены опкодов. Конкретно, когда код ядра читается для исполнения со страницы, где установлена модификация на основе замены опкодов, должна возвращаться изменённая страница. Если код ядра читается как ссылка на данные, например когда PatchGuard читает код ядра для проверки его целостности, должны возвращаться исходные данные. Эта техника фактически скрывает все изменения кода ядра от любых обращений, кроме прямого исполнения, что не даёт PatchGuard обнаружить, что сторонняя сторона изменила код ядра.

Отметим, что для успеха этого подхода сам перехват обработчика страничных ошибок должен быть скрыт от PatchGuard. Этого нельзя напрямую достичь той же тактикой десинхронизации TLB, поскольку обработчик страничных ошибок должен оставаться резидентным. Может понадобиться комбинированный подход, например использование отладочной точки останова на обработчике страничных ошибок вместе с подорванным обработчиком отладочного исключения, возможно через PsInvertedFunctionTable, как ранее описано в технике 3, а также схема, предотвращающая отключение PatchGuard точек останова на основе регистров отладки, как описано в технике 5. Это может быть нужно, чтобы перехват обработчика страничных ошибок был действительно прозрачен для PatchGuard.

Наиболее логичная защита от этого подхода - попытаться обнаружить компрометацию пути диспетчеризации страничных ошибок. Поскольку десинхронизацию TLB в общем случае нельзя использовать для сокрытия самого обработчика страничных ошибок, ведь обработчик страничных ошибок должен оставаться помеченным как присутствующий в памяти, сторонней стороне было бы трудно скрыть изменение обработчика страничных ошибок от ядра. Эта трудность выражалась бы в ограниченном числе способов скрыть изменения обработчика страничных ошибок, например через умное использование регистров отладки. Поэтому ключ к тому, чтобы не дать этой технике оставаться жизнеспособной, - разработать способ, позволяющий PatchGuard обнаружить перехват страничной ошибки. Если, например, обработчик отладочного исключения и отладочная точка останова на обработчике страничных ошибок использовались бы для получения управления при страничной ошибке, Microsoft могла бы предотвратить эту технику, блокируя или обнаруживая перехват обработчика отладочного исключения. Одним таким подходом могло бы быть более надёжное защищённое состояние PsInvertedFunctionTable, которая представляет лёгкий способ для сторонней стороны подорвать обработчик отладочного исключения без ведома PatchGuard. Однако такие контрмеры будут зависеть от механизма, используемого для сокрытия перехвата обработчика страничных ошибок.

4.9. Модификация DPC-процедур

Вариация техники 4.2, очень простолинейный подход к отключению PatchGuard, состояла бы в том, чтобы просто поставить перехват на каждую возможную DPC-процедуру, проверить, не вызывается ли DPC, вероятно, для выполнения проверки целостности системы PatchGuard, и если да, просто вернуться из DPC к диспетчеру DPC таймера ядра. Чтобы реализовать этот подход, сначала нужно найти каждую возможную DPC-процедуру. Техника 4.2 перечисляет ряд жизнеспособных алгоритмов снятия отпечатков и поиска каждой DPC-процедуры; любой, а лучше несколько, из предложенных там алгоритмов напрямую применим к этому подходу.

После идентификации всех возможных DPC-процедур остаётся только изменить каждую из них так, чтобы она переходила к коду, контролируемому драйвером. Затем драйвер мог бы решить, вызывается ли DPC легитимно или как часть процесса проверки целостности системы PatchGuard; последнее легко определить по неканоническому адресу ядра, переданному как DeferredContext. Если DPC связана с PatchGuard, то всё, что драйвер должен сделать для блокировки PatchGuard, - немедленно вернуться в диспетчер DPC.

Этот подход довольно тривиально предотвратить с точки зрения Microsoft. Поскольку он основан на сигнатурах, один возможный контрподход Microsoft состоял бы в том, чтобы определить, какие сигнатуры сторонние драйверы используют для обнаружения DPC PatchGuard, и изменить DPC-процедуры PatchGuard в следующей версии так, чтобы они не соответствовали этим сигнатурам. Microsoft также могла бы изменить число DPC-процедур, чтобы сбить с толку драйверы, предполагающие, что PatchGuard использует ровно десять DPC, или Microsoft могла бы перейти на альтернативный механизм доставки, отличный от DPC, чтобы не дать существующему коду, который обнаруживает и перехватывает конкретные DPC-процедуры, блокировать PatchGuard.

5. Подрыв PatchGuard

Сейчас PatchGuard обладает внушительным набором защитных механизмов, направленных на усложнение обратного инжиниринга и отладки. Учитывая, что у Microsoft сейчас нет инфраструктуры, которая заставила бы PatchGuard поддерживаться аппаратно, в краткосрочной перспективе это, пожалуй, лучшее, что Microsoft реально может сделать. Она способна построить только систему, основанную на обфускации и техниках защиты от отладки, пытаясь затруднить сторонним участникам её обнаружение, отключение или обход.

Существуют и другие классы ПО, которые стремятся создавать защиты, похожие на защиты PatchGuard. Однако у этих других классов обычно куда более вредоносные цели, чем предотвращение модификации ядра сторонними участниками. Конкретно защита от отладки, защита от обратного инжиниринга и саморасшифровывающийся код часто использовались для сокрытия вирусов, руткитов и другого вредоносного ПО на скомпрометированных системах.

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

Чтобы заставить PatchGuard исполнять чужую волю, сначала нужно, так сказать, поймать PatchGuard на месте действия. Для этого автор рекомендует использовать одну из предложенных техник обхода как стартовую точку. Например, рассмотрим первую предложенную технику обхода, где автор рекомендует перехватить _C_specific_handler, чтобы перехватить управление выполнением на исключении, сгенерированном DPC-процедурой PatchGuard для запуска проверки целостности системы. Реализация этой техники обхода даёт прямой доступ к машинному контексту внутри DPC-процедуры PatchGuard, а этот машинный контекст содержит сведения, необходимые для поиска процедуры проверки целостности системы PatchGuard.

Поскольку цель состоит в перепрофилировании процедуры проверки целостности системы для выполнения пользовательского кода, это хорошая стартовая точка. Однако определить местоположение процедуры проверки целостности системы гораздо сложнее, чем просто полностью пропустить проверки PatchGuard; указатель на нужную процедуру зашифрован на основе исходных аргументов DPC, то есть аргументов Dpc и DeferredContext. Кроме того, исходные аргументы DPC PatchGuard к этому моменту уже перенесены из регистров на стек и обфусцированы вращением влево или вправо на магическую константу. Поскольку исходное содержимое регистров аргументов DPC-процедура намеренно перезаписывает до генерации нарушения доступа, не остаётся выбора, кроме как каким-то образом выудить аргументы DPC из стека вызывающей стороны. Это действительно представляет некоторую сложность, учитывая, что такой подход должен работать во всех версиях ядра и для всех разных перестановок DPC. Поскольку этот набор возможностей представляет неприемлемо большое число процедур для обратного инжиниринга ради определения значений обфускации циклическим сдвигом и стековых смещений, нужен более обобщённый подход к поиску исходных аргументов на стеке. Чтобы создать такой общий подход, нужно внимательнее посмотреть на первые несколько инструкций каждой DPC-процедуры, ведущих к намеренному нарушению доступа. Хотя PatchGuard установил несколько барьеров, мешающих легко извлечь исходные аргументы из этого контекста, там может быть шаблон или слабость, которую можно использовать для восстановления нужных аргументов.

Базовые общие свойства каждой DPC-процедуры с точки зрения машинного контекста в момент нарушения доступа таковы:

1. Исходные аргументы сохранены на стеке в обфусцированном виде, через вращение влево или вправо на произвольную магическую константу.

2. Нарушение доступа всегда происходит при разыменовании rax. Здесь rax всегда является деобфусцированной формой аргумента DeferredContext. Это бесплатно даёт нам один из аргументов, поскольку rax в контексте регистров в момент нарушения доступа всегда содержит открытое значение DeferredContext.

3. Стековое место, где хранится аргумент Dpc, сильно меняется от одной версии DPC к другой. Более того, оно также меняется между разными вариантами ядра внутри семейства операционных систем и между семействами операционных систем. Поэтому непрактично жёстко задавать стековые смещения для этого аргумента.

4. Инструкция непосредственно перед инструкцией, вызвавшей исключение, всегда имеет форму ror rax, <магическая константа>. Здесь магическая константа является непосредственным значением, то есть кодируется как часть опкода самой инструкции. У каждой DPC есть собственная уникальная магическая константа, и используемые магические константы не меняются для конкретной разновидности DPC во всех вариантах ядра и семействах операционных систем. Это даёт удобный способ быстро определить, какая из десяти DPC PatchGuard используется, из контекста перехвата _C_specific_handler, без некрасивого снятия отпечатков кода или анализа. К сожалению, у нас всё ещё нет способа определить стековое смещение аргумента Dpc.

5. Регистр r8 всегда равен исходному аргументу Dpc, сдвинутому вправо на младший байт аргумента DeferredContext. Хотя это может казаться соблазнительно близким к искомому, на самом деле его нельзя использовать как замену исходного аргумента Dpc, даже несмотря на то, что аргумент DeferredContext здесь известен благодаря значению rax. Причина в том, что операция сдвига вправо разрушительна: информация безвозвратно теряется, когда биты сдвигаются вправо за пределы регистра. Поэтому, в зависимости от младшего байта DeferredContext, важные биты аргумента Dpc уже навсегда потеряны в псевдокопии, находящейся в r8.

Хотя поначалу ситуация может выглядеть мрачной, на самом деле по этим сведениям всё ещё можно найти аргумент Dpc; нужно лишь немного поработать и запачкать руки неприятными трюками. Конкретно можно искать аргумент Dpc в стековом кадре DPC-процедуры методом полного перебора. Это не особенно элегантно, но выполняет задачу. Есть ряд подсказок, которые можно использовать для повышения шанса успешно найти настоящий аргумент Dpc на стеке:

1. Стек выровнен как минимум по 8 байтам из-за требований соглашения о вызовах x64, и компилятор Microsoft C/C++ всегда размещает значения размером с указатель на стеке по 8-байтно выровненным адресам. Поэтому поиск можно сузить до 8-байтно выровненных мест на стеке вместо побайтового поиска.

2. Поскольку идентичность текущей DPC-процедуры известна благодаря анализу инструкции ror, непосредственно предшествующей инструкции mov eax, [rax], вызвавшей исключение, известна и константа циклического сдвига, используемая для обфускации аргумента Dpc. Каждая DPC-процедура имеет собственную уникальную магическую константу циклического сдвига, и поскольку текущая DPC-процедура положительно идентифицирована, константа циклического сдвига, используемая для обфускации аргумента Dpc на стеке, тоже известна.

3. Быструю проверку того, может ли значение на стеке быть аргументом Dpc, можно выполнить, повернув значение на стеке известной константой обфускации, затем сдвинув значение вправо на младший байт аргумента DeferredContext и сравнив результат со значением r8 в момент исключения. Если есть несовпадение, текущее место на стеке можно исключить из поиска. Это не даёт положительного совпадения, но даёт способ надёжно исключать варианты. Этот шаг также необязателен: аргумент Dpc всё ещё можно найти без опоры на r8; проверка через r8 является лишь оптимизацией.

4. Аргумент Dpc должен указывать на допустимый адрес невыгружаемого пула, поскольку он должен представлять допустимый указатель ядра. Чтобы проверить это, можно использовать MmIsAddressValid и проверить, является ли рассматриваемое деобфусцированное значение допустимым указателем. Да, MmIsAddressValid слегка подвержена гонкам и, безусловно, является трюком. Автор хотел бы отметить, что этот подход был описан как требующий от реализующего "запачкать руки неприятными трюками", чтобы предупредить неизбежные жалобы о том, что некоторые могут осудить этот подход как неудобоваримый грязный трюк.

5. Аргумент Dpc должен указывать на допустимый адрес невыгружаемого пула, длины которого достаточно, чтобы вместить объект KDPC плюс как минимум одно дополнительное поле размером с указатель. Вторичный тест MmIsAddressValid можно использовать, чтобы проверить, что указатель описывает допустимую область, достаточно большую для объекта KDPC плюс дополнительного поля размером с указатель после него, то есть ключа расшифровки PatchGuard.

6. Аргумент Dpc должен указывать на DPC, у которой аргументы Type и DeferredContext были обнулены. DPC-процедура намеренно обнуляет эти значения в DPC перед намеренной генерацией нарушения доступа. Если предполагаемый аргумент Dpc, будучи рассмотренным как PKDPC, не обладает этими свойствами, его можно исключить как вариант.

Повторно применяя эти правила к каждому подходящему месту в разумном диапазоне вверх от значения rsp в момент исключения, например 256 байт, хотя точный размер может быть больше; единственное требование состоит в том, чтобы вся область локальных переменных DPC-процедуры с наибольшей областью локальных переменных полностью помещалась в область поиска, можно восстановить аргумент Dpc с практически полной уверенностью. По опыту автора, эта техника работает довольно надёжно, несмотря на интуитивное опасение, что поиск в неизвестном стековом кадре может часто отказывать или давать ложные совпадения.

После восстановления обоих аргументов DPC-процедуры PatchGuard, Dpc и DeferredContext, остаётся простая задача: проанализировать, как PatchGuard вызывает проверку целостности системы, чтобы определить, как найти её в памяти. Это уже обсуждалось ранее и сводится к следующему набору выражений:

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

Напомним, что первая инструкция заглушки принимает следующее значение:

Если посмотреть на прототип дешифрующей заглушки, rcx соответствует адресу самой заглушки, а rdx - ключу расшифровки. Поскольку эта инструкция изменяет и саму себя, и следующую инструкцию, ведь длина инструкции четыре байта, а xor изменяет восемь байт, замещающий код для процедуры проверки целостности системы должен позволять первой инструкции быть приведённой выше xor-инструкцией и должен позволять второй инструкции как минимум изначально быть обфусцированной через XOR. Ради простоты автор выбрал самое простое возможное решение этой задачи: сделать вторую инструкцию замещающего кода дубликатом первой. Иными словами, замещающий код будет выглядеть так:

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

После настройки пользовательского кода и шифрования второй инструкции остаётся только скопировать пользовательский код поверх дешифрующей заглушки PatchGuard. Когда это выполнено, обработчик исключения DPC PatchGuard вызовет предоставленный пользовательский код вместо процедуры проверки целостности системы.

Однако это само по себе не особенно интересно, потому что PatchGuard использует одноразовый таймер. Пользовательский код, подставленный вместо дешифрующей заглушки, больше никогда не будет выполнен. Чтобы учесть это, было бы разумно поместить в блок пользовательского кода вызов постановки таймера со связанной DPC-процедурой, указывающей на DPC-процедуру, которую PatchGuard выбрал при загрузке.

На этом этапе можно просто позволить обычному процессу диспетчеризации исключений продолжиться, то есть возобновить _C_specific_handler, после чего вместо PatchGuard будет вызван пользовательский код. По сути, PatchGuard был не только отключён, но и полностью подорван так, чтобы вместо проверки целостности системы вызывать настраиваемый код под контролем стороннего драйвера.

Тем не менее ситуация всё ещё не оптимальна. В данный момент в _C_specific_handler всё ещё находится перехват, который может увидеть любой желающий и распознать, что кто-то вмешался в ядро. Кроме того, драйвер, изначально использованный для подрыва PatchGuard, всё ещё загружен, что тоже может быть явным признаком того, что с ядром сделали что-то неблаговидное.

Однако эти проблемы тоже решаемы. Оказывается, после подрыва PatchGuard можно безопасно снять перехват с _C_specific_handler, а затем просто вызвать _C_specific_handler после удаления перехвата. Более того, всё необходимое для выполнения подорванной процедуры проверки целостности системы может даже находиться внутри собственных внутренних структур данных PatchGuard. Например, можно использовать дополнительное пространство после пользовательского кода, где обычно находились бы дешифрующая заглушка и проверочная процедура PatchGuard, как блок параметров. Это особенно удобно, поскольку блоку пользовательского кода передаётся указатель на самого себя в rcx, первом аргументе, и к этому указателю легко прибавить известную константу, чтобы получить блок параметров пользовательского кода. На этом этапе весь код и все данные, необходимые для пользовательского кода, которым драйвер подорвал PatchGuard, находятся в динамически выделенной памяти. Учитывая это, исходный драйвер больше не нужен и даже может быть выгружен, чтобы ещё сильнее скрыть факт любых изменений ядра. После выгрузки драйвера единственными следами выполненных изменений будут список выгруженных модулей, который легко изменить, и сама переписанная процедура проверки целостности системы PatchGuard, которую легко усилить так, чтобы она была саморасшифровывающейся, с другим ключом шифрования, превращая её в крайне трудную для поиска цель в памяти.

Итоговый результат состоит в том, что PatchGuard отключён, а вместо него периодически выполняется произвольный пользовательский код. Более того, в коде ядра или глобальных данных нет модификаций или заплат, и в памяти не остаётся подозрительных драйверов или даже подозрительных лишних выделений памяти. По сути, единственные следы того, что PatchGuard был подорван, были бы видны только тому или тому, что знает, как найти и отключить PatchGuard.

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

6. Будущее направление PatchGuard и систем против взлома

В будущем Microsoft могла бы использовать несколько обобщённых подходов, чтобы значительно усилить PatchGuard против атак. Конкретно они связаны с добавлением избыточности и устранением единых точек отказа из PatchGuard. Часто полезно смотреть на систему против взлома вроде PatchGuard как на критическую систему, которую нужно держать работающей постоянно с минимальным простоем, то есть как сеть или сервис с высокой доступностью. Логичный способ достичь этой цели - найти и устранить единые точки отказа, например добавив избыточность. В сети с высокой доступностью это достигалось бы добавлением резервных кабелей, коммутаторов и тому подобного, чтобы при отказе одного компонента система в целом продолжала работать, а не падала полностью. В системе против взлома вроде PatchGuard полезно добавить избыточность ко всем критическим путям кода так, чтобы не существовало единственной точки, где атакующий мог бы просто изменить опкод или поставить перехват и в итоге отключить всю систему против взлома.

Устранение таких единых точек отказа критично для долговечности системы против взлома. Главная идея, которую нужно уловить в таких случаях, состоит в том, что атакующий всегда будет искать самый простой способ сломать защиты целевой системы. Вся обфускация и шифрование мира мало что дают, если атакующий может просто заменить jmp на nop и не дать сложным механизмам шифрования и защиты от отладки вообще получить шанс на запуск. В этом отношении текущая реализация PatchGuard ошибочна. Существует много разных единых точек отказа, где атакующий может внедриться в одном месте и полностью нарушить работу PatchGuard.

Одним возможным решением этой проблемы могло бы быть обеспечение нескольких разных путей кода, способных привести к каждой точке проверки целостности системы PatchGuard. Суть борьбы между системами против взлома и атакующими связана с тем, насколько легко обойти самое слабое звено такой системы. Пока все слабые звенья системы не укреплены одновременно, система остаётся гораздо более уязвимой для простой атаки или обхода. В этом отношении PatchGuard версии 2 мало улучшает самые слабые звенья системы, и поэтому всё ещё существует огромное число способов его обойти. Хуже того, каждой технике обхода часто достаточно атаковать лишь один конкретный аспект PatchGuard, чтобы отключить его целиком.

Что касается самого PatchGuard, один подход, который Microsoft могла бы использовать для значительного повышения устойчивости и надёжности системы к внешнему вмешательству, - объединить какую-либо критическую системную функциональность с проверкой целостности системы PatchGuard. Такой подход усложнил бы потенциальному атакующему простой обход вызова PatchGuard, потому что это одновременно обходило бы некоторую критическую системную функциональность, которая в идеале была бы необходима для хоть сколько-нибудь пригодной работы системы. Тогда задача атакующих превратилась бы либо в воспроизведение критической системной функциональности, содержащейся внутри PatchGuard, либо в поиск способа отделить критическую системную функциональность от частей PatchGuard, отвечающих за проверку целостности системы, либо в поиск способа полностью уклониться от обнаружения модификации ядра PatchGuard. Microsoft может сделать первые два пункта сколь угодно трудными, особенно поскольку знание внутреннего устройства Windows предположительно выше внутри Microsoft, чем вне Microsoft. Теоретически Microsoft было бы легче встроить критическую системную функциональность, чем потенциальным атакующим надёжно выполнить обратный инжиниринг и самостоятельно повторно реализовать такую функциональность, вынуждая атакующих идти трудным путём отделения PatchGuard от критической системной функциональности. Именно здесь умное использование обфускации и техник защиты от отладки действительно проявило бы максимальную эффективность, поскольку у атакующего в оптимальном случае не было бы выбора, кроме как полностью пройти PatchGuard пошагово и понять его, прежде чем он сможет воспроизвести критическую функциональность внутри PatchGuard или выборочно активировать критическую функциональность без активации проверки целостности системы.

Однако последняя проблема, то есть полное уклонение от обнаружения PatchGuard, вероятно, гораздо труднее для решения. Техники вроде умного использования регистров отладки, десинхронизации TLB и других связанных атак чрезвычайно трудно обнаружить; обычно их также очень легко изменить, чтобы избежать обнаружения после разработки известной схемы обнаружения таких атак. В этом конкретном отношении Microsoft сейчас находится в очень невыгодном положении. Улучшение PatchGuard для предотвращения таких тактик уклонения, вероятно, окажется и трудным, и плохим вложением времени относительно того, насколько быстро атакующие смогут адаптироваться и компенсировать усилия Microsoft по усилению возможностей PatchGuard.

Глядя в будущее, можно ожидать, что PatchGuard в конечном счёте заменит текущие защитные механизмы, основанные на обфускации, аппаратными защитными механизмами. В частности, автор ожидает, что Microsoft со временем развернёт версию PatchGuard, усиленную поддержкой аппаратной виртуализации, также известной как гипервизор, присутствующей в современных процессорах и разрабатываемой для Windows Server "Longhorn" под кодовым названием "Viridian". Реализация PatchGuard, защищённая гипервизором, была бы невосприимчива к простому удалению через модификацию, что устраняет некоторые из самых значительных недостатков текущих версий PatchGuard, по крайней мере пока сам гипервизор остаётся защищённым и свободным от пригодных для эксплуатации ошибок. В системе PatchGuard на основе гипервизора сторонним драйверам не разрешалось бы выполняться с привилегиями гипервизора, что полностью предотвращало бы модификацию самого PatchGuard во время выполнения, который был бы частью привилегированного слоя гипервизора. Система на основе гипервизора также могла бы реализовать концепции вроде однократно записываемой памяти, которые можно адаптировать для предотвращения модификации ядра вообще после его начальной загрузки в память, в отличие от обнаружения модификации постфактум и падения системы в ответ на недобросовестные действия сторонних драйверов.

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

7. Заключение

Хотя PatchGuard версии 2 вводит значительные улучшения в некоторых областях, он всё ещё остаётся уязвимым к широкому спектру потенциальных атак. Кроме того, возможно, хотя и непросто, полностью подорвать PatchGuard с целью запуска произвольного пользовательского кода вместо PatchGuard способом, который трудно обнаружить.

Учитывая эти моменты, возможно, пришло время заново оценить, действительно ли PatchGuard в нынешнем воплощении стоит всех усилий, которые Microsoft в него вложила. Безусловно, заставить мир IHV и ISV навести порядок в своём коде режима ядра - разумная цель, которая в конечном счёте приносит пользу всем пользователям Windows, как бы отдельные компании с плохо написанным кодом режима ядра [8] ни пытались представить факты иначе. Плохо написанный код режима ядра в лучшем случае приводит к хронической нестабильности, с которой часто ассоциируют Windows, а в худшем - к повышению привилегий и эксплуатации уязвимости для произвольного выполнения кода. Однако у того, что представляет собой PatchGuard, всё ещё есть серьёзные контраргументы: он может предоставить удобный способ вредоносному коду режима ядра скрываться крайне трудно обнаружимым образом, а ограничения, которые PatchGuard накладывает на систему, подавляют реальную инновацию. В качестве примера последнего можно рассмотреть Microsoft Virtual Server 2005 R2 SP1 (Beta), который конфликтует с PatchGuard и требует специального исправления ядра, меняющего то, что именно защищает PatchGuard, чтобы работать без падения системы с печально известной аварийной остановкой CRITICAL_STRUCTURE_CORRUPTION, прославленной PatchGuard [3]. Уже одно это должно служить признаком того, что, несмотря на утверждения Microsoft об обратном, для некоторых техник, предотвращаемых PatchGuard, действительно существуют легитимные применения. Также стоит отметить, что, несмотря на заявления Microsoft о том, что для PatchGuard не будет исключений [1], ей как минимум один раз пришлось внести изменения, чтобы её собственный код работал на PatchGuard. Любители теорий заговора могут задуматься, была бы Microsoft столь же любезна и сделала бы такие исключения для легитимных применений техник, блокируемых PatchGuard, в стороннем ПО с потребностями, похожими на Virtual Server 2005 R2 SP1, учитывая её подчёркнутые заявления об обратном.

В качестве последнего замечания о целях PatchGuard: даже с развёрнутой технологией гипервизора и, более того, даже с так называемой неизменяемой памятью, реализованной гипервизором, мало что можно сделать для защиты драйверов друг от друга. Даже в системе на основе гипервизора, где само ядро защищено от драйверов, взаимозависимые драйверы всё ещё смогут вмешиваться друг в друга, пока они сосуществуют в одном домене. Это особенно проблематично в Windows из-за концепций стеков устройств и интерфейсов устройств, позволяющих драйверам напрямую взаимодействовать друг с другом разными способами. Будет трудно гарантировать, что драйверы не прибегнут к модификации друг друга или к изменению выделений из пула вместо модификации кода в случае, когда неизменяемая память для областей кода обеспечивается гипервизором. В зависимости от целей стороннего ISV, пытающегося обойти PatchGuard, может быть возможно просто модифицировать драйверы, например Ntfs.sys или Tcpip.sys, вместо модификации ядра. С этой точки зрения маловероятно, что Windows когда-либо станет средой, где драйверы режима ядра полностью изолированы и не способны вмешиваться друг в друга, несмотря на усилия таких технологий, как PatchGuard.

Microsoft уже начала путь, который со временем может привести к системе, где ошибочные драйверы не смогут обрушить систему или модифицировать друг друга, с появлением User Mode Driver Framework (UMDF). Однако ещё предстоит увидеть, станут ли изолированные драйверы пользовательского режима жизнеспособной альтернативой для высокопроизводительных устройств, таких как PCI/PCI Express, в отличие от USB-устройств, или же они останутся ограниченными небольшим подмножеством устройств, поставляемых с типичным компьютером. Автор ожидает, что везде, где возможно, Microsoft будет пытаться перемещать сторонний код из чувствительных областей вроде ядра в более ограниченные места, такие как процесс пользовательского режима. Это соответствует заявленным целям PatchGuard: повышению стабильности системы за счёт предотвращения сомнительных действий сторонних драйверов или, по крайней мере, сомнительных действий способом, который может обрушить систему.

Библиография

1. Microsoft Corporation. Patching Policy for x64-Based Systems.

<http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx>;

дата обращения: 10 декабря 2006 г.

2. skape, Skywing. Bypassing PatchGuard on Windows x64.

<http://uninformed.org/index.cgi?v=3&a=3&t=sumry>;

дата обращения: 10 декабря 2006 г.

3. Microsoft Corporation. Connect: Virtual Server 2005 R2 SP1 Beta.

<https://connect.microsoft.com/site/sitehome.aspx?SiteID=151>;

дата обращения: 28 декабря 2006 г.

4. Advanced Micro Devices, Inc. AMD 64-Bit Technology.

<http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf>;

дата обращения: 28 декабря 2006 г.

5. Microsoft Corporation. RtlVirtualUnwind.

<http://msdn2.microsoft.com/en-us/library/ms680617.aspx>;

дата обращения: 28 декабря 2006 г.

6. The PaX Team. Paging Based Non-Executable Pages.

<http://pax.grsecurity.net/docs/pageexec.txt>;

дата обращения: 30 декабря 2006 г.

7. Sherri Sparks and Jamie Butler. "SHADOW WALKER" Raising the Bar for Rootkit Detection.

<http://www.blackhat.com/presentations/bh-jp-05/bh-jp-05-sparks-butler.pdf>;

дата обращения: 30 декабря 2006 г.

8. Skywing. Anti-Virus Software Gone Wrong.

<http://www.uninformed.org/?v=4&a=4&t=sumry>;

дата обращения: 31 декабря 2006 г.

Аннотация: в этой статье описывается процесс выявления и эксплуатации уязвимостей драйверов беспроводных устройств 802.11 в Windows. Этот процесс описан в виде двух шагов: предэксплуатации и эксплуатации. Шаг предэксплуатации даёт базовое введение в протокол 802.11, а также описывает инструменты и библиотеки, которые авторы использовали для создания простого фаззера протокола 802.11. Шаг эксплуатации описывает общие элементы эксплойта для драйвера беспроводного устройства 802.11. К этим элементам относятся базовая архитектура полезной нагрузки, используемая при выполнении произвольного кода в режиме ядра Windows, интеграция этой архитектуры полезной нагрузки в версию 3.0 Metasploit Framework и интерфейс, который Metasploit Framework предоставляет для упрощения разработки эксплойтов для драйверов беспроводных устройств 802.11. Наконец, три отдельные реальные уязвимости драйверов беспроводных устройств используются как практические примеры, иллюстрирующие применение этого процесса. Авторы надеются, что описание и иллюстрация этого процесса покажут: уязвимости режима ядра могут быть столь же опасными и столь же простыми в эксплуатации, как уязвимости пользовательского режима. Тем самым можно повысить осведомлённость о необходимости более надёжных технологий предотвращения эксплуатации в режиме ядра.