Cercetătorii de la compania chineză Chaitin Tech au identificat () în , o implementare deschisă a tehnologiilor Java Servlet, JavaServer Pages, Java Expression Language și Java WebSocket. Vulnerabilitatea a fost denumită Ghostcat și are un nivel critic de pericol (9.8 CVSS). Problema permite, în configurația implicită, citirea conținutului oricăror fișiere din directorul aplicației web prin trimiterea unei cereri pe portul de rețea 8009, inclusiv fișiere de configurare și cod sursă al aplicației.
Vulnerabilitatea oferă, de asemenea, posibilitatea de a importa alte fișiere în codul aplicației, permițând executarea codului pe server, dacă aplicația permite încărcarea de fișiere pe server (de exemplu, atacatorul poate încărca un script JSP sub forma unei imagini printr-un formular de încărcare). Atacul poate fi efectuat atunci când se poate trimite o cerere pe portul de rețea cu un handler AJP. Potrivit datelor preliminare, în rețea peste 1.2 milioane de gazde care acceptă cereri prin protocolul AJP.
Vulnerabilitatea este prezentă în protocolul AJP, iar de o eroare în implementare. În plus față de acceptarea conexiunilor prin HTTP (portul 8080), Apache Tomcat permite, în mod implicit, accesul la aplicația web prin protocolul AJP (, port 8009), care reprezintă un analog binar optimizat pentru performanță mai mare al HTTP, utilizat de obicei în crearea unui cluster de servere Tomcat sau pentru îmbunătățirea interacțiunii cu Tomcat pe un proxy invers sau un balansor de sarcină.
AJP oferă o funcție standard pentru accesarea fișierelor pe server, care poate fi utilizată inclusiv pentru obținerea fișierelor care nu ar trebui dezvăluite. Se subînțelege că accesul la AJP este deschis doar pentru servere de încredere, dar în practică, în configurația implicită, Tomcat a fost configurat să ruleze handler-ul pe toate interfețele de rețea, iar cererile au fost acceptate fără autentificare. Accesul este posibil la orice fișier din aplicația web, inclusiv conținutul din WEB-INF, META-INF și orice alte directoare livrate prin apelul ServletContext.getResourceAsStream(). AJP permite, de asemenea, utilizarea oricărui fișier din directoarele disponibile pentru aplicația web ca script JSP.
Problema apare începând cu ramura Tomcat 6.x, lansată acum 13 ani. Pe lângă Tomcat, problema și produsele sale, cum ar fi Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), precum și aplicațiile web autonome care utilizează . O vulnerabilitate similară (CVE-2020-1745) în serverul web , utilizat în serverul de aplicații Wildfly. În JBoss și Wildfly, protocolul AJP este activat în mod implicit doar în fișierele standalone-full-ha.xml, standalone-ha.xml și ha/full-ha din domain.xml. În Spring Boot, suportul pentru AJP este dezactivat în mod implicit. În prezent, diferite grupuri au pregătit mai mult de zece exemple de exploatare (
,
,
,
,
,
,
,
,
,
,
).
Vulnerabilitatea a fost eliminată în versiunile Tomcat , și (întreținerea ramurii 6.x ). Actualizările în distribuții pot fi urmărite pe aceste pagini: , , , , , . Ca o măsură de protecție, se poate dezactiva serviciul Tomcat AJP Connector (asocierea unui socket ascultător cu localhost sau comentarea liniei cu Connector port = "8009"), dacă nu este necesar, sau accesul autentificat prin intermediul atributelor „secret” și „address”, dacă serviciul este utilizat pentru interacțiunea cu alte servere și proxie pe baza mod_jk și mod_proxy_ajp (mod_cluster nu suportă autentificarea).
Sursa: opennet.ro
