MEGJEGYZÉS: cikkünk vendégszerzője Pfeiffer Szilárd, a Balasys szakértője. A cikkben foglaltak nem feltétlenül tükrözik a HWSW szerkesztőségének álláspontját.

A Proofpoint tanulmánya szerint 2021-ben a szervezetek 78%-át érte olyan támadás, ahol a rosszindulatú programokat elektronikus levélben próbálták terjeszteni. A közelmúltban Magyarországon és külföldön is történt nem egy, nagy nyilvánosságot kapott biztonsági incidens, ami a levelezés feltörésével, vagy hiányosságainak kihasználásával indult. A levelezés azért vált ilyen népszerű célponttá, mert szinte kivétel nélkül megszegi a jelenleg legelterjedtebb IT-biztonsági koncepció, a Zero Trust biztonsági modell minden alapelvét.

Ugyan számos módszer létezik a biztonsági szint növelésére, ezek nem kötelezőek, maguktól pedig alig alkalmazzák ezeket az érintett szervezetek – legalábbis közel sem olyan széles körben, mint az szükséges lenne.

Az elektronikus levelezés negyvenéves története során nem csak, hogy a legelterjedtebb, de egyúttal a leginkább túlhasznált kommunikációs módszerré nőtte ki magát. Sőt, a mai napig számos üzleti folyamat fundamentumát képezi, túlmutatva ezzel az elektronikus levelezés eredeti céljain és biztonsági képességein. Az elektronikus levelek továbbítására az egyik legrégebbi, és egyúttal az egyik legkevésbé biztonságos kommunikációs protokollt (SMTP) alkalmazzuk, amitől az az internet egyik legérzékenyebb és leginkább sebezhető területévé válik. Az adathalászat (phishing), a feladó címének hamisítása (spoofing) és más csalási technikák megléte bizonyítja, hogy a levelezés egy amúgy Zero Trust elveken nyugvó hálózat messze leggyengébb pontja, ami lehetőséget kínál a támadóknak kártékony programok a vállalati belső hálózatba való bejuttatására. De miért van ez így?

Az e-mail a Zero Trust ellenpélda

A Zero Trust alapelveinek megfelelően mindent erőforrásnak kell tekinteni, és azokat egyenlően is kell kezelni. Gondoskodni kell a biztonságos kommunikációról, a hozzáférések hitelesítéséről, és alkalmazni kell a legkisebb jogosultság elvét a hozzáférések során. Általánosságban elmondható, hogy megbízható hitelesítés és titkosítás nélkül senki sem adna hozzáférést egy vállalati erőforráshoz egy internetről származó kérés számára. Különösen igaz ez akkor, ha valaki fájlokat juttathat be a hálózatba ezen az erőforráson keresztül, különösen, ha ezeket a fájlokat a felhasználók később futtathatják. Alapesetben az elektronikus levelezés sajnos pont így működik.

Az eredeti levéltovábbítási protokollt kiterjesztő modern technikák nélkül bárki küldhet, magát másnak kiadva, olyan leveleket, amik ártó szándékú mellékleteket, adathalász üzeneteket, vagy ezek terjesztésére szolgáló weboldalakra mutató hivatkozásokat tartalmaznak.

Elengedhetetlen tehát, hogy a levelek kézbesítése során kövessük a Zero Trust jelmondatát; Never trust, always verify. Kérdés, miben nem kellene bíznunk, mit kell ellenőriznünk egy e-mail kapcsán?

Első lépés: a szerver hitelesítése

Kifejezetten fontos lenne, hogy a fogadó levelezőszerver valamilyen módon hitelesítse a küldő szervert, például annak hálózati címe alapján. Minden tartománynév (domain) tulajdonosának módjában áll közölni egy Sender Policy Framework (SPF) néven ismert szabályzatot, ami deklarálja, hogy mely szerverek jogosultak leveleket küldeni az adott tartomány (pl.: hwsw.hu) nevében.

A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.

A címzett oldal a közzétett házirendek segítségével ellenőrizheti, hogy a bejövő levelek jogosult küldőnek számítanak-e. A Balasys IT Zrt. kutatása szerint az egymillió leglátogatottabb weboldal tartományai közül nagyjából 78% tesz közzé ilyesfajta szabályzatot. Ez kiemelkedően magas arány, azonban nem szabad megfeledkezni két kapcsolódó tényezőről.

Az első kiemelendő tényező, hogy a házirend részeként a tartomány tulajdonosok deklarálhatják, mi történjen, ha nincs olyan explicit szabály, ami a feladó IP-címére vonatkozna. A tartományok tulajdonosainak kevesebb mint 35%-a tesz közzé olyan szabályzatot, ami ez esetben arra kérné a fogadó felet, hogy tekintse jogosulatlannak a feladót.

Mint oly gyakran, az üzletmenet folytonossága ez esetben is a biztonsági szempontok elé kerül, annak ellenére, hogy a házirend karbantartási költsége minimális, hiszen a levelezőszerverek címei ritkán változnak.

A Zero Trust biztonsági modell szerint mindent erőforrásnak kell tekinteni, tehát azokat a levelező szervereket is, amik a tartományunk nevében leveleket küldhetnek, még ha azokat külső szolgáltatásként is vesszük igénybe (pl. Mailchimp és mások). A Zero Trust megköveteli a legkisebb jogosultság elvének alkalmazását, ami itt azt jelenti, hogy a lehető legkevesebb kiszolgáló számára engedélyezendő a levelek küldése, alapértelmezésben pedig minden mást jogosulatlannak kell tekinteni, ahogy ez egyébként a biztonsági rendszereknél megszokott (default deny).

A második tényező az, hogy bármit is mond ki a házirend, azt csak a fogadó szerver tudja érvényesíteni. Ha a fogadó szerver nem támogatja a házirend érvényesítését, akkor a házirend deklarálása a gyakorlatban semmit sem ér. A nagy e-mail szolgáltatók (pl.: Google) arra ösztönzik a tartományok tulajdonosait, hogy használják ezt a mechanizmust, vagyis publikálják házirendjeiket arra vonatkozólag, kik jogosultak a tartomány nevében levelet küldeni. Ennek hiányában, vagy hibás szabályzat közzététele esetén, különösen akkor, ha a tartomány nem különösebben nagy forgalmú (pl.: KKV-k), az e-mailek nagyon gyorsan a spam mappába kerülhetnek.

Második lépés: titkosítás

A Zero Trust ösztönzi mind a bejövő, mind a kimenő forgalom titkosítását a lehallgatás és a tartalommanipuláció megelőzése érdekében. A levelek továbbítására vonatkozó szabvány azonban kimondja, hogy a nyilvánosan hivatkozott levelezőszerverek nem kényszeríthetnek ki titkosított kommunikációt. A szabvány ezen megközelítése 20 évvel ezelőttről származik, és azt a célt szolgálta, hogy a lehető legnagyobb fokú interoparabilitást biztosítsa az internetes levelezési infrastruktúra elemei között. A levélkézbesítés során használt protokoll azóta is csak opcionális elemként tartalmazza a titkosítást (opportunistic TLS).

A levélkézbesítés tehát potenciálisan ki van téve egy közbeékelődő támadónak, aki képes a titkosítatlan kommunikáció kikényszerítésére, függetlenül attól, hogy a kommunikációban részt vevő mindkét fél titkosítani szándékozik.

A titkosítás alkalmazása nélkül a címzett nem tudja érdemben hitelesíteni a feladót, és fordítva; a feladó sem a címzettet. Ezen túlmenően, titkosítás hiányában a levéltovábbítás nyitott a passzív lehallgatásos támadásokkal, illetve aktív esetben a levelekben közölni kívánt tartalom módosításával szemben is, ami azt jelenti, hogy egy ilyen támadó akár kártevő programokat is beékelhet egy levélbe.

Ennek a kihívást jelentő helyzetnek a kezelésére a tartomány tulajdonosa közzéteheti, egy a levelezéstől független csatornán, hogy a levelezőszerver támogat titkosítást. Az SMTP MTA Strict Transport Security (MTA-STS) mechanizmus a tartománynévrendszert (DNS) használja ezen információk terjesztésére. Sajnos az egymillió legnépszerűbb tartománynak csupán a 0,1%-a él azzal a lehetőséggel, hogy biztosítsa a küldő felet arról, hogy ő támogat titkosítást.

Az ezer legnépszerűbb tartomány közül azok, akik egyáltalán alkalmazzák a módszert, közel 50%-ban még csak a tesztelési fázisnál járnak. Ezek a statisztikák bizonyítják, hogy a domain tulajdonosok figyelmen kívül hagyják a Zero Trust egyik alapelvét, miszerint amikor csak lehetséges, alkalmazzunk titkosítást.

Harmadik lépés: a levél ellenőrzése

A szerver címének a fent említett módszerrel történő ellenőrzése nem tekinthető kielégítő hitelesítési módszernek, továbbá nem garantálja sem az elküldött levél bizalmasságát, sem a sértetlenségét. A titkosítás azonban egyaránt biztosíthatja a bizalmasságot, a sértetlenséget és a hitelességet. A fent említett kihívások szükségessé teszik, hogy legalább a sértetlenség és a hitelesség garantált legyen, hogy el tudjuk kerülni egy aktív közbeékelődésre képes támadó által végrehajtott esetleges tartalommódosítást.

A Zero Trust hitelesítésre vonatkozó követelménye teljesíthető lenne a levelet feladó szerver digitális aláírásának ellenőrzésével. Ez megoldható lenne azáltal, hogy minden tartománytulajdonos közzétesz egy vagy több nyilvános kulcsot, amelyek privát párját a jogosult szerverek az elküldött levek digitális aláírására használhatnak, majd a fogadó szerverek a levelek digitális aláírását a publikus kulcsok segítségével ellenőrzik. Ez egy már létező mechanizmus, mely DomainKeys Identified Mail (DKIM) néven ismert. Mivel egyes esetekben egynél több szerver is részt vesz egy e-mail kézbesítésében, ez a mechanizmus alapvető fontosságú ahhoz, hogy a hitelességet és sértetlenséget biztosítani lehessen a kézbesítési folyamat egésze során. Ezen túl, a levelezőkliens értesítheti a felhasználót, ha az ellenőrzés sikertelenül zárult, felhívhatja figyelmét az óvatosságra még akkor is, ha a levelet egyébként nem azonosították spamként.

Bár ez a mechanizmus nem tudja garantálni a bizalmasságot, mégis jelentős hozzáadott értékkel bír. A felhasználó biztos lehet benne, hogy a támadó nem tudja kiadni magát a feladónak, és nem módosíthatja az e-mail tartalmát a kézbesítés során. Ezzel számos e-mailes csalási technika megakadályozható, például az, hogy a támadó dezinformálja az áldozatot. A vezérigazgatói vagy CEO csalás erre kézenfekvő példa. A támadó a szervezet vezetőjének adja ki magát, hogy az áldozatot – cégének pénzügyi osztályát – rávegye arra, hogy tetemes pénzösszeget utaljon át a bankszámlájára, esetleg futtasson egy kártékony e-mail mellékletet. Jelentősége ellenére ennek a mechanizmusnak is sajnos meglehetősen alacsony az elterjedtsége.

Negyedik lépés: a rendszer monitorozása

A fent említett módszerek megelőzhetik vagy enyhíthetik a biztonsági incidenseket, de támogatást igényelnek a címzett (SPF, DKIM) vagy a feladó (MTA-STS) oldaláról. Ha van támogatás ezekhez a módszerekhez, akkor felmerül a kérdés: mit tegyen a szerver, ha ellenőrzi a feladó címét, a levél digitális aláírását vagy a szerver titkosítási képességét, és problémákat tapasztal?

A Zero Trust megköveteli a hálózat folyamatos figyelését (continuous monitoring), hogy megakadályozza a gyanús viselkedést, illetve, hogy legalább riasztást lehessen küldeni azokról. Ez még fontosabb a fent említett módszerek esetében, amikor nem mi magunk, hanem egy másik fél tapasztalja a problémákat, visszaéléseket a mi rendszerünk kapcsán, így ő az, aki minket ezekről értesíthet. Ennek okán célszerű lenne egy olyan mechanizmus, ami automatizáltan képes a hitelességi és egyéb ellenőrzések során felmerülő problémák jelentésére. Ez a mechanizmus a Domain-based Message Authentication, Reporting, and Conformance (DMARC), amely lehetővé teszi a tartománytulajdonos számára, hogy közzétegye, mit és hogyan kell tennie a fogadó félnek problémák esetén.

Egyértelműnek tűnik, hogy az SPF-et használó tartománytulajdonosok a DMARC-ot is használjanak annak deklarálására, hogy a címzettnek hogyan kell eljárnia, ha a küldő házirendjének ellenőrzése sikertelen. Ez a feltételezés azonban számos esetben nem áll meg, még az ezer legnépszerűbb tartomány esetében sem. Ezen tartományok szinte mindegyike közzétesz egy feladóra vonatkozó irányelvet, megközelítőleg 74%-uk pedig DMARC-ot is. A legnépszerűbbb 1 millió domain esetében körülbelül 78% publikál SPF-et, de csak 22% DMARC-ot. A legtöbb tartománytulajdonos ugyan deklarálja, hogy hogyan kell kezelni a házirend ellenőrzése során tapasztalt hibákat, de csak egy kis részük az, akik megpróbálnak ezen hibákról értesülni is, azáltal, hogy publikálnak olyan e-mail címet, vagy API-végpontot, ahová ezek a riasztások érkezhetnének.

Ötödik lépés: a szabályzatok érvényesítése

Az említett módszerek alkalmazásának alacsony elterjedtsége kiválóan mutatja, hogy az üzlet mennyire függ az e-mail rendszertől, és mennyivel fontosabb az üzletmenet folytonossága, mint a biztonság.

Az ezer legnépszerűbb tartomány kivételével a tulajdonosoknak csupán a töredéke elég bátor ahhoz, hogy arra kérje a fogadó felet, hogy helyezze karanténba, vagy utasítsa vissza a szabályzatokat megsértő leveleket.

A többség a fogadó oldalra bízza a helyzet kezelését, vagyis nem fogalmaz meg elvárást, hogy a fogadó oldal mit tegyen, ami felveti a kérdést, hogy mi értelme is van a DMARC használatának egy ilyen esetben. Hasonlóan megengedő beállításokkal találkozhatunk az SPF esetében is. A legnépszerűbb 1 millió domainben közzétett SPF-ek alig 35%-a nyilatkozik úgy, hogy az irányelvsértést tételesen hibaként kell kezelni, vagyis a kapott e-mailt minimum spam mappába kell helyezni. További 55%-uk azt kéri a fogadó féltől, hogy a kiszolgáló kellő körültekintéssel kezelje ezeket az e-maileket: továbbítsa például őket egy spam mappába, vagy legalább jelölje meg gyanúsként. A helyzet az MTA-STS esetében a legkiábrándítóbb, függetlenül attól, hogy csak ez a mechanizmus tudja garantálni a végponttól végpontig nem titkosított e-mailek bizalmasságát. Az egymillió legnépszerűbb domainnek mindössze 1%-a használja, ráadásul ezeknek a fele is még csak tesztelési fázisban.

A levelezőrendszer, ami megfelhet a Zero Trust alapvelveknek?

A Zero Trust szerint ehhez a következő lépéseket kell megtenni:

1. Hitelesíts minden erőforrás-hozzáférést. Az első lépés az SPF megkövetelése, illetve a küldő szerver IP-címének ellenőrzése még a levelezőrendszeredhez való hozzáfélés megadása előtt. A második lépés pedig a levél hitelességének ellenőrzése DKIM segítségével.
2. Amikor csak lehetséges, használj titkosított kommunikációt. Különösen igaz ez az interneten, ezért az MTA-STS-t közzé kell tenni, és abban kötelezőként kell a titkosítást megjelölni.
3. A legkisebb jogosultság elvével engedélyezd a hozzáférést. Ez azt jelenti, hogy az e-mailek sértetlensége szükséges ahhoz, hogy elkerüld a DKIM kihasználásával injektált kártékony programokat. 
4. A rendszer és az irányelvek megsértését kövesd nyomon a DMARC és a TLS-RPT által készített jelentésekkel. 
5. Az említett mechanizmusokat folyamatosan és szigorúan munkamenet-alapú módon használd.

Addig, amíg a nem biztonságosnak tervezett régi levelezőrendszerekkel kell élnünk, fontos, hogy a fent említett mechanizmusok közül minél többet használjunk és érvényesítsünk. Azokat a tartományokat, amelyek nem tesznek közzé házirendeket (mint az SPF, a DMARC vagy az MTA-STS), valamint a szervereket, amelyek nem teljesítik azokat, bizalmatlansággal és gyanakvással kell kezelnünk. Ezek elengedhetetlenek ahhoz, hogy a támadók addig se használhassák ki a levéltovábbítás biztonsági gyengeségeit egy betörés kiindulópontjaként, amig a rendszer a gyakorlatban is Zero Trust kompatibilissé nem válik.

Ha érdekel a levelezés biztonsága, gyere el a Balasys ingyenes online meetupjára, ahol meghívott szakértőinkkel ezt a témát fogjuk kivesézni november 24-én, csütörtökön, 18 órától.