PTWA: Hledání subdomén
Zdroj: SOOM.cz [ISSN 1804-7270]Autor: .cCuMiNn.
Datum: 19.1.2017
Hodnocení/Hlasovalo: 1.75/12
Tento text je součástí on-line testovací příručky, která pro vás na tomto serveru vzniká. Budeme rádi za vaše připomínky v komentářích a za vaši aktivní účast v doprovodných projektech.
Shromáždit informace o aplikacích sdílejících server s testovanou aplikací, bylo pro penetračního testera stejně tak důležité, jako zjistit všechny subdomény spadající pod testovanou doménu. Zatímco v případě shromažďování informací o sousedech nám šlo hlavně o možnosti vzájemného napadení napříč hostovanými aplikacemi, v případě subdomén nám půjde hlavně o zjištění dalších součástí aplikace, které mohou s námi testovanou sdílet společná data.
Příkladem budiž subdoména www, která má na starosti vyřizovat požadavky návštěvníků přicházejících ze stolních počítačů, zatímco subdoména mobile, na které běží stejná aplikace, má na starosti návštěvníky přicházející z mobilních zařízení. K tomu můžeme přidat ještě subdoménu admin, na které se nachází administrační rozhraní aplikace, nebo subdoménu beta, na které vývojáři testují nově přidané funkce.
Všechny uvedené subdomény se vyznačují tím, že sdílejí stejná data, a přestože jedna subdoména může být napsána zcela bezchybně, jiná může obsahovat celou řadu zranitelností. Vzhledem k tomu, že na jednotlivých subdoménách často pracují odlišné týmy vývojářů, setkáte se také s tím, že se tyto týmy vzájemně nedohodly na tom, zda validace sloužící proti jistým typům útoků budou provádět na vstupním, nebo až na výstupním rozhraní. Podle toho, na které subdoméně vloží návštěvník svůj vstup, a na které subdoméně si následně půjde svá data prohlédnout, se může stát, že budou tato data ošetřována hned dvakrát, nebo naopak vůbec.
Pro příklady, které nám důležitost odhalení všech subdomén dokáží demonstrovat, přitom nemusíme chodit nikterak daleko. Stačí si vzpomenout na známou zranitelnost Facebooku z roku 2016, která na doméně beta.facebook.com umožňovala provádět útoky hrubou silou proti autorizačním kódům zasílaným při resetu hesla. Stejný typ útoku byl přitom na doméně www.facebook.com správně ošetřen. Nálezci za oznámení této zranitelnosti připadlo z bug bounty programu celých 15.000$, což za tu trochu námahy s otestováním aplikace i na jiné než defaultní doméně zcela jistě stálo.
V této kapitole se proto zaměříme na jednotlivé metody, kterými lze seznam existujících subdomén v maximální možné míře získat.
Dotazování se vyhledávačů Google, Bing, apd.
Pravděpodobně nejsnazším způsobem, jak se o existenci několika existujících subdomén dozvědět, je zeptat se na ni vyhledávače Google. Náš první dotaz položíme tak, aby nám byl vrácen seznam všech webových stránek zaindexovaných na dané doméně druhého řádu.
site: soom.cz
Vráceným výsledkem bude velké množství stránek vedoucích na doménu www.soom.cz. Nyní položíme Googlu druhý dotaz, ve kterém subdoménu www vyloučíme z výsledků vyhledávání.
site:soom.cz -site:www.soom.cz
Nyní bude většina vrácených stránek odkazovat na doménu pravo.soom.cz, a proto tuto doménu opět vyloučíme v následném dotazu.
site:soom.cz -site:www.soom.cz -site:pravo.soom.cz
Jediné vrácené dotazy nyní směřují na doménu irc.soom.cz, kterou bychom pro úplnost mohli v následném dotazu také raději ještě vypustit. Google nám tedy prozradil existenci následujících tří subdomén: www, pravo a irc.
Obdobné dotazování můžete zkusit také proti dalším vyhledávačům, jako je Bing, Yahoo, Ask, Baidu, Seznam, apd.
Dotazovaní se cílového serveru
Již jsem zmínil v předchozích kapitolách, že jeden server může hostovat více různých domén. Psal jsem také o tom, že požadavky, které opouští webový prohlížeč, jsou směřovány přímo na konkrétní IP, kterou, kterou si prohlížeč zjistil na DNS serveru a o tom, že se server při rozhodování, kterou aplikaci nám předloží, rozhoduje na základě údaje uvedeného v HTTP request hlavičce Host.
Co by se tedy stalo, pokud byste pomocí modulu Intruder v nástroji Burp Suite měnili obsah této hlavičky a zkoušeli v ní tak uvádět jednotlivé subdomény hrubou silou, nebo na základě slovníku? Výsledek bude záležet nejen na skutečnosti, zda je daná subdoména na serveru skutečně hostována, ale také na nastavení a typu webového serveru. V případě, že se jedná o existující subdoménu, pak Vám bude vrácen její obsah. Ovšem v případě, kdy daná subdoména na serveru neexistuje, může dojít k jednomu z následujících scénářů.
- Server přebírá libovolné subdomény pro hostovanou doménu a pro všechny vrací stejný obsah, viz následující výpis z konfigurace vhostů v Apache:
DocumentRoot "/var/www/example" ServerName example.cz ServerAlias *.example.cz
Toto chování rozhodně není nejlepším řešením, neboť je možné jej při benevolentně nastaveném CNAME záznamu v DNS zneužít pro zaindexování neexistujících subdomén Googlem a dalšími vyhledávači. O této zranitelnosti bude později ještě řeč. - Server při požadavku na neexistující subdoménu přesměruje uživatele na defaultní subdoménu, nejčastěji www. Toho lze v Apache dosáhnout například vhodnou kombinací v nastavení vhosta (viz předchozí bod) a zápisem v souboru .htaccess
RewriteCond %{HTTP_HOST} !^www\.example\.cz RewriteRule (.*) http://www.example.cz/ [R=301,QSA,L] - Server zobrazí defaultní chybou stránku, informující o tom, že požadovaný zdroj nebyl na severu nalezen.
- Server přesměruje uživatele pomocí HTTP response hlavičky Location na požadovanou (sub)doménu. To může vést k redirektu na zcela jiný server a ani toto chování proto není úplně ideální. Svým způsobem se totiž jedná o otevřený redirekt, přestože jeho zneužití je v tomto případě spíše teoretické.
- Server poskytne svou defaultní uvítací stránku, což může útočníkovi poskytnout mnoho cenných informací, a opět to proto není optimální chování serveru.
Uvedený postup s využitím intruderu může být v něčem vhodný, ale z jiného pohledu současně také v mnohém zcela nevhodný. Přínosem může být odhalení subdomén, které jsou na serveru sice hostovány, ale nemají platný záznam v systému DNS. Pro přístup k nim bude nutné použít stejný postup, jaký jsme použili již v případě domén bez platného DNS záznamu. Nevýhodou je naopak skutečnost, že toto naše testování existence subdomén bude na server odesílat množství neplatných požadavků, které budou zcela jistě na serveru zalogovány. Druhou a poměrně významnější nevýhodou pak bude skutečnost, že se nedozvíme o existenci subdomén, které sice existují, ale jsou hostovány na zcela jiném serveru.
Pro úplnost na tomto místě ještě uvedu step by step postup pro použití modulu Intruder nástroje Burp Suite.
Již víte, že pokud máte vhodně nakonfigurován webový prohlížeč pro použití tohoto nástroje, můžete všechny požadavky opouštějící Váš prohlížeč najít na záložce HTTP history modulu Proxy. Pokud tedy navštívíte testovanou doménu zadáním její adresy v prohlížeči, nebude Vám jistě činit problém najít tento požadavek v uvedené historii. Když na tento požadavek kliknete pravým tlačítkem myši, zobrazí se kontextová nabídka, ve které si můžete všimnout několika voleb začínajících slovy „Send to…“. Pomocí těchto voleb je možné vybraný request odeslat do dalších modulů nástroje Burp Suite. Zvolte tedy možnost Send to Intruder.
Nyní se přepněte do modulu Intruder, kde najdete Vámi předaný požadavek. Modul Intruder obsahuje celkem čtyři záložky:
- Target – Zde se uvádí adresa serveru, proti kterému budou Vaše požadavky zasílány. Ve skutečnosti bude tato adresa přeložena na IP adresu a teprve ta bude následně použita.
- Position – Na této záložce označujete konkrétní místo v requestu, které si přejete testovat. V našem případě to bude subdoména v hlavičce Host. Pokud Vám Burp Suite automaticky označí některá místa, klikněte nejprve na tlačítko Clear §. Rozevírací pole Attack Type ponechte v tomto případě nastavené na hodnotu Sniper. O ostatních volbách v tomto seznamu se podrobněji zmíním později ve spojitosti s testováním guessingu.
- Payloads – Na záložce Positions jste intruderu sdělili, kam chcete do požadavků vkládat konkrétní hodnoty. Na záložce Payloads mu pak sdělujete, jaké hodnoty si přejete na uvedené místo vkládat. V případě hledání subdomén to může být například slovník nejčastěji se vyskytujících názvů. Pro výběr slovníku vyberte z rozbalovacího seznamu Payload type možnost Runtime file.
- Options – Na této záložce můžete nastavit sekci Grep – Match, pokud budete chtít, aby Vám Intruder na základě vrácených odpovědí automaticky zatrhával existující subdomény.
Samotné odstartování testu provedete volbou Start attack, která je dostupná jednak v nabídce Intruder hlavního menu, nebo stejnojmenným tlačítkem.
Intruder ve free verzi nástroje Burp Suite není bohužel možné spustit v několika souběžně běžících vláknech a požadavky jsou navíc uměle zpomalovány. Pro reálný test tedy budete muset sáhnout k jinému nástroji, nebo si pořídit placenou verzi Burp Suite.
Dotazování se systému DNS
Nevýhody předchozího přístupu, kdy jste se na existenci subdomén dotazovali přímo cílového serveru, eliminuje scénář, při kterém se na existenci subdomén budeme dotazovat systému DNS. Pokud jsou v CNAME záznamech DNS pro danou doménu uvedeny pouze platné subdomény, pak Vám dotaz odeslaný na DNS server poskytne IP adresu hostujícího serveru. Naproti tomu, pokud subdoména v DNS svůj záznam nemá, bude Vám vráceno chybové hlášení. Teoreticky můžete tento test provést i nástrojem ping. Ten ovšem v případě validní subdomény odešle na cílový server ICMP packet, čímž po sobě zanechá jistou stopu.
C:\>ping www.example.com
Příkaz PING na www.example.com [93.184.216.34] - 32 bajtů dat:
Odpověď od 93.184.216.34: bajty=32 čas=107ms TTL=52
…
C:\>ping test.example.com
Hostitele test.example.com se pomocí příkazu Ping nepodařilo najít.
Zkontrolujte název hostitele a akci opakujte.
Lepší možností bude využít nástroj určený pouze k odesílání dotazů na DNS server, kterým je například nslookup.
C:\>nslookup www.example.com 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Neautorizovana odpoved:
Nazev: www.example.com
Addresses: 2606:2800:220:1:248:1893:25c8:1946
93.184.216.34
C:\>nslookup test.example.com 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
*** google-public-dns-a.google.com, nelze najit adresu test.example.com: Non-existent domain
V obou uvedených případech ale mohou být výsledky zkreslené. Konkrétně ve chvíli, kdy je v DNS záznamu CNAME obsažen údaj *.example.cz, tedy, že všechny subdomény se mají odkazovat na některý A záznam. V takovém případě Vám bude odpovídat ping na libovolnou subdoménu a stejně se bude chovat také nástroj nslookup, přestože daná doména ve skutečnosti neexistuje. Kvalita tohoto postupu tedy silně závisí na návrhu DNS záznamů.
Samotné manuální dotazování se DNS serveru by bylo samozřejmě nereálné, a proto je vhodné sáhnout po nějakém automatizovaném nástroji, který se na základě slovníku dotáže DNS serveru za Vás. Skvělou práci za Vás v tomto směru odvedou nástroje z následující tabulky.
| Nástroje pro DNS enumeraci subdomén | |
|---|---|
| SubBrute | https://github.com/TheRook/subbrute |
| Knock Subdomain Scan | https://github.com/guelfoweb/knock |
| DNSRecon | https://github.com/darkoperator/dnsrecon |
| DNSmap | https://github.com/makefu/dnsmap |
| dns-brute.nse | Skript Nmapu |
Který z uvedených nástrojů použijete, nebo zda sáhnete k nástroji zcela jinému, je víceméně jedno. Záleží pouze na tom, který z nich Vám bude nejvíce vyhovovat. Všechny mají totiž jedno společné. Totiž, že vyhledávají subdomény na základě slovníku, který si s sebou často přinesou v základní výbavě. Nejde tedy ani tak o kvalitu samotného nástroje, jako spíše o kvalitu slovníku, který použijete. Samozřejmě, že některé nástroje mají lepší výstup než jiné, některé se zase lépe vyrovnávají se všeobecnými CNAME záznamy, jiné dokáží pracovat ve více vláknech, a podobně. Je tedy potřeba, abyste se s těmito nástroji nejprve seznámili a vybrali si z nich ten nejlepší právě pro Vás.
DNS a přenos zóny
Žádná z předchozích variant bohužel nebyla schopna poskytnout zcela vyčerpávající informace o skutečně všech existujících subdoménách. O tom, zda se nám podařilo odhalit opravdu všechny, nebo zda jsme zjistily pouze jejich malou část, proto můžeme pouze spekulovat. Chybně nakonfigurované DNS servery Vám ovšem mohou poskytnout seznam skutečně všech existujících subdomén. Stačí se těchto serverů pouze správně zeptat. Řeč je o přenosu zóny (zone transferu), tedy o funkčnosti, která je v systému DNS implementována pro klonování záznamů mezi jednotlivými jmennými servery, které jsou pro danou doménu autoritativní. Výpis těchto autoritativních DNS serverů pro danou doménu můžete snadno získat například nástrojem nslookup, pokud se DNS zeptáte na uložené NS záznamy.
C:\>nslookup -query=ns mzcr.cz
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Neautorizovana odpoved:
mzcr.cz nameserver = kasel.mzcr.cz
mzcr.cz nameserver = ns2.ksrzis.cz
V uvedeném příkladu jsme se zeptaly DNS serveru, který provozuje Google, na name servery, jež jsou autoritativní pro doménu mzcr.cz. Na náš dotaz nám byla vrácena jména serverů kasel.mzcr.cz a ns2.ksrzis.cz. Na těchto dvou serverech jsou tedy uloženy záznamy o všech subdoménách spadajících pod dotazovanou doménu. Jeden z těchto DNS serverů je přitom primární a druhý (sekundární) slouží jako záloha pro případ nedostupnosti primárního serveru. Aby byly na obou serverech uloženy stejné hodnoty záznamů, je mezi servery nastaveno klonování záznamů právě prostřednictvím přenosu zóny. Při správně nakonfigurovaném serveru by měly servery poskytnout tento obsah pouze druhému ze serverů. V případě chybné konfigurace ji poskytnou každému, kdo o ni požádá. Pojďme tedy vyzkoušet vyloudit zónu od prvního z autoritativních name serverů ministerstva zdravotnictví, tedy od serveru kasel.mzcr.cz.
C:\>nslookup
Vychozi server: google-public-dns-a.google.com
Address: 8.8.8.8
> server kasel.mzcr.cz
Vychozi server: kasel.mzcr.cz
Address: 193.84.7.66
> set type=any
> ls -d mzcr.cz
[kasel.mzcr.cz]
*** Nelze vypsat domenu mzcr.cz: Query refused
Server DNS odmítl přenos zóny mzcr.cz do vašeho počítače. Pokud to není správně,
zkontrolujte nastavení zabezpečení zónových přenosů pro: mzcr.cz na serveru DNS
na IP adrese 193.84.7.66.
Z uvedeného výpisu je patrné, že je server nakonfurován správně, protože obsah zóny odmítl předat. Stejný dotaz proto budeme směřovat i na druhý z nameserverů, tedy na adresu ns2.ksrzis.cz, viz následující výpis.
C:\>nslookup
Vychozi server: google-public-dns-a.google.com
Address: 8.8.8.8
> server ns2.ksrzis.cz
Vychozi server: ns2.ksrzis.cz
Address: 193.16.104.183
> set type=any
> ls -d mzcr.cz
[ns2.ksrzis.cz]
mzcr.cz. SOA kasel.mzcr.cz admin.mzcr.cz. (20170102
mzcr.cz. TXT "v=spf1 ip4:193.84.7.72/29 mx
mzcr.cz. MX 10 angina.mzcr.cz
mzcr.cz. MX 100 mail.ksrzis.cz
mzcr.cz. MX 1000 bb-brn.eunet.cz
mzcr.cz. A 81.0.239.195
mzcr.cz. NS ns2.ksrzis.cz
mzcr.cz. NS kasel.mzcr.cz
angina A 193.84.7.70
angina2 A 193.84.7.75
angina3 A 193.84.7.76
ap A 193.16.104.19
ap2 A 193.16.104.18
apwp A 193.16.104.17
archiv CNAME www.capitol.cz
branice A 193.84.7.65
chlap CNAME snzr.ksrzis.cz
crl A 193.16.104.172
czechhealth CNAME www2.mzcr.cz
czpres CNAME www.mzcr.cz
ciselniky.dasta A 62.77.77.254
www.ciselniky.dasta A 62.77.77.254
dotaznik CNAME www2.mzcr.cz
dotazniky A 81.0.239.198
eas A 193.84.7.10
email A 193.84.7.9
es A 193.84.7.8
espis A 195.122.195.65
espisskol A 193.16.104.14
ezp A 62.77.77.205
ezp2 A 62.77.77.205
ftp A 193.84.7.108
geoportal A 193.16.104.34
helpdesk A 193.84.7.70
hlukovemapy CNAME www.mzcr.cz
hlukovemapy2007 CNAME www.mzcr.cz
iga MX 10 angina.mzcr.cz
iga A 193.84.7.72
igatest A 193.84.7.73
kasel A 193.84.7.66
knihabezpeci CNAME www.mzcr.cz
ks A 82.208.40.28
legislativa A 81.0.239.195
localhost A 127.0.0.1
nated A 193.84.7.84
neco CNAME www2.mzcr.cz
nlk MX 10 nlk.mzcr.cz
nlk A 193.84.7.70
ns CNAME kasel.mzcr.cz
nsez CNAME www.mzcr.cz
ntb A 213.151.85.102
os A 193.84.7.11
outside A 193.84.7.8
ozn A 193.16.104.209
pandemie A 217.31.54.114
portalkvality CNAME www.mzcr.cz
post A 193.84.7.69
posta A 213.151.85.99
predsednictvivradeeu CNAME www.mzcr.cz
proxy A 193.84.7.68
reformanamiru A 217.31.54.118
ryma A 193.84.7.67
sms A 193.84.7.69
soubory A 193.16.104.195
ssl A 193.84.7.6
szv A 193.84.7.112
vnuzz A 77.93.199.33
www A 81.0.239.195
www2 A 81.0.239.196
mzcr.cz. SOA kasel.mzcr.cz admin.mzcr.cz. (20170102
>
V tomto případě již konfigurace serveru nebyla nejlepší a server obsah celé zóny ochotně vydal. Díky tomu jsme se byli schopni dozvědět o existenci skutečně všech subdomén.
Uživatelé Linuxu při přenosu zóny sáhnou pravděpodobně spíše k nástroji dig, nebo host, než k nástroji nslookup. Jejich použití zachycují následující (zkrácené) výpisy.
root@kali:~# dig @ns2.ksrzis.cz mzcr.cz AXFR
; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @ns2.ksrzis.cz mzcr.cz AXFR
; (1 server found)
;; global options: +cmd
mzcr.cz. 3600 IN SOA kasel.mzcr.cz. admin.mzcr.cz. 201701021 3600 900 604800 1800
mzcr.cz. 3600 IN RRSIG SPF 5 2 3600 20170323102151 20170102072923 59487 mzcr.cz. uyxFd2Dz6VLmibXWs3S/PUNqIJoPe+wMTsHS6SuuJp6cWUpGBCQbQzts xZkaEzyS7Drg6o4+1qt+DNF7t3ac66AAmm1P13qJnMtUcYf/KT6jYcpo iXQUADWCDro/FVkdP9JxuSJEDG1xrMi1+io3n69280e0NaRtohZlj+vD Hdc=
mzcr.cz. 3600 IN SPF "v=spf1 ip4:193.84.7.72/29 mx a -all"
mzcr.cz. 3600 IN RRSIG DNSKEY 5 2 3600 20170323102151 20170102072923 44764 mzcr.cz. X0hAeYlRPYf5PAT+uhQEWDmhhcWvgYIvAFqY55p+k4uavThLW9p8+dlF telYtWZYGyjg4pAODLdIIQlCicdPBW1LqDyKwcV7wPfbAm41uezuxlPP shb8QkK5y6Hycsvj5QJFRyTsnmDKPhnctCbj5z6SdGd4
…
root@kali:~# host -t axfr mzcr.cz ns2.ksrzis.cz
Trying "mzcr.cz"
Using domain server:
Name: ns2.ksrzis.cz
Address: 193.16.104.183#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35403
;; flags: qr aa; QUERY: 1, ANSWER: 262, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mzcr.cz. IN AXFR
;; ANSWER SECTION:
mzcr.cz. 3600 IN SOA kasel.mzcr.cz. admin.mzcr.cz. 201701021 3600 900 604800 1800
mzcr.cz. 3600 IN RRSIG SPF 5 2 3600 20170323102151 20170102072923 59487 mzcr.cz. uyxFd2Dz6VLmibXWs3S/PUNqIJoPe+wMTsHS6SuuJp6cWUpGBCQbQzts xZkaEzyS7Drg6o4+1qt+DNF7t3ac66AAmm1P13qJnMtUcYf/KT6jYcpo iXQUADWCDro/FVkdP9JxuSJEDG1xrMi1+io3n69280e0NaRtohZlj+vD Hdc=
mzcr.cz. 3600 IN SPF "v=spf1 ip4:193.84.7.72/29 mx a -all"
...
Při přenosu zóny můžete sáhnout také k on-line nástrojům, které přijdou vhod například ve chvílích, kdy má cílový nameserver Vaší vlastní IP adresu uvedenu na blacklistu, nebo pokud Vám úspěšné doručení zóny blokuje nějaké zařízení na cestě. Pokud v takové chvíli nemáte možnost připojit se například prostřednictvím VPN na jiný vzdálený systém, ze kterého byste přenos zóny provedli, nebo pokud prostě jen nechcete na cílovém serveru zanechat v logu svou IP adresu, pak se Vám on-line služby z následující tabulky budou zcela jistě hodit. Jejich použití je velice jednoduché a zcela intuitivní. Většinou se po Vás očekává pouze vložení domény, jejíž záznamy chcete získat. Zjištění odpovídajících NS záznamů a samotný přenos zóny, je pak plně automatické.
| On-line služby zprostředkovávající přenos zóny |
|---|
| https://hackertarget.com/zone-transfer |
| https://pentest-tools.com/network-vulnerability-scanning/dns-zone-transfer-check |
| https://www.ultratools.com/tools/zoneFileDump |
On-line zdroje
Stejně, jako jsme pro zjištění sousedů v předchozí kapitole využívali některé on-line služby, které podobné informace shromažďují, můžeme se na podobné veřejně dostupné zdroje s důvěrou obrátit také při enumeraci subdomén. V tomto případě bude stačit, pokud se dané webové aplikace zeptáme na doménu, jejíž subdomény nás zajímají. Ta se podívá do databáze svých záznamů a ochotně nám sdělí, které subdomény byly v historii na této cílové doméně spatřeny. Služby poskytující tyto informace, i když často se zcela jiným záměrem, jsou například ty z následující tabulky.
| Služby disponující seznamem známých subdomén | |
|---|---|
| Netcraft.com | https://searchdns.netcraft.com |
| Virustotal.com | https://virustotal.com |
| Shodan.io | https://www.shodan.io |
| https://github.com/achillean/shodan-python | |
V případě nástroje Netcraft stačí do vyhledávacího pole na webových stránkách vložit název cílové domény. Na následujícím screenshotu s výsledky vyhledávání si můžete všimnout, že kromě samotných subdomén je vráceno i několik dalších zajímavých informací.
Pro vyhledání subdomén na webových stránkách služby Virustotal je potřeba se nejprve přepnout na záložku hledat a teprve následně vložit do vyhledávacího pole hledanou doménu s uvedením prefixu domain:, jak je zachyceno na screenshotu.
Samostatnou kapitolu ve vyhledávacích službách tvoří Shodan.io. Běžné vyhledávače, mezi které patří například Google, Bing, Seznam, a mnoho dalších, prohledávají obsah webových stránek. Shodan.io oproti tomu indexuje a následně umožňuje prohledávat obsah HTTP response hlaviček. Díky tomu je pro kohokoliv snadné vyhledat na internetu různá hardwarová zařízení, jako jsou například IP kamery, ovládací prvky vodních a votlaických elektráren, nebo třeba konkrétní verze webových serverů. Při vyhledávání mohou zaregistrovaní uživatelé používat také nejrůznější filtry, z nichž se pro naše účely bude nejlépe hodit filtr hostname. Ten Vám umožní dohledat pouze zařízení (subdomény), které náleží konkrétní testované doméně.
Protože následné zpracování výsledků obdržených přes webové rozhraní není uživatelsky zrovna nejpříjemnější, nabízí Shodan také skript napsaný v pythonu, jež umožňuje automatizovat dotazy a získávat lépe formátované výsledky pro další použití. Následující obrázek zachycuje práci s webových rozhraním, který je následován výpisem, jenž obsahuje dotaz odeslaný prostřednictvím zmíněného skriptu.
shodan search --fields hostnames hostname:"tatrabanka.sk"
vportal.tatrabanka.sk
moja.tatrabanka.sk
smtp.tatrabanka.sk
www.tatrabanka.sk
dialog.tatrabanka.sk
kariera.tatrabanka.sk
ns2.tatrabanka.sk
psmtp.odpovede.tatrabanka.sk
tbwebex.tatrabanka.sk
ns.tatrabanka.sk
webextest.tatrabanka.sk
moja.tatrabanka.sk
ssmtp.odpovede.tatrabanka.sk
smtp2.tatrabanka.sk
Multifunkční automatické nástroje
Všechny výše uvedené postupy od dotazovaní se vyhledávačů a DNS serverů, přes testování zone transferu, až po vytěžování on-line zdrojů jsou za nás schopny zcela automaticky provést i některé nástroje k tomu určené. Jejich použitím si tak můžete ušetřit poměrně dost svého času. Podobně jako u nástrojů sloužících pouze k DNS enumeraci, i zde platí, že byste si měli všechny nástroje nejprve osahat, a na základě vlastní zkušenosti se teprve po té rozhodnout, které z nich budete ve své praxi následně používat. Jednotlivé nástroje se od sebe liší nejen možnostmi, které nabízejí, ale také kvalitou a formou výstupu, nutností zadání API klíčů k jednotlivým službám, apd.
| On-line nástroje umožňující enumeraci subdomén |
|---|
| https://pentest-tools.com/information-gathering/find-subdomains-of-domain |
| https://dnsdumpster.com |
| Nástroje umožňující enumeraci subdomén různými metodami | |
|---|---|
| Recon-ng | https://bitbucket.org/LaNMaSteR53/recon-ng/downloads |
| Sublist3r | https://github.com/aboul3la/Sublist3r |
| InstaRecon | https://github.com/vergl4s/instarecon |
| DNSenum | https://github.com/fwaeytens/dnsenum |
