Fuld eller ansvarlig offentliggørelse: Hvordan sikkerhedsproblemer er afsløret

Sikkerhedsproblemer i populære softwarepakker opdages hele tiden, men hvordan rapporteres de til udviklere, og hvordan opdager hackere om sårbarheder, som de kan udnytte?

Sikkerhedsproblemer i populære softwarepakker opdages hele tiden, men hvordan rapporteres de til udviklere, og hvordan opdager hackere om sårbarheder, som de kan udnytte?
Reklame

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

Sikkerhedsproblemer 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 der er interessant er den måde, hvorpå denne særlige sårbarhed blev afsløret.

videregivelse-osvdb-OSX

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

Slutresultatet var en arme-race mellem Apple og black hat hackere. Apple var nødt til at frigøre en patch, før sårbarheden blev våben, og hackerne skulle skabe en udnyttelse, før risikosystemerne blev patched.

Du tror måske, at en bestemt metode til offentliggørelse er uansvarlig. Du kan endda kalde det uetisk eller hensynsløs. Men det er mere kompliceret end det. Velkommen til den underlige, forvirrende verden af ​​udbredelse af sårbarhed.

Fuld vs Ansvarlig Disclosure

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

Den første kaldes fuld offentliggørelse . Som i det foregående eksempel offentliggør forskere straks deres sårbarhed i naturen, hvilket giver sælgerne absolut ingen mulighed for at frigive en løsning.

Den anden kaldes ansvarlig offentliggørelse eller forskudt offentliggørelse. Det er her forskeren kontakter sælgeren, før sårbarheden frigives.

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

Når begge parter er tilfredse med den rettelse, der er blevet produceret, bliver sårbarheden så afsløret og givet et CVE nummer. Disse identificerer unikt hver sårbarhed, og sårbarheden arkiveres online på OSVDB.

videregivelse-osvdb-vuln

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

På sikkerhedsområdet er der opvarmede debatter om, hvilken metode til offentliggørelse der er bedst. Nogle mener, at den eneste etiske og præcise metode er fuld offentliggørelse. Nogle mener, at det er bedst at give sælgerne mulighed for at løse et problem, før de frigives i det vilde.

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

Argumenterne til fordel for ansvarlig oplysning

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

Når vi taler om kritisk infrastruktur i forbindelse med internettet, er det svært at undgå at tale om DNS-protokollen. Sådan ændrer du dine DNS-servere og forbedrer internet sikkerhed. Sådan ændres dine DNS-servere og forbedrer internet sikkerhed. Forestil dig dette - du vågner op en smuk morgen, hell dig en kop kaffe og sæt dig derefter ned på din computer for at komme i gang med dit arbejde for dagen. Før du rent faktisk får ... Læs mere. Dette gør det muligt for os at oversætte menneskelige læsbare webadresser (som makeuseof.com) til IP-adresser.

DNS-systemet er utroligt kompliceret, og ikke kun på teknisk niveau. Der er meget tillid placeret i dette system. Vi stoler på, at når vi indtaster en webadresse, sendes vi til det rigtige sted. Der er simpelthen meget ridning på integriteten af ​​dette system.

videregivelse-server

Hvis nogen kunne interferere med eller kompromittere en DNS-forespørgsel, er der meget potentiale for skade. For eksempel kunne de sende folk til bedrageriske internetbanksider, hvorved de kunne få deres online bankingoplysninger. De kunne opfange deres e-mail og online-trafik gennem et menneske-i-midten-angreb, og læse indholdet. De kunne fundamentalt underminere sikkerheden for internettet som helhed. Skræmmende ting.

Dan Kaminsky er en velrenommeret sikkerhedsforsker, med et langt resume af at finde sårbarheder i velkendt software. Men han er mest kendt for 2008s opdagelse af måske den mest alvorlige sårbarhed i DNS-systemet nogensinde fundet. Dette ville have givet en person mulighed for nemt at udføre et cacheforgiftning (eller DNS spoofing) angreb på en DNS navneserver. De mere tekniske detaljer af 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 videregive den til sælgerne af DNS-softwaren, der er påvirket af denne fejl.

Der blev ramt en række større DNS-produkter, herunder dem, der blev bygget af Alcatel-Lucent, BlueCoat Technologies, Apple og Cisco. Problemet har også påvirket 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 lave en løsning og arbejdede sammen med dem i hemmelighed for at hjælpe dem med at forstå sårbarheden. Han vidste, at dette problem 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 sælgerne mulighed for at udstede en patch.

For øvrigt blev sårbarheden lækket af et uheld af sikkerhedsfirmaet Matsano i et blogindlæg. Artiklen blev taget ned, men den blev spejlet, og en dag efter offentliggørelsen er en udnyttelse. Det er sådan, hvordan de hakker dig: Den Murky World of Exploit Kit. Dette er hvordan de hakker dig: Den Murky World of Exploit Kits Scammers kan bruge software suiter til at udnytte sårbarheder og oprette malware. Men hvad er disse udnyttelsessæt? Hvor kommer de fra? Og hvordan kan de stoppes? Læs mere var blevet oprettet.

Kaminsky s DNS sårbarhed opsummerer i sidste ende kernen i argumentet til fordel for ansvarlig, forskudt offentliggørelse. Nogle sårbarheder - som sårbarheder på nul dag Hvad er en sårbarhed i nul dag? [MakeUseOf Forklarer] Hvad er en nul-dag sårbarhed? [MakeUseOf Forklarer] Læs mere - er så vigtige, at for offentligt at frigive dem ville forårsage betydelig skade.

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

Sagen for fuld oplysning

Ved at frigøre en sårbarhed i det åbne åbner du en pandoras boks, hvor uønskede personer hurtigt og nemt kan producere udnyttelser og kompromittere sårbare systemer. Så hvorfor ville nogen vælge at gøre det?

Der er et par grunde. For det første er sælgerne ofte ret langsomme til at reagere 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, nogle er tilbøjelige til ikke at offentliggøre, hvorfor virksomheder, der overholder en hemmelighed, kunne være en god ting, hvorfor virksomheder, der overholder en hemmelighed, kunne være en god ting. Med så meget information online bekymrer vi os alle for mulige sikkerhedsbrud. Men disse brud kan holdes hemmelige i USA for at beskytte dig. Det lyder skørt, så hvad sker der? Læs mere det faktum, at de var afsendt sårbar software. Fuld åbenhed tvinger dem til at være ærlige med deres kunder.

Tilsyneladende @PepsiCo er ligeglad med en vuln på deres websted, og accepterer ikke uopfordret hjælp. Har allerede et sekund hold. Jeg vil gøre fuld offentliggørelse

- White Packet (@WhitePacket) 4. september 2015

Men det giver også forbrugerne mulighed for at træffe et velinformeret valg om, hvorvidt de vil fortsætte med at bruge et bestemt, sårbart stykke software. Jeg kunne forestille mig, at flertallet ikke ville.

Hvad vil leverandører ønske?

Leverandører kan ikke lide fuld offentliggørelse.

Det er trods alt utrolig dårlig PR for dem, og det sætter deres kunder i fare. De har forsøgt at incitivere folk til at oplyse sårbarheder ansvarligt, selvom bug-bounty-programmer. Disse har været bemærkelsesværdigt succesfulde, idet Google betaler alene 1, 3 millioner dollars i 2014 alene.

Selv om det er værd at påpege, at nogle virksomheder - som Oracle Oracle, vil du stoppe med at sende dem fejl - her er hvorfor det er skønt Oracle vil du stoppe med at sende dem fejl - her er hvorfor det er vanvittigt Oracle er i varmt vand over et misforstået blogpost af sikkerhedschef, Mary Davidson. Denne demonstration af, hvordan Oracle's sikkerhedsfilosofi afviger fra mainstream, blev ikke modtaget godt i sikkerhedssamfundet ... Læs mere - afskrække folk fra at udføre sikkerhedsforskning på deres software.

Men der vil stadig være mennesker, der insisterer på at bruge fuld offentliggørelse, enten af ​​filosofiske grunde eller til deres egen underholdning. Ingen bug bounty program, uanset hvor generøs, kan imødegå det.

In this article