Kritična ranljivost v OpenSSL bi lahko omogočala krajo strežniških zasebnih ključev

Letos ni ravno najboljše leto za varno spletno komunikacijo, še posebej ne za dvojček SSL/TLS. Konec februarja smo lahko brali o nemarni kodi za preverjanje pristnosti strežniških certifikatov v Applovem iOS/OS X, še ne dva tedna zatem pa o kar 9 let stari podobni luknji v odprtokodni knjižnici GnuTLS. Malo poenostavljeno rečeno je kazalo, da prav nihče več ne zna pravilno preveriti pristnosti strežniške strani komunikacije.

Zdaj smo dobili še eno luknjo, tokrat na strežniški strani. Pomanjkljiva implementacija ti. heartbeat (TLS keepalive) razširitve v OpenSSL 1.0.1 napadalcu lahko omogoči pridobitev neposrednega dostopa do pomnilnika na strežniku, s tem pa tudi dostop do šifrirnega ključa za to sejo, ali celo zasebnega ključa od tega strežnika. V kodi je prisotna nekje od marca 2012. Glavni problem je v tem, da je OpenSSL ena najbolj popularnih knjižnic za šifriranje, prav tako pa jo uporabljata popularna spletna strežnika Apache in Nginx, na katerih sloni nekje dve tretjini vseh spletnih strani.

Varnostno podjetje CloudFlare, ki je skupaj s kolegi na Googlu tudi odkrilo napako, vsem prizadetim spletnim stranem priporoča takojšnjo nadgradnjo na sveži OpenSSL, ter, če je mogoče, tudi menjavo šifrirnih ključev in ponovno generiranje SSL certifikatov. Niso še prepričani, ali je napako kdo tudi aktivno izkoriščal, nameravajo pa zdaj to preveriti s pomočjo posebnih honeypot strežnikov. Ocene o tem se pričakujejo v kratkem. Če jo je, mu naj ne bi bilo težko priti tudi do zasebnega ključa, in to kar lepo na daljavo, brez potrebe po prestrezanju ene ali več obstoječih sej in brez puščanja kakršnih koli sledi na strežniku, npr. dnevniških zapisov.

Napadalec s posestjo zasebnega ključa bi lahko potem odklenil vso zajeto preteklo komunikacijo, razen seveda, če sta se takrat brskalnik in strežnik dogovorila še za posebni začasni sejni ključ (Perfect Forward Secrecy). Takšno možnost žal podpira le malo strežnikov; Slo-Tech recimo jo. Dalje bi napadalec lahko postopal tudi aktivno, npr. postavil svoji lažni spletni strežnik, ali izvedel man-in-the-middle napad.

Kot rečeno, leto se je precej zanimivo začelo ...

Dodatek: POC / spleti vmesnik, s katerem lahko preverite ranljivost vašega strežnika, od @FiloSottile.
Dodatek #2: Če kaj, je to odlično opozorilo, da se zasebnih ključev pri bolj kritičnih aplikacijah pač ne sme hraniti v delovnem spominu. Namenske HSM kartice ftw.