bardóczi ákos @post.r

Ahány munkahely annyi szokás, viszont alighanem mindenki belefutott már abba a kérdésbe, hogy vajon mennyire jó ötlet a munkahelyi gépet magáncélra használni, mennyit tudhat róla az IT-s, a főnök, esetleg olyan is, aki jóval pletykásabb az elviselhetőnél.

Vannak munkahelyek, ahol az alkalmazott azonnal aláír egy nyilatkozatot azzal kapcsolatban, hogy a munkahelyi IT infrastruktúrát csak a munkájához szükséges célokra és módon fogja használni, ha pedig ez a policy változik, arról a munkahelynek őt is köteles értesítenie. Ez jellemzően tartalmazza azt, hogy a munkahelyi levelezés nem használható másra a rendeltetésén kívül és ezt a munkahely ellenőrizheti, mondjuk szúrópróbaszerűen és ez így helyes. Ami viszont már sokkal kacifántosabban, esetleg kevésbé érthetően van megfogalmazva, hogy a munkahely milyen mélységig láthat bele az alkalmazott netezésébe, ami a privát kommunikációját is érintheti. Főleg akkor, ha a zavarosan megfogalmazott szabályzat kiterjedhet a BYOD-eszközökre is, azaz azokra a kütyükre, amiket az alkalmazott saját maga visz be és a céges hálózatot használják.

Amivel alighanem mindenki egyetért, hogy a munkahelyére alapvetően dolgozni jár az alkalmazott, tehát mindenki joggal várhatja el, hogy ne csessze el az időt olyannal, aminek semmi köze nincs a munkájához. Ugyanakkor nagyon gyorsan kiderült az is, hogy azokon a helyeken, ahol letiltották az egyértelműen magán célra szánt, közkeletű alkalmazások használatát, mint a Twitter, a Gmail vagy a Facebook, az alkalmazottak feszélyezettebben érezték magukat, ennek megfelelően a produktivitásuk is csökkent. Röviden: az olyan típusú szolgáltatások tiltásának bevezetése, amik mindennapi kommunikációnk részévé váltak és megszoktuk, hogy elérhetőek, amikor kell, értelemszerűen csak feszültséghez vezethet. Ugyanakkor természetesen senkinek sem jó, ha az alkalmazott elcsetelgeti a munkaidő felét.

Komolyan nem tudnám megmondani, hogy melyik a legidiótább céges korlátozás, amiről olvastam vagy hallottam, de alapvetően kerülendő minden olyan módszer, ami az alkalmazottban olyan benyomást kelt, mintha a főnöke a háta mögött egész nap azt figyelné, hogy hogyan dolgozik. Természetesen kivételek vannak, kritikus feladatokat ellátó szervezeteknél nyilván megengedhetetlen lenne biztonsági szempontból, hogy onnan az alkalmazottak szabadon netezgessenek, így esetleg lefertőzzenek véletlenül egy olyan hálózatot, ami egy SCADA-rendszerhez vagy minősített adatokat tartalmazó rendszerhez kapcsolódnak valamilyen módon. Ahogy az is ismert, hogy több hadsereg nagyon helyesen megtiltotta az állománya tagjainak, hogy egyáltalán a közösségi webet használják.

Ami általánosságban elmondható, hogy az alkalmazottak alapvetően tájékozatlanok, aminek eredményeként veszélyeztetik egyrészt a céges adatok séthetetlenségét, másrészt a saját magánszférájukat is.

2010-ben hatalmas botrányt kavart a Firesheep, ami lényegében egy olyan böngésző-kiegészítő volt, ami lehetővé tette, hogy a géppel egy hálózaton lévő több gép titkosítatlan adatforgalma már-már kínos egyszerűséggel teljes egészében lehallgatható legyen. Azaz bárki, elemi informatikai előismeretekkel láthatta és jókat derülhetett rajta, hogy tőle nem messze egy kollégája miket olvas éppen a neten. Nem az az érdekes az egészben, hogy megjelent egy böngészőbővítmény, ami lehetővé tett, hogy egy mezei felhasználó úgy láthassa a másik tevékenységét, ahogyan az a zsékategóriás kémfilmekben ábrázolni szokták. Ugyanis ennek a lehetősége már ezer éve adott volt, az olyan jól ismert alkalmazások, mint mondjuk a Wireshark ugyanerre képes volt már a Firesheep előtt 10 évvel korábban is, csak éppenséggel azzal a különbséggel, hogy a Wireshark által sniffelt adatforgalom nem úgy jelent meg, mint valami kémfilmben, hanem az adatcsomagokat szépen összerakva pici hozzáértéssel simán olvasható volt a titkosítatlan forgalom, ami származhatott vezeték nélküli hálózatból és persze vezetékes hálózatból, azaz például a munkahely helyi hálózatára csatlakozva egyaránt.

Tehát igaz, hogy a probléma ismert volt már száz éve, mégis egy, végülis teljesen átlagos, mindenki számára használható böngészőbővítményre volt szükség ahhoz, hogy a világ legnagyobb szolgáltatói arra kényszerüljenek, hogy az alapértelmezett beállítás az legyen, hogy a felhasználó böngészője és a szerver közti adatforgalmat titkosítsák. Ez a gyakorlatban nem csak abból látható, hogy a böngésző címsorában a cím https-sel kezdődik, hanem az is, hogy az elején látható egy - jó esetben zöld színű, nem törött - lakat ikonja, amire rákattintva láthatjuk, hogy a kommunikáció egészen pontosan milyen titkosítás mellett történik, és egy ún. certifikátum megfelelően igazolja-e, hogy a webhely, amire kapcsolódunk, valóban az a webhely-e, aminek a címét a címsorban látjuk.

De hát ha a címsorban az áll, hogy www.bankom.tld, akkor az csak a bankom webhelye lehet, nem? Nem. Amikor a böngészőbe beírjuk a címet, a kérést az oprendszeren keresztül átadja a DNS-szervernek, ami alapértelmezés szerint mindenkinek a saját internetszolgáltatójának azon két szervere, amelyik elvégzi a névfeloldást, azaz megkeresi vagy megkeresteti a webcímhez tartozó IP-címet, ez visszakerül a böngészőhöz a kommunikáció innentől a felhasználó címe és böngészője, valamint a DNS-től megtudott www.bankom.tld oldal IP-címe közt fog folytatódni végig. /*egyszerűsítve*/

Kivéve, amikor nem!

Ugyanis lévén, hogy semmi sem garantálja azt, hogy a névfeloldásra irányuló kérésbe senki sem fog belepiszkálni a felhasználó és a szolgáltató DNS szerveri közt ún. közbeékelődéses támadással. 

Másrészt a szolgáltatók DNS szerverei ha mondjuk az elmúlt néhány órában már több milliószor feloldottak egy bizonyos címet, nem fogják ismét megkeresni azt a net dzsungelében, hanem a gyorsítótárból, "emlékezetből" veszik elő azt, a legnagyobb sérülékenységet pedig pont ez jelenti. 2008-ban éppen egy névfeloldással kapcsolatos sebezhetőség sokkolta a világot.

Tételezzük fel, hogy a támadók sikeresen beléptek a szolgáltató DNS-szerverére  és a nemrég lekért, www.bankom.tld hosztnévhez tartozó IP-címet aaa.bbb.ccc.ddd-ről átírták xxx.yyy.ppp.qqq címre, ez utóbbi pedig egy, a Karibi-térségben vagy hasonló remek klímájú országban elhelyezett szervert jelöl, amin olyan webhely fut, ami megtévesztésig hasonlít a www.bankom.tld bejelentkezőoldalára. Az ügyfél ekkor beírja a felhasználói nevét és jelszavát, amit a támadók naplóznak. A belépési adatok megadása után a felhasználó hibaüzenetet kap, miszerint rosszul adta meg a belépési adatait, majd átirányítják a valódi webhelyre, ahol már szabályosan be tud lépni, viszont nem veszi észre, hogy a bejelentkezéshez szükséges azonosítókat a támadók ellopták.

Ez ugyan egy erősen egyszerűsített példa volt a DNS működésével és annak eltéríthetőségével kapcsolatban, hiszen nincs olyan hülye bank, ami ne használna az éles felületen titkosított kommunikációt, a szerver és a kliens azonosítását, a belépés vagy egy-egy konkrét banki művelet pedig plusz egy jóváhagyást kérnek az ügyfelektől, ami mondjuk egy SMS-ben érkező számsor megadása. Viszont tartsuk észben, hogy számos levelezőrendszer van mind a mai napig, aminek a webes felülete nem alkalmaz titkosított kommunikációt, ilyen esetben ha a DNS-t célzottan eltérítik, olyan, mintha a felhasználó teljes egészében odaadta volna a postafiókja használati jogát a támadónak.

A DNS eltérítés gyakoribb, egyszerűbb, na meg sokkal kevésbé feltűnő módja, ha nem a szolgáltató DNS kiszolgálóját piszkálják meg, hanem a felhasználó gépét kihasználva azt, hogy a kliens szintén gyorsítótárazza a korábban feloldott neveket. Ha például valaki folyamatosan a Gmail-en lóg, nem fogja a böngésző minden alkalommal arra utasítani az operációs rendszert, hogy kérdeztesse le a Gmail.com-hoz tartozó IP-címet, amikor megszólítja az oldalt, hanem azt a lekéréseket cachelő helyről vagy egy,  állandó hosztnév-IP-párosokat tartalmazó, de megmókolt fájlból húzza elő, ez a másik módja a DNS hijackingnek.

Miután tisztáztam, hogy a névfeloldás jelentősége mekkora, nem csoda, hogy gyakorlatilag minden kicsit is normális operációs rendszer és személyi tűzfal úgy kezeli a hosztnév-IP-cím párosokat tartalmazó fájlba való beavatkozási kísérleteket, mintha a támadó páncéltörvővel próbálna bejönni az ajtón. Könnyebb megérteni, ha belenézünk ezekbe a fájlokba.

OSX esetén a fájlt /private/etc/hosts helyen találjuk, a legtöbb linux disztróban az /etc/hosts alatt, ha csak kimondottan át nem helyezték, míg Windows esetén a rendszergyökér\Windows\System32\drivers\etc\hosts.txt fájlban. Ez ugyan csak az állandó hozzárendeléseket tartalmazza, így nem valami izgalmas, viszont kis trükkel előcsalható, hogy az operációs rendszer az adott pillanatban miket gyorsítótárazott, itt jelen esetben biztosan meg fogjuk találni mondjuk azt, hogy a reblog.hu-hoz  a 84.2.32.100 vagy 84.2.32.101 cím, esetleg egy ún. kanonikus név tartozik. Nosza! A lista megjelenítéséhez viszont ismét lehet, hogy adminisztrátori jogosultságokra lesz szükség. A Windowsban egyszerűen el kell indítani egy parancssort adminisztrátori jogosultságokkal, majd ott kiadni az

 ipconfig /displaydns | more

parancsot, majd lehet is böngészni benne.  

Nem kell pánikba esni, ha a vártnál sokkal több hosztnevet látunk, hiszen nem csak a webes böngészéshez kapcsolódó címek láthatók it. Ha gyakran frissít a víruskeresőnk, fut közben a Skype, meg még  ki tudja mi, minden alkalmazás és szolgáltatás, ami használja a hálózatot kapcsolódik pár jóhelyre. Tovább bonyolít a helyzeten, hogy a terheléselosztás miatt egy hosztnévhez tartozhat több IP-cím is, egy IP-címhez több hosztnév, de még egy adott webhely is a tartalmainak egy részét teljesen más hosztnévről cibálja be, így például a Facebookra töltött képek esetén a scontent.xx.fbcdn.net helyről, aminek további IP-címei vannak.

Az olvasó esetleg korábban is tudott róla, hogy mi is a névfeloldás, mostanra világosabb lehet, hogy hogyan is működik, ebből adódóan mekkora kockázata annak, ha ebbe valamilyen módon beleberhelnek, a harceddzettebb bitbúvároktól elnézését kérek az egyszerűsítésekért.

A DNS-eltérítés kockázatát persze már az internet hajnalán felismerték, ezért ki kellett találni egy olyan megoldást, ami azonnal beavatkozik vagy jelez, ha erre utaló jelet talál. És persze egy pillanatig se felejtsük el, hogy ennek a megoldásnak teljesen függetlennek kellett lennie az átvivő közegtől, ideértve a csatorna köztes szakaszait is. Azaz függetlennek kell lennie attól, hogy a netező LAN-kábelen keresztül csatlakozik, titkosítatlan wifin keresztül, az adatcsomagok egy ideig telefonkábelen keresztül haladnak át, mire célbaérnek keresztülmennek 8-10 szerveren, útválasztón, amikről azt sem tudni, hogy kié és így tovább. Azaz feltétel volt a tervezésnél, hogy legyen független a megoldás a fizikai, adatkapcsolati, stb. rétegektől, így került a megoldást jelentő SSL és a vele gyakorlatilag azonos TLS [Transport Layer Security] és ami kapcsolódik hozzá, megjelenítési rétegbe.

Hogy szemléletes legyek, tételezzük fel, hogy egy papírcetlin szeretnék üzenni valamit a kollégámnak és olyan valakit bíznék meg azzal, hogy a papírcetlit vigye el neki, akiről tudom, hogy biztos, hogy úgyis elolvassa, másrészt még pletykás is, a papírcetlire az üzenetet mondjuk arab avagy japán nyelven írom, amit a címzett megért ugyan, de aki átadja neki a cetlit, nem. Ez esetben az, akit megkérek a levél továbbítására, a fizikai vagy adatkapcsolati rétegnek feleltethető meg, míg ami a cetlire kerül az átvivő számára értelmezhetetlen nyelven, megfeleltethető az alkalmazási vagy megjelenítési rétegnek.

Az SSL/TLS titkosítási és azonosítási feladatokat is ellát. Amikor arról van szó, hogy mennyire okos dolog mondjuk reptéri nyílt wifit használni netbankoláshoz vagy levelezéshez, alapvetően azért hülye a kérdés, mert ha SSL titkosítás mellett működik az adott webhely a böngészőbe, hiába hallgatja le a wifit valaki, az a kommunikáció, ami a laptop és a banki szerver vagy levelezőszerver közt bonyolódik, értelmezhetetlen adatmasszaként fog csak megjelenni, hiszen titkosított. [SSL/TLS-t viszont nem csak a böngésző használ! Lazán kapcsolódik, de ilyenkor ésszerűen azt kellene figyelembe venni, hogy a laptopon futhatnak olyan szolgáltatások, amik viszont sehogy sem titkosítanak. Okostelefonok pedig gyakorlatilag általános, hogy az appok erőforrásigényének csökkentése miatt számos alkalmazás egyáltalán nem használ titkosítást vagy csak nagyon gyengét, ami igencsak rizikós annak tudatában, hogy az okosmobilok többsége, hacsak nincs készenléti állapotban, automatikusan csatlakozik a nyílt hálózatokhoz, ha olyat lát, a mobil gyengén vagy sehogy sem titkosító szolgáltatásai és alkalmazásai pedig kapásból küldik is az adatokat a szervereik felé.] Akit a titkosítás pontos módja érdekel, itt olvashat róla. 

A titkosítással a gyakorlatban együtt jár, hogy egy, a kommunikációtól független, harmadik  fél előzetesen tanusítványt állított ki a szerver számára, ami igazolja, hogy ő tényleg az, akinek mutatja magát a kliens felé, akárcsak a szerver személyi igazolványa lenne. A böngészőprogramok pedig szintén tudják, hogy milyen típusú tanusítványokat fogadnak el és ha olyan tanusítvánnyal találkoznak, amivel valami nem stimmel, azonnal jelzik a felhasználó felé.

Visszautalva arra, amit a cikk elején írtam, ha a szolgáltató oldalán a DNS-szerver a névfeloldásokat hibásan végzi, a gyorsítótárában hamis hosztnév-IP-cím összerendelések vannak, ennek megfelelően téves adatot ad át a kliensnek, előfordulhat, hogy a http://bardoczi.net címen valamilyen kábszicsempész-gyilokpornós-fegyverkereskedős cég oldala jelenik meg. Ugyanez történik akkor is, ha a felhasználók  gépén az emlegetett hosts fájlokban valótlan párosítások vannak megadva, lényeg, hogy a felhasználó fejében meg sem fordul, hogy alighanem nem azt az oldalt látja, amit keresett.

Abban az esetben viszont, ha valaki a httpS://bardoczi.net címet látogatja meg, számos forgatókönyv elképzelhető, ha a DNS-kérés hamis. A jólnevelt böngésző azonnal jelez, hogy a domainnévhez tartozó certifikátumot a Comodo olyan módon állította ki, hogy a bardoczi.net hosztnévhez a 70.39.146.219 IP-cím tartozik, viszont a tartalom ennek ellenére mégsem erről a címről csorogna be, hanem teljesen máshonnan – teljesen más tartalommal. A felhasználónak lehetősége van arra kattintani, hogy vállalja a kockázatot és mégis betölti az oldalt, de csak annál a látogatásnál, minden újabb látogatásnál a böngésző erre újra rá fog kérdezni. Ami viszont tragikus, hogy a böngészők a mai napig lehetővé teszik, hogy egy-egy oldal "hamis személyivel" felkerüljön a kivételek közé, azaz a felhasználó minden látogatásakor a problémás certit elfogadja a böngésző, ami nem csak annyit jelent, hogy a felhasználó esetleg nem is azt az oldalt látja, amelyiket szeretné, hanem man-in-the-middle támadással más az egész adatforgalmat lehallgathatja. A certi részletei egyébként minden böngészőben lekérdezhetőek a címsor elején lévő lakatra kattintva.

Nos, képzeljük el, hogy valaki egyszer elfogadott egy hamis tanusítványt - vagy valaki, akivel közösen használják a böngészőt – ezen kívül a hosts fájl is meg van buherálva. Így előfordulhat, hogy hónapokon keresztül úgy használja mondjuk a gmail.com-ot, hogy azt valaki, akinek a szerverén keresztül megy az adat, aki a már említett közbeékelődéses támadással a felhasználó és a gmail.com közt áll, minden nehézség nélkül lehallgatja felhasználónévvel, jelszóval, a küldött levelek tartalmával, mindennel együtt! Az azonosításon kívül a titkosítás arra is kiterjed, hogy az adatfolyamot bizonyos méretű adatblokkonként ellenőrzi, hogy megfelelően titkosított-e, ha nem, figyelmeztet vagy eldobja a kapcsolatot menet közben.

Ha a böngésző tanusítványhibát jelez, annak ugyan lehet számos más oka is, de mindig mérlegeljünk előtte, hogy megéri-e a kockázatot, ha továbbmegyünk.  

Egyre több szervezet alkalmaz ún. UTM, azaz unified threat management megoldásokat aminek a lényege, hogy a biztonságot veszélyeztető szolgáltatásokat nem külön-külön küszöbölik ki. Azaz nem külön egy tűzfalas megoldás figyeli a hálózati forgalmat, egy antivírus megoldás kergeti a vírusokat, ezen kívül megint másik arra ügyel, hogy az alkalmazottak véletlenül ne küldözgessenek kifelé olyan információkat, amiket nem szabadna, hanem ezeket egy szolgáltatás suite-ba csomagolják. Itt ismét néhány egyszerűsítéssel fogok élni. Képzeljük el, hogy az elérendő célja az IT staffnak, hogy az alkalmazottak ne használjanak Yahoo Mail-t céges adatok átküldésére, de nem akarjuk elzárni őket a privát levelezésüktől sem. Azaz ezt valahogy ellenőrizni kell. Ekkor nincs mese, annak ellenére, hogy a Yahoo levelezője titkosított forgalmat bonyolít a szerver és az ügyfél közt, valamilyen módon meg kell figyelmi a forgalmat tartalmi szempontból olyan nyomok vagy mintázatok után kutatva, amik arra utalnak, hogy valaki nem túl bölcs módon mondjuk üzleti szempontból kritikus információkat küldözget, amiről tipikusan nem is tudja, hogy mennyire kritikus, csak azt, hogy a kollégának kényelmesebb átküldeni Yahoo-n, ha már úgyis oda van belépve. Megint más esetben ha már Facebookozik az alkalmazott, a forgalom titkosított ugyan, mégis ellenőrizni kell, hogy véletlenül se kattintson olyan linkre, amivel lefertőzi a céges gépet.

Van-e megoldás arra, hogy az alkalmazott magánszéfrája ne sérüljön, ugyanakkor mégis maradjon házon belül az az infó, amit házon belül szeretne tartani mondjuk egy vadászrepülőket tervező cég? A rövid válasz, ahogyan sejthető: nincs.

Ha valaki bele akarna fülelni a titkosított forgalomba, a böngésző azonnal jelezne, aminek annyira nem örülne a felhasználó. Mit lehet kezdeni azzal az adatfolyammal, ami titkosított? Nincs mese, fel kell oldani valahogy a titkosítást, dekódolni kell, megszaglászni, hogy nincs-e benne valamilyen kényes adat, majd titkosítani, de már a céges szerverrel és úgy továbbítani a  külső szerver felé. Ha a külső szerver persze észleli, hogy valaki belepiszkált az adatfolyamba, ennek megfelelően lehet, hogy egy olyan ködös hibaüzenetet dob, hogy nem felel meg a kapcsolat az elvárt biztonsági standardoknak, ezért vége a mókának. A webes szolgáltatások viszont nagyon sok esetben sokkal megengedőbbek, ha SSL-ről és certikről van szó, mivel tisztában vannak vele az üzemeltetők, hogy lehetnek olyan felhasználók is, akik annyira régi böngészőt használnak, amelyik az alkalmazott titkosítási módszert még nem támogatja megfelelően vagy olyan államból használnák a szolgáltatást, ahol a webes szolgáltató és az adott állam megállapodást kötött azzal kapcsolatban, hogy a felhasználóikat lehallgathatják. Kínában például így. 

Felmerül a kérdés, hogy mégis hogyan oldják meg a titkosított kapcsolat elemzését alkalmazó cégek azt elegánsan, hogy a felhasználók ne kapjanak figyelmeztetést, maximum törött lakat látszódjon a címsorban, ami azt jelzi, hogy titkosított a kapcsolat ugyan, csak a másik fél, azaz a szerver valódisága nem garantált? Úgy, hogy a céges gépre az előtelepített böngészőbe a célnak megfelelően megmókolt tanusítványok kerülnek, mivel tudható, hogy a magán kapcsolattartásra leggyakrabban használt webhelyek melyek és milyen certit használnak, amihez a cég hozzábiggyeszti a sajátját. Ezen kívül a cég saját DNS-szervereket használ, ami a szükséges oldalakat eltéríti.

Azért valami feltűnőbb nyoma csak van annak, ha gyakorlatilag hakkolva van az a technológia, amit arra fejlesztettek ki, hogy a kliens és a szerver tökéletesen bízhasson egymásban, nem? Igen, viszont olyan helyen, amit a felhasználó tipikusan soha az életbe nem néz meg. Ahogy már írtam, a címsor elején lévő lakatra kattintva, majd azon belül a tanusítvány részleteit kiválasztva jeleníthetők meg a szerver hitelesítésével kapcsolatos részletek. Ez például a LinkedIN esetén a Digicert által LinkedIN-nek kiállított tanusítvány, a Gmail esetén egy Geotrust/Google CA által Gmail-nek kiállított tanusítvány és így tovább. Abban az esetben, ha ettől eltérő tanusítványinformációkat látunk, akkor vagy a cég mókolt valamit, ahogy természetesen az sem zárható ki, hogy a céget egy kifinomult támadás érte, a támadó helyezett el  hamis certiket a böngészőben az alkalmazottak lehallgatására.