Fuld eller ansvarlig videregivelse af, hvordan sikkerhedsmæssige sårbarheder afsløres

For tre uger siden blev et alvorligt sikkerhedsproblem i OS X 10.10.4 opdaget. Det i sig selv er ikke særlig interessant.

Sikkerhedsmæssige sårbarheder i populære softwarepakker opdages hele tiden, og OS X er ingen undtagelse. Open Source Vulnerability Database (OSVDB) viser mindst 1100 sårbarheder mærket som “OS X”. Men hvad er interessant er den måde, hvorpå denne særlige sårbarhed blev afsløret.

I stedet for at fortælle Apple og give dem tid til at afhjælpe problemet, besluttede forskeren at placere sin udnyttelse på Internettet for alle at se.

Slutresultatet var et våbenløb mellem Apple og black-hat-hackere. Apple måtte frigive en patch, før sårbarheden blev våbenudviklet, og hackerne måtte skabe en udnyttelse, inden risikosystemerne fik lappet.

Du synes måske, at den særlige metode til afsløring er uansvarlig. Du kan endda kalde det uetisk eller hensynsløs. Men det er mere kompliceret end det. Velkommen til den underlige og forvirrende verden af ​​afsløringer af sårbarheder.

Fuld kontra ansvarlig afsløring

Der er to populære måder at afsløre sårbarheder til softwareleverandører.

Den første kaldes fuld åbenhed. Ligesom i det foregående eksempel offentliggør forskere straks deres sårbarhed i naturen, hvilket giver leverandørerne absolut ingen mulighed for at frigive en rettelse.

Den anden kaldes ansvarlig afsløring, eller forskudt afsløring. Det er her forskeren kontakter leverandøren, før sårbarheden frigives.

Begge parter er derefter enige om en tidsramme, hvor forskeren lover ikke at offentliggøre sårbarheden for at give sælgeren en mulighed for at opbygge og frigive en løsning. Denne tidsperiode kan være overalt fra 30 dage til et år, afhængigt af sårbarhedens sværhedsgrad og kompleksitet. Nogle sikkerhedshuller kan ikke let fastgøres og kræver, at hele softwaresystemer genopbygges fra bunden.

Når begge parter er tilfredse med den rettelse, der er produceret, afsløres sårbarheden og får et CVE-nummer. Disse identificerer entydigt hver sårbarhed, og sårbarheden arkiveres online på OSVDB.

Men hvad sker der, hvis ventetiden udløber? Nå, en af ​​to ting. Sælgeren forhandler derefter en udvidelse med forskeren. Men hvis forskeren ikke er tilfreds med, hvordan sælgeren har reageret eller opført sig, eller de føler, at anmodningen om en udvidelse er urimelig, kan de muligvis blot offentliggøre den online uden reparation klar.

Inden for sikkerhedsområdet er der ophedede debatter om, hvilken metode til afsløring er bedst. Nogle mener, at den eneste etiske og nøjagtige metode er fuld offentliggørelse. Nogle mener, at det er bedst at give leverandører en mulighed for at løse et problem, før de frigives i naturen.

Som det viser sig, er der nogle overbevisende argumenter for begge sider.

Argumenterne til fordel for ansvarlig afsløring

Lad os se på et eksempel på, hvor det var bedst at bruge ansvarlig afsløring.

Når vi taler om kritisk infrastruktur inden for rammerne af Internettet, er det svært at undgå at tale om DNS-protokollen Sådan ændres dine DNS-servere og forbedres Internetsikkerhed Sådan ændrer du dine DNS-servere og forbedrer Internetsikkerhed Forestil dig det - du vågner op en smuk formiddag, hæld dig selv en kop kaffe, og sæt dig derefter ved din computer for at komme i gang med dit arbejde for dagen. Før du faktisk får…. Dette er, hvad der giver os mulighed for at oversætte menneskelige læsbare webadresser (som makeuseof.com) til IP-adresser.

DNS-systemet er utroligt kompliceret og ikke kun på et teknisk niveau. Der er en masse tillid i dette system. Vi stoler på, at når vi indtaster en web-adresse, bliver vi sendt til det rigtige sted. Der kører ganske enkelt meget på dette systems integritet.

Hvis nogen var i stand til at forstyrre eller kompromittere en DNS-anmodning, er der meget potentiale for skade. For eksempel kunne de sende folk til falske onlinebankesider og derved give dem mulighed for at få deres online bankoplysninger. De kunne aflytte deres e-mail og onlinetrafik gennem et mand-i-midten-angreb og læse indholdet. De kunne fundamentalt underminere sikkerheden på Internettet som helhed. Uhyggelige ting.

Dan Kaminsky er en respekteret sikkerhedsforsker med en lang CV for at finde sårbarheder i velkendt software. Men han er mest kendt for 2008's opdagelse af måske den mest alvorlige sårbarhed i det DNS-system, der nogensinde er fundet. Dette ville have gjort det muligt for nogen let at udføre et cache-forgiftning (eller DNS-spoofing) -angreb på en DNS-navneserver. De mere tekniske detaljer om denne sårbarhed blev forklaret på Def Con-konferencen i 2008.

Kaminsky, akut opmærksom på konsekvenserne af at frigive en så alvorlig fejl, besluttede at afsløre det til leverandørerne af DNS-softwaren, der er berørt af denne fejl.

Der var en række større DNS-produkter, der blev berørt, herunder produkter bygget af Alcatel-Lucent, BlueCoat Technologies, Apple og Cisco. Problemet påvirkede også en række DNS-implementeringer, der blev leveret med nogle populære Linux / BSD-distributioner, herunder dem til Debian, Arch, Gentoo og FreeBSD.

Kaminsky gav dem 150 dage til at fremstille en løsning og arbejdede med dem i hemmelighed for at hjælpe dem med at forstå sårbarheden. Han vidste, at dette emne var så alvorligt, og de potentielle skader så store, at det ville have været utroligt hensynsløst at offentliggøre det uden at give leverandørerne en mulighed for at udstede en patch.

I øvrigt lækkede sårbarheden ved et uheld af sikkerhedsfirmaet Matsano i et blogindlæg. Artiklen blev fjernet, men den blev spejlet, og en dag efter offentliggørelsen udnyttede dette en sådan Sådan hacker du dig: Den skumle verden af ​​udnyttelsessæt Sådan hacker du dig: Den skumle verden med udnyttelsessæt Svindlere kan bruge softwarepakker til udnytte sårbarheder og oprette malware. Men hvad er disse udnyttelsessæt? Hvor kommer de fra? Og hvordan kan de stoppes? var blevet skabt.

Kaminskys DNS-sårbarhed opsummer i sidste ende kernen i argumentet til fordel for ansvarlig, forskudt afsløring. Nogle sårbarheder - som sårbarheder med nul dage Hvad er en sårbarhed med nul dag? [MakeUseOf Explains] Hvad er en sårbarhed med nul dag? [MakeUseOf Explains] - er så betydningsfulde, at det ville medføre betydelig skade at offentliggøre dem.

Men der er også et overbevisende argument til fordel for ikke at give advarsel om forhånd.

Sagen til fuld afsløring

Ved at frigive en sårbarhed i det åbne låser du en pandora-boks op, hvor usmagelige individer er i stand til hurtigt og let at fremstille udnyttelser og kompromittere sårbare systemer. Så hvorfor skulle nogen vælge at gøre det?

Der er et par grunde. For det første er leverandører ofte ret langsomme med at svare på sikkerhedsmeddelelser. Ved effektivt at tvinge deres hånd ved at frigive en sårbarhed i naturen, er de mere motiverede til at reagere hurtigt. Endnu værre er, at nogle er tilbøjelige til ikke at offentliggøre, hvorfor virksomheder, der holder krænkelser en hemmelighed, kan være et godt ting, hvorfor virksomheder, der holder krænkelser en hemmelighed, kan være et godt ting. Med så meget information online, bekymrer vi os alle over mulige sikkerhedsbrud. Men disse overtrædelser kunne holdes hemmelige i USA for at beskytte dig. Det lyder vanvittigt, så hvad sker der? det faktum, at de sendte sårbar software. Fuld offentliggørelse tvinger dem til at være ærlige over for deres kunder.

Men det giver også forbrugere mulighed for at træffe et informeret valg om, hvorvidt de vil fortsætte med at bruge et bestemt, sårbart stykke software. Jeg kan forestille mig, at flertallet ikke ville gøre det.

Hvad ønsker leverandører?

Sælgere kan ikke lide fuld offentliggørelse.

Når alt kommer til alt er det utroligt dårlig PR for dem, og det sætter deres kunder i fare. De har forsøgt at incitamere folk til at afsløre sårbarheder på en ansvarlig måde, selvom fejl i bounty-programmer. Disse har været bemærkelsesværdigt succesfulde, idet Google kun betalte 1,3 millioner dollars i 2014 alene.

Selvom det er værd at påpege, at nogle virksomheder - som Oracle Oracle vil have dig til at stoppe med at sende dem bugs - her er hvorfor det er vanvittigt Oracle vil have dig til at stoppe med at sende dem bugs - her er hvorfor det er skøre Oracle er i varmt vand over et forkert blogindlæg fra sikkerhedschef , Mary Davidson. Denne demonstration af, hvordan Oracle's sikkerhedsfilosofi afgår fra mainstream, blev ikke modtaget godt i sikkerhedssamfundet ... - afskrække folk fra at udføre sikkerhedsundersøgelser på deres software.

Men der vil stadig være mennesker, der insisterer på at bruge fuld afsløring, enten af ​​filosofiske grunde eller af deres egen underholdning. Intet bugbounty-program, uanset hvor generøst, kan modvirke det.