Новый EMET 3.5 – механизмы ROP

Привет.

Совсем недавно я рассказывал про EMET 3.0 и жаловался, мол в части удобства развёртывания на сервера и рабочие станции, управления через групповые политики и прочего плюсов много, а функционал остался тот же – как добавили чуток в 2.1, так и оставили до сих пор. Microsoft ответил оперативно – новая версия EMET 3.5 поднимает планку безопасности ещё выше.

Новое разделение классов защитных механизмов
Механизм EMET LoadLib
Механизм EMET MemProt
Механизм EMET StackPivot
Механизм EMET SimExecFlow
Механизм EMET Caller Checks
Где скачать?
Дополнительные параметры, доступные через реестр

Приступим.

Новое разделение классов защитных механизмов

Механизмов защиты теперь много, и для удобства их разделили на три класса – механизмы защиты оперативной памяти (Memory), новые механизмы предотвращения действий, классифицируемых как атаки с использованием ROP (Return Oriented Programming, “возвратно-ориентированного программирования”, которое является развитием того, что раньше называлось “return-to-libc” и имеет бОльшие возможности, чем предшественник) и “прочие механизмы” (Other):

Новый EMET 3.5 – разделение механизмов защиты по классам
(кликните для увеличения до 842 px на 559 px)

Новый класс механизмов адресно работает с т.н. “критичными с точки зрения безопасности” API-функциями – например, LoadLibrary или HeapCreate. Посмотрим, что конкретнее добавляет каждый механизм:

Механизм EMET LoadLib

Механизм достаточно прост. Суть его в том, что EMET будет отслеживать все запросы на подгрузку библиотек, и если результатом будет попытка загрузить библиотеку с UNC-расположения (например, вида \\89.111.177.204\c$\crypt32.dll), то попытка будет пресечена. Этот механизм имеет смысл включать, когда Вы уверены, что подпадающий под неё exe-модуль никогда не будет подгружать библиотеки не с локального хоста.

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

Механизм EMET MemProt

Тоже простая штука – сегменты стека блокируются для выполнения кода. Развитие DEP, так сказать – только DEP блокировал сегменты данных, а MemProt – стека. Включение и того и того приведёт к тому, что адрес следующей выполняемой инструкции сможет быть только внутри сегментов кода и никаких других. Надо включать.

Механизм EMET StackPivot

EMET будет отслеживать, не перенаправляются ли обращения к сегментам, помеченым как стек. Т.е. если в ходе работы ПО будет обращение к стеку, но оно будет использовать новый адрес в памяти – EMET, отслеживая историю обращений, поймёт, что что-то пошло не так, предположит, что имеет место атака, и остановит работу приложения. Целесообразно включать на всём ПО, т.к. штатных ситуаций, когда ПО делает push в нормальный сегмент стека, а данные для pop почему-то забираются из другого, практически нет.

Механизм EMET SimExecFlow

EMET будет пробно анализировать некоторое количество инструкций, следующих за возвратом из критичной функции (стандартно это 15, но можно и увеличить, открыв в EMET-настройках конкретного приложения в реестре):

Устанавливаем глубину анализа кода EMET 3.5
(кликните для увеличения до 920 px на 335 px)

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

Механизм EMET Caller Check

Один из самых эффективных механизмов. EMET будет отслеживать ситуацию, когда в критичную функцию вернулось управление, но почему-то не путём выполнения инструкции RET, а иным способом. Это отсекает целый класс хитрых механизмов, базирующихся на логике “не вызывать критичную функцию напрямую, т.к. это легко отследить, а имитировать, что мы возвращаемся в неё после вызова другой”. Как самый эффективный механизм, данный является и самым проблемным с точки зрения совместимости. Проверьте тщательно функционирование всего ПО, для которого примените этот механизм.

Дополнительные параметры, доступные через реестр

Здесь особо ничего не поменялось. Как и раньше, можно на свой страх и риск включить возможность “глобального ASLR” – это увеличит уровень безопасности системы, но вот не все драйверы сторонних производителей это корректно поддерживают. Для этого необходимо поправить тот же ключ реестра, что и ранее, HKLM\SOFTWARE\Microsoft\EMET\, поставив там параметр EnableUnsafeSetting в единицу. Тогда станет доступна опция Always On у ASLR:

Включаем ASLR на уровне ОС с помощью EMET 3.5
(кликните для увеличения до 545 px на 303 px)

Также через реестр доступна опция отключения уведомлений EMET – функции, которая появилась, начиная с версии 3.0 (иконка в трее). Допустим, если Вы не мониторите визуально сервер, то уведомления на нём не очень нужны – в этом случае можно в этом же ключе создать DWORD32 с именем NotifierLogLevel и поставить его в нуль. Удобно в ситуации массового развёртывания, да и в сценарии с терминальным сервером, например.

В общем-то всё.

Где скачать?

Здесь – https://www.microsoft.com/en-us/download/details.aspx?id=30424. Учитывайте, что это пока Technology Preview, рабочая версия – 3.0.

Вместо заключения

Скоро такими темпами антивирусы начнут отключать EMET, чтобы хоть какие-то срабатывания были. :)

На самом деле, хорошо, что практичный и удобный инструмент развивается достаточно быстрыми темпами, и Microsoft с упреждением работает над механизмами безопасности, предотвращая даже такие механизмы, которые пока ни разу не срабатывали в виде готовых эксплойтов. Использование EMET для усиления защиты хостов на базе Windows становится “частью обязательной программы”, поэтому не откладывайте внедрение этого ценного инструмента.

Удач!

Возможно, вам будет также интересно почитать другие статьи про EMET на нашей Knowledge Base