Lo hanno scoperto i ricercatori dell'azienda cinese Chaitin Tech () in , un'implementazione aperta delle tecnologie Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. Alla vulnerabilità è stato assegnato il nome in codice Ghostcat e un livello di gravità critico (9.8 CVSS). Il problema consente, nella configurazione predefinita, inviando una richiesta sulla porta di rete 8009, di leggere il contenuto di eventuali file dalla directory dell'applicazione web, compresi i file con impostazioni e codici sorgente dell'applicazione.
La vulnerabilità consente inoltre di importare altri file nel codice dell'applicazione, il che consente l'esecuzione del codice sul server se l'applicazione consente il caricamento dei file sul server (ad esempio, un utente malintenzionato può caricare uno script JSP mascherato da immagine tramite il modulo di caricamento immagini). L'attacco può essere effettuato quando è possibile inviare una richiesta ad una porta di rete con un handler AJP. Secondo i dati preliminari, online più di 1.2 milioni di host che accettano richieste tramite il protocollo AJP.
La vulnerabilità esiste nel protocollo AJP e errore nell'implementazione. Oltre ad accettare connessioni tramite HTTP (porta 8080), Apache Tomcat consente per impostazione predefinita l'accesso a un'applicazione web tramite il protocollo AJP (, porta 8009), che è un analogo binario di HTTP ottimizzato per prestazioni più elevate, solitamente utilizzato quando si crea un cluster di server Tomcat o per accelerare l'interazione con Tomcat su un proxy inverso o un bilanciatore del carico.
AJP fornisce una funzione standard per l'accesso ai file sul server, che può essere utilizzata, incluso l'ottenimento di file che non sono soggetti a divulgazione. Si suppone che AJP sia accessibile solo ai server attendibili, ma in realtà la configurazione predefinita di Tomcat eseguiva il gestore su tutte le interfacce di rete e accettava le richieste senza autenticazione. L'accesso è possibile a qualsiasi file dell'applicazione web, inclusi i contenuti di WEB-INF, META-INF e qualsiasi altra directory fornita tramite una chiamata a ServletContext.getResourceAsStream(). AJP consente inoltre di utilizzare qualsiasi file nelle directory accessibili all'applicazione web come script JSP.
Il problema si è presentato da quando il ramo Tomcat 13.x è stato rilasciato 6 anni fa. Oltre al problema stesso di Tomcat e i prodotti che lo utilizzano, come Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), nonché applicazioni Web autonome che utilizzano . Vulnerabilità simile (CVE-2020-1745) nel server web , utilizzato nel server delle applicazioni Wildfly. In JBoss e Wildfly, 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 (
,
,
,
,
,
,
,
,
,
,
).
Vulnerabilità risolta nelle versioni Tomcat , и (manutenzione del ramo 6.x ). Puoi monitorare la disponibilità degli aggiornamenti nei kit di distribuzione in queste pagine: , , , , , . Come soluzione alternativa, è possibile disabilitare il servizio Tomcat AJP Connector (associare un socket in ascolto a localhost o commentare la riga con Connector port = "8009") se non è necessario, oppure accesso autenticato utilizzando gli attributi “secret” e “address”, se il servizio viene 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