Det har forskare från det kinesiska företaget Chaitin Tech upptäckt () i , en öppen implementering av Java Servlet, JavaServer Pages, Java Expression Language och Java WebSocket-teknologier. Sårbarheten har tilldelats kodnamnet Ghostcat och en kritisk svårighetsgrad (9.8 CVSS). Problemet tillåter, i standardkonfigurationen, genom att skicka en begäran på nätverksport 8009, att läsa innehållet i alla filer från webbapplikationskatalogen, inklusive filer med inställningar och applikationskällkoder.
Sårbarheten gör det också möjligt att importera andra filer till applikationskoden, vilket möjliggör kodexekvering på servern om applikationen tillåter att filer laddas upp till servern (till exempel kan en angripare ladda upp ett JSP-skript förklädd till en bild via bilduppladdningsformuläret). Attacken kan utföras när det är möjligt att skicka en begäran till en nätverksport med en AJP-hanterare. Enligt preliminära uppgifter, online mer än 1.2 miljoner värdar accepterar förfrågningar via AJP-protokollet.
Sårbarheten finns i AJP-protokollet, och fel i genomförandet. Förutom att acceptera anslutningar via HTTP (port 8080) tillåter Apache Tomcat som standard åtkomst till en webbapplikation via AJP-protokollet (, port 8009), som är en binär analog av HTTP optimerad för högre prestanda, vanligtvis används när man skapar ett kluster av Tomcat-servrar eller för att påskynda interaktion med Tomcat på en omvänd proxy eller lastbalanserare.
AJP tillhandahåller en standardfunktion för att komma åt filer på servern, som kan användas, inklusive att hämta filer som inte är föremål för avslöjande. AJP är tänkt att endast vara tillgänglig för betrodda servrar, men i själva verket körde Tomcats standardkonfiguration hanteraren på alla nätverksgränssnitt och accepterade förfrågningar utan autentisering. Åtkomst är möjlig till alla webbapplikationsfiler, inklusive innehållet i WEB-INF, META-INF och alla andra kataloger som tillhandahålls genom ett anrop till ServletContext.getResourceAsStream(). AJP låter dig också använda vilken fil som helst i kataloger som är tillgängliga för webbapplikationen som ett JSP-skript.
Problemet har dykt upp sedan Tomcat 13.x-grenen släpptes för 6 år sedan. Förutom själva Tomcat-problemet och produkter som använder den, såsom Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), såväl som fristående webbapplikationer som använder . Liknande sårbarhet (CVE-2020-1745) i webbservern , som används i Wildfly-applikationsservern. I JBoss och Wildfly är AJP aktiverat som standard endast i profilerna fristående-full-ha.xml, fristående-ha.xml och ha/full-ha i domain.xml. I Spring Boot är AJP-stöd inaktiverat som standard. För närvarande har olika grupper förberett mer än ett dussin fungerande exempel på bedrifter (
,
,
,
,
,
,
,
,
,
,
).
Sårbarhet fixad i Tomcat-versioner , и (underhåll av 6.x-grenen ). Du kan spåra tillgängligheten för uppdateringar i distributionspaket på dessa sidor: , , , , , . Som en lösning kan du inaktivera Tomcat AJP Connector-tjänsten (binda en lyssningssocket till localhost eller kommentera linjen med Connector-port = "8009") om den inte behövs, eller autentiserad åtkomst med attributen "hemlig" och "adress", om tjänsten används för att interagera med andra servrar och proxyservrar baserade på mod_jk och mod_proxy_ajp (mod_cluster stöder inte autentisering).
Källa: opennet.ru