Новое в EMET 4.1 и Certificate Pinning

Привет.

Вышел новый EMET 4.1 – поэтому надо посмотреть, что нового в нём появилось. Плюс, хочется осветить одну из ключевых новых функций EMET 4.0 – технологию Certificate Pinning. Данная технология предотвращает целый класс неприятностей и обязательна к использованию для безопасной работы в современном Интернете, но имеет в данной реализации некоторые ньюансы в применении.

Про что же пойдёт речь?

Новое в EMET 4.1 и Certificate Pinning

Нововведения в EMET 4.1 относительно EMET 4.0
- Редактирование pop-up сообщения
- Защита не только Internet Explorer
- Улучшенное журналирование
Зачем и как работает Certificate Pinning
Настраиваем Certificate Pinning для Альфа-Клик

Начнём.

Нововведения в EMET 4.1 относительно EMET 4.0

Нововведений относительно немного, что и логично – это minor-обновление.

Редактирование pop-up сообщения

Когда EMET обнаруживает проблему, справа внизу экрана всплывает окно с текстом. Теперь этот текст можно редактировать – достаточно зайти в EMET-овский ключ реестра HKLM\SOFTWARE\Microsoft\EMET, создать там REG_SZ значение TrayIconMsg и написать туда то, что захочется. Это удобно для корпоративного использования – например, можно в явном виде (через шаблон Group Policy) написать что-то вида “Нарушение внешнего контура защиты; позвоните админу по внутреннему номеру 1003, назвав ему код PZC, иначе отдел кадров повторно рассмотрит вопрос о Вашей годовой премии”. Для усиления эффекта и в случае особо монолитных головой пользователей можно раздавать через GPO персонализированное сообщение для каждого отдельно, включая ФИО и должность – обычно на такие сообщения реагируют ощутимо чаще, и сказать “оно там что-то написало, я не понял и не обратил внимание” будет сложнее.

Защита не только Internet Explorer

Это экспериментальная новая функция, хотя работает она без нареканий. Суть в следующем – в принципе, EMET ведь защищает механизмом Certificate Pinning не установку SSL/TLS сессии Internet Explorer’ом как таковым, а функционал SSL из CNG. Вы можете попросить EMET защитить любое приложение, указав имя исполняемого файла этого приложения в ключе реестра HKLM\SOFTWARE\Microsoft\EMET, создав там REG_SZ значение EMET_CE и разделяя имена точкой с запятой (без пробелов). Например, так: “iexplore.exe;anotherbrowser.exe;bankclient.exe”. Вы можете добавить туда, допустим, исполняемые файлы сервисов Exchange 2013, или exe-файл банк-клиента – в этом случае – и это очень хорошее нововведение – система будет отслеживать попытки проксирования SSL/TLS-сессий для данных, весьма важных приложений.

Улучшенное журналирование

В EMET 4.1 появилось больше кодов событий, что позволяет системному инженеру более гибко настраивать форвардинг именно нужных типов событий. Если раньше их было только три (00 для Information, 01 для Warning и 02 для Error), то теперь события классифицируемы по генерирующей их подсистеме EMET. Стартовый знак, который раньше был везде нулём, теперь разный – например у warning от подсистемы Certificate Pinning будет код 41, а не 01, у ошибки – 42, а не 02, и далее по аналогии. Учитывайте также исключения – не журналируются события в случае срабатывания mitigation при Bottom Up и Null Page, и – важно! – работает это журналирование только для Desktop-приложений. Ошибки в Modern, которые до этого Metro, в случае таких ситуаций не пишутся.

Зачем и как работает Certificate Pinning

При подключении к SSL/TLS ресурсам сервер всегда предъявляет свой сертификат. Если сертификат:

Просроченный
Ещё не начал действовать
С некорректной подписью
Использует неизвестные алгоритмы
Не содержит в Subject или в SAN имени сервера, к которому фактически идёт подключение

то вы увидите явное предупреждение со стороны браузера. Это грубые ошибки, которые браузер найдёт в сертификате сразу, никуда особо не подключаясь.

Более сложной будет проверка цепочки доверия. Она потребует последовательно изучить всю последовательность сертификатов, начиная с сертификата того CA, который выдал сертификат серверу, и заканчивая на моменте, когда очередной проверяемый сертификат окажется в одном из trusted-хранилищ. Это необязательно будет Root CA – вы можете явно доверять и одному из промежуточных. Эта проверка также будет проведена браузером и в случае неудачи вы увидите это явно – будет предупреждение.

Но на данный момент существует вариант, угрожающий вашим данным, который не отслеживается таким способом. Речь про проксирование SSL/TLS сессии, состоящее в том, что некий промежуточный узел устанавливает сессию с ресурсом, который вы запрашиваете, загружает себе ответ сервера, а после устанавливает сессию с вашим браузером, “прикидываясь” оригинальным источником. В результате он может читать ваш трафик, “разворачивая” на себе сессию. Понятное дело, сертификат, который он будет предъявлять вам, должен содержать то же самое имя сервера, плюс быть выданым от доверенного источника. Это непросто – и есть три основных варианта такой ситуации:

Вы работаете с корпоративного компьютера и ваши сессии проксируются на выходе из сети. Специфичный софт (допустим, тот же Microsoft TMG 2010) в момент, когда вы устанавливаете сессию с внешним узлом, “на лету” генерит сертификат с нужным именем и показывает его вашему браузеру. Так как сертификат, которым он выдан/подписан, заранее добавлен заботливыми IT-сотрудниками в ваше локальное хранилище доверенных сертификатов (через group policy, допустим), вы ничего не замечаете.
Кто-то получил несанкционированный доступ к одному из промежуточных CA и смог выписать сертификат на нужное имя сервера, и использует это для фишинга.
Вы подключаетесь к защищённым ресурсам из чужой (или гостевой сети), где все SSL/TLS-сессии проксируются с какими-либо целями.

В первых двух случаях ключевым будет, что сертификат является доверенным, но отличается от того, который используется настоящим сервером. В третьем сертификат доверенным не будет, но совершенно необязательно, что ПО, которое подключается, явно и наглядно предупредит об этом. Допустим, Microsoft Outlook предупреждает, и большинство банк-клиентов тоже – но всё же данные предупреждения могут быть и проигнорированы пользователем, и малозаметны – за всё ПО ручаться нельзя. Поэтому польза от этого нововведения в EMET 4.1 весома – не только тем, что будет наглядное предупреждение именно от системы защиты (а не стандартно игнорируемое пользователем “что-то программа написала я нажалО ОК и дальше работал”, но и тем, что будет генериться стандартное и легко фильтруемое/перенаправляемое сообщение в event log. Мониторинг этого и будет целью Certificate Pinning. Давайте разберемся, как это настраивается.

Настраиваем Certificate Pinning для Альфа-Клик

Открываем click.alfabank.ru и видим, что корневым сертификатом, который подписывает цепочку, является сертификат thawte Primary Root CA. Скачиваем его, добавляем в корневые доверенные (если его там ещё нет):

Корневой сертификат Thawte, используемый для Альфа-Клик
(кликните для увеличения до 796 px на 428 px)

Создаём правило соответствия (pinning rule), которое явно указывает, что для завершения проверки цепочки доверия для домена click.alfabank.ru может использоваться только данный сертификат:

Правило для Альфа-Клик в EMET Certificate Pinning
(кликните для увеличения до 896 px на 648 px)

Если хочется сделать сразу правило на весь домен второго уровня, чтобы не мелочиться – ну, типа *.alfabank.ru – забудьте. EMET не поддерживает wildcard в pinning rules.

Отдельно хочу остановиться на параметре PublicKey Match, который, как заметно на скриншоте, у разных правил разный. Данный параметр не усиливает безопасность правила, а снижает её, по сути действуя так – если сертификат RootCA не подпал под правило, то достаточно, чтобы у него совпадал только открытый ключ. Т.е. у сертификата могут поменяться другие поля – дата выдачи, например (удобно, если хочется, чтобы после продления действия корневого CA на том же ключе правило не стало нерабочим), или даже subject name (например, сертификат RootCA обновили, поменяв ему имя в силу изменения локального стандарта именования сертификатов – так было, к примеру, у GoDaddy, когда у сертификатов после смены SHA-1 на SHA-2/256 появились буквы G2 (Generation 2) в названии). Если нужно, чтобы правило было именно на точное соответствие, никакие доп.параметры типа страны, длины ключа и прочего выставлять не нужно, это смягчающие, а не ужесточающие настройки.

Теперь создадим правило доступа к домену, используя готовое правило соответствия:

Защищаем доступ к Альфа-Клик
(кликните для увеличения до 896 px на 648 px)

В общем-то всё, проверка работает. Так что осталось всего ничего – начать использовать. Данный функционал нельзя недооценивать, поскольку он может целиком и полностью убрать целый класс фишинговых атак, направленных на компрометацию данных пользователя, который тот передаёт открытым текстом поверх предположительно надёжной SSL/TLS сессии. Это может быть как домашний пользователь, не слишком искушённый в безопасности (совершенно не лишним будет включить certificate pinning для всех используемых соц.сетей и соц.сервисов, а также почты), так и корпоративный (веб-интерфейсы банк-клиентов, защищённая почта).

Удачного применения!

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