книги хакеры / Защита_от_взлома_сокеты,_эксплойты,_shell_код_Фостер_Дж_

сгенерированная методом PattetnCreate(). В строке 68 эта переменная используется вместо строки из 4000 букв ‘A’. Все остальное не изменилось. Если мы теперь выполним этот сценарий, то в регистре EIP должны оказаться однозначно идентифицируемые четыре байта (см. рис. 12.14).

Рис. 12.14. Перезапись EIP известной последовательностью

На рис. 12.14 регистр EIP содержит значение 0x74413674 или в ASCII-виде строку «tA6t». Чтобы получить исходную строку, байты нужно переставить местами, получится «t6At». Дело в том, что отладчик OllyDbg знает, что на платформе x86 словахранятся в порядке байтов little endian, но для удобства чтения представляет их и, в частности, значение регистра EIP в порядке big endian. Последовательность «t6At» находится в строке 11 примера 12.2, равно как и ASCII-строка, оказавшаяся в регистре ESI.

Найдя интересующие нас четыре байта, мы можем определить смещение адреса возврата от вершины стека. Для этого можно вручную подсчитать, сколько символов предшествует строке «t6At», но это скучно и долго. Проще воспользоваться сценарием patternOffset.pl, который находится в каталоге ~/framework/sdk. Хотя он и не документирован, но, заглянув в исходный текст, можно понять, что первый аргумент – это адрес, оказавшийся в EIP, в формате big endian, как его показывает OllyDbg, а второй – длина исходного буфера. В примере 12.3 сценарию patternOffset.pl переданы аргументы 0x74413674 и 4000.

Пример 12.3. Результат работы сценария patternOffset.pl

Administrator@nothingbutfat ~/framework/sdk $ ./patternOffset.pl 0x74413674 4000

589

Сценарий определил, что смещение подстроки «t6At» от начала строки равно 589. Значит, перед теми четырьмя байтами, которые окажутся в стеке на месте адреса возврата, должно быть 589 байтов. Второй вариант строки для

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

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

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

Рис. 12.16. Первый способ:

передача управления полезной нагрузке, размещаемой в стеке

Рис. 12.17. Второй способ:

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

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

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

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

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

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

Один из способов найти адрес подходящей команды CALL (или экви валентной ей) состоит в том, чтобы просмотреть всю виртуальную па мять процесса, пока не будет найдена последовательность байтов, соответствующая этой команде. Такая последовательность называет ся кодом операции (opcode). Предположим, например, что на полез ную нагрузку в стеке указывает регистр EAX. Тогда нам нужно найти в памяти команду CALL EAX, которой соответствует код операции 0xFFD0. Присоединив к процессу отладчик, мы могли бы найти в вир туальной памяти все вхождения цепочки 0xFFD0. Но даже если нам это удастся, то нет никакой гарантии, что при следующем выполнении программы нужная цепочка окажется по тому же адресу. Стало быть, случайный поиск в виртуальной памяти – дело ненадежное.

Наша цель – найти такие адреса, в которых нужные коды операции оказываются всегда. В Windows все разделяемые библиотеки (DLL), загружаемые в адресное пространство процесса, обычно начинаются с одних и тех же базовых адресов. Это объясняется тем, что в каждой DLL есть поле ImageBase, которое содержит адрес, по которому за грузчик должен постараться разместить библиотеку в памяти. Если загрузчик по какой то причине не сможет этого сделать, то DLL при дется динамически перенастроить на другой начальный адрес, а это ресурсоемкая процедура. Поэтому загрузчик по мере сил стремится поместить библиотеку туда, куда сказано. Ограничившись просмот ром только тех областей виртуальной памяти, которые отведены под DLL, мы существенно повысим шансы на то, что адреса нужных нам кодов операций не будут меняться от запуска к запуску.

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

Чтобы точно выяснить, куда именно указывают регистры, снова обратимся к рис. 12.13. Помимо самих значений регистров, отладчик выводит еще данные, находящиеся в тех областях памяти, на которые они указывают. Так, EAX указывает на строку, начинающуюся с «7At8», а ESI – на строку «At5A». Снова применив сценарий patternOffset.pl, мы найдем, что эти строки соответствуют смещения 593 и 585 байтов от начала.

На рис. 12.18 видно, что ESI указывает на область, где есть место только для 4 байтов, тогда как в области, на которую указывает EAX, можно разместить аж 3407 байтов.

Рис. 12.18. Области памяти, на которые указывают регистры EAX и ESI

Таким образом, мы ставим себе целью скопировать в EIP значение из регистра EAX. Осталось найти адрес команды CALL EAX в памяти, занятой разделяемыми библиотеками.

Примечание

Если бы EAX не указывал внутрь строки, то воспользоваться регист ром ESI и разместить полезную нагрузку всего в четырех байтах, ка залось бы, невозможно. Но мы смогли бы получить в свое распоря жение больше места, если бы поместили по адресу, отстоящему на 585 байтов от начала строки, команду JMP SHORT 6 (код операции 0xEB06). «Оттолкнувшись» от ESI и попав на эту команду, процессор перескочил бы через адрес возврата и оказался бы аккурат в начале обширной свободной памяти со смещением 593. А дальше эксплойт работал бы так же, как если бы на тот же адрес указывал регистр EAX. Заметим для интересующихся, что в команде JMP надо указать сме щение 6 (0xEB06), так как она сама не учитывается при подсчете рас стояния.

Очень хорошее справочное руководство по командам процессоров x86 можно найти на сайте проекта NASM по адресу http://nasm.sourceforge. net/doc/html/ nasmdocb.html.

Вычисление адреса возврата

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

с любым регистром в качестве операнда.

Рис. 12.20. Шаг 1: задание типа кода операции

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

На шаге 2 пользователь задает имя DLL, которую нужно найти в базе. Можно просматривать все модули, один или несколько обычно загружаемых модулей или набор конкретных модулей. Мы решили ограничиться модулями ntdll.dll и kernel32.dll, поскольку точно известно, что эти библиотеки процесс inetinfo.exe загружает в самом начале работы (рис. 12.21).

Рис. 12.21. Шаг 2: выбор DLL

Многие эксплойты отдают предпочтение библиотекам ntdll.dll и kernel32.dll в качестве трамплина по ряду причин:

1)начиная с Windows NT, любой процесс обязан загрузить в свое адресное пространство библиотеку ntdll.dll;