Dan Kaminsky și ziua în care s-a reparat DNS-ul
În 2008, Dan Kaminsky a găsit un defect în DNS — sistemul care traduce numele de domenii în adrese IP — care permitea unui atacator să redirecționeze traficul unui domeniu întreg. Nu era o eroare într-un produs anume, ci în felul în care funcționa protocolul.
Reacția a fost la fel de neobișnuită ca descoperirea: producători concurenți au reparat problema în secret, împreună, și au lansat patch-urile în aceeași zi. Kaminsky a murit în 2021, la 42 de ani. Ce a lăsat în urmă e mai mult decât un CVE.
Ce era, de fapt, otrăvirea cache-ului DNS
Când browserul tău cere adresa unui site, întrebarea ajunge la un resolver — un server care caută răspunsul și îl păstrează în cache pentru următorii care întreabă. Dacă cineva reușește să strecoare un răspuns fals în acel cache, toți utilizatorii resolverului ajung unde vrea atacatorul, deși au tastat adresa corectă.
Singura protecție reală era un identificator de tranzacție de 16 biți: 65.536 de valori posibile, pe care atacatorul trebuia să le ghicească. Nu foarte multe, dar suficiente cât timp aveai o singură încercare.
Și aici era limitarea cunoscută: dacă ratai, răspunsul corect intra în cache și rămânea acolo până expira. Trebuia să aștepți, uneori ore. Asta făcea atacul teoretic interesant și practic neinteresant.
Ideea care a schimbat totul: întreabă de subdomenii care nu există
Kaminsky a observat că nimeni nu te obligă să întrebi de numele pe care vrei să-l otrăvești. Poți întreba de un subdomeniu inventat — ceva aleatoriu, care sigur nu e în cache. Resolverul e obligat să plece să caute, iar tu ai o fereastră de atac proaspătă.
Ratezi? Inventezi alt subdomeniu și încerci din nou. Nu mai aștepți nimic. Limitarea care făcea atacul impracticabil dispăruse.
Al doilea element era la fel de important: în răspunsul fals nu injectai doar adresa subdomeniului inventat, ci și informația despre care server e autoritatea pentru domeniul întreg. Nu otrăveai o intrare, ci preluai domeniul.
Combinate, cele două idei transformau un atac de laborator în ceva ce se putea executa în secunde. Iar defectul nu era într-o implementare, ci în protocol: îi afecta pe toți deodată.
Patch-ul din 8 iulie 2008
Kaminsky lucra la IOActive, ca director de teste de penetrare. În loc să publice, a făcut ceva ce se întâmplă rar: a strâns producătorii la aceeași masă. În martie 2008 a avut loc o întâlnire discretă la sediul Microsoft, cu reprezentanți ai companiilor care, în restul timpului, concurau între ele.
Pe 8 iulie 2008 au lansat patch-urile simultan. Kaminsky a cerut public celorlalți cercetători un răgaz de treizeci de zile înainte de a specula asupra detaliilor, ca administratorii să apuce să actualizeze. Urma să prezinte totul la Black Hat, în august.
Răgazul nu a ținut. Detaliile au apărut public înainte de termen, iar de acolo până la cod de exploatare funcțional au trecut zile, nu săptămâni. Lecția a rămas în manuale: dezvăluirea coordonată cumpără timp, dar mai puțin decât speră toată lumea, iar planul trebuie să presupună scurgerea, nu tăcerea.
Ce a reparat patch-ul și ce nu
Soluția a fost aleatorizarea portului sursă. Pe lângă cei 16 biți ai identificatorului de tranzacție, resolverul folosește de atunci un port sursă imprevizibil, ceea ce ridică efortul de ghicire de la zeci de mii de încercări la ordine de mărime mai mari.
E important cum a fost prezentată această soluție chiar de la început: ca măsură de atenuare, nu ca reparație. Ghicitul devine impracticabil, dar rămâne posibil. Singurul răspuns complet la problemă era DNSSEC, care semnează criptografic răspunsurile, astfel încât unul fals să poată fi respins indiferent cât de bine e ghicit.
Asta e o distincție pe care merită să o păstrezi și în propriile decizii: o măsură care ridică suficient costul unui atac e adesea tot ce poți livra în ziua respectivă, dar nu e același lucru cu a rezolva problema. Confuzia dintre cele două e felul în care organizațiile ajung să creadă că au închis ceva ce doar au îngreunat.
Restul moștenirii
Firul comun nu e DNS-ul. E obiceiul de a măsura ce se întâmplă cu adevărat în lume, în loc de a raționa despre ce ar trebui să se întâmple.
- ▸În 2005 a atras atenția asupra gravității rootkit-ului Sony BMG, măsurându-i răspândirea reală în loc să dezbată principii
- ▸În 2010, ICANN l-a desemnat unul dintre reprezentanții comunității de încredere pentru rădăcina DNSSEC — oamenii cu rol ceremonial în gestionarea cheilor care ancorează încrederea în DNS
- ▸A fost cofondator și cercetător-șef la White Ops, azi HUMAN Security, companie axată pe detecția fraudei automate și a boților
- ▸A lucrat anterior la Cisco, Avaya și IOActive
Omul, nu doar cercetătorul
Dan Kaminsky s-a născut pe 7 februarie 1979 la San Francisco și a murit pe 23 aprilie 2021, la 42 de ani, din cauza cetoacidozei diabetice.
Ce au evocat cel mai des colegii după moartea lui nu au fost descoperirile, ci disponibilitatea: vorbea cu oricine, plătea din buzunar taxele de participare ale unor cercetători tineri la conferințe și îi lăsa să doarmă pe podeaua camerei lui de hotel.
Merită spus într-un articol tehnic, pentru că securitatea e un domeniu în care cunoașterea circulă prin oameni dispuși să o dea mai departe. Un defect de protocol se repară cu un patch. Un domeniu în care nimeni nu explică nimănui nimic nu se repară deloc.
Ce rămâne valabil pentru tine
- ▸Defectele de protocol nu apar în inventarul tău de produse, dar te afectează prin fiecare produs care implementează protocolul
- ▸Verifică dacă rezolvarea pe care ai aplicat-o e o reparație sau o atenuare — și scrie undeva care dintre ele e
- ▸Un plan de dezvăluire coordonată trebuie să presupună că detaliile se scurg înainte de termen
- ▸Fereastra dintre patch și exploatare se măsoară în zile; procesul tău de actualizare trebuie dimensionat pentru acea fereastră, nu pentru ciclul trimestrial
- ▸DNSSEC, pentru domeniile pe care le deții, e încă răspunsul complet la această clasă de atac — și încă e departe de a fi universal
Defectele de protocol te ating prin fiecare produs
Awarely Monitor agregă NVD, CISA KEV, EUVD și GitHub la fiecare două ore și îți arată, pe inventarul tău, care versiuni sunt efectiv afectate — nu o listă generică de CVE-uri.