» »

Odkrita resna ranljivost v SSL in TLS protokolih

Odkrita resna ranljivost v SSL in TLS protokolih

Slashdot - Predvčerajšnjim in včeraj so splet preplavile informacije o novo odkriti ranljivosti v šifrirnih protokolih SSL 3.0+ in TLS 1.0+. Gre za varnostno ranljivost, ki izkorišča napako v "pogajalskem procesu" protokola (tim. renegotiation phase), omogoča pa napade s posrednikom (tim. MITM napade) oziroma napade na HTTPS seje podpisane s certifikatom odjemalca.

Kot poročajo na SSL Shopper (analizo napada je na svojem blogu objavil Ivan Ristić) je težava v tem, da lahko nekdo nadzoruje en del šifrirane povezave pred ponovnim pogajanjem, nekdo drug pa po ponovnem pogajanju oz. izmenjavi sejnega ključa nadzoruje drugi del šifrirane povezave. Napadalec tako lahko odpre povezavo do SSL strežnika, pošlje nekaj podatkov, zahteva ponovno pogajanje in SSL strežniku prične pošiljati podatke, ki prihajajo od žrtve. Spletni strežniki (IIS in Apache) podatke, ki so prišli od napadalca in podatke, ki so prišli od žrtve nato povežejo, posledica česar je, da napadalec lahko SSL strežniku pošlje poljuben zahtevek, ki ga nato avtenticira njegova žrtev.

Ranljivost v protokolih torej omogoča, da napadalec v začetek podatkovnega toka aplikacije (v HTTPS seji) vrine poljuben niz nešifriranih podatkov. To mu omogoča izvedbo poljubne HTTP transakcije, žrtvi lahko prikaže poljubno vsebino v HTTPS seji ali pa njegov certifikat uporabi za povezovanje do poljubnega strežnika (in s tem izvede klasičen napad s posrednikom).

Podrobnosti napada so opisane v članku Renegotiating TLS Marsha Raya in Steva Dispensa iz podjetja PhoneFactor (na voljo je tudi diagram napada).

Rešitev sicer še ni na voljo, se pa na njej že intenzivno dela.

10 komentarjev

poweroff ::

Še par zanimivih diagramov (iz sorodnega napada): http://www.win.tue.nl/hashclash/rogue-c...
sudo poweroff

fiction ::

Zelo zanimivo.

V bistvu IMHO "rogue CA napad" ni kaj dosti soroden. Pri tem gre za pomankljivosti v MD5 in pri CA-ju, ki omogoca izdajanje "fake-CA" certifikata. Omenjeni napad cilja na to, da se drug streznik izdaja kot tisti pravi, recimo za phising.

Tukaj gre za to, da napadalec kot MITM poslje nek svoj request v plaintexu potem pa ga dejanski uporabnik "avtorizira" (napadalec pa tisto samo poslje naprej strezniku). Za server izgleda kot da je oboje prislo prek kriptirane povezave in od pravega uporabnika.

denial ::

Da bi se izognil nepotrebni paniki je eden izmed OpenSSH razvijalcev na svojem blogui objavil post da SSH ni ranljiv na renegotiation bug: KLIK. Na renegotiation session bug pa niso imuni protokoli IMAPs, POPs in SMTPs, čeprav je možnost zlorab v teh primerih verjetno minimalna.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Looooooka ::

mislm da je vecji problem da so ranljivi webserverji kot pa imap pops in smtps.
ne vem kdaj sem nazadnje placeval neki prek maila...al pa shella.

fiction ::

IMHO je ta bug bolj ala XSS oz. CSRF. Napadi so taki, da vrines zraven se neko kodo, ki v kontekstu clienta omogoca napadalcu neko priviligirano akcijo.

Da bi se izognil nepotrebni paniki je eden izmed OpenSSH razvijalcev na svojem blogui objavil post da SSH ni ranljiv na renegotiation bug
Se sreca. Ce bi bil, bi bilo to precej kriticno. Ampak za SSH je lazje, ker imas vzpostavljeno ves cas seje TCP povezavo. Pri HTTP-ju je v bistvu vsak request nekaj novega, vsakic posljes vse headerje, vcasih je vec requestov na enkrat (keep-alive), vedno lahko naredis rekeying itd.

ne vem kdaj sem nazadnje placeval neki prek maila...al pa shella.

Ce imas shell dostop, lahko delas precej stvari - prakticno vse kar bi lahko tudi, ce ne bi na daljavo dostopal. Se pravi shell dostop je mogoce dovolj za nek backdoor, ki bo takrat ko bos nekoc kakorkoli placeval problematicen.

BlueRunner ::

OpenSSH ni ranljiv, ker je to napaka v protokolu in ne napaka v implementaciji šifrirne knjižnice (OpenSSL), ki jo OpenSSH uporablja. IMAP, POP in ostali protkoli zaprti v SSL/TLS tunele ali pa razširjeni s podporo za STARTTLS mehanizem, pa so ranljivi. Kar je razumljivo, saj je ranljiv sam protokol.

Zelo neprijetno vprašanje pa je, kakšna je stopnja ranljivosti pri t.i. SSL VPN produktih, ki izkoriščajo ta protokol za varovanje podatkov pri prenosu od oddaljenega odjemalca do matičnega omrežja. Če se bo tukaj v katerem izmed produktov odkrila možnost MITM-a, bo to še zelo hudo. Tisti, ki v tem trenutku uporabljajo IPSec tunele, so pred to ranljivostjo varni, SSL/TLS pa morda niso.

Težava je veliko večja, ker ni niti pod razno omejena na spletišča...

poweroff ::

OpenVPN, ja.
sudo poweroff

denial ::

Domače spletne banke so se, vsaj v večini, odlično odzvale na SST/TLS renegotiation bug.

OpenVPN not affected: KLIK
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

BlueRunner ::

Ko se že pogovarjamo o tej tematiki. Malo prej sem ime ROTFL trenutek pri branju tega besedila o knjižnici OpenSSL.

BlueRunner ::

Za ceno tega, da bom zvenel kot denial.

Na The Register poročajo o uspešnem vdoru v Twitter s pomočjo te ranljivosti.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Najdena resna varnostna ranljivost v AJPESovi podpisni komponenti (strani: 1 2 3 4 5 )

Oddelek: Novice / Varnost
20181106 (63660) jukoz
»

Odkrita ranljivost v SSL 3.0

Oddelek: Novice / Varnost
157289 (5876) Looooooka
»

Odkrita resna ranljivost v SSL in TLS protokolih

Oddelek: Novice / Varnost
104859 (3828) BlueRunner
»

Napad z ničelno predpono na SSL/TLS certifikate že "v divjini"

Oddelek: Novice / Varnost
416378 (4756) McMallar
»

Izvedba popolnega MITM napada (strani: 1 2 3 )

Oddelek: Novice / Varnost
11620246 (16632) Brane2

Več podobnih tem