SCRIPT, LØGN OG WEB-TJENERE

av Gisle Hannemyr

Innholdsfortegnelse

Webtjener-sikkerhet
Slik ble ble innbruddet gjennomført
Forslag til forholdsregler

Natt til søndag den 6. april 1997 ble mer enn 11 tusen hjemmesider tilhørende bedrifter og privatpersoner slettet på en web-tjener tilhørende Telenor Nextel. En triviell programmeringsfeil i et script utviklet av en av Telenors kunder ga utenforstående adgang til å sende en kommando som slettet samtlige sider gjennom en såkalt bakdør, og feilkonfigurasjon gjorde at kommandoer sendt på denne måten ble akseptert av web-tjeneren. En del av kommentarene omkring hendelsen i Computerworld gir etter min mening et skjevt bilde av hva det var som skjedde og hvorledes man skal kunne unngå slike ting i fremtiden. Jeg ber derfor Computerworld om spalteplass til en kommentar.

Lenger nede på siden vil jeg i beskrive i detalj hvordan inntrengeren gikk frem å gjennomføre datainnbruddet, samt skissere noen enkle forholdsregler for å sikre delte webtjenere. Først vil jeg imidlertid drøfte sikkerhetsfilosofi for slike webtjenere med utgangspunkt i denne konkrete hendelsen.

Webtjener-sikkerhet

Computerworld har omtalt innbruddet i to separate reportasjer i Computerworld #13 (11. april 1997):

I en notis på side 8 («Siktet») påstår Telenors talsmann Arne Cartridge at «det var en script-feil» i et program utviklet av en kunde som muliggjorde innbruddet. Dette er i beste fall en halv sannhet.
På side 10 («Ingen bombe») følger to forskere fra Norsk Regnesentral opp dette, ved å utrope script-feilen til «halsbrekkende programmering» og ved å komme med (i og for seg utmerkede) tips om hvordan en sikrer kvalitet i design, valg av språk, programmering, installasjon og feilretting av silke script. Men ved å vektlegge kvaliteten i selve programmeringsarbeidet i den grad NR-forskerene gjør, hjelper de uforvarende Telenor Nextel med å spre den misforståelsen at web-tjenere ikke kan være sikrere enn de programmer og de script som måtte befinne seg på dem.

Ja – det var feil i et script. Og denne feilen ble utnyttet – enten det nå var en ondsinnet handling eller (som vedkommende selv hevder) et «arbeidsuhell» – til å slette samtlige web-sider på Telenor Nextels web-tjener. Det er ikke lenger noen tvil om hva som faktisk skjedde i denne saken.

Men der hvor Telenor Nextel tåkelegger, og der hvor NR-forskerene bommer på poenget, er hvor alvorlig og hvor ødeleggende en slikt scriptfeil bør være. Et webhotell av den typen Telenor Nextel opererer, med en rekke store innholdsleverandører som Dagbladet, Hjemmet-Mortensen og Nettavisen som gjester, huser bokstavelig talt hundretusenvis av programner, websider og script. Og fordi web er et dynamisk medium, går det ikke en dag uten at et script videreutvikles eller skiftes ut. Utviklingen og vedlikeholdet av scriptene gjøres til dels av Telenor Nextels egne folk, dels av kundene, og dels av selskaper og free-lancere som kundene leier inn. Knapt noe universitet eller høyskole gir fagutdanning i web-programmering og sikkerhet i åpne systemer, og derfor er selv faginformatikerene blant web-programmererene i dag selvlærte. Men svært mange av de som i dag utvikler innhold for web er rekruttert fra reklamebransjen eller har bakgrunn fra grafisk design. De er flinke til å lage slående og visuelle web-sider, men de har aldri blitt lært opp til å tenke datasikkerhet, og fordi de foretrekker grafiske grensesnitt er de knapt oppmerksom på hvilke krefter det underliggende operativsystem og kommandoskall kan romme.

Det er selvsagt dumt at det lages script som inneholder feil, og jeg er hjertens enig med NR-forskerne i at kvaliteten på dette gjerne kan bli bedre.

Men gitt knappheten på virkelig gode web-programmerere, og gitt den store mengde script det er å holde styr på, så er det neppe realistisk å forutsette at alle web-script på en større web-installasjon skal være 100% feilfri. Selvsagt er dette noe som bør tilstrebes, men dersom sikkerheten ved installasjonen skal gjøres avhengig av slik perfeksjon, så er man sanynligvis nødt til å begrense mengden script man kjører til et lite antall som så kontinuerlig overvåkes og kvalitetssikres av et toppkvalifisert team spesialister på web-sikkerhet. Slikt er nok vanskelig å gjennomføre når konkurransen er så hard som den er på web-publisering i dag, spesielt dersom en skal operere med realistiske inntjeningskrav i en markedsøkonomi.

Gitt slike rammebetingelser må en søke etter alternative tilnærmingsmåter. Jeg mener at det eneste som er realistisk, er å ta det for gitt at script vil inneholde feil, og at enkeltprogrammer kan bli kompromittert. Ja, dersom man tillater kunder og andre utenforstående å installere programmer på ens maskiner – slik alle som tilbyr web-hoteller og web-publisering i dag gjør – så må man også ta høyde for at den risiko at utro tjenere som leies inn for utviklingsoppdrag bevisst plasserer «bakdører» i programmene de skriver (jeg presiserer at det ikke finnes noe grunnlag for å tro at noe slikt har skjedd i denne saken).

Det som skjedde hos Telenor Nextel den 6. april var at en triviell og relativt vanlig programmeringsfeil ga full adgang til det underliggende operativsystemet og kommandoskallet. Å sikre at det ikke finnes en eneste feil i de hundretusener av programmer, script og html-sider som en slik web-tjener huser er en enorm oppgave. Å sikre maskinen slik at slike feil kun gir en kontrollert og begrenset adgang til operativsystemet og kommandoskallet er en langt mindre og mer overkommelig oppgave.

Det som var årsaken til at Telenor Nextel web-tjener lot seg kompromittere, var at Telenor hadde unnlatt å sikre tjeneren på noen som helst måte. Døren sto ulåst, bordet var dekket, og den første og beste programmeringsfeil stilte døren på vidt gap.

Slik ble ble innbruddet gjennomført

Den umiddlelbare årsaken til at innbruddet lot seg gjennomføre, var – slik Telenors Arne Cartridge og forskerne fra NR beskriver – en programmeringsfeil i et script utviklet av en av Telenors kunder som en del av en større webløsning.

Programmeringsfeilen befant seg i ett av de mange tusen script som utgjorde tjenestene på Telenor Nextels web-tjener. Scriptet var svært enkelt, og hadde som oppgave å sende data fra et bestillingsskjema til noen som skulle effektuere bestillingen.

Den som har laget scripet har ønsket at det skal gjøre følgende:

Scriptet får overlevert et sett med navgitte parametre som en del av URL-strengen. Denne URL-strengen vil ved normal bruk bli generert av den HTML-form som spør en bruker om navn, adresse og hva som bestilles.
De data som brukeren har oppgitt blir så splittet opp i navn/verdi-par, «+»-tegn blir oversatt til blanke og eventuelle hex-koder blir oversatt til ASCII.
En epost-adresse, som blir overført som en parameter med navnet «7» blir tilordnet variabelen $adresse, det åpnes en såkalt «pipe» til shell for å sende epost til denne adressen — og de andre parameterene blir samlet sammen i en variabel ($brev) og blir innholdet i det brev som sendes.
Når brevet er sendt vises det en kvittering: «Din bestilling er mottatt.» for brukeren.

Problemet med scriptet er at en kommando som inneholder e-mail-adressen $adresse overlates til shellet uten at det er gjort noe forsøk på å sjekke at det faktisk er en gyldig epost-adresse eller noe helt annet.

Setningen:

   open (MAIL,"|mail $adresse");

legger, slik Telenors web-tjener var konfigurert, adgangen til systemet temmelig åpent for den person som bestemmer hva som står i feltet $adresse.

Det store problemet er nemlig ikke programmeringsfeilen, men det faktum at Telenor hadde konfigurert webtjeneren sin slik at alle filene på denne hadde samme eier (nobody). Dermed gir en programmeringsfeil hos en kunde automatisk adgang til alle filene som befinner seg på maskinen - uavhengig av hvilken kunde som har lastet dem opp.

Vedkommende kan slette de filer han vil (slik det skjedde her), men hullet kunne like gjerne vært brukt til å bryte seg inn helt inn på webtjeneren ved å utplassere egne programmer som fungerer som «bakdører». (Telenor har nok rett når de sier at dette ikke skjedde i den aktuelle situasjon — men det skyldes i så fall at vedkommende inntrenger ikke hadde noen interesse av å gjøre det).

Hvordan kan man så bestemme hva som skal stå i feltet $adresse?

Vel, ganske enkelt ved selv å bygge parametrene til den URL man bruker for å aktivisere scriptet. Her er hvordan man sletter filer — i tre enkle steg:

Start opp Netscape Navigator eller Microsoft IE.
I feltet «Location» (Netscape) eller «Adresse» (Microsoft IE) skriver du følgende URL:
http://www.doktoronline.no/ta_i_mot_best.pl?7=a%3b+rm+-rf+%2f
Trykk på <enter>-tasten.

Den aktuelle kommando i programmet ser nå slik ut:

   open (MAIL,"|mail a;rm -rf /");

som betyr følgende. Utfør først kommandoen «mail a» (send elektronisk post til adressen «a») — utfør deretter kommandoen «rm -rf /» (slett alle filer på disken).

Andre observasjoner:

All den tid sikkerhetshullet lot seg aktivisere via en URL, så ville det vært uproblematisk utføre hærverket anyonymt — eller å rigge en «booby-trap» hvor man fikk en uvitende og utenforstående tredjepart til å detonere bomben.
Å slette en masse filer vekker en del oppsikt, men all den tid det finnes backup så er skaden minimal. Sikkerhetshullet var av en slik karakter at det i realiteten ga full brukeradgang til den aktuelle web-tjener. Dersom en slik «bakdør» hadde blitt utnyttet i all stillhet kunne en forbrytersk sinnet person gjort langt større skade enn det som var tilfelle her.

Forslag til forholdsregler

Nedenfor listes en del enkle forholdsregler som kan bidra til å innkapsle og skadebegrense programmeringsfeil i script og html-sider til den bruker som gjør feilen, slik at en feil hos en enkelt bruker ikke kompromitterer sikkerheten for en hel web-tjener.

Web-tjenere er ikke arbeidsstasjoner. Fjern alle interaktive programmer fra web-tjeneren. Funksjonaliteten skal være strippet, slik at kun de omgivelser som det er behov for til å ha en fungerende web skal finnes på maskinen. Rike omgivelser er den vanligste årsaken til sikkerhetsbrudd. Svært mange standardprogrammer kan gjøre langt mye mer enn de fleste er klar over. Når programmene ikke er tilgjengelig kan de ikke brukes på denne måten. Dersom webben du har bruk for spesiell programstøtte fra omgivelsene, så unngå standardprogram som åpner opp for interaktiv bruk. Strippede spesialprogram hvor man kan studere kildekoden og verifisere at de kun gjør den jobben de er laget for å gjøre er å foretrekke.
La verken egne utviklere eller kunder/brukere installere filer direkte på produksjonsmaskinen. La all installasjon og vedlikehold av kode på produksjonsmaskonen foregå via et «staging»-tjener hvor kunder og utviklere kan teste og «previewe» webber. Når ting skal publiseres flyttes tingene fra «staging»-tjener og til publiseringsmaskinen av et publiseringssystem — ikke av kunden selv. Slipper du kunder løs på produksjonsmaskinen er du prisgitt kundens kompetanse og integritet. 99% er sikkert både ærlige og flinke, men ett dårlig eple er nok til at hele kurven råtner.
Kjør ikke script under standard-shell. La disse i stedet kjøre under et restricted shell hvor alt som ikke eksplisitt er tillatt — er forbudt. På denne måten kan ikke et script «lures» til å foreta operasjoner rettet mot omgivelsene som utvikleren ikke har tenkt på og som operatøren eksplisitt har åpnet for.
Vær nøye med eierskap og privilegiebit. Ha eget eierskap for hver enkelt kunde. La ikke under noen omstendighet noe script ha privilegier til å lese, endre, utføre eller slette annet enn egne filer. Dermed kan ikke kundene (bevisst eller ubevisst) ødelegge for hverandre, og selv om en uærlig medarbeider hos en kunde klarer å smugle inn en bakdør, så vil skaden begrenses til denne ene kunden.

I tillegg kommer det en rekke ting som kan gjøres med brannvegger, med varslingssystemer og med ulike former for «tuning» av en installasjon, men listen over er i alle fall en start dersom man ønsker å forhindre at en skade i form av en programmeringsfeil utvikler seg til en katastrofe.

Basert på artikler opprinnelig publisert i: Digi, 11. april 1997 og i Computerworld, 25. april 1997.
Copyright © 1997 Gisle Hannemyr. Noen rettigheter reservert.
Dette verk gjøres tilgjengelig under en Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.