İçindekiler[Saklamak][Göstermek]
Bir internet güvenlik açığı olan Log4Shell, son zamanlarda milyonlarca makineyi etkiledi. Belirsiz ancak neredeyse her yerde bulunan bir yazılım parçası olan Log4j buna neden olur.
Log4j, çeşitli bilgisayar sistemlerinde perde arkasında gerçekleşen tüm eylemleri günlüğe kaydetmek için kullanılır.
Çoğu uygulamada işletmeler ve hatta devlet kurumları tarafından kullanılan açık kaynaklı bir günlük kitaplığına dayanmaktadır.
Şimdiye kadar ortaya çıkarılan en kötü siber güvenlik açıklarından biri olarak, sistemlerinizi bu güvenlik açığından korumak çok önemlidir. Ama nasıl?
Log4j güvenlik açığını ve bunun için olası tüm düzeltme çözümlerini ayrıntılı olarak inceleyelim.
Log4j nedir?
Log4j bir açık kaynak yazılım geliştiricilerin uygulamalarında farklı verileri kaydetmelerini sağlayan günlük kaydı çerçevesi. tarafından yürütülen Apache Logging Services projesinin bir bileşenidir. Apache Yazılım Vakfı.
Yüzlerce web sitesi ve uygulama, hata ayıklama ve diğer kullanımlar için verileri günlüğe kaydetme gibi kritik işlemleri gerçekleştirmek için Log4j'yi kullanır.
Kötü bir çevrimiçi bağlantıya girdiğinizde veya tıkladığınızda ve bir 404 hata bildirimi aldığınızda, bu Log4j'nin iş başında sık görülen bir örneğidir. Erişmeye çalıştığınız web bağlantısının etki alanını çalıştıran web sunucusu, böyle bir web sayfasının bulunmadığını size bildirir. Ayrıca sunucunun sistem yöneticileri için olayı Log4j'de günlüğe kaydeder.
Yazılım programları boyunca benzer tanılama sinyalleri kullanılır. Örneğin çevrimiçi Minecraft oyununda sunucu, kullanılan toplam RAM ve konsola gönderilen kullanıcı talimatları gibi etkinlikleri günlüğe kaydetmek için Log4j'yi kullanır.
Güvenlik açığı nasıl oluşur?
Aramalar, Log4j 2.0'da tanıtılan ve günlük girişlerine ek bilgilerin eklenmesine yardımcı olan yeni bir özelliktir. Bu aramalardan biri, bir dizin hizmetiyle iletişim kurmak için bir Java API'si olan JNDI (Java Adlandırma ve Dizin Arayüzü) aramasıdır.
Bu yaklaşımı kullanarak, dahili kullanıcı kimlikleri gerçek kullanıcı adlarıyla eşlenebilir. LDAP sunucusu tarafından sağlanan veri türlerinden biri, daha sonra belleğe yüklenen ve Log4j örneği tarafından çalıştırılan bir Java sınıfını işaret eden bir URI olduğundan, bu sorgu yeni keşfedilen RCE güvenlik açığını ortaya çıkarır.
Log4j kitaplığının giriş doğrulamasındaki bir zayıflık nedeniyle, güvenilmeyen bir kaynaktan rastgele bir LDAP sunucusu enjekte etmek mümkündür. Geliştiriciler, günlüklere gönderilen verilerin düz metin olarak ele alınacağını varsaydığından, fazladan giriş doğrulaması yapılmaz ve günlüklere tehlikeli kullanıcı girişi girer.
Bir günlük ifadesi şöyle görünebilir:
Kötü niyetli bir kullanıcı artık bir URL parametresine sahte bir LDAP sunucusuna atıfta bulunan bir JNDI araması ekler. JNDI araması aşağıdaki gibi olacaktır:
Log4j kitaplığı daha sonra, Java Factory ve Java Codebase için değerler de dahil olmak üzere dizin bilgilerini almak için attacker.com'daki bu LDAP sunucusuyla konuşur.
Bu iki değer, saldırganın daha sonra belleğe yüklenen ve Log4j örneği tarafından yürütülen ve kod yürütmesini tamamlayan Java sınıfını içerir.
Kimler risk altında?
Log4j güvenlik açığı inanılmaz derecede geniştir ve iş uygulamalarını, gömülü cihazları ve bunların alt sistemlerini etkiler. Etkilenen uygulamalar arasında Cisco Webex, Minecraft ve FileZilla FTP bulunur.
Ancak, bu hiçbir şekilde tam bir liste değildir. Kusur, olay kaydı için Apache Log2020j kullanan Ingenuity Mars 4 helikopter görevini bile etkiliyor.
Güvenlik topluluğu bir derleme yaptı savunmasız sistemler listesi. Bu listelerin sürekli olarak güncellendiğini unutmamak çok önemlidir, bu nedenle belirli bir program veya sistem öne çıkarılmamışsa, etkilenmediğini varsaymayın.
Bu güvenlik açığına maruz kalma oldukça olasıdır ve belirli bir teknoloji yığını Java uygulamazsa, güvenlik yöneticileri kritik tedarikçi sistemleri, SaaS tedarikçileri, bulut barındırma sağlayıcıları ve web sunucusu sağlayıcılarının bunu yapmasını beklemelidir.
Log4j güvenlik açığı nasıl kontrol edilir?
İlk adım, bir saldırının daha önce gerçekleşip gerçekleşmediğini belirlemektir. Bunu, RCE yük parçaları için sistem günlüklerini kontrol ederek yapabilirsiniz.
"jndi", "ldap" veya "$::" gibi terimler için yapılan arama herhangi bir günlük verirse, güvenlik araştırmacıları bunun meşru bir saldırı mı yoksa yalnızca parmak izi mi olduğunu görmek için daha fazla araştırma yapmalıdır.
Vahşi doğada herhangi bir zararlı yük sağlamayan birçok saldırı keşfedildi. Bununla birlikte, kaç uygulamanın bu saldırıya karşı savunmasız olduğunu belirlemek için güvenlik uzmanları tarafından gerçekleştirildi.
Sonraki adım, tüm projeleri tanımlamak için Log4j kitaplığını kullanmaktır. 2.0-beta9 ve 2.14.1 arasındaki sürümler kullanılıyorsa, proje etkilenebilir.
Bu güvenlik açığının nerede olduğunu belirlemenin zorluğu göz önüne alındığında, projenin duyarlı olduğunu ve kod yürütme tehlikesini ortadan kaldırmak için kitaplığı güncellemenin en iyi eylem planı olduğunu varsaymak tercih edilebilir.
2.0.x aralığındaki sürümler eski olduğundan ve artık güncelleme almadığından Log9j kitaplığının hala yükseltilmesi gerekmesine rağmen, kullanılan sürüm 4-beta 1'dan düşükse proje savunmasız değildir.
Hassas bir proje bulunup bulunmadığına bakılmaksızın, Log4j kullanılarak kaydedilen herhangi bir bilginin kullanıcının değiştirebileceği bilgiler içerip içermediğinin kontrol edilmesi tavsiye edilir. URL'ler, istek parametreleri, başlıklar ve tanımlama bilgileri bu verilere örnektir. Bunlardan biri günlüğe kaydedilirse, proje tehlikeye girer.
Bu bilgi, sistem günlüklerini daha ayrıntılı incelemenize ve web uygulamanızın saldırıya uğrayıp uğramadığını belirlemenize yardımcı olabilir.
Bir web uygulamasının savunmasız olup olmadığını tespit edebilen ücretsiz çevrimiçi araçlar vardır. Bu programlardan biri Log4Shell avcısı. Açık kaynak kodludur ve şurada mevcuttur: GitHub.
Çevrimiçi uygulamada savunmasız bir kod alanı keşfedilirse, açıklanan araç tarafından sağlanan yük, onu web uygulamasına enjekte etmek için kullanılabilir. Test aracı, güvenlik açığından yararlanılması durumunda web uygulamanız ile LDAP sunucusu arasında yapılan bağlantıları ortaya çıkaracaktır.
Log4j güvenlik açığını gidermek için çözümler
İlk adım, normal paket yöneticilerini kullanarak veya doğrudan buradan indirerek yapabileceğiniz Log4j'yi güncellemektir. Kanal.
FORMAT MSG NO LOOUPS ortam değişkenini true olarak ayarlayarak güvenlik açığından yararlanılabilirliği azaltmak da mümkündür. Ancak bu önlem, yalnızca 4'a eşit veya daha büyük Log2.10j sürümleri için geçerlidir.
Şimdi alternatif seçenekleri ele alalım.
1. Log4j sürüm 2.17.0 için geçici çözümler
Log4Shell'e karşı koruma sağlamak için Log2.15.0j 4 sürümünün kullanılması kesinlikle tavsiye edilir, ancak bu mümkün değilse başka çözümler de mevcuttur.
Log2.7.0j'nin 4 ve sonraki sürümleri: Kullanıcı tarafından sağlanan veriler için yüzde m nolookups sözdizimi kullanılarak günlüğe kaydedilecek olayların biçimini değiştirerek herhangi bir saldırıya karşı koruma sağlamak mümkündür. Bu güncelleme, programın yeni bir sürümünü oluşturmak için Log4j yapılandırma dosyasının düzenlenmesini gerektirir. Sonuç olarak, bu yeni sürümü dağıtmadan önce teknik ve işlevsel doğrulama aşamaları tekrarlanmalıdır.
Log4j 2.10.0 ve sonraki sürümleri: Örneğin, Java sanal makinesini -Dlog4j2 seçeneğiyle başlatırken log4j2.formatMsgNoLookps yapılandırma parametresini true olarak ayarlayarak herhangi bir saldırıya karşı koruma sağlamak da mümkündür.” formatMsgNoLookups = true, Başka bir seçenek de, ana saldırı vektörünü kaldıracak olan sınıf yolu argümanından JndiLookup sınıfını çıkarmaktır (araştırmacılar başka bir saldırı vektörü olasılığını dışlamazlar).
Amazon Web Services, "risk size ait olmak üzere kullanılması gereken" bir hotpatch sağlar. “Bu güvenlik açığını kendisine karşı kullanan” Logout4Shell gibi diğer “teknikler” yayınlandı. Güvenlik uzmanı, "düzeltmek için bir makineyi hacklemeyi" içeren bu hareketin yasallığını sorguluyor.
2. Log4j v2.17.0'da sorun çözüldü.
2.10'dan büyük sürümler için: Log4j2.formatMsgNoLookps true olarak ayarlanmalıdır.
2.0 ile 2.10.0 arasındaki sürümler için: LDAP sınıfını Log4j'den kaldırmak için aşağıdaki komutu çalıştırın.
Log4j2.formatMsgNoLookps sistem ayarlarında true olarak ayarlanmalıdır.
JVM'de Azaltma
JVM parametreleriyle azaltma artık bir seçenek değil. Diğer hafifletme yöntemleri başarılı olmaya devam ediyor. Mümkünse Log4j 2.17.0 sürümüne yükseltin. Log4j v1 için bir geçiş kılavuzu mevcuttur.
Güncelleme mümkün değilse, istemci tarafı ve sunucu tarafı bileşenlerinin -Dlog4j2.formatMsgNoLookps = true sistem özelliğinin ayarlanmış olduğundan emin olun.
Lütfen Log4j v1'in kullanım ömrünün sonuna (EOL) ulaştığını ve artık hata düzeltmeleri almayacağını unutmayın. Diğer RCE vektörleri de Log4j v1'e karşı hassastır. Bu nedenle, mümkün olan en kısa sürede Log4j 2.17.0'a yükseltmenizi öneririz.
3. Etki azaltma önlemleri
Mevcut istismarlar, ana makinenin 4u6, 212u7, 202u8 veya 192'den daha yüksek bir Java sürümünü çalıştırıyor olması gibi bazı durumlarda Log11.0.2j duyarlı olsa bile çalışamaz.
Bunun nedeni, saldırının çalışması için gerekli olan mevcut sürümlerde daha iyi Java Adlandırma ve Dizin Arabirimi (JNDI) uzaktan sınıf yükleme korumasıdır.
Ayrıca, 4'dan büyük Log2.10j sürümleriyle, formatMsgNoLookups sistem değerini true olarak ayarlayarak, JVM argümanı -Dlog4j2.formatMsgNoLookups = true sağlayarak veya JndiLookup sınıfını sınıf yolundan silerek sorun önlenebilir.
Bu arada, güvenlik açığı bulunan örnekler düzeltilene kadar aşağıdaki teknikler kullanılarak güvenlik açığı giderilebilir:
- >=4 için sistem özelliğini log2j2.10.formatMsgNoLookps true olarak ayarlayın.
- LOG4J FORMAT MSG NO LOOUPS ortam seçeneğini >=2.10 için true olarak ayarlayın.
- 2.0-beta9 - 2.10.0 için sınıf yolundan JndiLookup.class'ı kaldırın: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Önerilen en iyi uygulamalardan biri, internete çıkış trafiğini yalnızca uygun bağlantı noktalarıyla sınırlamaktır.
Alandaki saldırıların çoğu HTTP üzerinden gerçekleştirilse de, güvenlik açığı, Log4j kullanarak kullanıcı giriş verilerini günlüğe kaydeden herhangi bir protokol aracılığıyla kullanılabilir.
Ancak log4j 2.17.0'a güncellemek en iyi çözümdür çünkü birisi soruna ek bir yaklaşım keşfedebilir. Ayrıca, birçok yayıncı ve üretici, hizmetlerinde veya uygulamalarında iyileştirmeler yaptığını duyurdu.
4. Log4Shell güvenlik açığı yaması
Log4j, özellikle şimdi güvenlik açığından yararlanıldığı için her yerde mevcuttur. Özetlemek gerekirse Log4j tarafından incelenen loglara aşağıdaki karakterleri eklemeniz yeterlidir.
Ve bu, URL'nin sonunda bulunan Java dosyasını indirecek ve yürütecektir. Dramatik olduğu kadar basit.
Bildiğiniz gibi, bu Log4Shell güvenlik açığını (CVE-2.17.0-4) gidermek için log2021j'yi >= 44228 sürümüne yükseltmek çok önemlidir.
Bu mümkün değilse:
Log4j kitaplığı 2.10.0 ve sonraki sürümlerini kullanan uygulamalar için, örneğin Java sanal makinesini -Dlog4j2.formatMsgNoLookps = true ile başlatırken log4j2.formatMsgNoLookps yapılandırma parametresini true olarak ayarlayarak herhangi bir saldırıya karşı koruma sağlamak da mümkündür. seçenek.
Başka bir seçenek de, birincil saldırı vektörünü kaldıracak olan sınıf yolu argümanından JndiLookup sınıfını silmektir (araştırmacılar başka bir saldırı vektörünün varlığını ekarte etmezler).
not
Duyarlı sistemlerde ayarlamalar yapmakta tereddüt eden veya isteksiz olan (veya ekstra güvenlik önlemleri kurmak isteyen ancak isteyen) kuruluşlar şunları düşünmelidir:
- Tüm trafiğin bir iSensor/WAF/IPS. Bu, saldırının sisteme erişmesini engelleyebilir.
- Hassas sisteme ulaşabilecek trafik miktarını sınırlama Sistemin internete bağlı olması gerekmiyorsa, erişimi yalnızca gerekli ve güvenilir IPS ve aralıklarla sınırlayın.
- Ana bilgisayarın yetkili giden trafiğini azaltmak. Bu saldırı sahte bir sunucuya bağlanarak çalıştığından, tüm gereksiz IP adresleri ve bağlantı noktaları bir güvenlik duvarında engellenmelidir.
- Hizmet artık gerekli değilse, bir düzeltme hazır olana kadar devre dışı bırakılmalıdır.
Sonuç
Log4j kusurları topluluğumuzu şok etti ve hepimize açık kaynaklı yazılımlara ne kadar bağımlı olduğumuzu hatırlattı.
Log4j benzersizdir. Ne bir işletim sistemidir, ne bir tarayıcıdır, ne de bir yazılımdır. Bunun yerine, programcıların kitaplık, paket veya kod modülü olarak adlandırdıkları şeydir. Sadece bir amaca hizmet eder, yani bir sunucuda neler olduğunun kaydını tutmak.
Kod yazan kişiler, yazılımlarını farklı kılan şeylere odaklanmayı tercih ederler. Tekerleği yeniden icat etmekle ilgilenmiyorlar. Sonuç olarak, Log4j gibi çok sayıda mevcut kod kitaplığına güvenirler.
Log4j modülü, en yaygın olarak kullanılan web sunucusu yazılımı olan Apache'den türetilmiştir. Bu yüzden milyonlarca sunucuda keşfedilebilir. Bu nedenle, güvenlik tehditleri artıyor.
Umarım yukarıdaki çözümler cihazlarınızı güvende tutmanıza yardımcı olur.
Teknoloji dünyasından daha fazla yararlı bilgi için HashDork'ta bizi izlemeye devam edin.
Yorum bırak