BT çalışanlarının Aralık ayı tatil planları, geçen yıl yaygın olarak kullanılan Log4j aracındaki büyük bir açığın ortaya çıkmasının ardından altüst olmuştu. Güvenlik açığının keşfedilmesi, açığı kapatmak için aylarca süren hummalı bir faaliyete yol açtı, ancak bir yıl sonra açık gündemden düştü. Güvenlik uzmanları, tehdidin ortadan kalkmadığını ve sektörün dikkatli olmaması halinde yeniden canlanabileceğini söylüyor.
Log4Shell zafiyeti, Aralık 2021’in başlarında ilk kez ortaya çıktığında, şimdiye kadarki en ciddi güvenlik açıklarından biri olarak tanımlanmıştı. Açık, Java yazılımlarında hataları takip etmeye ve performans sorunlarını teşhis etmeye yardımcı olmak için tasarlanmış popüler bir günlük tutma aracını hedef alıyordu. Geniş kullanım alanı sayesinde Log4j binlerce yazılım paketine yerleştirilmiş olup, Amazon Web Services ve Minecraft video oyunu da dahil olmak üzere çok çeşitli ticari uygulamalarda kullanılmıştır. Dahası, açık, saldırganların savunmasız sistemlerin kontrolünü tamamen ele geçirmesini nispeten kolaylaştırdı.
Bu da açıkları kapatmak için çılgınca bir çabaya yol açtı. Açık kaynaklı yazılımı destekleyen Apache Yazılım Vakfı hızla bir yama yayınladı ve kurumlar aylarca sistemlerini tarayıp yazılımlarını güncelledi. Ancak bir yıldan uzun bir süre sonra, siber güvenlik firması Tenable, kuruluşların yüzde 72’sinin Log4Shell’e karşı savunmasız olduğunu söylüyor. Tenable’da teknik direktör ve güvenlik stratejisti olan Bernard Montel, endişe verici bir şekilde, hatayı düzelten çok sayıda kuruluşun o zamandan beri açığı barındıran yazılımlar yükleyerek hatayı sistemlerine yeniden bulaştırdığını belirtiyor.
2022 Aralık ayında sadece bir günde Log4j açığının keşfedilmesinden bu yana en yüksek günlük saldırı gerçekleşti.
“Yaklaşık bir yıl önce bunu düzeltmek için bir plan geliştirdiklerinde, bunu tamamladıklarını düşündüler” diyor. “Temizlediler, tespit ettiler, taradılar, yazılımlarını yamaladılar ve onlar için yapmaları gerekeni yaptılar. Sadece saldırı yüzeyinin hareket halinde olduğu gerçeğini unuttular.”
Tenable’ın tahminlerine göre geçtiğimiz Aralık ayında her on makineden birinde görülen istismara açık makinelerin oranı, bu Ekim ayı itibariyle sadece yüzde 2,5’e düşmüştür. Ancak bunların üçte biri zaten tamamen yamalanmıştı ve o zamandan beri Log4Shell ile yeniden enfekte oldular. Montel, sorunun bir kısmının Log4j’nin yaygın olarak kullanılan pek çok yazılım kütüphanesinin derinliklerine gömülmüş olması olduğunu söylüyor. Yardımcı programın belirli bir araca dahil olup olmadığı genellikle net değildir ve dahil olsa bile, çoğu geliştirici, özellikle hızlı bir şekilde kod üretme baskısı altında oldukları göz önüne alındığında, en güncel sürüm olup olmadığını kontrol etmek için yeterince güvenlik bilincine sahip değildir, diye ekliyor. Güvenlik firması Sonatype’ın bir yıl önce yaptığı araştırma, Log4j indirmelerinin yüzde 65’inin aracın açığa sahip sürümlerine ait olduğunu ortaya koydu.
Montel ayrıca kurumsal düzeyde, ilk aylarda güvenlik açığı ile başa çıkmak için yapılan büyük baskıdan sonra, insanların sorunu çözdüklerini düşündüklerinde odaklarını kaybetmelerinin neredeyse kaçınılmaz olduğunu düşünüyor. Montel, Covid-19 salgını ile açık benzerlikler olduğunu düşünüyor; karantina gibi sıkı önlemler virüsü hızla kontrol altına almış, ancak işler tekrar rahatladığında virüs yeniden ortaya çıkmıştı. “Bu [Log4j] geri geliyor,” diyor Montel. “Hala orada bir yerde, o yüzden dikkatli olun.”
ABD Ulusal Savunma Bakanlığı’na bağlı Siber Güvenlik İnceleme Kurulu’nun Temmuz ayında yayınladığı bir raporda, bu hatanın “endemik” hale geldiği ve on yıllarca olmasa bile yıllarca sorun olmaya devam edeceği değerlendirmesinde bulunuldu. Güvenlik şirketi Imperva tarafından toplanan veriler, 2022’nin ilk birkaç ayından bu yana hatadan yararlanan saldırıların önemli ölçüde azalmasına rağmen, Kasım ayından bu yana sürekli bir artış olduğunu ve 2022 Aralık ayının 3. gününde, güvenlik açığının keşfedilmesinden bu yana en yüksek günlük saldırıların görüldüğünü göstermiştir.
Potansiyel bir çözüm: kuruluşlar kullandıkları tüm kodlar için bir Yazılım Bileşenleri Listesi talep ederek başlayabilirler.
Imperva bu saldırıların yaklaşık yüzde 7’sinin başarılı olduğunu tahmin ediyor. Ancak Mart ayında Çinli devlet destekli bilgisayar korsanları tarafından yapılanlar ve Kasım ayında bir ABD federal kurumuna yapılan İran saldırısı da dahil olmak üzere bazı yüksek profilli saldırılar olmasına rağmen, açık şu ana kadar geçen yıl yapılan korkunç tahminler kadar gerçekleşmedi. Imperva’da tehdit araştırma analisti olan Gabi Stapel, “Çok sayıda şirket etkilenmiş olsa da, büyük ölçüde beklenenden daha az oldu” diyor. Yine de birçok şirketin, üzerinde çok az kontrol ya da görünürlüğe sahip oldukları üçüncü taraf ve açık kaynak kodlarına ne kadar bağımlı olduğu ortaya çıktı. Stapel, “Tarihsel olarak şirketler, yakın tedarikçi gruplarının ve güvendikleri kritik yazılımların getirdiği risklere odaklandılar” diyor. “Kuruluşların tedarik zincirinin tüm parçalarını içeren bir tehdit yönetim modeline geçmeleri gerekiyor.”
Siber Güvenlik ve Altyapı Güvenliği Ajansı’nda (CISA) siber güvenlikten sorumlu müdür yardımcısı Eric Goldstein, Log4Shell’e yönelik müdahalenin maliyeti ve karmaşıklığının, yazılım tedarik zincirinin güvenliğinin sağlanması ve şeffaflığın artırılması konularına daha fazla odaklanılmasına öncülük ettiğini söylüyor. “Geçtiğimiz yıl yazılım bağımlılıklarını daha iyi anlamaya yardımcı olmak için bir dizi yeni araç, şirket ve ürün ortaya çıktı ve Log4j genellikle yenilik ve benimseme için birincil motivasyon olarak kullanılıyor” diyor.
CISA’nın teşvik ettiği potansiyel çözümlerden biri de Yazılım Bileşenleri Listesi (Software Bill of Materials – SBOM). Bu, bir yazılım uygulamasını oluşturan tüm bileşenlerin bir envanteridir ve geliştiricilerin potansiyel olarak riskli kod parçalarına olan bağımlılıklarını takip etmelerini kolaylaştırmak için tasarlanmıştır. ABD hükümeti, bunların yakında federal kurumlara teslim edilen yazılımlar için bir gereklilik haline gelebileceğinin sinyalini verdi.
Açık Kaynak Güvenlik Vakfı (OSSF) genel müdürü Brian Behlendorf, yaklaşımın gerçekten etkili olabilmesi için daha da ileriye taşınması gerektiğini, böylece geliştiricilerin uygulamaları oluşturmak için bir araya getirdikleri orijinal açık kaynaklı yazılım paketleri veya kütüphanelerin bile kendi SBOM’ları ile birlikte geleceğini söylüyor. Behlendorf’a göre bunu yapmak için bu süreci basitleştiren ve mevcut yazılım oluşturma araçlarına dahil eden yeni araçlara ihtiyaç duyulabilir çünkü “geliştiricilerin fazladan çaba harcamasını sağlamak zor olabilir”.
Sektörün bir bütün olarak daha iyi koordine olması ve güvendiği açık kaynak araçlarının güvenliğini sağlama konusunda daha proaktif olması gerektiğini söylüyor. Behlendorf, her bir projenin kod incelemeleri gibi şeyleri yapacak mali gücü ya da insan gücü olmadığını söylüyor. “Ekosistemin elde edeceği değer ile bu tür kaynakları bir araya getirme becerisi arasında bir kopukluk var” diyor. “İhtiyacımız olan şey, bu tür şeylerin daha iyi incelenmesine yönelik talebi bir araya getirebilecek ve kaynakları hedefe yönelik, kolay ulaşılabilir konulara kanalize edebilecek kurumlar.”
Bu nedenle Mayıs ayında OSSF ve Linux Vakfı, az miktarda yatırımın Log4Shell gibi güvenlik açıkları riskini önemli ölçüde azaltabileceği on alanı vurgulayan bir Açık Kaynak Yazılım Güvenliği Seferberlik Planı açıkladı. Bunlar arasında geliştiriciler için daha iyi güvenlik eğitimi, yetersiz kaynaklara sahip açık kaynak ekiplerinin güvenlik açıklarına tepki vermesine yardımcı olmak için bir OSSF olay müdahale ekibinin kurulması ve en kritik 200 açık kaynak yazılım bileşeninin yıllık kod incelemeleri gibi şeyler yer alıyor.
Behlendorf, bunun hayata geçirilmesi için hem endüstri hem de hükümetten önemli miktarda fon sağlanması gerekeceğini söylüyor. Ancak bunun akıllıca bir yatırım olacağını ve eğer bu tür bir koordinasyon olmazsa, bir sonraki Log4j’nin ortaya çıkmasının uzun sürmeyeceğini söylüyor.
Kaynak:
Yorum yazabilmek için oturum açmalısınız.