Impresszum Help Sales ÁSZF Panaszkezelés DSA

About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (38),Facebook (18),privacy (17),egyéb (12),social media (11),itsec (11),social web (10),biztonság (9),mobil (8),Google (6),OSINT (6),jog (6),szellemi tulajdon (6),tudomány (6),magánszféra (6),szájbarágó (5),email (5),webcserkészet (5),molbiol (5),felzárkóztató (5),Nobel-díj (4),big data (4),Gmail (4),kultúra (4),terrorizmus (4),online marketing (4),kriminalisztika (4),plágium (4),webkettő (4),genetika (3),molekuláris biológia (3),pszichológia (3),azelsosprint (3),Android (3),biztonságpolitika (3),nyelvtechnológia (3),magatartástudomány (3),Apple (3),sajtó (3),2015 (3),orvosi-fiziológiai (3),élettudomány (3),gépi tanulás (3),jelszó (3),üzenetküldés (3),CRISPR (3),Onedrive (3),2-FA (3),popszakma (3),konferencia (3),levelezés (3),kriptográfia (3),reklám (3),biztonságtudatosság (3),hype (3),torrent (3),open source intelligence (3),neuropszichológia (2),Whatsapp (2),deep web (2),FUD (2),kulturális evolúció (2),nyílt forrású információszerzés (2),TOR (2),hitelesítés (2),titkosítás (2),Pécs (2),bűnügy (2),tweak (2),facebook (2),SPF (2),DKIM (2),bűnüldözés (2),DDoS (2),bejutas (2),videó (2),Reblog Sprint (2),természetes nyelvfeldolgozás (2),villámokosság (2),Hacktivity (2),Yoshinori Ohsumi (2),reblog (2),cyberbullying (2),arcfelismerés (2),ransomware (2),fiziológia (2),Netacademia (2),webkamera (2),szabad információáramlás (2),P2P (2),Balabit (2),cas9 (2),beszélgetés rögzítése (2),pszeudo-poszt (2),molekuláris genetika (2),bulvár (2),gépház (2),tartalomszolgáltatás (2),jövő (2),bolyai-díj 2015 (2),könyv (2),Tinder (2),öröklődő betegség (2),HR (2),sudo (2),Yandex (2),bug (2),nyelvtudomány (2),meetup (2),Twitter (2),tanulás (2),biológia (2),netkultúra (2),malware (2),IDC (2),social engineering (2),szociálpszichológia (2),kutatás (2),hírszerzés (2),iOS (2),vírus (2),farmakológia (2),pedofília (2),epic fail (2),génterápia (2)

Triviálisan lehallgatható a Gmail (is)


Igen, jól olvasod, ennyire ügyesen sikerült implementálni a kétlépcsős hitelesítést és valószínűtlen, hogy elsőként vettem észre.

Nem clickbait, azzal kapcsolatban meg mindenkit megnyugtatok, hogy nem arról fogok írni már megint, hogy miért necc az, hogy egy Google/Gmail-heroinista világban élünk.

Aki bekapcsolta a Google Accountján ennek a remek, überbiztonságos rendszernek a beállításai közt a kétlépcsős hitelesítést annak ugye ún. alkalmazásjelszavakat kell létrehoznia, ha például levelezőklienssel is használná a Gmail-t, mivel értelemszerűen a kliensprogram nem tudja pár percenként elvégezni a 2-FA-t magától.

Elvben az alkalmazásjelszavakban pont az a szép, hogy nem kell a felhasználónak fejben tartania, így egyszer kell kopipésztelni a megfelelő helyre és kész, kilopni legfeljebb egy hülyén programozott alkalmazásból lehet, amiben meg lett adva.

Na már most normális ésszel az ember azt gondolná, hogy abban az esetben, ha a felhasználó a 2-FA-t kikapcsolja, akkor az összes alkalmazásjelszó semmissé válik, így például a levelezőkliesen keresztül a levelek csak a fő jelszó beírásával lesznek elérhetőek. Van egy nagyon szar hírem a Google fanoknak: a korábban létrehozott alkalmazásjelszavak nemhogy érvényüket vesztenék, hanem továbbra biztosítják a hozzáférést a fiók adott szolgáltatásához, legalábbis az IMAP4 esetén biztos, Google Drive és a többi esetén valószínűleg, a hasonló  azonosítási séma miatt. Nem, nem ideig-óráig működik, egy érintett fiók több, mint egy hónapja elérhető az elvben már nem létező alkalmazásjelszó használatával úgy - most figyelj! - hogy a fiók fő jelszava is meg lett változtatva. Még az is full mindegy, hogy OAuth2-vel vagy sima, ugyan titkosított csatornán átküldött jelszóval jelentkezik fel a kukkoló alkalmazás!

Mit jelent ez a gyakorlatban? Tételezzük fel, hogy a támadó a célpont gépéhez ül, amíg nincs ott, majd generál egy alkalmazásjelszót olyan névvel, ami még akkor sem lesz feltűnő, ha a Google kényszeríti az érintett felhasználót a security checkup végigjátszására, az app password leírása lehet mondjuk "Gmail", "Mail", "iPhone" vagy hasonló, a megtámadott felhasználónak miért lenne gyanus? A támadó az alkalmazásjelszót feljegyzi. Az alkalmazásjelszóval a támadó belép egy levelezőklienssel, majd IMAP4-en keresztül tokkal-vonóval olvashatja a célpont postafiókjának tartalmát. A Google vagy küld figyelmeztetést az érintett felhasználónak, hogy bejelentkezett valaki mondjuk egy japán VPN-en keresztül, ami igencsak anomáliaszerű, ha a felhasználó sosem használ VPN-t és korábban még csak nem is járt Japánban. Viszont vegyük észre, hogy éppen azért, mert levelezésről van szó, a támadó ezt a levelet simán tudja törölni, mielőtt a felhasználó el tudná olvasni a biztonsági figyelmeztetést!

Tehát ha a felhasználó valamilyen okból kikapcsolja a 2-FA-t, de előtte nem vonja vissza az alkalmazásjelszavak érvényességét, teljesen logikusan arra gondolva, hogy azok ilyen módon érvényüket vesztik, valójában erről szó sincs. Egy korábban beállítva maradt fiókhoz a levelezőprogram úgy fér hozzá máig, hogy az érintett fiókon a 2-FA-t 2018. február elején ki lett kapcsolva, a fő jelszó pedig át lett írva!

A támadó vagy úgy felejtett alkalmazás csak akkor veszti el a hozzáférést az érintett postafiókjához, ha az érintett fiók tulajdonosa ismét bekapcsolja a 2-FA-t, egyébként meg gusztus szerint úgy tesztelheti a hibát, rosszabb esetben pedig kukkolhat, ahogy csak akar.

Az abnormális működést 2018. március 5-én, azaz ma 10:13-kor sikerült reprodukálni egy teszt fiókkal, ugyan nem csináltam sem TCPdumpot, sem HAR-t, mert jobb dolgom is van, aki ráér, annak szabad a pálya.

Hogy ez most bug vagy kényelmi feature,  na, azt nem tudom, ahogy azt sem teszteltem, hogy a Google mára kőkeményen fizetős, vállalati verziója, a G Suite is érintett-e benne, de valószínűleg igen.

Legegyszerűbb bugfix: ne használd azt a szart, legfeljebb spamszűrésre, azaz olyan beállítással, hogy a beérkező leveleket azonnal forwardolja is normális helyre és végleg törölje.

Áldásos lenne, ha ahelyett, hogy a felhasználók leginkább veszélyeztetett néhány ezrelékét nem riogatnák azzal, hogy kormányzati támadást észleltek, ezért változtassanak jelszót és költözzenek le a pincébe, bármiféle indoklás nélkül, hogy miből következtetett erre a rendszer.

Valamint a felhasználók ugyanezen veszélyeztetett csoportjára nem akarnák rátukmálni pusztán a biztonságérzetet növelő, de legalább jó drága baromságokat az Advanced Protection Program keretében, hanem a mezei Gmail-fiók úgy működne, ahogy az amúgy logikusan elvárható. Az én, eredetileg még googlemail.com végződéssel, 2004-2005. körül USA-ból kapott meghívóval létrehozott fiókom pedig csak azért is marad amolyan bóvli kis emlékként.

0 Tovább

Honnan tudható, hogy a címzett olvasta-e az emailed? 


email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésAmikor emailt küldünk valakinek, annak reményében tesszük, hogy azt a címzett majd el is olvassa. Ugyanakkor bármikor bárki mondhatja, hogy az emailt nem kapta meg, spamben landolt, nem volt még ideje foglalkozni vele, ugyanakkor indokolt esetben, ha a levél kellően fontos volt, tudunk kellene, hogy a levelet a címzett olvasta-e és ha igen, akkor mikor is. Hogyan oldható meg mégis a feladat? Tökéletesen sehogy, de részmegoldás azért van.  

Sokak számára alighanem már csak amolyan megmosolyogtató emlék, hogy az emailek olvasottságáról a címzettől visszajelzést kérhetünk, ha levelezőrendszerünk támogatja azt a pattintott kőkorszakból ránk maradt funkciót, amiben kérelmezi a címzettet, hogy jelezzen vissza a feladónak emailen, ha a levelet elolvasta. Ezt tekinthetjük a klasszikus e-tértivevénynek. A lehetőséget szinte már senki sem használja, ugyanis alapvetően a felhasználók többsége nem akarja a címzettel tudatni, hogy a levelet elolvasta-e, ha fontos dologról van szó, úgyis jelentkezik majd, ha pedig nem, jobb elsumákolnia, aztán tud jönni valami vérszegény kifogással. 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésAhogy írtam, gyakorlatilag egy kihalt lehetőségről van szó, mivel még ha kérünk is ilyen visszajelzést, a címzett levelezőrendszere ezt vagy figyelembe veszi vagy sem, ha támogatott a visszajelzés funkció, a felhasználó még mindig dönthet róla, hogy küldjön visszajelzést, ne küldjön visszajelzést, esetleg a levelezőrendszer rá se kérdezzen, így soha senkinek ne küldjön olvasottsági visszajelzést. 

Ugyanakkor fennmaradt az a természetes igény, hogy a feladó tudhasson róla, hogy a levelét a címzett megkapta, olvasta, csak ha nem válaszol, tesz rá magasról vagy nem jutott el hozzá. Az egész pedig egy régi jó technikával szinte mindig kivitelezhető, hamarosan rátérek, hogy miért nem garantáltan mindig. 

Amikor egy webszerverről egy dokumentumot letöltünk, annak a naplófájljába bekerül többek közt, hogy milyen IP-címmel, milyen böngészővel és böngészőverzióval, milyen oprendszerrel és annak milyen verziójával, azaz milyen géppel történt a letöltés. Megjegyzem, ezek kombinációja sokszor már önmagában is igencsak egyedi. Már több, mint tíz évvel ezelőtt is úgy küldték a hírleveleket a szolgáltatók, hogy abban olyan grafikus elemeket, azaz képeket helyeztek el, amiket HMTL formátumú levélbe szerkesztettek bele, a képeket pedig ennek megfelelően nem csatolták az emailhez, hanem egy külső szerverről töltötték be a HTML megjelenítésnek megfelelően a címzettnél. Nyilvánvaló, hogy ha a levél normálisan megjelent, a hírlevél küldője visszajelzést kapott azzal kapcsolatban, hogy a levelét egyáltalán mennyien nyitották meg, hiszen látta, hogy mennyi különböző logbejegyzés van, ami a képi elemek szerverről való letöltődését tanusította. Biztonsági szempontból viszont nagyban gondolkozva igen nagy kockázatot jelent, ha tudható, hogy valaki pontosan milyen platformmal netezik, ráadásul az IP-címekhek kapcsolódó szervezet és annak helye egyre pontosabban azonosíthatóvá vált az évek folyamán. 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésSok-sok évvel ezelőtt már minden jólnevelt levelezőkliensben és webes levelezőrendszerben alapértelmezés volt, hogy a HTML-formátumú levelekben lévő távoli szerveren tárolt képeket nem tölti le automatikusan, hanem rákérdez a felhasználónál, hogy letöltse-e azokat. Ha a felhasználó úgy döntött, hogy ne töltse le, akkor a feladó nem értesült róla, hogy a címzett a levelet megkapta-e. Viszont könnyen lehet, hogy a címzett egyszerűen nem tudta elolvasni a levelet, mert ilyen-olyan lényegi információk nem szöveges formátumban, hanem egy képre írva voltak a levélben, mint például egy szilveszteri parti helyszíne. Így ha a címzettet érdekelte a dolog, mindenképp le kellett töltenie a képet, mint külső tartalmat is. 

Ez még mindig az ókor. Aztán jöttek az ügyesebb hírlevélkézbesítő rendszerek, amik minden egyes címzett leveléhez külön-külön, egy egyedi, távolról letölthető képet is linkeltek. 

Azaz például, ha valaki feliratkozott pistike@example.org címmel, akkor a hírlevélküldő az adott címhez és hírlevélhez generált egy egyedi nevű fájlt a szerveren, mondjuk http://hirlevelkuldo.tld/track/d1a3c5382be1a69c57f7caccbb8c6858.gif 

ahol a fura nevű GIF, tipikusan 1x1 pixeles átlátszó GIF-fájl a HMLT-levélbe volt ágyazva és ha a fájl a levéllel együtt letöltődött a szerverről, akkor az egyértelműen bizonyította, hogy a pistike@example.org címre kiküldött hírlevél kézbesítődött és Pistike meg is nyitotta azt, természetesen azzal az információval együtt, hogy mikor. 

Az ilyen típusú állandó feedback mesterkéltnek tűnhet, viszont olyan hírlevelet küldeni, amire a felhasználó valaha feliratkozott, a levelezőrendszer nem vágja azonnal spambe, drágább mulatság, mint amilyennek tűnik, a hírlevél küldője pedig érthető módon tudni szeretné, hogy mennyi értelme van egyáltalán hírlevelet küldözgetnie. 

Ezen kívül voltak még ilyen-olyan torzszülött megoldások, mint például a HTML-levélbe ágyazott JavaScript-kód, ami elvben a levél megnyitásakor lefut, érthető módon kicsit is normális levelezőrendszer nem tette lehetővé az azonnali kódfuttatást a levél megnyitásakor. 

Azaz maradt a jó öreg 1x1 pixeles megoldás, ami persze nem csak hírleveleknél vethető be, hanem minden további nélkül egyénileg küldött leveleknél is. Számos szolgáltató van, ami lehetővé teszi ilyen levelek küldését, úgy, hogy a részletekkel a feladónak ne kelljen foglalkoznia, ami viszont közös bennük, hogy sosem garantálják 100%-ra a visszajelzést, de az esetek többségében igen.  Ezek közül egyet mutatok be, utána pedig azt, hogy mindez hogyan kivitelezhető sokkal geekebb stílusban, bármilyen szolgáltató igénybevétele nélkül. Ezen kívül feltételezem, hogy a levelezéshez a legtöbben Gmail-t használnak, azt is webes felületen keresztül – ott viszont gyakorlatilag mindig működik. 

http://www.getnotify.com/ oldalon egyszerűen csak regisztrálni kell azzal a saját email címünkkel, amelyikkel követett levelet szeretnénk küldeni, majd ha ez megvan, teljesen hagyományos módon megírhatjuk az emailt a címzettnek, nemes egyszerűséggel csak a címzett címének végére kell biggyeszteni a getnotify.com hosztnevet. Azaz ha a címzett pistike@example.org lenne, akkor a levelet a pistike@example.org.getnotify.com címre kell küldeni. 

A küldést követően a Getnotity a levelet átformázza HMLT-formátumúvá, akár HTML levél volt eredetileg, akár nem, majd elhelyez benne a kézbesítésre nézve teljesen egyedi nevű átlátszó fájlt, majd a levél fejlécét olyan módon módosítja, hogy levágja a .getnotify.com hosztnevet a cím végéről és továbbküldi a levelet a címzettnek. A címzett a levelet megkapja, megnyitja, a feladó pedig a Getnotify felületén keresztül értesül is róla, hogy a levél meg lett nyitva, mi több, ha a címzett a levelet többször is megnyitotta, az összes időpont szerepelni fog, amikor a levél meg lett nyitva. Hogy érthetőbb legyen, egy Gmail-es címre küldött levél kézbesítési reportja valahogy így néz ki: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Mint látható, a report szinte mindent mutatna, ami a kézbesítődéssel kapcsolatos, ráadásul külön-külön, amennyiszer megnyitotta a címzett a levelet, ebben az esetben persze a tesztlevelet egy saját gmail-es címemre küldtem. Gyakorlatilag viszont a levél megnyitásának idején kívül semmilyen értelmes adat nem hámozható ki például a címzett földrajzi hollétét illetően, mert annak helyén a Google szerverei által odamókolt adatok vannak. Mi lehet a magyarázat? 

A Google nagyon jól tudja, hogy a Gmailt a többség webes felületen keresztül használja, ugyanakkor azt is, hogy ha azonnal betöltenék a távoli tartalmakat, az egyrészt felfedné a felhasználó hollétét, az általuk használt platformot, ugyanakkor emellett nyilván igény van rá, hogy a HTML-formátumú emaileket a felhasználók el tudják olvasni úgy, hogy azokban megjelennek a képek is. Éppen ezért nem is olyan rég a Gmail-ben az lett az alapértelmezett beállítás, hogy a távoli tartalmakat is automatikusan betölti a levél megnyitásakor, viszont nem az eredeti helyéről, hanem előzetesen a képet a Gmail a háttérben gyorsítótárazza a GoogleImageProxy-n keresztül, majd innen töltődnek be a képek ténylegesen. Ekkor viszont természetesen a küldő rendszer nem a valódi címzett címét és egyéb platformjellemezőit látja, hanem a GoogleImageProxy-ét fogja naplózni. Nem megyek bele olyan finom részletekbe, hogy a Google természetesen a háttérben nem Windows XP-s gépeket használ Firefox böngészővel a gyorsítótárazáshoz. 

Persze mezei levelezőrendszer esetén, ha a HTML-levéllel távolról letöltődik az apró, átlátszatlan kép, a feladó teljesen valid információkat kap a címzett által használt platformmal kapcsolatban is, ez viszont szinte mellékes, ha a fél világ Gmailt, Outlook.com-ot és hasonlókat használ levelezéshez, amik a GoogleImageProxy-hoz hasonló megoldást alkalmaznak. A filléres és fapados levelezőfelületeknél, mint amilyen a Horde, Squirrel vagy a Roundcube, a rendszer ideális esetben rákérdez, hogy betöltse-e a távoli tartalmat, amit a felhasználó jó esetben csak akkor engedélyez, ha a feladó számára megbízható.  

Érdekesség, hogy az egyik legkomolyabb levelezőrendszer, a Microsoft Exchange alapértelmezés szerint úgy tölti be a levelek megnyitásakor a képeket, hogy nem is kérdez rá, hogy a távoli tartalmat letöltse-e. Az ok alighanem az, hogy meglegyen az a típusú kényelem, amiért egy-egy felhasználó elvár, ha a cége egy Exchange üzemeltetéséért fizet. Ott az Exchange előzetesen persze alaposan átvizsgálja, hogy a levél tartalmaz-e kártékony kódot, amit akár egy képbe rejtettek el, de nem proxyzza magukat a képeket, hanem letölti azokat az eredeti helyükről, így ha tudjuk, hogy a címzett Exchange-t használ a cégnél, ritkábban magáncélra, ott jobban jobb lesz a „találati arány”. 

Végülis mennyire megbízható konkrétan a Getnotify? 

A saját súgóoldalán ugyan azt állítja, hogy a címzett semmit fog észlelni abból, hogy egy követett küldeményről van szó, ez igaz is és nem is. Az átlag felhasználó valóban semmit sem fog észlelni belőle, kicsit is jobban megnézve viszont ordít a trackelt levélről, hogy az egy köztes átjárón lett keresztülpréselve valami miatt. Éppen a Gmail nemrég vezette be azt az újítást, hogy a feladó mellett egy törött piros lakatot helyez el akkor, ha a feladó rendszere nem szavatolta, hogy az email csak titkosított csatornán kézbesítődhet, márpedig a Getnotify esetén ez a helyzet. 

A részleteket megnézve pedig egyre büdösebb lesz a dolog: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Ami pedig már bizonyító erejű, ha megnézzük az emailt nyers formátumban, ahol nem csak az kerül ki, hogy a látszólag egyszerű szövegként küldött levél valójában egy egyszerű szövegnek tűnő HTML-levél benne egy-két érdekes képpel, ami sima nézetben nem látszik, hanem az is, hogy ha a feladó domain nevéhez DKIM-rekord tartozik, a fejlécben látható, hogy az sérült, lévén hogy a levelet valami út közben megváltoztatta, ez egyébként annak az esélyét is nagyban növeli, hogy a levél a címzettnél spamben landol. 

Összességében elmondható, hogy nem, bárki bármit is mond, máig nincs olyan csoda technika, ami biztosan szavatolná, hogy a levél olvasottságáról a feladó biztosan tudomást szerezzen, pláne nem úgy, hogy azt a címzett ne vegye észre, ha akarja, legalábbis hagyományos emailek esetében nincs és ez így van jól. Ez a technikailag meglehetősen egyszerű trükk viszont az esetek döntő többségében működik, csak személyre szóló levél küldésekor nem túl bizalomgerjesztő, ha a címzett észreveszi, hogy előzetes beleegyezése ellenére ellenőrizni akarta a feladó a levél olvasottságát, hiszen ahhoz vagyunk hozzászokva, hogy ez a címzett magánügye. Egy személyes hangvételű levélbe bele lehet varrni olyan linket, amiben valaminek a megtekintésére kérjük a feladót egy linken keresztül, ami persze olyan szerveren van tárolva, amihez a logjaihoz hozzáférünk, hiszen ekkor ugyanúgy szervernaplóba kerül a linkelt tartalom letöltése, csak éppen egyáltalán nem biztos, hogy kattintani is fog a linkre a címzett. 

Ami fontos, hogy olyan levelet, amilyet például a Getnotify.com készít, írhat bárki, aki olyan levelezőprogramot használ, amelyik támogatja a nyers HTML-szerkesztést, amiben csak egy saját tárhelyre mutató, akár láthatatlan képet lehet elhelyezni, ez lenne a kézműves megoldás. 

Megjegyzem, gyakorlatilag minden levelezőrendszerben tiltható, hogy a levél egyáltalán HTML-ben jelenjen meg vagy éppen az, hogy külső képeket töltsön be. Ha mégis ilyen levelet kapnánk, megbízunk a feladóban tipikusan néhány kattintással engedélyezhetjük a teljes megjelenítést. 

Mindegy, hogy a Getnotify-ről vagy szó vagy valamelyik másikról, a működési elve mindnek az, amit leírtam. A kukkoló funkciót különböző levelezőrendszerek esetén ezekkel a beállításokkal lehet teljesen hatástalanítani.  

Gmail esetén: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

AOL-on: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Zimbra rendszerben: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Horde-n: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Hushmailen: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Roundcube-on: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Squirrelmailnél: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

1 Tovább

A Gmail megmondja, hogy hiteles-e a levél. Tényleg?  


Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladóHa egy levelezőrendszernek hatékony a spamszűrő rendszere, azaz kevés legitim levél landol a szinte sosem nézett levélszemét mappába, ugyanakkor a bejövő levelek közt nincs spam, nyilván jó. Ha már a levelezőrendszer akarja eldönteni a felhasználó helyett, hogy mi levélszemét, kevésbé az. Arról már volt szó, hogy néha a Facebook üzenetküldő úgy viselkedik, mint a Bermuda-háromszög, arról is, hogy az emailek hitelesítése hogyan vagy hogyan nem történik, azokhoz képest most középhaladó téma jön.

Korábban írtam róla, hogy a Facebook üzenetküldési logikájának megváltozása miatt gyakorlatilag sosem lehetünk biztosak abban, hogy a másik felhasználónál kézbesítődik is, amit küldünk, majd nem sokkal később röviden arról, hogy a klasszikus levelezőrendszerek hogyan küzdenek a spam ellen.

Az utóbbiban spamvédelem szempontjából két, a feladó és a levelezőrendszer hosztneveihez kötődő azonosítási technikát emeltem ki, ami megnehezíti, hogy az emailek meghamisítsást és valaki más nevében küldjön levelet. Megnehezíti, de nem teszi lehetetlenné! Mindkét módszer szorosan kapcsolódik a domain-név szolgáltatáshoz, egyszerűsítve az SPF, azaz Sender Policy Framework csak azt ellenőrzi, hogy az adott domainről/levelezőrendszerből jogosult-e a feladó levelet küldeni, míg a DomainKeys és a továbbfejlesztéseként létrejött DKIM már alá is írja a levelet digitálisan, azaz tudja mutatni, hogy a levelet esetleg módosította-e valaki vagy valami miközben a feladótól a címzettig jutott. Végül megjegyeztem, hogy ezek csak annyit igazolnak, hogy a levelet az adott postafiókból küldték, de azt nem, hogy a feladó tényleg a postafiók tulajdonosa, erre már a magasabb szinten működő PGP alkalmas, hiszen a PGP-s digitális aláíráshoz a feladónak az aláíráshoz ott kell ülnie a gép előtt, hacsak nincs a beállítás elszúrva.

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladóA levelezőrendszerekben vagy SPF van beállítva vagy DKIM, gyakran mindkettő, igazából nem is nagyon kell foglalkozni vele. A Gmailt ugyan csak azért nézegetem, hogy képbe kerüljek, ha valamit újítanak benne, a napokban lettem figyelmes a Gmail Labs egyik lehetőségére, amit bekapcsolva a Gmail egy, a levelek mellett lévő apró lakattal jelzi, hogy a Gmail meggyőződött a levél feladójának hitelességéről. A súlyos probléma csak az, hogy a feature ebben a formában súlyosan megtévesztő, mivel a kis lakat megjelenítéséhez megkövetel egy olyan rekordot is, amit a gigaméretű levelezőrendszereken kívül a többi feladó nem tűz a levélhez, saját domainnel használt levelezésnél pedig csak akkor működik hibátlanul, ha ahhoz valakinek saját szervere is van.

A hasznos kis lakatfunkció több tényezőt is ellenőriz a SPF-re és a DKIM-re támaszkodva, ezen kívül figyelembe vesz még egy rekordot, amiről nem írtam. Nos, igen, ha valaki úgy gondolta volna, hogy a levelek hitelesítésével kapcsolatos protokollokat már nem lehet hova tovább cizellálni, annak írom, hogy hát persze, hogy lehet: ez a DMARC, teljes nevén Domain-based Message Authentication, Reporting and Conformance.

Az SPF-re tekinthetünk úgy, mint a feladó postahivatal és helység azonosításáért felelős jelölőre, a DKIM-re pedig úgy, mint a levél írójának aláírására. [a PGP-re pedig úgy, mint a pecsétgyűrűvel levélre nyomott viaszos pecsétjére]. De a fenti Google-funkciót megkövetelő DMARC első ránézésére egyfelől egyszerű, másfelől viszont annyira elborult, hogy komolyan nem tudok rá életszerű analógiát hozni.

Ugyanis a DMARC nem mást csinál, mint a hitelességet hitelesíti, megvizsgálja, hogy az SPF rendben van-e, ha több küldő szerver is küldheti a levelet ["postahivatal"] és ezzel egybehangzóan a DKIM-mel is minden oké, ha esetleg azonos címről érkezhet elvben levél teljesen eltérő levelezőrendszerekből is. Visszapillantva az előző posztban hozott témához, a magyar levelezőrendszerek nem rendelkeznek saját küldő szerverrel, azaz SMTP-vel, így ha valaki nem webes felületen, hanem levelezőprogrammal vagy a mobiljával szeretne levelet küldeni a mobil beépített levelezőkliensével, akkor abban küldő szervernek a szolgáltató SMTP-szerverét fogja beállítani, aminek viszont semmi köze nem lesz a feladó domainhez és az ahhoz kapcsolódó hosztnevekhez. Ez UPC esetén smtp.upcmail.hu lesz, amire  @upcmail.hu-s azonosítóval lehet fellépni, Telekom esetén pedig a mail.t-online.hu az SMTP szerver, amivel a t-online.hu-s címmel léphetünk fel, ha nincs netszolgáltatásunk csak egy magentás mobilunk, akkor mail.t-email.hu hosztnévvel és így tovább. Azaz például az indamail-es levelet a Telekomon vagy az UPC SMTP szerverén keresztül nyomva szigorúan nézve semmi sem garantálja, hogy valóban a feladó mezőben lévő felhasználó küldte a levelet, mivel egy levelezőrendszer szervereinek semmi köze nincs a netszolgáltató szervereihez, a címzett szerver gondolhatja úgy, hogy a címzett csak oda lett kamuzva a levélhez, ha az például Citromail.hu-s, az egyszerűsítésekért bocs.

Azaz azt kellene valahogy elérni, hogy a Gmail-es címzettek postafiókjában ott legyen a kis lakat, ha esetleg tömegesen bekapcsolják ezt a funkciót, ez viszont csak akkor fog működni, ha a feladónál helyes SPF, DKIM és DMARC rekordok vannak beállítva. És itt kezdődik a totális rémálom: az SPF rekord ugye egy egyszerű dolog, viszont a DKIM-et már támogatnia kell a levelezőrendszernek, ami a levelet küldi, azaz nem elég csak a domainnév-szerveren léteznie az aláíráshoz szükséges publikus kulcsnak, magának a szervernek az aláírást el kell végeznie. Ez azért még minden komolyabb saját domaines levelezőrendszerben elérhető, úgy, mint a 10 felhasználóig ingyenes Zoho Mail vagy a Yandex Domains. Viszont a levelezőrendszerek többsége a postagalambnak nem mondja meg, hogy még egy DMARC értéket is oda kellene böknie. Például még a Microsoft Exchange Online esetén is csak alig egy éve van erre lehetőség és persze érdemes azt is figyelembe venni, hogy a DMARC-ot a címzett szervere majd vagy értelmezi vagy sem függően attól, hogy fel lett-e készítve rá.

Az előző levelezőrendszerekkel foglalkozó posztban írtam, hogy a Gmailen a kis nyílra kattintva kiderül, hogy a levelet formálisan ki küldte milyen domainről [ez a példában a whitehouse.gov volt], ezt követően ténylegesen milyen domainnel [ami egy filléres netszolgáltató szervere volt] és ki hitelesítette [ez a mező hiányzott, nem kötelező]. Azaz valahogy így:

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó

A példában használt Zoho viszont nem támogatja a DMARC-ot, ezért eleve nem lehetett beállítani sem, megnéztem, hogy mi történik, ha a levél küldéséhez a szintén több tízmillió felhasználóval rendelkező Microsoft Exchnage Onlinet használom, persze megfelelő beállítás után.

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó

Remek! Tehát nem a hosztnév virít a hitelesítő domain helyén, mint amelyik a feladóé annak ellenére, hogy az SPF szabálynak megfelel a levél, a DKIM ugyancsak szabályos, ahhoz nem is lehet hozzányúlni, mivel az az Exchange szerver belügye, legalábbis EOL esetén. A levél hosszú fejlécéből kiderül, hogy ez már tartalmaz szabályos DMARC jelölést is.

Gmail Labs hitelesítés DKIM DMARC SPF email spoofing középhaladó

De akkor miért nem kapott lakatot? Egy lehetséges ok, hogy a DKIM hitelesítés szabályos ugyan, de az már nem a feladó címéhez tartozó domainnévhez lett hozzárendelve.

Az IT-s részletekről alighanem már így is többet írtam, mint amennyire az a töbséget érdekelheti, a kínos kérdés csak az, hogy akkor most a Gmail valóban meg tudja mondani automatizáltan, hogy egy email hiteles-e? Hát persze, hogy nem! Ugyan a DMARC-technika hatékonynak tűnik az email spoofing most ismert módszerei ellen, könnyen keltheti azt a megtévesztő benyomást a felhasználókban az addon, hogy amelyik levél mellett nincs lakat, az nem feltétlenül hiteles, ami pedig még rosszabb, hogy emellett azt a benyomást is, hogy amelyik mellett pedig van, az biztosan hiteles olyan értelemben, hogy a feladó írta. Na ez a tragikus. És persze az, hogy a Gmail, az Outlook, a YahooMail, a Yandex megint úgy tesz, mintha rajtuk kívül nem is létezne levelezőrendszer, szóval szépen alkalmazkodjon mindenki hozzájuk.

Mi a megoldás? Továbbra is az éberség és a józan eszünk. Ha valamilyen kétség merül fel azzal kapcsolatban, hogy egy beérkező levelet esetleg nem a feladója írt, nézzük meg a levél hosszú fejlécét, igaz, abban tudni kell, hogy mit is kellene benne nézni.

A posztot végig kísérte az a gondolat, hogy a levél feladóját és íróját ne keverjük, nyilván küldhet valaki akár közvetlenül más postafiókjából is levelet, ha annak a jelszava 10 éve ugyanaz és már a postit cetlit, amire rá van írva, úgy kellett a monitor szélére celluxozni. Azt, hogy a levél feladója és írója azonos, ahogy írtam, a PGP szavatolja. Igaz, alapvetően a PGP célja más, de nem alapvetően más. Mindkét megoldás végülis a levélhamisítás ellen hivatott védeni. Hogy mikor lesz PGP a Gmailben? Nyilván soha. Egyrészt azért, mert nem éreznék a felhasználók eléggé komfortosnak, ha a belépéshez használt jelszón kívül egy másikat is meg kellene adni egy-egy levél elküldése előtt, másrészt nyilván elkezdenének titkosítani is vele a felhasználók a digitális aláírás mellett, azaz csak a címzett és a feladó tudná elolvasni a levelet, maga a Google nem. Nos, ez nem érdeke egy olyan levelezőszolgáltatónak, ami a magánlevelek tartalmának befalásából él, igaz, az ebből szerzett információ jórészét arra használja fel, hogy a szolgáltatásai hagyományos értelemben használhatóbbak legyenek és hatékonyabb legyen a keresés.

0 Tovább

Gmail-törés egyetlen mobilszámmal


Körülbelül két héttel ezelőtt tett közzé a Symantec egy figyelmeztetést az otthoni felhasználók részére egy videóval együtt, amiben pazar módon elmagyarázzák, hogy hogyan lopható, "törhető" egy Google Account  mindössze az áldozat mobilszámának ismeretében. /*azaz hogyan férhető hozzá a Gmail mellett az áldozat összes kapcsolódó Google-szolgáltatáshoz való hozzáférése is a jelszó ismerete nélkül*/

A módszer lényege nagyon röviden:

1. a támadó kattint az elfelejtett jelszóra a Google bejelentkező felületén, megadja az áldozat címét, majd kiválasztja a jelszóhelyreállítás módjainál, hogy SMS-tokent kér a visszaállításhoz. Ez ugye az a rövidke számsor, ami az áldozat mobiljára megérkezik, majd a begépelésével új jelszó állítható be.
2. Az áldozat persze azonnal figyelmeztetést kap, hogy valaki jelszóhelyreállítást kért a nevében és persze magát a tokent /*vegyük figyelembe a pszichés hatást is!*/, ilyennel bizonyára már többen találkoztatok Ti is korábban. Valami ilyesmire kell gondolni:

"Your account was logged into from a new browser or device. Review the login: https://webhely.tld/token_helye"

"Your account was recently logged into from Safari on Windows."

"Facebook Password reset code: [öt-hat számjegyű szám] Or reset your password here: http://fb.com/l/token_helye" [1]

"Access data for your account has been ordered by you personally or by someone else. Your temporary password: [jelszó helye]"

3. És itt jön a csavar, a támadó egy, az áldozat által nem ismert mobilszámról SMS-t küld, ami nagyban hasonlít a webszolgáltatások előbb idézett rendszerüzeneteihez, majd hozzáteszi, hogy a fiókja biztonságosabbá tétele érdekében SMS-ben küldje el válaszként a tokent.

4. Az áldozat kellően beparázik ahhoz, hogy ne vegye észre azt, hogy a válasz SMS-t egy közönséges mobilszámra küldi, ami kézbesítődik is a támadó mobiljára, aki a böngésző előtt vigyorogva szépen bekalapálja a tokent, új jelszót állít be és már el is lopta a fiókot, az áldozat legfeljebb akkor veszi észre, hogy valami nagyon nem stimmel, amikor legközelebb próbál belépni, de akkor már valóban új jelszót kell kérnie, hiszen nyilván nem tudja, hogy mit adott meg a támadó. Esetleg a támadó egy olyan kamu SMS-t küld, amiben egy kamu ideiglenes jelszó van és azt állíttatja be a felhasználóval olyan körítéssel, hogy ne változtassa meg pár napig :)

Videó, hogy szemléletes legyen:

Hozzáteszem, hogy a Symantec a Gmail-en mutatja be a módszert, de vegyük észre, hogy gyakorlatilag bármilyen webalkalmazásnál bevethető a támadás, ideértve a Facebookot, LinkedIN-t, Evernote-ot, stb. aminél a fiókhoz hozzá van rendelve mobilszám.

Adja magát a kérdés, hogy a támadás kivédésére mi jelent megoldást és mi nem?

Első laikus gondolat, ami nemhogy nem jelent megoldást, utalva a korábbi posztjaimra, nagyon veszélyesen hülye ötlet, a fiók még könnyebben ellopható:
- ha nincs beállítva mobilszám - hiszen így akkor sem tud a szolgáltatás azonosítani, amikor a legitim felhasználónak lenne rá szüksége
- ha olyan mobilszám van hozzárendelve, amit más nem ismerhet meg - ne vicceskedjünk már, ilyen egész egyszerűen nincs, soha nem is lesz, még olyan életszerűtlen esetben sem, amikor valaki fene nagy biztonságtudatosságában direkt a webszolgáltatásokhoz vesz egy SIM kártyát, amit a mobilszolgáltató titokban tart, a felhasználó a számot nem árulja el senkinek. Egészen egyszerűen nincs olyan, hogy "beszerezhetetlen mobilszám".

Akkor mi jelent megoldást? Egyszerűen az, ha a felhasználó figyelmes, és semmilyen webes szolgáltatásból érkező SMS-re nem válaszol, mivel ilyet normális webes szolgáltatás szinte sosem kér, néhány nagyon ritka esetet leszámítva!

Egyébként a videó megjelenése óta gondolkoztam rajta, hogy ezt megírjam-e vagy sem, több szempontból. Egyrészt egész egyszerűen azért, mert ez a blog nem news outlet, nem posztolom újra, amit más kitalált, esetleg csak abban az esetben, ha ahhoz eléggé sokmindent hozzá tudok tenni. Másrészt azért, mert ez a tweak nekem konkrétan annyira nem új, hogy már ezer éve találkoztam vele, ugyanakkor felvet egy fogós etikai kérdést. Amikor valaki talál egy programhibát, ami esetlegesen kihasználható, majd azonnal közzéteszi, ezzel kényszerítve a szoftverrendszer fejlesztőjét a minél gyorsabb javításra, full disclosure-nek nevezzük, megoszlanak a vélemények azzal kapcsolatban, hogy ez mennyire jó gyakorlat. Nos, teoretikai szempontból az olyan módszerrel kapcsolatban is tehető közzé full disclosure, mint amilyen ez, azaz egy kevéssé ismert social hack ismertetése, viszont remek kérdés, hogy erre a szolgáltatók hogyan reagálnak, persze legnagyobb valószínűséggel sehogy, ugyanakkor alighanem lesznek olyan pöcsök, akik megtalálják mondjuk ezen a blogon, aztán fel is használják, mivel a téma iránti érdeklődés finoman fogalmazva is intenzív – ja, az egy tálca sört még tartom!  

Ugyanakkor egyrészt a blogolás olyan értelemben nem felelősségteljes műfaj, hogy agyalnom kellene annak a közvetett következményein, amit leírok,  az is előfordulhat, hogy aki biztonságtudatossági tréningeket tart, esetleg itt találkozik a módszerrel először, aztán be tudja építeni a tananyagba, hogy aztán a felhasználók erre a támadási formára is fel legyenek készítve.

Azoknak írom, akik erre a posztra keresőn keresztül találtak rá törési gyorstalpaló után kutatva és primitív kíváncsiskodó pöcsként nem értik meg, hogy a barát, barátnő, főnök, alkalmazott, feleség fiókjához való illetéktelen hozzáférés milyen súlyosságú dolog, azt tudom mondani, hogy nyugodtan próbálják ki, mivel az előzetes megfelelő anonimizáláshoz, na meg mondjuk úgy, laborkörülmények beállításához elég eszük úgysincs, a web giantek meg nem hülyék, jó esetben szokatlan aktivitás esetén úgyis meggátolják a támadást, bónuszként azonosítják a támadót, de úgy, hogy őt rúgják ki végleg, szóval hajrá!  

Sokszor nem értik, amikor arról beszélek, hogy alapvetően mindenféle jelszóemlékeztető, jelszóhelyreállító feature rossz, pláne, ami nem igényel emberi beavatkozást, akármilyen szofisztikáltnak tűnik is. Ugyanakkor erre nyilván szükség van tömegszolgáltatások esetén, hiszen semmilyen szolgáltatás, amelyik közvetlenül nem kér előfizetési díjat a használatáért, egyszerűen nem engedheti meg magának egy harceddzett ügyfélszolgálat fenntartását [2], ugyanakkor azt sem, hogy a felhasználóik semmilyen módon ne férhessenek hozzá a fiókjukhoz például amikor valóban elfelejtették a jelszavukat.

Vegyük észre, hogy a netbank-rendszerek már nem ilyen hülyék, nem lehet beállítani új jelszót csak úgy, néhány banknál még telebankon keresztül sem, ahogy azt is, hogy itt - az én definícióm szerint - ismétcsak szó sincs törésről, csak egy átlagosan kifinomult trükkről, ami az emberi tudat egy sajátosságát használja ki, - ami ugye esetfüggően bug vagy feature :) -  nem pedig egy szoftveres hibát!  

[1] korábban a FB-ban volt egy olyan jelszóhelyreállító metódus, amiben a mobilra érkező 5 számjegyű számmal lehetett új jelszót beállítani. Nos, ekkor megérkezett egy token SMS-ben, amit a felhasználónak meg kellett adnia, ha pedig elírta, akkor a Facebook figyelmeztette, hogy helytelen, ezért adja meg újra, VISZONT nem korlátozta a próbálkozások számát! #facepalm!!! Tehát akár automatizáltan is bárki bárki másnak a fiókján végigpróbálgathatta a maximálisan 99999 lehetséges ismétléses permutációt - átlagosan ebből ugye tehát mindössze ötvenezer próbálkozás is elegendő volt, majd ha talált, beengedte a szolgáltatás a támadót. A módszer persze azóta már nem működik és a próbálkozások számán túl még nagyon sok mást is figyelnek a normális webszolgáltatások annak kiküszöbölése érdekében, hogy a jelszót valóban a fiók tulajdonosa tudja csak átírni, aztán ha támadást tapasztal, ahogy írtam, szépen szögre akasztja a támadót.

[2] Ami a szolgáltatások supportját illeti, nos, igen, kivétel minden alól van. Ortó nagy botrány volt belőle, amikor kiderült, hogy jelszóvisszaállításkor az Apple telefonos supportja az új jelszó beállításához csak a fióktulajdonos postai címét kérte el meg talán még egy adatot, amit bárki megtudhat, a gyakorlaton mégis csak akkor változtattak, amikor már jópár Apple-fiókot feltörtek. Másrészt bizonyos esetekben a Google csak akkor engedélyezi az új jelszó beállítását, ha a fiók tulajdonosa befizet 1-3 USD-t, ekkor egy alkalmazott is megnézi a felhasználó korábbi aktivitását, majd valamilyen belső policy alapján eldönti, hogy a kapcsolattartói email-címre küld-e átmeneti jelszót. Azt viszont már nem ellenőrzik, hogy a bankkártya, amivel ezt az összeget valaki fizeti, annak a nevén van-e, akinek a nevén regisztrálva van a fiók :)

A legdöbbenetesebb tapasztalatom konkrétan személyes és egy óriásszolgáltatóhoz tartozik, mivel nem tudom, hogy a módszer működik-e még, nem írom meg, hogy melyikről van szó. Történt, hogy egy szolgáltatásba még kiskoromban regisztráltam, nem használtam évekig, amikor pedig ismét léptem volna be, a jelszó nem stimmelt. Gondoltam, semmi probléma, ott az account recovery, igen ám, de a hozzá tartozó email cím már nem élt, már a domain sem, így oda nem tudtam jelszóhelyreállítót kérni. Ahogy az ott szépen le volt írva, felvettem a kapcsolatot a supporttal, megírtam nekik, hogy mi az ábra, viszont lévén, hogy ilyet bárki írhat, feltüntettem azokat az adatokat, amiket csak én tudhatok, nevezetesen, hogy évekkel korábban másodperc pontossággal mikor regisztráltam /*megvolt az ezzel kapcsolatos email a benne lévő aktiváló kóddal együtt*/, melyik netszolgáltatót használtam akkor. Olyan válasz érkezett, hogy azt hittem, nem hiszek a szememnek: a supportos tag ragaszkodott hozzá, hogy arról az email címről írjak nekik, amelyikkel regisztráltam, holott pont azért írtam nekik, mert a postafiók már nem létezett. Aztán küldtem nekik még néhány adatot, ami nyilván megvolt nekik is, rajtuk kívül csak én tudhatok róla, de a tag ragaszkodott a belső policyhoz, aztán ellevelezgettünk pár napig. Végén gondoltam, hogy ez már tuti bukó, nincs vesztenivalóm, aztán lezavartam neki a legcifrább kurvaanyázást, amit csak tudtam, ékes angolsággal viszont - itt jön a lényeg - az emailem fejlécét úgy változtattam meg, hogy annak a feladó mezőjében az általuk kért, a már nem létező címem szerepeljen, válaszcímként pedig olyan, ami létezik és azt is megírtam nekik, hogy egy több tízmilliós szolgáltatásban ez a gyakorlat nevetséges, hiszen ilyen alapon bárki lenyúlhatja más fiókját egyszerűen a supportnak küldött email fejlécének megmókolásával. Nem hiszitek el, hogy mi történt: a supportos azonnal küldött jelszót /*hiszen formálisan arról a címről írtam nekik, amelyikhez tartozott az account!*/ és visszakaptam a hozzáférést a szolgáltatáshoz.

képek: geekpause.com, hackpla.net, mikeyanderson.com

4 Tovább