Sikkerhedshullet, der er ældre end www

Illustration: leowolfert/Bigstock
Et 25 år gammelt sikkerhedshul har de seneste uger sat it-verdenen på den anden ende, da det viste sig blot at være ét af mange.

2014 har foreløbig budt på to alvorlige sikkerhedshuller i it-verdenen, som har vakt så meget opsigt, at de har fået deres egne navne. I foråret var det Heartbleed i sikkerhedsprotokollen OpenSSL, og nu er det Shellshock i Bash – et program, der bruges til at fortolke kommandoer i Unix-lignende systemer, og som derfor findes på bl.a. computere med styresystemerne Mac OS X og Linux.

Men hvad er risikoen for at blive ramt af netop Shellshock – og hvad er konsekvenserne, hvis det sker?

I starten var Shellshock navnet på én sårbarhed, men der opstod hurtigt forvirring, fordi en sikkerhedsekspert mente, at den fejlrettelse, som var udarbejdet, alligevel ikke lukkede sikkerhedshullet. Det viste sig så, at der var tale om to forskellige sårbarheder, og i skrivende stund er der fundet seks sårbarheder i Bash i kølvandet på Shellshock.

»Vi forventer, at der dukker flere op. Efter 25 år var der én, som fandt en sårbarhed lidt ud af det blå og åbnede for Pandoras æske,« siger research-chef Kasper Lindgaard fra sikkerhedsfirmaet Secunia.

Det første sikkerhedshul, som blev fundet, var en dum, lille fejl i 25 år gammel programkode, som ingen havde opdaget, selvom kildekoden lå frit tilgængelig. Sårbar­heden lå lige for næsen af enhver, som skulle finde på at kigge nærmere på kildekoden til Bash.

Det var der imidlertid ingen, der gjorde, før sikkerhedseksperten Stéphane Chazelas gik grundigt til værks, efter at han havde fundet en anden fejl i Bash. Ingen ved med sikkerhed, hvornår sårbarheden opstod, eller hvem der kom til at lave fejlen. Nogle peger på en tidlig ver­sion fra 1989, mens andre mener, den først dukkede op i 1993. Til sammenligning blev World Wide Web åbnet for offentligheden i 1991.

Alvorlige følger

Uanset oprindelsen så vakte Shellshock omgående stor opmærksomhed i sikkerhedskredse. Der er nemlig tale om et sikkerhedshul i et udbredt stykke software, som kan udnyttes til at få fuld adgang til systemer med masser af data. Sårbarheden blev først rapporteret til den ansvarlige for vedligeholdelsen af Bash-koden og blev ikke offentliggjort, før en opdatering, som kunne lukke hullet, var klar.

Da sårbarheden blev offentliggjort, gik der ikke længe, før sikkerhedseksperter forudså, at det kunne få alvorlige følger, hvis systemerne ikke blev opdateret i tide.

»Det er en grim sårbarhed, fordi den er så enkel at udnytte. Dermed er det også en sårbarhed, der lægger op til, at der kommer selvreplikerende kode. Vi vil se en masse scanninger efter sårbarheden, og jeg er bange for, at vi i kølvandet på det vil se noget kode, der automatisk vil forsøge at udnytte det her,« sagde sikkerhedskonsulent Peter Kruse fra it-sikkerhedsfirmaet CSIS dagen efter offentliggørelsen.

Dén forudsigelse skulle vise sig at holde stik. Sikkerhedsfirmaerne Cloudflare og FireEye har registreret tusindvis af automatiske forsøg på at finde sårbare systemer med forbindelse til internettet. En af disse scanninger har været rettet mod netværkslagringsenheder (NAS) fra firmaet QNAP. Det illustrerer også en af de ting, eksperterne frygtede ved Shellshock: at der var tale om en sårbarhed, som fandtes i mange forskellige typer systemer.

Forbrugere går fri

Dommedagsscenariet er heldigvis ikke indtruffet. Mange af de systemer, som ville være mest udsatte på grund af en sårbarhed som Shellshock, bruger nemlig ikke Bash men derimod nogle af de alternativer, som findes. Bredbåndsroutere kunne have anvendt Bash, men de fleste bruger BusyBox, som ikke indeholder Shellshock-sårbarheden.

Et system skal også være sat op på en måde, så det er muligt at få adgang til Bash og ændre miljøvariable. Det er heldigvis ikke muligt i standardopsætningen på eksempelvis pc’er med Apples Mac OS X, hvor Bash ellers også findes.

Derfor er Shellshock foreløbig endt med at være endnu en alvorlig advarsel. De systemer, som var sårbare, kan i dag opdateres, så sikkerhedshullet lukkes, men der er en risiko for, at mange overser, at deres systemer skal opdateres, fordi opmærksomheden hidtil mest har været rettet mod webservere.

Der findes nemlig en anden angrebsvinkel gennem protokollen DHCP (Dynamic Host Configuration Protocol), som en pc eksempelvis anvender til at få tildelt en IP-adresse, når den forbinder til et trådløst netværk. Hvis en hacker kontrollerer netværket og DHCP- serveren, kan DHCP udnyttes til at udløse Bash-sårbarheden. Derfor bør man opdatere sin Mac- eller Linux-baserede pc, inden man kobler sig på fremmede netværk.

Flere huller udløste forvirring

Helt præcist er der dog tale om flere sårbarheder. I de første dage efter offentliggørelsen af sårbarheden 24. september var det med til at forstærke panikken, fordi der løbende indløb meldinger om, at en opdatering ikke lukkede sikkerhedshullet fuldstændigt. Det skyldtes, at det først var efter et par dage, at det stod klart, at der var flere sårbarheder i spil, og at en enkelt opdatering derfor ikke var tilstrækkelig.

Langt de fleste producenter af systemer, hvor der var potentiale for at blive ramt af Shellshock, var dog hurtige til at melde ud, hvorvidt deres produkter var sårbare, eller endda frigive en opdatering.

Som forudset dukkede der også hurtigt eksempler på ondsindet kode (malware) op, som udnyttede Shellshock.

Heldigvis var der ikke tale om en decideret orm, der automatisk spredte sig fra én inficeret vært til den næste. Men selvom der er frigivet opdateringer, er faren ikke helt overstået. Lige nu er sikkerhedseksperter verden over i færd med at finkæmme Bash-kildekoden for flere fejl, men Bash er blot ét af mange stykker software, som indeholder programkode, der ikke er blevet set igennem for fejl gennem det 21. århundredes sikkerheds­mikroskop.

  • Godt og skidt

  • Mac OS X er sårbar, men sårbar­heden kan ikke udnyttes i standardkonfigurationen.

  • Bredbåndbåndsroutere bruger typisk BusyBox i stedet for Bash og er derfor ikke sårbare.
  • Der er frigivet opdateringer, som lukker sikkerhedshullerne til de fleste ramte systemer.
  • Sårbarheden blev overset i 25 år.
  • Indtil videre er der fundet seks sikkerhedshuller i Bash i kølvandet på den første Shellshock-sårbarhed.
  • Visse filservere – NAS-systemer – med Linux er sårbare, men risikerer at blive overset i patch-processen.

Hvad er Bash?

Bash er en kommandofortolker, som både brugere og applikationer kan benytte til at køre programmer og ændre konfigurationen af et Unix-lignende system. Bash blev lanceret i 1989 som en videreudvikling af flere andre kommandofortolkere, bl.a. Bourne
shell (sh). Bash er open source og er derfor blevet brugt i mange open source-styresystemer.*

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Carsten Olsen

Hvis en hacker kontrollerer netværket og DHCP- serveren, kan DHCP udnyttes til at udløse Bash-sårbarheden.

Som det også fremgår så er det et kæmpe problem at alle computere stoler 100% på en DHCP server. De er nemlig 0 konfigureret. D.V.S. at de får :
1- Deres IP adresse/netmaske fra en maskine på lokal nettet.
2- IP adressen på deres Default router fra en maskine på lokal nettet.
3- IP adressen på deres DNS server fra en maskine på lokal nettet.

Alså det vil sige hvis boxen der har kontakt med ISPen (som ingen "sikkeheds folk" interessere sig for) har lyst til/er inficeret med f.eks. Shellschock så hele local nettet inficeret/kan f.eks. aflyttes. Dette gælder også Linux og OSX maskiner.

Problemet bliver endnu værre hvis du tager maskinen ud på et fremmed net stadig 0 konfigureret. Ved at gøre dette stoler du 100% på det fremmede netværk (uden at kende til den fremmede netværk-administrators hensigter/evner men hvis han er windows-typen har han opdateret sin virus scanner, hvilket du så trygt kan stole på redder dig fra Hartbleed/Shellschock...siger han.... !--?)

Sune Foldager

"En dum lille fejl" hvad skal det betyde? Fejlen er vel kombinationen af to features: At CGI sætter environment vars til indkomne HTTP headers, og at hash evaluerer funktioner i sit indgående environment.

CGI har haft flere andre problemer gennem tiden.

Peter Stricker

Beklager hvis det er et dumt spørgsmål, men er det ikke begrænset hvor mange (kritiske) kommandoer man kan fyre af uden at starte med "sudo" og dermed skulle kende kodeordet?


Jo, hvis du er logget ind på systemet og afvikler kommandoer i en bash-shell, så kan du kun røre ved de filer, du har rettigheder til. Det kan nu også være slemt nok på et enkeltbrugersystem, for du vil typisk have skriverettigheder til alle dine egne filer.

Men hvis bash bliver afviklet af en anden proces, der har root-rettigheder (eller andre højt prioriterede rettigheder), så vil de kommandoer, der afvikles af denne proces, arve processens rettigheder.

Så mange af de problemer man kan opleve som følge af Shellshock skyldes afvikling af kommandoer, som man ikke selv kører, men som derimod udføres af en baggrundsproces som eksempelvis en webserver.

Claus Futtrup

Jeg får sådan en lidt underlig fornemmelse, når jeg læser at dette er BASH's skyld osv. For mig er BASH et stærkt værktøj og umiddelbart ser jeg ikke nogen problemer i dette. Poul Henning-Kamp har været ude og skælde ud på BASH for denne feature, men jeg er nu ikke så sikker på at det er BASH's fejl. Programmer som BASH skal primært være stærke værktøjer (power tools). Derimod synes jeg det er mærkeligt at andre programmer tillader at køre avancerede BASH kommandoer, uden at de i øvrigt checker hvad det er de gør, se DET er sgu da farligt. Det kan godt være at det er nemmest at fixe det i BASH. I øvrigt bliver jeg så glad over at koden nu bliver finkæmmet - det er da i realiteten en super ting.

Troels Henriksen

Derimod synes jeg det er mærkeligt at andre programmer tillader at køre avancerede BASH kommandoer, uden at de i øvrigt checker hvad det er de gør, se DET er sgu da farligt

Denne fejl aktiveres så snart bash starter - det har intet at gøre med hvad man derudover bruger bash til. Problemet forværres endvidere af at bash ofte er installeret således, at hvis man beder om /bin/sh, så får man bash uden at have bedt om det.

Log ind eller Opret konto for at kommentere