Инженеры Microsoft обновили свои рекомендации по защите от 0-day уязвимостей в Exchange (CVE-2022-41040 и CVE-2022-41082), которые известны под названием ProxyNotShell. Проблема в том, что патчей для этих проблем все еще нет, а ИБ-исследователи продемонстрировали, что изначальные защитные рекомендации компании можно было легко обойти.
Напомню, что на прошлой неделе аналитики из вьетнамской компании GTSC рассказали о двух уязвимостях нулевого дня в Microsoft Exchange: CVE-2022-41040 и CVE-2022-41082, которым ИБ-специалисты присвоили название ProxyNotShell.
Как вскоре подтвердили в Microsoft, эти проблемы уже взяты на вооружение хакерами и позволяют выполнить произвольный код. По данным экспертов, как минимум одна группировка уже использовала эти баги против примерно 10 компаний по всему миру.
«Первая уязвимость с идентификатором CVE-2022-41040, представляет собой проблему SSRF, а вторая, с идентификатором CVE-2022-41082, допускает удаленное выполнение кода (RCE), если PowerShell доступен для злоумышленника», — сообщают в Microsoft.
Пока эксперты держат технические детали уязвимостей в тайне, чтобы еще большее число злоумышленников не занялось их эксплуатацией. Но когда о багах стало известно, Microsoft выпустила рекомендации по смягчению проблемы. Увы, предложенное инженерами правило блокировки URL-адресов оказалось слишком специфичным, и как вскоре продемонстрировали ИБ-специалисты, его можно легко обойти.
Так как специалисты предложили свои способы временного решения проблемы, Microsoft рассмотрела их и представила обновленную версию рекомендаций по защите от ProxyNotShell. На скриншоте ниже показаны основные отличия улучшенной рекомендации от изначальной.
При этом ИБ-исследователи быстро заметили, что условие {URL} to {REQUEST_URI} в правиле для перезаписи URL-адресов по-прежнему позволяет злоумышленникам обойти защитные меры. К примеру, аналитик Питер Хиле отмечает, что условие фильтрации строк в URI не учитывает кодировку символов, и это, в сущности, делает правило неэффективным.
Известный ИБ-эксперт и бывший аналитик CERT/CC Уилл Дорманн согласен с мнением Хиле и объясняет, что {REQUEST_URI} бесполезен при кодировании символов. По его словам, лучше применять {UrlDecode:{REQUEST_URI}}.
Другой известный ИБ-специалист, Кевин Бомонт, давший уязвимостям имя ProxyNotShell, пишет, что его коллеги правы: эксплуатация ProxyNotShell продолжается, причем хакеры обходят как предыдущий, так и более новый способ защиты, предложенный Microsoft.
В итоге Microsoft вынуждена была еще раз пересмотреть свои рекомендации по защите от ProxyNotShell. Так, клиенты с включенной Exchange Emergency Mitigation Service (EEMS) автоматически получают обновленную защиту от перезаписи URL-адресов для Exchange Server 2016 и Exchange Server 2019.
Специальный скрипт EOMTv2 (версия 22.10.03.1829) теперь тоже включает улучшенное правило перезаписи URL. Он автоматически обновляется на компьютерах, подключенных к интернету, и его следует снова запустить на любом сервере Exchange без включенной EEMS.
Третий вариант — вручную удалить ранее созданное правило и добавить улучшенное:
- открыть диспетчер IIS;
- выбрать сайт по умолчанию;
- во Feature View нажать на URL Rewrite;
- в панели Actions справа кликнуть на Add Rule(s)…;
- выбрать Request Blocking и нажать «ОК»;
- добавить строку «.*autodiscover\.json.*Powershell.*» (без кавычек);
- в Using выбрать пункт Regular Expression;
- в разделе How to block выбрать пункт Abort Request, а затем нажать «ОК»;
- развернуть правило и выбрать правило с шаблоном: .*autodiscover\.json.*Powershell.*и кликнуть на Edit в разделе Conditions;
- изменить {URL} на {UrlDecode:{REQUEST_URI}}.
Кроме того, Microsoft настоятельно рекомендует отключать удаленный доступ PowerShell для пользователей без прав администратора.
Напомню, что резонанс вокруг этих уязвимостей настолько велик, что на GitHub уже пытаются продавать фальшивые эксплоиты для ProxyNotShell. Исследователи из компании Flashpoint и вовсе сообщают, что на русскоязычном форуме Exploit эксплоит для свежих уязвимостей на днях продали за 250 000 долларов США. Был ли этот эксплоит настоящим, специалистам выяснить не удалось.
