Czym jest podatność zero-day?

Podatność, exploit i atak zero-day

Te trzy pojęcia są często używane zamiennie, ale opisują różne rzeczy:

• Podatność zero-day: sama luka, nieznana dostawcy lub bez poprawki.
• Exploit zero-day: kod lub technika wykorzystująca lukę.
• Atak zero-day: exploit użyty przeciwko rzeczywistym celom.

Gdy dostawca dostarczy poprawkę, luka przestaje być zero-day i staje się znaną podatnością, często nazywaną n-day. Rozpoczyna to drugi wyścig: napastnicy analizują poprawkę i szukają systemów, które jej nie zastosowały, więc niezałatana znana podatność może wyrządzić tyle samo szkód co pierwotny zero-day.

Zero-day w Państwa zależnościach

Większość kodu we współczesnej aplikacji pochodzi z pakietów open source, a większość z nich to zależności przechodnie: wciągane przez inne pakiety, a nie wybrane przez Państwa zespół. Zero-day w którejkolwiek z nich to zero-day w Państwa produkcie.

Najbardziej znanym przykładem jest Log4Shell (CVE-2021-44228). Ujawniony w grudniu 2021 r. pozwalał napastnikowi, który kontrolował logowaną wiadomość, uruchomić dowolny kod przez Apache Log4j 2 i otrzymał maksymalną ocenę CVSS 10,0. Dla większości zespołów trudna nie była sama poprawka, lecz pytanie, które ją poprzedzało: które z naszych aplikacji zawierają log4j-core i w jakich wersjach? Log4j był zwykle zależnością zależności, a wiele zespołów spędziło dni na ustalaniu tego.

Zero-day w łańcuchu dostaw to nie zawsze błędy. W marcu 2024 r. Andres Freund znalazł tylną furtkę w wersjach xz 5.6.0 i 5.6.1 (CVE-2024-3094) po tym, jak zauważył, że logowania SSH zużywają zbyt dużo CPU. Złośliwe wydania pakietów, częsty rodzaj ataku na łańcuch dostaw, działają tak samo: pierwsze zespoły, które zainstalują zainfekowaną wersję, tak jak te dotknięte przez robaka npm Shai-Hulud, mierzą się z atakiem, o którym nie wie jeszcze żaden biuletyn ani skaner.

Jak reagować, gdy zero-day uderza w zależność

1. Ustalić, gdzie się znajduje. Wypisać każdą aplikację, obraz i wydanie zawierające dany komponent, także jako zależność przechodnią. Wymaga to dokładnego SBOM dla każdego buildu. Lockfile pomija zależności pobrane poza menedżerem pakietów, takie jak kod pobierany przez skrypty instalacyjne lub warstwy systemu operacyjnego obrazu kontenera.
2. Ustalić okres narażenia. Które buildy dostarczyły podatną wersję i od kiedy? To mówi, co należy zbadać i co zgłosić.
3. Opanować sytuację. Zastosować poprawkę lub obejście, gdy są dostępne, i powstrzymać dostarczanie podatnej wersji przez nowe buildy, gdy tylko otrzyma CVE. Zob. usuwanie CVE.
4. Sprawdzić, czy doszło do wykorzystania. Szukać oznak, że lukę wykorzystano przeciwko Państwu w okresie narażenia, i zrotować wszystkie sekrety, do których mogła dać dostęp.

Pierwsze dwa kroki szczegółowo omawia artykuł Czy to nas dotyczy?.

Czy można bronić się przed zero-day, o którym nikt nie wie?

Nie przez łatanie i nie za pomocą skanerów, ponieważ jedno i drugie wymaga, aby luka była znana. Przed ujawnieniem działa ograniczanie tego, co napastnik może zrobić ze znalezioną luką:

• Najmniejsze uprawnienia. Dawać każdemu systemowi i każdemu zadaniu CI tylko niezbędny dostęp i sekrety.
• Kontrola ruchu wychodzącego. Blokować połączenia wychodzące do hostów, których system nie potrzebuje, aby uruchomiony exploit nie mógł wysłać danych do napastnika. W buildzie CI to jedna z niewielu kontroli, które działają nawet wtedy, gdy są Państwo pierwszą ofiarą nowego złośliwego pakietu. Zob. polityki ruchu wychodzącego dla GitHub Actions.
• Obrona w głąb. Nakładać warstwy kontroli, aby jedna luka nie otwierała wszystkiego.
• Zapisy, które można później przeszukać. Gdy zero-day zostanie ujawniony, szybkość reakcji zależy od wiedzy o tym, co Państwo zbudowali i dostarczyli.

Jak pomaga CRACI

CRACI uruchamia Państwa zadania GitHub Actions na własnych runnerach i rejestruje każdy build w trakcie jego działania:

• SBOM-y z buildu wymieniają pakiety faktycznie pobrane przez każde zadanie, łącznie z ukrytymi zależnościami, które pomijają narzędzia oparte na lockfile, dzięki czemu na pytanie „gdzie to jest?” mogą Państwo odpowiedzieć na podstawie tego, co naprawdę zbudowano. Zob. SBOM-y z buildu.
• Historia buildów pokazuje każdy wcześniejszy build i jego SBOM oraz to, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, dzięki czemu znają Państwo okres narażenia.
• Bramki polityk mogą blokować build zawierający określoną CVE, aby nowy build nie dostarczył ponownie podatnej wersji.
• Polityka ruchu wychodzącego z domyślną odmową blokuje połączenia z hostami niepotrzebnymi buildowi, nawet podczas ataku, którego nikt wcześniej nie widział.

Podatności zero-day: najczęściej zadawane pytania

Czym jest podatność zero-day?

To luka bezpieczeństwa, o której napastnicy wiedzą lub którą już wykorzystują, zanim dostawca lub opiekun projektu wyda poprawkę. Nazwa odlicza dni, które obrońcy mieli na jej załatanie: zero.

Jaka jest różnica między podatnością, exploitem i atakiem zero-day?

Podatność to luka. Exploit to kod lub technika, która ją wykorzystuje. Atak to exploit użyty przeciwko rzeczywistym celom.

Kiedy zero-day przestaje być zero-day?

Gdy dostępna jest poprawka. Od tej chwili jest to znana podatność, czasem nazywana n-day, a ryzyko przenosi się na systemy, które jeszcze nie zastosowały poprawki.

Czy skaner może wykryć zero-day?

Nie przez wyszukiwanie. Skanery podatności dopasowują komponenty do opublikowanych biuletynów, a zero-day jeszcze żadnego nie ma. Skaner lub SBOM daje natomiast inwentarz, który można przeszukać w chwili pojawienia się biuletynu.

Jak sprawdzić, czy zero-day dotyczy mojego oprogramowania?

Należy przeszukać dokładny inwentarz zawartości każdego buildu i wydania, łącznie z zależnościami przechodnimi, pod kątem danego komponentu i wersji. Następnie ustalić, które wydania go dostarczyły i od kiedy, aby poznać okres narażenia.