Calcweb.ru

Информационный портал
4 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как в Windows 8.1 и 10 закрыть уязвимость в работе ASLR

Защита от атаки ASLR в Windows

атака ASLR windows

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

Что такое ASLR

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

В первые ASLR появилась в OpenBSD, в далеком 2003 году, и с тех пор она была добавлена ​​во все популярные операционные системы, включая Linux, Android, MacOS и Windows.

Microsoft добавила ASLR в Windows с выпуском Vista в 2006 году. Чтобы включить эту функцию, пользователям пришлось установить Microsoft EMET и использовать ее графический интерфейс для включения ASLR в общесистемных и / или конкретных приложениях.

aslr уязвимость

С выпуском Windows 10 ASLR был добавлен в «Центр безопасности защитника Windows», и теперь пользователи могут включить его в разделе «Управление приложениями и браузером», а затем «Параметры защиты от эксплойтов».

ASLR в Windows

Изучая недавно обнаруженную 17-летнюю уязвимость, влияющую на редактор формул Microsoft Office, специалист в области информационной безопасности Уилл Дорманн обнаружил, что в определенных условиях ASLR не рандомизировала местоположения объектов в памяти.

aslr windows 8

Согласно Dormann, включение общесистемной защиты ASLR, приводит к ошибке в реализации этой функции в Windows. Исследователь говорит, что эта проблема затрагивает только Windows 8 и более поздние версии, поскольку Microsoft изменила значения реестра, с помощью которых включается ASLR.

Защита от атаки ASLR в Windows

Ожидается, что Microsoft в будущем патче исправит данную проблему. В настоящее же время единственным способом активации функции ASLR на Windows является ручное изменение реестра Windows.

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

aslr windows 8

  1. Создайте пустой текстовый файл и введите следующий текст: Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Managerkernel] «MitigationOptions»=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00
  2. Сохраните файл с расширением .reg, например ASLR.reg.
  3. Откройте редактор реестра Windows, выполнив поиск по слову «regedit» в меню «Пуск» или с помощью комбинации WIN + R.
  4. Выберите пункт меню «Файл» и выберите импортировать REG-файл, который вы только что создали.

Технология ASLR некорректно работает в операционных системах Microsoft, начиная с Windows 8

Рекомендуем почитать:

Реверс малвари

Специалист координационного центра CERT (CERT/CC) Уилл Дорманн (Will Dormann) обнаружил, что в ряде случаев защитный механизм Address Space Layout Randomisation (ASLR) работает некорректно, причем проблема появилась еще во времена Windows 8 и сохраняется по сей день, после релиза Windows 10.

Напомню, что ASLR (Address Space Layout Randomization или рандомизация размещения адресного пространства) – это защитный механизм, поддерживаемый практически всеми современными операционными системами, включая Windows, Linux, macOS, iOS и Android. По сути, ASLR случайным образом изменяет расположение в адресном пространстве различных важных структур данных: образов исполняемых файлов, подгружаемых библиотек, хипа и так далее. Дело в том, что зачастую для успешной реализации атаки злоумышленнику необходимо знать, где именно в адресном пространстве происходит выполнение кода того или иного приложения, а ASLR призван защитить систему от таких атак.

Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME.
Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017

Исследователь CERT/CC объясняет, что начиная с релиза Windows 8 общесистемная имплементация ASLR (system-wide mandatory), так же известная как принудительный ALSR (Force ASLR), имеет нулевую энтропию, то есть, по сути, рандомизация размещения адресного пространства не производится, и релокация исполняемых файлов осуществляется по одному и тому же адресу. Напомню, что данная функция активируется через EMET, а с недавних пор, после выхода Windows 10 Fall Creators Update, она стала частью Windows Defender Exploit Guard. Force ASLR призвана осуществлять рандомизацию даже в тех случаях, когда поддержка ASLR не включена для конкретного приложения.

Читайте так же:
Как отформатировать флешку в NTFS в Windows

Специалисты Microsoft уже ответили на опубликованный Дорманном доклад, сообщив, что тот обнаружил проблему, которую вряд ли можно назвать полноценной уязвимостью. Дело в том, что, по словам инженеров Microsoft, все отнюдь не так плохо. ASLR в Windows 8 и 10 работает как должно в 11 случаях из 12, а описанные исследователем проблемы могут возникать крайне редко, исключительно в силу нюансов конфигурации. Свои слова инженеры Microsoft подкрепили наглядной иллюстрацией: в таблице ниже проблема обозначена желтым цветом.

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

ASLR в новейших выпусках Windows

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

Мы не будем касаться истории ASLR, которая известна уже почти всем, отметим лишь некоторые не совсем очевидные возможности, которые Microsoft использует для улучшения ASLR в своих флагманских ОС Windows 7-8-8.1.

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).

Читайте так же:
Как запретить программам в Windows запускать параллельные экземпляры процессов

Как видно, библиотека 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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage 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.

Читайте так же:
Как в документах Word снять защиту от копирования средствами Word

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: форточки в окнах вашего компьютера

С выхода Windows 2000 прошло больше двадцати лет, и все десять лет, что официально Microsoft поддерживала ее расширенную версию, разработчики только тем и занимались, что выпускали очередные заплатки. Если вы до сих пор где-то ее используете, все обновления можно просмотреть через systeminfo в командной строке. Пройти мимо очередного сервис-пака было опасно – никто знал, во что могут вылиться незакрытые гештальты проблемы с безопасностью.

Читайте так же:
Как включить виртуализацию на ПК в ОС Windows

Чтобы хоть немного подняться в глазах простых сисадминов, Microsoft выводит на рынок новую ОС, которая… оказывается практически полным клоном Win2000 и, конечно, повторяет ее судьбу. И вместо того, чтобы чистосердечно раскаяться, разработчики в очередной раз переводят стрелки на грозных хакеров. Хотя на самом деле хакеры не мешали, а наоборот, помогали создавать что-то более стабильное и безопасное.

Тем временем в Microsoft продолжили искать обходные механизмы. Одним из них должен быть стать DEP (Data Execution Prevention). Он появился в XP, но так и не оправдал надежд. Следующая попытка была сделана уже в Win7, где реализовали функцию ASLR (Address Space Layout Randomization). На нее возлагали много надежд, но скоро стало понятно: ASLR так же уязвима, как и предыдущие решения.

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

Защиту от исполнения данных можно реализовать двумя способами: программным и аппаратным. Первый, он же software-enforced, подходит только для 32-битных версий Windows, у второго (hardware-enforced) область применения чуть шире: все та же 32-битная ось, но уже 64-битные чипы. Подобное разделение легко объяснить: DEP прямо соотносится с 63-м битом в записях виртуальных страниц PTE (Page Table Entry), которого нет в 32-битных ОС. Поэтому для последних доступен только один вариант – с эмуляцией и подключением ядра Ntkrnlpa.exe.

Допустим, основное (Ntoskrnl.exe) и альтернативное ядра находятся в папке windowssystem32. Если в boot.ini установить флаг /РАЕ (Physical Address Extension), то ось будет грузиться с альтернативного ядра, пока основное будет простаивать. РАЕ помогает сделать так, чтобы у обычного процессора на 32 бита было в распоряжении не 4 Гб адресного пространства, а 64 Гб.

На левом скрине у нас PDT (каталог виртуальных страниц), на который указывает регистр управления CR3 текущего процесса. В каталоге находятся ровно 1024 (или 10 бит) записей Entry, каждая – по 32 бита. На каждую запись приходится одна из 1024 таблиц PT, в которой, в свою очередь, тоже 1024 записи PTE. И, наконец, PTE указывают на одну из 1024 страниц виртуальной памяти по 4 Кб. Итого суммарно мы получаем 4 ГБ памяти (результат умножения 1024 на 1024 на 4096).

На правом скрине видно, что в ядре РАЕ с 32 до 52 бит выросла разрядность записей Entry, но их количество сократилось вдвое: было 1024, стало 512, то есть теперь у нас девять бит вместо десяти. Благодаря тому, что в записях теперь есть дополнительные разряды, можно создавать в два раза больше таблиц PT и каталогов PDT. У любой страницы по-прежнему 4 Кб, но количество страниц просто гигантское. Также возможны иные режимы, когда вместо 4-килобайтных страниц мы получаем 2- и даже 4-мегабайтные.

32-битные записи PTE заполнены информацией по максимуму, и свободных битов в них нет. Но если разрядность повысить до 64 бит (а мы помним, что полезных там только 52 бита), появляется 12 свободных бит. Их можно закодировать под что-то полезное.

Что мы здесь видим: в РАЕ-режиме длина записи увеличилась вдвое. Это позволило нам поместить в старший (63-й) бит защиту от исполнения NX. Если записать туда единицу, то мы защитим от исполнения страницу, у которой базовый адрес хранится в записи PTE таблицы РТ (и это та самая запись, значение бита которой мы меняем). Максимум, что будет доступно для этой страницы – запись или перезапись (write/rewrite). В ntoskrnl.exe ядро non-PAE таким битом не располагает, поэтому и DEP для него не доступен, как и для всего 32-битного семейства Windows XP без РАЕ.

Читайте так же:
ТОП 10 клоакинг сервисов для Facebook, Google Ads и других

На 64-битных осях все иначе. Так как им не нужно ядро РАЕ, то оно не входит в состав операционной системы, а сама она функционирует в режиме AWE (Address Windowing Extensions). На схеме ниже показано, как в этом случае происходит трансляция виртуального адреса.

Механизм трансляции адреса в 64-битном режиме

Ядро выставляет DEP-защиту в момент запуска программы. Сама операционная система конфигурирует DEP (всего доступно четыре варианта), и это напрямую определяет, можно или нет обойти защиту программным способом.

Первая конфигурация: AlwaysOff = 0

Аппаратный DEP деактивирован для всех элементов ОС, а сама она работает на базовом ядре Ntoskrnl.exe без РАЕ.

Вторая конфигурация: AlwaysOn = 1

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

Третья конфигурация: OptInt = 2

DEP на аппаратном уровне распространяется только на компоненты ОС. Эта модель по умолчанию используется на клиентских версиях Windows. Если нужно отключить DEP для отдельных приложений/процессов, это можно сделать программным способом.

Четвертая конфигурация: OptOut = 3

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

Не рекомендую относиться к DEP как к надежному средству защиты. Судя по конфигурациям, им легко управлять на программном уровне. А если вспомнить про VirtualProtect(Ex), с которой можно «поиграть» атрибутами страниц виртуальной памяти, механизм защиты выглядит еще более хрупким. Единственное, что достойно внимания, – это вторая конфигурация. С ней попытки сломить защиту закончатся фейлом. Минус в том, что работает это только на серверных системах, а на клиентских даже при такой конфигурации DEP может легко отключить вполне безобидное приложение вроде архиватора (легального, между прочим!).

Эти функции собраны в библиотеке kernel32.dll, и их можно использовать с правами администратора.

1. GetSystemDEPPolicy() – вызывает параметры системной политики DEP. У этой функции нет дополнительных аргументов, и все, на что она способна, – это вернуть порядковый номер выбранной DEP конфигурации. Сама конфигурация выбирается на этапе загрузки операционной системы, а для ее изменения придется обратиться к boot.ini. Чтобы активировать DEP на глобальном уровне, нужен бит (11) MSR-регистра 0xC0000080, который называется IA32_EFER.NXE.

2. GetProcessDEPPolicy() – делает запрос параметра DEP для выбранного процесса. Если операция успешная, функция возвращает TRUE, в противном случае – FALSE=0.

3. SetProcessDEPPolicy() – задает параметры DEP для выбранного процесса. Доступен всего один аргумент – флаг предыдущей функции Get(). Результат работы функции зависит от общесистемной политики DEP (два варианта: OptInt или OptOut). Работать с DEP можно только тогда, когда GetProcessDEPPolicy() периодически возвращает FALSE.

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

голоса
Рейтинг статьи
Ссылка на основную публикацию