Apache Tomcat-en ahultasuna JSP kodea ordezkatzea eta web aplikazio-fitxategiak eskuratzea ahalbidetzen duena

Txinako Chaitin Tech konpainiako ikertzaileek identifikatu dute zaurgarritasuna (CVE-2020-1938) at Apache Tomcat, Java Servlet, JavaServer Pages, Java Expression Language eta Java WebSocket teknologien kode irekiko inplementazioa. Ahultasunari Ghostcat kode izena eta larritasun maila kritikoa (9.8 CVSS) eman zaizkio. Arazoak aukera ematen du, konfigurazio lehenetsian, sareko 8009 atakara eskaera bat bidaliz, web aplikazioen direktorioko edozein fitxategiren edukia irakurtzeko, ezarpenak eta aplikazioaren iturburu-kodeak dituzten fitxategiak barne.

Zaurgarritasunak aplikazioaren kodean beste fitxategi batzuk inportatzea ahalbidetzen du, eta horrek zerbitzarian kodearen exekuzioa antolatzea ahalbidetzen du, aplikazioak fitxategiak zerbitzarira kargatzeko aukera ematen badu (adibidez, erasotzaile batek JSP script bat kargatu dezake baten itxurapean). irudia irudiak igotzeko formularioaren bidez). Eraso bat egin daiteke sareko ataka batera eskaera bat bidaliz AJP kudeatzaile batekin. Lehen datuen arabera, sarean aurkituta 1.2 milioi ostalari baino gehiagok AJP protokoloaren bidez eskaerak onartzen dituzte.

Zaurgarritasuna AJP protokoloan dago, eta ez deitzen ezarpen akatsa. HTTP bidez (8080 ataka) konexioak onartzeaz gain, Apache Tomcat-ek lehenespenez web aplikazio batera sartzeko aukera ematen du AJP protokoloaren bidez (Apache JServ protokoloa, 8009 ataka), hau da, errendimendurako optimizatutako HTTPren baliokide bitar bat, Tomcat zerbitzarien multzo bat sortzeko edo Tomcat-ekin komunikazioa bizkortzeko, alderantzizko proxy edo karga-orekatzaile batean.

AJP-k zerbitzariko fitxategiak atzitzeko funtzio estandar bat eskaintzen du, erabil daitekeena, dibulgaziorik ez duten fitxategiak lortzea barne. AJP zerbitzari fidagarrientzat bakarrik erabil daiteke, baina, egia esan, Tomcat-en konfigurazio lehenetsia kudeatzailea sareko interfaze guztietan exekutatu eta autentifikaziorik gabe eskaerak onartzea zen. Web-aplikazioetako edozein fitxategitara sar daiteke, WEB-INF, META-INF eta ServletContext.getResourceAsStream() deiaren bidez emandako beste edozein direktorioren edukia barne. AJP-k, halaber, web aplikazioaren direktorio eskuragarrietako edozein fitxategi erabil dezakezu JSP script gisa.

Arazoa duela 13 urte atera zen Tomcat 6.x-en adarra agertu zenetik. Zuzenean Tomcat arazoa izan ezik eragiten du eta erabiltzen duten produktuak, hala nola Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), baita erabiltzen duten web aplikazio autonomoak ere. Udaberriko bota. Antzeko ahultasuna (CVE-2020-1745) presente web zerbitzarian undertowWildfly aplikazio zerbitzarian erabiltzen da. JBoss eta Wildfly-n, AJP protokoloa lehenespenez gaituta dago standalone-full-ha.xml, standalone-ha.xml eta ha/full-ha profiletan domain.xml. Spring Boot-en, AJP laguntza desgaituta dago lehenespenez. Dozena bat ustiapen adibide baino gehiago prestatu dituzte talde ezberdinek (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Ahultasuna konpondu da Tomcat-en bertsioetan 9.0.31, 8.5.51 ΠΈ 7.0.100 (mantentze-adarra 6.x etenda). Banaketan eguneratzeen itxura jarrai dezakezu orrialde hauetan: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Konponbide gisa, Tomcat AJP Connector zerbitzua desgai dezakezu (lotu entzuteko socketa localhost-era edo iruzkin ezazu lerroa Konektorearen ataka = "8009") behar ez bada, edo konfiguratu autentifikatutako sarbidea "sekretua" eta "helbidea" atributuak erabiliz, zerbitzua mod_jk eta mod_proxy_ajp-en oinarritutako beste zerbitzari eta proxy batzuekin elkarreragiteko erabiltzen bada (mod_cluster-ek ez du autentifikazioa onartzen).

Iturria: opennet.ru

Gehitu iruzkin berria