Dezvăluirea completă sau responsabilă: modul în care sunt dezvăluite vulnerabilitățile de securitate

Publicitate

Acum trei saptamani, o problemă serioasă de securitate în OS X 10.10.4 a fost descoperită. Acest lucru, în sine, nu este deosebit de interesant.

Sunt descoperite vulnerabilitățile de securitate în pachetele software populare tot timpul, iar OS X nu face excepție. Baza de date a vulnerabilității Open Source (OSVDB) arată cel puțin 1100 vulnerabilități etichetate drept „OS X”. Dar ce este interesant este modul în care a fost dezvăluită această particulară vulnerabilitate.

În loc să-i spună Apple și să le acorde timp să remedieze problema, cercetătorul a decis să-și posteze exploit-ul pe internet pentru ca toată lumea să-l vadă.

Rezultatul final a fost o cursă de arme între hackerii Apple și hat-black. Apple a trebuit să elibereze un plasture înainte ca vulnerabilitatea să fie armată, iar hackerii au trebuit să creeze o exploatare înainte ca sistemele cu risc să se implice.

S-ar putea să credeți că o anumită metodă de dezvăluire este iresponsabilă. Ai putea chiar să-l numești etic sau nechibzuit. Dar este mai complicat de atât. Bine ați venit în lumea ciudată, confuză, a dezvăluirii vulnerabilității.

Dezvăluirea completă vs.

Există două moduri populare de dezvăluire a vulnerabilităților furnizorilor de software.

Primul este numit dezvăluirea completă. La fel ca în exemplul precedent, cercetătorii își publică imediat vulnerabilitatea în sălbăticie, oferind vânzătorilor absolut nicio ocazie de a elibera o soluție.

Al doilea este numit divulgarea responsabilăsau dezvăluirea eșalonată. Acesta este locul în care cercetătorul contactează vânzătorul înainte de eliberarea vulnerabilității.

Ambele părți convin apoi asupra unui interval de timp în care cercetătorul promite să nu publice vulnerabilitatea, pentru a oferi vânzătorului posibilitatea de a construi și elibera o soluție. Această perioadă de timp poate fi oriunde de la 30 de zile la un an, în funcție de gravitatea și complexitatea vulnerabilității. Unele găuri de securitate nu pot fi fixate cu ușurință și necesită reconstruirea de la zero a sistemelor software complete.

Odată ce ambele părți sunt satisfăcute de soluția care a fost produsă, vulnerabilitatea este apoi dezvăluită și este dată o Numărul CVE. Acestea identifică în mod unic fiecare vulnerabilitate, iar vulnerabilitatea este arhivată online pe OSVDB.

Dar ce se întâmplă dacă timpul de așteptare expiră? Ei bine, unul din cele două lucruri. Vânzătorul va negocia apoi o extindere cu cercetătorul. Dar, dacă cercetătorul este nemulțumit de modul în care vânzătorul a răspuns sau s-a comportat, sau consideră că solicitarea unei prelungiri este lipsită de rezonabilitate, ar putea pur și simplu să o publice online, fără a fi gata.

În domeniul securității, există dezbateri aprinse cu privire la ce metodă de divulgare este cea mai bună. Unii consideră că singura metodă etică și precisă este divulgarea completă. Unii consideră că este mai bine să oferiți vânzătorilor oportunitatea de a rezolva o problemă înainte de a o elibera în sălbăticie.

După cum se dovedește, există câteva argumente convingătoare pentru ambele părți.

Argumentele în favoarea divulgării responsabile

Haideți să aruncăm un exemplu despre locul în care a fost cel mai bine să folosiți divulgarea responsabilă.

Când vorbim despre infrastructură critică în contextul internetului, este greu de evitat să vorbim protocolul DNS Cum să vă schimbați serverele DNS și să îmbunătățiți securitatea internetuluiImaginează-ți acest lucru - te trezești o dimineață frumoasă, toarnă-ți o ceașcă de cafea și apoi stai la computer pentru a începe cu munca ta pentru toată ziua. Înainte de a primi efectiv ... Citeste mai mult . Aceasta ne permite să traducem adrese web care pot fi citite de oameni (cum ar fi makeuseof.com) în adrese IP.

Sistemul DNS este incredibil de complicat și nu doar la nivel tehnic. Există multă încredere în acest sistem. Avem încredere că atunci când introducem o adresă web, am fost trimiși la locul potrivit. Pur și simplu se bazează foarte mult pe integritatea acestui sistem.

Dacă cineva a putut să intervină sau să compromită o solicitare DNS, există multe potențiale de daune. De exemplu, aceștia ar putea trimite persoane către pagini bancare online frauduloase, permițându-le astfel să obțină detaliile bancare online. Aceștia își puteau intercepta mesajele de e-mail și traficul online printr-un atac în mijloc și pot citi conținutul. Aceștia ar putea submina fundamental securitatea Internetului în ansamblu. Lucruri înfricoșătoare.

Dan Kaminsky este un cercetător de securitate bine respectat, cu un CV lung de găsire a vulnerabilităților în software-ul bine cunoscut. Dar este cel mai cunoscut pentru descoperirea, probabil, din 2008 vulnerabilitatea cea mai severă în sistemul DNS găsit vreodată. Acest lucru ar fi permis cuiva să efectueze cu ușurință un intoxicații cu cache (sau spoofing DNS) atac pe un server de nume DNS. Detaliile mai tehnice ale acestei vulnerabilități au fost explicate la conferința Def Con 2008.

Kaminsky, conștient de consecințele declanșării unui defect atât de sever, a decis să-l dezvăluie furnizorilor de software DNS care sunt afectate de acest bug.

Au fost afectate o serie de produse DNS majore, inclusiv cele construite de Alcatel-Lucent, BlueCoat Technologies, Apple și Cisco. Problema a afectat, de asemenea, o serie de implementări DNS livrate cu unele distribuții Linux / BSD populare, inclusiv cele pentru Debian, Arch, Gentoo și FreeBSD.

Kaminsky le-a dat 150 de zile pentru a produce o soluție și a lucrat cu ei în secret pentru a-i ajuta să înțeleagă vulnerabilitatea. Știa că această problemă era atât de severă și că daunele potențiale sunt atât de mari, încât ar fi fost incredibil de imprudent pentru a-l elibera public, fără a oferi vânzătorilor posibilitatea de a emite un plasture.

De altfel, vulnerabilitatea a fost scurs din accident de firma de pază Matsano într-o postare pe blog. Articolul a fost dat jos, dar a fost oglindit și la o zi după publicare o exploatare Acesta este modul în care vă hackhează: The Murky World of Exploit KitsScamatorii pot folosi apartamente software pentru a exploata vulnerabilitățile și a crea malware. Dar ce sunt aceste truse de exploatare? De unde vin ei? Și cum pot fi opriți? Citeste mai mult fusese creat.

Vulnerabilitatea DNS a lui Kaminsky rezumă în cele din urmă la elementul principal al argumentului în favoarea divulgării responsabile și eșalonate. Unele vulnerabilități - cum ar fi vulnerabilități de zero zile Ce este o vulnerabilitate Zero Day? [FaceUseOf Explică] Citeste mai mult - sunt atât de importante, încât eliberarea publică ar provoca pagube semnificative.

Dar există și un argument convingător în favoarea de a nu da un avertisment în avans.

Cazul pentru dezvăluirea completă

Prin eliberarea unei vulnerabilități în aer liber, deblocați o casetă a pandorei, în cazul în care persoanele defavorabile sunt capabile să producă rapid și ușor exploitări și să compromită sistemele vulnerabile. Deci, de ce ar alege cineva să facă asta?

Există câteva motive. În primul rând, vânzătorii sunt adesea destul de lent pentru a răspunde la notificările de securitate. Prin forțarea eficientă a mâinii prin eliberarea unei vulnerabilități în sălbăticie, sunt mai motivați să răspundă rapid. Și mai rău, unii sunt înclinați a nu face publicitate De ce companiile care păstrează secretul încălcărilor ar putea fi un lucru bunCu atât de multe informații online, cu toții ne îngrijorează eventualele încălcări ale securității. Dar aceste încălcări ar putea fi păstrate secrete în SUA pentru a vă proteja. Sună nebun, deci ce se întâmplă? Citeste mai mult faptul că transportau software vulnerabil. Dezvăluirea completă îi obligă să fie sinceri cu clienții lor.

Dar permite, de asemenea, consumatorilor să aleagă în cunoștință de cauză dacă doresc să continue să folosească un anumit software vulnerabil. Mi-aș imagina că majoritatea nu ar fi.

Ce vor vânzătorii?

Vânzătorii le place cu adevărat dezvăluirea completă.

La urma urmei, este un PR incredibil de rău pentru ei și își pune clienții în pericol. Ei au încercat să încurajeze oamenii să dezvăluie în mod responsabil vulnerabilitățile, deși programele de recompense pentru bug-uri. Acestea au avut un succes remarcabil, Google plătind 1,3 milioane de dolari doar în 2014.

Deși merită să subliniem că unele companii - ca Oracle Oracle dorește să nu mai trimiteți bug-uri - Iată de ce asta este nebunOracle se află în apă fierbinte peste un post de blog greșit de către șefa de securitate, Mary Davidson. Această demonstrație a modului în care filosofia de securitate Oracle se îndepărtează de mainstream nu a fost bine primită în comunitatea de securitate ... Citeste mai mult - descurajează oamenii să efectueze cercetări de securitate pe software-ul lor.

Dar vor fi în continuare oameni care insistă să folosească divulgarea deplină, fie din motive filozofice, fie pentru propriul lor amuzament. Niciun program de recompense pentru bug, oricât de generos nu poate contracara acest lucru.