Как взломать непропатченный сервер Exchange с помощью мошеннического кода PowerShell

Чуть менее двух месяцев назад появились тревожные новости об ошибках: в Microsoft Exchange было объявлено о паре уязвимостей нулевого дня.

Как мы советовал в свое время, эти уязвимости, официально обозначенные CVE-2022-41040 и CVE-2022-41082:

[были] два нулевых дня, которые [могли] быть связаны друг с другом, при этом первая ошибка использовалась удаленно, чтобы открыть достаточную дыру, чтобы вызвать вторую ошибку, которая потенциально позволяет удаленное выполнение кода (RCE) на самом сервере Exchange.

Первая уязвимость напоминала проблемную и широко используемую Дыра в безопасности ProxyShell еще в августе 2021 года, поскольку он полагался на опасное поведение функции автообнаружения Exchange, описано Майкрософт как протокол, который «используется клиентами Outlook и EAS [Exchange ActiveSync] для поиска и подключения к почтовым ящикам в Exchange».

К счастью, ошибка автообнаружения, которая могла быть использована в атаке ProxyShell любым удаленным пользователем, вне зависимости от того, вошел он в систему или нет, была устранена. исправлено больше года назад.

К сожалению, исправления ProxyShell не сделали достаточно, чтобы закрыть эксплойт для аутентифицированных пользователей, что привело к новой уязвимости нулевого дня CVE-2022-40140, которая вскоре лаконично, хотя и вводила в заблуждение, была дублированный Проксинотшелл.

Не так опасно, но все же опасно

Ясно, что ProxyNotShell был далеко не так опасен, как исходный ProxyShell, учитывая, что он требовал так называемого доступа с проверкой подлинности, поэтому он не был открыт для злоупотреблений кем угодно и откуда угодно.

Но быстро выяснилось, что на многих серверах Exchange знание имени и пароля любого пользователя для входа в систему было бы достаточно, чтобы сойти за аутентифицированного и организовать эту атаку, даже если этому пользователю самому потребуется использовать двухфакторную аутентификацию (2FA) для правильного входа в систему для доступа. их электронная почта.

Эксперт Sophos Честер Вишневски положите в то время:

Если хотите, это «уязвимость промежуточной аутентификации». Это смешанное благословение. Это означает, что автоматизированный сценарий Python не может просто просканировать весь Интернет и потенциально использовать каждый сервер Exchange в мире за считанные минуты или часы, как это произошло с ProxyLogon и ProxyShell в 2021 году. […]

Вам нужен пароль, но, к сожалению, найти одну комбинацию адреса электронной почты и пароля, действующую на любом заданном сервере Exchange, не так уж сложно. И вы, возможно, еще не подверглись эксплуатации, потому что для успешного входа в Outlook Web Access [OWA] требуется их токен FIDO, или их аутентификатор, или любой второй фактор, который вы можете использовать.

Но эта атака не требует второго фактора. […] Простое получение комбинации имени пользователя и пароля — довольно низкий барьер.

Как вы, наверное, помните, многие из нас предполагали (или, по крайней мере, надеялись), что Microsoft поспешит исправить дыры в ProxyNotShell, учитывая, что до октябрьского вторника исправлений оставалось еще две недели.

Но мы были разочарованы, обнаружив, что надежное исправление, по-видимому, сложнее, чем ожидалось, а в октябре пришел и ушел ProxyNotShell, решаемый только обходными путями, а не соответствующими исправлениями.

Даже ноябрьский вторник исправлений напрямую не предоставил необходимых исправлений, хотя исправления все же вышел в тот же день как часть обновления безопасности для Exchange, которое можно загрузить и установить отдельно:

Обнародовано доказательство концепции

Теперь, когда пыль улеглась и у всех было время пропатчить свои серверы Exchange (по крайней мере, те, о которых они не забыли), исследователи из Zero Day Initiative (ZDI), которым эти уязвимости изначально были ответственно раскрыты для отправки в Майкрософт, объяснили как можно использовать ошибки.

Плохая новость, в зависимости от вашего мнения о открытом раскрытии эксплойтов, заключается в том, что команда ZDI фактически предоставила доказательство концепции (PoC), объясняющее, как атаковать серверы Exchange.

Хорошая новость, конечно, в том, что:

• Теперь мы можем изучать и понимать ошибки сами. Это не только помогает всем нам убедиться в том, что принятые нами общие меры предосторожности (не ограничиваясь только установкой исправлений), вероятно, обеспечат ожидаемую защиту, но также информирует нас о методах программирования, которых мы хотели бы избегать в будущем, поэтому мы не не попасть в ловушку, открывая ошибки такого рода в нашем собственном коде на стороне сервера.
• Теперь у нас не осталось оправданий для того, чтобы не применять патчи. Если мы затянули с обновлением, объяснение ZDI того, почему атака работает, ясно дает понять, что лекарство определенно предпочтительнее болезни.

Как это работает?

ЗДИ объяснение об этой уязвимости представляет собой захватывающий рассказ о том, насколько сложным может быть связать воедино все части, необходимые для превращения уязвимости в жизнеспособный эксплойт.

Ее также стоит прочесть, чтобы понять, почему изучение существующего эксплойта может помочь выявить другие способы злоупотребления уязвимостью, что потенциально может привести к дополнительным исправлениям, призывам к изменениям конфигурации и продвижению новых методов программирования, которые могли быть неочевидны после исправления. оригинальная дырка.

Объяснение, по необходимости, сложное и довольно техническое, и ведет вас вперед через длинную серию шагов для достижения удаленного выполнения кода (RCE) в конце.

В надежде на то, что вам будет легче следить за деталями высокого уровня, если вы решите прочитать отчет ZDI, вот краткое изложение, надеюсь, не слишком упрощенное, с шагами, перечисленными в обратном порядке…

…так что вы будете знать заранее, почему история развивается именно так:

• ШАГ 4. Удаленно обманным путем заставьте Exchange создать экземпляр объекта .NET по вашему выбору с параметром инициализации по вашему выбору.

В современном кодировании экземпляр объекта это жаргонное слово, обозначающее выделенный фрагмент памяти, автоматически инициализируемый данными и ресурсами, которые ему потребуются во время его использования, и привязанный к определенному набору функций, которые могут с ним работать. (Создать экземпляр просто красивое слово для Создайте.)

Объекты могут управляться и контролироваться самой операционной системой, чтобы помочь избежать ошибок неправильного управления памятью, характерных для таких языков, как C, где вам обычно нужно выделять память самостоятельно, заполнять соответствующие поля данных вручную и не забывать освободите память и ресурсы, которые вы используете, такие как сетевые сокеты или файлы на диске, когда вы закончите.

Объекты обычно имеют связанную с ними программную функцию, называемую конструктор, который автоматически выполняется при создании нового объекта, чтобы выделить нужный объем памяти и правильный набор системных ресурсов.

Обычно вам нужно передать один или несколько параметров в качестве аргументов конструктору, чтобы указать, как вы хотите, чтобы объект был сконфигурирован при запуске.

Проще говоря, если вы создаете экземпляр, скажем, TextString объекта (мы придумываем эти имена, но вы поняли идею), используя параметр, который сам является текстовой строкой, такой как example.com:8888...

… вы, вероятно, в конечном итоге получите буфер памяти, выделенный для хранения вашего текста, инициализированный так, чтобы он содержал то же значение, которое вы передали, а именно необработанный текст example.com:8888.

В этом контексте текстовая строка, переданная конструктору объекта в качестве данных, не представляет немедленной очевидной угрозы кибербезопасности при удаленном запуске конструктора, за исключением возможного отказа в обслуживании (DoS) путем многократного запроса все более и более крупных строк для попробуй исчерпать память.

Но если бы вы создавали экземпляр, скажем, ConnectedTCPClient объект, использующий тот же параметр текстовой строки, что и example.com:8888, вы можете получить буфер памяти, готовый для хранения временных данных, а также сетевой сокет, выделенный операционной системой, который готов обмениваться данными с сервером. example.com через TCP-порт 8888.

Вы можете увидеть здесь риск удаленного выполнения кода, даже если вам никогда не удастся отправить какие-либо данные в открытый сокет, учитывая, что вы обманом заставили сервер позвонить домой в место, которое вы контролируете.

Вы можете даже найти объект с именем, скажем, RunCmdAndReadOutput, где текстовая строка, которую вы отправляете в качестве параметра, в буквальном смысле представляет собой команду, которую вы хотите запустить автоматически, как только объект будет создан, чтобы вы могли позже собрать ее выходные данные.

Даже если вам никогда не удастся восстановить вывод команды, простое создание экземпляра такого объекта, тем не менее, позволит вам выбрать команду для запуска, что даст вам общее удаленное выполнение кода и представляет риск, ограниченный только правами доступа самого серверного процесса. .

Конечно, атака становится настолько простой только после того, как вы дойдете до последней стадии, которую вы не должны делать, потому что Exchange имеет строгий список разрешений, который запрещает вам выбирать любой старый объект для создания экземпляра.

Теоретически только безопасные объекты или объекты с низким уровнем риска могут быть созданы удаленно с помощью PowerShell, так что создание экземпляра нашего воображаемого TextString выше, или SimpleIntegerValue, можно считать приемлемым, в то время как ConnectedTCPClient или RunCmdAndReadOutput точно не будет.

Но исследователи ZDI замечают, что перед тем, как запустить последний шаг, они могли сделать это:

• ШАГ 3. Удаленно обманите Exchange, заставив его думать, что объект с низким уровнем риска, прошедший тест на безопасность, на самом деле является каким-то другим объектом по вашему выбору.

Даже в этом случае вы можете ожидать, что Exchange предотвратит удаленное создание даже объектов с низким уровнем риска, чтобы еще больше минимизировать угрозу.

Но исследователи обнаружили, что они могут:

• ШАГ 2. Удаленно обманом заставить Exchange использовать его Удаленное взаимодействие PowerShell возможность создания объекта на основе параметров инициализации, управляемых извне.

И это стало возможным из-за дыры, похожей на ProxyShell, которая была лишь наполовину исправлена:

• ШАГ 1. Удаленно обманом заставить Exchange принять и обработать веб-запрос с кодом, упаковав действительный username:password поле в запросе, а также.

Даже если пользователь, указанный в запросе, на самом деле не вошел в систему и ему нужно было пройти какой-то процесс 2FA для доступа к своему почтовому ящику, злоумышленник, который знал его username:password комбинация будет иметь достаточно информации для проверки подлинности, чтобы заставить Exchange принять веб-соединение, которое можно использовать для запуска цепочки атак, описанной в шагах 2–4 выше.

Грубо говоря, любой действительный username:password такая комбинация подойдет, учитывая, что «аутентификация» была необходима просто для того, чтобы Exchange не отклонил HTTP-запрос заранее.

Что делать?

Обратите внимание, что эта атака работает только:

• Если у вас есть локальные серверы Exchange. Microsoft утверждает, что быстро заблокировала свои собственные облачные службы, поэтому Exchange Online не пострадал. Убедись, что ты знать, где находятся ваши серверы Exchange. Даже если вы теперь используете Exchange Online, у вас все еще могут быть запущены локальные серверы, которые, возможно, остались по ошибке в процессе миграции.
• Если ваши серверы не пропатчены. Убедитесь, что у вас есть применил обновление программного обеспечения Exchange от 2022 ноября 11 г. в закрыть уязвимости что требует эксплойт.
• Если ваши серверы по-прежнему принимают обычную аутентификацию, также известную как устаревшая аутентификация. Убедитесь, что у вас есть заблокировал все аспекты устаревшей аутентификации так что ваши серверы не будут принимать username:password заголовки, упомянутые выше, и в первую очередь не будет принимать рискованные запросы протокола автообнаружения. Этот останавливает атакующих заставить сервер принять их трюки с созданием объектов-ловушек, даже если этот сервер не исправлен.

Вы можете следить за наших официальных советов по предотвращению, исправлению и реагированию, а клиенты Sophos могут отслеживать имена обнаружения угроз, используемые нашими продуктами, через ленту Sophos X-Ops в Твиттере (@SophosXOps).

Опубликована новая информация о CVE-2022-41040 и CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 21 ноября 2022

---

УЗНАЙТЕ БОЛЬШЕ О АУТЕНТИФИКАЦИИ EXCHANGE И OAUTH2

С Полом Даклином и Честером Вишневски
Интро и аутро музыка Эдит Мадж.

---