16 914
Tesztek Android Google Apple Microsoft Samsung Huawei Linux Okostelefon Biztonság Tudomány Facebook Videojáték Film
Kattints ide  ➜

A titkosított webes kapcsolatok lehallgatása

Black Cell Kft.2013.03.10. 12.14
Belegondoltunk már abba, milyen lehet egy személy Facebook beszélgetését, Gmail levelezését, vagy bármelyik más titkosított kommunikációját lehallgatni? Valószínűleg igen. A helyzet az, hogy ennek kivitelezése nem csak a hollywoodi filmekben lehetséges.

Amikor a HTTPS forgalmak megfigyeléséről beszélünk, az történhet legális értelemben, például egy vállalat adatfelügyeleti szabályzása által, vagy illegálisan. Mind a két esetben az SSL/TLS kapcsolatok, az AES (Advanced Encrytion Standard) és a végpontok sérülékenységei vannak kiaknázva, de éppen a tanúsítványokkal is mehet a játék.

Az első, legális esetben a vállalatok többnyire SSL proxy-t alkalmaznak, amely begyűjti a forgalmat az alkalmazott eszköz és a világ között. Ez egy bevett gyakorlat, divatos szóval élve a DLP (Data Leakage Prevention) egy része, ami a "biztonságos" webes szörfölést felügyeli. Amikor a felhasználó ezeken az oldalakon - HTTPS - tevékenykedik, az SSL proxy kicselezi a webszerver tanúsítványát, majd kiépíti a legitim kapcsolatot a proxy és a webszerver között. A proxy ezután készít egy hamis tanúsítványt a felhasználó számára, amely igen nagyban hasonlít az eredetire és felépíti a második SSL/TLS sessiont a felhasználó és a web proxy között. A felhasználó esetleg kap egy hibaüzenetet egy felugró ablakban - és valószínűleg ki is ikszeli -, hogy a tanúsítvány vélhetően nem megbízható. Természetesen a vállalatok rászánják az időt, hogy beimportálják a proxy tanúsítványait a webes böngésző számára. Ebben az esetben természetesen nincs hibaüzenet. A proxy így lényegében "plain textben" - titkosítatlan szövegként - látja az adatokat és ki tudja szűrni az előre meghatározott kulcsszavakat és a malware-ket. Ez - akárhonnan is nézzük - egy MITM (Man-In-The-Middle) támadás pompás példája. Csak nem támadás ugye, hanem a felügyeleti eszköz.

A másik esetben viszont már nyugodt szívvel lehet támadónak nevezni, aki gyakorlatilag ugyanezt az eljárást alkalmazza, hogy hozzáférhessen a kívánt adatokhoz. A másik szó, amit nyugodt szívvel használhatunk, az a triviális, hiszen eléggé egyszerű az alkalmazása. Olyan előre leprogramozott eszközök állnak publikusan a téma iránt érdeklődők rendelkezésre, hogy némi alapismerettel gyakorlatilag bárki csemegézhet a "biztonságos" Gmail, Facebook és sajnos a banki tranzakciók között is. A séma ugyanaz, begyűjteni a webszerver tanúsítványát, és menet közben legenerálni az újat a szerzett információkkal. Egy másik eszközzel pedig teljesen eltakaríthatjuk a kliens SSL kapcsolatát és odabiggyeszthetünk egy zöld lakatot, hogy a felhasználó szépen megnyugodjon.

Az SSL/TLS titkosítási szabvány egy olyan funkcióval rendelkezik, amivel a meghatározott böngészőkből elegendő információ nyerhető ki ahhoz, hogy visszafejtsük az állítólag védett felhasználói sütik titkosítását, és "kifosszuk a sessoinöket" (Hijack session). Két igen kiváló figura kifejlesztett egy exploitot, ami ezt a sérülékenységet használja ki és immáron a TLS minden verziója ellen bevethető, valamint a session titkosításánál alkalmazott chiper készlet sem változtat a támadás sikerességén. Őket személy szerint Juliano Rizzonak és Thai Doungnak hívják. Ez a páros volt az, aki 2011-ben kihozta a nagy port kavaró BEAST (Browser Exploit Against SSL/TLS) névre hallgató programot. Ez akkor igen kritikus kérdésnek számított, mivel a bankok által is alkalmazott TLS 1.0-ára vonatkozott. Ám, a ravasz bankos szakemberek, mintha a jövőbe láttak volna, megtagadták, hogy átváltsanak a TLS 1.1-re, ami igen komplikált lett volna. Lám, igazuk lett, mert kijött a továbbfejlesztett CRIME (Compression Ratio Info-leak Made Easy). Itt már édes mindegy, hogy a TLS melyik verziója fut, vagy, hogy az AES helyett RC4-es algoritmus van-e alkalmazva. Egy biztos, nevet is igen frappánsan tudnak választani. Mind a két támadás egy JavaScript kódot futtat le az áldozat böngészőjében. Igen, megint a JavaScript és megint a böngészés közbeni klikkelgetéssel lehet áldozatul esni.

Szeretnék naprakész információkkal szolgálni, így nem a fentieket, hanem a Lucky Thirteent fejtem ki részletesebben, ELMÉLETI SÍKON. Ez nem egy praktikus dolog, mivel igen dolgos és igen sokat kellene rajta guggolni, de az tény, hogy érdekes.

A név a titkosított TLS csomagok headerjéből jött, ugyanis ez 13 bájtot használ fel. Illetve javítanom kell, 12 bájtot is használhat, csak így jobban cseng. Nyilván 12 bájtnál még hatékonyabb a támadás.


A legtöbb TLS sessionben a titkosított csomagok:

Általában AES-t használnak CBC módban a blokkok titkosítására

Általában HMAC-SHA1-et alkalmaznak ellenőrzésként, hogy megelőzzék a hibákat és a hamisításokat

Azt lehetne hinni, hogy ilyen megoldásokkal igen komoly biztonsági szintet lehet elérni. Azonban a vicces az, hogy ezt a két biztonsági funkciót fel lehet használni egy másik ellen, TLS-ben való kombinálásuk miatt.


A támadás a következőkre támaszkodik:

Az AES 16 bájtos blokkokat titkosít egyszerre és azok a csomagok, amik nem ilyen hosszúak azokat ki kell egészíteni.

A TLS csomagok ellenőrző kódja a titkosítási rétegen belül tárolódik a nyers adatok után, de a szükséges kiegészítések, kitömések előtt.

Amikor a TLS szerver megkapja a csomagot, ami már AES-CBS-el titkosított és HMAC-SHA1 kóddal rendelkezik, a következőképpen kell validálnia:

- Fel kell oldania a fogadott adatok titkosítását, ami több 16 bájt hosszú csomag.

- Fel kell fedeznie és le kell választania a kitöméseket a visszafejtett pufferek végén.

- Le kell választania az utolsó 20 bájtot (ez HMAC-SHA1 hash bázisú autentikáló kód mérete) és referenciaként tárolnia.

- Ki kell számítania HMAC-SHA1 kódot, ami benne maradt a pufferben.

Ha a kiszámolt HMAC-SHA1 kód nem egyezik a referencia kóddal, akkor az hibás, vagy hamis. A szerver ilyenkor visszaküld egy hibaüzenetet és megszakítja a kapcsolatot. Képzeljük el, hogy "mi vagyunk az ember középen" (MiTM). Menet közben nem tudjuk visszafejteni és újra titkosítani a csomagokat, de el tudjuk kapni, le tudjuk rövidíteni és finoman tudjuk őket módosítani, majd továbbadni a módosított verziót. Minden egyes alkalommal, amikor így járunk el, feltörjük a TLS sessiont, de megtehetjük, mivel csak az információkat nézzük meg az immáron megtört sessionben. Ez nem azt jelenti, hogy már miénk is a "dicsőség", de bármit kihalászhatunk a titkosított adatfolyamból.

A trükk az, hogy amikor megcsonkítjuk a titkosított csomagot van rá esély, hogy az adatfolyam végéről levágott egyszerű szöveg, valahogy úgy fog kinézni, mint a TLS által használt eredeti tömítő, kiegészítő adat. Ebben az esetben a TLS szerver le fogja vágni azt, amit tömítésnek gondol, kivonja, amire azt hiszi, hogy a csomag ellenőrző kódja és összehasonlítja az egyezést. Természetesen nem fognak egyezni, de emiatt nem kell aggódni. Amire figyelni kell az a TLS szerver hibaüzenetének a hosszúsága, amit a csomag érvénytelensége miatt küld vissza.


A HMAC-SHA1 működése során négy egységet vesz el a CPU idejéből, hogy ellenőrizze az első 55 bájtnyi adatot, plusz egy egységet minden további 64 bájtos adatdarabhoz.


Próbálkozások

Azonban, és most jön az érdekesség, ha egy két bájtos csavart teszünk bele és megcsonkítjuk a titkosított csomagot, akkor van rá esély - nagyjából 1:65.000-hez -, hogy a szerver rosszul fogja gondolni, hogy a csomag ki van egészítve, majd levágja a kiegészítést és a maradékot adja be ellenőrző kódként. Ha a TLS szerver kódja nincsen precízen megtervezve, hogy ugyanazt az időt használja fel, mint ami a tartalom dekódolásához szükséges, akkor az eredeti csomag feldolgozásánál az idő 4/5-ét veszi igénybe.

Ez megtörténhet, mivel a trükkös csomagunkkal kicseleztük a szervert és az ellenőrző 55 bájt lesz vagy kevesebb, nem pedig 56 vagy több. Ha megbízható méréseket tudunk végezni, hogy a szerver hibaüzenete milyen gyorsan jön vissza, akkor a csavar alapján ki tudjuk számítani azt a két bájtot, amit az eredeti csomag tartalmazott. Szisztematikus próbálkozások mellett, minden lehetséges két bájtot bepróbálva, feltételezve a tökéletes időzítést garantáltan ki tudunk vonni kettőt a titkosított bájtok közül. Ha egyszer az első két bájtot megtörtük, a következő 14-et is meg tudjuk, egyesével, bepróbálva (2^16) mind a 256 lehetséges beállítást, aminek az összege (2^16) + 14*(2^8). Hát igen, próbálkozni kell párszor.

Ezek a Lucky Thirteen támadás groteszk módon összefoglalt műveletei. Mint említettem ez nem egy gyakorlatias támadás, és nemcsak azért, mert a teljesen tökéletes méréseket gyakorlatilag nem lehet elvégezni (bár van, akinek sikerült):

- Minden egyes próbálkozásunkkal megszakítjuk a TLS sessiont, ami megfigyelhető és időigényes

- Minden egyes próbálkozásnak ugyanazt a szöveget és csomaghelyzetet kell tartalmaznia

- Nagyjából 8 milliló TLS session-re van szükség, amiben a mérések is benne vannak.

Tehát elég komplikált.Továbbá mindennek ideális hálózati környezetben kell történnie úgy, hogy a TLS kliens, a szerver és az MiTM PC is egy dedikált LAN-on legyen. Azonban, az hogy ez elméletileg tud működni, igen nagy lyukat üt a TLS titkosítási szentségén, mivel ez az operáció, nem a kliens sérülékenységeire támaszkodik, hanem magára a titkosítási műveletre. Ezen autentikált titkosítási algoritmussal (pl.: AES-GCM), titkosítási utáni ellenőrzéssel lehet javítani. Érdekes módon ezek a fejlesztések már bekerültek a TLS 1.2-be, ami nagyjából 5 éve jött ki, ám a weboldalak csupán 12%-a alkalmazza egy 2013 januári felmérés alapján, és a legtöbb böngésző nem tartalmazza, kivétel az Internet Explorer Windows 7 és 8 alatt.

A cikk a Black Cell Kft. megbízásából kerül publikálásra, Gyebnár Gergő tollából.
Kattints ide  ➜

Az Androbit technológiai és tudományos magazinnál hiszünk abban, hogy az információ mindenkit megillet. Hosszú évek munkájával megszerzett hírnevünknek köszönhetően megadatott számunkra az a lehetőség, hogy műszaki témájú médiumként is elérhessünk minden internetező korosztályt. Tesszük ezt olyan hírekkel és cikkekkel, amik között egyaránt szerepel nagyobb tömegeket és kisebb szakmai csoportokat érintő tartalom is.

A témák gondos összeválogatásának és a cikkek minőségi kidolgozottságának hála mára Magyarország egyik legnépszerűbb technológiai és tudományos információforrásává váltunk – fejlesztéseinkkel és kutatásainkkal pedig igyekszünk mindig egy lépéssel a versenytársak előtt járni.

A weboldalunkon található, szerkesztőségünk által készített tartalmakra vonatkozó összes felhasználási jogot az Androbit technológiai és tudományos magazin birtokolja. A tartalmak egyes részleteinek felhasználását kizárólag látványos (vagy jól hallható) forrásmegjelöléssel engedélyezzük. A feltételek megszegésének jogi következményei lehetnek. A feltételektől eltérő tartalomfelhasználás kizárólag megegyezés útján lehetséges.
Copyright © 2007-2016 – Makay József (makay@androbit.net)