I ricercatori dell'azienda cinese Chaitin Tech hanno identificato () a , un'implementazione open source delle tecnologie Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. La vulnerabilità è stata battezzata Ghostcat ed è di livello critico (9.8 CVSS). Il problema consente, nella configurazione predefinita, di leggere il contenuto di qualsiasi file nella directory dell'applicazione web, inclusi i file di configurazione e i codici sorgente, inviando una richiesta attraverso la porta di rete 8009.
La vulnerabilità consente anche di importare altri file nel codice dell'applicazione, il che consente di eseguire codice sul server se l'applicazione permette il caricamento di file (ad esempio, un attaccante potrebbe caricare uno script JSP spacciandolo per un'immagine tramite un modulo di caricamento). L'attacco può essere effettuato se è possibile inviare una richiesta alla porta di rete con un gestore AJP. Secondo dati preliminari, nella rete oltre 1,2 milioni di ospiti che accettano richieste tramite il protocollo AJP.
La vulnerabilità è presente nel protocollo AJP, e da un errore nell'implementazione. Oltre a ricevere connessioni via HTTP (porta 8080), in Apache Tomcat è possibile accedere all'applicazione web tramite il protocollo AJP (, porta 8009), che rappresenta un'implementazione binaria ottimizzata per prestazioni superiori rispetto all'HTTP, comunemente usata per creare cluster di server Tomcat o per migliorare l'interazione con Tomcat su un server proxy inverso o bilanciatore di carico.
L'AJP fornisce una funzionalità nativa per accedere ai file sul server, utilizzabile anche per ottenere file che non dovrebbero essere divulgati. Si presume che l'accesso all'AJP sia aperto solo per server fidati, ma in realtà nella configurazione predefinita di Tomcat veniva avviato un gestore su tutte le interfacce di rete, e le richieste venivano accettate senza autenticazione. L'accesso è possibile a qualsiasi file dell'applicazione web, inclusi i contenuti di WEB-INF, META-INF e qualsiasi altra directory servita tramite il metodo ServletContext.getResourceAsStream(). L'AJP consente inoltre di utilizzare qualsiasi file nelle directory disponibili per l'applicazione web come script JSP.
Il problema si manifesta a partire dalla versione di Tomcat 6.x rilasciata 13 anni fa. Oltre a Tomcat, il problema e utilizzando i suoi prodotti, come Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), e anche applicazioni web autonome che utilizzano . Una vulnerabilità simile (CVE-2020-1745) nel web server , utilizzato nel server applicazioni Wildfly. In JBoss e Wildfly, il protocollo AJP è abilitato per impostazione predefinita solo nei profili standalone-full-ha.xml, standalone-ha.xml e ha/full-ha in domain.xml. In Spring Boot, il supporto AJP è disattivato per impostazione predefinita. Attualmente, diversi gruppi hanno preparato più di una decina di esempi pratici di exploit (
,
,
,
,
,
,
,
,
,
,
).
La vulnerabilità è stata corretta nelle versioni di Tomcat , e (supporto della branch 6.x ). È possibile tenere traccia dell'uscita degli aggiornamenti nelle distribuzioni su queste pagine: , , , , , . Come misura di protezione alternativa, è possibile disabilitare il servizio Tomcat AJP Connector (collegare il socket in ascolto a localhost o commentare la riga con Connector port = "8009"), se non è necessario, oppure l'accesso autenticato utilizzando gli attributi "secret" e "address", se il servizio è utilizzato per interagire con altri server e proxy basati su mod_jk e mod_proxy_ajp (mod_cluster non supporta l'autenticazione).
Fonte: opennet.ru
