Mindegy, hogy csoportmunkát támogató nagyvállalati megoldásokról, a Twitterről, a Facebookról, a munka világába betörni próbáló Workplace by Facebookról, a Google-ről, G Suite-ról vagy éppen a Zoho Suite-ról van szó, mind egyre kifinomultabb megoldásokat vezettek be, amivel a jelszólopáson alapuló betörési kísérleteket próbálják sokkal nehezebbé tenni. A tesztek alapján érdemes végigvenni, hogy mik azok a tényezők, amiket egy-egy belépésnél ezek a rendszerek figyelnek, ha úgy tetszik, ha valaki bombabiztos intranetet, collaboration suite-ot, ERP-t, intranetet tervezne, ezeket mindenképp érdemes beépíteni a szolgáltatásba még akkor is, ha az implementálása nem tűnik rutin feladatnak, másrészt költségesebbé teszi a működtetést olyan szempontból is, hogy külső szolgáltatók szolgáltatásait, például külső GeoIP-szolgáltatókat kell igénybe venni.

Tekintsük az alábbi hipotetikus esetet: adott egy potenciális áldozat, aki tipikusan Budapestről, vagy ha nem is Budapestről, de Magyarországról szokott belépni az adott szolgáltatásba, mobilról mindig iOS-en, mobilappon keresztül, asztali gépen pedig böngészővel Windows 10-es oprendszerrel és az aktuálisan legújabbra frissített Firefox böngészővel, amin nagyjából ugyanazok az addonok vannak telepítve a munkahelyi vagy otthoni gépén. A jólnevelt, alapos azonosítást végző webszolgáltatások lényegében a mi biztonságunk érdekében szeretik lekérdezni és naplózni az ún. browser fingerprintet, ami többek közt a következőket foglalja magába:

- képernyő felbontása és színmélysége

- a felhasználó által használt böngésző típusa, verziója és az általa használt pluginek

- a gép által használt időzóna

- a böngésző engedélyezi-e a DNT-headert, amiről érdemes tudni, hogy a webhelyek vagy figyelembe veszik vagy sem, de nincs kötelező érvénye

- a HTTP_ACCEPT , válaszban fogadható adatok típusa

- az egyedi  WebGL hash

- a böngésző és persze az operációs rendszer nyelve

- azok a rendszerben telepített betűtípusok, amiket a böngésző használhat a webhelyek megjelenítéséhez

- természetesen a jó öreg user-agent

Már ennyiből belátható, hogy itt valóban egy ujjlenyomatról van szó, hiszen alighanem nincs két ugyanolyan eszköz a világon, aminek ezek az értékek azonosak lennének, ami érthetőbbé válik a következő ábra alapján:

A saját böngésző ujjlenyomatunkat a legegyszerűbbben a https://panopticlick.eff.org/  oldalon nézhetjük meg, a teszt lefutása után csak a Show full results for fingerprinting lehetőségre kell kattintani. Az ujjlenyomatban látható bits of identifying information valamint one in x browsers have this value oszlopban látható értékek értelemszerűen azt mutatják, hogy az összes korábban mért böngésző-ujjlenyomathoz képest a sajátunk mennyire egyedi.

Ezen kívül van még több finomság, amire rendszerint nem gondolnak azok, akiknek rendszerint az a rögeszméjük, hogy ők aztán tényleg anonim módon szörföznek, saját tapasztalataim szerint akik úgy gondolják, hogy a legnagyobb avatott szakértői az anonimizálásnak, nehezebben edukálhatók, mint a teljesen fogalmatlan felhasználók, senkinek sem ajánlanám, hogy bárki is megpróbálja meggyőzni őket arról, hogy nem tévedhetetlenek.

De vannak más információk is, amiket a böngésző kikotyoghat, például a WebRTC-technológia miatt. A WebRTC ötletét az adta, hogy a VoIP és a böngészőben elérhető videótelefonálós szolgáltatások zökkenőmentesebben működjenek, alapértelmezés szerint máig az összes böngészőben alapértelmezés szerint engedélyezett a WebRTC, ami a következő információkat árulja el a felhasználóról, amiről aztán nem gondolná, hogy kívülről is látható:

- LAN IP - nem nehéz belátni, hogy a használt routerben beállított DHCP lease timetól függően a publikus IP-LAN IP együttesen nézve már alkalmas lehet a konkrét eszköz és felhasználó azonosítására. Viszont azt, hogy például egy felhasználó a  5.62.39.247 publikus IP-t használja, amihez a hozzá tartozó LAN IP 192.168.1.88, elvben természetesen nem csak olyan szolgáltatás kérdezheti le, amelyiknek ténylegesen szüksége van erre az információra, azaz nem csak videócsetes szolgáltatás. Egy 5.62.39.247 cím önmagában nem túl egyedi, de egy 192.168.1.88-192.168.1.88 már eléggé, egy 5.62.39.247-172.16.231.122 pedig annál inkább, több irodaépületben esetleg a LAN IP sosem változik.

- A felhasználó által használt DNS-szerverek, amik akár az alapértelmezés szerint az internetszolgáltató által automatikusan beállított DNS1, DNS2 címek, akár a kézileg beállított OpenDNS, akár a Google DNS1, DNS2 címei, egyaránt árulkodóak, hiszen ugyancsak lekérdezhetőek.

Hogy a gépünk érintett-e a DNS leaking szempontjából, a legegyszerűbben a  https://ipleak.net/ oldalon ellenőrizhetjük.  

Természetesen a böngésző ujjlenyomata és a WebRTC is megmókolható illetve lecsapható, viszont nem feltétlenül bölcs dolog, hiszen ezeket az információkat alapvetően azért árulja el a böngészőnk, hogy a webhelyek megfelelően legyenek megjeleníthetőek.

Egy-egy gyanús belépési kísérletnél a hitelesítés ellenőrzésének része lehet a böngésző ujjlenyomat és a WebRTC miatt lekérdezhető információk összevetése azokkal, amiket korábban naplózott a rendszer az adott felhasználóra vonatkozóan.

Ennél sokkal kevesebb információ is elegendő ahhoz, hogy valamilyen anomáliát szúrjon ki egy-egy szolgáltatás egy gyanus belépés esetén, ezért extra, az azonosításhoz szükséges adatokat kérjen majd a felhasználótól. Tételezzük fel, hogy a felhasználó 13:00-kor belép vagy éppenséggel aktívan használ egy korábban indított munkamenetet Budapestről, mondjuk a UPC lakossági hálózatán keresztül, ahol ráadásul igen ritkán változnak az elvben dinamikus IP-címek, közben pedig egy másik eszközön 13:10-kor valaki elsőre megadja a helyes felhasználói nevet és jelszót olyan eszközön, ami a hozzárendelt IP-cím alapján Bécsben van és mondjuk az A1 IP-tartományából kapott publikus IP-t mutatja. Ezen kívül tételezzük fel, hogy a felhasználó ritkán utazgat, nem szokott VPN-t használni, valamint azt, hogy 10 perc alatt nem teleportálta magát Budapestről Bécsbe. A szolgáltatás joggal fog riasztani azzal kapcsolatban, hogy egy támadó egy szimpla jelszólopással próbál hozzáférni a felhasználó fiókjához és függően attól, hogy a korábbiakhoz képest mennyire szokatlan a belépési kísérlet, annál komolyabb extra lépéseket kérhet a felhasználótól az azonosításhoz. Persze ha valaki rendszeresen ugrál akár céges VPN-en keresztül, akár anonimizáló VPN-szolgáltatáson, akár TOR-on keresztül, az okos beléptetés ezt is meg fogja jegyezni és a későbbiekben már nem tekinti szokatlan belépési kísérletnek az előzőhöz hasonló esetet. Ráadásul a legnagyobb webes szolgáltatások azt is nagyon jól tudják, hogy milyen címtartományok tartoznak anonimizáló VPN szolgáltatásokhoz valamint egész precíz listája van a TOR exit node-okról.

Az ilyen típusú ellenőrzésnek ugye semmi köze pl. az UBA-hoz, viszont mégis nagyon hatékony. Kísérletező kedvűek kipróbálhatják, hogy egy USA-beli VPN-re csatlakoznak, nyitnak egy privát böngészőablakot, majd megpróbálnak belépni a Twitter-, Google- vagy Facebook-fiókjukba, közel 100%, hogy mindegyik sikítani fog és további információt kér az azonosításához. A szolgáltatás a felhasználót kötelezheti új jelszó megadására, arra is, hogy végigmenjen egy security checkupon, ami magába foglalja korábbi belépések áttekintését, a megbízhatónak megjelölt eszközök áttekintését, az utolsó felhasználói aktivitások áttekintését, de ha csak a Google- vagy Facebook accountra gondolunk, előfordulhat olyan forgatókönyv is, hogy a szolgáltatás az accountot átmenetileg lezárja, amíg egy moderátor át nem nézi, hogy mennyire is gyanus egy-egy belépési kísérlet, ennek megfelelően a Facebook kérheti, hogy a felhasználó küldjön arcképes személyi igazolvány scant, amin valóban az ő arca van. Persze olyan arc, ami összevethető a korábbi feltöltött képek alapján. Ezen kívül az is lehetséges, hogy a helyreállítást csak akkor hajtják végre, ha a felhasználó engedi, hogy a saját nevén lévő bankkártyán keresztül zároljanak egy jelképes összeget, a bankkártyán lévő névnek pedig egyeznie kell a szolgáltatásban használt névvel.

Ilyesmit alighanem többen láttak már, ideális esetben nem túl sokszor:

A Google-t és a Facebookot két szempontból emelem ki. Az egyik, hogy a Google a G Suite-tal már rég meghódította hatalmas szervezetek szinte teljes kommunikációját már akkor, amikor a mostani szabványok szerinti megfelelőséggel nem is rendelkezett, amiről itt olvashatunk bővebben:https://gsuite.google.com/security/?secure-by-design_activeEl=data-centers   

Amivel most a Facebook is próbálkozik, a Workplace by Facebook, amivel kapcsolatban amúgy a cég esküszik rá, hogy sokkal komolyabban veszik az abban tárolt, elvben Facebooktól teljesen elválasztva kezelt információkat és ezt szintén igyekeznek külső audit reportokkal alátámasztani. 

A második, ami miatt ezt a kettőt emeltem ki, hogy ha alapvetően tömegszolgáltatás esetén be lehetett vezetni a fent vázolt, felhasználók biztonságát fokozó módszereket, ebből lenne mit tanulniuk például a céges intranet rendszerek fejlesztőinek.

Előbb írtam, hogy ezek a szolgáltatások nem figyelik a felhasználói magatartást, ami azért nem teljesen igaz, használják, de nem elsődlegesen. A Facebook például sikít, ha egy teljesen friss belépést követően valakinek az első dolga a figyelmeztetések vagy a kétlépcsős hitelesítés kikapcsolása, a fiókhelyreállításra alkalmas email-cím vagy mobilszám megváltoztatása, míg a Google drákói szigorral ideiglenesen jegeli azt a Google-accountot, amelyiknél egy friss belépést követően a felhasználó olyan szűrőszabályt állít be az emailekre, amik éppen a biztonsági figyelmeztetéseket tartalmazó emaileket dobálná kukába, ha pedig a támadó átirányítást állított be egy külső email címre, webes felületen az ezzel kapcsolatos figyelmeztetés egy hétig fog a felső sávban virítani.

Ha egy-egy fontos, akár minősített adatokat is tároló rendszerben eléggé kifinomultan van kialakítva a védelem, ami, mint lájuk, nagyobb részt nem perimeter-based védelemi mechanizmusokra támaszkodik, az igencsak megnehezítheti még a felkészültebb támadó dolgát is.

Nos, mindezt figyelembe kell venni a pentesternek is, akár pusztán no-tech hacking, akár technikaibb módszerekkel próbálkozik. Tételezzük fel, hogy a pentester vagy a rosszindulatú támadó tisztában van azokkal, amiket leírtam, éppen ezért virtuális gépet használ, természetesen a virtuális gépen használt böngészővel. Ekkor a virtuális gépnek minél inkább sikeresen el kell hitetnie a támadott szolgáltatással, hogy hagyományos gép, ami pedig a böngészőt illeti, azt is úgy kell kialakítania, hogy az minél jobban hasonlítson egy mezei böngészőhöz. És tételezzük fel, hogy nem használ TOR-t vagy hasonló csodát, amivel gyanusabbá nem is tehetné önmagát. Persze a portable browser sem megoldás, egyszerűen azért, mert kellően bravúros védelmi megoldás esetén a szolgáltatás észleli, hogy valószínűleg portable browserről van szó. Azaz OPSEC szempontból még az sem a legjobb megoldás, ami egyébként annak tűnik. Akár a pentester, akár a rosszindulatú támadó egy támadásnál annál inkább számíthat sikerre, minél inkább úgy kezeli a virtuális gépet és a böngészőt, mintha az valódi lenne. Például rendkívül gyanus az olyan böngésző, aminek az ujjlenyomata alapján semmilyen addon nincs telepítve, ahogy természetesen az is, ha ugyancsak a fingerprint alapján kiderül, hogy az oprendszer és a böngésző orosz nyelvű, holott a támadott felhasználó angol vagy magyar nyelvűtől eltérő oprendszert és böngészőt sosem szokott használni, orosz nyelvűt sosem használt. Az pedig már szinte biztos, hogy bekapcsolja a vészcsengőt, ha valaki a TOR hordozható böngészőjével próbálkozik, amiben éppen az a gyanus, hogy semmilyen addonja nincs, de NoScript mindig, csak a legszükségesebb betűtípusokat használja és így tovább.

A böngészőnk és a viselkedésünk nem csak valamilyen szolgáltatásba való belépésnél lehet nagyon árulkodó. Néhány hónappal ezelőtt, miután a nagyon sokadik emailt kaptam egy szépnevű USA-beli hoszting szolgáltatótól, hogy költöztessek hozzájuk ezt, azt, amazt, gyanusan olcsón, egy idő után a szolgáltató oldalán kértem egy pre-sales csetes supportot. A beszélgetésből kiderült, hogy a felkínált ár tényleg annyi, amennyit feltüntettek, de csak az első számlázási ciklusban és csak akkor, ha három évre előre fizetek elő, de ha mindez nem lenne elég, az is kiderült, hogy ha az ügyfél európai vagy sejthetően az adatforgalmat jórészt Európa felé kellene biztosítani, ami ennek megfelelően sokkal drágább a szolgáltatónak, akkor háromszoros áron tudják csak biztosítani a szolgáltatást. Gondoltam, magamban, nesze neked net neutrality, puding próbája az éves, ennyire pofátlan szolgáltató esetén nem éreztem különösebb bűntudatot, amikor szűz böngészővel egy USA-beli VPN-szerveren keresztül elindítottam szolgáltatás megrendelését, USA-beli számlázási címet megadva. Ahogy pedig ez jobb helyeken bevett gyakorlat, ellenőrzik a szolgáltatás élesítése előtt, hogy a megrendelő nem spambáró, terrorista vagy hasonszőrű arc-e esetleg. Paypal-lel fizettem volna, azaz a fizetési eszköz alapján nem lehetett következtetni a kilétemre. A szolgáltatást mégsem élesítették a csalásmegelőző rendszer riasztása miatt. Az adott szolgáltató a MaxMind MinFraud szolgáltatását használta, az pedig alighanem abból következtetett rá, hogy valószínűleg nem USA-beli vásároló vagyok, hogy a megrendeléskor használt böngésző nyelve magyar volt a fingerprint alapján, ami meglehetősen ritka lehet a megrendelőik körében. Vagy olyan tényező alapján, amiről nem tudok.

Összefoglalásként elmondható, hogy a felkészült támadó dolgát - persze nem csak webes környezetben - igencsak meg lehet nehezíteni, ha a védelem teljesen különböző technikáit kombináltan használják. A perimeter-based védelem nem elég, a felhasználói viselkedést elemző rendszerek önmagukban még biztosan nem eléggé kiforrottak, ugyanakkor több elegáns, alapvetően a kliensre jellemző technikai sajátosságok lekérdezése, azok összehasonlítgatása korábbi mintákkal, az ahhoz kapcsolódó valószínűségi változókkal már igen hatékony lehet.

Amit még megjegyeznék, hogy nagyon sokszor nem is szükséges olyan, diszkrét, kevésbé diszkrét, de drasztikus módszerek bevetése, mint supercookie-k és hasonló okosságokküldése az ügyfél felé ahhoz, hogy egy felhasználó nagy pontossággal azonosítható legyen. Persze, van, amikor igen, ugyan ez kevésbé tárgya a cikknek. Mire is gondolok? Az FBI a Wikipedia szerint legalább 2002. óta használja a semmitmondó nevű Network Investigative Technique toolkitet, ami nem tűnik túl privacy-barát dolognak. Az is tudvalevő, hogy a nyomozóhatóságok nem ritkán a feketepiacra járnak 0-day exploitokat vásárolni. Természetesen 100%-ig nem zárható ki, hogy ezzel nem élnek vissza, viszont rendszeresen felröppen olyan hír, amikor éppen valamilyen 0-day sebezhetőséget kihasználva sikerült egy-egy pedofilhálózatot leleplezniük a dark weben, ekkor senki sem ítéli el a módszert különösebben. Az egyik ilyen pedofil ügyben a vádemelést követően egy bíró próbálta kötelezni a FBI-t az általuk használt technikák és az összes többi technika felfedésére, amit lehet indokolni mondjuk azzal, hogy csak törvényesen szerzett bizonyíték használható fel, ahogyan Európában is, csak éppen józan ésszel nem. Személy szerint azért nem értek egyet azokkal, akik szerint a privacy mindenek fölött álló és bűnüldöző szervek se használjanak néha etikai szempontból  megkérdőjelezhető módszereket, mert ha lebuktatnak 1000 pedofilt, embercsempészt, bérgyilkost, nagy tételben utazó drogbárót, na meg olyan arcot, akikkel nem szivesen találkoznánk személyesen, emellett 1 ártatlan személy magánszférájába a feltétlenül szükségesnél jobban beletúrnak akár véletlenül, akár szándékosan, ép ésszel belátható, hogy szerencsésebb eset, mintha senkinek a magánszférája nem sérült volna minimális mértékben sem, de tovább ténykedhet 1000 bűnöző a net legsötétebb bugyraiban.

Tökéletes OPSEC nincs. Az pedig a kriminalisztika dogmaként kezelt megállapítása, hogy elkövetés sem létezik nyom nélkül.

Cikkem lényegi mondandója, hogy a felhasználó eszközeiről és viselkedéséről szerzett és naplózott információk nélkül pedig nyilván esélytelen lenne a jelenleg leghatékonyabbnak tűnő biztonsági megoldásokat megvalósítani. Ahogy a Snowden-botrányt követően készült South Park epizódban Cartman anyukája megjegyzi Carmannek: „Tudom, hogy az NSA kínozza a Mikulást, Szivem, de ez a biztonság ára.” Nemrég jegyeztem meg egy ismerősömnek, hogy meg nem tudnám mondani, hogy mennyi könyvet és cikket olvastam el a Snowden-sztorival kapcsolatban, de egyszerűen nem találtam olyat, ami a lényeget jobban összefoglalná, mint a Let Go, Let Gov South Park-epizód, aminek a mondandója van akinek úgymond átmegy, megint másoknak nem, magyar szinkronnal is nagyon jó lett.