Anonim hálózati all-in-one: Network Query Tool

Sokszor használjuk tesztelés során a Network Query Tool-t: ingyenes kis PHP szkript, amit számtalan helyen futtatnak szerte az interneten. Egy erőteljes google-kereséssel takaros listát állíthatunk össze. Az eszköz kezelőfelülete önmagáért beszél.



A leghasznosabb funkciója az, hogy többé-kevésbé anonim módon lehet portscannelni.

Port scanning 1x1

Sok kérés érkezett azzal kapcsolatban, hogy írjunk az nmap-ról bővebben. Az alábbi összefoglaló a BME "Unix/Linux rendszerek üzemeltetése" c. tárgyában elhangzott előadás jegyzete. A jegyzet a 4.20-as nmap-hoz készült, a legújabb (4.90RC1) verzió számtalan egyéb szolgáltatást is tud - ehhez tessék megnézni az nmap officiál dokumentációját. További ajánlott irodalom a "man nmap" :)

A portscannelésről általában

TCP/IP-s protokollstacket használva gépünk több, mint 65.000 különféle porton kommunikálhat. Egy portnak alapvetően hat állapota lehet:

• Open: a portra érkező csomagokkal foglalkoznak és van egy alkalmazás, amely reagál az ide érkező adatokra. A portscannelés legfontosabb célja, hogy az összes ilyet megtaláljuk.

• Closed: a port reagál a kérésekre, de nincs alkalmazás, amely használná.

• Filtered: a legidegesítőbb mind közül. A portot szűrik, és az nmap ebben az esetben nem tudja eldönteni, hogy open vagy closed állapotban van-e (azaz ha pl. egy tűzfallal kiszűrik valamelyik irányban a csomagokat, vagy kéréseink egy DROP-actionben végződnek a célgép iptables-beállításaiban.)

• Unfiltered: bár a csomagjainkat nem szűrik, az nmap mégsem tudja eldönteni a port állapotát. Az ACK-szkennelés eredményezi.

• Open/filtered: az nmap nem tud dönteni, hogy a port open vagy filtered. Az olyan szkennelési módoknál kapunk eredményt, amelyeknél az jelzi a port nyitott állapotát, hogy nem érkezik válasz (UDP, FIN, PROT, Xmas scantípusok).

• Closed/filtered: ld. feljebb, csak itt a close és a filtered között vacilálunk. IPID idle scan esetén.

Az nmap scantípusai

• sP: ping scan. Egyszerűen megpingeti a célpontol és ha választ kap, örülünk - máris van mire célozni a többi scantípust. Az alap mód az ICMP echo request/reply, ezt azonban mostanra sok helyen szűrik. Az ICMP azonban lehetőséget ad többfajta módra is, amivel a célpontot válaszra lehet bírni: ezeket nagyon nehézkes szűrni, és ha szűrik, fennakadásokat okoz a legitim hálózati forgalomban.
  • PE/PP/PM: ICMP echo, timestamp és netmask kéréseket küld a célpontnak.
  • PS/PA/PU: SYN, ACK és UDP csomagokkal bírja válaszra a célpontot. Fontos megjegyezni, hogy a -PS 80 működése nem azonos a portscannelés közbeni SYN csomagokéval: az előbbi célja egyszerűen annyi, hogy kiderítse, működik-e az adott IP-n valaki.

• sS: a default, SYN scan. A TCP-s háromutas kapcsolatfelvételi mechanizmus első (SYN) csomagját küldi el a célportra. Ha érkezik rá SYN/ACK, akkor a port open, ha RST, akkor closed állapotban van. Ha ICMP port unreachable vagy semmi sem érkezik, akkor a port filtered. A leggyorsabb és legkedveltebb az összes scantípus közül, viszont kellő körültekintéssel kell élni az intenzitás megválasztásánál: gyakorlatilag DoS is megvalósítható vele és figyelmes rendszergazdák szűrni szokták.

• sT: az aktuális oprendszer TCP protokoll-implementációjának connect() függvényét használja a kapcsolódásra, nem közvetlenül küldi ki a kapcsolatfelvételi csomagot. Akkor használatos, ha valamiért nem tudunk közvetlenül SYN csomagot küldeni (pl. nem root-ként indítjuk el az nmap-ot. Erre a „sorry, dude!” hibaüzenettel figyelmeztet is. Érdekes scantípus olyan szempontból, hogy ez a legzajosabb, ugyanakkor a legnagyobb rejtőzködést is ez biztosíthatja: zajos, mivel a kapcsolatokat minden esetben megpróbálja felépíteni, viszont megvan az az óriási előnye a többi scantípussal szemben, hogy proxyzható.

• sM, sF, sX, sN: Maimon, FIN, Xmas és NULL scan. Gyakorlatilag ugyanarra a logikára működnek: beállítunk egy bizonyos értelmetlen flagbit-kombinációt a TCP fejlécében, majd útjára engedjük a csomagot. A Maimonnél a FIN+ACK, FIN-nél csak a FIN, az Xmas-nél a FIN+PSH+URG flagek vannak bekapcsolva, NULL-nál értelemszerűen semmi. Az egész játék arra megy ki, hogy a TCP RFC-jét teljes egészében megvalósító implementációk eldobják az ilyen értelmetlen csomagot, ha a porton értelmes forgalmat várnak (azaz nyitva van) és RST-t küldenek vissza, ha a port closed. Butább állapotmentes tűzfalakon keresztül is működik a dolog, azonban mivel a figyelmes rendszergazdák is olvassák az nmap dokumentációját, könnyen szűrhető - másrészt az nmap lehetőséget nyújt arra is, hogy a nyolc flagbitet tetszés szerint kapcsolgassuk a tapogatózáshoz (--scanflags kapcsoló).

• sA: ACK scan. Különbözik az előzőektől – soha nem mondja azt, hogy a port open (ugyanis mindenképp RST csomag jön vissza, akármelyik állapotban is van igazából a port). Arra használatos, hogy a célgép előtt őrködő tűzfal szabályait puhatoljuk ki. A kipuhatolás olyan módon történhet, hogy megscannelünk egy gépet, amelyről biztosan tudjuk, hogy a tűzfal mögött található. Ha a tűzfal helyesen beállított állapottartó, akkor nem fogunk választ kapni a csomagjainkra (ugyanis ACK csomagok nem kezdhetnek legitim kommunikációt). Ha azonban figyelmetlenül van bekonfigurálva és egy-egy portot szabadon hagy, akkor a célgép RST csomagot fog válaszul küldeni függetlenül attól, hogy a simogatott port open vagy closed állapotban van-e. Az nmap ezeket a portokat unfiltered-ként fogja jelölni.

• sW: Window scan. Pontosan ugyanúgy működik, mint az ACK scan, viszont bizonyos rendszerek/implementációk esetén képes különbséget tenni a szűretlen portok open/closed állapotai között. Az alapötlet az, hogy a visszaérkező RST csomag TCP fejlécében a window mező értéke ezen implementációk esetében nulla, ha a port closed, viszont pozitív, ha open. Ha a éppenséggel nem jön be a window mezők különbözősége, széttárja a karját ésnem azt mondja, hogy unfiltered - ilyen értelemben pedig használhatóbb, mint a mezei ACK scan.

• sI: Idle scan. A legkifinomultabb mind közül - azon alapszik, hogy nem a saját gépünkről végezzük a scannelést, hanem egy Ártatlan Áldozat forgalmát manipuláljuk úgy, hogy végül is portscannelést hajtson végre a célgépen. Ennek megfelelően a scan eredménye azon portok listája lesz, amelyet az áldozat lát! A következőképp működik: az operációs rendszer minden általa kiküldött csomagnak egyedi számot ad: ez az IP fejlécben lévő IPID érték. Butább operendszerek (pl. Xp, vagy a legtöbb nyomtató oprendszere) inkrementálisan növelgetik ezt a mezőt az egymás utáni csomagok kiküldésekor. A Támadó két dolgot csinál egyszerre: egyrészt folyamatosan SYN csomagokat küld a zombi egy ismert, unfiltered portjára, amire az annak rendje-módja szerint válaszol. A kettes pályán olyan csomagokat küld a hálózatra, amelyek feladója a zombi, címzettje pedig a célpont: a célpont nyilván a zombinak fog válaszolni ezekre a csomagokra. A varázslat itt jön: ha a célpont nyitott portját szólította meg a csomag, akkor a zombi egy SYN/ACK-ot kap, amire neki RST-t kell küldenie. A kiküldött RST viszont ugrást fog okozni az egyes pályán, a támadónak visszaküldött RST-k (nyitott port esetén SYN/ACK-ok) IPID-szekvenciájában - a támadó pedig pont erre figyel. Számos tulajdonsága közül a tisztasága a legvonzóbb; a saját ip-tartományunk vagy MAC-címünk soha nem kerül a célpontra felügyelő IDS-ek elé. Hogy hogyan találhatunk zombit? Nagyon egyszerű: használjuk a Nessust, vagy az nmap -A kapcsolós scan után is megmondja.

• sO: Kitapogatja, hogy az IP-re épülő protokollok (UDP, TCP, ICMP, IGMP,...) közül melyekre hallgat a célpont, így igazából nem is portscanner a szó hagyományos értelmében. A TCP fejlécben beállítjuk a tapogatott protokoll azonosítóját, majd elküldjük a csomagot a célgépnek. A headerek korrekt kitöltésével a legtöbb esetben nem is foglalkozik az nmap: ha ICMP protocol unreachable érkezik vissza, akkor a protokollt closed-nak nyilvánítjuk. Ha érkezik válasz az adott protokollra, akkor open, ha pedig egyéb ICMP hibaüzenetet kapunk, a protokoll filtered. Ha az újraküldés után sem érkezik semmi, a protokoll open/filtered.

• b: FTP bounce scan. Az eredeti RFC szerint való FTP-szerverekben van egy feature, ami azt csinálja, hogy csatlakozva egy FTP-szerverhez kérhetjük, hogy a file-okat egy harmadik félnek küldje! (Egy ideális világban ezzel lehetne megoldani egyszerűen azt, hogy az A gépen ülő júzer a B gépen lévő fájlokat a C gépre juttassa úgy, hogy az A gépen csak a parancscsatorna megy keresztül, maguk a másolt fájlok nem.) Ezen a sec. hole-on persze egy tankhajó is keresztülfér, így aztán a legtöbb implementációban egyszerűen nem engedélyezik ezt a proxy-szerű funkciót. (Gondoljunk bele: pl. wardrivinggal lesniffelünk egy plaintext ftp-bejelentkezést, majd a megszerzett usernévvel-jelszóval feltöltjük az ftp-szerverre az exploit kódját és ha az ftp-szerver támogatja ezt a proxy-funkciót, akármelyik hosztra ráuszíthatjuk a vállalati hálózaton...) Portscanre eléggé triviális rávenni az ilyen ftp-proxyt: egyszerűen megmondjuk a célgép ip-jét és a minket érdeklő port számát és az ftp-szerver elvégzi a piszkos munkát azzal, hogy megpróbál áttölteni valamit.
• sU: UDP scan. A TCP-től eltérően az UDP kapcsolat- és állapotmentes, így a scan úgy történik, hogy egy üres UDP csomagot küldünk a célgép egy portjára. Ha ICMP port unreachable jön vissza, a port closed, ha egyéb ICMP hiba, akkor open/filtered. Ha értelmes válasz érkezik UDP-n, akkor a port nyitva van. Tipikus használati módok: DHCP, Kazaa, játékok stb. felderítésére (egyébként érdemes elgondolkozni, hogy a hentelés közben harmadszorra is felugró, figyelmeztető tűzfalablakon a felhasználók legnagyobb része mindent megenged az adott játéknak). A legnagyobb nehézséget az UDP-s scannelésben az jelenti, hogy megfelelő időlimitet válasszunk a port felé küldött csomagok között. Fontos megjegyezni, hogy bámelyik TCP-s scan móddal használható karöltve, TCP-s scanmódokat nem lehet egymással zatyulni!

Az NMAP portkezelése

Az NMAP lehetőséget ad arra is, hogy megadjuk a minket érdeklő portok listáját. Az alábbi kapcsolók segítségével érhető el a portkezelés:

• -p: megadható port, porttartomány. Ha -sO kapcsolóval együtt használjuk protokollscannelésre, a protokollok kódját kell értelmszerűen megadnunk.

• -F: gyorsított scannelés, a leggyakoribb portok listáját pörgeti végig. Ha kerülni szeretnénk a feltűnést, kiváló választás; az nmap_services file-ban lehet személyre szabni a listát.

• -r: nem keveri meg a kipróbált portok sorrendjét, hanem egyszerűen elindul az 1-esen és addig megy, amíg el nem éri a 65535-öt.

• --allports: nem hagy ki egy portot sem a portscanből. Általában érdemes átugrani a 9100-as portot, mivel sok nyomtató egyszerűen kiírja az ide érkező adatokat (ezáltal sok-sok mókusnak otthont adó erdőt kell kivágni az elpazarolt papír miatt, amint számtalan oldalnyi SSL-handshake-et vagy HTTP-kérést nyomtatunk nagy lelkesen).

Hátborzongatás

A fenti funkciók mellett az nmap még egy sereg dologra is képes, ezek között vannak elég hátborzongatóak is (jelen sorok írója például egészen elképedt, hogy egy háromnapos, tűzfalazott, otthoni használatra szánt Xp-n mennyi nyitott port is van és hogy az nmap a nyitott portok mellett egy sereg információt is megmond a gépről...) Ezen funkciók közül az operációs rendszer és a rajta futó szolgáltatások típusának és verziószámának(!) kiderítése a leghasznosabb - mind a rendszergazda, mind a Gonosz Cracker szempontjából.

A hátborzongató funkciók elérésére szolgáló kapcsolók az alábbiak:

• sV, A, : verziódetektálás. Az nmap a tcp stack tulajdonságai és különféle nem szabványos csomagokra történő válaszok alapján több száz oprendszert tud felismerni és ha nem biztos a dolgában, három-négy lehetőséget ad vissza.

• O: operációs rendszer detektálása. Az A kapcsoló tartalmazza.

• --version-intensity: azt állíthatjuk be vele, hogy mennyire gyanakodjon szokatlan helyeken futó szolgáltatásokra. 1-től 9-ig lehet értéket adni - minél magasabb, annál valószínűbb a helyes diagnózis, viszont annál hosszabb ideig tart a scannelés.

• --version-light: ~--version-intensity 2

• -sR: RPC-re szolgáló portok felderítésére használható. Portscan után végignézi a nyitott portokat és a SunRPC NULL parancsával elárasztja őket abban a reményben, hogy valamelyik válaszol. A verziófelismerés már tartalmazza ezt, így önmagában ritkán használatos - ha viszont gyanakszunk valamelyik portra, hogy RPC céljából van nyitva, jó választás.

"Udvariasság"

A portscannelést végre lehet hajtani pokoli gyorsan (a szerző tapasztalatai szerint egy 100Mbit-es egyetemi/kollégiumi hálózaton ideális esetben nem egész egy másodperc alatt végigpörgethetők a portok), azonban ez nagyjából annyira csendes és észrevehetetlen, mintha a zsebtolvajt egy teljes hangerőn játszó tűzoltózenekar követné. Nagyon könnyű észrevenni - ha IPS működik a célpont hálózatán, szinte biztos, hogy valamilyen szankciót fog bevezetni az IP-nkről érkező csomagokkal szemben, másrészt pedig feltehetőleg jelzi a rendszergazdának, hogy mi történt. Vannak célpontok persze, amelyeknél annyi portscan történik úgyis, hogy eggyel több vagy kevesebb semmit sem számít - ilyen pl. a google.com, a whitehouse.gov és társaik.

Az időzítési tulajdonságok szempontjából a legfontosabb szabály az, hogy a scan időigénye O(n*p), ahol n a simogatott hosztok, p a vizsgált portok számát jelenti. Ennek megfelelően egy több száz gépből álló (pl. vállalati) hálózat okos, csendes felderítése akár több napig is eltarthat.

A -M kapcsoló segítségével megadható a párhuzamosan scannelt portok max. száma, ilyen módon jó kis DoS támadásokat lehet végrehajtani az nmap segítségével. Csak kiadjuk, hogy

nmap -T 5 -M 1000 -sT 1.2.3.4

és várunk.

Jelmagyarázat: a lehető leggyorsabb portscan, egyszerre 1000 porton(!) próbálkozik egyszerre kapcsolatfelvétellel. A szerző saját, SP2 nélküli Xp professionaljét gyakorlatilag megölte az iménti parancs kikapcsolt tűzfallal, ha viszont be volt kapcsolva akárcsak a difót vindózos tűzfal, akkor is jelentős lassulást tapasztalt.

Tűzfalak, IDS-ek és egyéb házörzők

Az nmap számtalan opciót tartalmaz, amely igyekszik minél nehezebben felderíthetővé tenni a tevékenységét. Ezt az nmap fórumain néhányan nehezményezik: szerintük túlozottan megkönnyítik a crackerek dolgát azzal, hogy konkrét eszközöket integrálnak tűzfalak és IDS-ek elkerülésére az nmap-ba. Az nmap készítői azzal reagáltak a felvetésekre, hogy mivel a szoftver open-source, előbb-utóbb valaki biztosan beleteszi ezeket az opciókat, így viszont a rendszergazdák is próbára tehetik saját hálózatuk biztonságát.

A mezei portscan elég egyszerűen észrevehető, ha nem kellő körültekintéssel választjuk meg a paramétereit: lényegében egy olyan egyszerű, netflow statisztikákat megevő algoritmus is elég jól detektálja, amely egyszerűen a 60byte-os csomagokra érkező 40byte-os válaszokra figyel. Ha ilyenből egy hoszt sokat összeszed, akkor valószínűleg portscant hajt végre.

Csomagszinten figyelő tűzfalak és IDS-ek kijátszására jók az alábbi kapcsolók:

• f: ezen kapcsoló használatakor a simogató csomagok nem egyben érkeznek meg a célpont közelébe, hanem apró fragmentek formájában - a célpont úgyis összerakja őket, viszont ha a csomag részeit külön-külön megvizsgálja egy csomagszűrő tűzfal, sokkal nehezebb dolga lesz a portscan azonosításakor. Az IP fejléc mögé 8byte-os adagokba pakolgatja a TCP header darabkáit - így pl. egy 20byte-os csomag helyett hármat küldünk ki, 8 byte-os mérettel. Óvatosan bánjunk ezzel a kapcsolóval, ugyanis sok kiszolgáló nem tudja megfelelően kezelni ezeket a parányi csomagocskákat, így előfordulhat, hogy a szolgáltatás felfedezése helyett jól seg.faultra futtatjuk a kiszolgálót. Kis kitérő: fragrouter.

• --mtu: a paraméterül megadott MTU értéket veszi figyelembe, nyolccal oszthatónak kell lennie. Ekkora fragmentekben küldi ki az összes csomagot (még a ping-et is). Az -f kapcsolóval együtt nem használható.

• D: decoy scan használata. Hamisított TCP/IP fejlécek segítségével a célpontban (és a körülötte őrködőkben) azt a (tév)képzetet kelti, hogy a portscan nem csak a mi címünkről jön, hanem az összes, a listában megadott hoszt egyszerre scanneli a célpontot. Ez persze nagyon hasznos, ugyanis a célpontnak fogalma sem lesz arról, hogy melyik támadó az igazi. Mindazonáltal óvatosan kell eljárni az ilyen "beárulásokkal", ugyanis a célpont a portscanre küldött csomagokat a "beárult" hosztoknak is elküldi, ilyen módon floodolja őket és csinosan leterheli a hálózatot. A kapcsoló szintaktikája szerint a "beárult" hosztokat vesszővel kell elválasztani és akár a saját IP-t jelentő ME string is beletehető. Az nmap fejlesztői szerint a hatodik helyre bebökve a legtöbb portscan-detektor nem fogja észlelni a címünket a sok hamis cím között (a szerző ezt némileg kétkedve fogadja, de ám legyen.) Kis kitérő: mire jó ez? Milyen esetekben lehet komoly szolgáltatáskiesést okozni?

• S: IP-cím spoofolása. Bővebb magyarázatot nem igényel. Házi feladat: vajon mire lehet jó?

• --source-port: forrásport meghamisítása. Hasznos pl., ha a tűzfal forrásport alapján szűr (pl. ha gonosz módon az irodából szeretnénk portscannelni, de csak a 80-as van kiengedve.) Másrészt aktív FTP-szerverekkel történő kommunikáció esetében vonzó lehetőség, hogy a buta tűzfalon nyitva hagyjuk az utat azoknak a kapcsolatoknak, amelyek a 20-as portról érkeznek (azaz a szerver számára lehetőséget biztosítsunk arra, hogy visszakapcsolódjon a kliensre). A crackerek számára egyébként ez a hozzáállás termi meg leginkább a gyümölcsét: a lusta rendszergazdák nem csinálják meg a bonyolult, ám biztonságos megoldást, hanem egy olyat vezetnek be, amelyik egyszerűen megcsinálható még az ebédszünet előtt, viszont kis tapogatózás után kihasználható.

• --data-length: lehetőség van arra is, hogy random számokkal töltsük fel a csomagjaink payload részét (alapból ugye payload nélkül küldi ki a csomagokat, ami meg elég könnyen detektálható). Érdemes megnézni egyébként pl. a snort nmap-ra vonatkozó szabályait, ezeket egyesével lehet kicselezni különféle kapcsolókkal. Házi feladat: nézzétek meg a snort.org szabályai között az nmap-osakat, és cselezzétek ki őket! Nagyon tanulságos játék egyébként...

• --ip-options: a megadott IP-fejlécmezőkkel küldhetjük ki a csomagjainkat. Gyakorlatilag az összes fenti opciót megadhatjuk így, de ezzel lényegében teljesen testre (és hálózatra) szabhatjuk a scant.

• --randomize-hosts: ha több scannelt célgépet adunk meg, ezzel véletlenszerű sorrendben veszi őket, ezáltal nehezítve a házőrzők dolgát.

• --spoof-mac: önmagáért beszél. Megadhatunk gyártót is (ebben az esetben a fennmaradó byte-okat véletlenszerűen tölti ki az nmap).

• --badsum: helytelen ellenőrző összeggel küldi ki a csomagokat. Mivel ebben az esetben a célpont nem dolgozza fel a csomagot, ha választ kapunk ilyenre, akkor az szinte biztosan egy checksumot nem ellenőrző tűzfaltól jött.

Mire jó az nmap?

A fenti kapcsolókkal szó szerint több ezer üzemmódban lehet használni a kicsi, parancssoros nmap-ot. Mire lehet használni? Csak néhány tipp:

• Hálózatra betörve portok feltérképezése.
• Tűzfalak szabályrendszerének kiderítése.
• DoS (no comment...)
• Tömeges reverse DNS-feloldás.
• ARP táblák ellenőrzése lokális hálózaton.
• Hálózatmonitorozás (á la Nagios).
• Szolgáltatásmonitorozás.
• Hálózati eszközök katalógusának automatizált összeállítása.
• Hálózati eszközök terhelésvizsgálata (stress test).
• Szolgáltatások terheléses vizsgálata (pl. Apache).
• Stb.

Diszkimage-ből bootolható vmware virtuális gép

Forensic munkák során sokszor van (lenne) szükség arra, hogy elindítsuk az image-elt munkaállomást virtuális gépben: kézzel ez meglehetősen macerás munka, ugyanis az image-hez kell(ene) illeszteni a virtuális merevlemez fizikai méreteit, illetve egyéb beállításokat eszközölni a virtuális partíciós táblában és az MBR-ben.

Nemrég akadtunk rá erre a zseniális kis eszközre, ami képes arra, hogy vwmare image-et készítsen egy raw image-elt (pl. *dd) gép merevlemezéről. Tapasztalatok szerint windowsos image-ekkel egészen jól elboldogul.

Hálózati vizsgálatok 1. - Buta tűzfalak szabályrendszerének vizsgálata

Betörési tesztek során gyakran kerülünk olyan feladat elé, amikor meg kellene állapítani valamely TCP szintű tűzfalról, hogy milyen szabályrendszert alkalmaz.

A TCP szintig figyelő tűzfalak meglehetősen hatékonyak (legalábbis megfelelő hardverrel megtámogatva elképesztő mennyiségű forgalmat tudnak szűrni), és egyszerűen karbantarthatóak, konfigurálhatóak: definiálunk egy szabályrendszert, amely a "megfelelő", "szép" hálózati forgalomra jellemző, és a tűzfalunkra rábízzuk, hogy betartassa a szabályrendszert a rajta áthaladó forgalmon.

Alapvetően IP/PORT/irány -> go-nogo alakú szabályokat szokás definiálni, azonban a legtöbb tűzfal (már a fapados iptables is) jóval összetettebb szűrési módokat is ismer - lehet figyelni pl. egy TCP kapcsolat állapotát, lehet adatmennyiség-forgalmazási határokat definiálni, esetleg az egyszerre nyitva tartott kapcsolatok számát korlátozni: a gyakorlat azonban azt mutatja, hogy a legtöbb tűzfalon megmaradnak a szabályok az egyszerű portát(nem)engedésnél.

Egy jól működtetett informatikai infrastruktúra esetében minden tűzfalra dokumentálva vannak az implementált szabályok - white-box vizsgálatoknál tipikus esetben a tesztelők megkapják az elvárt szabályrendszer listáját és egy UTP-kábelt, amin ellenőrizniük kell, hogy valóban az történik-e a tűzfalon, amit elvárnak. Milyen lehetőségek állnak a tesztelők előtt ekkor?

ACK-scan
Az ACK-scan lényege az, hogy csomagokat küldünk a tűzfal "túloldalán" ülő hosztnak, amelyekben egyedül az ACK bit van bebillentve. Ha célhoz érnek a csomagok, mindenképp RST fog válaszul jönni - a cél nem tud mit kezdeni a csomagjainkkal.

Az igazán érdekes dolog itt az, hogy megérkeznek-e a válasz RST-k: ha igen, a tűzfalunk átengedi a vizsgált portot.

Firewalking
A firewalking az IP TTL-t használja ki: arra való a TTL, hogy a valahonnét valahová tartó csomagok előbb-utóbb lekerüljenek a hálózatról, ha esetleg kör lenne a routerek között, vagy egyéb probléma jönne közbe. A TTL-t a küldő beállítja valami értékre, és minden eszköz, amin áthalad a csomag, eggyel csökkenti az értéket: ha eléri a nullát, a legutolsó eszköz (többnyire) küld a feladónak egy ICMP TTL Exceeded üzenetet, de az eredeti csomagot nem adja tovább.

A legtöbb tűzfal (hiszen valamilyen operációs rendszeren fut, valamilyen TCP/IP stack-implementációval) szintén csökkenti a rajta áthaladó csomag TTL-jét: a vizsgálat során ezt használjuk ki. A folyamat két lépésből áll: első körben megtudjuk, hogy hányadik eszköz a sorban a tűzfal a gépünktől (hányadik hop). A hop-szám ismeretében beállítjuk a tűzfalon átjuttatni kívánt csomagok induláskori TTL-jét hop-számnyira, és elküldjük egy, a tűzfal túloldalán ülő hosztnak minden portjára a csomagjainkat - ha a tűzfalunk eldobja (azaz szűri), nem érkezik válasz, míg az átengedett csomagok esetében visszakapunk egy ICMP TTL Exceeded csomagot.

Válaszüzenetek analízise
Nem önmagában van értelmezve: az előző kettő, illetve tetszőleges, a tűzfalra mutató portscanning során érdemes figyelni azt, hogy milyen válaszok jönnek a tapogató csomagjainkra. Az nmap --reason kapcsolójával megmondja, hogy egy filtered portot azért mutat filtered-nek, mert nem érkezett válasz, vagy esetleg visszajött egy ICMP Administratively Prohibited üzenet.

Zárak

A fizikai biztonsággal meglepően keveset foglalkoznak (khm... foglalkozunk) szakmai fórumokon. A tavaly decemberi DefConon tartott előadás és workshopról készült, kimondottan érdekfeszítő videó.

Webalkalmazások biztonsági hibái - 10. Lefordított alkalmazások

Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.

Sok webalkalmazás alkalmaz valamilyen beágyazott/lefordított kódot: ezek az esetek nagy részében csodaszépen animált menüket, izgőmozgó bannereket, esetleg az oldal betöltésekor megjelenő és az oldalt kiszürkítő "KATTINTS IDE OLCSÓ REPÜLŐJEGYEKÉRT!"-feliratot jelenítenek meg, de láttunk már példát arra is, amikor valamilyen üzleti funkcionalitást valósítottak meg ilyen módon.

Az ilyen "beágyazott" kódok kapcsán két technológia terjedt el: a java appletek és a flash. Nagyon sokban hasonlítanak - az eszközöket leszámítva ugyanazok a biztonsági problémák mondhatóak el velük kapcsolatban.

A flasht és appleteket nem túl nehéz programozni, ugyanakkor szerveroldalon nem igazán foglalnak működéskor erőforrást, ugyanis a varázslat nagy része a kliens böngészőjében történik, a kliens processzoridejét használva. Flash és java sandbox specifikus biztonsági is résből sok van, de a legizgalmasabb az a lehetőség, hogy viszonylag egyszerűen dekompilálhatóak a böngésző által futtatott .swf fájlok és appletek.

Maga a visszaforgatott kód is érdekes (lehet), azonban a legizgalmasabbak azok a pillanatok, amikor a lefordított kódból adatforgalom történik - a használt URL-eket a legtöbb dekompiler eszköz szépen kigyűjti. Tapasztalataink szerint a bevésett URL-ek mögött figyelő függvények a legritkább esetben alkalmaznak bármilyen ellenőrzést, validációt az inputokkal kapcsolatban: nem egy on-line flash játékban érhető el a highscore-listában 999.999.999 pont a 99. szinten azzal, hogy a submitkor meghívott függvényt böngészőből is meglátogatjuk egy megfelelően összeállított HTTP-kéréssel. (Vissza)fordítással nagyon egyszerűen megnyerhető a legtöbb on-line kvíz is, ami szépen animált flashes felülettel operál, ugyanis a függvények törzsében ott van a legtöbb esetben plain-textben a kérdésre adandó helyes válasz.

Teszteléssel appletek, flash objektumok vizsgálatával sok esetben kiegészíthető a webalkalmazásról a mapping fázisban alkotott képünk: a háttérrendszerből/webalkalmazásból letöltött képek, adatok, információk URL-je sok esetben árulkodó lehet. Amennyiben valamilyen biztonsági kontroll megvalósítása történik beágyazott kódok segítségével, visszaforgatással ezen kódok, algoritmusok ellenőrzése is megoldható.

Klasszikus java decomplier itt, flashesből a legjobb a HP által bekebelezett SWFscan.

Forensic vizsgálatok 5.- Időpecsétek és fájlszignatúrák

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.

Az időpecsétekről bővebben
Az időpecsétekről már írtunk korábbi bejegyzésekben - rövid ismétlés: NTFS alatt négyféle időbélyeg tartozik egy-egy fájlhoz: ACME (Accessed, Created, Modified, Entry modified), ezeknek kritikus szerep jut a timeline összeállítása során. A népszerű profi forensic eszközök, mint pl. az EnCase, az Autopsy az időbélyegek alapján automatikusan kigyűjtik a fájlrendszer metaadataiból a törlések, létrehozások stb. idősorrendjét.

Az NTFS időpecsétek azonban nem csak egy helyen tárolódnak: az $MFT fájlban az egyes fájlokhoz tartozó leíróban nem csak a Standard Information mezőben, hanem a File Attribute mezőben is találhatóak ACME időpecsétek: a legtöbb fájlkezelő és forensic eszköz csak a Standard Information mező tartalmát veszi figyelembe, a másikat békén hagyja. A két mező közül az SI időpecsétek minden alkalommal frissülnek, az FA csak a fájl másolásakor/áthelyezésekor - ebből annyi jön, hogy az SI pecsétek elvileg nem lehetnek korábbiak, mint az FA pecsétjei: ha mégis, akkor valószínűleg valaki játszott a pecsétekkel.

Egy példa technet blogjáról (az ntfs.txt fájl a "sima" időpecsétek szerint 1601-ben keletkezett, 1801-ben nyúltak hozzá és 2008-ban nyitották meg utoljára, viszont az NTFS $MFT-ben láthatóak az érvényes, igazi időpecsétek.)

A fájlszignatúrákról még egyszer
A fájlszignatúrákat módosító posztban mondtuk, hogy nagyon egyszerűen lehet maszkírozni a fájlunkat különféle típusok között - jöttek visszajelzések arról, hogy mutassunk példát. Lássunk egyet!

zsombor@jester:~$ cat bela
Nem vagyok vegrehajthato!
zsombor@jester:~$ file bela
bela: ASCII text

Egyértelmű a kép: a bela fájl szöveget tartalmaz, a file parancs egyértelműen észre is veszi. De mi van, ha...?

zsombor@jester:~$ cat bela
MZ Nem vagyok vegrehajthato!
zsombor@jester:~$ file bela
bela: MS-DOS executable

Nocsak-nocsak. Ha megnézzük egy forensic céleszközzel az állományt:


Tanulság: ne bízzunk a céleszközeinkben sem!

Webalkalmazások biztonsági hibái - 9. Szerveroldali input kontrollok

Betörési tesztjeink során gyakran találkozunk azzal a jelenséggel, hogy a weboldalak fejlesztői ugyanazokat a hibákat követik el újra és újra. Ezen klasszikus hibákat egy több részből álló sorozatban szeretnénk bemutatni.

A biztonsági hiányosságok eddig tárgyalt területei között érintettük az inputvalidációs kontrollok témakörét: szó esett már a kliensoldaliakról, a szerveroldali kontrollok tárgyalásával még adósak vagyunk.

A szerveroldali kontrollok kiemelten fontos szerepet játszanak egy alkalmazás biztonságának szempontjából: ez az, ami "megvédi" az alkalmazás logikáját, az általa kezelt adatokat a rosszindulatú felhasználók által adott "trükkös" inputoktól. A sessionkezelés mellett ez a másik olyan terület, amit nagyon nehéz jól csinálni, viszont minden webfejlesztő beleütközik - emiatt számos példát láthatunk rosszul megvalósított validációs kontrollokra: minden olyan sikeres támadás, aminek a neve "injection"-re végződik, innét eredeztethető (SQL, XSS, Javascript, LDAP stb.)

Milyen hibák vezetnek ide?

A kerék újbóli feltalálása.
A legtöbb webprogramozó valamilyen módon megoldja az inputok validációját, azonban sok esetben saját validációs függvénycsaláddal történik a feladat megoldása: ezeket a legegyszerűbb kicselezni. Sokkal hasznosabb és hatékonyabb, ha a használt keretrendszer által biztosított validációs eszközöket használják - a keretrendszerek általában biztosítanak ilyen lehetőséget. Tessék élni velük!

Doboz típusú validáció.
Gyakori programozói hanyagság, ha a fejlesztő megírja Az Inputvalidáló Függvényt, és mindenfajta inputot ezen ereszt keresztül, függetlenül attól, hogy milyen típusú az input (szöveges, szám stb.), illetve mi fog történni az adott inputtal a továbbiakban. Ez a megközelítés csak akkor indokolható, ha (biztonság)tudatos programozói döntés eredménye, és megfelelő körültekintéssel történik az implementáció: például egy keresési mező tartalma egyrészt bekerül egy SQL query-be (SQL injection), másrészről visszaíródik a felhasználó képernyőjére (XSS) - ebben az esetben mind XSS, mind SQL injection szempontjából validálni kell(ene) a beérkező adatokat - például tipikus hiba, hogy az SQL metakaraktereket szűrik, viszont javascriptet könnyedén lehet injektálni.

Negatív szemléletű validáció.
Negatív szemléletűnek nevezünk (itt) minden olyan validációs módot, amely bizonyos nem kívánatos karakterek, minták szűrését végzi: ilyen például a <,>,\,",' stb. karakterek eplicit filterezése az SQL injection elkerülésekor.

Egy probléma van ezzel a megközelítéssel: nevezetesen az, hogy annyiféleképp lehet ártó módon injektálni az input mezőibe, hogy ezek ellen egyesével védekezni teljesen esélytelen: az XSS-injektálás lehetőségeiről kiváló XSS CHEAT SHEETet találhatni kattintás után.

Sokkal egyszerűbb és hatékonyabb megoldás az, ha pozitív módon állunk a problémához: ha számot várunk, akkor bizony illeszteni kell egy ^[0-9]*$ alakú regexpet a mezőre, és máris jóval nehezebb ártó kódot bevinni.

Egy másik példa: az böngészők is, és az MSSQL is mindenféle egzotikus karakterkódolásokat támogatnak, emiatt a kínai karakterkészletben szereplő, '-hoz hasonló karakter átjut a sima SQL metakaraktereket kereső validáción, viszont az adatbázisszerver előzékenyen kicseréli a valódi ' karakterre - ezt pedig nem nagyon lehet megfogni negatív validációval (a támadás nem túl régi, SQL smugglingnak keresztelték el.)

A validálóeszköz megrágás után továbbengedi az inputot.
Nem kevésbé veszélyes az sem, ha a validátor megpróbálja jól formálttá tenni az inputot: némi kísérletezéssel könnyen ki lehet ismerni a validátor logikáját, és kicselezni. Például tegyük fel, hogy a validátor XSS-támadás kiszűrésére a <> sztringet keresi, és szűri ki. Az alábbi két sztring például keresztüljut a PHP-s ellenőrzésen:

>< scri < script > pt > alert(document.cookie) < scr < /script > ipt>
% 00 < script > alert(document.cookie) < /script >
Az a legbiztosabb, hogy ha az alkalmazás hibaüzenetet jelenít meg, és semmiképp sem engedi tovább a folyamatot.

Forensic vizsgálatok 4. - Nagy Testvér szemmel tart

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.

Az adatrejtős posztban arról írtunk, hogy az adatrejtők miért vannak előnyben az adatvadászokkal szemben – a kép úgy teljes, ha írunk arról is, hogy az adatvadászok miért vannak előnyben az adatrejtőkkel szemben: az ugyanis, hogy a felhasználó milyen tevékenységet végzett, milyen fájlokat nyitott meg stb. az incidenst megelőzően, meglepően sok helyen nyomot hagy maga után. A felhasználói tevékenység rekonstrukciója kapcsán már írtunk a registry elemzéséről, van azonban számtalan egyéb hely is, ahol érdemes kutakodnunk nyomok után.

Recycled bin
A kuka kezeléséről és forensic elemzéséről sok helyen írtak már. Az alapvető működését mindenki tudja: amikor csak letörlünk egy fájlt, nem törlődik igazából, hanem a windows átnevezi, és speciális flaggel jelöli meg. A kuka fizikailag minden meghajtón a RECYCLER mappát jelenti (Xp alatt így hívják, más verzióknál Recycled bin stb. lehet a neve).

Ha total commanderrel belenézünk, ilyen jellegű fájlokkal van tele, hogy Dc1.exe, Dc2.txt: a D jelenti azt, hogy „deleted”, a „c” jelenti az eredeti meghajtó betűjelét, a szám pedig elkülöníti a fájlokat. Az oprendszer onnét tudja, hogy honnét törölték a fájlokat, hogy tart egy info2 nevű adatbázist a kukában, amely megmutatja a törölt fájlok metaadatait.

Recycle bin-ből is törölt fájlok
A kukából törölt fájlok nem semmisülnek meg, továbbra is ott vannak a lemezen, megfelelő eszközzel visszanyerhetőek. Annyi kis kiegészítést tennénk, hogy akkor sincs veszve minden (adat), ha a törölt, nagyméretű fájlunk bizonyos fragmentjei felülíródnak, ugyanis az operációs rendszer rendszerint nagyobb clustermérettel dolgozik, mint a fájlrendszer (Xp/NTFS-nél ez 4096byte vs. 512byte): ez azt jelenti, hogy az Xp 4096byte-os szeletekben írja fel a lemezre a fájlokat teljesítményokokból, és csak annyi null-t ír a tényleges adat mögé, hogy osztható legyen 512byte-tal az adattartalom, a 4096byte végéig terjedő részt békén hagyja (azaz megmarad benne az eredeti adat).

Népszerű tévhit, hogy a töredezettség-mentesítés megöli a slackekben található adattartalmat. Az a helyzet, hogy a defrag egyrészt nem biztos, hogy hozzányúl az adott, megsemmisíteni kívánt fájlhoz, másrészt ha hozzányúl is, 4096byte-os egységekben mozgatja az adatokat, tehát a slackeket ugyanúgy meghagyja, csak máshol kell őket keresni a lemezen. A legbiztosabb az a megoldás, ha valamilyen wiper eszközzel semmisítjük meg a nagyon törölni kívánt fájlokat.

Az UserAssist
A registry-s posztban írtunk már róla: a felhasználó által valaha elindított programok listája a HKCU\Software\Microsoft\windows\CurrentVersion\Explorer\UserAssist\GUID\Count kulcs alatt található ROT-13 encodinggal. A kulcsban lévő bináris időpecsét elárulja windows timestamp formátumban az utolsó elindítás idejét, illetve a mellette lévő (a kulcs 5-8. byte-ját elfoglaló) hexa érték megmondja, hogy hányszor indították el az adott programot (igaz, le kell vonni belőle valami egészen elképesztő okból ötöt).

.LNK fájlok vizsgálata
A .LNK fájlok parancsikonokat jelölnek – parancsikonok jellemzően háromféleképp keletkeznek: egyrészt telepítők szórják őket szanaszét, másrészt maguk a felhasználók teszik őket ide-oda, harmadrészt egy csomó funkció használatakor (pl. Recent documents) linkeket helyez el az oprendszer.

A linkekből bináris túrással rengeteg hasznos infót lehet kinyerni: például hogy mikor készítették, mikor indították el utojára a parancsikont, mikor módosították utoljára. Az NTFS-es ACM timestampekkel összetéve meglehetősen nagy biztonsággal megállapítható, hogy a felhasználó tette-e oda, vagy a telepítő: ezáltal adott esetben bizonyítható, hogy egy parancsikon mögött lévő XLS-t a felhasználó bizony megnézett egy adott időpontban, bármit is mondjon.

My recent documents
A fenti mappa a „c:\documents and settings\%USER%\My Recent Documents” alatt lakik, és parancsikonokat tartalmaz, emiatt a fenti vizsgálatok az itt található elemekre is elvégezhetőek.

Thumbs.db
A thumbs.db fájlok jellemzően képek mellett bukkannak fel a windows Xp-ben, a Vistában már máshogy oldották meg a feladatot. OLE-embedded streamek formájában előnézeti verzióit tárolják a képeknek, ezen előnézeteket viszont nem frissíti automatikusan, valahányszor változás történik a mappa tartalmában. Az elemzés során érdemes ezekkel is foglalkozni: itt egy ingyenes eszköz, amellyel megnézhető a tartalmuk.

Prefetch
A Prefetch olyan mechanizmus, amely felgyorsítja a gyakran használt alkalmazások betöltését: a c:\windows\prefetch mappában .pf fájlok formájában tárol információkat a gyakran elindított programokról. Megtudható belőlük, hogy hányszor indították el az adott programot, illetve mikor történt az utolsó elindítás.

History
A history a „c:\documents and settings\%user%\local settings\history” mappában található, és meglepő módon a megnyitott fájlokkal, meglátogatott oldalakkal kapcsolatos információkat tartalmaz (mikor nyitották meg utoljára és hány megnyitás történt idáig). A Windows File Analyser eszközzel egyszerűen lehet böngészni a tartalmát.

Firefox history
A Firefox által használt sqlite adatbázis elemzéséről már írtunk korábban, tessék kattintani.

Cookie cache/Flash cache
A cookie/flash cache-ben tárolódnak a weboldalak által kiadott cookie-k, emiatt látható belőlük, hogy a felhasználó milyen weboldalakat látogatott meg.

Temp
Átmeneti fájlokat sok helyen találhatunk a windowsban: a környezeti változók között lehet megtekinteni a listát. Tipikus helyek a c:\windows\temp, a c:\documents and settings\%user%\local settings\temp[orary internet files]: innét az esetek nagy részében egészen pontos képet kaphatunk arról, hogy a felhasználónk mivel tölti a gépidőt.

Eventlog, security log
Ne feledkezzünk el az öregekről sem: a felhasználók tevékenysége sok esetben generál bejegyzéseket a különféle logokban.

Forensic vizsgálatok 3. - Adatrejtés Windows alatt

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.

Az adatrejtés meglehetősen szerteágazó dolog; sajnos azt kell mondanunk, hogy - mint látni fogjuk - az adatrejtők lépéselőnyben vannak a nyomkeresőkkel szemben. Lássunk néhány módot, hogy hogyan lehet adatokat rejteni például a windowsban!

• Fájlattribútumok. Az egyik legegyszerűbb fájlrendszerbeli rejtési mód, ugyanis a "normál" explorer, illetve fájlkezelők beállítástól függően nem mutatják a hidden/system attribútumú fájlokat. Nagymértékű adatrejtést nem nyújt, néhány kattintással ki lehet cselezni.
  
• Átnevezés. Nem sokkal összetettebb módszer, ha átnevezzük az elrejteni kívánt (például a vezetőség bérezését tartalmazó xls) adatot MSVCIRT.dll-re, és beletesszük a c:\windows\system32 mappába: itt annyi minden található amúgy is, hogy célzatos keresés nékül nem valószínű, hogy akár sasszemű adminisztrátorunk is ráakadna: a windows API a fájlok típusát a kiterjesztésük alapján kezeli, és a HKEY_CLASSES_ROOT registrykulcsban tárolja, hogy melyik típussal mit kell/lehet csinálni.
  
• Átnevezés okosan, szignatúraátírással. A fenti módszernek egy komoly hátránya van: a fájl neve hiába .dll, attól még xls marad, emiatt az eredeti fájlszignatúra megmarad a fejlécben. Tipikusan az első néhány bájt alapján megmondható, hogy itten ellentmondás van a fejlécinformáció és a kiterjesztés között: a sima átnevezést leleplező, éjfélkor lefutó okos kis perl szkriptet meg lehet bolondítani azzal, hogy hexaeditorban megváltoztatjuk az xls fejlécét dll szignatúrára (gyakorlatilag egy MZ karakterfüzért kell beletenni az első két bájt helyére: ez a végrehajtható fájlok szignatúrája. Ilyenek a dll, ocx, sys, srv, exe kiterjesztések). Ekkor már a fájltípust szignatúra alapján megtippelő eszközök is megbolondíthatók bizonyos szintig (természetesen tüzetes vizsgálat után továbbra is kiderül, hogy nem dll a fájlunk a fejléc ellenére sem, de itt a felfedezést már komolyan akarni kell).
  
• Átnevezés nagyon okosan, időpecsétekkel. Az átnevezős/szignatúramatatós módszernek van egy óriási hátránya: ha megnézzük a fájlok keletkezési időpontjait, akkor az utólag odatett fájlok idői bizony úgy fognak kilógni a többi közül, mint egy fájó hüvelykujj. Az NTFS négy időpecsétet rendel az egyes fájlokhoz: ezek az ACME (Acessed, Created, Modified/Written, Entry modified), és a dir /t[acw] kapcsolókkal elhet kilistázni őket. Természetesen egyik sincs kőbe vésve: a metasploit project antiforensics szekciójában található timestomp eszközzel tetszőlegesen lehet módosítani az időpecséteket.
• Alternate data streams használata. Az egyik legrégebbi windowsos adatrejtési módszer: azon az NTFS szolgáltatáson alapszik, hogy lehetséges kiegészítő információkat hozzárendelni fájlokhoz, ezek egyszerű listázáskor nem látszanak és logikailag a fájl végéhez kerülnek a fájlrendszerben és semmilyen "hagyományos" listázási móddal nem lehet előhozni őket (a helyet attól még foglalják, tehát vigyázni kell a túl nagy fájlok elrejtésekor). A windows itt tárolja a fájlokhoz tartozó metaadatokat (pl. thumbnail, vagy a tulajdonságlapon található bejegyzések) Például: echo kiskutya > bela.txt:rejtettfile.txt, előhozás: notepad.exe bela.txt:rejtettfile.txt. Hogy lehet megszabadulni ezektől az ADS-ektől? Több eszköz is használható, az egyik legjobb az lads.exe, a SysInternalstól, vagy egész egyszerűen átmásoljuk a fájlt egy nem NTFS-partícióra (pl. ext3), vagy FTP-n töltjük le, ugyanis az FTP terminál az EOF karakter elérésekor. Megjegyzés: a netről letöltött chm fájlok megnyitásához is használható ez a trükk, ha a chm viewer 404-es hibát ad az oldalak megnézésekor. Több vírus is használta ezt a módszert. Forensic szempontból fontos információ, hogy ADS-ekre nem definiálhatók külön ACL-ek, emiatt egy felhasználó csak akkor hozhat létre ilyeneket, ha amúgy írhatja a fájlt, amihez hozzácsatol.
  
• ADS nagyon alattomos módon. A windows dll-jei mögé is lehet ADS-t tenni, viszont ez különösen alattomos mód akkor, ha a dll cache-ben lévő példányok mögé szúrjuk az ADS-t, ugyanis hiába törlik le a munkapéldány mögül az ADS-eket, a windows szépen visszamásolja őket a WFT (Windows File Protection) keretében. A cache a %WINDIR%\system32\dllcache mappában lakik.
• Slackbe írás. A slack használatának megértéséhez szükséges némi előismeret a fájrendszerek működéséről. A fájlrendszerben formázáskor beállítunk egy értéket (a blokkméretet), aminél kisebb egységet nem lehet írni rá vagy olvasni róla, tehát fizikailag ennyi helyet fog elfoglalni egy akár egy bájtos fájl is. Egy blokkban csak egy fájl lakhat, emiatt pl. 512B-os blokkméretnél egy 1B-os állomány tárolásakor ~500B "szabad" hely lesz a fájlunk mögött. Ebbe pedig akár írni is lehet, ugyanis a fájlrendszer üzemszerű használatakor békén hagyják a slackeket. A metasploit project slacker nevű eszközével lehet írni a slackbe, illetve olvasni belőle (értelemszerűen több slacket is felhasznál, ha nagyobb a rejteni kívánt fájl, mint az aktuális blokkméret). Kimondottan nehéz detektálni: ha pedig pl. titkosított fájlt rejtünk el így, nagyon nehéz észrevenni.
• Adatrejtés office dokumentumokban. Néha a kőbalta-fatengely kombó a legjobb megoldás: triviális módon lehet adatokat elrejteni dokumentumokban, amelyek amúgy is nagy mennyiségben megtalálhatóak egy modern irodában. Néhány ötlet: fehér színnel a dokumentum végére tesszük a szöveget, vagy beállítjuk a bekezdés tulajdonságainál a "hidden" pipát.
  
• Adatrejtés office dokumentumokban okosan. A fenti módszerek viszonylag egyszerűen észrevehetőek, viszont a Glue nevű zseniális kis eszközzel nagyon nehezen detektálható rejtést végezhetünk: megadunk neki egy word doksit és egy excel munkafüzetet, és összeolvasztja a kettőt a word nevén (a dolog azon alapszik, hogy mindkét fájltípus OLE-streameket használ, és két streamhalom viszonylag problémamentesen összeilleszthető). Ha az így készülő állományt .doc néven megnyitjuk worddel, az eredeti word doksi tartalmát látjuk, viszont ha átnevezzük .xls-re, akkor az excel worksheetet (!). A fájlszignatúra-ellenőrző programok nagy része pedig egyszerűen Microsoft Office Document (OLE embedded) fájltípusként azonosítja a hibridünket is.
• Adatrejtés a registryben. A registryben rengeteg olyan hely van, amit a windows egész egyszerűen nem használ semmire: egy ilyen rejtekhely az a kulcs, ahol a windows az időzóna-információkat tárolja (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation). Ezt a kulcsot lehet írni-olvasni - tökéletes rejtekhely.
  

DoS DNS poisoninggal

A tavalyi év nagy it-biztonsági szenzációja volt a Dan Kaminsky-féle DNS-poisoning támadás és a körülötte szerveződött hype. Gyors áttekintés: Kaminsky több-kevesebb huzavona és titkolózás-találgatás-kiszivárogtatás után bejelentett egy olyan sebezhetőséget, amely lehetővé teszi a meglévő DNS infrastruktúra tervezési hiányosságain alapulóan valamely DNS-szerverben tetszőleges bejegyzéshez tartozó IP-cím megváltoztatását tetszőleges címre.

Kaminsky felvette a kapcsolatot a legelterjedtebb DNS-szoftvereket fejlesztő cégekkel, hogy patcheljék a termékeiket, mielőtt kiszabadul a szellem a palackból. Ez nagyrészt meg is történt, viszont a történetnek még sajnos korántsincs vége: a patchek telepítése opcionális, emiatt százával (tízezrével) lehetnek "odakint" DNS-szerverek, amelyek nincsenek javítva. Egy 2008 novemberében készült felmérés szerint az akkori DNS-szerverállomány 1/4-e továbbra sem volt patchelve (!).

Mit jelent mindez a gyakorlatban? Elsősorban azt, hogy a poisoning támadás sikeres kivitelezése esetén továbbra is lehetséges DNS alapokon eltéríteni egy-egy DNS-szerver által kiszolgált hálózati szegmens forgalmát, ezáltal példátlanul hatékony DoS-támadást indítani - mint ahogy az meg is történt egyik ügyfelünk hálózatában.

Az üzemeltetők figyelmét az keltette fel, hogy a webszerver(klaszter) terhelése hirtelen két nagyságrenddel megnőtt, emiatt a legitim kérések kiszolgálása sok esetben TCP-s timeoutot elérő ideig tart - ezáltal gyakorlatilag elérhetetlenné téve az internet felől a központi webes rendszert. A logok megvizsgálása után kiderült, hogy három-négy IP-tartományból érkeznek a kérések, viszont ami különös volt az érkező HTTP-kérésekben, az a HOST mező tartalma: lényegében mindegyik fals kérés a google.com felé irányult, ennek ellenére a központi load balancer internet felől elérhető IP-címére érkeztek.

Több lehetőség is felmerült a helyzet kezelésére.

• Az érintett, mérgezett cache-ű DNS-szerver üzemeltetőinek küldtek egy e-mailt, hogy tájékoztassák őket a helyzetről - sajnos a megkeresésre a mai napig nem érkezett válasz, cserébe a szervert sem patchelték fel azóta sem.
• Felmerült a lehetőség, hogy IP-szinten tűzfalazzák a "veszélyes" IP-tartományokat - ezt hamar elvetették, ugyanis legitim forgalom is érkezik az érintett szegmensekből.
• A megoldás végül is az lett, hogy üzembe állítottak egy squid proxy-t a load balancer előtt, és a proxy a Host mező tartalma alapján minimális erőforrásigénnyel eldobálta a nem megfelelő kéréseket, csak a legitimeket engedte tovább. Ezzel a megoldással néhány óra alatt sikerült normalizálni a helyzetet.
  

A nem megfelelő helyre érkező kérések áradata még egy napig fennállt (feltehetőleg ekkorra járt le a mérgezett bejegyzés TTL-je), és nem ismétlődött meg azóta sem. A tanulság az, hogy egy súlyos, széles körben érvényes sebezhetőség a kezdeti hype és pánik elcsitulta után is tud problémát okozni.