Şimdi dürüst olalım; çoğunuzun şirketinde o 'pahalı' güvenlik tarayıcıları çalışıyor. Nessus’tan Qualys’e, OpenVAS’tan ticari diğer araçlara kadar her şey kurulu. Haftalık raporlar geliyor, 'Critical' seviyesindeki zafiyetleri kapatıp kahvenizi yudumluyorsunuz. Ama size bir sır vereyim mi? O elinizdeki tertemiz raporlar, gerçek bir saldırganın karşısında sadece birer kağıt parçası. Neden mi? Çünkü o araçlar sadece 'bilineni' arıyor. Sektörde herkesin bu araçları bir 'güvenlik garantisi' gibi pazarlaması tam bir delilik. Gerçek dünya, o yeşil raporların dışında, henüz adı konmamış, CVE numarası verilmemiş 'Zero-day'lerle dönüyor.
Bugün o gizemli, hani filmlerde gördüğümüz 'sıfırıncı gün' meselesini konuşacağız. Ama öyle teorik değil; sahada bu işler nasıl dönüyor, bir Zero-day nasıl doğuyor ve en önemlisi, bu hayaletle nasıl savaşırsınız, ona bakacağız.
Zero-Day Nedir, Ne Değildir?
Zero-day (0-day), bir yazılımdaki zafiyetin, yazılımı geliştiren ekip tarafından henüz keşfedilmediği ve yamalanmadığı o kritik zaman dilimini ifade eder. Yani 'sıfır' günümüz var; saldırgan içeri sızdı bile ve bizim savunma sistemlerimiz (IDS/IPS/AV) imza tabanlı çalıştığı için ne olduğunu bile anlamıyor.
Bir zafiyetin yaşam döngüsü genellikle şöyledir:
- Zafiyetin (tesadüfen veya araştırma ile) keşfi.
- Exploit kodunun yazılması.
- (Opsiyonel) Bu bilginin karaborsada veya devlet kurumlarına satılması.
- Zafiyetin halka duyurulması (CVE atanması).
- Yamanın (patch) yayınlanması.
İşte o 1. ve 4. maddeler arası bizim 'karanlık bölgemiz'.
Bu Canavarlar Nerede Saklanır?
Genellikle karmaşık bellek yönetimi olan dillerde (C/C++) yazılmış sistemlerde karşımıza çıkarlar. Ama günümüzde web uygulamalarındaki mantık hataları (logic flaws) da birer Zero-day adayıdır. Örnek vermek gerekirse, testCompany bünyesinde geliştirdiğimiz bir API'nin, kimlik doğrulamayı bypass eden ama kimsenin fark etmediği bir 'gizli parametresi' olduğunu düşünün. İşte bu bir Zero-day'dir.
Teknik tarafa biraz girelim. Bir güvenlik araştırmacısı olarak vaktimin çoğunu 'Fuzzing' yaparak harcıyorum. Nedir bu fuzzing? Bir programa milyonlarca anlamsız, bozuk veya beklenmedik veri gönderip onu çökertmeye çalışmak. Program 'Crash' verdiğinde, o crash'in nedenini analiz ederiz. Eğer bu çökme, bellek üzerindeki bir alanı (EIP/RIP register'larını) kontrol etmemize izin veriyorsa, geçmiş olsun; bir exploit kapısı aralandı.
Teknik Bir Bakış: Buffer Overflow (Zararsızlaştırılmış Örnek)
Bir uygulamanın kullanıcıdan isim aldığı basit bir C fonksiyonunu düşünün. Klasik ama hala can yakan bir örnektir bu:
// testCompany - Eğitim Amaçlı Zafiyetli Kod Bloğu
#include <stdio.h>
#include <string.h>
void karsila(char *isim) {
char tampon_bolge[64]; // Sadece 64 byte yer ayırdık
// [!] KRİTİK HATA: strcpy girdi boyutunu kontrol etmez.
// Eğer kullanıcı 64 byte'tan fazla veri gönderirse,
// bellek taşar ve bitişikteki verileri ezer.
strcpy(tampon_bolge, isim);
printf("Selam, %s!\n", tampon_bolge);
}
int main(int argc, char *argv[]) {
if (argc > 1) {
karsila(argv[1]);
}
return 0;
}
Buradaki strcpy kullanımı tipik bir 'Zero-day' başlangıç noktasıdır. Saldırgan, 64 byte yerine 128 byte gönderir. Bu fazladan veri, işlemcinin bir sonraki komutu nereden okuyacağını belirleyen 'Return Address' kısmını ezer. Saldırgan oraya kendi zararlı kodunun (shellcode) adresini yazar. Boom! Sistem artık sizin değil, onun.
Modern Dünyada Zero-Day: Log4Shell Hatırlatması
Çok değil, birkaç yıl önce Log4j kütüphanesindeki o meşhur açık (Log4Shell) patladığında neler olduğunu hatırlayın. Kimsenin haberi yoktu, tarayıcılar görmüyordu. Ama internet üzerindeki milyonlarca sunucu şu kadar basit bir payload ile ele geçirilebiliyordu:
{jndi:ldap://127.0.0.1:1389/Exploit} (Defanged - 127.0.0.1 kullanılmıştır)
Sadece bir log satırı yazdırarak sunucunun kontrolünü ele geçirmek... İşte Zero-day'in gücü budur. Sizin o meşhur WAF'ınız (Web Application Firewall), bu payload'un bir saldırı olduğunu öğrenene kadar geçen 48 saatte dünya genelinde binlerce şirket hacklendi.
Peki, Nasıl Korunacağız? (Defensive Mindset)
Tamam, korkuttuk yeterince; şimdi biraz da savunma konuşalım. Eğer Zero-day'leri otomatik araçlar bulamıyorsa, biz ne yapacağız? Cevap: 'Defense in Depth' yani derinlemesine savunma.
Girdi Doğrulama (Input Validation): Asla ama asla kullanıcıdan gelen veriye güvenmeyin. 'Whitelist' mantığı ile çalışın. Sadece beklediğiniz karakterlere izin verin.
Memory Protections: Modern işletim sistemleri ASLR (Address Space Layout Randomization) ve DEP (Data Execution Prevention) gibi özellikler sunar. Bunları kapatmak, bir kalenin kapılarını ardına kadar açmaktır. Derleme aşamasında stack canary'lerini aktif edin.
Davranışsal Analiz (EDR/XDR): İmza tabanlı antivirüsler öldü. Bize 'X dosyası zararlıdır' diyen değil, 'PowerShell neden durup dururken internete bağlanıp bir script indirmeye çalışıyor?' diye soran sistemler lazım.
Fuzzing ve Statik Analiz (SAST/DAST): Kodunuzu prod ortamına almadan önce kendi iç fuzzing süreçlerinizi işletin. Kendi zafiyetinizi saldırganlardan önce bulun.
Least Privilege: Eğer o web uygulaması 'root' yetkisiyle çalışmıyorsa, bir Zero-day olsa bile saldırganın içeride yapabilecekleri sınırlıdır. Konteyner kullanıyorsanız 'rootless' modları zorlayın.
Red Team Gözünden Bir Tavsiye
Arkadaşlar, güvenlik bir ürün değil, bir süreçtir. 'En iyi firewall'u aldım, bitti' diye bir dünya yok. Zero-day her zaman olacak. Apple, Google, Microsoft bile her ay onlarca Zero-day kapatıyor. Onların yapamadığını sizin 10 bin dolarlık tarayıcınız mı yapacak?
Gerçek güvenlik, bir zafiyetin olacağını kabullenip (Assume Breach), o zafiyet kullanıldığında saldırganı ne kadar hızlı fark edebileceğinizde ve yayılmasını nasıl engelleyeceğinizde gizli. O yüzden bırakın o cafcaflı dashboard'lara bakmayı da, sistemlerinizin loglarını, anomali hareketlerini incelemeye başlayın.
Bir sonraki yazıda, bu yakaladığımız zafiyetlerin üzerinden nasıl 'Lateral Movement' (Yanal Hareket) yaparız, o konuya gireriz. Şimdilik sistemlerinize iyi bakın, her logu bir hikaye gibi okuyun.