Sårbarhet i Apache Tomcat som gjør det mulig å erstatte JSP-kode og hente nettapplikasjonsfiler

Forskere fra det kinesiske selskapet Chaitin Tech har identifisert sårbarhet (CVE-2020-1938) inn Apache Tomcat, en åpen kildekode-implementering av Java Servlet, JavaServer Pages, Java Expression Language og Java WebSocket-teknologier. Sårbarheten har fått kodenavnet Ghostcat og et kritisk alvorlighetsnivå (9.8 CVSS). Problemet tillater, i standardkonfigurasjonen, ved å sende en forespørsel til nettverksport 8009 å lese innholdet av filer fra nettapplikasjonskatalogen, inkludert filer med innstillinger og applikasjonskildekoder.

Sårbarheten gjør det også mulig å importere andre filer til applikasjonskoden, noe som gjør det mulig å organisere kodekjøring på serveren hvis applikasjonen tillater at filer lastes opp til serveren (for eksempel kan en angriper laste opp et JSP-skript under dekke av en bilde gjennom bildeopplastingsskjemaet). Et angrep kan gjøres ved å sende en forespørsel til en nettverksport med en AJP-behandler. Ifølge foreløpige data, online funnet mer enn 1.2 millioner verter aksepterer forespørsler via AJP-protokollen.

Sårbarheten finnes i AJP-protokollen, og ikke ringt implementeringsfeil. I tillegg til å akseptere tilkoblinger via HTTP (port 8080), tillater Apache Tomcat som standard tilgang til en nettapplikasjon via AJP-protokollen (Apache Jserv-protokoll, port 8009), som er en ytelsesoptimalisert binær ekvivalent av HTTP, som vanligvis brukes når du oppretter en klynge av Tomcat-servere eller for å øke hastigheten på kommunikasjonen med Tomcat på en omvendt proxy eller lastbalanser.

AJP gir en standardfunksjon for tilgang til filer på serveren, som kan brukes, inkludert innhenting av filer som ikke er gjenstand for offentliggjøring. AJP er ment å være tilgjengelig kun for pålitelige servere, men faktisk var Tomcats standardkonfigurasjon å kjøre behandleren på alle nettverksgrensesnitt og godta forespørsler uten autentisering. Tilgang er mulig til alle nettapplikasjonsfiler, inkludert innholdet i WEB-INF, META-INF og alle andre kataloger gitt gjennom ServletContext.getResourceAsStream()-kallet. AJP lar deg også bruke hvilken som helst fil i nettapplikasjonens tilgjengelige kataloger som et JSP-skript.

Problemet har vært manifestert siden grenen av Tomcat 13.x ble utgitt for 6 år siden. Bortsett fra direkte Tomcat-problem påvirker og produkter som bruker den, for eksempel Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), samt selvstendige nettapplikasjoner som bruker Vårstøvel. Lignende sårbarhet (CVE-2020-1745) tilstede i webserveren Undertowbrukes i Wildfly-applikasjonsserveren. I JBoss og Wildfly er AJP-protokollen bare aktivert som standard i profilene standalone-full-ha.xml, standalone-ha.xml og ha/full-ha i domain.xml. I Spring Boot er AJP-støtte deaktivert som standard. Mer enn et dusin fungerende eksempler på utnyttelser er utarbeidet av forskjellige grupper (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Sårbarhet fikset i Tomcat-utgivelser 9.0.31, 8.5.51 и 7.0.100 (vedlikeholdsgren 6.x avsluttet). Du kan følge utseendet til oppdateringer i distribusjoner på disse sidene: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Som en løsning kan du deaktivere Tomcat AJP Connector-tjenesten (binde lyttekontakten til localhost eller kommentere linjen med Connector-port = "8009") hvis det ikke er nødvendig, eller sette opp autentisert tilgang ved å bruke attributtene "hemmelig" og "adresse", hvis tjenesten brukes til å samhandle med andre servere og proxyer basert på mod_jk og mod_proxy_ajp (mod_cluster støtter ikke autentisering).

Kilde: opennet.ru