Гостевая статья Ghostcat: анализ уязвимости Apache Tomcat (CVE-2020-1938 и CNVD-2020-10487)

Обсуждения, касающиеся уязвимости Ghostcat ( и ), обнаруженные в Apache Tomcat, поскольку исследователи ее влияние на безопасность, особенно ее потенциальное использование для удаленного выполнения кода (RCE).

- это популярный контейнер Java-сервлетов с открытым исходным кодом, поэтому обнаружение Ghostcat по понятным причинам вызвало некоторые тревоги. Эта запись в блоге направлена на то, чтобы представить наиболее вероятный сценарий, связанный с Ghostcat, углубившись в маловероятные обстоятельства, которые позволили бы RCE преодолеть уязвимость.

Протокол AJP
Ghostcat был обнаружен 20 февраля исследователями безопасности Chaitin Tech, которые что уязвимость существует в протоколе Apache JServ (AJP). представляет собой бинарный протокол , используемый веб-сервером Apache Tomcat для связи с контейнером сервлетов , который сидит за веб-сервером с использованием соединений TCP. Он в основном используется в сценарии с кластером или обратным прокси, когда веб-серверы взаимодействуют с серверами приложений или сервлет-контейнерами.

Проще говоря, это означает, что HTTP-коннектор доступен для клиентов, а AJP используется внутри между веб-сервером (например, Apache HTTPD) и сервером Apache Tomcat (показано на рисунке 1). AJP реализован как модуль в HTTP-сервере Apache, представленный как mod_jk или mod_proxy_ajp. Суть в том, что AJP по своей природе не подвержен внешнему воздействию. Это важно отметить, так как это одна из предпосылок для сценария RCE, который мы обсудим в следующем разделе.

figure-1-ajp-illustration-640x782.jpg

Рисунок 1. Иллюстрация протокола Apache JServ

Уязвимость Ghostcat
Ghostcat сам по себе является уязвимостью Local File Include / Read, а не произвольной загрузкой / записью файлов. На Ghostcat описывается как «Внедрение запроса AJP и потенциальное удаленное выполнение кода». Ключевое слово «потенциальное» подчеркивает, что Ghostcat по умолчанию не является уязвимостью RCE.

Далее в консультативном документе подробно описываются обстоятельства, необходимые для выполнения RCE: веб-приложение должно разрешать загрузку файлов и хранение этих загруженных файлов в самом веб-приложении, иначе злоумышленник должен каким-то образом получить контроль над содержимым веб-приложения. , Этот сценарий в сочетании со способностью обрабатывать файл как JSP (что стало возможным благодаря уязвимости), сделает возможным RCE .

Таким образом, Ghostcat может вызвать проблемы у организаций, если у них есть Tomcat AJP Connector, который внешне не доступен, что, в первую очередь, не рекомендуется. Тем не менее, кроме незащищенного AJP, для выполнения RCE потребуется несколько других предпосылок. Это требования, которые в совокупности трудно найти в реальном сценарии.

, известный исследователь безопасности из Бразилии, определил предпосылки, необходимые для того, чтобы Ghostcat стал RCE.

figure-2-post-identifying-the-prerequisites-640x348.jpg

Рисунок 2. Предварительные условия для проведения RCE

Мы рассмотрели их далее, как описано ниже:

Загрузка файлов через функцию приложения . Это первое предварительное условие означает, что приложение с функцией загрузки файлов должно быть уже установлено в системе для того, чтобы RCE была возможной. Если это так, потенциальному злоумышленнику было бы удобнее использовать само веб-приложение с уязвимостью загрузки файлов для загрузки файла вредоносной веб-оболочки. Необходимость интерпретировать файл как JSP возникнет только в тех случаях, когда уязвимость загрузки ограничивает определенные расширения файлов, такие как JPG или TXT.

Эти файлы сохраняются в корне. После того, как злоумышленник скомпрометирует приложение и сможет загрузить вредоносный файл, эти файлы необходимо будет сохранить в корневой папке приложения. Само по себе это предварительное условие маловероятно или сложно по двум причинам: 1) в приложениях Java редко можно сохранять файлы в корневой папке приложения; и 2) корневая папка приложения является временной, поэтому эта папка полностью перезаписывается при развертывании новой версии приложения.

Кроме того, с точки зрения разработчика, для функции загрузки файлов не имеет смысла загружать файлы в корневую папку, поскольку большинство приложений Apache Tomcat развертываются в виде файла .WAR, который в основном представляет собой zip-файл.

Получите прямой доступ к порту AJP . Наконец, после того, как эти два предварительных условия выполнены, потенциальный злоумышленник должен иметь возможность подключиться к Tomcat AJP Connector (порт по умолчанию 8009) напрямую из Интернета через обратный прокси-сервер, который является внешним AJP. Как уже упоминалось, это не рекомендуемая или распространенная конфигурация. Даже если AJP-коннектор открыт и злоумышленник попытается установить с ним связь, он получит ответ 400 Bad Request от веб-сервера, поскольку AJP является двоичным протоколом.

Насколько серьезна Ghostcat?
Что добавляет к известности Ghostcat, так это тот факт, что он существует уже более тринадцати лет и затрагивает все основные версии Apache Tomcat. В этой записи блога мы пытаемся помочь справиться с тревогой, вызванной обнаружением уязвимости. Учитывая все требования, описанные выше, маловероятно, что эти требования произойдут в реальном сценарии, который превратит Ghostcat в уязвимость RCE. Злоумышленник должен будет выполнить эти требования, поскольку вряд ли есть законная причина для их существования в реальных условиях.

Большинство PoC, демонстрирующих эту проблему, уже имели файл webshell.txt внутри webapps / ROOT Apache Tomcat, что позволило включить RCE до использования Ghostcat. В реальном сценарии злоумышленник, уже находящийся в сети, может использовать эту уязвимость для выполнения бокового перемещения, поскольку он сможет напрямую связаться с соединителем AJP. Однако для того, чтобы они достигли этой стадии своей атаки, им все равно потребуется загрузить вредоносный файл, такой как веб-оболочка, в папку webapps /, чтобы использовать уязвимость Ghostcat LFI, а затем принудительно интерпретировать файл как JSP независимо от расширение.

Исправление для Ghostcat
Исправления, внесенные командой Apache Tomcat для исправления Ghostcat, также должны прояснить его истинные ограничения. В этом разделе мы детализируем исправления в коде из версии 9.0.31, который в основном использует тот же код в других версиях.

Ghostcat использует неверную конфигурацию (как показано ниже) коннектора AJP, где он включен по умолчанию в файле /conf/server.xml:

<Connector port = ”8009 ″ protocol =” AJP / 1.3 ″ redirectPort = ”8443 ″ />

Команда Apache Tomcat закомментировала эту строку из файла, тем самым отключив соединитель AJP по умолчанию для коммита 4c933d8 , как показано на рисунке 3.

figure-3-image-showing-commit-4c933d8-1024x331.jpg

Рисунок 3. Изображение, показывающее Commit 4c933d8 , который по умолчанию отключает соединитель AJP

Само по себе исправление кода выше достаточно, чтобы остановить Ghostcat, поскольку по умолчанию он отключает AJP. Это должно быть сделано, только если AJP не используется.

Мы подробно опишем второе исправление, которое не обязательно отключает AJP, но ограничивает его только прослушиванием интерфейса обратной связи по умолчанию (рисунок 4). Команда Apache Tomcat внесла другие изменения, чтобы улучшить общее использование протокола AJP, например, установив secret, который будет определен, когда для атрибута secretRequired установлено значение true (рисунок 5). Они также удостоверились, что любые запросы к соединителю AJP, который содержит произвольные и нераспознанные атрибуты, получают ответ 403 (Запрещено) (рисунок 6).

figure-4-Figure-4.-image-showing-commit-0e8a50f0-1024x499.jpg

Рисунок 4. Изображение, показывающее Commit 0e8a50f0 , которое заставляет протокол AJP прослушивать адрес обратной связи по умолчанию вместо 0.0.0.0.

figure-5-image-showing-commit-9ac90532-1024x970.jpg

Рисунок 5. Изображение, показывающее Commit 9ac90532 , который проверяет, установлено ли для параметра secretRequired значение «true» и существует ли определенный «секрет»


figure-6-image-showing-commit-64fa5b99-1024x836.jpg

Рисунок 6. Изображение, показывающее Commit 64fa5b99 , которое блокирует запросы к соединителю AJP с ответом 403 сообщение, если оно содержит произвольные и нераспознанные атрибуты

Вывод
Учитывая все, что обсуждалось в этом посте, пользователям по-прежнему важно осознавать, что Ghostcat по-прежнему представляет риски, даже если по умолчанию это не RCE. Тот факт, что уже существует много общедоступных эксплойтов для этой уязвимости, должен подтолкнуть пользователей к обновлению своего Tomcat до последней версии как можно скорее, чтобы снизить риск использования.

Apache Tomcat выпустил исправления для следующих версий Tomcat:

  • (версия 7.0.1000)
  • (версия 5.51)
  • (версия 0.31)
Если обновление не является немедленным вариантом, пользователи, которые не используют службу соединителя AJP, должны вместо этого отключить ее, комментируя или полностью удаляя ее из $ CATALINA_HOME / conf / server.xml и перезапуская Tomcat, аналогично действиям, предпринимаемым Apache Tomcat. Команда описана выше.

Помимо обновления Tomcat до последней версии, если используется служба AJP Connector, задайте для атрибута «secret» определенные учетные данные для аутентификации протокола AJP в соответствии с рекомендациями , как указано ниже:

<Протокол соединителя = ”AJP / 1,3 ″

адрес =»:: 1"

порт =»8009"

redirectPort =»8443"

secretRequired =»истина»

секрет = ”YOUR_SECRET_HERE” />

также упоминает, что эта уязвимость может также затронуть приложения, использующие среду Spring Boot, поскольку они по умолчанию используют встроенную версию Tomcat. Пользователи этих приложений также должны изучить этот вопрос, чтобы убедиться, что Ghostcat не влияет на них.

Источник:
 
  • Нравится
Реакции: gtrynox
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!