Odkryli to naukowcy z chińskiej firmy Chaitin Tech () W , otwarta implementacja technologii Java Servlet, JavaServer Pages, Java Expression Language i Java WebSocket. Luce nadano kryptonim Ghostcat i krytyczny poziom ważności (9.8 CVSS). Problem pozwala w domyślnej konfiguracji poprzez wysłanie żądania na port sieciowy 8009 na odczytanie zawartości dowolnych plików z katalogu aplikacji internetowej, w tym plików z ustawieniami i kodami źródłowymi aplikacji.
Luka umożliwia także zaimportowanie do kodu aplikacji innych plików, co pozwala na wykonanie kodu na serwerze, jeśli aplikacja umożliwia przesłanie plików na serwer (przykładowo osoba atakująca może załadować skrypt JSP przebrany za obraz poprzez formularz przesyłania zdjęć). Atak można przeprowadzić, gdy istnieje możliwość wysłania żądania do portu sieciowego za pomocą modułu obsługi AJP. Według wstępnych danych w Internecie ponad 1.2 miliona hostów akceptujących żądania za pośrednictwem protokołu AJP.
Luka występuje w protokole AJP i błąd w wykonaniu. Oprócz akceptowania połączeń poprzez HTTP (port 8080), Apache Tomcat domyślnie umożliwia dostęp do aplikacji internetowej poprzez protokół AJP (, port 8009), który jest binarnym odpowiednikiem protokołu HTTP zoptymalizowanym pod kątem wyższej wydajności, zwykle używanym podczas tworzenia klastra serwerów Tomcat lub w celu przyspieszenia interakcji z Tomcat na odwrotnym proxy lub module równoważenia obciążenia.
AJP udostępnia standardową funkcję dostępu do plików znajdujących się na serwerze, z której można skorzystać, w tym pozyskać pliki niepodlegające ujawnieniu. AJP powinien być dostępny tylko dla zaufanych serwerów, ale w rzeczywistości domyślna konfiguracja Tomcata uruchamiała moduł obsługi na wszystkich interfejsach sieciowych i akceptowała żądania bez uwierzytelniania. Dostęp jest możliwy do dowolnych plików aplikacji internetowych, w tym zawartości WEB-INF, META-INF i innych katalogów udostępnianych poprzez wywołanie ServletContext.getResourceAsStream(). AJP umożliwia także użycie dowolnego pliku w katalogach dostępnych dla aplikacji internetowej jako skryptu JSP.
Problem pojawia się od wydania gałęzi Tomcat 13.x 6 lat temu. Oprócz samego problemu Tomcat i produkty, które z niego korzystają, takie jak Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), a także samodzielne aplikacje internetowe korzystające . Podobna luka (CVE-2020-1745) w serwerze WWW , używany na serwerze aplikacji Wildfly. W JBoss i Wildfly AJP jest domyślnie włączone tylko w profilach standalone-full-ha.xml, standalone-ha.xml i ha/full-ha w domain.xml. W Spring Boot obsługa AJP jest domyślnie wyłączona. Obecnie różne grupy przygotowały kilkanaście działających przykładów exploitów (
,
,
,
,
,
,
,
,
,
,
).
Luka naprawiona w wersjach Tomcat , и (utrzymanie gałęzi 6.x ). Dostępność aktualizacji w pakietach dystrybucyjnych możesz śledzić na tych stronach: , , , , , . W ramach obejścia możesz wyłączyć usługę Tomcat AJP Connector (powiązać gniazdo nasłuchujące z localhost lub zakomentować linię za pomocą Connector port = „8009”), jeśli nie jest ona potrzebna, lub dostęp uwierzytelniany przy użyciu atrybutów „secret” i „address”, jeśli usługa jest wykorzystywana do interakcji z innymi serwerami i proxy w oparciu o mod_jk i mod_proxy_ajp (mod_cluster nie obsługuje uwierzytelniania).
Źródło: opennet.ru