Kerentanan dalam Apache Tomcat yang membolehkan anda menggantikan kod JSP dan mendapatkan fail aplikasi web

Penyelidik dari syarikat China Chaitin Tech telah menemui kelemahan (CVE-2020 1938-) dalam Apache Tomcat, pelaksanaan terbuka Java Servlet, JavaServer Pages, Java Expression Language dan teknologi Java WebSocket. Kerentanan telah diberikan nama kod Ghostcat dan tahap keterukan kritikal (9.8 CVSS). Masalahnya membenarkan, dalam konfigurasi lalai, dengan menghantar permintaan pada port rangkaian 8009, untuk membaca kandungan mana-mana fail daripada direktori aplikasi web, termasuk fail dengan tetapan dan kod sumber aplikasi.

Kerentanan juga memungkinkan untuk mengimport fail lain ke dalam kod aplikasi, yang membolehkan pelaksanaan kod pada pelayan jika aplikasi membenarkan fail dimuat naik ke pelayan (contohnya, penyerang boleh memuat naik skrip JSP yang menyamar sebagai imej melalui borang muat naik imej). Serangan boleh dilakukan apabila mungkin untuk menghantar permintaan ke port rangkaian dengan pengendali AJP. Mengikut data awal, dalam talian dijumpai lebih daripada 1.2 juta hos menerima permintaan melalui protokol AJP.

Kerentanan wujud dalam protokol AJP, dan tidak dipanggil kesilapan dalam pelaksanaan. Selain menerima sambungan melalui HTTP (port 8080), Apache Tomcat secara lalai membenarkan akses kepada aplikasi web melalui protokol AJP (Protokol Apache Jserv, port 8009), yang merupakan analog binari HTTP yang dioptimumkan untuk prestasi yang lebih tinggi, biasanya digunakan semasa mencipta kluster pelayan Tomcat atau untuk mempercepatkan interaksi dengan Tomcat pada proksi terbalik atau pengimbang beban.

AJP menyediakan fungsi standard untuk mengakses fail pada pelayan, yang boleh digunakan, termasuk mendapatkan fail yang tidak tertakluk kepada pendedahan. AJP sepatutnya boleh diakses hanya kepada pelayan yang dipercayai, tetapi sebenarnya konfigurasi lalai Tomcat menjalankan pengendali pada semua antara muka rangkaian dan permintaan yang diterima tanpa pengesahan. Akses boleh dilakukan kepada mana-mana fail aplikasi web, termasuk kandungan WEB-INF, META-INF dan mana-mana direktori lain yang disediakan melalui panggilan ke ServletContext.getResourceAsStream(). AJP juga membenarkan anda menggunakan mana-mana fail dalam direktori yang boleh diakses oleh aplikasi web sebagai skrip JSP.

Masalahnya telah muncul sejak cawangan Tomcat 13.x dikeluarkan 6 tahun lalu. Selain masalah Tomcat itu sendiri mempengaruhi dan produk yang menggunakannya, seperti Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), serta aplikasi web serba lengkap yang menggunakan Boot musim bunga. Kerentanan serupa (CVE-2020-1745) hadir dalam pelayan web Undertow, digunakan dalam pelayan aplikasi Wildfly. Dalam JBoss dan Wildfly, AJP didayakan secara lalai hanya dalam profil standalone-full-ha.xml, standalone-ha.xml dan ha/full-ha dalam domain.xml. Dalam Spring Boot, sokongan AJP dilumpuhkan secara lalai. Pada masa ini, kumpulan yang berbeza telah menyediakan lebih daripada sedozen contoh kerja eksploitasi (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Kerentanan diperbaiki dalam keluaran Tomcat 9.0.31, 8.5.51 и 7.0.100 (penyelenggaraan cawangan 6.x dihentikan). Anda boleh menjejaki ketersediaan kemas kini dalam kit pengedaran pada halaman ini: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Sebagai penyelesaian, anda boleh melumpuhkan perkhidmatan Tomcat AJP Connector (mengikat soket mendengar ke localhost atau mengulas baris dengan port Connector = "8009") jika ia tidak diperlukan, atau sediakan akses yang disahkan menggunakan atribut "rahsia" dan "alamat", jika perkhidmatan digunakan untuk berinteraksi dengan pelayan dan proksi lain berdasarkan mod_jk dan mod_proxy_ajp (mod_cluster tidak menyokong pengesahan).

Sumber: opennet.ru