Hva er en zero-day-sårbarhet?

Zero-day-sårbarhet, exploit og angrep

De tre begrepene brukes ofte om hverandre, men de beskriver ulike ting:

• Zero-day-sårbarhet: selve feilen, ukjent for leverandøren eller uten retting.
• Zero-day-exploit: koden eller teknikken som utnytter feilen.
• Zero-day-angrep: exploiten brukt mot reelle mål.

Når leverandøren har levert en retting, slutter feilen å være en zero-day og blir en kjent sårbarhet, ofte kalt en n-day. Det starter et nytt kappløp: Angripere studerer patchen og skanner etter systemer som ikke har tatt den i bruk, så en kjent sårbarhet som ikke blir patchet, kan gjøre like stor skade som den opprinnelige zero-dayen.

Zero-days i avhengighetene dine

Det meste av koden i en moderne applikasjon kommer fra pakker med åpen kildekode, og de fleste av dem er transitive avhengigheter: hentet inn av andre pakker, ikke valgt av teamet ditt. En zero-day i noen av dem er en zero-day i produktet ditt.

Log4Shell (CVE-2021-44228) er det best kjente eksemplet. Den ble offentliggjort i desember 2021, lot en angriper som kontrollerte en loggmelding, kjøre vilkårlig kode gjennom Apache Log4j 2, og fikk den høyeste CVSS-scoren, 10,0. For de fleste team var det vanskelige ikke rettingen. Det var spørsmålet før den: Hvilke av applikasjonene våre inneholder log4j-core, og i hvilke versjoner? Log4j var som regel en avhengighet av en avhengighet, og mange team brukte dager på å finne det ut.

Zero-days i leverandørkjeden er ikke alltid feil. I mars 2024 fant Andres Freund en bakdør i xz-versjonene 5.6.0 og 5.6.1 (CVE-2024-3094) etter å ha lagt merke til at SSH-pålogginger brukte for mye CPU. Ondsinnede pakkeutgivelser, en vanlig form for leverandørkjedeangrep, fungerer på samme måte: De første teamene som installerer en infisert versjon, for eksempel de som ble rammet av npm-ormen Shai-Hulud, står overfor et angrep som ingen advisory eller skanner kjenner til ennå.

Slik responderer du når en zero-day rammer en avhengighet

1. Finn ut hvor den er. List opp hver applikasjon, hvert image og hver utgivelse som inneholder den berørte komponenten, også som transitiv avhengighet. Dette krever en nøyaktig SBOM for hvert bygg. En lockfile går glipp av avhengigheter hentet utenom pakkebehandleren, for eksempel kode lastet ned av installasjonsskript eller operativsystemlagene i et container-image.
2. Finn eksponeringsperioden. Hvilke bygg leverte den sårbare versjonen, og siden når? Det forteller deg hva du må undersøke, og hva du må rapportere.
3. Begrens den. Bruk rettingen eller en workaround når den finnes, og hindre at nye bygg leverer den sårbare versjonen når den har fått en CVE. Se CVE-utbedring.
4. Sjekk for utnyttelse. Se etter tegn på at feilen ble brukt mot deg i eksponeringsperioden, og bytt alle hemmeligheter den kan ha nådd.

Er vi berørt? går gjennom de to første stegene i detalj.

Kan du forsvare deg mot en zero-day ingen kjenner til?

Ikke med patching og ikke med skannere, fordi begge forutsetter at feilen er kjent. Det som virker før offentliggjøring, er å begrense hva en angriper kan gjøre med en feil vedkommende finner:

• Minste privilegium. Gi hvert system og hver CI-jobb bare den tilgangen og de hemmelighetene det trenger.
• Egress-kontroll. Blokker utgående tilkoblinger til verter et system ikke trenger, så en exploit som kjører, ikke kan sende data til angriperen. I et CI-bygg er dette en av få kontroller som virker selv om du er det første offeret for en ny ondsinnet pakke. Se egress-policyer for GitHub Actions.
• Dybdeforsvar. Legg kontroller i lag, så én feil ikke åpner alt.
• Registreringer du kan søke i senere. Når zero-dayen blir offentliggjort, avhenger responstiden din av at du vet hva du har bygget og levert.

Slik hjelper CRACI

CRACI kjører GitHub Actions-jobbene dine på egne runnere og registrerer hvert bygg mens det skjer:

• SBOM-er fra bygget viser pakkene hver jobb faktisk hentet inn, inkludert de skjulte avhengighetene som lockfile-baserte verktøy går glipp av, så du kan svare på «hvor er den?» ut fra det som faktisk ble bygget. Se SBOM-er fra bygget.
• Byggehistorikken viser hvert tidligere bygg og SBOM-en til det, og hvilke bygg som inneholdt en sårbar avhengighet, direkte eller transitiv, så du vet i hvilken periode du var berørt.
• Policy gates kan blokkere et bygg som inneholder en bestemt CVE, så et nytt bygg ikke leverer den sårbare versjonen igjen.
• En default deny-policy for egress blokkerer tilkoblinger til verter bygget ikke trenger, selv under et angrep ingen har sett før.

Zero-day-sårbarheter: ofte stilte spørsmål

Hva er en zero-day-sårbarhet?

En sikkerhetsfeil som angripere kjenner til, eller allerede utnytter, før leverandøren eller vedlikeholderen har gitt ut en retting. Navnet teller dagene forsvarerne har hatt på å patche den: null.

Hva er forskjellen på en zero-day-sårbarhet, en exploit og et angrep?

Sårbarheten er feilen. Exploiten er koden eller teknikken som utnytter den. Angrepet er exploiten brukt mot reelle mål.

Når slutter en zero-day å være en zero-day?

Når en retting er tilgjengelig. Fra da av er den en kjent sårbarhet, noen ganger kalt en n-day, og risikoen flytter seg til systemer som ennå ikke har tatt i bruk rettingen.

Kan en skanner oppdage en zero-day?

Ikke ved å slå den opp. Sårbarhetsskannere matcher komponenter mot publiserte advisories, og en zero-day har ingen ennå. Det en skanner eller SBOM gir deg, er oversikten du kan søke i i det øyeblikket advisoryen dukker opp.

Hvordan finner jeg ut om en zero-day berører programvaren min?

Søk etter den berørte komponenten og versjonene i en nøyaktig oversikt over hva hvert bygg og hver utgivelse inneholder, inkludert transitive avhengigheter. Finn deretter ut hvilke utgivelser som leverte den, og siden når, så du kjenner eksponeringsperioden.