No, Mr. Sullivan, we can't stop it! There's never been a worm with that though a head or that long a tail! It's building itself, don't you understand! Already it's passed a billion bits and it's still growing. […] Yes, sir! I`m quite aware that a worm of that type is theoretically impossible! But the fact stands, he's done it, and now it's so goddamn comprehensive that it can't be killed. Not short of demolishing the net!
— John Brunner: The Shockwave Rider; Ballantine Books, 1975
Dette monsteret fra John Brunners 28 år gamle science fiction-roman fant sitt motstykke i virkeligheten den 1. november 1988. Da slapp den unge studenten Robert T. Morris jr. sin «orm» løs på det amerikanske datanettet (Reynolds 1989). Morris hadde tenkt at «ormen» skulle leve uoppdaget i nettverket og ubemerket stjele passord som den rapporterte tilbake til ham. Heldigvis var han ikke flink nok. En triviell programmeringsfeil fikk «ormen» til å kopiere seg selv nær sagt uhemmet. Datamaskinene og nettverket ble derfor raskt overbelastet av den enorme mengde kopier av Morris' «orm» som sirkulerte i nettet, og driftsansvarlige på de forskjellige nodene skjønte at et eller annet galt fra fatt. Da hadde imidlertid «ormen» klart å gjøre nettverket og mer enn 6000 datamaskiner inoperative. Det tok flere dager, og et ukjent antall arbeidstimer og dollar, å rydde opp i kaoset. Robert T. Morris jr. ble arrestert, og ble dømt av en føderal domstol for det skaden «ormen» hadde forårsaket.
Introduksjon
Det har vært forsket på ulike type orm- og viruslignende programmer helt i fra databehandlingens barndom.
På 1950-tallet var for eksempel Robert T. Morris sr. (far til førnevnte junior) en del av et team ved Bell Labs som utviklet et program med navn Darwin. Dette var et selv-reproduserende program som angrep andre programmer for å ødelegge dem (Dewdney 1985). Programmet Darwin kan derfor betraktes som stamfaren til moderne ormer slik som den hans sønn slapp løs i 1988.
For militæret har denne typen programvare særlig blitt studert med tanke på elektronisk krigføring. Men andre har tenkt seg at slike programmer også kan være nyttige, for eksempel til å lage feiltolerante og robuste datasystemer. Et tredje mulig anvendelsesområde er innenfor distribuert databehandling, der slike programmer er foreslått benyttet til å gjøre om et nettverk av selvstendige arbeidsstasjoner om til en gigantisk «supercomputer» hvor kompliserte beregninger ved hjelp av et «virus» eller en «orm» distribueres dynamisk ut til ledige arbeidsstasjoner (Schoch & Hupp 1982).
De første viruslignende programmene som beveget seg utenfor laboratoriene dukket opp tidlig på 1980-tallet. Det første programmet av denne typen for en personlig datamaskin kom i 1982. Programmet gikk under navnet Elk Cloner, og angrep den populære hjemmedatamaskinen Apple II. Elk Cloner var skrevet i 6502 assembly (maskinspråk) av Rich Skrenta, som på den tiden var 14 år gammel og gikk i 9. klasse i grunnskolen (Dewdney 1985)
Skrentas Elk Cloner infiserte boot-sektoren på en diskett. Programmet var laget slik at når det var aktivisert ville det modifisere alle nye disketter som ble satt inn i maskinen til å lage nye kopier av seg selv. Den 50. gang en infisert disk ble brukt ville Elk Cloner i tillegg vise fram et lite dikt på skjermen. Bortsett fra eventuell irritasjon over å bli avbrutt i annet arbeide av dette diktet gjorde Elk Cloner ingen bevisst skade på det systemet det hadde infisert. På enkelte systemer gikk data likevel tapt, fordi det området som programmet overskrev på disken var i bruk til andre ting.
Ordet «virus» var ikke i bruk på den tiden, så «Elk» ble kalt for en «cloner» fordi programmet «klonet» seg selv (dvs. var i stand til å føre infeksjonen videre til nye systemer ved å framstille kopier av seg selv.
Den første som brukte ordet «virus» om fenomenet var sannsynligvis forskeren Fred Cohen, som i 1983 eksperimenterte med selvkopierende kode på VAX minimaskiner fra Digital Equipment Corporation (Denning 1990).
I dag er ordet «datavirus» en del av dagligtalen til folk som bruker datamaskiner. I media brukes ofte «datavirus» for å betegne nær sagt alle former for angrep på et datasystem. Det kan imidlertid være nyttig å kunne skille mellom ulike typer angrep. I denne artikkelen brukes derfor ordet «datavirus» om en helt bestemt type angrep. Andre typer angrep går under betegnelser som «ormer», «trojanske hester», «bakdører», «bomber» og «datasnoking», og vil også bli kort beskrevet.
Virus
I biologien er virus; ørsmå, sykdomsframbringende partikler som trenger inn i levende celler. Viruset overtar kontroll over cellens stoffskifte og bruker dette til å framstille nye kopier av seg selv. Datavirus er små programfragmenter som oppfører seg tilnærmet lik den biologiske varianten.
I likhet med biologiske virus har ikke datavirus «alt» de trenger for reproduksjon. Et datavirus trenger derfor inn i andre programmer, og modifiserer dette slik at programmet begynner å produsere nye kopier av viruset. I tillegg har som regel datavirus en eller annen funksjon. Denne funksjonen kalles ofte for «payload» (last), og i de fleste tilfelle er den laget for å skade det systemet som viruset har angrepet. For eksempel kan en slik funksjon slette filer, eller stjele passord eller annen informasjon.
Datavirus omfattes av en god del mystikk, men de fleste er svært enkle i sin virkemåte. De utnytter det faktum at datamaskiner alltid utfører det et program forteller maskinen at den skal gjøre, enten det er fornuftig eller ikke.
Vi kan simulere virkemåten til et datavirus ved å lage en lapp der det står:
- Lag en kopi av denne lappen og gi den til alle du kjenner.
- Skyt deg deretter i hodet.
Lappen er her selve viruset som modifiserer mottakeren til å hjelpe det med å reprodusere seg selv (kopiere lappen og gi den videre), og til å utføre en skadelig handling (skyte seg i hodet). Poenget er at lappen selv ikke er i stand til reproduksjon - den trenger å modifisere personens adferd får å få utført dette.
Når folk opplever unormale feil på datasystemet er det lett å tro at systemet er infisert av datavirus. Men man bør være oppmerksom på at langt fra alle mystiske feil skyldes «virus». Årsaken kan like gjerne være mekaniske feil i elektronikken eller på harddisken, eller at det finnes feil i de programmene som man bruker.
Det finnes på markedet en mengde såkalte antivirus-programmer som skal gjennomsøke et datasystem etter virus og fjerne dem dersom systemet er rammet. Desverre kan det fort dukke opp nye virus, slik at man bør ikke stole alt for mye på at slik programvare gir fullgod beskyttelse. Her som ellers, viktig å unngå risikoadferd. Særlig er det vikitig å være varsom med bruken av programvare av ukjent opprinnelse.
Ormer
I likhet med virus er ormer programvare som forsøker å spre seg selv fra datasystem til datasystem. Men i motsetning til virus modifiserer en orm ingen ting for å gjøre dette. Ormer sprer seg ved rett og slett å sende meldinger som inneholder en kopi av seg selv til de systemene de forsøker å få innpass på (for eksempel som vedlegg til elektronisk post). I stedet for å modifisere eksisterende programmer slik at de blir usikre, benytter ormer seg av de sikkerhetshullene som allerede finnes i eksisterende programvare (vi kan si at "ormen kryper gjennom" slike sikkerhetshull).
Fordi en godt laget orm meget raskt kan spre seg til en enorm mengde maskiner koblet sammen i nett, kan et angrep som baserer seg på en orm være ekstremt vanskelig å bekjempe. Selv om man fjerner den på ens egen maskin, slår av strømmen til maskinen, eller sletter disken og installerer all programvare på nytt fra en «ren» backup, så risikerer man at ormen dukker opp på nytt så snart maskinen kobles til nettverket igjen dersom ikke sikkerhetshullet den slapp inn gjennom i første omgang er tettet i mellomtiden.
Som Robert T. Morris jr. har vist oss, en orm ute av kontroll kan være en svært kraftig og svært destruktiv mekanisme. Det vil være interessant å se mer forskning på autentiserings- og beskyttelsesmekanismer som gjør det enkelt og sikkert å utnytte «orm»-programmer til å distribuere beregninger på nettverk av arbeidsstasjoner.
Trojanske hester
Trojanske hester er programmer som gir seg ut for å være legitime, nyttige programmer. Som regel har de samme navn og tilsynelatende samme oppførsel som systemets standardprogrammer. I tillegg vil de ha en annen «skjult» effekt som bare er kjent for inntrengeren. Ved «lure» en annen bruker til å utføre programmet aktiviseres denne skjulte effekten.
Trojanske hester kan bare plantes i systemet av noen som allerede har adgang til det. «Noen» kan være en inntrenger som har banet seg adgang ved passord-snoking, en usosial legitim bruker, eller en uskyldig bruker som installerer et nytt program uten å vite at det er en trojansk hest.
Formålet med å plante en trojansk hest er nesten alltid å skaffe seg flere rettigheter på systemet. Ved hjelp av en trojansk hest er det mulig for en inntrenger å forvandle en passord-løs gjestekonto til en konto med fulle systemrettigheter.
Et angrep med en trojansk hest kan gjøres svært så banalt. En angriper kan rett og slett gi en uskyldig bruker en diskett med et slikt program, eller distribuere programmet som elektronisk post. Dersom offeret ukritisk kjører programmet er skaden et faktum.
De fleste moderne operativsystemer benytter seg av oppslagslister (eng. «searchpaths»). Dette er en liste av kataloger som systemet skal søke gjennom når et program skal startes. Oppslagslister har den fordelen at brukeren ikke trenger å huske eller å skrive katalognavnet fullt ut for å få startet et program. Denne mekanismen kan imidlertid også utnyttes til å plante programmer som er trojanske hester. Alt inntrengeren trenger å gjøre, er å plassere sin versjon av et vanlig standardprogram i en eller annen katalog som ligger i offerets oppslagsliste, og offeret får inntrengerens versjon, i steden for systemets.
På et større anlegg kjører også operativsystemet selv en rekke programmer. Dette er administrative rutiner som ofte kjøres automatisk om natten når ingen andre bruker maskinen. Dersom en innbryter klarer å «lure» operativsystemet til å kjøre et av sine programmer isteden for systemets, kan han lett skaffe seg rettigheter som systemadministrator på maskinen. Dette er lett å få til, dersom katalogene som inngår i systemets søkeliste ikke er tilstrekkelig beskyttet. Uheldigvis distribueres minst en versjon av UNIX (BSD 4.2) uten slik beskyttelse. Dersom systemadministrator ikke passer på å endre dette kan hvem som helst skaffe seg rett til å gjøre hva som helst med anlegget.
Følgene retningslinjer vil redusere faren for at et system blir angrepet fra en trojansk hest:
- Vær kritisk med hvordan du setter opp oppslagslisten din. Forsøk å ha den så kort og oversiktelig som mulig, og unngå kataloger som er allment skrivbare. På et UNIX-system kan du sjekke oppslagslisten ved å skrive echo $path. Dersom tegnet prikk («.») ligger først i listen, er du svært sårbar for et angrep fra en trojansk hest.
- Sørg for at oppslagslisten for systemadministrasjonskontoen er absolutt minimal. Inkluder aldri kataloger hvor vanlige brukere har skriveadgang. Sjekk regelmessig at disse katalogene fortsatt er skrivebeskyttet.
- På et UNIX-system, lag aldri setuid shellscripts.
- Bruk aldri systemadministrasjonskontoen til annet enn systemadministrasjon. Test aldri nye eller ukjente brukerprogrammer fra denne kontoen.
- Kjør ikke programmer av ukjent opprinnelse.
Bakdører
En bakdør er en adgang til systemet som kortslutter alle de vanlige kontrollmekanismene. Slike smutthull kan f.eks. legges inn i programmer av den som lager dem. Enkelte ganger kan formålet med å lage en bakdør være uetisk, men ofte legges det bakdører inn i programmer for å forenkle feilsøking i utviklingsfasen, og fordi programmer sjelden er feilfrie, finner man det praktisk å beholde den der selv når produksjonsversjonen av programmet distribueres. Det var en slik bakdør i programmet sendmail Robert T. Morris jr. benyttet for å spre sin «orm».
Det er vanskelig å sikre seg mot bakdører. De er i sin natur udokumenterte, og som oftest må man lese kildekoden for i det hele tatt oppdage at en bakdør eksisterer. I enkelte tilfelle er det ikke en gang tilstrekkelig å lese kildekoden: I sin Turing-forelesning demonstrerer Ken Thompson (1984) hvordan det er mulig å lage en bakdør uten at denne synes i kildekoden, men som like fullt var i stand til å overleve rekompileringer.
Thompsons forelesning illustrerer på en svært overbevisende måte hvor sårbare alle former for generelt programerbare systemer er for programvare som er plantet i systemet med det formål å ødelegge sikkerheten i systemet.
Bomber
Bomber er mekanismer som minner mye om bakdører. I likhet med bakdører er de vanligvis plassert i programmer av den opprinnelige programmereren, men til forskjell fra dem er de ikke laget for å finne feil, men for å lage feil.
Den vanligste kilden til bomber er misfornøyde ansatte, som f.eks. innstiller «bomben» slik at den utløses av en eller annen ytre begivenhet (typisk: at navnet til den misfornøyde ikke lenger figurerer i datamaskinens kjøring av firmaets lønnsutbetalinger). Logiske bomber virker vanligvis bare en gang. Når de detonerer kan de for eksempel være programmert til å slette så mye som mulig av systemet hvor de er installert, og deretter seg selv.
I det siste har det også dukket opp bomber i underskogen av gratisprogrammer for mikrodatamaskiner. Dette er en variant av «trojanske hester» som utgir seg for å utføre noe nyttig, men som eksploderer etter et bestemt intervall. Den mest kjente slike bomben er en program som utgir seg for å være en ny versjon av det populære gratisprogramet arc. De fire første gangene programmet kjører fungerer det identisk med originalen, men den femte gangen det startes reformaterer det harddisken.
Mange av programmene som leter etter datavirus på mikromaskiner, forsøker også å lete etter og advare om mulige logiske bomber. Retningslinjene for å unngå slike bomber er de samme som for å beskytte seg mot virus.
DoS
DoS er her en forkortelse for Denial of Service, eller tjenestenektelse. Et DoS-angrep tar altså sikte på å forhindre at legitime brukere av en maskin eller tjeneste kan nyttiggjøre seg denne.
For en maskin tilkoblet Internett kan for eksempel et DoS-angrep være å sende så mange (falske) forespørsler til maskinen at den blir overbelastet, og dermed ikke lenger er i stand til å besvare (legitime) forespørsler.
I utgangspunktet er det svært vanskelig å skille mellom falske og legitime forespørsler. Det kan derfor være svært vanskelig å beskytte et datasystem mot DoS-angrep.
Snoker
Datasnoking er en av de mest vanlige formenene for angrep. En datasnok er rett og slett en som forsøker å snoke til seg data og informasjon han eller hun ikke har rett til å se. Det kan være en som utbytter feil eller svakheter i datamaskinens operativsystem for å tilgang til data som er beskyttet mot innsyn, eller det kan være en person som ved hjelp av såkalt sosial ingeniørkunst narrer andre til å gi fra seg slik informasjon.
Et av de fremste målene for en datasnok er adgangskontrollkoder (for eksempel passord). Med dette kan snoken logge seg på datamaskinen. Når snoken først har kommet seg inn på maskinen kan han eller hun lettere snoke videre etter annen informasjon - f.eks. brukernavn og passord til andre kontoer med kraftigere privilegier.
Snoker opererer på mange forskjellige måter. De kan kikke over skulderen din når du logger deg på maskinen, de kan ringe deg opp å be deg om å oppgi passordet under dekke av å være en operatør eller overordnet, eller de kan lete etter passord som glemske brukere har en tendens til å skrive ned på løse papirlapper eller på omslagssidene i manualene sine. Når en snok allerede har brutt seg inn på én konto kan han eller hun ofte plukke opp nye passord ved å søke i brukernes filer, i elektroniske postkasser, og i «script» som brukeren benytter til batchkjøringer og automatisk innlogging på andre systemer.
Ofte kan en snok bryte seg inn i et system ved å gjette «åpenlyse» passord. Ved mange innbrudd har systemansvarlig eller brukere nærmest innvitert til innbrudd ved å la det finnes åpne kontoer uten passord, eller med passord som «guest» eller «demo». Typiske kontonavn en passord-snok først vil angripe på denne måten er: sys, system, root, rt, demo, test, guest, sysdiag, ean, nobody, floppy-user og anonymous.
En mer tålmodig og ressurs-sterk snok kan tenkes å ta i bruk kraftigere virkemidler. F.eks. kan han eller hun programmere en mikromaskin til forsøke tusenvis av forskjellige passord som hentes fra en ordliste. En slikt ordliste vil typisk inneholde vanlige egennavn, bilmerker, drikkevarer, sportsgrener, persongalleriet fra «Lord of the Rings» samt en vanlig engelsk og norsk ordliste. En snok med lokalkunnskap vil supplere listen med brukerens personnumer, fødselsdato, telefonnummer, bilnummer, navn på ektefelle, barn og kjæledyr i forlengs og baklengs utgave. En undersøkelse av passord på Lawrence Berkeley Laboratory (Stoll 1988) viste at omkring 20 prosent av passordene kunne finnes på denne måten.
Elektroniske oppslagstavler (BBS-systemer) blir stadig mer og mer vanlig. Bare i Oslo finnes det nå nærmere 40 slike konferansesystemer og meldingsformidlingssystemer som drives på hobbybasis. Mange av disse systemene er konstruert slik at brukerens passord er tilgjengelig for systemadministrator i klartekst. Det vil derfor være en enkel sak for en skruppel-løs snok å etablere en elektronisk oppslagstavle og bruke denne til å stjele passord fra sine brukere. Dersom noen av disse benytter samme passord på en annen datamaskin, vil snoken få adgang til denne.
Nesten alle kjente tilfelle av innbrudd på minimaskiner og stormaskiner i Norge har dreid seg om enkle former for passord-snoking. I praksis har det vist seg at dersom passordene som gir utenforstående adgang til systemet er sikre, er systemet relativt sikkert. Dersom man ikke kan logge seg på, er det lite en inntrenger får gjort. Derfor er det viktig å passe godt på sine passord:
- Skift passord ofte, helst en gang i måneden.
- Bruk forskjellige passord på forskjellige maskiner. Bruk aldri samme passord i et oppslagstavlesystem og på en maskin du benytter i jobb-sammenheng.
- Bruk ikke passord som kan knekkes ved hjelp av ordlister. En enkel mekanisme for å hindre dette er å benytte passord som består av både bokstaver og andre tegn (f.eks. kontroll-tegn).
- Bruk ikke passord som er så kryptiske at du ikke selv klarer å huske dem. Skriv aldri passordet ned på papirlapper. Fall ikke for fristelsen til å bruke «rare ord» som finnes på plakater eller oppslag på kontoret ditt.
- Del ikke passordet ditt med andre. Et passord som er «lånt» ut kan ofte komme lenger enn du regnet med.
- Ha ikke passord liggende i klartekst i modefiler og shellscripts.
Prisen for sikkerhet
De fleste av de datasystemene vi bruker er ikke konstruert med spesiell tanke på sikkerhet. I steden er systemene laget for samarbeid, utveksling av informasjon og effektiv deling og fordeling av resursser. Jeg må innrømme at jeg liker at slike kriteria ligger bak designvalgene av enkelte av de systemene jeg bruker; og jeg er ikke like sikker på at jeg vil være like glad i den systemfilosofien som ville blitt resultatet dersom frykt og mistenksomhet skulle være det underliggende prinsipp.
Det er imidlertid liten tvil om at det bør være mulig å konstruere lett tilgjengelige systemer som er sikre og mindre sårbare enn de vi har i dag. Hvordan man skal kunne ivareta sikkerhet i tillegg til åpenhet er et område som hittil har vært lite fokusert i arbeidet med å lage samvirke mellom åpne systemer (Open Systems Interconnection). Dette bør bli et interessant område for framtidig forskning på dette feltet.
Litteratur
Denning, Peter (1990): Computers Under Attack: Intruders, Worms, and Viruses; ACM Press, 1990
Dewdney, Alexander Keewatin (1985): Computer Recreations. A Core War Bestiary of Viruses, Worms, and Other Threats to Computer Memories; Scientific American, March 1985, s. 14-23.
Hoffman, Lance (1990): Rogue Programs: Viruses, Worms, and Trojan Horses; Van Norstrand Reinhold, 1990
Reid, Brian (1987): Reflections on Some Recent Widespread Computer Break-Ins; Communications of the ACM, vol. 30, no. 2 (February 1987), p. 103.
Reynolds, J. (1989): The Helminthiasis of the Internet; RFC1135, https://tools.ietf.org/html/rfc1135
Ross, Andrew (1990): Hacking Away at the Counterculture; I: The Cybercultures Reader. David Bell and Barbara M. Kennedy, (red.). Ss. 254-267. London: Routledge
Schoch, John F. & Jon A. Hupp (1982): The "Worm" Programs - Early Experience with a Distributed Computation; Communications of the ACM, vol. 25, no. 3 (March 1982), p. 172.
Stoll, Clifford (1988): Stalking the Wily Hacker; Communications of the ACM, vol. 31, no. 5 (May 1988), p. 484.
Thompson, Ken (1984): Reflections on Trusting Trust; Communications of the ACM, vol. 37, no. 8 (August 1984), p. 761.
Først publisert i: Computerworld Norge, nr. 43, 1988, oppdatert 24. august 2003.