Wypuszczono naukowców z Chaitin Tech w Chinach informacje o nowym odkryciu, zgodnie z ustaleniami luka w popularnym kontenerze serwletów (Java Servlet, JavaServer Pages, Java Expression Language i Java WebSocket) Apache tomcat (już wymieniony jako CVE-2020-1938).
Ta luka otrzymali pseudonim „Ghostcat” i krytyczny poziom dotkliwości (9.8 CVSS). Problem pozwala w domyślnej konfiguracji na wysłanie zapytania przez port sieciowy 8009 aby odczytać zawartość dowolnego pliku w katalogu aplikacji internetowej, w tym kody źródłowe aplikacji i pliki konfiguracyjne.
Luka umożliwia również importowanie innych plików do kodu aplikacji, co pozwala organizować wykonanie kodu na serwerze, jeśli aplikacja umożliwia przesyłanie plików na serwer.
Na przykład, czy aplikacja internetowa umożliwia użytkownikom przesyłanie plików, atakujący może szarżować pierwszy plik zawierający kod skryptu JSP złośliwy na serwerze (sam przesłany plik może być dowolnym typem pliku, na przykład obrazami, zwykłymi plikami tekstowymi itp.) a następnie dołącz przesłany plik, wykorzystując lukę w zabezpieczeniach z Ghostcat, co ostatecznie może skutkować zdalnym wykonaniem kodu.
Wspomina się również, że atak można przeprowadzić, jeśli możliwe jest wysłanie żądania do portu sieciowego za pomocą sterownika AJP. Według wstępnych danych, znaleziono sieć ponad 1.2 miliona hostów akceptujących żądania przy użyciu protokołu AJP.
Luka występuje w protokole AJP i nie jest to spowodowane błędem implementacji.
Oprócz akceptowania połączeń HTTP (port 8080) w Apache Tomcat, domyślnie jest możliwy dostęp do aplikacji internetowej przy użyciu protokołu AJP (Apache Jserv Protocol, port 8009), który jest binarnym odpowiednikiem HTTP zoptymalizowanym pod kątem wyższej wydajności, zwykle używanym podczas tworzenia klastra z serwerów Tomcat lub w celu przyspieszenia interakcji z Tomcat na odwrotnym serwerze proxy lub module równoważenia obciążenia.
AJP zapewnia standardową funkcję dostępu do plików na serwerze, z których można skorzystać, w tym odbieranie plików nie podlegających ujawnieniu.
Rozumie się, że dostęp do AJP jest otwarte tylko dla zaufanych sługale w rzeczywistości w domyślnej konfiguracji Tomcata sterownik był uruchamiany na wszystkich interfejsach sieciowych, a żądania były akceptowane bez uwierzytelniania.
Dostęp jest możliwy do dowolnego pliku w aplikacji internetowej, w tym do zawartości WEB-INF, META-INF i dowolnego innego katalogu zwróconego przez wywołanie ServletContext.getResourceAsStream (). AJP umożliwia również użycie dowolnego pliku w katalogach dostępnych dla aplikacji internetowej jako skryptu JSP.
Problem jest widoczny od czasu wydania gałęzi Tomcat 6.x 13 lat temu. Oprócz samego Tomcata, problem dotyczy również produktów, które go używają, takie jak Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), a także samodzielne aplikacje internetowe korzystające z Spring Boot.
również znaleziono podobną lukę (CVE-2020-1745) na serwerze WWW Undertow używany w serwerze aplikacji Wildfly. Obecnie różne grupy przygotowały kilkanaście działających przykładów exploitów.
Apache Tomcat oficjalnie wydał wersje 9.0.31, 8.5.51 i 7.0.100 aby naprawić tę lukę. Aby poprawnie usunąć tę lukę, musisz najpierw ustalić, czy usługa Tomcat AJP Connector jest używana w środowisku serwera:
- Jeśli klaster lub zwrotny serwer proxy nie jest używany, można w zasadzie stwierdzić, że protokół AJP nie jest używany.
- Jeśli nie, musisz dowiedzieć się, czy klaster lub serwer zwrotny komunikuje się z usługą Tomcat AJP Connect
Wspomina się również o tym aktualizacje są teraz dostępne w różnych dystrybucjach Linuksa takie jak: Debian, Ubuntu, RHEL, Fedora, SUSE.
Aby obejść ten problem, możesz wyłączyć usługę Tomcat AJP Connector (powiązać gniazdo nasłuchujące z hostem lokalnym lub zakomentować linię za pomocą portu złącza = »8009 ″), jeśli nie jest to wymagane, lub skonfigurować dostęp uwierzytelniony.
Jeśli chcesz dowiedzieć się więcej na ten temat, skonsultuj się poniższy link.