PEN-200 Serisi, Bölüm 3: Zafiyet Taraması — ve Bir Tarayıcıyı Yalan Söylerken Yakalamak#

Seri planı OSCP+ hazırlık rehberinde; Bölüm 1 not tutma, Bölüm 2 bilgi toplamaydı. Bölüm 2'de NSE'nin default/safe kategorisine (-sC) kısaca değindik. Bu yazı PEN-200'ün kendi zafiyet taraması modülünü ele alıyor: Nessus ve nmap'in vuln kategorisi, ve ikisinin de neden "tarayıcı dedi ki" cümlesinin asla raporun son cümlesi olamayacağını öğrettiği.

Nessus: ne yapıyor, burada neden çalıştıramıyorum#

Nessus, imzalı bir zafiyet veritabanına karşı hem kimliksiz hem kimlikli (authenticated) tarama yapan ticari bir araçtır. Kimlikli tarama önemli: hedefe SSH/WinRM ile giriş yapıp yüklü paket listesini, yama seviyesini doğrudan okur — ağdan "bu servis şu sürüm gibi görünüyor" tahmin etmek yerine, "bu paket gerçekten şu sürümde kurulu" der. Bu farkın OSCP açısından anlamı: gerçek bir Nessus taraması network üzerinden asla göremeyeceğin dahili zafiyetleri (örneğin kernel privesc zafiyetleri) kimlikli modda ortaya çıkarabilir.

Bu seriyi yazdığım sandbox'ta Nessus kurulu değil ve lisanslama/kayıt gerektiriyor, o yüzden burada canlı bir Nessus taraması gösteremem — bunu söylemek, göstermeden "işte çıktı" demekten daha dürüst. PEN-200'ün kendi modülü kurulumu, plugin güncellemesini ve kimlikli/kimliksiz tarama farkını adım adım anlatıyor; kendi Kali kurulumunda tenable.com'dan ücretsiz Essentials sürümüyle bunu bizzat deneyimlemen gerekiyor.

Burada bizzat çalıştırıp doğrulayabileceğim şey nmap'in vuln kategorisi — ve çıkan sonuç, Nessus'u da içeren her tarayıcı için geçerli bir dersi mükemmel şekilde gösteriyor.

nmap --script vuln: kendi lab'ımıza karşı gerçek bir çalıştırma#

$ nmap -Pn -p 8080 --script vuln 127.0.0.1
 
PORT     STATE SERVICE
8080/tcp open  http-proxy
| http-vuln-cve2011-3192:
|   VULNERABLE:
|   Apache byterange filter DoS
|     State: VULNERABLE
|     IDs:  CVE:CVE-2011-3192  BID:49303
|       The Apache web server is vulnerable to a denial of service attack when numerous
|       overlapping byte ranges are requested.
|     Disclosure date: 2011-08-19
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
|_      https://www.securityfocus.com/bid/49303
| http-enum:
|_  /robots.txt: Robots file

Tarama, eresus-ctf-lab'ın Apache-özel bir 2011 Denial-of-Service CVE'sine karşı VULNERABLE olduğunu söylüyor. Lab'ın tamamı Node.js/Express — hiç Apache yok. Bu ya gerçek bir bulgu ya da bir yanlış pozitif, ve tek yol: bizzat doğrulamak.

Doğrulama: script neye bakıyor, biz de ona bakalım#

http-vuln-cve2011-3192'nin mantığı basit: sunucuya aynı byte aralığını onlarca kez tekrar eden bir Range header'ı gönder, sunucu bunu reddetmeden işlerse (yani 206 Partial Content dönerse), zafiyeti işaretle. Bu davranışsal bir test — sunucunun kendisinin Apache olduğunu hiç doğrulamıyor:

$ curl -s -o /dev/null -w "%{http_code}\n" -H "Range: bytes=0-10" localhost:8080/robots.txt
206
 
$ curl -s -D - -o /dev/null \
    -H "Range: bytes=0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10,0-10" \
    localhost:8080/robots.txt | head -5
 
HTTP/1.1 206 Partial Content
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Thu, 15 Oct 2026 22:19:55 GMT
 
$ curl -sI localhost:8080/robots.txt | grep -i server
(hiçbir satır dönmedi — Server header'ı hiç yok)

Üç şey doğrulandı:

1. Express, 20 kere tekrarlanan örtüşen aralık isteğine itirazsız 206 döndü — script'in tetikleyici koşulu gerçekten gerçekleşti.
2. Server header'ı yok, ama X-Powered-By: Express gayet açık. Bu Apache değil.
3. CVE-2011-3192, Apache httpd'nin belirli sürümlerindeki bir bellek tüketimi hatası. Node.js'in HTTP sunucusu bambaşka bir kod tabanı; aynı açığı taşıması mümkün değil.

Sonuç: yanlış pozitif, kesin olarak doğrulanmış. Script'in sezgisel yöntemi ("örtüşen aralıkları kabul ediyor mu") bir davranış kalıbını yakalıyor, ama o kalıbı üreten tek sebep Apache'nin spesifik hatası değil — herhangi bir sunucu, Range RFC'sini uygularken örtüşen aralıkları reddetmemeyi seçebilir, zafiyetli olmadan.

Neden bu, bir metodoloji dersi#

Bu tek örnekten çıkan kural evrensel: Nessus dahil her tarayıcı, davranışa, banner'a ya da sürüm string'ine bakan sezgisel kontrollerle çalışır. Hiçbiri "bu kodu çalıştırdım, zafiyet tetiklendi" demez — "bu kalıp genelde bu zafiyetle ilişkilendirilir" der. Güvenlik bulgularını skorlama yazısında tam olarak bunu işliyoruz: bir etiketin ciddiyeti ile gerçek istismar edilebilirliği aynı şey değil. Burada bir adım geriye gidiyoruz — etiketin kendisi bile bazen yanlış.

Pratik kural: bir tarayıcı (Nessus, nmap --script vuln, OpenVAS, fark etmez) bir şey işaretlediğinde, rapora geçirmeden önce üç soru sor:

1. Tarayıcı neye bakıyor? (--script-help <script-adı> ya da Nessus plugin detayı, kontrolün mantığını anlatır.)
2. O kontrolü manuel olarak tekrarlayabiliyor muyum? Burada yaptığımız gibi — aynı isteği elle gönder, yanıtı oku.
3. Hedefin gerçekten iddia edilen yazılım/sürüm olduğunu bağımsız bir kaynaktan doğruladım mı? (X-Powered-By, hata sayfaları, davranış farkları — tek bir header'a güvenme.)

Bu üç soruyu geçemeyen bir bulgu, rapora "doğrulanmamış tarayıcı çıktısı" notuyla düşer ya da hiç düşmez — asla "tarayıcı kritik dedi" tek başına bir cümle olarak girmez.

http-enum: küçük ama gerçek bir bulgu#

Aynı taramadaki ikinci script, http-enum, /robots.txt'yi buldu — Bölüm 2'de zaten manuel olarak okuduğumuz dosya. Burada ders farklı: otomatik bir zafiyet taraması bazen sana zaten bildiğin şeyi tekrar söyler, ve bu normal — amaç her script'in yeni bir şey bulması değil, hiçbir şeyi kaçırmamak. http-enum'ün kapsamı küçük bir dahili kelime listesiyle sınırlı; Bölüm 2'deki gobuster örneğinde gösterdiğimiz gibi, kendi kelime listenle yaptığın hedefli bir tarama her zaman daha fazlasını bulur.

Notlarına ne girsin#

Her VULNERABLE etiketi için üç satır: script'in adı, doğrulama adımların (burada: iki curl komutu ve bir header kontrolü), ve sonuç — gerçek bulgu mu, yanlış pozitif mi. Bu, Bölüm 1'in şablonundaki "Zafiyet" alt başlığına direkt giriyor ve raporuna "neden bunu bulgu olarak yazmadım" sorusuna hazır bir cevap kazandırıyor — ki sınav değerlendiricisinin sormayacağı ama senin kendi güvenilirliğin için cevaplamış olman gereken bir soru bu.

Bölüm 4, web uygulama saldırılarına giriyor: modern bir tech stack'i haritalamak, API'leri enumere etmek ve OWASP Top 10'un hangi kategorisinin hangi gerçek davranışa karşılık geldiğini kendi lab'ımızda göstermek.