Исследователи из Chaitin Tech, Китай, опубликовали информация о новом открытии, как они определили уязвимость в популярном контейнере сервлетов (Java Servlet, JavaServer Pages, Java Expression Language и Java WebSocket) Апачский томкаt (уже указан как CVE-2020-1938).
Эта уязвимость им было присвоено кодовое имя "Ghostcat" и критический уровень серьезности (9.8 CVSS). Проблема позволяет в конфигурации по умолчанию отправить запрос через сетевой порт 8009 читать содержимое любого файла в каталоге веб-приложения, включая исходные коды приложений и файлы конфигурации.
Уязвимость также позволяет импортировать в код приложения другие файлы., что позволяет организовать выполнение кода на сервере, если приложение позволяет загружать файлы на сервер.
Например, позволяет ли приложение веб-сайта пользователям загружать файлы, злоумышленник может зарядить первый файл, содержащий код сценария JSP вредоносный на сервере (сам загруженный файл может быть любым типом файла, например изображениями, текстовыми файлами и т. д.) а затем включите загруженный файл, используя уязвимость от Ghostcat, что в конечном итоге может привести к удаленному выполнению кода.
Также упоминается, что атака может быть выполнена, если есть возможность отправить запрос на сетевой порт с помощью драйвера AJP. По предварительным данным, сеть найдена более 1.2 миллиона хостов принимают запросы по протоколу AJP.
Уязвимость присутствует в протоколе AJP. и это не вызвано ошибкой реализации.
Помимо приема HTTP-соединений (порт 8080) в Apache Tomcat, по умолчанию можно получить доступ в веб-приложение с использованием протокола AJP (Протокол Apache Jserv, порт 8009), который является бинарным аналогом HTTP, оптимизированным для повышения производительности, обычно используется при создании кластера из серверов Tomcat или для ускорения взаимодействия с Tomcat на обратном прокси-сервере или балансировщике нагрузки.
AJP предоставляет стандартную функцию для доступа к файлам на сервере, которые можно использовать, в том числе для получения файлов, не подлежащих разглашению.
Подразумевается, что доступ к AJP открыт только для доверенных служащихно на самом деле в конфигурации Tomcat по умолчанию драйвер запускался на всех сетевых интерфейсах, и запросы принимались без аутентификации.
Доступ возможен к любому файлу в веб-приложении, включая содержимое WEB-INF, META-INF и любой другой каталог, возвращаемый посредством вызова ServletContext.getResourceAsStream (). AJP также позволяет использовать любой файл в каталогах, доступных для веб-приложения, в качестве сценария JSP.
Проблема стала очевидной с тех пор, как ветка Tomcat 6.x была выпущена 13 лет назад.. Помимо самого Tomcat, проблема также влияет на продукты, которые ее используют, такие как Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), а также автономные веб-приложения, использующие Spring Boot.
также обнаружена аналогичная уязвимость (CVE-2020-1745) на веб-сервере Undertow используется в сервере приложений Wildfly. В настоящее время различными группами подготовлено более десятка рабочих примеров эксплойтов.
Apache Tomcat официально выпустил версии 9.0.31, 8.5.51 и 7.0.100. чтобы исправить эту уязвимость. Чтобы правильно исправить эту уязвимость, вы должны сначала определить, используется ли служба Tomcat AJP Connector в вашей серверной среде:
- Если кластер или обратный прокси-сервер не используется, можно в принципе определить, что AJP не используется.
- Если нет, вам нужно выяснить, взаимодействует ли кластер или обратный сервер со службой Tomcat AJP Connect.
Также упоминается, что обновления теперь доступны в различных дистрибутивах Linux например: Debian, Ubuntu, RHEL, Fedora, SUSE.
В качестве обходного пути можно отключить службу Tomcat AJP Connector (привязать прослушивающий сокет к localhost или закомментировать строку с помощью Connector port = »8009 ″), если это не требуется, или настроить доступ с проверкой подлинности.
Если вы хотите узнать об этом больше, вы можете проконсультироваться по следующей ссылке.