Yazılım testi herkesin bildiği gibi zordur. Temel nedenlerin neden olduğu CVE’leri Google’da arayın CRLF (yeni satır karakteri) sorunları ve göreceksiniz binlerce giriş. İnsanlık aya bir adam gönderdi, ancak hala metin dosyalarındaki satır sonlarını işlemenin uygun bir yolunu bulamadık. Programcıların gözden kaçırmaya meyilli olduğu ince köşe vakalarıdır.
Log4j’nin doğasında bulunan karmaşıklık, bu zorluğu yeni bir düzeye taşıyor. bu Log4Shell güvenlik açığı (CVE-2021-44228), sekiz yıl sonra sıfır gün olarak istismar edilene kadar fark edilmeden 2013’ten beri var. Log4Shell güvenlik açığını sektörü sarsmadan önce keşfetmek için hangi araçlar kullanılabilirdi? Hâlâ bilinmezken bu tür güvenlik açıklarının otomatik olarak algılanmasını beklemek gerçekçi midir? Öyleyse, Log4j gibi yoğun bir şekilde test edilmiş bir modül nasıl oldu da tüm savunma hatlarından kaçtı?
Sıfır Gün Güvenlik Açığı Tespit Mücadelesi
Geri görüş 20/20’dir. Günlüğe kaydetme API işlevlerinin sonunda kullanıcı tarafından kontrol edilen verileri alacağı ve JNDI enjeksiyonlarının büyük bir endişe kaynağı olduğu, ancak Log4Shell’in keşfinden önce, her iki gerçek de o kadar açık değildi. İlk gerçek için, uygulama ve kütüphaneler arasındaki girdileri doğrulama sorumluluğunun ayrımı iyi tanımlanmamıştır ve saldırı yüzeyinin kesin tanımı belirsizdir. İkincisi için, her ne kadar JNDI enjeksiyonlar Birkaç yıldır biliniyordu, potansiyel ciddiyet farkındalığı yoktu.
Bu nedenle, muhtemelen CVE-2021-44228 veya benzeri güvenlik açıklarını istismar edilmeden önce tespit etmenin önündeki en büyük engel, tehdit parametrelerinin belirsizliğidir. Güvenilebilecek veya güvenilemeyecek değerlerin veya bunlar üzerinde gerçekleştirilebilecek veya gerçekleştirilemeyecek işlemlerin mutlak ve eksiksiz bir tanımı yoktur. Uygulamada, herhangi bir tehdit analizi, bu gri alanların yorumlanmasına bağlı olacaktır.
Gereksinimler belirsiz olduğunda, geliştiriciler dezavantajlıdır. Büyük bir yazılım modülünün davranışında “yanlış bir şey” olup olmadığını kontrol etmek için güvenlik odaklı bir kod incelemesi bunaltıcıdır. Onlarca işlev çağrısıyla ayrılmış bir programın farklı bölümleri arasındaki ilişkileri kavramak mümkün olmadığından, gözden geçirenler yerel hataları aramaya eğilimlidirler. Tam tersine, bir saldırgan için özel Güvenlik açığından yararlanmak için kodda mevcut olduğundan şüpheleniliyorsa, görev çok daha yönetilebilirdir.
Otomatik Sıfır Gün Güvenlik Açığı Tespiti — Çalışabilir mi?
adı verilen dinamik analiz tekniği bulanık rastgele (veya sözde rastgele) girdiler üzerinde bir program yürüterek ve çöktüğü veya bazı iddiaları ihlal ettiği durumları arayarak bilinmeyen güvenlik açıklarını tanımlar. Log4j durumunda fuzzing yardımcı olur mu? Muhtemelen değil.
Bulanıklaştırma genellikle bellek bozulmasını gösteren çökmeleri aramayı içerir. Bellek açısından güvenli olan Java bağlamında, çökmelerin genellikle ciddi güvenlik etkileri olmaz.
Anlamlı bulanıklaştırma için, sorunlu davranışı gösteren belirli mantıksal koşullara özel kancalara ihtiyacınız vardır. Ek olarak, girdi sağlamak için bir fuzzing koşum takımı oluşturmanız gerekir (bizim durumumuzda Log4j API işlevlerine). Her iki yapı da biraz manuel çaba gerektirebilir. Bu kurulumdan sonra, fuzzing kullanılabilir Bu hatayı, hatta gerekli kancalar ve kablo demeti yeterince benzerse diğer yazılımlardaki benzer hataları tespit etmek için. Bununla birlikte, manuel kod incelemesi durumunda olduğu gibi, gereksinimlerin belirsizliği ve farklı varsayımları denemekle ilgili manuel çaba, büyük olasılıkla Log4j’nin fuzz testinde de gözden kaçırılmasına yol açacaktır.
Bu bizi, uygulamayı gerçekten yürütmeden programın olası davranışlarını inceleyen statik analiz denen son tekniğimize götürür. Statik analizin özel bir ilginç biçimi, veri akışı analizi — programdaki veri kaynaklarından veri havuzlarına kadar olası veri yollarını izlemek. Bu durumda, bir Log4j API işlevleri argümanından başlayan ve JNDI aramasına ulaşan bir veri yolunun varlığı, istismar edilebilir bir güvenlik açığını gösterir.
Modern bir prosedürler arası statik analizör, log4j’yi bir dizi önceden belirlenmiş havuzla veya onsuz analiz ederken birkaç problemle karşılaşacaktır.
Statik Analiz Yoluyla Sıfır Gün Tespiti — Daha Derin Bir Bakış
Aşağıdaki kod parçacığında, alınan log4j-2.14.1-çekirdek, LogEvent nesne (e) alanlarından birinde kullanıcı tarafından kontrol edilen dizeyi içerir. Bu, statik analizöre gönderilen bir sinyaldir. e daha fazla izlenmelidir. Appender arabiriminde, appender.append( içinde çağrılan 20’den fazla uygulama vardır.e). Statik çözümleyici, orada hangi uygulamanın kullanıldığını kesin olarak nasıl biliyor?
Öyle değil! Yapamaz. Göre durma sorunuçalışma zamanı sırasında gerçekte hangi kod yolunun alınacağını statik olarak belirlemek kelimenin tam anlamıyla yapılamaz.
Ne olmuş olabilmek analizör yapar mı? Fazla yaklaşabilir. Kodunuzda tehlikeli kod yolları bulunduğunda, kodunuz “tehlikeli” olarak bildirilecektir. Ve ön kapınızı gece boyunca açık tutmanın birinin akıllı TV’nizi çalacağını garanti etmemesi gibi, statik analizör de “ön kapınızı kilitleyin daha iyi”ye eşdeğer bir şey söyleyecektir.
Statik analizörlerin doğasında var olan aşırı yaklaşım, onların gerçek hayattaki koda ölçeklenmesine olanak tanır. Döngüleri düşünün. Dinamik yöntemler kaçınılmaz olarak döngülerin ardışık yinelemelerini ayrı ayrı keşfedecektir. Bu, kelimenin tam anlamıyla, kapsanacak durumların sayısının sonsuz olduğu anlamına gelir. Özetle, statik analizörler, 0,1,2, … yinelemelerin etkilerini göz önünde bulundurarak bir döngünün etkisini özetleyecektir. kombine.
Statik analizörlerin en büyük dezavantajı, kesinlik eksikliğidir – başka bir deyişle, yanlış pozitiflerdir. Statik analizörler, uygulanabilir olmayanlar da dahil olmak üzere birçok kod yolunun etkilerini bir araya getirdiğinden, kullanıcılar, hatanın tam yerini tespit edebilen dinamik analiz yöntemlerinin aksine, sayısız sahte kod yolu ile karşı karşıya kalırlar.
Etkileşimde Geçiş
Daha fazla şirket kullanıyor güvenlik odaklı statik analiz onların gelişim döngüsünde. Statik analiz araçları, geliştiricilere IDE entegrasyonu yoluyla kod yazarken giderek daha fazla rehberlik sağlıyor. Ancak, yukarıda açıklanan zorluk nedeniyle, mevcut araçların çoğu, uygun havuz tanımları olmadan veri yolu analizleri gerçekleştirmeyi “reddeder”. Hatta ile birlikte açık bir dizi önceden tanımlanmış havuz, sayısız yanlış pozitif var – ne olacağını hayal edin olmadan
onlara.
Endüstri, geliştiricilere kod yazarken kullanıcı girdilerinden kaynaklanan potansiyel riskler hakkında bilgi veren bir araç olan daha “etkileşimli” türde bir statik analiz cihazına doğru hareket etmelidir. Bu esnek yaklaşım, sıfırıncı gün tespitinde oyunun kurallarını değiştirebilir.
Kullanıcı kontrollü giriş noktalarının tanımı genellikle bir programın API’si ile elde edilebilirken, kullanıcı kontrollü girdi kullanan tehlikeli kod havuzlarını tanımlamak daha zordur. Sıfır gün tespiti için bu daha da doğrudur. Geliştiriciler her zaman hangi güvenlik uyarı sinyallerini arayacaklarını bilemezler, ancak sanal parmağını kullanıcı kontrollü girişe koyan otomatik bir yardımcı yardımcı olabilir. Bunu başarmak için, “sola kaydırma” statik analiz eklentileri biçiminde etkileşimli IDE desteğini savunuyoruz.
Veri akışı statik analizi, geliştiricilerin Log4Shell gibi manipüle edilmiş kullanıcı girdilerini içeren güvenlik açıklarını erkenden belirlemesine olanak tanır. Şu anda bir aktif güvenlik araştırması alanıancak teknolojiyi endüstride yaygınlaştırmak herkesin hedefi olmalıdır.