I ricercatori della compagnia cinese Chaitin Tech hanno identificato () in , un'implementazione open source delle tecnologie Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. La vulnerabilità è stata battezzata Ghostcat e ha un livello di gravità critico (9.8 CVSS). Il problema consente, nella configurazione predefinita, di leggere il contenuto di qualsiasi file dalla directory dell'app web inviando una richiesta sulla porta di rete 8009, inclusi i file di configurazione e il codice sorgente dell'applicazione.
La vulnerabilità consente anche di importare altri file nel codice dell'applicazione, permettendo l'esecuzione di codice sul server, qualora l'applicazione consenta il caricamento di file (ad esempio, l'attaccante può caricare uno script JSP spacciato per un'immagine tramite un modulo di caricamento). Un attacco può essere eseguito se è possibile inviare richieste sulla porta di rete con il gestore AJP. Secondo i dati preliminari, ci sono oltre 1,2 milioni di host che accettano richieste tramite il protocollo AJP.
La vulnerabilità è presente nel protocollo AJP, e errore nell'implementazione. Oltre alla ricezione delle connessioni tramite HTTP (porta 8080), Apache Tomcat consente per impostazione predefinita l'accesso all'applicazione web tramite il protocollo AJP (), porta 8009), che è un'alternativa binaria ottimizzata per ottenere prestazioni superiori rispetto all'HTTP, solitamente utilizzata durante la creazione di cluster di server Tomcat o per accelerare l'interazione con Tomcat su un proxy inverso o un bilanciatore di carico.
AJP fornisce una funzione nativa per accedere ai file sul server, che può essere utilizzata anche per ottenere file che non devono essere divulgati. Si presume che l'accesso a AJP sia aperto solo per server di fiducia, ma in realtà nella configurazione predefinita Tomcat avviava il gestore su tutte le interfacce di rete, e le richieste venivano accettate senza autenticazione. L'accesso era possibile a qualsiasi file dell'applicazione web, compresi i contenuti di WEB-INF, META-INF e qualsiasi altra directory, ottenuti tramite la chiamata ServletContext.getResourceAsStream(). 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 13 anni fa Tomcat 6.x. Oltre a Tomcat, il problema riguarda e i prodotti che lo utilizzano, come Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), così come le applicazioni web autonome che utilizzano . Una vulnerabilità simile (CVE-2020-1745) nel server web , 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 è disabilitato per impostazione predefinita. Attualmente, diversi gruppi hanno preparato più di una dozzina di esempi funzionanti di exploit (
,
,
,
,
,
,
,
,
,
,
).
La vulnerabilità è stata corretta nelle versioni di Tomcat , e (supporto della versione 6.x ). È possibile monitorare il rilascio di aggiornamenti nelle distribuzioni su queste pagine: , , , , , . Come misura preventiva, si può disattivare il servizio Tomcat AJP Connector (fissare la porta di ascolto su localhost o commentare la linea con Connector port = "8009"), se non è necessario, o 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
