Hvad er en zero-day-sårbarhed?

Zero-day-sårbarhed, exploit og angreb

De tre begreber bruges ofte i flæng, men de beskriver forskellige ting:

• Zero-day-sårbarhed: selve fejlen, ukendt for leverandøren eller uden en rettelse.
• Zero-day-exploit: den kode eller teknik, der udnytter fejlen.
• Zero-day-angreb: exploitet brugt mod reelle mål.

Når leverandøren leverer en rettelse, holder fejlen op med at være en zero-day og bliver en kendt sårbarhed, ofte kaldet en n-day. Det starter et nyt kapløb: Angribere studerer patchen og scanner efter systemer, der ikke har installeret den, så en kendt sårbarhed, der ikke bliver patchet, kan gøre lige så stor skade som den oprindelige zero-day.

Zero-days i dine afhængigheder

Det meste af koden i en moderne applikation kommer fra open source-pakker, og de fleste af dem er transitive afhængigheder: hentet ind af andre pakker i stedet for valgt af dit team. En zero-day i en af dem er en zero-day i dit produkt.

Log4Shell (CVE-2021-44228) er det bedst kendte eksempel. Den blev offentliggjort i december 2021 og lod en angriber, der kontrollerede en logget besked, køre vilkårlig kode gennem Apache Log4j 2, og den fik den maksimale CVSS-score på 10,0. For de fleste teams var det svære ikke rettelsen. Det var spørgsmålet før den: Hvilke af vores applikationer indeholder log4j-core, og i hvilke versioner? Log4j var som regel en afhængighed af en afhængighed, og mange teams brugte dage på at finde ud af det.

Zero-days i forsyningskæden er ikke altid fejl. I marts 2024 fandt Andres Freund en bagdør i xz-versionerne 5.6.0 og 5.6.1 (CVE-2024-3094), efter at han havde bemærket, at SSH-logins brugte for meget CPU. Ondsindede pakkereleases, en almindelig form for forsyningskædeangreb, virker på samme måde: De første teams, der installerer en inficeret version, som dem, der blev ramt af npm-ormen Shai-Hulud, står over for et angreb, som ingen advisory eller scanner kender til endnu.

Sådan reagerer du, når en zero-day rammer en afhængighed

1. Find ud af, hvor den er. Oplist hver applikation, hvert image og hver release, der indeholder den ramte komponent, også som transitiv afhængighed. Det kræver en præcis SBOM for hvert build. En lockfile overser afhængigheder, der hentes uden om pakkehåndteringen, for eksempel kode downloadet af install-scripts eller styresystemlagene i et container-image.
2. Fastlæg eksponeringsperioden. Hvilke builds leverede den sårbare version, og siden hvornår? Det fortæller dig, hvad du skal undersøge, og hvad du skal rapportere.
3. Inddæm den. Anvend rettelsen eller en workaround, når der findes en, og forhindr nye builds i at levere den sårbare version, når den har fået en CVE. Se CVE-afhjælpning.
4. Tjek for udnyttelse. Se efter tegn på, at fejlen blev brugt mod dig i eksponeringsperioden, og rotér alle secrets, den kan have nået.

Er vi ramt? gennemgår de to første trin i detaljer.

Kan du forsvare dig mod en zero-day, ingen kender?

Ikke med patching og ikke med scannere, for begge afhænger af, at fejlen er kendt. Det, der virker før offentliggørelse, er at begrænse, hvad en angriber kan gøre med en fejl, vedkommende finder:

• Mindste privilegium. Giv hvert system og hvert CI-job kun den adgang og de secrets, det har brug for.
• Egress-kontrol. Blokér udgående forbindelser til hosts, et system ikke har brug for, så et exploit, der kører, ikke kan sende data til angriberen. I et CI-build er det en af de få kontroller, der virker, selv hvis du er det første offer for en ny ondsindet pakke. Se egress-politikker til GitHub Actions.
• Dybdeforsvar. Læg kontroller i lag, så én fejl ikke åbner for det hele.
• Registreringer, du kan søge i senere. Når zero-day'en offentliggøres, afhænger din reaktionshastighed af, at du ved, hvad du har bygget og leveret.

Sådan hjælper CRACI

CRACI kører dine GitHub Actions-jobs på sine egne runnere og registrerer hvert build, mens det sker:

• SBOM'er fra buildet angiver de pakker, hvert job faktisk hentede, inklusive de skjulte afhængigheder, som lockfile-baserede værktøjer overser, så du kan svare på "hvor er den?" ud fra det, der reelt blev bygget. Se SBOM'er fra buildet.
• Build-historikken viser hvert tidligere build og dets SBOM, og hvilke builds der indeholdt en sårbar afhængighed, direkte eller transitiv, så du kender den periode, du var ramt i.
• Policy gates kan blokere et build, der indeholder en bestemt CVE, så et nyt build ikke leverer den sårbare version igen.
• En egress-politik med default deny blokerer forbindelser til hosts, buildet ikke har brug for, selv under et angreb, ingen har set før.

Zero-day-sårbarheder: ofte stillede spørgsmål

Hvad er en zero-day-sårbarhed?

En sikkerhedsfejl, som angribere kender til eller allerede udnytter, før leverandøren eller maintaineren har udgivet en rettelse. Navnet tæller de dage, forsvarerne har haft til at patche den: nul.

Hvad er forskellen på en zero-day-sårbarhed, et exploit og et angreb?

Sårbarheden er fejlen. Exploitet er den kode eller teknik, der udnytter den. Angrebet er exploitet brugt mod reelle mål.

Hvornår holder en zero-day op med at være en zero-day?

Når der findes en rettelse. Fra da af er det en kendt sårbarhed, nogle gange kaldet en n-day, og risikoen flytter til de systemer, der endnu ikke har installeret rettelsen.

Kan en scanner opdage en zero-day?

Ikke ved at slå den op. Sårbarhedsscannere matcher komponenter mod offentliggjorte advisories, og en zero-day har endnu ingen. Det, en scanner eller en SBOM giver dig, er det inventar, du kan søge i, i det øjeblik advisoryen kommer.

Hvordan finder jeg ud af, om en zero-day rammer min software?

Søg efter den ramte komponent og de ramte versioner i et præcist inventar over, hvad hvert build og hver release indeholder, inklusive transitive afhængigheder. Find derefter ud af, hvilke releases der leverede den og siden hvornår, så du kender eksponeringsperioden.