Ghostcat, vulnerabilitatea din Tomcat care poate înlocui codul

pisica fantomă

Cercetătorii de la Chaitin Tech, China au lansat informații despre o nouă descoperire, așa cum au identificat-o o vulnerabilitate în popularul container servlet (Servlet Java, pagini JavaServer, limbaj Java Expression și Java WebSocket) Apache tomcat (listat deja ca CVE-2020-1938).

Această vulnerabilitate li s-a atribuit numele de cod „Ghostcat” și un nivel critic de severitate (9.8 CVSS). Problema permite în configurația implicită să trimită o cerere prin portul de rețea 8009 pentru a citi conținutul oricărui fișier din directorul aplicației web, inclusiv codurile sursă ale aplicației și fișierele de configurare.

Vulnerabilitatea permite, de asemenea, importul altor fișiere în codul aplicației, ceea ce permite organizează executarea codului pe server dacă aplicația permite încărcarea fișierelor pe server.

De exemplu, dacă aplicația site-ului web permite utilizatorilor să încarce fișiere, un atacator poate încărca în primul rând un fișier care conține cod script JSP rău intenționat pe server (fișierul încărcat în sine poate fi orice tip de fișier, cum ar fi imagini, fișiere text simplu etc.) și apoi includeți fișierul încărcat prin exploatarea vulnerabilității de la Ghostcat, care poate duce în cele din urmă la executarea codului la distanță.

De asemenea, se menționează că se poate efectua un atac dacă este posibilă trimiterea unei cereri către un port de rețea cu un driver AJP. Conform datelor preliminare, rețeaua găsită mai mult de 1.2 milioane de gazde acceptă cereri folosind protocolul AJP.

Vulnerabilitatea este prezentă în protocolul AJP și nu este cauzată de o eroare de implementare.

Pe lângă acceptarea conexiunilor HTTP (portul 8080) în Apache Tomcat, în mod implicit este posibil să accesați la aplicația web folosind protocolul AJP (Apache Jserv Protocol, portul 8009), care este un analog binar al HTTP optimizat pentru performanțe mai mari, utilizat în general la crearea unui cluster de pe serverele Tomcat sau pentru a accelera interacțiunea cu Tomcat pe un proxy invers sau un echilibru de încărcare.

AJP oferă o funcție standard pentru accesarea fișierelor de pe server, care pot fi utilizate, inclusiv primirea de fișiere care nu fac obiectul dezvăluirii.

Se înțelege că accesul la AJP este deschis numai servitorilor de încrederede fapt, în configurația implicită Tomcat, driverul a fost lansat pe toate interfețele de rețea și solicitările au fost acceptate fără autentificare.

Accesul este posibil la orice fișier din aplicația web, inclusiv conținutul WEB-INF, META-INF și orice alt director returnat prin apelul ServletContext.getResourceAsStream (). AJP vă permite, de asemenea, să utilizați orice fișier din directoarele disponibile unei aplicații web ca script JSP.

Problema a fost evidentă de când filiala Tomcat 6.x a fost lansată acum 13 ani. Pe lângă Tomcat însuși, problema afectează și produsele care o utilizează, cum ar fi Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), precum și aplicații web independente care utilizează Spring Boot.

de asemenea a fost găsită o vulnerabilitate similară (CVE-2020-1745) pe serverul web Undertow utilizat în serverul de aplicații Wildfly. În prezent, diferite grupuri au pregătit mai mult de o duzină de exemple de exploatare.

Apache Tomcat a lansat oficial versiunile 9.0.31, 8.5.51 și 7.0.100 pentru a corecta această vulnerabilitate. Pentru a corecta corect această vulnerabilitate, trebuie mai întâi să determinați dacă serviciul Tomcat AJP Connector este utilizat în mediul server:

  • Dacă nu se utilizează cluster sau proxy invers, se poate stabili practic că AJP nu este utilizat.
  •  Dacă nu, trebuie să aflați dacă clusterul sau serverul invers comunică cu serviciul Tomcat AJP Connect

De asemenea, se menționează că actualizările sunt acum disponibile în diferite distribuții Linux cum ar fi: Debian, Ubuntu, RHEL, Fedora, SUSE.

Ca soluție, puteți dezactiva serviciul Tomcat AJP Connector (legați soclul de ascultare la localhost sau comentați linia cu portul Conector = »8009 ″), dacă nu este necesar, sau puteți configura accesul autentificat.

Dacă doriți să aflați mai multe despre aceasta, puteți consulta următorul link. 


Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.