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.
   

Webalkalmazások biztonsági hibái - 11. Fájlok feltöltése

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.

Rengeteg webalkalmazás biztosít lehetőséget arra, hogy a felhasználók feltöltsenek fájlokat az oldalra, és sajnos a sessionkezeléshez hasonlóan ez is triviálisnak tűnhet, noha a gyakorlatban a legtöbb fejlesztő elkövet klasszikus hibákat.

• Kik számára engedélyezzük a funkció elérését? A fájlfeltöltés biztonságilag kritikus folyamat egy webalkalmazásban, ennek megfelelően kell a felelőtlen elérhetővé tételével. Sok helyen egyszerű regisztráció szükséges csak ahhoz, hogy elérjük a feltöltéses felületet - tehát gyakorlatilag egy ugysincsilyenemailcim@freemail.hu kaliberű cím regisztrálása elegendő. A webalkalmazás biztonsági architektúrájának (!) és védelmi mechanizmusainak (!!) megtervezése (!!!) szükséges, még a kódolás megkezdése előtt (!!!!) - ennek keretében pedig igenis tessék átgondolni, hogy valóban szükségük van-e a mezei felhasználóknak arra, hogy fájlokat töltögethessenek fel a portál webes felületén keresztül.
• Mit engedünk feltölteni? A legtöbb probléma itt kezdődik, ugyanis a webfejlesztőnek meglehetősen korlátozott funkciók állnak rendelkezésére, hogy a feltöltött állományok típusáról meggyőződjön. Vannak ugye a naiv megoldások, amikor ellenőrizzük, hogy .jpg-re végződik-e a feltöltött fájl neve, de ezeket triviális kicselezni azzal, hogy kedvenc php backdoorunk kiterjesztését megváltoztatjuk. Aztán ott van az eggyel okosabb megoldás, amikor feltöltött adat MIME típusa alapján szortírozunk: nos, ez sem jobb semmivel, mint a kiterjesztés ellenőrzése, ugyanis a típust a kliens állítja be - gyakorlatilag egy mezei intercepting proxyval át lehet ütni tetszőleges értékre a típust, és aztán mehet is fel a backdoor php.Elvileg lehet fokozni a dolgot azzal, ha belenézünk a fájlba pl. a file filenév parancs lefuttatásával, de a fájlszignatúrás posztunk alapján ebben sem szabad megbízni.
  
• Milyen néven engedünk feltölteni? Találkoztunk már olyannal, hogy a portál előzékenyen felajánlotta a lehetőséget, hogy valamilyen néven tudjuk feltölteni a fájlunkat. Előzékenyen beleírva a fájlnév mezőbe a "../../backdoor.php" stringet, a webrootba másolta fel a fájlt. Vagy akár írhattunk volna tetszőleges, a php/apache által elérhető helyet.
  
• Mi történik a feltöltött fájlokkal? A feltöltésen túljutottunk. Mi történik a fájlokkal, amiket feltöltöttek a webalkalmazásra? A naiv megoldás az, hogy van egy "upload" könyvtár, ahol elérhetőek a feltöltött fájlok: ekkor, mivel tudjuk a fájl nevét, egyszerűen meghívjuk kedvenc PHP backdoorunkat, és voilá!, már meg is van a shell. Ha engedjük a fájlokat inklúdálni ellenőrzés nélkül az include() függvénnyel (például fórumokban az avatárok képei), akkor szintén könnyedén shellt kaphat a támadó. Ami a jogosultságkezelést illeti, már írtunk arról a hibáról, amikor az egyes fájlok elérését nem kötjük hitelesítéshez, hanem az URL ismeretében egyszerűen elérhetőek - nos, ebben az esetben ez a PHP backdoor akadálytalan lefutását eredményezi.
• Hogy fogunk törölni? Gyakran nem foglalkoznak a fejlesztők azzal a kérdéssel, hogy milyen módon fognak eltűnni a felhasználók által feltöltött fájlok a szerverről: egyetlen példaként hozzuk azt a szkriptet, ami a megengedett maximális méretű fájlt tölti fel - egymilliószor, vagy annyiszor, amennyit a tárterület enged.
  

VLAN-ok biztonsága

A VLAN-ok biztonságát érintő kérdések olyan területek, amivel az end-userek a gyakorlatban sohasem találkoznak - a VLAN számukra olyan valami, ami a csomagokat A-ból B-be eljuttató felhő lelkivilágához tartozik. Betörési tesztelői szemmel tekintve viszont épp ennek ellenkezője igaz - tesztelőként abból élünk, hogy nem hiszünk el dolgokat, például azt, hogy a VLAN-ok nyújtotta korlátokat nem lehet kikerülni.

Induljunk az elején. A VLAN-okat a 802.1Q RFC-ben definiálták, legleegyszerűsítőbb megfogalmazásban gyakorlatilag broadcast domaineket jelentenek a második rétegben: minden VLAN-nak van egy száma, amely számokat rá lehet aggatni a hálózati eszközök portjaira (Ne tessék keverni a TCP-s porttal! A port itt egy UTP-s aljzatot jelent.) A VLAN-ba sorolás történhet bárhogy: szokás fizikai alapon végezni a dolgot (például az X épület tárgyalói), feladat alapján (pl. VoIP vs. adathálózat), vagy okosan kiépített 802.1x használatakor a felhasználó bejelentkezéskor megadott azonosítója alapján - ezáltal biztosítható, hogy a marketing osztály munkatársai a gépüket bármilyen módon csatlakoztatva a hálózathoz, ugyanabba a subnetbe kerüljenek.

Nagyon elnagyolt módon összefoglalva az azonos számot kapott portok beszélhetnek egymással, míg a különböző számúak közötti forgalmazást a hálózat csak bizonyos szabályok esetén engedélyezi. Azt, hogy a forgalom melyik VLAN-ba tartozó portról érkezik, az eszközök úgy jelölik, hogy az ethernet header megfelelő mezőjébe teszik a vonatkozó VLAN értéket. Két különböző VLAN-ba tartozó hoszt csak router közbeiktatásával tud egymással beszélni.

Szokás access és trunk portokról beszélni a VLAN-ok kapcsán: a szakirodalom nem egységes abban a tekintetben, hogy mit értenek a két típus között. A Cisco-s irodalom nagy része a következőképp különíti el a kettőt.

• Access port: a kliens, aki csatlakozik a portra (azaz laptop, nyomtató, telefon, IP-kamera, akármi), nem végez ethernet rétegbeli VLAN-jelölést, a legtöbb esetben fogalma sincs arról, hogy ő valamilyen VLAN-ba lett sorolva. "Buta" eszközök esetén szokás használni leginkább.
  
• Trunk port: a forgalmat kezdeményező végzi a saját forgalmának jelölését, azaz taggelését. Ugyanabban a trunk portban elvileg akármennyi VLAN is mehet, a kereteket hálózati eszköz szortírozza szét a különféle VLAN-ok és célMAC szerint. Szokás például Cisco hardveres IP-telefonok és Cisco switchek között használni: ekkor a telefonon lévő aljzatba toljuk a laptopunkat, a switch üzemmódban működő telefon pedig elvégzi a taggelést: a gép által forgalmazott adatok a "A" VLAN-ban mennek tovább, míg a telefon a VoIP forgalomhoz a "B" azonosítót taggeli - a túloldalon ülő switch pedig ez alapján elkülönítve kezeli a kettőt.

Fontos megemlíteni még a natív VLAN fogalmát. Az IEEE back-kompatibilitási okokból előírja, hogy a trunk portok tudjanak nem taggelt forgalmat is kezelni (tehát itt nincs VLAN érték a frame-eken), ekkor a nem taggelt frame-ek az ún. natív VLAN-ba kerülnek be.

Nézzük a biztonsági vonatkozásokat. A VLAN-ba sorolás meglehetősen erős védelmi korlátot jelent, ha megfelelően történt a megvalósítás: nagyon kell küzdeni ahhoz, hogy át tudjunk tenni kereteket másik VLAN-ba, és nagy valószínűséggel nem fogunk akkor sem választ kapni a kérdésünkre.

VLAN-ok "kikerülését" vlan hoppingnak szokás nevezni: ha sikerül véghezvinni a dolgot, beleforgalmazhatunk olyan VLAN-okba is, amelyekhez nem tartozunk. Mik a gyenge pontok?

• Natív VLAN-ok nem megfelelő egyeztetése. Előfordul néha, hogy nem foglalkoznak a natív VLAN-okkal megfelelően, nem egyeztetik a natív VLAN-ok számát a switcheken. Emiatt előfordulhat az a jelenség (ha nagyon akarjuk, vlan hopping): 1. Az A switchre csatlakozó hoszt taggeletlenül küld kereteket a B switchre csatlakozó hosztnak. Az A switch beleteszi a natív VLAN-jába (mondjuk a 10-es számúba) a kereteket, és továbbküldi - szintén taggeletlenül - a B switch felé. A B switch taggeletlenül megkapja a kereteket és beleteszi a saját natív VLAN-jába (mondjuk hanyagul a 20-as), ami alapján dönt a továbbításáról. A probléma akkor jelentkezik, ha a B switch natív VLAN-ja nem egyezik meg az A switchével - ekkor gyakorlatilag VLAN-t ugrunk (jelen esetben 10-esből 20-asba).
• DTP engedélyezése felhasználó felé néző portokon. A DTP a Dynamic Trunking Protocol rövidítése, és arra szolgál, hogy switchek egymás között tudjanak trunkölést szabályozni. Mint a legtöbb L2 protokollnál, itt sincs sem hitelesítés, sem azonosítás, ezért a megfelelő eszközzel trunk porttá kapcsolható a portunk - ehhez persze az kell, hogy a DTP elővigyázatlanul bekapcsolva maradjon. Ha sikerült trunkké kapcsolni, a végpontra csatlakozó eszköz saját maga tudja taggelni a kereteit, ezáltal a sajátjától különböző VLAN-ba is forgalmazni tud. A yersinia tud ilyet.
• A kliensre bízzák az eszközök a keretek taggelését. IP-telefónia kiépítésénél használatos megoldás az, hogy a telefonok végpontjai egyből trunköltek, a telefon maga végzi a taggelést. Ha pl. laptopot csatlakoztatunk a hálózathoz, ilyekor nemcsak a VoIP eszközök forgalmához lehet hozzáférni, hanem elővigyázatlan kiépítésnél az összes VLAN-hoz.
• Kőbalta-fatengely. Az egyik legrégebbi, switchek ellen irányuló támadás során a támadó random MAC-címeket hamisít bele a kiküldött keretek fejlécébe, a switch pedig megyjegyzi, hogy melyik lábán milyen MAC címeket lát - mivel az eszköz memóriája véges, előbb-utóbb eljön a pillanat, amikor megtelik a tábla. Ilyenkor a sokezer dolláros, intelligens switchünk egy ötcentes hubbá változik - minden lábán kiküld minden forgalmat. A VLAN-okhoz annyiban kapcsolódik a dolog, hogy ilyenkor a switch egészen egyszerűen figyelmen kívül hagyja a VLAN-okat, minden forgalmat kitesz minden lábára. Nagyon aljas támadás: egyrészt iszonyat zajos, másrészt a switchet is leállíthatja.
• Double tagging. A szakirodalomban írnak erről a támadásról is - én még nem találkoztam olyan esettel, amikor működött volna a gyakorlatban. Annyi történik itt, hogy a 802.1Q lehetővé teszi a keretek dupla taggelését - ekkor, ha a csillagok együttállása megfelelő (a csillagok itt speciális funkciók beállítását és két-három speciális félrekonfigurációt jelentenek...), lehetséges felduplataggelni a kereteket, amik végül is másik VLAN-ban kötnek ki.

DHCP - Domain Hijack and Control Protocol

A DHCP a Dynamic Host Configuration Protocol rövidítése, azonban olyannyira nem biztonságtudatos módon történt a megalkotása, hogy a címbeli feloldás is tökéletesen helytálló. A DHCP-vel a legtöbb felhasználó akkor találkozik, amikor a Windows systrayen figyeli a hálózat állapotát jelző kis piktogramot, és várja, hogy a gép ikon alatt kis vajszínű pöttyöt mozgató három fázisú animáció eredményeképp végre forgalmazhasson a hálózaton, azaz legyen végre internet.

A DHCP klasszikus rétegelési értelemben UDP-s, azaz a TCP/IP negyedik rétege, azonban a támadhatóságát kihasználó módszerek tulajdonságai és eredménye miatt szokták a második rétegbeli protokollokkal együtt tárgyalni a szakirodalomban. A megalkotását az az igény szülte, hogy az egyre nagyobbá váló hálózatok beállításakor a hálózatüzemeltetőknek kézzel kellett nyilvántartaniuk a kiosztott IP-címeket, DNS-beállításokat, emiatt egy mérethatár elérése után kiszaladt a kezükből a hálózat. A DHCP automatizálja a technikust, aki oda-vissza szalad a hálózati eszközök és a csatlakoztatott hosztok között.

Működését tekintve roppant egyszerű protokollról van szó: a hálózathoz csatlakoztatott kliens broadcast kérést küld, a DHCP szerver pedig unicast üzenetben válaszol a kliensnek, amelyben megmondja, hogy mik a hálózat beállításai. Alapkiépítésben az alábbiakat mondta meg a válaszban:

• a kliens IP-je
• netmask
• DNS szerverek címe
• a default gw címe
• időtartam, ami lejártakor el kell felejtenie a beállításokat a kliensnek és új IP-t kérnie

Ehhez újabban hozzájött windowsos hálózatokban néhány újabb mező is:

• a DC neve és IP-címe
• a CIFS master browser neve és IP-címe

A kliens részéről megadható preferált cím (például akkor, amikor ismételten ugyanahhoz a hálózathoz csatlakozunk), ezt a szerver vagy elfogadja, vagy nem. A DHCP protokoll lehetővé teszi, hogy több szerver is legyen ugyanazon hálózatban, ekkor a kliens a legelső választ tekinti irányadónak.

Támadások?

• Man-in-the-middle. Egyrészt azért, mert a DHCP kérés broadcast, arra bárki válaszolhat: ha például a támadó annyit csinál, hogy elindít egy DHCP szervert a gépén és figyeli a kéréséket, válaszolhat rájuk, amin saját magát adja meg default gw-nek, a buta kliensek (figyelem! Nem olvastunk a fenti leírásban sem hitelesítésről, sem azonosításról!) szó nélkül érvényesítik a küldött beállítást. Mivel felhetetőleg azért az igazi DHCP szerver is válaszol némi késéssel, a kliens megkapja az igazi választ is, de a protokoll kialakítása miatt nem foglalkozik vele, a támadón keresztül forgalmaz csak. Fokozható a hatás azzal, hogy a támadó előzékenyen saját magát adja meg master browsernek, és ekkor a kliens mindenképpen rajta keresztül fog authentikálni a hálózati SMB-szerverekhez.
  
• DoS - IP pool exhaustion. A másik triviális támadási mód a szerverek ellen irányul: egész egyszerűen több száz (ezer) DHCP-kérést injektál bele a támadó a hálózatba, ezzel nagy valószínűséggel elég hamar elfogyasztja a rendelkezésre álló tartományt (scope-ot). A gobbler nevű eszköz dokumentációja szerint negyven másodperc alatt le lehet halasztani egy /24-es szkópot: aki ez után szeretne csatlakozni, az nem fog tudni.
  
• DoS - Die, baby, die! Nagyméretű hálózatokban sem lehetnek meg DHCP nélkül, viszont ez azt jelenti, hogy nem lehet minden switch mögé DHCP szervert telepíteni, keresztül kell vinni a switcheken a DHCP forgalmat. A Cisco switchek a DHCP feldolgozást erőből (CPU-ból) végzik, viszont ebből meglehetősen kevés áll rendelkezésükre relatíve, emiatt viszont nagy valószínűséggel működésképtelennél válnak, ha rengeteg DHCP-kérés/válasz megy egyszer csak keresztül rajtuk.

Ami az eszközöket illeti, a fiatal, lelkes, ám nem kikezdhetetlen tudású IT-biztonsági szakemberek távoltartása érdekében csak pár szót mondunk: yersinia és gobbler, valamint ettercap.

Védekezés.
Nyilván rengeteg lehetőség van a védekezésre, lássunk ezek közül néhány fontosat - és hogy miért lövik lábon magukat az üzemeltetők, ha aktiválják.

• Nem használunk DHCP-t. Ekkor lehet kézzel beállítgatni mindent. Nem reális két hosztnál többet tartalmazó hálózatokban.
  
• Port security. Szokták mondani, hogy ez a megoldás a L2-beli támadások nagy részére, de sajnos ez ellen nem véd. Például szépen be lehet állítani, hogy a 23-as fizikai porton csak a DEADBEEFCAFE MAC-cím fogalmazhat, de ez sajnos nem véd a pool exhaustion ellen, ugyanis a proxyzások miatt belekerült egy szolgáltatás a protokollba, amely lehetővé teszi, hogy egy MAC-címről ne csak saját magunknak kérhessünk címet, hanem a valaki másnak is - a MAC címek ugyanazok lesznek mind az ezer kérésben, ennek ellenére szépen elérhetetlenné tesszük egy napra az IP-poolt ezzel az opcióval.
• ICMP/ARP ping a DHCP poolban. Sok DHCP szerver ICMP-n/ARP-n megpingeli a kiosztott címeket rendszeres időközönként - elsősorban nem biztonsági okokból, ugyanis sok kliens egész egyszerűen nem engedi el a szervernél kikapcsoláskor a használt IP-címet. A gobbler például azt is tudja, hogy válaszol az ilyen pingekre.
  
• Rate limiting per port. Lehet persze azzal is próbálkozni, hogy nem engedünk, csak n kérést bejönni a porton percenként - ezzel annyi a gond, hogy a DHCP lease rendszerint több órára szól, viszont ha ezt a rate-et szeretnénk átengedni mindenfajta forgalomból, az meglehetősen lerontja a felhasználói élményt.
  
• DHCP snooping. Ez a legkevésbé rossz megoldás, a Cisco switchek saját védelmi mechanizmusa, cserébe meglehetősen sok CPU-időt foglal: a switch figyeli a kiosztott IP-címeket, megjegyzi, melyik portján lakik az érintett IP/MAC cím, valamint hogy hol lakik a DHCP-szerver és nem enged másféle forgalmat. A hátránya annyi, hogy rengeteg hibát tud okozni: ha a switchnek valahogy egy, a hálózat távoli pontján végzett átpatchelés miatt bekövetkezett feszítőfa-változás következtében másik lábára került a DHCP-szerver (jó, igaz: rendesen menedzselt hálózatoknál ilyen nyilván nem fordulhat elő, de maradjunk meg az esőben váratlanul szakadozó hálózatok való világában), akkor az üzemeltetők napokig nyomozhatnak az összes swichen, hogy miért is nem működik a DHCP abban a szegmensben...
  

A WPA töréséről

A WEP halott. Sokszor, sokan kimondták már: egy 128bites WEP-kulcs körülbelül egy kávé és egy túrós bukta elfogyasztása alatt megszerezhető. Itt például már gondolkodni sem kell, annyira részletesen elmondják a tutorial készítői.

A WPA van soron: a 802.1i szabvány megalkotói meglehetősen magasra dobták a labdát biztonsági szempontból, ugyanis tanultak a WEP hibáiból: per-packet keying van, minden csomagot külön kulccsal titkosítunk, azonkívül kettéválasztották a hitelesítést a csomagtitkosítástól. A WPA2-ben megkövetelik a TKIP mellett az AES titkosítás használatát is.

A tudomány jelen állása szerint több módon is lehet támadni támadni a technológiát:

• Az Achilles-sarok a WPA tekintetében a négylépéses kulcscsere-protokoll, ami akkor zajlik le, amikor a kliens csatlakozik a hálózathoz. Ha a támadó elcsípi ezt a négy csomagot, szótárral-rainbow-táblával megpróbálhatja feltörni, és ha kellően jó a szótára, megszerezheti a passphrase-t. Meglehetősen egyszerű ilyet előidézni: a támadó deauthentikációs kéréseket tud kiabálni bármely kliens nevében, ez okosabb klienseknél reasszociációt eredményez.
  
• A WPA-ra is alkalmazható a ChopChop-nak nevezett támadás (úgy-ahogy), erről bővebb leírás itt - tekintve, hogy kulcsot ez sem talál meg és csak ARP-kereteket lehet injektálni a hálózatba nagyon sok küzdelem árán, gyakorlati tesztelés során sok hasznát nem vesszük - még...
  
• Felállítunk egy hamis AP-t, amihez megpróbál authentikálni a felhasználó: a cowpatty legújabb verziója a négylépéses kulcscsere első két üzenetét is képes szótárral támadni. Ez azért nagyon hasznos, mert a Windows a wifi üzembe helyezésekor elkezd keresni a megbízható hálózatok után, ezt a támadó meghallja, és behazudja saját magát a keresett hálózatok AP-jának: a felhasználó eljut a második lépéséig a handshake-nek, a támadó pedig már izzítja is a harmincgigás rainbow-tábláit.
  

Végezetül néhány szó a szótáralapú támadásokról. A legtöbb hálózatban a passphrase nem közvetlenül szótári szó, hanem inkább szótári szavakból képzett string. Vannak klasszikus szabályok: évszám a szó elé-mögé, esetleg az l lecserélése 1-re stb: ilyen "erős" jelszavakat a john the ripperrel viszonylag egyszerűen lehet generálni szólista alapján, azonban némi mértéktartás szükséges ezen a téren.

Vegyünk például egy négymillió szóból álló listát, ez már elég nagynak számít: jó negyvenkét mega a mérete. Engedjük át a john the ripperen, kapcsoljunk be minden keverőszabályt, és hipp-hopp, két nagyságrendet ugrott a listánk mérete (a fenti 42 megából történő generálásnál az 1882 megás méret elérésekor untam meg a folyamatot, ekkor 71 millió szóból állt) . Próbáljuk meg felhasználni: a saját laptopom 400 kulcsot tud kipróbálni másodpercenként, ez egy nap alatt 30 millió szó: két napig tartana végigpróbálgatni a fenti, hevenyészett szótárt. Sok.

A fenti eszmefuttatás folyományaként kijelenthető, hogy a brute-force WPA-törés, bár technikailag lehetséges, nem valószerű: csak olyan számból, ami öt és tíz közötti karakterszámú és nem nullával kezdődik, O(10^10) darab van. Napi 30M próbával nagyságrendileg száz nap alatt futnának végig... és ezek csak a számok, amivel az "1957635241"-jellegű kulcsokat nézzük végig.

Tehát:

• Tessék megváltoztatni az SSID-t.
• Tessék WPA2-t használni, erős passphrase-zel.

Kémkedés, adatszivárogtatás, e-mail headerek

Nemrég kaptunk egy meglehetősen szokatlan munkát.

A megbízás arról szólt, hogy a megbízó cég vezetőjéhez eljutott egy e-mail (a tartalmából ítélve két dummy hotmail-es cím közötti hosszú levelezés egy részlete), amely meglepő módon igen szenzitív információkat tartalmazott a megbízó pályázatáról egy nagy beszerzéssel kapcsolatban. A megbízó arra kért, hogy találjuk meg, hogy tőlük küldték-e ki a levelet, vagy egyéb helyről szivárogtak ki az információk. Nagyon sürgős volt a munka, ugyanis aznap délután a megbízó megbeszélésre volt hivatalos a pályázattal kapcsolatban.

Az e-mail vizsgálata során végigmentünk a szokásos lépéseken: megnéztük a headereket, és hamar reménykedni kezdtünk, ugyanis a levelet nem a hotmail webes felületéről küldték, hanem az X-mailer mező tanúsága szerint 2003-as Outlookból, a Received mezők pedig elárulták, hogy egy t-online-os/ADSL-es cím volt az eredeti feladó. Egy nyom megvan, meg kell tudni, kié az ADSL végpont - ennél azonban egyértelműbb nyom is akadt a levélben: a Message-id mező.

A kiküldött leveleken szereplő message-id mező szerepe az, hogy a kliensek nyilván tudják tartani, hogy melyik levél melyikre érkezett válaszként. Implementációtól függően másként generálják az id-t a kliensek, a generált id jellemző a kliensre: míg pl. a Thunderbird az elküldött levél azonosítóját a "sender" mezőben szereplő e-mailcím domainjéből képzi (tehát a zsombor.kovacs@korbacs.hu cím azonosítója krikszkraksz@korbacs.hu lesz), a domainbe léptetett Outlook2003 meglepő módon fix domaineset ad: mégpedig azt a domaint, amelybe be van léptetve a gép. Jelen esetben a hotmail-es címről érkező levél message-id értéke krikszkraksz@XYZ.hu alakú volt, ahol az XYZ a megbízóval kapcsolatban álló pályázatíró cég neve. Erős volt tehát a gyanú, hogy valahonnét onnét jött ki a kérdéses levél.

További könnyítés, hogy az Outlook előzékenyen elküldi a munkaállomás NetBIOS nevét, így az első SMTP szerver jó eséllyel beleteszi az EHLO handshake után a továbbküldött fejlécbe - további nyomként megtalálható egy belső hálózati név is a fejlécben, ami alapján jó eséllyel azonosítható volt a küldő munkaállomás.

A vizsgálatokra rendelkezésre álló néhány óra eredményeképp annyi volt állítható, hogy nagy valószínűséggel egy olyan gépről küldték ki a levelet, amely be van léptetve egy, a pályázatíró cég nevével megegyező domainbe. A megbízó ennek megfelelően tudta alakítani tárgyalási stratégiáját.