bardóczi ákos @post.r

A Silent Signal kutatói hétfőn egy blogposztban számoltak be róla, hogy a világ egyik vezető biztonsági csomagja, a Panda Adaptive Defense 360 olyan hibát tartalmaz, amit kihasználva az antivírus motor simán megengedi rosszindulatú kód lefutását, ha az azt tartalmazó fájlt tévesen fehérlistára tette a víruskergető. A Silent Signal nem először mutat rá éppen olyan termékek hibáira, amik éppen informatikai rendszerek biztonságát kellene, hogy fokozzák.

Haladó felhasználók most ne olvassanak tovább, szájbarágó poszt következik, több helyen egyszerűsítésekkel.

Hogy mennyi kártékony kód létezik a világon, csak nagyságrendileg sejthető, egy eléggé megbízható forrás szerint az azonosított vírusok száma 2016-ban 600 millió körül járt és közel négyszázezer új rosszindulatú kód jelenik meg naponta, ugyan ezeknek egy jókora része korábbi vírusok polimorfjai.

A vírusirtók gyártói már régen olyan megoldásokat építettek a termékeikbe, amik nem csak ismert vírusok után keresnek, hanem például az éppen futtatott alkalmazások és szolgáltatások viselkedéséből következtetnek rá, hogy a gép vírusfertőzés áldozata lett. Emellett gyakori egy másik, igencsak megbízhatónak látszó megoldás az ún. fehérlisták összeállítása, azaz amikor a security suite telepítését követően a védelmi szoftverek megjegyzik, hogy mely fájlok futtathatóak anélkül, hogy különösen szaglászni kellene őket, hiszen így az egész kevésbé lassítja a gépet, akár egy végponti gépről, akár egy szerveroldali megoldásról van szó. Ilyenek például a Windows megszokott szolgáltatásai, gyakran használt alkalmazások, a fehérlista pedig később bővíthető egy-egy új alkalmazás telepítése után, jó esetben úgy, hogy a víruskergető azért előtte ehhez a felhasználó szives beleegyezését kéri.

Abban az esetben, ha az AV termék a fájlokat például önmagában a nevük alapján jegyezné meg és tenné fehérlistára, szinte értelmetlen lenne, hiszen a vírusok ezt kihasználva egyszerűen felülírnának egy legitim, fehérlistán lévő fájlt egy olyannal, ami rosszindulatú kódot tartalmaz, majd a fertőzött fájl legitimként futna le. Ezért a biztonsági termékek inkább elkészítik a fájl teljes ún. hash-lenyomatát és mindig ezt használja a fájl azonosítására. A hash-érték pedig függetlenül attól, hogy miből generálódott, állandó, de kis hosszúságú, például 128 bit.

Egyszerűsítve, ha az elindított alkalmazáshoz vagy szolgáltatáshoz tartozó fájl apró hash-értéke egyezik azzal, amit a víruskergető korábban tárolt, akkor futtatható, ami nyilván sokkal gyorsabb, mintha a teljes, akár több megabájtos fájlt tárolni kellene, majd az elejétől a végéig mindig megnézni, hogy egyezik-e a korábban tárolttal.

Ideális esetben természetesen egy adott tartalomhoz, jelen esetben egy fájl tartalmához csak egy hash-érték tartozhat illetve olyan hash-algoritmust használ egy jólnevelt szoftverrendszer, amit nem lehet csak úgy becsapni, hiszen ekkor a vírusok akár fehérlistás alkalmazásoknak is álcázhatnák magukat.

Viszont nyilván vannak erős, ugyanakkor rosszul leprogramozott vagy egyszerűen becsapható hash-algoritmusok, mint amilyen a Panda terméke által használt, eltéríthető MD5 algó.

A leginkább para pedig az az egészben, hogy egy olyan termékben, amelyik biztonsági csomagként azért lenne felelős, hogy biztosan azonosítsa a biztonságos és esetlegesen kártékony folyamatokat, ez simán eltéríthető, ahogy azt a Silent Signal egy videón keresztül be is mutatja.

Adja magát a kérdés, hogy akkor mégis miért használnak még biztonsági termékekben is MD5 algót valamilyen más helyett? Több lehetséges tippem is van, az egyik legerősebb érv talán a fejlesztői lustaság és megszokás, ami jelen van függetlenül attól, hogy biztonsági csomagot vagy valamilyen faék egyszerűségű appot kell fejleszteni.

Kép: blog.varonis.com

Nem csak az az érdekes, hogy az információ koncentrálódásának és áramlásának felgyorsulásával és növekedésével hogyan vált az informatikai biztonság egyre érdekesebb kérdéssé a kutatók számára, hanem az is, hogy ennek hogyan lett hasonlóan exponenciális mértékben növekvő hatása az életünkre.

Gondoltad volna, hogy abban az esetben, ha frissíted a webkamerádat működtető illesztőprogramot, esetleg pont azzal teszed lehetővé, hogy távolról szinte bárki által megfigyelhetővé váljon a kamera által aktuálisan mutatott kép? Vagy éppen a firmware távolról módosítható úgy, hogy ezt tegye.

És azt, hogy a világ egyik legnagyobb mobilos, helymeghatározáson alapuló csajozós-pasizós alkalmazása a Tinder olyan sebezhetőséget tartalmazott, amin keresztül az összes fotót le lehetett volna tölteni a Tinder szervereiről bármiféle bejelentkezés nélkül, olyan adatokat kért le a Facebook-fiókodból, amire nyilvánvalóan semmi szüksége nem volt vagy éppenséggel módosítani kellett a másik távolságát mutató funkciót, mert olyan pontossággal mutatta a felhasználók pozícióját, hogy az potenciálisan veszélyes volt rájuk nézve?

Azt hinnénk, hogy az olyan titkosítási módszerek a leghatékonyabbak, amiket abszolút az alapoktól, a nulláról fejlesztettek ki valamilyen meglévő felszteroidozása helyett, hiszen így kívülállónak nem lehetett lehetősége rá, hogy kiismerje a kriptográfiai megoldás gyengeségeit, ha egyedi fejlesztés. Valójában viszont az a helyzet, hogy éppen az egyedi fejlesztésű kriptográfiai megoldások jelentik a legnagyobb kockázatot ezen a téren. Egyrészt éppen azért, mert nincs egy egyedi, zárt forráskódú fejlesztés mögött egy hatalmas közösség, amelyik rá tudna mutatni a tervezésben vagy esetlegesen az implementációban – azaz konkrét szoftveres megvalósításban – rejlő gyengeségekre. Másrészt azért, mert körülbelül olyan rossz, mint a biztonság hiánya: hamis biztonságérzetet ad.

Többek közt ezeket a témákat filézték ki a tavalyi Ethical Hackingen egy-egy előadás keretében az előadók, amikről a videó nemrég már elérhető a neten is.

Az idei Ethical Hacking konferencia programja nemrég vált elérhetővé itt. 

A három emlegetett témáról szóló felkerült tavalyi videót pedig itt nézhetitek meg.

--

--

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.

Na jó, a címadással csaltam egy kicsit: egyrészt az egyik legerősebb ma ismert és civil használatra megengedett titkosítási eljárásról fogok írni, másrészt a számításelméleti részletekbe egyáltalán nem megyek bele.

A PGP vagy annak egy klónja, megbízható becslések szerint az egész világon a titkosítást alkalmazó kütyük - legyen szó mainframe szerverről vagy filléres mobilról - közt legtöbb helyen alkalmazott titkosítási eljárás. A PGP valójában két titkosítási eljárás, egy asszimmetrikus és valamelyik szimmetrikus módszer alkalmazásaként működik.

Az asszimmetrikus titkosítás gyakorlatilag minden esetben az RSA módszeren alapul, aminek a működését a következő módon szemléltetném, ráadásul már-már tankönyvi nevekkel: Alice szeretne üzenetet küldeni Bobnak, viszont abban az esetben, ha Alice az üzenetet titkosítja, akkor a titkosításhoz szükséges kulcsot is el kellene juttatnia Bobnak, hogy Bob ugyanazzal a kulccsal az üzenetet vissza tudja fejteni. Abban az esetben, ha a titkosításhoz szükséges kulcsot közben elkapják a titkosított üzenettel együtt, a titkosítás semmit sem ér, hiszen vissza tudja fejteni az is, aki elkapta. Ezzel szemben az asszimmetrikus titkosításnál Alice és Bob egyaránt rendelkezik egy kulcspárral: mindkettőjüknek van egy saját, privát kulcsa, amit csak ő ismer és egy publikus kulcsa, amit bárki ismerhet és ismernie is kell, ha titkosított üzenetet szeretne küldeni neki. Ebben az esetben a történet a következő módon néz ki:
1. Alice és Bob odaadják egymásnak a saját publikus kulcsukat [ezt csak egyszer kell megtenniük]
2. Alice titkosított üzenetet küld Bobnak olyan módon, hogy az üzenet titkosításához a saját privát és Bob publikus kulcsát használja, majd elküldi az üzenetet
3. az üzenet megérkezik Bobhoz, majd az üzenet visszafejtését a saját privát kulcsával, valamint Alice publikus kulcsával végzi el

Azaz egyszer sem haladt át a teljes titkosításhoz szükséges kulcs, mégis tudják olvasni az egymásnak küldött üzeneteket, így az 1970-es években a több ezer éves (!!) ún. kulcsmegosztási problémát oldották meg. Hogyan kombinálódik is az asszimmetrikus és szimmetrikus módszer?

A szimmetrikus kulcsú titkosításnál ugyan csak egy kulcs van, ami a titkosítást és a visszafejtést egyaránt végzi, de ez ideális esetben eléggé erős.

Teljes kommunikáció RSA-val titkosítani egyrészt elképesztően számításigényes lenne, másrészt szükségtelen is, ebből adódott az ötlet, hogy a kettőt össze lehetne lőni, így létrehozva egy olyan titkosítási eljárást, ami kellőképpen erős ahhoz, hogy minden ma ismert törési próbálkozásnak ellenálljon. Ennek az ötletnek az alapján valósította meg Phil Zimmermann a PGP-nek nevezett titkosítási eljárást 1991-ben, ami a következőképp működik:

1. Alice tömöríti az üzenetet, hogy a műveleteket kisebb adathalmazon kelljen végrehajtani
2. Alice egy egyszer használatos, akkor generált kulccsal titkosítja az üzenetet egy szimmetrikus módszerrel
3. Alice magához a szimmetrikus titkosításhoz használt kulcsot - amit beágyaz az üzenetbe - titkosítja Bob nyilvános kulcsával, majd elküldi az üzenetet

Bob az üzenet visszafejtésekor a saját privát kulcsával először az asszimmetrikus titkosításhoz használt kulcsot éri el, majd azzal bontja ki a teljes üzenetet.

Kultúrtörténeti érdekesség, hogy az internet hőskorában az, hogy egy egyszerű otthoni számítógéppel olyan erős titkosított üzenetet lehetett létrehozni, amit még a nagy-nagy hárombetűs szervezetek sem tudnak visszafejteni szuperszámítógépekkel, akkora riadalmat keltett, hogy 1993-ban az USA-ban eljárást kezdeményeztek Phil Zimmermann ellen, viszont lévén, hogy nem lehet perelni valakit csak azért, mert túl hatékony algoritmust hozott létre, a vád a fegyverek exportját szabályozó törvény megsértése volt. Végül az eljárást 1996-ban megszüntették vádemelés nélkül, addigra pedig a PGP már úgyis elterjedt az egész világon.

Még középiskolás koromban gondolkoztam azon, hogy ha ennyire egyszerű és ennyire hatékony egy titkosítási eljárás, akkor miért nem megy át minden elképzelhető felhasználói adat két fél közt, azaz például ha emailt vagy SMS-t küldünk valakinek, az eszköz csak betöltené a címtárból a feladó nyilvános kulcsát és a címzett már meg is nyitná az üzenetet a saját privát kulcsával. A teljes magyarázat bőségesen meghaladná ennek a posztnak a kereteit, a legfontosabb indokok mogyoróhéjban az emailezés példáján keresztül: pont a 90-es évek elején robbantak be az ingyenesen elérhető email szolgáltatók, amik döntően webes felületen működtek és a felhasználóik tudatosság szempontjából egész egyszerűen nem voltak érdekeltek abban, hogy az üzeneteik titkosítva legyenek, a szolgáltatóknak pedig nem volt érdekük plusz munkát róni a saját szervereikre, ezen kívül a privát kulcsokat is biztonságosan tárolni kellett volna valahol, ha szempont, hogy a felhasználó a leveleit bárhonnan meg tudja nézni, ne csak azon a gépen, amin a saját privát kulcsa van. Megjegyzem: ebben az időben még pendrive-ok és hasonlók kanyarban sem voltak, amin lehetett volna tárolni és használni a privát kulcsot.

Ma pedig az ingyenes levelezőszolgáltatók leggyakoribb üzleti modellje az, hogy a levelezésért nem kell fizetni, viszont egy algoritmus megvizsgálja a levélben előforduló kifejezéseket, majd annak alapján sebészi pontossággal helyez el targetált hirdetéseket a levél szövege melletti oldallécben. Dollármilliárdos piacról van szó. Ha az üzenet titkosított, természetesen a hirdetés targetálása lehetetlen. A Gmailnek például nyilván veszteséges, de nem tiltja, hogy olyan üzenetek továbbítására használják a felhasználók a fiókjukat, amik teljesen elemezhetetlenek az elemzőmotorjaik számára, ez azonban a felhasználóknak csak nagyon kis részét érinti.

Elméletileg megoldható, hogy egy webes levelezőrendszerben PGP-t alkalmazzanak, ez azonban rendkívüli kockázatot rejt magában, hiszen ha valamilyen módon a privát kulcsokat ellopják, az összes felhasználó titkosított levelezése olvasható lesz, ráadásul új kulcsot kellene mindegyiküknek generálnia. Valójában a publikus levelezőrendszerek közt egyetlen normális kivétel van, a Hushmail, ami a privát kulcsok tárolását saját maga oldja meg, ez a kulcs egyébként le is tölthető.

De mit tegyünk, ha saját magunk akarunk olyan titkosított leveleket küldeni és fogadni, amit aztán tényleg nem olvas se ember, se isten, hacsak nem szerezte meg a privát kulcsunkat? Természetesen több konkrét megvalósítás is van, ezek közül az egyik legelterjedtebb kombót mutatom be, ami működik Windowsban, OSX-en és linuxokon is.

Először is a levelezőszolgáltatónknál engedélyezzük az IMAP4/POP3-letöltést - annyira alap szolgáltatás, hogy ha nem lenne lehetséges, időszerű szolgáltatót váltani - majd telepítsünk fel egy levelezőklienst, például a Thunderbirdöt. Ezt követően szükség lesz egy PGP motorra, amiből többféle is létezik, a legelterjedtebb a Gnu Project által feljesztett GnuPG, ami Windowshoz a http://www.gpg4win.org/ címről, OSX-hez pedig a https://gpgtools.org címről tölthető le, a linux-júzerek meg úgyis tudják. Ezek után a Thunderbirdbe telepítsük az Enigmail addont, ami meg fogja hívni a motort, amikor titkosításra van szükség.

Ha mindez megvan, indítsuk el a GnuPG részeként települt PGA-t [GnuPG Agent] vagy a Kleopatra-t, ahol már gyerekjáték új kulcspárt generálni, kezelni. A kulcsunk mérete lehet 1024, 2048, 3072 és 4096 bites is, viszont erősen ajánlott alapértelmezés szerinti 2048 bites kulcsot generálni, mivel más PGP-szoftverek ezzel garantáltan kompatibilisek, ideértve például mobiltelefonok esetén például Android platformon az APG-t, iPhone-nál használt iPGMailt-t is. Fontos, az is, hogy a kulcs több jellemzője is megváltoztatható, a mérete azonban nem!

Ha a kulcspár készen van, aminek a privát részét egy szerkeszthető jelszó is védi, készítsünk róla másolatot, a publikus kulcsot pedig küldjük át annak, akinek szeretnénk GPG-zet levelet küldeni ill. kérjük el az ő publikus kulcsát. Természetesen azért, hogy mindez egyszerűbb legyen, szerte a neten vannak óriási "GPG-telefonkönyvek", ahol ki lehet keresni más GPG-kulcsát az email címe, neve és egyéb adatok alapján, így a publikus kulcsok betölthetők a saját helyi kulcstárunkba illetve mi is feltölthetjük a sajátunkat. Ha egy nagy GPG-adatbázisba feltöltöttük a publikus kulcsunkat, a többibe már nem szükséges, hiszen ezek szinkronban vannak egymással, Magyarországon ilyen például a http://keys.niif.hu/

Amint mindez kész, írjuk meg a titkosítani kívánt levelet, majd küldéskor üssük be a privát kulcsunkhoz tartozó jelszavunkat, az Enigmail pedig a címzett alapján tudni fogja, hogy kinek a publikus kulcsát kell használnia az üzenet titkosításához a kulcstárunkból és a levelet el is küldtük.

Ami még hatalmas előnye a megoldásnak, hogy ha a levelet digitálisan alá is írtuk, az megmásíthatatlanul bizonyítja, hogy a levelet valóban mi írtuk, akkor, azzal a tartalommal, közben nem írt át benne senki semmit és mivel egy GPG-kulcshoz több email cím is hozzárendelhető, ha az email címünk megváltozik, de a leveleinket továbbra is aláirkáljuk, az igazolja a címzett oldalán, hogy tényleg mi vagyunk csak más címmel, nem pedig valaki a nevünkben akar levelet írni.

A posztban nem tértem ki rá, hogy természetesen minden normális levelezőklienshez hozzá lehet adni olyan kiegészítőt, ami lehetővé teszi a PGP-zést, csak éppen van, amelyikben iszonyatosan fapados módon működik. Ahogy nem tértem ki a kulcspár finomhangolási lehetőségeire sem [érvényességi idő, kulcs értvénytelenítésének lehetősége].

Amit viszont nagyon fontos megjegyeznem, hogy a szimmetrikus- és asszimmetrikus titkosítást természetesen nem csak emailek titkosításánál használják, hanem ez a lelke például az SSL/TSL-titkosításnak is, aminek a nyomát nap, mint nap látunk a böngészőben szinte minden, önmagára valamit is adó webszolgáltatásnál, kis lakatként a böngészőben a címsor elején. Ott az egyszer használatos kulcs ismétcsak nálunk van, de a böngésző belügye, hogy azt hogyan kezeli, míg a publikus kulcs a szervernél, ami éppen kiszolgálja a webhelyet. A titkosítás eléggé világos ok miatt sokkal kisebb, mint 2048 bites kulccsal dolgozik. De a technika egyre több internetes telefonálást vagy chatelést biztosító szolgáltatásban is ott figyel, nem mellékesen nem mindegyikben, amelyikre a gyártó azt mondja, hogy igen. A ütősebb, jóval erősebb hardveres titkosítást alkalmazó pendriveok titkosításának az alapja ugyanez.

Néhány kapcsolódó téma, amibe most szintén nem mentem bele: az alkalmazott asszimmetrikus módszertől függően bizonyos kulcsok csak titkosításra használhatók, digitális aláírásra viszont nem valamint az, hogy a titkosítás szigorúan számításelméleti szempontból feltörhetetlen, nem jelenti azt, hogy a gyakorlatban is az: például, ha az egész véletlenül hibásan van leprogramozva vagy az algoritmusnak az a része, ami a kulcspárok generálásához a dög nagy prímszámokat nem teljesen véletlenül választja ki, így a lehetséges privát kulcsokból sokkal kevesebb állítható elő - amiből nemrég orbitális botrány is lett. 

A GPG-ről egyébként Thunderbird-GunPG-specifikusabban egy behatóbb cikket is írtam néhány napja, amit itt találtok meg. 

[kollégák figyelmébe: itt ismeretterjesztő cikkről van szó, ennek megfelelően lett megírva, az egyszerűsítések és az érthetőség kedvéért alkalmazott kevésbé precíz megfogalmazás, a PGP és GPG itt-ott szinonimaként való használata az érthetőséget hivatott szolgálni] A magyarázó ábra forrása: Wikipedia.