Navorsers van die Chinese maatskappy Chaitin Tech het ontdek () in , 'n oop implementering van Java Servlet, JavaServer Pages, Java Expression Language en Java WebSocket-tegnologieë. Die kwesbaarheid is die kodenaam Ghostcat en 'n kritieke ernsvlak (9.8 CVSS) toegeken. Die probleem laat toe, in die verstekkonfigurasie, deur 'n versoek op netwerkpoort 8009 te stuur, om die inhoud van enige lêers vanaf die webtoepassingsgids te lees, insluitend lêers met instellings en toepassingsbronkodes.
Die kwesbaarheid maak dit ook moontlik om ander lêers in die toepassingskode in te voer, wat voorsiening maak vir kode-uitvoering op die bediener as die toepassing toelaat dat lêers na die bediener opgelaai word (byvoorbeeld, 'n aanvaller kan 'n JSP-skrip oplaai wat as 'n beeld vermom is deur die beeldoplaaivorm). Die aanval kan uitgevoer word wanneer dit moontlik is om 'n versoek na 'n netwerkpoort met 'n AJP-hanteerder te stuur. Volgens voorlopige data, aanlyn meer as 1.2 miljoen gashere wat versoeke via die AJP-protokol aanvaar.
Die kwesbaarheid bestaan in die AJP-protokol, en fout in implementering. Benewens die aanvaarding van verbindings via HTTP (poort 8080), laat Apache Tomcat by verstek toegang tot 'n webtoepassing via die AJP-protokol (, poort 8009), wat 'n binêre analoog van HTTP is wat geoptimaliseer is vir hoër werkverrigting, gewoonlik gebruik wanneer 'n groep Tomcat-bedieners geskep word of om interaksie met Tomcat op 'n omgekeerde instaanbediener of lasbalanseerder te bespoedig.
AJP bied 'n standaardfunksie vir toegang tot lêers op die bediener, wat gebruik kan word, insluitend die verkryging van lêers wat nie onderhewig is aan openbaarmaking nie. AJP is veronderstel om slegs toeganklik te wees vir betroubare bedieners, maar in werklikheid het Tomcat se verstekkonfigurasie die hanteerder op alle netwerkkoppelvlakke laat loop en versoeke sonder verifikasie aanvaar. Toegang is moontlik tot enige webtoepassinglêers, insluitend die inhoud van WEB-INF, META-INF en enige ander gidse wat verskaf word deur 'n oproep na ServletContext.getResourceAsStream(). AJP laat jou ook toe om enige lêer in dopgehou wat toeganklik is vir die webtoepassing as 'n JSP-skrip te gebruik.
Die probleem verskyn sedert die Tomcat 13.x-tak 6 jaar gelede vrygestel is. Benewens die Tomcat-probleem self en produkte wat dit gebruik, soos Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), sowel as selfstandige webtoepassings wat gebruik . Soortgelyke kwesbaarheid (CVE-2020-1745) in die webbediener , gebruik in die Wildfly-toepassingsbediener. In JBoss en Wildfly is AJP by verstek slegs geaktiveer in selfstandige-vol-ha.xml, selfstandige-ha.xml en ha/vol-ha profiele in domein.xml. In Spring Boot is AJP-ondersteuning by verstek gedeaktiveer. Tans het verskillende groepe meer as 'n dosyn werkende voorbeelde van uitbuiting voorberei (
,
,
,
,
,
,
,
,
,
,
).
Kwesbaarheid reggestel in Tomcat-vrystellings , и (onderhoud van die 6.x-tak ). U kan die beskikbaarheid van opdaterings in verspreidingsstelle op hierdie bladsye naspoor: , , , , , . As 'n oplossing kan jy die Tomcat AJP Connector-diens deaktiveer (bind 'n luistersok aan localhost of maak kommentaar op die lyn met Connector-poort = "8009") as dit nie nodig is nie, of geverifieerde toegang met behulp van die "geheime" en "adres" eienskappe, as die diens gebruik word om met ander bedieners en gevolmagtigdes te kommunikeer gebaseer op mod_jk en mod_proxy_ajp (mod_cluster ondersteun nie verifikasie nie).
Bron: opennet.ru