Vundebleco en Apache Tomcat, kiu ebligas al vi anstataŭigi JSP-kodon kaj akiri retprogramojn

Esploristoj de la ĉina kompanio Chaitin Tech malkovris vundebleco (CVE-2020-1938) en Apache Tomcat, malferma efektivigo de Java Servlet, JavaServer Pages, Java Expression Language kaj Java WebSocket teknologioj. La vundebleco ricevis la kodnomon Ghostcat kaj kritika severecnivelo (9.8 CVSS). La problemo ebligas, en la defaŭlta agordo, sendante peton sur rethaveno 8009, legi la enhavon de iuj dosieroj el la dosierujo de la retejo, inkluzive de dosieroj kun agordoj kaj fontkodoj de aplikaĵo.

La vundebleco ankaŭ ebligas importi aliajn dosierojn en la aplikaĵokodon, kio ebligas kodon ekzekuton sur la servilo se la aplikaĵo permesas alŝuti dosierojn al la servilo (ekzemple, atakanto povas alŝuti JSP-skripton maskitan kiel bildon per la bildo alŝuta formularo). La atako povas esti farita kiam eblas sendi peton al rethaveno kun AJP-traktilo. Laŭ antaŭaj datumoj, interrete trovita pli ol 1.2 milionoj da gastigantoj akceptantaj petojn per la AJP-protokolo.

La vundebleco ekzistas en la AJP-protokolo, kaj ne vokis eraro en efektivigo. Krom akcepti konektojn per HTTP (haveno 8080), Apache Tomcat defaŭlte permesas aliron al TTT-apliko per la protokolo AJP (Apache Jserv-Protokolo, haveno 8009), kiu estas binara analogo de HTTP optimumigita por pli alta efikeco, kutime uzata dum kreado de aro de Tomcat-serviloj aŭ por akceli interagadon kun Tomcat sur inversa prokurilo aŭ ŝarĝbalancilo.

AJP disponigas norman funkcion por aliri dosierojn sur la servilo, kiuj povas esti uzataj, inkluzive de akirado de dosieroj ne submetitaj al malkaŝo. AJP supozeble estas alirebla nur por fidindaj serviloj, sed fakte la defaŭlta agordo de Tomcat funkciis la prizorganton sur ĉiuj retaj interfacoj kaj akceptis petojn sen aŭtentigo. Aliro estas ebla al ajnaj retejo-aplikaj dosieroj, inkluzive de la enhavo de WEB-INF, META-INF kaj iuj aliaj dosierujoj provizitaj per voko al ServletContext.getResourceAsStream(). AJP ankaŭ permesas vin uzi ajnan dosieron en dosierujoj alireblaj al la retejo kiel JSP-skripto.

La problemo aperas ekde la Tomcat 13.x-filio publikigita antaŭ 6 jaroj. Krom la Tomcat problemo mem influas kaj produktoj kiuj uzas ĝin, kiel ekzemple Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), same kiel memstaraj interretaj aplikoj kiuj uzas Printempa boteto. Simila vundebleco (CVE-2020-1745) ĉeestanta en la retservilo Undertow, uzata en la aplikaĵservilo Wildfly. En JBoss kaj Wildfly, AJP estas ebligita defaŭlte nur en standalone-full-ha.xml, standalone-ha.xml kaj ha/full-ha profiloj en domain.xml. En Spring Boot, AJP-subteno estas malŝaltita defaŭlte. Nuntempe, malsamaj grupoj preparis pli ol dekduo da funkciaj ekzemploj de heroaĵoj (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Vundebleco riparita en Tomcat-eldonoj 9.0.31, 8.5.51 и 7.0.100 (prizorgado de la branĉo 6.x finita). Vi povas spuri la haveblecon de ĝisdatigoj en distribuaj iloj sur ĉi tiuj paĝoj: Debian, ubuntu, RELO, Fedora, SUSE, FreeBSD. Kiel solvo, vi povas malŝalti la Tomcat AJP Connector-servon (ligi aŭskultan ingon al loka gastiganto aŭ komenti la linion kun Connector haveno = "8009") se ĝi ne estas bezonata, aŭ starigi aŭtentikigita aliro uzante la atributojn "sekreto" kaj "adreso", se la servo estas uzata por interagi kun aliaj serviloj kaj prokuriloj bazitaj sur mod_jk kaj mod_proxy_ajp (mod_cluster ne subtenas aŭtentikigon).

fonto: opennet.ru