Виноваты «пещерные пользователи»? Microsoft отказалась исправлять RCE в .NET, найденную на Black Hat

ИБ-специалисты рассказали об уязвимости в .NET, которая может затрагивать множество корпоративных продуктов и приводить к удалённому выполнению кода. Проблема связана с тем, как приложения на базе Microsoft .NET обрабатывают SOAP-сообщения, а Microsoft, по словам исследователей, отказывается её исправлять, перекладывая ответственность на разработчиков и пользователей.

О находке на конференции Black Hat Europe сообщил Piotr Bazydło из компании watchTowr. По его словам, целый ряд коммерческих и внутренних решений уязвим для атак с удалённым выполнением кода (RCE) из-за ошибок в обработке SOAP-сообщений в приложениях, построенных на .NET.

Ключевой проблемой стал класс SoapHttpClientProtocol. Исследователь объяснил, что он может использоваться атакующими по-разному, в зависимости от их целей. Этот класс наследуется от HttpWebClientProtocol, как и другие клиентские прокси, но именно SoapHttpClientProtocol чаще всего встречается в кодовой базе, поэтому watchTowr сосредоточила внимание на нём.

На бумаге всё выглядит безобидно: и название класса, и официальная документация говорят о том, что он должен работать с SOAP-сообщениями по HTTP. «Простой, предсказуемый и безопасный» сценарий, как иронично замечает Bazydło. На практике всё сложнее.

Класс отвечает за установку целевого URL SOAP-сервиса и вызов SOAP-метода. Уязвимость возникает в момент, когда злоумышленник может повлиять на этот URL и на то, как SoapHttpClientProtocol создаёт клиент. Хотя по идее он должен работать с HTTP-запросами, внутри используется обобщённый механизм, который поддерживает сразу несколько протоколов: HTTP/HTTPS, FTP и даже FILE.

Если атакующий подставит вместо веб-адреса URL, указывающий на файловую систему, класс не выдаст ошибку, а просто запишет SOAP-запрос (отправляемый методом POST) прямо в файл. «Почему вообще SOAP-прокси должен "отправлять" запросы в локальный файл? Никто в здравом уме не ожидает получить валидный SOAP-ответ от файловой системы», — замечает исследователь.

Этим поведением можно злоупотребить для произвольной записи файлов, включая XML-данные из SOAP-запроса. Менее разрушительным, но тоже неприятным сценарием могут быть атаки типа NTLM relay.

Изначально Bazydło сообщил об этой проблеме в Microsoft через программу Zero Day Initiative (ZDI). По его словам, в компании ответили, что исправлять баг не будут, потому что разработчики не должны позволять использовать недоверенные входные данные.

«Предсказуемо, Microsoft посчитала это "особенностью", а не уязвимостью, — пишет он. — В ответе обвинили разработчиков и пользователей. По версии Microsoft, URL, передаваемый в SoapHttpClientProtocol, никогда не должен контролироваться пользователем, а проверка входных данных — целиком ответственность разработчика».

Bazydło язвительно добавляет, что, конечно же, «все разработчики регулярно декомпилируют сборки .NET Framework и изучают внутреннюю реализацию, прекрасно зная, что "HTTP-клиентский прокси" можно убедить писать данные на диск. Ну а как иначе?».

Спустя год команда watchTowr взялась за анализ Barracuda Service Center — «широко используемой RMM-платформы», которая, как выяснилось, тоже уязвима для описанной техники. Исследователи обнаружили, что её SOAP-API можно было вызывать без аутентификации, а затем нашли альтернативный путь эксплуатации — через импорт WSDL-файлов (Web Services Description Language).

Суть в том, что атакующий может подсунуть приложению URL, указывающий на WSDL-файл под его контролем. Уязвимое приложение на основе этого описания генерирует HTTP-клиентский прокси, после чего Bazydło удалось добиться удалённого выполнения кода двумя способами: загрузкой ASPX-web-shell на сервер и размещением полезной нагрузки (CSHTML-web-shell или PowerShell-скрипта) в пространстве имён (namespace) тела SOAP-запроса.

Эта техника с namespace, по его словам, позволила успешно проэксплуатировать Ivanti Endpoint Manager и CMS Umbraco 8. В отчёте watchTowr эти продукты названы прямо, но исследователи подчёркивают, что реальный перечень затронутых решений намного шире.

«Учитывая масштабы использования .NET и то, что в сутках всего 24 часа, наш список пострадавших продуктов стоит считать скорее иллюстрацией. Практически наверняка уязвимы и многие другие коммерческие и внутренние решения», — констатирует Bazydło.

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

Похожую реакцию исследователи получили и на последующие отчёты — уже по поводу продуктов самой Microsoft, в которых проявлялась та же проблема. В официальном комментарии компания заявила, что, хотя речь идёт о поведении приложения, «пользователям следует избегать потребления недоверенных данных, которые могут привести к генерации и выполнению кода».

Bazydło не скрывает иронии: «Сначала мы обвиняем приложение. Если так нельзя — потому что это потребует исправлять код самой Microsoft, — обвиняем пользователя. Пещерный пользователь должен был вручную проверить WSDL-файл и догадаться, что тот может писать SOAP-запросы в файлы вместо того, чтобы отправлять их по HTTP. Эх».