Full eller ansvarlig avsløring: Hvordan sikkerhetsproblemer avsløres

Annonse

Tre uker siden, et alvorlig sikkerhetsspørsmål i OS X 10.10.4 ble oppdaget. Det i seg selv er ikke spesielt interessant.

Sikkerhetsproblemer i populære programvarepakker oppdages hele tiden, og OS X er intet unntak. Open Source Vulnerability Database (OSVDB) viser minst 1100 sårbarheter merket som “OS X”. Men hva er interessant er måten denne spesielle sårbarheten ble avslørt.

I stedet for å fortelle Apple og gi dem tid til å avhjelpe problemet, bestemte forskeren seg for å legge ut utnyttelsen på Internett for alle å se.

Sluttresultatet var et våpenløp mellom Apple og black-hat-hackere. Apple måtte gi ut en oppdatering før sårbarheten ble våpenvåpen, og hackerne måtte opprette en utnyttelse før risikosystemene blir lappet.

Du tenker kanskje at den spesielle metoden for avsløring er uforsvarlig. Du kan til og med kalle det uetisk, eller uvøren. Men det er mer komplisert enn det. Velkommen til den underlige, forvirrende verdenen om avsløringer om sårbarhet.

Full vs Ansvarlig avsløring

Det er to populære måter å avsløre sårbarheter til programvareleverandører.

Den første heter full avsløring. Akkurat som i forrige eksempel publiserer forskere umiddelbart sin sårbarhet i naturen, noe som gir leverandørene absolutt ingen mulighet til å gi ut en løsning.

Det andre heter ansvarlig avsløring, eller forskjøvet avsløring. Det er her forskeren kontakter leverandøren før sårbarheten løslates.

Begge parter er da enige om en tidsramme der forskeren lover å ikke publisere sårbarheten, for å gi leverandøren en mulighet til å bygge og gi ut en løsning. Denne tidsperioden kan være fra 30 dager til et år, avhengig av alvorlighetsgraden og kompleksiteten til sårbarheten. Noen sikkerhetshull kan ikke enkelt festes, og krever at hele programvaresystemene skal bygges om fra grunnen av.

Når begge parter er fornøyd med fiksen som er produsert, blir sårbarheten avslørt og gitt en CVE-nummer. Disse identifiserer hvert sårbarhet, og sårbarheten arkiveres online på OSVDB.

Men hva skjer hvis ventetiden går ut? Vel, en av to ting. Leverandøren vil deretter forhandle om en utvidelse med forskeren. Men hvis forskeren ikke er fornøyd med hvordan leverandøren har respondert eller oppført seg, eller de føler at forespørselen om en utvidelse er urimelig, kan de ganske enkelt publisere den på nettet uten noen løsning.

På sikkerhetsfeltet er det opphetede debatter om hvilken metode for avsløring som er best. Noen mener at den eneste etiske og nøyaktige metoden er full avsløring. Noen tenker at det er best å gi leverandører en mulighet til å løse et problem før de slipper ut i naturen.

Som det viser seg, er det noen overbevisende argumenter for begge sider.

Argumentene til fordel for ansvarlig avsløring

La oss se på et eksempel på hvor det var best å bruke ansvarlig avsløring.

Når vi snakker om kritisk infrastruktur innenfor konteksten av Internett, er det vanskelig å unngå å snakke om DNS-protokollen Slik endrer du DNS-serverne dine og forbedrer Internett-sikkerhetSe for deg dette - du våkner en vakker morgen, skjenker deg en kopp kaffe og setter deg deretter ved datamaskinen for å komme i gang med arbeidet ditt for dagen. Før du faktisk ... Les mer . Det er dette som gjør at vi kan oversette menneskelige lesbare web-adresser (som makeuseof.com) til IP-adresser.

DNS-systemet er utrolig komplisert, og ikke bare på et teknisk nivå. Det er mye tillit i dette systemet. Vi stoler på at når vi skriver inn en nettadresse, blir vi sendt til rett sted. Det er ganske enkelt mye som sykler på integriteten til dette systemet.

Hvis noen var i stand til å forstyrre eller kompromittere en DNS-forespørsel, er det mye potensiale for skade. For eksempel kan de sende folk til uredelige nettbanker, og dermed la dem få tak i nettbankinformasjonen sin. De kunne avskjære e-post og elektronisk trafikk gjennom et midt-angrep og lese innholdet. De kan fundamentalt undergrave sikkerheten til Internett som helhet. Skumle ting.

Dan Kaminsky er en respektert sikkerhetsforsker, med en lang gjenopptakelse av å finne sårbarheter i kjent programvare. Men han er mest kjent for 2008s oppdagelse av kanskje mest alvorlig sårbarhet i DNS-systemet som noen gang er funnet. Dette ville gjort det mulig for noen å utføre en cache-forgiftning (eller DNS-forfalskning) angrep på en DNS-navneserver. De mer tekniske detaljene om dette sikkerhetsproblemet ble forklart på Def Con-konferansen i 2008.

Kaminsky, som var klar over konsekvensene av å frigjøre en så alvorlig feil, bestemte seg for å avsløre den til leverandørene av DNS-programvaren som er berørt av denne feilen.

Det var en rekke viktige DNS-produkter som ble berørt, inkludert de som ble bygget av Alcatel-Lucent, BlueCoat Technologies, Apple og Cisco. Problemet påvirket også en rekke DNS-implementeringer som ble levert med noen populære Linux / BSD-distribusjoner, inkludert dem for Debian, Arch, Gentoo og FreeBSD.

Kaminsky ga dem 150 dager på å produsere en løsning, og jobbet med dem i det skjulte for å hjelpe dem med å forstå sårbarheten. Han visste at dette problemet var så alvorlig, og de potensielle skadene så store, at det ville ha vært utrolig hensynsløs å offentliggjøre den uten å gi leverandørene en mulighet til å utstede en lapp.

Forresten, sårbarheten var lekket ved et uhell av sikkerhetsfirmaet Matsano i et blogginnlegg. Artikkelen ble tatt ned, men den ble speilet, og en dag etter publisering en utnyttelse Slik hacker du deg: Den skumle verden av utnyttede kitsSvindlere kan bruke programvarepakker for å utnytte sårbarheter og lage malware. Men hva er disse utnyttelsessettene? Hvor kommer de fra? Og hvordan kan de stoppes? Les mer hadde blitt opprettet.

Kaminskys DNS-sårbarhet oppsummerer til slutt kjernen i argumentet til fordel for ansvarlig, forskjøvet avsløring. Noen sårbarheter - som sårbarheter med null dager Hva er en sårbarhet med null dager? [MakeUseOf Explains] Les mer - er så betydningsfulle at det å forårsake betydelig offentlig skade for å løslate dem.

Men det er også et overbevisende argument for å ikke advare på forhånd.

Saken for full avsløring

Ved å frigjøre en sårbarhet i det fri, låser du opp en panda-boks der ubehagelige individer raskt og enkelt kan produsere utnyttelser og kompromittere sårbare systemer. Så hvorfor skulle noen velge å gjøre det?

Det er et par grunner. For det første er leverandører ofte ganske trege til å svare på sikkerhetsvarsler. Ved å tvinge hånden effektivt ved å slippe en sårbarhet i naturen, er de mer motiverte til å svare raskt. Enda verre er noen tilbøyelige å ikke offentliggjøre Hvorfor selskaper som holder brudd på hemmeligheten, kan være et godt tingMed så mye informasjon på nettet, bekymrer vi oss alle for potensielle sikkerhetsbrudd. Men disse bruddene kan holdes hemmelige i USA for å beskytte deg. Det høres sprøtt ut, så hva skjer? Les mer det faktum at de sendte sårbar programvare. Full avsløring tvinger dem til å være ærlige overfor kundene sine.

Men det gjør det også mulig for forbrukerne å ta et informert valg om de vil fortsette å bruke en bestemt, sårbar programvare. Jeg kan tenke meg at flertallet ikke ville gjort det.

Hva vil leverandører?

Selgere liker ikke full avsløring.

Det er tross alt utrolig dårlig PR for dem, og det setter kundene deres i fare. De har forsøkt å incentivere folk til å avsløre sårbarheter på en ansvarlig måte, men med programvare for feilbelastning. Disse har vært bemerkelsesverdig vellykket, med at Google betalte 1,3 millioner dollar i 2014 alene.

Selv om det er verdt å påpeke at noen selskaper - som Oracle Oracle ønsker at du skal slutte å sende dem feil - her er hvorfor det er sprøttOracle er i varmt vann over et feilaktig blogginnlegg av sikkerhetssjef, Mary Davidson. Denne demonstrasjonen av hvordan Orakles sikkerhetsfilosofi avviker fra mainstream ble ikke mottatt godt i sikkerhetssamfunnet ... Les mer - fraråde folk å utføre sikkerhetsforskning på programvaren sin.

Men det kommer fortsatt til å være mennesker som insisterer på å bruke full avsløring, enten av filosofiske grunner eller av sin egen underholdning. Ingen bug-dusørprogram, uansett hvor raus, kan motvirke det.