For tre uker siden ble det oppdaget et alvorlig sikkerhetsproblem i OS X 10.10.4. Det er i seg selv ikke særlig interessant.
Sikkerhetsproblemer i populære programvarepakker blir oppdaget hele tiden, og OS X er ikke noe unntak. Sikkerhetsdatabasen for åpen kildekode (OSVDB) viser minst 1100 sårbarheter merket som "OS X". Men det som er interessant, er hvordan dette bestemte sikkerhetsproblemet ble avslørt.
I stedet for å fortelle Apple og gi dem tid til å rette opp problemet, bestemte forskeren seg for å legge ut sin utnyttelse på Internett for alle å se.
Sluttresultatet var et våpenløp mellom Apple og Black Hat Hackere. Apple måtte slippe ut en patch før sårbarheten ble våpen, og hackerne måtte skape en utnyttelse før risikosystemene ble patched.
Det kan hende du tror at en bestemt metode for avsløring er uansvarlig. Du kan til og med kalle det uetisk eller hensynsløs. Men det er mer komplisert enn det. Velkommen til den underlige, forvirrende verden av avsløring av sårbarhet.
Full vs Responsible Disclosure
Det er to populære måter å avsløre sårbarheter for programvareleverandører.
Den første kalles full avsløring . I likhet med det forrige eksemplet publiserer forskere umiddelbart sårbarheten i naturen, noe som gir selgerne absolutt ingen mulighet til å frigjøre en løsning.
Den andre kalles ansvarlig avsløring, eller forskjøvet avsløring. Det er her forskeren kontakter leverandøren før sikkerhetsproblemet utgis.
Begge partene er så enige om en tidsramme hvor forskeren lover å ikke publisere sårbarheten, for å gi selgeren muligheten til å bygge og frigjøre en løsning. Denne perioden kan være hvor som helst fra 30 dager til et år, avhengig av alvorlighetsgrad og kompleksitet av sikkerhetsproblemet. Noen sikkerhetshull kan ikke løses enkelt, og krever at hele programvareanlegg skal gjenoppbygges fra bunnen av.
Når begge parter er fornøyd med reparasjonen som er blitt produsert, blir sårbarheten da avslørt og gitt et CVE-nummer. Disse identifiserer unikt hvert sikkerhetsproblem, og sikkerhetsproblemet arkiveres online på OSVDB.
Men hva skjer hvis ventetiden utløper? Vel, en av to ting. Leverandøren vil deretter forhandle en forlengelse med forskeren. Men hvis forskeren er misfornøyd med hvordan leverandøren har reagert eller opptrådt, eller de føler at forespørselen om forlengelse er urimelig, kan de bare publisere den på nettet uten klare klare.
I sikkerhetsfeltet er det oppvarmede debatter om hvilken metode for avsløring som er best. Noen tror at den eneste etiske og nøyaktige metoden er fullstendig avsløring. Noen mener at det er best å gi leverandørene mulighet til å løse et problem før de slippes 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 i sammenheng med Internett, er det vanskelig å unngå å snakke om DNS-protokollen. Slik endrer du DNS-serverne og forbedrer Internett-sikkerhet. Slik endrer du DNS-servere og forbedrer Internett-sikkerhet. Tenk deg dette - du våkner en vakker morgen, hell deg en kopp kaffe, og sett deg ned på datamaskinen for å komme i gang med arbeidet ditt for dagen. Før du faktisk får ... Les mer. Dette gjør det mulig for oss å oversette menneskelige lesbare webadresser (som makeuseof.com) til IP-adresser.
DNS-systemet er utrolig komplisert, og ikke bare på teknisk nivå. Det er mye tillit plassert i dette systemet. Vi stoler på at når vi skriver inn en webadresse, blir vi sendt til rett sted. Det er rett og slett mye ridning på integriteten til dette systemet.
Hvis noen kunne forstyrre eller kompromittere en DNS-forespørsel, er det mye potensial for skade. De kunne for eksempel sende folk til falske nettbaserte banksider, slik at de kunne få tak i deres nettbankinformasjon. De kunne fange opp deres e-post og Internett-trafikk gjennom et mann-i-midten-angrep, og lese innholdet. De kunne fundamentalt undergrave sikkerheten til Internett som helhet. Skummelt ting.
Dan Kaminsky er en respektert sikkerhetsforsker, med lang gjenopptak av å finne sårbarheter i kjent programvare. Men han er mest kjent for 2008s oppdagelse av kanskje det mest alvorlige sikkerhetsproblemet i DNS-systemet som noen gang har funnet. Dette ville ha tillatt noen å enkelt utføre et cache-forgiftning (eller DNS spoofing) angrep på en DNS-navneserver. De mer tekniske detaljene av dette sikkerhetsproblemet ble forklart på Def Con konferansen 2008.
Kaminsky, akutt oppmerksom på konsekvensene av å gi ut en så alvorlig feil, bestemte seg for å avsløre det til leverandørene av DNS-programvaren som er berørt av denne feilen.
Det var en rekke store DNS-produkter som ble rammet, inkludert de som ble bygget av Alcatel-Lucent, BlueCoat Technologies, Apple og Cisco. Problemet har også påvirket en rekke DNS-implementeringer som sendes med noen populære Linux / BSD-distribusjoner, inkludert de for Debian, Arch, Gentoo og FreeBSD.
Kaminsky ga dem 150 dager til å lage en rettelse, og jobbet med dem i hemmelighet for å hjelpe dem å forstå sårbarheten. Han visste at dette problemet var så alvorlig, og de potensielle skaderne var så store at det ville vært utrolig hensynsløst å offentliggjøre det uten å gi selgerne mulighet til å utstede en patch.
Forresten ble sårbarheten lekket av et uhell av sikkerhetsfirmaet Matsano i et blogginnlegg. Artikkelen ble tatt ned, men den ble speilet, og en dag etter utgivelsen utgjorde en utnytning. Dette er hvordan de hakker deg: Den murige verden av brukssett. Dette er hvordan de hakker deg: Den murige verden av brukssett. Svindlere kan bruke programvarepakker til å utnytte sårbarheter og opprett malware. Men hva er disse utnyttesettene? Hvor kommer de fra? Og hvordan kan de stoppes? Les mer var opprettet.
Kaminsky s DNS-sårbarhet oppsummerer i slutten av argumentets kritikk til fordel for ansvarlig, forskjøvet avsløring. Noen sikkerhetsproblemer - som sårbarheter med nulldag Hva er et sikkerhetsproblem i null dag? [MakeUseOf Forklarer] Hva er et sikkerhetsproblem i null dag? [MakeUseOf Forklarer] Les mer - er så signifikant at det for å offentliggjøre dem vil føre til betydelig skade.
Men det er også et overbevisende argument for ikke å gi advarsel.
Saken for full avsløring
Ved å frigjøre et sårbarhet i det åpne, låser du opp en pandoras boks hvor uønskede personer raskt og enkelt kan produsere utnyttelser og kompromittere sårbare systemer. Så hvorfor ville noen velge å gjøre det?
Det er et par grunner. For det første er leverandørene ofte ganske sakte å svare på sikkerhetsvarsler. Ved å tvinge hånden sin effektivt ved å frigjøre et sårbarhet i naturen, er de mer motiverte til å reagere raskt. Enda verre, noen er tilbøyelige til å ikke offentliggjøre hvorfor selskaper som holder seg til en hemmelighet, kan være en god ting, hvorfor selskaper som bryter en hemmelighet, kan være en god ting. Med så mye informasjon på Internett, er vi alle bekymret for potensielle sikkerhetsbrudd. Men disse bruddene kan holdes hemmelige i USA for å beskytte deg. Det høres gal, så hva skjer? Les mer det faktum at de var frakt sårbar programvare. Full avsløring tvinger dem til å være ærlige med sine kunder.
Angivelig @PepsiCo bryr seg ikke om en vuln på deres nettsted, uten å akseptere uønsket hjelp. Har allerede et seksslag. Jeg vil gjøre full avsløring
- White Packet (@WhitePacket) 4. september 2015
Men det gjør det også mulig for forbrukerne å gi et informert valg om de vil fortsette å bruke et bestemt, sårbart stykke programvare. Jeg vil tro at flertallet ikke ville.
Hva vil leverandører ha?
Leverandørene misliker ikke fullstendig avsløring.
Tross alt er det utrolig dårlig PR for dem, og det setter sine kunder i fare. De har forsøkt å incentivisere folk til å avsløre sårbarheter ansvarlig selv om bug-bounty-programmer. Disse har vært bemerkelsesverdig vellykkede, med Google betaler alene $ 1, 3 millioner i 2014 alene.
Selv om det er verdt å påpeke at noen selskaper - som Oracle Oracle, vil du slutte å sende dem feilene - her er hvorfor det er gal Oracle vil du slutte å sende dem bugs - her er hvorfor det er gal Oracle er i varmt vann over et misvisende blogginnlegg av sikkerhetschef, Mary Davidson. Denne demonstrasjonen av hvordan Oracles sikkerhetsfilosofi avviker fra det vanlige, ble ikke godt mottatt i sikkerhetssamfunnet ... Les mer - motvirke folk fra å utføre sikkerhetsforskning på deres programvare.
Men det kommer fortsatt til å være folk som insisterer på å bruke fullstendig avsløring, enten av filosofiske årsaker eller for egen fornøyelse. Ingen bug-bounty-program, uansett hvor generøs, kan motvirke det.