Volledige of verantwoorde openbaarmaking Hoe beveiligingslekken worden onthuld

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

Beveiligingskwetsbaarheden in populaire softwarepakketten worden ontdekt altijd, en OS X is geen uitzondering. De Open Source Vulnerability Database (OSVDB) toont minstens 1100 kwetsbaarheden die zijn gelabeld als “OS X”. Maar wat is interessant is de manier waarop deze specifieke kwetsbaarheid is onthuld.

In plaats van het aan 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 vrijgeven voordat het beveiligingslek werd geactiveerd en de hackers moesten een exploit maken voordat de risicostelsels werden gepatcht.

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

Volledige versus verantwoorde openbaarmaking

Er zijn twee populaire manieren om kwetsbaarheden aan softwareleveranciers bekend te maken.

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

De tweede wordt genoemd verantwoorde openbaarmaking, of gespreide openbaarmaking. Hier neemt de onderzoeker contact op met de leverancier voordat het beveiligingslek wordt vrijgegeven.

Beide partijen zijn het dan eens over een tijdschema waarin de onderzoeker belooft de kwetsbaarheid niet te publiceren, om de verkoper de kans te geven een fix 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 beveiligingsgaten kunnen niet eenvoudig worden opgelost en vereisen dat complete softwaresystemen volledig opnieuw worden opgebouwd.

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

Maar wat gebeurt er als de wachttijd verloopt? Nou, een van de twee dingen. De leverancier onderhandelt dan met de onderzoeker over een verlenging. Maar als de onderzoeker niet tevreden is met de manier waarop de leverancier heeft gereageerd of zich heeft gedragen, of als ze vinden dat het verzoek om een ​​extensie onredelijk is, kunnen ze het eenvoudig online publiceren zonder fix-ready.

Op het gebied van beveiliging zijn er verhitte discussies over welke methode 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 verkopers een kans te geven om een ​​probleem op te lossen voordat het in het wild wordt vrijgegeven.

Het blijkt dat er voor beide partijen enkele overtuigende argumenten zijn.

De argumenten voor de verantwoorde openbaarmaking

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

Wanneer we het hebben over kritieke infrastructuur in de context van internet, is het moeilijk om te voorkomen dat we praten over het DNS-protocol. Hoe uw DNS-servers te veranderen en internetveiligheid te verbeteren Hoe u uw DNS-servers kunt veranderen en internetbeveiliging kunt verbeteren Stel u dit eens voor - u wordt één mooie wakker 's morgens, schenk jezelf een kopje koffie in en ga vervolgens op je computer zitten om aan de slag te gaan met je werk voor vandaag. Voordat je daadwerkelijk ... Lees meer. 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 niveau. Er zit veel vertrouwen in dit systeem. We vertrouwen erop dat wanneer we een webadres typen, we naar de juiste plek worden gestuurd. Er gaat gewoon veel over de integriteit van dit systeem.

Als iemand in staat was om een ​​DNS-verzoek in de weg te staan ​​of in gevaar te brengen, is er veel potentieel voor schade. Ze kunnen mensen bijvoorbeeld naar frauduleuze pagina's voor online bankieren sturen, waardoor ze hun online bankgegevens kunnen achterhalen. Ze konden hun e-mail en online verkeer onderscheppen door middel van 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 zeer gerespecteerde beveiligingsonderzoeker, met een lang verhaal over het vinden van kwetsbaarheden in bekende software. Maar hij is het meest bekend voor de ontdekking van 2008 van misschien wel de meest ernstige kwetsbaarheid in het DNS-systeem ooit gevonden. Hierdoor zou iemand gemakkelijk een cachevergiftigings (of DNS-spoofing) -aanval op een DNS-naamserver kunnen uitvoeren. De meer technische details van deze kwetsbaarheid werden uitgelegd tijdens de 2008 Def Con conferentie.

Kaminsky, zich acuut bewust van de gevolgen van het vrijgeven van zo'n ernstige fout, besloot om het bekend te maken aan de verkopers van de DNS-software die getroffen zijn door deze bug.

Er waren een aantal belangrijke DNS-producten aangetast, inclusief de producten die werden gebouwd door Alcatel-Lucent, BlueCoat Technologies, Apple en Cisco. Het probleem had ook gevolgen voor een aantal DNS-implementaties die werden geleverd met een aantal populaire Linux / BSD-distributies, waaronder die voor Debian, Arch, Gentoo en FreeBSD.

Kaminsky gaf hen 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 ongelooflijk roekeloos zou zijn om het publiekelijk vrij te geven zonder de leveranciers de gelegenheid te geven een patch uit te geven.

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

Kaminsky's DNS-kwetsbaarheid vat uiteindelijk de kern van het argument samen ten gunste van een verantwoorde, gespreide openbaarmaking. Enkele kwetsbaarheden - zoals zero-day-kwetsbaarheden Wat is een Zero Day-kwetsbaarheid? [MakeUseOf Explains] Wat is een Zero Day-beveiligingslek? [MakeUseOf Explains] Read More - zijn zo belangrijk dat 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 in de openbaarheid vrij te geven, ontgrendel je een pandora's doos waar onfrisse 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 een aantal redenen. Ten eerste zijn leveranciers vaak vrij traag in het reageren op beveiligingsmeldingen. Door effectief hun hand te forceren door een kwetsbaarheid in het wild vrij te geven, zijn ze meer gemotiveerd om snel te reageren. Erger nog, sommigen zijn geneigd om niet te publiceren waarom bedrijven die een geheim houden overtroffen een goede zaak kunnen zijn. Waarom bedrijven een geheim overtreden, kan een goede zaak zijn. Met zoveel informatie online, maken we ons allemaal zorgen over mogelijke beveiligingsinbreuken. Maar deze overtredingen kunnen geheim worden gehouden in de VS om u te beschermen. Het klinkt gek, dus wat is er aan de hand? Lees Meer over het feit dat ze kwetsbare software verzendden. Volledige openbaarmaking dwingt hen om eerlijk te zijn tegenover hun klanten.

Blijkbaar maakt @PepsiCo zich geen zorgen over een vulkaan op hun site en accepteert het geen ongevraagde hulp. Heeft al een sec-team. Ik zal volledige openbaarmaking doen

- White Packet (@WhitePacket) 4 september 2015

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?

Verkopers houden niet van volledige openbaarmaking.

Het is tenslotte ongelofelijk slechte PR voor hen en het brengt hun klanten in gevaar. Ze hebben geprobeerd mensen te motiveren om kwetsbaarheden op een verantwoorde manier openbaar te maken via bugbounty-programma's. Deze zijn opmerkelijk succesvol geweest, waarbij Google in 2014 alleen al $ 1,3 miljoen betaalde.

Hoewel het de moeite waard is om erop te wijzen dat sommige bedrijven - zoals Oracle Oracle wil stoppen met het versturen van die bugs - hier is waarom dat gek is Oracle wil dat je stopt met het verzenden van die bugs - hier is waarom dat gekke Oracle in warm water is over een misplaatste blogpost van de veiligheidsleider , Mary Davidson. Deze demonstratie van hoe de beveiligingsfilosofie van Oracle afwijkt van de mainstream, werd niet goed ontvangen in de beveiligingsgemeenschap ... Lees meer - ontmoedig mensen van beveiligingsonderzoek naar hun software.

Maar er zullen nog steeds mensen zijn die aandringen op volledige onthulling, hetzij om filosofische redenen, hetzij voor hun eigen amusement. Geen enkel bugbounty-programma, hoe genereus ook, kan dat tegengaan.

Ontdek meer over: Computerbeveiliging, Hacking.