Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 412 z 487

Autor: Wojciech Ciemski

Nowy zero-day w Windows RasMan (DoS) – darmowe, nieoficjalne łatki 0patch. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

W systemach Windows wykryto nową podatność zero-day w usłudze Remote Access Connection Manager (RasMan). Błąd pozwala nieuprzywilejowanemu lokalnemu użytkownikowi doprowadzić do awaryjnego zakończenia działania usługi (DoS). Luka nie ma jeszcze identyfikatora CVE i nie została załatana przez Microsoft w momencie pisania artykułu. ACROS Security (platforma 0patch) udostępniło darmowe mikrolatki dla szerokiego zakresu wersji Windows, od 7 po 11 oraz od Windows Server 2008 R2 do Server 2025.

W skrócie

  • Co: Zero-day DoS w RasMan (Windows). Brak oficjalnej łatki od Microsoft.
  • Kto: Odkrycie/opracowanie obejścia – ACROS Security / 0patch; dostępne darmowe mikrolatki.
  • Kiedy: Publiczne ujawnienie i mikrolatki 12 grudnia 2025 r. (CET).
  • Wpływ: Lokalny DoS na RasMan; w łańcuchu z CVE-2025-59230 (EoP) pozwala na eskalację do SYSTEM (gdy RasMan nie działa).
  • Zakres: Windows 7–11 i Server 2008 R2–2025 (0patch publikuje listę wspieranych buildów).
  • Status: Dostępny eksploit i relacje prasowe; brak daty oficjalnej poprawki.

Kontekst / historia / powiązania

W październiku 2025 r. Microsoft załatał w RasMan CVE-2025-59230 (eskalacja uprawnień). ACROS, analizując techniki wyzyskania tej luki, zauważyło, że skuteczny łańcuch ataku wymaga zatrzymania RasMan, aby napastnik mógł podszyć się pod jego punkt RPC. To doprowadziło do wykrycia oddzielnej, niezałatanej podatności DoS, która umożliwia lokalnemu użytkownikowi awaryjne wyłączenie RasMan na żądanie.

Analiza techniczna / szczegóły luki

  • Błąd logiczny w obsłudze listy cyklicznej: podczas iteracji po circular linked list w RasMan sprawdzany jest wskaźnik na bieżący element. Gdy napastnik spowoduje, że wskaźnik jest NULL, funkcja nie wychodzi z pętli, tylko próbuje odczytać „następny element” z adresu NULL, co kończy się naruszeniem dostępu i crashem procesu usługi. Mikrolatka 0patch dodaje warunek wyjścia przy wykryciu NULL.
  • Warunki ataku: wymagany jest lokalny dostęp (bez uprawnień admina); skutkiem jest DoS RasMan. Sam w sobie błąd nie daje RCE, ale w połączeniu z luką typu EoP (np. CVE-2025-59230) umożliwia rejestrację fałszywego endpointu RPC RasMan i wykonanie poleceń z uprawnieniami SYSTEM.
  • Zasięg wersji: ACROS opublikowało binarne mikrolatki dla wielu wspieranych i niewspieranych edycji Windows (w tym Windows 7/Server 2008 R2 oraz Windows 11/Server 2025).

Praktyczne konsekwencje / ryzyko

  • Środowiska z VPN/PPPoE/dial-up: RasMan zarządza połączeniami zdalnymi (m.in. VPN). Crash usługi może powodować przerwy w łączności z zasobami firmowymi, utratę sesji i wpływ na SLA.
  • Łańcuchowanie z EoP: Zero-day DoS jest szczególnie groźny w połączeniu z CVE-2025-59230 oraz innymi świeżymi EoP w RasMan (grudniowe CVE z kategorii EoP), co ułatwia eskalację do SYSTEM.
  • Dostępność exploita / presja operacyjna: media branżowe wskazują na publicznie dostępny exploit i brak jasnej deklaracji Microsoftu co do terminu poprawki – to zwiększa ekspozycję organizacji.

Rekomendacje operacyjne / co zrobić teraz

  1. Rozważ wdrożenie mikrolatek 0patch (FREE do czasu oficjalnej łatki) w środowiskach o podwyższonym ryzyku, zwłaszcza tam, gdzie RasMan jest krytyczny dla VPN. Wymaga konta i agenta 0patch; poprawki stosują się bez restartu.
  2. Natychmiast załatataj i wymuś zgodność z październikową poprawką CVE-2025-59230 oraz innymi bieżącymi EoP dotyczącymi RasMan – ogranicza to możliwość łańcuchowania. (Sprawdź stan aktualizacji w narzędziach zarządzania poprawkami/WSUS/Intune).
  3. Twarde ograniczenie lokalnych uprawnień:
    • Minimalizuj liczbę lokalnych kont z interaktywnym logowaniem na serwerach/VDI.
    • Egzekwuj Just-Enough-Administration i WDAC/Device Guard dla krytycznych hostów.
  4. Monitoring i detekcja:
    • Alertuj na nagłe zatrzymania RasMan (np. Service Control Manager – 7031/7034) i nietypowe ponowne uruchomienia usługi. Koreluj z logami RPC/Win32k/EDR i kontami użytkowników.
    • W SOC dodaj reguły wykrywające utratę łączności VPN korelowaną z lokalnym logowaniem na hostach brzegowych.
  5. Tymczasowe obejścia ryzyka operacyjnego:
    • Tam gdzie to możliwe, redukuj powierzchnię: wyłącz RasMan na hostach, które nie używają VPN/PPPoE (uważaj na zależności!).
    • Segmentuj dostęp do portów/IPC/RPC hostów z RasMan i wymuś MFA dla sesji zdalnych.
  6. Gotowość na patch Microsoftu:
    • Zaplanuj pilne okno serwisowe na wdrożenie poprawki, gdy tylko się pojawi, i testy regresji dla klientów VPN i NAC.

Różnice / porównania z innymi przypadkami

  • Ten zero-day dotyczy DoS (awaryjne wyłączenie RasMan), a nie bezpośredniej EoP/RCE. Ryzyko eskalacji pojawia się przy łańcuchowaniu z EoP CVE-2025-59230 (i potencjalnie innymi EoP w RasMan).
  • W grudniu 2025 ZDI odnotowuje nowe CVE EoP w RasMan (inne numery niż 59230) – nie są to DoS, ale podkreślają, że komponent pozostaje w obszarze zainteresowania badaczy/atakujących.

Podsumowanie / kluczowe wnioski

  • Zero-day DoS w RasMan pozostaje niezałatany przez Microsoft; dostępne są darmowe mikrolatki 0patch dla szerokiego spektrum wersji Windows.
  • Największe ryzyko wynika z łańcuchowania tej luki z CVE-2025-59230 (EoP) – daje to realną drogę do SYSTEM. Priorytetem jest pełna zgodność patchowa i monitoring usług.
  • Organizacje zależne od VPN przez Windows powinny rozważyć tymczasowe wdrożenie 0patch, wzmocnić kontrole dostępu lokalnego i telemetrię usług, a także przygotować się na szybkie wdrożenie oficjalnej łatki, gdy się ukaże.

Źródła / bibliografia

  • BleepingComputer – „New Windows RasMan zero-day flaw gets free, unofficial patches”, 12 grudnia 2025. (BleepingComputer)
  • 0patch (ACROS Security) – „Free Micropatches for Windows Remote Access Connection Manager DoS (0day)”, 12 grudnia 2025. (0patch Blog)
  • NVD – CVE-2025-59230 szczegóły (EoP w RasMan), październik 2025. (NVD)
  • The Register – „Microsoft RasMan 0-Day gets unofficial patch; working exploit out”, 12 grudnia 2025. (The Register)
  • ZDI – „The December 2025 Security Update Review” (lista CVE, w tym nowe EoP w RasMan), 9 grudnia 2025. (Zero Day Initiative)

MITRE publikuje listę „CWE Top 25 (2025)” – najgroźniejsze słabości oprogramowania i co z nimi zrobić

Wprowadzenie do problemu / definicja luki

MITRE opublikowało listę 2025 CWE Top 25 Most Dangerous Software Weaknesses – zestawienie klas błędów, które najczęściej i najdotkliwiej prowadzą do podatności w realnych produktach. Ranking powstaje na podstawie publicznych rekordów CVE i łączy częstość mapowań na daną CWE z średnią surowością (CVSS v3), aby wyliczyć „Danger Score” i ułożyć kolejność słabości. W 2025 r. na szczycie ponownie znalazł się CWE-79 (XSS), dalej CWE-89 (SQL Injection) i CWE-352 (CSRF).

W skrócie

  • XSS #1, SQLi #2, CSRF #3; mocne przesunięcia pozycji zaliczyły m.in. Missing Authorization (CWE-862), NULL Pointer Dereference (CWE-476) oraz Missing Authentication (CWE-306).
  • Nowe wejścia do Top 25: trzy klasyczne przepełnienia bufora (CWE-120/121/122), Improper Access Control (CWE-284), Authorization Bypass via User-Controlled Key (CWE-639) i Allocation of Resources Without Limits (CWE-770).
  • Próbka danych 2025: 39 080 rekordów CVE (okres 1 VI 2024 – 1 VI 2025), z dwoma odświeżeniami zbioru (23 VII i 17 XI 2025). Po raz pierwszy ranking wykorzystał nienormalizowane mapowania CWE oraz wspierał się LLM do sugestii mapowań dla CNAs.
  • Artykuł BleepingComputer: podsumowuje listę i rekomendacje CISA/MITRE dla zespołów dev/sec.

Kontekst / historia / powiązania

Edycja 2025 różni się metodologicznie od lat ubiegłych: zrezygnowano z „zwijania” mapowań do uproszczonego View-1003 (NVD), co pozwoliło na pojawienie się bardziej precyzyjnych, niższych poziomów CWE w rankingu (np. konkretne typy overflow). Ponadto 67% CVE w tegorocznej próbce miało mapowanie dostarczone już przez publikującego CNA (wzrost o 14 p.p. r/r), a zespół Top 25 przeanalizował i korygował mapowania we współpracy z 170 CNA.

Analiza techniczna / szczegóły luki

Top 10 (2025):

  1. CWE-79 XSS – injekcja skryptów w kontekście przeglądarki; często wynik słabego filtrowania/escapingu danych i braku CSP.
  2. CWE-89 SQL Injection – manipulacja zapytaniami do DB przy braku parametrów/bindowania.
  3. CWE-352 CSRF – nieautoryzowane akcje wykonywane w kontekście zalogowanego użytkownika; brak tokenów anty-CSRF, niepoprawne SameSite.
  4. CWE-862 Missing Authorization – brak sprawdzenia uprawnień do zasobu/operacji (również w ścieżkach „bocznych” i API).
  5. CWE-787 Out-of-Bounds Write – korupcja pamięci; typowo prowadzi do RCE/DoS.
  6. CWE-22 Path Traversal, 7) CWE-416 Use-After-Free, 8) CWE-125 OOB Read, 9) CWE-78 OS Command Injection, 10) CWE-94 Code Injection. (Pełna tabela na stronie MITRE).

Nowe i istotne akcenty 2025:

  • Powrót klasyków pamięci – CWE-120/121/122 (różne formy przepełnień bufora) wskazują, że wciąż istnieje duży zbiór kodu w C/C++ bez wystarczających mechanizmów bezpieczeństwa pamięci.
  • Autoryzacja i kontrola dostępu – wzrost pozycji CWE-862/863 oraz pojawienie się CWE-284 pokazują, że błędy uprawnień w mikroserwisach i API są dziś tak samo krytyczne jak klasyczne injekcje.

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie systemu / RCE – w wyniku OOB Write/Use-After-Free/Command Injection.
  • Masowe wycieki danych – przez błędy kontroli dostępu (CWE-284, CWE-862/863) i ekspozycję informacji (CWE-200).
  • Ataki na łańcuchy dostaw – z wykorzystaniem uploadu niebezpiecznych plików (CWE-434) i deserializacji (CWE-502).
  • Ataki na interfejsy webowe i mobilne – XSS/CSRF nadal realnie monetyzowane w phishingu przeglądarkowym i oszustwach transakcyjnych. (Zob. opis ryzyk i listę w źródłach).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów deweloperskich:

  • Eliminacja injekcji: wszędzie używaj zapytania parametryzowane, ORM, walidację białych list, escaping kontekstowy; zabroń konkatenacji inputu w SQL/OS/LDAP.
  • Ochrona front-endu: CSP, HttpOnly/SameSite/secure dla ciasteczek; tokeny synchronizowane lub Double Submit Cookie dla CSRF; sanitizacja i escaping dla XSS.
  • Bezpieczeństwo pamięci: preferuj języki memory-safe (Rust/Go/Java) dla nowych komponentów; dla C/C++ włącz ASLR/DEP/CFI, hardening kompilatora (Fortify, UBSan, ASan) i fuzzing.
  • Autoryzacja i dostęp: model ABAC/RBAC z weryfikacją uprawnień na każdym endpointcie (również „read-only”/list); testuj scenariusze IDOR (CWE-639).
  • Upload plików: whitelist MIME/rozszerzeń, zapis poza webroot, skan AV/sandbox, transkodowanie treści (np. obrazów/PDF).
  • SDLC: SAST + DAST + IAST + fuzzing, skany SCA (licencje/CVE), testy IaC (misconfig), Code Review z checklistą CWE, threat modeling.

Dla zespołów security / platform / AppSec:

  • Mapuj wyniki na CWE i priorytetyzuj według listy Top 25 + wpływu biznesowego.
  • Bloki pre-commit/CI: brak merge, jeśli testy bezpieczeństwa nieprzechodzą (policy-as-code).
  • Telemetria: WAF/RASP z regułami na XSS/SQLi/OS cmd, monitorowanie anomalii uprawnień, limity i throttling (rate-limit – CWE-770).
  • Program bounty i red teaming ukierunkowane na Top 25.
  • Uzgodnij definicję „done”: ticket niezamykany bez remediacji/kompensacji.
  • Komunikacja z vendorami: w zgłoszeniach proś o dokładne mapowanie CVE→CWE, co ułatwia priorytetyzację i trendowanie, zgodnie z praktykami MITRE.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Zmiana metodologii 2025 (rezygnacja z normalizacji do View-1003) spowodowała spadek pozycji abstrakcyjnych CWE i wzrost szczegółowych klas (np. konkretne overflow), co lepiej oddaje rzeczywiste przyczyny podatności w kodzie.
  • Zestawienie potwierdza utrzymującą się dominację błędów wejścia/wyjścia (XSS/SQLi/CSRF) – mimo lat edukacji i frameworków. To argument za wymuszaniem ochron w linterach, generatorach kodu i warstwach platformowych, a nie tylko w recenzjach.

Podsumowanie / kluczowe wnioski

  • Top 25 (2025) to praktyczna mapa na najczęstsze i najgroźniejsze klasy błędów w produkcyjnym kodzie.
  • Pamięć wraca na świecznik (CWE-120/121/122), a kontrola autoryzacji staje się krytyczna w architekturach API/mikroserwisów.
  • Wdrożenie zabezpieczeń jako domyślnych (parametryzacja, CSP, limity zasobów, kontrola uprawnień) + automatyzacja testów powinny stać się normą, nie „best effort”.

Źródła / bibliografia

  • MITRE: 2025 CWE Top 25 – tabela i ranking. (CWE)
  • MITRE: 2025 Methodology (zakres danych, daty, re-mapowanie, LLM, scoring). (CWE)
  • MITRE: 2025 Key Insights (nowości, największe wzrosty/spadki, wnioski dot. mapowań). (CWE)
  • BleepingComputer: MITRE shares 2025’s Top 25 (przegląd i rekomendacje dla zespołów). (BleepingComputer)

Nowe luki w React Server Components (RSC): DoS i wyciek kodu źródłowego. Co musisz zrobić dziś?

Wprowadzenie do problemu / definicja luki

Zespół Reacta opublikował poprawki dla dwóch nowych klas podatności w React Server Components (RSC), które umożliwiają atak typu Denial-of-Service (DoS) oraz ujawnienie skompilowanego kodu źródłowego funkcji serwerowych. Wydanie tych łatek nastąpiło po ubiegłotygodniowej łatce krytycznej luki RCE „React2Shell” (CVE-2025-55182). Poprzednie wersje poprawek okazały się częściowo niepełne, stąd konieczna jest ponowna aktualizacja do najnowszych wydań RSC.

W skrócie

  • Nowe CVE:
    • CVE-2025-55184 (DoS, CVSS 7.5) – niekompletna poprawka; uzupełniona jako CVE-2025-67779.
    • CVE-2025-67779 (DoS, CVSS 7.5) – finalizuje fix na DoS.
    • CVE-2025-55183 (wyciek kodu, CVSS 5.3).
  • Dotyczy pakietów: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack w liniach 19.0.x, 19.1.x, 19.2.x do wersji wskazanych niżej. Zalecane wersje: 19.0.3, 19.1.4, 19.2.3.
  • Frameworki zależne (m.in. Next.js App Router) wymagają aktualizacji do wersji ogłoszonych przez vendorów (tabela niżej).
  • Te dwie nowe luki nie umożliwiają RCE – łatka na React2Shell pozostaje skuteczna.

Kontekst / historia / powiązania

3 grudnia 2025 r. zespół Reacta ujawnił krytyczną lukę CVE-2025-55182 (CVSS 10.0) pozwalającą na nieautoryzowane RCE przez błędną deserializację ładunków RSC. Szybko wypuszczone patche zostały przyjęte przez ekosystem (np. Next.js), ale jak to często bywa po głośnym CVE, badacze znaleźli warianty – tym razem skutkujące DoS i wyciekiem kodu.
The Hacker News potwierdza, że nowe luki zidentyfikowano podczas prób obejścia wcześniejszych poprawek, a wykorzystanie oryginalnego RCE w środowiskach produkcyjnych zostało już odnotowane, co dodatkowo podnosi priorytet aktualizacji.

Analiza techniczna / szczegóły luki

1) DoS przez deserializację ładunku RSC – CVE-2025-55184 oraz CVE-2025-67779

  • Wektor: specjalnie przygotowane żądanie HTTP do dowolnego endpointu Server Functions w aplikacji obsługującej RSC.
  • Skutek: nieskończona pętla podczas deserializacji po stronie serwera → zawieszenie procesu i blokada dalszych żądań (wyczerpanie CPU / workerów).
  • Status poprawek: pierwotna łatka dla CVE-2025-55184 okazała się niepełna, dlatego opublikowano CVE-2025-67779 z uzupełnieniem fixu. Wersje bezpieczne: 19.0.3 / 19.1.4 / 19.2.3.

2) Ujawnienie skompilowanego kodu funkcji serwerowych – CVE-2025-55183

  • Wektor: spreparowane żądanie HTTP do podatnej Server Function, która jawnie lub niejawnie „stringifikuje” argument.
  • Skutek: odpowiedź może zawierać skompilowany kod źródłowy innej Server Function – w tym potencjalnie tajne wartości zakodowane w kodzie (np. „sekret” w łańcuchu przekazywanym do klienta lub inlined przez bundler). Zespół podkreśla, że zmienne środowiskowe w runtime (np. process.env.SECRET) nie są bezpośrednio dotknięte – ryzyko dotyczy treści, które realnie trafiają do bundla/łańcucha znaków.

Wersje dotknięte i zależności

  • Dotknięte wersje pakietów: dla DoS i wycieku – 19.0.0–19.2.2 z wyjątkami opisanymi przez zespół; finalne poprawki w 19.0.3 / 19.1.4 / 19.2.3.
  • Dotknięte frameworki/bundlery: Next.js (App Router), React Router (RSC), Waku, Parcel RSC, @vite/plugin-rsc, Redwood SDK i inne korzystające z RSC.

Praktyczne konsekwencje / ryzyko

  • Dostępność: DoS może skutecznie „wyłączyć” usługę HTTP (zawieszenie procesu serwera). W środowiskach „serverless” może to windować koszty (piki CPU / cold starty).
  • Poufność/IP: wyciek skompilowanego kodu Server Functions może ujawnić reguły biznesowe lub sekrety twardo osadzone w kodzie (np. klucze testowe), jeśli zostały w niego wbudowane.
  • Łańcuch supply-chain: podatność jest „upstreamowa” (w samym React RSC), więc „rozlewa się” na frameworki. Wymagana jest koordynowana aktualizacja zarówno pakietów RSC, jak i frameworków (np. Next.js).

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe aktualizacje pakietów RSC

Zaktualizuj do 19.0.3 / 19.1.4 / 19.2.3 odpowiednio dla Twojej linii wersyjnej:

# przykład
npm install react-server-dom-webpack@19.2.3 react@latest react-dom@latest
npm install react-server-dom-parcel@19.2.3
npm install react-server-dom-turbopack@19.2.3

(W razie monorepo/React Native – aktualizuj wyłącznie pakiety RSC, bez podbijania react/react-dom.)

2) Next.js (App Router) – wersje „fixed”

Zespół Next.js publikuje precyzyjne docelowe wersje (dla poszczególnych linii), np. 14.2.35, 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, 16.0.10, a dla canary odpowiednio 15.6.0-canary.60 / 16.1.0-canary.19. Zalecane jest użycie narzędzia:

npx fix-react2shell-next

które automatycznie podniesie wersje według matrycy bezpieczeństwa. Uwaga: Pages Router nie jest podatny, ale aktualizacja nadal jest rekomendowana.

3) Twarde zasady bezpieczeństwa kodu

  • Nie osadzaj sekretów w kodzie źródłowym (dotyczy zwłaszcza funkcji serwerowych); używaj zmiennych środowiskowych i sejfów sekretów.
  • Przejrzyj miejsca, gdzie argumenty funkcji są stringifikowane lub mogą trafić do odpowiedzi – minimalizuj echo danych użytkownika.
  • Weryfikuj build produkcyjny (tree-shaking/inlining bundlera może nieoczekiwanie włączyć wartości do artefaktów).

4) Ochrony doraźne (do czasu wdrożenia poprawek)

  • Rate-limiting / circuit-breaking na endpointach Server Functions.
  • WAF/filtry żądań pod kątem anomalii w ładunkach RSC (niestandardowe typy/pola).
  • Monitoruj CPU/worker saturation i HTTP 5xx/timeouty jako wczesny sygnał DoS.
    (React współpracował z dostawcami hostingu nad tymczasowymi mitigacjami, ale to nie zastępuje aktualizacji).

5) Walidacja po aktualizacji – szybka checklista

  • npm ls react-server-dom-* → potwierdź 19.0.3/19.1.4/19.2.3.
  • Dla Next.js: npx fix-react2shell-next → sprawdź zgodność z tabelą wersji.
  • Testy smoke dla:
    • obsługi błędnych ładunków RSC (brak wieszania procesu),
    • odpowiedzi Server Functions (czy nie zwracają fragmentów kodu).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • RCE (CVE-2025-55182) vs DoS/Leak (CVE-2025-55184/67779/55183):
    • RCE dawało pełne wykonanie kodu po stronie serwera bez autoryzacji.
    • DoS „tylko” unieruchamia proces;
    • Leak może ujawnić logikę biznesową lub twardo osadzone tajne wartości – to ryzyko reputacyjne i compliance, ale nie jest to pełne przejęcie jak w RCE.
    • Łatka na RCE pozostaje skuteczna, jednak musisz zaktualizować ponownie z powodu niekompletnego fixu DoS.

Podsumowanie / kluczowe wnioski

  • Dwie nowe luki w React Server Components umożliwiają DoS oraz wyciek skompilowanego kodu.
  • Zaktualizuj teraz do 19.0.3 / 19.1.4 / 19.2.3 oraz do zalecanych wersji Next.js (App Router).
  • Nie trzymaj sekretów w kodzie; sprawdź, czy bundler nie wstrzykuje wartości do odpowiedzi.
  • Traktuj to jako kolejny etap cyklu po-incydentowego po React2Shell – to normalne, że po dużym CVE pojawiają się warianty.

Źródła / bibliografia

  1. React Blog – Denial of Service and Source Code Exposure in React Server Components (11 grudnia 2025) – oficjalne omówienie luk, wersje fixed i timeline. (React)
  2. React Blog – Critical Security Vulnerability in React Server Components (3 grudnia 2025) – opis i wytyczne dot. RCE (CVE-2025-55182) oraz sekcja zaktualizowana o nowe CVE. (React)
  3. Next.js Blog – Next.js Security Update: December 11, 2025 – matryca wersji App Router, narzędzie npx fix-react2shell-next, informacja o niekompletnym fixie i CVE-2025-67779. (Next.js)
  4. The Hacker News – New React RSC Vulnerabilities Enable DoS and Source Code Exposure (12 grudnia 2025) – przegląd i kontekst eksploitacji w świecie rzeczywistym. (The Hacker News)

Systemy Bazowe Dla Kontenerów Docker – Analiza Bezpieczeństwa

Kiedy „oficjalny obraz” nie oznacza „bezpieczny obraz”

W świecie Dockera często mówimy o obrazach i kontenerach, ale rzadziej zastanawiamy się nad systemem bazowym, na którym te kontenery są oparte. A to poważny błąd – „base image” to fundament naszego kontenera. Jeśli jest słaby lub popękany od znanych podatności, cała aplikacja może być zagrożona.

Czytaj dalej „Systemy Bazowe Dla Kontenerów Docker – Analiza Bezpieczeństwa”

CISA dodaje do KEV aktywnie wykorzystywaną lukę XXE w GeoServer (CVE-2025-58360)

Wprowadzenie do problemu / definicja luki

12 grudnia 2025 r. amerykańska CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) lukę CVE-2025-58360 w OSGeo GeoServer — błąd XXE (XML External Entity) możliwy do wykorzystania bez uwierzytelnienia. Oznacza to potwierdzone, realne nadużycia w środowiskach produkcyjnych i pilną konieczność aktualizacji.

W skrócie

  • CVE-2025-58360 (CVSS: wysoki) — XXE w operacji WMS GetMap na endpointzie /geoserver/wms, podatność bez uwierzytelnienia.
  • Wersje podatne: linie 2.25.x ≤ 2.25.5 oraz 2.26.0–2.26.1 (inne gałęzie przed łatami).
  • Wersje naprawione: 2.25.6, 2.26.2, 2.27.0, 2.28.0/2.28.1.
  • Status zagrożenia: CISA: aktywne wykorzystanie; kanadyjskie Cyber Centre: „eksploit istnieje w naturze”.
  • Termin dla agencji FCEB: do 1 stycznia 2026 r. (wymóg z komunikatu o wpisie do KEV).

Kontekst / historia / powiązania

GeoServer był już celem głośnych nadużyć — w 2024 r. krytyczne RCE CVE-2024-36401 doprowadziło do incydentów w infrastrukturze rządowej USA. Obecny przypadek XXE potwierdza, że usługi OGC (WMS/WFS) są atrakcyjnym wektorem ataku i wymagają rygorystycznej walidacji wejścia oraz twardych konfiguracji parserów XML.

Analiza techniczna / szczegóły luki

Sedno błędu: GeoServer akceptuje dane XML w żądaniach WMS GetMap i niewystarczająco ogranicza możliwość definiowania zewnętrznych encji XML. Atakujący może wstrzyknąć DTD/encje wskazujące na zasoby lokalne lub zdalne. Brak uwierzytelnienia powoduje, że atak jest pre-auth.

Skutki techniczne potwierdzone przez projekt:

  • Odczyt plików z systemu plików serwera (np. /etc/passwd, klucze, konfiguracje).
  • SSRF do sieci wewnętrznej (np. do metadanych chmury, usług intranetowych).
  • DoS przez wyczerpywanie zasobów parsera.

Zakres dotkniętych pakietów (wg komunikatów projektu): obrazy docker.osgeo.org/geoserver oraz artefakty Maven org.geoserver.web:gs-web-app i org.geoserver:gs-wms.

Wersje z poprawkami:
Projekt wydał łatki w kilku gałęziach: 2.25.6, 2.26.2, 2.27.0, a następnie w linii 2.28 (0 i 1). Te wydania zawierają m.in. poprawki bezpieczeństwa oraz wzmacniają polityki CSP i izolację plików (sandbox).

Uwaga nt. rozbieżności źródeł: zapisy NVD wskazują naprawę m.in. w 2.26.3, lecz komunikaty projektu potwierdzają łatę w 2.26.2 — w analizie preferujemy dane producenta.

Praktyczne konsekwencje / ryzyko

  • Ekspozycja danych: wyciek sekretów konfiguracyjnych → przejęcia dalszych systemów.
  • Pivoting przez SSRF: skanowanie/atakowanie hostów wewnętrznych i usług chmurowych.
  • Zakłócenia usług GIS: parsowanie złośliwych encji może wywołać DoS.
  • Ryzyko regulacyjne: wpis do KEV oznacza, że SOC/IR powinny traktować to jako priorytet P1.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja GeoServer do jednej z wersji naprawionych (2.25.6 / 2.26.2 / 2.27.0 / 2.28.0+). Dla linii 2.28 zalecana jest 2.28.1. Zaktualizuj także powiązane komponenty (GeoTools, GeoWebCache) zgodnie z komunikatami projektu.
  2. Jeśli nie możesz patchować od ręki:
    • Tymczasowo zablokuj/ogranicz przyjmowanie żądań WMS POST z Content-Type: application/xml/text/xml na warstwach narażonych / publicznych.
    • Rozważ WAF z regułami blokującymi DTD (<!DOCTYPE), odwołania SYSTEM i ENTITY w payloadach WMS.
    • Wystaw WMS tylko przez reverse proxy z inspekcją treści i limitem wielkości żądań. (Dobre praktyki dla XXE).
  3. Twarda konfiguracja parserów XML w usługach pomocniczych: wyłącz external general/parameter entities, DTD, włącz secure processing (jeśli własne rozszerzenia przetwarzają XML). (Good practice uzupełniająca zalecenia projektu i CVE).
  4. Segmentacja i egress control: ogranicz wyjścia z hosta GeoServer (aby utrudnić SSRF do sieci wewnętrznej i chmury).
  5. Hunting / detekcja:
    • Logi żądań z nietypowymi POST /geoserver/wms zawierającymi GetMap i XML/DTD.
    • Wzorce w treści: <!DOCTYPE, <!ENTITY, SYSTEM, file:///, http(s)://169.254.169.254.
    • Korelacja z błędami parsera XML i skokami zużycia CPU/RAM.
  6. Weryfikacja obrazów/kontenerów: zaktualizuj obrazy docker.osgeo.org/geoserver do wersji zawierających łatę.
  7. Zgodność z KEV: jeżeli podlegasz wytycznym FCEB, dopilnuj remediacji do 1 stycznia 2026 r.

Różnice / porównania z innymi przypadkami

  • CVE-2025-58360 (XXE) vs CVE-2024-36401 (RCE): XXE daje dostęp do plików/SSRF/DoS, ale nie jest bezpośrednim RCE — mimo to, w połączeniu z odczytem kluczy/konfiguracji może prowadzić do przejęcia systemu. RCE z 2024 r. był natychmiastowo wykorzystywany do trwałej obecności (web-shelle, narzędzia ofensywne), co pokazuje, jak szybko atakujący pivotują po publikacji poprawek.

Podsumowanie / kluczowe wnioski

  • Luka CVE-2025-58360 w GeoServer to pre-auth XXE w WMS GetMap, aktywnie wykorzystywana i formalnie wpisana do CISA KEV.
  • Aktualizacja jest najlepszą i wymaganą ścieżką — wersje 2.25.6 / 2.26.2 / 2.27.0 / 2.28.0/2.28.1 zawierają poprawki.
  • Do czasu patchowania stosuj kompensacje: blokady WMS XML/DTD, WAF, segmentację, monitoring logów.
  • Traktuj usługę GIS jak krytyczną bramę danych — kontroluj wejścia XML i egress, aby zminimalizować skutki SSRF/XXE.

Źródła / bibliografia

  • GitHub Security Advisory (projekt GeoServer) — opis błędu XXE w GetMap, CVE-2025-58360. (GitHub)
  • GeoServer 2.26.2 — ogłoszenie wydania z informacją o naprawie CVE-2025-58360. (geoserver.org)
  • GeoServer 2.28.1 — ogłoszenie wydania, lista poprawek (m.in. CVE-2025-58360). (geoserver.org)
  • NVD — karta CVE-2025-58360 (CVSS, informacje o wersjach). (NVD)
  • Canadian Centre for Cyber Security — advisory dot. GeoServer; „exploit exists in the wild”. (Canadian Centre for Cyber Security)
  • (Kontekst) The Hacker News — informacja o wpisie do KEV i terminie FCEB. (The Hacker News)

Krytyczna luka 0-day w Gogs (CVE-2025-8110) aktywnie wykorzystywana — ponad 700 serwerów skompromitowanych

Wprowadzenie do problemu / definicja luki

Badacze Wiz ujawnili aktywnie wykorzystywaną lukę 0-day w Gogs — lekkim, samodzielnie hostowanym serwerze Git. Błąd oznaczono jako CVE-2025-8110 i dotyczy niewłaściwej obsługi symlinków w API PutContents. Pozwala to uwierzytelnionemu atakującemu nadpisać pliki poza katalogiem repozytorium, co przekłada się na zdalne wykonanie kodu (RCE). Według Wiz, ponad 700 publicznie dostępnych instancji Gogs nosi ślady kompromitacji; poprawki oficjalnie jeszcze nie ma.

W skrócie

  • Identyfikator: CVE-2025-8110 (CVSS 7.8).
  • Status: brak łatki w momencie publikacji (10–12 grudnia 2025); utrzymująca się eksploatacja od co najmniej 1 grudnia.
  • Zakres: wersje ≤ 0.13.3, zwłaszcza instancje wystawione do Internetu z otwartą rejestracją (domyślnie włączona).
  • Skala: ~1 400 wystawionych serwerów; 700+ potwierdzonych kompromitacji.
  • Przyczyna: obejście poprzedniej poprawki CVE-2024-55947 poprzez symlinki.

Kontekst / historia / powiązania

CVE-2025-8110 to obejście poprawki dla CVE-2024-55947 (trawersja ścieżek w API), które dodało walidację „ścieżki” — ale nie sprawdzało, dokąd wskazuje symlink. Podobne problemy z bezpieczeństwem Gogs były już wcześniej opisywane (m.in. CVE-2024-39930/31/32/33), a utrzymanie projektu bywało krytykowane za opieszałość w usuwaniu błędów. SonarSource już w 2024 r. rekomendował rozważenie migracji do Gitea (fork Gogs) jako aktywniej utrzymywanej alternatywy.

Analiza techniczna / szczegóły luki

Wektor nadużycia (wysoki poziom):

  1. Atakujący zakłada repozytorium (prawo tworzenia repo jest domyślnie dostępne po rejestracji), 2) w repo umieszcza symlink wskazujący poza katalog repo, 3) używa API PutContents, które nadpisuje plik docelowy, 4) nadpisuje .git/config (pole sshCommand), uzyskując RCE z uprawnieniami procesu Gogs. Mechanika jest trywialna dla każdego użytkownika z prawem tworzenia repozytoriów.

Warunki powodzenia:

  • Serwer Gogs wystawiony do Internetu i z włączoną otwartą rejestracją (domyślnie).
  • Wersja Gogs 0.13.3 lub starsza.

Artefakty kompromitacji zaobserwowane przez Wiz:

  • Masowo tworzone konta i repozytoria o losowych 8-znakowych nazwach (owner/repo).
  • Wspólny wzorzec czasowy pierwszej fali: 10 lipca 2025.
  • Wykorzystanie frameworka Supershell jako C2; przykładowe IOC: 119.45.176[.]196 (C2), sumy SHA-1 dwóch próbek malware (podane przez Wiz).

Dowody i relacje w mediach: informacje Wiz potwierdzają m.in. SecurityWeek oraz The Register, wskazując na >700 naruszeń i brak dostępnej łatki w chwili publikacji.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wycieku i sabotażu kodu: odczyt, modyfikacja i wstrzykiwanie backdoorów do prywatnych repozytoriów; możliwość „supply-chain” poprzez artefakty CI/CD.
  • Rozszerzenie przyczółka: serwer Gogs bywa ulokowany w strefach z dostępem do systemów buildowych; RCE umożliwia lateral movement.
  • Przestój zespołów dev: blokada repo, utrata integralności commitów, konieczność odtwarzania i przeglądu łańcucha dostaw. (Wniosek na podstawie powyższej techniki ataku).
  • Ryzyko reputacyjne i zgodności: możliwe naruszenia wymogów wytwarzania bezpiecznego oprogramowania (np. NIS2/DORA w UE).

Rekomendacje operacyjne / co zrobić teraz

Działania „tu i teraz” (0–24 h):

  1. Wyłącz otwartą rejestrację (Open Registration) na wszystkich instancjach Gogs.
  2. Ogranicz ekspozycję do Internetu: wstaw za VPN/reverse proxy i allow-listę IP; jeśli to możliwe, czasowo odłącz publiczny dostęp.
  3. Hunting/IR:
    • Wyszukaj nowo utworzone repozytoria o losowych 8-znakowych nazwach (owner/repo).
    • Przejrzyj logi pod kątem nietypowego użycia API PutContents.
    • Sprawdź, czy .git/config nie był nadpisywany (pole sshCommand).
  4. IOC/ekosystem: sprawdź komunikację z hostami C2 wskazanymi przez Wiz i znanymi sumami hash binarek (Supershell).
  5. Zarządzanie wersjami: jeżeli musisz utrzymywać Gogs, trzymaj instancję za uwierzytelnionym frontem i zablokuj rejestrację do czasu pojawienia się oficjalnej łatki.

Działania krótkoterminowe (1–7 dni):

  • Asset discovery: przeszukaj sieć pod kątem instancji Gogs; runZero opisuje prosty sygnatury/filtr (np. hash favikony) pomocne w wykryciu zasobów.
  • Hardening: uruchamiaj Gogs jako nie-uprzywilejowany użytkownik, w kontenerze z read-only rootfs i profilami AppArmor/SELinux ograniczającymi skutki RCE (najlepiej z minimalnym zestawem syscalów). (Dobre praktyki wynikające z natury RCE).
  • Kontrole detekcyjne: reguły SIEM/EDR pod PutContents oraz modyfikacje .git/config; alerty na tworzenie repo z losowymi nazwami.

Działania średnioterminowe (7–30 dni):

  • Ocena alternatyw: rozważ migrację do Gitea (aktywnie utrzymywany fork) — w 2024 r. SonarSource nie stwierdził w nim badanych problemów, a projekt ma szybszy cykl poprawek.
  • Segmentacja i Zero Trust dla narzędzi Dev: repozytoria i CI/CD w dedykowanych strefach, z kontrolą dostępu na poziomie sieci i tożsamości.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • CVE-2024-55947 vs. CVE-2025-8110: pierwszy błąd naprawiono walidacją ścieżki, jednak obejście symlinkiem przywraca możliwość zapisu poza repozytorium — to klasyczny przykład „bypassu” łatki.
  • Gogs vs. Gitea: oba projekty są pokrewne, lecz to Gitea wykazuje obecnie większą responsywność na raporty bezpieczeństwa; niezależne badania wskazywały na utrzymujące się luki w Gogs.

Podsumowanie / kluczowe wnioski

  • Luka CVE-2025-8110 jest aktywnie wykorzystywana, a łatki brak — ekspozycja Internet + otwarta rejestracja = wysokie ryzyko.
  • Skala kompromitacji jest znacząca (700+ instancji), a wektor prosty (symlink + PutContents + nadpisanie .git/config).
  • Natychmiast: zamknij rejestrację, zdejmij z Internetu lub ogranicz dostęp, poluj na artefakty, monitoruj IoC.
  • Strategicznie: wzmocnij hardening i rozważ migrację do lepiej utrzymywanego forka.

Źródła / bibliografia

  1. Wiz Research — szczegóły techniczne, IoC, skala kompromitacji. (wiz.io)
  2. SecurityWeek — omówienie incydentu, status łatki, liczby. (SecurityWeek)
  3. runZero — identyfikacja zasobów, wersje podatne, praktyczne wskazówki wykrywania. (runZero)
  4. The Register — potwierdzenie ataków, 700+ instancji, brak natychmiastowej poprawki. (The Register)
  5. SonarSource (2024) — kontekst historyczny problemów bezpieczeństwa Gogs i rekomendacja migracji do Gitea. (sonarsource.com)

Hakerzy wykorzystują błąd kryptograficzny w Gladinet CentreStack/Triofox do ataków RCE

Wprowadzenie do problemu / definicja luki

11 grudnia 2025 r. pojawiły się doniesienia o aktywnym wykorzystywaniu nowej, nieudokumentowanej wcześniej podatności kryptograficznej w produktach Gladinet CentreStack i Triofox. Błąd wynika z zastosowania stałych (hardcoded) kluczy AES w komponencie odpowiedzialnym za szyfrowanie tzw. „Access Ticketów”. Atakujący, posiadając te klucze, mogą odszyfrowywać lub fałszować bilety dostępu, pobierać plik web.config z serwera i następnie doprowadzać do zdalnego wykonania kodu (RCE) poprzez nadużycie ASP.NET ViewState. Vendor potwierdził aktualizacje i przekazał IOC oraz zalecenia, a badacze obserwują ataki na co najmniej 9 organizacji z różnych sektorów.

W skrócie

  • Co się dzieje: aktywne ataki na CentreStack/Triofox z wykorzystaniem stałych kluczy AES i mechanizmu „Access Ticket”.
  • Skutki: odczyt web.config → pozyskanie machineKey → ViewState deserialization → RCE.
  • Skala: potwierdzone co najmniej 9 ofiar (stan na 10 grudnia 2025 r.). Adres źródłowy widoczny w telemetrii: 147.124.216[.]205.
  • Wersje/patch: zalecana wersja 16.12.10420.56791 (wydana 8 grudnia 2025 r.). Bezwzględnie zrotować machineKey.
  • Łańcuch z wcześniejszą luką: aktywnie wykorzystywane CVE-2025-11371 (LFI) oraz wcześniejsze CVE-2025-30406 (RCE przez ViewState).

Kontekst / historia / powiązania

Jesienią 2025 r. CISA dodała do katalogu KEV podatność CVE-2025-11371 (LFI), umożliwiającą nieautoryzowany odczyt plików – w praktyce web.config. Wcześniej opisywano także CVE-2025-30406, gdzie błędna obsługa kluczy/machineKey umożliwia RCE przez ViewState. Obecnie obserwowany błąd kryptograficzny z hardcoded kluczami AES ułatwia ten sam łańcuch ataku i jest wykorzystywany „widzianie w boju” (in the wild).

Analiza techniczna / szczegóły luki

  • Miejsce problemu: niestandardowa implementacja AES w GladCtrl64.dll; podczas startu serwisu generowane są dwie stałe 100-bajtowe sekwencje znaków (chiński i japoński tekst marketingowy), z których obliczane są klucz (32 B) i IV (16 B).
  • Mechanizm błędu: handler filesvr.dn przyjmuje parametr t (Access Ticket), podmienia znaki, dekoduje Base64 i odszyfrowuje bilety stałym kluczem/IV. Ktokolwiek te wartości odczyta (np. z pamięci procesu), może tworzyć własne, ważne bilety – np. z timestampem ustawionym na rok 9999 (nigdy nie wygasną).
  • Co dalej robi atakujący: tworzy bilet wskazujący na ścieżkę C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config, pobiera plik i wyciąga z niego <machineKey>. Następnie przeprowadza ViewState deserialization i osiąga RCE w kontekście aplikacji IIS.
  • IOC o wysokiej wiarygodności: skrót szyfrowanego ciągu odpowiadający ścieżce web.config: vghpI7EToZUDIZDdprSubL3mTZ2 – to najlepszy wskaźnik w logach HTTP.

Praktyczne konsekwencje / ryzyko

  • Przejęcie serwera aplikacyjnego (RCE) i dostęp do plików udziałów/zasobów.
  • Ruch lateralny w domenie (kradzież poświadczeń, eskalacja uprawnień).
  • Eksfiltracja danych z udziałów plikowych udostępnionych przez CentreStack/Triofox.
  • Trwałość: bilety z timestampem „9999-…” można wielokrotnie odtwarzać.
  • Sektory: potwierdzone ofiary m.in. ochrona zdrowia i technologia.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja do 16.12.10420.56791 (build z 8 grudnia 2025 r.).
  2. Rotacja machineKey we wszystkich węzłach/instancjach (to warunek konieczny – same łatki nie unieważnią zdobytych kluczy).
  3. Przegląd logów (IIS, WAF, proxy) pod kątem:
    • żądań do /storage/filesvr.dn z parametrem t=,
    • wystąpień ciągu vghpI7EToZUDIZDdprSubL3mTZ2 (wysoka trafność),
    • nietypowych błędów ViewState/ObjectStateFormatter.
  4. Weryfikacja kompromitacji: jeśli machineKey mógł wyciec, zakładaj kompromitację → rotuj klucze, unieważnij sesje, przeprowadź IR (przegląd harmonogramów zadań, usług, modułów IIS, webshelli, skryptów w katalogach aplikacji).
  5. Twardnienie konfiguracji:
    • wyłącz/ogranicz dostęp do filesvr.dn,
    • zastosuj WAF-owe reguły dla podejrzanych t= (Base64 + znaki :, |),
    • zmień domyślny machineKey i egzekwuj jego rotację proceduralnie (runbook).
  6. Śledź KEV/CVE: monitoruj status CVE-2025-11371 (LFI) i wcześniejszej CVE-2025-30406 (RCE) – łańcuchy są ze sobą silnie powiązane operacyjnie.

Różnice / porównania z innymi przypadkami

  • CVE-2025-11371 (LFI): umożliwia odczyt plików bez uwierzytelnienia (np. web.config). Sama w sobie nie daje natychmiastowego RCE, ale otwiera drzwi do pozyskania machineKey.
  • Nowy błąd kryptograficzny (brak CVE na dziś): ułatwia fałszowanie Access Ticketów dzięki stałym kluczom AES — z pominięciem innych kontroli czasu/uwierzytelniania — co przyspiesza zdobycie web.config.
  • CVE-2025-30406 (RCE): deserializacja ViewState z użyciem poznanego machineKey → pełne RCE w aplikacji.

Podsumowanie / kluczowe wnioski

  • Atakujący aktywnie łączą błąd kryptograficzny z wcześniejszymi słabościami CentreStack/Triofox, aby masowo uzyskiwać RCE.
  • Patch + rotacja kluczy to absolutne minimum; bez rotacji machineKey środowisko pozostaje narażone na ponowne wykorzystanie.
  • Najbardziej wiarygodny IOC do szybkiego huntingu w logach HTTP to: vghpI7EToZUDIZDdprSubL3mTZ2.
  • Wdrożenie kontroli prewencyjnych (WAF, ograniczenie handlerów, segmentacja) znacząco utrudni powtórny kompromis.

Źródła / bibliografia

  1. BleepingComputer: „Hackers exploit Gladinet CentreStack cryptographic flaw in RCE attacks” (11 grudnia 2025). (BleepingComputer)
  2. Huntress: „Active Exploitation of Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability” (10 grudnia 2025). (Huntress)
  3. CISA KEV – wpis dot. CVE-2025-11371 (4 listopada 2025). (CISA)
  4. Huntress: „CVE-2025-30406 – Critical Gladinet CentreStack & Triofox vulnerability exploited in the wild” (14 kwietnia 2025). (Huntress)
  5. Gladinet Support: „Hardening the CentreStack Cluster” – sekcja o aktualizacji/rotacji machineKey. (support.centrestack.com)