Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 324 z 331

Autor: Wojciech Ciemski

Krytyczna luka w SAP NetWeaver (CVE-2025-42944): deserializacja przez RMI-P4 pozwala na przejęcie serwera bez logowania

Wprowadzenie do problemu / definicja luki

W SAP NetWeaver AS Java ujawniono krytyczną podatność CVE-2025-42944 (CVSS 10.0), klasy insecure deserialization. Atakujący bez uwierzytelnienia mogą przesłać złośliwy ładunek do modułu RMI-P4 nasłuchującego na otwartym porcie i osiągnąć wykonanie poleceń w systemie operacyjnym serwera SAP. SAP ujęło problem w październikowym Patch Day jako aktualizację noty bezpieczeństwa (pierwsza poprawka wyszła we wrześniu 2025).

W skrócie

  • Identyfikator: CVE-2025-42944
  • Skala: CVSS 10.0 (krytyczna)
  • Komponent: SAP NetWeaver AS Java, interfejs RMI-P4
  • Wymagania ataku: brak uwierzytelnienia, zasięg sieciowy
  • Skutek: zdalne wykonanie kodu / komend OS, pełne przejęcie instancji
  • Status poprawek: poprawki opublikowane, uzupełnione w Patch Day październik 2025; systemy należy zaktualizować niezwłocznie.

Kontekst / historia / powiązania

Październikowy Patch Day SAP przyniósł pakiet łatek, w tym ponowne wzmocnienie zabezpieczeń wobec deserializacji w NetWeaver AS Java (CVE-2025-42944), a także korekty innych komponentów (m.in. SAP Print Service, SAP GUI for HTML, CSRF w AS ABAP). To sugeruje, że producent domyka scenariusze obejściowe względem pierwotnej poprawki z września.

W ostatnich miesiącach ekosystem SAP zmagał się z aktywnie wykorzystywanymi podatnościami, m.in. w Visual Composer (CVE-2025-31324, CVSS 10.0), która umożliwiała nieautoryzowany upload binariów i była łączona w łańcuchy RCE przez grupy APT. To podnosi wagę szybkiego patchowania NetWeavera oraz twardych kontroli na perymetrze.

Analiza techniczna / szczegóły luki

  • Klasa błędu: insecure deserialization w stosie Java.
  • Powierzchnia ataku: RMI-P4 — protokół komunikacyjny używany przez NetWeaver AS Java. Usługa nasłuchuje na interfejsie sieciowym i przetwarza przesyłane obiekty.
  • Warunki powodzenia: atak z sieci (zewnętrznej lub wewnętrznej), brak potrzeby posiadania konta SAP; dostarczenie specjalnie spreparowanego strumienia serializacji do otwartego portu RMI-P4.
  • Efekt: zainicjowanie łańcuchów deserializacji prowadzących do wykonania kodu/komend OS w kontekście procesu serwera aplikacyjnego.
  • Łatka październikowa: rozszerza ochronę wobec scenariuszy, których nie obejmowała łatka wrześniowa (tzw. defense-in-depth i/lub domknięcie wektorów obejścia).

Uwaga: szczegółowe artefakty (np. klasy, gadżety deserializacyjne) nie są publicznie opisane w notach SAP. Organizacje powinny polegać na oficjalnych poprawkach i kontrolach kompensacyjnych, nie na „sygnaturach” konkretnych łańcuchów.

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie instancji SAP AS Java, możliwość ruchu bocznego do systemów ABAP/S4 i baz danych.
  • Eksfiltracja danych (dane finansowe, HR, łańcuch dostaw), modyfikacje transakcji i integracji B2B.
  • Ransomware / sabotaż: zatrzymanie procesów biznesowych o krytycznym znaczeniu (ERP, SRM, BW/BOBJ).
  • Ryzyko CRQ/SoD: ominięcie mechanizmów autoryzacji dzięki wykonaniu kodu poza kontrolą aplikacyjną.
    Te wnioski wynikają z klasy błędu (RCE bez uwierzytelnienia) i roli NetWeavera w krajobrazie SAP oraz obserwowanej wcześniej aktywności wobec komponentów NetWeaver (np. Visual Composer).

Rekomendacje operacyjne / co zrobić teraz

1) Patchowanie (priorytet najwyższy)

  • Zastosuj październikowe poprawki SAP dla NetWeaver AS Java odnoszące się do CVE-2025-42944 (w tym aktualizację noty z września). Zweryfikuj, że wszystkie węzły/instancje w klastrze zostały zaktualizowane.

2) Ograniczenie ekspozycji RMI-P4

  • Ogranicz dostęp do interfejsu RMI-P4 do zaufanych sieci (ACL, segmentacja, WAF/Reverse Proxy/SAP Web Dispatcher), wyłącz zbędne usługi i protokoły zdalne.

3) Twardnienie i detekcja

  • Włącz wzmożone logowanie w AS Java i centralną korelację (SIEM).
  • Monitoruj nietypowe połączenia do portu usługi RMI-P4 i wzorce deserializacji/uruchamiania powłok.
  • Stosuj reguły EDR/NDR pod kątem: uruchomień interpreterów, living-off-the-land, tunelowania RMI, subsekwentnych połączeń do C2.
  • Przegląd praw i kluczy usługowych używanych przez integracje (minimalizacja szkód przy ewentualnym włamaniu).

4) Testy regresyjne i skany zgodności

  • Po aktualizacji wykonaj testy techniczne i biznesowe (interfejsy, RFC, JMS).
  • Zaktualizuj skanery i polityki zgodności (np. aby wykrywać stare wersje komponentów AS Java).

5) Zarządzanie ryzykiem

  • Dodaj CVE-2025-42944 do wewnętrznego rejestru ryzyka i KPI „patch SLA” dla systemów Internet-facing.
  • Przeprowadź table-top exercise dla scenariusza przejęcia AS Java i ruchu bocznego do krańcowych systemów finansowych.

Różnice / porównania z innymi przypadkami

  • CVE-2025-42944 (NetWeaver AS Java, RMI-P4, deserializacja, bez uwierzytelnienia) — RCE z sieci; krytyczne i pre-auth.
  • CVE-2025-31324 (Visual Composer, upload pliku) — również bardzo ciężkie (CVSS 10.0), często łączone w łańcuchy ataku; potwierdzona aktywna eksploatacja w 2025 r.
  • Inne łatki z Patch Day październik 2025 obejmują m.in. SAP Print Service (Directory Traversal, CVSS 9.8) oraz aktualizacje ABAP/GUI i CSRF — ważne, ale o innych wektorach.

Podsumowanie / kluczowe wnioski

  • CVE-2025-42944 to krytyczna, pre-auth RCE w SAP NetWeaver AS Java przez RMI-P4.
  • SAP wydało poprawki we wrześniu i dodatkowe zabezpieczenia w październiku 2025 — należy wdrożyć natychmiast i ograniczyć ekspozycję usług zdalnych.
  • Historia ostatnich ataków na NetWeaver (np. CVE-2025-31324) pokazuje, że opóźnienia w patchowaniu szybko przekładają się na kompromitacje.

Źródła / bibliografia

  1. The Hacker News — „New SAP NetWeaver Bug Lets Attackers Take Over Servers Without Login” (15 paź 2025). (The Hacker News)
  2. SAP — „Security Patch Day — October 2025” (aktualizacja not bezpieczeństwa, 2 dni temu). (support.sap.com)
  3. SecurityWeek — „SAP Patches Critical Vulnerabilities in NetWeaver, Print Service, SRM” (konkret dot. CVE-2025-42944 i uzupełnień październikowych). (SecurityWeek)
  4. Onapsis — „SAP Security Patch Day — October 2025” (tło do innych krytycznych poprawek i priorytetyzacja). (Onapsis)
  5. Onapsis / CISA — materiały dot. wcześniejszej, aktywnie wykorzystywanej luki CVE-2025-31324 (kontekst zagrożeń dla NetWeaver). (Onapsis)

Czy ISO/IEC 27001 Zapewnia Zgodność Z NIS2?

Wstęp: ISO 27001 a NIS2 – dobra baza to za mało

Certyfikat ISO 27001 stanowi solidną bazę bezpieczeństwa informacji, jednak sam w sobie nie gwarantuje pełnej zgodności z dyrektywą NIS2. ISO 27001 pokrywa co prawda większość wymagań techniczno-organizacyjnych, ale nie spełnia szeregu obowiązków prawnych NIS2, takich jak formalna identyfikacja podmiotów i nadzór państwowy czy raportowanie incydentów w ścisłych terminach (24h/72h) oraz osobista odpowiedzialność zarządu. Innymi słowy – certyfikat ISO 27001 ≠ zgodność z NIS2. Poniżej wyjaśniamy różnice między dobrowolnym standardem ISO a obowiązkową regulacją prawną NIS2, wskazujemy co ISO zapewnia, a co trzeba uzupełnić, by organizacja była w pełni zgodna z NIS2.

Czytaj dalej „Czy ISO/IEC 27001 Zapewnia Zgodność Z NIS2?”

Adobe łata krytyczną podatność w pakiecie współpracy (Connect). Co powinni zrobić administratorzy?

Wprowadzenie do problemu / definicja luki

Adobe opublikowało poprawki bezpieczeństwa usuwające krytyczną lukę w Adobe Connect, platformie do wirtualnych spotkań i webinarów. Najpoważniejszy błąd to DOM-based XSS (CVE-2025-49553), oceniony na CVSS 9.3, który – przy odpowiedniej sekwencji działań – może prowadzić do zdalnego wykonania kodu (RCE) po stronie klienta. Łatka jest dostępna w wydaniu Adobe Connect 12.10.

W skrócie

  • Produkty/wersje: Adobe Connect 12.9 i starsze na Windows i macOS. Naprawa w 12.10.
  • Najpoważniejsza luka: CVE-2025-49553 (DOM-XSS, CVSS 9.3) → możliwość wykonania kodu. Dodatkowo CVE-2025-49552 (DOM-XSS, CVSS 7.3) oraz CVE-2025-54196 (open redirect, CVSS 3.1).
  • Status exploitów: brak informacji o aktywnym wykorzystywaniu w środowisku produkcyjnym.
  • Szeroki kontekst: w tym samym cyklu Adobe załatało ponad 35 luk w różnych produktach (m.in. Illustrator, Bridge, Animate).

Kontekst / historia / powiązania

Aktualizacja jest częścią październikowego cyklu łatkowania (Patch Tuesday). Poza Connect, Adobe opublikowało również biuletyny dla innych aplikacji kreatywnych – np. Illustrator (APSB25-102) – gdzie wyeliminowano luki prowadzące do RCE. To potwierdza, że ekosystem Adobe regularnie otrzymuje zbiorcze poprawki obejmujące zarówno narzędzia biurowo-kolaboracyjne, jak i kreatywne.

Analiza techniczna / szczegóły luki

Zgodnie z biuletynem APSB25-70 dla Adobe Connect:

  • CVE-2025-49553 – DOM-based XSS (CWE-79), CVSS 9.3, krytyczna: atakujący może dostarczyć spreparowany ładunek (np. przez złośliwy link lub wstrzyknięty skrypt), który po interakcji użytkownika uruchomi się w kontekście przeglądarki i umożliwi wykonanie kodu, kradzież tokenów sesyjnych, eskalację działań w ramach aplikacji itp. Wektor: AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N.
  • CVE-2025-49552 – DOM-based XSS (CWE-79), CVSS 7.3: podobna kategoria, ale wymaga wyższych uprawnień i trudniejszych warunków do skutecznej eksploatacji.
  • CVE-2025-54196 – Open Redirect (CWE-601), CVSS 3.1: umożliwia przekierowanie użytkownika na niezweryfikowany adres (sprzyja phishingowi, kradzieży poświadczeń).

SecurityWeek potwierdza, że poprawki dla Connect dostarczono w wersji 12.10, równolegle z pakietem innych biuletynów (łącznie >35 luk).

Praktyczne konsekwencje / ryzyko

  • Ryzyko kompromitacji sesji i kont: DOM-XSS w aplikacjach webowych do spotkań pozwala na kradzież tokenów, wstrzyknięcie skryptów śledzących, przejęcie uprawnień w ramach aplikacji (np. moderowanie pokoju, dostęp do nagrań, materiałów).
  • Łańcuchowe nadużycia: Open Redirect ułatwia kampanie spear-phishingowe kierujące do stron wyłudzających MFA lub SSO, co może stać się etapem wstępnym do BEC/APT.
  • Ekspozycja w organizacjach hybrydowych: Connect jest często publikowany w internecie (dla gości/webinarów), co obniża próg dotarcia atakującego. (Wniosek na podstawie charakteru produktu i biuletynu.)

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja do Connect 12.10 na wszystkich hostach (Windows/macOS). Zweryfikuj zgodność w środowiskach testowych, ale nie odkładaj wdrożenia w produkcji.
  2. Twarde EDR/AV i polityki przeglądarek na stacjach prowadzących webinary (sandboxing, blokada niechcianych rozszerzeń, CSP gdzie to możliwe po stronie serwera).
  3. Higiena linków w zaproszeniach: generuj linki do spotkań wyłącznie z oficjalnych domen; skanuj treści opisów/webinarów pod kątem wstrzyknięć HTML/JS (reguły WAF).
  4. Monitorowanie anomalii:
    • Reguły SIEM/UEBA pod kliknięcia w nieoczekiwane linki przekierowujące (HTTP 3xx do domen spoza allowlisty).
    • Alarmy na zmianę ról w pokojach, nietypowe pobrania nagrań, masowe zaproszenia.
  5. Szkolenia dla prowadzących: znakowanie zewnętrznych prelegentów, weryfikacja materiałów, unikanie osadzania niezweryfikowanych skryptów/iframe.
  6. Przegląd innych biuletynów Adobe z tego cyklu (np. Illustrator) i zaplanowanie zbiorczego okna serwisowego — w październiku lista luk przekracza 35 pozycji.

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

W poprzednich miesiącach najgłośniejsze poprawki Adobe dotyczyły m.in. ColdFusion i Commerce/Magento (RCE, obejścia zabezpieczeń). Obecna runda przesuwa uwagę na warstwę kolaboracji (Connect), gdzie typowym ryzykiem są ataki webowe (XSS/redirect), a nie serwerowe luki w interpreterach czy komponentach backendowych. To wymaga innego zestawu kontroli – więcej CSP/WAF, przeglądarkowej telemetrii i higieny linków – zamiast samych hardeningów aplikacyjnych.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj do Connect 12.10 – to jedyny skuteczny sposób eliminacji CVE-2025-49553 i powiązanych luk.
  • Traktuj Connect jak krytyczną aplikację webową: CSP, WAF, monitorowanie przekierowań i tokenów.
  • W tym samym cyklu Adobe łata >35 luk w innych produktach – zaplanuj zbiorczy maintenance window zamiast ad-hoc instalacji.

Źródła / bibliografia

  • Adobe Security Bulletin – APSB25-70: Security update available for Adobe Connect (CVE-2025-49552, CVE-2025-49553, CVE-2025-54196; wersje i CVSS). Adobe Help Centre
  • SecurityWeek: Adobe Patches Critical Vulnerability in Connect Collaboration Suite (przegląd, skala poprawek >35 luk, kontekst). SecurityWeek
  • Adobe – APSB25-102: Security Updates Available for Adobe Illustrator (przykład innych produktów załatanych w tym cyklu). Adobe Help Centre
  • Qualys Blog – Patch Tuesday (październik 2025) (kontekst zbiorczy aktualizacji tego miesiąca). Qualys
  • The Cyber Express – Adobe Security Update (zestawienie CVE dla Connect; źródło wtórne). The Cyber Express

F5 obwinia „aktorów państwowych” o kradzież kodu źródłowego i danych o podatnościach BIG-IP

Wprowadzenie do problemu / definicja incydentu

15 października 2025 r. F5 ujawniło w raporcie Form 8-K oraz komunikacie do klientów, że wysoce zaawansowany, prawdopodobnie sponsorowany przez państwo napastnik utrzymywał długotrwały dostęp do wybranych systemów firmy, m.in. do środowiska rozwoju BIG-IP i platform wiedzy inżynierskiej. Z systemów tych wyeksfiltrowano pliki zawierające fragmenty kodu źródłowego BIG-IP oraz informacje o niewydanych jeszcze podatnościach (niepublicznych). F5 twierdzi, że nie ma dowodów na modyfikację łańcucha dostaw (pipeline’y build/release), ani na dostęp do środowisk NGINX, Distributed Cloud czy Silverline.

O sprawie jako pierwsze szeroko doniosły branżowe media, wskazując także, że profil ataku może wskazywać na Chiny.

W skrócie

  • Kiedy wykryto: 9 sierpnia 2025 r.; ujawnienie odroczono za zgodą DOJ (Item 1.05(c) 8-K).
  • Co ukradziono: pliki z częściami kodu BIG-IP i informacjami o niewydanych podatnościach; częściowo także konfiguracje/implementacje niewielkiego odsetka klientów.
  • Czego nie stwierdzono: brak dowodów na modyfikację supply chain, brak dostępu do CRM/finansów/iHealth/wsparcia; brak oznak aktywnego wykorzystywania „nieujawnionych krytycznych/ RCE” podatności F5.
  • Aktualizacje/łagodzenie: opublikowano zbiorcze biuletyny/aktualizacje październikowe dla BIG-IP, F5OS, BIG-IP Next, BIG-IQ i APM; F5 zaleca natychmiastowe wdrożenie.
  • Potwierdzenia zewnętrzne: media i niezależne serwisy powtórzyły główne tezy; NCSC wydało krótką notę z zaleceniem pilnych aktualizacji.

Kontekst / historia / powiązania

Urządzenia i oprogramowanie F5 BIG-IP od lat znajdują się w centrum uwagi APT i cyberprzestępców (m.in. fale exploitacji CVE-2020-5902, CVE-2022-1388 czy pary CVE-2023-46747/-46748). Trwałe utrzymanie się napastników w środowiskach wykorzystujących BIG-IP bywało wcześniej wiązane z chińsko-języcznymi grupami (np. kampania „Velvet Ant” z wykorzystaniem starszych urządzeń F5 dla utrzymania persystencji). Dzisiejszy incydent wpisuje się w ten trend polowania na źródła i wiedzę o 0-day u producentów.

Analiza techniczna / szczegóły luki

Z udostępnionego klientom oświadczenia (Exhibit 99.1 do 8-K) wynika, że:

  • Atakujący posiadali długoterminową persystencję w sieci F5, obejmującą repozytoria kodu i systemy KM.
  • Eksfiltracja objęła m.in. fragmenty kodu BIG-IP oraz opisy/artefakty podatności będących „w toku” (nieopublikowanych).
  • F5 nie zidentyfikowało dowodów na naruszenie łańcucha dostaw (źródła, build’y, pipeline’y), co potwierdziły niezależne audyty NCC Group i IOActive.
  • Brak dowodów na dostęp do NGINX oraz usług chmurowych F5, co ogranicza bezpośredni wektor supply-chain dla tych linii.

Choć firma podkreśla brak wiedzy o krytycznych/RCE nieujawnionych błędach, sama kradzież wiedzy o lukach zwiększa prawdopodobieństwo samodzielnego opracowania exploitów przez APT przed publikacją biuletynów („pre-disclosure weaponization”). To klasyczny wyścig z czasem: jeżeli opis podatności/patch różnicowy trafił do przeciwnika, okno narażenia dla klientów może się skrócić do tygodni lub dni.

Praktyczne konsekwencje / ryzyko

  • Ryzyko exploitów „day-(-1)” – użycie informacji o nieopublikowanych lukach F5 do cichych, ukierunkowanych wejść (szczególnie tam, gdzie konfiguracja BIG-IP bywa złożona i historycznie zaniedbana).
  • Rozpoznanie środowisk klientów – wyciek konfiguracji/implementacji części organizacji ułatwia lateral movement i selektywne omijanie WAF/ASM/AFM/APM.
  • Reputacyjne i regulacyjne – formalne ujawnienie w 8-K oznacza „material event” z potencjalnym wpływem na decyzje użytkowników i rynków; samo F5 ocenia na dziś brak istotnego wpływu operacyjnego.
  • Fala skanowania i prób dostępu – po medialnym nagłośnieniu zwykle rośnie aktywność botnetów i „copy-cats”.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe aktualizacje: wdrożyć październikowe wydania dla BIG-IP/F5OS/BIG-IP Next/BIG-IQ/APM zgodnie z biuletynem F5. Zaplanuj rolling upgrade i weryfikację po-update’ową.
  2. Threat hunting pod kątem F5:
    • Przejrzeć logi TMOS/ASM/APM oraz syslog z event streaming do SIEM (zgodnie z KB F5 – wzorce: logowania admin, nieudane auth, zmiany uprawnień/konfiguracji).
    • Użyć zaleceń F5 dot. twardnienia (hardening checks w iHealth) i porównać z własnymi benchmarkami.
  3. Segmentacja i kontrola dostępu: odseparować interfejsy zarządcze BIG-IP (Mgmt/SSH/TMU) od sieci produkcyjnych, wymusić MFA i listy dozwolonych.
  4. Repozytoria i tajemnice: skontrolować własne integracje CI/CD z BIG-IP (np. AS3/DO/FAST). Zmienić poświadczenia, tokeny API, klucze iControl REST.
  5. Atesty konfiguracji klientów: jeśli korzystasz z partnerów/Integratorów, zażądaj potwierdzenia, że nie używali artefaktów/fragmentów konfigów podatnych na wyciek.
  6. Monitoring exploitów: śledzić biuletyny CISA KEV i krajowe CERT-y; NCSC rekomenduje pilne wdrożenie poprawek F5.
  7. Plan awaryjny: przygotować playbook „virtual patching” na F5 (np. tymczasowe iRules/policy WAF) w razie pojawienia się PoC przed pełnym patchem.

Różnice / porównania z innymi przypadkami

  • SolarWinds/3CX – głęboka manipulacja supply chain; tutaj F5 i niezależne audyty raportują brak modyfikacji pipeline’ów i artefaktów wydań, co zmniejsza ryzyko „zatrutych” aktualizacji.
  • Wycieki „knowledge-base” u dostawców (np. przypadki wiązane z MAPP/SharePoint) – wspólny motyw to pozyskanie wiedzy o 0-day przed publikacją, a niekoniecznie natychmiastowe uderzenie supply-chain. W doniesieniach prasowych o incydencie F5 przewija się hipoteza o aktorze z Chin, spójna z wcześniejszymi kampaniami przeciw producentom infrastruktury.

Podsumowanie / kluczowe wnioski

  • Incydent nie wygląda na kompromitację łańcucha dostaw, ale na wyciek kodu i „researchu” o lukach – co nadal jest poważnym zagrożeniem.
  • Czas działa na korzyść obrońców tylko wtedy, gdy szybko wdrożą aktualizacje i wymuszą twardnienie/monitoring zgodnie z zaleceniami F5.
  • Organizacje z krytycznymi wdrożeniami BIG-IP powinny traktować najbliższe tygodnie jako okres podwyższonego czuwania i aktywnie polować na anomalie.

Źródła / bibliografia

  1. F5 – Security Incident: Disclosure Statement (Exhibit 99.1 do 8-K, 15.10.2025) – szczegóły o eksfiltracji, produktach i zaleceniach. (SEC)
  2. SEC EDGAR – F5, Inc. Form 8-K (15.10.2025) – formalne zgłoszenie incydentu (Item 1.05). (SEC)
  3. SecurityWeek (15.10.2025) – przegląd incydentu i wskazanie na profil ataku sugerujący Chiny. (SecurityWeek)
  4. BleepingComputer (15.10.2025) – streszczenie zakresu eksfiltracji i harmonogramu wykrycia. (BleepingComputer)
  5. NCSC (UK) – nota potwierdzająca kompromitację i zalecająca wdrożenie aktualizacji. (NCSC)

Krytyczne ryzyko łańcucha dostaw w marketplace’ach rozszerzeń VS Code: co odkrył Wiz i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Zespół Wiz Research ujawnił 15 października 2025 r. systemowy problem bezpieczeństwa w ekosystemie rozszerzeń VS Code: setki kluczy i tokenów dostępowych zostały nieumyślnie spakowane w paczki rozszerzeń i opublikowane w Visual Studio Code Marketplace oraz Open VSX. W ponad stu przypadkach były to tokeny umożliwiające… aktualizację samego rozszerzenia — a ponieważ VS Code domyślnie autoaktualizuje rozszerzenia, przejęcie takiego tokenu pozwalałoby rozesłać złośliwą aktualizację do całej bazy instalacji danego rozszerzenia.

W skrócie

  • Wiz znalazł 550+ ważnych sekretów w 500+ rozszerzeniach od setek wydawców; w tym tokeny Azure DevOps (VS Marketplace) i Access Tokens Open VSX. Łącznie dotknięta baza instalacji to ponad 85 tys. (VS Marketplace) i 100 tys. (Open VSX).
  • Po zgłoszeniu przez Wiz, Microsoft włączył skanowanie sekretów i blokowanie publikacji rozszerzeń zawierających wykryte klucze; skanowanie objęło też istniejące rozszerzenia.
  • Open VSX wprowadził prefiks tokenu („ovsxp_”) ułatwiający wykrywanie wycieków przez narzędzia skanujące.

Kontekst / historia / powiązania

Ryzyko łańcucha dostaw w IDE narasta od lat: rozszerzenia mają dostęp do środowiska dewelopera i mogą wykonywać kod. Microsoft dokumentował mechanizmy kontroli i „trust” w runtime rozszerzeń, ale tajne klucze w paczkach to inny wektor — działa poza samym silnikiem uprawnień: atak następuje na etapie publikacji/aktualizacji. Dlatego Microsoft zapowiedział i wdrożył „Secret Detection for Extensions” w Marketplace, a dodatkowo opisał szerszy plan podniesienia zaufania do ekosystemu.

Analiza techniczna / szczegóły luki

Wiz rozpakowywał paczki .vsix (to zwykłe archiwa ZIP) i znajdował w nich m.in.:

  • Dotfiles i pliki konfiguracyjne (np. .env, config.json, mcp.json, .cursorrules) zawierające klucze;
  • Twardo zakodowane sekrety w kodzie/package.json/README;
  • Tokeny wydawców:
    • Azure DevOps PAT (dla publikacji do VS Marketplace),
    • Open VSX Access Tokens (dla Open VSX).

Najgroźniejsze były tokeny publikacyjne — przejęcie ich pozwalałoby wypchnąć złośliwą wersję do całej bazy odbiorców danego rozszerzenia (przy włączonym auto-update). Wiz potwierdził 100+ ważnych PAT-ów VS Marketplace (ok. 85 tys. instalacji) oraz 30+ tokenów Open VSX (ok. 100 tys. instalacji).

Praktyczne konsekwencje / ryzyko

  • Masowa dystrybucja malware przez zaufany kanał aktualizacji rozszerzeń.
  • Ukierunkowane ataki na firmy korzystające z wewnętrznych/„vendor-specific” rozszerzeń opublikowanych publicznie „dla wygody”.
  • „Fałszywe poczucie bezpieczeństwa” przy motywie/tematach (themes) — choć zwykle nie zawierają kodu, nic nie blokuje dołączenia złośliwych payloadów do takiej paczki.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów developerskich

  1. Minimalizacja rozszerzeń – instaluj tylko niezbędne; oceń reputację wydawcy, historię wersji i liczbę instalacji.
  2. Zarządzanie autoaktualizacją – rozważ kontrolowane okna aktualizacji i obserwację zmian uprawnień/rozmiaru paczki; w środowiskach korporacyjnych wdrażaj aktualizacje etapowo.
  3. Inwentaryzacja i „allowlista” rozszerzeń (VS Code wspiera centralne polityki).

Dla wydawców rozszerzeń

  1. CI gate na sekrety: uruchamiaj skanery sekretów (np. GitHub Advanced Secret Scanning/partner program) i blokuj build/publikację przy wykryciu.
  2. Higiena repo/paczki: usuń .env i inne dotfiles z artefaktów (.vscodeignore / konfiguracja vsce), rotuj i skracaj TTL dla tokenów.
  3. Migracja tokenów: używaj tokenów z identyfikowalną strukturą/prefiksem (np. ovsxp_ w Open VSX) – to zwiększa skuteczność ochrony.

Dla operatorów platform

  1. Blokowanie publikacji z sekretami (pre-publish scanning) i skan „retro” istniejących rozszerzeń. Microsoft ogłosił i włączył tryb blocking w VS Marketplace.
  2. Standardyzacja sekretów (prefiksy, checksumy, CASK) oraz krótkie TTL.
  3. Transparentność i roadmapa bezpieczeństwa — publikowanie postępów i zasad (jak w aktualizacji Microsoft z czerwca 2025).

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

Ta kampania nie polegała głównie na publikacji ewidentnie złośliwych rozszerzeń, ale na wyciekach sekretów wydawców, co czyni wektor wyjątkowo niebezpiecznym: atakujący może podszyć się pod legalnego wydawcę i wykorzystać auto-update. To odróżnia sprawę od „klasycznych” kampanii złośliwych pluginów, a reakcje platform (blokowanie publikacji, skan istniejących paczek, prefiksy tokenów) są tu kluczowe.

Podsumowanie / kluczowe wnioski

  • Łańcuch dostaw IDE to realny wektor ataku: sekret w paczce rozszerzenia = potencjał RCE przez zaufaną aktualizację.
  • Reakcja platform (blokowanie publikacji, retro-skan, prefiksy tokenów) znacząco zmniejsza ryzyko, ale higiena po stronie wydawców i zespołów pozostaje niezbędna.
  • Organizacje powinny wdrożyć allowlistę, inwentaryzację, kontrolowane aktualizacje oraz policyjne skanowanie sekretów w CI/CD.

Źródła / bibliografia

  1. Wiz Research: “Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (15 października 2025). (wiz.io)
  2. GitHub (Microsoft VS Marketplace): „Upcoming Security Enhancement: Secret Detection for Extensions” + ogłoszenie trybu blocking. (GitHub)
  3. Microsoft DevBlogs: „Security and Trust in Visual Studio Marketplace” (11 czerwca 2025). (Microsoft for Developers)
  4. Open VSX (Eclipse): dokumentacja prefiksu tokenów ovsx.token-prefix. (GitHub)
  5. VS Code Docs: „Extension runtime security” (sekcja o skanowaniu sekretów i blokowaniu publikacji). (Visual Studio Code)

ICTBroadcast (CVE-2025-2611): krytyczna komenda w ciasteczku, aktywnie wykorzystywana w atakach

Wprowadzenie do problemu / definicja luki

CVE-2025-2611 to krytyczna podatność typu command injection w ICTBroadcast (oprogramowanie autodialer/call center). Błąd polega na tym, że aplikacja niebezpiecznie przekazuje zawartość ciasteczka sesyjnego do powłoki, co pozwala napastnikowi – bez uwierzytelnienia – wykonywać zdalnie dowolne komendy systemowe (RCE). Według analizy VulnCheck ataki są już w toku i obejmują skanowanie oraz próby zestawienia powłok odwrotnych. Badacze szacują, że w sieci jest wystawionych „kilkaset” instalacji, które w ogóle nie powinny być publicznie dostępne.

W skrócie

  • Produkt: ICTBroadcast (wersje ≤ 7.4 znane jako podatne).
  • Identyfikator: CVE-2025-2611, CVSS v4: 9.3 (CRITICAL).
  • Wektor: nagłówek HTTP Cookie – manipulacja ciasteczkiem (np. BROADCAST) prowadzi do wykonania komend.
  • Status: aktywnie wykorzystywana (wykryte kampanie; dostępny moduł Metasploit).
  • Ekspozycja: ~200 hostów widocznych w Internecie.
  • Działania priorytetowe: odizolować wystawione instancje, zaktualizować, wdrożyć WAF/IPS, doraźne reguły detekcyjne i polisy nagłówków, przeszukać logi pod kątem IOCs.

Kontekst / historia / powiązania

Podatność została zgłoszona vendorowi w marcu 2025 r., a po przekroczeniu 120-dniowego okna ujawnienia pojawił się publiczny moduł Metasploit – co typowo znacząco przyspiesza falę eksploatacji w Internecie. 11 października 2025 r. VulnCheck dodał CVE-2025-2611 do własnego VulnCheck KEV (katalog aktywnie wykorzystywanych luk) po obserwacji realnych ataków. Część wskaźników ataku (m.in. adresy IP i wykorzystanie tunelowania localtonet) pokrywa się z kampanią opisywaną wcześniej przez Fortinet, co sugeruje re-use narzędzi/infrastruktury.

Analiza techniczna / szczegóły luki

Mechanika jest prosta i dlatego groźna:

  • Aplikacja ewaluje dane z ciasteczka w kontekście powłoki. Atakujący wstawia w ciasteczko sekwencję poleceń; popularny wariant to payload zakodowany base64, który serwer dekoduje i odpala (|base64 -d|sh).
  • Widoczne w telemetrii dwie fazy:
    1. sonda czasowa (np. komenda sleep) do potwierdzenia RCE,
    2. dowiezienie powłoki – m.in. przez mkfifo+nc, warianty awk, czy sprytne python+zlib w ciasteczku.
  • Wystarczy pojedynczy żądany URL (np. /login.php) z odpowiednio przygotowanym nagłówkiem Cookie; uwierzytelnienie nie jest wymagane.
  • NVD wskazuje na Improper Input Validation (CWE-20) i potwierdza zakres (≤ 7.4) oraz scoring CVSS v4 zgodny z VulnCheck.

Dostępne narzędzia ataku

Publiczny moduł Metasploit (linux/http/ictbroadcast_unauth_cookie) automatyzuje wysyłkę złośliwego ciasteczka i uzyskanie RCE – to podnosi ryzyko „commodity exploits” również przez mniej zaawansowanych sprawców.

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie hosta: wykonywanie komend jako użytkownik usługi/webservera; eskalacja uprawnień możliwa lokalnie.
  • Pivot do sieci wewnętrznej: hosty te często mają dostęp do baz danych PBX/CRM.
  • Exfiltracja danych i nadużycia telekomunikacyjne: kradzież list kontaktowych, nadużycia kosztowe (robocalls), reputacyjne i prawne.
  • Łańcuchowe kampanie: pokrycie IOCs z innymi operacjami sugeruje możliwość kampanii masowych i ponownego wykorzystania infrastruktury.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe ograniczenie ekspozycji

  • Jeżeli ICTBroadcast jest publicznie dostępny, odłącz go od Internetu lub przepuść wyłącznie przez VPN/zerotrust z MFA.
  • Dodaj tymczasowe reguły WAF/IPS blokujące nagłówki Cookie zawierające backticki, potoki (|), base64 -d, czy wzorce mkfifo, nc, awk, python -c.

2) Aktualizacja i twarda konfiguracja

  • Zaktualizuj do najnowszej wersji dostawcy (wersje ≤ 7.4 są znane jako podatne według NVD). Po aktualizacji przeprowadź testy regresyjne i sprawdź noty wydania.

3) Detekcja i reagowanie (IR)

  • Przeskanuj logi HTTP pod kątem podejrzanych ciasteczek (BROADCAST=..., sekwencje base64, backticki).
  • Sprawdź ewentualne połączenia wychodzące do znanych IOCs (np. localtonet.com, IP 143.47.53.106, itp.).
  • Zweryfikuj, czy na hoście nie ma trwałych mechanizmów (crontab, systemd timers, autoruns) ani nietypowych plików w /tmp.
  • Zaimplementuj reguły IDS/IPS – VulnCheck publikuje gotowe sygnatury Snort/Suricata dla klientów.

4) Zmniejszanie ryzyka długoterminowo

  • Segmentacja i zasada najmniejszych uprawnień dla serwerów telekomunikacyjnych.
  • AppArmor/SELinux oraz sandboxing procesów WWW.
  • Włączenie monitoringu EDR i list kontroli aplikacji dla procesów sieciowych (nc, bash, python).
  • Używaj list KEV (np. VulnCheck KEV) jako wejścia do priorytetyzacji patchy i skanowań ataków w toku.

Różnice / porównania z innymi przypadkami

W odróżnieniu od wielu RCE w aplikacjach web, tu wektor to ciasteczko (pre-auth), a nie parametry URL/POST. To ułatwia ukrycie się przed prostymi filtrami. W porównaniu z głośnymi 0-dayami w urządzeniach VPN (np. Ivanti z 2025 r.), bariera wejścia jest podobnie niska, ale powierzchnia mniejsza – to jednak nie zmniejsza krytyczności dla organizacji, które wdrożyły ICTBroadcast jako usługę internetową.

Podsumowanie / kluczowe wnioski

  • CVE-2025-2611 to krytyczna, pre-auth RCE; ataki już trwają i mają dwa powtarzalne etapy (sonda + powłoka).
  • Publiczny Metasploit przyspiesza masową eksploatację.
  • Priorytety: natychmiastowa izolacja hostów, aktualizacja, reguły WAF/IPS, przegląd logów i IOCs, wzmocnienie hostów i segmentacja.

Źródła / bibliografia

  1. VulnCheck: „ICTBroadcast Command Injection Actively Exploited (CVE-2025-2611)” – szczegóły techniczne, payloady, IOCs i status KEV (14 paź 2025). (VulnCheck)
  2. NVD: wpis CVE-2025-2611 – opis, zakres wersji (≤ 7.4), CVSS v4 i odniesienia. (NVD)
  3. Rapid7 Metasploit Wrap-Up (08 sie 2025): dostępność modułu ictbroadcast_unauth_cookie. (Rapid7)
  4. The Hacker News: podsumowanie i potwierdzenie aktywnej eksploatacji w środowisku. (The Hacker News)
  5. VulnCheck KEV (strona społeczności): wykorzystanie KEV do priorytetyzacji reakcji. (VulnCheck)

ICS Patch Tuesday (październik 2025): łatki od Siemens, Schneider Electric, Rockwell, ABB i Phoenix Contact – co musisz zrobić dziś

Wprowadzenie do problemu / definicja luki

Tegoroczny ICS Patch Tuesday (15 października 2025 r.) przyniósł serię biuletynów bezpieczeństwa od czołowych dostawców OT/ICS. Najważniejsze: krytyczne błędy w produktach Siemens (TeleControl/ET 200SP, SiPass), poprawki Rockwell (m.in. FactoryTalk, NAT router 1783-NATR, moduły 1715), aktualizacje ABB (B&R) oraz Phoenix Contact (QUINT4 UPS, CHARX SEC-3xxx). Część problemów umożliwia zdalne, nieautoryzowane działania, w tym pozyskanie skrótów haseł, obejście uwierzytelniania, a nawet modyfikację konfiguracji urządzeń.

W skrócie

  • Siemens: krytyczne luki w SIMATIC ET 200SP CP (brak wymaganego uwierzytelnienia dla połączeń konfiguracyjnych) oraz TeleControl Server Basic (ujawnienie skrótów haseł); dodatkowo wiele poważnych usterek w SiPass integrated i poprawki dla Solid Edge.
  • Rockwell: nowe i zaktualizowane porady dot. m.in. FactoryTalk (priv-esc, DoS/XXE), 1783-NATR (krytyczne problemy auth/NAT) oraz 1715 EtherNet/IP (DoS).
  • ABB (B&R): seria porad dot. Automation Runtime SDM, MConfig i innych komponentów.
  • Phoenix Contact: zestaw podatności w QUINT4-UPS EIP (DoS, wyciek poświadczeń) i CHARX SEC-3xxx (command injection z uprawnieniami root).
  • Moxa: październikowe porady dot. twardo zakodowanych kluczy SSH i słabych szyfrów w serii TRC-2190.

Kontekst / historia / powiązania

Patch Tuesday dla ICS/OT konsoliduje ogłoszenia wielu vendorów, co pomaga działom OT skoordynować okna serwisowe. Ten cykl przyniósł ponad 20 biuletynów, a najgłośniejsze poprawki dotyczą produktów wdrażanych w segmentach: energetyka, produkcja dyskretna, automatyka budynkowa i e-mobilność. SecurityWeek podsumował je zbiorczo, a szczegóły techniczne potwierdzają portale producentów oraz CERT-y branżowe.

Analiza techniczna / szczegóły luki

Siemens

  • SIMATIC ET 200SP Communication Processors – CVE zbiorcze, CVSS 9.8/9.3: luka w uwierzytelnianiu umożliwia nieautoryzowany dostęp do danych konfiguracyjnych z sieci; wymaga aktualizacji wg SSA-486936.
  • TeleControl Server Basic – podatność ujawniająca hash’e haseł użytkowników, co może umożliwić późniejsze logowanie i operacje na bazie; wymaga aktualizacji do wersji łatającej gałąź 3.1.2.x.
  • SiPass integrated (< 3.0) – łańcuch błędów pozwalających atakującemu m.in. przejąć konta, manipulować danymi i wykonać kod po stronie serwera.

Rockwell Automation

  • Zestaw porad dla FactoryTalk (Linx, View ME/PanelView Plus 7, ViewPoint) dot. eskalacji uprawnień i DoS; dodatkowo poprawki dla 1783-NATR (uwierzytelnianie i modyfikacja reguł NAT) i 1715 EtherNet/IP (DoS). Szczegółowe wyliczenie luk i produktów – w przeglądzie Patch Tuesday.

ABB (B&R)

  • Automation Runtime – SDM: zestaw problemów (m.in. przejęcie sesji/kod), a także inne świeże biuletyny (np. MConfig – ujawnianie haseł w czystym tekście). Lista i dokumenty PDF/CSAF dostępne w portalu ABB/B&R.

Phoenix Contact

  • QUINT4-UPS EIP – wiele CVE: od DoS wywoływanego zdalnie po pozyskanie poświadczeń;
  • CHARX SEC-3xxx – command injection z root w firmware (zalecana aktualizacja do FW 1.7.4 wg najnowszej noty CERT@VDE).

Moxa

  • TRC-2190 – poprawki dotyczą twardo zakodowanych kluczy SSH i problemów kryptograficznych (SWEET32/średnia siła szyfrów).

Praktyczne konsekwencje / ryzyko

  • Utrata integralności i dostępności systemów: DoS na modułach sieciowych/UPS może wstrzymać komunikację lub zasilanie linii technologicznej.
  • Nieautoryzowana konfiguracja/sterowanie: luki auth (Siemens ET 200SP, Rockwell 1783-NATR) pozwalają modyfikować parametry sieci/urządzeń.
  • Przejęcie kont i eskalacja uprawnień: SiPass oraz FactoryTalk (wybrane komponenty) umożliwiają impersonację i wykonanie kodu.
  • Łańcuch ataku od IT do OT: słabe SSH/certyfikaty (Moxa) ułatwiają rozpoznanie i pivot na segment OT.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzuj:
    • Krytyczne: Siemens ET 200SP CP, TeleControl Server Basic, Phoenix Contact CHARX, Rockwell 1783-NATR / 1715.
  2. Zaplanuj okna serwisowe i zastosuj łatki/aktualizacje firmware zgodnie z poradami producentów (Siemens ProductCERT, ABB/B&R, Phoenix Contact PSIRT).
  3. Zredukuj ekspozycję: segmentacja sieci (L3/L2), ACL, zamknięcie interfejsów konfiguracyjnych na CP/serwerach HMI/SCADA, firewall dla CHARX (zalecenie producenta).
  4. Zarządzaj poświadczeniami: natychmiastowa rotacja haseł / wyłączenie kont domyślnych, wymuszenie MFA tam, gdzie dostępne; audyt wycieków hashy (TeleControl).
  5. Twardy hardening: wyłączenie zbędnych usług (np. SDM w B&R jeśli nieużywany), ujednolicenie konfiguracji SSH/kryptografii, monitoring XXE/DoS na usługach webowych (FactoryTalk ViewPoint).
  6. Detekcja i reagowanie: reguły IDS/IPS dla Modbus/TCP, CIP, OPC UA; logowanie zmian NAT/konfiguracji; playbooki IR dla utraty zasilania/UPS. (ogólne dobre praktyki OT)

Różnice / porównania z innymi przypadkami

  • Brak uwierzytelniania vs. słabe szyfry: ET 200SP/1783-NATR to logiczne obejście kontroli dostępu, podczas gdy Moxa TRC-2190 to słabość kryptograficzna obniżająca próg wejścia dla MITM.
  • Serwery dostępu fizycznego (SiPass) vs. komponenty sieciowe (1715/CP/NAT): pierwsze grozi przejęciem tożsamości i RCE w aplikacji, drugie – trwałym zakłóceniem komunikacji/sterowania.

Podsumowanie / kluczowe wnioski

  • Październikowy Patch Tuesday w OT/ICS to krytyczne poprawki, których wdrożenie powinno być priorytetem w tym tygodniu.
  • Skup się na: Siemens ET 200SP/TeleControl/SiPass, Rockwell FactoryTalk & urządzenia sieciowe, Phoenix Contact QUINT4 & CHARX, ABB/B&R SDM, Moxa TRC-2190.
  • Poza łataniem, segmentacja + hardening + monitoring znacząco ograniczają ryzyko eksploatacji.

Źródła / bibliografia

  1. SecurityWeek – zbiorcze podsumowanie ICS Patch Tuesday (15.10.2025). (SecurityWeek)
  2. Siemens ProductCERT – SSA-486936 (SIMATIC ET 200SP CP – authentication vuln). (cert-portal.siemens.com)
  3. Siemens ProductCERT – SSA-599451 (SiPass integrated < 3.0 – multiple vulns). (cert-portal.siemens.com)
  4. CERT@VDE – Advisories – Phoenix Contact QUINT4-UPS EIP i CHARX SEC-3xxx (CVE pakiet + rekomendacje). (certvde.com)
  5. ABB/B&R – Cyber Security: Alerts and Notifications – B&R Automation Runtime SDM, MConfig, EIBPORT (październik 2025). (ABB Group)