Windows CLFS (CVE-2025-29824): 0-day eskalacji

W kwietniowym „wtorku poprawek” 2025 roku Microsoft załatał CVE-2025-29824 — lukę typu use-after-free w sterowniku CLFS (Common Log File System) Windows, która była już aktywnie wykorzystywana jako 0-day. Podatność sama w sobie nie brzmi spektakularnie: to nie zdalne wykonanie kodu, lecz lokalna eskalacja uprawnień (LPE). A jednak trafiła do arsenału operatorów ransomware i jest doskonałą ilustracją, dlaczego luki „tylko lokalne” bywają równie groźne jak te zdalne — oraz dlaczego jeden komponent Windows wraca w tej roli rok po roku.

Czym jest eskalacja uprawnień i czemu jest tak cenna

Atak na organizację niemal nigdy nie kończy się na pierwszym przejętym koncie. Napastnik zwykle wchodzi jako zwykły użytkownik — przez phishing, złośliwy załącznik czy przejęte poświadczenia. Ma wtedy dostęp, ale ograniczony. Żeby zaszyfrować całą sieć, wyłączyć zabezpieczenia i dobrać się do danych, potrzebuje uprawnień administracyjnych — najlepiej SYSTEM, najwyższego poziomu na Windows.

I tu wchodzą luki LPE takie jak CVE-2025-29824: pozwalają lokalnemu użytkownikowi o niskich uprawnieniach awansować do SYSTEM. To brakujący element układanki między „mam stopę w drzwiach” a „kontroluję całą maszynę”. Dla operatora ransomware to nie ciekawostka, lecz kluczowy krok w łańcuchu ataku — dlatego 0-daye LPE są cennym, płatnym towarem w podziemiu.

Dlaczego akurat CLFS wraca jak bumerang

CLFS to wewnętrzny podsystem Windows do zarządzania logami transakcyjnymi, obecny w każdej instalacji. Problem w tym, że jego sterownik działa w jądrze systemu (kernel), parsuje złożone struktury danych i ma długą, „obrosłą” historię. To przepis na błędy obsługi pamięci: use-after-free, przepełnienia, błędy walidacji. CVE-2025-29824 nie jest pierwszym 0-dayem w CLFS — ta sama rodzina luk pojawiała się w kolejnych latach, wielokrotnie wykorzystywana przez różne grupy. To modelowy przykład komponentu wysokiego ryzyka: skomplikowany, uprzywilejowany, wszechobecny i historycznie dziurawy.

Dla obrońcy płynie stąd praktyczny wniosek: pewne komponenty (sterowniki jądra, parsery, usługi uprzywilejowane) będą źródłem luk także w przyszłości. Nie da się ich „raz naprawić” — trzeba mieć proces, który zakłada ich powracającą podatność.

Obrona: skoro nie da się przewidzieć 0-daya

Nie zapobiegniesz istnieniu kolejnego 0-daya w CLFS, ale możesz sprawić, że będzie mniej groźny:

Łataj szybko, priorytetyzuj wykorzystywane. CVE-2025-29824 od razu trafiło do katalogu CISA KEV jako aktywnie wykorzystywane — a to najwyższy priorytet w zarządzaniu podatnościami. Luka LPE w połączeniu ze zdalnym wektorem wejścia to gotowy przepis na przejęcie maszyny.

Utrudnij pierwszy krok. Eskalacja wymaga najpierw jakiegokolwiek dostępu lokalnego. Im trudniej napastnikowi wejść (odporne na phishing MFA, ograniczanie makr i wykonywalnych załączników, kontrola aplikacji), tym rzadziej w ogóle dojdzie do etapu eskalacji.

Wykrywaj eskalację, nie tylko wejście. Nagłe uzyskanie uprawnień SYSTEM przez proces użytkownika, nietypowe zachowania w jądrze, uruchamianie narzędzi po eskalacji — to sygnały dla EDR i monitoringu. Nawet jeśli 0-day ominie prewencję, dobre wykrywanie skraca czas reakcji.

Zasada minimalnych uprawnień i segmentacja. Konto SYSTEM na jednej stacji nie powinno automatycznie oznaczać dostępu do całej sieci. Hardening Active Directory i segmentacja ograniczają, jak daleko napastnik zajdzie po udanej eskalacji.

Najczęstsze pytania (FAQ)

To „tylko” lokalna eskalacja. Czy naprawdę jest groźna? Tak — bo napastnicy łączą luki. Zdalny wektor (phishing, podatna usługa) daje wejście na niskich uprawnieniach, a LPE zamienia je w pełną kontrolę nad maszyną. „Tylko lokalna” jest kluczowym ogniwem, bez którego wiele ataków ransomware by się nie powiodło. Dlatego CISA traktuje takie luki priorytetowo.

Jesteśmy załatani. Czy temat zamknięty? Dla tej konkretnej luki — tak, o ile wdrożyliście kwietniową poprawkę na wszystkich systemach (uwaga: część starszych wersji Windows dostawała łatki z opóźnieniem). Ale klasa problemu wróci: CLFS i inne sterowniki jądra będą źródłem kolejnych 0-dayów, więc liczy się proces szybkiego łatania, nie jednorazowa akcja.

Czy da się wyłączyć CLFS, żeby zamknąć ten wektor? W praktyce nie — to głęboko zintegrowany komponent systemu, od którego zależą inne funkcje. Obrona nie polega na usunięciu komponentu, lecz na szybkim łataniu, wykrywaniu eskalacji i ograniczaniu skutków przez minimalne uprawnienia i segmentację.

Jak sprawdzić, czy ktoś wykorzystał to u nas? Poszukaj w telemetrii EDR śladów procesów użytkownika, które nagle uzyskały uprawnienia SYSTEM, nietypowej aktywności sterowników i narzędzi typowych dla fazy poeksploatacji. Przy podejrzeniu potraktuj to jak incydent i uruchom analizę — eskalacja zwykle jest środkiem, nie celem.

Jak przetestować odporność na taki scenariusz? Test penetracyjny infrastruktury wewnętrznej sprawdza dokładnie ścieżkę „zwykły użytkownik → SYSTEM → kontrola sieci”: stan łatania, konfigurację, możliwości eskalacji i to, jak daleko zajdzie napastnik po zdobyciu przyczółka. To jeden z najbardziej wartościowych scenariuszy testowych.

Podsumowanie

CVE-2025-29824 przypomina, że luki „tylko lokalne” bywają decydującym ogniwem realnych ataków — a komponenty takie jak sterownik CLFS będą wracać jako źródło 0-dayów. Skoro nie da się przewidzieć następnego, obrona polega na procesie: szybkim łataniu wykorzystywanych luk, utrudnianiu pierwszego wejścia, wykrywaniu eskalacji i ograniczaniu jej skutków. Jeśli chcesz sprawdzić, jak daleko w Twojej sieci zaszedłby napastnik po zdobyciu pojedynczej stacji, przetestujemy tę ścieżkę.

Źródła i dalsza lektura: Microsoft MSRC, CISA KEV, Sekurak, Niebezpiecznik.