Привет.
Развитие Enhanced Mitigation Experience Toolkit продолжается – и вот на горизонте появилась новая версия, EMET 5.0 – пока в виде technology preview, но новое и интересное уже есть.
Новое в EMET 5.0
- EAF+
- ASR – Attack Surface Reduction
Начнём.
EAF+
EAF – это Export Address Table Access Filtering. Схема этой защитной меры уже описана ранее – вкратце, чтобы сделать что-то плохое, вредоносный код должен найти, куда при данном запуске заражённого приложения загружались всякие DLL, реализующие WinAPI. Для этого надо пробежать EAT (Export Address Table) и найти, например, ntdll.dll. Или kernel32.dll. EMET отсекает это в случае включенного EAF, но делает это только для указанных двух модулей. EAF+ расширяет защиту, добавляя также фильтрацию поиска kernelbase, а также доп.проверки стека и регистров на момент, когда кто-то шарит по EAT.
Просто включив EAF+ Вы, по сути, переведёте все модули, для которых включён EAF, на обновлённый вариант защиты. Но это ещё не всё – помимо ужесточения дефолтного поведения, можно явно указать модули, которым так делать (тихо шариться по Export Address Table) нельзя, потому что им, по идее, это не нужно для нормальной работы. Например, Adobe Flash. Чтобы добавить это, нужно залезть в ключ реестра (надеюсь, к выходу EMET 5.0 RTM сделают интерфейс всё же):
HKLM\SOFTWARE\Microsoft\EMET\_settings_\{CLSID приложения}\, создать там REG_SZ значение eaf_modules и написать туда список исполняемых модулей через точку с запятой – например, “flash*.ocx;mshtml.dll”. Как видно, можно использовать wildcard’ы. Глобально такой список сделать, увы, нельзя – только для конкретного приложения. По умолчанию включение EAF+ добавляет ко всем экземплярам IE версии 10 и выше (даже если этот ключ реестра не создан) фильтрацию нехороших действий в плане EAT от таких модулей: “mshtml.dll;flash*.ocx;jscript*.dll;vbscript.dll;vgx.dll”
Attack Surface Reduction
Данная новая возможность позволяет явно запретить конкретному приложению загружать конкретный модуль, притом достаточно гибко – с учётом того, в какой security zone находится данный модуль. Т.е. можно, допустим, разрешить загрузку Adobe Flash со страницы в Intranet, но запретить в случае, если его просит загрузить страница из Restricted (Untrusted).
Идея хорошая, но пока что надо делать всё опять вручную через реестр. Как?
Первым делом, идём в ключ целевого приложения, которому надо запретить подгружать модули:
HKLM\SOFTWARE\Microsoft\EMET\_settings_\{CLSID приложения}\, и создаём там REG_SZ с названием asr_modules. Туда, в том же синтаксисе, что и в случае с EAF+, пишем один или более модулей, которые надо разрешить подгружать.
Второе – после, в этом же ключе создаём REG_SZ asr_zones и – внимание! – указываем там через точку с запятой номера зон, из которых будет _можно_ подгружать указанные модули. В документации написано наоборот, по факту работает именно так. Номера зон безопасности стандартные и привычные для тех, кто уже намучался с настройкой Internet Explorer через Group Policy – локальные страницы – 0, интранет – 1, trusted sites – 2, весь Интернет 3, недоверенные / ограниченные – 4. То есть, если хотите, чтобы Flash работал везде, кроме Restricted – в asr_zones надо написать “0;1;2;3”. Если не написать в asr_zones ничего, то указанный модуль/модули нельзя будет загружать вообще ниоткуда.
Распределять же ресурсы по зонам можно как обычно – или вручную, во вкладке Security у IE, или через групповые политики.
В общем-то пока всё – будут новые версии – разберём новый функционал. Ну, а если ещё не используете EMET – пора, давно пора. :)
Удачного применения!
