Новаторские принципы построения программного кода полезной нагрузки

Новаторские принципы построения программного кода полезной нагрузки

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

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

Использование того, что у вас есть

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

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

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

Например, если библиотека kernel32.dll загружена, то можно использовать любую ее функцию, даже не используемую явно программой. Функцию можно использовать, потому что она, как и все другие компоненты библиотеки, уже загружена в память. Другими словами, при установлении связи с любой динамически подключаемой библиотекой DLL загружается гораздо больше программного кода, чем это кажется на первый взгляд.

Другой пример использования имеющегося под рукой кода относится к UNIX-системам. Речь идет о трюке, который использовался исследователями безопасности для преодоления защиты ранних патчей ядра Linux и модификаций ядра в рамках проекта PAX. Впервые этот трюк применила Solar Designer. Он заключался в записи в стек сначала параметров функции execve, а затем подмены хранимого в стеке содержимого регистра EIP на адрес функции execve. Стек оказывался настроен таким же образом, как и при вызове функции execve. По завершении функции команда ret восстанавливала подмененное содержимое регистра EIP и передавала управление на функцию execve. Следовательно, при подозрении взлома защиты выполнения программ из стека можно заблокировать выполнение программ из стека.

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

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

В Windows NT есть пара функций, которыми всегда может воспользоваться программа: LoadLibrary() и GetProcAddress(). Они позволяют загрузить любую динамически подключаемую библиотеку DLL и вызвать функцию. В системе UNIX для этих целей служат функции dlopen() и dlsym().

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

Функции загрузки библиотеки LoadLibrary() или dlopen() загружают совместно используемую часть кода в доступную программе память. Совсем не обязательно, что загружаемый код будет выполняться, но после загрузки он доступен для использования. В основном загружаемый код впоследствии выполняется.

Функции GetProcAddress() и dlsym() определяют в таблице функций динамически подключаемой библиотеки адрес экспортируемой функции. Для поиска в таблице функций используются символические имена и, возможно, необязательные порядковые целые числа – индексы. Входным параметром этих функций является имя искомой функции или ее индекс, а выходным – адрес искомой функции.

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

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

Программа с жестко запрограммированными адресами функций работает быстро и безошибочно, но, как правило, непереносима с одной платформы на другую. Для Windows NT это означает ограничение работоспособности программы переполнения буфера рамками единственного служебного пакета service pack и составом операционной системы OS combo. В зависимости от используемой платформы и библиотек в UNIX она может вообще не заработать.

Второй способ основан на определении адреса функции по таблице импортируемых символов атакованного процесса во время его выполнения. В этом случае программа работает лучше и переносима на другие платформы, но больше по размеру. В условиях недостатка памяти это серьезный минус, который может привести к непригодности способа. Для поиска адреса функции в управляющем коде должны быть предусмотрены возможности поиска. Лучше найти уже загруженную в память функцию определения адреса функции и использовать ее. Конечно, этот способ предполагает, что функция загружена в память. Часто так и бывает, но вообще это дело случая. Для успешного применения способа необходимо ясно представлять используемый в операционной системе механизм редактирования связей. Для Windows NT он реализован в виде переносимого выполнимого формата PE (portable executable format). Для большинства систем UNIX это выполнимый формат редактирования связей ELF (executable and linking format).

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

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

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

Вложенный программный код полезной нагрузки использован в программе IISHACK1.5, которая компрометирует Windows NT Server с установленным информационным сервером Интернет IIS 4. Подробный анализ программы и ее код можно найти в документе www.eeye.com/html/Research/Advisories/AD20001003.html. Для внедрения программой asp-файла на сервер был использован непривилегированный код, реализующий атаку «Unicode». Атака «Unicode» выполняется в пространстве процесса IUSR_MACHINE, который обычно является непривилегированным процессом.

Атака «Unicode» была объединена с атакой переполнения буфера на неназванный синтаксический анализатор. ASP, который выполнялся в контексте LOCAL_SYSTEM. Их комбинация позволила добиться полной компрометации системы.

Данный текст является ознакомительным фрагментом.