Archiwa: NIST - Strona 30 z 38 - Security Bez Tabu

113 tys. osób dotkniętych wyciekiem danych w Richmond Behavioral Health Authority (Virginia)

Wprowadzenie do problemu / definicja luki

Publiczna jednostka ochrony zdrowia psychicznego Richmond Behavioral Health Authority (RBHA) z Richmond w stanie Wirginia poinformowała o poważnym naruszeniu bezpieczeństwa danych. Atakujący uzyskali nieuprawniony dostęp do systemów, wykradli dane ponad 113 000 osób i wdrożyli ransomware, co mogło zakłócić dostępność usług. Ujawnione informacje obejmują m.in. imiona i nazwiska, numery Social Security, dane finansowe oraz informacje medyczne (PHI).

W skrócie

  • Skala: 113 232 osób objętych naruszeniem (RBHA).
  • Linia czasu: nieautoryzowany dostęp wykryto około 30 września 2025 r.; następnie rozpoczęto dochodzenie i powiadomienia.
  • Zakres danych: PHI, SSN, możliwie numery paszportów i informacje o kontach finansowych.
  • Taktyka: kradzież danych + wdrożenie ransomware w sieci RBHA.
  • Podstawa prawna: obowiązki notyfikacyjne wg prawa Wirginii dla naruszeń danych medycznych.

Kontekst / historia / powiązania

RBHA to agencja publiczna świadcząca usługi z zakresu zdrowia psychicznego, leczenia uzależnień i wsparcia osób z niepełnosprawnościami na terenie miasta Richmond. W sektorze ochrony zdrowia w USA ataki ransomware i wycieki PHI pozostają trendem rosnącym – wpis RBHA pojawia się w doniesieniach branżowych oraz zestawieniach incydentów zdrowotnych.

Analiza techniczna / szczegóły luki

Wektor i przebieg: według RBHA i relacji branżowych, incydent polegał na nieautoryzowanym dostępie do systemów, następnie ekstrakcji danych i uruchomieniu ransomware. Taki łańcuch (data theft → encryption/impact) odzwierciedla obecny model „double-extortion”, gdzie wyciek jest dźwignią do wymuszenia okupu.

Kategorie danych objętych ryzykiem:

  • identyfikacyjne: imię i nazwisko, SSN, czasem numery paszportów;
  • finansowe: informacje o kontach;
  • medyczne: chronione informacje zdrowotne (PHI).
    Te klasy danych znacząco zwiększają ryzyko kradzieży tożsamości i nadużyć finansowych, a w przypadku PHI – długotrwałego narażenia prywatności.

Skala: 113 232 rekordów – liczba raportowana w komunikatach i powiązana z wpisem na portalu naruszeń HHS (OCR).

Praktyczne konsekwencje / ryzyko

  • Ryzyko finansowe: wykorzystanie SSN i danych kont do fraudów (kredyty, wnioski podatkowe, przejęcia kont).
  • Ryzyko prywatności: ujawnienie PHI może prowadzić do stygmatyzacji, szantażu i naruszenia poufności leczenia.
  • Ryzyko operacyjne: ransomware może powodować przestoje w systemach rejestracji, EHR i teleopieki, wpływając na ciągłość usług publicznych.

Rekomendacje operacyjne / co zrobić teraz

Dla osób poszkodowanych:

  1. Zamrożenie kredytu (credit freeze) w głównych biurach kredytowych oraz włączenie alertów oszustw.
  2. Monitorowanie kont bankowych i polis; skonfigurowanie powiadomień transakcyjnych.
  3. Weryfikacja wyciągów medycznych (Explanation of Benefits) pod kątem fikcyjnych świadczeń.
  4. Zmiana haseł/rotacja, włączenie MFA wszędzie, gdzie to możliwe.
  5. Zachowanie listów notyfikacyjnych i skorzystanie z oferowanego monitoringu tożsamości, jeśli zapewniono.

Dla organizacji zdrowotnych i JST (w tym RBHA i podobnych):

  • Segmentacja sieci oraz separacja systemów klinicznych od biurowych; wprowadzenie MFA + FIDO2 dla kont uprzywilejowanych.
  • Zarządzanie podatnościami: EDR/XDR z detekcją kradzieży danych (DLP), monitoring ruchu egress i blokady exfiltracji.
  • Kopia zapasowa 3-2-1 + testy odtwarzania; przechowywanie offline i immutable.
  • Plan IR zgodny z HIPAA Security Rule i NIST 800-61; przygotowane playbooki na double-extortion.
  • Zgodność i notyfikacje: raportowanie zgodnie z Va. Code § 32.1-127.1:05 (AG, Commissioner of Health, podmioty danych, rezydenci), dokumentacja działań naprawczych.

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

W ostatnich miesiącach odnotowano wiele incydentów w ochronie zdrowia (laboratoria, sieci klinik, dostawcy usług). Wspólny mianownik to ekfiltracja PHI i presja okupu. Przypadek RBHA wpisuje się w ten trend, łącząc kradzież danych z ransomware, ale wyróżnia się charakterem instytucji publicznej świadczącej usługi zdrowia psychicznego – co zwiększa wrażliwość wycieków i potencjalny impact społeczny.

Podsumowanie / kluczowe wnioski

  • Atak na RBHA to klasyczny scenariusz double-extortion: dostęp → exfiltracja → ransomware.
  • Ujawnione PHI + SSN + dane finansowe tworzą wysoki, długofalowy profil ryzyka dla obywateli.
  • Jednostki publiczne muszą wdrożyć kontrole „zero-trust”, silną segmentację, DLP i gotowość IR.
  • Z perspektywy compliance, kluczowe są sprawne notyfikacje zgodnie z prawem Wirginii i HIPAA oraz transparentna komunikacja z pacjentami.

Źródła / bibliografia

  • SecurityWeek: „113,000 Impacted by Data Breach at Virginia Mental Health Authority” – główne fakty o kradzieży danych i wdrożeniu ransomware. (SecurityWeek)
  • Comparitech: zgłoszenie 113 232 osób i kategorie danych, odniesienie do rejestru HHS. (Comparitech)
  • HIPAA Journal: oś czasu zdarzeń (~30 września 2025 r. wykrycie) i rekomendacje dla poszkodowanych. (hipaajournal.com)
  • Prawo Wirginii: Va. Code § 32.1-127.1:05 – Breach of medical information notification. (law.lis.virginia.gov)

React2Shell: krytyczna luka RCE w React Server Components (CVE-2025-55182) oraz duplikat w Next.js (CVE-2025-66478)

Wprowadzenie do problemu / definicja luki

3 grudnia 2025 r. zespół React ujawnił krytyczną podatność typu pre-auth RCE w protokole Flight dla React Server Components (RSC), śledzoną jako CVE-2025-55182 (CVSS 10.0). Dotyczy ona pakietu react-server i implementacji RSC w wersjach React 19.0–19.2.0 oraz bibliotekach react-server-dom-* (webpack/parcel/turbopack). Równolegle Next.js opublikował własne ogłoszenie (CVE-2025-66478), które następnie zostało odrzucone jako duplikat CVE-2025-55182.

W skrócie

  • Co to jest? Błąd nieserializowania bezpiecznego (unsafe deserialization) w obsłudze żądań Flight dla RSC prowadzący do zdalnego wykonania kodu bez uwierzytelnienia.
  • Kogo dotyczy? React 19 (pakiety react-server-dom-* w wersjach 19.0/19.1.0/19.1.1/19.2.0) oraz frameworki korzystające z RSC, m.in. Next.js 15.x/16.x (App Router).
  • Status Next.js: CVE-2025-66478duplikat CVE-2025-55182.
  • Wykryte nadużycia: CISA dodała CVE-2025-55182 do katalogu KEV (Known Exploited Vulnerabilities); Unit 42 opisuje realne działania poeksploatacyjne (skanowanie, web-shelle, kryptokoparki, próby Cobalt Strike).
  • Naprawa: aktualizacja do React 19.0.1 / 19.1.2 / 19.2.1 oraz do bieżących wersji Next.js z poprawkami.

Kontekst / historia / powiązania

Reakcja społeczności była natychmiastowa: oprócz oficjalnych biuletynów React i Next.js, w krótkim czasie pojawiły się alerty CISA oraz vendorów bezpieczeństwa. Vercel wydał podsumowanie i narzędzie ułatwiające podbicie projektów Next.js do wersji łatających błąd. 6 grudnia Vercel opublikował wpis z instrukcją i narzędziem npx fix-react2shell-next do automatycznej aktualizacji zależności w aplikacjach Next.js. 8 grudnia Unit 42 zaktualizowało swój raport, potwierdzając obserwacje działań atakujących.

Analiza techniczna / szczegóły luki

Rdzeń problemu: parser/warstwa deserializacji w RSC Flight akceptuje złośliwe, specjalnie spreparowane ładunki HTTP kierowane do Server Functions, co pozwala wpływać na logikę wykonania po stronie serwera i osiągnąć RCE. Co istotne, domyślna konfiguracja popularnych szablonów (np. świeżo utworzonego Next.js) była podatna bez modyfikacji kodu.

Zakres wersji:

  • React / RSC: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack w wersjach 19.0.0 / 19.1.0 / 19.1.1 / 19.2.0.
  • Next.js: głównie gałęzie 15.x i 16.x (App Router) oraz wybrane wydania canary od 14.3.0; projektowe domyślne wdrożenia były atakowalne.

Dlaczego to groźne dla „niewykorzystujących” Server Functions? Nawet jeśli aplikacja nie definiuje własnych endpointów Server Functions, obsługa RSC może być włączona „po drodze”, co utrzymuje powierzchnię ataku.

Praktyczne konsekwencje / ryzyko

  • Łatwość ataku: brak uwierzytelnienia, niski poziom złożoności, wysoka niezawodność exploita; podatność w konfiguracji domyślnej.
  • Skala: React/Next.js mają ogromny udział w rynku — CISA oznaczyła CVE jako znaną, wykorzystywaną; Unit 42 raportuje już poeksploatacyjne działania napastników (skrypty Bash, web-shelle, kryptokoparki, próby wdrożenia Cobalt Strike i aktywność IAB).
  • Potencjalny wpływ: przejęcie procesu serwerowego (Node.js), kradzież tajemnic (klucze, zmienne środowiskowe), pivot w sieci, trwale osadzone backdoory i dalsze kampanie (np. cryptojacking).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja (patch now):
    • React: do 19.0.1 / 19.1.2 / 19.2.1 (lub nowszych).
    • Next.js: do najnowszych wersji z poprawką; w projektach Next.js skorzystaj z narzędzia npx fix-react2shell-next (Vercel).
  2. Przegląd zależności: wymuś podbicie react, react-dom, react-server, react-server-dom-*, a w Next.js — aktualny next oraz bundlery (Turbopack/Webpack) w zgodnych wersjach. (Weryfikuj lockfile.)
  3. Twarde ograniczenia sieciowe: izoluj serwery renderujące (SSR/RSC), kontroluj wychodzące połączenia z Node.js (blokuj „curl/wget do Internetu”, egres tylko do potrzebnych usług). Obserwuj anomalie DNS/HTTP. (Wnioski z TTP napastników).
  4. Detekcja IOC/TTP: szukaj poleceń Base64 z potokami | base64 -d | sh, skryptów typu sex.sh, podejrzanych web-shelli „React File Manager”, prób pobrania C2, śladów Cobalt Strike/Mirai/NOODLERAT.
  5. Higiena sekretów: rotuj klucze/tokenty środowiskowe (CI/CD, .env), sprawdź uprawnienia ról w chmurze — traktuj serwer jako potencjalnie skompromitowany, jeśli był podatny i publicznie dostępny w okresie 3–8 grudnia 2025 r. (po ujawnieniu).
  6. Twardnienie buildów: włącz ograniczenia --frozen-lockfile, SCA w CI, testy E2E po aktualizacji; rozważ WAF z regułami blokującymi sekwencje Flight/RSC nietypowe dla twojej aplikacji. (Dodatkowe wskazówki społeczności).

Różnice / porównania z innymi przypadkami

  • Wzorzec błędu: klasyczne unsafe deserialization znane z ekosystemów Java/.NET teraz uderza w RSC/Node.js — wektor to niestandardowy protokół (Flight) i domyślna obsługa w popularnych frameworkach.
  • CVE w Next.js: początkowo wydzielone jako CVE-2025-66478, lecz scalone do Reactowego CVE-2025-55182 — z punktu widzenia ryzyka operacyjnego to jedna podatność w warstwie RSC.

Podsumowanie / kluczowe wnioski

  • To najpoważniejsza luka w ekosystemie React/Next.js od lat: CVSS 10.0, pre-auth RCE, domyślne konfiguracje atakowalne. Aktualizacje są dostępne — wdrażaj natychmiast.
  • Dowody nadużyć już istnieją (CISA KEV, telemetryczne obserwacje Unit 42). Reaguj jak na incydent: patch + poszukiwanie TTP/IOC + rotacja sekretów.

Źródła / bibliografia

  • React — Critical Security Vulnerability in React Server Components (03.12.2025). (React)
  • Next.js — Security Advisory: CVE-2025-66478 (06.12.2025). (Next.js)
  • NVD — CVE-2025-55182 (ostatnia aktualizacja ~3 dni temu). (nvd.nist.gov)
  • CISA — dodanie CVE-2025-55182 do KEV (05.12.2025). (CISA)
  • Unit 42 (Palo Alto Networks)Exploitation of Critical Vulnerability in React Server Components (akt. 08.12.2025) — obserwacje skanowania i działań poeksploatacyjnych. (Unit 42)

Krytyczna podatność XXE w Apache Tika (CVE-2025-66516, CVSS 10.0) – co musisz załatać już teraz

Wprowadzenie do problemu / definicja luki

W Apache Tika ujawniono krytyczną lukę typu XML External Entity (XXE) oznaczoną jako CVE-2025-66516 z oceną CVSS 10.0. Błąd pozwala na XXE poprzez spreparowany plik XFA osadzony w PDF, co dotyka kluczowych modułów Tiki: tika-core, tika-pdf-module oraz tika-parsers. Projekt wskazuje, że usterka jest ściśle powiązana z wcześniejszym problemem (CVE-2025-54988), ale rozszerza zakres dotkniętych pakietów – dlatego wymaga pilnej aktualizacji nie tylko modułu PDF, lecz także rdzenia (tika-core).

W skrócie

  • Zakres podatnych pakietów:
    • org.apache.tika:tika-core 1.13 – 3.2.1 (naprawione w 3.2.2)
    • org.apache.tika:tika-parser-pdf-module 2.0.0 – 3.2.1 (naprawione w 3.2.2)
    • org.apache.tika:tika-parsers 1.13 – 1.28.5 (naprawione od 2.0.0 w górę)
  • Wektor ataku: XXE przez XFA w PDF, możliwy odczyt plików, SSRF, a w niektórych scenariuszach DoS.
  • Dlaczego nowe CVE? Poprzednie (CVE-2025-54988) skupiało się na module PDF; teraz potwierdzono, że problem i fix są w tika-core, a w gałęzi 1.x parser PDF znajdował się w tika-parsers. Użytkownicy, którzy zaktualizowali wyłącznie moduł PDF, wciąż mogli być podatni.
  • Pilne działanie: aktualizacja do Tika 3.2.2 (i odpowiednio do bezpiecznych wersji w gałęzi 2.x) oraz weryfikacja łańcuchów zależności.

Kontekst / historia / powiązania

W sierpniu 2025 ujawniono CVE-2025-54988 – XXE w parserze PDF Tiki. Część organizacji zaktualizowała jedynie moduł PDF, pozostawiając niezałatany tika-core, co utrzymywało okno podatności. Nowe CVE-2025-66516 formalizuje rozszerzony zakres i „zamyka” lukę poprzez wymaganie wersji tika-core ≥ 3.2.2. Dodatkowo w linii 1.x PDFParser był w pakiecie tika-parsers, więc także ten artefakt należy sprawdzić i zaktualizować.

Analiza techniczna / szczegóły luki

Atakujący osadza formularz XFA w dokumencie PDF. Podczas parsowania Tika – zależnie od ścieżki kodu i konfiguracji – może przetworzyć zewnętrzne encje XML (XXE), co umożliwia:

  • odczyt lokalnych plików (np. /etc/passwd, klucze, tokeny),
  • SSRF – wykonywanie żądań HTTP z serwera aplikacji do zasobów wewnętrznych (np. http://169.254.169.254/ w chmurze),
  • w niektórych przypadkach wyciek metadanych i zasobów lub wyczerpywanie zasobów (DoS).
    Problem jest w tika-core, a wejściem bywa moduł PDF; w gałęzi 1.x wejściem mógł być tika-parsers. To tłumaczy, czemu sama aktualizacja modułu PDF nie wystarcza.

Praktyczne konsekwencje / ryzyko

Tika jest powszechnie osadzana w wyszukiwarkach treści, e-discovery, DLP, systemach ETL, serwerach indeksujących, portalach do uploadu plików czy narzędziach bezpieczeństwa. Każda usługa, która przyjmuje PDF od użytkownika i przekazuje do Tiki, może stać się wektorem wycieku danych lub ruchu SSRF do sieci wewnętrznej i usług chmurowych. Instytucje rządowe ostrzegają przed eksfiltracją danych i rekonesansem wewnętrznej sieci przez tę lukę.

Rekomendacje operacyjne / co zrobić teraz

  1. Patch teraz
    • Upewnij się, że tika-core = 3.2.2 (lub nowszy), tika-parser-pdf-module = 3.2.2 (lub nowszy) oraz brak artefaktów 1.x (tika-parsers ≤ 1.28.5) w drzewie zależności. W ekosystemach Maven/Gradle wymuś wersje przez dependencyManagement/constraints.
  2. Przegląd transytywności
    • Audytuj aplikacje, które pośrednio wciągają Tikę (np. przez narzędzia wyszukiwania, DLP, CMS-y, biblioteki importu). Zadbaj o lockfile i raporty mvn dependency:tree/gradle dependencies. (Wnioski z doradców i ekosystemu GitHub Advisory.)
  3. Tymczasowe twardnienie (gdy aktualizacja wymaga okna serwisowego):
    • Odrzuć/izoluj PDF z XFA (np. wstępny „content sniffer” przed Tiką).
    • Sandbox dla procesu parsowania: AppArmor/SELinux, kontenery z restrykcyjnymi profilami, brak dostępu do metadanych chmury, brak sieci lub wyłącznie wyjście przez proxy/egress filter.
    • Limit zasobów (timeouty, limity pamięci/CPU) na pipeline’ach parsowania.
  4. Detekcja i reagowanie
    • Szukaj anomalii: żądania do IMDS (169.254.169.254), nietypowe odczyty plików przez usługę parsującą, nadmiarowe błędy parsera PDF.
    • Dodaj reguły w WAF/IDS (sygnatury PDF z XFA, nietypowe nagłówki/URI).
  5. Testy bezpieczeństwa
    • Przeprowadź testy jednostkowe/integracyjne z próbkami PDF zawierającymi XFA, aby potwierdzić, że aplikacja nie przetwarza zewnętrznych encji po aktualizacji.

Różnice / porównania z innymi przypadkami

  • CVE-2025-54988 vs. CVE-2025-66516: w obu przypadkach wektorem jest XFA w PDF, ale 66516 formalnie poszerza listę podatnych pakietów i wskazuje, że rdzeń (tika-core) zawierał przyczynę – stąd wymóg jego aktualizacji do ≥ 3.2.2. Jeśli załatano tylko moduł PDF, system nadal mógł być podatny.

Podsumowanie / kluczowe wnioski

  • To krytyczna luka (CVSS 10.0) w popularnym komponencie przetwarzania dokumentów.
  • Aktualizacja tika-core do 3.2.2 (oraz modułów PDF) jest warunkiem koniecznym.
  • Przejrzyj wszystkie aplikacje z PDF upload/parsing oraz zależności transytywne – Tika bywa ukryta w wielu platformach.
  • Dodaj kontrole prewencyjne (filtrowanie XFA, sandbox, egress filtering) i monitoring pod kątem SSRF/wycieków.

Źródła / bibliografia

  • The Hacker News – pierwsza publikacja prasowa i zestawienie wersji dotkniętych/naprawionych. (The Hacker News)
  • NVD (NIST) – karta CVE-2025-66516 z oceną CVSS i opisem rozszerzenia zakresu względem CVE-2025-54988. (NVD)
  • GitHub Advisory (GHSA-f58c-gq56-vjjf) – szczegóły: przyczyna w tika-core, konsekwencje „partial patch”, wersje naprawione. (GitHub)
  • Belgian CCB (rządowe CERT) – ostrzeżenie o eksfiltracji danych/SSRF i szerokim użyciu Tiki. (ccb.belgium.be)
  • Strona projektu Apache Tika – ogólne info o wydaniach i bezpieczeństwie (w tym 3.2.2 jako najnowsza linia 3.x). (tika.apache.org)

Krytyczna luka w dodatku „King Addons for Elementor” aktywnie wykorzystywana. Jak się bronić?

Wprowadzenie do problemu / definicja luki

Atakujący aktywnie wykorzystują krytyczną podatność CVE-2025-8489 w wtyczce King Addons for Elementor (dodatek do buildera Elementor dla WordPressa). Błąd pozwala podnieść uprawnienia podczas rejestracji użytkownika i uzyskać rolę administratora bez uwierzytelnienia — co w praktyce oznacza pełne przejęcie strony. Według informacji z branżowych raportów ataki rozpoczęły się pod koniec października, a do tej pory odnotowano dziesiątki tysięcy prób eksploatacji.

W skrócie

  • CVE-2025-8489 (CVSS 9.8) — błąd eskalacji uprawnień: dowolny rejestrujący się może nadać sobie rolę administrator. Dotyczy wersji 24.12.92–51.1.14.
  • Eksploatacja trwa — zarejestrowano ~48–50 tys. prób ataków; używano m.in. zapytań do admin-ajax.php z parametrem user_role=administrator.
  • Aktualizacja naprawcza — problem załatano w 51.1.35 (wydanie 25 września 2025 r.). Zaktualizuj do 51.1.35+.

Kontekst / historia / powiązania

Błąd został ujawniony 31 października 2025 r., a masowe skanowanie i próby wykorzystania nasiliły się 9–10 listopada. Wtyczka ma ok. 10 tys. aktywnych instalacji, więc nawet umiarkowany odsetek niezałatanych instancji to duża powierzchnia ataku. Dodatkowo obserwowane były powtarzalne adresy IP źródłowe (np. 45.61.157.120, 2602:fa59:3:424::1).

Analiza techniczna / szczegóły luki

  • Istota problemu: handler rejestracji użytkowników w King Addons nie ograniczał ról, które można przypisać w procesie zakładania konta. Skutkiem był brak kontroli roli i możliwość samodzielnego nadania roli administrator. Klasyfikacja słabości: CWE-269 (Improper Privilege Management).
  • Wektor ataku: zapytanie do admin-ajax.php z parametrem wskazującym pożądaną rolę (user_role=administrator). Po udanym założeniu konta napastnik ma pełny panel administracyjny.
  • Zakres wersji: NVD wskazuje, że podatne są 24.12.92–51.1.14; poprawka znajduje się od 51.1.35.
  • Ślad w repo WordPressa: log zmian/depozyty dla King Addons potwierdzają wydania z 25 września 2025 r. (51.1.35 i 51.1.36).

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie strony: dodawanie backdoorów, podmiana treści, przekierowania, wstrzykiwanie złośliwego JS/SEO spam, instalowanie dodatkowych wtyczek do utrzymania trwałości.
  • Łańcuchy ataku: po uzyskaniu admina możliwe jest RCE poprzez edytor motywu/wtyczek lub upload plików, a także kradzież danych użytkowników i sekretów konfiguracyjnych. (Wniosek na bazie uprawnień admina oraz obserwacji incydentów WP).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja King Addons do ≥ 51.1.35 (lub wyżej) albo tymczasowe wyłączenie wtyczki, jeśli aktualizacja niemożliwa. Zweryfikuj w panelu WordPress /Composer.
  2. Przegląd kont użytkowników: usuń nieznane konta adminów; wymuś reset haseł administratorów i edytorów. Zweryfikuj adresy e-mail adminów.
  3. Logi i IOC: sprawdź logi pod kątem żądań do admin-ajax.php z parametrem user_role=administrator oraz ruchu z adresów IP wskazywanych w raportach.
  4. Twarde zasady rejestracji: jeśli nie potrzebujesz publicznej rejestracji — wyłącz ją. W przeciwnym razie zastosuj allowlistę ról, moderację nowych kont, reCAPTCHA/WAF. (Dobre praktyki wynikające z charakteru luki).
  5. Skan i hardening: przeskanuj stronę (np. Wordfence, inne WAF-y), usuń web-shell’e, sprawdź crontaby, wp-content/uploads, mu-plugins, niepodpisane wtyczki/motywy. (Dobre praktyki).
  6. Segmentacja i kopie zapasowe: odseparuj panel administracyjny (np. dostęp tylko przez VPN/IP allowlist), trzymaj offline’owe backupy, z testem odtwarzania. (Dobre praktyki).

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

Równolegle zgłoszono i załatano inną krytyczną podatność w ekosystemie WordPress: ACF Extended – CVE-2025-13486 (CVSS 9.8), RCE bez uwierzytelnienia w wersjach 0.9.0.5–0.9.1.1, naprawioną w 0.9.2. Mechanizm: przekazywanie danych użytkownika do call_user_func_array() w prepare_form(). To inny typ błędu (RCE) niż w King Addons (eskalacja uprawnień), ale efekt końcowy bywa podobny — pełna kompromitacja strony. Wnioski: utrzymywać higienę aktualizacji i minimalizować liczbę dodatków.

Podsumowanie / kluczowe wnioski

  • King Addons (CVE-2025-8489) to łatwa do wykorzystania, publicznie atakowana luka umożliwiająca utworzenie konta admina. Zaktualizuj do ≥51.1.35 i przeprowadź incident check (kontrola kont, logów, artefaktów).
  • Fala ataków na wtyczki (w tym ACF Extended) przypomina, że wtyczki to główny wektor kompromitacji WordPressa — wdrażaj WAF, ograniczaj rejestrację i przeglądaj zależności.

Źródła / bibliografia

  • BleepingComputer: „Critical flaw in WordPress add-on for Elementor exploited in attacks” (03.12.2025). (BleepingComputer)
  • SecurityWeek: „Critical King Addons Vulnerability Exploited to Hack WordPress Sites” (03.12.2025). (SecurityWeek)
  • NVD (NIST): CVE-2025-8489 – opis, zakres wersji, CVSS, CWE. (NVD)
  • WordPress.org (profil/commits KingAddons) – potwierdzenie wydań 51.1.35/51.1.36 (25.09.2025). (WordPress.org)
  • GitHub Advisory DB: CVE-2025-13486 (ACF Extended) – szczegóły RCE i CVSS. (GitHub)

CISA dodaje do KEV aktywnie wykorzystywaną lukę XSS (CVE-2021-26829) w OpenPLC ScadaBR

Wprowadzenie do problemu / definicja luki

28 listopada 2025 r. CISA dodała do katalogu KEV (Known Exploited Vulnerabilities) lukę CVE-2021-26829 w OpenPLC ScadaBR – podatność typu stored XSS (Cross-Site Scripting), która umożliwia wstrzyknięcie kodu JavaScript poprzez stronę system_settings.shtm. Afera jest istotna dla środowisk OT/ICS, bo błąd dotyczy paneli HMI używanych do nadzoru i sterowania procesami. Wpis w KEV oznacza potwierdzoną eksploatację w środowisku rzeczywistym i dla agencji FCEB wyznacza termin wdrożenia środków zaradczych do 19 grudnia 2025 r.

W skrócie

  • CVE-2021-26829: stored XSS w OpenPLC ScadaBR (Windows ≤ 1.12.4, Linux ≤ 0.9.1), CVSS 3.1: 5.4 (Medium).
  • Status: dodane do CISA KEV 28.11.2025 r. z obowiązkiem działań do 19.12.2025 r. dla FCEB.
  • Eksploatacja: m.in. przez grupę hacktywistyczną TwoNet w incydencie na wabiku (honeypot) stylizowanym na oczyszczalnię wody – defacement HMI, manipulacja ustawieniami, wyłączanie logów i alarmów.
  • Trend: skoordynowane skanowanie i eksploatacja setek CVE z wykorzystaniem prywatnej infrastruktury OAST działającej w Google Cloud, z regionalnym ukierunkowaniem na Brazylę.

Kontekst / historia / powiązania

Badacze Forescout/Vedere Labs opisali we wrześniu 2025 r. atak grupy TwoNet na ich pułapkę OT – agresorzy najpierw zalogowali się na HMI domyślnymi danymi, a następnie użyli CVE-2021-26829 do osadzenia złośliwego skryptu wyświetlającego komunikat „HACKED BY BARLATI” oraz modyfikowali ustawienia systemu (w tym wyłączenie logów i alarmów). To potwierdza realny wpływ XSS na bezpieczeństwo operacji, mimo że formalnie ma on „średni” rating.

Równolegle VulnCheck wykrył długotrwale działającą, atakującą infrastrukturę OAST (*.i-sh.detectors-testing[.]com na IP 34.136.22.26) hostowaną w Google Cloud. Zarejestrowano ok. 1,4 tys. prób dotyczących ponad 200 CVE, kierowanych głównie przeciw systemom w Brazylii, co wskazuje na skanowanie „masowe, ale ukierunkowane”. Taki model ułatwia sprawcom weryfikację skuteczności exploitów i maskowanie ruchu w chmurze.

Analiza techniczna / szczegóły luki

  • Wektor: stored XSS w system_settings.shtm – użytkownik o uprawnieniach aplikacyjnych może wprowadzić treść, która zostanie renderowana w HMI i wykona skrypt w przeglądarce operatora. S: Changed, PR: Low, UI: Required.
  • Zakres dotkniętych wersji: Windows ≤ 1.12.4, Linux ≤ 0.9.1. Brak dowodów, że starsze forki lub niestandardowe buildy są odporne.
  • Skutki techniczne:
    • Defacement interfejsu HMI i wstrzyknięcie złośliwych treści (np. pop-upy, przekierowania).
    • Kradzież sesji/CSRF lub pułapki operatorskie (ang. UI redressing), które mogą prowadzić do błędnych decyzji operatorskich.
    • Modyfikacja widoków i formularzy skutkująca np. fałszywymi parametrami procesu. (W incydencie TwoNet mix: defacement + manipulacja ustawieniami i wyłączenie alarmów).

Praktyczne konsekwencje / ryzyko

W środowiskach OT/ICS skutki XSS wykraczają poza klasyczne „phishing UI”. Manipulacja widokiem HMI może:

  • ukryć rzeczywiste alarmy,
  • zafałszować setpointy/telemetrię,
  • skłonić operatora do niebezpiecznych działań (np. zmiany parametrów).

Incydent Forescout pokazał, że od pierwszego dostępu do działań destrukcyjnych minęło ~26 godzin, a atakujący skoncentrował się wyłącznie na warstwie webowej HMI, bez eskalacji na hosta – co czyni tego typu ataki ciche, szybkie i możliwe do przeoczenia przez klasyczne EDR.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa weryfikacja ekspozycji
    • Zidentyfikuj instancje OpenPLC ScadaBR (Windows/Linux) i ich wersje; sprawdź bezpośrednią ekspozycję do Internetu (Shodan/asset inventory).
  2. Aktualizacje i środki tymczasowe
    • Jeśli dostępne łatki/vendor-fix – wdrożyć; w przeciwnym wypadku filtracja treści, encoding output i sanityzacja pól konfiguracyjnych system_settings.shtm.
    • Dla środowisk FCEB: dotrzymaj terminu 19.12.2025 z wpisu KEV.
  3. Twardnienie interfejsów HMI (zalecenia Vedere Labs):
    • Eliminacja słabych/dom yślnych haseł, MFA dla adminów.
    • Segmentacja (oddzielenie strefy HMI od IT/Internetu), przepływy jednokierunkowe tam, gdzie to możliwe.
    • Usunięcie zbędnej ekspozycji (VPN z mTLS zamiast publicznego HMI).
  4. Monitoring i detekcja specyficzna dla OT
    • DPI z rozumieniem Modbus/S7 i regułami na: próby exploitów, nieautoryzowane zapisy, zmiany w HMI, tworzenie kont (np. „BARLATI”).
  5. Blokowanie i hunting na wskaźniki OAST
    • Monitoruj/blokuj wywołania do domen *.i-sh.detectors-testing.com i aktywność z adresów Google Cloud wymienionych przez VulnCheck (np. 34.136.22.26 dla hosta OAST). Uważaj na fałszywie dodatnie – kontekst sieci i geolokalizacja są kluczowe.
  6. Bezpieczne SDLC dla HMI/SCADA
    • Systematyczny output encoding, CSP, sanitizacja danych, testy DAST/SAST i testy XSS (stored/reflected/DOM) w pipeline.

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

W przeciwieństwie do typowych XSS w aplikacjach biurowych, XSS w HMI/SCADA:

  • oddziałuje na proces przemysłowy przez interakcję z operatorem,
  • bywa „wystarczający” do manipulacji setpointami i wyłączenia alarmów, nawet bez RCE na hoście,
  • częściej jest łączony z domyślnymi hasłami i błędną segmentacją sieci (co pokazał przypadek TwoNet).

Z kolei kampania opisana przez VulnCheck obrazuje industrializację skanowania – prywatne OAST na chmurze, stare i nowe szablony Nuclei, szeroka lista CVE i regionalne ukierunkowanie. To inny wektor niż ręczny atak na HMI, ale oba trendy się uzupełniają: masowe wykrywanie podatnych hostów + celowana eksploatacja w OT.

Podsumowanie / kluczowe wnioski

  • CVE-2021-26829 w OpenPLC ScadaBR trafiła do CISA KEV z powodu realnej eksploatacji – to nie tylko „estetyczny” XSS.
  • Incydent TwoNet pokazuje, że XSS w HMI może prowadzić do defacementu, manipulacji i ukrycia alarmów w ciągu ~26 godzin od pierwszego dostępu.
  • OAST w chmurze (Google Cloud) napędza skalowalną eksploatację setek CVE – to trend, który ułatwia przeciwnikom maskowanie aktywności.
  • Organizacje OT/ICS powinny natychmiast zidentyfikować instancje ScadaBR, wdrożyć łatki/mitigacje, utwardzić HMI i wprowadzić monitoring DPI z regułami pod XSS/OAST.

Źródła / bibliografia

  • NVD: CVE-2021-26829 (opis, wersje, CVSS, informacja o włączeniu do CISA KEV z datami 28.11.2025 / 19.12.2025) – National Vulnerability Database. (nvd.nist.gov)
  • VulnCheck: The Mystery OAST Host Behind a Regionally Focused Exploit Operation (OAST na Google Cloud, ~1400 prób, >200 CVE, 27.11.2025). (VulnCheck)
  • The Hacker News: CISA Adds Actively Exploited XSS Bug CVE-2021-26829 in OpenPLC ScadaBR to KEV (kontext i agregacja informacji, 30.11.2025). (The Hacker News)

CISA dodaje nową lukę do katalogu KEV (28 listopada 2025): krytyczne RCE w Oracle Identity Manager (CVE-2025-61757)

Wprowadzenie do problemu / definicja luki

28 listopada 2025 r. CISA dodała jedną nową pozycję do katalogu Known Exploited Vulnerabilities (KEV) po potwierdzeniu aktywnego wykorzystywania. Najświeższe doniesienia branżowe i materiały źródłowe wskazują, że chodzi o CVE-2025-61757 – krytyczną podatność typu pre-auth RCE w Oracle Identity Manager (OIM), składniku pakietu Oracle Fusion Middleware, ocenioną na CVSS 9,8. Oracle załatał problem w ramach Critical Patch Update z 21 października 2025. CISA wyznaczyła federalnym agencjom termin remediacji do 12 grudnia 2025.


W skrócie

  • Produkt: Oracle Identity Manager (OIM) – REST WebServices.
  • Identyfikator: CVE-2025-61757, CVSS 9.8 (Critical).
  • Natura błędu: obejście uwierzytelniania prowadzące do zdalnego wykonania kodu (RCE) bez logowania.
  • Status: aktywnie wykorzystywana; dodana do CISA KEV; patch dostępny od 21.10.2025.
  • Termin CISA (FCEB): do 12.12.2025 należy załatać lub wyłączyć podatne systemy.

Kontekst / historia / powiązania

Badacze Searchlight Cyber opublikowali 20 listopada 2025 r. szczegóły techniczne luki, a SANS ISC odnotował próby dostępu do charakterystycznego endpointu już pod koniec sierpnia i na początku września 2025, co sugeruje exploitation jako zero-day przed wydaniem łat. Media branżowe (CSO Online) potwierdziły dodanie do CISA KEV i podkreśliły skrócony horyzont działań dla instytucji federalnych.


Analiza techniczna / szczegóły luki

Wadliwy filtr uwierzytelniania w OIM opierał się na „białej liście” wzorców URL. Dwa wektory manipulacji ścieżką pozwalały ominąć ochronę:

  1. Dodanie ?WSDL – filtr traktował trasę jako publiczną.
  2. Macierzowe parametry w ścieżce, np. ;.wadl – błędny regex powodował oznaczenie chronionych zasobów jako niechronione.

Po obejściu uwierzytelniania atakujący mógł osiągnąć endpoint weryfikacji składni Groovy (/groovyscriptstatus). W praktyce kompilacja Groovy uruchamia adnotacje wykonujące kod w czasie kompilacji, co umożliwia RCE bez uwierzytelnienia. SANS ISC raportował jednolity rozmiar ładunku ~556 bajtów, powtarzalny User-Agent i ścieżki zakończone ;.wadl.

Wersje podatne: 12.2.1.4.0 i 14.1.2.1.0 (OIM / Fusion Middleware). Oracle CPU z 21.10.2025 zawiera poprawkę. NVD klasyfikuje skutki jako pełne przejęcie OIM.


Praktyczne konsekwencje / ryzyko

  • Tożsamość w centrum ataku: OIM odpowiada za governance tożsamości – przejęcie oznacza ryzyko eskalacji uprawnień, zmian polityk, tworzenia/zmiany kont i pivotu w całej organizacji.
  • Ekspozycja perymetru: instancje OIM ujawnione do Internetu są wysokiego ryzyka (prosty exploit URL).
  • Łańcuchy ataków: obejście auth ⇒ dostęp do REST ⇒ kompilacja Groovy ⇒ RCE ⇒ implant / kradzież danych uwierzytelniających / trwałość.
  • Dowody w telemetrii: charakterystyczne wzorce ;.wadl, POST ~556 B, specyficzny User-Agent i próby dotarcia do endpointu Groovy.

Rekomendacje operacyjne / co zrobić teraz

  1. Patch teraz: zastosuj Oracle CPU (21.10.2025) dla OIM 12.2.1.4.0 i 14.1.2.1.0. Dla FCEB: deadline CISA 12.12.2025 (niespełnienie ⇒ odłączenie systemu).
  2. Izolacja i twardnienie:
    • Czasowo zablokuj zewnętrzny dostęp do OIM (VPN/ZTNA), jeśli patchowanie wymaga okna serwisowego.
    • WAF: blokuj wzorce z ;.wadl, ?WSDL, dostęp do /groovyscriptstatus i podobnych.
  3. Detekcja i monitoring:
    • Reguły na URI z ;.wadl, POST ≈556 B, znany UA fingerprint oraz odwołania do endpointu Groovy.
    • Koreluj ruch wychodzący serwera (kompilacja Groovy może inicjować callbacki).
  4. Hunting / IR:
    • Przejrzyj logi od 30.08–09.09.2025 i dalej pod kątem ww. artefaktów.
    • Waliduj integralność konfiguracji i artefaktów wdrożeniowych OIM; szukaj nietypowych adnotacji/klas w katalogach tymczasowych kompilacji.
  5. Długofalowo:
    • Ograniczaj publiczną ekspozycję REST OIM.
    • Migracja z allow-list/regex na per-route authz i silniejsze bramki przed warstwą API.

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

  • W przeciwieństwie do wielu ostatnich pozycji KEV (np. wtyczki WordPress czy urządzenia perymetrowe), CVE-2025-61757 uderza w rdzeń zarządzania tożsamością. Skutki kompromitacji są systemowe i mogą przewyższać skutki typowych RCE w usługach pomocniczych.
  • Podobnie jak w historycznych błędach filtrów Java/URL, sednem problemu jest logika dopuszczania ścieżek (regex + parametry macierzowe), co już wcześniej prowadziło do autobypassów.

Podsumowanie / kluczowe wnioski

  • CVE-2025-61757 (OIM) to krytyczna, aktywnie wykorzystywana podatność z prostym wektorem i ciężkimi skutkami (RCE).
  • Patch Oracle (21.10.2025) jest dostępny – wdrożenie bez zwłoki. FCEB: termin 12.12.2025.
  • Operacyjnie: blokady WAF, monitoring pod kątem ;.wadl/?WSDL, POST ~556 B, hunting logów i izolacja perymetru do czasu aktualizacji.

Źródła / bibliografia

  • CSO Online – potwierdzenie dodania do KEV i terminu CISA, opis ryzyka OIM. (CSO Online)
  • OracleCritical Patch Update Advisory – October 2025 (listuje podatne wersje OIM i dostępność poprawek). (Oracle)
  • NVD (NIST) – karta CVE-2025-61757 (opis techniczny, CVSS 9.8, skutki). (nvd.nist.gov)
  • SANS Internet Storm Center – obserwacje ruchu exploita (okres, UA, rozmiar ładunku, ścieżki). (SANS Internet Storm Center)
  • Searchlight Cyber (research) – analiza łańcucha obejścia auth i RCE przez kompilację Groovy/adnotacje. (Searchlight Cyber)

Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0

Czy backup to wystarczająca tarcza przed ransomware?

Jeszcze do niedawna wiele firm spało spokojnie, wierząc, że regularne kopie zapasowe uchronią je przed każdym atakiem. W końcu, jeśli dane zostaną zaszyfrowane, zawsze można je odzyskać z backupu, prawda? Niestety, nowa generacja ransomware – tzw. Ransomware 2.0 – brutalnie weryfikuje to założenie.

Czytaj dalej „Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0”