Sårbarhet i Apache Tomcat som möjliggör insättning av JSP-kod och åtkomst till filer i web-applikationer

Forskare från det kinesiska företaget Chaitin Tech har upptäckt sårbarhet (CVE-2020-1938) i Apache Tomcat, en öppen implementering av Java Servlet-teknologierna, JavaServer Pages, Java Expression Language och Java WebSocket. Sårbarheten har kodnamnet Ghostcat och har en kritisk risknivå (9.8 CVSS). Problemet gör det möjligt, i standardkonfiguration, att genom att skicka en förfrågan till nätverksport 8009, läsa innehållet i alla filer från webapplikationens katalog, inklusive inställningsfiler och källkoder för applikationen.

Sårbarheten gör också att det går att importera andra filer i applikationens kod, vilket möjliggör kodexekvering på servern, om applikationen tillåter filuppladdning till servern (till exempel kan en angripare ladda upp ett JSP-skript under förevändning av en bild via en bilduppladdningsformulär). En attack kan genomföras om det finns möjlighet att skicka en förfrågan till nätverksporten med AJP-hanteraren. Enligt preliminära uppgifter finns det i nätverket fanns över 1,2 miljoner värdar som tar emot förfrågningar via AJP-protokollet.

Sårbarheten finns i AJP-protokollet, och inte orsakas av ett fel i implementeringen. Förutom att ta emot anslutningar via HTTP (port 8080) tillåter Apache Tomcat som standard åtkomst till webapplikationen genom AJP-protokollet (Apache Jserv Protocol, port 8009), vilket representerar en optimerad binär motsvarighet till HTTP designad för att uppnå högre prestanda, vanligtvis använd vid skapande av kluster av Tomcat-servrar eller för att påskynda kommunikationen med Tomcat på en reverse proxy eller lastbalanserare.

AJP erbjuder en inbyggd funktion för att få åtkomst till filer på servern, vilket också kan användas för att hämta filer som inte bör avslöjas. Det antas att åtkomsten till AJP endast är öppen för betrodda servrar, men i praktiken har Tomcats standardkonfiguration startat hanteraren på alla nätverksgränssnitt, och förfrågningar har accepterats utan autentisering. Åtkomst är möjlig till alla filer i webapplikationen, inklusive innehållet i WEB-INF, META-INF och andra kataloger som förmedlas genom anrop av ServletContext.getResourceAsStream(). AJP tillåter också att vilken fil som helst i katalogerna som är tillgängliga för webapplikationen används som JSP-skript.

Problemet har funnits sedan den version av Tomcat 6.x som släpptes för 13 år sedan. Utöver direkt Tomcat påverkas även problemet. lösningar baserade på det öppna UPnP-stacket och dess produkter, såsom Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), samt självgående webbapplikationer, som använder Spring Boot. En liknande sårbarhet (CVE-2020-1745) är närvarande i webbservern Undertow, som används i applikationsservern Wildfly. I JBoss och Wildfly är AJP-protokollet som standard aktiverat endast i standalone-full-ha.xml, standalone-ha.xml och ha/full-ha-profiler i domain.xml. I Spring Boot är stödet för AJP avaktiverat som standard. För närvarande har olika grupper förberett fler än ett dussin fungerande exempel på exploits (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Sårbarheten har åtgärdats i Tomcat-versioner 9.0.31, 8.5.51 och 7.0.100 (underhållet av version 6.x avslutat). Håll koll på uppdateringar i distributionerna på följande sidor: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Som en tillfällig skyddsåtgärd kan du stänga av Tomcat AJP Connector-tjänsten (bind lyssnande socket till localhost eller kommentera raden med Connector port = "8009"), om det inte är nödvändigt, eller anpassas autentiserad åtkomst med hjälp av attributen "secret" och "address", om tjänsten används för kommunikation med andra servrar och proxyer baserat på mod_jk och mod_proxy_ajp (mod_cluster stödjer inte autentisering).

Källa: opennet.ru