Archiwa: DDoS - Strona 20 z 25 - Security Bez Tabu

CVE-2019-2725 — Oracle WebLogic Server deserialization RCE

TL;DR

Krytyczna luka RCE w Oracle WebLogic (CVE‑2019‑2725) umożliwia zdalne, nieautoryzowane wykonanie kodu przez podatne endpointy SOAP/WS‑AT (/_async/AsyncResponseService, /wls-wsat/CoordinatorPortType). Atak bazuje na niebezpiecznej deserializacji (java.beans.XMLDecoder). Najczęstsze skutki: instalacja webshelli (JSP), kryptokoparki (XMRig) lub ransomware (REvil/Sodinokibi). Główne detekcje: nietypowe żądania POST do ww. ścieżek + procesy powłokowe z rodzicem java/java.exe na serwerze aplikacyjnym. Natychmiastowe działania: izolacja hosta, wyszukanie webshelli w katalogach WebLogic, aktualizacja do wersji naprawczej i segmentacja sieci.


Krótka definicja techniczna

CVE‑2019‑2725 to błąd deserializacji w komponencie Web Services Oracle WebLogic Server, który pozwala zdalnemu napastnikowi (bez uwierzytelnienia) wysłać spreparowany SOAP/XML i uruchomić dowolny kod po stronie serwera. Podatne są instalacje z włączonymi archiwami wls9_async_response.war i/lub wls-wsat.war, a typowe wektory to żądania POST do endpointów asynchronicznych i WS‑AtomicTransaction.


Gdzie występuje / przykłady platform

  • Windows / Linux (on‑prem): klasyczne wdrożenia WebLogic (AdminServer/ManagedServer).
  • AD: integracje SSO/LDAP po kompromitacji mogą posłużyć do lateral movement.
  • AWS: EC2/Autoscaling; często za ALB/WAF (logi CloudWatch/ALB).
  • Azure / GCP: VM Scale Sets/Compute Engine; analogicznie za load balancerami.
  • Kubernetes: WebLogic Operator (konteneryzacja); ruch przychodzi przez Ingress/Service.
  • ESXi: WebLogic jako VM-y; artefakty systemowe na datastore.
  • M365: brak bezpośredniego wpływu — istotne tylko pod kątem tożsamości/poczty w dalszych fazach.

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

  • Mechanizm ataku: napastnik wysyła żądanie SOAP/XML zawierające obiekt do przetworzenia przez XMLDecoder, co prowadzi do wykonania łańcucha gadżetów Javy i uruchomienia poleceń systemowych w kontekście procesu JVM WebLogic. Najczęściej wykorzystywane endpointy: /_async/AsyncResponseService (wls9‑async) oraz /wls-wsat/* (WS‑AT).
  • Skutki: pełne przejęcie serwera (pre‑auth RCE). Następnie typowe TTP: pobranie ładunku (T1105), uruchomienie interpreterów (T1059), zainstalowanie webshella JSP dla stałego dostępu (T1505.003).
  • Dlaczego skuteczna: brak uwierzytelniania, łatwość masowego skanowania/wykorzystania, popularność WebLogic w środowiskach krytycznych. Ataki obserwowano m.in. w kampanii ransomware REvil/Sodinokibi oraz w botnecie Muhstik kopiącym Monero.
  • Status i poprawki: Oracle wydał poza-cykliczny alert 26.04.2019 z poprawkami; luka figuruje w katalogu CISA KEV.

Artefakty i logi

ŹródłoArtefakt/LogEID / PoleCo obserwowaćUwagi
Web/proxy/WAFAccess logs (Nginx/IIS/WebLogic HTTP Server)cs-uri-stem, cs-method, status, request_bodyPOST na /_async/AsyncResponseService, `/wls-wsat/(CoordinatorPortTypeRegistrationService
Windows SecurityProcess Creation4688Rodzic java.exe uruchamia cmd.exe/powershell.exeKorelować z logami aplikacji.
SysmonProcess Create, Network, File Create1, 3, 11, (13)ParentImage=*\java.exe i dziecko cmd.exe/powershell.exe/wget/curl ; nowe JSP w katalogach aplikacji
Linux (auditd)SYSCALL=execveexe = /usr/bin/bash, /bin/sh z PPID java
WebLogicSerwerowe logi (access.log, AdminServer.log)SOAP Faults/500 na ww. endpointach, wyjątki deserializacji
AWS (ALB/WAF)CloudWatch/ALB access logsrequest_uriTe same ścieżki i metoda POST, wysoka liczba 400/500CloudTrail nie rejestruje ruchu HTTP do aplikacji — używaj ALB/WAF/Flow Logs.
K8s auditAPI Server audit logverb=create, resource=podsGdy WebLogic w K8s: nieoczekiwane pody/zmiany ConfigMap po RCE[Zależne od architektury]
M365[brak danych / nie dotyczy bezpośrednio]

Detekcja (praktyczne reguły)

Sigma — sonda na żądania do podatnych endpointów

title: Oracle WebLogic CVE-2019-2725 Probe
id: 9c5c0f93-1b76-4a8f-9b7c-fb4a2db1c2725
status: experimental
description: Detects HTTP POST to WebLogic async/WS-AT endpoints and XMLDecoder markers
logsource:
  category: webserver
  product: apache
detection:
  sel_uri:
    cs-method: POST
    cs-uri-stem|contains:
      - "/_async/AsyncResponseService"
      - "/wls-wsat/CoordinatorPortType"
      - "/wls-wsat/RegistrationService"
      - "/wls-wsat/ParticipantPortType"
  sel_body:
    request_body|contains:
      - "java.beans.XMLDecoder"
      - "<object class="
  condition: sel_uri or (sel_uri and sel_body)
fields:
  - src_ip
  - cs-host
  - cs-uri-stem
  - user_agent
falsepositives:
  - Legitymne WS-AT (rzadkie)
level: high
tags:
  - attack.T1190

(Ścieżki i kontekst ataku potwierdzone w opisach Tenable/Oracle).

Sigma — potomne powłoki z procesu Java

title: Java Spawns Shell (WebLogic RCE aftermath)
id: 0a0a7f5a-0e7a-4d1a-bb1e-2cfa7c2725ab
status: stable
logsource:
  product: windows
  category: process_creation
detection:
  parent:
    ParentImage|endswith: '\java.exe'
  child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: parent and child
fields:
  - CommandLine
  - ParentCommandLine
falsepositives:
  - Rzadkie skrypty administracyjne
level: high
tags:
  - attack.T1059
  - attack.T1190

Splunk (SPL)

Web/proxy:

index=web (sourcetype=access_combined OR sourcetype=iis)
method=POST uri_path IN ("/_async/AsyncResponseService",
"/wls-wsat/CoordinatorPortType","/wls-wsat/RegistrationService","/wls-wsat/ParticipantPortType")
| stats count by src, uri_path, status, useragent

Procesy Windows/Sysmon:

(index=wineventlog EventCode=4688 OR (index=sysmon EventCode=1))
ParentImage="*\\java.exe"
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\bash.exe")
| table _time host ParentImage Image CommandLine ParentCommandLine

KQL (Microsoft Defender XDR)

// Potomna powłoka po WebLogic (Windows)
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "java.exe"
| where FileName in~ ("cmd.exe","powershell.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

CloudWatch Logs Insights (ALB/WAF)

-- ALB access logs: podejrzane ścieżki WebLogic
fields @timestamp, elb, client_ip, request_uri, target_status_code, user_agent
| filter request_uri like /_async\\/AsyncResponseService|wls-wsat\\/(CoordinatorPortType|RegistrationService|ParticipantPortType)/
| sort @timestamp desc

Elastic / EQL

// Java -> shell
process where event.type == "start"
  and process.parent.name : "java*"
  and process.name in ("cmd.exe","powershell.exe","bash","sh","wget","curl")

Heurystyki / korelacje

  • Korelacja warstwowa: (1) POST do /_async/... lub /wls-wsat/... i (2) w ≤2 min pojawia się javacmd/powershell/bash i/lub (3) nowy plik .jsp w webroot.
  • Artefakty utrwalenia: webshell w katalogach tymczasowych/aplikacyjnych WebLogic (często podkatalogi _WL_internal lub bea_wls_internal).
  • Anomalie sieciowe: niespodziewane wyjścia z serwera aplikacyjnego do Internetu (pobranie ładunku/XMRig).
  • Ransomware chain: wektor T1190 → T1059 → T1105/T1505.003 → szyfrowanie (T1486), widoczne w kampaniach REvil.

False positives / tuning

  • Legalne implementacje WS‑AT/async SOAP (rzadkie) — filtruj po metodzie POST, wzorcach URI i treści body (XMLDecoder).
  • Skrypty administracyjne uruchamiające powłokę z Javy — whitelisting po ścieżkach i podpisach JAR/serwisu.
  • Testy skanerów VA — rozpoznawalne po user‑agentach i niskiej częstotliwości.

Playbook reagowania (IR)

  1. Identyfikacja: potwierdź trafienia z §7; wylistuj ostatnie POST na podatne ścieżki i błędy 500/SOAP Fault.
  2. Izolacja: odłącz host (lub usługę) od sieci produkcyjnej/Internetu.
  3. Triada forensyczna:
    • Zrzut procesów JVM, timeline plików aplikacji (szukaj nowych *.jsp), rejestry/konfiguracje usług.
    • Artefakty Sysmon (1/3/11) i 4688.
  4. Szukaj webshelli/JSP: w katalogach aplikacji i tymczasowych WebLogic (_WL_internal, bea_wls_internal).
  5. Zabij i usuń: wstrzymaj procesy podrzędne (cmd/powershell/bash), usuń webshell, wyczyść harmonogramy/usługi utworzone przez napastnika.
  6. Patch & harden: zastosuj poprawki Oracle i konfiguracje „secured production mode”, upewnij się że serwer nie jest bezpośrednio wystawiony do Internetu; wymuś WAF/IPS.
  7. Hunting wsteczny (30–90 dni): IOC‑driven search po ścieżkach/UA/źródłach IP; sprawdź transfery do domen hostingowych koparek/ransomware.
  8. Lessons learned: segmentacja i zasada „deny by default” dla ruchu do AdminServer.

Przykłady z kampanii / case studies

  • REvil/Sodinokibi (kwiecień–maj 2019): wykorzystanie nowo ujawnionej luki WebLogic jako wektora początkowego; Oracle opublikował patch 26.04.2019.
  • Muhstik botnet (kwiecień 2019): w ciągu dni od ujawnienia — masowe infekcje kryptokoparką i DDoS przez CVE‑2019‑2725.
  • Kryptokoparki (czerwiec 2019): Trend Micro: łańcuch z wykorzystaniem certyfikatów X.509 do zaciemniania, finalnie XMRig.
  • KEV/CISA: CVE pozostaje w katalogu znanych, wykorzystywanych podatności (KEV) — traktuj priorytetowo.

Lab (bezpieczne testy)

Uwaga: poniższe testy nie zawierają payloadów eksploatujących i służą wyłącznie do weryfikacji detekcji.

  1. Generowanie ruchu HTTP do podatnych ścieżek (bez RCE):
# symulacja sondowania endpointów (status 404/405/SOAP Fault)
curl -s -o /dev/null -w "%{http_code}\n" -X POST http://<weblogic>/wls-wsat/CoordinatorPortType
curl -s -o /dev/null -w "%{http_code}\n" -X POST http://<weblogic>/_async/AsyncResponseService
  1. Symulacja „Java → powłoka” (dla EDR/Sysmon):
# Linux: uruchom prosty program Java, który odpala /bin/sh -c 'echo test' (benign)
# Windows: analogicznie uruchom "java" jako rodzic prostego procesu cmd /c echo
# (wygeneruje zdarzenia: Sysmon 1, Windows 4688)
  1. ALB/WAF logi (CloudWatch): odpal curl jak wyżej przez publiczny endpoint testowy; uruchom zapytanie §7.5 i sprawdź, czy wykrywa ścieżki.

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK)

  • M1051 — Update Software: wdrażaj poprawki Oracle CPU i utrzymuj łańcuch zależności Javy/serwera aktualny.
  • M1031 — Network Intrusion Prevention: WAF/IPS z sygnaturami na CVE‑2019‑2725.
  • M1030 — Network Segmentation: izolacja serwerów aplikacyjnych i kanałów administracyjnych.

Powiązane techniki ATT&CK

T1190 — Exploit Public‑Facing Application

Wektor początkowy (Initial Access) — żądania POST do endpointów SOAP/WS‑AT WebLogic.

T1059.003 — Windows Command Shell

Uruchomienie cmd.exe przez java.exe po udanym RCE.

T1059.004 — Unix Shell

/bin/sh/bash inicjowane przez JVM na Linux/Unix.

T1505.003 — Web Shell

Umieszczenie JSP w webroot dla utrwalenia.

T1105 — Ingress Tool Transfer

Pobranie XMRig/ransomware po RCE. (odniesienia ogólne do techniki)


Źródła / dalsza literatura

  • Oracle Security Alert — CVE‑2019‑2725 (opis, ryzyko, wersje) (Oracle)
  • NVD — CVE‑2019‑2725 (CVSS, wersje dotknięte) (NVD)
  • Tenable (opisy endpointów i deserializacji) (Tenable®)
  • Cisco Talos — Sodinokibi via WebLogic (timeline) (Cisco Talos Blog)
  • Unit 42 — Muhstik wykorzystuje CVE‑2019‑2725 (kryptokoparka/DDoS) (Unit 42)
  • Trend Micro — cryptomining po CVE‑2019‑2725 (www.trendmicro.com)
  • CISA — KEV Catalog (występowanie CVE) (CISA)
  • MITRE ATT&CK — T1190/T1059/T1505.003 (definicje, wersja v18) (MITRE ATT&CK)
  • Oracle — zabezpieczanie środowiska (secured production mode) (Oracle Documentation)
  • ZDI — analiza webshelli i ścieżek _WL_internal/bea_wls_internal (kontekst utrwalenia) (Zero Day Initiative)

Checklisty dla SOC / CISO

SOC (operacyjne)

  • Alerting na POST do /_async/* i /wls-wsat/* + korelacja z java → shell.
  • WAF/IPS sygnatury aktywne dla CVE‑2019‑2725.
  • Hunting webshelli JSP w katalogach aplikacji/tymczasowych.
  • Blokada egress z serwerów aplikacyjnych do Internetu (allow‑list).
  • Telemetria Sysmon (1/3/11/13) i pełny 4688 na hostach WebLogic.

CISO (strategiczne)

  • Priorytety patchowania (M1051) — potwierdzony KEV.
  • Segmentacja (M1030) i oddzielne strefy dla AdminServer.
  • Wymóg WAF/IPS dla wszystkich usług publicznych (M1031).
  • Zakaz bezpośredniego wystawiania WebLogic do Internetu (proxy/WAF).
  • Regularne testy IR pod kątem webshelli i koparek.

Sankcje USA, Wielkiej Brytanii i Australii uderzają w rosyjne „bulletproof hosting” (Media Land, Hypercore/Aeza). Co to oznacza dla obrony przed ransomware?

Wprowadzenie do problemu / definicja luki

Rządy USA, Wielkiej Brytanii i Australii ogłosiły skoordynowane sankcje wobec dostawców tzw. bulletproof hostingu (BPH) – wyspecjalizowanej infrastruktury, która świadomie toleruje nadużycia, ignoruje zgłoszenia z organów ścigania i usuwa mechanizmy egzekwowania regulaminu, by zapewnić cyberprzestępcom „bezpieczną przystań” dla C2, serwerów płatności w kryptowalutach, dropów danych czy infrastruktur DDoS. Na celowniku znalazły się m.in. Media Land (Rosja) i Hypercore Ltd. (Wielka Brytania), powiązane z wcześniej sankcjonowaną Aeza Group.


W skrócie

  • Kogo objęto sankcjami (SDN/Krajowe listy):
    Media Land LLC, ML.Cloud LLC, Media Land Technology LLC, Data Center Kirishi LLC; osoby: Aleksandr A. Volosovik (alias „Yalishanda”), Kirill A. Zatolokin, Yulia V. Pankova. Dodatkowo: Hypercore Ltd. jako „front” Aeza Group, osoby: Maksim V. Makarov, Ilya V. Zakirov.
  • Powód: wspieranie ransomware (LockBit, BlackSuit, Play, Cl0p), DDoS i innej działalności cyberprzestępczej.
  • Zakres koordynacji: wspólne działania USA–UK–AU + poradnik techniczny Five Eyes (+Niderlandy) dot. ograniczania ryzyk BPH.
  • Co to zmienia: większe ryzyko deplatformingu, „przemeblowanie” infrastruktur przestępczych i przepięcia do kolejnych AS/hostingów w krajach trzecich (np. Serbia, Uzbekistan – spółki wspierające).

Kontekst / historia / powiązania

Hypercore Ltd. została wskazana jako fasada dla Aeza Group, wobec której wcześniej zastosowano środki ograniczające. Obecnie rządy wskazują dodatkowo łańcuch podmiotów pomocniczych (np. Smart Digital Ideas DOO w Serbii i Datavice MCHJ w Uzbekistanie), które miały służyć obchodzeniu sankcji. Australia równolegle nałożyła kary finansowe i zakazy wjazdu na kluczowe osoby oraz podmioty powiązane z Media Land.


Analiza techniczna / szczegóły luki

Jak BPH wzmacnia ataki:

  • Odporność na zgłoszenia (abuse/LEA): brak reakcji na notyfikacje, przeciąganie lub ignorowanie nakazów, szybka rotacja adresacji i AS.
  • Segmentacja i „whitelabel”: klienci dostają dedykowane podsieci, tunelowanie, anycast/GeoDNS, aby utrudnić atribucję i sekwencję blokad.
  • Infrastruktury „pod kampanię”: hosting paneli C2, serwerów kradzieży danych i portali płatności, z możliwością szybkiego „mirrorowania” i fast-flux.
  • Łańcuch pośredników: firmy-słupy, resellerzy i procesory płatności w jurysdykcjach o niższej współpracy prawnej.

Wspólna publikacja techniczna (CISA/FBI + partnerzy Five Eyes i Niderlandy) zalicza BPH do dostawców, którzy „świadomie i celowo” oferują infrastrukturę cyberprzestępcom; dokument podaje konkretne wzorce TTP i czeklisty dla operatorów.

Wskazane powiązania kampanii: w materiałach rządowych Media Land/Aeza mają historię obsługi LockBit, BlackSuit, Play (oraz w komunikatach AU także Cl0p) i kampanii DDoS wymierzonych w infrastrukturę krytyczną.


Praktyczne konsekwencje / ryzyko

  • Ryzyko „przeciążenia” list blokad: nowe sankcje spowodują przepięcia infrastruktur do innych AS/hostingów (w tym „czystych”), co może przejściowo obniżyć skuteczność statycznych blokad.
  • Efekt uboczny (collateral): błędnie zaklasyfikowane adresy współdzielone z legalnymi klientami mogą trafić na denylisty – potrzebna granularność i telemetria ruchu.
  • Ekspozycja łańcucha dostaw: jeżeli Twój MSP/ISP używa trasowania przez AS powiązane z BPH, możesz nadal widzieć beaconing lub fallback C2 mimo sankcji.
  • Zwiększona presja compliance: podmioty objęte sankcjami trafiają na listy SDN/UK sanctions, co implikuje obowiązki KYC/AML i weryfikacje kontrahentów (także dla dostawców chmurowych i rejestratorów).

Rekomendacje operacyjne / co zrobić teraz

W oparciu o wspólne wytyczne (CISA/FBI/partnerzy) i komunikaty rządowe:

  1. Dynamiczne filtrowanie: wdrażaj dynamiczne listy ASN / prefiksów / IP powiązanych z BPH; utrzymuj „curated lists” i automatyczne review. Zapewnij telemetrię i logowanie zdarzeń dla ruchu dopasowanego do list.
  2. Routing security: stosuj najlepsze praktyki BGP (RPKI/ROA), BCP-38/84 i monitoruj anomalia tras do „podejrzanych” AS. (Rekomendacja wynika z poradnika – „internet routing security best practices”.)
  3. Segmentacja i egress controls: ogranicz połączenia wychodzące do dozwolonych destynacji (FQDN/JA3/SNI), wymuś proxy/TLS inspection w strefach o podwyższonym ryzyku.
  4. TI & współdzielenie: zasilaj SIEM/SOAR i IDS/IPS z wielu źródeł TI, w tym publikacji CISA/FBI (IOC/TTP), oraz dziel się obserwacjami z branżą (ISAC/CSIRT).
  5. Playbook „deplatformingu”: przygotuj runbook na nagłe „przepięcia” C2 (nowe ASN, nowe VPS w 3. krajach), z huntami DNS/HTTP-TLS i regułami detekcji beaconing-like.
  6. KYC dostawców: przeprowadź due diligence wobec rejestratorów, resellerów i mniejszych dostawców chmurowych; unikaj podmiotów bez polityk abuse i Secure-by-Design.
  7. Mapowanie zależności: zaktualizuj asset inventory i mapy egress/ingress pod kątem zależności od AS powiązanych z BPH; uruchom alerty na zmiany tras/WHOIS.

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

W odróżnieniu od poprzednich, bardziej punktowych sankcji przeciw pojedynczym operatorom, obecne działania łączą designacje z natychmiastowo dostarczonym poradnikiem technicznym (mitigacje na poziomie ISP/defenderów). Dodatkowo rządy ujawniają łańcuchy obejścia sankcji (np. Hypercore ⇄ Aeza + spółki w Serbii/Uzbekistanie), co ułatwia proaktywne blokady na poziomie AS/firm-słupów.


Podsumowanie / kluczowe wnioski

  • BPH to krytyczne „zaplecze” ekosystemu ransomware – uderzenie w infrastrukturę dostawców utrudnia monetyzację i utrzymanie C2.
  • Skuteczna obrona wymaga dynamicznej, as-levelowej kontroli ruchu i koordynacji branżowej; same, statyczne denylisty nie wystarczą.
  • Organizacje powinny operacyjnie wdrożyć zalecenia z poradnika CISA/FBI/Five Eyes w ciągu najbliższych sprintów (network, SOC, compliance).

Źródła / bibliografia

  1. U.S. Treasury (OFAC): „United States, Australia, and United Kingdom Sanction Russian Cybercrime Infrastructure Supporting Ransomware” (19 listopada 2025). (U.S. Department of the Treasury)
  2. OFAC – Recent Actions / SDN Update (19 listopada 2025) – pełna lista osób/podmiotów (Media Land, ML.Cloud, MLT, DC Kirishi; Hypercore; Makarov, Zakirov; Pankova, Zatolokin; Volosovik). (OFAC)
  3. UK FCDO: „UK smashes Russian cybercrime networks…” (19 listopada 2025). (GOV.UK)
  4. Australian Federal Police: wspólny komunikat o sankcjach (20 listopada 2025). (afp.gov.au)
  5. CISA/FBI + partnerzy (Five Eyes + NL): „Bulletproof defense: Mitigating risks from bulletproof hosting providers” – komunikat i publikacja techniczna (19 listopada 2025). (CISA)

Nowa luka w SonicOS (CVE-2025-40601): błąd w SSLVPN pozwala zdalnie zawiesić zapory SonicWall

Wprowadzenie do problemu / definicja luki

SonicWall ostrzega przed świeżo ujawnioną podatnością CVE-2025-40601 w komponencie SSLVPN systemu SonicOS, która pozwala zdalnemu, nieuwierzytelnionemu napastnikowi na spowodowanie odmowy usługi (DoS) i crash narażonej zapory. Luka dotyczy urządzeń Gen7 oraz Gen8 (sprzętowych i wirtualnych). Według producenta, Gen6 oraz urządzenia SMA 100/1000 nie są podatne.

W skrócie

  • Identyfikator: CVE-2025-40601, CWE-121 (stack-based buffer overflow).
  • Wektor: zdalny, bez uwierzytelnienia, przez interfejs SSLVPN.
  • Skutek: DoS i zawieszenie firewalla (restart/przerwa w łączności).
  • Skala: Gen7/Gen8; brak dowodów aktywnego wykorzystywania w momencie publikacji.
  • Ocena: CVSS 3.1: 7.5 (High).
  • Naprawa: aktualizacja do wersji 7.3.1-7013+ (Gen7) oraz 8.0.3-8011+ (Gen8) lub nowszych; tymczasowo ogranicz dostęp do SSLVPN/wyłącz usługę.

Kontekst / historia / powiązania

Edge’owe usługi VPN SonicWall były w ostatnich latach intensywnie atakowane. W 2024–2025 operatorzy ransomware Akira wykorzystywali starszą, inną podatność w SSLVPN SonicOS (niewłaściwe kontrole dostępu) w kampaniach prowadzących do włamań — co podkreśla wagę terminowego patchingu i twardych konfiguracji portali zdalnych.

W kwietniu 2025 r. raportowano też odrębną lukę DoS w interfejsie Virtual Office SSLVPN (SNWLID-2025-0009). Dzisiejsza podatność CVE-2025-40601 nie jest tym samym błędem — ale skutek (zawieszenie urządzenia) jest podobny z punktu widzenia dostępności.

Analiza techniczna / szczegóły luki

  • Klasa błędu: Stack-based buffer overflow (CWE-121) w usłudze SSLVPN.
  • Warunki ataku: zdalne, bez interakcji użytkownika, bez uwierzytelnienia — wystarczy ekspozycja usługi SSLVPN do internetu lub sieci dostępnej dla atakującego.
  • Wpływ: pełna utrata dostępności (A:H), brak wpływu na poufność/integralność wg metryki producenta (C:N/I:N).
  • Metryka bezpieczeństwa: CVSS 3.1: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
  • Status zagrożenia: na 20 listopada 2025 r. brak potwierdzonych exploitów w dziczy i brak publicznego PoC.

Wersje dotknięte / naprawcze:

  • Dotknięte: SonicOS 7.3.0-7012 i starsze (linia Gen7) oraz 8.0.2-8011 i starsze (linia Gen8).
  • Naprawa: Gen7 → 7.3.1-7013+, Gen8 → 8.0.3-8011+ (oraz nowsze wydania wymienione przez producenta).

Praktyczne konsekwencje / ryzyko

  • Przestój usług: zawieszenie zapory = utrata łączności VPN/site-to-site, przerwy w pracy oddziałów, niedostępność aplikacji.
  • Możliwość powtarzania ataku: brak wymogu autoryzacji sprzyja prostym, zautomatyzowanym skanom i powtarzalnym crashom, aż do skutku.
  • Łańcuchowanie: DoS na brzegu może odwrócić uwagę zespołów i ułatwić równoległe działania napastnika (np. DDoS + włamanie inną ścieżką).
  • Ryzyko reputacyjne i SLA: szczególnie dotkliwe dla MSP i środowisk wielooddziałowych.

Te ryzyka są tym większe, im szerzej SSLVPN jest wystawione do internetu bez ograniczeń źródłowych.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowy patch do wersji 7.3.1-7013+ (Gen7) / 8.0.3-8011+ (Gen8) lub nowszych. Zweryfikuj sukces aktualizacji na wszystkich węzłach/NSv.
  2. Tymczasowe zabezpieczenia, jeśli patch musi poczekać:
    • Wyłącz SSLVPN na brzegu lub ogranicz dostęp (ACL, allow-list) do zaufanych adresów/VPN hubów.
    • Zastosuj geofencing i rate-limiting na WAF/edge’u przed portalem.
  3. Hardening konfiguracji (nawet po aktualizacji):
    • Ogranicz/ukryj Virtual Office/portal do sieci zarządzającej lub ZTNA; unikaj pełnej ekspozycji.
    • Wymuś MFA dla administracji oraz użytkowników zdalnych; rotuj hasła i sekrety (LDAP/RADIUS/SNMP).
    • Włącz alerting na crash/reboot i nietypowe wzorce ruchu do SSLVPN; monitoruj logi pod kątem anomalii.
  4. Segmentacja i plan awaryjny: oddziel ruch użytkowników od ruchu krytycznych systemów; utrzymuj zapory zapasowe / HA z testem przełączenia.
  5. Weryfikacja ekspozycji: skanuj AS-y organizacji pod kątem otwartych portali SSLVPN; rozważ dostęp wyłącznie przez bastion/ZTNA.

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

  • CVE-2025-40601 (ten artykuł): błąd overflow w SSLVPN → DoS/crash, bez uwierzytelnienia, CVSS 7.5. Brak potwierdzonej eksploatacji w momencie publikacji.
  • Kampanie Akira (2024–2025): wykorzystywano wcześniejsze luki logiczne/dostępowe w SSLVPN SonicOS, prowadzące do nieautoryzowanego dostępu i pełnych kompromitacji — inny typ błędu i skutek niż DoS w CVE-2025-40601. Wniosek: nawet jeśli nowa luka „tylko” crashuje, proxy-ataki na VPN pozostają wektorem wysokiego ryzyka.
  • SNWLID-2025-0009 (IV/2025): wcześniejsza DoS w Virtual Office SSLVPN; technicznie inna implementacja, lecz podobny efekt (zawieszenie). Pokazuje powtarzalność problemów dostępnościowych w okolicach SSLVPN i sens ograniczania ekspozycji.

Podsumowanie / kluczowe wnioski

  • Aktualizuj teraz do wersji naprawczych na wszystkich Gen7/Gen8.
  • Jeśli nie możesz — wyłącz/ogranicz SSLVPN do zaufanych źródeł i wzmacniaj ochronę perymetru.
  • Traktuj portale zdalnego dostępu jak krytyczną powierzchnię ataku: patch, MFA, ograniczenia sieciowe i monitoring to „must-have”.
  • Dzisiejsza luka to DoS, ale historia ataków na SSLVPN SonicOS (np. Akira) pokazuje, że opieszałość w patchowaniu kończy się kompromitacją.

Źródła / bibliografia

  • BleepingComputer — „New SonicWall SonicOS flaw allows hackers to crash firewalls” (20 listopada 2025). (Bleeping Computer)
  • OpenCVE — rekord CVE-2025-40601 (opis, CVSS, CWE, daty, referencja do PSIRT). (OpenCVE)
  • CISecurity — doradztwo nt. wcześniejszych ataków na SSLVPN SonicOS (kontekst Akira). (CIS)
  • TechRadar Pro — o eksploatacji starszych luk SSLVPN SonicWall przez Akira (kontekst). (TechRadar)
  • Tenable Plugin — wzmianka o SNWLID-2025-0009 (DoS w Virtual Office) z kwietnia 2025 r. (porównanie). (Tenable®)

Amazon: Iran łączy cyberszpiegostwo z atakami kinetycznymi. Nowa kategoria zagrożeń – „cyber-enabled kinetic targeting”

Wprowadzenie do problemu / definicja luki

Amazon Threat Intelligence opisał trend, który nazywa „cyber-enabled kinetic targeting” – sytuacje, w których operacje cybernetyczne (rozpoznanie, przejęcia infrastruktury, dostęp do strumieni wideo) bezpośrednio umożliwiają lub ulepszają fizyczne uderzenia (np. ostrzał rakietowy). W dwóch studiach przypadków Amazon łączy działania grup przypisywanych Iranowi z późniejszymi atakami kinetycznymi na cele morskie i miejskie. Firma argumentuje, że granica między cyber a fizycznym polem walki zaciera się i wymaga zmiany modeli zagrożeń po stronie obrońców.

W skrócie

  • Imperial Kitten (IRGC/Tortoiseshell/TA456): od 2021 r. kompromitacja systemów AIS i CCTV na statkach; w styczniu 2024 aktor wyszukiwał dane AIS konkretnej jednostki, która 1 lutego 2024 r. została ostrzelana przez Huti na Morzu Czerwonym (strzał nieskuteczny). Korelacja czasowa wskazuje na wykorzystanie cyber-rozpoznania do planowania uderzenia.
  • MuddyWater (MOIS/Rana): w maju 2025 przygotowano infrastrukturę CNO; 17 czerwca 2025 r. użyto jej do dostępu do przejętego serwera z na żywo strumieniami CCTV z Jerozolimy; 23 czerwca 2025 r. Iran przeprowadził zmasowany atak rakietowy, a władze izraelskie ostrzegały przed wykorzystaniem zhakowanych kamer do korekty ognia w locie.
  • Amazon publikuje przykładowe IOC (adresy IP) i nawołuje do rozszerzenia modelowania zagrożeń o scenariusze, w których pozornie „nieistotne” systemy (np. kamery, AIS) służą jako sensory dla uderzeń fizycznych.

Kontekst / historia / powiązania

W 2025 r. amerykańskie agencje (CISA, FBI, NSA, DC3) ostrzegły, że aktorzy związani z Iranem regularnie atakują słabo zabezpieczone sieci i urządzenia IoT/OT, a firmy z łańcuchami powiązań z izraelską obronnością są w podwyższonym ryzyku. Podkreślono nadużywanie domyślnych haseł, podatności „KEV” oraz wzrost defacementów i DDoS. Ten obraz wpisuje się w przypadki opisane przez Amazon – cyberoperacje nie kończą się na kradzieży danych, lecz zasilają cele taktyczne.

Relacje branżowe (SecurityWeek, CyberScoop, CSO) potwierdzają szczegóły osi czasu i atrybucje do Imperial Kitten i MuddyWater, a także nacisk Amazona na zmianę paradygmatu obrony.

Analiza techniczna / szczegóły luki

Łańcuch ataku (przykładowy):

  1. Przygotowanie infrastruktury – aktorzy zestawiają serwery C2/VPN i warstwę anonimizacji (infrastruktura „actor-controlled”).
  2. Dostęp do systemów „sensorowych” – przejęcie systemów AIS, serwerów z CCTV (często z domyślnymi hasłami lub słabymi konfiguracjami). Celem nie musi być sabotaż, lecz pozyskanie strumienia danych w czasie rzeczywistym.
  3. Fuzja danych i korekcja ognia – wykorzystanie wideo/GNSS/AIS do śledzenia obiektu i prowadzenia ognia z korektą (ang. in-flight retargeting), co Amazon nazywa „cyber-enabled kinetic targeting”.
  4. IOC i ślady – Amazon publikuje m.in. 18[.]219.14.54 (MuddyWater C2) oraz kilka IP proxy Imperial Kitten (85[.]239.63.179; 37[.]120.233.84; 95[.]179.207.105) – użyteczność: korelacja logów, blokady czasowe, hunting.

Różnica względem „cyber-kinetic operations”: tu cyber nie niszczy sprzętu bezpośrednio (jak w Stuxnecie), lecz podnosi precyzję uderzeń kinetycznych dzięki rozpoznaniu i telemetrii.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wtórne dla podmiotów cywilnych: kamery biurowe, portowe, miejskie i przemysłowe mogą stać się „czujnikami” przeciwnika, nawet jeśli organizacja nie jest bezpośrednim celem wojskowym.
  • Sektor morski i logistyczny: kompromitacja AIS/CCTV na statkach ułatwia namierzanie jednostek. Łańcuch dostaw staje się podatny na ataki punktowe.
  • Eskalacja międzydomenowa: incydenty cyber mogą generować skutki fizyczne, podnosząc wymagania dla zarządzania ryzykiem, zgodności i ubezpieczeń. (Wnioski na podstawie raportów branżowych i zaleceń rządowych).

Rekomendacje operacyjne / co zrobić teraz

Higiena i segmentacja systemów „sensorowych” (CCTV, NVR, AIS, VMS):

  • Odseparuj je sieciowo (VLAN/VRF), zablokuj dostęp z Internetu, egzekwuj MFA do wszystkich zdalnych paneli (RDP/VNC/SSH/WebUI).
  • Wymuś zmianę domyślnych haseł, RBAC i zasady deny-by-default dla dostępu zdalnego.
  • Szybko łatataj systemy wystawione (sprawdź wpisy z katalogu CISA KEV).

Monitoring i threat hunting:

  • Przeskanuj logi pod kątem IOC z publikacji Amazona oraz własnych wskaźników nietypowego dostępu do strumieni RTSP/HTTP z kamer. (np. IP: 18[.]219.14.54; 85[.]239.63.179; 37[.]120.233.84; 95[.]179.207.105).
  • Ustaw detekcje na anomalie ruchu wideo (długie sesje, zewnętrzne ASN/VPN), z osobnym priorytetem w okresach napięć geopolitycznych. (Wnioski z AWS i IC3/CISA).

Modelowanie zagrożeń i procedury:

  • Włącz do threat modeling scenariusz: „nasze kamery/sensory jako cel rozpoznawczy dla obcego ataku fizycznego” – oraz konsekwencje odłączenia kamer w trybie alarmowym (playbook).
  • Ćwicz table-top z udziałem zespołów bezpieczeństwa fizycznego (GSOC) i SOC: decyzja o czasowym wyłączeniu publikowanych strumieni i mechanizmy degradacji usług (fail-secure). (Wnioski na podstawie rekomendacji Amazona).
  • Zintensyfikuj wymianę TI z partnerami/przemysłem – Amazon wskazuje na wagę korelacji międzydomenowej.

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

  • Cyber-enabled kinetic targeting vs. cyber-kinetic operations: w pierwszym przypadku cyber to sensor i wsparcie celowania; w drugim – cyber sam powoduje skutek fizyczny (sabotuje/niszczy).
  • OT/ICS: CISA i partnerzy zwracają uwagę, że aktorzy irańscy chętnie atakują urządzenia OT (PLCs/HMIs) przez domyślne hasła i wystawione interfejsy – to inna ścieżka do skutków fizycznych (np. zakłócanie pracy infrastruktury).

Podsumowanie / kluczowe wnioski

  • Amazon dostarczył mocne, czasowo skorelowane przykłady łączenia cyber-rozpoznania z uderzeniami fizycznymi i zaproponował precyzyjny termin dla tego zjawiska.
  • Dla obrońców to sygnał, by traktować CCTV/AIS/IoT jako cele o wysokiej wartości wywiadowczej, nawet poza klasycznym obszarem OT.
  • Najważniejsze działania: segmentacja, uszczelnienie zdalnego dostępu, wymuszenie MFA i haseł, hunting po IOC, procedury odłączania kamer, ćwiczenia GSOC+SOC.

Źródła / bibliografia

  1. AWS Security Blog: New Amazon Threat Intelligence findings: Nation-state actors bridging cyber and kinetic warfare (19 XI 2025). (Amazon Web Services, Inc.)
  2. SecurityWeek: Amazon Details Iran’s Cyber-Enabled Kinetic Attacks… (19 XI 2025). (SecurityWeek)
  3. CyberScoop: Amazon warns of global rise in specialized cyber-enabled kinetic targeting (19 XI 2025). (CyberScoop)
  4. CSO Online: Iranian APT hacks helped direct missile strikes in Israel and the Red Sea (19 XI 2025). (csoonline.com)
  5. IC3/CISA/NSA/DC3 (TLP:CLEAR): Iranian Cyber Actors May Target Vulnerable US Networks and Entities of Interest (30 VI 2025). (ic3.gov)

Dziesiątki tysięcy routerów ASUS przejętych w kampanii „WrtHug”. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Nowo ujawniona kampania Operation WrtHug kompromituje dziesiątki tysięcy domowych i SOHO routerów ASUS WRT, przede wszystkim urządzenia EoL (poza wsparciem). Badacze ze STRIKE (SecurityScorecard) szacują, że ponad 50 tys. unikatowych adresów IP należących do zainfekowanych routerów było widocznych w ciągu ostatnich 6 miesięcy. Wspólnym wskaźnikiem infekcji jest identyczny, samopodpisany certyfikat TLS na usłudze AiCloud z nietypowym 100-letnim terminem ważności od kwietnia 2022 r.. Kampania łączy się taktykami i zasięgiem z operacjami klasy ORB (Operational Relay Box), które służą do skrytego pośredniczenia w ruchu na potrzeby cyber-szpiegostwa.

W skrócie

  • Skala: ≥50 000 zainfekowanych routerów ASUS, głównie w Tajwanie i Azji Płd-Wsch., ale również w USA, Rosji i Europie.
  • Wektor: łańcuch n-day na AiCloud + zestaw błędów OS command injection i auth bypass w starszych firmware’ach ASUS WRT.
  • IoC: wspólny self-signed cert (AiCloud) z ważnością 100 lat.
  • Powiązania: zbieżność TTP z wcześniejszą kampanią AyySSHush na routery ASUS (GREYNOISE).
  • Kluczowe CVE: CVE-2023-41345/6/7/8, CVE-2023-39780, CVE-2024-12912, CVE-2025-2492 (AiCloud).

Kontekst / historia / powiązania

W maju 2025 r. GreyNoise opisał cichą kampanię AyySSHush: trwałe tylne wejście w tysiącach routerów ASUS, z wykorzystaniem CVE-2023-39780, modyfikacji konfiguracji SSH oraz przechowywania artefaktów w NVRAM (przetrwanie restartów i aktualizacji). WrtHug dzieli część TTP (wykorzystanie tych samych rodzin błędów i celów), ale STRIKE notuje zaledwie 7 hostów z nakładającą się infekcją, więc traktuje WrtHug jako oddzielną kampanię – potencjalnie tego samego lub skoordynowanych aktorów.

Analiza techniczna / szczegóły luki

Łańcuch ataku w WrtHug opiera się na publicznie znanych (n-day) błędach w ASUS WRT oraz podatnościach AiCloud:

  • OS command injection:
    • CVE-2023-41345 / 41346 / 41347 / 41348 – rodzina błędów powiązana z mechanizmami tokenowymi oraz „apply” w panelu, w praktyce skorelowana z CVE-2023-39780 (RT-AX55; wstrzyknięcie komend po uwierzytelnieniu).
  • AiCloud (arbitrary command / auth bypass):
    • CVE-2024-12912 – błąd w AiCloud pozwalający na wykonanie poleceń (CVSS 7.2, NVD).
    • CVE-2025-2492improper authentication control w AiCloud (CVSS 9.2); możliwe wywołanie funkcji bez autoryzacji przygotowanym żądaniem.

Artefakt/kondensator IoC: na zainfekowanych urządzeniach usługa AiCloud prezentuje ten sam certyfikat TLS, samopodpisany, z okresem ważności 100 lat (od 04.2022). To najprostszy punkt zaczepienia dla huntów i detekcji.

Modele na celowniku: raporty wymieniają m.in. 4G-AC55U/860U, DSL-AC68U, GT-AC5300, GT-AX11000, RT-AC1200HP/1300G+/1300UHP i inne starsze/EoL wersje. (Lista może nie być kompletna; kluczowe jest sprawdzenie statusu wsparcia danego modelu).

Praktyczne konsekwencje / ryzyko

  • Skryte proxy/relay (ORB): urządzenia stają się węzłami ukrywającymi ruch na potrzeby eksfiltracji i rozpoznania – mniejsze ryzyko DDoS, większy nacisk na szpiegostwo i pivoting.
  • Trwałość: atak często przetrwa aktualizacje firmware’u (konfiguracja w NVRAM, zmiany SSH), więc „patch ≠ remediacja”.
  • Ekspozycja MŚP i domów: domowe/SoHo routery bywają pomijane w procesach hardeningu, a AiCloud bywa wystawiony do Internetu bez MFA i segmentacji.

Rekomendacje operacyjne / co zrobić teraz

  1. Szybki hunting IoC
    • Sprawdź, czy AiCloud prezentuje nietypowy, samopodpisany cert z datą ważności do 2122 r.. Jeśli tak – traktuj jako wysoki wskaźnik kompromitacji.
  2. Weryfikacja AiCloud i dostępu zdalnego
    • Jeżeli urządzenie jest EoL lub brak łatki – wyłącz AiCloud i każdy zdalny dostęp z Internetu (HTTP/HTTPS, SSH, WAN admin).
  3. Remediacja trwałości
    • Jeżeli podejrzewasz kompromitację: pełny factory reset, następnie ręczna, czysta konfiguracja (nie przywracaj kopii!), sprawdź authorized_keys, porty SSH (GREYNOISE raportował niestandardowy TCP/53282), usuń obce klucze.
  4. Aktualizacje firmware’u
    • Zastosuj najnowsze firmware’y naprawiające m.in. CVE-2025-2492 (AiCloud) oraz luki z 2023 r. W przypadku EoL – wymiana urządzenia.
  5. Hardening
    • Zmień hasła admina, włącz MFA (jeśli wspierane), ogranicz panel do LAN/VPN, wyłącz UPnP, stosuj ACL/geo-IP na brzegu, segmentuj sieć (IoT/Wi-Fi gości oddzielnie). (Dobre praktyki na bazie ogólnych zaleceń i obserwacji z raportów).
  6. Monitoring i bloki
    • Blokuj znane IP/porty z raportów (np. 53282/TCP dla SSH), loguj odwołania do AiCloud, ustaw alerty na zmiany certyfikatów i włączenie SSH.

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

  • WrtHug vs. AyySSHush: oba celują w ASUS WRT i łączą CVE-2023-39780, ale WrtHug ma wyraźny IoC TLS (100-letni cert) na AiCloud i inną dystrybucję geograficzną; AyySSHush akcentował trwałość przez NVRAM/SSH. Mało hostów z podwójną infekcją → różne klastry/etapy jednego lub skoordynowanych aktorów.
  • Botnet vs. ORB: klasyczne botnety = hałaśliwe DDoS/kripto-koparki; ORB = ciche szlaki ruchu dla operacji APT (maskowanie źródła, pivot). WrtHug ma profil ORB-like.

Podsumowanie / kluczowe wnioski

  • Słabe ogniwo #1: EoL routery z włączonym AiCloud i zdalnym dostępem.
  • Najprostsza detekcja: sprawdzenie certyfikatu TLS AiCloud (100 lat).
  • Remediacja ≠ patch: przy podejrzeniu infekcji reset do fabrycznych + ręczna rekonfiguracja, dopiero potem aktualizacja; dla EoL – wymiana.
  • Zagrożenie strategiczne: rosnący trend ORB na urządzeniach brzegowych – cichsze, długotrwałe kampanie.

Źródła / bibliografia

  1. SecurityScorecard STRIKE – Operation WrtHug, The Global Espionage Campaign Hiding in Your Home Router (19.11.2025). (SecurityScorecard)
  2. The Register – Tens of thousands more ASUS routers pwned by suspected, evolving China operation (19.11.2025). (The Register)
  3. GreyNoise – Stealthy Backdoor Campaign Affecting Thousands of ASUS Routers (28.05.2025). (greynoise.io)
  4. NVD – CVE-2023-39780 (ASUS RT-AX55 OS command injection). (nvd.nist.gov)
  5. NVD – CVE-2025-2492 (ASUS AiCloud improper authentication control). (nvd.nist.gov)

ShadowRay 2.0: nowa fala ataków zmienia klastry Ray w koparki kryptowalut

Wprowadzenie do problemu / definicja luki

Trwa globalna kampania „ShadowRay 2.0”, w której napastnicy przejmują publicznie dostępne klastry Ray (open-source framework do skalowania aplikacji AI/Python) i zamieniają je w samopropagującą się infrastrukturę do kopania Monero. Wektor wejścia to nadal sporna, niewyłatania podatność CVE-2023-48022 w API zadań Ray, umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia przy błędnej ekspozycji usług na Internet. Najnowsza fala kampanii rozszerza się poza cryptojacking – obserwowane są kradzieże danych/poświadczeń i funkcje DDoS.

W skrócie

  • Nowa kampania („ShadowRay 2.0”): ta sama luka, bardziej automatyczny łańcuch ataku; self-spread między węzłami/klastrami.
  • Ekspozycja ekosystemu: badacze szacują dziś >230 tys. serwerów Ray widocznych w Internecie (wcześniej „kilka tysięcy”).
  • CVE-2023-48022: zdalne RCE przez Jobs API; ocena CVSS 9.8 (CRITICAL), status „disputed” – twórcy Ray wskazują, że Ray ma działać w „ściśle kontrolowanym środowisku”.
  • Ładunki: generowane z pomocą LLM (charakterystyczne komentarze/docstringi), moduł XMRig ograniczający użycie CPU do ~60%, utrwalanie przez cron/systemd, reverse-shelle i moduł DDoS (Sockstress).
  • Brak łatki: zalecenia to „best practices” Anyscale – uruchomienie w zaufowanej sieci, filtrowanie portu 8265 (Dashboard), autoryzacja przez proxy, monitoring anomalii.

Kontekst / historia / powiązania

Pierwszą kampanię ShadowRay opisano w marcu 2024 r., wskazując aktywne nadużycia od września 2023 r. Wtedy już raportowano setki skompromitowanych klastrów oraz dominujące użycie koparek (XMRig/NBMiner/Zephyr) i reverse-shelli. Jednocześnie Anyscale podtrzymało, że brak wbudowanego uwierzytelniania to decyzja projektowa, a instancje powinny działać w środowiskach kontrolowanych; firma zapowiadała dodanie auth w przyszłych wersjach.

Analiza techniczna / szczegóły luki

CVE-2023-48022 dotyczy Jobs API w Ray i umożliwia zdalne przesłanie/uruchomienie zadań (Bash/Python) bez uwierzytelnienia, jeśli endpointy są wystawione na świat. NVD klasyfikuje lukę jako krytyczną (CVSS 9.8). Brak łatki wynika z modelu zaufania Ray – framework zakłada izolację sieciową i kontrolę dostępu po stronie operatora. W praktyce tysiące wdrożeń są błędnie wystawione (np. 0.0.0.0) lub pozbawione filtracji, co czyni je łatwym celem.

W ShadowRay 2.0 napastnicy (TRACK: IronErn440) korzystają z CVE-2023-48022 do uruchamiania wielostopniowych łańcuchów Bash/Python. Payloady, z oznakami generowania przez LLM, po zainfekowaniu rozsiewają się na wszystkie węzły klastra poprzez natywne mechanizmy orkiestracji Ray, a nawet klaster-do-klastra. Zaobserwowano dwie fale: starszą z dystrybucją przez GitLab (zakończona 5 listopada) i nową przez GitHub (aktywna od 17 listopada).

Moduły złośliwe obejmują:

  • Cryptojacker (XMRig) – wykrywa CPU/GPU, maskuje procesy (np. dns-filter), limity CPU (ok. 60%), zabija konkurencyjne koparki, blokuje pule w /etc/hosts i iptables, utrzymuje persistencję przez cron/systemd.
  • Dostęp interaktywny – wiele reverse-shelli do infrastruktury C2, z możliwością eksfiltracji danych środowisk ML (sekrety, hasła DB, klucze SSH, tokeny usług).
  • DDoS – komponent oparty o Sockstress do wyczerpywania zasobów TCP.

Praktyczne konsekwencje / ryzyko

  • Utrata mocy obliczeniowej (GPU/CPU) i wzrost kosztów chmurowych przez kopanie kryptowalut.
  • Wycieki sekretów produkcyjnych: hasła DB, klucze SSH, tokeny (OpenAI, HuggingFace, Slack, Stripe), dostęp do kube-API – ryzyko lateral movement i kompromitacji danych klientów.
  • Degradacja dostępności: możliwość użycia zasobów do DDoS oraz wpływ na trening/inferencję modeli.

Rekomendacje operacyjne / co zrobić teraz

  1. Nie wystawiaj Ray na Internet: uruchamiaj wyłącznie w zaufowanej, odseparowanej sieci/VPC/VPN; blokuj ruch przychodzący do komponentów Ray (w tym Dashboard :8265) regułami firewall/SG.
  2. Warstwa autoryzacji przed Dashboard/Jobs API: jeżeli dostęp zdalny jest konieczny, zastosuj reverse proxy z uwierzytelnianiem (mTLS/OIDC) i autoryzacją endpointów. Nie wiąż usług na 0.0.0.0.
  3. Higiena sekretów: rotuj poświadczenia (DB/SSH/API), unieważnij tokeny znalezione w logach/środowiskach i wymuś krótkie TTL. (Wnioski z incydentów ShadowRay.)
  4. Monitoring runtime: alertuj na tworzenie nietypowych zadań, reverse-shelle, połączenia do puli Monero, procesy podobne do xmrig, modyfikacje crontab/systemd. (IOC-e i TTP-y opisane przez Oligo.)
  5. Segmentacja i egress control: ogranicz ruch wychodzący z węzłów Ray do niezbędnych destynacji; blokuj znane pule, domeny pastebin/Git* używane w kampanii.
  6. Plan odzyskania: w razie kompromitacji – odseparuj klaster, zbuduj nowy z zaufanych artefaktów, przeprowadź triage sekretów i przegląd dostępu do chmury.
  7. Śledź komunikaty producenta: Anyscale wcześniej sygnalizowało przyszłe wsparcie auth – wdrażaj gdy dostępne; do tego czasu polegaj na izolacji sieci i kontrolach dostępu.

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

W porównaniu z typowymi kampaniami cryptojacking w klastrach kontenerowych, ShadowRay wyróżnia:

  • Wykorzystanie Jobs API Ray jako „legalnego” mechanizmu wykonania kodu (przy błędnej ekspozycji), co utrudnia detekcję przez skanery SAST/kompilacyjne.
  • Szybkie rozprzestrzenianie w obrębie klastra dzięki wbudowanej orkiestracji Ray oraz automatyczne „cluster-to-cluster spreading” w fali 2.0.
  • Ładunki generowane przez LLM (charakterystyczne artefakty w kodzie), co wskazuje na rosnącą automatyzację po stronie atakujących.

Podsumowanie / kluczowe wnioski

  • ShadowRay 2.0 pokazuje, że błędna ekspozycja usług AI to dziś jeden z najbardziej kosztownych błędów operacyjnych.
  • Brak wbudowanego auth w Ray nie jest „bugiem” w rozumieniu vendor-a, ale ryzyko operacyjne – które trzeba neutralizować segmentacją, filtracją i proxy z autoryzacją.
  • Zespoły ML/AI powinny mieć runbook na wypadek kompromitacji klastrów treningowych/inferencyjnych oraz telemetrykę ukierunkowaną na IOC/TTP ShadowRay.

Źródła / bibliografia

  1. BleepingComputer – „New ShadowRay attacks convert Ray clusters into crypto miners” (18 listopada 2025). (BleepingComputer)
  2. Oligo Security – „ShadowRay: First Known Attack Campaign Targeting AI Workloads…” (26 marca 2024). (oligo.security)
  3. NVD (NIST) – wpis CVE-2023-48022 (RCE w Ray Jobs API, CVSS 9.8, status „disputed”). (NVD)
  4. SecurityWeek – „Ray AI Framework Vulnerability Exploited to Hack Hundreds of Clusters” (27 marca 2024). (SecurityWeek)
  5. The Hacker News – „Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining” (27 marca 2024). (The Hacker News)

Awarie Cloudflare 18 listopada 2025 r.: co poszło nie tak, jak się bronić i czego się nauczyć

Wprowadzenie do problemu / definicja luki

18 listopada 2025 r., około 11:20 UTC (12:20 czasu polskiego), sieć Cloudflare zaczęła masowo zwracać błędy HTTP 5xx, co przełożyło się na niedostępność wielu serwisów na całym świecie (w tym X, ChatGPT, Uber, Spotify, Canva). Cloudflare potwierdził, że incydent nie był atakiem — źródłem problemu okazał się błąd operacyjno-konfiguracyjny skutkujący powstaniem nadmiernie dużego pliku cech („feature file”) używanego przez moduł Bot Management. Plik przekroczył limit obsługiwany przez oprogramowanie proxy, co spowodowało jego awarię i kaskadowe błędy w ruchu klientów. Główna przyczyna została usunięta, a ruch przywrócono ok. 14:30 UTC, pełna stabilizacja nastąpiła o 17:06 UTC.

W skrócie

  • Kiedy: start degradacji 11:20 UTC, główne przywrócenie 14:30 UTC, koniec 17:06 UTC (18 listopada 2025).
  • Co zawiodło: generowanie pliku „feature” dla Bot Management (duplikaty cech po zmianie uprawnień w ClickHouse), co przekroczyło limit liczby cech w module i wywołało błąd krytyczny w proxy (FL/FL2).
  • Skala: globalna; zauważalny wpływ na popularne usługi internetowe (m.in. X, ChatGPT).
  • Co to nie było: nie DDoS/atak, lecz wewnętrzna zmiana konfiguracji + błąd obsługi limitu.

Kontekst / historia / powiązania

Cloudflare określił zdarzenie jako najpoważniejszą awarię od 2019 r. — wcześniejsze incydenty dotyczyły zwykle panelu czy nowszych funkcji, nie zaś ogólnego przepływu ruchu. Incydent wpisuje się w serię ostatnich dużych awarii w ekosystemie chmury (AWS, Azure), co potwierdza rosnącą współzależność usług infrastrukturalnych.

Analiza techniczna / szczegóły luki

Łańcuch zdarzeń (high-level):

  1. O 11:05 UTC wdrożono zmianę uprawnień w klastrze ClickHouse, która sprawiła, że zapytanie generujące plik cech („feature file”) zaczęło zwracać duplikaty kolumn (z powodu ujawnienia metadanych z dodatkowej bazy r0).
  2. Wygenerowany co 5 minut plik z nadmiarowymi cechami był propagowany globalnie.
  3. Moduł Bot Management posiada limit liczby cech (ok. 200) oraz prealokację pamięci — przekroczenie limitu spowodowało panic/unwrap error w implementacji FL2 (Rust) i błędy HTTP 5xx.
  4. W starszym silniku FL nie widać było 5xx, ale bot score = 0, co mogło generować fałszywe pozytywy w regułach antybotowych.
  5. Dodatkowo wystąpiły wtórne skutki: Workers KV, Access, Turnstile oraz Dashboard notowały problemy logowania i wzrost opóźnień; część z nich złagodzono dzięki bypassowi KV ok. 13:04 UTC.

Dlaczego diagnoza była trudna?

  • System czasowo „sam się podnosił”, ponieważ jedne nody generowały „dobre”, a inne „złe” pliki — fluktuacja co ~5 min utrudniała identyfikację winowajcy.
  • Zbieg okoliczności: niedostępność status page (hostowanej poza infrastrukturą Cloudflare) wprowadziła podejrzenie skoordynowanego ataku.

Ostateczna naprawa: zatrzymanie generacji i dystrybucji wadliwego pliku, wstawienie „last-known-good”, restart proxy i stopniowe restartowanie zależnych usług.

Praktyczne konsekwencje / ryzyko

  • Ryzyko biznesowe: utrata przychodów, spadek konwersji, wizerunkowe koszty „internet stanął”. Dla spółek publicznych — wpływ na komunikację (przykład: zakłócone wydarzenia IR).
  • Ryzyko bezpieczeństwa: reguły oparte na bot score mogły w starszym FL reagować nieprawidłowo (score=0 → blokady/obejścia). Potencjalny degradujący wpływ na detekcję spamu w Email Security (chwilowy brak źródła reputacji IP).
  • Łańcuch dostaw (third-party risk): pojedyncza zmiana u dostawcy edge/CDN wpływa na dziesiątki krytycznych usług — konieczne plany obejścia i redundancja dostawców.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SRE/Architektów:

  1. Redundancja na warstwie CDN/edge: projektuj polityki active-active lub graceful degradation (np. fallback DNS → origin / alternatywny CDN) dla kluczowych ścieżek (auth, płatności, API).
  2. Feature-flag kill switch: lokalne przełączniki wyłączające zależne moduły (np. scoring botów) bez restartu całego proxy/aplikacji. Cloudflare zapowiedział poszerzenie globalnych „kill switches” — odzwierciedl to po stronie klienta.
  3. Walidacja „wewnętrznych” artefaktów konfiguracyjnych jak danych użytkownika: schemy, limity rozmiaru/rekordów, detekcja duplikatów, testy kontraktowe (CI/CD) dla plików konfig generowanych automatycznie.
  4. Observability budżetowane: zabezpiecz systemy debugowania przed „zajadaniem CPU” przy masowych błędach (rate-limit na trace/log/error-reports).
  5. Runbooki fail-open/fail-closed: jasno zdefiniuj tryby awaryjne dla modułów bezpieczeństwa (antybot/WAF) i konsekwencje biznesowe obu trybów.

Dla SecOps:

  1. Polityki antybotowe oparte na wielu sygnałach, nie tylko globalnym „bot score”.
  2. Monitorowanie skutków ubocznych (np. gwałtowny wzrost odrzuceń/akceptacji sesji) i gotowe reguły tymczasowe na czas degradacji dostawcy.
  3. Komunikacja kryzysowa: zespół IR/PR + strona statusowa off-platform (poza dostawcą, z wieloma regionami i DNS-em niezależnym). Przykład problemów z dostępem do statuspage to lekcja o separacji zależności.

Dla devów aplikacyjnych:

  • Circuit breakers & timeouts na wywołaniach do usług edge.
  • Backpressure i retry-policy z jitterem (zapobiega lawinie po powrocie ruchu).
  • Tryb „read-only / degraded UI” zamiast pełnego 5xx dla krytycznych ścieżek.

Różnice / porównania z innymi przypadkami

  • W przeciwieństwie do typowych outage’y spowodowanych DDoS lub błędami sieciowymi, tu mieliśmy błąd w danych konfiguracyjnych + granice (limits) w module proxy, co ujawniło brak „twardych” walidacji dla artefaktów wewnętrznie generowanych (nie tylko dostarczanych przez klientów).
  • Od strony objawów incydent przypominał masowe ataki L7 (skok 5xx i fluktuacje), co utrudniło triage. Jednak root cause nie był security-atakiem, lecz regresją po zmianie uprawnień w ClickHouse.

Podsumowanie / kluczowe wnioski

  • „Trust but verify” dla własnych artefaktów konfiguracyjnych: walidacja, limity, schemy, canary rollout i globalne kill-switche.
  • Projektuj na awarie dostawcy edge: niezależna strona statusowa, multi-CDN, szybkie ścieżki bypass.
  • Observability z ograniczeniami: mechanizmy, które pomagają w diagnozie, nie mogą „zjadać” zasobów podczas katastrofy.
  • Ćwicz tryby degradacji: fail-open/fail-closed dla komponentów bezpieczeństwa i jasne runbooki.

Źródła / bibliografia

  • Szczegółowy post-mortem Cloudflare z osi czasu, technikaliami (ClickHouse, limit cech, FL/FL2): Cloudflare Blog — “Cloudflare outage on November 18, 2025”. (The Cloudflare Blog)
  • Relacja i wpływ na największe serwisy: Financial Times, Washington Post, The Verge, Reuters. (Financial Times)
  • Historia i status incydentów Cloudflare: Cloudflare Status / Incident History. (cloudflarestatus.com)