В июле 2025 года мир информационной безопасности был потрясён сообщениями о новом эксплойт-цепочке под названием ToolShell, нацеленном на уязвимости в Microsoft SharePoint. Эта цепочка критических уязвимостей позволяла удалённое выполнение кода (RCE) на уязвимых серверах с минимальными предварительными условиями, вплоть до отсутствия аутентификации. SharePoint на протяжении многих лет является важным компонентом корпоративных сред, и данный инцидент стал серьёзным вызовом для системных администраторов и специалистов по безопасности, требуя глубокого понимания внутренней архитектуры и механизмов работы платформы. Эксплойт цепочки ToolShell объединил две ключевые уязвимости: CVE-2025-49706 — обход аутентификации на странице ToolPane, и CVE-2025-49704 — небезопасная десериализация с участием DataSetSurrogateSelector. Анализ этих проблем выявляет насколько непростыми бывают внутренние механизмы SharePoint и с какими сложностями сталкиваются исследователи при нахождении и реализации уязвимостей.
Страницы SharePoint, особенно расположенные в каталоге _layouts, часто использовались злоумышленниками благодаря открытым API и богатыми возможностями кастомизации. ToolPane.aspx, центральная цель эксплойта, содержит компонент Microsoft.SharePoint.WebPartPages.
ToolPane, отвечающий за обработку визуальных элементов страниц и редактируемых частей. Основное препятствие для атаки заключалось в проверках аутентичности пользователя, осуществляемых модулем SPRequestModule и жизненным циклом страниц ASP.NET. Однако механизм обхода связан с особенностями обработки HTTP-заголовка Referer, а именно с использованием путей выхода из учётной записи (SignOut.aspx).
Если запрос содержит реферер, указывающий на signout path, валидация аутентификации пропускается. Это неочевидное поведение позволяет обходить блокировки, выдавая доступ к функционалу страницы ToolPane без стандартного подтверждения подлинности. При этом метод GetPartPreviewAndPropertiesFromMarkup, служащий для извлечения превью веб-чертежа и свойств, становится достижимым на этапе события InitComplete, происходящего до загрузки страницы (Load). Это критично, поскольку до этой стадии проверка формального запроса с кодом достоверности формы (form digest), требующая аутентификации, ещё не происходит. Комплексные проверки позволили выявить возможность работы в режиме редактирования DisplayMode=Edit, одновременно удовлетворяя условию InCustomToolPane.
Путь запроса для успешного обхода должен содержать параметры, например: /_layouts/15/ToolPane.aspx?DisplayMode=Edit&foo=/ToolPane.aspx. Ксенофобия к проверке безопасности усиливается тем, что функция для получения файла веб-части (GetFile) ожидает путь, начинающийся с _controltemplates/ и заканчивающийся на .ascx, обращаясь к файловой системе, а не сетевым ресурсам, что позволяет избежать дополнительных проверок разрешений.
Далее эксплойтеры используют параметр MSOTlPn_DWP для передачи произвольного разметочного кода (markup), создающего веб-части, обходя классические фильтры безопасности SafeControlCheck. Хотя контроль безопасных компонентов (SafeControls) существует, его реализация не учитывала сложные сценарии с шаблонными парсерами, позволяя вводить элементы, вызывающие десериализацию опасных объектов. Следующая важная часть цепочки — недостатки в DataSetSurrogateSelector. SharePoint применяет этот селектор для безопасного преобразования сериализованных объектов DataSet и DataTable, фильтруя входные типы и валидируя XML с помощью XmlValidator. Запрещено использование потенциально опасных типов, а разрешены только ограниченный список известных безопасных.
Но тонкости в разборе имени типа (ParseAssemblyQualifiedName) сделали возможным обход. Если тип обёрнут в обобщённый контейнер List, с отсутствующим в ожидаемой позиции разделителем запятой, валидатор интерпретирует тип как object, входящий в белый список. Это создает брешь, позволяющую паковать произвольные типы и добиваться десериализации практически любых объектов, что особенно опасно при наличии gadget-объектов, способных запускать произвольный код. Один из таких гаждетов — ObjectDataProvider, который вместе с LosFormatter позволяет запускать опасные операции десериализации. Используется схема XML, содержащая XmlSchema и XmlDiffGram с тщательно подобранными элементами для обхода проверок и вызова методов десериализации.
Далее цепочка связывается через управляемые веб-части Microsoft.PerformancePoint.Scorecards.ExcelDataSet, которые содержат механизм декомпрессии и десериализации ранее сформированных данных из свойства CompressedDataTable. При обращении к свойству DataTable происходит обход защиты и десериализация, инициирующая выполнение кода.
Веб-часть внедряется посредством секции ProgressTemplate в UpdateProgress, которая позволяет вставлять произвольные шаблоны и элементы управления в тело страницы. Строгие проверки безопасности не срабатывают, поскольку UpdateProgress разрешён в SafeControls и позволяет работать с произвольным шаблоном загрузки контента, который обрабатывается через TemplateParser. Итогом становится возможность удалённого выполнения кода без какой-либо аутентификации, что представляет собой серьёзную угрозу корпоративным средам, работающим на SharePoint 2013 и 2019 до июня 2025 года с определёнными сборками. Несмотря на то, что в июле 2025 года Microsoft выпустила обновления, существенно затрудняющие эксплуатацию этой цепочки уязвимостей, анализ ToolShell подчёркивает, каким сложным и многоступенчатым может быть поиск обходов в корпоративных продуктах. Рекомендуется своевременно использовать обновления безопасности и внимательно отслеживать атипичное поведение SharePoint, особенно на публично доступных порталах.
Главный урок из истории ToolShell — необходимость тщательного код-ревью, понимания жизненного цикла приложений и глубокого анализа внутренних механизмов сериализации и аутентификации платформ. Исследовательский опыт показал, что даже компоненты, отвечающие за безопасность, могут содержать тривиально выглядящие ошибки, приводящие к критическим последствиям. Для администраторов важно помнить о необходимости использования советов Microsoft по ротации ключей и настройке политик доступа, чтобы минимизировать воздействие возможных уязвимостей. Подобные атаки демонстрируют, что огромный пласт кода в корпоративных решениях требует постоянного внимания исследователей по вопросам безопасности. Именно совместная работа исследовательского сообщества и вендоров обеспечивает повышение устойчивости современных систем к сложным и целенаправленным атакам.
Инцидент с ToolShell — это напоминание о том, что кибербезопасность — это бесконечный процесс, где нет места расслаблению, и каждый элемент архитектуры должен быть проверен на надёжность и защищённость.
