Omul care a găsit un bug în internetul însuși: Dan Kaminsky, otrăvirea cache-ului DNS și remedierea care a avut nevoie de lumea întreagă

Fiecare site pe care îl vizitezi, fiecare email pe care îl trimiți, fiecare actualizare pe care o descarcă sistemele tale începe cu aceeași întrebare: ce adresă IP aparține acestui nume? Domain Name System răspunde, de miliarde de ori pe secundă, iar aproape nimic din felul în care folosim internetul nu funcționează dacă acelui răspuns nu i se poate acorda încredere.

În 2008, un cercetător pe nume Dan Kaminsky și-a dat seama că răspunsului nu i se putea acorda încredere. Ce a făcut mai departe e motivul pentru care majoritatea oamenilor nu au fost nevoiți niciodată să se gândească la asta.

Ce a fost, de fapt, Kaminsky Bug

Resolverele DNS potrivesc răspunsurile cu cererile folosind un ID de tranzacție și un port sursă. Problema identificată de Kaminsky era că aceste valori erau, în practică, previzibile — iar câmpul ID de tranzacție permitea doar 65.536 de valori posibile. Un atacator care putea ghici combinația corectă suficient de repede obținea acceptarea unui răspuns falsificat înaintea celui legitim, iar resolverul păstra acea minciună în cache și o servea tuturor celor din spatele lui.

Otrăvirea cache-ului era cunoscută înainte de 2008. Ce a găsit Kaminsky a fost o tehnică ce o făcea fiabilă și repetabilă, nu o chestiune de noroc, și care se aplica practic oricărui resolver aflat în uz. Internet Hall of Fame rezumă consecințele fără ocolișuri: defectul le-ar fi permis atacatorilor să intercepteze emailuri, să ocolească autentificarea prin parolă și să impersoneze site-uri web.

Gândește-te ce înseamnă asta practic. Otrăvești resolverul folosit de banca ta și clienții ei ajung pe serverul tău, în timp ce bara de adrese arată corect. Otrăvești un resolver de care depinde mecanismul de actualizare al unui producător de software și îți distribui propriul cod drept patch-ul lui. Nu era o vulnerabilitate într-un produs. Era o vulnerabilitate într-o presupunere comună.

Partea cu adevărat grea: să nu spui nimănui

Un cercetător care găsește ceva de o asemenea magnitudine are la dispoziție o cale evidentă: publici, prezinți la marile conferințe, ești celebru până în weekend. Kaminsky a ales-o pe cealaltă.

A dezvăluit discret unui cerc restrâns de lideri din DNS și securitate și Departamentului american pentru Securitate Internă. A fost convocată o întâlnire confidențială la sediul Microsoft, cu Kaminsky conducând efortul, adunând organizații care concurează comercial în orice alt context — între ele ISC, Microsoft, Cisco, Red Hat și mari furnizori de internet — pentru a construi o remediere care putea fi livrată peste tot deodată.

Pe 8 iulie 2008 a fost lansat un patch sincronizat multi-vendor. Implementarea pe resolverele din întreaga lume a urmat în lunile următoare. Kaminsky a păstrat detaliile tehnice pentru a le da operatorilor un avans, iar acestea au devenit publice abia după ce patch-ul circulase pe scară largă.

E un lucru mai greu decât sună. A cerut convingerea unor rivali să se coordoneze, păstrarea unui secret cunoscut de zeci de oameni, rezistența în fața stimulentului profesional de a publica primul și acceptarea scepticismului celor care voiau dovezi înainte de a acționa. Modelul de dezvăluire coordonată care a urmat — notificare discretă, patch sincronizat, detalii tehnice amânate — a devenit un șablon pentru tratarea defectelor de protocol la scară largă și e motivul pentru care aceeași abordare e astăzi așteptată, nu remarcabilă.

Iar remedierea a fost, într-un sens, un workaround

Patch-ul din 2008 a făcut atacul mult mai greu prin randomizarea porturilor sursă, crescând dramatic numărul de valori pe care un atacator trebuie să le ghicească. Nu a făcut răspunsurile verificabile. DNS tot nu avea cum să demonstreze că un răspuns venea într-adevăr de la sursa autoritativă.

Kaminsky a înțeles asta și a petrecut ani promovând un DNS semnat criptografic. Acea pledoarie a contribuit la semnarea zonei rădăcină DNS în 2010 — fundamentul DNSSEC și diferența dintre „a ghici e greu" și „falsificarea e detectabilă".

Restul muncii

Firul comun merită numit. În fiecare caz, munca tehnică a fost în slujba măsurării sau protejării unor oameni care nu erau în încăpere — clienți care nu știau ce li se instalase, utilizatori care nu-și dădeau seama că sunt infectați, pacienți fără acces la îngrijire.

• Rootkit-ul Sony BMG: Kaminsky a folosit tehnici de măsurare DNS pentru a demonstra amploarea software-ului ascuns pe care Sony îl instalase pe calculatoarele clienților, arătându-l pe circa 500.000 de sisteme — transformând povestea unei decizii proaste a unei companii într-un prejudiciu documentat și măsurat
• Conficker: a contribuit la dezvoltarea tehnologiei de scanare pentru detectarea viermelui care compromisese milioane de sisteme și era notoriu de greu de identificat de la distanță
• Dincolo de securitate, a construit aplicații de accesibilitate pentru persoanele daltoniste și instrumente de telemedicină pentru refugiați
• A fost inclus în Internet Hall of Fame în 2021, postum. A murit la 42 de ani

De ce contează și în 2026

DNS rămâne o țintă. Campania CaptiveCrunch despre care am scris luna aceasta funcționează manipulând DNS-ul pe routere compromise, astfel încât călătorii aflați pe Wi-Fi-ul hotelurilor să fie direcționați către infrastructura atacatorilor — alt mecanism, aceeași pradă de fond. Cine e tentat să claseze securitatea DNS drept problemă rezolvată a anilor 2000 ar trebui să recitească fraza.

Norma dezvăluirii coordonate pe care Kaminsky a ajutat-o să se impună e și ea vizibil vie. Incidentele din evaluările AI dezvăluite de Anthropic, AI Security Institute din Marea Britanie și Meta în ultimele două săptămâni au urmat exact acel tipar: notifici părțile afectate, te coordonezi cu platformele implicate, publici odată ce remedierea e în curs. Acele organizații au ales să arate prost repede, pentru ca toți ceilalți să învețe ceva — același schimb pe care l-a făcut Kaminsky în 2008.

Și mai există un contrast care merită lăsat să lucreze. Celălalt articol pe care l-am publicat astăzi privește o vulnerabilitate WordPress găsită de un sistem autonom multi-agent în aproximativ patru zile. Descoperirea se industrializează. Coordonarea nu se industrializează și nici nu poate — a decide cui spui, în ce ordine și când devii public rămâne o judecată făcută de oameni cu reputații și interese.

Ce poate lua o echipă de securitate din asta

Ultimul punct ține de cultură, nu de tehnologie, și e partea care se degradează fără întreținere. Awarely Learning o construiește deliberat — awareness bazat pe scenarii în română și engleză, simulări de phishing și inginerie socială, teste, certificate verificabile și un audit trail imutabil care satisface obligația de training din NIS2, prin OUG 155/2024, producând în același timp ceva mai util decât conformitatea: oameni care vorbesc devreme.

• Știi unde se face rezoluția ta. În ce resolvere au încredere sistemele tale, sunt ale tale și ai observa dacă răspunsurile lor s-ar schimba?
• Tratează DNS-ul ca pe un control de securitate, nu ca pe o instalație — validare DNSSEC acolo unde poți, monitorizarea schimbărilor de rezoluție și alerte pentru modificări neașteptate de NS sau de configurare DNS
• Ai o politică de dezvăluire înainte să ai nevoie de ea. Dacă un cercetător te contactează despre un defect, prima oră a răspunsului tău decide dacă lucrează cu tine sau pe lângă tine
• Construiește relațiile din timp. Kaminsky a putut convoca acea încăpere pentru că oamenii știau deja cine e. Echivalentul tău e să-ți cunoști CSIRT-ul, furnizorii-cheie și autoritatea de reglementare înainte de un incident, nu în timpul lui
• Recompensează persoana care raportează discret. Orice organizație spune că își dorește dezvăluiri; cele care le primesc sunt acelea în care raportarea nu a fost niciodată pedepsită