Случайное распределение выделения памяти низший aslr

Обновлено: 15.01.2025

Защита от эксплойтов ( Exploit Guard ) — эта новая функция в Windows Defender в Windows 10 1709, которая представляет собой объединенную и более улучшенную версию инструмента EMET от Microsoft. Exploit Guard предназначен для защиты компьютера от эксплоитов, и заражения вашей системы вредоносными программами. Специально активировать Защиту от эксплойтов не нужно, это происходит автоматически, но только при включенном защитнике Windows.

Изменить параметры Exploit Guard по умолчанию можно в Центре безопасности Защитника Windows.

Получить к нему доступ можно через меню Пуск или Параметры (Windows + I). Настройки будут производиться именно через Центр Безопасности, а не Параметры Защитника. Учитывайте это при использовании быстрого поиска. Получить к нему доступ можно через меню Пуск или Параметры (Windows + I). Настройки будут производиться именно через Центр Безопасности, а не Параметры Защитника. Учитывайте это при использовании быстрого поиска.

В появившемся окне перейдите в меню «Управление приложениями и браузером».
Пролистайте страницу в самый низ и выберите «Параметры защиты от эксплойтов».

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

Системные параметры

Здесь отображается список доступных пользователю механизмов защиты Windows. Рядом указывается статус — включено, отключено. Доступны:

CFG. Защита потока управления и обеспечение его целостности для совершения непрямых вызовов (включена по умолчанию).
SEHOP. Проверка цепочек исключений и обеспечение ее целостность во время отправки.
DEP. Предотвращение выполнения данных (включена по умолчанию).
Обязательный ASLR. Принудительное случайное распределение для образов, которые не соответствуют /DYNAMICBASE (выключена по умолчанию).
Низкий ASLR. Случайное распределение выделения памяти. (включена по умолчанию).
Проверка целостности кучи. В случае нахождения повреждений, процесс автоматически завершается. (включена по умолчанию).

Пользователь может отключить их независимо друг от друга.

Параметры программ

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

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

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

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

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

Импорт и экспорт настроек

Экспортировать текущие настройки Exploit Guard можно через Центр безопасности Защитника Windows. Для этого достаточно нажать на соответствующую кнопку и сохранить файл в формате XML.

Экспортировать настройки можно и через командную строку Windows PowerShell. Для этого есть команда:

Get-ProcessMitigation -RegistryConfigFilePath C:\Users\Alex\Desktop\Settings.xml

Для импорта необходимо заменить командлет Get на Set и по аналогии с примером указать название и путь к файлу.

Установить уже существующий XML файл с настройками можно через редактор локальных групповых политик gpedit.msc:

В левой части экрана перейдите в ветку редактора Конфигурация компьютера —> Административные шаблоны —> Компоненты Windows —> Exploit Guard в Защитнике Windows —> Защита от эксплойтов. Откройте политику Используйте общий набор параметров защиты от эксплойтов.
Измените значение на «Включено», а в появившемся поле укажите путь или URL- адрес к существующему XML файлу с конфигурацией.

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

Настройка Exploit Guard с помощью PowerShell

Для редактирования списка модулей защиты можно использовать командную строку Windows PowerShell.

Здесь доступные следующие команды:

Get-ProcessMitigation -Name iexplore.exe — получить список всех защитных мер для выбранного процесса. В данном примере это iexplore.exe, вы можете указать любой другой. Вместо имени программы, можно указать точный путь.
Состояние NOTSET (не установлено) для категории системных параметров означает, что выставлены значения по умолчанию, для категории программ здесь следует вписать параметр, к которому будут присвоены меры защиты.
— Set с добавочной командой ProcessMitigation используется для редактирования каждого отдельного значения. Чтобы активировать SEHOP для конкретного исполняемого файла (в нашем примере test.exe) по адресу C:\Users\Alex\Desktop\test.exe, используйте команду в PowerShell: Set-ProcessMitigation -Name C:\Users\Alex\Desktop\test.exe -Enable SEHOP
Чтобы применить эту меру для всех файлов, а не для конкретной программы, используйте команду: Set-Processmitigation -System -Enable SEHOP
-Enable — включить, — Disable — отключить.
Командлет — Remove используется для восстановления настроек по умолчанию и указывается сразу после — Name .
-Enable или — DisableAuditDynamicCode — активировать или выключить аудит.

При вводе команд учитывайте, что каждый отдельный параметр меры должен отделяться запятой. Посмотреть их список вы можете здесь же, в PowerShell. Они отобразятся после ввода команды Get-ProcessMitigation -Name имя_процесса.exe.

Exploit Guard- новая функция безопасности Защитника Windows, которая была впервые представлена Microsoft в Windows 10 Fall Creators Update.

Защита от эксплойтов представляет собой интегрированную версию инструмента Microsoft EMET (Enhanced Mitigation Experience Toolkit), поддержка которого завершится в середине 2018 года.

Защита от использования уязвимостей включена по умолчанию, если активен Защитник Windows. Эта функция является единственной функцией Exploit Guard, которая не требует включения защиты в режиме реального времени.

Данную функцию можно настроить в Центре безопасности Защитника Windows, с помощью групповых политик или команд PowerShell.

Центр безопасности Защитника Windows

Пользователи Windows 10 могут настроить защиту от эксплойтов в Центре безопасности Защитника Windows.

Все настройки разделены на две категории: Системные параметры и Параметры программ.

На вкладке Системные параметры выводится список всех доступных механизмов защиту с их статусом. В Windows 10 Fall Creators Update доступны следующие защиты:

Защита потока управления (CFG) - вкл. по умолчанию.
Предотвращение выполнения данных (DEP) - вкл. по умолчанию.
Принудительное случайное распределение для образов (обязательный ASLR) - выкл. по умолчанию.
Случайное распределение выделения памяти (низкий ASLR) - вкл. по умолчанию.
Проверить цепочки исключений (SEHOP) - вкл. по умолчанию.
Проверка целостности кучи - вкл. по умолчанию.

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

По умолчанию несколько программ добавлены в исключения, в частности svchost.exe, spools.exe, runtimebroker.exe, iexplore.exe и другие основные программы Windows. Обратите внимание, что вы можете переопределить эти исключения, выбрав файлы и нажав кнопку “Редактировать”.

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

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

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

Защита от произвольного кода (ACG)
Блокировка образов низкой целостности
Блокировка удаленных образов
Блокировка ненадежных шрифтов
Защита целостности кода
Отключение точек расширения
Отключение вызовов системы Win32k
Не разрешать дочерние процессы
Фильтрация адресов экспорта (EAF)
Фильтрация адресов импорта (IAF)
Имитация выполнения (SimExec)
Проверка вызовов API (CallerCheck)
Проверка использования дескриптора
Проверка целостности зависимостей образа
Проверка целостности стека (StackPivot)

PowerShell

Вы можете использовать командную строку PowerShell для установки, удаления или изменения списка мер. Доступны следующие команды:

Чтобы просмотреть все защитные меры указанного процесса: Get-ProcessMitigation -Name processName.exe

Чтобы установить защитную меру: Set-ProcessMitigation - - , ,

Область действия: -System или -Name .

Действие: либо -Enable или -Disable .

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

Set-Processmitigation -System -Enable DEP
Set-Processmitigation -Name test.exe -Remove -Disable DEP
Set-ProcessMitigation -Name processName.exe -Enable EnableExportAddressFilterPlus -EAFModules dllName1.dll, dllName2.dll

Импорт и экспорт конфигураций

Конфигурации можно импортировать и экспортировать. Данные операции можно сделать на странице “Параметров защиты эксплойтов” в Центре безопасности Защитника Windows, а также с помощью PowerShell или редактора групповых политик.

Кроме того, конфигурации EMET можно преобразовать для последующего импорта.

Использование настроек защиты от эксплойтов

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

Нажмите ссылку “Параметры экспорта” и выберите местоположение для файла .XML с настройками.

Использование PowerShell для экспорта файла конфигурации

Откройте Powershell с правами администратора устройства.
Запустите команду: Get-ProcessMitigation -RegistryConfigFilePath filename.xml

Измените путь и filename.xml, указав требуемое местоположение и название файла.

Использование PowerShell для импорта файла конфигурации

Откройте Powershell с правами администратора устройства.
Запустите команду: Set-ProcessMitigation -PolicyFilePath filename.xml

Использование групповых политик для установки файла конфигурации

Вы можете установить файлы конфигураций с помощью редактора групповых политик:

Windows 10

Привет! Сегодня я покажу вам как настроить параметры защиты от эксплойтов на компьютере или ноутбуке Windows 10. Что это такое? Данная функция встроена в систему по умолчанию, чтобы защитить ваше устройство от атак. Смотрите инструкцию далее и пишите комментарии, если вам что-то не понятно.

В панели задач, внизу экрана слева, откройте меню Пуск. В открывшемся окне, нажмите на вкладку или значок Параметры.

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

В настройках безопасности, слева в боковой панели, перейдите на вкладку Защитник Windows. На данной странице, нажмите на кнопку Открыть Центр безопасности Защитника Windows .

В центре безопасности, нажмите на вкладку Управление приложениями и браузером .

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

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

Защита потока управления (CFG). Обеспечивает целостность потока управления для непрямых вызовов;
Предотвращение выполнения данных (DEP). Не позволяет коду запускаться со страниц памяти, содержащих только данные;
Принудительное случайное распределение для образов (обязательный ASLR). Принудительное перемещение образов, не соответствующих /DYNAMICBASE.
Случайное распределение выделения памяти (низший ASLR). Случайно распределите расположения для выделения виртуальной памяти;
ASLR с высокой энтропией. Увеличивать дисперсию при использовании случайного выделения памяти (AS снизу вверх);
Проверить цепочки исключений (SEHOP). Обеспечивает целостность цепочки исключений во время отправки;
Проверка целостности кучи. Завершает процесс при обнаружении повреждения кучи.

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

Мы уже неоднократно упоминали ASLR, по справедливому замечанию MS, эта технология позволяет сделать разработку эксплойтов гораздо более дорогостоящим мероприятием, поскольку кроме эксплуатации самой уязвимости в ПО злоумышленнику нужно опереться на те или иные предсказуемые адреса в памяти в момент эксплуатации, которых ASLR его лишает. Как мы видим, в последнее время, в том числе, и с выпуском новейших Windows 8/8.1 MS решили более серьезно подойти к развертыванию данной особенности в системе. Если в узком смысле ASLR понимается как просто перемещение образа по непредсказуемым адресам с каждой перезагрузкой, то в более общем смысле эта возможность на уровне системы должна лишить атакующих любой возможности зацепится за те или иные адреса функций системных библиотек и иных системных объектов (ASLR bypass mitigation / Address Space Information Disclosure Hardening) в тех нескольких десятках байт шелл-кода, который может быть исполнен минуя DEP (ROP).

Microsoft использует по отношению к ASLR схожий c DEP подход, т. е. разрешать его использование по мере необходимости, если приложение скомпилировано с поддержкой. Такая практика применяется в виду очевидных проблем совместимости, которые могут возникнуть при работе программ с технологиями, на которые они могут реагировать неадекватно. Но в случае с ASLR эта ситуация работает с большими ограничениями. Например, на современных выпусках Windows 8/8.1 DEP включен всегда для приложений вне зависимости от того, скомпилированы они с его поддержкой или нет (по крайней мере на 64-битном процессоре и вне зависимости от разрядности ОС и параметра загрузчика). С ASLR ситуация иная, даже работая на Windows 8/8.1 он опирается на правила его поддержки самим приложением и не включает рандомизацию образа, если в заголовке нет этого флага.

Атакующие могут использовать «преимущества» системной библиотеки, которая не скомпилирована с поддержкой ASLR, для своих целей, например, для реализации стабильной цепочки ROP, которая будет работать во всех поддерживаемых ОС. Как показывает практика последних лет, такая возможность использовалась не один раз при организации таргетированных атак. Ниже указаны такие эксплуатируемые in-the-wild уязвимости типа RCE (drive-by download).

Как видно, библиотека MS Office (hxds.dll) не поддерживает ASLR (Office 2007-2010) и атакующие смогли воспользоваться ее не меняющимся адресом загрузки для успешной эксплуатации уязвимости. В рамках декабрьского patch tuesday компания закрыла эту оплошность (которая называется Security Feature Bypass) с помощью MS13-106, обеспечивая пользователей Windows, которые работают с этой версией Office, должным уровнем защиты.

Одной из основных возможностей по поддержке ASLR, которую MS внесла с Windows 8, является функция принудительного ASLR (Force ASLR). Эта функция чем-то напоминает параметр OptIn политики DEP для всей системы. Теперь используя раздел реестра Image File Execution Options (IFEO) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options и параметр MitigationOptions пользователь может вручную включать ASLR для исполняемых PE файлов. Ниже в таблице приводится поведение ОС при загрузке в память исполняемого файла с ForceASLR и без него.

Подобная функция доступна и для пользователей Windows 7 при установке опционального обновления KB2639308.

Для того чтобы сделать Internet Explorer (10+) более безопасным, компания ввела поддержку функции принудительного применения ASLR (на Windows 8+ и для Windows 7 с установленным KB2639308) для всех библиотек, загружаемых в адресное пространство процесса браузера (ForceASLR). Таким образом, если какая-то из библиотек или плагинов изначально скомпилирована без поддержки этой функции, она будет применена к ней в принудительном порядке.

Атакующие используют преимущества Windows, которая применяет некоторую оптимизацию при работе с виртуальной памятью через последовательное выделение смежных регионов нужного размера для клиентов (процессов) через VirtualAlloc. Приложение может запросить способ выделения блока виртуальной памяти как снизу-вверх (по умолчанию), сверху-вниз (MEM_TOP_DOWN) или по фиксированному адресу (указанный функции адрес). По умолчанию Windows использует метод выделения снизу-вверх, т. е. от младших адресов к старшим она будет искать блок необходимого размера для того, чтобы отдать его приложению.

Начиная с Windows 8 на выделение виртуальной памяти может воздействовать ASLR. Такая политика до Windows 8 уже применялась для выделения блоков памяти на куче, при резервировании блоков для стеков потоков, а также TEB и PEB. Последние две структуры являются очень полезными для атакующих поскольку потенциально содержат определенное количество указателей на различные системные функции, раскрывая таким образом расположение библиотек в памяти. В Windows 8 VirtualAlloc также различает опции выделения сверху-вниз и снизу-вверх, но теперь базовый адрес начала этих выделений фиксируется ASLR при каждой загрузке ОС, т. е. не может быть предсказуем. Очевидно, что в адресном пространстве невозможно выделять память совсем хаотично ввиду быстрой фрагментации, поэтому через ASLR фиксируется именно базовый адрес начала выделения блоков для процессов. Согласно MS для процесса такая опция включается только в случае соответствующей поддержки ASLR его исполняемым файлом (/DYNAMICBASE).

High Entropy ASLR

ASLR потенциально может работать эффективнее в 64-битном адресном пространстве, поскольку там существует гораздо большая возможность по произвольному размещению памяти в таком большом адресном пространстве. Очевидно и само его использование уже является усложняющим фактором для heap spray. См. Internet Explorer EPM для Windows 7 x64. В то же время ОС до Windows 8 не используют ASLR на x64 самым полноценным образом. Главным образом это касается возможности энтропии (т. е. степени произвольности/предсказуемости выбора адреса) и сколько бит адреса будут использоваться для вычисления произвольности этого размещения. В Windows 8 такая возможность получила название High Entropy Randomization.

Windows 8+ содержит возможности, реализующие High Entropy Randomization и эта технология распространяется как на выделяемые процессом блоки виртуальной памяти, так на и загружаемые исполняемые файлы. Для 64-битных приложений, скомпонованных с флагом /LARGEADDRESSAWARE, Windows 8 выделяет для использования 8 TB виртуальной памяти (128 TB в Windows 8.1). Для сравнения, у 32-битных приложений размер пользовательской части адресного пространства ограничивается 2 GB. В таком случае возможность High Entropy Randomization позволяет применять ASLR для базового адреса отсчета выделений памяти типа снизу-вверх, используя 24 бита адреса для получения энтропии и для выделений типа сверху-вниз 17 бит адреса для энтропии. Для использования такого уровня ASLR и при использовании выделений снизу-вверх (по умолчанию) 64-битное приложение должно быть скомпилировано с флагами /HIGHENTROPYVA и /DYNAMICBASE.

Следует отметить, что сам /HIGHENTROPYVA используется как режим ограничения OptIn использования HEASLR в ОС. То есть VirtualAlloc в своем обычном поведении (выделения блоков снизу-вверх) на Windows 8 не будет использовать усиленный ASLR для приложений, которые скомпилированы без этого флага. Такое ограничение связано с вопросами совместимости и возможным непредсказуемым поведением этих приложений в данной ситуации. Как указано выше, возможность High Entropy Randomization применима и к 64-битным исполняемым файлам.

Браузер Internet Explorer 10+ использует режим High Entropy ASLR (x64). Ниже показано свойство его запущенного процесса на Windows 8. Отметим, что все системные исполняемые файлы, которые Microsoft поставляет в Windows 8, используют HEASLR.

ASLR bypass mitigations (aka Address Space Information Disclosure Hardening)

С выпуском Windows 8 компания постаралась пойти по стратегии сокрытия различных адресов системных функций и объектов. Некоторые из этих возможностей доставлялись как обновления и для Windows 7. Присутствие подобной информации по предсказуемым для атакующих адресам сильно снижает возможности существующих технологий DEP&ASLR и повышает возможность успеха атакующих к эксплуатации.

Одним из ярких примеров является обновление MS13-031, которое вводит ограничение на выделение памяти по нулевой странице (Windows 7+). Размещение кода на этой странице с последующей эксплуатацией уязвимости в драйвере используется атакующими как LPE, т. е. поднятие своих привилегий до системных и исполнение своего кода в режиме ядра. Ядро использует поле EPROCESS!LowVaAccessible для регулирования подобных ситуаций, а именно, для обнаружения минимального адреса, с которого можно резервировать регионы виртуальной памяти.

Другим примером является обновление MS13-063 для Windows Vista+ (Windows 8 по умолчанию). Это обновление убирает из UserSharedData (KUSER_SHARED_DATA) указатель на ntdll!LdrHotPatchRoutine, который использовался для быстрой загрузки необходимой атакующим библиотеки в память. UserSharedData очень полезна для атакующих, поскольку доступна по одному и тому же адресу во всех процессах, а также используется в режиме ядра.

В Windows 8.1 появилась возможность скрывать информацию об адресах объектов ядра для недоверенных приложений (чей Integrity Level < Medium). Более подробно об этой фукнции мы писали здесь. Важные функции ntoskrnl возвращают статус ошибки на запрос получения информации об адресах различных объектов ядра.

P. S. Вы можете воспользоваться бесплатным инструментом BinScope от Microsoft для проверки модулей ваших программ на поддержку ASLR (iTunes взят в качестве примера).

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

1 Введение

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

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

Хотя приведенные выше снимки экрана показывают одни и те же инструкции из библиотеки USER32.DLL, их адреса в памяти немного различаются (760F и 75DA). Дело в том, что USER32.DLL – библиотека ядра, в которой включен ASLR.

2 Метод первый – частичная перезапись

Наверное вы помните, как несколько лет назад появился печально известный ANI-эксплоит, к которому были уязвимы все версии Windows вплоть до Vista включительно. Поскольку до Windows Vista не было ASLR, процесс эксплуатации уязвимости на предшествующих версиях системы был довольно прост: требовалось лишь перейти по указателю, хранящемуся в EBX (JMP PTR EBX), а затем сделать пару коротких прыжков через ANI-заголовок, пока вы не приземлитесь на начале шелл-кода.

В случае Windows Vista и наличия ASLR вы не можете просто посмотреть на системную библиотеку SHELL32.DLL, чтобы добраться до выбранного регистра, так как базовый адрес также будет меняться после каждой перезагрузки. Поскольку аварийное завершение происходило в библиотеке USER32.DLL, в эксплоите для Windows Vista было сделано нечто действительно особенное, и для совершения необходимого прыжка в начало ANI-файла использовалась частичная перезапись EIP.

Наблюдая в отладчике за Internet Explorer в момент его аварийного завершения с помощью демонстрационного эксплоита ms07-017, мы видим, что EIP полностью перезаписан значением 43434343.

Сократив передаваемые в буфер данные на два байта, мы можем добиться частичной перезаписи EIP и обойти ASLR. Нам придется изменить заголовок ANI-файла, иначе мы можем не получить рабочий адрес возврата, поскольку тогда пришлось бы использовать метод грубой силы (что не слишком увлекательно).

Если перезаписать лишь два нижних байта регистра EIP адресом из USER32.DLL и оставить другую половину нетронутой, то верхние два байта не изменят своего первоначального значения (именно они рандомизируются ASLR). Теперь нам нужно лишь найти опкод, который позволит успешно обойти ASLR и выполнить наш код.

Ни один из регистров не указывает на наш буфер напрямую, однако первые 4 байта EBX указывают на адрес, предшествующий началу нашего ANI-заголовка. Поэтому нам нужно найти инструкцию JMP PTR [EBX] в текущей библиотеке USER32.DLL.

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

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

Мы можем заменить 5 и 6 байты ANI-заголовка коротким прыжком на 22 байта, где мы можем использовать другую пару байтов, чтобы прыгнуть на 123 байта и на нашу полезную нагрузку.

3 Метод 2 – не-ASLR процесс

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

Например, предположим, что вы нашли баг в музыкальном медиаплеере и находитесь под ОС с поддержкой ASLR вроде Windows Vista, а данный плеер подгружает во время выполнения несколько библиотек - скажем, MP3.DLL и т. д.

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

Во время поиска загруженных библиотек программы ’Free MP3 CD Ripper 1.1’ я заметил, что ни программа, ни загружаемые ей библиотеки не поддерживают ASLR, а значит при открытии будут загружаться по одному и тому же адресу в памяти. Затем я смог исследовать загруженные библиотеки на предмет надежной инструкции JMP ESP instruction, однако таковой не нашел.

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

4 Метод 3 – метод грубой силы

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

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

5 Заключение

Хотя ASLR впервые появился в Windows Vista, очень многие производители ПО (в том числе ПО с открытым кодом) не торопились реализовать этот механизм защиты памяти. Например, в июне 2010 года Mozilla (производитель браузера Firefox) не реализовала полной поддержки ASLR в своем браузере, а Google – в своем (Chrome). Учитывая методологию ПО с открытым кодом, вы могли подумать, что новые механизмы защиты памяти вроде ASLR станут активно использоваться вскоре после появления, однако большинство производителей опровергают подобное суждение.

Microsoft включила поддержку ASLR во все программные пакеты, выпущенные ей с 2007 года, что сделало неэксплуатирумыми уязвимости в некотором ПО. Тем не менее, если переполнение буфера нельзя эксплуатировать для запуска кода, оно все еще может вызвать отказ в обслуживании (DoS), который сделает недоступным приложение/сервис. Если таким приложением окажется открытый наружу веб-сервер, это может иметь неблагоприятные финансовые последствия.

Хотя я рассматривал лишь ASLR в Windows Vista, подобные методы окажутся применимы и для других версий Windows (поддерживающих ASLR), вроде Windows Server 2008 и выше, а также для основанных на Linux дистрибутивов и, возможно, для таких систем, как Mac OS и Solaris.

Читайте также: