3204

Смысл отдельных байт эксплойта иллюстрирует табл. 2.3

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

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

В приведенных примерах эксплойтов для этого

141

достаточно заменить в коде эксплойта команды push О

call ExitThread

командой безусловного перехода на адрес, из которого вызывается функция main (первый пример), или адрес одной из функций SomeFuncX (второй и третий примеры).

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

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

К наиболее известным уязвимостям, связанным с переполнениями буферов, относятся:

переполнение буфера в Internet Explorer 5.5 и более ранних версий при попытке отображения специально сформированного изо бражения в формате BMP;

переполнение буфера практически во всех программах Microsoft, выпущенных до 2004 г., при попытке отображения специально сформированного изображения в формате JPEG;

142

переполнение буфера в Windows ХР и более ранних версий при получении специально сформированного сетевого запроса по протоколу RPC. Данная уязвимость использовалась сетевыми вирусами семейства MSBlast.

Начиная с Windows ХР SP2 в Windows включен специальный механизм DEP (Data Execution Prevention,

альтернативное название – NX, No Execute), защищающий от переполнения буферов. Основная идея DEP заключается в том, что страницы оперативной памяти, выделяемые процессу под глобальные данные, кучу и стеки потоков, получают атрибуты защиты PAGE_READWRITE вместо PAGE_ EXECUTEREADWRITE, как обычно.

В целом DEP вполне надежно защищает от переполнений буферов, однако имеет два существенных недостатка:

данный механизм работает лишь начиная с процессоров AMD Athlon и Intel Core. Более старые процессоры семейства х86 в силу особенностей конструкции не отличают доступ к оперативной памяти на чтение от доступа на выполнение. Уверения Microsoft о наличии какой-то «программной эмуляции» DEP для старых процессоров не соответствуют действительности – если такая эмуляция и существует, она никак не проявляет себя в экспериментах с реальными переполнениями буферов;

некоторые программы некорректно функционируют при включенном DEP.

Управление настройками DEP осуществляется путем файлов конфигурации загрузчика операционной системы (в Windows 2003 и более ранних версиях – файла boot.ini). В

панели управления в разделе System / Advanced / Performance

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

143

умолчанию во всех системных и прикладных процессах. Однако администратор может принудительно отключать DEP для конкретных процессов.

Другой механизм защиты от переполнений буфера – введенная в Windows Vista система ASLR (Address Space Layout Randomization). При включенной системе ASLR выбор адресов для отображения программных файлов, а также для выделения памяти под «кучу» и стек выполняются случайным образом. В результате в разных экземплярах одной и той же операционной системы и даже в разных загрузках одного и того же экземпляра операционной системы для одного и того же процесса карты распределения памяти будут совершенно различными. В результате использовать переполнение буфера для несанкционированной передачи управления на внедренный машинный код практически невозможно – для этого необходимо заранее знать адрес, по которому в памяти размещается этот код. Благодаря ASLR для Windows Vista/2008/7 неизвестно ни одного эксплойта, позволяющего удаленно внедрять код и несанкционированно передавать на него управление. Впрочем, от локального внедрения кода, на который несанкционированно передается управление, ASLR не защищает – если инсталлятор эксплойта выполняется в том же сеансе работы операционной системы, что и атакуемая программа, инсталлятор эксплойта часто может восстановить карту распределения памяти в атакуемой программе с требуемой степенью точности.

Не каждое переполнение буфера можно использовать для выполнения произвольного кода в контексте атакуемого процесса. Так, например, переполнения буферов в обработчиках NPFS-запросов (CAN-2003-0231) и LPC-запросов

(CAN-2003-0232), поступающих в Microsoft SQL Server 2000,

могут быть использованы лишь для временного выведения сервера СУБД из строя.

144

2.4.3. Отсутствие необходимых проверок входных данных

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

GetAdmin

Это, пожалуй, самый знаменитый эксплойт за всю историю Windows. Он разработан Константином Соболевым в 1996 г. Данный эксплойт использует тот факт, что, вплоть до Windows NT 4.0 SP3 включительно, ядро операционной системы не проверяло корректность адреса, передаваемого в функцию NtAddAtom в качестве выходного параметра. Если клиентская передавала в функцию NtAddAtom адрес, указывающий в память ядра, ядро записывало результат выполнения функции в указанную область памяти, не делая никаких проверок. Правильно подобрав параметры функции, нарушитель мог заставить ядро операционной системы записать произвольные (с некоторыми ограничениями) данные в произвольное место системного адресного пространства. Это позволяло заставить операционную систему считать, что она функционирует в отладочном режиме, и предоставлять всем пользователям привилегию отлаживать системные процессы. А эта привилегия позволяет практически неограниченно повышать полномочия пользователя-нарушителя.

Интересно, что в ядре Windows NT 4.0 SP3 присутствовало не менее четырех других функций, обладающих аналогичными уязвимостью

(NrtQuerylnformationFile, NtQueryVolumelnformationFile, NtSetlnformationFile, NtSetVolumelnformationFile), однако уже в

145

Windows NT 4.0 SP 4 все эти уязвимости были устранены. Судя по всему, программисты Microsoft использовали специальную тестирующую программу, позволяющую находить подобные уязвимости в автоматическом режиме, путем отправки в ядро операционной системы большого количества пакетов случайно подобранных данных. При наличии в операционной системе уязвимости, подобной GetAdmin, подобная тестирующая программа должна вызывать регулярные крахи операционной системы, при этом место обнаруженной уязвимости несложно определить исходя из информации на «синем экране» и в дампе оперативной памяти.

Уязвимость %00

Данная уязвимость имела место в веб-браузере Internet Explorer до версии 5.5. включительно. Нарушитель размещает на своей вебстранице гиперссылку вида

<а href=prog.exe%00some.html>

При проверке данной гиперссылки браузером она распознается как безопасная (поскольку имеет безопасное расширение, html) и передается в операционную систему. После этого выполняется перекодировка строки из внутреннего формата браузера в универсальный формат ASCIIZ, понятный операционной системе. В ходе этой перекодировке байты %00 превращаются в нулевой байт, являющийся в формате ASCIIZ признаком конца строки. Таким образом, подстрока some, html «отрезается» и при переходе по гиперссылке запускается программа prog.exe, причем браузер считает данное действие безопасным и не выдает никаких предупреждений.

Кратко опишем еще несколько известных уязвимостей данного класса:

в ранних версиях Microsoft Internet Information Server расширение. COM по ошибке не было включено в список возможных расширений исполняемых файлов Windows; в Internet Explorer 6.0 и более ранних версиях не выполнялись некоторые проверки безопасности при обработке НТМЕ-тэга IFRAME. Данная уязвимость использовалась

сетевыми вирусами семейства Nimda;

146

в Internet Explorer 6.0 и более ранних версиях при просмотре вебстраницы не запрещалась автоматическая загрузка (upload) локального файла с заданным именем на заданный сервер;

в Microsoft Office ХР и более ранних версиях поле INCLUDETEXT, включенное в документ Word или Excel, автоматически обновлялось при каждом открытии документа. В результате содержимое локальных файлов могло несанкционированно копироваться в документы, предназначенные для совместного использования и доступные другим пользователям.

2.4.4. Некорректный контекст безопасности

Средства динамического изменения полномочий пользователей традиционно являются одним из самых уязвимых мест во всех операционных системах. В Windows динамическое изменение полномочий реализовано путем динамического понижения, что в целом заметно более надежно, чем динамическое повышение полномочий, принятое в UNIX. Механизм олицетворения пользователя Windows заметно более устойчив к ошибкам программирования и администрирования, чем механизм SUID/SGID в UNIX, но, тем не менее, с ним связан целый ряд программных уязвимостей. Перечислим лишь некоторые из них.

AdminTrap

Данный эксплойт, разработанный автором настоящего пособия в 1997 г., создает NPFS-сервер, маскирующийся под один из двух стандартных NPFS-серверов Windows NT 4.0. При подключении пользователя к NPFS-серверу, обслуживаемому эксплойтом, эксплойт выполняет олицетворение пользователяклиента и немедленно разрывает сетевое соединение. Если «пойманный» пользователь обладает административными полномочиями, эксплойт тоже получает административные полномочия.

Эксплойт был выложен на сайт http://hackzone. га

147

приблизительно через год после его написания. В это время в Интернете стали появляться сообщения от хакеров, самостоятельно реализующих эту идею. Версия эксплойта, выложенная в общий доступ, имела серьезные ограничения и не могла быть использована в хакерских целях. Интересно, что хакеры, изучавшие код эксплойта, так и не смогли снять блокировки, присутствующие в общедоступной программной реализации эксплойта, и даже не обнаружили недокументированный ключ командной строки «/обезпингвинено», снимающий часть блокировок. В целом появление в общем доступе демонстрационной версии эксплойта AdminTrap [19] оказало благотворное влияние на безопасность Windows, поскольку серьезные хакеры свернули свои исследования в данном направлении, убедившись, что оно полностью изучено.

Начиная с Windows 2000 AdminTrap перестал функционировать в «голом» Windows, однако продолжал нормально работать при наличии в атакуемой сети дополнительных систем защиты наподобие Secret Net. Однако это не было связано с тем, что программисты Microsoft внесли

вкод Windows необходимые изменения, окончательно уязвимость AdminTrap была исправлена лишь в Windows ХР SP2. Судя по всему, публикации в русскоязычном сегменте Internet проходят мимо поля зрения Microsoft.

Некоторые модификации AdminTrap продолжали функционировать вплоть до Windows ХР SP1 включительно. Интересно, что многие из них так и остались неизвестными широкой публике. Одна из немногих уязвимостей данного класса, ставших известной широкой публике, – уязвимость

CAN-2003-0230, обнаруженная в Microsoft SQL Server 2000 SP3

в2003 г., уже после выхода Windows ХР SP2.

Системные окна на рабочем столе пользователя

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

148

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

Подобные уязвимости известны для Norton Antivirus, Agnitum Outpost Firewall, а также для некоторых других программ. Поскольку целый ряд таких уязвимостей до сих пор не исправлен и может быть использован «хакерами» на практике, мы не будем приводить здесь полный список уязвимых программ.

С введением в Windows Vista мандатного контроля целостности (Mandatory Integrity Control, MIC) уязвимости данного класса стали значительно менее опасными, поскольку передача оконных сообщений из пользовательских окон в системные стала по умолчанию запрещена.

2.4.5. Устаревшие функции

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

NetDDE Exploit

Данный эксплойт разработан компанией @stake в 2002 г. В Windows NT 4.0 сервер NetDDE запускался только при входе в систему локального пользователя и выполнялся от имени и с полномочиями локального пользователя. Начиная с Windows 2000 сервер NetDDE стал «полноценным» сетевым

149

сервисом, он стартует автоматически при старте системы и выполняется по умолчанию с полномочиями псевдопользователя SYSTEM.

Начиная с самых ранних версий сервер NetDDE поддерживал функцию, позволяющую произвольной клиентской программе заставить сервер NetDDE запустить на выполнение произвольную программу. Все, что необходимо клиентской программе – направить в невидимое окно данного процесса оконное сообщение WM_COPYDATA, содержащее в своем теле определенный набор «магических» данных, за которым следует имя программы, которую необходимо выполнить. Данная функция введена для того, чтобы NetDDEсервер мог запускать дополнительные серверные процессы по команде клиента.

В Windows NT описанная функция не представляла опасности, поскольку ее несанкционированное использование ничем не отличалось с точки зрения пользователя от обычного запуска программ с помощью системного вызова CreateProcess

– в обоих случаях порожденные процессы вели себя совершенно одинаково. Однако в Windows 2000, где NetDDEcepBep выполняется с полномочиями псевдопользователя SYSTEM, любой процесс, порожденный NetDDE-сервером, также выполняется с этими полномочиями. Это позволяет любому пользователю запускать произвольные программы от имени псевдопользователя SYSTEM и тем самым несанкционированно повышать свои полномочия.

WMF Exploit (MS06-001)

Данный эксплойт использовался вирусом Sober в 2006 г. Начиная еще с Windows 3.0 в Windows поддерживается формат векторных графических файлов WMF. Как неожиданно выяснилось в первых числах января 2006 г., данный формат допускает хранение внутри графического файла произвольного машинного кода, который автоматически выполняется при невозможности корректно отобразить файл на графическом устройстве. Для эксплуатации данной уязвимости достаточно всего лишь попытаться просмотреть файл экс-плойта с

150