n-day

Podatności klasy n-day to luki już publicznie znane i naprawione przez producenta, które wciąż dają się wykorzystać na systemach bez aktualizacji. Sekurak wyjaśnia termin przez porównanie z zero-day: przy błędzie n-day exploit jest znany od wielu dni, a takie exploity są tanie, czasem wręcz darmowe, bo publicznie dostępne ^[1]. Mandiant w analizach czasu wykorzystania definiuje n-day jako podatność po raz pierwszy wykorzystaną dopiero wtedy, gdy łatka jest już dostępna ^[2].

Jak działa

Cykl życia podatności n-day zaczyna się w chwili, w której producent publikuje poprawkę i opis błędu. Od tego momentu informacja jest dostępna dla wszystkich: dla administratorów, którzy powinni zaktualizować system, i dla atakujących. Opis zmian, numer CVE, a często także PoC (proof of concept) pokazują, gdzie leży błąd. Atakującemu wystarczy znaleźć systemy, które wciąż działają na starej wersji. Nie musi odkrywać niczego nowego ani płacić za drogi exploit zero-day, dlatego ataki tego typu są dla niego tanie ^[1]. Porównanie wersji przed poprawką i po niej często wystarcza, by zrozumieć, gdzie leżał błąd.

RYS. 1Okno podatności n-day

Sekurak odróżnia trzy określenia ^[1]. Zero-day to błąd wcześniej nieznany. Przy 1-day błąd jest już załatany, ale użytkownicy nie zdążyli zaktualizować oprogramowania. Przy n-day exploit krąży od dłuższego czasu. Granica między 1-day a n-day nie jest ścisła; oba określenia opisują ten sam problem: łatka (patch) istnieje, ale nie została zainstalowana.

W WordPressie

W ekosystemie WordPressa podatności klasy n-day dotyczą przede wszystkim wtyczek. Patchstack policzył 7966 nowych podatności w ekosystemie w 2024 roku, z czego 96 procent we wtyczkach, 4 procent w motywach, a w rdzeniu 7 ^[5]. Ten sam raport podaje, że 33 procent podatności nie zostało naprawionych do chwili ich publicznego ujawnienia ^[5]. Po publikacji łatki strona z nieaktualną wtyczką staje się celem błędu n-day, a bez łatki jest narażona jeszcze bardziej. Szczególnym przypadkiem jest porzucona wtyczka, dla której łatka może się nigdy nie pojawić.

Rdzeń WordPressa ogranicza okno podatności przez automatyczne aktualizacje. Wprowadzono je w wersji 3.7, a przed wersją 5.6 domyślnie obejmowały wydania pomniejsze i pliki tłumaczeń ^[4]. Od wersji 5.6 nowe instalacje domyślnie aktualizują się automatycznie także do wydań głównych, chyba że WordPress wykryje kopię z systemu kontroli wersji ^[4]. Wtyczki i motywy aktualizują się automatycznie tylko w szczególnych przypadkach, o których decyduje zespół bezpieczeństwa WordPressa przez odpowiedź API WordPress.org, przy krytycznych podatnościach ^[4]. Pozostałe aktualizacje wtyczek zależą od administratora.

Zagrożenia i skutki

Czas między publikacją łatki a atakiem się skraca. Mandiant przeanalizował 138 podatności ujawnionych w 2023 roku i wykorzystanych w praktyce; 97 z nich było zero-day, a 41 n-day ^[2]. Średni czas od ujawnienia do wykorzystania dla całej tej grupy spadł do 5 dni, wobec 63 dni w latach 2018–2019 ^[2]. Wśród podatności n-day z 2023 roku 12 procent wykorzystano w ciągu jednego dnia, 29 procent w ciągu tygodnia, a ponad połowę w ciągu miesiąca ^[2]. Tylko 5 procent wykorzystano po upływie sześciu miesięcy, podczas gdy w poprzednim raporcie Mandianta było to 25 procent ^[2]. Nie znaczy to, że stare luki przestają być groźne: dopóki system działa na podatnej wersji, publicznie dostępny exploit n-day pozostaje skuteczny ^[1].

Dla stron WordPress oznacza to, że aktualizacja odkładana na koniec miesiąca może nie zdążyć. Patchstack opisuje przypadek podatności umożliwiającej zdalne wykonanie kodu (RCE) w Bricks Builder z początku 2024 roku: kilka godzin po ujawnieniu z wielu adresów IP ruszyły zautomatyzowane kampanie, które przejmowały podatne strony i umieszczały na nich złośliwe oprogramowanie ^[5].

Jak się bronić

Podstawą obrony jest zarządzanie poprawkami (patch management). NIST definiuje je jako proces identyfikowania, priorytetyzowania, pozyskiwania, instalowania i weryfikowania instalacji poprawek, aktualizacji i uaktualnień w całej organizacji ^[6]. Według NIST taka profilaktyka pomaga zapobiegać włamaniom, naruszeniom danych i przerwom w działaniu ^[6].

• Priorytety. CISA prowadzi katalog KEV, który określa jako autorytatywne źródło podatności wykorzystywanych w praktyce, i zaleca używać go przy ustalaniu kolejności działań w zarządzaniu podatnościami ^[3].
• Automatyzacja. Automatyczne aktualizacje rdzenia i wybranych wtyczek skracają okno, w którym działa błąd n-day ^[4].
• Inwentaryzacja. Bez listy wtyczek i ich wersji nie da się sprawdzić, czy nowa podatność dotyczy strony; pomaga skanowanie podatności.
• Osłona na czas aktualizacji. Gdy łatki nie można od razu zainstalować, wirtualne patchowanie (virtual patching) w WAF blokuje znany sposób ataku, ale nie usuwa błędu.

Historia i przykłady

W marcu 2022 roku Sekurak opisał kampanię przejmowania telefonów Samsunga i Xiaomi ^[1]. Według komunikatu Google, który przytoczył Sekurak, komercyjny dostawca systemów inwigilacji przekierowywał ruch z przeglądarki Chrome do przeglądarek fabrycznie instalowanych na telefonach, a następnie używał exploitów n-day ^[1]. Przeglądarka Samsunga działała na silniku Chromium 87 ze stycznia 2021 roku, a przeglądarka Xiaomi na Chromium 79 z grudnia 2019 roku ^[1]. Wykorzystano w nich znane i załatane w Chromium błędy CVE-2020-16040 i CVE-2021-30563 ^[1]. Użytkownik mógł mieć aktualną przeglądarkę Chrome i mimo to paść ofiarą ataku przez nieaktualizowany program producenta telefonu.