Güvenlik açıkları tartışmasını yararlı kılmak için ne gerekiyor? Ve bu 2022’de nerede yanlış gitti?
Bu gibi durumlarda, güvenlik topluluğu kendisini büyük bir deniz değişikliğine hazırlarken, bunun yerine aldığı şey bir dalgalanmadır. Geçen yılın en büyük yanlış iletişimlerinden ve güvenlik açıklarındaki hatalardan bazılarını burada bulabilirsiniz.
1. “Kurtlanabilir”
Bir bütün olarak güvenlik topluluğunun omurgasını ürperten güvenlik açıkları için bazı nitelikler vardır. Virüslü bir sistemin aktif bir kaynak olarak diğer sistemlere bulaşmasına katkıda bulunma olasılığı olduğunda “kurtlanabilir” bir güvenlik açığı kullanılır. Bu, bir enfeksiyonun büyüme potansiyelini üstel hale getirir. “WannaCry benzeri oranlar” ifadesinin ne kadar kötüye gidebileceğine dair bir uyarı olarak kullanıldığını sık sık görürsünüz.
Bu da bizi ilk örneğimize getiriyor: CVSS derecesi 9,8 olan bir Windows TCP/IP Uzaktan Kod Yürütme (RCE) güvenlik açığı olan CVE-2022-34718. Güvenlik açığı, kimliği doğrulanmamış bir saldırganın, kullanıcı etkileşimi olmadan etkilenen sistemlerde yükseltilmiş ayrıcalıklarla kod yürütmesine izin verebilirdi, bu da onu “kurtulabilir” hale getirir, ancak sonunda, yalnızca IPv6 ve IPSec içeren sistemleri etkilediği için o kadar da kötü olmadığı ortaya çıktı. etkinleştirildi ve güvenlik açığının derinlemesine bir analizi genel olarak ifşa edilmeden önce yama uygulandı.
2. Temel yapı taşları
Zor yoldan öğrendiğimiz bir şey de, diğer birçok uygulamanın güvendiği, gönüllüler tarafından yönetilen çok popüler kitaplıkların olduğudur. Kitaplık, işlemler arasında paylaşılabilen bir dizi kaynaktır. Genellikle bu kaynaklar, yazılımın koduna dahil edilmeleri gerekmediğinden ihtiyaç duyulduğunda çağrılabilecek belirli bir amaca yönelik belirli işlevlerdir. Oldukça fazla hasara neden olan böyle bir kitaplığın en önemli örneği Log4j idi.
Bu nedenle, OpenSSL, OpenSSL’deki kritik bir sorun için bir düzeltme duyurduğunda, herkes OpenSSL’nin kritik bir güvenlik açığını son kez düzelttiğinde, bu güvenlik açığının Heartbleed olarak bilindiğini hatırladı. Heartbleed güvenlik açığı 2014 yılında keşfedildi ve yamalandı, ancak virüslü sistemler yıllarca ortaya çıkmaya devam etti.
Ancak, daha yeni OpenSSL sorunu için yama çıktığında, hatanın önem derecesinin düşürüldüğü ortaya çıktı. Bu her yönden iyi bir haberdi: İki güvenlik açığı için yama mevcut ve duyurulan güvenlik açığı beklediğimiz kadar şiddetli değildi. Ve tur yapan güvenlik açıkları için bilinen bir istismar yoktur.
3. Sıfır gün
Sıfır gün terimi için farklı yorumlar da kafa karıştırıcı olma eğilimindedir.
En çok kabul gören tanım:
“Sıfır gün, kusuru yamalamaktan veya başka bir şekilde düzeltmekten sorumlu taraf veya taraflarca bilinmeyen bir yazılım, donanım veya bellenim kusurudur.”
Ancak, yama yapmaktan veya kusuru başka bir şekilde düzeltmekten sorumlu taraf veya taraflar güvenlik açığının farkında olsalar bile, yama henüz mevcut olmadığı için sıfır gün denen bir şeyi neredeyse sıklıkla göreceksiniz. Örneğin, Microsoft şu tanımı kullanır:
“Sıfır gün güvenlik açığı, resmi yama veya güvenlik güncellemesi yayınlanmamış bir yazılım hatasıdır. Bir yazılım satıcısı bu güvenlik açığından haberdar olabilir veya olmayabilir ve bu risk hakkında halka açık hiçbir bilgi mevcut değildir.”
Fark önemlidir. Bir güvenlik açığının var olduğu gerçeği, neredeyse tüm karmaşık platformlar veya yazılımlar için geçerlidir. Bir risk haline gelmeden önce birinin böyle bir güvenlik açığı bulması gerekir. Daha sonra, bir tehdide dönüşüp dönüşmeyeceği araştırmacının kusuru bulmasına bağlıdır. Araştırmacı sorumlu açıklama kurallarına uyarsa, satıcı kusurun varlığından herkesten önce haberdar edilecek ve satıcı, herhangi bir kötü niyetli aktör bunu öğrenmeden önce hata için bir düzeltme bulup yayınlama şansına sahip olacaktır. .
Bu nedenle, bir güvenlik açığının endişe verici olması için, vahşi ortamda kullanılması gerektiğini veya halka açık bir Kavram Kanıtı olması gerektiğini savunuyorum. önceki yama yayınlandı.
Bunun nerede yanlış gittiğine bir örnek olarak, WhatsApp’taki bir dizi kritik RCE güvenlik açığı, daha iyi bilmesi gerekenler de dahil olmak üzere birçok kuruluş tarafından sıfır gün olarak belirlendi. CVE-2022-36934 ve CVE-2022-27492 olarak listelenen güvenlik açıkları, WhatsApp iç güvenlik ekibi tarafından bulundu ve sessizce düzeltildi, bu nedenle hiçbir kullanıcı için gerçek bir risk oluşturmadı. Evet, tehdit aktörleri güvenlik açıklarını WhatsApp ekibinden önce bulsaydı, sonuçlar felaket olurdu, ancak bu güvenlik açıklarından yararlanıldığına dair hiçbir belirti yoktu.
4. Spring4Shell
Genel olarak açıklanan bilgisayar güvenlik kusurları, Ortak Güvenlik Açıkları ve Etkilenmeler (CVE) veritabanında ayrı bir sayı olarak listelenir. CVE numaraları, benzersiz oldukları ve birçok güvenilir kaynakta kullanıldıkları için çok faydalıdır, bu nedenle belirli bir güvenlik açığı hakkında birçok bilgi bulmayı kolaylaştırırlar. Ama hatırlamaları zor (en azından benim için). Güvenlik açığı adları için Log4Shell, Heartbleed ve Meltdown/Spectre gibi süslü adlar ve logolar bulmak, bunları birbirinden ayırmamıza yardımcı olur.
Ancak güvenlik uzmanlarının kendileri aynı çerçevedeki farklı güvenlik açıklarını karıştırmaya başladıklarında ve araştırmacılar, bilginin zaten dışarıda olduğunu düşündükleri için yama uygulanmamış bir güvenlik açığıyla ilgili ayrıntıları açıkladığında ciddi sorunlar ortaya çıkabilir.
Mart ayında, internette iki RCE güvenlik açığı tartışılıyordu. Onlar hakkında konuşan insanların çoğu, “Spring4Shell” (CVE-2022-22965) hakkında konuştuklarını sanıyordu, ancak gerçekte CVE-2022-22963’ü tartışıyorlardı. Stresi artırmak için Çinli bir araştırmacı, güvenlik açığı bulunan Spring Framework geliştiricisi bir yama bulamadan güvenlik açığıyla ilgili ayrıntıları zamanından önce ortaya çıkardı. Bunun nedeni, iki güvenlik açığı hakkındaki kafa karışıklığı olabilir.
Sonunda, Spring4Shell, kullanıma hazır bir kurulum için değil, yalnızca belirli yapılandırmalar için çalışarak fiyaskoyla sonuçlandı.
Kamu hizmeti mi değil mi?
Öyleyse, güvenlik açıkları hakkında yazarak halka bir hizmet mi yapıyoruz? Öyle olduğumuzu hissediyoruz çünkü güvenlik açıklarının varlığı konusunda farkındalık yaratmak iyidir. Ancak etkili olabilmemiz için belirli kriterleri karşılamamız gerekiyor.
- Her şeyden önce, kimin etkilendiği ve kimin bu konuda bir şeyler yapması gerektiği netleştirilmelidir. Ve kendinizi korumak için yapabilecekleriniz.
- Tehdit düzeyi hakkında bir değerlendirme yapmak her zaman kolay olmasa da, genellikle bir güvenlik açığının tam ayrıntılarına sahip olmadığımız için, etkiyi abartmamak tercih edilir.
- Bu bilgilere sahipseniz, vahşi doğada bir tehdidin kullanılıp kullanılmadığını açıkça belirtin.
Yakın tarihli bir değerlendirmede, güvenlik araştırmacısı Amélie Koran, Mastodon’da Heartbleed’in ekonomik maliyetlerinin çoğunlukla güvenlik açığı değerlendirmesi ve yama uygulamalarından kaynaklandığını ve verilerin kaybolması veya çalınması gerekmediğini söyledi. Yama dağıtılmamış olsaydı geri tepmeyeceğinden değil ama akılda tutulması gereken bir şey. Bir panik durumu, gerçek tehditten daha fazla zarar verebilir.
Tehditleri sadece rapor etmiyoruz, onları kaldırıyoruz
Siber güvenlik riskleri asla bir manşetin ötesine geçmemelidir. Malwarebytes’i bugün indirerek tehditleri cihazlarınızdan uzak tutun.