Co je zero-day zranitelnost?

Zero-day zranitelnost, exploit a útok

Tyto tři pojmy se často zaměňují, popisují ale různé věci:

• Zero-day zranitelnost: samotná chyba, o které dodavatel neví nebo pro kterou nemá opravu.
• Zero-day exploit: kód nebo technika, která chyby využívá.
• Zero-day útok: exploit použitý proti skutečným cílům.

Jakmile dodavatel vydá opravu, chyba přestává být zero-day a stává se známou zranitelností, často nazývanou n-day. Tím začíná druhý závod: útočníci studují záplatu a hledají systémy, které ji ještě nenainstalovaly, takže nezáplatovaná známá zranitelnost může napáchat stejně škody jako původní zero-day.

Zero-day zranitelnosti ve vašich závislostech

Většina kódu v moderní aplikaci pochází z open source balíčků a většina z nich jsou tranzitivní závislosti: přitáhly je jiné balíčky, nevybral je váš tým. Zero-day v kterékoli z nich je zero-day ve vašem produktu.

Nejznámějším příkladem je Log4Shell (CVE-2021-44228). Byl zveřejněn v prosinci 2021 a útočníkovi, který ovládal logovanou zprávu, umožnil spustit libovolný kód přes Apache Log4j 2; dostal maximální skóre CVSS 10.0. Pro většinu týmů nebyla nejtěžší oprava. Byla to otázka, která jí předcházela: které z našich aplikací obsahují log4j-core a v jakých verzích? Log4j byl obvykle závislostí závislosti a mnoho týmů to zjišťovalo celé dny.

Zero-day zranitelnosti v dodavatelském řetězci nejsou vždy chyby. V březnu 2024 našel Andres Freund zadní vrátka ve verzích xz 5.6.0 a 5.6.1 (CVE-2024-3094), když si všiml, že přihlášení přes SSH spotřebovávají příliš mnoho CPU. Škodlivá vydání balíčků, běžný druh útoku na dodavatelský řetězec, fungují stejně: první týmy, které nainstalují infikovanou verzi, jako ty zasažené červem Shai-Hulud v npm, čelí útoku, o kterém zatím neví žádné bezpečnostní upozornění ani skener.

Jak reagovat, když zero-day zasáhne závislost

1. Zjistěte, kde je. Sepište každou aplikaci, image a vydání, které zasaženou komponentu obsahuje, včetně podoby tranzitivní závislosti. K tomu potřebujete přesnou SBOM pro každý build. Lockfile nezachytí závislosti stažené mimo správce balíčků, například kód stažený instalačními skripty nebo vrstvy operačního systému v image kontejneru.
2. Určete období expozice. Které buildy dodaly zranitelnou verzi a od kdy? Z toho poznáte, co prověřit a co nahlásit.
3. Omezte ji. Nasaďte opravu nebo náhradní řešení, pokud existuje, a jakmile má zranitelnost CVE, zabraňte tomu, aby nové buildy zranitelnou verzi dodávaly. Viz náprava CVE.
4. Ověřte, zda došlo ke zneužití. Hledejte známky toho, že chyba byla během období expozice použita proti vám, a vyměňte všechny tajné klíče, ke kterým se mohla dostat.

Článek Týká se nás to? podrobně prochází první dva kroky.

Dá se bránit proti zero-day, o které nikdo neví?

Záplatováním ne a skenery také ne, protože obojí závisí na tom, že je chyba známá. Před zveřejněním funguje omezení toho, co může útočník s nalezenou chybou udělat:

• Nejnižší oprávnění. Dejte každému systému a každému jobu CI jen přístupy a tajné klíče, které potřebuje.
• Kontrola odchozího provozu. Blokujte odchozí spojení na hostitele, které systém nepotřebuje, aby spuštěný exploit nemohl posílat data útočníkovi. V buildu CI je to jedna z mála kontrol, které fungují, i když jste první obětí nového škodlivého balíčku. Viz egress policy pro GitHub Actions.
• Hloubková obrana. Vrstvěte kontroly tak, aby jedna chyba neotevřela všechno.
• Záznamy, ve kterých lze později hledat. Když je zero-day zveřejněna, rychlost vaší reakce závisí na tom, zda víte, co jste sestavili a dodali.

Jak pomáhá CRACI

CRACI spouští vaše joby GitHub Actions na vlastních runnerech a každý build zaznamenává v okamžiku, kdy probíhá:

• SBOM z doby buildu uvádějí balíčky, které každý job skutečně stáhl, včetně skrytých závislostí, které nástroje založené na lockfilu přehlížejí, takže na otázku „kde to je?“ odpovíte podle toho, co se skutečně sestavilo. Viz SBOM z doby buildu.
• Historie buildů ukazuje každý minulý build a jeho SBOM a také to, které buildy obsahovaly zranitelnou závislost, přímou nebo tranzitivní, takže víte, v jakém období jste byli zasaženi.
• Kontrolní brány politik (policy gates) mohou zablokovat build, který obsahuje konkrétní CVE, takže nový build zranitelnou verzi znovu nedodá.
• Egress policy nastavená na výchozí zákaz (default deny) blokuje spojení na hostitele, které build nepotřebuje, a to i během útoku, jaký ještě nikdo neviděl.

Zero-day zranitelnosti: časté dotazy

Co je zero-day zranitelnost?

Bezpečnostní chyba, o které útočníci vědí nebo ji už zneužívají dřív, než dodavatel nebo správce vydal opravu. Název počítá dny, které obránci měli na záplatování: nula.

Jaký je rozdíl mezi zero-day zranitelností, exploitem a útokem?

Zranitelnost je chyba. Exploit je kód nebo technika, která ji využívá. Útok je exploit použitý proti skutečným cílům.

Kdy zero-day přestává být zero-day?

Když je k dispozici oprava. Od té chvíle jde o známou zranitelnost, někdy nazývanou n-day, a riziko se přesouvá na systémy, které opravu ještě nenainstalovaly.

Dokáže skener odhalit zero-day?

Vyhledáním ne. Skenery zranitelností porovnávají komponenty se zveřejněnými bezpečnostními upozorněními a zero-day zatím žádné nemá. Skener nebo SBOM vám dá inventář, ve kterém můžete hledat v okamžiku, kdy upozornění vyjde.

Jak zjistím, zda zero-day zasahuje můj software?

Prohledejte přesný inventář toho, co každý build a vydání obsahuje, včetně tranzitivních závislostí, a najděte zasaženou komponentu a verze. Pak určete, která vydání ji dodala a od kdy, abyste znali období expozice.