GovCert: Derfor ventede vi en dag med at informere om Shellshock

Illustration: leowolfert/Bigstock
Statens varslingstjeneste for internettrusler, GovCert, ventede med at varsle om den kritiske Shellshock-sårbarhed til dagen efter, sårbarheden var kendt i den brede offentlighed. Varslingstjenesten har siddet på hænderne, lyder kritikken fra it-sikkerhedsekspert.

Der gik en dag fra nyheden om den kritiske Shellshock-sårbarhed ramte offentligheden, til GovCert reagerede sendte en advarsel ud til de statslige it-leverandører om sikkerhedshullet.

Shellshock er blevet sammenlignet med Heartbleed-sårbarheden, en anden stor internettrussel, der dukkede op tidligere på året. Den nye sårbarhed er ifølge it-sikkerhedseksperten Peter Kruse fra CSIS så let at udnytte, at selv et 8-årigt barn, ville kunne finde ud af det.

»Det kan ikke gå hurtigt nok, når man har en sårbarhed af denne her kaliber og specielt en sårbarhed, som også rammer z/OS (IBM’s mainframe styresystem, red.), som jo er de mainframes, som vi allerede har masser af i Danmark. Det er på alle måder superkritisk, at der kommer information ud, så folk kan få patchet det i en fart,« siger Peter Kruse til Version2.

Nyheden om Shellshock blev kendt onsdag 24. september, men GovCert, der ligger under Center for Cybersikkerhed, sendte først advarslen til statens leverandører torsdag 25. september, mens offentligheden fik besked på Center for Cybersikkerheds hjemmeside fredag 26. september.

Læs også: Shellshock: Statsligt it-system stod pivåbent efter advarsler

»Vi meldte det ud torsdag. Vi reagerer ikke på andres meldinger om, at det er farligt. Der er altid noget, der er farligt. I stedet kigger vi på, om der rent faktisk er nogen, der forsøger at udnytte sårbarheden, før vi melder ud,« siger chefen for netsikkerhedsafdelingen i Center for Cybersikkerhed, Thomas Kristmar.

Shellshock-sårbarheden var dog allerede kendt i lukkede sikkerhedskredse meget tidligere ifølge Peter Kruse.

»Hvis GovCert havde de rette kanaler, ville de have vidst det allerede mandag i sidste uge (22. september, red.), og så skal man forberede en varsling til udsendelse, når den officielle advarsel er sendt ud. Jeg kan ikke se andet end, at de har siddet på hænderne,« siger han og fortsætter:

»To dage er simpelthen for længe i et internetmiljø, hvor vi har udadvendte systemer, som er sårbare.«

Sårbarheder blev patched for sent i statslige it-systemer

På trods af advarslerne om Shellshock, lykkedes det lørdag i sidste uge for Peter Kruse at finde sårbarheder i mainframes til statens it-drift fra leverandørerne IBM og CSC. Begge virksomheder havde ifølge sikkerhedseksperten ikke sikret deres systemer mod Shellshock-buggen.

GovCert holdt i første omgang tilbage på advarslerne, fordi Shellshock-hullet skulle være patched.

»Vi havde torsdag opfattelsen af, at patchen rettede sårbarheden. Det viste sig så, at det ikke var tilfældet. Derfor gjorde vi noget ekstra ud af at informere om det efterfølgende,« siger Thomas Kristmar, der dog ikke vil udtale sig om, hvilke konkrete virksomheder, som GovCert sendte advarslerne ud til.

»Vi er ikke myndigheders og virksomheders sikkerhedsleverandør. De har selv ansvar for at holde sig opdaterede.«

Advarer først, når det er gået galt

På Center for Cybersikkerheds hjemmeside står der, at »GovCERT medvirker til, at der i staten er overblik over trusler og sårbarheder i tjenester, netværk og systemer relateret til internettet.«

Alligevel oplyste GovCert først om sårbarheden i det øjeblik, den blev udnyttet.

»Torsdag kunne vi bekræfte, at der var nogle scanninger på sårbarheden, der gjorde, at vi sendte generelle varslinger ud til vores kunder. Vi har dog ikke set nogen succesfulde kompromitteringer.«

Hos Digitaliseringsstyrelsen, der har ansvar for en lang række offentlige it-tjenester, fik man allerede en varsling fra det private it-sikkerhedsvirksomhed CSIS sent onsdag aften og en varsling fra GovCert torsdag middag. Og på baggrund af disse varslinger tog styrelsen fat i leverandørerne for at høre, hvordan de var påvirket af sårbarheden, og hvilke foranstaltninger de havde truffet på den baggrund.

»Vi har været i kontakt med leverandørerne af alle de systemer, vi er ansvarlige for. Enten har der ikke været nogen problemer i forhold til den konkrete sårbarhed, eller også har leverandørerne installeret en patch, der lukker hullerne,« siger kontorchef i Digitaliseringsstyrelsen Cecile Christensen

Synes du ikke, det er sent først at få varslingerne fra Center for Cybersikkerhed torsdag, når sårbarheden, der er blevet sammenlignet med Heartbleed, har været bredt kendt siden onsdag eftermiddag, 24. september?

»Vi læner os op ad de vurderinger, Center for Cybersikkerhed kommer med, og vi har generelt tiltro til, at de advarer, når det er relevant. Du må tale med dem om tidspunktet for, hvornår de melder den slags ud,« siger hun.

Efter at have meldt ud om Shellshock-sårbarheden til statens leverandører torsdag, ventede GovCert endnu en dag med at oplyse offentligheden om sikkerhedshullet på Center for Cybersikkerheds hjemmeside.

»Vores fokus er på den kritiske infrastruktur. Borgere og små- og mellemstore virksomheder er ikke indenfor vores arbejdsområde,« siger Thomas Kristmar.

Det er ikke første gang, at danske myndigheder er blevet kritiseret for at tøve med at informere om store internettrusler.

Da Heartbleed-buggen blev opdaget i april i år, var der i starten heller ingen officielle meldinger om, hvad man som borger skulle foretage sig, og hvilke digitale tjenester, der var ramt.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Troels Arvin

Jeg synes, at der har udviklet sig hysteri omkring ShellShock.

DHCP-klienter på visse systemer er udsat, OK.

Og visse situationer omkring CGI-scripts (men hvor mange benytter bash-baseret CGI-scripting?).

Og situationer, hvor man har erklæret, at en SSH-nøgle kun må benyttes til efterfølgende at udføre én bestemt kommando; folk, der konfigurerer sådanne setups har normalt så godt styr på tingene, at de sørger for at have flere lag af sikkerhed.

Kigger man på Peter Kruses demonstration, hvor vi angivelig er "sitting ducks", ser jeg kun en demonstration af, at bash har en fejl; men det demonstreres ikke, hvorfor at dette er et problem.

Hvis der var tale om en fejl i software, der kører med forhøjede rettigheder (såsom NTP-servere, SSH-dæmoner, ...), ville jeg bedre kunne forstå den megen omtale.

Endelig: Hvorfor skal GovCert klandres for deres kommunikation om dette? Der har været kommunikeret rigelig (læs: for meget) om det ad andre kanaler. Man skal virkelig have boet under en klippe den sidste uges tid, hvis man ikke har hørt om det. Jeg vil hellere have, at GovCert gør opmærksom på sager, som har en tendens til at blive overset.

  • 2
  • 12
#2 Lars Lundin

»Vi meldte det ud torsdag. Vi reagerer ikke på andres meldinger om, at det er farligt. Der er altid noget, der er farligt. I stedet kigger vi på, om der rent faktisk er nogen, der forsøger at udnytte sårbarheden, før vi melder ud,« siger chefen for netsikkerhedsafdelingen i Center for Cybersikkerhed, Thomas Kristmar.

Det var da en kvajet udtalelse.

Debian sendte en mail onsdag (kl. 16.06 dansk tid) om at et sikkerhedsrelateret (CVE-2014-6271) og automatisk update af bash var klar.

Herefter må man antage at alle script-kiddies går igang, og at der derfor skal patches ASAP.

Men Statens varslingstjeneste for internettrusler går måske hjem kl. 16.

  • 11
  • 0
#3 Lars Lundin

Og visse situationer omkring CGI-scripts (men hvor mange benytter bash-baseret CGI-scripting?).

Uanset hvor mange eller få der benytter bash til CGI), så er det ikke så simpelt.

Mange systemer lænker /bin/sh til bash. Hvis f.eks. et CGI-script (python, perl, et C-program (!)) kalder system() [*], så vil /bin/sh blive kaldt og sårbarheden kan udløses.

[*] I perl's tilfælde dog kun hvis systemkaldet indeholder meta-tegn, der skal evalueres af sh.

  • 5
  • 0
#4 Christian Nobel

Mange systemer lænker /bin/sh til bash. Hvis f.eks. et CGI-script (python, perl, et C-program (!)) kalder system() [*], så vil /bin/sh blive kaldt og sårbarheden kan udløses.

Hvordan rent praktisk vil det kunne lade sig gøre at udløse sårbarheden (når den eneste tilgang udefra er gennem port 80), hvis et CGI-script kalder system()?

Det fordrer vel muligheden for at kunne ændre i selve scriptet?

  • 0
  • 0
#5 Kim Bjørn Tiedemann Blogger

Kreativiteten for at udnytte sårbarheden skal nok blomstre, og historisk set har vi set, at det tager lang tid at få patchet servere rundt omkring. Det gælder sikkert også offentlige servere.

Her er lidt eksempler på shellshock kreativiteten: http://research.zscaler.com/2014/09/shellshock-attacks-spotted-in-wild.html

Jeg håber at de organisationer, som drifter for staten også bruger andre kilder end govcert :-)

  • 7
  • 0
#8 Lars Lundin

Hvordan rent praktisk vil det kunne lade sig gøre at udløse sårbarheden (når den eneste tilgang udefra er gennem port 80), hvis et CGI-script kalder system()?

Det fordrer vel muligheden for at kunne ændre i selve scriptet?

Nej, scriptet skal ikke ændres, det er det der er så smart (eller slemt hvis man står på indersiden af serveren).

De fleste ved at en web-server kigger på en såkaldt User Agent.

Den er een af mange mulige valg for data der kan overføres (via port 80) til CGI-scriptet, hvor det kan læses som en environment variabel, f.eks. $HTTP_USER_AGENT.

Under UNIX og lignende arver en proces sine environment variable fra sin 'parent' proces, dvs. enhver proces som startes (direkte eller indirekte) af CGI-scriptet, har en værdi af $HTTP_USER_AGENT som kommer udefra.

Og hvis systemet kører en /bin/sh, der er lænket til en upatchet bash, så vil et system() kald starte bash, som vil evaluere $HTTP_USER_AGENT - med den kode som kommer udefra.

(Der kan næsten ikke være nogen på V2, som ved mindre om det her end jeg, så kom gerne med en mere korrekt eller tydelig forklaring).

  • 6
  • 0
#11 Lars Lundin

Ikke-bash CGI-scripts, der kalder andre programmer, kan vel også kan være problematisk? QUERY_STRING kan vel arves og komme til bash?

import os status = os.system('printenv | grep SHELL') SHELL=/bin/bash

Ja, det er hele pointen (som jeg nævner højere oppe), og hvis ovenstående python kode udføres via CGI på et system hvor /bin/sh er lænket til en upatchet bash, så er der hul igennem.

Måske kan nogen bekræfte det, men jeg mener at der ikke engang skal CGI til.

Hvis en HTML-side inkluderer PHP, som kalder system(), f.eks. sådan her:

<?php $output = system($my_too_clever_command, $retval); ?>

så er der så vidt jeg kan se også hul igennem.

  • 0
  • 0
#13 Troels Arvin

Lars Lundin skrev bl.a.:

Måske kan nogen bekræfte det, men jeg mener at der ikke engang skal CGI til.

Hvis en HTML-side inkluderer PHP, som kalder system(), f.eks. sådan her:

<?php $output = system($my_too_clever_command, $retval); ?>

så er der så vidt jeg kan se også hul igennem.

I følge Red Hat har du ikke ret, med mindre vi taler om den ret marginale situation, hvor PHP eksekveres via CGI:

PHP scripts executed with mod_php are not affected even if they spawn subshells.

I øvrigt synes jeg, at denne her er ret sjov: Local TV Tries To Cover Shellshock Bug, Fails Miserably

Jeg er tydeligvis i mindretal i denne tråd, men jeg er bange for, at vi råber "ulv" for mange gange. Og når der så en dag virkelig er noget fælt på færde, vil folk tænke, at der nok bare igen er de tossede IT-folk, der har glemt at spise dagens beroligende medicin.

  • 0
  • 1
Log ind eller Opret konto for at kommentere