Уязвимость в Apache Tomcat, позволяющая подставить JSP-код и получить файлы web-приложений

Исследователи из китайской компании Chaitin Tech выявили уязвимость (CVE-2020-1938) в Apache Tomcat, открытой реализации технологий Java Servlet, JavaServer Pages, Java Expression Language и Java WebSocket. Уязвимости присвоено кодовое имя Ghostcat и критический уровень опасности (9.8 CVSS). Проблема позволяет в конфигурации по умолчанию через отправку запроса по сетевому порту 8009 прочитать содержимое любых файлов из каталога web-приложения, в том числе файлов с настройками и исходных текстов приложения.

Уязвимость также даёт возможность импортировать другие файлы в код приложения, что позволяет организовать выполнение кода на сервере, если приложение допускает загрузку файлов на сервер (например, атакующий может загрузить JSP-скрипт под видом картинки через форму загрузки изображения). Атака может быть совершена при возможности отправки запроса на сетевой порт с обработчиком AJP. По предварительным данным, в сети найдено более 1.2 млн хостов, принимающих запросы по протоколу AJP.

Уязвимость присутствует в протоколе AJP, а не вызвана ошибкой в реализации. Помимо приёма соединений по HTTP (порт 8080) в Apache Tomcat по умолчанию допускается обращение к web-приложению через протокол AJP (Apache Jserv Protocol, порт 8009), который представляет собой оптимизированный для достижения более высокой производительности бинарный аналог HTTP, применяемый обычно при создании кластера из Tomcat-серверов или для ускорения взаимодействия с Tomcat на обратном прокси или балансировщике нагрузки.

AJP предоставляет штатную функцию для доступа к файлам на сервере, которую можно использовать в том числе получения файлов, не подлежащих разглашению. Подразумевается, что доступ к AJP открыт только для доверенных серверов, но на деле в конфигурации по умолчанию Tomcat осуществлялся запуск обработчика на всех сетевых интерфейсах, а запросы принимались без аутентификации. Доступ возможен к любым файлам web-приложения, включая содержимое WEB-INF, META-INF и любых других каталогов, отдаваемых через вызов ServletContext.getResourceAsStream(). AJP также позволяет использовать любой файл в доступных для web-приложения каталогах как скрипт JSP.

Проблема проявляется начиная с выпущенной 13 лет назад ветки Tomcat 6.x. Кроме непосредственно Tomcat проблема затрагивает и использующие его продукты, такие как Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), а также самодостаточные web-приложения, использующие Spring Boot. Аналогичная уязвимость (CVE-2020-1745) присутствует в web-сервере Undertow, применяемом в сервере приложений Wildfly. В JBoss и Wildfly протокол AJP по умолчанию включён только в standalone-full-ha.xml, standalone-ha.xml и ha/full-ha профилях в domain.xml. В Spring Boot поддержка AJP отключена по умолчанию. В настоящее время разными группами подготовлено более десятка рабочих примеров эксплоитов (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Уязвимость устранена в выпусках Tomcat 9.0.31, 8.5.51 и 7.0.100 (сопровождение ветки 6.x прекращено). Проследить за появлением обновления в дистрибутивах можно на данных страницах: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. В качестве обходной меры защиты можно отключить сервис Tomcat AJP Connector (привязать слушающий сокет с localhost или закомментировать строку с Connector port = «8009»), если в нём нет необходимости, или настроить аутентифицированный доступ при помощи атрибутов «secret» и «address», если сервис используется для взаимодействия с другими серверами и прокси на базе mod_jk и mod_proxy_ajp (mod_cluster аутентификацию не поддерживает).

Источник: opennet.ru