Saat sabahın 02:45'iydi. Ekranın mavi ışığı, masadaki soğumuş kahve lekesini aydınlatırken terminalde yanıp sönen imleç adeta benimle dalga geçiyordu. testCompany için yürüttüğümüz geniş kapsamlı sızma testi projesinde, dışarıdan içeriye tek bir açık kapı bile bulamamıştık. Firewall'lar canavar gibi çalışıyor, EDR'lar kuş uçurtmuyordu. Ta ki o ana kadar. Gözden kaçmış, unutulmuş ve muhtemelen yıllardır kimsenin login olmadığı bir 'legacy' test sunucusu, ağın karanlık bir köşesinden bana göz kırptı. İşte o an anladım: Güvenlik, en güçlü halkan kadar değil, unutulan en zayıf halkan kadardır.
Araçların Ötesine Geçmek
Sızma testi (penetration testing) dendiğinde piyasada genel bir algı var: 'Abi, Nmap atıyoruz, Nessus çalıştırıyoruz, sonra raporu basıyoruz.' Eğer böyle düşünüyorsan, üzgünüm ama sen bir siber güvenlik uzmanı değil, bir 'skript kiddie' adayı bile değilsin. Gerçek bir pentest, sistemin nasıl çalıştığını değil, nasıl 'bozulabileceğini' hayal etme sanatıdır.
O gece o legacy sunucuya ulaştığımda, üzerinde koşan eski bir Jenkins instance'ı vardı. Standart bir tarama cihazı bunu 'orta riskli' olarak işaretleyip geçerdi belki ama bir Red Teamer gözüyle baktığında, o bir altın madeniydi. Neden mi? Çünkü Jenkins üzerindeki 'Script Console' özelliği, yetkilendirme hataları (misconfiguration) ile birleştiğinde size doğrudan sistem üzerinde kod çalıştırma yetkisi (RCE) verir.
Bir Senaryo: Jenkins Üzerinden Sisteme Sızmak
Şimdi gel, bu işin mutfağına girelim. Zararsızlaştırılmış bir örnek üzerinden gidelim. Jenkins'in script console'una eriştiğini düşün. Aşağıdaki gibi basit bir Groovy script'i ile sistemin ciğerini okuyabilirsin:
// ZARARSIZLAŞTIRILMIŞ ÖRNEK (Defanged)
// Amacımız sistemde kim olduğumuzu anlamak
def command = "whoami"
def process = command.execute()
println process.text
Burada çıktı olarak nt authority\system veya root görüyorsan, geçmiş olsun. Artık sadece bir web uygulamasına değil, işletim sisteminin kalbine dokunuyorsun demektir. Ama iş burada bitmiyor. Bizim derdimiz sistemi yıkmak değil, o sistemin neden savunmasız kaldığını anlamak.
Lateral Movement: İçeride Sessizce İlerlemek
İçeri girdik, peki ya sonra? Pentest'in en sevdiğim aşaması burası: Yanlara doğru hareket etmek (Lateral Movement). Tek bir makineyi ele geçirmek bir şey ifade etmez; asıl hedef Active Directory (AD) veya hassas verilerin olduğu database sunucularıdır.
Bir sızma testinde, ele geçirilen ilk makinedeki 'credential dump' işlemleri kritik öneme sahiptir. Bellekteki (memory) şifreleri veya hash'leri çekmek için kullanılan araçlar her ne kadar gelişmiş olsa da, günümüzdeki modern EDR (Endpoint Detection and Response) çözümleri bunları şak diye yakalar.
Mesela, lsass.exe sürecine doğrudan dokunduğun an alarm zilleri çalar. Biz ne yapıyoruz? Belleği olduğu gibi dump etmek yerine, daha 'stealth' (sessiz) yöntemler deniyoruz.
# Defanged - Bellek dökümü alma mantığı (Temsili)
# Gerçek hayatta EDR bu komutu engeller!
# rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <ProcessID> C:\temp\lsass.dmp full
Bu tür bir hareketten kaçınmak için savunma tarafında 'Credential Guard' aktif edilmeli ve LSA koruması devreye alınmalıdır. Yoksa saldırgan, o bellekteki hash'i alıp Pass-the-Hash yöntemiyle ağdaki diğer sunuculara elini kolunu sallayarak girer.
Savunma Stratejisi: Nasıl Durdururuz?
Buraya kadar hep 'saldırı' dedik, şimdi biraz da 'savunma' tarafına bakalım. testCompany'deki o sızma anında, eğer aşağıdaki önlemler alınmış olsaydı, işim imkansıza yakın olurdu:
- Ağ Segmantasyonu: Test sunucuları ile üretim (prod) ortamı asla aynı VLAN üzerinde olmamalı. Jenkins'in hacklenmesi, Domain Controller'a ulaşmamı sağlamamalıydı.
- Least Privilege (En Az Yetki) Prensibi: Jenkins servisi, neden 'system' yetkisiyle çalışıyor? Sadece işini yapacak kadar yetkiye sahip bir 'service account' ile çalıştırılmalıydı.
- Patch Management: O Jenkins'in versiyonu 2018'den kalmaydı. Güvenlik yamalarını düzenli geçmek, bir lüks değil zorunluluktur.
- MFA (Çok Faktörlü Doğrulama): Sadece şifre yetmez. Script console veya yönetim panellerine erişim her zaman MFA ile korunmalıdır.
SQL Injection: Klasik Ama Hala Ölümcül
Sızma testlerinde hala en sık karşılaştığımız açıkların başında SQL Injection (SQLi) geliyor. Geliştiriciler bazen 'Hızlıca bir query yazayım' derken parametrik sorgu kullanmayı unutuyor.
Bakın, şöyle bir kod bloğu (pseudo-code) siber güvenliğin en büyük düşmanıdır:
-- TEHLİKELİ VE YANLIŞ KULLANIM
-- Gelen parametre doğrudan query'nin içine basılıyor
query = "SELECT * FROM users WHERE username = '" + userInput + "'";
Bunu gören bir pentester, userInput yerine ' OR '1'='1 yazar ve tüm veritabanını dökebilir. Savunma çok basit ama hayati:
-- GÜVENLİ VE DOĞRU KULLANIM (Parameterized Query)
-- Veri ve komut birbirinden ayrılıyor
query = "SELECT * FROM users WHERE username = ?";
stmt.setString(1, userInput);
Raporun Gücü: Teknik Detaydan İş Değerine
Test biter, ekranlar kapanır ve o en 'sıkıcı' görünen ama aslında en önemli kısım başlar: Raporlama. Bir Red Team uzmanı olarak, sadece 'Şurayı patlattık, burayı hackledik' demek kimsenin işine yaramaz. Rapor, yönetimin anlayacağı bir dilde (Risk analizi) ve IT ekibinin uygulayacağı teknik netlikte (Remediation) olmalıdır.
Örneğin; 'Jenkins sunucusu hacklendi' demek yerine, 'X sunucusundaki yetkilendirme hatası nedeniyle şirketin müşteri verilerine 15 dakika içinde tam erişim sağlanabilmektedir. Çözüm olarak network izolasyonu ve yama yönetimi önerilir' demek, sızma testini bir başarı hikayesine dönüştürür.
Sızma testleri, sadece bir 'güvenlik check-up'ı değil, aynı zamanda organizasyonun reflekslerini ölçen bir antrenmandır. Biz bugün bu testleri yapıyoruz ki, yarın gerçekten kapıya biri dayandığında o kapının kilitli olduğundan emin olalım.
Unutma; siber güvenlik bir varış noktası değil, sürekli bir yolculuktur. Ve bu yolculukta yanına alacağın en büyük silahın merakın ve şüpheciliğindir. Bir sonraki terminal session'ında görüşmek üzere!