Привет.
Популярный инструмент для укрепления защищённости ОС и ПО, Enhanced Mitigation Experience Toolkit, получил очередную версию – 5.1. Давайте посмотрим, что будет интересного в ней – чуток повторимся на тему того, что нового появилось ещё в EMET 5.0 Technology Preview, но ещё и добавим то, что вышло в EMET 5.0 RTM, в пакетном обновлении KB3015976 для EMET 5.0, и в EMET 5.1 – ну, чтобы не плодить крохотные статьи про каждый чих.
Новое в EMET 5.1
- Исправление ошибок версии 5.0
- Улучшенная защита часто используемого стороннего ПО
- EAF+
- Новое журналирование – Local Telemetry
- ASR – Attack Surface Reduction
Начнём.
Исправление ошибок версии 5.0
Исправлено огромное число вопросов несовместимости – это и проблемы работы Certificate Pinning с 64х битовым IE 10 и старше, проблемы Adobe Flash и Adobe Reader, проблемы в Mandatory ASLR, проблемы при установке EMET не в папку по умолчанию, и главное – теперь IE 11 не падает при включённом EAF+. Это показывает, что работа над EMET полезна ещё и тем, что данный инструмент позволяет улучшать качество кода других подразделений Microsoft – не только некоего абстрактного “стороннего ПО других разработчиков”, в отношении которого можно включить различные mitigation, но и встроенных в ОС программ. Поэтому, если у Вас установлен EMET 5.0 – обновите его оперативно до EMET 5.1, или как минимум поставьте патч KB 3015976. Иначе полностью пропатченный IE 11 будет просто закрываться с ошибкой при начале работы.
Улучшенная защита часто используемого стороннего ПО
При установке EMET сам предлагает использовать некие “типовые настройки безопасности” – в принципе, это можно как принимать, так и настраивать всё вручную. Безусловно, правильная настройка EMET на уровне предприятия – задача достаточно нетривиальная, требующая много навыков и опыта – но Microsoft значительно облегчает её, добавляя справочные сведения о том, как то или иное ПО стороннего производителя реагирует на те или иные EMET mitigations. Эти справочные данные есть как на официальной странице EMET – теперь она по удобному пути, https://www.microsoft.com/emet, так и в специализированных статьях KB – допустим, KB2909257.
Учитывайте, что всё это – не аксиомы, а лишь рекомендации, потому что после выхода любого патча ПО, которое было совместимо с определённым EMET mitigation, запросто может стать несовместимым, и наоборот. Вопрос качества разработки стороннего ПО – это то, с чем EMET вынужден сосуществовать, а не бороться.
Кстати, что ж это за зловредный новый EAF+, который был одним из ключевых нововведений 5й линейки EMET, и который так нарушает работу многих привычных сервисов?
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”
Новое журналирование – Local Telemetry
Ранее EMET был способен создавать и отправлять подробные отчёты о происходящем – но только в случае включения режима Early Warning в меню:
Early Warning в EMET 5.0(кликните для увеличения до 660 px на 650 px)Ruslan V. Karmanovrk@atraining.ruУчебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/
Теперь эту информацию можно во-первых отбирать более тщательно, во-вторых – хранить локально, а не отправлять наружу. Делается это, как обычно для интересного функционала EMET, через жо реестр:
Первым делом – идём в ключ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET и создаём там параметр типа REG_SZ с названием LocalTelemetryPath. Это абсолютный путь к папке, где будут лежать файлы с журналом – вида C:\EMETLogs. Никаких URL и UNC.
Вторым действием создаём рядом с ним параметр типа REG_DWORD с названием MiniDumpFlags. Его значением по-умолчанию будет 9 включенных бит – 0x000001FF, но это можно задавать и детальнее – данная структура описана вот по этой ссылке: https://msdn.microsoft.com/library/windows/desktop/ms680519(v=vs.85).aspx.
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 – пора, давно пора. :)
Удачного применения!
