Sårbarhed i Apache Tomcat, der gør det muligt at erstatte JSP-kode og hente webapplikationsfiler

Forskere fra det kinesiske firma Chaitin Tech har identificeret sårbarhed (CVE-2020-1938) i Apache Tomcat, en open source-implementering af Java Servlet, JavaServer Pages, Java Expression Language og Java WebSocket-teknologier. Sårbarheden har fået kodenavnet Ghostcat og et kritisk sværhedsniveau (9.8 CVSS). Problemet tillader, i standardkonfigurationen, ved at sende en anmodning til netværksport 8009 at læse indholdet af filer fra webapplikationsbiblioteket, inklusive filer med indstillinger og applikationskildekoder.

Sårbarheden gør det også muligt at importere andre filer til applikationskoden, hvilket gør det muligt at organisere kodekørsel på serveren, hvis applikationen tillader, at filer uploades til serveren (f.eks. kan en angriber uploade et JSP-script under dække af en billede via billedoverførselsformularen). Et angreb kan udføres ved at sende en anmodning til en netværksport med en AJP-handler. Ifølge foreløbige data, online fundet mere end 1.2 millioner værter accepterer anmodninger via AJP-protokollen.

Sårbarheden findes i AJP-protokollen, og ikke kaldet implementeringsfejl. Ud over at acceptere forbindelser via HTTP (port 8080) tillader Apache Tomcat som standard adgang til en webapplikation via AJP-protokollen (Apache Jserv-protokollen, port 8009), som er en præstationsoptimeret binær ækvivalent til HTTP, der almindeligvis bruges ved oprettelse af en klynge af Tomcat-servere eller til at fremskynde kommunikationen med Tomcat på en omvendt proxy eller load balancer.

AJP giver en standardfunktion til at få adgang til filer på serveren, som kan bruges, herunder indhentning af filer, der ikke er genstand for offentliggørelse. AJP formodes kun at være tilgængelig for betroede servere, men faktisk var Tomcats standardkonfiguration at køre handleren på alle netværksgrænseflader og acceptere anmodninger uden godkendelse. Adgang er mulig til alle webapplikationsfiler, inklusive indholdet af WEB-INF, META-INF og alle andre mapper givet gennem ServletContext.getResourceAsStream()-kaldet. AJP giver dig også mulighed for at bruge enhver fil i webapplikationens tilgængelige mapper som et JSP-script.

Problemet har vist sig siden grenen af ​​Tomcat 13.x blev udgivet for 6 år siden. Undtagen direkte Tomcat problem påvirker og produkter, der bruger det, såsom Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), samt selvstændige webapplikationer, der bruger Forår støvle. Lignende sårbarhed (CVE-2020-1745) er til stede i webserveren Undertowbruges i Wildfly-applikationsserveren. I JBoss og Wildfly er AJP-protokollen kun aktiveret som standard i standalone-full-ha.xml, standalone-ha.xml og ha/full-ha profiler i domain.xml. I Spring Boot er AJP-understøttelse deaktiveret som standard. Mere end et dusin arbejdseksempler på bedrifter er blevet udarbejdet af forskellige grupper (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Sårbarhed rettet i Tomcat-udgivelser 9.0.31, 8.5.51 и 7.0.100 (vedligeholdelsesgren 6.x opsagt). Du kan følge udseendet af opdateringer i distributioner på disse sider: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Som en løsning kan du deaktivere Tomcat AJP Connector-tjenesten (bind lyttesocket til localhost eller kommentere linjen med Connector-port = "8009"), hvis det ikke er nødvendigt, eller oprettet autentificeret adgang ved hjælp af attributterne "hemmelig" og "adresse", hvis tjenesten bruges til at interagere med andre servere og proxyer baseret på mod_jk og mod_proxy_ajp (mod_cluster understøtter ikke godkendelse).

Kilde: opennet.ru