Badacze z chińskiej firmy Chaitin Tech odkryli () w , otwartej implementacji technologii Java Servlet, JavaServer Pages, Java Expression Language i Java WebSocket. Luka przyjęła nazwę kodową Ghostcat i została oceniona na krytyczny poziom zagrożenia (9.8 CVSS). Problem pozwala w konfiguracji domyślnej na odczytanie zawartości wszelkich plików z katalogu aplikacji webowej poprzez wysłanie żądania na porcie sieciowym 8009, w tym plików konfiguracyjnych i źródłowych aplikacji.
Luka ta również umożliwia importowanie innych plików do kodu aplikacji, co pozwala na wykonanie kodu na serwerze, jeśli aplikacja zezwala na wgrywanie plików na serwer (na przykład atakujący może wgrzać skrypt JSP udający obrazek za pośrednictwem formularza przesyłania obrazu). Atak może zostać przeprowadzony, jeśli istnieje możliwość wysyłania żądań na port sieciowy z obsługą AJP. Według wstępnych danych, w sieci ponad 1,2 miliona hostów akceptujących żądania przez protokół AJP.
Luka występuje w protokole AJP, a błędem w implementacji. Oprócz przyjmowania połączeń przez HTTP (port 8080), Apache Tomcat w domyślnej konfiguracji zezwala na dostęp do aplikacji webowej poprzez protokół AJP (, port 8009), który jest zoptymalizowaną wersją binarną HTTP, stosowaną zazwyczaj w klastrach serwerów Tomcat lub do przyspieszania interakcji z Tomcatem na odwrotnym proxy lub w równoważniku obciążenia.
AJP zapewnia wbudowaną funkcję dostępu do plików na serwerze, którą można wykorzystać, w tym do uzyskiwania plików, które nie powinny być ujawnione. Zakłada się, że dostęp do AJP jest otwarty tylko dla zaufanych serwerów, jednak w rzeczywistości w domyślnej konfiguracji Tomcat uruchamiał obsługę na wszystkich interfejsach sieciowych, a żądania były przyjmowane bez uwierzytelnienia. Dostęp możliwy jest do wszelkich plików aplikacji webowej, w tym do zawartości WEB-INF, META-INF oraz wszelkich innych katalogów, udostępnianych za pomocą wywołania ServletContext.getResourceAsStream(). AJP umożliwia również wykorzystywanie dowolnego pliku w dostępnych dla aplikacji webowej katalogach jako skryptu JSP.
Problem występuje od wydania 13 lat temu wersji Tomcat 6.x. Oprócz samego Tomcata, problem i produkty, które go wykorzystują, takie jak Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), a także samodzielne aplikacje internetowe wykorzystujące . Podobna podatność (CVE-2020-1745) w serwerze WWW , stosowanym w serwerze aplikacji Wildfly. W JBoss i Wildfly protokół AJP jest domyślnie włączony tylko w plikach standalone-full-ha.xml, standalone-ha.xml i ha/full-ha w domain.xml. W Spring Boot wsparcie dla AJP jest domyślnie wyłączone. Obecnie różne grupy przygotowały ponad dziesięć działających przykładów exploitów (
,
,
,
,
,
,
,
,
,
,
).
Podatność została naprawiona w wydaniach Tomcat , i (wsparcie dla gałęzi 6.x ). Aby śledzić wprowadzenie aktualizacji w dystrybucjach, można odwiedzić te strony: , , , , , . Jako środek ochrony można wyłączyć serwis Tomcat AJP Connector (powiązać gniazdo nasłuchujące z localhost lub zakomentować linię z Connector port = «8009»), jeśli nie jest on potrzebny, lub uzyskać dostęp uwierzytelniony za pomocą atrybutów «secret» i «address», jeśli serwis jest używany do interakcji z innymi serwerami i proxy na bazie mod_jk i mod_proxy_ajp (mod_cluster nie wspiera uwierzytelnienia).
Źródło: opennet.ru
