Rubriik: Brauser

4. novembril aadressil http://extendedsubset.com/ publitseeritud info SSL protokolli nõrkuse (“SSL Authentication Gap”) kohta on leidnud elavat vastukaja, Internet kubiseb blogijate postitustest ning on olemas ka kodumaine näide.

Ette rutates võib öelda, et soovitus ID-kaardid sahtlisse panna on enneaegne. Kliendituvastusega (client authentication) SSL/TLS protokolli kasutamine on ja jääb alati turvalisemaks kui ilma selleta. Paneme tähele, et kõik teised autentimisvahendid (paroolikaart, PIN-kalkulaator, Mobiil-ID) ei kasuta kliendituvastusega SSL protokolli ning on seetõttu olulisel määral rohkem altid vahemehe (Man-in-The-Middle) rünnakutele, kus ohver juhatatakse võltslehele ning vahendatakse sobivalt tema suhtlust „pärislehega“.

Milles siis jutu all olev nõrkus seisneb?  Olukorra lihtsustamiseks vaatleme näidet, kus SSL veebiserver on konfigureeritud aktsepteerima ID-kaarti, kuid see ei ole „kohustuslik“, s.t. eksisteerib serveri alamosa, mida saab kasutada siis, kui ID-kaardiga ei ole autenditud või autentimine ebaõnnestus. Nii on meil konfigureeritud enamus veebiservereid, kuna kasutajasõbralikkuse huvides on ID-kaardiga autentimise ebaõnnestumise korral ilus näidata browser error’i asemel mingit ilusamini kujundatud pilti.

Nende kahe SSL oleku (on klient autenditud või ei) vahetamist nimetatakse SSL renegotiation’iks ehk siis maakeeli „ümberleppimiseks“. Häda on nüüd selles, et enamus SSL realisatsioone ei pea järge selle üle, kas ümberleppimise-eelne sessioon oli sama mis ümberleppimis-järgne.

Kujutame nüüd ette olukorda, kus ohver alustab serveriga sessiooni nii, et kliendituvastust veel ei nõuta. Kommunikatsioonikanalil asuv ründaja aga varastab selle sessiooni ning asub suhtlema ohvri eest. Peale SSL ühenduse saavutamist teeb ründaja päringu, mille täitmiseks server nõuab kliendituvastust. Hakkab toimuma ümberleppimine, ründaja annab nüüd „otsad ära“, vahendades pakette edasi-tagasi, ja laseb ohvril sooritada kliendi autentimise. Peale edukat autentimist on aga serveril kohustus täita esitatud päring (mida ründaja tegi). Päringu tulemused kuvatakse muidugi ohvrile, ründaja neid enam ei näe.

Tüüpiliselt kasutatud näide on see, kui ohver on näljane ning teeb päringu:

GET /pizza?täidis=kana?aadress=Kana8 HTTP/1.1
Cookie: minuküpsis

Singilembeline ründaja aga topib selle päringu ette paar rida (ilma reavahetuseta lõpus) ja tulemus on:

GET /pizza?täidis=sink;aadress=Kurja3 HTTP/1.1
X-Ignore-This: GET /pizza?täidis=kana?aadress=Kana8 HTTP/1.1
Cookie: minuküpsis

Tulemuseks saab ohver jahmatava kinnitusteate väärastunud soovi kohta, kurjam aga võib palvetada (kuna ta serveri vastust ei näe), et kunagi tasuta pizza tuleb. Rohkem ründaja selles seansis osaleda ei saa.

Paneme tähele, et sellise ründe edukus sõltub mitmest asjaolust:

• Ründaja peab asuma ohvri ja serveri-vahelise kommuikatsioonikanali vahel, s.t. ründajal peab olema kontroll mõne marsruuteri või tulemüüri üle ning olema võimeline manipuleerima seal infovooge. Lihtsalt ohvriga samas kohtvõrgus viibides võiks see ka teoreetiliselt võimalik olla kuid praktikas on rünne kohtvõrgust väga väikese õnnestumise tõenäosusega.
• Server aktsepteerib GET-päringuid, mille esmakordse töötlemise tulemuseks on kohe reaalne tegevus (s.t. pizza pannakse teele).
• Server peab olema konfigureeritud nii, et ta suhtleks nii ID-kaardiga autendituna kui ka ilma ning seetõttu SSL ümberleppimine on võimalik.

Kokkuvõtteks võib öelda, et ajalugu on näinud palju hullemaid SSL turvaauke, kummatigi pole maailm veel kokku vajunud ning tundlikud e-teenused eksisteerivad edasi. Eriti paranoilistele e-teenuste pidajatele võiks aga soovitada seda, et ID-kaardi autentimist kasutav e-teenus asuks eraldi IP-aadressil ning kliendituvastus oleks konfigureeritud kohustuslikuks. Võib-olla kaalub 100% turvalisus (antud puuduse mõttes) üles kasutaja frustratsiooni, kes autentimise ebaõnnestumise korral browser error’i saab.