Volledige of verantwoordelijke openbaarmaking: hoe beveiligingslekken worden onthuld

Advertentie

Drie weken geleden, een ernstig beveiligingsprobleem in OS X 10.10.4 werd ontdekt. Dat is op zichzelf niet bijzonder interessant.

Beveiligingsproblemen in populaire softwarepakketten worden ontdekt altijd, en OS X is geen uitzondering. De Open Source Vulnerability Database (OSVDB) toont ten minste 1100 kwetsbaarheden die zijn getagd als "OS X". Maar wat is interessant is de manier waarop deze specifieke kwetsbaarheid werd onthuld.

In plaats van Apple te vertellen en hen de tijd te geven om het probleem op te lossen, besloot de onderzoeker zijn exploit op het internet te plaatsen zodat iedereen het kon zien.

Het eindresultaat was een wapenwedloop tussen Apple en black-hat-hackers. Apple moest een patch uitbrengen voordat de kwetsbaarheid werd bewapend en de hackers moesten een exploit maken voordat de risicosystemen werden gepatcht.

Je zou kunnen denken dat een bepaalde manier van openbaarmaking onverantwoord is. Je zou het zelfs onethisch of roekeloos kunnen noemen. Maar het is ingewikkelder dan dat. Welkom in de vreemde, verwarrende wereld van openbaarmaking van kwetsbaarheden.

Volledige versus verantwoordelijke openbaarmaking

Er zijn twee populaire manieren om kwetsbaarheden te onthullen aan softwareleveranciers.

De eerste wordt genoemd totale openheid. Net als in het vorige voorbeeld, publiceren onderzoekers hun kwetsbaarheid onmiddellijk in het wild, waardoor de leveranciers absoluut geen kans krijgen om een ​​oplossing vrij te geven.

De tweede wordt genoemd verantwoorde openbaarmakingof gespreide openbaarmaking. Hier neemt de onderzoeker contact op met de leverancier voordat de kwetsbaarheid wordt vrijgegeven.

Beide partijen komen vervolgens een tijdschema overeen waarin de onderzoeker belooft de kwetsbaarheid niet te publiceren, om de leverancier de kans te geven een oplossing te bouwen en vrij te geven. Deze periode kan variëren van 30 dagen tot een jaar, afhankelijk van de ernst en complexiteit van de kwetsbaarheid. Sommige beveiligingslekken kunnen niet eenvoudig worden verholpen en vereisen dat volledige softwaresystemen helemaal opnieuw worden opgebouwd.

Zodra beide partijen tevreden zijn met de gemaakte oplossing, wordt de kwetsbaarheid bekendgemaakt en krijgt deze een CVE-nummer. Deze identificeren elke kwetsbaarheid op unieke wijze en de kwetsbaarheid wordt online gearchiveerd op de OSVDB.

Maar wat gebeurt er als de wachttijd verloopt? Nou, een van de twee dingen. De verkoper onderhandelt dan met de onderzoeker over een verlenging. Maar als de onderzoeker niet tevreden is met hoe de leverancier heeft gereageerd of zich heeft gedragen, of als hij vindt dat het verzoek om een ​​verlenging onredelijk is, kan hij het eenvoudig online publiceren zonder dat er een oplossing klaar is.

Op veiligheidsgebied zijn er heftige discussies over welke manier van openbaarmaking het beste is. Sommigen denken dat de enige ethische en nauwkeurige methode volledige openbaarmaking is. Sommigen denken dat het het beste is om leveranciers de kans te geven om een ​​probleem op te lossen voordat het in het wild wordt vrijgegeven.

Het blijkt dat er voor beide partijen een aantal overtuigende argumenten zijn.

De argumenten voor verantwoorde openbaarmaking

Laten we eens kijken naar een voorbeeld van waar het het beste was om verantwoordelijke openbaarmaking te gebruiken.

Als we het hebben over kritieke infrastructuur in de context van internet, is het moeilijk om erover te praten het DNS-protocol Hoe u uw DNS-servers kunt wijzigen en internetbeveiliging kunt verbeterenStel je voor: je wordt op een mooie ochtend wakker, schenkt jezelf een kopje koffie in en gaat dan achter je computer zitten om aan de slag te gaan met je werk voor de dag. Voordat je echt krijgt ... Lees verder . Dit is wat ons in staat stelt om door mensen leesbare webadressen (zoals makeuseof.com) te vertalen naar IP-adressen.

Het DNS-systeem is ongelooflijk ingewikkeld, en niet alleen op technisch vlak. Er wordt veel vertrouwen in dit systeem gesteld. We vertrouwen erop dat wanneer we een webadres typen, we naar de juiste plaats worden gestuurd. Er wordt gewoon veel gereden op de integriteit van dit systeem.

Als iemand een DNS-verzoek kon verstoren of in gevaar kon brengen, is er veel kans op schade. Ze kunnen bijvoorbeeld mensen naar frauduleuze internetbankierpagina's sturen, waardoor ze hun gegevens over internetbankieren kunnen opvragen. Ze konden hun e-mail en online verkeer onderscheppen door een man-in-the-middle-aanval en de inhoud lezen. Ze kunnen de veiligheid van het internet als geheel fundamenteel ondermijnen. Enge dingen.

Dan Kaminsky is een gerespecteerde beveiligingsonderzoeker, met een lange samenvatting van het opsporen van kwetsbaarheden in bekende software. Maar hij is vooral bekend vanwege de ontdekking van misschien wel de meest ernstige kwetsbaarheid in het DNS-systeem ooit gevonden. Hierdoor zou iemand gemakkelijk een cachevergiftiging (of DNS-spoofing) aanval op een DNS-naamserver. De meer technische details van dit beveiligingslek werden uitgelegd tijdens de Def Con-conferentie van 2008.

Kaminsky, zich terdege bewust van de gevolgen van het uitbrengen van een dergelijke ernstige fout, besloot deze bekend te maken aan de leveranciers van de DNS-software die door deze bug worden getroffen.

Er waren een aantal grote DNS-producten getroffen, waaronder die van Alcatel-Lucent, BlueCoat Technologies, Apple en Cisco. Het probleem was ook van invloed op een aantal DNS-implementaties die bij enkele populaire Linux / BSD-distributies werden geleverd, waaronder die voor Debian, Arch, Gentoo en FreeBSD.

Kaminsky gaf ze 150 dagen om een ​​oplossing te maken en werkte in het geheim met hen samen om hen te helpen de kwetsbaarheid te begrijpen. Hij wist dat dit probleem zo ernstig was en dat de potentiële schade zo groot was dat het zou zijn geweest ongelooflijk roekeloos om het publiekelijk vrij te geven zonder de leveranciers de kans te geven een patch.

Overigens was de kwetsbaarheid per ongeluk gelekt door beveiligingsbedrijf Matsano in een blogpost. Het artikel werd verwijderd, maar het werd gespiegeld en een dag na publicatie een exploit Dit is hoe ze je hacken: de duistere wereld van exploitkitsOplichters kunnen softwaresuites gebruiken om kwetsbaarheden te misbruiken en malware te creëren. Maar wat zijn deze exploitkits? Waar komen ze vandaan? En hoe kunnen ze worden gestopt? Lees verder was gemaakt.

Kaminsky's DNS-kwetsbaarheid vat uiteindelijk de kern van het argument samen ten gunste van verantwoorde, gespreide openbaarmaking. Sommige kwetsbaarheden - zoals zero day kwetsbaarheden Wat is een Zero Day-kwetsbaarheid? [MakeUseOf Explains] Lees verder - zo belangrijk zijn dat het openbaar maken ervan aanzienlijke schade zou veroorzaken.

Maar er is ook een overtuigend argument om geen waarschuwing vooraf te geven.

De zaak voor volledige openbaarmaking

Door een kwetsbaarheid openbaar te maken, ontgrendel je een pandora-doos waar onsmakelijke individuen in staat zijn om snel en gemakkelijk exploits te produceren en kwetsbare systemen in gevaar te brengen. Dus waarom zou iemand ervoor kiezen om dat te doen?

Er zijn verschillende redenen. Ten eerste reageren leveranciers vaak vrij traag op beveiligingsmeldingen. Door hun hand effectief te forceren door een kwetsbaarheid in het wild los te laten, zijn ze meer gemotiveerd om snel te reageren. Erger nog, sommigen zijn geneigd om niet te publiceren Waarom bedrijven schendingen geheim houden, kan een goede zaak zijnMet zoveel informatie online, maken we ons allemaal zorgen over mogelijke inbreuken op de beveiliging. Maar deze inbreuken kunnen in de VS geheim worden gehouden om u te beschermen. Het klinkt gek, dus wat is er aan de hand? Lees verder het feit dat ze kwetsbare software verscheepten. Volledige openbaarmaking dwingt hen om eerlijk te zijn tegenover hun klanten.

Maar het stelt consumenten ook in staat om een ​​weloverwogen keuze te maken of ze een bepaald, kwetsbaar stuk software willen blijven gebruiken. Ik kan me voorstellen dat de meerderheid dat niet zou doen.

Wat willen leveranciers?

Leveranciers houden echt niet van volledige openbaarmaking.

Het is tenslotte ongelooflijk slechte PR voor hen en het brengt hun klanten in gevaar. Ze hebben geprobeerd mensen te stimuleren om kwetsbaarheden op een verantwoorde manier openbaar te maken door middel van bugbounty-programma's. Deze zijn opmerkelijk succesvol geweest, waarbij Google $ 1,3 miljoen dollar heeft betaald in 2014 alleen.

Hoewel het de moeite waard is om erop te wijzen dat sommige bedrijven - zoals Oracle Oracle wil dat u stopt met het verzenden van bugs - hier is waarom dat gek isOracle zit in de problemen met een misleidende blogpost van beveiligingschef Mary Davidson. Deze demonstratie van hoe Oracle's beveiligingsfilosofie afwijkt van de mainstream werd niet goed ontvangen in de beveiligingsgemeenschap ... Lees verder - mensen ontmoedigen om beveiligingsonderzoek naar hun software uit te voeren.

Maar er zullen nog steeds mensen zijn die erop staan ​​om volledige onthulling te gebruiken, hetzij om filosofische redenen, hetzij voor hun eigen plezier. Geen enkel programma voor bugbounty's, hoe genereus ook, kan dat tegengaan.