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.