Selama hari-hari terakhir di internet ada banyak pembicaraan tentang kerentanan Log4j di mana berbagai vektor serangan telah ditemukan dan berbagai eksploitasi fungsional juga telah disaring untuk mengeksploitasi kerentanan.
Keseriusan masalah ini adalah bahwa ini adalah kerangka kerja yang populer untuk mengatur registri dalam aplikasi Java., yang memungkinkan kode arbitrer dieksekusi ketika nilai yang diformat khusus ditulis ke registri dalam format "{jndi: URL}". Serangan dapat dilakukan pada aplikasi Java yang mencatat nilai yang diperoleh dari sumber eksternal, misalnya dengan menampilkan nilai bermasalah dalam pesan kesalahan.
Dan apakah itu penyerang membuat permintaan HTTP pada sistem target, yang menghasilkan log menggunakan Log4j 2 Yang menggunakan JNDI untuk membuat permintaan ke situs yang dikendalikan penyerang. Kerentanan tersebut kemudian menyebabkan proses yang dieksploitasi tiba di situs dan mengeksekusi payload. Dalam banyak serangan yang diamati, parameter milik penyerang adalah sistem pendaftaran DNS, yang dimaksudkan untuk mendaftarkan permintaan di situs untuk mengidentifikasi sistem yang rentan.
Seperti yang telah dibagikan oleh rekan kami Isaac:
Kerentanan Log4j ini memungkinkan untuk mengeksploitasi validasi input yang salah ke LDAP, memungkinkan eksekusi kode jarak jauh (RCE), dan membahayakan server (kerahasiaan, integritas data, dan ketersediaan sistem). Selain itu, masalah atau pentingnya kerentanan ini terletak pada jumlah aplikasi dan server yang menggunakannya, termasuk perangkat lunak bisnis dan layanan cloud seperti Apple iCloud, Steam, atau video game populer seperti Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash, dan long dll.
Berbicara tentang masalah ini, baru-baru ini Yayasan Perangkat Lunak Apache dirilis melalui Pos ringkasan proyek yang membahas kerentanan kritis di Log4j 2 yang memungkinkan kode arbitrer berjalan di server.
Proyek Apache berikut terpengaruh: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl, dan Calcite Avatica. Kerentanan juga memengaruhi produk GitHub, termasuk GitHub.com, GitHub Enterprise Cloud, dan GitHub Enterprise Server.
Dalam beberapa hari terakhir telah terjadi peningkatan yang signifikan kegiatan yang terkait dengan eksploitasi kerentanan. Sebagai contoh, Check Point mencatat sekitar 100 upaya eksploitasi per menit di server fiktifnya di puncaknya, dan Sophos mengumumkan penemuan botnet penambangan cryptocurrency baru, yang dibentuk dari sistem dengan kerentanan yang belum ditambal di Log4j 2.
Mengenai informasi yang telah dirilis tentang masalah tersebut:
- Kerentanan telah dikonfirmasi di banyak gambar Docker resmi, termasuk couchbase, elasticsearch, flink, solr, gambar badai, dll.
- Kerentanan hadir dalam produk MongoDB Atlas Search.
- Masalah muncul di berbagai produk Cisco, termasuk Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Pelaporan Keamanan Web Tingkat Lanjut, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, dll.
- Masalahnya ada di IBM WebSphere Application Server dan di produk Red Hat berikut: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse, dan AMQ Streams.
- Masalah yang dikonfirmasi di Platform Manajemen Jaringan Luar Angkasa Junos, Pengontrol / Perencana Northstar, Paragon Insights / Pathfinder / Planner.
- Banyak produk dari Oracle, vmWare, Broadcom, dan Amazon juga terpengaruh.
Proyek Apache yang tidak terpengaruh oleh kerentanan Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper, dan CloudStack.
Pengguna paket bermasalah disarankan untuk segera menginstal pembaruan yang dirilis untuk mereka, perbarui versi Log4j 2 secara terpisah atau setel parameter Log4j2.formatMsgNoLookups ke true (misalnya, menambahkan kunci "-DLog4j2.formatMsgNoLookup = True" saat startup).
Untuk mengunci sistem rentan yang tidak ada akses langsung, disarankan untuk mengeksploitasi vaksin Logout4Shell, yang, melalui komisi serangan, memperlihatkan pengaturan Java "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.objek. trustURLCodebase = false "dan" com.sun.jndi.cosnaming.object.trustURLCodebase = false "untuk memblokir manifestasi lebih lanjut dari kerentanan pada sistem yang tidak terkontrol.