Cercetătorii de la compania chineză Chaitin Tech au descoperit () în , o implementare deschisă a tehnologiilor Java Servlet, JavaServer Pages, Java Expression Language și Java WebSocket. Vulnerabilitatea a primit numele de cod Ghostcat și un nivel critic de severitate (9.8 CVSS). Problema permite, în configurația implicită, prin trimiterea unei cereri pe portul de rețea 8009, să citească conținutul oricăror fișiere din directorul aplicației web, inclusiv fișiere cu setări și coduri sursă ale aplicației.
Vulnerabilitatea face, de asemenea, posibilă importarea altor fișiere în codul aplicației, ceea ce permite executarea codului pe server dacă aplicația permite încărcarea fișierelor pe server (de exemplu, un atacator poate încărca un script JSP deghizat în imagine prin intermediul formularul de încărcare a imaginii). Atacul poate fi efectuat atunci când este posibilă trimiterea unei cereri către un port de rețea cu un handler AJP. Conform datelor preliminare, online peste 1.2 milioane de gazde care acceptă cereri prin protocolul AJP.
Vulnerabilitatea există în protocolul AJP și eroare de implementare. Pe lângă acceptarea conexiunilor prin HTTP (portul 8080), Apache Tomcat permite implicit accesul la o aplicație web prin protocolul AJP (, portul 8009), care este un analog binar al HTTP optimizat pentru performanțe mai mari, folosit de obicei atunci când se creează un cluster de servere Tomcat sau pentru a accelera interacțiunea cu Tomcat pe un proxy invers sau un echilibrator de încărcare.
AJP oferă o funcție standard pentru accesarea fișierelor de pe server, care poate fi utilizată, inclusiv obținerea de fișiere care nu fac obiectul dezvăluirii. AJP ar trebui să fie accesibil doar serverelor de încredere, dar, de fapt, configurația implicită a Tomcat a rulat handlerul pe toate interfețele de rețea și a acceptat cereri fără autentificare. Accesul este posibil la orice fișiere de aplicație web, inclusiv conținutul WEB-INF, META-INF și orice alte directoare furnizate printr-un apel către ServletContext.getResourceAsStream(). AJP vă permite, de asemenea, să utilizați orice fișier din directoarele accesibile aplicației web ca script JSP.
Problema apare de la lansarea sucursalei Tomcat 13.x acum 6 ani. Pe lângă problema Tomcat în sine și produse care îl folosesc, cum ar fi Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), precum și aplicații web autonome care utilizează . Vulnerabilitate similară (CVE-2020-1745) în serverul web , utilizat în serverul de aplicații Wildfly. În JBoss și Wildfly, AJP este activat implicit numai în profilurile standalone-full-ha.xml, standalone-ha.xml și ha/full-ha în domain.xml. În Spring Boot, suportul AJP este dezactivat implicit. În prezent, diferite grupuri au pregătit mai mult de o duzină de exemple de lucru de exploit-uri (
,
,
,
,
,
,
,
,
,
,
).
Vulnerabilitatea remediată în versiunile Tomcat , и (întreținerea ramurii 6.x ). Puteți urmări disponibilitatea actualizărilor în kiturile de distribuție pe aceste pagini: , , , , , . Ca o soluție, puteți dezactiva serviciul Tomcat AJP Connector (legați o priză de ascultare la localhost sau comentați linia cu Portul conector = „8009”) dacă nu este necesar, sau acces autentificat folosind atributele „secret” și „address”, dacă serviciul este utilizat pentru a interacționa cu alte servere și proxy pe baza mod_jk și mod_proxy_ajp (mod_cluster nu acceptă autentificarea).
Sursa: opennet.ru