Megint meghekkelték az internetet!

Az utóbbi időben rendszeresen bukkannak fel szenzációhajhász hírek az elektronikus sajtóban arra vonatkozóan, hogy „feltörték az internetet”. A híradások nagy része elnagyoltan foglalkozik a konkrét okokkal, a konkrét sebezhetőséggel, sokkal inkább a hatásokra koncentrál: „A legtitkosabb adatokhoz - tehát például gmail, PayPal és Facebook információkhoz is - az SSL encryption nevű védőrendszer feltörésével tudnak könnyedén hozzáférni az adattolvajok.”, „már az SSL-lel védett weboldalakon sincsenek biztonságban az információk”.

A valóság a hírekkel szemben az, hogy a Black Hat konferencián múlt héten bemutatott sebezhetőség nem rengeti meg alapjaiban az SSL-lel, és az X509-es tanúsítványokkal kapcsolatos eddigi képünket. Való igaz, hogy a sebezhetőség súlyos, és a rengeteg, SSL-t implementáló szoftverben megtalálható, azonban ezek az SSL-re és az X509-es tanúsítványok kezelésére vonatkozó RFC hanyag implementációjából, illetve a böngészők és weboldalak felhasználónak adott jelzéseiből fakadnak.

Miben áll a technikai sebezhetőség?

Amikor valamilyen SSL-t megkövetelő szolgáltatáshoz csatlakozik egy kliens, lehetősége van arra, hogy a konkrét adatforgalom megkezdése és a titkosított SSL csatorna felépítése előtt tanúsítványok segítségével meggyőződjön arról, hogy a kommunikációban részt vevő másik fél az, akinek mondja magát.

Az algoritmus, amit a kliens követ, meglepően egyszerű:

1. Nézd meg, hogy a kapott tanúsítvány annak a nevére szól-e, akitől kaptad.
2. Nézd meg, a kapott tanúsítvány lejárt-e.
3. Nézd meg, hogy a tanúsítványt aláíró hatóság (Certificate Authority, CA) ismeretes-e előtted. Ha igen, fogadd el a tanúsítványt és építsd fel a csatornát, majd forgalmazz.
4. Ha nem ismered a tanúsítványt aláíró CA-t, nézd meg az aláíró CA tanúsítványának érvényességét a fenti algoritmussal.

Az algoritmus háromféleképp végződhet.

1. Minden tanúsítvány megfelelő és találunk benne egy CA-t, amelyet elfogadunk hitelesnek (Pl. a Microsoft, a VeriSign, vagy akár a NetLock). Az egész láncot elfogadjuk hitelesnek, és továbblépünk.
2. Valamelyik tanúsítványban hibát találunk. Ekkor jelezzük a felhasználónak, hogy mi a hiba, és megkérdezzük, hogy mi legyen: kommunikáljunk, vagy ne.
3. Minden tanúsítvány megfelelő, viszont elérünk egy olyan CA-hoz, amelynek nincs „felettes” CA-ja (pl. úgy, hogy saját maga írta alá a tanúsítványát). Ez esetben megkérdezzük a felhasználótól, hogy mi legyen.

A tanúsítványok lánca elég hosszú lehet, az SSL implementációjától függ, hogy milyen hosszút tud kezelni. Ha például a böngészőnknek az alábbi tanúsítványláncot adja egy oldal (legyen ez mondjuk a Gigabank netbank alkalmazása), akkor először megnézi a netbank.gigabank.hu tanúsítványát: ezt rendben találja (1. és 2. pont), viszont a Gigabank írta alá a tanúsítványt, így a Gigabank tanúsítványának ellenőrzése következik. Ezt a NetLock írta alá, a NetLock pedig elfogadja hitelesnek a böngészőnk (hiszen bele van égetve, mint hiteles tanúsítványszolgáltató), így megnyugtató kis lakat jelenik meg a böngésző címsorában, megkezdődhet a tényleges adatforgalom. (Az ábrákon zöld háttérrel jelöljük a legitim, pirossal az illegitim tanúsítványokat, a nyilakon pedig a tanúsítvány el (nem) fogadását jelöljük.)

Miért jó ez? Ha a támadó közbeékelődést hajt végre (pl. ARP spoofinggal, vagy egyéb technikával), nem tudja hitelesen megszemélyesíteni a Gigabankot, ugyanis nem fogja tudni aláírni a Gigabank titkos kulcsa nélkül a kliensnek adandó tanúsítványt, a kliens pedig (hibás tanúsítványt kapott) a felhasználótól kérdezi meg, hogy mi legyen. Természetesen a támadó behazudhatja az általa adott tanúsítvánnyal kapcsolatban, hogy a Gigabank adta ki, de ez esetben sem lesz megfelelő az aláírás.

Figyelem, most jön a csavar.

Mi történik akkor, ha a támadónak van egy, a VeriSign által aláírt, hiteles tanúsítványa a Bela Kft. nevére és a saját tanúsítványával hitelesíti az általa generált (hamis) tanúsítványt, amivel az áldozat böngészője számára megszemélyesíti a netbank.gigabank.hu-t?

A hitelesítési algoritmus lefut, a netbank.gigabank.hu tanúsítványát igazolja a Bela Kft., a Bela Kft.-ét pedig a VeriSign. A böngészőnk elfogadja hitelesnek a kapott tanúsítványt.

De hát miért nem gondoltak erre a támadásra a tanúsítványkiadó rendszer kitalálói?

De igen, gondoltak rá. A tanúsítványokban található egy mező, amellyel azt jelölik, hogy használható-e további tanúsítványok aláírására: ez a mező a „Basic Constraints – CA:TRUE/FALSE” mező. Olyan visszakövethető tanúsítványa, amellyel továbbiakat lehet aláírni, csak a tanúsítványkiadóknak lehet, az általuk kiadott tanúsítványokon kellene szerepelnie a CA:FALSE mezőnek, és minden, SSL-t implementáló kliensnek hibát kell(ene) jeleznie, ha CA:FALSE mezős tanúsítvánnyal írtak alá továbbiakat.

Amennyiben használják és jól használják ezt a mezőt, kétféle tanúsítvány lehet forgalomban:

1. Root CA-ig visszakövethető, viszont további tanúsítványok generálására alkalmatlan.
2. További tanúsítványok generálására alkalmas, viszont nem követhető vissza megbízható Root CA-ig.
   

A gyakorlatban azonban mindkét oldalról hibázik a dolog, ugyanis egyrészről sok CA nem teszi bele explicit módon a tanúsítványaiba a mezőt, másrészről az SSL implementációi sem ellenőrzik a mező meglétét. A két hiba bármelyikének fennállásakor előállhat a harmadik ábrán látható helyzet, mely szerint a böngészőnk hitelesnek fogad el el illegitim tanúsítványt.

Mit lehet tenni a fenti helyzet megoldására? Sajnos az a helyzet, hogy a végfelhasználó nem tud sok mindent tenni: a böngészők fejlesztőin a sor, hogy javítást adjanak a fenti helyzetre.