Şimdiye kadar herkes kritik log4j sıfır gününü duydu. ‘Log4Shell’ ve ‘Logjam’ olarak adlandırılan güvenlik açığı interneti ateşe verdi.
Şimdiye kadar, CVE-2021-44228 olarak izlenen log4j güvenlik açığı, her türlü tehdit aktörü tarafından kötüye kullanıldı. devlet destekli hackerlar ile fidye yazılımı çeteleri ve diğerleri Monero madencilerini enjekte et savunmasız sistemlerde.
Log4j kullanımı birçok yazılım ürünü arasında yaygındır ve birden çok satıcı tavsiyeleri beri su yüzüne çıktı. Ve şimdi öyle görünüyor ki, ‘logback’ de o kadar bağışık değil.
Aşağıda, şimdiye kadar tanımlanan çok sayıda ilgili CVE’yi ve log4j sürüm 2.15.0’ı 2.16.0’ın lehine çevirmek için oldukça iyi nedenleri özetliyoruz.
Hangi CVE’ler hakkında endişelenmeliyim?
Her şey geçen Perşembe, 9 Aralık’ta başladı. PoC istismarı kritik Log4j sıfır gün vuruşu için GitHub.
Sonrası güvenlik açığıydı ifşa ve toplu tarama savunmasız sunucuları hedefleyen saldırganların etkinliği.
Log4j’nin Java uygulamalarının çoğunda geniş kullanımı göz önüne alındığında, Log4Shell kısa sürede bir işletmeler ve hükümetler için kabus Dünya çapında.
Aşağıda, ortaya çıktıkları sırayla bilmeniz gereken CVE’ler verilmiştir:
- CVE-2021-44228 [Critical]: Orijinal ‘Log4Shell’ veya ‘logjam’ güvenlik açığı, güvenilmeyen seri durumdan çıkarma kusur. Önem derecesi kritik olarak derecelendirilen bu, 10 puan alır. CVSS ölçeklendirir ve kimliği doğrulanmamış saldırganlara uzaktan kod yürütme (RCE) yetenekleri vererek sistemin tamamının ele geçirilmesine olanak tanır.
Alibaba Bulut Güvenlik Ekibinden Chen Zhaojun tarafından 24 Kasım’da Apache’ye bildirilen CVE-2021-44228, Apache Struts2, Apache Solr, Apache Druid, Apache Flink ve diğerleri dahil olmak üzere birden çok Apache çerçevesinin varsayılan yapılandırmalarını etkiler.
İçlerinde en tehlikelisi olan bu güvenlik açığı, log4j-çekirdek bileşen, 2.x sürümleriyle sınırlıdır: 2.0-beta9’dan 2.14.1’e kadar. Log4Shell için bir düzeltme 2.15.0 sürümünde kullanıma sunuldu, ancak eksik kabul edildi (okumaya devam edin).
Tehdit istihbarat analisti Florian Roth, Sigma kurallarını paylaştı [1, 2] savunmalardan biri olarak kullanılabilir.
- CVE-2021-45046 [Low]: Önem derecesi düşük olan bu, yalnızca 3,7 puan alan bir Hizmet Reddi (DoS) hatasıdır. Hata, CVE-2021-44228 için 2.15.0’a giren eksik bir düzeltmenin sonucu olarak ortaya çıktı. 2.15.0’a uygulanan düzeltme, kusuru büyük ölçüde çözmüş olsa da, varsayılan olmayan bazı yapılandırmalar için durum pek de böyle değildi.
Log4j 2.15.0, JNDI LDAP aramalarını kısıtlamak için “en iyi çabayı” gösteriyor yerel ana bilgisayar varsayılan olarak. Ancak, İş Parçacığı Bağlam Haritası (MDC) giriş verileri üzerinde denetimi olan saldırganlar, DoS saldırılarına neden olmak için JNDI Arama kalıpları aracılığıyla kötü amaçlı yükler oluşturabilir. Bu, bir Bağlam Araması, örneğin $${ctx:loginId} veya bir İş Parçacığı Bağlam Eşlemesi kalıbı (%X, %mdc veya %MDC) kullanan bir varsayılan olmayan Kalıp Düzeninin olduğu varsayılan olmayan konfigürasyonlar için geçerlidir.
NVD danışma belgesi, “Log4j 2.16.0, mesaj arama kalıpları için desteği kaldırarak ve varsayılan olarak JNDI işlevini devre dışı bırakarak bu sorunu düzeltir” diyor. 2.12.1 dalında olanlar için, bir düzeltme 2.12.2’ye geri aktarıldı.
- CVE-2021-4104 [High]: Log4j 2.x sürümlerinin savunmasız olduğunu mu söyledik? Log4j 1.x ne olacak?
Daha önce güvenli olduğu düşünülen Log4Shell, eski Log4j’de de gizlenmenin bir yolunu buldu. Temel olarak, aşağıdakileri kullanan Log4j 1.x örneklerinin varsayılan olmayan yapılandırması: JMSAppender sınıfı da güvenilmeyen seri durumdan çıkarma kusuruna karşı duyarlı hale gelir.
CVE-2021-44228’in daha az şiddetli bir varyantı olmasına rağmen, yine de bu CVE, tüm sürümlerini etkiler. log4j:log4j ve org.apache.log4j:log4j yalnızca 1.x sürümlerinin bulunduğu bileşenler. Çünkü bunlar hayatın sonu sürümlerinde, 1.x şubesi için bir düzeltme hiçbir yerde mevcut değildir ve log4j-çekirdek 2.16.0.
- CVE-2021-42550 [Moderate]: Bu, Logback günlüğü çerçevesindeki bir güvenlik açığıdır. Log4j 1.x kitaplığının halefi olan Logback, “log4j 1.x’in kaldığı yerden” devam ettiğini iddia ediyor.
Geçen haftaya kadar Logback ayrıca övünen “log4j 2.x ile ilgisiz, [logback] güvenlik açıklarını paylaşmıyor.”
CVE-2021-4104’ün Log4j 1.x’i de etkilediği keşfedildiğinde bu varsayım hızla ortadan kalktı ve Logback’e olası etki olasılığı değerlendirildi. Bu daha az ciddi güvenlik açığını ele alan daha yeni Logback sürümleri, 1.3.0-alpha11 ve 1.2.9 artık piyasaya sürülmüş.
- Bir CVE daha…? Okumaya devam et.
Ditch Log4j 2.15: DNS hırsızlığı ve RCE mümkün
Log4j 2.15.0, şimdiye kadar keşfedilenlerden daha ciddi güvenlik açıkları içerebilir, bu nedenle 2.16.0 çok daha güvenli bir bahistir.
Yukarıda açıklanan CVE-2021-45046 nedeniyle, kusurun maksimum etkisi başlangıçta DoS gibi görünüyordu, ancak BleepingComputer, bu varsayımın gelişmekte olduğunu öğrendi.
Bulut güvenlik firması Praetorian, Log4j 2.15.0 sürümlerinin harici ana bilgisayarlardan DNS tabanlı veri sızması için nasıl kötüye kullanılabileceğini gösterdi ve koordineli bir açıklama için Apache ile birlikte çalışıyor.
Praetorian’ın baş güvenlik mühendisi Anthony Weems, BleepingComputer ile yaptığı bir e-posta röportajında araştırmaya daha fazla ışık tutuyor:
“Praetorian Blog yazısı Log4j sürüm 2.15 için geçerli olan CVE-2021-45046’ya yanıttır. CVE açıklaması, belirli bir Model Düzeni türü kullanıldığında bu güvenlik açığının hizmet reddine yol açabileceğini belirtir. Yalnızca DoS olduğunu belirtmelerinin nedeni, yerel ana bilgisayar izin verilenler listesi,” Weems, BleepingComputer’a söyler.
“Bu ‘yerel ana bilgisayar’ izin verilenler listesi için bir atlama geliştirdik ve ayrıntıları Apache’ye gönderdik. En azından bu, CVE-2021-45046’ya karşı savunmasız olan sistemlerin yalnızca DoS’ye karşı savunmasız olmadığı, aynı zamanda potansiyel olarak hassas ortamın DNS exfil’ine karşı da savunmasız olduğu anlamına gelir. değişkenler.”
Praetorian, tam da bunu gösteren bir PoC videosu paylaştı:
“Apache, yazımızın alındığını onayladı; bunun CVE’nin düzenlenmesini mi yoksa yeni bir CVE’yi mi hak ettiği iyi bir sorudur – ancak, her iki durumda da savunucuların yapması gereken eylem açıktır: 2.16.0’a geçmek burada jndi varsayılan olarak devre dışı bırakılması en güvenli eylem şeklidir ve müşterilerimize önerdiğimiz yaklaşımdır,” diye sonlandırdı Praetorian, BleepingComputer’a yaptığı açıklamada.
Ayrıca, yazının yazıldığı sırada, BleepingComputer, 2.15.0 ile bile tam RCE elde etmenin mümkün olduğunu iddia eden birçok güvenlik araştırmacısına rastladı.
“İşte nasıl atlanacağına dair bir PoC izin verilenLdapHost ve izin verilenSınıflar Log4J 2.15.0’da kontrol eder. RCE’ye ulaşmak için… ve baypas etmek için izin verilenSınıflar sadece JDK’da bir sınıf için bir isim seçin. Araştırmacı Márcio Almeida şöyle açıklıyor:
Bunun nedeni, kontrolün nasıl yapıldığıdır. en https://t.co/KrgP5x639Q.URI getHost() yöntemi, gerçek ana bilgisayar olarak #’den önceki değeri döndürür. Ancak JNDI/LDAP çözümleyici, kötü amaçlı LDAP sunucusuna bağlanmaya çalışan tam ana bilgisayar adı dizesini çözecektir. 2/n pic.twitter.com/HuZtYekuHw
— Márcio Almeida (@marcioalm) 17 Aralık 2021
Benzer şekilde GitHub Security Lab’den Alvaro Muñoz, uzaktan kod yürütmeyi sağlamak için 2.15.0’da yapılan düzeltmeleri atlayarak başarıyı paylaştı:
@_atorralba
ve az önce allowLdapHost ve allowClasses kontrollerini atlamayı başardım. 2.15, formatMsgNoLookps azaltıcı özelliği olmadan RCE’ye karşı hala savunmasızdır. 2.15.0 Bu azaltıcı etkenler olmadan yalnızca saldırganlar desen düzeninin mesaj olmayan kısımlarını kontrol edebiliyorsa savunmasızdır– Alvaro Muñoz (@pwntester) 16 Aralık 2021
“Bir not olarak, varsayılan ayarlar etkilenmeyecektir. %m{arama} veya CVE-2021-45046 gibi bir yöntemle” diyor güvenlik araştırmacısı RyotaK, Muñoz’un araştırmasına ekleniyor.
Log4j 2.15.0’dan kaynaklanan olası en kötü senaryo henüz tam olarak belirlenmedi, ancak şunu söylemek yeterli, sadece DoS ile sınırlı görünmüyor.
Durum gelişmeye devam ettikçe, kuruluşlar ve geliştiriciler 2.16.0’a yükseltmeye ve Apache’nin Log4j’sini izlemeye devam etmeye teşvik ediliyor. danışma sayfası güncellemeler için.