Forskare från Chaitin Tech, Kina släpptes information om en ny upptäckt, som de har identifierat en sårbarhet i den populära servletbehållaren (Java Servlet, JavaServer Pages, Java Expression Language och Java WebSocket) Apache tomcat (redan listad som CVE-2020-1938).
Denna sårbarhet de tilldelades kodnamnet "Ghostcat" och en kritisk svårighetsgrad (9.8 CVSS). Problemet tillåter i standardkonfigurationen att skicka en begäran via nätverksport 8009 för att läsa innehållet i valfri fil i webbapplikationskatalogen, inklusive källkoder för program och konfigurationsfiler.
Sårbarheten tillåter också att andra filer importeras till applikationskoden, vilket tillåter organisera kodutförande på servern om applikationen tillåter att filer laddas upp till servern.
Till exempel, om webbplatsapplikationen tillåter användare att ladda upp filer, en angripare kan ladda först en fil som innehåller JSP-skriptkod skadlig på servern (själva den uppladdade filen kan vara vilken typ av fil som helst, t.ex. bilder, vanliga textfiler etc.) och inkludera sedan den uppladdade filen genom att utnyttja sårbarheten från Ghostcat, vilket i slutändan kan resultera i fjärrkörning av kod.
Det nämns också att en attack kan utföras om det är möjligt att skicka en begäran till en nätverksport med en AJP-drivrutin. Enligt preliminära uppgifter, nätverket hittades mer än 1.2 miljoner värdar accepterar förfrågningar med AJP-protokollet.
Sårbarheten finns i AJP-protokollet och det orsakas inte av ett implementeringsfel.
Förutom att acceptera HTTP-anslutningar (port 8080) i Apache Tomcat, som standard det är möjligt att komma åt till webbapplikationen med hjälp av AJP-protokollet (Apache Jserv Protocol, port 8009), som är en binär analog av HTTP optimerad för högre prestanda, används vanligtvis när du skapar ett kluster från Tomcat-servrar eller för att påskynda interaktionen med Tomcat på en omvänd proxy eller belastningsbalans.
AJP tillhandahåller en standardfunktion för åtkomst till filer på servern, som kan användas, inklusive mottagande av filer som inte är föremål för avslöjande.
Det är underförstått att tillgång till AJP är endast öppen för betrodda anställdamen faktiskt, i Tomcat-standardkonfigurationen lanserades drivrutinen på alla nätverksgränssnitt och förfrågningar accepterades utan autentisering.
Åtkomst är möjlig till alla filer i webbapplikationen, inklusive innehållet i WEB-INF, META-INF och andra kataloger som returneras via ServletContext.getResourceAsStream (). AJP låter dig också använda alla filer i kataloger som är tillgängliga för en webbapplikation som ett JSP-skript.
Problemet har varit uppenbart sedan Tomcat 6.x-filialen släpptes för 13 år sedan. Förutom Tomcat själv, problemet påverkar också de produkter som använder det, såsom Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), samt fristående webbapplikationer som använder Spring Boot.
också en liknande sårbarhet hittades (CVE-2020-1745) på Undertow-webbservern används i Wildfly-applikationsservern. För närvarande har olika grupper förberett mer än ett dussin arbetsexempel på exploater.
Apache Tomcat har officiellt släppt versionerna 9.0.31, 8.5.51 och 7.0.100 för att korrigera denna sårbarhet. För att korrigera denna sårbarhet korrektmåste du först avgöra om Tomcat AJP Connector-tjänsten används i din servermiljö:
- Om kluster eller omvänd proxy inte används kan du i princip bestämma att AJP inte används.
- Om inte, måste du ta reda på om klustret eller omvänd servern kommunicerar med Tomcat AJP Connect-tjänsten
Det nämns också att uppdateringar finns nu tillgängliga i de olika Linux-distributionerna som: Debian, Ubuntu, RHEL, Fedora, SUSE.
Som en lösning kan du inaktivera tjänsten Tomcat AJP Connector (binda lyssningsuttaget till localhost eller kommentera raden med Connector-port = »8009 ″), om det inte krävs, eller konfigurera autentiserad åtkomst.
Om du vill veta mer om det kan du rådfråga följande länk.