Dezvăluirea completă sau responsabilă Cum sunt dezvăluite vulnerabilitățile de securitate

Acum trei săptămâni, a fost descoperită o problemă serioasă de securitate în OS X 10.10.4. Aceasta, în sine, nu este deosebit de interesant.

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

Mai degrabă decât să le spună Apple și să le dea timp pentru a remedia problema, cercetătorul a decis să posteze exploatarea pe Internet pentru toată lumea să vadă.

Rezultatul final a fost o cursă de arme între Apple și pălăriile de hackeri. Apple a trebuit să elibereze un patch înainte ca vulnerabilitatea să fie armată și hackerii trebuiau să creeze un exploit înainte ca sistemele la risc să fie patch-uri.

S-ar putea să vă gândiți că metoda particulară de dezvăluire este iresponsabilă. Ați putea chiar să-l numiți neetic sau nesăbuit. Dar este mai complicat decât asta. Bine ați venit în lumea ciudată, confuză a dezvăluirii vulnerabilităților.

Dezvăluirea integrală și responsabilă

Există două modalități populare de a divulga vulnerabilitățile furnizorilor de software.

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

Al doilea este numit divulgarea responsabilității, sau divulgarea eșalonată. Acesta este locul în care cercetătorul contactează furnizorul înainte ca vulnerabilitatea să fie lansată.

Ambele părți sunt de acord 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 a lansa o soluție. Această perioadă de timp poate fi oriunde între 30 de zile și 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 completă a sistemelor software de la zero.

Odată ce ambele părți sunt mulțumite de soluția care a fost produsă, vulnerabilitatea este apoi dezvăluită și primită un număr 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. Furnizorul va negocia o extensie cu cercetătorul. Dar dacă cercetătorul nu este mulțumit de modul în care vânzătorul a răspuns sau sa comportat sau simte că cererea pentru o extensie este nerezonabilă, ei ar putea să-l publice doar online, fără să fie pregătit.

Î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ă le ofere furnizorilor posibilitatea de a rezolva o problemă înainte de ao elibera în sălbăticie.

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

Argumentele în favoarea dezvăluirii responsabile

Să aruncăm o privire asupra unui exemplu în care ar fi mai bine să folosim divulgarea responsabilă.

Când vorbim despre infrastructura critică în contextul Internetului, este greu să eviți să vorbești despre protocolul DNS Cum să-ți schimbi serverele DNS și să îmbunătățești securitatea pe Internet Cum să-ți schimbi serverele DNS și să îmbunătățești securitatea pe Internet Imaginează-ți - te trezești într-o frumoasă dimineață, turnați-vă o ceașcă de cafea și apoi așezați-vă la computer pentru a începe munca cu ziua. Înainte de a obține de fapt ... Citește mai mult. Aceasta este ceea ce ne permite să traducem adrese de web care pot fi citite de om (precum makeuseof.com) în adrese IP.

Sistemul DNS este incredibil de complicat și nu doar la nivel tehnic. În acest sistem există o mare încredere. Avem încredere că atunci când tastăm o adresă web, suntem trimisi la locul potrivit. Există pur și simplu o mulțime de echitatie asupra integrității acestui sistem.

Dacă cineva a fost capabil să interfereze cu, sau să compromită o solicitare DNS, există o mare posibilitate de deteriorare. De exemplu, aceștia ar putea trimite persoane către pagini bancare online frauduloase, permițându-le astfel să obțină detaliile lor bancare online. Ei puteau intercepta e-mail-ul și traficul lor online printr-un atac de tip man-in-the-middle și citeau conținutul. Ele ar putea submina în mod fundamental securitatea internetului în ansamblu. Lucruri înfricoșătoare.

Dan Kaminsky este un cercetător de securitate bine respectat, cu un rezumat lung de identificare a vulnerabilităților în software bine-cunoscut. Dar este cel mai bine cunoscut pentru descoperirea din 2008 a vulnerabilității celei mai grave din sistemul DNS găsit vreodată. Acest lucru ar fi permis unei persoane să efectueze cu ușurință un atac de intoxicare în cache (sau un spoofing DNS) pe un server de nume DNS. Cele mai multe detalii tehnice ale acestei vulnerabilități au fost explicate la conferința Def Con 2008.

Kaminsky, conștient de consecințele eliberării unui astfel de defect grav, a decis să-l dezvăluie vânzătorilor software-ului DNS care sunt afectați 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 care au fost livrate cu unele distribuții populare Linux / BSD, 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 le ajuta să înțeleagă vulnerabilitatea. El știa că această problemă era atât de gravă, iar pagubele potențiale atât de mari încât ar fi fost incredibil de nepăsător să-l elibereze public fără a oferi vânzătorilor posibilitatea de a emite un patch.

De altfel, vulnerabilitatea a fost scurgată accidental de firma de securitate Matsano într-un post de blog. Articolul a fost scos, dar a fost oglindită și, la o zi după publicarea unui exploit, acesta este modul în care te hack: Lumea murdară a seturilor de exploatare Acesta este modul în care te hack: Lumea murdară a kiturilor de exploatare Scammerii pot folosi suite de software pentru a să exploateze vulnerabilitățile și să creeze programe malware. Dar care sunt aceste kituri de exploatare? De unde vin ei? Și cum pot fi opriți? Citește mai mult a fost creat.

Vulnerabilitatea DNS a lui Kaminsky însumează, în cele din urmă, esența argumentului în favoarea divulgării responsabile și eșalonate. Unele vulnerabilități - cum ar fi vulnerabilitățile zilei zero Ce este o vulnerabilitate Zero Ziua? [Explicarea MakeUseOf] Ce este o vulnerabilitate Zero Ziua? [Explicarea MakeUseOf] Citește mai mult - sunt atât de semnificative, încât eliberarea publică a acestora ar cauza pagube semnificative.

Dar există și un argument convingător în favoarea faptului că nu se avertizează în avans.

Cazul pentru dezvăluirea completă

Prin eliberarea unei vulnerabilități în aer liber, deblocați o cutie a unei pandore unde indivizii necuviinci sunt capabili să producă rapid și ușor exploată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 lenți pentru a răspunde la notificările de securitate. Prin forțarea efectivă a mâinii prin eliberarea unei vulnerabilități în sălbăticie, ei sunt mai motivați să răspundă repede. Chiar mai rău, unii sunt înclinați să nu facă publicitate De ce companiile care încalcă un secret ar putea fi un lucru bun De ce companiile care păstrează încălcări un secret ar putea fi un lucru bun Cu atât de multe informații online, ne îngrijorează cu toții despre posibile încălcări ale securității. Dar aceste încălcări ar putea fi păstrate în secret în SUA pentru a vă proteja. Sună nebun, deci ce se întâmplă? Citiți mai multe despre faptul că livrează software vulnerabil. Informarea completă le obligă să fie cinstiți cu clienții lor.

Aparent @PepsiCo nu le pasă de un vuln în site-ul lor, nu acceptă ajutor nesolicitat. Are deja o echipă sec. Voi face o dezvăluire completă

- Pachet alb (@WhitePacket) 4 septembrie 2015

Dar, de asemenea, permite consumatorilor să facă o alegere în cunoștință de cauză dacă doresc să continue să utilizeze o anumită parte vulnerabilă a software-ului. Mi-ar imagina majoritatea nu ar fi.

Ce Vânzătorii doresc?

Furnizorii nu doresc divulgarea completă.

La urma urmei, este un PR incredibil de rău pentru ei și îi pune pe clienții lor în pericol. Au încercat să stimuleze oamenii să dezvăluie în mod responsabil vulnerabilitățile prin intermediul programelor de recompense de bug-uri. Acestea au fost remarcabil de succes, Google plătește 1,3 milioane dolari numai în 2014.

Deși merită subliniat faptul că unele companii - cum ar fi Oracle Oracle vrea să nu le trimiteți bug-uri - Iată de ce este nebun Oracle vrea să nu le trimiteți Bugs - Iată ce este nebun Oracle este în apă fierbinte pe un post de blog greșit de șef de securitate , Mary Davidson. Această demonstrație a modului în care filozofia de securitate a Oracle se îndepărtează de principalele nu a fost recepționată în comunitatea de securitate ... Citește mai mult - descuraja oamenii să efectueze cercetări de securitate asupra software-ului lor.

Dar totuși vor exista oameni care insistă să folosească dezvăluirea completă, fie din motive filosofice, fie din propria distracție. Nici un program de recompense de bug, indiferent cât de generos, poate contracara acest lucru.

Explorați mai multe despre: Computer Security, Hacking.