Temaartikel: Hvad er en zero-day?

Når vi taler cybersikkerhed og specifikt sårbarheder i software, så er der få ord, der vækker større bekymring end "zero-day" – eller nuldagssårbarheder på dansk. Det betyder, at hackerne har haft et nyt våben i deres værktøjskasse i form af en sårbarhed, som først nu er blevet offentligt kendt. Som it-sikkerhedsansvarlig betyder det, at det er tid til at opdatere eller sikre sine systemer og undersøge, om man allerede er blevet ramt.

 

Denne temaartikel handler om de særlige udfordringer for it-organisationen, som følger med zero-day-sårbarheder. Artiklen beskriver også det generelle problem med sårbarheder i software. Artiklen indeholder desuden konkrete råd til at sikre sine systemer, når en zero-day bliver kendt.

 

 

Nul dage til at reagere

Navnet "zero-day" kan være lidt misvisende. Det henviser til, at man har haft nul dages forspring til at opdatere sine programmer, før sårbarheden bliver udnyttet af hackere. Men i mange tilfælde har hackere udnyttet sårbarheden, inden den bliver kendt af offentligheden. Så hackerne kan have haft flere dages, ugers eller måneders forspring.

 

Nul dage kan derfor snarere ses som den tid, man har til at opdatere eller sikre sine systemer, efter sårbarheden blev kendt. Hvis der vel at mærke findes en opdatering. I visse tilfælde bliver detaljer om sårbarheden offentliggjort, før leverandøren har en opdatering klar. Det kan derfor være nødvendigt at sikre sine systemer midlertidigt ved for eksempel at slå bestemte funktioner fra eller begrænse adgang til systemet.

 

For langt de fleste organisationer vil risikovurderingen være simpel: Hvis man har den sårbare software på sine systemer og ikke gør noget, så må man forvente, at man bliver kompromitteret, hvis man ikke allerede er det. Risikoen kan håndteres, hvis man installerer sikkerhedsopdateringen. Hvis man ikke kan opdatere systemet, må man beskytte det på anden vis. Det kan også være nødvendigt at tage andre skridt for at beskytte sine systemer, hvis leverandøren endnu ikke har en opdatering tilgængelig. I så fald bør man følge leverandørens anvisninger i det omfang, det er muligt i driftsmiljøet. Man bør samtidig være opmærksom på, om leverandøren efterfølgende justerer sine anvisninger eller frigiver en opdatering, som lukker sårbarheden.

 

For en aktør, der opdagede sårbarheden, før den blev offentligt kendt, er der to faser i udnyttelsen af sårbarheden. Den første fase er den, hvor sårbarheden udnyttes i det skjulte. For visse aktører betyder det, at sårbarheden udnyttes til at kompromittere organisationer, der har særlig høj værdi for aktøren. Angrebsforsøgene kan være manuelle eller automatiserede, og alt der er koblet til netværk kan potentielt blive ramt. I denne fase er det eneste forsvar at have en grundlæggende god sikkerhed på organisationens netværk og systemer, herunder segmenterede netværk og firewalls. Se for eksempel Cyberforsvar der virker og vejledningen Beskyt IoT-enheder.

 

Den anden fase begynder, når sårbarheden bliver offentligt kendt. Aktørerne har her et vindue til at forsøge at kompromittere så mange systemer som muligt, inden sårbarheden bliver lukket. Samtidig vil der ofte være flere aktører, som forsøger at udnytte sårbarheden. I denne fase vil der typisk ske automatiserede angrebsforsøg mod alle sårbare systemer, der er tilgængelige via internettet. Det understreger igen vigtigheden af en grundlæggende god cybersikkerhed, samt vigtigheden af at have overblik over sine it-aktiver, at reagere hurtigt og beskytte sine sårbare systemer, når en zero-day bliver kendt.

 

Man bør også være opmærksom på en tredje fase, som kan følge efter de to angrebsfaser. Når der er fundet en sårbarhed, så vil forskellige aktører ofte lede efter tilsvarende sårbarheder. Det kan både være i andre lignende produkter, men det kan også være andre sårbarheder i det samme produkt. Man bør derfor være forberedt på, at der inden for en kort tidsperiode kan komme flere kritiske opdateringer til det samme produkt. Selvom man har fulgt leverandørens første råd til at sikre sine systemer, bør man være særligt opmærksom på eventuelle opfølgninger.

 

Zero-days kræver mere end blot en patch

Det særlige ved en zero-day-sårbarhed er den korte reaktionstid. Der er aktører, som udnytter sårbarheden på det tidspunkt, hvor den bliver offentligt kendt. Det stiller flere krav til it-organisationen end blot at udrulle sikkerhedsopdateringerne som en fast rutine.

 

Kend dit miljø: Overblik over aktiver (asset management) og kendskab til installeret udstyr og software på netværket er en forudsætning for at have overblik over, hvilke systemer der kan være påvirket og sårbare i forhold til en zero-day. Det er ikke blot vigtigt at kende til systemer, som anvender den sårbare software, men også hvorvidt disse systemer er tilgængelige fra internettet. Det er ofte en forudsætning for at kunne udnytte en zero-day, at det pågældende udstyr kan tilgås fra internettet. En zero-day kan dog også udnyttes af en aktør, som på anden vis har fået fodfæste på netværket. Her kan en zero-day eksempelvis udnyttes til at eskalere adgangen fra en klient med begrænsede rettigheder til en server eller netværksudstyr med administratoradgang.

 

Kend dine komponenter og leverandører: Der har været flere eksempler på alvorlige zero-day-sårbarheder i softwarebiblioteker eller komponenter, som anvendes i mange forskellige programmer og applikationer. Det kan være vanskeligt at sikre sig et komplet overblik over, hvilke delkomponenter organisationens forskellige systemer består af. Det er derfor vigtigt at have kendskab til alle leverandører af applikationer, som bruges i organisationen, og følge deres sikkerhedsvarsler i forbindelse med sårbarheder i udbredte softwarebiblioteker. For egenudviklede applikationer er det vigtigt at have processer på plads til at opdatere eksempelvis open source-komponenter løbende og at sikre dokumentation og overblik over anvendte komponenter.

 

Kort frist til test: Fordi sårbarheden allerede bliver aktivt udnyttet, så er potentielt hver time, der går, inden systemet bliver opdateret eller på anden måde sikret, et vindue, hvor en aktør kan kompromittere systemet. Det kan derfor være nødvendigt at afveje risikoen ved at opdatere eller sikre systemet med det samme mod risikoen ved at afvente test og kvalitetssikring af opdateringen eller andre tiltag.

 

Kompromittering kan allerede være sket: Et af de særlige kendetegn ved zero-day-sårbarheder er, at sårbarheden er blevet udnyttet, når den bliver kendt. Derfor er det ikke nødvendigvis tilstrækkeligt blot at opdatere eller sikre systemerne. Det kan også være nødvendigt at undersøge, hvorvidt systemet er kompromitteret. Ofte vil softwareleverandører eller sikkerhedsfirmaer, som rapporterer om en nuldagssårbarhed, også angive "Indicators of Compromise" (IoC'er). Det vil sige tekniske indikatorer, som man kan kigge efter i sine systemer for at finde tegn på en kompromittering. Det kan derfor være en god strategi på forhånd at sikre sig, at man har adgang til de nødvendige kompetencer og logs til at udføre sådan en basal undersøgelse. Det kan i mange tilfælde blot være at afvikle nogle bestemte kommandoer eller søge i en logfil. Hvis man finder de angivne IoC'er på et system, bør man iværksætte et passende incident response og eventuelt forensics-arbejde.

 

Det kommer an på organisationens generelle risikovurdering og den specifikke risikovurdering for de sårbare systemer, præcis hvordan man vil håndtere en zero-day. For nogle organisationer vil det være nødvendigt at håndtere det som en sikkerhedshændelse, hvor man antager, at systemet er kompromitteret (assume breach). For andre kan det være en afvejning af den potentielle risiko ved et kontrolleret driftstop i forbindelse med undersøgelse og sikring af systemet kontra risikoen ved et driftstop forårsaget af en angriber, som har kompromitteret systemet.

 

Hvordan opstår sårbarheder i software?

Det er praktisk taget umuligt at udvikle software, som er fuldstændig sikkert. Jo flere funktioner, jo flere steder i programkoden kan der opstå problemer. Det samme sker, hvis kompleksiteten er høj, eller programmet skal kunne tale med andre programmer. De fleste af de sikkerhedsproblemer, som kan udnyttes af hackere, findes netop i programmets snitflader. Det er de steder, hvor programmet skal modtage noget information. Det kan være fra et andet program eller fra en bruger, som indtaster noget eller uploader en fil. Ved alle disse snitflader er det vigtigt at beskytte programmet, så det kun tager imod noget, der er lige præcis den type information, programmet forventer.

 

Et andet almindeligt sikkerhedsproblem er den måde, hvorpå programmer deles om computerens hukommelse. Her kan sårbarheder for eksempel være, hvis et program kan træde uden for det område i hukommelsen, som er afsat til det. På den måde kan en hacker så at sige få programmet til at lægge en ondsindet instruks på et område, som bruges af et andet program. Hvis dette naboprogram læser instruksen, kan programmet eksempelvis lukke hackeren ind.

 

Selve den usikre programkode, som fører til en sårbarhed, kan som regel kun rettes af dem, der udvikler softwaren. Har man adgang til kildekoden og mulighed for at udrulle en opdateret version af programmet, kan man i princippet selv rette fejlen. I de fleste tilfælde vil det dog være en leverandør eller et open source-fællesskab, som retter fejlen og gør en ny version af softwaren tilgængelig.

 

Organisationer, som selv udvikler software til intern brug, bør være opmærksomme på, at deres software sandsynligvis også indeholder potentielle sårbarheder. Hvis egenudviklet software modtager data, som kan stamme fra eksterne kilder, bør man anvende nogle af de udviklingsværktøjer og –metoder, som kan hjælpe med at opdage de mest almindelige typer sikkerhedsproblemer. Tilsvarende bør man sikre, at driftsmiljøet er konfigureret på en måde, så applikationerne har begrænsede adgange og rettigheder, og at de ikke er unødigt eksponeret mod internettet. På den måde kan man gøre det vanskeligere at udnytte en sårbarhed til at få et program til at udføre en ondsindet instruks, som kompromitterer andre dele af driftsmiljøet.

 

Hvordan bliver sårbarheder opdaget?

De fleste sårbarheder i software bliver fundet af de softwareudviklere, som arbejder med at vedligeholde og videreudvikle programmet. De har adgang til programmets kildekode og kan køre mange slags test for at afprøve programmet. Samtidig får de ofte også fejlrapporter, når programmet fejler eller crasher. Det giver udviklerne et fingerpeg om, at der kan være en del af programmet, som ikke håndterer input på en sikker måde.

 

Sårbarheder bliver også hyppigt opdaget af andre softwareleverandører i forbindelse med fejlsøgning i deres egne produkter.

 

Der findes desuden et stort antal specialister, som leder efter sårbarheder i andres software. De fleste er motiveret af nysgerrighed og rapporterer til softwareleverandøren, hvis de finder en sårbarhed. Et voksende antal softwareleverandører har desuden ordninger, hvor eksterne sikkerhedsspecialister kan få en dusør for at rapportere en sårbarhed.

 

Specialisterne har ikke adgang til fejlrapporter eller kildekode, men kan i stedet forsøge at fremprovokere fejl. De kan for eksempel forsøge at give programmets funktioner input eller data, som afviger fra det, programmet forventer. Hvis programmet crasher, kan det være et tegn på, at en del af programmet ikke er tilstrækkelig beskyttet mod uventede input.

 

En hacker kan benytte de samme metoder til at lede efter sårbarheder i software. Forskellen er, at hackeren er motiveret af at kunne udnytte sit kendskab til sårbarheden til at kompromittere systemer.

 

Hvor finder man information om zero-days?

Der er typisk to måder, hvorpå en nuldagssårbarhed bliver offentligt kendt. Ofte er softwareleverandøren blevet opmærksom på den og udsender et varsel (advisory). Men sårbarheden kan også blive beskrevet i et blogindlæg af sikkerhedsspecialister, som har opdaget, at en aktør udnytter sårbarheden.

 

Som organisation, der anvender software, er det vigtigt at følge med i, om leverandørerne frigiver sikkerhedsopdateringer. Mange leverandører følger en regelmæssig cyklus med en fast månedlig dag, som for eksempel "Patch Tuesday" (anden tirsdag i hver måned), hvor Microsoft, Adobe og en række andre leverandører udsender opdateringer.

 

I visse tilfælde er leverandøren nødt til at udsende en ekstraordinær opdatering. En nuldagssårbarhed kan være så alvorlig, at kunderne er nødt til at handle hurtigt. Derfor bør man følge med i, om leverandørerne varsler om sårbarheder i den software, man anvender.

 

Den information kan man for eksempel finde på leverandørernes sikkerheds- eller supportportaler, men der er også offentligt tilgængelige databaser, som samler alle kendte sårbarheder. Eksempelvis kan man finde sårbarheder hos National Institute of Standards and Technology (NIST), der har en database kaldet National Vulnerability Database (NVD). Her samles alle sårbarheder, som har fået tildelt et unikt ID, et Common Vulnerabilities and Exposures (CVE).