Данная публикация - перевод статьи Jang - No[one|thing] will be left behind — Manual guide to patch your the exiled SharePoint/Exchange server.

В последние дни сообщество кибербезопасности активно обсуждает инцидент с уязвимостью в SharePoint сервере, которая была проэксплуатирована в реальной среде. Уровень воздействия этой уязвимости почти равен ProxyLogon из прошлого.

Существует множество причин, объясняющих эту ситуацию, самая распространённая — задержка системных администраторов с установкой обновлений безопасности для серверов, что вполне можно понять. Обновление патчей на продуктивных системах сильно отличается от обновления в тестовой среде: нельзя просто сразу применить патч, администратору нужно тщательно оценить уровень воздействия, возможные риски и дождаться одобрения перед внедрением.

Также следует принять тот факт, что уязвимость была использована злоумышленниками ещё до того, как Microsoft выпустила патч.

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

И с недавним патчем для ToolShell ситуация такая же, его payload для обхода был обнаружен в эксплуатации в реальных условиях сразу после публикации proof of concept (PoC):

MS исправила это с помощью патча для CVE-2025–53771, гарантируя, что только некоторые рефереры из белого списка смогут пропускать аутентификацию:

Использование устаревших версий продуктов

В 2021 году, когда появилась уязвимость ProxyLogon, мне было поручено проанализировать и изучить способ создания эксплойта для этой уязвимости. После того, как был успешно продемонстрирован PoC, работающий на production-системе организации, появилось достаточное обоснование, чтобы обязать системного администратора применить патч на системе и обновить ее.

Однако проблема началась тогда, когда версия сервера была слишком старая — примерно на уровне CU3, в то время как на практике уже использовались версии CU16–17.

Microsoft выпустила security patch только для версий CU16–17 и выше, поэтому чтобы применить патч безопасности, необходимо было обновить серверы до CU16–17. Во время тестирования обновления CU один из серверов перестал подавать признаки жизни после обновления, но, к счастью, удалось откатить изменения и вернуть его в рабочее состояние.

После этого мне пришлось изучать и анализировать патч, а затем применять исправления напрямую на production-сервере. К счастью, всё работало отлично до тех пор, пока они не перестали использовать Exchange.

Патчинг

Возвращаясь к ToolShell, Microsoft предоставляет патчи только для версий SharePoint SE, 2019 и самой старой — 2016. Однако на практике очень много серверов в production работают на версии 2013.

Версия SharePoint 2013 уже давно не поддерживается, механизмы защиты устарели, поэтому в сочетании с уязвимостью ToolShell это может превратиться в серьёзные цепочки эксплойтов, например, легко создать Memory WebShell при использовании вместе с CVE-2024–38018 без необходимости отключать Type Check, как это требуется в более новых версиях. В этой статье я буду показывать, как патчить несколько уязвимостей, которые непосредственно влияют на систему, а с остальными уязвимостями читатели смогут поступить аналогично.

Инструмент, который потребуется использовать — dnSpy, я использую версию dnSpyEx, так как старая версия больше не поддерживается.

Патч обхода аутентификации

Первый шаг — в dnSpy открыть Debug > Attach to Process, выбрать процесс w3wp.exe с командной строкой вида «SharePoint — <порт сервера>», в данном случае порт сервера — 80:

Если вы не видите процесса с такой строкой, возможно, процесс ещё не запущен — зайдите на сайт SharePoint, чтобы процесс запустился, затем нажмите Refresh, чтобы обновить список процессов.

После этого откройте Debug > Windows > Modules, в этом окне щёлкните правой кнопкой мыши и выберите Open All Modules:

В этот момент все загруженные модули будут загружены в dnSpy для отладки. Выберите Edit > Search Assemblies, чтобы найти нужный файл для патча.

dnSpy позволяет напрямую изменять методы и классы в бинарных файлах без необходимости иметь исходный код.

Чтобы изменить метод, кликните правой кнопкой мыши по телу нужного метода и выберите Edit Method. В данном случае это SPRequestModule.PostAuthent

Причина уязвимости обхода аутентификации здесь в том, что если запрос содержит заголовок, совпадающий с «_layouts/15/SignOut.aspx», то аутентификация пропускается.

Как было проанализировано в патче, для устранения этой проблемы только определённые URL разрешено пропускать аутентификацию.

internal static readonly HashSet<string> SignoutRefererSystemPredefinedAllowList = new HashSet<string>(StringComparer.OrdinalIgnoreCase)
  {
   "/_layouts/15/SignOut.aspx", "/_layouts/15/1033/initstrings.js", 
"/_layouts/15/init.js", "/_layouts/15/theming.js", "/ScriptResource.axd", 
"/_layouts/15/blank.js", "/ScriptResource.axd", "/WebResource.axd", 
"/_layouts/15/1033/styles/corev15.css", "/_layouts/15/1033/styles/error.css",
   "/_layouts/15/images/favicon.ico", "/_layouts/15/1033/strings.js", 
"/_layouts/15/core.js"
  };

В зависимости от конкретной ситуации, если вы считаете, что эта функция не нужна, вы можете отключить её, удалив следующий участок кода:

Затем нажмите Compile, чтобы dnSpy скомпилировал класс заново, и вы получите следующий результат:

Далее выберите File > Save Module, чтобы сохранить изменённый dll-файл.

Важно: нужно выбрать новое имя файла, так как текущий dll открыт и перезаписать его нельзя!

Затем откройте путь к dll, сделайте резервную копию старого файла и переименуйте только что изменённый файл для использования. В данном случае имя файла — Microsoft.SharePoint.dll.

Повторно протестируйте запрос, и вы получите:

Сравнение с ответом 401 до обхода аутентификации:

*Ответ с обходом аутентификации будет содержать дополнительный заголовок X-SharePointHealthScore.

Патч CVE-2024–38018

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

Согласно анализу команды Viettel, коренная причина этой уязвимости кроется в методе SPSerializationBinder.IsAllowedType(), который позволяет десериализовать все классы из списка SafeControls:

Патч для этой уязвимости ограничил десериализацию, разрешив только определённые типы для deser:

Мы полностью перенесём этот allow list в SharePoint 13:

Далее снова Save Module -> заменить файл

Для уязвимости, связанной с DataSetSurrogateSelector, чтобы полностью исправить проблему, пришлось бы изменить множество файлов.

Вместо этого я предлагаю исправить её, убрав этап десериализации, вызывающий ошибку, в методе ExcelDataSet.get_DataTable:

Далее снова Save Module и замените файл для применения патча.

Выше приведены лишь мои самые базовые рекомендации по ручному патчингу уязвимостей в случае отсутствия официальных патчей.

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

Это лишь временное решение, позволяющее предотвратить текущие атаки. SharePoint 2013 не поддерживается с 2018 года, и вы не сможете вручную патчить все CVE с 2018 по настоящее время. Для оптимальной работы сервера рекомендуется рассмотреть обновление до более новой поддерживаемой версии и как можно скорее применять официальные Security Patch !