Wat is een zero-daykwetsbaarheid?

Zero-daykwetsbaarheid, -exploit en -aanval

De drie termen worden vaak door elkaar gebruikt, maar ze beschrijven verschillende dingen:

• Zero-daykwetsbaarheid: de fout zelf, onbekend bij de leverancier of zonder fix.
• Zero-dayexploit: de code of techniek die misbruik maakt van de fout.
• Zero-dayaanval: de exploit die tegen echte doelwitten wordt ingezet.

Zodra de leverancier een fix levert, is de fout geen zero-day meer maar een bekende kwetsbaarheid, vaak een n-day genoemd. Dan begint een tweede race: aanvallers bestuderen de patch en scannen op systemen die hem niet hebben toegepast, dus een bekende kwetsbaarheid die niet wordt gepatcht, kan evenveel schade aanrichten als de oorspronkelijke zero-day.

Zero-days in uw afhankelijkheden

De meeste code in een moderne applicatie komt uit open-sourcepakketten, en de meeste daarvan zijn transitieve afhankelijkheden: binnengehaald door andere pakketten in plaats van gekozen door uw team. Een zero-day in een daarvan is een zero-day in uw product.

Log4Shell (CVE-2021-44228) is het bekendste voorbeeld. De kwetsbaarheid werd in december 2021 openbaar gemaakt, liet een aanvaller die een gelogd bericht beheerste willekeurige code uitvoeren via Apache Log4j 2, en kreeg de maximale CVSS-score van 10,0. Voor de meeste teams was de fix niet het moeilijkste. Dat was de vraag ervoor: welke van onze applicaties bevatten log4j-core, en in welke versies? Log4j was meestal een afhankelijkheid van een afhankelijkheid, en veel teams waren dagen bezig om dat uit te zoeken.

Zero-days in de softwareketen zijn niet altijd bugs. In maart 2024 vond Andres Freund een backdoor in xz-versies 5.6.0 en 5.6.1 (CVE-2024-3094), nadat hij had gemerkt dat SSH-logins te veel CPU gebruikten. Kwaadaardige pakketreleases, een veelvoorkomende vorm van aanval op de softwareketen, werken op dezelfde manier: de eerste teams die een geïnfecteerde versie installeren, zoals de slachtoffers van de Shai-Hulud-npm-worm, krijgen te maken met een aanval die nog geen enkele advisory of scanner kent.

Hoe u reageert wanneer een zero-day een afhankelijkheid treft

1. Zoek uit waar het zit. Maak een lijst van elke applicatie, image en release die de getroffen component bevat, ook als transitieve afhankelijkheid. Daarvoor is een nauwkeurige SBOM per build nodig. Een lockfile mist afhankelijkheden die buiten de pakketbeheerder om worden opgehaald, zoals code die installatiescripts downloaden of de besturingssysteemlagen van een containerimage.
2. Bepaal de blootstellingsperiode. Welke builds hebben de kwetsbare versie geleverd, en sinds wanneer? Dat vertelt u wat u moet onderzoeken en wat u moet melden.
3. Dam het in. Pas de fix of een workaround toe zodra die er is, en voorkom dat nieuwe builds de kwetsbare versie leveren zodra die een CVE heeft. Zie CVE-remediatie.
4. Controleer op misbruik. Zoek naar tekenen dat de fout tijdens de blootstellingsperiode tegen u is gebruikt, en roteer alle secrets die ermee bereikbaar waren.

Zijn we getroffen? behandelt de eerste twee stappen in detail.

Kunt u zich verdedigen tegen een zero-day die niemand kent?

Niet met patchen en niet met scanners, want beide gaan ervan uit dat de fout bekend is. Wat vóór de openbaarmaking werkt, is beperken wat een aanvaller kan doen met een fout die hij vindt:

• Least privilege. Geef elk systeem en elke CI-job alleen de toegang en secrets die nodig zijn.
• Egresscontrole. Blokkeer uitgaande verbindingen naar hosts die een systeem niet nodig heeft, zodat een exploit die draait geen gegevens naar de aanvaller kan sturen. In een CI-build is dit een van de weinige maatregelen die ook werken als u het eerste slachtoffer van een nieuw kwaadaardig pakket bent. Zie egressbeleid voor GitHub Actions.
• Defense in depth. Stapel maatregelen, zodat één fout niet alles openzet.
• Vastleggingen die u later kunt doorzoeken. Wanneer de zero-day openbaar wordt, hangt de snelheid van uw reactie ervan af of u weet wat u hebt gebouwd en geleverd.

Hoe CRACI helpt

CRACI draait uw GitHub Actions-jobs op zijn eigen runners en legt elke build vast terwijl die draait:

• SBOM's tijdens de build tonen de pakketten die elke job daadwerkelijk heeft binnengehaald, inclusief de verborgen afhankelijkheden die op lockfiles gebaseerde tools missen, zodat u "waar zit het?" kunt beantwoorden aan de hand van wat echt is gebouwd. Zie SBOM's tijdens de build.
• De buildgeschiedenis toont elke eerdere build met zijn SBOM, en welke builds een kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet in welke periode u getroffen was.
• Policy gates kunnen een build blokkeren die een specifieke CVE bevat, zodat een nieuwe build de kwetsbare versie niet opnieuw levert.
• Een default-deny-egressbeleid blokkeert verbindingen met hosts die de build niet nodig heeft, zelfs tijdens een aanval die nog niemand heeft gezien.

Zero-daykwetsbaarheden: veelgestelde vragen

Wat is een zero-daykwetsbaarheid?

Een beveiligingsfout die aanvallers kennen, of al misbruiken, voordat de leverancier of maintainer een fix heeft uitgebracht. De naam telt de dagen die verdedigers hebben gehad om te patchen: nul.

Wat is het verschil tussen een zero-daykwetsbaarheid, -exploit en -aanval?

De kwetsbaarheid is de fout. De exploit is de code of techniek die er misbruik van maakt. De aanval is de exploit die tegen echte doelwitten wordt ingezet.

Wanneer is een zero-day geen zero-day meer?

Wanneer er een fix beschikbaar is. Vanaf dan is het een bekende kwetsbaarheid, soms een n-day genoemd, en verschuift het risico naar systemen die de fix nog niet hebben toegepast.

Kan een scanner een zero-day detecteren?

Niet door hem op te zoeken. Kwetsbaarheidsscanners vergelijken componenten met gepubliceerde advisories, en voor een zero-day is er nog geen. Wat een scanner of SBOM u geeft, is de inventaris die u kunt doorzoeken op het moment dat de advisory verschijnt.

Hoe kom ik erachter of een zero-day mijn software raakt?

Doorzoek een nauwkeurige inventaris van wat elke build en release bevat, inclusief transitieve afhankelijkheden, op de getroffen component en versies. Zoek vervolgens uit welke releases die hebben geleverd en sinds wanneer, zodat u de blootstellingsperiode kent.