bardóczi ákos @post.r

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.

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.

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:

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.

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.

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.

 Ahogy egyre nagyobb részben folytatjuk a személyes és munkához kapcsolódó kommunikációt is a neten, folyamatosan vált egyre fontosabbá, hogy minden olyan eszköz, ami ezt biztosítja egyre stabilabb és biztonságosabb legyen. Ezeknek az szolgáltatásoknak az egyike az email, ami - ahogyan írtam a korábbi posztomban - mai formájában legalább három évtizede létezik, megelőzte a web születését közel tíz évvel, a net legősibb, máig széles körben használt szolgáltatása és alighanem minden webes óriást túl fog élni, amiről ma még nem gondolnánk, hogy valaha bizony vége lesz.  
 
Kiemelt fontosságú, hogy ha emailt kapunk, ellenőrizhető legyen, hogy a feladó valóban az-e, akinek gondoljuk, ezt pedig sokszor ugyan azokra a technikákra támaszkodva lehet megtenni, amit spamvédelem céljából kitaláltak. Egy durván meghamisított levél példáján mutatom be, hogy mikor mit érdemes nézni, az emailek hosszú fejléce minden webes levelezőrendszerben megjeleníthető, a legelterjedtebb Gmail esetén például a levél megnyitását követően a legördülő menüben a Show original pontra kattintva. 

 Amikor valaki egy nevet és egy hozzá tartozó email címet lát a feladó mezőben, teljesen természetesnek veszi, hogy a levelet az írta, akinek a neve és címe olvasható, nemde? Óriási tévedés! Az, hogy a feladó neve és a cím mezőben mi álljon, csupán egy adalék információ, amit a feladó szervere az email fejlécéhez hozzáfűz, viszont semmiféle megkötés nincs azzal kapcsolatban, hogy ott mi szerepelhet, mi több, még az sem megkötés, hogy ki legyen töltve. Viszont abban az esetben, ha valaki megmókolja a levelezőrendszert a levélküldés idejére olyan módon, hogy az valamilyen tetszőleges címet csapjon a levélhez, a levél elmegy ugyan, a címzettnél akár a spam mappába megy, akár sem, a levelezőrendszerek a címzettnél jó esetben figyelmeztetnek azzal kapcsolatban, hogy a levél valószínűleg hamisívány. Viszont, ahogy a frissen előállított példában látszik, simán lehet, hogy nem, annak ellenére, hogy minden arra utal, hogy a levél hamisítvány, mégsem jelzett a Gmail emiatt. Hamisított levélre utaló figyelmeztetést eredményezhet más is legitim levelek esetében, viszont érdemes tudni, hogy hogyan tudható meg esetleg több a valódi feladó kilétéről. 
 
Nosza, lássuk azt az előbb emlegetett hosszú fejlécet! 
 
Delivered-To: bardoczi@gmail.com 
Received: by 10.27.186.198 with SMTP id k189csp415282wlf; 
        Fri, 8 Jan 2016 03:48:06 -0800 (PST) 
X-Received: by 10.140.101.201 with SMTP id u67mr91933194qge.33.1452253686478; 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Return-Path: <president@whitehouse.gov> 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
        by mx.google.com with ESMTPS id r9si92146028qhb.7.2016.01.08.03.48.06 
        for <bardoczi@gmail.com> 
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Received-SPF: softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) client-ip=104.193.143.56; 
Authentication-Results: mx.google.com; 
       spf=softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) smtp.mailfrom=president@whitehouse.gov 
Received: from localhost ([::1]:63179 helo=ecbiz178.inmotionhosting.com) 
    by ecbiz178.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) 
    (Exim 4.85) 
    (envelope-from <president@whitehouse.gov>) 
    id 1aHVWX-000DKS-T9 
    for bardoczi@gmail.com; Fri, 08 Jan 2016 06:48:06 -0500 
Received: from 179.43.161.147 ([179.43.161.147]) by 
 secure178.inmotionhosting.com (Horde Framework) with HTTP; Fri, 08 Jan 2016 
 11:48:05 +0000 
Date: Fri, 08 Jan 2016 11:48:05 +0000 
Message-ID: <20160108114805.Horde.zOWNX3cXXgeNf-MxqaUvuw5@secure178.inmotionhosting.com> 
From: President of US <president@whitehouse.gov> 
To: bardoczi@gmail.com 
Subject: =?utf-8?b?aGFkw7x6ZW5ldA==?= - fake =?utf-8?b?bGV2w6ls?= 
Reply-to: akos@null.net 
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) 
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes 
MIME-Version: 1.0 
Content-Disposition: inline 
Content-Transfer-Encoding: 8bit 
X-OutGoing-Spam-Status: No, score=3.6 
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report 
X-AntiAbuse: Primary Hostname - ecbiz178.inmotionhosting.com 
X-AntiAbuse: Original Domain - gmail.com 
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] 
X-AntiAbuse: Sender Address Domain - whitehouse.gov 
X-Get-Message-Sender-Via: ecbiz178.inmotionhosting.com: authenticated_id: akos@genetics.bardoczi.net 
 
A valódi küldő felhasználó azonosítása és a feladó mező összevetése az első lépés.  
 
A hosszú fejléc sorai közt az X-szel kezdődők nem kötelezők a levelezőrendszerek számára. A levelezőrendszereknek nem kötelező hozzáfűzniük, hogy egy levelet pontosan milyen felhasználó vagy alkalmazás feladói felhatalmazásával küldenek, viszont ha nem totálisan hülyén van konfigurálva a levelezőrendszer, akkor tartalmaz ilyet, ez jelen esetben az "authenticated_id: " sor, amivel gyakorlatilag semmi sem stimmel. A sorban lévő akos@genetics.bardoczi.net csak annyit mond, hogy amikor a levelezőrendszer átvette kézbesítésre a levelet, akkor ezzel a felhasználói névvel lett feljogosítva a levélküldésre. Ha semmilyen azonosítás nem feltétele egy levél kiküldésének, ún. open relay szerverről beszélünk, azaz olyan levelezőszerverről, amin keresztül bárki bármit küldhet bármiféle azonosítás nélkül. Mivel valamikor rég ezeket előszeretettel használták a spammerek, open relay-t már nagyon keveset találunk, hiszen ha olyan helyről érkezik email, azzal valami teljesen biztos, hogy nem stimmel. Ugyan vannak a neten olyan oldalak, ahol egyszerűen csak meg kell adni, hogy mi kerüljön a feladó, a tárgy és az üzenet mezőbe, hova menjen az email, az ilyen levelek jobb helyeken közel biztos, hogy spamben landolnak, másrészt általában még az ilyen kamu emailek sem open relayen keresztül mennek, hiszen a hamisító szolgáltatás van feltüntetve küldésre feljogosított felhasználóként, ami persze csak a hosszú fejlécből derül ki. Viszont vegyük észre, hogy legalább van lehetőség azonnal kideríteni, ellentétben például a Facebook-üzenettel, amivel a továbbiakban nem fogom hasonlítgatni az emailt.  
 
A bűvös boríték és "vissza a feladónak", azaz envelope és return-path 
 
Ha jobban megfigyeljük a levelet, figyelmesek lehetünk az egyik Received sorban található "envelope-from <president@whitehouse.gov>" részre. Az envelope, azaz boríték azonosításához a levelezőrendszerek sokszor külön sort hoznak létre, akkor biztosan, ha az nem egyezik a valódi emailcímmel, ami felhasználói név is egyben. Még a Return-path sorban is a hamis email cím szerepel, ami azt a címet tartalmazza, ahova a címzett szerverének mailer daemonjától várja a visszaküldést akkor, ha a kézbesítés sikertelen valami miatt, azaz ide pattan vissza a feladóhoz a levél. Egy szó, mint száz, ebben az esetben (sem) szerepelt valami fényesen a legelterjedtebb kommersz levelezőrendszer a kamu levél kiszűrérében. 
 
A postás és a postahivatal  
 
Persze az azonosított feladó cím lehet, hogy még mindig nem mond semmit, az első Received sorban lévő szerver hosztneve és IP-címe már egyértelműen azonosítja, hogy mi is vette át a levelet küldés céljából elsőként:  
 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
 
Márpedig ha ennek utánanézünk például az ARIN adatbázisában, abból kiderül, hogy a levél egy mezei hosztingszolgáltatótól jött, ráadásul azon belül is egy olyan szerverről, ahova a filléres hosztingot igénylő ügyfelek oldalait teszik, mint amilyen az én életrajzi oldalam. Ennek ténye egyre valószínűtlenebbé teszi, hogy a levél valóban a Fehérházból jött volna.  
 
Amikor az email küldéshez szerver sem kell  
 
Megjegyzem, elvben az is megoldható, hogy valaki az otthoni gépére telepítsen olyan szolgáltatást, amin keresztül tud levelek küldözgetni úgy, hogy maga a levelezőszerver is az ő otthoni gépe. Normál esetben egy levelezőszerver IP-címéhez tartozik egy hosztnév, ebben az esetben a reverse hostname-re gondolok, azaz ha nem tudnánk, hogy a ecbiz178.inmotionhosting.com hosztnévhez a 104.193.143.56 cím tartozik, a cím alapján meg lehet nézni a hosztnevet, már ha van.   
 
Egy egyszerű internetszolgáltatással rendelkező gépnek viszont nincs feltétlenül szüksége arra, hogy ahhoz hosztnév legyen hozzárendelve, abban az esetben pedig, ha mégis van hozzárendelve, akkor arról általában süt, hogy otthoni felhasználók gépeinek, végfelhasználóknak kiosztott hosznévről van szó. Egy UPC-s magánelőfizető IP reverzje aaa.bbb.ccc.ddd cím esetén catv-aaa-bbb-ccc-ddd.catv.broadband.hu lesz, azaz látszik ugyan, de ebből azonnal kiderül az is, hogy nem szerverről, hanem valakinek az otthoni gépéről van szó, a címre egyszerűen elég rákeresni az európai és közel-keleti IP-ket nyilvántartó RIPE-adatbázisában, ha nem lenne elég egyértelmű. Hasonlóan például egy Vodafone-os magánelőfizető címe hiába reverselhető, a RIPE lekérdezés alapján egyértelmű, hogy magánelőfizetőről van szó és nem pedig levelezőszerverről:  
 
 Még egy kicsit a hamisított feladói címről  
 
Adott címről érkező levél esetén természetesnek vesszük, hogy arra simán válaszolva a címzettnél meg is érkezik valami. Amikor emailt küldünk valakinek, a kézbesítéshez többek közt a domain név szolgáltatáson keresztül le kell kérdezni a hosztnévhez tartozó ún. MX-rekordokat, ami azt dönti el, hogy a beérkező emaileket mely gépek kezeljék, azaz kik töltik be a postahivatalok szerepét, ha a domain-nevet tekintjük a címzett városának. Ez a freemail.hu esetén például fmx.freemail.hu ugyan a netes szolgáltatások szabványosításáért dolgozó IETF azt javasolja, hogy levelet fogadó domainhez legalább kettő MX-rekord, azaz „postahivatal” tartozzon arra az esetre, ha az első valami miatt nem érhető el vagy túlterhelt, de ne is legyen belőle 10-nél több. Persze könnyen lehet, hogy ha csak egy MX-rekord van, akkor az egy terheléselosztó vagy tűzfal, mögötte sok-sok postással. Mégis gyakoribb megvalósítás, hogy MX-rekordból több van, a secure.bardoczi.net domain esetén például 14, földrajzilag gondosan távol egymástól, épphogy a Holdon nincs.   
  
Viszont ha az email címben szereplő domainhez nem tartozik MX-rekord, akkor gyakorlatilag biztos, hogy kamu címről van szó, hiszen MX-rekord nélkül az adott domain nem tud emailt fogadni, az pedig életszerűtlen hogy úgy működjön egy domain név, amiről csak küldeni tud, de fogadni már nem. A genetics.bardoczi.net jelen esetben ilyen:  

http://mxtoolbox.com/SuperTool.aspx?action=mx%3agenetics.bardoczi.net&run=toolpage  

Mi lehet a célja egy ilyen emailes scamnek?  
 
Felmerül a kérdés, hogy a példában hozott scam emailnek mi lehet a célja, miért kér a feladó bankkártyaadatokat, ha ezek szerint a president@whitehouse.gov címre érkezett levelet úgysem kapná meg, mivel nem is ő küldte? És egyáltalán: mindig érdemes a levél tartalma alapján felállítani néhány forgatókönyvet azzal kapcsolatban, hogy valaki kamu címmel, kamu személyazonossággal vajon miért írja pont azt, amit? Ebben a levélben ugye arról van szó, hogy ha a címzett nem küldi a bankkártyaadatait, itt bizony vér fog folyni. Mivel a Gmail rövid fejlécéből nem derül ki semmi szokatlan, a laikus felhasználó gondolhatná, hogy ha a válasz gombra kattint, a levél a whitehouse.gov-os címre küldi a levelet, ha viszont kamu, úgyis visszapattanna, nemde? Igen ám, viszont abban az esetben, ha a válaszcím, azaz az a cím, amire a feladó a választ várja, eltér a feladó címétől, ilyenkor a levelezőrendszernek kötelező elhelyeznie egy Reply-to sort, amiben pedig az akos@null.net cím van, aminek aligha van bármi köze is a Fehérházhoz. Viszont amikor az egység sugarú felhasználó a válasz gombra kattint, egyáltalán nem veszi észre, hogy a címzett mezőben már más cím szerepel, mint amiről a levél érkezett, amit épp megválaszol és erre a levelezőprogramok nem is hívják fel a figyelmet!  
 
Jelen példa persze blőd, de gondoljunk bele, hogy a feladó mezőben simán szerepelhetne egy bank címe is, a levélben a bankra jellemző arculati elemekkel és persze hihetőbb szöveggel, a válaszcím pedig lehet bármilyen ingyenes mailszolgáltatónál létrehozott, esetleg totálisan visszakövethetetlen emailcím, amire a csaló a kért adatokat megkapja, ha az áldozat válaszol is rá.   
 
A spamekkel és scamekkel vívott automatizált küzdelem  
 
Felmerülhet a kérdés, hogy hogyan jelenthet csak a spam önmagában sok-sok százmillió dolláros össz-veszteséget évről évre, ha olyan levelekről van szó, amiket a felhasználó úgysem olvas el? Úgy, hogy a spamek küldése, fogadása mind használja az IT erőforrásokat, legyen szó akár az adatátvitelről, akár arról, hogy ezeket a leveleket a levelezőszervereknek fel kell dolgozniuk, ami ugye processzoridőben mérhető, és persze valameddig tárolni is kell őket, aminek szintén forintosítható-dollárosítható ára van. Ahogyan annak is, ha az alkalmazott megnyit egy spamet, ha az olvasására csak negyed percet szán, az is a munkaidejéből megy el. Mindezek bagatell apróságoknak tűnnek, de ha nagyban gondolkozunk, ha már felhasználók számilliói érintettek, érthető, hogy miért kerül nagyon sokba a spam, még ha jól is van szűrve, nem is beszélve arról az esetről, amikor egy fontos levél falspozitívként kerül spambe és valaki nem értesül időben valamiről, ami egyébként fontos lenne. A scam, azaz a megtévesztő levél más műfaj és máshogy is okoz költségeket és kellemetlenségeket, például ha a felhasználó olyan linkre kattint, amivel valamivel alaposan lefertőzi a gépét, amit az antivírus termék nem szúr ki.  
 
Ami a spamben és a scamben közös, hogy nyilván minél jobban hasonlítaniuk kell a legitim levelekhez, hogy megtévesszék a spam- és scamszűrő rendszereket és eljuthassanak a felhasználókig. Így a versenyfutás a spammerek és a levelek biztonságáért felelős fejlesztők és kutatók közt folyamatos. Alapvetően a legitim és fölösleges-kártékony levelek szűrése a tartalom és a fejléc automatizált elemzésével történik. A tartalom alapú elemzéssel itt egészen röviden foglalkozom. Igencsak kifinomult gépi tanuláson alapuló mechanizmusok dolgoznak a háttérben, amikor nagy mintán tanulják a szerverek, sokszor közösen, hogy mik a spamek és a legitim levelek jellemzői, ez alapján következtetnek.  
 
A gépi tanulás lényegéről korábban már itt írtam annak kapcsán, hogy hogyan idomítottak be egy gépet arra, hogy megkülönböztesse az előnyös és az előnytelen szelfiket. A kifinomult tanulóalgoritmusok helyett vegyük a legegyszerűbb hipotetikus spamszűrőt: ha tudjuk, hogy egy 1000 levélből álló mintában abból a 200-ból, ami tartalmazza a Viagra kifejezést pontosan 199 spam, akkor a jövőre nézve biztosak lehetünk benne, hogy ha jön egy levél, aminek a szövegezésében a Viagra szerepel, jó eséllyel ugyancsak spam lesz. Ez az ún. Bayes-valószínűségen alapuló szűrés.  
 
Vissza a fejlécekhez  
 
A levélszemét szűrésének tartalmi elemzést megelőző lépése viszont a – sokkal kisebb számításigényű – fejlécelemzés, ráadásul ha a fejléccel túl sokminden nem stimmel, a levelet esetleg a szűrő már nem is vizsgálja tartalmi szempontból. A header elemzésekor többek közt a levelezőrendszer olyan sajátosságok után kutat, amikről írtam a poszt első felében, azaz amik végképp nem jellemzők egy normális emailre. Másrészt idővel bevezettek olyan technológiákat, amik a fejlécben helyeznek el extra, az emailt hitelesítő sorokat, azaz olyan sorokat, amiket pillanatok alatt ki tud elemezni első körben a fogadó szerver. Ezek ugyan messze nem tökéletesek, de jobbak, mintha csak tartalom alapú elemzésre és az alapvető ellentmondások elemzésére támaszkodhatna a spamszűrő.  
 
A Sender Policy Framework, avagy SPF  
 
A legősibb és legegyszerűbb megoldást az SPF jelentette. Szinte minden levél hosszú fejlécében találunk SPF-re vonatkozó sort, ami mutatja, hogy a domainhez beállított SPF-szabályokkal összevetve a levelet milyennek értékelte a szerver. Az SPF-szabályokat pedig a doménnév szolgáltatásból tudja lekérdezni. A kiértékelés eredménye lehet semleges, legitim vagy éppenséggel bukó, de ezzel a levél sorsa természetesen nem dől el végleg, hanem csak hozzáad vagy kivon abból a pontszámból, ami fölött a fogadó szerver egy levelet spamnek talál.  
 
Példaként, ha az SPF-szabály IP-cím alapján van meghatározva a domainhez tartozó domain név szerverben, az egy ilyesmi bejegyzés lehet a domainhez tartozó rekordok közt:  
 
v=spf1 a:kuldoszerver.example.com –all  
 
Ez annyit jelent, hogy a fogadó fél megnézi a küldést végző hosztnév IP-címét vagy hosztnevét és ha az egyezik azzal az IP-címmel, ami a kuldoszerver.example.com domainhez tartozik, akkor az a levél legitim, minden más esetben viszont valószínűleg spam, ezért el kell dobni, amit a -all paraméter határoz meg.  
 
Az SPF szűrési logikája alapulhat még más egyéb tényezőkön is, a fenti példát azért választottam, mert a legegyszerűbb, de van még pár beállítási lehetőség bőven.  
 
Fontos, hogy az SPF nem élet és halál ura, azaz ha például egy adott domainről érkezik hamisított feladóval egy levél, amit biztosan nem a domainhez tartozó levelezőszerveren keresztül küldtek, akkor az az SPF szerint spam ugyan, viszont a kifinomultan konfigurált spamszűrő csak egy valószínűségi értéket rendel hozzá, hogy ennek alapján a levél elbuktott, legitim vagy semleges. Hosszú lenne kifejteni, de az SPF működésmódjából adódóan egyrészt még ez is megkerülhető a spammerek számára, másrészt elvben előfordulhat, hogy egy teljesen legitim levél repül spambe. Másrészt ahogy írtam, az SPF megléte a névszerveren  nem is kötelező.  
 
Példaként ha valaki nem webes felületről, hanem kliensprogramból használja a postafiókját, viszont Indamailt vagy Freemailt használ, amivel a levelek letölthetők ugyan, viszont küldeni levelezőprogramon keresztül nem lehet, a felhasználó kénytelen lesz más szervert használni a küldéshez, például a netszolgáltatója levélküldőjét, azaz SMTP-szerverét. Könnyen belátható, hogy az előző SPF-logika alapján a levél minimum spamgyanusnak lesz nyilvánítva a fejléce alapján, ilyen szempontból kész szerencse, hogy eléggé kevesen használnak levelezőprogramot böngésző helyett a levelezéshez, viszont akik igen, ezt általában tudják is. Azt hinnénk, hogy a túl szigorú SPF beállítás, azaz amikor a szűrést végző szerver nem csak lepontozza a levél hitelességét, hanem vakon az SPF alapján jár el és el is dobja azt, nem túl gyakori beállítás. Sajnos olyan cégek is gyakran rosszul konfigurálják a szűrést küldésre és fogadásra vonatkozóan, amikről nem hinnénk.    
 
DomainKeys, DKIM és az Identified Internet Mail  
 
Ezek a megoldások elvben nem voltak jobbak vagy rosszabbak, mint az SPF, hanem teljesen mások, gyakorlatilag viszont jóval korszerűbbek, számos olyan sajátossággal rendelkeztek, amik mégis nagyban megnehezítették egy-egy email meghamisítását.  
 
Mindháromnak az alapját az jelenti, hogy a domaint működtető névszerveren be van állítva egy publikus kulcs, amit a küldő szerver aláír, majd a fogadó fél szervere lekérdezve ezt a publikus kulcsot ugyancsak a névszerverről, a feladó legitimitásának azonosításán túl azt is ellenőrzik, hogy az emailt átvitel közben esetleg nem hamisították-e meg, ami sokkal gyakoribb és egyszerűbb, mint ahogy azt az Olvasó gondolná.  
 
Ugyanakkor több szempontból sokkal nagyobb rugalmasságot biztosít, mint az SPF, hogy mást ne mondjak, elvben az SPF egy sima szöveges rekord ugyan a névszerveren, mi több, lehet el kilométeres is, gyakorlatilag a fogadó fél gyakran nem értelmezi a szabályt, ha 255 karakternél hosszabb.  
 
A Yahoo által kitalált DomainKeys és a Cisco-tól származó IIM összegyúrásából született DKIM esetén viszont ugyanazzal az email-címmel való üzenet küldéséhez használhatjuk teljesen eltérő szolgáltatók küldő szervereit is, a küldő szerver egyszerűen csak hozzácsapja a nyilvános kulccsal és persze az általa használt titkosító algoritmussal kiszámított ellenőrzőösszeget, amit a fogadó fél majd ellenőriz. Ugyan a DomainKeys-t, azaz DK-t, amit gyakran kevernek a DKIM-mel, elvben felváltotta az utóbbi, gyakorlatilag viszont nagyon sok szerver előnyben részesíti, ha a levél a régivágású módszerrel is alá van írva. Annyira, hogy a példánál maradva a Gmail máig csak akkor fogad el teljesen hitelesnek egy levelet, ha helyes DomainKeys értéket is talál benne.  
Az alábbi ábrát az appmaildev.com-ról vettem át:  
 

Hogy a saját leveleink tartalmaznak-e SPF, DK és DKIM értékeket, valamint azok helyesek-e a http://www.appmaildev.com/en/dkim/ -en ellenőrizhetjük, ahol egy email-címre küldött levelet követően a szolgáltatás egy részletes elemzést fog visszaküldeni.  
 
Hasonló, kevésbé részletes, de áttekinthetőbb eredményt ad, ha  a http://dkimvalidator.com oldalon megjelenő email címre küldünk emailt, majd néhány másodperc múlva megnézzük az eredményt.  
 
Esetleg marginálisnak tűnik foglalkozni ilyen részletekkel, egyszer mindenkinek érdemes eljátszania vele azért is, mert abban az esetben, ha valaki egy beígért emailt nem kap meg, annak senki sem örül főleg akkor nem, ha fontos emailről lett volna szó.  
Az emailek itt ismertetett hitelesítése protokoll-szinten működik, még mindig összesen csak annyit bizonyít, hogy egy-egy adott levelet a feladó postafiókjából küldtek, azt viszont nem, hogy valóban a postafiók tulajdonosa küldte, nem pedig valaki, aki odament a lezáratlan gépéhez vicceskedni ebédidőben.  
 
Alkalmazásréteg szintjén a levelek hitelesítése a korábban tárgyaltaktól teljesen függetlenül a digitális aláírással oldható meg, aminek de facto standardja a PGP, aminek az alapjairől korábban írtam itt  a finomhangolásáról pedig ebben a posztban.  
 

Igaz, nemrég ígértem, hogy bemutatom, hogyan azonosítható egy webes felületről elküldött Gmail-es levél földrajzi helye, annak ellenére, hogy a Gmail-en keresztül küldött levél nem tartalmazza a kliens IP-címét - ellentétben a Google Apps-en keresztül küldött levelekkel, amik igen! -  mindez esélytelen lenne ésszerű terjedelemben úgy, hogy közérthető is legyen - viszont kommentben tippelni lehet!  
Képek: filterforge.com, pophangover.com, themetapicture.com