Heartbleed

Heartbleed este un bug de securitate în biblioteca criptografică open-source OpenSSL^{⁠(en)[traduceți]}, utilizată pe scară largă la implementarea protocolului Transport Layer Security care funcționează peste Internet. O versiune de OpenSSL reparată a fost publicată la 7 aprilie 2014, în aceeași zi în care Heartbleed a fost anunțat public. În acel moment, circa 17% (circa jumătate de milion) de servere web din Internet certificate de autoritățile de încredere^{⁠(en)[traduceți]} erau considerate a fi vulnerabile la atacuri ce ar putea permite furtul cheilor private^{⁠(en)[traduceți]} ale serverului, precum și cookie-urile de sesiune și parolele utilizatorilor.^{[3][4][5][6][7]}

Heartbleed este înregistrat în sistemul Common Vulnerabilities and Exposures^{⁠(en)[traduceți]} cu codul CVE-2014-0160.^[8]

Extensia Heartbeat pentru protocoalele Transport Layer Security (TLS) și Datagram Transport Layer Security^{⁠(en)[traduceți]} (DTLS) este o propunere de standard specificată prin RFC 6520, document publicat în februarie 2012. Ea furnizează o modalitate de a testa și pentru a păstra deschisă o legătură securizată de comunicație fără necesitatea de a renegocia conexiunea de fiecare dată.

În 2011, dr. Robin Seggelmann, pe atunci student la doctorat la Universitatea Duisburg-Essen, a implementat extensia Heartbeat pentru OpenSSL. În urma cererii lui Seggelmann de a pune rezultatul muncii sale în OpenSSL,^[9][10][11] modificarea sa a fost revizuită de dr. Stephen N. Henson, unul dintre cei patru dezvoltatori de bază ai proiectului OpenSSL. Se pare că Henson nu a observat un bug în implementarea lui Seggelmann, și a introdus vulnerabilitatea rezultată, Heartbleed, în codul sursă al OpenSSL la 31 decembrie 2011. Codul vulnerabil a fost adoptat odată cu release-ul versiunii 1.0.1 de OpenSSL la 14 martie 2012.^[12][13][14]

La 21 martie 2014 Bodo Moeller și Adam Langley de la Google au scris un patch prin care se repara bugul. Data patch-ului este cunoscută din issue-trackerul Red Hat.^[15] Următoarea dată cronologică disponibilă în bazele de date publice este declarația companiei de securitate și performanță denumită CloudFlare că au reparat defectul pe sistemele lor la 31 martie 2014.^[16]

Conform lui Mark J. Cox de la OpenSSL, Neel Mehta din echipa de securitate Google a raportat bugul Heartbleed la 1 aprilie 2014.^[17] Bugul se manifesta printr-o eroare gravă de tratare a accesului la memorie în implementarea extensiei Heartbeat a Transport Layer Security.^[18][19] Acest defect putea fi utilizat pentru a expune până la 64 kiloocteți de memorie a aplicației la fiecare heartbeat^{⁠(en)[traduceți]}.^[19]

Bugul a fost botezat de un inginer de la firma Codenomicon^{⁠(en)[traduceți]}, o firmă finlandeză de securitate informatică, firmă ce a a creat și logoul și a lansat domeniul Heartbleed.com Arhivat în 7 aprilie 2014, la Wayback Machine. în care bugul era explicat publicului.^[20] Conform firmei Codenomicon, Neel Mehta a raportat primul bugul la OpenSSL, dar atât Google cât și Codenomicon l-au descoperit independent.^[12] Codenomicon raportează data de 3 aprilie ca dată a descoperirii bugului și ca dată în care au notificat NCSC-FI (fost CERT-FI) pentru coordonarea vulnerabilității.^[12][21] Mehta a felicitat și Codenomicon, fără a intra în detalii.^[22]

La 10 aprilie, „Cisco Systems și Juniper Networks, doi dintre cei mai mari producători de echipamente pentru Internet, au anunțat (...) că produsele lor au fost afectate de bugul Heartbleed. Rutere, firewalluri și switch-uri ... au fost toate foarte probabil afectate de bug, expunând informațiile personale la riscul de a fi furate de hackeri.”^[23]

La 12 aprilie, cel puțin doi cercetători independenți au reușit să fure chei private^{⁠(en)[traduceți]} utilizând atacul de pe un server experimental instalat special pentru acest scop de către CloudFlare.^[24][25]

Numeroase site-uri web majore au instalat patch-uri sau au dezactivat funcționalitatea afectată în câteva zile de la anunț,^[26] dar nu se știe dacă potențialii atacatori au fost conștienți de bug mai devreme și în ce măsură a fost bugul exploatat. Pe baza analizelor logurilor de audit efectuate de cercetători, s-a concluzionat că este posibil ca unii atacatori să fi exploatat bugul cu cinci luni înainte de descoperire și anunț.^[27][28] Errata Security a respins parțial aceasta ipoteză,^[29] în vreme ce Department of Homeland Security crede că la 11 aprilie „nu s-a confirmat vreun raport despre vreun atac sau incident malițios care să implice această anume vulnerabilitate”.^[30]

Bloomberg.com citează două surse din interiorul National Security Agency din SUA, care afirmă că defectul a fost observat de organizație la scurt timp după ce a fost introdus, dar a fost păstrat secret și neraportat, în vederea exploatării lui în scopurile organizației.^[31][32][33] NSA a negat această afirmație.^[34]

Extensia Heartbeat RFC 6520 testează legăturile securizate TLS/DTLS permițând unui computer de la un capăt al conexiunii să trimită un mesaj „Heartbeat Request”, care constă dintr-un conținut (de regulă, un șir de caractere), împreună cu lungimea sa sub forma unui întreg pe 16 biți. Mașina care primește mesajul trebuie să trimită înapoi exact același mesaj.

Versiunile de OpenSSL afectate alocau un buffer de memorie pentru mesajul de returnat, buffer a cărui lungime se baza pe lungimea specificată în mesajul „Heartbeat request”, fără a ține cont de lungimea efectivă a conținutului real al mesajului. Din cauza lipsei unei verificări corespunzătoare a limitelor, mesajul returnat consta din mesajul cerut plus ce se întâmpla să se mai afle în bufferul de memorie alocat. Problema s-a combinat cu decizia echipei OpenSSL de a scrie propria sa versiune a rutinelor de alocare dinamică a memoriei^{⁠(en)[traduceți]} (malloc și free). Ca urmare, bufferul de memorie de dimensiuni mari returnat mașinii ce a emis cererea putea conține date din blocuri de memorie ce fuseseră anterior cerute și eliberate de OpenSSL. Aceste blocuri de memorie puteau conține date sensibile trimise utilizatorilor sau chiar cheile private utilizate de OpenSSL. În plus, utilizarea propriilor rutine de gestiune a memoriei de către OpenSSL făcea inactive măsurile de siguranță existente în unele sisteme de operare care ar fi putut detecta și neutraliza bugul.^[35]

Bugul Heartbleed este exploatat prin trimiterea unei cereri malformate de heartbeat cu un conținut mic și cu un număr mare în câmpul de lungime, pentru a determina un răspuns al serverului care să permită atacatorilor să citească până la 64K octeți din memoria serverului, memorie care fusese probabil utilizată anterior de SSL.^[36] Atacatorii puteau astfel primi date sensibile, compromițând securitatea serverului și a utilizatorilor săi. Printre datele vulnerabile se numără cheia privată principală a serverului^{⁠(en)[traduceți]},^[12][14] care ar fi putut permite atacatorilor să decripteze traficul curent sau cel stocat printr-un atac pasiv de tip man-in-the-middle (dacă serverul și clientul nu folosesc perfect forward secrecy^{⁠(en)[traduceți]}), sau printr-un atac activ man-in-the-middle dacă perfect forward secrecy este utilizat. Atacatorul nu poate controla ce date primește, întrucât OpenSSL răspunde de regulă cu bucățile de memorie pe care le-a dealocat cel mai recent.

Bugul poate dezvălui și părți necriptate din cererile și răspunsurile utilizatorilor, inclusiv date din formulare transmise prin metoda HTTP POST^{⁠(en)[traduceți]} din cererile userilor, cookie-urile de sesiune și parolele, ceea ce ar putea permite atacatorilor să deturneze identitatea^{⁠(en)[traduceți]} unui alt utilizator al serviciului.^[37] La anunț, circa 17% sau jumătate de milion de servere web securizate din Internet și certificate de autoritățile de certificare de încredere^{⁠(en)[traduceți]} erau considerate a fi vulnerabile la atacuri.^[38] Electronic Frontier Foundation,^[39] Ars Technica^{⁠(en)[traduceți]},^[40] și Bruce Schneier^[41] au catalogat bugul Heartbleed drept „catastrofal”, ultimul dându-i vulnerabilității nota 11 „pe o scară de la 1 la 10” a gravității. Editorialistul pe teme de securitate informatică de la Forbes Joseph Steinberg a descris bugul ca fiind potențial „cea mai gravă vulnerabilitate descoperită (cel puțin în termeni de impact potențial) de la începutul traficului comercial prin Internet”.^[42]

Bugul este clasificat ca „buffer over-read”,^[43] situație în care software-ul permite citirea mai multor date decât ar trebui în mod normal.^[44] Problema se poate rezolva ignorând mesajele Heartbeat Request care cer mai multe date decât este necesar în conformitate cu dimensiunile conținutului.

Versiunea 1.0.1g de OpenSSL adaugă verificări de limite pentru a preveni supracitirea bufferului. De exemplu, s-a adăugat testul

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */

în fața liniei

pl = p;

O listă completă de modificări este disponibilă la git.openssl.org Arhivat în 13 aprilie 2014, la Wayback Machine..^[45]

Deși aplicarea patch-ului (pe biblioteca OpenSSL și pe orice binare legate static^{⁠(en)[traduceți]}) rezolvă bugul, software-ul aflat în funcțiune va continua să utilizeze codul OpenSSL încărcat în memorie și afectat de bug până la repornirea fiecărei aplicații afectate, operațiune ce duce la încărcarea codului reparat. Mai mult, pentru a redobândi secretizarea și securitatea datelor private, toate aceste date trebuie înlocuite, întrucât nu se mai poate ști dacă ele au fost sau nu compromise în timpul în care a fost utilizat codul vulnerabil:^[46]

• toate perechile cheie publică-cheie privată posibil compromise trebuie regenerate,
• toate certificatele legate de aceste perechi de chei compromise trebuie revocate și înlocuite, și
• toate parolele pe serverele posibil compromise trebuie schimbate.

Sunt disponibile mai multe servicii de testare a bugului Heartbleed pe un site specificat de utilizator, între care:

• Unealtă de test Heartbleed realizată de o companie europeană de securitate IT^[47]
• Scanner pentru Heartbleed realizat de criptologul italian Filippo Valsorda^[48]
• Tester Heartbleed de la Critical Watch Heartbleed^[49]
• Modulul scanner Heartbleed de la Metasploit^{⁠(en)[traduceți][50]}
• Scannerul de servere pentru Heartbleed realizat de Rehmann^[51]
• Lookout Mobile Security^{⁠(en)[traduceți]} Heartbleed Detector, aplicație pentru Android care determină versiunea de OpenSSL de pe dispozitiv și indică dacă heartbeatul vulnerabil este activ^[52]
• Verificator de Heartbleed găzduit de LastPass^{⁠(en)[traduceți][53]}
• Scanner online de rețea pentru vulnerabilitatea Heartbleed realizat de Pentest-Tools.com ^[54]
• Scanner offline în Python realizat de Redhat „https://access.redhat.com/labs/heartbleed/heartbleed-poc.py”.  Legătură externa în |title= (ajutor)
• Qualys^{⁠(en)[traduceți]} SSL Labs' SSL Server Test care nu caută doar bugul Heartbleed, ci și alte erori de implementare SSL/TLS.
• Extensii de browser, cum ar fi Chromebleed Arhivat în 18 octombrie 2014, la Wayback Machine. și FoxBleed Arhivat în 12 octombrie 2014, la Wayback Machine..

Alte unelte de securitate au adăugat suport pentru detectarea bugului. De exemplu, Sourcefire a publicat reguli de Snort^{⁠(en)[traduceți]} pentru detectarea traficului ce exploatează Heartbleed și posibilul răspuns.^[55] Tenable Network Security^{⁠(en)[traduceți]} a scris un plugin pentru scannerul de vulnerabilități Nessus^{⁠(en)[traduceți]}, plugin ce scanează exact această vulnerabilitate.^[56]

Următoarele versiuni de OpenSSL sunt considerate vulnerabile:

• OpenSSL 1.0.2-beta
• OpenSSL 1.0.1 – OpenSSL 1.0.1f
  • Dacă nu a fost instalat un patch de sistem de operare pentru CVE-2014-0160 și care nu schimbă versiunea bibliotecii, așa cum este cazul pentru Debian (inclusiv derivatele cum ar fi Ubuntu și Linux Mint), openSUSE, FreeBSD și Red Hat Enterprise Linux, inclusiv derivatele CentOS și Amazon Linux.

Următoarele versiuni de OpenSSL includ patch-uri care repară bugul Heartbleed:

• OpenSSL 1.0.2-beta2 (nelansat încă)
• OpenSSL 1.0.1g

Pentru a rezolva bugul, administratorii de server sunt sfătuiți să utilizeze 1.0.1g sau să recompileze OpenSSL cu -DOPENSSL_NO_HEARTBEATS, dezactivând astfel funcționalitatea vulnerabilă până la actualizarea software-ului serverului.^[19]

Următoarele site-uri au servicii afectate sau au făcut aununțuri prin care recomandă utilizatorilor să-și actualizeze parolele:

• IPCop^{⁠(en)[traduceți]} 2.1.4 a fost lansat la 8 aprilie 2014 cu rezolvarea problemei pentru „biblioteca OpenSSL despre care vorbește toată lumea”.^[78]
• LastPass Password Manager^{⁠(en)[traduceți]} nu era vulnerabil, datorită utilizării forward secrecy^{⁠(en)[traduceți]}, dar a recomandat utilizatorilor să schimbe parolele stocate de LastPass pentri site-urile web vulnerabile.^[79]
• LibreOffice 4.2.3 a fost lansat la 10 aprilie 2014 cu repararea CVE-2014-0160^[80]
• LogMeIn^{⁠(en)[traduceți]} a susținut că a „actualizat numeroase produse și părți din serviciile noastre care se bazeaza pe OpenSSL”.^[81]

În ziua anunțului, 7 aprilie 2014, Tor Project^{⁠(en)[traduceți]} a publicat pe blog un anunț și a sfătuit pe oricine dorește „anonimitate și siguranță puternică a datelor personale pe Internet” să „stea departe de Internet cu totul câteva zile până se așează lucrurile”. Ei au recomandat și ca operatorii de relee Tor și cei de servicii ascunse să-și revoce și să-și genereze noi chei după ce aplică patch-ul OpenSSL, dar a atras atenția că releele Tor utilizează două seturi de chei șî că designul multi-hop pe care îl are Tor minimizează impactul exploatării unui singur releu.^[82]

Guvernul federal canadian a închis temporar serviciile online ale Canada Revenue Agency^{⁠(en)[traduceți]} (CRA) și ale mai multor departamente guvernamentale pentru problema Heartbleed^[83][84] și Canadian Cyber Incident Response Centre^{⁠(en)[traduceți]} a emis un buletin de securitate prin care îi informa pe administratorii de sistem despre bug.^[85]

Organizațiile ce gestionează platforme, cum este Fundația Wikimedia, a sfătuit utilizatorii să-și schimbe parolele.^[75] Un purtător de cuvând al cabinetului american a recomandat ca „oamenii să pună în aplicare sfatul de a-și schimba parolele de pe site-urile la care le folosesc...Majoritatea site-urilor web au corectat bugul și sunt în măsură să dea indicații.”^[86]

O analiză postată pe GitHub ale celor mai vizitate 1000 de site-uri web la 8 aprilie 2014 a relevat vulnerabilități la mai multe site-uri, inclusiv Yahoo!, Imgur, Stack Overflow, Slate^{⁠(en)[traduceți]}, și DuckDuckGo.^[87][88]

Theo de Raadt^{⁠(en)[traduceți]}, fondatorul și liderul proiectelor OpenBSD și OpenSSH^{⁠(en)[traduceți]}, a criticat dezvoltatorii OpenSSL pentru scrierea propriilor rutine de gestiune a memoriei, prin care ocoleau contramăsurile existente în biblioteca standard C^{⁠(en)[traduceți]} a sistemului OpenBSD, afirmând că „OpenSSL nu este dezvoltat de o echipă responsabilă”.^[89][35]

Autorul bugului, Robin Seggelmann,^[90] a afirmat că i-a „scăpat validarea unei variabile conținând lungimea” și a negat orice intenție de a promova o implementare defectă.^[9] Ca urmare a dezvăluirii vulnerabilității Heartbleed, Seggelmann a afirmat că OpenSSL nu este analizat de suficiente persoane.^[91]

Wikiversity are materiale didactice despre Heartbleed