Kwetsbaarheid in Apache Tomcat waardoor JSP-code kan worden ingevoegd en webapplicatiefiles kunnen worden verkregen

Onderzoekers van het Chinese bedrijf Chaitin Tech hebben kwetsbaarheid (CVE-2020-1938) in Apache Tomcat, een open implementatie van Java Servlet-technologieën, JavaServer Pages, Java Expression Language en Java WebSocket. De kwetsbaarheid is de codenaam Ghostcat toegewezen en heeft een kritieke risico-niveau (9.8 CVSS). Het probleem stelt in de standaardconfiguratie in staat om via een verzoek op netwerkpoort 8009 de inhoud van eventuele bestanden uit de webapplicatie-directory te lezen, inclusief configuratiebestanden en de bronteksten van de applicatie.

De kwetsbaarheid maakt het ook mogelijk om andere bestanden in de applicatiecode te importeren, wat het uitvoeren van code op de server mogelijk maakt als de applicatie het uploaden van bestanden naar de server toestaat (bijvoorbeeld kan een aanvaller een JSP-script als afbeelding uploaden via een afbeelding uploadformulier). Een aanval kan worden uitgevoerd als er een verzoek naar de netwerkpoort met de AJP-handler kan worden verzonden. Voorlopige gegevens tonen aan dat er in het netwerk meer dan 1,2 miljoen hosts zijn gevonden die verzoeken via het AJP-protocol accepteren. De kwetsbaarheid is aanwezig in het AJP-protocol, en

is niet veroorzaakt door een fout in de implementatie. Naast het accepteren van verbindingen via HTTP (poort 8080) staat Apache Tomcat standaard toe om de webapplicatie via het AJP-protocol te benaderen ( Apache Jserv Protocol, poort 8009), dat een geoptimaliseerde binaire variant van HTTP is voor hogere prestaties, meestal gebruikt bij het creëren van een cluster van Tomcat-servers of voor het versnellen van de interactie met Tomcat via een omgekeerde proxy of load balancer.AJP biedt een ingebouwde functie voor toegang tot bestanden op de server, die ook kan worden gebruikt om bestanden die niet voor openbaarmaking zijn bedoeld te verkrijgen. Er wordt verondersteld dat toegang tot AJP alleen open is voor vertrouwde servers, maar in werkelijkheid werd in de standaardconfiguratie van Tomcat de handler op alle netwerkinterfaces gestart en werden verzoeken zonder authenticatie geaccepteerd. Toegang is mogelijk tot alle bestanden van de webapplicatie, inclusief de inhoud van WEB-INF, META-INF en andere directories die kunnen worden opgevraagd via ServletContext.getResourceAsStream(). AJP staat ook toe om elk bestand in de toegestane directories van de webapplicatie als JSP-script te gebruiken.

Het probleem doet zich voor vanaf de 13 jaar geleden uitgebrachte serie Tomcat 6.x. Naast Tomcat zelf is het probleem

Het probleem doet zich voor sinds de release van de 13 jaar oude Tomcat 6.x tak. Naast Tomcat is er ook een probleem aan en de producten die het gebruikt, zoals Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), evenals zelfstandige webapplicaties die gebruikmaken van Spring Boot. Een vergelijkbare kwetsbaarheid (CVE-2020-1745) aanwezig in de webserver Undertow, dat wordt toegepast in de Wildfly-applicatieserver. In JBoss en Wildfly is het AJP-protocol standaard alleen ingeschakeld in standalone-full-ha.xml, standalone-ha.xml en ha/full-ha profielen in domain.xml. In Spring Boot is de ondersteuning voor AJP standaard uitgeschakeld. Momenteel zijn door verschillende groepen meer dan een handvol werkende voorbeelden van exploits voorbereid (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

De kwetsbaarheid is verholpen in de Tomcat-releases 9.0.31, 8.5.51 en 7.0.100 (ondersteuning van de 6.x tak gestopt). De updates in de distributies kunnen worden gevolgd op de volgende pagina's: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Als een tijdelijke beveiligingsmaatregel kan de Tomcat AJP Connector-service worden uitgeschakeld (de luisterende socket aan localhost binden of de regel met Connector port = "8009" uitcommentariëren), indien niet nodig, of configureren geauthenticeerde toegang middels de attributen "secret" en "address" als de service gebruikt wordt voor interactie met andere servers en proxies op basis van mod_jk en mod_proxy_ajp (mod_cluster ondersteunt geen authenticatie).

Bron: opennet.ru