Исследователи в области безопасности выявили уязвимость в .NET, которая, как полагают, затрагивает множество корпоративных продуктов, и которую, по их словам, Microsoft отказывается исправлять.
Петр Базидло, ведущий исследователь уязвимостей в watchTowr, представил результаты исследования на конференции Black Hat Europe в среду, заявив, что несколько сторонних и внутренних решений могут быть уязвимы для атак с удаленным выполнением кода (RCE) из-за ошибок в обработке сообщений Simple Object Access Protocol (SOAP) приложениями, построенными на фреймворке .NET от Microsoft.
Исследователь определил класс SoapHttpClientProtocol как основного виновника, объяснив, что его можно использовать различными способами для достижения целей злоумышленника.
Класс наследуется от HttpWebClientProtocol, как и другие типы клиентских прокси, но watchTowr выделил SoapHttpClientProtocol, поскольку он является наиболее распространенным в кодовых базах.
Базидло заявил в блоге, которым поделился с The Register до публикации: «Его название и официальная документация рисуют простую картину: он должен обрабатывать SOAP-сообщения, передаваемые по HTTP. Просто. Предсказуемо. Безопасно. Реальность менее податлива».
Класс отвечает за установку целевого URL SOAP-сервиса и определение SOAP-метода, но уязвимость возникает, когда злоумышленники могут манипулировать этим целевым URL и способом создания клиентов классом SoapHttpClientProtocol.
Несмотря на то, что класс предназначен для обработки HTTP-запросов, SoapHttpClientProtocol использует общий метод создания, поддерживающий несколько протоколов, включая HTTP/HTTPS, FTP и FILE.
Если злоумышленник может установить целевой URL на файловую систему вместо веб-адреса HTTP, класс проигнорирует ошибку и запишет SOAP-запрос (использующий метод POST) непосредственно в файл.
Базидло написал: «Подождите, что. Почему SOAP-прокси должен иметь возможность «отправлять» SOAP-запросы в локальный файл? Никто на этой планете не ожидает получить действительный SOAP-ответ из файловой системы».
Это непреднамеренное поведение может быть использовано злоумышленниками для произвольной записи файлов, включая XML-данные в SOAP-запросе. Или, с меньшим эффектом, для атак типа NTLM relay.
Исследователь сообщил об этой проблеме Microsoft через Zero Day Initiative (ZDI). Microsoft, как сообщается, заявила Базидло, что не будет исправлять ошибку, поскольку разработчики не должны допускать недоверенные входные данные.
«Предсказуемо, Microsoft отнеслась к этому поведению как к функции, а не как к уязвимости», — сказал Базидло. «В ответе обвинили разработчиков и пользователей.
«По словам Microsoft, URL, передаваемый в SoapHttpClientProtocol, никогда не должен контролироваться пользователем, и ответственность за проверку входных данных лежит на разработчике.
«Конечно, все разработчики регулярно декомпилируют сборки .NET Framework и читают внутреннюю реализацию, поэтому они, очевидно, знают, что «HTTP-клиентский прокси» может быть убежден записывать данные в файловую систему. Как кто-либо мог подумать иначе?»
Год спустя команда watchTowr начала расследование Barracuda Service Center, который они описали как «широко развернутую платформу RMM», и один из (теперь исправленных) корпоративных продуктов, уязвимых к эксплойтам .NET.
Вскоре они обнаружили, что к его методу SOAP API можно получить доступ без аутентификации, что привело их к альтернативному пути эксплуатации: через импорт файлов описания веб-сервисов (WSDL).
Злоумышленники могут предоставить уязвимым приложениям URL, указывающий на контролируемый ими WSDL-файл, которые затем генерируют из него HTTP-клиентский прокси.
Базидло сказал, что нашел два способа достижения удаленного выполнения кода с использованием этого метода: через загрузку ASPX-веб-шеллов; или путем внедрения полезных нагрузок (CSHTML-веб-шеллов или PowerShell скриптов) через пространство имен тела SOAP-запроса.
Он отметил, что, вероятно, существуют и другие способы эксплуатации уязвимости, но метод пространства имен был достаточен для эксплуатации Ivanti Endpoint Manager и Umbraco 8 CMS.
Это были продукты, упомянутые в отчете watchTowr как затронутые, но общее число, как полагают, намного выше.
«Учитывая широкое использование .NET и ограниченность часов в сутках, список затронутых продуктов следует считать анекдотичным. Определенно существует множество затронутых сторонних и внутренних решений, но, откровенно говоря, мы считаем, что с приведенным выше списком мы свою точку зрения доказали», — сказал Базидло.
Команда watchTowr сообщила о втором пути эксплуатации Microsoft в июле, но получила аналогичный ответ, как и год назад через ZDI.
Microsoft снова заявила исследователям, что это не ее вина, что пользователи принимают недоверенные входные данные.
Они получили почти идентичный ответ в последующих отчетах Microsoft, сделанных в контексте собственных продуктов Microsoft, некоторые из которых также были затронуты ошибкой.
Хотя проблема связана с поведением приложения, «пользователи должны избегать потребления недоверенных входных данных, которые могут генерировать и выполнять код», — заявили в Microsoft.
Явно довольный ответом, Базидло написал: «Итак, сначала мы виним приложение. Если это невозможно, потому что это потребует исправления собственного кода Microsoft, мы виним пользователя.
«Неандерталец-пользователь должен был вручную проверить WSDL-файл и понять, что он может записывать SOAP-запросы в файлы вместо отправки их по HTTP. Вздох». ®
Автор – Connor Jones
