Bakdør (databehandling) - Backdoor (computing)

Del av en serie om
Informasjonssikkerhet
Informasjonssikkerhetshendelser etter kategori, regnskapsår 2014.svg
Relaterte sikkerhetskategorier
Trusler
Forsvar

En bakdør er en typisk skjult metode for å omgå normal autentisering eller kryptering i en datamaskin , produkt, innebygd enhet (f.eks. En hjemmeruter ) eller dens utførelse (f.eks. Del av et kryptosystem , algoritme , brikkesett eller til og med en "homunculus datamaskin" - en liten datamaskin, innenfor en datamaskin som den som finnes i Intels AMT-teknologi ). Bakdører brukes oftest for å sikre ekstern tilgang til en datamaskin, eller for å få tilgang til ren tekst i kryptografiske systemer . Derfra kan den brukes til å få tilgang til priviligert informasjon som passord, ødelegge eller slette data på harddisker eller overføre informasjon i autoskjeddiske nettverk.

En bakdør kan ha form av en skjult del av et program, et eget program (f.eks. Back Orifice kan undergrave systemet gjennom et rootkit ), kode i fastvaren til maskinvaren eller deler av et operativsystem som Windows . Trojanske hester kan brukes til å lage sårbarheter i en enhet. En trojansk hest kan se ut til å være et helt legitimt program, men når den kjøres, utløser det en aktivitet som kan installere en bakdør. Selv om noen er hemmelig installert, er andre bakdører bevisst og allment kjent. Slike bakdører har "legitime" bruksområder, for eksempel å gi produsenten en måte å gjenopprette brukerpassord.

Mange systemer som lagrer informasjon i skyen, klarer ikke å lage nøyaktige sikkerhetstiltak. Hvis mange systemer er koblet til i skyen, kan hackere få tilgang til alle andre plattformer gjennom det mest sårbare systemet.

Standardpassord (eller andre standardopplysninger) kan fungere som bakdører hvis de ikke endres av brukeren. Noen feilsøkingsfunksjoner kan også fungere som bakdører hvis de ikke fjernes i utgivelsesversjonen.

I 1993 forsøkte USAs regjering å distribuere et krypteringssystem , Clipper -brikken , med en eksplisitt bakdør for rettshåndhevelse og nasjonal sikkerhetstilgang. Brikken var mislykket.

Oversikt

Trusselen om bakdører dukket når flerbruker og nettverk operativsystemer ble allment vedtatt. Petersen og Turn diskuterte datasubversjon i en artikkel som ble publisert i forhandlingene på AFIPS -konferansen i 1967. De bemerket en klasse med aktive infiltrasjonsangrep som bruker "trapdoor" -inngangspunkter til systemet for å omgå sikkerhetsanlegg og tillate direkte tilgang til data. Bruken av ordet falldør sammenfaller tydelig med nyere definisjoner av en bakdør. Siden ankomsten av offentlig nøkkelkryptografi har imidlertid begrepet trapdoor fått en annen betydning (se trapdoor -funksjon ), og derfor er begrepet "backdoor" nå foretrukket, først etter at begrepet trapdoor gikk ut av bruk. Mer generelt ble slike sikkerhetsbrudd diskutert lenge i en RAND Corporation -arbeidsgrupperapport publisert under sponsing av ARPA av JP Anderson og DJ Edwards i 1970.

En bakdør i et påloggingssystem kan ha form av en hardkodet bruker- og passordkombinasjon som gir tilgang til systemet. Et eksempel på denne typen bakdør ble brukt som en plot -enhet i filmen WarGames fra 1983 , der arkitekten for " WOPR " datasystem hadde satt inn et hardkodet passord som ga brukeren tilgang til systemet og til udokumenterte deler av system (spesielt en videospilllignende simuleringsmodus og direkte interaksjon med kunstig intelligens ).

Selv om antallet bakdører i systemer som bruker proprietær programvare (programvare hvis kildekode ikke er offentlig tilgjengelig) ikke er mye kreditert, blir de likevel ofte avslørt. Programmører har til og med lyktes med å installere store mengder godartet kode som påskeegg i hemmelighet i programmer, selv om slike tilfeller kan innebære offisiell utholdenhet, om ikke faktisk tillatelse.

Politikk og attribusjon

Det er en rekke kappe- og dolkhensyn som spiller inn når du fordeler ansvar.

Skjulte bakdører maskerer noen ganger som utilsiktede feil (feil) av grunner til sannsynlig fornektelse . I noen tilfeller kan disse begynne livet som en faktisk feil (utilsiktet feil), som, når de først er oppdaget, blir bevisst etterlatt uoppklarte og ikke avslørt, enten av en useriøs ansatt for personlig fordel, eller med C-nivå lederbevissthet og tilsyn.

Det er også mulig for et helt overordnet selskaps teknologibase å være skjult og usporbart besmittet av eksterne agenter (hackere), selv om dette sofistikeringsnivået antas å eksistere hovedsakelig på nivået til nasjonalstatsaktører. For eksempel, hvis en fotomask hentet fra en fotomaskeleverandør avviker fra noen få porter fra fotomaskespesifikasjonen, ville en brikkeprodusent bli hardt presset for å oppdage dette hvis det ellers er funksjonelt stille; en skjult rootkit som kjører i fotomaskens etsingsutstyr, kan vedta denne uoverensstemmelsen for fotomaskeprodusenten, og på en slik måte kan en bakdør potensielt føre til en annen. (Dette hypotetiske scenariet er i hovedsak en silisiumversjon av den uoppdagelige kompilatoren bakdør, diskutert nedenfor.)

I generelle termer, de lange avhengighets-kjeder i moderne, høyt spesialisert teknologisk økonomi og utallige menneske-elementer behandle kontrollpunkter gjør det vanskelig å entydig presisere ansvar på et tidspunkt som en skjult bakdør blir avduket.

Til og med direkte erkjennelse av ansvar må granskes nøye hvis den tilstående part blir opptatt av andre mektige interesser.

Eksempler

Ormer

Mange datamaskinsormer , for eksempel Sobig og Mydoom , installerer en bakdør på den berørte datamaskinen (vanligvis en PC på bredbånd som kjører Microsoft Windows og Microsoft Outlook ). Slike bakdører ser ut til å være installert slik at spammere kan sende useriøs e-post fra de infiserte maskinene. Andre, som for eksempel Sony / BMG rootkit som er lagt inn i hemmelighet på millioner av musikk-CDer til slutten av 2005, er ment som DRM tiltak-og, i så fall, som datainnhenting agenter , siden begge surreptitious programmer installert de rutinemessig kontaktet sentrale servere.

Et sofistikert forsøk på å plante en bakdør i Linux -kjernen , avslørt i november 2003, la til en liten og subtil kodeendring ved å undergrave revisjonskontrollsystemet . I dette tilfellet en tolinjers endringen syntes å sjekke root-tilgang tillatelser for en innringer til sys_wait4funksjon, men fordi det pleide oppdrag =i stedet for likestilling kontroll ==, er det faktisk gitt tillatelser til systemet. Denne forskjellen blir lett oversett, og kan til og med tolkes som en utilsiktet skrivefeil, snarere enn et forsettlig angrep.

Markert med gult: administrasjonspassord for bakdør skjult i koden

I januar 2014 ble det oppdaget en bakdør i visse Samsung Android -produkter, for eksempel Galaxy -enhetene. Samsungs proprietære Android -versjoner er utstyrt med en bakdør som gir ekstern tilgang til dataene som er lagret på enheten. Spesielt implementerer Samsung Android -programvaren som har ansvaret for å håndtere kommunikasjonen med modemet, ved hjelp av Samsung IPC -protokollen, en klasse forespørsler kjent som kommandoer for ekstern filserver (RFS), som lar bakdøroperatøren utføre via modemkontroll I/O -operasjoner på enhetens harddisk eller annen lagring. Siden modemet kjører Samsungs proprietære Android-programvare, er det sannsynlig at det tilbyr fjernkontroll over luften som deretter kan brukes til å utstede RFS-kommandoene og dermed få tilgang til filsystemet på enheten.

Objektkode bakdører

Vanskeligere å oppdage bakdører innebærer å endre objektkode , i stedet for kildekoden-objektkoden er mye vanskeligere å inspisere, siden den er designet for å være maskinlesbar, ikke lesbar for mennesker. Disse bakdørene kan settes inn enten direkte i objektkoden på disken, eller settes inn på et tidspunkt under kompilering, sammenkobling eller lasting-i sistnevnte tilfelle vises aldri bakdøren på disken, bare i minnet. Objektkodedører er vanskelig å oppdage ved inspeksjon av objektkoden, men oppdages enkelt ved å lete etter endringer (forskjeller), spesielt i lengde eller i kontrollsum, og kan i noen tilfeller oppdages eller analyseres ved å demontere objektkoden. Videre kan objektkode bakdører fjernes (forutsatt at kildekoden er tilgjengelig) ved å bare kompilere fra kilde på et pålitelig system.

For at slike bakdører skal unngå deteksjon, må alle eksisterende kopier av en binær undergraves, og eventuelle valideringskontrollsummer må også kompromitteres, og kilden må være utilgjengelig for å forhindre rekompilering. Alternativt kan disse andre verktøyene (lengdekontroller, differanser, kontrollsummering, demontering) i seg selv kompromitteres for å skjule bakdøren, for eksempel å oppdage at den subverterte binæren blir kontrollert og returnerer den forventede verdien, ikke den faktiske verdien. For å skjule disse ytterligere subversjonene må verktøyene også skjule endringene i seg selv - for eksempel må en undergravd sjekksommer også oppdage om den sjekker seg selv (eller andre undergravde verktøy) og returnerer falske verdier. Dette fører til omfattende endringer i systemet og verktøy som trengs for å skjule en enkelt endring.

Fordi objektkoden kan regenereres ved å kompilere (sette sammen, koble til på nytt) den opprinnelige kildekoden, krever det å lage en vedvarende objektkode bakdør (uten å endre kildekoden) å undergrave selve kompilatoren - slik at når den oppdager at den kompilerer programmet under angrep setter inn bakdøren - eller alternativt montøren, linkeren eller lasteren. Ettersom dette krever at kompilatoren undergraves, kan dette igjen løses ved å kompilere kompilatoren på nytt, fjerne innsettingskoden for bakdøren. Dette forsvaret kan igjen undergraves ved å sette en kilde-meta-bakdør i kompilatoren, slik at når den oppdager at den kompilerer seg selv, setter den inn denne meta-bakdørgeneratoren, sammen med den originale bakdørgeneratoren for det opprinnelige programmet under angrep. Etter at dette er gjort, kan kilden meta-bakdør fjernes, og kompilatoren kompileres på nytt fra den opprinnelige kilden med den kompromitterte kompilatoren kjørbar: bakdøren har blitt bootstrapped. Dette angrepet dateres til Karger & Schell (1974) , og ble populært i Thompsons artikkel fra 1984, med tittelen "Reflections on Trusting Trust"; det er derfor i daglig tale kjent som "Trusting Trust" -angrepet. Se kompilatorens bakdører nedenfor for detaljer. Analoge angrep kan målrettes mot lavere nivåer i systemet, for eksempel operativsystemet, og kan settes inn i systemet starter opp prosessen; disse er også nevnt i Karger & Schell (1974) , og eksisterer nå i form av boot -sektorvirus .

Asymmetriske bakdører

En tradisjonell bakdør er en symmetrisk bakdør: alle som finner bakdøren kan igjen bruke den. Tanken om en asymmetrisk bakdør ble introdusert av Adam Young og Moti Yung i Proceedings of Advances in Cryptology: Crypto '96 . En asymmetrisk bakdør kan bare brukes av angriperen som planter den, selv om full implementering av bakdøren blir offentlig (f.eks. Via publisering, blir oppdaget og avslørt av reverse engineering , etc.). Det er også beregningsmessig vanskelig å oppdage tilstedeværelsen av en asymmetrisk bakdør under black-box-forespørsler. Denne angrepsklassen er blitt kalt kleptografi ; de kan utføres i programvare, maskinvare (for eksempel smartkort ) eller en kombinasjon av de to. Teorien om asymmetriske bakdører er en del av et større felt som nå kalles kryptovirologi . Spesielt satte NSA inn en kleptografisk bakdør i Dual EC DRBG -standarden.

Det finnes en eksperimentell asymmetrisk bakdør i RSA -nøkkelgenerering. Denne OpenSSL RSA bakdøren, designet av Young og Yung, bruker et par vridd elliptiske kurver, og er gjort tilgjengelig.

Compiler bakdører

En sofistikert form for svart boks bakdør er en kompilator bakdør , der ikke bare en kompilator blir undergravd (for å sette inn en bakdør i et annet program, for eksempel et påloggingsprogram), men den endres ytterligere for å oppdage når den kompilerer seg selv og deretter setter inn både bakdørinnsettingskoden (rettet mot det andre programmet) og den kodemodifiserende selvkompilasjonen, som mekanismen gjennom hvilken retrovirus infiserer verten sin. Dette kan gjøres ved å endre kildekoden, og den resulterende kompromitterte kompilatoren (objektkoden) kan kompilere den originale (umodifiserte) kildekoden og sette inn seg selv: utnyttelsen har blitt oppstrammet.

Dette angrepet ble opprinnelig presentert i Karger & Schell (1974 , s. 52, avsnitt 3.4.5: "Trap Door Insertion"), som var en amerikansk luftvåpen sikkerhetsanalyse av Multics , der de beskrev et slikt angrep på en PL/ Jeg kompilator, og kaller det en "kompilertrapdør"; de nevner også en variant der systeminitialiseringskoden er modifisert for å sette inn en bakdør under oppstart , da dette er komplekst og dårlig forstått, og kaller det en "initialiseringsfelle"; Dette er nå kjent som et oppstartsektorvirus .

Dette angrepet ble deretter faktisk implementert og populært av Ken Thompson , i hans Turing Award -aksepttale i 1983 (utgitt 1984), "Reflections on Trusting Trust", som påpeker at tillit er relativt, og den eneste programvaren man virkelig kan stole på er kode hvor hvert trinn i bootstrapping har blitt inspisert. Denne bakdørsmekanismen er basert på det faktum at folk bare vurderer kildekoden (menneskeskrevet), og ikke kompilert maskinkode ( objektkode ). Et program kalt en kompilator brukes til å lage den andre fra den første, og kompilatoren er vanligvis klarert for å gjøre en ærlig jobb.

Thompsons papir beskriver en modifisert versjon av Unix C -kompilatoren som ville:

  • Sett en usynlig bakdør i Unix innlogging kommandoen når det lagt merke til at login-programmet ble utarbeidet, og som en vri
  • Legg også til denne funksjonen på en uoppdagelig måte i fremtidige kompilatorversjoner også når de er samlet.

Fordi selve kompilatoren var et kompilert program, er det svært lite sannsynlig at brukerne vil legge merke til maskinkodeinstruksjonene som utførte disse oppgavene. (På grunn av den andre oppgaven ville kompilatorens kildekode virke "ren".) Hva som er verre, i Thompsons bevis på konseptimplementering , undergravde den undergravede kompilatoren også analyseprogrammet ( demontereren ), slik at alle som undersøkte binærfiler i vanlig måte ville faktisk ikke se den virkelige koden som kjørte, men noe annet i stedet.

En oppdatert analyse av den opprinnelige utnyttelsen er gitt i Karger & Schell (2002 , avsnitt 3.2.4: Compiler trap doors), og en historisk oversikt og oversikt over litteraturen er gitt i Wheeler (2009 , seksjon 2: Bakgrunn og tilhørende arbeid ) .

Forekomster

Thompsons versjon ble, offisielt, aldri utgitt i naturen. Det antas imidlertid at en versjon ble distribuert til BBN og minst én bruk av bakdøren ble registrert. Det er spredte anekdotiske rapporter om slike bakdører i de påfølgende årene.

I august 2009 ble et slikt angrep oppdaget av Sophos laboratorier. W32/Induc-A-viruset infiserte programkompilatoren for Delphi , et Windows-programmeringsspråk. Viruset introduserte sin egen kode for samlingen av nye Delphi -programmer, slik at det kunne infisere og spre seg til mange systemer, uten kunnskap fra programvareutvikleren. Et angrep som formerer seg ved å bygge sin egen trojanske hest kan være spesielt vanskelig å oppdage. Det antas at Induc-A-viruset hadde forplantet seg i minst et år før det ble oppdaget.

Motforanstaltninger

Når et system er blitt kompromittert med en bakdør eller trojansk hest, for eksempel Trusting Trust -kompilatoren, er det veldig vanskelig for den "rettmessige" brukeren å gjenvinne kontrollen over systemet - vanligvis bør man bygge om et rent system og overføre data (men ikke kjørbare) over. Imidlertid har flere praktiske svakheter i Trusting Trust -ordningen blitt foreslått. For eksempel kan en tilstrekkelig motivert bruker nøye gjennomgå maskinkoden til den upålitelige kompilatoren før du bruker den. Som nevnt ovenfor er det måter å skjule den trojanske hesten, for eksempel å undergrave demontereren; men det finnes måter å motvirke det forsvaret på, for eksempel å skrive din egen demonterer fra bunnen av.

En generisk metode for å motvirke tillitsfullt angrep kalles Diverse Double-Compiling (DDC). Metoden krever en annen kompilator og kildekoden til kompilatoren som er under test. Denne kilden, samlet med begge kompilatorene, resulterer i to forskjellige trinn-1-kompilatorer, som imidlertid bør ha samme oppførsel. Således må den samme kilden kompilert med begge trinn-1-kompilatorer deretter resultere i to identiske trinn-2-kompilatorer. Det gis et formelt bevis på at sistnevnte sammenligning garanterer at den påståtte kildekoden og kjørbar for kompilatoren-under-test samsvarer, under noen forutsetninger. Denne metoden ble brukt av forfatteren for å bekrefte at C -kompilatoren til GCC -pakken (v. 3.0.4) ikke inneholdt noen trojan, ved bruk av icc (v. 11.0) som den forskjellige kompilatoren.

I praksis blir slike verifikasjoner ikke utført av sluttbrukere, bortsett fra under ekstreme omstendigheter ved inntrengningsdeteksjon og analyse, på grunn av sjeldenheten av slike sofistikerte angrep, og fordi programmer vanligvis distribueres i binær form. Fjerning av bakdører (inkludert kompilator bakdører) gjøres vanligvis ved ganske enkelt å bygge om et rent system. Imidlertid er de sofistikerte verifikasjonene av interesse for leverandører av operativsystemer, for å sikre at de ikke distribuerer et kompromittert system, og i høysikkerhetsinnstillinger, der slike angrep er en realistisk bekymring.

Liste over kjente bakdører

  • Back Orifice ble opprettet i 1998 av hackere fra Cult of the Dead Cow -gruppen som et fjernadministrasjonsverktøy. Det tillot Windows -datamaskiner å kunne fjernstyres over et nettverk og parodierte navnet på Microsofts BackOffice .
  • Den Dual EC DRBG kryptografisk sikker pseudo nummer generator ble avslørt i 2013 for å muligens ha en kleptographic bakdør bevisst satt inn av NSA, som også hadde den private nøkkelen til bakdør.
  • Flere bakdører i de ulisensierte kopiene av WordPress- plugin-moduler ble oppdaget i mars 2014. De ble satt inn som skjult JavaScript- kode og opprettet lydløst, for eksempel en administratorkonto i nettstedsdatabasen. En lignende ordning ble senere avslørt i Joomla -pluginet.
  • Borland Interbase versjoner 4.0 til 6.0 hadde en hardkodet bakdør, satt av utviklerne. Serverkoden inneholder en samlet bakdørskonto (brukernavn: politisk , passord: korrekt ), som kan nås via en nettverkstilkobling; en bruker som logger på med denne bakdørskontoen, kan ta full kontroll over alle Interbase -databaser. Bakdøren ble oppdaget i 2001 og en lapp ble sluppet.
  • Juniper Networks bakdør satt inn i 2008 i versjonene av fastvare ScreenOS fra 6.2.0r15 til 6.2.0r18 og fra 6.3.0r12 til 6.3.0r20 som gir enhver bruker administrativ tilgang ved bruk av et spesielt hovedpassord.
  • Flere bakdører ble oppdaget i C-DATA Optical Line Termination (OLT) -enheter. Forskere offentliggjorde funnene uten å varsle C-DATA fordi de tror bakdørene med vilje ble plassert av leverandøren.

Se også

Referanser

Videre lesning

Eksterne linker