PEN-200 Serisi, Bölüm 2: Pasif ve Aktif Bilgi Toplama#

Seri planı OSCP+ hazırlık rehberinde, 1. bölüm not tutma ve rapor yazımıydı. Şimdi notların dolmaya başladığı ilk modüle geçiyoruz: bilgi toplama.

PEN-200 bunu ikiye ayırıyor: pasif (hedefe hiç paket göndermeden) ve aktif (hedefle doğrudan konuşarak). Ayrım kozmetik değil — pasif aşamada öğrendiğin şey, aktif aşamada hangi portları, hangi sırayla ve ne kadar gürültüyle tarayacağını belirliyor.

Pasif: hiçbir paket göndermeden#

WHOIS#

Domain kayıt bilgisi: kayıt tarihi, kayıt şirketi, bazen isim sunucuları. Eski WHOIS kayıtlarında teknik iletişim e-postası gerçek bir çalışan adını sızdırabilir; bu da sosyal mühendislik ya da kullanıcı adı tahmini için malzeme.

whois hedef-domain.com

Arama motoru dork'ları#

Google ya da Bing'de site:, filetype:, inurl: operatörleri, indekslenmiş ama kasıtlı olarak linklenmemiş sayfaları bulur:

site:hedef.com filetype:pdf
site:hedef.com inurl:admin
site:hedef.com "index of /"

Netcraft ve sertifika şeffaflığı#

Netcraft bir sitenin barındırma geçmişini ve teknoloji yığınını gösterir. Sertifika şeffaflığı günlükleri (crt.sh) ise asıl altın madeni: bir hedef için verilmiş her TLS sertifikasını listeler, çoğu zaman staging., dev., internal- gibi hiç duyurulmamış alt alan adlarını ortaya çıkarır.

curl -s "https://crt.sh/?q=hedef.com&output=json" | jq -r '.[].name_value' | sort -u

(Bazı kısıtlı ya da kurumsal ağlar — bu serinin yazıldığı sandbox dahil — crt.sh'ye giden dışa dönük trafiği özellikle engeller. Komut takılırsa ya da bağlantı reddedilirse, bu sözdiziminin değil ağın sorunu; tekniğin çalışmadığını düşünmeden önce curl -v ile doğrula.) CT log yaklaşımı alt alan adı brute-force'tan daha iyidir çünkü yalnızca gerçekten sertifika verilmiş isimleri döndürür — kelime listesi yok, listede o kelime olmadığı için kaçırma riski yok.

DNS zone transfer (AXFR) — denemeye değer, nadiren açık#

Yanlış yapılandırılmış bir isim sunucusu, sorana tüm bölge dosyasını — elindeki her kaydı — verir:

dig axfr @ns1.hedef.com hedef.com

Doğru yapılandırılmış DNS, AXFR'ı yalnızca ikincil isim sunucularıyla sınırlar, bu yüzden çoğu deneme "Transfer failed" ya da timeout döner. Bu, denemeyi atlama sebebi değil — yapılandırma hatası, kontrol etmek tek komut tutacak kadar yaygın; PEN-200'ün kendi modülü bunu açıkça, asla atlanmaması gereken bir adım olarak işaretliyor, tam olarak başarısız olduğunda bedava, başarılı olduğunda ise tam zafer olduğu için.

Shodan#

İnternete açık servisleri, bantlarını ve genellikle sürüm bilgilerini tarıyıp indeksleyen bir arama motoru. hedef.com ile ilgili IP aralığını biliyorsan, Shodan sana o aralığı hiç paket göndermeden tarar.

Güvenlik header'ları ve TLS#

Bunu şu an, gerçek bir siteye karşı doğrulayabilirsin — bu tamamen pasif, tek bir normal HTTP isteği:

$ curl -sI https://anthropic.com
HTTP/1.1 200 Connection Established
 
HTTP/2 301
content-security-policy: default-src 'self'; script-src 'self' 'unsafe-inline' ...
strict-transport-security: max-age=3600
server: cloudflare

server, x-powered-by gibi header'lar teknoloji yığınını sızdırır. content-security-policy'nin yokluğu (ya da unsafe-inline gibi gevşek bir CSP) ileride XSS bulgusu yazarken "neden bu önemli" sorusuna doğrudan cevap. strict-transport-security eksikse, bu da kendi başına bir bulgu.

Aktif: hedefle konuşmaya başlamak#

Aktif aşamadan itibaren örnekleri kendi eresus-ctf-lab reposuna karşı, gerçekten çalıştırarak veriyorum — izinli ve kendi kontrolümdeki bir hedef.

DNS enumerasyonu#

$ dig A github.com +short
140.82.114.4

Bir A kaydı ortamdan ortama çalışır; bazı ağlarda MX, TXT, NS sorguları filtrelenir — kendi test ortamında bunu önceden doğrula, sınav gecesi sürpriz istemezsin. Bulduğun her alt alan adını hem DNS hem HTTP seviyesinde kontrol et; bazı alt alan adları DNS'te var ama hiçbir web sunucusu arkasında yok (ya da tam tersi, sanal host routing'i yüzünden DNS'te hiç görünmeyen bir isim web sunucusunda yanıt veriyor olabilir).

Port taraması#

Önce hızlı, tüm porta geniş bir tarama; sonra sadece açık olanlara detaylı bir tarama. Sıra önemli: 65535 portun hepsine -sV ile vurmak hem yavaş hem gereksiz gürültü.

$ nmap -Pn -sT -p 8080,8081 127.0.0.1
 
PORT     STATE SERVICE
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
 
$ nmap -Pn -sT -sV -p 8080 127.0.0.1
 
PORT     STATE SERVICE VERSION
8080/tcp open  http    Node.js Express framework

-sV ikinci taramada ne çalıştığını (Node.js/Express) doğru tahmin etti — bunu kendi makinende doğrulayabilirsin, eresus-ctf-lab'ı npm start ile ayağa kaldırıp aynı komutu çalıştır.

Buradaki 8081 ayrıntısı önemli: lab'ı aynı makineden tarıyorum, bu yüzden 8081 (internal servis) açık görünüyor. Başka bir makineden tarasaydım, o port hiç görünmezdi — 127.0.0.1'e bağlı, dışarıya kapalı. NoSQL injection serisinin SSRF bölümünde tam olarak bu farkı istismar ediyoruz: dışarıdan görünmeyen bir servise, sunucunun kendisini vekil olarak kullanarak ulaşmak.

NSE: nmap'in script motoru#

-sC, nmap'in varsayılan script setini çalıştırır — tüm NSE kütüphanesinin seçilmiş, düşük riskli bir alt kümesi (default ve safe kategorileri; nmap ayrıca vuln, exploit, brute, dos gibi açıkça seçerek kullandığın kategoriler de sunar; --script-help <isim> herhangi bir scriptin hangi kategoriye ait olduğunu ve tam olarak neyi kontrol ettiğini gösterir). Lab'a karşı otomatik olarak üç script tetiklendi ve üçü de gerçek bir şey söyledi:

$ nmap -Pn -sT -sC -sV -p 8080 127.0.0.1
 
PORT     STATE SERVICE VERSION
8080/tcp open  http    Node.js Express framework
|_http-title: Eresus Internal Portal
| http-robots.txt: 2 disallowed entries
|_/api/legacy/ /internal/
|_http-open-proxy: Proxy might be redirecting requests

http-title ve http-robots.txt adlarından anlaşıldığı gibi — ve http-robots.txt'nin, rutin bir -sC taramasının yan etkisi olarak, önceki bölümdeki recon işini senin için otomatik olarak yaptığına dikkat et. http-open-proxy daha ilginç: bu bir yanlış pozitif. Lab açık bir proxy değil; scriptin sezgisel yöntemi (bir proxy isteğine benzeyen bir istek gönder, yanıt yönlendirilmiş gibi mi bak) Express'in yanıt verme şeklindeki başka bir şeye takıldı. Bunu erken içselleştirmek önemli: NSE scriptleri sezgisel yöntemlerdir, kesin gerçek değil. İşaretlenen her sonuç, rapora girmeden önce manuel kontrol ister — buradaki http-open-proxy'yi doğrulamak (ya da elemek) "proxy" üzerinden manuel bir curl atıp hiçbir yere yönlendirmediğini görmek kadar basit.

Parmak izi çıkarılmış bir servise karşı bilinen bir CVE için sıradaki adım vuln kategorisi; bunu varsayılan taramadan ayrı ve bilerek çalıştır, çünkü bazı scriptleri kırılgan bir servisi çökertecek kadar müdahaleci:

nmap -Pn -p 8080 --script vuln 127.0.0.1

İçerik keşfi: varsayılan taramalar POST-only route'ları kaçırır#

Burası, içerik keşif araçlarını yanılmaz sayan insanları yakalayan kısım. gobuster, ffuf, feroxbuster ve benzerleri varsayılan olarak GET isteği atar. Yalnızca POST'a yanıt veren bir route, varsayılan bir taramaya görünmezdir — kelime listende tam doğru yol olsa bile:

$ curl -s -o /dev/null -w "%{http_code}\n" localhost:8080/api/legacy/v1/session
404
 
$ echo -n "legacy/v1/session" > exact.txt
$ gobuster dir -u http://127.0.0.1:8080/api -w exact.txt -q
# (çıktı yok — gobuster'ın varsayılan GET isteği 404 dönüyor, yukarıdaki curl ile aynı)
 
$ curl -s -o /dev/null -w "%{http_code}\n" -X POST localhost:8080/api/legacy/v1/session \
    -H 'Content-Type: application/json' -d '{}'
400

Aynı yol, iki farklı HTTP metodu, iki farklı sonuç. Route gerçek — 400, isteği aldığını ve gövdesini reddettiğini gösterir, var olmadığını değil — ama GET-only bir brute force bunu kaçırılmış olarak raporlar. Pasif bölümdeki robots.txt sızıntısının burada brute force'tan daha değerli olmasının sebebi de bu: sana yolu ve bunun bir legacy session API'sine ait olduğunu söyledi, ki bu, başka hiçbir şekilde metodu doğrulamadan önce bile POST'u denemeye değer olduğunu tahmin etmene yeter. Bir içerik keşif taraması beklediğinden daha boş döndüğünde, hele hedef bir JSON API kullanıyorsa, kontrol edilecek ilk şey bu — hiçbir şey yok sonucuna varmadan önce -m POST (ya da aracının eşdeğeri) ile yeniden çalıştır.

Bilinmeye değer ikinci bir boşluk: tek segmentlik düz bir kelime listesi (admin, api, internal, legacy, backup) bu uygulamanın kök dizinine karşı hiçbir şey bulamadı, çünkü buradaki her gerçek route iki üç segment derinlikte (/api/legacy/v1/session, /internal/healthz). Düz kelime listeleri düz uygulamaları bulur; modern bir API ya uygulamanın kendi adlandırma kurallarından (framework varsayılanları, client-side JS bundle'ının route string'leri, açıkta kalmış API dokümantasyonu) oluşturulmuş bir kelime listesi ya da bir segmenti brute force edip bulduğunun içinde tekrar brute force eden recursive bir tarama ister.

SMB, SMTP, SNMP enumerasyonu#

Bu üçü PEN-200'ün aktif bilgi toplama modülünün geri kalanı. Standart sözdizimleri:

# SMB — paylaşımlar, oturum açma politikası, OS sürümü
smbclient -N -L //$HEDEF
enum4linux-ng -A $HEDEF
 
# SMTP — kullanıcı adı doğrulama (VRFY/EXPN hâlâ bazı sunucularda açık)
nc $HEDEF 25
VRFY root
 
# SNMP — çoğu zaman "public" community string'iyle açık kalır
snmpwalk -v2c -c public $HEDEF

SNMP (161/udp) özellikle değerli: açıksa, çoğu zaman tüm ağ arayüzlerini, yönlendirme tablosunu ve bazen çalışan süreç listesini düz metin olarak döker — hiç exploit gerekmeden.

Pasif + aktifi birleştirmek: kendi lab'ımızdan bir örnek#

eresus-ctf-lab'ın ana sayfası (pasif — tek bir HTTP isteği) bir destek e-postası veriyor:

$ curl -s localhost:8080/ | grep -A1 support@
Having trouble signing in? Contact
<a href="mailto:support@eresus.lab">support@eresus.lab</a>.

robots.txt (yine pasif) iki dizin daha işaret ediyor:

$ curl -s localhost:8080/robots.txt
User-agent: *
Disallow: /api/legacy/
Disallow: /internal/

Bu iki pasif gözlem — bir kullanıcı adı ipucu (support) ve bir legacy endpoint yolu — NoSQL injection, Bölüm 1 yazısındaki tüm zincirin başlangıç noktası. Aktif tarama hiçbir şey keşfetmeden önce, pasif aşama zaten hedefi nereden vuracağını söylüyor — PEN-200'ün bu ikisini ayrı modül olarak öğretmesinin sebebi tam olarak bu.

Notlarına ne girsin#

Bölüm 1'in şablonuna göre, bu aşamanın çıktısı "Enumeration" bölümünün "Ports" ve "Services" alt başlıklarını dolduruyor. Ham nmap çıktısını olduğu gibi yapıştır, ama üstüne bir satır ekle: hangi port seni nereye yönlendirdi. Altı ay sonra raporuna bakan biri (ya da sınav gecesi yorgun hâldeki sen) bu tek satırdan metodolojini yeniden kurabilmeli.

Bölüm 3, zafiyet taramasını ele alıyor: Nessus ve nmap'in NSE script motoruyla, bulduğun servislerin hangi bilinen zafiyetlere sahip olabileceğini sistematik olarak kontrol etmek.