Vad är en zero-day-sårbarhet?

Zero-day-sårbarhet, exploit och attack

De tre termerna används ofta som synonymer, men de beskriver olika saker:

• Zero-day-sårbarhet: själva bristen, okänd för leverantören eller utan rättning.
• Zero-day-exploit: koden eller tekniken som utnyttjar bristen.
• Zero-day-attack: exploiten använd mot verkliga mål.

När leverantören levererar en rättning upphör bristen att vara en zero-day och blir en känd sårbarhet, ofta kallad n-day. Det startar en andra kapplöpning: angripare studerar patchen och söker efter system som inte har installerat den, så en känd sårbarhet som lämnas opatchad kan göra lika stor skada som den ursprungliga zero-dayn.

Zero-days i dina beroenden

Det mesta av koden i en modern applikation kommer från open source-paket, och de flesta av dem är transitiva beroenden: de dras in av andra paket och har inte valts av ditt team. En zero-day i något av dem är en zero-day i din produkt.

Log4Shell (CVE-2021-44228) är det mest kända exemplet. Bristen offentliggjordes i december 2021, lät en angripare som kontrollerade ett loggat meddelande köra godtycklig kod genom Apache Log4j 2 och fick högsta möjliga CVSS, 10,0. För de flesta team var det svåra inte rättningen. Det var frågan före den: vilka av våra applikationer innehåller log4j-core, och i vilka versioner? Log4j var oftast ett beroende till ett beroende, och många team ägnade dagar åt att ta reda på det.

Zero-days i leveranskedjan är inte alltid buggar. I mars 2024 hittade Andres Freund en bakdörr i xz-versionerna 5.6.0 och 5.6.1 (CVE-2024-3094) efter att ha märkt att SSH-inloggningar använde för mycket CPU. Skadliga paketreleaser, en vanlig typ av attack mot leveranskedjan, fungerar på samma sätt: de första teamen som installerar en infekterad version, som de som drabbades av npm-masken Shai-Hulud, möter en attack som varken något säkerhetsmeddelande eller någon skanner ännu känner till.

Så agerar du när en zero-day drabbar ett beroende

1. Hitta var den finns. Lista varje applikation, avbild och release som innehåller den berörda komponenten, även som transitivt beroende. Det kräver en korrekt SBOM för varje bygge. En lockfile missar beroenden som hämtas utanför pakethanteraren, till exempel kod som laddas ned av installationsskript eller operativsystemslagren i en containeravbild.
2. Ta reda på exponeringsperioden. Vilka byggen levererade den sårbara versionen, och sedan när? Det visar vad du ska utreda och vad du ska rapportera.
3. Begränsa den. Installera rättningen eller en tillfällig lösning när det finns en, och stoppa nya byggen från att leverera den sårbara versionen när den väl har en CVE. Se Åtgärda CVE:er.
4. Kontrollera om den har utnyttjats. Leta efter tecken på att bristen använts mot dig under exponeringsperioden, och byt ut alla hemligheter den kan ha nått.

Är vi drabbade? går igenom de två första stegen i detalj.

Går det att försvara sig mot en zero-day som ingen känner till?

Inte genom patchning och inte med skannrar, eftersom båda förutsätter att bristen är känd. Det som fungerar före offentliggörandet är att begränsa vad en angripare kan göra med en brist som den hittar:

• Minsta möjliga behörighet. Ge varje system och varje CI-jobb bara den åtkomst och de hemligheter som behövs.
• Kontroll av utgående trafik. Blockera utgående anslutningar till värdar som ett system inte behöver, så att en exploit som körs inte kan skicka data till angriparen. I ett CI-bygge är det en av få kontroller som fungerar även om du är det första offret för ett nytt skadligt paket. Se Egress-policyer för GitHub Actions.
• Försvar på djupet. Lägg kontroller i flera lager så att en enda brist inte öppnar allt.
• Register du kan söka i senare. När zero-dayn offentliggörs beror din reaktionstid på om du vet vad du har byggt och levererat.

Så hjälper CRACI

CRACI kör dina GitHub Actions-jobb på egna runners och registrerar varje bygge medan det körs:

• SBOM:er från bygget listar paketen som varje jobb faktiskt drog in, inklusive de dolda beroenden som lockfile-baserade verktyg missar, så att du kan svara på "var finns den?" utifrån vad som verkligen byggdes. Se SBOM:er från bygget.
• Bygghistoriken visar varje tidigare bygge och dess SBOM, och vilka byggen som innehöll ett sårbart beroende, direkt eller transitivt, så att du vet under vilken period du var drabbad.
• Policykontroller kan blockera ett bygge som innehåller en viss CVE, så att ett nytt bygge inte levererar den sårbara versionen igen.
• En egress-policy som nekar som standard blockerar anslutningar till värdar som bygget inte behöver, även under en attack som ingen har sett tidigare.

Zero-day-sårbarheter: vanliga frågor

Vad är en zero-day-sårbarhet?

En säkerhetsbrist som angripare känner till, eller redan utnyttjar, innan leverantören eller förvaltaren har släppt en rättning. Namnet räknar dagarna som försvararna har haft på sig att patcha: noll.

Vad är skillnaden mellan en zero-day-sårbarhet, en exploit och en attack?

Sårbarheten är bristen. Exploiten är koden eller tekniken som utnyttjar den. Attacken är exploiten använd mot verkliga mål.

När upphör en zero-day att vara en zero-day?

När det finns en rättning. Från och med då är den en känd sårbarhet, ibland kallad n-day, och risken flyttas till system som ännu inte har installerat rättningen.

Kan en skanner upptäcka en zero-day?

Inte genom uppslagning. Sårbarhetsskannrar matchar komponenter mot publicerade säkerhetsmeddelanden, och för en zero-day finns inget sådant ännu. Vad en skanner eller SBOM ger dig är inventeringen att söka i så snart säkerhetsmeddelandet dyker upp.

Hur tar jag reda på om en zero-day påverkar min programvara?

Sök efter den berörda komponenten och versionerna i en korrekt inventering av vad varje bygge och release innehåller, inklusive transitiva beroenden. Ta sedan reda på vilka releaser som levererade den och sedan när, så att du vet exponeringsperioden.