Bűvös userID, ami a fél életed megmutatja bárkinek több szolgáltatásban

alice-csodaorszagbanA szolgáltatás, aminek a privacy beállításain még a legharceddzettebb felhasználók sem tudtak kiigazodni, ilyen módon kikotyogott mindent a felhasználókról tudtuk nélkül – és most nem is a gignatikus adatlopásra gondolunk – a Google Plus 2019. április 2-én szépen lehúzta a rolót. Ez azt jelentené, hogy a Google felhasználók egyedi, felhasználói azonosítói hozzáférhetetlenné váltak volna, ilyen módon nélkülöznünk kell egy igencsak ütős OSINT-eszközt? Nem egészen.

Nem részleteznénk, hogy a Google-fiók alá tartozó Youtube-azonosító, Google Plus-azonosító (amíg létezett), Google Hangouts-azonosító nem mindig ugyanaz, viszont egy ijesztően egyszerű trükkel számtalan információ fedhető fel egy Google-felhasználóról, ha a Google szolgáltatásaiban nem állította be megfelelő elővigyázatossággal, hogy mit is oszt meg önmagáról – vagy egész egyszerűen alapértelmezetten hagyta a kapcsolódó beállításokat. Nem lenne könnyű megállapítani, hogy ebben az egészben mi mindennek a csimborasszója, de alighanem az, hogy az androidos mobilok, valamint az iOS-re telepített Google-szolgáltatások alapértelmezés szerint szinte mindent publikusan lekérdezhető módon kezelnek.

Az alábbiakban egy példán keresztül lépésről lépésre vezetjük az olvasót, hogyan jeleníthet meg egy felhasználóról gyakorlatilag minden aktivitást az userID kinyerését követően. Nem foglalkozunk viszont a kinyert adatok lehetséges felhasználásával. Ez hasznos lehet, ha azt szeretnénk megállapítani, hogy valaki egy eldobható Gmail-es címet hozott létre nemrég vagy olyan felhasználó, aki aztán mindent megoszt ész nélkül, így nem lenne praktikus olyan munkahelyre felvenni, ahol minősített adatokkal kell dolgoznia, több ötletet nem is adnánk, ami viszont fontos, hogy az ilyen információkinyerés célirányosság nélkül nem kutatás, hanem stalkolás.

A Gmail-fiók az, ami aztán tényleg mindenkinek van, annak is, aki egyébként ezer éve nem használja, így ezen cikk szerzőjének is. Miután megnyitottuk a Firefoxon vagy a Chrome-ban a Developer tools-t, egyszerűen lépjünk be a Gmail-fiókunkba.

Ezt követően navigáljunk a bal fülőn előtűnő Google Hangouts tabra, ha nem lennénk bejelentkezve a Hangouts-ba, tegyük meg.

google-userid-gathering-1

AZ oldalra kihelyezett Developer tools minden mozzanatot naplózó Network tabja ekkor már tele lesz mindenféle lommal, amit a Clear console gombra kattintással üríthetünk ki. Ezt követően a session rögzítéséhez kattintsunk a Clear console melletti Record gombra. Miután ez megtörtént, a Hangouts tabon egyszerűen kattintsunk annak a vizsgálni kívánt felhasználónak a nevére vagy vegyük fel a Google Accounthoz kapcsolt, szinte mindig gmail.com-os címe alapján, ami ismert, majd kattintsunk rá. Ezt követően állítsuk is le a felvételt a Developer toolsban.

google-hangoust-developer-tools-2

Érdemes tudni, hogy még ha csetablakot is nyitottunk a felhasználóval – de nem írtunk neki – a másik fél mindebből semmit sem fog észlelni. A Developer tools-on a jobb egérgombbal való kattintás után válasszunk egy tetszőleges elemet, majd a Save all as HAR with content menüpontot és mentsük el a HAR-fájlt. (A módszer az esetek többségében működik, a másik felhasználó privacy beállításaitól függően – például bárki írhat neki vagy csak akinek elfogadta a meghívását korábban.)

Nem baj, ha alig értünk valamit abból, amit a böngészőnk küldött a Google felé és a Google arra válaszolt, ha pedig megnyitjuk nyers szövegként a fájlt, egy körülbelül egymillió soros masszát kapunk, amiben igencsak elveszünk, ha nem tudjuk pontosan, hogy mit is kell keresni. Az egyszerűség kedvéért most feltételezzük, viszont magának a Google-nek van saját, online HAR-elemzője, ahova csak fel kell tölteni a fájlt és már át is látunk a káoszon: https://toolbox.googleapps.com/apps/har_analyzer/

google-har-analizis-3

Az All entries nézetet választva a legegyszerűbb, ha a bal oldali keresőbe beütjük egy részletét az ismert felhasználói névnek vagy email-címnek, máris megkapjuk, hogy merre kotorásszunk tovább. Esetünkben a https://contacts.google.com/_/SocialPeopleHovercardUi/data/batchexecute kérésre adott válaszként, a jobb oldali panel Response content tabjára navigálva találjuk meg a 21 számjegyű azonosítót, ami a keresett felhasználó userID-ja.

Ha nem annyira penge a számmemóriánk, ezt a számot egyszerűen másoljuk ki egérrelmajd látogassunk el például a Google Maps-re, ahol ugye a felhasználói review-k is vannak.

A https://www.google.com/maps/contrib/ URL-t követően egyszerűen illesszük be a vágólapon lévő azonosítót a böngésző címsorába és már meg is jelenik az összes hely, ahova a felhasználó becheckolt és/vagy értékelte, továbbá azok a képek, amiket ő töltött fel. Amit fontos tudni, hogy az összes csak akkor jelenik meg mind a Reviews, mint pedig a Photos fül alatt, ha a lista végére gördítunk.

google-maps-osint-4

Természetesen nem csak a térképalkalmazást használhatjuk információforrásként, ellátogathatunk a Google más szolgáltatásaiba is, ahol rendszerint nem szükséges ennél bonyolultabb trükk, a felhasználó nevére kattintva előtűnik még, hogy milyen szolgáltatásban mennyire volt aktív, innentől pedig már tényleg csak egy lépés ellátogatni az adott szolgáltatásba, majd megnézni, hogy ott milyen nyomokat hagyott maga után.

google-felhasznaloi-aktivitas-osint-5

Ez persze nem feltétlenül működik döglött Google-szolgáltatások esetén, viszont ha például a már inaktív Google Answers szolgáltatásba keresnénk, minden további nélkül használhatjuk a inurl:answers.google.com operátorral a felhasználó nevét, felhasználónevét vagy azonosítóját.

Nem lehet elégszer hangsúlyozni, hogy a kutatásnak mindig célirányosnak kell lennie – jelen esetben kellően aktív felhasználót választottunk – intuitív adja magát a kérdés, hogy miért jó valakinek, ha gyakorlatilag ráköti az agyára az internet patásördögének kikiáltott szolgáltatását, a Google-t, aztán megoszt mindent. Nem tárgya a cikknek, de alighanem egész egyszerűen nem is tudja, hogy amit feltölt, gyakorlatilag korlátozás nélkül megjeleníthető, esetleg egy felhasználó véletlenül tölt osztott mappába olyan fotó vagy videós tartalmat, amit rosszabb esetben tényleg mindeképp célszerűbb lett volna mondjuk a négy fal közt hagyni 🙂

google-fotok-osintGDPR ide, GDPR oda, szolgáltatásokban folyamatosan throttle-olt API-k ide vagy oda, mindig meg lehet találni a módját számunkra új módszereknek vagy módszerek kombinációjának, amik a nyílt forrású információszerzést segítik. Ez különösen fontos, ha azt nézzük, hogy az etikus hekkelés területén az első lépés mindig annak feltérképezése, hogy mit is kellene támadni és hogyan, amiben persze nem csak szigorúan véve az informatikai infrastruktúra jellemzőinek ismerete játszhat kulcs szerepet, hanem a social engineering előkészítésekor bizonyos kulcs személyekkel kapcsolatos információk is.

Etikus hekkelést tanulnál? A NetAcademia oldaláról nem tűntek el, csak kissé elbújtak. A korábbi ethical hacking tanfolyamok elérhetők a Tanfolyamkereső NetAcademia almenüje alatt a Classic választékban keresve. OSINTológia tanfolyam legközelebb? Előre láthatóan az is!

Az adatszivárgások anatómiája

linkedin-jelszavakAz előző posztban hivatkoztuk a SecureNetworkx szakmai blogjának azt a bejegyzését, ami alapján gyorsan képbe kerülhetünk minden idők egyik legnagyobb – ha nem a legnagyobb – adatszivárgásáról. Nemrég a SecureNetworkx ügyvezetője, Kocsis Tamás beszélt az ISACA Budapest Chapter második szerdai előadásán arról, hogy hol is tart ma az, amit nevezhetnénk úgy is, adatszivárgás kutatás.

Mielőtt a mélyébe mennénk…
Mára követhetetlenné vált, hogy ténylegesen mennyi érzékeny felhasználói adat is szivárgott ki, ami biztos, hogy gyakorlatilag nincs olyan, aki valamilyen szempontból ne lenne érintett. Elég csak beütni az email címünket a https://haveibeenpwned.com/ oldalon, máris látható, hogy milyen szolgáltatásokat pattintottak meg, amibe a megadott email címmel regisztráltunk és mikor, olyan részletekkel együtt, hogy az email címen kívül a címhez tartozó jelszó is kikerült-e, esetleg “csak” jelszó hash vagy annál sokkal több minden.

Egyre többen valamilyen jelszókezelő alkalmazás használatát javasolják amolyan silver bulletként, amikkel kapcsolatban azért lehet megfogalmazni kritikákat bőven. Ezeknek az alkalmazásoknak a lényege ugye az lenne, hogy egy mesterjelszót kelljen megjegyezni, majd ennek a megadásával a jelszókezelő az adott alkalmazásba kifillezi az ott megadott jelszómezőt. Egy könnyedebb téma, hogy ez miért messze nem a legjobb ötlet. Azt most ugorjuk át, hogy ezek a jelszókezelők is tartalmazhatnak komoly szoftveres sebezhetőségeket, aztán esetleg az a mesterjelszó mégsem védi annyira jól az összes többi jelszót, mint ahogyan azt logikusan gondolnánk. De hogy egy egyszerűbb trükkre gondoljunk, arra sincs 1000%-os garancia, hogy amikor valaki letölt egy 1Passwords-t vagy LastPass-t valamilyen eszközére, akkor a valódi alkalmazást tölti le és nem annak valamilyen megtévesztésig hasonló gonosz klónját egy eltérített oldalról. Ami pedig szerintünk a legkomolyabb rizikó: ha egy laptop vagy asztali gép esetén van egy azonosítatlan keylogger, hiába a jelszómenedzser, a mesterjelszó ellopásával a támadó gyakorlatilag viszi a boltot, az összes jelszót, amit a szolgáltatásra bíztunk. Ha pedig mobileszközről van szó, több esetben találkoztak már olyan esettel, amikor egy, háttérben futó alkalmazás az érintőképernyőt figyelte meg, ami tehát a keylogger mobileszköz-beli megfelelője, belegondolva pedig annál is rosszabb, mivel nehezebb azonosítani.

Amennyiben tartjuk magunkat az erős jelszó elvéhez, valamint ahhoz, hogy mindenhol más jelszót használjunk, mégis mit lehet tenni, ha biztonságban szeretnénk tudni a hozzáféréseinket, ugyanakkor ne kelljen reggelente bemagolni a különböző jelszavakat, de felirkálni se? Eddig nem igazán van normálisabb, széles közben alkalmazható stratégia, mint az, hogy gyakorlatilag az agyunkat használjuk hash-elésre, így a bonyolult jelszavakat is könnyedén meg tudjuk adni, mindenhol mást és mást. Azaz eléggé jó gyakorlat lehet a jelszóképzésre, ha van egy bizonyos, eleve eléggé bonyolult karaktersorozat, aminek a végére biggyesztünk egy olyan karaktersorozatot, amit egy általunk kitalált séma alapján képzünk. Példaként az adott szolgáltatásba való belépéshez szükséges jelszó végét a szolgáltatás mássalhangzóinak számából képezzünk valamilyen logika alapján. Azaz példaként a LinkedIN-be való belépéshez a matyómintás fix sztringünk végére kerül, hogy LnkdN, mivel 5 mássalhanzónk van, ezt felszorozzuk 7-tel, amire osztási szabály sincs, amit pedig kapunk, a végére írunk, így lesz LnkdN35. Mivel a 35 páratlan szám, még egy felkiáltójelet teszünk a végére. Igazából fejszámolás kérdése, hogy milyen cizellált szisztémát találunk ki rá, ami biztos, hogy mondjuk egy Beni19890623LnkdN35! jelszót már annyira nem egyszerű kitalálni az elterjedtebb módszerekkel, feltéve, ha a fix rész a mostani vagy néhai kutyánk neve is, hozzácsapva egy születési dátumot.

Ami a Troy Hunt és mások által feltárt és a nemrég alaposan kivesézett esetet illeti, egyfajta gyorstalpalót mutatunk be amellett, hogy mire lehetnek alkalmasak az érzékeny hozzáférési adatokat tartalmazó halmazok.

A kiszivárgott adathalmazokkal kapcsolatban eleve izgalmas kérdés, hogy vajon mennyi ideje lehetnek elérhetőek, mekkora kör számára, ami biztos, hogy a feketepiaci áruk az idő előrehaladtával csökken, míg idővel ingyenessé válik, ha úgy tetszik, amolyan közkincs lesz. A hagyományos keresőmotorokkal ilyen adathalmazokat keresve amire biztosan lehet számítani, hogy az első értelmes forrás a nagyon sokadik találat lesz, a másik pedig, hogy természetesen több olyan találat is elénk kerülhet, ami nem jelszóadatbázis, hanem konkrétan egy malware, amit nem a legbölcsebb letölteni virtuális gép, erős AV motor vegyvédelmi felszerelés nélkül, előre pedig nem látszik rajta, hogy malware lenne. Ahogy a múltkori előadáson elhangzott, lehetnek olyan paste-oldalakon fellelhető források, amik base64-ben kódolt szövegnek tűnnek, letöltve pedig éles víruskódként fognak működni.

Itt egy konkrét esetet mutatunk be, ami – úgy fest – nem harap. A https://publicdbhost.dmca.gripe/ oldalról letölthető az egyik LinkedIN-breach felhasználói név-jelszó adatbázisa, ami látszólag 2017. májusában került fel erre a helyre, arról viszont szó sincs, hogy a fájl 2017. májusi leakből származó adatokat tartalmazna, egyrészt valószínűleg régebbieket, másrészt láthatóan már egy “átdolgozott kiadásról” van szó, amire hamarosan visszatérek.

Ha egy műértő letölti a fájlt, kibontva egy 11 GB méretű plain textet kap, amit persze nem lehet megnyitni csak úgy. Ennek egyik oka, hogy az oprendszer eleve nem engedi, hogy például egy sima szöveg megnyitására alkalmas szövegszerkesztő rántsa magával az összes rendszererőforrást egy fájl megnyitásával, másrészt a szövegszerkesztőknél nyilván van egy ésszerű méretbeli korlát, aminél nagyobb fájlt nem lehet megnyitni. Az egészet hagyományos szövegként megnyitni természetesen nem is kell. Ha macOS-t vagy egy kényelmesebb linux disztrót használunk, nagyon gyorsan kereshetünk benne parancssori eszközökkel, Windows esetén pedig válasszunk olyan megoldást, amivel elfogadható sebességgel kezelhető a fájl, akár darabolás nélkül. Erre megfelelő lehet a PowerShell, a legelegánsabbak és leggyorsabbak mégis az olyan *nix-es környezetből ismert eszközök, mint amilyen a grep. A grep persze nem része a Windows CLI-nek, viszont a Cygwint vagy annak valamelyik kistestvérét használhatjuk minden további nélkül, ennek a részletezése viszont nem tárgya a posztnak.

A grep a hatalmas fájlban akár regexek alapján is nagyon gyorsan megtalálja, amit keresünk. Ha a fájl tartalmi felépítése nem lenne eleve ismert, akkor persze érdemes az első néhány sort megnézni előtte, amiből kiderül, hogy a fájl email-címeket tartalmaz, kettősponttal elválasztva a hozzá tartozó jelszó hash-sel.

Feltételezzük, hogy nem konkrét felhasználót keresünk, hanem arra vagyunk kíváncsiak, hogy a Lausanne-i Egyetem címével regisztrált felhasználók közt mennyien érintettek. A varázsszó:

grep -i “unli.ch” linkedin_all.txt

Ennek kimenetének egy részletét ezek az ábrán láthatjuk:

linkedin_adatszivargas

A -i paraméter miatt a grep nem finnyáskodik, azaz nem tesz különbséget kis- és nagybetűk közt, a felsorolásban jórészt, de nem kizárólag olyan címeket találunk, amikben szerepel, hogy unil.ch, ezt követi a hash, kettősponttal elválasztva.

Az első, ami eszébe jut annak, aki nem sok ilyet látott, hogy amellett, hogy ezek az adatok már eleve régiek, csak hasheket látunk, ami közvetlen belépésre tehát elvben nem alkalmasak. Ezzel kapcsolatban van néhány rossz hírünk.

A kiszivárgott adatokkal eleve probléma, hogy szinte biztosan élő email címeket tartalmaz, ami aranybánya a spammereknek. Másrészt igaz, hogy nem jelszót látunk, csak hash-t, aminek definíciószerűen az lenne a lényege, hogy ne lehessen belőle visszakövetkeztetni a jelszóra, ez a gyakorlatban nincs így.

Máig vannak olyan szolgáltatások, amik rossz fejlesztői gyakorlatot követve olyan hash-algoritmussal hash-elik a jelszavakat, amiket nem is ilyen célra találtak ki eredetileg, mint amilyen a jelszó hasheléshez egyszerűen gyenge MD5.

A LinkedIN-nél – elvben erős algoritmus használnak, mint a SHA-1 ezek viszont nem ún. salted-hash-ek.

Anélkül, hogy belemennénk a hash-elés matekjába-néprajzába, néhány gyakorlati szempontot mindenképp szem előtt kell tartani. Az egyik, hogy az MD5 már sok-sok évvel ezelőtt is annyira gyenge algoritmusnak számított hash-elésre, hogy egy átlagos gép néhány nap, esetleg néhány óra alatt visszaguberálta belőle a jelszót, a SHA-1 esetén pedig egy-egy számítási felhő pedig hasonlóan eléggé gyorsan végezhet.

Ennek egyik módja az ún. szivárványtáblák használata.

Hogy mit jelentenek az “xxx”-ek egy-másik után a konkrét példában? Jól mutatja, hogy mennyire valós is a veszély, hogy több forrás szerint ilyen-olyan hashkiller szolgáltatásokkal, mint amilyen például a https://hashkiller.co.uk/hash-min-max.aspx visszaguríthatók’ igen bonyolult jelszavak is, ha azok nem voltak alaposan sózva. A xxx jelentése a szövegfájlban, na, az aggodalomra ad okot, minimum. A Cyberforce-n megjelent forrás valószínűsíti, hogy ezek olyan jelszavak hash-lenyomata, amik megegyeznek olyan jelszavak hash-lenyomatával, ami a leggyakrabban használt jelszavak közé tartoznak, ilyen módon túl egyszerű lenne a n00boknak a jelszót kinyerniük belőle, a felkészültebbeknek viszont annál könnyebb. Vagy olyan jelszavak lenyomatai, amit az adott felhasználó más szolgáltatásban is használt, ergo egy korábbi adatszivárgással már össze lett vetve (!!). Alighanem a 2016-os LinkedIN-breach adatbázisában számtalan hash-t találnánk, mint amik a 2012-ben kerültek ki, tehát a felhasználó nem változtatott jelszót ez idő alatt.

Ahogy az ISACA előadásán elhangzott, 2017-ben 816 millió egyedi felhasználói adat szivárgott ki, pontosabban ennyit azonosítottak – nem feltétlenül csak hozzáférési adatok – 2018-ban 621 millió, amihez a mostani “Collection #1”, “Collection #2” megjelenésével együtt alighanem bátran hozzácsaphatunk akár fél-egy milliárdot is. Ahogy a január 9-ei előadáson és a Hacktivity-n előadott előadásban is volt róla szó, paste oldalakon, de a Github-on úgyszintén bőven akad forráskódokban publikusan hagyott API kulcs is, művészbejárót hagyva egy-egy szolgáltatásba.

Régi adat nem vén adat! A témát számos vonatkozásban lehetne még ízlelgetni, ha hirtelen úgy gondolnánk, hogy egy több éves adatbázissal akkor sem lehet mit kezdeni, ha abban plain textben tárolt felhasználói név-jelszó párosok vannak, mint a 000hosting-ot ért támadás eredményeként kikerült gyűjtemény esetén, mivel a felhasználó azóta már úgyis megváltoztatta a jelszavát, valószínűbb, hogy nem. A mezei felhasználók alapvető hozzáállása, hogy ha történt egy adatszivárgás, oldják meg az informatikusok vagy a szolgáltató, ami régen rossz. Ritkább az olyan eset, amikor a szolgáltató jelszóváltoztatásra kényszeríti a felhasználót, a breach-et vagy bejelentik egyáltalán vagy sem, de a felhasználó nem változtat jelszót. Már csak azért sem, mivel már-már érzéketlenné vált arra a hírre, hogy hetente történik valamilyen adatszivárgás. A biztonságtudatosabb felhasználó is emberből van, így ő sem fog feltétlenül jelszót változtatni, amik, ahogyan korábban utaltunk rá, ráadásul gyakran több szolgáltatásban azonosak. így a több évvel ezelőtti gyűjtemények vélhetőleg még mindig használható belépési adatokat tartalmaznak.

Szinte kínos elismételni, hogy mennyire rossz hozzáállás az, ha valaki úgy gondolja, hogy nem lehet célpont, ezért mondjuk úgy, lazára veszi a figurát. Rendszeresen jelennek meg olyan botok, amik például régen frissített CMS-eket támadnak meg és tesznek zombivá, botnethálózat tagjává téve őket. Nemrég egy WordPress core-t érintő sebezhetőség lényegében már ismert jelszavakkal próbált belépkedni, amint pedig sikerült neki, olyan módon módosította a blogmotor kódját, hogy az más WordPress-oldalakat fertőzzön meg.

Hogy az adatszivárgások hogyan észlelhetők a leghamarabb, már-már elfogadható időn belül, egy későbbi posztban beszámolunk, olyan részletekre nem tértünk ki, hogy mi az, amit semmiképp ne tegyünk, ha nyugodtan szeretnénk aludni. Az index.hu valamelyik cikkében a szerző egy korábbi adatszivárgás kapcsán még meg is írta, hogy az adatok hitelességét úgy ellenőrizték, hogy beléptek az érintett szolgáltatásba. Az ilyen adatokon jól vizsgálható több minden a felhasználói magatartással kapcsolatban az „öreg jelszó nem vén jelszó” elven túl. Ha valakinek egy belépési adat tudomására jut, önmagában azzal nem sérti meg a törvényt. Ha viszont annyira ostoba, hogy ellenőrzésként belép valaki más nevében egy szolgáltatásba, így információkhoz juthat, amihez semmi köze, azonnal. Arról nem is beszélve, hogy az egyre kifinomultabb szolgáltatások kiszúrják, ha szokatlan helyről történik bejelentkezés helyes felhasználói név-jelszó párossal és zárolják a fiókot, amit aztán a tényleges tulajdonosa vagy fel tud oldani ésszerű idő alatt vagy sem.

kép: CSOOnline