Pentru că nu prea am cum să ocolesc evenimentul, nu am încotro și voi vorbi și eu de heartbleed. Pare a fi printre cele mai mari probleme de securitate întâmplate până acum, nu ca vulnerabilitate în sine, ci ca anvergură și ca implicații.
Să o luăm incetișor. Pe 7 aprile apare știrea că un bug în suita openssl afectează mai multe versiuni ale acesteia. Suita openssl este o bibliotecă folosită pentru criptarea datelor de către majoritatea aplicațiilor care rulează pe sistemele de tip Unix și nu numai: servere de web, de mail și tot ce mai necesită criptare. Lucruri din astea se mai întâmplă; programatorii sunt oameni și fac și ei greșeli, ca noi toți. Problema este că acest bug a fost introdus în 2011 în suita openssl, cu ocazia adăugării unor noi funcționalități și afectează toate versiunile apărute până în acest an. Mai rău este că prin intermediul lui se poate citi o porțiune din memoria serverului care nu ar trebui să poată fi citită. Acest lucru nu lasă urme vizibile pe server, cu alte cuvinte dacă din 2011 și până astăzi o persoană ar fi cunoscut acest bug, ar fi putut să îl folosească fără a fi identificat.
Nu știm precis cum ar putea fi exploatată această vulnerabilitate; în teorie probabil că prin intermediul ei s-ar putea citi în final datele de pe server. Cel mai probabil însă ar fi că s-ar putea citi cheia privată corespunzătoare certificatului public cu care se face criptarea.
O scurtă și simplistă teorie: la criptarea, să îi zicem de secol 19, textul de transmis este criptat folosind o anumită cheie, un cifru. Pentru a fi decriptat, destinatarul trebuie să cunoască acest cifru ( presupunănd că algoritmul este cunoscut). Aceasta ar fi criptarea simetrică, și are ca dezavantaj faptul că trebuie să transmitem cumva corespondentului cheia de criptare. Dacă “inamicul” o interceptează, poate citi mesajul.
Securitatea serverelor folosește o altă abordare, cu două chei, criptare asimetrică ( se folosește și cea simetrică, dar nu despre asta discutăm aici). Ideea e următoarea: am o cheie de criptare și una de decriptare; pe cea de criptare o fac publică: dacă cineva are să îmi transmită un mesaj, îl criptează cu aceasta, dar decriptarea lui se face cu cea privată, pe care o păstrez cât pot de bine. În felul ăsta nu mai am problema transmiterii cheii, pentru că cea publică singură nu folosește la decriptare.
Deci în cazul nostru cineva care a putut să ne copieze cheia privată va putea să decripteze conversația, ba, mai rău, ar putea să construiască un site fals care să semene leit cu al nostru și să fie validat de certificatul nostru ( nu intru în detalii despre autoritățile de certificare, ideea e că în general certificatele sunt emise de un fel de “notariate electronice” care în felul ăsta autentifică faptul că site-ul este cel care pretinde că este).
În atmosfera post-Snowden, există speculații că un astfel de bug ar putea fi “plantat”; de fapt știm numele “autorului”: Robin Seggelmann, unul din programatorii care participă la acest proiect, pentru că este vorba de un proiect open source, deci toate modificările sunt accesibile.
Plantat sau nu însă, vorbind de cod open-source, oricine ( cu preocupări în domeniu) ar putea să se uite pe cod. Deci probabil că dacă un serviciu secret nu a știut de el, criptanaliștii acestuia ar trebui concediați. Tocmai de aici vine perplexitatea întregii lumi IT: problema e veche, dar aparent nu a fost observată de nimeni, cel puțin din partea “bună” a baricadei. Explicabil în prima fază ( upload-ul inițial a fost în preajma Anului Nou, dacă nu cumva și asta e suspect) dar se pare că ulterior nimeni nu l-a mai analizat. Ideea că softul open source este mai bun pentru că mai mulți ochi se uită pe el primește o serioasă lovitură.
Realitatea este că anumite zone sunt mult prea specializate pentru ca teoria să functioneze, iar criptografia este unul dintre ele. Aparatul matematic este complex, algoritmii sunt mulți și complicați și ei, încât în general prea puțini pot să analizeze pertinent codul, mai ales atunci când funcționează. Pentru că în acest caz, programul funcționa. Dacă ar fi produs blocaje sau alte neplăceri, probabil că ar fi fost de mult descoperit. Nu întămplător bug-ul a fost decoperit de o echipă care lucra la o soluție de teste de securitate ; probabil printre puținii care au supus programul la teste aprofundate.
Ce ar mai putea fi spus? In teorie știm că trebuie să ne așteptăm ca datele noastre să fie vulnerabile. În practică însă, eram obișnuiți ca exploit-urile să fie limitate ca amploare sau anvergură. Cazul acesta ne readuce cu picioarele pe pământ.
Dumneavoastra spuneti:
„Să o luăm incetișor. Pe 7 aprile apare știrea că un bug în suita openssl afectează mai multe versiuni ale acesteia. Suita openssl este o bibliotecă folosită pentru criptarea datelor de către majoritatea aplicațiilor care rulează pe sistemele de tip Unix și nu numai: servere de web, de mail și tot ce mai necesită criptare.”
Daca s-ar folosi cheia de descifrare on19, dar cu aplicatie directa in textul dumneavoastra citat on7, ar rezulta transmiterea datelor in felul urmator:
1 a1c2d2d5. 1 b1c4. 1 d2b2d9c4a2c1. 1 d3d4d2 2 l8 1 c2d9a2d7.
Ori de aici ar rezulta o decriptare foarte dificil de rezolvat fara on23, putin cunoscuta.
Nu cred ca avem de ce sa ne temem!
puteti fi mai putin… criptic? :)
Dumneavoastra spuneti:
„Nu știm precis cum ar putea fi exploatată această vulnerabilitate; în teorie probabil că prin intermediul ei s-ar putea citi în final datele de pe server. Cel mai probabil însă ar fi că s-ar putea citi cheia privată corespunzătoare certificatului public cu care se face criptarea.”
De asemenea, paragraful urmator din textul dumneavoastra este revelator pentru „decriptarea” de care vorbiti in raspunsul dumneavoastra. Cele doua chei se afla in textul initial. (in mo normal, una care v-ar apartine si una care mi-ar apartine). Depinde de dumneavoastra daca le vedeti. Cititi cu atentie.
Sper sa fie de folos raspunsul meu.
Cateva, probabil, scapari in text:
– certificat privat – asa ceva nu exista
– criptanalistii care trebuia sa descopere bug-ul – nu are nicio treaba povestea asta cu criptologia.
Merci pentru „bug-ul” descoperit; in continuarea textului este explicata legatura intre cheie si certificat, dar acolo mi-a scapat. Am corectat.
In ceea ce priveste „criptanalistii” : am folosit o denumire generica; sunt sigur ca serviciile care se respecta au departamente specializate, iar openssl este soft open-source, deci as zice ca daca nu au o obligatie legala sa se uite pe cod, macar o sarcina de serviciu ar trebui sa aiba. Ce e drept, nu stiu cum s-ar putea numi acest departament, dar zic ca e clar la ce ma refer :)
Un „cautator de bug-uri” serios nu are nevoie de codul sursa pentru a gasi problemele de securitate.
Uitati-va la istoria lunga si insingerata a programelor scrise de Microsoft. Nimic din ce au scris ei nu a fost publicat sub forma de cod sursa (au fost niste scapari dar ele sint irelevante), insa autorii de malware a fost intotdeauna cu citiva pasi inaintea celor care se chinuiau sa protejeze utilizatorii.
E adevarat, dar daca tot ai acces la codul sursa de ce te-ai complica?