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

Распространённые способы перенаправления управления:

• Переход или вызов через регистр: перезапишите EIP адресом JMP <reg> или CALL <reg>, если регистр указывает на shellcode.

• Снятие значений и возврат: если полезный указатель находится по адресу ESP+n, выполните одну или несколько инструкций POP, а затем RET, чтобы отбросить предшествующие элементы стека и вернуться через этот указатель.

• Помещение на стек и возврат: последовательность PUSH <reg>; RET эквивалентна передаче управления по адресу из регистра.

• Переход через регистр со смещением: используйте инструкцию наподобие JMP [ESP+8], если указатель на shellcode хранится со смещением.

• Blind return: перезапишите EIP адресом инструкции RET, а на вершину стека поместите жёстко заданный адрес shellcode.

• Собственный jumpcode: выполните небольшой первый этап, который корректирует регистр и переходит в более крупный управляемый буфер в другом месте.

• SEH: перезапишите exception handler, чтобы получить более крупный или стабильный путь выполнения; этот способ рассматривается в третьей части.

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

CALL <reg>

Если регистр указывает непосредственно на shellcode, инструкция CALL <reg> работает так же, как переход. Для ESP найдите подходящие инструкции в загруженных модулях с помощью findjmp:

В примере с Easy RM to MP3 перед EIP находятся 26 094 байта, а до того места, где ESP достигнет shellcode, требуется четыре байта padding:

POP и RET

Если ни один регистр не указывает на shellcode, изучите первые элементы стека. Если там находится указатель на управляемые данные, перезапишите EIP адресом подходящей последовательности POP; RET, POP; POP; RET или более длинного варианта.

Каждая инструкция POP отбрасывает один четырёхбайтовый элемент стека. Затем RET загружает следующее значение в EIP. Если указатель на shellcode находится по адресу ESP+8, две инструкции POP пропустят первые восемь байтов, прежде чем RET воспользуется указателем.

Другой вариант размещает указатель на JMP ESP по адресу ESP+8, а shellcode — сразу после него. Первая последовательность POP POP RET достигает трамплина, а он передаёт управление payload.

Управляемый тест:

Найдите POP POP RET и перезапишите EIP его адресом. По адресу ESP+8 поместите адрес второй точки останова. RET передаст туда управление.

PUSH и RET

Если регистр указывает на shellcode, но прямого перехода или вызова нет, используйте:

PUSH ESP помещает значение регистра на стек. RET снимает его в EIP. Найдите такую последовательность в стабильном загруженном модуле и перезапишите EIP её адресом.

Тот же принцип применим к любому регистру. findjmp сообщает о трамплинах PUSH/RET вместе с прямыми вызовами и переходами.

JMP [reg+offset]

Если указатель на shellcode хранится со смещением относительно регистра, найдите косвенный переход наподобие JMP [ESP+8]. Соберите инструкцию в WinDbg:

Opcode равен FF 64 24 08. Найдите его в загруженных исполняемых модулях и используйте адрес инструкции для перезаписи EIP.

Точное совпадение со смещением +8 необязательно. Более крупное смещение может попасть в NOP sled перед shellcode. В этом примере подходящей последовательности в нужном модуле не нашлось, что наглядно показывает: теоретически правильный метод может оказаться непригодным для конкретной цели.

Blind return

Blind return использует только инструкцию RET:

1. Перезапишите EIP адресом RET.

2. Поместите абсолютный адрес shellcode в первые четыре байта по адресу ESP.

3. RET загрузит этот адрес в EIP.

Метод требует контроля над ESP и стабильного адреса shellcode без нулевых байтов. В примере Easy RM ESP находился около 0x000ff730; нулевой байт завершает строковый ввод и мешает обычным способом дописать shellcode. Иногда вместо него в ESP можно поместить указатель через другой управляемый регистр.

Blind return ненадёжен, поскольку часто жёстко задаёт адрес стека, однако он может сработать, если подходящего трамплина через регистр нет.

Маленькие буферы и собственный jumpcode

Предположим, после EIP остаётся лишь 50 полезных байтов, а большой буфер перед EIP всё ещё присутствует где-либо на стеке. Поместите после EIP небольшой первый этап, а основной shellcode — в более ранний буфер.

Сначала определите, где повторно появляются данные перед EIP. В тесте после EIP размещаются 54 байта X, а затем NOP:

ESP начинается с 0x000ff730. Байты X занимают непосредственный небольшой буфер, а копии данных A, расположенных до EIP, начинаются примерно по адресу ESP+281:

Замените начало большого буфера циклическим шаблоном длиной 1000 байтов. По адресу 0x000ff849 первые четыре видимых символа равны 5Ai6:

pattern_offset сообщает смещение 257. Разместите 250 байтов A, NOP sled длиной 50 байтов, payload и padding, сохраняющий общую длину перед EIP равной 26 094 байтам:

Первый этап должен переместить ESP примерно на 281 байт вперёд. Избегайте immediate value, добавляющего нулевые байты. Три прибавления 0x5e сдвигают указатель на 282 байта и приводят в NOP sled:

WinDbg собирает последовательность так:

Полный первый этап занимает всего 11 байтов:

После проверки перехода замените breakpoint настоящим shellcode. NOP sled допускает небольшие различия смещения.

Другие способы перехода

Тот же принцип позволяет создавать множество маленьких stub:

• прибавить значение к ESP, EBP, ESI, EDI или другому управляемому указателю либо вычесть его, а затем перейти через этот регистр;

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

• поместить на стек абсолютный или вычисленный адрес и выполнить RET;

• вычислить effective address с помощью LEA, не изменяя flags;

• связать несколько коротких инструкций, если одной подходящей последовательности нет.

Всегда собирайте выбранную последовательность, проверяйте её байты на bad characters и тестируйте под отладчиком.

Короткие и условные переходы

Короткий переход x86 использует восьмибитное знаковое смещение, отсчитываемое от инструкции, следующей сразу за переходом. Диапазон составляет от -128 до +127 байтов.

Переход вперёд на шесть байтов:

Near jump использует E9 и следующее за ним знаковое 32-разрядное смещение, поэтому покрывает намного больший диапазон. Рассчитывайте смещение относительно адреса после пятибайтовой инструкции.

Переходы назад

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

Независимо от выбранного метода проверяйте точную runtime layout, отдавайте предпочтение стабильным адресам из модулей приложения, избегайте bad characters и используйте достаточный NOP padding для компенсации небольших различий размещения.

SEH перезаписывается указателем на pop pop ret, а next SEH содержит код перехода через запись SEH. Такая структура соответствует поведению многих уязвимостей SEH, включая уязвимость Easy RM to MP3 Player из предыдущей статьи, но это лишь пример. Необходимо изучить все регистры, использовать точки останова, выяснить расположение полезной нагрузки или шелл-кода, исследовать стек и соответствующим образом построить полезную нагрузку. Проявляйте изобретательность.

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

В этом руководстве создаётся эксплойт для уязвимости Millenium MP3 Studio 1.0, о которой первоначально сообщалось в эксплойте Milw0rm 9277. Исходная демонстрация концепции предполагала, что проблему легко эксплуатировать, вероятно исходя из значений регистров, однако её автор не создал рабочего эксплойта.

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

Создайте файл MPF, содержащий http://, за которым следуют 5000 символов A:

Откройте исполняемый файл MP3 Studio в WinDBG, запустите его и загрузите созданный файл:

Нарушение доступа не похоже на состояние регистров из PoC. Либо длина буфера неверна для прямой перезаписи EIP, либо это уязвимость на основе SEH. Изучим цепочку SEH:

Перезаписаны и обработчик исключения, и next SEH, что подтверждает переполнение на основе SEH.

Создайте ещё один файл с 5000-символьным шаблоном Metasploit. Теперь цепочка SEH выглядит так:

Обработчик SE содержит 0x39466830, а next SEH — 0x67463867, интерпретируемые в порядке little-endian:

• Обработчик SE: 0x39466830, или 9Fh0, находится на смещении шаблона 4109.

• Next SEH: 0x67463867, или g8Fg, находится на смещении шаблона 4105.

Обычная полезная нагрузка SEH должна содержать:

1. 4105 мусорных символов. Удалите две проблемные обратные косые черты после http: и добавьте достаточно символов A, чтобы сохранить четырёхбайтовое выравнивание.

2. Значение next SEH \xeb\x06\x90\x90, выполняющее переход через обработчик SE.

3. Обработчик SE, содержащий указатель pop pop ret.

4. Шелл-код, при необходимости окружённый NOP, и заполнение.

Сначала используйте легко узнаваемые значения-заполнители, чтобы проверить смещения:

Сбой подтверждает структуру:

Как и ожидалось, обработчик равен 0x43434343 (CCCC), а next SEH — 0x42424242 (BBBB).

Замените обработчик указателем pop pop ret, а next SEH — четырьмя точками останова. Код перехода пока не нужен, потому что сейчас требуется определить местоположение полезной нагрузки. xaudio.dll, одна из DLL приложения, не защищена SafeSEH и содержит несколько подходящих последовательностей. Используем последовательность по адресу 0x1002083D:

Передайте первое нарушение доступа обратно приложению. Выполнится последовательность pop pop ret, и управление достигнет точек останова в next SEH. Если полезная нагрузка следует за SEH, EIP указывает на next SEH, а дамп должен показать next SEH, указатель SEH и затем шелл-код:

Результат обнадёживает, но примерно в 32 байтах после SEH встречаются четыре нулевых байта. Можно перепрыгнуть через SEH, а затем использовать следующие байты для второго перехода либо перейти непосредственно из next SEH к шелл-коду.

Замените первые символы D узнаваемыми данными, чтобы подтвердить структуру:

Дамп подтверждает, что это начало шелл-кода и после первых байтов имеется небольшой разрыв. Чтобы начать настоящий шелл-код по адресу 0x0012f9c0, поместите после SEH 24 инструкции NOP и выполните из next SEH переход на 30 байт с помощью \xeb\x1e:

После передачи первого исключения приложению выполнение останавливается на точке останова по адресу 0x0012f9c0:

Замените байты точек останова настоящим шелл-кодом. В окончательном эксплойте используется 303-байтовая полезная нагрузка windows/exec, закодированная x86/alpha_upper, с EXITFUNC=seh и CMD=calc:

Готово. Эксплойт был опубликован под названием Millenium MP3 Studio 1.0 .mpf File Local Stack Overflow Exploit #2.

Упражнение

Создайте рабочий эксплойт для файлов M3U и найдите способ использовать прямую перезапись EIP вместо SEH.

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

SEH-эксплойт для файлов M3U почти идентичен версии MPF и здесь не рассматривается.

Обновление: пользователь блога и форума по имени mancu37 опубликовал альтернативный эксплойт на основе прямой перезаписи RET.

Следите за новыми материалами, советами и приёмами по написанию эксплойтов.

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

Модули Metasploit пишутся на Ruby. Даже без глубокого знания Ruby вы сможете создать модуль по этому руководству и существующим эксплойтам Metasploit.

Структура модуля эксплойта Metasploit

Типичный модуль состоит из:

• Заголовка и зависимостей:

• Комментариев о модуле.

• require 'msf/core'.

• Определения класса.

• Подключаемых компонентов.

• Определений методов:

• initialize.

• check — необязательно.

• exploit.

Комментарии начинаются с #. Пока этого достаточно; перейдём к созданию модуля эксплойта.

Практический пример: эксплойт для простого уязвимого сервера

Используем следующий уязвимый сервер на C:

Скомпилируйте код и запустите в Windows Server 2003 R2 SP2. Я использовал lcc-win32. Отправка 1000 байт вызывает сбой. Следующий сценарий Perl демонстрирует его:

Уязвимый сервер завершается, а EIP перезаписывается символами A:

По шаблону Metasploit определяем, что EIP перезаписывается со смещения 504. Создадим новый сценарий для проверки смещения и регистров:

После 504 символов A, четырёх B и последовательности C регистры и стек выглядят так:

Увеличьте мусорные данные, чтобы определить место для шелл-кода, которое нужно указать в модуле. При $totalbuffer = 2000 переполнение работает, а ESP содержит C до esp+5d3, то есть доступно около 1491 байта.

Нужно лишь перезаписать EIP инструкцией jmp esp, call esp или аналогичной и заменить C шелл-кодом. findjmp находит подходящий адрес в Windows Server 2003 R2 SP2:

Проверка шелл-кода даёт ещё два вывода:

• Исключить 0xff из шелл-кода.

• Разместить перед шелл-кодом цепочку NOP.

Окончательный Perl-эксплойт использует 702-байтовую нагрузку windows/shell_bind_tcp, созданную Metasploit с кодировщиком x86/alpha_upper, EXITFUNC=seh и LPORT=5555. Транспорт и создание буфера:

Эксплойт успешно открывает командную оболочку:

Важнейшие параметры:

• Смещение адреса возврата — 504.

• Адрес перехода для английской Windows Server 2003 R2 SP2 — 0x71C02B67.

• Шелл-код не должен содержать 0x00 или 0xff.

• Для шелл-кода доступно около 1400 байт.

В английской Windows XP SP3 смещение то же, но адрес перехода нужно изменить, например на 0x7C874413. Создадим модуль Metasploit с обеими целями.

Преобразование эксплойта в Metasploit

Сначала определите тип эксплойта: от него зависит место в структуре каталогов Metasploit. Например, эксплойт FTP-сервера Windows относится к эксплойтам FTP-серверов Windows.

Модули находятся в framework3/modules/exploits и организованы сначала по ОС, затем по службе. Наш сервер работает в Windows, но не относится к конкретной службе, поэтому поместим модуль в windows/misc:

Модуль состоит из:

• require 'msf/core', используемого всеми эксплойтами Metasploit.

• Класса-наследника Msf::Exploit::Remote.

• Msf::Exploit::Remote::Tcp, предоставляющего обычное TCP-соединение. В Metasploit есть обработчики HTTP, FTP и других протоколов.

• Параметров нагрузки с доступным пространством и недопустимыми символами.

• Целей со специфичными адресами возврата и смещениями.

• Метода exploit, который подключается, создаёт и отправляет буфер, запускает обработчик и отключается.

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

Проверка эксплойта Проверка 1: Windows XP SP3 Проверка 2: Windows Server 2003 R2 SP2

Продолжение проверки Windows XP:

Готово!

Дополнительные сведения об API Metasploit

Сведения об API Metasploit и доступных классах находятся в архивной документации API Metasploit.

Теперь создавайте собственные эксплойты, добавляйте в них немного l33t-лексики и не забывайте передавать привет corelanc0d3r.

• WinDBG и справочник по командам WinDBG.

• OllyDbg.

• Immunity Debugger и Python.

• Metasploit.

• PyDbg для создания собственных отладчиков на Python.

• Язык сценариев, например Perl или Python.

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

Byakugan: введение, pattern_offset и searchOpcode

У WinDBG есть инфраструктура расширений, подобная системе плагинов OllyDbg. Пакет Byakugan из Metasploit содержит byakugan.dll, injectsu.dll и detoured.dll. Поместите первые два файла в каталог приложения WinDBG, а detoured.dll — в C:\Windows\System32.

Byakugan предоставляет следующие компоненты:

• jutsu: поиск и отслеживание буферов, определение контролируемой памяти при сбое и поиск адресов возврата.

• pattern_offset: поиск смещений в циклическом шаблоне.

• mushishi: обнаружение и обход методов защиты от отладки.

• tenketsu: эмуляция и визуализация кучи Vista.

injectsu.dll перехватывает API целевого приложения и создаёт поток обратного канала, соединённый с отладчиком. Библиотека Microsoft detoured.dll предоставляет перехватывающие трамплины, отслеживает перехваченные функции и корректирует трамплины функций.

Загрузите Byakugan:

Компонент Jutsu включает:

• identBuf, listBuf и rmBuf для поиска в памяти ASCII-строк, циклических шаблонов или данных файла.

• memDiff для сравнения памяти с шаблоном и обнаружения изменённых байтов или недопустимых символов.

• hunt.

• findReturn для поиска подходящих путей возврата.

• searchOpcode для ассемблирования инструкций и поиска их экземпляров в исполняемой памяти.

• searchVtptr.

• trackVal.

Практический пример BlazeDVD

Мы воспользуемся переполнением стека в BlazeDVD 5.1 Professional и Blaze HDTV Player 6.0. Сбой вызывается некорректным файлом PLF. Вместо того чтобы начинать с символов A, сразу создадим 1000-символьный шаблон Metasploit:

Запустите BlazeDVD под WinDBG, продолжите выполнение после точек останова при запуске и откройте файл. При сбое в EIP оказывается значение из шаблона:

Загрузите Byakugan и запросите смещения:

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

Перед нами перезапись SEH. Позиция 612, указанная инструментом, соответствует SEH, поэтому next SEH начинается на четыре байта раньше — со смещения 608. Стандартная полезная нагрузка имеет вид [мусор][переход][pop pop ret][шелл-код]. Здесь мы выполняем переход на 30 байт и добавляем перед шелл-кодом 30 инструкций NOP.

Найдём pop esi; pop ebx; ret:

Выберите адрес в исполняемом модуле BlazeDVD. Для английской Windows XP SP3 подходит 0x640246f7:

Структура эксплойта выглядит так:

Плагины OllyDbg

На OpenRCE была размещена большая коллекция плагинов OllyDbg. Один из наиболее полезных для разработки эксплойтов — OllySSEH: он проверяет загруженные модули и сообщает, были ли они скомпилированы с /SafeSEH. OllyDbg должен быть присоединён к процессу, поскольку проверка выполняется по загруженной памяти.

При наличии уязвимости SEH используйте плагин, чтобы определить модули без SafeSEH, а затем ограничьте поиск pop pop ret их диапазонами адресов.

Список исполняемых модулей:

Состояние SafeSEH этих модулей:

Ищите No SEH или, что предпочтительнее, /SafeSEH OFF. Чтобы изучить MediaPlayerCtrl.dll, вернитесь к списку исполняемых модулей и дважды щёлкните модуль:

Щёлкните правой кнопкой мыши и выберите Search for > Sequence of commands. Например, найдите pop eax, ещё одну инструкцию pop и ret:

Перебирайте сочетания регистров, пока не найдётся подходящее. findjmp.exe работает быстрее, поскольку нужно указать только первый регистр, а второй он перебирает автоматически. Тем не менее OllySSEH экономит значительное время, сначала определяя надёжные диапазоны модулей.

Плагины и PyCommands для Immunity Debugger

В Immunity Debugger входит множество плагинов, а среди дополнительных PyCommands есть findtrampoline, aslrdynamicbase, funcdump, nsearch и pvefindaddr. Скопируйте загруженные файлы .py в каталог PyCommands.

Immunity также предоставляет псевдонимы для многих команд WinDBG, объединяя сценарии Python со знакомым набором команд.

findtrampoline

Для прямых переполнений стека findtrampoline похож на findjmp и msfpescan. Он ищет jmp <reg>, call <reg> и push <reg>; ret, однако не ищет pop pop ret.

Откройте окно PyCommand и выберите команду:

Дважды щёлкните её, укажите целевой регистр и запустите поиск:

Команда проверит все загруженные модули и сообщит количество найденных совпадений:

Команду также можно вызвать из командной строки:

Команда ищет варианты jmp, call и push; ret. Откройте Log data, чтобы изучить результаты:

Дважды щёлкните адрес и откройте окно CPU, чтобы изучить инструкцию:

Команда !searchcode позволяет искать конкретную инструкцию, например jmp esp, показывая адрес, модуль и признак исполняемости страницы:

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

aslrdynamicbase

aslrdynamicbase выводит загруженные модули и указывает, поддерживает ли каждый из них ASLR в Windows Vista и Server 2008. Если стабильный адрес должен сохраняться после перезагрузки, выбирайте адрес возврата из исполняемого файла или DLL без ASLR. От этого может зависеть, будет ли эксплойт надёжным или сработает лишь один раз.

pvefindaddr

pvefindaddr — мой собственный PyCommand. Даже эта ранняя версия поддерживает несколько полезных операций:

• p: находит все сочетания pop pop ret и автоматически исключает модули SafeSEH. Необязательный регистр сужает набор сочетаний; необязательный модуль ограничивает поиск, даже если в нём используется SafeSEH.

• j: находит сочетания jmp, call и push; ret для регистра, при необходимости только в одном модуле.

• jseh: находит последовательности, пригодные для обхода SafeSEH.

• nosafeseh: выводит загруженные модули, не защищённые SafeSEH.

Запустите PyCommand без аргументов и изучите синтаксис в окне Log data:

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

Другие полезные команды Immunity

Команда !packets перехватывает сетевой трафик и определяет функцию, отвечающую за его отправку или приём. Присоедините Immunity к Firefox, выполните !packets, продолжите выполнение и откройте какой-нибудь сайт. Перехваченные пакеты появятся в отдельном окне:

Команда !safeseh выводит исполняемые модули и их состояние SafeSEH. После её запуска откройте Log data:

Удачной охоты!

• Cookie стека через параметр компилятора /GS.

• SafeSEH через параметр компоновщика /SAFESEH.

• Structured Exception Handler Overwrite Protection (SEHOP).

• Программное и аппаратное предотвращение выполнения данных (DEP).

• Рандомизация адресного пространства (ASLR).

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

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

Защита cookie стека /GS

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

В эпилоге сохранённое значение сравнивается с ожидаемым cookie. Последовательное переполнение до адреса возврата сначала перезаписывает cookie; несоответствие обнаруживается до RET, и процесс завершается.

Для снижения затрат компилятор защищает функции с подходящими строковыми буферами или _alloca. Малые буферы и некоторые массивы целых чисел или указателей могут остаться без cookie. /GS также меняет порядок локальных переменных, чтобы уязвимые буферы при прямом переполнении реже повреждали другие локальные данные и аргументы.

Способы обхода cookie стека

Возможные слабости зависят от программы и вывода компилятора:

• Вызвать исключение и получить управление через перезаписанную запись SEH до проверки cookie.

• Произвольной записью заменить и главный cookie в .data, и копию в стеке.

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

• Повредить объекты в кадре вызывающей функции, включая указатель объекта или vtable, используемые до возврата защищённой функции.

• Вычислить cookie с недостаточной энтропией.

• Повторно использовать статичный в целевом окружении cookie.

Обход через обработку исключений

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

При этом нужно удовлетворить или обойти защиту SEH. Классическая запись направляет обработчик на POP POP RET, а nSEH содержит короткий переход. В зависимости от регистров возможны варианты:

Исторические команды pvefindaddr jseh и jseh all помогают искать такие последовательности.

Замена cookie

Если уязвимость даёт контролируемую четырёхбайтовую запись, эксплойт может заменить главный cookie в .data и записать то же значение в текущий кадр. Это значительно сильнее обычного последовательного переполнения: нужно управлять и адресом, и значением.

Незащищённые буферы и данные вызывающей функции

Эвристики компилятора защищают не каждый локальный объект. Массивы указателей или чисел и малые буферы могут пропускаться. Полезными целями остаются объекты вызывающей функции: повреждение объекта и его vtable может передать управление при виртуальном вызове до текущей проверки cookie.

Отладка защиты cookie стека

Скомпилируйте простую уязвимую консольную программу в Visual C++ 2008 с /GS и без него. Функция с небезопасным копированием в защищённой сборке получает дополнительные инструкции пролога и эпилога.

Типичный защищённый пролог:

Эпилог отменяет преобразование кадра и вызывает проверку:

Демонстрация 1: обработка исключений

Пример basicbof.cpp содержит уязвимый strcpy в GetInput. После копирования в локальный буфер повреждённые данные снова копируются в меньший выходной буфер. Функция также устанавливает обработчик исключения приложения.

Без /GS и обработчика длинный аргумент вызывает обычную перезапись сохранённого адреса возврата.

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

Установка обработчика

При входе пролог сохраняет предыдущий указатель кадра и связывает новую запись исключения через FS:[0]. Запись содержит указатель на предыдущую регистрацию и процедуру обработчика.

Второе копирование достигает недоступной страницы. В этот момент используется повреждённая цепочка SEH, а эпилог /GS ещё не выполнялся.

Использование SEH до проверки cookie

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

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

Демонстрация 2: вызов виртуальной функции

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

Демонстрация по исследованию Алекса Сотирова и Марка Дауда размещает объект рядом с уязвимыми данными. Переполнение заменяет его указатель vtable контролируемым адресом. Последующий виртуальный вызов разыменовывает поддельную таблицу и перенаправляет выполнение.

SafeSEH

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

SafeSEH защищает выбор обработчика, а не стек. Классические обходы используют одно из условий:

• Загруженный модуль собран без SafeSEH и содержит нужную последовательность.

• Адрес находится вне диапазонов всех модулей, и таблицы SafeSEH к нему не применяются.

• Логика приложения или отдельный примитив повреждения предоставляет другой путь управления.

Адрес вне загруженных модулей

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

SEHOP

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

Обход SEHOP обычно требует восстановить правдоподобную цепочку с терминатором, совместимым с процессом и ОС. Это отличается от SafeSEH: SafeSEH проверяет адреса обработчиков, SEHOP — структуру цепочки.

Предотвращение выполнения данных

DEP помечает страницы данных, включая стек и кучу, неисполняемыми. Аппаратная DEP использует бит NX/XD процессора. Переход EIP прямо в шелл-код неисполняемого стека вызывает нарушение доступа.

Стратегии обхода DEP

Исторические подходы:

• Возврат в библиотечный код, выполняющий действие без внедрённого кода.

• Вызов ZwProtectVirtualMemory или родственного API для исполняемости страницы нагрузки.

• Вызов NtSetInformationProcess для изменения политики выполнения там, где путь доступен.

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

Отключение DEP в Windows XP / Server 2003 SP1

В примере уязвимой службы сохранённый EIP перезаписывается после 508 байт. Процесс содержит внутренние пути ntdll, вызывающие ZwSetInformationProcess с классом политики выполнения.

Историческая вспомогательная команда pvefindaddr ищет адреса:

Предложенный стек — только начало. Создавайте его по одному адресу и проверяйте регистры после каждого возврата.

Начните с диагностического буфера:

Первая последовательность устанавливает младший байт EAX в 1 и возвращается в BBBB. Следующему этапу нужна доступная запись по [EBP-4]; неконтролируемый EBP вызывает нарушение доступа.

Добавьте последовательность вроде PUSH ESP / POP EBP / RET, чтобы EBP указывал возле контролируемого стека. Продолжайте добавлять внутренние вызовы и возвраты, пока политика не изменится и выполнение не вернётся к нагрузке.

Итоговая структура концептуально:

Цепочка работает и при отключённой аппаратной DEP, поскольку возвращается к той же нагрузке.

Отключение DEP в Windows Server 2003 SP2

Server 2003 SP2 добавляет проверки, требующие подходящих доступных для записи адресов в EBP и ESI. В показанном окружении:

Установите точку останова в соответствующем пути ntdll!LdrpCheckNXCompatibility и трассируйте цепочку. Порядок настройки регистров важен, поскольку эпилог позднее восстанавливает и использует ESI как продолжение.

После перестановки настройки EBP и ESI управление достигает маркера GGGG. EDX указывает рядом с концом нагрузки, поэтому стабильный JMP EDX достигает размещённого там короткого обратного перехода.

Обход DEP в SEH-эксплойтах

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

POP ESP переключает стек на контролируемую запись исключения, а RET начинает цепочку обхода.

Защита ASLR

ASLR рандомизирует исполняемые образы, DLL, стеки и кучи. В рассматриваемых Windows адреса образов выбираются при загрузке из конечного набора слотов. Несистемные образы участвуют при /DYNAMICBASE и наличии данных перемещения.

Историческое значение реестра MoveImages по пути:

управляет рандомизацией образов:

• 0: учитывать предпочтительные базы.

• -1: рандомизировать все перемещаемые образы.

• Другие значения: рандомизировать перемещаемые образы с IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE.

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

Частичная перезапись EIP

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

Для адреса 0x12345678 память содержит:

Если ASLR меняет 0x1234, но полезная инструкция есть в той же области 0x1234xxxx, перезапись только 0x5678 перенаправляет выполнение без знания старших байтов.

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

Модуль без ASLR

Многие сторонние приложения исторически загружали хотя бы один EXE или DLL без /DYNAMICBASE. Адреса действительно нерандомизированного модуля могут предоставить JMP ESP, CALL ESP, PUSH ESP / RET или POP POP RET.

Пример — переполнение списка воспроизведения BlazeDVD 5.1 Professional. Проверка показывает прямую перезапись возврата около смещения 260 и SEH около 608. Сравнивайте базы после перезагрузок, а не доверяйте одному отчёту.

Стабильные кандидаты показанной установки имеют базы 0x60300000, 0x61600000, 0x64000000, 0x64100000 и 0x67000000.

Для прямой перезаписи:

Для SEH определите модули без ASLR и SafeSEH:

Затем поместите стабильный POP POP RET такого модуля в обработчик, а передачу — в nSEH.

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

ASLR и DEP вместе

Уязвимость анимированного курсора показала исторический способ бороться с обеими защитами. Восстанавливаемое исключение позволяло повторять попытки и перебрать рандомизированный адрес отключения DEP в ограниченном числе слотов ASLR. Метод очень специфичен и зависит от выживания приложения после неудач.

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

Egg hunting — это разновидность многоэтапного шелл-кода. Компактный первый этап, egg hunter, ищет в памяти процесса более крупную полезную нагрузку, отмеченную уникальным тегом. Найдя этот тег, hunter передаёт управление байтам, расположенным сразу после него.

Должны выполняться три условия:

1. Для hunter должна быть доступна небольшая предсказуемая область, куда можно перенаправить выполнение.

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

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

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

История и основные методы

Главным справочным материалом остаётся статья Skape Safely Searching Process Virtual Address Space. Отдельная статья описывает egg hunting только в куче.

Помните о следующих практических моментах:

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

• Не каждый способ проверки памяти работает в любой цели, поэтому тестируйте hunter в реальном процессе.

• Разным hunters требуется разный объём пространства: примерно 60 байт для метода SEH, 37 байт для IsBadReadPtr и 32 байта для вариантов с нативными системными вызовами.

Код egg hunter Внедрение SEH

Длина этого hunter составляет 60 байт; он ищет восьмибайтовое egg. Выделенное непосредственное значение — тег в формате little-endian.

Тег w00t также можно записать как \x77\x30\x30\x74. Внедрение SEH всё сильнее ограничивается SafeSEH, поэтому для новых целей Windows может потребоваться обход SafeSEH или другой hunter.

IsBadReadPtr

Длина этого hunter составляет 37 байт:

NtDisplayString

Этот 32-байтовый hunter использует нативный системный вызов для безопасной проверки памяти:

NtAccessCheckAndAuditAlarm

В следующем варианте номер службы изменён с 0x43 на 0x02:

Оба hunter с нативными вызовами продвигаются по памяти страница за страницей. Они вызывают системную службу, проверяют STATUS_ACCESS_VIOLATION, сравнивают с тегом два последовательных двойных слова с помощью SCASD и после совпадения обеих копий выполняют JMP EDI.

Реализация hunter: all your w00t are belong to us

Целью служит Eureka Mail Client 2.2q, уязвимый при получении от POP3-сервера специально сформированного слишком длинного ответа -ERR. Тестовая среда — английская Windows XP SP3 в VirtualBox.

Установите pvefindaddr в каталог PyCommands отладчика Immunity Debugger, затем создайте 2000-байтовый шаблон Metasploit:

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

Настройте Eureka на использование узла с Perl-скриптом в качестве POP3-сервера. Имя пользователя и пароль могут содержать произвольные значения.

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

Выполните:

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

В этой среде:

• Непосредственная перезапись адреса возврата происходит после 710 байт.

• Смещение может меняться в зависимости от длины настроенного имени сервера. Общая формула: 723 - length(local IP).

• ESP указывает на контролируемые данные после 714 байт.

• EDI указывает на контролируемые данные примерно по смещению 991.

• ESP указывает в стек приблизительно по адресу 0x0012cd6c; EDI указывает в секцию .data приложения около 0x00473678.

Прямой JMP EDI через 0x7E47B533 приводит к контролируемым байтам A, а не к ожидаемому хвосту, однако полезная нагрузка всё ещё существует дальше в памяти процесса.

Используйте JMP ESP по адресу 0x7E47BCAF, поместите 32-байтовый hunter в ESP, добавьте заполнение, а затем допишите w00tw00t и настоящий шелл-код:

Поместите байт INT 3 между тегом и шелл-кодом, чтобы увидеть точное место назначения. В этом запуске помеченная полезная нагрузка найдена в секции ресурсов приложения около 0x004739AD.

Настройка начальной позиции hunter

Инструкция OR DX,0x0FFF перемещает указатель поиска в конец текущей страницы. Затем INC EDX начинает поиск со следующей страницы. Обычно это полезно, но так можно пропустить полезную нагрузку, расположенную раньше в том же кадре стека.

Возможные начальные точки:

• Начало текущего кадра стека.

• Адрес, скопированный из другого полезного регистра.

• Начало кучи процесса, найденное через TEB и PEB.

• Базовый адрес образа.

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

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

Запишите исходные байты полезной нагрузки в файл и сравните их со всеми экземплярами в памяти:

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

Тестирование с более крупным шелл-кодом

Одна из причин использовать hunter — возможность выполнять полезные нагрузки, которые не помещаются в непосредственный буфер переполнения. Создайте буквенно-цифровую полезную нагрузку Meterpreter reverse TCP и подставьте её вместо шелл-кода Calculator:

Запустите соответствующий обработчик Metasploit, вызовите переполнение и дождитесь, пока hunter найдёт помеченный этап.

Реализация egg hunters в Metasploit

Модуль Metasploit для этой цели должен работать как POP3-сервер, вычислять правильное смещение из SRVHOST, выбирать зависящий от цели JMP ESP и использовать поддержку генерации egg в Metasploit.

Встроенный hunter Metasploit использует семейство методов NtDisplayString/NtAccessCheckAndAuditAlarm. Пользовательский hunter также можно передать в виде необработанного байт-кода.

Запрещённые символы и кодирование

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

Кодирование с помощью Metasploit

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

Создание декодера вручную

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

Декодер:

1. Корректирует ESP, чтобы он указывал на область, куда следует записать декодированный hunter.

2. Обнуляет EAX двумя операциями AND.

3. Использует три операции SUB EAX, value для построения каждой четырёхбайтовой группы.

4. Помещает эту группу в стек.

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

6. Продолжает выполнение с восстановленного hunter либо передаёт ему управление.

Например, последнее двойное слово hunter 75 E7 FF E7 разворачивается в E7 FF E7 75. Его дополнительный код равен 0x1800188B. Выбираются три разрешённых печатных значения, сумма которых равна этому дополнению. В каждом блоке для очистки EAX используются 10 байт, для трёх инструкций SUB — 15 байт и для PUSH EAX — один байт: итого 26 байт на двойное слово, или 208 байт для hunter из восьми двойных слов без учёта выравнивания стека.

Самодельный декодер зависит от конкретного набора запрещённых символов, требуемой коррекции стека и компоновки цели. Размер этого примера — около 220 байт, то есть намного больше исходного hunter.

Преобразование Unicode

Egg hunting может быть возможен в двух сценариях, когда уязвимый путь преобразует ввод в Unicode.

ASCII-полезная нагрузка остаётся в памяти

Некоторые приложения сохраняют исходный ввод перед преобразованием другой его копии. Используйте !pvefindaddr compare, чтобы найти неповреждённую ASCII-полезную нагрузку. Преобразуйте в Venetian shellcode только hunter, оставив w00tw00t и конечную полезную нагрузку в ASCII.

Поскольку ввод Unicode допускает вставленные нулевые байты, настройку начального адреса hunter иногда можно изменить проще, чем в пути только с ASCII.

И hunter, и полезной нагрузке требуется безопасное для Unicode кодирование

Если неповреждённой ASCII-полезной нагрузки нет, отдельно закодируйте hunter и конечный шелл-код для пути Unicode. Убедитесь, что восстановленный hunter ищет точное представление маркера в памяти и что после второго тега выполнение правильно выровнено.

При переполнении SEH остановитесь на цепочке SEH и передайте исключение приложению. Выполняйте трассировку, пока декодер не начнёт записывать исходный hunter в стек.

После обнаружения маркера JMP EDI приводит к следующему за ним коду выравнивания. Этот код направляет EAX на финальную заглушку декодера и использует PUSH EAX/RET для продолжения.

Omelet egg hunter

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

Каждое egg содержит:

• Свою длину.

• Номер индекса.

• Трёхбайтовый маркер.

• Один фрагмент исходного шелл-кода.

Omelet hunter также знает размер фрагмента, количество eggs и маркер. Реализация Skylined использует пользовательские обработчики SEH для восстановления после недопустимых операций чтения памяти.

Скомпилируйте повторно используемый двоичный файл hunter:

Создайте двоичный файл с конечным шелл-кодом, затем разделите его на eggs. В этом примере 303-байтовая полезная нагрузка Calculator разделяется с максимальным размером egg 127 и маркером 0xBADA55:

Первые пять байт каждого созданного egg содержат его размер, индекс и маркер. Остальные байты содержат фрагмент полезной нагрузки; неиспользованное пространство последнего egg заполняется.

Поместите мусор между eggs, чтобы смоделировать фрагменты в несвязанных областях памяти, а затем запустите omelet hunter через тот же путь JMP ESP.

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

Запишите каждое egg в файл и найдите все неповреждённые копии:

EDI уже указывает на область перед eggs, поэтому замените начальную инструкцию XOR EDI,EDI двумя NOP. Теперь hunter находит первый маркер и копирует этот фрагмент в область сборки в стеке.

Трассировка цикла копирования и проверка восстановленной полезной нагрузки выявляют вторую проблему: исходный hunter продолжает поиск после сбора всех eggs. Для исправления неиспользуемый регистр инициализируется как счётчик eggs, его значение увеличивается после каждого REP MOVSB, а при достижении ожидаемого количества выполняется переход к восстановленному шелл-коду.

Повторно скомпилируйте изменённый ассемблерный код, заново создайте eggs и замените hunter в эксплойте. Исправленный omelet находит каждый фрагмент, восстанавливает исходную полезную нагрузку, прекращает поиск и запускает Calculator.

Обучение

Автор отмечает, что эти методы рассматриваются на учебных курсах Corelan по разработке эксплойтов.

Благодарности

Спасибо Skape за исходное исследование egg hunting, Skylined за реализацию SEH omelet и Unicode-кодировщики, muts за метод декодера с ограниченным набором символов, а также исследователям, которые проверили и улучшили примеры.

WinDBG поддерживает плагины, однако найденные мной расширения, включая MSEC и Byakugan из Metasploit, не всегда работали так, как хотелось, и решали не все возникавшие задачи.

OllyDbg и Immunity Debugger заметно отличаются от WinDBG. Их графические интерфейсы устроены иначе, а плагинов доступно гораздо больше. Оценив оба, я сосредоточился на Immunity Debugger. Это не означает, что OllyDbg плох или ограничен. Просто быстро изменять его плагины сложнее, поскольку они являются скомпилированными DLL. Immunity использует сценарии Python: можно изменить файл и сразу увидеть результат.

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

Я выбрал Immunity и Python. Я не эксперт по Python, однако смог сравнительно быстро создать собственный PyCommand. Главная сложность, помимо синтаксиса Python и правил отступов, заключалась в понимании API, методов и атрибутов Immunity. Встроенная справка API в основном перечисляла имена без объяснения поведения, поэтому существующие PyCommands стали ценными примерами.

Выберите Help > Select API help file и укажите IMMLIB.HLP из каталога Documentation:

Затем используйте Help > Open API help file:

У Immunity также была онлайн-справка API с несколько более подробными сведениями. Эта статья — практическая отправная точка для создания PyCommands, а не полное руководство по API.

PyCommands используют Python 2.x. Между Python 2 и Python 3 есть существенные различия, поэтому для этих примеров обращайтесь к документации Python 2.

Создание PyCommand с нуля

Создайте <filename>.py в каталоге PyCommands Immunity Debugger. Имя файла определяет способ вызова команды.

Запуск PyCommand

В командном поле Immunity введите восклицательный знак и имя файла без .py:

Для plugin1.py выполните:

Базовая структура

Плагин обычно загружает библиотеки Immunity и другие зависимости, определяет main(args) и реализует вызываемые из main функции:

Для работы с API создайте экземпляр класса отладчика Immunity:

Я обычно объявляю его глобально сразу после импортов.

Обработка аргументов

Параметры командной строки передаются в массиве args. Используйте len(args) для подсчёта и индекс для обращения:

Запись в журналы, таблицы и файлы

Обычный вывод print не отображается в стандартном окне PyCommand. Его можно направить в окно Log Immunity, отдельную таблицу или файл. Файл удобен, если объём данных превысит буфер Log.

Запись в окно Log

Используйте метод Log() экземпляра отладчика:

В левом столбце Log обычно отображается 0BADF00D. Передайте целочисленный адрес вторым аргументом, чтобы показать другое значение:

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

Обновление журнала или таблицы

Во время ресурсоёмкого поиска по памяти Log может не обновляться до завершения операции. После Log() принудительно обновите его:

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

Запись вывода в таблицу

Задайте заголовок и столбцы через createTable(), затем добавляйте строки методом add() объекта таблицы:

Запись вывода в файл

Это обычный Python, а не API Immunity. Относительные файлы записываются в каталог программы Immunity Debugger:

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

Работа с адресами

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

Если API Immunity говорит, что метод принимает address, передавайте целое число.

Опкоды, ассемблирование, дизассемблирование и поиск в памяти

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

Можно передать ассемблерный код и позволить Immunity собрать его перед поиском либо непосредственно искать байты опкодов.

Поиск jmp esp

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

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

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

Создание ассемблера

Следующая команда объединяет аргументы, разделяет инструкции по #, ассемблирует каждую и форматирует полученные байты:

Перемещение по памяти

readMemory() принимает начальный адрес и число байтов. Этот пример читает восемь байтов по адресу, переданному в шестнадцатеричном виде:

Регистры Цепочка SEH Свойства адресов и модулей

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

Определение принадлежности адреса модулю Базовый адрес и размер модуля Проверка SafeSEH

Для этого кода требуется import struct:

Проверка поддержки ASLR Уровень доступа Имя и путь отлаживаемого приложения Влияние обновления до Immunity Debugger 1.74 или новее

Immunity планировала унифицировать регистр букв в именах методов. В PyCommands могут потребоваться следующие изменения:

Заключение

Этот справочник далеко не полон. API Immunity умеет гораздо больше, но приведённые примеры помогут быстрее начать создавать собственные PyCommands.

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

Полезные ссылки

• Архив плагинов отладчиков Tuts 4 You

• Презентация Immunity Debugger с DEF CON 15

• PEDetect и создание сигнатур в Immunity Debugger

• http://beist.org/research/public/immunity1/imm_present_jff.pdf

Шелл-код Windows обычно вызывает функции Windows API. Примеры этой главы создавались в Windows XP SP3; показанные жёстко заданные адреса относятся только к этому окружению и не переносимы.

Полезная лаборатория включает:

• Компилятор C, например LCC-Win32 или Visual C++.

• NASM.

• IDA Free или другой дизассемблер.

• Immunity Debugger или WinDbg.

• Инструменты Metasploit для шелл-кода и кодирования.

• Небольшие сценарии для записи строк опкодов в двоичные файлы и чтения двоичных файлов в виде массивов байтов C или Perl.

Проверка существующего шелл-кода

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

Подход 1: статический анализ

Запишите массив байтов в двоичный файл:

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

Затем дизассемблируйте его с помощью ndisasm, IDA, Beta3 или отладчика. Один исторический пример помещает в стек строку Write, загружает жёстко заданный адрес API из XP SP2 и вызывает его. Статического анализа достаточно, чтобы понять: код запускает WordPad. В XP SP3 абсолютные адреса указывают в другие места, и нагрузка не работает.

Подход 2: анализ во время выполнения

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

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

От C к шелл-коду

Цель примера — окно сообщения с текстом You have been pwned by Corelan и заголовком Corelan.

От C через исполняемый файл к ассемблеру

Скомпилируйте и запустите программу, затем откройте её в IDA или отладчике.

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

Помещение строк в стек

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

Для заголовка Corelan:

Точные значения зависят от заполнения. Важно различать: MessageBoxA ожидает указатели для lpText и lpCaption, а hWnd и uType являются значениями. После создания каждой строки сохраните ESP в регистре.

Помещение аргументов MessageBox в стек

Сигнатура API:

Аргументы помещаются справа налево:

Собираем всё вместе

Сначала руководство предполагает, что user32.dll загружена, и использует адрес MessageBoxA из XP SP3. Это подходит для обучения, но не для переносимого шелл-кода.

Получите опкоды отдельных инструкций с помощью nasm_shell или исторического вспомогательного ассемблера pvefindaddr.

Поместите байты в небольшой тестовый каркас C:

Остановитесь на main, войдите в косвенный вызов и проверьте созданные строки и четыре аргумента API в стеке.

Почему этот код пока ненадёжен

У первого шелл-кода несколько серьёзных проблем:

• Он содержит нулевые байты.

• Он предполагает фиксированный адрес MessageBoxA.

• Он предполагает, что user32.dll загружена.

• Он небезопасно завершается внутри эксплуатируемого процесса.

• Он может зависеть от состояния стека и регистров, унаследованного от цели.

Функции завершения шелл-кода

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

ExitProcess

ExitProcess экспортируется kernel32.dll и принимает один код завершения. На компьютере XP SP3 из руководства её адрес равен 0x7c81cb12:

Вызов исключения

Компактный, но непредсказуемый вариант — вызов нулевого адреса:

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

ExitThread

ExitThread также принимает код завершения и может закончить только текущий поток, повышая вероятность выживания процесса-хозяина. Найдите её адрес с помощью IDA, dumpbin или утилиты вроде arwin.

Извлечение экспортов DLL

dumpbin из Visual Studio выводит экспорты:

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

Создание шелл-кода с помощью NASM

Запишите инструкции в текстовый файл, начинающийся с [BITS 32]:

Соберите его как плоский двоичный файл:

Прочитайте двоичный файл как массив байтов C и проверьте в тестовом каркасе.

Работа с нулевыми байтами

Уязвимости копирования строк часто воспринимают 0x00 как терминатор. Ноль в полезной нагрузке может обрезать всё последующее. Шелл-код должен либо использовать эквивалентные инструкции без запрещённых байтов, либо кодировать данные и восстанавливать их во время выполнения.

1. Воспроизведение значений сложением и вычитанием

Чтобы создать 0x006e616c, не встраивая нулевой байт, вычтите удобное ненулевое значение и прибавьте его во время выполнения:

2. Точная запись нулевого байта

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

3. Формирование значения побайтно

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

4. XOR двух безопасных значений

Выберите два двойных слова, XOR которых даёт нужное значение:

5. Использование частей регистра

К регистру x86 можно обращаться как к 32-разрядному (EAX), 16-разрядному (AX) или младшему и старшему 8-разрядным (AL/AH). Создайте значение, не кодируя его нулевые старшие байты:

6. Выбор более коротких эквивалентных инструкций

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

В зависимости от окружающего состояния сама PUSH 1 может оказаться самым коротким вариантом.

7. Замена терминатора заполнением и отдельное помещение нулей

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

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

Кодировщики полезной нагрузки

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

Обнаружение недопустимых символов

Запишите исходный шелл-код в файл, поместите его в целевой процесс, остановитесь до выполнения и сравните с памятью:

Отчёт показывает усечение и смещения изменённых байтов. Beta3 также умеет проверять двоичный файл по известному набору запрещённых байтов.

Кодировщики Metasploit

Выведите список кодировщиков x86:

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

x86/shikata_ga_nai

Закодируйте двоичный файл с исключением нулей:

В примере 78-байтовая нагрузка превращается в 105 байт. Декодер получает собственный адрес, инициализирует счётчик цикла и ключ XOR, затем декодирует по одному двойному слову за итерацию. Ключ аддитивно изменяется, а восстановленная нагрузка записывается сразу после цикла.

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

x86/alpha_mixed

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

x86/fnstenv_mov

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

Skylined Alpha3

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

Создание собственного кодировщика

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

Найти себя: GetPC

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

CALL $+5

CALL помещает в стек адрес следующей инструкции, который извлекает POP EAX. Относительный вызов обычно содержит нулевые байты.

Прямой вызов метки

Принцип тот же; в зависимости от смещения кодировка также может содержать нежелательные нули.

CALL $+4

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

FPU FSTENV

Выполните инструкцию FPU и сохраните окружение сопроцессора. По известному смещению оно содержит адрес последней инструкции FPU:

Это короткий примитив GetPC без нулей, используемый несколькими кодировщиками.

Обратный вызов

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

Код GetPC — не формальная заготовка: именно он позволяет позиционно-независимому шелл-коду найти свои закодированные данные после копирования по непредсказуемому адресу.

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

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

Двое моих друзей из Corelan Team, TecR0c и mr_me, заметили, что этим можно воспользоваться, а TecR0c задокументировал результат процесса преобразования. Его таблица доступна здесь. Вскоре после этого мой друг _sinn3r, также из Corelan Team, применил метод при создании эксплойта для уязвимости Ken Ward.

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

Важно: прежде чем читать эту публикацию, я настоятельно рекомендую ознакомиться со статьёй в блоге abysssec.com. Без неё некоторые понятия, предположения и решения из этой публикации будут непонятны.

Подводя итог статье на abysssec.com, мы знаем следующее:

• Смещение до nSEH составляет 1022 байта.

• Можно использовать указатель на pop-pop-ret из самого исполняемого файла.

• Шелл-код присутствует в памяти в неизменённом виде.

• Для поиска и выполнения шелл-кода необходимо разместить egghunter.

Из-за ограничения набора символов мне пришлось использовать несколько переходов назад и вперёд, писать код для выравнивания ESP, создавать и запускать собственные декодеры, чтобы направить регистр на начало egghunter, а затем запускать сам egghunter.

Всё работало, но процесс был довольно сложным и трудоёмким.

Влияние преобразования набора символов

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

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

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

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

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

Рассмотрим следующий сценарий:

После перезаписи nSEH значением BBBB и SEH значением CCCC я разместил тестовый шаблон. Он состоит из большинства байтов от 0x01 до 0xFF. Я исключил лишь несколько байтов, поскольку опытным путём выяснил, что они влияют на поведение приложения при обработке полезной нагрузки:

• Перевод строки и возврат каретки.

• Прямая косая черта, обратная косая черта и двоеточие.

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

Создайте ZIP-файл с помощью приведённого сценария. Откройте Ken Ward Zipper, подключите к нему Immunity и откройте ZIP-файл.

Затем дважды щёлкните имя файла Admin accounts and passwords.txt внутри архива. Это вызовет нарушение доступа, и управление перейдёт к Immunity Debugger.

Убедитесь, что запись SEH по-прежнему перезаписана значениями BBBB и CCCC:

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

Мы видим $testpattern, размещённый в полезной нагрузке после перезаписи записи SE.

Пока всё хорошо.

Определение и документирование влияния преобразования

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

Определить и задокументировать преобразование можно двумя способами.

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

Или можно поручить неприятную работу pvefindaddr.

Загрузите pvefindaddr версии 1.27 или новее: в старых версиях есть небольшая ошибка, приводящая к неточным результатам.

Затем добавьте следующие строки в конец Perl-сценария и снова запустите его:

Теперь тестовый шаблон записан и в стек, и в файл. Поэтому pvefindaddr может сравнить их и указать изменения:

Дождитесь завершения сравнения и откройте файл compare.txt в каталоге программы Immunity Debugger.

Найдите в файле раздел, относящийся к адресу в стеке, где обнаружена полезная нагрузка; в нашем примере это 0x0012F910.

Отлично. Видно, что большинство символов в обычном диапазоне ASCII не изменились. Все значения выше 0x7f были заменены, и теперь у нас есть полный список преобразований этих байтов.

Что с этим можно сделать?

Хороший вопрос. Сделать можно многое.

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

Переходы вперёд и назад

В статьях о QuickZip и Ken Ward на abysssec.com возникала необходимость выполнять переходы вперёд или назад с помощью условного перехода. Это были короткие переходы, поэтому доступная дистанция была ограничена.

Из таблицы преобразований видно, что для перехода можно получить 0xeb: значение 0x89 преобразуется в 0xeb.

Значит, чтобы перейти вперёд, например, на 12 (0x0c) байт, можно использовать 0x89 0x0c. Во время выполнения эти два байта преобразуются в 0xeb 0x0c, то есть в переход вперёд.

Для переходов назад действует тот же принцип. Например, в nSEH можно выполнить переход назад. Найдите в compare.txt все байты, которые после преобразования дают значение, начинающееся с f.

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

Чтобы перейти назад на 12 байт, требуется 0xeb 0xf4. При использовании 0x89 0x93 во время выполнения получится именно такой переход.

Для дальнего перехода назад необходимо четырёхбайтовое смещение вместо однобайтового.

Предположим, нужно перейти назад на 800 байт. Код операции для этого: 0xe9 0xe0 0xfc 0xff 0xff.

Чтобы получить его, в полезную нагрузку необходимо записать 0x82 0x85 0x81 0x98 0x98.

Совсем неплохо, правда?

Указатели

Возможности не ограничиваются воспроизведением инструкций. Преобразованием можно воспользоваться и при записи указателей в стек. Что делать, если единственный рабочий указатель на pop-pop-ret содержит недопустимый байт или значение, которое будет преобразовано? Попробуйте обратить преобразование себе на пользу.

Предположим, нужный указатель на pop-pop-ret равен 0x0046BBFA. Нулевой байт не представляет проблемы, как и 46. Но и BB, и FA преобразуются в другие значения. Поэтому для получения после преобразования адреса 0x0046BBFA нужно записать 0x0046AFA3: AF преобразуется в BB, а A3 — в FA.

Переходы к регистрам

Код перехода тоже можно воспроизвести:

• jmp eax: 0xff 0xe0 -> 0x98 0x85

• jmp ecx: 0xff 0xe1 -> 0x98 0xa0

• jmp edx: 0xff 0xe2 -> 0x98 0x83

• jmp ebx: 0xff 0xe3 -> невозможно

• jmp esp: 0xff 0xe4 -> 0x98 0x84

• jmp ebp: 0xff 0xe5 -> 0x98 0x86

• jmp esi: 0xff 0xe6 -> 0x98 0x91

• jmp edi: 0xff 0xe7 -> 0x98 0x87

Буквенно-цифровой код GetPC?

Можно пойти ещё дальше и попробовать создать код GetPC.

Если это удастся, сложные собственные декодеры больше не понадобятся.

Код GetPC можно поместить перед любым шелл-кодом, созданным alpha2, и заставить закодированный egghunter или шелл-код работать без предварительного выравнивания регистра.

Если это сработает, экономия времени будет огромной.

Рассмотрим код GetPC с обратным вызовом, показанный в моём учебнике по шелл-коду:

Коды операций этой процедуры GetPC выглядят так:

• jmp short corelan: 0xeb 0x03

• geteip: pop esi: 0x5e

• call esi: 0xff 0xd6

• corelan: call geteip: 0xe8 0xf8 0xff 0xff 0xff

После выполнения этого кода GetPC регистр ESI будет указывать непосредственно на область после инструкции call geteip.

Снова применим преобразование:

• 0xeb 0x03: 0x89 0x03 — как видно из compare.txt, значение 03 не изменилось.

• 0x5e: без преобразования.

• 0xff 0xd6: 0x98 0x99.

• 0xe8 0xf8 0xff 0xff 0xff: 0x8a 0x?? 0x98 0x98.

Возникает небольшая проблема: ни одно преобразование не даёт 0xf8. Поэтому нужно немного изменить код — скорректировать смещения и вставить NOP-подобные инструкции.

Рассмотрим следующий код:

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

Это именно то, что требовалось. Сразу после выполнения кода ESI указывает на адрес непосредственно после процедуры GetPC. Если поместить сразу за кодом GetPC шелл-код, закодированный alpha2 с ESI в качестве базового регистра, цель достигнута.

Собираем всё вместе: улучшенный эксплойт Ken Ward Zipper

На основе знаний из первой статьи на abysssec.com структура полезной нагрузки будет следующей:

В состав первых 1022 байт входят:

• Имя файла.

• Большое количество NOP; поскольку 0x90 преобразуется в другое значение, используются NOP-аналоги, например 0x41.

• Код GetPC.

• Закодированный egghunter.

• Несколько NOP.

• Дальний переход назад, приводящий к NOP перед кодом GetPC.

В nSEH выполняется короткий переход назад, приводящий к NOP перед дальним переходом назад.

SEH перезаписывается адресом из zip4.exe, включая нулевой байт.

Мусор: несколько NOP, двойной тег, необходимый egghunter, и шелл-код.

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

Результат: больше никаких сложных кодировщиков и приёмов выравнивания регистров — только сочетание простой логики и компенсации преобразования символов:

В первой части создаётся обычный SEH-эксплойт, который затем адаптируется к ограниченному пространству после SEH с помощью egghunter. Во второй части намеренно используется обработчик из DLL операционной системы и исследуются дополнительные проблемы кодирования и надёжности, возникающие из-за этого выбора.

Примеры предназначены для исторических версий Windows и QuickZip. Адреса относятся только к показанному окружению.

Окружение и инструменты

В лабораторной среде используются:

• Уязвимая версия QuickZip.

• Windows XP SP3.

• Immunity Debugger.

• Вспомогательные средства отладчика в стиле pvefindaddr/Mona.

• Инструменты Metasploit для шаблонов и полезных нагрузок.

• Perl для создания вредоносного содержимого ZIP.

• ZIP-утилита или библиотека, позволяющая точно управлять полями имён файлов.

Ошибка

Создайте архив с длинным именем файла. Циклический шаблон позволит найти перезаписанные поля управления.

Используйте значение шаблона из nSEH или SEH, чтобы вычислить точное смещение:

Создайте архив заново с различимыми маркерами:

Создание SEH-эксплойта: пять минут работы

Классическая структура использует короткий переход в nSEH и стабильный адрес POP POP RET в SEH:

Ищите модули без защиты SafeSEH и избегайте адресов, содержащих байты, которые изменяет анализатор имён файлов.

Сработал ли эксплойт?

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

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

Пять минут работы и неприятности

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

Переход назад

Если перед nSEH достаточно неповреждённых контролируемых байтов, используйте обратный переход. Вычислите смещение относительно инструкции, следующей за переходом:

Для ближнего относительного перехода:

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

Мы можем перейти назад; что дальше?

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

Где можно разместить шелл-код?

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

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

Охотник

Используйте 32-байтовый охотник на основе NtAccessCheckAndAuditAlarm с меткой w00t:

Добавьте двойную метку перед настоящей полезной нагрузкой:

Беги, охотник, беги

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

Пока не запускайте

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

Это может занять больше минуты

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

Переход на ESP

Альтернативный путь использует стабильный JMP ESP, выравнивание стека и небольшой трамплин к охотнику. Выбранные модуль и адрес должны удовлетворять ограничениям SafeSEH, ASLR и недопустимых символов для целевой версии.

Часть 2: использование POP POP RET из DLL операционной системы

Адрес из DLL операционной системы может присутствовать на большем количестве целей, но способен привнести нулевые байты, ограничения SafeSEH, ASLR и зависящие от версии изменения инструкций. В этом разделе предполагается наличие пригодного обработчика из модуля ОС, а основное внимание уделяется ограниченному набору символов, обусловленному уязвимым путём обработки имени файла.

Чего можно ожидать?

После диспетчеризации исключения выполнение достигает области, содержащей только разрешённые печатные байты. Обычные опкоды для JMP ESP, прямые адреса API и произвольный шелл-код нельзя вставить без изменений.

Сначала первые конфеты: PPR и переход вперёд

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

Шоколадный шелл-код

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

Магия базового регистра: подготовка декодера

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

Если ESP расположен близко, скопируйте его разрешёнными инструкциями и скорректируйте арифметически. Когда непосредственные опкоды ADD или SUB запрещены, используйте последовательности, составленные из печатных кодировок POP, PUSH, AND и SUB EAX,imm32.

Определение цели декодера

Восстановленный код должен записываться после декодера или в другую безопасную область. Вычислите:

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

Формирование значений в EBX и ESP

Обнулите EAX с помощью двух масок AND, комбинация битов которых даёт ноль:

Затем сформируйте нужное двойное слово тремя операндами вычитания, состоящими из печатных символов:

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

Испорченная конфета

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

Создание декодера

Для каждого четырёхбайтового блока:

1. Разверните исходные байты в соответствии с порядком little-endian в стеке.

2. Вычислите дополнительный код.

3. Разделите его на три разрешённых двойных слова.

4. Обнулите EAX.

5. Выполните три вычитания.

6. Поместите полученное двойное слово в стек.

Размещение шелл-кода

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

Шоколад расплавился: щёлк, щёлк, взрыв

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

Заключительные замечания

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

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

Аппаратное предотвращение выполнения данных помечает страницы данных, например стек и кучу, как неисполняемые. Классическое переполнение всё ещё может перезаписать адрес возврата, но непосредственное перенаправление выполнения во внедрённый шелл-код вызывает нарушение доступа.

Возвратно-ориентированное программирование (ROP) повторно использует короткие последовательности инструкций, уже находящиеся в исполняемых модулях. Каждая последовательность заканчивается RET или другим управляемым переходом. Располагая адреса и данные в стеке, эксплойт связывает последовательности в небольшую программу, которая вызывает существующий API, изменяет разрешения памяти, копирует код или выполняет нужное действие, не запуская первоначально байты со страницы данных.

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

Аппаратная DEP в мире Win32

В 32-разрядной Windows разрешения NX/XD таблицы страниц отличают исполняемый код от данных. DEP настраивается для системы и процессов, а двоичные файлы могут включать или отключать её через флаги образа и политику API, если это допускает ОС.

Обход DEP: строительные блоки

Возможные стратегии:

• Вызвать VirtualProtect, чтобы сделать область шелл-кода исполняемой.

• Вызвать VirtualAlloc, создать исполняемую память и скопировать туда нагрузку.

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

• Вызвать NtSetInformationProcess или SetProcessDEPPolicy, если платформа позволяет менять политику процесса.

• Использовать возврат в библиотечный код, например WinExec, без выполнения внедрённого шелл-кода.

• Построить ROP-цепочку, подготавливающую аргументы API и вызывающую одну из этих функций.

Гаджет

Гаджет — полезная последовательность инструкций, заканчивающаяся RET, например:

Если ESP указывает на адрес гаджета, RET загружает его в EIP. POP EAX забирает следующее двойное слово стека, а заключительная RET — следующий адрес. Стек одновременно служит программой и данными.

У длинных гаджетов могут быть побочные эффекты:

Цепочка должна предоставить заполнение для каждой POP и учесть RET n, изменения стека, записи в память, флаги и испорченные регистры.

Функции Windows для обхода DEP VirtualProtect

Цепочке нужны адрес шелл-кода, достаточная длина, PAGE_EXECUTE_READWRITE (0x40) и доступное для записи место старого значения защиты.

VirtualAlloc

Типичные значения — MEM_COMMIT и исполняемая защита чтения-записи. Вторая операция должна скопировать или создать нагрузку в возвращённой области.

WriteProcessMemory

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

WinExec

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

Выбор оружия

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

1. Точное перезаписанное поле управления.

2. Состояние регистров и стека при первом получении управления.

3. Стабильные исполняемые модули без нежелательного перемещения.

4. Целевой API или указатель на него.

5. Доступную для записи память для выходных параметров API.

6. Надёжный адрес продолжения после возврата API.

Советы по параметрам функций

API Win32 обычно используют stdcall: аргументы помещаются в стек справа налево, CALL добавляет адрес возврата, а вызываемая функция удаляет аргументы.

При входе в VirtualProtect стек должен выглядеть так:

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

Переносимость ROP-эксплойта

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

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

От EIP к ROP Прямая перезапись возврата

При прямой перезаписи замените сохранённый EIP первым гаджетом и поместите оставшуюся цепочку сразу после него. RET каждого гаджета продвигается по цепочке.

Перезапись на основе SEH

SEH-эксплойту сначала нужен разворот стека. Последовательность обработчика POP reg / POP reg / POP ESP / RET может направить ESP в контролируемые данные записи исключения. Другие развороты используют ADD ESP,n, XCHG reg,ESP или MOV ESP,reg с последующим управляемым возвратом.

Перед началом

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

Прямой RET: версия ROP с VirtualProtect Время ROP-н-ролла

Первая цепочка вызовет VirtualProtect, сделает страницу нагрузки исполняемой и вернётся к шелл-коду.

Как создать цепочку

Начните с каркаса-заполнителя:

Если непосредственные константы содержат недопустимые символы, создайте их арифметически:

Гаджеты передачи вроде XCHG EAX,EDX, MOV ECX,EAX и PUSHAD размещают значения там, где их ожидает последовательность вызова.

Поиск ROP-гаджетов

Ищите в исполняемых секциях стабильных модулей. Среди исторических средств — pvefindaddr, msfrop и специализированные сканеры.

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

Гаджеты CALL-регистра

Гаджет с CALL EAX помещает адрес возврата в стек, а не просто забирает следующее значение. Учтите дополнительное двойное слово и очистку стека вызываемой функцией. Во многих цепочках PUSHAD / RET компактно создаёт вызов API из подготовленных регистров.

С чего начать?

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

Проверка до начала

Проверяйте каждый адрес гаджета отдельно с маркерами:

• Нужная граница инструкции.

• Все изменяемые регистры.

• Точное новое значение ESP.

• Чтение и запись памяти.

• Флаги для последующих условных операций.

• Изменение стека из-за RET n.

Всем сохранять спокойствие, это ROP-ограбление

Типичная регистровая цепочка VirtualProtect подготавливает:

Затем PUSHAD предсказуемо помещает значения регистров в стек, а RET передаёт выполнение последовательности вызова API.

Прямой RET, версия 2: NtSetInformationProcess

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

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

Прямой RET, версия 3: SetProcessDEPPolicy

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

Прямой RET, версия 4: ret-to-libc с WinExec

Не каждому эксплойту нужен внедрённый шелл-код. Если строка команды находится в контролируемой памяти, цепочка может напрямую вызвать WinExec:

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

SEH-ROP с WriteProcessMemory

Демонстрация SEH использует WriteProcessMemory, чтобы скопировать шелл-код в исполняемую свободную область кода и вернуться туда.

Вызов ошибки

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

Разворот стека

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

ROP NOP

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

Создание цепочки WriteProcessMemory

Желаемый кадр функции:

Создайте или исправьте каждое значение гаджетами, вызовите WriteProcessMemory и вернитесь к назначению.

Egghunter

Обычный egghunter выполняется из памяти данных и тоже блокируется DEP. Сочетать поиск с ROP-обходом можно двумя общими способами.

Сценарий 1: исправление egghunter

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

Сценарий 2: ROP перед шелл-кодом

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

Unicode

Преобразования Unicode ограничивают адреса гаджетов, непосредственные значения и выравнивание так же, как обычный шелл-код. «Венецианское» выравнивание может привести к развороту стека или компактной цепочке первого этапа, но каждый вставленный ноль и изменённый байт нужно моделировать. ROP не отменяет необходимости понимать преобразование уязвимого ввода.

ASLR и DEP Теория

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

• Модуль без ASLR.

• Утечка информации с базой рандомизированного модуля.

• Частичная перезапись, сохраняющая рандомизированные старшие байты.

• Указатель модуля в полезном регистре или позиции стека.

• Специфичное для цели перебираемое условие с восстановлением после неудачи.

Пример

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

Другая литература

Исходная статья направляет к исследованиям возвратно-ориентированного программирования, return-to-libc, внутреннего устройства DEP Windows, создания гаджетов и обходов защиты памяти. Эти материалы важны, поскольку версии компиляторов и механизмы защиты ОС продолжают развиваться.

Заключительные замечания

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

Сегодня я хочу поделиться собственной реализацией «из яиц в омлет», объяснить её работу и показать использование в самостоятельном эксплойте или модуле Metasploit. Это изложение моих заметок и инструментов, а не полноценное руководство, поэтому сначала полезно прочитать часть 8.

Основные понятия

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

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

Раньше мне не приходилось использовать охотник за омлетом в настоящем эксплойте, если не считать описания идеи в части 8. Затем я столкнулся с ошибкой со следующими свойствами:

• Для исполняемого кода было доступно лишь около 300 байт. Этого достаточно для многих полезных нагрузок, но не для надёжного модуля Metasploit с поддержкой более крупных нагрузок вроде Meterpreter.

• В памяти можно было разместить несколько дополнительных блоков примерно по 200 байт. Работали десять блоков, обеспечивая не менее 2000 фрагментированных байтов. Универсальный эксплойт становится возможным, если разделить любую полезную нагрузку на части, а в первоначальную 300-байтовую область поместить охотник «из яиц в омлет».

Это идеальный сценарий для охотника за омлетом.

Ранее Skylined написал охотник за яйцами омлета. Я адаптировал его для Windows XP SP3, однако он работал лишь в некоторых случаях и ненадёжно обрабатывал нарушения доступа при обходе памяти, поэтому я написал собственный.

Мой охотник «из яиц в омлет»

Охотник исходит из следующих предположений:

• Поиск начинается в конце текущего кадра стека. Если яйца находятся в том же кадре, измените начальное значение EDX — указателя поиска по памяти.

• Он обходит всё адресное пространство и завершается неудачей, если какое-либо яйцо не найдено.

• Яйца должны располагаться в памяти в правильном порядке. У каждого есть уникальная метка с порядковым номером.

• Размер яйца не может превышать 127 байт: четырёхбайтовая метка и до 123 байт полезной нагрузки. Это ограничение позволяет избежать нулевых байтов в охотнике.

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

Ассемблерный код в corelanc0d3r_omelet.asm:

Размер кода — 96 байт, и в нём нет нулевых байтов. В коде жёстко заданы два значения: количество яиц и число байтов полезной нагрузки в каждом яйце.

Выберите egg_size не более 123. Вычислите количество яиц целочисленным делением длины шелл-кода на egg_size, затем прибавьте единицу, если nr_eggs * egg_size всё ещё меньше размера шелл-кода.

Скомпилируйте охотник с помощью NASM:

Используйте pveReadbin.pl, чтобы преобразовать двоичный файл в формат для эксплойта:

Как он работает?

Сначала охотник находит конец кадра стека: копирует ESP в EDI и устанавливает младшие 16 бит EDI в 0xffff. EDI становится адресом назначения для собранных яиц. EDX отслеживает позицию поиска в памяти и первоначально получает тот же адрес.

EBX содержит количество яиц, которые нужно найти. Чтобы избежать нулевых байтов, фактически там хранится nr_eggs + 1, что позволяет сравнивать значение с единицей. Счётчик одновременно служит частью метки и числом оставшихся яиц.

Для обработки недоступных адресов поиск использует технику NtAccessCheckAndAuditAlarm со смещением 0x2 в KiServiceTable. Охотник проверяет EDX и, если адрес доступен для чтения, ищет четырёхбайтовую метку.

Ожидаемая метка:

Порядковое значение равно 1 + число оставшихся яиц + 1. Для трёх яиц метки будут следующими:

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

После обнаружения подходящей метки инструкция rep movsb копирует egg_size байтов по адресу EDI. ECX содержит количество копируемых байтов, а ESI указывает на источник. Во время копирования ESI и EDI увеличиваются, поэтому EDI остаётся на правильной позиции назначения для следующего фрагмента.

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

Константа 0x77303001 в охотнике не может совпасть с меткой яйца. Поэтому найденная метка относится именно к яйцу, а не к самому охотнику.

Реализация в самостоятельном эксплойте

Определите количество контролируемых байтов в каждом блоке памяти и число создаваемых блоков. Подход работает, когда number_of_blocks * size_of_each_block — при ограничении каждого фрагмента полезной нагрузки 123 байтами — не меньше полного размера шелл-кода.

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

Добавьте порядковую метку перед каждой частью. Для трёх фрагментов представление Perl выглядит так:

Разместите фрагменты в памяти так, чтобы охотник встретил сначала часть 1, затем часть 2 и наконец часть 3.

В pvefindaddr 2.0.7 появилась команда omelet, автоматизирующая разделение и добавление меток. Укажите файл с необработанным двоичным шелл-кодом, при необходимости выберите размер яйца и трёхбайтовую постоянную метку. По умолчанию используются 123 байта полезной нагрузки и метка 773030.

Для 224-байтового файла C:\tmp\calc.bin при доступных блоках по 100 байт остаётся 96 байт полезной нагрузки и четырёхбайтовая метка. Чтобы использовать 55DABA, представляющее 0xBADA55, выполните:

Готовые для Perl фрагменты записываются в omelet.txt:

Модуль Metasploit: трудный путь

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

Если сам созданный охотник необходимо закодировать для удаления недопустимых символов, используйте:

Примесь Metasploit: простой путь

Чтобы упростить процесс, я написал класс и примесь Metasploit с дополнительными возможностями настройки. Начиная с ревизии 10106, примесь omelet официально входит в Metasploit.

Она состоит из следующих файлов:

• /framework3/lib/msf/core/exploit/omelet.rb

• /framework3/lib/rex/exploitation/omelet.rb

Центральный загрузчик примесей подключает:

В ревизии 10106 или новее вручную изменять загрузчик не нужно. Подключите класс в модуле эксплойта:

Создайте охотник и яйца:

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

Доступные параметры:

• eggsize: число байтов полезной нагрузки в яйце, по умолчанию и не более 123.

• eggtag: три постоянных символа метки, по умолчанию 00w.

• searchforward: направление поиска, по умолчанию true; укажите false для поиска назад.

• reset: начинать поиск с исходного адреса после каждого яйца, что позволяет располагать яйца не по порядку; по умолчанию false.

• startreg: использовать адрес из указанного регистра как начальную позицию поиска. Если параметр не нужен, не передавайте его вместо пустого значения.

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

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

Пример:

Функция возвращает два элемента: omelet[0] — охотник, а omelet[1] — массив яиц. Поместите охотник в исполняемый буфер и переберите фрагменты:

Благодарю команду Corelan, jduck и HD Moore за ответы на мои вопросы о Ruby и Metasploit, а также всех остальных, кто помогал.

Тестируя ROP-гаджеты при создании эксплойта с обходом DEP для WM Downloader, он хотел узнать, можно ли заранее определить объём padding, необходимый для правильного выравнивания и настройки стека, если гаджет завершается инструкцией RET со смещением.

По-видимому, многие полагали, что смещение RET нужно компенсировать непосредственно после указателя на гаджет. Это неверно.

Давайте визуализируем проблему и попробуем вывести общее правило.

Предположим, ROP-цепочка содержит следующие три вымышленных гаджета:

• 77C1E842: PUSH EDI / POP EAX / POP EBP / RET

• 77C1D7F5: ADD EAX,20 / POP EBP / RET

• 71AA2526: XOR EAX,EAX / INC ESI / RET

• ...

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

Для приведённых выше указателей стек будет выглядеть так:

Пока ничего особенного.

Что изменится, если гаджеты завершаются RET со смещением? Как это повлияет на выравнивание стека и padding между двумя указателями на гаджеты?

Ответ

Предположим, теперь у нас есть такие гаджеты:

• 77C1E842: PUSH EDI / POP EAX / POP EBP / RETN + 4

• 77C1D7F5: ADD EAX,20 / POP EBP / RETN + 8

• 71AA2526: XOR EAX,EAX / INC ESI / RET

• ...

Первый гаджет завершается RETN+4, второй — RETN+8. Посмотрим, как изменится структура стека.

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

Спасибо sickn3ss за вопрос и совместное документирование этого поведения!

Думаю, все согласятся, что сегодня обход DEP (и ASLR) уже не роскошь. По мере того как операционные системы вроде Windows 7 набирают популярность, разработчикам эксплойтов приходится иметь дело со всё большим числом механизмов защиты памяти, включая DEP и ASLR. С точки зрения защиты это хорошо. Но все мы знаем, что при удачном стечении обстоятельств существуют способы их обойти.

Один из самых популярных методов обхода DEP — ROP, также называемый «повторным использованием кода». Как объяснялось в одной из моих предыдущих статей, суть техники состоит в создании цепочки указателей. Каждый из них указывает на уже существующую последовательность исполняемых инструкций, а вместе они подготавливают аргументы функции, позволяющей отключить или обойти DEP.

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

Наиболее важные для этого функции в Windows 7:

• VirtualProtect — изменяет защиту заданной области.

• VirtualAlloc вместе с функцией копирования или перемещения шелл-кода в новую область. В зависимости от вида полезной нагрузки для этого подойдёт одна из функций: strcpy(), strncpy(), memcpy(), memmove() и другие.

За несколькими исключениями это почти все варианты. NtSetInformationProcess() и SetProcessDEPPolicy() в Windows 7 больше использовать нельзя.

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

Сегодня я подробнее расскажу об использовании egghunter в эксплойте, обходящем DEP.

Что делать, если нужен egghunter?

Как объяснялось в упомянутом руководстве, выполнение egghunter не отличается от выполнения другого шелл-кода. Однако нужно решить дополнительную проблему.

На снимке ниже видно, что по умолчанию сразу после обнаружения яйца — вашей настоящей полезной нагрузки — в памяти egghunter просто переходит к нему (jmp edi).

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

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

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

Поэтому я выбрал короткий путь и изменил реализацию egghunter в Metasploit, позволив помечать найденное яйцо как исполняемое. Идея такова:

• Поскольку вам уже пришлось каким-либо способом сделать исполняемым сам egghunter, вы смогли получить указатель на нужную функцию Windows: VirtualProtect(), VirtualAlloc(), strncpy(), memcpy() и так далее.

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

Чтобы эта идея сработала, перед запуском egghunter достаточно поместить указатель на VirtualProtect() либо на одну из функций копирования или перемещения в регистр.

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

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

Использование в Metasploit

Сначала обновите репозиторий Metasploit и убедитесь, что используете ревизию 12637 или новее.

Вот как это работает.

Общая схема

Для создания egghunter в Metasploit необходимо:

• Подключить в модуле примесь Egghunter.

• Создать хеш с параметрами яйца, которые будут переданы процедуре создания egghunter в Metasploit.

• Вызвать процедуру создания egghunter.

• Разместить охотник и яйцо в полезной нагрузке.

Чтобы подключить примесь, достаточно добавить в начало кода следующую строку:

Затем задайте параметры:

Дополнительные параметры, позволяющие управлять техникой обхода DEP:

Обязательный параметр

:depmethod => "function"

Вместо function можно указать одно из следующих значений:

• virtualprotect

• copy

• copy_size

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

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

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

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

Необязательные параметры

:depreg => reg

Здесь reg — допустимый регистр. Если параметр не указан, код предполагает, что указатель API находится в ESI. Если регистр указан, egghunter начинает работу с перемещения двойного слова из этого регистра в ESI.

:depsize => value

Здесь value — числовое значение размера, которое будет передано вызываемой функции. При использовании метода DEP copy этот параметр игнорируется. Как объяснялось выше, если параметр не указан, для метода virtualprotect используется (payload.length * 2), а для метода copy_size — payload.length.

:depdest => reg

Здесь reg — допустимый регистр. Этот регистр указывает на местоположение egghunter и может служить адресом назначения для операции копирования или перемещения после обнаружения яйца. Параметр работает только с методами copy и copy_size и избавляет egghunter от необходимости использовать процедуру GetPC для поиска собственного адреса, немного сокращая код.

VirtualProtect()

Для VirtualProtect() указатель на функцию должен находиться в одном из регистров, по умолчанию в ESI. Остальные параметры создаются во время выполнения.

При использовании функции VirtualProtect() созданный egghunter выглядит так:

Вместо непосредственного перехода на EDI он подготавливает в стеке аргументы для VirtualProtect и вызывает функцию. Поскольку указатель на шелл-код уже находится в EDI, его можно использовать для параметров lpAddress и returnTo.

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

Выделение памяти и Copy_to_self()

Эта техника основана на следующей идее:

• С помощью ROP-цепочки выделяется исполняемая память, куда копируется egghunter.

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

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

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

Предположим, указатель на strcpy() находится в EDI, а поскольку egghunter только что скопирован в новую исполняемую область памяти, указатель на неё находится в EBP. Параметры egghunter будут выглядеть так:

Созданный для strcpy() egghunter выглядит так:

Сначала указатель на strcpy() сохраняется в ESI, чтобы его можно было вызвать позднее. До адреса 100B001E выполняется обычная процедура egghunter, находящая двойную метку в памяти. Затем указатель на яйцо в EDI помещается в стек.

Параметром depdest мы сообщили охотнику, что яйцо можно скопировать по адресу из этого регистра. В нашем случае это EBP. Код дважды помещает его в стек: один раз как аргумент returnTo, второй — как адрес назначения для strcpy(). Наконец, значение EBP также переносится в EDI, поэтому если полезной нагрузке требуется bufferregister, можно по-прежнему использовать EDI.

Операция копирования или перемещения возьмёт шелл-код и запишет его поверх кода охотника либо в любое другое указанное место, а затем перейдёт — вернётся — к нему.

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

Как объяснялось выше, при использовании техники copy сначала нужно найти способ выделить память RWX и скопировать туда охотник. Выделите достаточно пространства, чтобы в нём поместилось и яйцо.

copy_size

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

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

В конечном счёте эта процедура вызовет strncpy() со следующими аргументами:

Функция копирования или перемещения запишет яйцо поверх охотника и затем выполнит его.

Примечание: обязательно выделите достаточно места и для самого яйца.

Вот и всё!

Пример

Пример использования охотника можно найти здесь.

Благодарности

Разумеется, благодарю команду Corelan, вдохновляющую и мотивирующую меня продолжать, Lincoln за начало работы над модулем msf (см. раздел «Пример») и _sinn3r за тестирование изменённого охотника.

Изображение яйца: digitalart / FreeDigitalPhotos.net

После почти пяти месяцев проектирования, разработки и тестирования, а также после двух «пережитых» презентаций — на AthCon и Hack In Paris — я с огромным воодушевлением и гордостью объявляю от имени всей команды Corelan об общедоступном выпуске mona.py.

Вместе с этим анонсом мы официально объявляем, что с этого момента проект pvefindaddr прекращён.

Это не означает, что pvefindaddr уже совершенно бесполезен: в Mona пока перенесены не все его функции.

Это означает лишь то, что обновлений pvefindaddr больше не будет, а страница проекта и страница загрузки со временем исчезнут после переноса всей функциональности в Mona.

Что такое Mona?

Для тех, кто пропустил мои выступления на AthCon или Hack In Paris: Mona — долгожданная преемница pvefindaddr. Этот PyCommand для Immunity Debugger назван в честь моей дочери — уверен, сейчас она ещё слишком мала, чтобы это понимать или хотя бы интересоваться. По сравнению с pvefindaddr он содержит множество улучшений и новых возможностей.

• Полностью переработана и переписана вся функциональность поиска. Теперь поиск выполняется намного быстрее — в отдельных случаях до 20 раз.

• Улучшена интеграция различных функций и классов PyCommand. Например, функция suggest сразу попытается найти указатель, который должен привести к payload.

• Значительно расширены возможности точной настройки поиска. Теперь можно задавать критерии модулей: включать или исключать из поиска модули с ASLR, rebasing, системные модули и модули с SafeSEH. Можно задавать критерии указателей (ascii, asciiprint, unicode, nonull, upper, lower, numeric и другие), а также список bad characters, чтобы исключить указатели, содержащие хотя бы один из них. Это позволяет рассматривать указатели как данные на стеке и применять к ним те же правила, что и при кодировании payload, например с помощью Metasploit msfencode.

• Мы реализовали конфигурационный файл. В нём можно задать два параметра. workingfolder определяет папку для выходных файлов; если добавить в путь %p, во время выполнения он будет заменён именем процесса. Второй параметр, excluded_modules, содержит список модулей, исключаемых из всех поисковых операций: расширения оболочки, гостевые инструменты виртуальных машин и так далее.

• Генератор ROP-гаджетов полностью переписан. Он по-прежнему создаёт rop.txt, а также несколько дополнительных файлов: rop_suggestions с разбитыми по категориям гаджетами, которые, согласно нашему опыту, особенно часто нужны при создании ROP-эксплойта, и rop_virtualprotect с ROP-цепочкой, если генератор сумел найти указатель для загрузки значений и указатель на PUSHAD. Кроме того, инструмент позволяет искать stack pivot с заданными минимальным и максимальным смещениями и пытается находить статические, надёжные указатели на указатели интересующих функций для обхода DEP (VirtualProtect, VirtualAlloc и других). Иными словами, Mona автоматизирует ROP. Уверен, многие специалисты по безопасности давно ждали такую возможность. Она пока не идеальна во всех ситуациях, но уже способна сэкономить огромное количество времени.

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

У нас также есть хорошие идеи по расширению функциональности и дополнительным улучшениям для версии 1.1, так что следите за новостями. А пока можете посмотреть слайды презентации, которую я использовал на AthCon и Hack In Paris. Они дают краткое представление о нашей работе и её результатах.

Скачать слайды презентации.

Во время презентации я показал три видео:

• Демонстрация 1: pvefindaddr suggest

• Демонстрация 2: mona suggest

• Демонстрация 3: автоматизация ROP

Где скачать?

Страница проекта Mona находится здесь: github.com/corelan/mona.

Существуют две версии Mona: стабильная версия release и версия разработки trunk. Если вам нужны самые свежие изменения и вы готовы к тому, что что-нибудь может быть сломано, выбирайте вторую.

В любом случае функция !mona update позволяет загрузить последнюю версию той ветки, которая установлена в вашей системе.

Команде Corelan нужна ваша помощь!

В последние недели мы тестировали PyCommand, но это не означает, что в нём нет ошибок. Если вы обнаружили проблему или хотите предложить новую функцию либо улучшение, свяжитесь с нами: peter [dot] ve @ corelan [dot] be.

Благодарности

• Команде Corelan — отличная работа, ребята!

• Моим жене и дочери — за неизменную любовь и поддержку.

• Организаторам AthCon и Hack In Paris — за возможность выступить и представить Mona всему миру.

• Всем друзьям по всему миру.

Для ясности: я не знаю, что именно произошло, и не видел доказательств, поэтому не стану делать заявлений или кого-либо судить.

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

Версия White Phosphorus

Процедура, выпущенная в составе White Phosphorus Exploit Pack, использует только гаджеты и указатель на VirtualProtect из msvcr71.dll. Эта конкретная версия DLL не выполняет rebasing и не поддерживает ASLR, поэтому отлично подходит для универсального обхода DEP и ASLR — при условии, что в ней есть все гаджеты, необходимые для обобщённой ROP-процедуры.

Если целевое приложение загружает именно эту версию DLL или вы можете каким-либо способом заставить его сделать это, ROP-цепочка позволит универсально обойти DEP и ASLR.

Immunity Inc опубликовала этот метод обхода на своём сайте. Процедура выглядит так:

(22 двойных слова.)

Поводом послужили «инцидент» с программой вознаграждений Metasploit, опубликованный всего несколько часов назад материал Abysssec и тот факт, что Immunity уже раскрыла процедуру. Поэтому я решил самостоятельно изучить вопрос и проверить, можно ли построить альтернативный обход DEP/ASLR на основе msvcr71.dll.

Альтернативная версия с mona.py

Я подключил Immunity Debugger к приложению, загрузившему DLL, и воспользовался mona.py, чтобы создать базу ROP-гаджетов и сгенерировать ROP-цепочку.

Вариант White Phosphorus не содержит нулевых байтов, поэтому я постараюсь добиться того же.

Вот результат.

Использованная команда:

Через 17 секунд я получил следующее:

Интересно: mona.py создала почти полную ROP-цепочку, используя указатели из msvcr71.dll.

Она немного длиннее варианта Immunity — поэтому да, версия White Phosphorus, скорее всего, лучше. Но я хотел лишь проверить, существует ли альтернатива.

В цепочке Mona не хватало только процедуры, которая перенесла бы адрес VirtualProtect() из EAX в ESI.

mona.py не нашла очевидных гаджетов наподобие MOV ESI,EAX, поэтому альтернативу пришлось искать вручную.

Однако, как подсказала Mona, достаточно найти гаджет, записывающий значение EAX на стек, чтобы затем забрать его в ESI.

Для этого, вероятно, понадобятся два или три гаджета: один для получения указателя стека, второй для записи значения на стек и третий для его извлечения через POP ESI.

Через несколько минут поиска в созданном файле rop.txt я нашёл два подходящих гаджета:

• 0x7c37591f: PUSH ESP # ADD EAX,DWORD PTR DS:[EAX] # ADD CH,BL # INC EBP # OR AL,59 # POP ECX # POP EBP # RETN

• 0x7c376069: MOV DWORD PTR DS:[ECX+1C],EAX # POP EDI # POP ESI # POP EBX # RETN

Это должно сработать.

С помощью этих двух гаджетов можно записать указатель на VirtualProtect() в стек и забрать его в ESI. Более того, второй гаджет и записывает, и извлекает значение. Нужно лишь направить ECX в правильное место стека и обеспечить, чтобы POP ESI забрал его оттуда.

Обратите внимание: первый гаджет требует, чтобы EAX содержал действительный указатель на читаемую область. Для выполнения этого требования достаточно сначала загрузить в EAX читаемый адрес из msvcr71.dll.

После объединения всех частей цепочка выглядит так:

31 двойное слово — на девять больше, чем в коммерческой версии White Phosphorus. Но это подтверждает мою мысль. На создание универсальной цепочки, обходящей DEP и ASLR, ушло меньше десяти минут.

Кстати, если вы не знали: при наличии других bad characters — например, если нужно исключить \x0a и \x0d — достаточно выполнить:

и получить другие указатели. Да, всё настолько просто.

Заключение

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

В этом руководстве описывается исторический набор команд Mona для Immunity Debugger. Названия и принципы команд применимы и к более новым версиям Mona, однако точные параметры могут меняться; окончательным источником истины всегда служит !mona help <command> в установленной версии.

Загрузка mona.py

Загрузите mona.py и поместите его в каталог PyCommands Immunity Debugger, обычно:

После установки или замены файла перезапустите Immunity Debugger.

Основы использования

Запускайте Mona из командной строки:

Вывод общей справки:

Mona записывает подробные результаты в окно Log, а для крупных операций — в файлы рабочего каталога.

Обновление Mona

Если команда поддерживается, используйте:

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

Настройка окружения отладчика Рабочий каталог

Задайте отдельный выходной каталог для процесса:

%p заменяется именем процесса. Раздельное хранение не позволяет шаблонам, массивам байтов и отчётам о гаджетах одной цели перезаписать данные другой.

Исключённые модули

Исключите модули, которые не следует искать:

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

Автор

Задайте имя автора для создаваемых каркасов эксплойтов и отчётов:

Глобальные параметры

Глобальные фильтры можно сочетать со многими командами.

-n: пропуск модулей

Исключает указанные модули из текущей команды:

-o: пропуск модулей операционной системы

Так вывод ограничивается модулями приложения. Принадлежность модуля ОС определяется по пути и метаданным Mona.

-p: шаблон имени модуля

Ограничивает модули шаблоном имени или пути:

-m: явный список модулей -cm: характеристики модуля

Фильтрует по механизму защиты или свойству модуля. В зависимости от команды и версии Mona характеристики могут включать SafeSEH, ASLR, перемещение базы, принадлежность ОС и исполняемость.

-cp: набор символов

Ограничивает результаты адресами или байтами, совместимыми с набором символов:

-cpb: недопустимые символы

Исключает адреса или созданные данные с запрещёнными байтами:

-x: уровень доступа

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

Выходные файлы

Mona создаёт текстовые отчёты, двоичные массивы байтов, файлы шаблонов, предлагаемые каркасы эксплойтов, файлы ROP-гаджетов и цепочек. Окно Log обычно сообщает путь к каждому файлу.

Распространённые файлы:

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

Команды a

Псевдоним для ассемблирования инструкции:

Mona выводит байты опкода заданной ассемблерной инструкции.

assemble

Ассемблирует одну или несколько инструкций. Допустимый разделитель зависит от версии; заключайте всю строку инструкций в кавычки.

bf

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

bp

Управляет точками останова Mona по адресам или шаблонам.

Когда нужна точная семантика, используйте встроенные команды отладчика bp, bu, ba и bl.

bytearray

Создаёт двоичную последовательность для проверки недопустимых символов:

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

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

compare

Сравнивает файл или созданный массив байтов с памятью:

Mona сообщает совпадения, изменённые байты, усечение и смещения. Это полезно для поиска недопустимых символов и неповреждённых копий шелл-кода.

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

config

Выводит или изменяет постоянные настройки Mona:

dump

Записывает память в файл:

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

egg

Создаёт egghunter и сведения о полезной нагрузке с меткой:

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

filecompare

Сравнивает два файла и сообщает различающиеся смещения:

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

find

Ищет байты или строки в памяти процесса либо выбранных модулях:

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

findmsp

Ищет ссылки на циклический шаблон Metasploit в регистрах, стеке, записях SEH и памяти:

Отчёт показывает вероятные смещения до полей управления и регистров. Подтвердите каждое воспроизведением с маркерами.

findwild

Ищет последовательности инструкций с подстановочными знаками:

Так можно искать семантические шаблоны без указания конкретных регистров.

getpc

Находит или создаёт последовательности GetPC, помещающие адрес относительно кода в регистр:

GetPC полезен для позиционно-независимых декодеров и шелл-кода.

getiat

Находит указатели импортированных API в таблице импорта модуля:

ROP-цепочки часто разыменовывают запись IAT вместо встраивания адреса API операционной системы.

header

Выводит сведения заголовка PE и характеристики защиты:

Проверьте базу образа, секции, характеристики, сведения о перемещениях, SafeSEH, совместимость с NX и состояние DynamicBase.

heap

Исследует кучи, сегменты, фрагменты и связанные метаданные процесса:

Вывод зависит от платформы. Страничная куча, LFH, архитектура и версия Windows изменяют структуры и поведение.

help

Показывает синтаксис, параметры и примеры для установленной версии Mona.

info

Выводит сведения об адресе, модуле или указателе:

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

j

Короткий псевдоним исторических версий для поиска инструкций перехода, эквивалентный jmp.

jmp

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

Возможные последовательности: JMP reg, CALL reg и PUSH reg / RET.

jop

Ищет гаджеты и диспетчеры программирования, ориентированного на переходы:

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

jseh

Находит указатели для передачи SEH помимо классического POP POP RET, включая переходы относительно регистров и корректировки стека:

modules

Выводит загруженные модули и свойства механизмов защиты:

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

noaslr

Выводит модули без ASLR:

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

nosafeseh

Выводит модули без SafeSEH, полезные при выборе обработчика SEH в соответствующих 32-разрядных системах.

nosafesehaslr

Объединяет предыдущие фильтры и находит модули без защиты SafeSEH и ASLR.

offset

Вычисляет расстояние между адресами или регистрами:

При создании относительных переходов используйте знаковую интерпретацию.

p, p1 и p2

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

pattern_create

Создаёт неповторяющийся циклический шаблон:

Mona записывает шаблон в файл и окно Log.

pattern_offset

Находит смещение значения в шаблоне:

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

pc

Создаёт или исследует цепочки указателей в зависимости от исторической версии. По справке команды уточните глубину цепочки и параметры цели.

po

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

rop

Ищет ROP-гаджеты в выбранных модулях и создаёт категоризированные отчёты:

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

Созданные гаджеты — лишь кандидаты. Дизассемблируйте каждый адрес и учитывайте все POP, обращения к памяти, изменения флагов и RET n.

ropfunc

Находит указатели API и последовательности инструкций для стандартных цепочек обхода DEP:

Типичные цели: VirtualProtect, VirtualAlloc, WriteProcessMemory и указатели импортированных функций.

seh

Находит совместимые с SafeSEH или незащищённые адреса POP POP RET для эксплуатации SEH:

Отчёт учитывает защиту модулей и фильтры байтов адреса.

stackpivot

Находит гаджеты, перемещающие ESP в контролируемые данные или корректирующие его на полезную величину:

Среди кандидатов: ADD ESP,n / RET, XCHG reg,ESP, MOV ESP,reg и последовательности из нескольких POP.

stacks

Исследует стеки потоков и ищет контролируемые данные или полезные указатели:

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

suggest

Анализирует текущий сбой и предлагает направления разработки эксплойта:

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

Не считайте предложения доказательством. Воспроизведите каждое смещение с маркерами и проверьте предложенный путь управления.

skeleton

Создаёт базовый шаблон сценария эксплойта с настроенным автором и метаданными цели:

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

Metasploit

Mona дополняет инструменты Metasploit для шаблонов, полезных нагрузок, кодировщиков и модулей. Используйте Metasploit для создания шелл-кода или циклических данных, а Mona — для проверки их вида в целевом процессе.

Ошибки, запросы функций и вклад в проект

Исходная статья направляет пользователей на сайт проекта Mona для сообщений об ошибках, исходного кода и участия в разработке.

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

Обучение разработке эксплойтов

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

Получение помощи

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

Mona в интернете

Исходное руководство ссылается на сайт Corelan, исходный код проекта, документацию и каналы сообщества. Поскольку Mona развивается, сравнивайте это историческое руководство с документацией установленной версии.

У egghunter две основные задачи:

• Найти и выполнить шелл-код с меткой.

• Пережить попытки чтения недоступной памяти.

В учебном материале Питера о поиске яйца в Win32 эта техника рассматривается подробно. Данная статья посвящена охотнику на основе системного вызова от Skape из работы Safely Searching Process Virtual Address Space.

Традиционный охотник проверяет память с помощью NtAccessCheckAndAuditAlarm и перед чтением адреса-кандидата проверяет возвращённое состояние:

Перед int 0x2e регистр EAX содержит номер запрашиваемого системного вызова. Прерывание переключает выполнение из пользовательского режима в режим ядра. Заглушка системного вызова может использовать как int 0x2e, так и sysenter, хотя последний вариант требует дополнительной работы.

Когда 64-разрядная Windows стала широко распространённой, многие приложения оставались 32-разрядными и выполнялись внутри слоя совместимости WOW64. Эксплуатация такого процесса в целом похожа на эксплуатацию процесса в нативной 32-разрядной Windows, но переход для системных вызовов устроен иначе.

Время исследований

При запуске wow64.dll загружает x86-версию ntdll.dll, инициализация которой загружает необходимые 32-разрядные DLL. Чтобы проверить существующий охотник, скомпилируйте эту 32-разрядную программу на C и запустите её в 64-разрядной Windows. Включение VirtualProtect позволяет тесту работать, когда DEP находится в режиме OptOut или AlwaysOn. Перед небольшой демонстрационной полезной нагрузкой расположена двойная метка w00t, а точки останова перед меткой предотвращают случайное сквозное выполнение.

Сеанс 64-разрядного WinDBG показывает как нативные модули, так и модули WOW64:

Установите точку останова в начале охотника и выполните трассировку. Вместо обычного для нативной 32-разрядной Windows поведения int 0x2e вызывает нарушение доступа:

Заглушки системных вызовов WOW64 вместо этого вызывают адрес, хранящийся в TEB по смещению 0xC0:

![32-разрядная заглушка WOW64, вызывающая FS:[0xC0]](img/2011-11-18-wow64-egghunter-04-fs-c0-call.png)

Это поле называется WOW32Reserved. Переход по нему приводит к дальнему переходу в 64-разрядный режим:

Создание egghunter для WOW64

Дизассемблирование 32-разрядной заглушки NtAccessCheckAndAuditAlarm показывает необходимую подготовку:

Первый каркас выглядит так:

NASM создаёт:

Этот черновой вариант содержит нулевые байты и, что ещё важнее, неправильно подготавливает некоторые аргументы в стеке. Журнал исключений Immunity показывает, что память проверяется не последовательно:

Трассировка wow64!whNtAccessCheckAndAuditAlarm показывает, что функция читает полную структуру параметров. Если предоставить только целевой адрес, значениями остальных аргументов станут посторонние данные из стека. В конечном счёте вызов достигает нативной функции ntdll!ZwAccessCheckAndAuditAlarm:

Адрес 0x8f000 доступен для чтения, а 0x9000 — нет:

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

Когда целевой адрес равен 0x9000, инструкция mov eax,[rcx+4] вызывает сбой по адресу 0x9004. Передача исключения возвращает управление 32-разрядному процессу, причём AL равен 0x05:

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

При проверке требуется следующая структура стека:

Требуемые значения регистров:

• EAX: 0x26 — номер NtAccessCheckAndAuditAlarm в Windows 7.

• ECX: ноль.

• EDX: адрес блока параметров в стеке; перед вызовом устанавливается равным ESP.

• EBX: 0xC0, выбирает FS:[0xC0].

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

Получившийся 47-байтовый охотник только для WOW64 выглядит так:

Универсальный охотник для нативной x86 и WOW64

Предыдущая процедура работает только под WOW64. В 32-разрядном процессе WOW64 значение CS равно 0x23, поэтому небольшая проверка архитектуры позволяет выбрать либо традиционный путь int 0x2e, либо переход WOW64.

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

Опкоды для копирования и вставки:

Исходный код, совместимый с Metasm:

Размер универсальной версии составляет 67 байт. Она больше традиционного охотника, но всё равно меньше поэтапной полезной нагрузки.

DEP

Когда DEP включена, перед переходом к найденному шелл-коду его память необходимо сделать исполняемой с помощью VirtualProtect, VirtualAlloc или другой функции обхода DEP. Техника, описанная в статье Ropping eggs for breakfast, сохраняет указатель на функцию в регистре.

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

Обновление для Windows 8

Эта статья была написана до выхода Windows 8. Начиная с Windows 8 охотник больше не работает, поскольку номера системных вызовов изменились по сравнению с Windows 7, а затем снова изменились в Windows 8.1. Можно добавить ещё одну заглушку выбора окружения, но это увеличит размер. Для современных систем предпочтительнее иной, более универсальный способ проверки памяти.

Возможности для улучшения

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

-Lincoln

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

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

Стек

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

Куча

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

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

История

Классические браузерные эксплойты популяризировали heap spraying с помощью JavaScript в Internet Explorer. Ранние методы создавали большие строки из NOP-подобных слов и шелл-кода, а затем сохраняли множество копий в массиве, чтобы выделения оставались активными.

Принцип

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

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

Среда

В первых демонстрациях используются Windows XP SP3 с Internet Explorer 6 и 7, JavaScript и отладчик, например WinDbg или Immunity Debugger.

Выделение памяти под строки Базовая процедура

Функция JavaScript unescape преобразует последовательности %uXXXX в кодовые единицы UTF-16. На x86 с порядком байтов little-endian %u0c0c помещает в память байты 0c 0c.

unescape()

Браузер хранит строки JavaScript как широкие символы. %u4142 превращается в памяти в 42 41, поэтому при кодировании шелл-кода и значений указателей необходимо учитывать порядок байтов.

Желаемая схема heap spray

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

Базовый сценарий

Массив сохраняет ссылки, поэтому сборщик мусора не освобождает строки немедленно.

Визуализация heap spray в IE6

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

Просмотр spray в отладчике

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

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

Трассировка выделения строк с помощью WinDbg

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

Тестирование того же сценария в IE7

IE7 изменяет некоторые аспекты выделения, но в продемонстрированной среде XP классический сценарий по-прежнему создаёт узнаваемые крупные блоки. Проверяйте пользовательский размер и интервалы, не предполагая, что результаты IE6 переносятся без изменений.

Составляющие хорошего heap spray

Для полезного spray необходимы:

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

• Выделения, которые остаются активными.

• Шаблон приземления, безопасный при многократном выполнении.

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

• Размеры выделений, выбранные с учётом метаданных кучи и представления строк в браузере.

• Достаточное количество блоков, чтобы покрыть вариации, не исчерпав память и не вызвав нестабильность.

• Отдельная обработка DEP и ASLR, когда она требуется.

Сборщик мусора

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

Сценарий heap spray Часто используемый сценарий IE6, пользовательский размер 0x7ffe0

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

IE7, пользовательский размер 0x7ffe0

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

Предсказуемый указатель

Эксплойт перезаписывает указатель кода, указатель vtable или поле объекта адресом, который, как ожидается, попадёт внутрь sprayed-диапазона. Указатель не должен содержать нулевые и другие запрещённые символы и должен попадать глубоко внутрь повторяющейся области, а не около границы блока.

Почему 0x0c0c0c0c?

Значение 0x0c исторически удобно, поскольку повторяющиеся байты 0x0c могут вести себя как приемлемая последовательность инструкций в соответствующих контекстах x86, адрес не содержит нулевых байтов, а %u0c0c позволяет легко создать широкую строку с этим шаблоном. Это соглашение, а не магия; пригодность зависит от режима выполнения эксплойта и компоновки цели.

Реализация spray в эксплойте Принцип

1. Создайте большую строку приземления.

2. Добавьте полезную нагрузку или ROP-цепочку.

3. Выделите множество копий и сохраните ссылки на них.

4. Активируйте уязвимость.

5. Перезапишите целевой указатель адресом из sprayed-области.

Упражнение

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

Структура полезной нагрузки Создание полезной нагрузки

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

Варианты

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

DEP

При DEP sprayed-область не является исполняемой. Добавьте перед полезной нагрузкой ROP-цепочку, которая вызывает VirtualProtect, VirtualAlloc либо копирует полезную нагрузку в исполняемую память. Перезаписанный указатель сначала должен привести к исполняемым гаджетам.

Проверка надёжности spray

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

Альтернативный сценарий heap spray

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

Совместимость браузеров и сценариев

Разные выпуски Internet Explorer используют разные движки JavaScript, поведение распределителя, защитные механизмы кучи и сборщики мусора. Сценарий, создающий идеальные блоки в IE6, в IE8 или IE9 может иначе фрагментировать, объединять или рандомизировать память.

Когда имеет смысл 0x0c0c0c0c?

Используйте его, только если контролируемый указатель может надёжно достигнуть этого диапазона адресов, а повторяющиеся байты 0x0c безопасны в контексте выполнения. Во многих эксплойтах уместнее другой адрес, последовательность выравнивания, поддельный объект или ROP-ориентированная компоновка.

Альтернативные способы spray кучи браузера Изображения

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

Bitmap spraying с помощью Metasploit

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

Heap spraying вне браузера JavaScript в Adobe PDF Reader

JavaScript в PDF предоставляет выделения строк и объектов, концептуально сходные с браузерными сценариями. Размер блоков и предсказуемость определяются поведением конкретной версии Reader.

ActionScript в Adobe Flash

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

Spraying с помощью VBA в Microsoft Office

VBA может выделять повторяющиеся строки или массивы в процессах Office. Конкретная куча и представление отличаются от JavaScript в браузере.

Heap Feng Shui и HeapLib

Heap Feng Shui формирует состояние распределителя с помощью тщательно упорядоченных выделений и освобождений. HeapLib предоставляет оболочку над этими операциями для эксплойтов Internet Explorer, помогая создавать свободные области, занимать выбранные корзины и предсказуемее размещать объекты.

Проблема IE8

IE8 вносит изменения в распределитель и браузер, снижающие надёжность старых монолитных sprays строк. Манипуляции в стиле HeapLib позволяют лучше контролировать кучу, подготавливая её вокруг уязвимого объекта.

Тестирование HeapLib в XP SP3 с IE8

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

Системы с ASLR

Heap spraying не обходит ASLR автоматически. Он может повысить вероятность того, что широкий диапазон кучи содержит контролируемые данные, однако базовые адреса куч, порядок выделений и защитные механизмы браузера всё ещё могут меняться. Комбинированным эксплойтам часто требуется утечка информации или отдельная стратегия определения адреса модуля для ROP-гаджетов.

Точный heap spraying Зачем нужна точность

Некоторые уязвимости разыменовывают указатель по фиксированному смещению внутри поддельного объекта, а не передают выполнение непосредственно в широкую зону приземления. Spray должен разместить конкретную vtable, поле объекта, длину или элемент ROP по точному смещению в каждом выделении.

Смещение заполнения

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

Поддельная vtable и указатели функций

Поместите поддельный объект по предсказуемому адресу. Его первое двойное слово может указывать на поддельную vtable в другом месте того же sprayed-блока, выбранный слот которой указывает на первый ROP-гаджет.

От EIP к ROP в куче

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

Размеры блоков

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

Точный spraying с помощью изображений

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

Защита от heap spraying Nozzle и BuBBle

Исследовательские инструменты Nozzle и BuBBle выявляют подозрительное содержимое кучи, крупные области, похожие на исполняемый код, либо повторяющиеся шаблоны указателей и инструкций. Они показывают, что обнаружение spray может анализировать семантику, а не только объём выделений.

EMET

EMET представил защитные механизмы, делающие распространённые адреса spray недоступными или защищёнными, что вынуждает эксплойты отказываться от традиционных зон приземления.

HeapLocker

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

Heap spraying в Internet Explorer 9

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

Усиленная рандомизация

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

Heap spraying в Firefox 9.0.1

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

Heap spraying в IE10 и Windows 8

IE10 и Windows 8 вводят дополнительные защитные механизмы кучи и браузера. Продемонстрированный spray создаёт контролируемые выделения, однако для эксплуатации также необходима совместимая с защитами стратегия ROP.

Обход защиты от ROP

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

Заключительные замечания

Heap spraying — это проектирование выделений памяти. Надёжный spray строится на понимании представления строк, запрошенных и полезных размеров, метаданных распределителя, сборки мусора, версии браузера, семантики целевого указателя, DEP и ASLR. Источником истины служит отладчик, а не знакомая константа вроде 0x0c0c0c0c.

Проблема заключается в следующем: исполняемый файл CGI CSUserCGI.exe является дочерним процессом IIS и запускается только по запросу пользователя. После выполнения задачи сценарий быстро завершается — прежде чем мы успеваем присоединить отладчик. Как же его отлаживать? Поможет ли настройка отладчика для JIT, то есть отладки «точно вовремя»?

Давайте проверим.

При вызове сценария CGI через HTTP видно, как он очень быстро запускается и завершается.

Попытка № 1:

Не получилось! Так как же его отладить? Способ должен существовать.

Усыпляем процесс

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

Звучит разумно — пора приступать к делу. Я открыл исполняемый файл в Immunity и выбрал подходящую функцию для перехвата (0x00401010). Мне хотелось пропустить часть первоначальных вызовов ядра и настройки окружения и сразу перейти в main().

Затем требовалось найти в .text неиспользуемое исполняемым файлом место, изменение которого не повредит другие функции и не нарушит нормальную работу программы. План состоял в том, чтобы взять существующую инструкцию вызова — в данном случае call 0x00401010 — и изменить её смещение, перенаправив вызов в область с нашей процедурой.

Я нашёл подходящее место по адресу 0x00415362, поэтому вызов по адресу 0x00414CD6 нужно изменить так, чтобы он указывал туда.

Теперь нужно найти адреса kernel32.Sleep и kernel32.IsDebuggerPresent. Это локальный патч для моей системы, поэтому искать универсальные вызовы этих функций необязательно: достаточно посмотреть их адреса в Immunity в разделе имён исполняемого файла. В моей системе Windows 2003 SP2 это 0x77e424de и 0x77e5da00. На вашем компьютере они почти наверняка будут другими!

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

Сначала я изменил смещение вызова, направив его в пользовательскую процедуру, которую собирался разместить по адресу 0x00415362:

А по адресу 0x00415362 разместил саму процедуру:

Теперь в Immunity можно щёлкнуть правой кнопкой мыши и сохранить изменения под новым именем. Я назвал файл NEWCSUserCGI.exe и поместил его в каталог сценариев CGI (C:\Inetpub\wwwroot\securecgi-bin).

Затем я переименовал исходный исполняемый файл в OLDCSUserCGI.exe, а NEWCSUserCGI.exe — в CSUserCGI.exe, то есть вернул исходное имя файла.

На этот раз я запустил демонстрацию концепции через URL — и вот он, сценарий всё ещё работает!

Теперь посмотрим на переполнение буфера и проверим работу общедоступного кода демонстрации концепции. Из описания CVE-2008-0532 от FX видно, что длинная строка после Logout+ приводит к переполнению буфера и позволяет управлять EIP.

Уязвимая функция является подпрограммой перехваченной нами функции (0x00401010). Сначала видно, как для аргумента Logout подготавливается фиксированный буфер размером 0x60.

Вызывается msvcrt.strtok, которая ищет первую строку, заканчивающуюся символом ..

Затем строка копируется в стек, и в итоге возникает переполнение буфера.

Отлично! Это оказалось простым переполнением буфера стека, а окончательный код доступен здесь.

А можно это автоматизировать?

Я подумал, что это хорошая возможность написать сценарий для автоматизации процесса либо найти альтернативный подход. Перед уходом с работы я рассказал о своей идее коллегам и поехал домой, предвкушая эксперименты на выходных. Но, видимо, у меня случился провал в памяти: я забыл, что у corelanc0d3r за плечами более 5000 строк мастерства Python в Immunity — помните mona.py? Он закончил всё ещё до того, как я добрался домой! Все заслуги здесь принадлежат ему.

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

corelanc0d3r воспользовался модулем Python pefile, который позволяет читать и обрабатывать файлы PE (Portable Executable). К сведению: этот модуль по умолчанию установлен в BackTrack и Immunity Debugger.

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

Затем он ищет место в файле с 12 последовательными нулевыми байтами. При необходимости вместо них можно искать, например, NOP.

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

Иными словами, при запуске исполняемый файл просто зависает в бесконечном цикле. При присоединении отладчика процесс приостанавливается. После этого нужно найти место вставки пользовательской ассемблерной процедуры — фактически адрес сразу после обновлённой точки входа — и либо заменить инструкцию cmp на NOP, либо изменить cmp eax,0 на cmp eax,1. После продолжения процесс начнёт выполнять свою обычную работу. Можно также позволить приложению выполняться, а затем приостановить его: оно остановится на инструкции cmp или переходе внутри пользовательской процедуры.

Запустим сценарий из cmd.exe и посмотрим, как всё работает автоматически.

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

После запуска видно, что он работает так же, как мой ручной патч.

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

Отлично! Похоже, всё работает правильно. На этом всё: это небольшая статья о возникшей у меня проблеме и её решении. Учтите, что с упакованными или закодированными исполняемыми файлами эта техника, скорее всего, не сработает.

WinDbg?

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

Допустим, вы хотите заменить инструкцию CMP на CMP EAX,1. Для этого нужно изменить один байт в памяти — в данном случае байт по адресу 0x00415337.

Присоединив отладчик и приостановив процесс, просто выполните следующую команду:

eb означает редактирование байта. Другие команды WinDbg для редактирования: ew — редактирование слова и ed — редактирование двойного слова.

После изменения нажмите F5 или введите g, чтобы процесс вышел из цикла и вернулся к исходной точке входа.

Обновление от 1 марта 2012 года

Как подсказали несколько человек в Twitter, в качестве процедуры патча можно использовать и \xeb\xfe, которая просто переходит сама на себя. Благодарю @fdfalcon и @pa_kt за полезные отзывы!

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

Список желаний

Я давно хотел запускать mona.py непосредственно из WinDbg. Если не считать мира во всём мире и справедливости для всех, это, пожалуй, следующий по значимости подарок человечеству. Ладно, возможно, это не настолько важно, но разве не было бы полезно делать вот так?

Мне нравятся интерфейсы OllyDbg и Immunity, но для некоторых задач и ошибок я также использую WinDbg. В отдельных сценариях он быстрее и надёжнее.

Около двух недель назад, добавляя новую функциональность в Mona, я не смог найти способ удалить из скрипта все breakpoints. Я спросил об этом в Twitter и сразу получил несколько ответов, в том числе от @jduck1337:

Я ответил:

Затем комментарий оставил @WanderingGlitch:

Возник вопрос: может ли Mona работать в WinDbg? Для этого нужен способ выполнять Python внутри WinDbg и замена immlib — библиотеки, предоставляемой Immunity Debugger.

PyKD

Поиск привёл меня к PyKD — расширению WinDbg с открытым исходным кодом, предназначенному для автоматизации отладки и анализа crash dump с помощью Python. Оно может работать как Python-модуль в обычном скрипте или как расширение WinDbg, позволяющее Python управлять отладчиком.

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

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

Mona 2

Corelan Team с радостью представляет Mona v2, работающую как в Immunity Debugger, так и в WinDbg: один плагин для двух отладчиков. Внимательные пользователи могли заметить изменения в предыдущие недели, а Mona уже появилась в статье Metasploit о 0day-уязвимости Internet Explorer в конце 2012 года.

Видео о выпуске доступно на YouTube.

В Immunity Debugger последнюю версию можно получить командой !mona update или загрузить из репозитория проекта Mona. В WinDbg используется тот же файл mona.py, однако для подготовки среды необходимо выполнить четыре шага:

1. Установить WinDbg.

2. Установить Python.

3. Установить PyKD.

4. Установить windbglib.py и mona.py.

WinDbg

Современные версии WinDbg входят в Windows Software Development Kit или Windows Driver Kit. В установщике SDK или WDK выберите компонент Debugging Tools. Для старой версии, которая всё ещё работает в Windows XP, используйте пакет Windows 7 Debugging Tools с WinDbg 6.2.

Используйте 32-разрядный WinDbg. В Windows 7 или 8 он обычно расположен в одном из следующих каталогов:

Python и PyKD для WinDbg

Для Mona под WinDbg требуется Python 2.7. Immunity Debugger 1.8x обычно устанавливает необходимую среду выполнения. В противном случае установите Python 2.7 отдельно. Я рекомендую дистрибутив из комплекта Immunity, поскольку именно в этой среде велась разработка.

WinDbg выполняет Python через расширение PyKD. Загрузите совместимый пакет версии 0.2.x, а именно pykd-0.2.0.11-python.2.7.zip. В его папке x86 находятся:

• pykd.pyd

• vcredist_x86.exe

Скопируйте pykd.pyd в подкаталог winext каталога установки WinDbg:

Запустите vcredist_x86.exe, чтобы установить среду выполнения Visual Studio 2008. Найдите msdia90.dll, которая обычно находится в C:\Program Files\Common Files\Microsoft Shared\VC, и зарегистрируйте её с помощью regsvr32:

Если Mona выводит следующую ошибку символов, регистрация msdia90.dll должна её устранить:

Совместимый архив PyKD также размещался в репозитории windbglib.

windbglib.py

PyKD позволяет WinDbg выполнять Python, но Mona по-прежнему требуется соответствующее поведение immlib. Я перенёс необходимые Mona методы в windbglib.py. Это не полная реализация «один к одному», однако функциональность можно расширять, и патчи приветствуются.

Загрузите windbglib и поместите windbglib.py и mona.py в каталог WinDbg:

Скрипт установки

Lincoln написал установочный скрипт, который загружает необходимые файлы, устанавливает зависимости и раскладывает всё по нужным местам. Python 2.7 и WinDbg должны быть установлены заранее. Запустите скрипт из командной строки с повышенными привилегиями:

Скрипт доступен в проекте windbglib.

Символы WinDbg

Для некоторых функций PyKD необходима правильная настройка символов. В меню File > Symbol File Path укажите:

Локальный каталог можно изменить. Убедитесь, что в конце значения нет пробелов или переводов строк. Закройте WinDbg и сохраните workspace, когда появится запрос. Если путь символов пуст, Mona v2 попытается установить его автоматически.

Запуск Mona в WinDbg

В отличие от Immunity Debugger, перед выполнением команд WinDbg должен быть подключён к процессу. В каждом новом экземпляре WinDbg один раз загрузите расширение PyKD:

При успешной загрузке расширения WinDbg ничего не выводит. Если переименовать файл в pykd.dll, его можно загрузить так:

Для автоматической загрузки создайте ярлык WinDbg с параметром -c:

PyKD предоставляет команду !py для запуска Python-скриптов. Запустите Mona:

С этого момента Mona работает так же, как в Immunity Debugger. С помощью команды настройки Mona задайте рабочую папку.

Большой объём вывода может проявить проблему обновления интерфейса WinDbg. Надпись BUSY уже исчезает, но текст не отображается:

Прокрутите окно Command вверх и вниз, чтобы принудительно обновить его.

Обновление Mona и windbglib

Оба компонента можно обновить из WinDbg:

Исходный файл Mona одинаков для Immunity и WinDbg, но обновление затрагивает только копию, используемую текущим отладчиком. Хранить отдельные копии проще, поскольку в среде WinDbg immlib должна отсутствовать.

Что вы можете заметить

Некоторые операции стали быстрее, другие — медленнее. Сборка и дизассемблирование инструкций, а также операции WinDbg/PyKD со страницами памяти могут выполняться несколько медленнее. Mona v2 содержит оптимизированные процедуры и кэширование, уменьшающие этот эффект. Поиск по всему процессу — например, !mona suggest, !mona find без -m и !mona findwild без -m — в WinDbg всё же остаётся медленнее.

Функции deferbp и calltrace в WinDbg недоступны. Deferred breakpoints уже встроены в отладчик, а call tracing, возможно, вернётся позднее.

В Mona v2 добавлены следующие функции:

• sehbp: устанавливает breakpoints на все указатели функций SE handler.

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

• fillchunk (только WinDbg): заполняет выбранным символом heap chunk, на который указывает регистр. Например, если указатель на освобождённый heap chunk находится по адресу ESP+4, выполните !py mona fillchunk -r [ESP+4], чтобы найти его и заполнить символами A, а затем проверить, использует ли приложение этот chunk повторно.

До полной совместимости windbglib с immlib предстоит ещё много работы: в частности, необходимо перенести heap class и реализовать heap.getChunks(). WinDbg уже умеет напрямую перечислять выделенные chunks, поэтому одним из решений может быть обёртка и разбор его вывода.

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

IDA Pro?

Похожую обёртку, вероятно, можно создать и для IDA Pro с использованием её API. У меня есть лицензия IDA Pro, но у значительной части сообщества её нет, поэтому первым приоритетом стал WinDbg. Если вы хотите помочь перенести логику в IDA, свяжитесь со мной.

Благодарности

Особая благодарность Fancy, Lincoln и Matt Molinyawe за тестирование библиотеки; Ange Albertini за документацию формата PE; Wir3Gh0st за видео о выпуске; разработчику PyKD за столь быстрое добавление необходимых функций; и @dualcoremusic за музыку.

Спасибо также команде Corelan, моей семье за предоставленное время и всему сообществу.

Счастливого Рождества и Нового года!

Взламывайте всё подряд!

Вопросы о Mona в Immunity Debugger или WinDbg можно обсудить в статье и теме форума о Mona.

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

Разумеется, это не означает, что точное распыление кучи в современных браузерах невозможно. Федерико Муттис и Анибал Сакко из Core Security недавно опубликовали результаты исследования распыления HTML5, которое отлично использует новые технологии для выделения памяти в современных браузерах. Преимущество техники в том, что HTML5 не ограничен IE или Firefox и работает также в браузерах на WebKit, включая Google Chrome и Safari. Федерико и Анибал любезно предоставили мне исходный код генератора процедур распыления на основе HTML5. Сценарий можно скачать с архивной страницы файлов Corelan heapspray (HTML5Spray.zip). Но я решил не использовать HTML5 и попробовать другой подход.

Хорошо известно, что использование строк BSTR для замены освобождённого объекта при Use-After-Free в браузере может быть проблематичным. Обычно в начале объекта ожидается указатель vtable, но именно туда после замены объекта строкой BSTR попадёт поле заголовка BSTR. Иными словами, заменить объект, возможно, удастся, однако подделать указатель vtable контролируемым значением — нет.

Распространённый способ обойти проблему основан на элементах DOM. Нужно создать один или несколько элементов DOM — изображение, div и так далее — и задать свойство с полезной нагрузкой, которую требуется записать в освобождённый объект. Для изображений таким свойством может быть .src или .title, а для объектов div хорошим вариантом может стать .className.

Поскольку этот метод позволяет создавать точные выделения — разумеется, с учётом завершающего нулевого байта, — я захотел проверить, можно ли использовать его для полноценного распыления кучи. После экспериментов с размерами мне удалось написать сценарий, работающий в Firefox и всех версиях Internet Explorer. Он значительно быстрее моих старых сценариев для FF9 и IE9, а более высокая область памяти позволяет также обойти стандартную защиту EMET от распыления кучи.

Техника

Идея состоит в создании большого числа элементов DOM и присвоении определённого значения свойству элемента. Я проверял концепцию на кнопках, но не вижу причин ограничиваться только ими. Можно даже смешивать разные элементы и при необходимости варьировать размер. Поэтому я назвал технику DOM Element Property Spray. Поскольку в индустрии информационной безопасности явно любят запутанные четырёхбуквенные сокращения, получилось DEPS. Если ваше любимое средство защиты заявит, что предотвращает DEPS, вы будете знать, о чём речь. Или нет.

Использование элементов DOM для точных выделений не ново, но распыления кучи на этой основе я раньше не видел. Вкратце DEPS состоит из четырёх шагов:

1. Поместить элемент div на страницу.

2. Создать множество кнопок.

3. Задать свойство title полезной нагрузкой и с помощью substring() обеспечить требуемую длину.

4. Добавить кнопку в div.

Сценарий

Базовый сценарий выглядит так:

Копию использованных в статье сценариев можно получить на архивной странице файлов Corelan heapspray (deps_corelan_ff_ie_spray.zip). Пароль архива — infected.

Сценарий больше не пытается расположить начало ROP-цепочки по адресу 0x0c0c0c0c. Поскольку код уже нельзя выполнять напрямую без предварительного отключения DEP, а 0c0c0c0c использовать одновременно как цель разыменования vtable и NOP, адрес 0x0c0c0c0c почти утратил прежнюю ценность. Кроме того, целевой адрес вовсе не обязан состоять из четырёх одинаковых байтов. Выделения должны быть выровнены по четырём байтам, поэтому попадание в нужную точку каждый раз не должно вызывать проблем.

Элемент div в документе служит контейнером: div_container.appendChild() сохраняет элементы и их свойство title в памяти. Из-за размера выделений все фрагменты входят в список VirtualAllocdBlocks стандартной кучи.

Текущая версия сценария нацеливается на 0x20202210 или 0x20302210 в Firefox — в зависимости от числа итераций; 0x20302210 пока показывал высокую надёжность — и на 0x20202228 либо 0x20302228 в IE8/9/10 на XP, Win7 и Win8. Это интересно, поскольку для точного распыления больше не нужно различать версии IE. В моих тестах 0x20302228 оказался надёжнее 0x20202228.

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

Если требуется другое свойство элемента, можно поэкспериментировать с obj.style.fontFamily. Более того, можно одновременно задавать два разных свойства, уменьшая число итераций, необходимых для достижения предсказуемого адреса:

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

Тестовая среда

Во всех случаях использовалась последняя 32-разрядная версия конкретного браузера на полностью обновлённой ОС. Тесты выполнялись на виртуальных машинах VirtualBox и VMware и на физических компьютерах; работа подтверждалась после перезагрузки.

Все тесты Windows 7 проводились с включённой EMET 3.5, настроенной на обнаружение и предотвращение распыления кучи:

В Windows 8 проверялась стандартная установка IE10.

Результаты Firefox 18 в Windows 7

(Работает и в OS X.)

IE8 в Windows XP IE9 в Windows 7 IE10 в Windows 8

Во всех случаях структура фрагмента кучи со строкой AAAABBBBCCCCDDDD..., которая просто обозначает расположение ROP-цепочки, выглядит так:

• Заголовок фрагмента VirtualAlloc (0x20 байт).

• Мусорные данные — пробелы.

• ROP-цепочка (AAAABBBBCCCCDDDD...).

• Шелл-код (\xcc\xcc\xcc\xcc...).

• Мусорные данные — пробелы.

Анализ распыления

Что именно происходит при запуске базовой версии распыления DEPS? Выполним трассировку и журналирование в Windows XP SP3 с IE8.

Сначала изменим основную процедуру и вставим вызовы Math.atan2() для взаимодействия с WinDbg из JavaScript:

Следующая точка останова WinDbg выводит сообщения Math.atan2():

Затем установите точку останова для наблюдения за созданием кнопки:

При запуске HTML-страницы WinDbg должен вывести сообщение Creating object button и остановиться в функции CreateElement:

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

Продолжите выполнение процесса с установленной точкой. Теперь вы получите сведения обо всех выделениях одной итерации.

Одна итерация создаёт следующие выделения:

Первое интересное выделение происходит сразу после отладочного сообщения Assigning data to title.. Его стек вызовов:

Поскольку первое выделение использует jscript!JsStrSubstring, можно предположить, что его вызывает следующий код JScript из распыления:

Второе выделение происходит непосредственно перед отладочным сообщением Let's AppendChild. Его стек вызовов:

Поскольку это выделение использует SetString, можно предположить, что именно оно фактически присваивает данные свойству.

Сочетание substring, свойства элемента DOM и добавления элемента в ранее созданный в HTML-документе div обеспечивает создание копий данных и выделение для них памяти. Строка, созданная substring, со временем исчезнет, но данные, выделенные SetString(), останутся в памяти.

(Благодарю sinn3r за анализ распыления в WinDbg.)

Обновление от 6 марта 2013 года

После серии тестов в XP SP3 с IE8, Windows 7 с IE9 и IE10 и Windows 8 с IE10, включая системы с EMET и защитой от распыления кучи, мы обнаружили, что 0x0c0d0228 является надёжным адресом назначения для распыления или ROP-цепочки при 0x350 и более итерациях.

Обновлённая и улучшенная версия распыления DEPS также была принята в Metasploit Framework: New heap spray technique for Metasploit browser exploitation.

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

Сбой

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

В первую очередь полезно сохранить:

• Точный образец, вызывающий сбой, и исходный начальный файл.

• Код исключения и инструкцию, на которой произошёл сбой.

• Состояние регистров и стека.

• Версии загруженных модулей.

• Журнал мутаций фаззера.

• Конфигурацию проверки кучи.

• Полную трассировку отладчика.

Анализ данных о сбое

Отладчик сообщает о недопустимом обращении к памяти в модуле приложения. Команда !exploitable даёт первоначальную классификацию, но её результат — лишь ориентир для сортировки.

Начните с буквального прочтения инструкции, на которой произошёл сбой:

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

Используйте такие команды:

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

Определение причины исключения

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

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

Установите точку останова перед сбоем и пройдите назад по базовому блоку. Зафиксируйте происхождение каждого операнда и установите точки останова по данным на важные указатели.

Обратная разработка ошибочной функции

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

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

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

1. Найдите инструкцию, которая последней записывает значение в регистр, вызвавший сбой.

2. Проследите копирования, арифметические операции и обращения к таблицам.

3. Отметьте значения, поступившие из файла.

4. Отметьте значения, полученные из выделенных объектов.

5. Определите, происходит ли повреждение до заключительного сбоя.

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

Определение возможности эксплуатации

Опишите первопричину через явные примитивы:

• Какие байты можно контролировать?

• Контролируется ли адрес назначения полностью, частично или вычисляется из объекта?

• Сколько байтов можно записать или прочитать?

• Повторяется ли повреждение?

• Какие объекты могут оказаться в соседней или повторно используемой области памяти?

• Какие последующие виртуальные вызовы, обратные вызовы, освобождения или копирования используют повреждённые поля?

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

Перезапись указателей на функции

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

• Указатели на таблицы виртуальных функций C++.

• Поля обратных вызовов.

• Указатели на функции в объектах синтаксического анализатора.

• Таблицы импорта или диспетчеризации, хранящиеся в доступной для записи памяти.

• Указатели на объекты, которые позднее используются для косвенного вызова.

Установите точки останова на косвенные вызовы и аппаратные точки наблюдения на поля-кандидаты.

Подготовка кучи для целевого объекта

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

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

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

Состояние гонки

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

Для исследования:

1. Определите все потоки, входящие в соответствующие функции.

2. Установите точки останова на выделение, освобождение и использование объекта.

3. Записывайте идентификаторы потоков и временные метки.

4. Приостанавливайте один поток в контролируемых точках.

5. Определите, может ли другой поток освободить или заменить объект.

При сравнении с путём, в котором возникает гонка, по-прежнему важно ранее рассмотренное состояние сбоя:

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

Переполнение кучи? Не совсем

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

Вернитесь к рассмотренному ранее состоянию объекта и сравните естественную структуру кучи при отключённой страничной куче:

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

Практический процесс анализа первопричины

Полная методика выглядит так:

1. Сохраните результаты фаззинга и точное состояние окружения.

2. Воспроизведите сбой под отладчиком.

3. Классифицируйте ошибочную операцию, не предполагая, что именно она является первопричиной.

4. Минимизируйте тестовый пример.

5. Сопоставьте изменённые байты с форматом файла.

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

7. Проследите операнды ошибочной инструкции назад до входных данных и состояния объекта.

8. Найдите самый ранний недопустимый переход состояния.

9. Представьте ошибку в виде примитивов чтения, записи, времени жизни или управления.

10. Составьте перечень последующих случаев использования повреждённого состояния.

11. Оцените ограничения, связанные с размещением в куче, временем выполнения и механизмами защиты.

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

Заключение

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

Главный урок — различать место сбоя, место повреждения и место эксплуатации:

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

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

Введение

Целевое приложение — GOM Media Player 2.1.43. О проблеме сообщили GOM Labs 19 ноября 2012 года, а 12 декабря 2012 года она была исправлена.

Уязвимость обнаружена фаззингом файлов MP4/QuickTime с помощью Peach 2.3.9. Минимизированный PIT-файл Peach нацелен на уязвимую область формата файла.

Анализ данных о сбое

Peach регистрирует нарушение доступа при записи в цикле, эквивалентном следующему:

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

Такая классификация — гипотеза, а не доказательство. Нам всё ещё нужно ответить на вопросы:

• От чего зависит размер выделения?

• От чего зависит количество операций записи?

• Контролируются ли копируемые данные?

• Можно ли предсказуемо повредить соседние данные или метаданные кучи?

• Может ли полученное повреждение достичь цели, управляющей потоком выполнения?

Определение причины исключения Страничная куча

Конфигурация Peach включает страничную кучу через GFlags. Страничная куча добавляет перед выделениями структуру _DPH_BLOCK_INFORMATION, включая трассировку пользовательского стека, которая показывает цепочку вызовов выделения.

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

Для изучения стандартных метаданных и метаданных страничной кучи используйте:

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

Первоначальный анализ

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

Достаточно одной четырёхбайтовой мутации по смещению файла 0x131f. Она находится в атоме stsz, который определяется по строке FourCC stsz.

Атом размеров образцов содержит:

Исходное значение Number of Entries равно 0x3b, а изменённое — 0x80000027.

Обратная разработка ошибочной функции

Первая часть цикла читает 32-разрядное значение из файла и меняет порядок байтов, фактически преобразуя данные атома из big-endian в используемый системой порядок little-endian.

Упрощённое поведение:

Установите точки останова на оба условия выхода из цикла и на инструкцию записи. Регистрируйте источник, назначение, копируемое значение и счётчики.

Цикл выполняет 0x29 операций записи, прежде чем достигает защитной страницы полной страничной кучи. Записываемые данные поступают из файла и контролируются. Однако полезный размер фрагмента назначения составляет всего 0x9c байт.

Переключитесь на стандартную страничную кучу и изучите назначение:

Трассировка стека выделения приводит к внутренней реализации calloc, а затем к RtlAllocateHeap.

calloc получает из stsz.NumberOfEntries количество элементов и размер элемента, равный четырём:

Уязвимое умножение фактически выглядит так:

Математически:

В регистр помещаются только младшие 32 бита:

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

Определение возможности эксплуатации

Примитив обладает полезными свойствами:

• На размер выделенного фрагмента влияет переполненное умножение.

• Копируемые двойные слова поступают из файла.

• На число операций записи влияют количество элементов и структура атома.

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

Сложности:

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

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

• На размещение влияют списки lookaside и списки свободных областей Windows XP.

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

• Повреждение слишком большого объёма состояния кучи приводит к сбою до вызова полезного указателя.

Предварительные требования

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

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

Основы кучи

Выделенный фрагмент кучи XP начинается с восьмибайтового заголовка _HEAP_ENTRY. Свободные фрагменты повторно используют пользовательские данные для указателей связного списка.

Небольшие свободные фрагменты могут помещаться в список lookaside (LAL) — односвязный кэш. Более крупные фрагменты хранятся в списках свободных областей для конкретных размеров или в общем списке Freelist[0], упорядоченном по размеру.

В основании кучи находятся 128 заголовков списков свободных областей. В пустом списке и Flink, и Blink указывают на сам заголовок.

Предупредительные меры защиты

К механизмам защиты кучи Windows XP, важным для статьи, относятся:

• Cookie заголовков или закодированные метаданные в соответствующих версиях.

• Проверка безопасного исключения двусвязных свободных фрагментов из списка.

• Поведение списков lookaside, не использующее тот же путь исключения.

• Сообщения о повреждении кучи.

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

Эксплуатация с учётом приложения

Сначала отобразите последовательность выделений и освобождений анализатора GOM. Изменяйте размеры соседних атомов, чтобы позднейшее выделение повторно использовало освобождённый фрагмент нужного размера, а переполнение stsz повреждало выбранный соседний фрагмент.

Формат файла предоставляет несколько полезных средств управления:

• stsz.NumberOfEntries влияет на переполненный размер выделения и число копирований.

• Таблица размеров образцов stsz предоставляет данные переполнения.

• Длины других атомов влияют на размеры последующих выделений.

• Таблица смещений фрагментов stco предоставляет контролируемые данные для более позднего выделения.

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

Универсальные методы эксплуатации Перезапись списка lookaside

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

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

Концептуально:

Это может превратить следующую контролируемую запись анализатора в произвольную или частично произвольную запись.

Атаки на Freelist[0] Атака при вставке

Атака при вставке в Freelist[0] повреждает метаданные свободного фрагмента так, чтобы операция вставки или исключения записала указатели под влиянием атакующего. Техника ограничивается безопасным исключением и требует точного состояния кучи.

В ходе анализа отслеживается:

1. Какой соседний фрагмент освобождается.

2. Его размер и принадлежность списку.

3. Какие поля достигаются переполнением.

4. Какая последующая операция вставляет, удаляет или объединяет его.

5. Проходит ли проверка списка до выполнения целевой записи.

Атака при поиске в Freelist[0]

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

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

Например, если интерпретировать заголовок списка свободных областей возле 0x00160180 как поддельный фрагмент, получится пользовательский указатель 0x00160188. Если видимый размер фрагмента равен 0xc00, запросите 0xbf8 байт с учётом восьмибайтового заголовка.

Распределитель:

1. Обнаруживает, что настоящий первый фрагмент слишком мал.

2. Переходит по повреждённому Flink к поддельному фрагменту.

3. Читает поддельный размер.

4. Исключает элемент или сообщает о повреждении.

5. В Windows XP всё же может вернуть выбранный указатель.

После этого контролируемое выделение stco может записать данные через возвращённый указатель и достичь такой цели, как указатель CommitRoutine в куче.

Нацеливание на CommitRoutine

CommitRoutine находится в основании кучи и вызывается, когда кучу необходимо расширить. Цель атаки:

• Вернуть указатель перед CommitRoutine.

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

• Вызвать выделение, превышающее доступное зафиксированное пространство.

• Перенаправить выполнение через перезаписанный указатель.

Для показанной частной кучи эксплойт использует:

Переполнение перезаписывает заголовок и Flink следующего фрагмента. Размер предшествующего атома stsz корректируется так, чтобы неизбежное выделение 0x48 повторно использовало намеренно освобождённую запись LAL и не нарушало целевой список.

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

Доступные для записи указатели на функции как поддельные фрагменты

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

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

Многие результаты непригодны. Видимый поддельный размер, превышающий самый крупный элемент Freelist[0], может вызвать RtlExtendHeap после повреждения списка, что приведёт к раннему нарушению доступа. Указатель также может успешно перезаписаться, но не быть вызванным до сбоя обработки кучи.

Поведение безопасного исключения в XP

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

Ограничения демонстрации концепции

В статье намеренно не заявляется о надёжном выполнении кода:

• Базовый адрес частной кучи нестабилен.

• Запись от выбранного поддельного фрагмента уничтожает значительную часть _HEAP.

• Для последующих выделений требуется восстановить повреждённые поля кучи.

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

• Проверенные доступные для записи указатели на функции не вызывались до очередного сбоя диспетчера кучи.

• Многие кандидаты Mona имеют невозможные или разрушительные поддельные размеры.

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

Заключение

Первопричина — 32-разрядное целочисленное переполнение при вычислении размера выделения:

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

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

Рекомендуемая литература

• Alexander Anisimov, Defeating Microsoft Windows XP SP2 Heap Protection and DEP Bypass.

• Brett Moore, исследования атак на Freelist[0].

• Ben Hawkes, Attacking the Vista Heap.

• Chris Valasek, Understanding the Low Fragmentation Heap.

• Предыдущая статья Corelan об анализе первопричины уязвимостей повреждения памяти.

Готовясь к курсу Advanced exploit dev на Derbycon, я экспериментировал с примитивами выделения памяти в куче IE. Одна из вещей, вызывающих раздражение — или по крайней мере замедляющих исследование, — это необходимость быстро находить потенциально полезные объекты. Ведь я ищу объекты с произвольными данными или указателями на такие данные, а из-за шума сделать это не всегда легко.

Я решил добавить в mona.py несколько функций для ускоренного поиска интересных объектов. Новые возможности доступны только в WinDbg.

Чтобы получить последнюю версию Mona, выполните !py mona up. Поскольку я также перешёл на свежую версию pykd, перед запуском новой Mona, возможно, потребуется обновить pykd.pyd. При попытке запустить Mona с устаревшим pykd инструкции по обновлению должны появиться в окне журнала WinDbg.

dumpobj (do)

Первая новая функция — dumpobj. Эта команда mona.py выводит содержимое объекта и предоставляет, как я надеюсь, полезные сведения о нём. Команда принимает следующие аргументы:

Как видно из вывода !py mona help dumpobj, нужно передать как минимум два аргумента:

• -a <address>: начальная позиция — адрес объекта, хотя можно указать любое место.

• -s <number>: размер объекта. Если -s не указан, Mona попытается определить размер. Если это невозможно, она выведет 0x28 байт объекта.

Можно также попросить Mona вывести связанные объекты. Аргумент -l принимает число уровней рекурсивного дампа. Чтобы ограничить объём вывода и повысить производительность, для связанных объектов выводятся только первые 0x28 байт, если это не переопределено через -m.

Разумеется, вывести объект в WinDbg несложно. Команды dds и dc покажут данные и некоторые сведения. Но иногда этого недостаточно и требуется дополнительная работа для анализа объекта и связанных с ним необязательных объектов.

Рассмотрим пример. Допустим, по адресу 0x023a1bc0 находится объект размером 0x78 байт. Его можно вывести встроенными командами WinDbg:

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

Mona выводит тот же объект и пытается собрать дополнительные сведения о каждом двойном слове:

Некоторые значения объекта указывают на ASCII- и Unicode-строки, а ещё один указатель, по-видимому, связывает его с другим объектом (ADVAPI32!g_CodeLevelObjTable+0x4). Это гораздо полезнее dds или dc. Но результат можно улучшить ещё сильнее: попросить Mona автоматически выводить связанные объекты на любую глубину. Повторим команду с одним уровнем:

Как видно, Mona обнаружила ссылки исходного объекта на два связанных объекта и вывела их. Строки ASCII и Unicode не считаются объектами, поскольку Mona уже отображает их даже при ссылке из объекта. Результат dumpobj записывается в dumpobj.txt.

К сведению: вывод !mona info -a <address> включает результат dumpobj без рекурсивных объектов. Если нужно понять, что представляет собой адрес, получится примерно следующее:

dumplog (dl)

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

Чтобы упростить задачу, я реализовал dumplog: она разбирает журнал определённого синтаксиса и выполняет dumpobj для каждого выделенного, но не освобождённого объекта. Текущая версия dumplog не выводит связанные объекты, однако вскоре я планирую добавить эту функцию — вероятно, уже завтра.

Для dumplog нужна правильная настройка. Необходимо заставить WinDbg создать журнал в определённом формате и выполнить dumplog в том же сеансе отладки, чтобы записанные операции выделения и освобождения сохраняли актуальность.

Вывод !py mona help dumplog:

Идея состоит в записи всех выделений и освобождений кучи. В WinDbg это делается следующим образом.

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

Затем установите две регистрирующие точки останова:

(На основе свежей версии kernel32.dll из Windows 7 SP1.)

Эти точки выводят сообщение в журнал WinDbg при каждом вызове RtlAllocateHeap и RtlFreeHeap, включая ценные сведения о вызове API. Важно соблюдать формат, но в конец строки можно добавлять текст. Активировав точки и запись журнала в файл, запустите приложение.

Когда будете готовы к анализу, прервите WinDbg. Не закрывайте его, а закройте файл журнала командой .logclose.

Теперь Mona может разобрать журнал, найти выделенные и не освобождённые объекты и выполнить dumpobj для каждого:

Результат записывается в dump_alloc_free.txt.

Надеюсь, эти две новые функции вам понравятся.

Берегите себя.

С наилучшими пожеланиями,

-corelanc0d3r

Обновление от 17 августа

dumplog теперь поддерживает вывод связанных объектов (параметр -l). У связанных объектов указывается ссылка на родительский объект. Это также относится к dumpobj.

В ходе исследования рассматриваются следующие вопросы:

1. Как ведёт себя внутренний распределитель?

2. Что активирует кучу с низкой фрагментацией?

3. Чем поведение LFH в Windows 10 отличается от Windows 7?

4. Можно ли предсказуемо размещать рядом объекты одинакового или различного размера?

5. Можно ли по-прежнему выполнить точное распыление кучи?

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

Предполагается, что читатель знаком с внутренним и внешним распределителями Windows 7 и выводом команд WinDBG !heap. Во всех тестах используется стандартная куча процесса.

Терминология:

• Фрагмент (chunk): непрерывная выделенная область.

• Блок (block): восьмибайтовая единица размера. WinDBG иногда называет словом «block» фрагмент, но в этой статье такое значение не используется.

• VirtualAllocdBlock: фрагмент, запрошенный через RtlAllocateHeap, размер которого превышает VirtualMemoryThreshold; он выделяется вне обычных сегментов и отслеживается через VirtualAllocdBlocks.

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

• Подсегмент: область LFH, содержащая фрагменты из одной корзины.

Тестовая среда

• Полностью обновлённая Windows 10 Enterprise x64 в VirtualBox, два процессора и 1,8 ГБ ОЗУ.

• Visual Studio Express 2015 for Desktop.

• Свежая версия WinDBG для Windows 10, способная разбирать актуальные структуры кучи.

• Символы настроены через _NT_SYMBOL_PATH=srv*C:\symbols*http://msdl.microsoft.com/download/symbols.

Исходный код и проекты Visual Studio доступны в репозитории win10_heap.

Куча

Как и в предыдущих версиях Windows, куча Windows 10 начинается по адресу, зависящему от ASLR, и открывается заголовком _HEAP. Адреса меняются между запусками.

Важные поля 32-разрядной структуры _HEAP:

Поля EncodeFlagMask и Encoding находятся по тем же смещениям, что и в Windows 7. Случайный ключ для каждого процесса и каждой кучи по смещению 0x50 кодирует заголовки фрагментов операцией XOR. Расширение кучи WinDBG декодирует их автоматически.

Значение VirtualMemoryThreshold равно 0xfe00 блоков, то есть 0x7f000 байт. Обычное выделение в куче, превышающее этот порог, обрабатывается как VirtualAllocdBlock.

Значение FrontEndHeapType, равное 2, обозначает LFH. Поле FrontEndHeap указывает на её главную структуру _LFH_HEAP, содержащую структуры корзин, подсегментов, кэша, политик и локальных данных:

В Windows 7 заголовок LFH обычно располагается внутри первого сегмента кучи. В Windows 10 он, по всей видимости, находится за пределами диапазона этого сегмента.

Внутренний распределитель BEA_Alloc1: разделение и объединение

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

Первый тест выделяет два фрагмента по 0x300 байт. Изначально точного свободного фрагмента нет, но сегмент заканчивается свободным фрагментом размером 0xba0 байт:

Распределитель отделяет память от его начала:

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

BEA_Alloc2: точное соответствие перед более крупными фрагментами

Выделим десять фрагментов по 0x300, не достигая порога активации LFH, а затем освободим последний. Поскольку он граничит с оставшимся пространством сегмента, области объединяются в свободный фрагмент размером 0x12c8 байт.

Перед двумя новыми запросами по 0x100 список свободных областей содержит:

Результаты:

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

BEA_Alloc3: повторное занятие объекта точного размера

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

Тест исчерпывает свободные записи для 0x58 и 0x100, а затем создаёт:

WinDBG подтверждает соседство:

Защитные фрагменты предотвращают объединение. После освобождения и повторного выделения 0x58 используется тот же адрес:

Исходные данные A заменяются на B, что демонстрирует надёжное повторное занятие фрагментом того же размера при использовании BEA.

BEA_Alloc4: перекрытие областями разных размеров

В этом тесте предпринимается попытка заменить освобождённый объект 0x58 выделением 0x80, последние четыре DWORD которого должны перекрыть первые четыре DWORD исходного объекта.

Желаемая структура:

При освобождении фрагменты 0x68 и 0x58 объединяются во фрагмент 0xc8. Выделение 0x80 занимает начало этой области. В расчёте допущена ошибка на восемь байт; вероятно, предшествующий фрагмент 0x60 обеспечил бы нужное выравнивание перекрытия. Тем не менее тест показывает, как объединение и выделение областей различного размера позволяют создать контролируемое перекрытие.

Все техники BEA зависят от того, удастся ли избежать управления задействованными размерами со стороны LFH.

Внешний распределитель: LFH LFH_Alloc1: порог активации

Windows 7 активирует корзину после 18 выделений. Тесты в Windows 10 с размерами 0x1500, 0x2100, 0x3000 и 0x800 дают тот же результат. Выделение 17 является обычным занятым фрагментом, а выделением 18 управляет LFH:

Выделение из другой корзины в середине последовательности не сбрасывает счётчик. Освобождение фрагмента другого размера или фрагмента из той же корзины во время последовательности также не препятствует активации: 18-м выделением всё равно начинает управлять LFH.

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

LFH_Alloc2: отсутствие надёжного LIFO

Активируем LFH двадцатью выделениями 0x500, освободим последний фрагмент и запросим ещё один 0x500. В отличие от Windows 7, следующий запрос не всегда возвращает последний освобождённый адрес:

При дальнейших выделениях адрес 0x008E6E10 в конечном счёте занимается повторно; в этом запуске потребовалось девять запросов. В разных запусках количество варьировалось от немедленного повторного использования до его отсутствия в первых 20 запросах. Добавленные позднее автоматические измерения в LFH_TakeBack показали максимум около 50 выделений для размеров до 0x4000, но единого фиксированного правила LIFO нет.

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

LFH_Alloc3: максимальный размер

Двадцать выделений 0x4000 активируют LFH на 18-м запросе. При двадцати выделениях 0x4008 этого не происходит:

Как и в Windows 7, максимальный размер LFH остаётся равным 0x4000.

LFH_TakeBack2: замена фрагментом из другой корзины

Можно ли заменить освобождённый фрагмент LFH размером 0x58 запросом 0x88? Разместим уязвимый объект в подсегменте, где все остальные фрагменты контролируются, освободим уязвимый фрагмент и всех его соседей, а затем запросим достаточно выделений 0x88, чтобы диспетчер кучи повторно использовал освобождённые страницы.

До освобождения:

После освобождения всего подсегмента и выделения фрагментов 0x88:

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

Крупные фрагменты Large_Alloc1: VirtualAllocdBlocks

Запросы, превышающие порог 0x7f000, по-прежнему создают VirtualAllocdBlocks. Двадцать запросов 0x7ffb0 отображаются в списке так:

Каждый начинается с новой страницы, но промежутки больше и менее предсказуемы, чем в Windows 7. Это снижает надёжность распыления широких диапазонов адресов с помощью VirtualAllocdBlocks.

Large_Alloc2: точное распыление

Точное распыление в Windows 10 по-прежнему возможно, если избежать как LFH, так и VirtualAllocdBlocks. Выберите обычное выделение сегмента, полный размер фрагмента которого выровнен по странице, например 0x20000-8 или 0x40000-8. После создания нового сегмента и получения первого места возвращаемые пользовательские адреса выравниваются единообразно:

Первый сегмент может начинаться с неудобного смещения, но последующие сегменты выравниваются по границам страниц. Повторяйте желаемую структуру через каждые 0x1000 байт внутри каждого выделения. Тест Precise_Spray помещает $$$$ по адресу 0x0c0c0c0c:

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

Хорошие результаты были получены с запрашиваемыми размерами 0x1fff8 и 0x3fff8; другие размеры фрагментов, кратные странице, должны вести себя схожим образом.

Удачи.

Peter

Меня восхищает именно метод поиска по памяти, который не приводит к аварийному завершению процесса.

Это моя первая техническая публикация почти за три года и первая после фактического прекращения работы Corelan Team. Недавно я ушёл с основной работы и основал Corelan Consulting, сосредоточившись на обучении разработке эксплойтов и консалтинге по кибербезопасности.

Обновляя материалы Corelan Bootcamp для Windows 10, я обнаружил, что Windows 7 WOW64 egghunter, созданный Lincoln, больше не работает. В этом нет ничего удивительного: Microsoft меняет номера системных вызовов между крупными выпусками Windows, а распространённый механизм egghunter зависит от такого вызова. Номера задокументированы в таблицах системных вызовов Windows Матэуша Юрчика.

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

WOW64 egghunter для Windows 10

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

Обновлённая процедура:

Код работает в WOW64, то есть в 32-разрядном процессе на 64-разрядной Windows 10. Как Lincoln описал в предыдущей статье, для поддержки нативной 32-разрядной Windows можно добавить проверку архитектуры.

Сгенерировать hunter с помощью Mona можно так:

При отладке WOW64 hunter, вызывающего системные функции, каждая попытка проверить нечитаемую страницу вызывает access violation. Операционная система безопасно обрабатывает эти исключения, но отладчик останавливается на каждом из них. В Immunity Debugger откройте Debugging options > Exceptions и добавьте следующие диапазоны:

• 0xC0000005: access violation;

• 0x80000001: guard-page violation.

После завершения отладки hunter удалите эти исключения.

Дальнейшее направление

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

Отсюда возник более общий вопрос: можно ли создать egghunter, который вообще не использует системные вызовы, работает в старых версиях Windows и поддерживает как нативную x86, так и WOW64?

Обработка исключений

В статье Skape 2004 года Safely Searching Process Virtual Address Space описано применение собственного exception handler для восстановления после попытки прочитать недоступную страницу. Handler возвращает управление в hunter, чтобы тот продолжил поиск.

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

Когда Windows передаёт исключение потока диспетчеру, процедура из ntdll.dll читает первое поле TEB по адресу FS:[0] и получает верхнюю запись SEH-цепочки потока. Каждая запись содержит два поля:

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

SEH-based hunter должен создать и сохранять собственную верхнюю запись, чей handler возвращает выполнение в hunter на следующей странице. Необходимо учесть несколько последствий:

1. Диспетчеризация исключения изменяет ESP и создаёт на стеке frame диспетчера. Указатель исходного SEH frame находится по адресу ESP+8; hunter должен отменить изменение стека.

2. Hunter должен повторно использовать одну запись, а не постоянно добавлять новые и исчерпывать место на стеке. Он обязан оставаться position-independent.

3. Поле handler должно быть совместимо с SafeSEH. Это слабое место решения. Оно также не работает при включённом SEHOP, хотя на момент написания статьи SEHOP по умолчанию не включался на клиентских системах.

Собственная запись перезаписывает данные рядом с ESP. Если в этой области стека находится hunter или shellcode, сначала скорректируйте ESP.

Следующий исходный код NASM реализует универсальный SEH-based hunter для нативной x86 и WOW64; он протестирован в Windows 7 и Windows 10:

GetPC и собственная запись

Hunter начинается с GetPC-процедуры, получающей его абсолютный адрес. После добавления 0x1d регистр ECX указывает на handle. Механизм обработки исключений в итоге должен вернуть управление туда.

Хотя SEH-запись содержит лишь два поля, hunter помещает на стек пять специально подобранных значений:

• Первый PUSH ECX сохраняет адрес handle.

• Второй компенсирует второй POP, когда последовательность POP POP RET используется повторно.

• 0x90c3585c декодируется как POP ESP; POP EAX; RET; NOP. Последовательность восстанавливает исходное положение стека, а затем возвращается к указателю POP POP RET, сохранённому в SEH-записи.

• 0x44444444 заменяется адресом POP POP RET из модуля без SafeSEH. Направить handler прямо в стек или heap нельзя, поэтому эта последовательность сохраняет управление потоком.

• 0x04EB5858 декодируется как две инструкции POP и короткий переход. Она корректирует стек и передаёт выполнение ранее помещённой последовательности инструкций.

Инструкция MOV DWORD [FS:EBX], ESP записывает адрес созданной записи в FS:[0], делая её верхней в SEH-цепочке.

Поиск и восстановление

EDX служит указателем поиска. OR DX,0x0FFF перемещает его в конец текущей страницы, а INC EDX переходит к следующей. Текущее значение сохраняется на стеке, чтобы exception handler мог его восстановить.

Если SCASD вызывает access violation, собственная SEH-запись запускает путь восстановления. handle вычитает 0x14 из ESP, снова устанавливает собственную запись во главе цепочки, загружает EDX и переходит к следующей странице.

Если страница читаема, hunter дважды ищет tag. При совпадении JMP EDI выполняет код, находящийся сразу после двойного tag.

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

Сборка SEH hunter

Сохраните исходный код, например как C:\dev\win10_egghunter_seh.nasm, и соберите его с помощью NASM:

Преобразуйте бинарный файл в hexadecimal-представление с помощью Corelan bin2hex.py:

Результат:

Замените четыре байта \x44 в конце третьей строки little-endian адресом POP POP RET. Удобное представление на Python:

На момент публикации эта процедура ещё не была добавлена в Mona. Приветствуются отзывы, уменьшенные варианты и результаты тестов в разных версиях и архитектурах Windows.

Вот и всё, друзья

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

Эта глава закладывает практическую основу отладки пользовательского режима: установка, символы, запуск и присоединение, управление выполнением, регистры, дизассемблирование, точки останова, исследование, поиск и редактирование памяти, журналирование и Mona.

Почему WinDbg?

WinDbg понимает символы Windows, исключения, потоки, процессы, модули, кучи, нативные структуры данных, дампы сбоев и состояние ядра. Язык команд поддерживает сценарии и одинаково работает при живой отладке и анализе дампов.

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

Символы

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

Настройте локальный кэш с сервером символов Microsoft:

Эквивалентный явный путь:

Проверка и устранение проблем загрузки:

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

Установка WinDbg Classic и WinDbgX Зачем нужны обе версии?

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

Автоматическая установка

PowerShell или пакетные менеджеры позволяют установить средства отладки Windows SDK и WinDbgX.

Установщик учебной виртуальной машины Corelan может настроить распространённые зависимости и отладчики в лабораторном образе.

Ручная установка

WinDbg Classic устанавливается через Windows SDK с выбором Debugging Tools for Windows. WinDbgX распространяется как пакет WinDbg через Microsoft Store/App Installer.

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

Сервер символов Microsoft

Задайте _NT_SYMBOL_PATH глобально или настройте путь в каждом отладчике:

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

Проверка обеих версий

Запустите каждый отладчик, откройте простой исполняемый файл, выполните .symfix и .reload и убедитесь, что lm показывает символы.

Подключение к процессу Открытие исполняемого файла и присоединение

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

В Classic WinDbg выберите File > Open Executable.

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

Запуск из командной строки:

Полезные параметры:

Выполнение и приостановка

Приглашение показывает, остановлена ли цель. Команда g продолжает выполнение.

Используйте Debug > Break или Ctrl+Break, чтобы прервать работающий процесс.

В WinDbgX выберите Launch executable или Attach to process на начальном экране.

Перед присоединением изучите список процессов и подтвердите архитектуру, PID и командную строку.

Несколько процессов

При отладке дочерних процессов или нескольких целей Classic WinDbg позволяет выбирать процессы и потоки командами | и ~.

В WinDbgX имеются соответствующие представления процессов и потоков.

Команды:

Аргументы командной строки

Заключайте пути и аргументы цели в кавычки по правилам оболочки, запускающей WinDbg. -c получает команды отладчика, а аргументы после исполняемого файла относятся к цели.

Используйте неинвазивное присоединение только тогда, когда рабочий процесс допускает ограниченное управление:

Настройка графического интерфейса WinDbg Classic

Расположите окна Command, Registers, Disassembly, Memory, Call Stack и Processes/Threads вокруг командной панели. Сохраните рабочее пространство для повторного использования.

Окна регистров могут показывать разные группы и форматы.

WinDbgX

WinDbgX объединяет параметры темы, исходного кода, символов, событий и запуска в Settings.

Основы отладки Интерфейс командной строки

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

Получение справки:

Повторяйте и редактируйте команды через историю. В командных файлах комментарии начинаются с $$.

Управление выполнением

Режим исходного кода влияет на p и t. Когда важно точное состояние инструкций, используйте режим ассемблера.

Управление продолжением после исключения:

Перезапуск или завершение:

Дизассемблирование: u, ub и uf

• u дизассемблирует вперёд.

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

• uf дизассемблирует полную функцию по символам и потоку управления.

Разрешение адреса:

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

Точки останова Точки останова на коде

bp привязывается к текущему адресу. bu остаётся неразрешённой или отложенной и отслеживает символы при повторной загрузке модуля.

Одноразовая точка останова:

Команды точки останова:

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

Условные точки останова

В командах точек останова предпочтительна gc.

Точки останова по данным с ba

Аппаратные точки останова срабатывают при обращении к памяти:

Допустимые длины и выравнивание зависят от архитектуры. У процессора лишь несколько регистров аппаратных точек останова.

Примеры:

.printf и Debugger Markup Language

Форматированный вывод:

Полезные спецификаторы: %p для указателя, %x для шестнадцатеричного, %d для десятичного, %ma для ANSI-строки, %mu для Unicode-строки и %y для символа.

DML создаёт интерактивный вывод отладчика:

Осторожно экранируйте кавычки в командах точек останова и командных файлах.

Просмотр памяти

Команды вывода различаются размером и интерпретацией элементов:

Примеры:

Длина после L — количество выводимых единиц, не всегда байтов.

Переход по указателям:

poi() MASM читает значение размера указателя. Операторы явного размера: by, wo, dwo и qwo.

Исследование метаданных виртуальной памяти:

Исследование структур при наличии типа в символах:

Поиск в памяти

Поиск байтов, слов, двойных и четверных слов, строк и диапазонов:

Для больших диапазонов, которые отклоняет обычный анализатор длины, используйте L?length:

Сохраняйте совпадения для последующих поисков с помощью -s; после определения подходящих областей через !address при необходимости ищите только в доступной для записи или исполняемой памяти.

Редактирование памяти

Примеры:

Заполнение памяти:

Перемещение и сравнение:

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

Mona

Mona автоматизирует повторяющиеся задачи разработки эксплойтов в вариантах для WinDbg/PyKD и Immunity Debugger. Типичные операции: инвентаризация модулей, циклические шаблоны, сравнение недопустимых символов, поиск гаджетов и указателей, исследование кучи и создание ROP.

Настройка рабочего каталога:

Распространённые команды:

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

Файлы журналов

Открытие и закрытие журнала отладчика:

Журналирование из командной строки:

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

Псевдорегистры

Автоматические псевдорегистры предоставляют контекст отладчика:

Пользовательские псевдорегистры от $t0 до $t19 хранят временные значения:

Распространённые команды WinDbg Сеанс и символы Состояние процессов и потоков Исключения и контекст Регистры и стек Модули и символы Куча и память Вывод и поведение команд Предупреждение о QuickEdit

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

Заключительные замечания

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