Jadual Kandungan[Sembunyi][Tunjukkan]
Log4Shell, kelemahan internet, baru-baru ini menjejaskan berjuta-juta mesin. Log4j, perisian yang kabur namun hampir ada di mana-mana, menyebabkannya.
Log4j digunakan untuk log semua tindakan yang berlaku di belakang tabir dalam pelbagai sistem komputer.
Ia berdasarkan perpustakaan pembalakan sumber terbuka yang digunakan oleh perniagaan dan juga organisasi kerajaan dalam kebanyakan aplikasi.
Sebagai salah satu lubang keselamatan siber yang paling teruk pernah ditemui, adalah penting untuk melindungi sistem anda daripada kelemahan ini. Tetapi bagaimana?
Mari kita terokai kelemahan Log4j secara terperinci dan semua penyelesaian pembaikan yang mungkin untuknya.
Apakah Log4j?
Log4j ialah sebuah sumber terbuka rangka kerja pembalakan yang membolehkan pembangun perisian merekodkan data yang berbeza dalam aplikasi mereka. Ia adalah komponen projek Perkhidmatan Pembalakan Apache, yang dikendalikan oleh Yayasan Perisian Apache.
Beratus-ratus tapak web dan apl menggunakan Log4j untuk melaksanakan operasi kritikal seperti mengelog data untuk penyahpepijatan dan kegunaan lain.
Apabila anda memasukkan atau mengklik pada pautan dalam talian yang lemah dan mendapat notis ralat 404, ini adalah contoh kerap Log4j di tempat kerja. Pelayan web yang menjalankan domain pautan web yang anda cuba akses memberitahu anda bahawa tiada halaman web sedemikian wujud. Ia juga mencatatkan peristiwa dalam Log4j untuk pentadbir sistem pelayan.
Sepanjang program perisian, isyarat diagnostik yang serupa digunakan. Dalam permainan dalam talian Minecraft, contohnya, pelayan menggunakan Log4j untuk log aktiviti seperti jumlah RAM yang digunakan dan arahan pengguna yang dihantar ke konsol.
Bagaimanakah kelemahan berlaku?
Carian ialah ciri baharu yang diperkenalkan dalam Log4j 2.0, yang membantu untuk memasukkan maklumat tambahan dalam entri log. Salah satu carian ini ialah carian JNDI (Java Penamaan dan Antara Muka Direktori), yang merupakan API Java untuk berkomunikasi dengan perkhidmatan direktori.
Menggunakan pendekatan ini, ID pengguna dalaman boleh dipetakan kepada nama pengguna sebenar. Pertanyaan ini mendedahkan kerentanan RCE yang baru ditemui, kerana salah satu jenis data yang dibekalkan oleh pelayan LDAP ialah URI yang menunjuk ke kelas Java, yang kemudiannya dimuatkan ke dalam memori dan dijalankan oleh tika Log4j.
Disebabkan oleh kelemahan dalam pengesahan input pustaka Log4j, adalah mungkin untuk menyuntik pelayan LDAP sewenang-wenangnya daripada sumber yang tidak dipercayai. Oleh kerana pembangun menganggap bahawa data yang dihantar ke log akan dikendalikan sebagai teks biasa, tiada pengesahan input tambahan dilakukan dan input pengguna berbahaya memasuki log.
Pernyataan log mungkin kelihatan seperti ini:
Pengguna berniat jahat kini akan memasukkan carian JNDI merujuk kepada pelayan LDAP penyangak dalam parameter URL. Carian JNDI adalah seperti berikut:
Pustaka Log4j kemudian bercakap dengan pelayan LDAP ini di attacker.com untuk mendapatkan maklumat direktori, termasuk nilai untuk Java Factory dan Java Codebase.
Kedua-dua nilai ini termasuk kelas Java penyerang, yang kemudiannya dimuatkan ke dalam memori dan dilaksanakan oleh contoh Log4j, melengkapkan pelaksanaan kod.
Siapa yang berisiko?
Kerentanan Log4j adalah sangat luas, mempengaruhi aplikasi perniagaan, peranti terbenam dan subsistemnya. Apl yang terjejas termasuk Cisco Webex, Minecraft dan FileZilla FTP.
Walau bagaimanapun, ini sama sekali bukan senarai keseluruhan. Kepincangan itu malah memberi kesan kepada misi helikopter Ingenuity Mars 2020, yang menggunakan Apache Log4j untuk rakaman acara.
Komuniti keselamatan telah menyusun a senarai sistem yang terdedah. Adalah penting untuk ambil perhatian bahawa senarai ini sentiasa dikemas kini, jadi jika program atau sistem tertentu tidak ditampilkan, jangan anggap ia tidak terjejas.
Pendedahan kepada kerentanan ini berkemungkinan besar, dan walaupun khusus timbunan teknologi tidak menggunakan Java, eksekutif keselamatan harus mengharapkan sistem pembekal kritikal, pembekal SaaS, penyedia pengehosan awan dan penyedia pelayan web untuk berbuat demikian.
Bagaimana untuk menyemak kelemahan Log4j?
Langkah pertama adalah untuk menentukan sama ada serangan telah berlaku. Anda boleh berbuat demikian dengan menyemak log sistem untuk serpihan muatan RCE.
Jika carian untuk istilah seperti "jndi", "ldap" atau "$::" menghasilkan sebarang log, penyelidik keselamatan harus meneroka lebih lanjut untuk melihat sama ada ia adalah serangan yang sah atau hanya cap jari.
Banyak serangan di alam liar ditemui yang tidak memberikan sebarang muatan berbahaya. Walau bagaimanapun, mereka telah dijalankan oleh pakar keselamatan untuk menentukan berapa banyak aplikasi yang terdedah kepada serangan ini.
Langkah seterusnya ialah menggunakan perpustakaan Log4j untuk mengenal pasti semua projek. Jika versi antara 2.0-beta9 dan 2.14.1 digunakan, projek itu boleh terdedah.
Memandangkan kesukaran untuk menentukan di mana kelemahan ini wujud, adalah lebih baik untuk menganggap projek itu mudah terdedah dan mengemas kini perpustakaan adalah tindakan terbaik untuk menghapuskan bahaya pelaksanaan kod.
Projek ini tidak terdedah jika versi yang digunakan kurang daripada 2.0-beta 9, walaupun pustaka Log4j masih perlu ditingkatkan kerana versi dalam julat 1.x sudah lama dan tidak lagi mendapat kemas kini.
Sama ada projek yang mudah terdedah ditemui, dinasihatkan supaya ia diperiksa untuk melihat sama ada sebarang maklumat yang dilog menggunakan Log4j mengandungi maklumat yang boleh diubah oleh pengguna. URL, parameter permintaan, pengepala dan kuki ialah contoh data ini. Jika salah satu daripada ini dilog, projek itu berada dalam bahaya.
Pengetahuan ini boleh membantu anda dalam mendalami log sistem dan menentukan sama ada aplikasi web anda telah diserang.
Terdapat alat dalam talian percuma yang boleh mengesan jika aplikasi web terdedah. Salah satu program ini ialah Pemburu Log4Shell. Ia adalah sumber terbuka dan tersedia pada GitHub.
Jika kawasan kod yang terdedah dalam aplikasi dalam talian ditemui, muatan yang disediakan oleh alat yang didedahkan boleh digunakan untuk menyuntiknya ke dalam aplikasi web. Alat ujian akan mendedahkan sambungan yang dibuat antara aplikasi web anda dan pelayan LDAP mereka jika kelemahan itu dieksploitasi.
Penyelesaian untuk membetulkan kelemahan Log4j
Langkah pertama ialah mengemas kini Log4j, yang boleh anda lakukan dengan menggunakan pengurus pakej biasa atau dengan memuat turun terus dari ini halaman.
Ia juga mungkin untuk mengurangkan kebolehgunaan kelemahan dengan menetapkan pembolehubah persekitaran FORMAT MSG NO LOOKUPS kepada benar. Tindakan balas ini, bagaimanapun, hanya terpakai untuk versi Log4j yang lebih besar daripada atau sama dengan 2.10.
Sekarang mari kita pertimbangkan pilihan alternatif.
1. Penyelesaian untuk Log4j versi 2.17.0
Ia pasti sangat dinasihatkan untuk menggunakan Log4j versi 2.15.0 untuk melindungi daripada Log4Shell, namun, jika ini tidak mungkin, penyelesaian lain tersedia.
Versi 2.7.0 dan lebih baru bagi Log4j: Adalah boleh untuk melindungi daripada sebarang serangan dengan menukar format acara yang akan dilog menggunakan sintaks peratus m nolookups untuk data yang dibekalkan oleh pengguna. Kemas kini ini memerlukan pengeditan fail konfigurasi Log4j untuk menjana versi baharu program. Akibatnya, sebelum menggunakan versi baharu ini, peringkat pengesahan teknikal dan fungsi mesti diulang.
Log4j versi 2.10.0 dan lebih baru: Ia juga mungkin untuk melindungi daripada sebarang serangan dengan menetapkan parameter konfigurasi log4j2.formatMsgNoLookups kepada benar, sebagai contoh, apabila memulakan mesin maya Java dengan pilihan -Dlog4j2." formatMsgNoLookups = true, Pilihan lain ialah mengalih keluar kelas JndiLookup daripada argumen classpath, yang akan mengalih keluar vektor serangan utama (penyelidik tidak menolak kemungkinan vektor serangan lain).
Perkhidmatan Web Amazon menyediakan hotpatch yang "harus digunakan atas risiko anda sendiri." "Teknik" lain seperti Logout4Shell, yang "menggunakan kelemahan ini terhadap dirinya sendiri," telah diterbitkan. Pakar keselamatan mempersoalkan kesahihan langkah ini, yang melibatkan "menggodam mesin untuk memperbaikinya."
2. Masalah telah diselesaikan dalam Log4j v2.17.0.
Untuk versi yang lebih besar daripada 2.10: Log4j2.formatMsgNoLookups hendaklah ditetapkan kepada benar.
Untuk versi 2.0 hingga 2.10.0: Jalankan arahan berikut untuk mengalih keluar kelas LDAP daripada Log4j.
Log4j2.formatMsgNoLookups hendaklah ditetapkan kepada benar dalam tetapan sistem.
Mitigasi dalam JVM
Mitigasi dengan parameter JVM bukan lagi pilihan. Kaedah mitigasi lain terus berjaya. Naik taraf kepada Log4j versi 2.17.0 jika boleh. Terdapat panduan migrasi tersedia untuk Log4j v1.
Jika kemas kini tidak boleh dilakukan, pastikan komponen bahagian klien dan bahagian pelayan mempunyai set sifat sistem -Dlog4j2.formatMsgNoLookups = benar.
Sila ambil perhatian bahawa Log4j v1 telah mencapai akhir hayatnya (EOL) dan tidak akan menerima pembetulan pepijat lagi. Vektor RCE lain juga terdedah kepada Log4j v1. Oleh itu, kami menggesa anda menaik taraf kepada Log4j 2.17.0 secepat mungkin.
3. Langkah-langkah mitigasi
Eksploitasi semasa tidak boleh berfungsi walaupun Log4j terdedah dalam beberapa keadaan, seperti jika mesin hos menjalankan versi Java yang lebih tinggi daripada 6u212, 7u202, 8u192 atau 11.0.2.
Ini disebabkan oleh perlindungan pemuatan kelas jauh Java Penamaan dan Antara Muka Direktori (JNDI) yang lebih baik dalam versi semasa, yang diperlukan untuk serangan itu beroperasi.
Tambahan pula, dengan versi Log4j lebih besar daripada 2.10, isu ini boleh dielakkan dengan menetapkan nilai sistem formatMsgNoLookups kepada benar, memberikan hujah JVM -Dlog4j2.formatMsgNoLookups = benar, atau memadamkan kelas JndiLookup daripada laluan kelas.
Sementara itu, sehingga kejadian terdedah diperbaiki, kelemahan boleh ditangani menggunakan teknik di bawah:
- Tetapkan log4j2.formatMsgNoLookups sifat sistem kepada benar untuk >=2.10.
- Tetapkan pilihan persekitaran LOG4J FORMAT MSG NO LOOKUPS kepada benar untuk >=2.10.
- Alih keluar JndiLookup.class daripada classpath untuk 2.0-beta9 hingga 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Satu amalan terbaik yang disyorkan ialah mengehadkan trafik keluar ke Internet kepada port yang sesuai sahaja.
Walaupun kebanyakan serangan dalam medan dihantar melalui HTTP, kelemahan mungkin dieksploitasi melalui mana-mana protokol yang merakam data input pengguna menggunakan Log4j.
Walau bagaimanapun, mengemas kini kepada log4j 2.17.0 adalah penyelesaian terbaik kerana seseorang boleh menemui pendekatan tambahan kepada isu tersebut. Tambahan pula, banyak penerbit dan pengeluar telah mengumumkan penambahbaikan pada perkhidmatan atau apl mereka.
4. Tampalan kelemahan Log4Shell
Log4j ada di mana-mana, terutamanya sekarang apabila kelemahan itu dieksploitasi. Untuk meringkaskan, semua yang anda perlu lakukan ialah memasukkan aksara berikut dalam log yang diperiksa oleh Log4j.
Dan ini akan memuat turun dan melaksanakan fail Java yang terletak di hujung URL. Ia semudah yang dramatik.
Seperti yang anda sedia maklum, adalah penting untuk menaik taraf log4j kepada versi >= 2.17.0 untuk membetulkan kelemahan Log4Shell ini (CVE-2021-44228).
Jika ini tidak mungkin:
Untuk aplikasi yang menggunakan perpustakaan Log4j versi 2.10.0 dan lebih baru, ia juga mungkin untuk melindungi daripada sebarang serangan dengan menetapkan parameter konfigurasi log4j2.formatMsgNoLookups kepada benar, contohnya, semasa memulakan mesin maya Java dengan -Dlog4j2.formatMsgNoLookups = true pilihan.
Pilihan lain ialah memadamkan kelas JndiLookup daripada argumen classpath, yang akan mengalih keluar vektor serangan utama (penyelidik tidak menolak kewujudan vektor serangan lain).
Nota
Organisasi yang teragak-agak atau tidak mahu membuat pelarasan pada sistem yang mudah terdedah (atau yang hanya ingin memasang perlindungan tambahan) harus memikirkan:
- Pastikan semua trafik dihalakan melalui iSensor/WAF/IPS. Ini boleh menghalang serangan daripada mendapat akses kepada sistem.
- Mengehadkan jumlah trafik yang boleh mencapai sistem yang mudah terdedah Jika sistem tidak perlu disambungkan ke Internet, hadkan akses kepada IPS dan julat yang penting dan boleh dipercayai sahaja.
- Mengurangkan trafik keluar yang dibenarkan oleh hos. Oleh kerana serangan ini beroperasi dengan menyambung ke pelayan penyangak, semua alamat IP yang berlebihan dan port harus disekat pada tembok api.
- Jika perkhidmatan itu tidak diperlukan lagi, perkhidmatan itu harus dilumpuhkan sehingga pembetulan sedia.
Kesimpulan
Kelemahan Log4j mengejutkan komuniti kami dan mengingatkan kami semua betapa kami bergantung pada perisian sumber terbuka.
Log4j adalah unik. Ia bukan sistem pengendalian, bukan juga pelayar, mahupun perisian. Sebaliknya, ia adalah apa yang dirujuk oleh pengaturcara sebagai perpustakaan, pakej atau modul kod. Ia hanya berfungsi satu tujuan, iaitu, menyimpan rekod tentang apa yang berlaku pada pelayan.
Orang yang menulis kod lebih suka menumpukan pada perkara yang menjadikan perisian mereka tersendiri. Mereka tidak berminat untuk mencipta semula roda. Akibatnya, mereka bergantung pada kebanyakan perpustakaan kod sedia ada, seperti Log4j.
Modul Log4j diperoleh daripada Apache, perisian pelayan web yang paling banyak digunakan. Itulah sebabnya ia boleh ditemui pada berjuta-juta pelayan. Oleh itu, meningkatkan ancaman keselamatan.
Saya harap penyelesaian di atas membantu anda memastikan peranti anda selamat.
Nantikan HashDork untuk mendapatkan maklumat yang lebih berguna daripada dunia teknologi.
Sila tinggalkan balasan anda