Archiwa: Linux - Strona 33 z 42

Intel łata ponad 60 podatności (listopad 2025). Co to oznacza dla Twoich stacji roboczych i serwerów?

Wprowadzenie do problemu / definicja luki

W listopadowym „chipmaker Patch Tuesday” Intel opublikował 30 nowych biuletynów bezpieczeństwa opisujących ponad 60 podatności w szerokim wachlarzu produktów – od procesorów Xeon/Core i narzędzi deweloperskich po sterowniki grafiki, NPU oraz QuickAssist (QAT). Równolegle własne aktualizacje doręczyli AMD i NVIDIA, obejmując m.in. sterowniki XRT (AMD) oraz frameworki AI (NVIDIA NeMo, Megatron, AIStore, Triton). To wydanie łącznie adresuje błędy prowadzące do eskalacji uprawnień, ujawnienia informacji i DoS, a w przypadku części komponentów AI – także potencjalnego wykonania kodu.

W skrócie

Intel: 30 advisory, >60 CVE; wysokie ryzyka m.in. w Xeon/Slim Bootloader/PROSet/CIP/Graphics/QAT; liczne średnio-/niskopoważne błędy w narzędziach użytkowych i SDK.
AMD: 14 CVE w 6 advisory; wysoka powaga m.in. w XRT; StoreMi z EoL – producent nie dostarczy łatek (należy odinstalować).
NVIDIA: 6 CVE w 4 advisory dot. NeMo, Megatron, AIStore, Triton – część z nich umożliwia wykonanie kodu / EoP / ujawnienie danych.

Kontekst / historia / powiązania

Intel publikuje zbiory biuletynów cyklicznie (zwykle kwartalnie) w ramach Intel Product Security Center. Listopadowy zrzut (11 listopada 2025 r.) zawiera serię advisory INTEL-SA-0130x…0136x widocznych na stronie PSIRT, w tym np. INTEL-SA-01328 (CIP). Równolegle pojawiły się aktualizacje mikrokodu CPU dla Linuksa.

Analiza techniczna / szczegóły luki

Najczęściej dotknięte komponenty (Intel):

Procesory Xeon / Slim Bootloader / PROSet / CIP / Graphics / QAT – w części z nich błędy prowadzą do EoP i DoS (wysoka waga). Przykładowo INTEL-SA-01328 (CIP) klasyfikuje wpływ jako EoP/Info Disclosure (severity: HIGH).
Narzędzia i biblioteki (Server Configuration Utility, Display Virtualization, NPU drivers, SigTest, VTune, ITT API, oneAPI MKL, QAT userspace, Gaudi, MPI, PresentMon, Driver & Support Assistant, Rapid Storage Technology) – przeważnie średnie/niskie ryzyko (EoP/DoS/Info Disclosure).

AMD:

Advisory obejmują XRT (Xilinx Run Time), μProf, wybrane Epyc oraz status StoreMi – technologia jest poza wsparciem, brak łatek (zalecane usunięcie).

NVIDIA (AI stack):

NeMo i Megatron (frameworki LLM), AIStore (składowanie aplikacji AI) i Triton Inference Server – biuletyny z listopada 2025 r. naprawiają podatności pozwalające m.in. na wykonanie kodu, EoP i wyciek danych. Przykładowy biuletyn AIStore (listopad 2025): aktualizacja komponentu AuthN.

Praktyczne konsekwencje / ryzyko

Stacje robocze DaaS/VDI i deweloperskie (grafika Intel, narzędzia oneAPI/VTune/ITT, Driver & Support Assistant) – ryzyko lokalnej eskalacji uprawnień oraz ujawnienia informacji przez developer tools.
Serwery bare-metal i wirtualizacja (Xeon, QAT, Slim Bootloader) – potencjalna EoP/DoS może ułatwić pivot z VM do hosta lub zakłócić akceleratory kryptograficzne/kompresyjne (QAT).
Klastry AI/ML (NVIDIA NeMo/Megatron/Triton/AIStore) – błędy w pipeline’ach inferencyjnych/treningowych mogą skutkować RCE w węzłach GPU, sabotażem modeli czy kradzieżą artefaktów.
Dziedzictwo: instalacje z AMD StoreMi – niezabezpieczalne; pozostawienie oprogramowania zwiększa powierzchnię ataku.

Rekomendacje operacyjne / co zrobić teraz

1) Inwentaryzacja i priorytetyzacja

Zbuduj listę hostów z komponentami: Intel Graphics/PROSet/CIP/QAT/VTune/ITT/oneAPI/DSA/RST, Xeon/Core; u AMD – XRT, μProf, StoreMi; u NVIDII – NeMo/Megatron/AIStore/Triton. (Źródła producentów w sekcji na końcu).

Windows (PowerShell – szybkie sprawdzenie wybranych komponentów Intel):

# sterowniki Intel Graphics + wersja
Get-PnpDevice -Class Display | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion

# Intel Driver & Support Assistant
Get-ItemProperty "HKLM:\SOFTWARE\Intel\Intel(R) Driver & Support Assistant" | Select-Object Version

# Intel PROSet (NIC)
Get-ItemProperty "HKLM:\SOFTWARE\Intel\NetworkServices\PROSet" -ErrorAction SilentlyContinue

# RST (Rapid Storage Technology)
(Get-Item "HKLM:\SOFTWARE\Intel\IAStor*","HKLM:\SOFTWARE\WOW6432Node\Intel\IAStor*").Property

Linux (mikrokod CPU i QAT):

# wersja mikrokodu
dmesg | grep -i microcode
grep microcode /proc/cpuinfo | uniq

# pakiet mikrokodu (Debian/Ubuntu)
apt policy intel-microcode

# sterowniki QAT (przykład)
lsmod | grep -i qat
modinfo qat_4xxx | egrep 'version|vermagic'

2) Aktualizacje / łagodzenia

Intel: zastosuj pakiety z advisory z 11.11.2025 – szczególnie dla CIP (INTEL-SA-01328), Graphics, QAT, PROSet, VTune i komponentów firmware (Slim Bootloader). Sprawdź także dostępność mikrokodu CPU (Linux).
AMD: zaktualizuj XRT do wydania 2025.1+; odinstaluj StoreMi (EoL, brak łatek).
NVIDIA: zaktualizuj NeMo, Megatron, AIStore (AuthN), Triton do wersji wskazanych w biuletynach z listopada 2025 r.

3) Twardnienie i detekcja

W SIEM dodaj korelacje na nieoczekiwane ładowanie sterowników/narzędzi deweloperskich (np. vtune, ittapi, presentmon), eskalację integratorów sterowników (Intel DSA), a w klastrach AI – na nieautoryzowane aktualizacje modelu / pluginów Triton.
W EDR utwardź zasady driver loading i app control dla narzędzi z rodziny oneAPI, QAT i NPU.

4) Testy regresji

W środowiskach z QAT i akceleracją AI wprowadź krótkie testy wydajnościowe po aktualizacji; błędy DoS potrafią maskować się jako „spadki throughputu”.

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

W przeciwieństwie do wielu poprzednich wydań, tym razem ciężar komunikatów NVIDII dotyczy frameworków AI, nie tylko sterowników GPU – to ważne dla zespołów MLOps/AI Platform.
W ekosystemie AMD rzadkim, lecz istotnym przypadkiem jest brak łatek dla StoreMi z racji EoL – konieczna decyzja remove/replace zamiast „patch & continue”.
Intel utrzymuje szeroki zakres – od firmware (Slim Bootloader) po narzędzia deweloperskie – co wymaga zarówno aktualizacji OS/drivers, jak i firmware/BIOS/mikrokodu.

Podsumowanie / kluczowe wnioski

To wydanie jest „szerokospektralne”: dotyka endpointów użytkowników, hostów serwerowych i klastrów AI.
Priorytetyzuj: Intel CIP/Graphics/QAT/PROSet, AMD XRT, usunięcie StoreMi, NVIDIA NeMo/Megatron/AIStore/Triton.
Zadbaj o mikrokod CPU (Linux) i pipeline’y CI/CD dla komponentów AI – błędy w narzędziach deweloperskich i frameworkach to dziś realna ścieżka ataku.

Źródła / bibliografia

SecurityWeek – przekrojowe omówienie tegorocznego „Chipmaker Patch Tuesday” (Intel/AMD/NVIDIA), 12.11.2025. (SecurityWeek)
Intel Product Security Center – lista advisory z 11.11.2025 (m.in. INTEL-SA-01356…01364). (Intel)
Intel INTEL-SA-01328 (Computing Improvement Program – CIP), 11.11.2025. (Intel)
AMD – biuletyn StoreMi (EoL, brak planu łatek). (AMD)
NVIDIA – biuletyn AIStore (AuthN), listopad 2025. (NVIDIA Support)

Brytyjski „Cyber Security and Resilience Bill” – co zmieni w praktyce bezpieczeństwo IT (NIS 2.0 po brytyjsku)

Wprowadzenie do problemu / definicja luki

Rząd Zjednoczonego Królestwa przedstawił w Parlamencie ustawę Cyber Security and Resilience (Network and Information Systems) Bill. Jej celem jest gruntowna aktualizacja ram NIS 2018, tak aby objąć więcej podmiotów krytycznych, uszczelnić łańcuchy dostaw, ujednolicić raportowanie incydentów i dać państwu narzędzia reagowania na zagrożenia o charakterze narodowego bezpieczeństwa. Ustawa jest ukierunkowana na sektory energii, transportu, zdrowia, wody oraz infrastrukturę danych (data centers) i managed service providers (MSP).

W skrócie

Zakres: do NIS dołączą data centers (jako „data infrastructure”), MSP (średnie i duże) oraz „large load controllers” w energetyce.
Raportowanie: wstępne zgłoszenie w 24h od wykrycia istotnego/potencjalnie istotnego incydentu + pełny raport w 72h; jednoczesne informowanie NCSC oraz – dla DC/MSP/dostawców cyfrowych – klientów mogących być dotkniętymi.
Dostawcy krytyczni (critical suppliers): regulator będzie mógł ich wyznaczać i obejmować reżimem NIS, domykając luki w łańcuchach dostaw (np. diagnostyka w NHS, chemikalia dla spółek wodociągowych).
Egzekwowanie i koszty: nowoczesne, obrotowe kary za poważne naruszenia i szersze odzyskiwanie kosztów przez regulatorów; badania rządowe szacują koszt cyberataków na ~£14,7 mld/rok (0,5% PKB).
Uprawnienia państwa: sekretarz stanu zyska możliwość wydawania kierunkowych priorytetów dla regulatorów i wiążących dyrektyw wobec podmiotów, gdy zagrożone jest bezpieczeństwo narodowe.

Kontekst / historia / powiązania

NIS 2018 podniósł poprzeczkę, ale nie obejmował szeregu podmiotów kluczowych dla ciągłości działania państwa (MSP, część DC, krytyczni poddostawcy). Po serii incydentów (m.in. w zdrowiu publicznym i przemyśle) rząd zapowiedział reformę – opartą także o CAF (Cyber Assessment Framework) i przeglądy NIS z lat 2020 i 2022. Projekt z 12 listopada 2025 r. jest kulminacją prac i towarzyszą mu faktyczne materiały: ustawa, noty wyjaśniające, ocena skutków, factsheety i badania ekonomiczne.

Analiza techniczna / szczegóły ustawy

1) Nowe kategorie w NIS

Data centres: formalnie klasyfikowane jako „essential services” w podsektorze data infrastructure. Progi oparte o „rated IT load”:
– DC nie-enterprise: ≥1 MW;
– DC enterprise (na potrzeby własne): ≥10 MW.
Definicja zawiera m.in. wspierającą infrastrukturę (zasilanie, HVAC, bezpieczeństwo fizyczne, odporność).
Managed Service Providers (MSP): nowe obowiązki i dedykowane przepisy (Part 4A) – zarządzanie ryzykiem, obowiązki raportowe, oraz jasna definicja, czym jest i nie jest „managed service” (np. samo dostarczenie sprzętu lub pewnych form chmury nie zawsze kwalifikuje się jako MSP).
„Large load controllers” (energetyka/Smart Grid): wejdą w zakres, by ograniczyć ryzyka destabilizacji sieci przez atak na systemy zarządzania obciążeniem.
„Critical suppliers”: możliwość wyznaczania niektórych dostawców jako krytycznych i objęcia ich reżimem adekwatnym do ryzyka.

2) Raportowanie incydentów

Definicja incydentu rozszerzona o zdarzenia „mogące mieć znaczący wpływ” (nie tylko już zakłócające usługę).
Model 24/72h: pierwsze zgłoszenie w 24 h, pełny raport w 72 h; dla data center wymóg jest jawnie zapisany (nowy § dot. „data centre incidents”).
Logika ekonomiczna (z oceny skutków): model dwustopniowy zmniejsza koszt i pozwala skupić zasoby na ograniczaniu skutków w pierwszej dobie.

3) Wzmocnienie egzekwowania i rola państwa

Sankcje i egzekucja: ustawa przewiduje nowoczesny reżim kar i notyfikacji naruszeń (sekcje 48–51), a rząd zapowiada „tougher turnover-based penalties” dla najpoważniejszych naruszeń.
Uprawnienia Sekretarza Stanu (Part 3 i 4): priorytety strategiczne dla regulatorów, kodeks praktyk, dyrektywy do podmiotów regulowanych i organów w sytuacjach zagrożenia bezpieczeństwa narodowego.

4) Koszty i skala problemu

Nowe badania rządowe: cyberataki kosztują ~£14,7 mld rocznie (~0,5% PKB); średni koszt „znaczącego” ataku >£190 tys.; projekt wskazuje też na wzrost poważnych incydentów w statystykach NCSC.

Praktyczne konsekwencje / ryzyko

SOC/IR: trzeba dostosować progi zgłoszeń (nie tylko „service disruption”), wdrożyć timer 24/72h, zsynchronizować kanały do regulatora i NCSC oraz – dla DC/MSP – kanał klientowski (notification to customers).
MSP: konieczność udokumentowania zarządzania ryzykiem (Part 4A), asset & access management multi-tenant, segmentacja klientów, powiadamianie klientów o incydentach wpływających potencjalnie/znacząco.
Data centers: compliance by design dla obiektów ≥1 MW (lub ≥10 MW enterprise), testy odporności (HVAC, zasilanie, systemy fizyczne), procedury „blackstart”, oraz gotowe szablony raportów i playbooki awaryjne.
Operatorzy infrastruktury krytycznej i dostawcy krytyczni: konieczność przeglądu łańcucha dostaw (kto może być wyznaczony jako critical supplier) i włączenia ich do programu audytów i ćwiczeń.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań gotowych do wdrożenia (przykłady „z życia” dla zespołów bezpieczeństwa i operacji):

1) Zmiana progów i procedur IR (24/72h + „potentially significant”)

Polityka (fragment):

Trigger-NIS: Każdy incydent, który mógłby znacząco wpłynąć na (C/I/A) systemów istotnych dla świadczenia usługi, uruchamia ścieżkę NIS.
T+0: natychmiastowe utrwalenie dowodów, izolacja, triage.
T+4h: decyzja o klasyfikacji NIS (potencjalnie/znacząco istotny).
T+24h: wstępne zgłoszenie do regulatora + NCSC, a dla DC/MSP także notyfikacja klientów dotkniętych/„likely impacted”.
T+72h: raport pełny (IOC, kill chain, skutki, działania naprawcze, lessons learned).
Kanał stały: dedykowana skrzynka/endpoint, 24/7 on-call.

Szablon „Initial Notification (24h)” (skrót):

- Organisation: <nazwa>
- Service in scope: <OES/R(D)SP/Data Centre/MSP>
- Incident time: <UTC ISO>
- Impact (potential/significant) on C/I/A: <krótko>
- Affected systems: <zakres>
- Customer impact likely? <Yes/No> (DC/MSP: jeśli "Yes", status powiadomień)
- Immediate actions taken: <izolacja, EDR, blokady>
- Point of contact (24/7): <telefon/e-mail>

2) Mapowanie do CAF / kontrolki techniczne

Checklist (minimum):

Identity & Access: PAM dla kont uprzywilejowanych, JIT/JEA, segmentacja tenants (MSP/DC).
EDR + telemetry na węzłach krytycznych; sysmon/auditd na serwerach w strefach istotnych.
Network: microsegmentation (np. z wykorzystaniem policy-based routing), east-west IDS (Suricata/Zeek), NetFlow/SVT.
Backups: 3-2-1, w tym immutable (WORM, S3 Object Lock), testy odtwarzania pod scenariusz „wrogie środowisko”.
Vulnerability & Patch: wskaźnik MTTP dla poprawek w strefach NIS, SBoM + monitorowanie known exploited vulns.
OT/ICS: monitoring PLC/RTU (integrity checks), mapa sieci L2/L3, jump-hosts, polityka „no internet from OT”.

Przykładowe komendy i automatyzacje:

Linux (zbieranie artefaktów w 24h):

# szybkie paczkowanie triage (logi + artefakty) z serwera krytycznego
sudo tar -czf /tmp/triage_$(hostname)_$(date -u +%FT%TZ).tgz \
  /var/log /etc /var/tmp /tmp \
  /root/.bash_history /home/*/.bash_history \
  --exclude='*.gz' --warning=no-file-changed

Windows (PowerShell – stan poprawek krytycznych):

Get-WindowsUpdate -KBArticleID KB* -IsInstalled |
  Select-Object KB, Title, InstalledOn |
  Sort-Object InstalledOn -Descending

SIEM (KQL – ślady exfiltracji do nietypowego ASN):

DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionSuccess"
| summarize dcount(RemoteIP) by RemoteASN, DeviceName
| where RemoteASN in ("AS9009","AS208091") // przykładowe AS-y high-risk

MISP (curl – publikacja IoC do współdzielonego ekosystemu):

curl -X POST https://misp.example/api/events \
  -H "Authorization: $MISP_KEY" -H "Content-Type: application/json" \
  -d @ioc_event.json

3) Specyfika MSP

Contracting: odśwież umowy i runbooki komunikacji z klientami (wymogi powiadamiania, zakres telemetrii, SLO dla IR).
Tenancy isolation: ensure-by-design – osobne jump-hosty, MFA per-tenant, least privilege dla RMM/PSA, rejestry dostępu awaryjnego (break glass).
Attack surface: regularnie testuj RMM (np. podpisy binariów, allowlist na EDR), WAF dla paneli, MFA+FIDO2.

4) Data centers

Rated IT load – upewnij się, że obiekt wpada/nie wpada w próg 1 MW / 10 MW; przygotuj dowody kontroli dla regulatora (HVAC, zasilanie, fizyczne).
Playbook „facility+IT”: wspólne ćwiczenia DC/IT/SOC (scenariusze: utrata zasilania, HVAC, atak na BMS/EPMS).
Customer notification: gotowy pipeline do powiadomień (listy dystrybucyjne, integracja z CRM/RMM, szablony).

Różnice / porównania z innymi przypadkami

UK NIS 2018 → Cyber Security & Resilience Bill (2025): z „reakcji na zakłócenia” do proaktywnego raportowania także zdarzeń potencjalnie istotnych, objęcie MSP i data centers, narzędzia kierunkowego sterowania przez rząd.
UE NIS2 (2024/2025) vs UK Bill: cele podobne (łańcuch dostaw, MSP, raportowanie wczesne), ale brytyjski projekt wprost definiuje progi DC (MW) i daje silne dyrektywy Sekretarzowi Stanu w trybie bezpieczeństwa narodowego. (Wniosek autorski na bazie projektu i factsheetów.)
DORA/PSTI: komplementarne reżimy sektorowe (finanse/IoT konsumenckie). Nowy Bill skupia się na usługach krytycznych i cyfrowych w rozumieniu NIS.

Podsumowanie / kluczowe wnioski

24/72h + „potentially significant” to największa zmiana operacyjna – przygotuj proces, szablony i integracje już teraz.
MSP i DC wchodzą do gry – ureguluj powiadamianie klientów, segmentację, dowody kontroli i CAF-mapping.
Spodziewaj się bardziej stanowczych działań regulatorów (koszty odzyskiwane od podmiotów, kary obrotowe za rażące naruszenia).
Ekonomicznie – skala szkód ~£14,7 mld/rok uzasadnia inwestycje w odporność i wcześniejsze zgłaszanie.

Źródła / bibliografia

Tekst projektu ustawy: Cyber Security and Resilience (Network and Information Systems) Bill – Bill 329 (Part 2 – DC/MSP; Part 3–4 – uprawnienia, egzekucja). (Parliament Publications)
Ocena skutków (Impact Assessment) – model 24/72h, koszty, uzasadnienie ekonomiczne. (GOV.UK)
Factsheet – Summary of the Bill (DSIT) – filary reform, zakres, implementacja. (GOV.UK)
Komunikat rządowy (DSIT) – główne tezy, cytaty, kierunek egzekwowania, rola NCSC. (GOV.UK)
Analiza prasowa (The Record) – kontekst, harmonogram, uzasadnienie zmian, koszty wdrożenia w skali gospodarki. (The Record from Recorded Future)

„Whisper Leak” — atak kanałem bocznym na LLM, który ujawnia temat rozmowy mimo TLS

Wprowadzenie do problemu / definicja luki

„Whisper Leak” to zaprezentowany przez badaczy Microsoftu atak kanałem bocznym na modele językowe udostępniane zdalnie (API/WWW), który nie łamie TLS ani nie odczytuje treści — zamiast tego wykorzystuje wzorce metadanych ruchu (rozmiary pakietów i odstępy czasowe w trybie streamingu), aby klasyfikować temat rozmowy użytkownika. Atak ma znaczenie praktyczne dla scenariuszy z podsłuchem na poziomie ISP, niezaufanego Wi-Fi lub obserwatora w tej samej sieci.

SecurityWeek podkreśla, że napastnik, który tylko przechwyci szyfrowany ruch, może z wysoką skutecznością ustalić, czy rozmowa dotyczy „wrażliwego” tematu (np. legalności prania pieniędzy, polityki, protestów, zdrowia).

W skrócie

Zakres: dotyczy LLM w trybie streamingu (tokeny/porcje zwracane na bieżąco).
Technika: analiza sekwencji {rozmiar TLS → czas między pakietami} do klasyfikacji tematu pierwszego promptu.
Skuteczność: w testach na 28 popularnych LLM uzyskano zwykle >98% AUPRC; przy realnym niezrównoważeniu 10 000:1 możliwa była precyzja 100% przy 5–50% recall dla modelu-celu.
Mitigacje: padding losowy, batchowanie tokenów, wtrysk „szumu”/syntetycznych pakietów; część dostawców wdrożyła już obrony (np. dodatkowe pole losowego tekstu w streamie w Azure/OpenAI, parametr „p” w Mistral).
Ryzyko: ujawnienie kontekstu/tematu, nie treści; wystarcza pasywny podsłuch. Brak dowodów użycia w naturze, ale ryzyko praktyczne oceniono jako realne.

Kontekst / historia / powiązania

„Whisper Leak” wpisuje się w nową falę ataków side-channel na LLM. W 2024 r. pokazano m.in.:

wyciek długości tokenów i częściową rekonstrukcję odpowiedzi ze strumieni TLS,
zdalne ataki timingowe wynikające z optymalizacji inferencji (np. speculative decoding),
korelację liczby tokenów wyjściowych z cechami wejścia,
wycieki przez cache sharing (prefix/semantic caching).

Autorzy odnoszą się do tych prac i przesuwają akcent z rekonstrukcji treści na klasyfikację tematu.

Analiza techniczna / szczegóły luki

Model zagrożeń

Adwersarz pasywny z widocznością ruchu sieciowego (ISP, wspólne Wi-Fi, lokalny admin, przejęty router).
Brak dostępu do kluczy, brak aktywnej ingerencji — podgląd samych metadanych.

Wektor i cecha charakterystyczna

LLM w streamingu wysyła wynik porcjami; wewnętrzna dynamika generowania (autoregresja, batching, UX-owe „flushowanie”) przekłada się na sekencję rozmiarów pakietów i interwałów.
TLS (AES-GCM/ChaCha20) zachowuje relację długości: ciphertext ≈ plaintext + stała, więc rozmiar pakietu zdradza „długość tokenu/porcji”. Połączenie size + timing buduje fingerprint tematu.

Metodologia badaczy

Zebrano ślady dla 28 usług LLM; zdefiniowano cel binarny: „pytania o legalność prania pieniędzy” vs. szum (11 716 losowych pytań z Quora).
Trzy klasyfikatory: LightGBM, Bi-LSTM, BERT-based na sekwencjach (size/time bucketed).
Miara: AUPRC (ze względu na silne niezrównoważenie zbioru).

Wyniki (wybrane)

>98% AUPRC dla wielu modeli/prowadzących.
W symulacji 10 000:1 (1 rozmowa wrażliwa na 10 000 zwykłych) uzyskano przypadki 100% precision przy 5–50% recall — czyli zero false positives przy „wyłapywaniu” części rozmów o temacie-celu.

Status vendorów i mitigacje

OpenAI, Microsoft (Azure), Mistral, xAI: wdrożone obrony (m.in. losowy „obfuscation field” do streamu; parametr „p” w Mistral).
Część innych dostawców według The Register nie wdrożyła poprawek lub była nie-responsywna (m.in. wskazywani: Anthropic, AWS, DeepSeek, Google; uwaga: AWS zakwestionował skuteczność ataku w swojej architekturze).

Praktyczne konsekwencje / ryzyko

Prywatność użytkowników i compliance: wykrywanie tematów rozmów może samo w sobie stanowić dane wrażliwe (polityka, zdrowie, poglądy).
Ryzyko profilowania i selekcji: przy precyzji 100% atak nadaje się do filtrowania ruchu pod kątem „zainteresowań” (np. AML, protesty).
Bezpieczeństwo korporacyjne: sygnały „intencji” (np. rozmowy o produktach, planach, incydentach) mogą ujawnić strategie lub incydenty nawet bez wycieku treści. CSO Online ostrzega wprost przed ryzykiem dla przedsiębiorstw.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników końcowych

Unikaj rozmów na wysoce wrażliwe tematy na niezaufanych sieciach; jeśli musisz — wyłącz streaming (gdy dostawca na to pozwala).
VPN dodaje warstwę tunelowania i utrudnia korelację ruchu per usługa, choć nie eliminuje samego side-channelu po stronie dostawcy.
Preferuj dostawców, którzy wdrożyli mitigacje (padding/obfuscation, batching).

Dla SOC/Blue Team / architektów

Polityka proxy/DLP: jeżeli organizacja korzysta z LLM-ów chmurowych, wymuś nie-streaming dla wrażliwych przepływów (np. przez nagłówki/parametry API).
Segmentacja i bramki egress: kieruj ruch LLM przez pojedynczy egress (NAT/Proxy) i uśredniaj przepływy, by utrudnić fingerprinting per użytkownik.
Traffic shaping (u Ciebie): rozważ grupowanie i bursty dla ruchu wychodzącego do hostów LLM (koszt: latency).

Przykładowe szkice (Linux, dla ruchu do API LLM — przykład edukacyjny):

# 1) Oznacz ruch do domen LLM (tu: fikcyjne *.api.llm.example)
ipset create llm dsthash
ipset add llm 203.0.113.10
ipset add llm 203.0.113.11

# 2) Przekieruj do kolejki HTB o docelowym kształtowaniu "burst + coalesce"
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20mbit ceil 100mbit
tc qdisc add dev eth0 parent 1:30 handle 30: fq maxrate 20mbit flow_limit 1000 # uśrednianie/koalescencja

# 3) (Opcj.) Dodaj minimalny jitter (uwaga na SLA)
tc qdisc replace dev eth0 parent 1:30 netem delay 15ms 5ms distribution normal

Uwaga: to nie uniemożliwia ataku (napastnik przy ISP nadal widzi wzorce), ale zmniejsza rozróżnialność na wyjściu organizacji kosztem opóźnień.

Monitoring anomalii TLS: buduj profile czasowo-rozmiarowe własnych połączeń z dostawcą; wykrywaj nietypowe „sondowanie” (wiele krótkich zapytań o podobnych strukturach, typowe dla zbierania datasetu treningowego napastnika).

Przykład prostego zbierania cech (packet size / IAT) do SIEM:

# Zeek: ekstrakcja metadanych TLS → TSV/JSON do SIEM
zeek -i eth0 tls
# W logach ssl.log / conn.log masz ts, id.resp_h, resp_p, orig_bytes, resp_bytes, resp_pkts, duration
# Inter-arrival time można przybliżyć z ts + duration + liczby pakietów; dokładniej użyj pcap + tshark:
tshark -r capture.pcap -Y "tls && ip.dst==203.0.113.10" \
  -T fields -e frame.time_epoch -e frame.len -e tcp.stream

Dla dostawców / twórców integracji

Padding/obfuscation: dodaj losowy „wypełniacz” (serwerowy) do porcji streamu; Microsoft i OpenAI wdrożyli pole z losową sekwencją tekstu. Mistral wprowadził parametr p do API o podobnym efekcie.
Batchowanie tokenów: wysyłaj grupy tokenów zamiast pojedynczych; zmniejsza liczbę obserwowalnych zdarzeń (trade-off: płynność UX).
Wtrysk pakietów syntetycznych: wstrzykuj pakiety o losowych rozmiarach/odstępach, by zniszczyć korelację size/IAT.
Tryb non-streaming jako opcja „high-privacy”.
Audyt side-channel: udostępnij profil ruchu i parametry obrony w dokumentacji (transparency).

Różnice / porównania z innymi przypadkami

Atak side-channel na LLM	Co wycieka	Na czym bazuje	Status/uwagi
Whisper Leak	Temat rozmowy (klasyfikacja)	Rozmiary pakietów + timing w streamingu	Skuteczny między dostawcami; częściowe mitigacje wdrożone.
Token-length leak (Weiss 2024)	Sekwencja długości tokenów → rekonstrukcja fragmentów	Rozmiary pakietów	Dotyczy stricte streamingu token-by-token.
Remote timing (Carlini/Nasr 2024)	Cechy promptu przez timing optymalizacji	Różnice czasu generacji	Zależny od mechanizmów typu speculative decoding.
Output-token count (Zhang 2024)	Atrybuty wejścia (np. język)	Łączny czas/liczba tokenów	Nie wymaga pełnego streamu.
Cache-sharing timing (Zheng 2024)	Semantyka przez trafienia cache	Opóźnienia przy współdzieleniu	Wymaga współdzielenia zasobów.

Podsumowanie / kluczowe wnioski

TLS chroni treść, nie metadane. W dobie LLM-ów metadane w streamingu wystarczą, by z dużą pewnością odgadnąć temat rozmowy.
Ryzyko jest praktyczne: wysokie AUPRC i scenariusz 10 000:1 z precyzją 100% (częściowo) pokazują użyteczność dla cenzury/surveillance.
Mitigacje istnieją, ale to trade-off między prywatnością a latencją/kosztem. Część ekosystemu już wdrożyła obrony, część — nie.
Działaj warstwowo: polityka (non-streaming dla wrażliwych tematów), shaping, wybór dostawców z paddingiem, monitoring i edukacja użytkowników.

Checklist dla CISO/SOC (do wydrukowania):

Zidentyfikowane przypadki użycia LLM z danymi wrażliwymi.
Wymuszony tryb non-streaming dla tych przepływów (jeśli dostępny).
Ocena dostawców pod kątem paddingu/parametrów obrony (Azure/OpenAI/Mistral/xAI — tak).
Shaping/jitter na egress (świadomie, z testami SLA).
Runbook SIEM: kolekcja metryk size/IAT dla TLS → detekcja sondowań.
Program „AI side-channel testing” w SecEng/Red Team.

Źródła / bibliografia

SecurityWeek — omówienie badań i zaleceń (11 listopada 2025). (SecurityWeek)
Microsoft Security Blog — pełny opis metody, wyniki i mitigacje (7 listopada 2025). (Microsoft)
ArXiv — artykuł techniczny „Whisper Leak: a side-channel attack on Large Language Models” (listopad 2025). (arXiv)
The Register — status dostawców, komentarze badaczy i aktualizacja od AWS (11 listopada 2025). (The Register)
CSO Online — konsekwencje dla przedsiębiorstw i streszczenie mitigacji (10 listopada 2025). (CSO Online)

CVE-2025-42887 — Code Injection w SAP Solution Manager

TL;DR

Krytyczna podatność CVE‑2025‑42887 w SAP Solution Manager (ST 720) umożliwia wstrzyknięcie kodu podczas wywołania zdalnie udostępnionego modułu funkcyjnego (RFC) przez uwierzytelnionego atakującego. Skutkiem może być pełna kontrola systemu (wysokie C/I/A). CVSS v3.1: 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Dostawca opublikował poprawkę w Security Note 3668705 — należy wdrożyć niezwłocznie oraz ograniczyć dostęp do SAP RFC Gateway (porty 33xx) i monitorować Security Audit Log (SM20) i logi bramy RFC/ICM.

Krótka definicja techniczna

Błąd walidacji danych wejściowych w SAP Solution Manager pozwala podczas wywołania remote‑enabled function module na umieszczenie i wykonanie złośliwego kodu w kontekście aplikacyjnym. Wektor ataku jest sieciowy, z niską złożonością, wymaga niskich uprawnień (PR:L), nie wymaga interakcji użytkownika i zmienia zakres (Scope: Changed).

Gdzie występuje / przykłady platform

Produkt: SAP Solution Manager 7.2 (komponent ST 720) – krajobrazy on‑prem (Windows/Linux) i IaaS (AWS/Azure/GCP).
Protokół/warstwa dostępu: SAP RFC/Gateway (TCP 33xx/sapgw<inst>), HTTP(S)/ICM w wybranych scenariuszach SOAP RFC.
Przykładowe wdrożenia demo/PoC: oficjalne systemy pokazowe SolMan 7.2 (ST 720).

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

Mechanizm RFC umożliwia wywoływanie w ABAP funkcji oznaczonych jako Remote‑Enabled. W CVE‑2025‑42887 brak właściwego oczyszczania danych wejściowych przy takim wywołaniu prowadzi do wstrzyknięcia kodu i jego wykonania po stronie serwera SolMan. Ponieważ podatność dotyczy elementu administracyjnego (Solution Manager), kompromitacja może kaskadowo oddziaływać na systemy zarządzane i integracje (zmieniony zakres). W praktyce błąd wpisuje się w łańcuch TTP: eksploatacja usługi (T1190/T1210) → wykonanie/podniesienie uprawnień (T1068/T1059). Krytyczność rośnie, gdy RFC Gateway jest dostępny spoza zaufowanych segmentów lub gdy konta techniczne mają szerokie uprawnienia S_RFC/S_RFCACL.

Artefakty i logi

Źródło	Typ/ID	Pole / EID / Event	Wzorzec / co szukać	Uwagi
SAP Security Audit Log (SM19/SM20)	Aplikacja	Klasy „RFC/CPIC”, logony RFC, wywołania FM	Nietypowe logony RFC (pory, hosty), skoki liczby wywołań; nieudane/odrzucone autoryzacje S_RFC	Podstawowy strumień audytowy ABAP.
SAP RFC Gateway (gw_log / dev_rd, GWMON)	Aplikacja	Zdarzenia bramy (rejestracja, połączenia, wywołania)	Niespodziewane źródła, nietypowe programy rejestrowane, błędy autoryzacji/ACL	Porty 33xx; obserwuj reg_info/sec_info.
ICM/HTTP (dev_icm, log HTTP)	Aplikacja	Żądania do endpointów RFC/SOAP	Nietypowe POST do ścieżek RFC/SOAP z zewnątrz	W zależności od konfiguracji.
Firewall/NetFlow/VPC Flow Logs	Sieć	dstPort 3300–3399 (sapgw*)	Połączenia z niezalistowanych ASN/VPC; skoki wolumenu	Dobre do korelacji z SAL.
Windows Sysmon	EID=1	ParentImage = `disp+work.exe`/`gwrd.exe`/`sapstartsrv.exe` → child `cmd.exe`/`powershell.exe`	Egzekucja powłoki przez procesy SAP	W SolMan na Windows.
Linux auditd	SYSCALL/EXECVE	`exe` parent `disp+work`/`gwrd` → `/bin/sh`, `/bin/bash`	Jak wyżej dla Linux
AWS VPC Flow Logs (CloudWatch)	—	`dstPort` 3300..3399, `action=ACCEPT`	Źródła poza allowlistą, krótkie serie połączeń	CloudTrail nie rejestruje ruchu sieciowego.
K8s audit / M365	—	—	[nie dotyczy]	—

(Porty RFC Gateway 33xx potwierdza KBA; komponent SolMan 7.2 = ST 720).

Detekcja (praktyczne reguły)

Sigma — nieautoryzowane wejścia na SAP RFC Gateway (sieć)

title: Suspicious Access to SAP RFC Gateway (sapgw 33xx) From Untrusted Source
id: 1c9b8f8b-2c0f-4c2b-a8a2-7b2b7b33f9e1
status: experimental
description: Detect inbound connections to SAP RFC Gateway ports (33xx) from non-approved networks
author: Badacz CVE
date: 2025/11/12
logsource:
  category: network_connection
detection:
  selection:
    destination.port|gte: 3300
    destination.port|lte: 3399
    network.direction: inbound
  filter_allowlist:
    source.ip|cidr:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      # uzupełnij o własne sieci i partnerów
  condition: selection and not filter_allowlist
fields:
  - source.ip
  - destination.ip
  - destination.port
  - network.transport
falsepositives:
  - Zdalne serwisy administracyjne w zaufowanych strefach
level: high
tags:
  - attack.T1190
  - attack.T1210

Sigma — egzekucja powłoki z procesów SAP (Windows Sysmon)

title: Shell Spawned by SAP Work/Gateway Process
id: 9e7f4d95-2a8f-4ff0-9f6a-1d0b6e18bb3e
status: experimental
logsource:
  product: windows
  service: sysmon
  definition: Event ID 1 (Process Create)
detection:
  selection:
    EventID: 1
    ParentImage|endswith:
      - '\disp+work.exe'
      - '\gwrd.exe'
      - '\sapstartsrv.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: selection
level: high
tags:
  - attack.T1059
  - attack.T1068

Splunk (SPL) — ruch do sapgw i korelacja z hostami SolMan

| tstats count min(_time) as first_seen max(_time) as last_seen 
  from datamodel=Network_Traffic 
  where All_Traffic.dest_port>=3300 All_Traffic.dest_port<=3399 
  All_Traffic.action=allowed 
  All_Traffic.dest IN ($SOLMAN_HOSTS$)
  by All_Traffic.src, All_Traffic.dest, All_Traffic.dest_port
| `drop_dm_object_name("All_Traffic")`
| eval duration=last_seen-first_seen
| where count>=5 OR duration < 60

KQL (Microsoft Sentinel) — CommonSecurityLog / ASIM

let Allowed = dynamic(["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"]);
imNetworkSession
| where DstPort between (3300 .. 3399)
| where not( ipv4_is_in_any_range(SrcIpAddr, Allowed) )
| summarize cnt=count(), firstSeen=min(TimeGenerated), lastSeen=max(TimeGenerated)
          by SrcIpAddr, DstIpAddr, DstPort, NetworkProtocol
| where cnt >= 5 or datetime_diff("minute", lastSeen, firstSeen) <= 1

AWS CloudWatch Logs Insights — VPC Flow Logs (przykład + AWS CLI)

Zapytanie:

fields @timestamp, srcAddr, dstAddr, dstPort, action, bytes
| filter dstPort >= 3300 and dstPort <= 3399 and action = 'ACCEPT'
| stats count() as flows, sum(bytes) as totalBytes, min(@timestamp) as firstSeen, max(@timestamp) as lastSeen by srcAddr, dstAddr, dstPort
| sort by flows desc

CLI:

aws logs start-query \
  --log-group-name /vpc/flowlogs/production \
  --start-time $(date -d '15 minutes ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, srcAddr, dstAddr, dstPort, action | filter dstPort >= 3300 and dstPort <= 3399 and action="ACCEPT" | stats count() by srcAddr, dstAddr, dstPort'

Elastic Security — EQL (sieć) i KQL (host)

EQL (sieć):

network where destination.port >= 3300 and destination.port <= 3399
  and not cidrmatch(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")

KQL (Windows host):

event.code:1 and event.provider:"Microsoft-Windows-Sysmon" and
process.parent.name:( "disp+work.exe" or "gwrd.exe" or "sapstartsrv.exe" ) and
process.name:( "cmd.exe" or "powershell.exe" )

Uzasadnienie doboru portów i usług: SAP RFC Gateway nasłuchuje na 33xx (sapgw<inst>), co potwierdzają oficjalne materiały SAP.

Heurystyki / korelacje (co łączyć)

Łańcuch sieć → aplikacja → host: (1) inbound na 33xx z adresów spoza allowlisty → (2) wzrost liczby logonów RFC/odrzuconych autoryzacji S_RFC w SM20 → (3) pojawienie się powłoki/nietykowego procesu potomnego spod disp+work/gwrd.
Anomalia kont technicznych: Nagle wzmożone wywołania RFC przez rzadko używany service user lub nowe destynacje SM59.
Zmiana zakresu (Scope Changed): aktywność na hostach zarządzanych przez SolMan po zdarzeniu na SolMan (lateral movement).
„Public‑facing” vs. „internal”: traktuj SolMan jak krytyczny admin plane – ekspozycja bramy RFC/ICM poza segment IT Ops zwiększa ryzyko T1190/T1210.

False positives / tuning

Legitmny monitoring/automaty (np. EEM, integracje, batch) generują stały ruch RFC — whitelistuj znane źródła/VPN/VPC oraz konta S‑user.
Działania adminów w oknach serwisowych (SM59 testy, importy) – uwzględnij harmonogramy.
W regułach hostowych ogranicz do serwerów roli SolMan ABAP i do procesów rodziców SAP.

Playbook reagowania (kroki + komendy)

Triage

Zweryfikuj podatność: czy Security Note 3668705 jest zaimplementowana (SNOTE), jaka wersja ST 720 SP.
- Linux: sapcontrol -nr <inst> -function GetVersionInfo | egrep -i "ST *720|SAP BASIS"
- Windows PowerShell: sapcontrol.exe -nr <inst> -function GetVersionInfo
- Sprawdź dziennik wdrożeń not SAP.
Zbierz logi: SM20, gw_log/dev_rd, dev_icm; artefakty hostowe (Sysmon/auditd).

Containment

Ogranicz ruch: ACL/Firewall – zamknij 33xx spoza allowlisty; jeżeli w chmurze – NSG/SG.
Czasowo zablokuj konto użyte w podejrzanych logonach RFC; wymuś rotację haseł/kluczy SNC.

Eradication

Natychmiast wdroż poprawkę (Note 3668705).
Zweryfikuj i doprecyzuj role S_RFC/S_RFCACL; wymuś SNC/TLS dla RFC.

Recovery + Lessons

Testy regresji krytycznych funkcji SolMan; przywróć dostęp etapami; dopisz kontrolę bazową w SIEM.

(Poprawka i opis CVE wg NVD/SAP Patch Day).

Przydatne szybkie komendy (bezpieczne):

# Linux: nasłuchy i procesy SAP
ss -ltnp | egrep ':33[0-9]{2}\s'         # RFC Gateway
ps -ef | egrep 'disp\+work|gwrd|sapstartsrv|icman'

# Windows (PowerShell): połączenia na 33xx
Get-NetTCPConnection -LocalPort 3300..3399 | 
  Select-Object LocalAddress,LocalPort,RemoteAddress,State

Przykłady z kampanii / case studies

CVE‑2020‑6207 (SolMan EEM) – publiczny exploit i aktywne skanowanie/exploity w 2021 r.; pełny kompromis agentów SMD. To pokazuje, że CVE w SolMan są szybko wykorzystywane, jeśli nie spatchowane.
CVE‑2025‑31324 (NetWeaver Visual Composer) – aktywna eksploatacja RCE w 2025 r.; potwierdzenie, że n‑day SAP bywają na celowniku.

Status CVE‑2025‑42887: na moment 2025‑11‑12 brak publicznych raportów o aktywnej eksploatacji; zalecane działanie jak dla krytycznych RCE (patch + ograniczenie ekspozycji). (Wnioski na podstawie komunikatów prasowych i NVD).

Lab (bezpieczne testy) — przykładowe komendy

Środowisko: izolowane NON‑PROD SolMan 7.2 (ST 720). Testy nie polegają na eksploatacji CVE — służą weryfikacji detekcji.

Wygeneruj zdarzenia RFC (SM59 → „Test connection”) z hosta testowego spoza allowlisty — powinny pojawić się wpisy w SM20 i w logach Gateway.
Symuluj ruch sieciowy

# skan portów sapgw
nmap -Pn -p 3300-3399 <ip_solman>

Sprawdź logi bramy RFC (GWMON → Logs/Traces) i zweryfikuj, że reguły Sigma/SIEM z pkt 7 wyłapują wejścia spoza allowlisty.
Host telemetry (Windows/Linux) – uruchom prosty proces testowy z poziomu SAP (legalne zadanie/rapport), aby potwierdzić, że reguła „shell spawned by SAP” działa — NIE uruchamiaj poleceń wrażliwych.

Mapowania (Mitigations, Powiązane techniki)

Techniki ATT&CK (Enterprise)

T1190 – Exploit Public‑Facing Application (jeśli RFC/ICM wystawione publicznie).
T1210 – Exploitation of Remote Services (wykorzystanie RFC w sieci wewnętrznej/lateral).
T1068 – Exploitation for Privilege Escalation (eskalacja po uzyskaniu wykonania w ABAP/host).
T1059 – Command and Scripting Interpreter (ew. wtórne wykonanie poleceń).

Mitigations ATT&CK

M1051 – Update Software (wdrożenie SAP Note 3668705/Patch Day).
M1030 – Network Segmentation (izolacja SolMan/RFC Gateway; dostęp tylko z sieci admin).
M1040 – Behavior Prevention on Endpoint (EDR/ASR na hostach Windows SolMan).

Źródła / dalsza literatura

NVD: opis, wektor CVSS, odniesienia do SAP Note 3668705. (NVD)
SAP Security Patch Day (listopad 2025): lista not, CVE‑2025‑42887 (CVSS 9.9), produkt/wersja. (SAP Support Portal)
BleepingComputer / SecurityWeek: przegląd poprawek SAP, wzmianka o CVE‑2025‑42887. (BleepingComputer)
SAP docs — Security Audit Log, RFC Gateway, S_RFC/S_RFCACL, ACL: konfiguracja i logging. (SAP Help Portal)
Porty RFC Gateway (33xx): artykuł KBA/Community. (SAP Support Portal)
Kontekst kampanii (SolMan/NetWeaver): Onapsis/Tenable/NVD/Darktrace. (Onapsis)

Checklisty dla SOC / CISO

SOC (operacyjne, 24/7):

Reguły SIEM na 33xx inbound + korelacja z SM20 i procesami hosta.
Watchlist kont S_RFC/S_RFCACL i destynacji SM59.
Alarm „shell from disp+work/gwrd”.
Dashboard: status wdrożenia Note 3668705 na wszystkich SolMan.

CISO / GRC (strategiczne):

Polityka segmentacji – SolMan wyłącznie w strefie admin z dostępem z bastionów.
Harmonogram Patch Day SAP + SLA krytycznych poprawek ≤ 7 dni.
Przegląd uprawnień RFC (least privilege) + SNC/TLS obowiązkowe.
Testy kontrolne: skan ekspozycji (33xx/ICM), przegląd konfiguracji reg_info/sec_info.

CVE-2025-12735 — expr‑eval: RCE przez nieograniczone funkcje w evaluate()

TL;DR

Biblioteka expr‑eval (oraz fork expr‑eval‑fork) pozwala — z powodu niewystarczającej walidacji wejścia — przekazać do evaluate() spreparowany obiekt zmiennych/kontekstu i wywołać dowolne funkcje, co w środowisku Node.js może prowadzić do zdalnego wykonania kodu (RCE). Fork został załatany (v3.0.0); w oryginalnym repo trwa proces patchowania (PR #288, brak wydania). Priorytet: krytyczny dla backendów Node i funkcji serverless korzystających z expr‑eval.

Krótka definicja techniczna

CVE‑2025‑12735 to luka typu CWE‑94 (Improper Control of Generation of Code / Code Injection) w bibliotece expr‑eval, która umożliwia przekazanie własnych funkcji w obiekcie variables/context do evaluate(). Brak restrykcji/allowlisty funkcji pozwala w Node.js dotrzeć do API procesu (np. pośrednio do child_process) i doprowadzić do wykonania komend systemowych.

Gdzie występuje / przykłady platform

Aplikacje Node.js (monolity i mikroserwisy) — API, boty, serwery WWW.
Serverless: AWS Lambda/Azure Functions/Cloud Run z runtime Node.
Kontenery/Kubernetes: obrazy z zależnością expr-eval.
Przeglądarka: wpływ ograniczony (brak process/require), nadal możliwe nadużycia logiki/dane.
Fork: expr-eval-fork — załatany w 3.0.0.

Szczegółowy opis techniki (jak działa, cele, skuteczność)

expr-eval parsuje i ocenia wyrażenia matematyczne. Luka polega na tym, że funkcje dostępne w czasie ewaluacji nie były odpowiednio ograniczone i można je było wstrzyknąć poprzez obiekt zmiennych (evaluate(vars)), co narusza założenia „bezpiecznej alternatywy dla eval”. W środowisku Node.js skutkiem jest możliwość eskalacji do prymitywów wykonania (np. wywołania interpretera lub komend systemowych), gdy aplikacja przekazuje niezaufane wyrażenia/zmienne do parsera. CERT/CC odnotował wprowadzenie łat poprzez PR #288 (allowlista funkcji, mechanizm rejestracji), a GitHub Advisory formalnie klasyfikuje słabość jako CWE‑94. expr‑eval‑fork 3.0.0 zawiera poprawkę; w oryginalnym repo brak wydanego release’u w momencie publikacji.

Zakres wersji (według GH Advisories):

expr-eval ≤ 2.0.2 — podatne; brak opublikowanej wersji naprawczej.
expr-eval-fork ≤ 2.0.2 — podatne; naprawiono w 3.0.0.

Ocena ryzyka: CISA‑ADP ocenia na CVSS 9.8 (sieć, brak uprawnień/UI), GitHub na 8.6 (CVSS v4.0); różnica wynika z przyjętego modelu wektorów i założeń dot. kontekstu wykonania.

Artefakty i logi (co szukać)

Warstwa	Źródło / ID	Na co patrzeć	Przykład / wskazówka
Windows	Security EID 4688, Sysmon EID 1	Dziecko procesu `node.exe` → `cmd.exe`/`powershell.exe`; nietypowe `-c`/`/c`	ParentImage = `\node.exe`, Image = `\cmd.exe`, CommandLine zawiera `/c`
	Sysmon EID 3	Nowe połączenia sieciowe z procesu aplikacji Node	Nietypowe dest. IP/AS, brak w allowliście egress
	Sysmon EID 11/13	Tworzenie/zmiana plików/kluczy rejestru przez `node.exe`	Drop plików w temp/autoruns
Linux	auditd (`EXECVE`), journald	`node` uruchamia `sh`/`bash`/`python` z parametrem `-c`	`/usr/bin/node … → /bin/sh -c …`
Container/K8s	K8s audit (`create` na `pods/exec`, `ephemeralcontainers`)	Próby ucieczki/utrzymania kontroli po RCE	Użytkownik SA aplikacji inicjuje `pods/exec`
Cloud (AWS)	CloudTrail	Nietypowe UpdateFunctionCode, CreateFunction, modyfikacje env/secrets przez role aplikacji	Koreluj z IP/UA i oknem incydentu
M365/Entra (po wtórnej kompromitacji)	Unified Audit Log	„Consent to application”, „Add service principal”, „Add app role assignment to service principal”	Weryfikuj nieoczekiwane zgody/role w czasie incydentu

Detekcja (praktyczne reguły)

Sigma (Windows / Sysmon — „Node → shell”)

title: Suspicious Shell Spawned by Node.js (possible expr-eval abuse)
id: 7b3fbf8c-2c7a-4d37-9b7a-ef3a6c1b57a8
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  parent_node:
    ParentImage|endswith: '\node.exe'
  child_shell:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  cli_flags:
    CommandLine|contains:
      - ' /c '
      - ' -c '
  condition: parent_node and child_shell and cli_flags
fields:
  - Image
  - CommandLine
  - ParentImage
falsepositives:
  - Legit. task runners/installer scripts
level: high
tags:
  - attack.t1059.003
  - attack.t1059.001
  - attack.t1203
  - attack.t1190

Splunk (Sysmon EID=1)

index=your_sysmon_index EventCode=1 ParentImage="*\\node.exe"
| search Image="*\\cmd.exe" OR Image="*\\powershell.exe"
| search CommandLine="* /c *" OR CommandLine="* -c *"
| stats count min(_time) max(_time) by Computer, User, ParentImage, Image, CommandLine

KQL (Microsoft Defender for Endpoint)

DeviceProcessEvents
| where InitiatingProcessFileName =~ "node.exe"
| where FileName in~ ("cmd.exe","powershell.exe","bash","sh")
| where ProcessCommandLine has_any (" /c ", " -c ")
| summarize cnt=count(), firstTime=min(Timestamp), lastTime=max(Timestamp)
        by DeviceName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

CloudTrail (CloudWatch Logs Insights)

fields @timestamp, eventSource, eventName, userIdentity.type, userIdentity.arn, sourceIPAddress
| filter eventSource="lambda.amazonaws.com"
  and eventName in ["UpdateFunctionCode","CreateFunction","UpdateFunctionConfiguration"]
| sort @timestamp desc

Cel: wychwycić nieoczekiwane zmiany kodu/konfiguracji funkcji wykonywane przez role/podmioty powiązane z usługą korzystającą z expr-eval.

Elastic EQL

process
  where process.parent.name == "node"
    and process.name in ("cmd.exe","powershell.exe","sh","bash","python")
    and process.args in ("-c","/c","-e")

Heurystyki / korelacje

SBOM/SCA ↔ telemetry: stwierdzona zależność expr-eval (<=2.0.2) lub expr-eval-fork (<=2.0.2) + anomalia „Node → shell”.
Wzorce ruchu: nagły egress z procesu aplikacji (nowe domeny/ASN) w pobliżu czasu wywołań evaluate().
Zmiany w infrastrukturze: CloudTrail UpdateFunctionCode/modyfikacje env/secret po zdarzeniach aplikacji.
M365/Entra: niespodziewane „Consent to application” / „Add service principal” po incydencie (możliwa eskalacja OAuth).

False positives / tuning

Legit. narzędzia Node uruchamiające powłokę (instalatory, task‑runnery) — obwiedniaj detekcję listą dozwolonych ścieżek/usług, oknem czasowym (CI/CD), użytkownikiem i komendami (blokuj -c poza maintenance).
Środowiska dev — wydzielone indeksy/logsource, niższy poziom alertowania.
Serwisy, które w ogóle nie powinny odpalać powłoki — alert krytyczny.

Playbook reagowania (IR)

Triaging: korelacja alertu (Node→shell / CloudTrail / M365) + potwierdzenie zależności w SBOM (npm ls expr-eval).
Izolacja: odłącz instancję/poda (K8s: kubectl cordon/drain serwis, tymczasowe NetworkPolicy egress‑deny).
Ograniczanie szkód: rotacja secretów/tokenów używanych przez serwis; w chmurze — blokada roli/aplikacji zaufania.
Forensyka: zachowaj dysk/pamięć, eksportuj dzienniki (Sysmon/auditd/CloudTrail/M365 UAL).
Eradykacja:
- Migracja do expr-eval-fork 3.0.0 lub wdrożenie łatki po publikacji release oryginału; tymczasowo usuń/wyłącz niestandardowe funkcje i wdroż allowlistę funkcji.
Weryfikacja: testy regresji, monitoring post‑incident (szczególnie „Consent to application” w M365).
Lessons learned: reguły pre‑commit/CI (npm audit, SCA), polityki review zmian zależności.

Przykłady z kampanii / case studies

Na dzień 11 lis 2025 brak potwierdzonej eksploatacji „in the wild”; Tenable klasyfikuje CVE jako „not exploited (being monitored)”. Rekomendowane jest pilne łatanie/migracja.

Lab (bezpieczne testy)

A. Weryfikacja zależności

# sprawdź wersję
npm ls expr-eval expr-eval-fork
# jeżeli obecne i podatne, przygotuj hotfix/migrację (fork 3.0.0)

B. Generowanie sygnałów do reguł (symulacja „Node → shell”) — bez użycia luki:

# Linux
node -e "require('child_process').spawn('/bin/sh',['-c','echo ok'],{stdio:'inherit'})"
# Windows (PowerShell)
node -e "require('child_process').spawn('cmd.exe',['/c','echo ok'])"

Następnie zweryfikuj dopasowania: Sysmon EID=1, auditd EXECVE, oraz reguły Sigma/SPL/KQL.

C. K8s/CloudTrail

W K8s odpal kubectl auth can-i dla SA serwisu i potwierdź brak uprawnień do pods/exec.
W AWS przepuść kontrolowany UpdateFunctionConfiguration (np. dummy tag), aby potwierdzić zadziałanie zapytania CloudWatch Insights.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

M1038 Execution Prevention (application allowlisting, blokada interpreterów w usługach).
M1054 Software Configuration (wyłącz/ogranicz niestandardowe funkcje, hardening konfigu).
M1045 Code Signing (wymuszaj podpisy/CI deklaratywny deployment).
M1047 Audit (regularny audyt zależności i uprawnień).

Powiązane techniki: T1190, T1203, T1059(.003/.004/.007)

Źródła / dalsza literatura

NVD: opis, CVSS CISA‑ADP 9.8, referencje (w tym PR #288, npm). (NVD)
CERT/CC VU#263614: opis wektora, stan łat (PR #288), identyfikatory (GHSA). (CERT Coordination Center)
GitHub Advisory (GHSA‑jc85‑fpwf‑qm7x): zakres wersji podatnych i wersje naprawcze (fork 3.0.0), CWE‑94, CVSS v4.0. (GitHub)
PR #288 (silentmatt/expr‑eval): propozycja poprawki (allowlista, testy), status Open. (GitHub)
BleepingComputer — materiał prasowy o RCE i rekomendacji migracji do forka. (BleepingComputer)
Tenable Research — status „not exploited” (monitorowane). (Tenable®)
ATT&CK v18 — wersjonowanie i strony technik. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjna)

Aktywuj/zweryfikuj telemetry: Sysmon (Win), auditd (Linux), K8s Audit, CloudTrail.
Wdroż reguły: Sigma/KQL/SPL/EQL z tej noty.
Przekrój SBOM/SCA: znajdź expr-eval/expr-eval-fork ≤ 2.0.2.
Koreluj „Node → shell” oraz nietypowy egress z procesów aplikacji.
Monitoruj M365 UAL pod kątem „Consent to application”/„Add service principal”.

CISO / AppSec (strategiczna)

Migracja: expr-eval-fork 3.0.0 lub oczekuj na oficjalny release oryginału (po weryfikacji PR #288).
Polityki wejścia: zakaz ewaluacji niezweryfikowanych wyrażeń; allowlista funkcji.
CI/CD: blok w PR na dodanie podatnych wersji (SCA), podpisy artefaktów (M1045).
Least privilege dla ról chmurowych usług korzystających z expr‑eval; segmentacja egress.
Plan IR: playbook z rotacją sekretów i sanityzacją środowiska po incydencie.

Uwaga dot. łat: wg GHSA fork expr‑eval‑fork ma poprawkę w 3.0.0; w oryginalnym expr‑eval trwa proces patchowania (PR #288, w momencie pisania Open). Planiści powinni rozważyć pilną migrację do forka i later ew. powrót po publikacji stabilnego wydania z łatą.

Cl0p publikuje listę ~30 ofiar kampanii na Oracle E-Business Suite. Co wiemy o atakach i jak się bronić

Wprowadzenie do problemu / definicja luki

Grupa powiązana z Cl0p opublikowała na swoim portalu około 30 rzekomych ofiar kampanii wymierzonej w klientów Oracle E-Business Suite (EBS) — popularnego systemu ERP. Na liście wymieniono m.in. Logitech, The Washington Post, Cox Enterprises, Pan American Silver, LKQ Corporation i Copeland. Część podmiotów (np. The Washington Post) potwierdziła naruszenie, większość jednak milczy lub prowadzi dochodzenia wewnętrzne. Źródła branżowe łączą tę falę incydentów z krytyczną podatnością CVE-2025-61882 (CVSS 9.8) w komponencie BI Publisher Integration pakietu EBS, która umożliwia zdalne, nieautoryzowane ataki przez HTTP. Oracle załatał błąd w trybie alarmowym na początku października 2025 r.

W skrócie

Atakujący: klaster przestępczy kojarzony z FIN11 i marką Cl0p (ekstorsja + wycieki).
Wektor: wykorzystanie luk w Oracle EBS; najbardziej prawdopodobna — CVE-2025-61882 (RCE bez uwierzytelniania) w zakresach wersji 12.2.3–12.2.14.
Skala: dziesiątki organizacji; ok. 29 pozycji na stronie Cl0p, wycieki danych u co najmniej 18 z nich (częściowo wieluset-GB/TB).
Linia czasu: masowe maile z szantażem od 29 września; łatki Oracle — 4–5 października 2025 r.; kolejne potwierdzenia ofiar w październiku-listopadzie.
Status: część firm potwierdziła incydent (np. The Washington Post), inne nie komentują publicznie.

Kontekst / historia / powiązania

Specjaliści Google Threat Intelligence i Mandiant opisali na początku października zmasowaną kampanię ekstorsyjną: do menedżerów spływały e-maile z twierdzeniami o kradzieży danych z ich środowisk EBS. Równolegle Reuters i inne media informowały o kolejnych ofiarach (np. Envoy Air/AA, Harvard), a Oracle potwierdził problem i wydał Security Alert z łatą. SecurityWeek zebrał listę ~30 nazw wskazanych przez Cl0p, podkreślając, że część danych rzeczywiście wygląda na pochodzące z instancji Oracle. Tę kampanię osadzono w modus operandi znanym z wcześniejszych akcji Cl0p (MOVEit, Fortra, Cleo) — presja medialna + publikacja wykradzionych pakietów.

Analiza techniczna / szczegóły luki

CVE-2025-61882 (Oracle E-Business Suite – Concurrent Processing / BI Publisher Integration)

Zakres wersji: 12.2.3–12.2.14.
Skutki: zdalne przejęcie komponentu (CIA: C/I/A=H, CVSS 9.8), bez uwierzytelniania przez HTTP.
Charakter: „easily exploitable”; sprzyja RCE i dostępowi do wrażliwych danych przetwarzanych w EBS.
Eksploatacja: raporty wskazują na aktywny exploit przed publikacją poprawki (zero-day).

Uwaga: w doniesieniach pojawia się także druga luka z tej samej „rodziny”, jednak na dziś to CVE-2025-61882 jest jednoznacznie potwierdzone przez Oracle/NVD jako krytyczny wektor RCE.

Prawdopodobny łańcuch ataku (uogólniony)

Skany internetowo dostępnych instancji EBS (typowe ścieżki /OA_HTML/…).
Wykorzystanie CVE-2025-61882 do wykonania kodu w komponentach związanych z BI Publisher/Concurrent Processing.
Utrwalenie (np. web-shell, konto aplikacyjne) i zbieranie danych (eksporty, raporty, zrzuty tabel).
Ekstorsja: kontakt do kadry zarządzającej z żądaniem okupu + groźbą publikacji plików.
Publikacja paczek na stronie Cl0p w razie braku płatności.

Praktyczne konsekwencje / ryzyko

Kompromitacja danych ERP: finanse, łańcuch dostaw, HR, logistyka — wysokie ryzyko wtórnych oszustw i fraudów.
Zakłócenia operacji: ryzyko zatrzymania procesów (AP/AR, zamówienia, produkcja).
Ryzyko prawno-regulacyjne: RODO/PCI/sox — kary administracyjne, obowiązki notyfikacyjne.
Efekt łańcuchowy: EBS z reguły integruje się z innymi systemami (ESB, hurtownie danych) — możliwość lateral movement.
Ryzyko reputacyjne: Cl0p publikuje duże wolumeny danych (setki GB do TB), co zwiększa presję na zapłatę.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i konfiguracja

Natychmiast zastosuj Security Alert dla CVE-2025-61882 (EBS 12.2.3–12.2.14). Zweryfikuj, że poprawka została wdrożona na wszystkich węzłach (apps tier/db tier).
Ogranicz ekspozycję EBS do internetu: jeśli to możliwe, dostęp wyłącznie przez VPN/ZTNA; przeglądarkowy interfejs użytkownika (OA_HTML) nie powinien być publiczny.
WAF/Reverse proxy: tymczasowe reguły blokujące nietypowe żądania do endpointów raportowania/BI, rozmiary odpowiedzi i długotrwałe transfery.

2) Detekcja i monitoring (przykładowe reguły)

Netflow/Proxy/Firewall – wykrywanie dużych POST/GET do zewnętrznych adresów z hostów EBS:
- Splunk (prosty szkic): index=proxy OR index=nginx sourcetype=http (uri_path="/OA_HTML/*" OR cs_uri_stem="/OA_HTML/*") | stats sum(bytes_out) as out, values(cs_uri_query) as q by src_ip, uri_path, http_method | where out > 500000000 /* >500MB dziennie */
System – nietypowe procesy JVM/Java z parametrami uruchamianymi przez użytkowników aplikacyjnych:
- Linux (ad-hoc): ps -ef | egrep 'java|weblogic' | egrep -i 'curl|wget|nc|bash -i|sh -i'
Pliki aplikacyjne – poszukiwanie web-shelli w katalogach serwisujących EBS: find $INST_TOP/ora/10.1.3/j2ee -type f -mtime -30 -size +50k \ -iname "*.jsp" -exec grep -H -E "(Runtime|getRuntime|ProcessBuilder)" {} \;
Logi HTTP – anomalie w BI Publisher/Concurrent Processing (duże odpowiedzi, 5xx po dużych POST, nagły skok 2xx): awk '{print $7, $9, $10}' access_log | grep -E "BIPublisher|Concurrent|OA_HTML" | sort | uniq -c | sort -nr | head

(Powyższe to wzorce poszukiwań – dostosuj do swojej topologii i ścieżek w danym wydaniu EBS.)

3) Łagodzenie skutków i IR

Załóż kompromitację dla instancji nienaprawionych przed 4–5 października 2025 r.; przeprowadź triage pamięci (Volatility/AVML) i przegląd harmonogramów (Concurrent Requests), kont oraz pakietów raportowych.
Rotacja haseł/kd. integracyjnych i przegląd SSO jeśli EBS zintegrowany jest z IdP.
Segmentacja: izoluj serwery apps/db do czasu zakończenia dochodzenia, wstrzymaj zadania eksportów masowych.
Zgłoszenia regulacyjne: oceń zakres danych wg jurysdykcji (np. RODO) i czasów detekcji.

4) Twardnienie (hardening) „na jutro”

Minimalizacja powierzchni: odłącz zbędne moduły/servlety, wymuś TLS 1.2+, nagłówki bezpieczeństwa.
Kontrola egress: EBS zwykle nie potrzebuje otwartego ruchu wychodzącego do internetu — egres pod ścisłą allowlistą.
Kopia zapasowa planu odtworzeniowego: test odtworzenia offline; backupy szyfrowane i odseparowane (immutability).

Różnice / porównania z innymi przypadkami

MOVEit/Fortra/Cleo vs Oracle EBS: podobny model ekstorsji (nacisk medialny, tablica wstydu, hurtowe wycieki). Różnica: zamiast podatności w menedżerach transferu plików, celem jest system ERP — więc jakość i kontekst danych (finanse, logistyka) mają zwykle wyższą wartość operacyjną dla przestępców i większy impakt biznesowy. SecurityWeek wskazuje, że wcześniejsze skojarzenia Cl0p-FIN11 tłumaczą użycie brandu Cl0p jako „frontu” kampanii.

Podsumowanie / kluczowe wnioski

CVE-2025-61882 w Oracle EBS to krytyczna luka RCE, realnie wykorzystywana w kampanii ekstorsyjnej. Łatka od Oracle jest dostępna — patchuj natychmiast.
Lista Cl0p obejmuje ~29 organizacji, a część z nich potwierdziła incydenty (np. The Washington Post). Nie zakładaj, że „to tylko straszak”.
Traktuj EBS jak system krytyczny: zamknięcie ekspozycji internetowej, kontrola egresu, ciągły monitoring i „assume breach” dla okien bez łatek z końca września/początku października 2025 r.

Źródła / bibliografia

SecurityWeek – lista ~30 ofiar i kontekst kampanii Cl0p (10 listopada 2025). (SecurityWeek)
Reuters – The Washington Post potwierdza naruszenie związane z Oracle EBS (6 listopada 2025). (Reuters)
Oracle Security Alert – CVE-2025-61882 (EBS) – opis i łatki. (Oracle)
NVD – karta podatności CVE-2025-61882 (CVSS 9.8, RCE bez uwierzytelniania). (NVD)
Google Threat Intelligence – wpis o zero-day w Oracle EBS i kampanii ekstorsyjnej (9 października 2025). (Google Cloud)

CVE‑2014‑6271 — “Shellshock”

TL;DR

Shellshock (CVE‑2014‑6271) to krytyczna podatność RCE w GNU Bash (do 4.3 włącznie), która pozwala na wykonanie komend podczas parsowania zmiennych środowiskowych zawierających definicje funkcji. W praktyce była nadużywana głównie przez wektory HTTP/CGI (np. mod_cgi), ale także przez OpenSSH ForceCommand, klientów DHCP i inne komponenty, w których Bash jest odpalany po przekazaniu środowiska. Z perspektywy ATT&CK najlepiej mapuje się na T1190 (Initial Access), a dalsze uruchamianie komend — na T1059.004 (Unix Shell).

Krótka definicja techniczna

CVE‑2014‑6271 wynika z błędu w sposobie, w jaki Bash importuje funkcje ze środowiska: trailing‑string po definicji funkcji może zostać zinterpretowany jako komenda i wykonany w nowym procesie powłoki. Jeśli napastnik kontroluje wartości nagłówków/parametrów (np. przez CGI), osiąga zdalne wykonanie kodu (RCE) bez uwierzytelnienia.

Gdzie występuje / przykładowe platformy

Linux/UNIX (w tym macOS): serwery WWW z CGI (mod_cgi, mod_cgid), skrypty powłoki, usługi systemowe.
OpenSSH (ForceCommand): możliwość wstrzyknięcia przez SSH_ORIGINAL_COMMAND przy logowaniu do powłoki Bash.
Klienci DHCP (np. dhclient): złośliwe opcje DHCP jako nośnik.
Aplikacje/appliance’y sieciowe i środowiska kontenerowe: skrypty entrypoint, obrazy z podatnym Bashem; jeśli endpoint jest publiczny → T1190.
ESXi/appliance’y: niektóre systemy oparte o BusyBox/Bash (rzadziej), ale T1190 obejmuje też urządzenia brzegowe.
Chmury (AWS/Azure/GCP): po RCE na serwerze/pojemniku często obserwuje się dostęp do IMDS (169.254.169.254) w celu kradzieży poświadczeń — dalsze fazy.
AD/M365: brak typowych wektorów dla Shellshock — wpływ pośredni po uzyskaniu przyczółka na hostach Linux.

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

Bash umożliwia „eksport” funkcji przez zmienne środowiskowe. W podatnych wersjach parser Basha wykonywał łańcuchy znaków następujące po definicji funkcji, co otwierało drogę do RCE, jeśli napastnik mógł wstrzyknąć zawartość środowiska (np. przez nagłówki HTTP obsługiwane przez CGI). Pierwsza łatka okazała się niepełna (CVE‑2014‑7169), co dodatkowo zwiększyło okno ryzyka. Skuteczność ataku wynikała z: (1) powszechności Basha, (2) prostoty ładunku, (3) wielu wektorów przekazania środowiska przez granicę zaufania (HTTP, SSH, DHCP). W efekcie w ciągu godzin od ujawnienia obserwowano zautomatyzowane skanowanie i budowanie botnetów DDoS.

Artefakty i logi

Warstwa	Źródło	Pole / EID	Wskaźnik / wzorzec	Notatki
Aplikacja WWW	Apache/nginx access/error	`User-Agent`, `Referer`, `URI`, status	Wzorzec funkcji Basha w nagłówkach/parametrach (np. sekwencja funkcja+trailing)	Często wzrost 4xx/5xx przed właściwym RCE
System (Linux)	`auditd`	`type=EXECVE`	Rodzic: `httpd`/`apache2`/`nginx`/`cgi-fcgi` → dziecko: `/bin/bash -c …`	Łańcuch procesów po RCE
System (Linux)	`syslog`/journald	komunikaty serwisu WWW/CGI	Nagłe spawny powłoki, błędy CGI	Koreluj z access logami
EDR/telemetria	Procesy/sieć	—	`bash` uruchomiony przez konto serwisu WWW + wyjścia do Internetu	W tym wywołania narzędzi typu `curl/wget`
Chmura AWS	CloudTrail	`userAgent`, `sourceIPAddress`, `eventName`	Po RCE — nagłe API (np. `ListBuckets`, `GetCallerIdentity`, `AssumeRole`) z roli instancji / nietypowe UA	Często po próbie dostępu do 169.254.169.254 (IMDS) z hosta ofiary.
K8s	Audit log	`verb`, `objectRef`, `userAgent`	Niespodziewane `create pods/exec`/`attach` z SA serwisu WWW; enumeracja `secrets`	Efekt wtórny po RCE w podzie
M365	Unified Audit Log	—	[brak bezpośredniego wektora]	Koreluj tylko, gdy atak przechodzi w chmurę SaaS

Detekcja (praktyczne reguły)

Sigma (HTTP/CGI — próby Shellshock)

title: Possible Shellshock Attempt in HTTP Headers
id: 6b7e2d8d-2a0e-4b6b-9c5f-3d7a5f2d1b01
status: experimental
description: Wykrywa klasyczne wzorce importu funkcji Bash w nagłówkach/URI (np. wzorzec funkcja + trailing), charakterystyczne dla Shellshock.
author: Badacz CVE
date: 2025/11/08
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2014-6271
tags:
  - attack.T1190
  - cve.2014-6271
logsource:
  category: webserver
detection:
  sel_any_header:
    c-uri|contains:
      - "(){"
      - "%28%29%7B"    # URL‑encoded
    cs-user-agent|contains:
      - "(){"
      - "%28%29%7B"
    cs-referer|contains:
      - "(){"
      - "%28%29%7B"
  condition: sel_any_header
fields:
  - src_ip
  - http.request_referrer
  - http.user_agent
  - url
  - status
falsepositives:
  - Skany bezpieczeństwa/WAF test strings
level: high

Splunk (web access → wzorzec + łańcuch procesów)

(index=web OR index=proxy) (sourcetype=apache:* OR sourcetype=nginx:* OR sourcetype=haproxy*)
| eval raw=coalesce(cs_User_Agent," ") . " " . coalesce(cs_Referer," ") . " " . coalesce(uri," ") . " " . coalesce(query," ")
| where match(raw, "\\(\\)\\s*\\{\\s*:\\s*;\\s*\\}")
| stats count earliest(_time) as first latest(_time) as last by src_ip, cs_User_Agent, uri, status

Korelacja (Splunk) — procesy na hoście Linux (jeśli zbierasz dzienniki systemowe/EDR):

index=os_linux (sourcetype=auditd OR sourcetype=sysmon_linux OR sourcetype=edr*)
| where (parent_process IN ("httpd","apache2","nginx","lighttpd","cgi-fcgi") AND process IN ("bash","sh") )
| stats values(process_cmdline) as cmd by host, parent_process, user, process

KQL (Defender for Endpoint / Azure)

// RCE → bash uruchomiony przez proces WWW
DeviceProcessEvents
| where OSPlatform in ("Linux","macOS")
| where InitiatingProcessFileName in~ ("httpd","apache2","nginx","lighttpd","cgi-fcgi")
| where FileName in~ ("bash","sh")
| extend suspicious = iif(ProcessCommandLine has_any ("() {","%28%29%7B"), 1, 0)
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, suspicious

CloudTrail (CloudWatch Logs Insights) – post‑exploitation z roli instancji

fields @timestamp, eventSource, eventName, userAgent, sourceIPAddress, awsRegion
| filter eventCategory="Management"
| filter userAgent like /aws-cli|Boto|Go-http-client|curl|wget|python-requests/i
| filter eventName in ("GetCallerIdentity","AssumeRole","ListBuckets","GetObject","DescribeInstances","ListAccessKeys")
| sort @timestamp desc
| limit 200

Uzasadnienie: po RCE atakujący często odczytuje IMDS 169.254.169.254 i zaczyna wykonywać API przy użyciu roli instancji. Monitorowanie userAgent i nietypowej sekwencji API pomaga to wyłapać.

Elastic EQL (host Linux — łańcuch WWW → powłoka)

process where host.os.type == "linux" and
  process.name in ("bash","sh") and
  process.parent.name in ("httpd","apache2","nginx","lighttpd","cgi-fcgi")

Heurystyki / korelacje (co łączyć)

Anomalia HTTP → 4xx/5xx/niestandardowe metody/URI → spawn powłoki przez proces WWW → wyjście sieciowe lub IMDS 169.254.169.254 → aktywność API w CloudTrail.
Jednorodny UA/źródła IP atakujące wiele hostów + identyczne wzorce nagłówków = kampania skanowania.
Po RCE: zapis webshella (T1505.003) lub pobranie binarek (T1105) — koreluj z tworzeniem nietypowych plików w katalogach serwisu WWW.

False positives / tuning

Skany bezpieczeństwa/WAF test strings — przepuść przez allow‑listy znanych skanerów i Twoich narzędzi QA.
Zaszyfrowane/URL‑encoded warianty — rozszerz regex (np. %28%29%7B).
Reverse proxy — upewnij się, że widoczny jest oryginalny UA i IP (X‑Forwarded‑For).
Systemy bez CGI — same ślady w logach HTTP ≠ RCE: szukaj łańcucha procesów (rodzic WWW → bash).

Playbook reagowania (IR)

Blokada na brzegu: reguły WAF/IPS dla wzorca funkcji Basha; tymczasowe ograniczenie dozwolonych metod/ścieżek.
Izolacja hosta (serwer/Pod) + snapshot dysku/pamięci.
Triage artefaktów: access/error logs, auditd, łańcuch procesów, nowe pliki w docroot, klucze/sekrety.
Weryfikacja IMDS/poświadczeń: sprawdź ruch do 169.254.169.254 i następujące wpisy w CloudTrail; rotacja kluczy/rol.
Patching Bash do wersji załatanej (dystrybucyjny update), weryfikacja wyłączenia/ograniczenia CGI.
Hunting w SIEM: zapytania z sekcji 7 na całą flotę.
Hardening: wymuś IMDSv2, segmentację DMZ, least‑privilege dla kont serwisów.

Przykłady z kampanii / case studies

Szybka weaponizacja (2014): w ciągu doby od ujawnienia powstały botnety DDoS; liczne ataki obserwowali m.in. Kaspersky i media branżowe.
Raporty vendorów/CSIRT: Cisco Talos dokumentował masowe próby eksploatacji w sieci; Akamai opisywał rekrutację hostów do botnetów.

Lab — przykładowe kroki

Cel: przetestować detekcje bez wykonywania exploita. Wykorzystujemy syntetyczne dane i odizolowane środowisko testowe.

Symulacja logów HTTP: wygeneruj sztuczne wpisy access.log zawierające charakterystyczny wzorzec funkcji Basha w formie zanonimizowanej (bez komend), np. () { :; }; <marker>; wgraj plik do SIEM i uruchom reguły z pkt 7.
Symulacja łańcucha procesów: w kontenerze testowym uruchom skrypt, który (lokalnie) tworzy proces bash jako dziecko procesu o nazwie „httpd” (np. wrapper), tak aby telemetria EDR/auditd wygenerowała ślad parent=apache2 -> bash — bez wykonywania zewnętrznych komend.
Symulacja post‑exploitation w chmurze: używając konta testowego z rolą instancji, wykonaj bezpieczne GetCallerIdentity i ListBuckets, aby sprawdzić reguły CloudTrail (CloudWatch Logs Insights) — wyłącznie w środowisku testowym.

Uwaga: celem jest walidacja detekcji i playbooków IR zgodnie z zasadami bezpieczeństwa.

Mapowania (Mitigations, powiązane techniki)

Mitigacje ATT&CK:

M1051 – Update Software: szybkie łatanie Basha/aplikacji publicznych.
M1031 – Network Intrusion Prevention: sygnatury na brzegach/WAF/IPS dla typowych wzorców Shellshock.
M1030 – Network Segmentation: separacja DMZ i serwerów publicznych.
M1040 – Behavior Prevention on Endpoint: blokowanie podejrzanych łańcuchów procesów (WWW→bash).
M1016 – Vulnerability Scanning: regularne skany z szybkim SLA na krytyczne ujawnienia.

Powiązane techniki:

T1059.004 – Unix Shell (wykonanie komend po RCE).
T1505.003 – Web Shell (utrwalenie po pierwszym włamaniu).
T1105 – Ingress Tool Transfer (dociągnięcie narzędzi po uzyskaniu RCE).
T1190 – Exploit Public‑Facing Application (wektor wejścia).

Źródła / dalsza literatura

NVD: opis, CVSS 9.8/10.0 i wektory (Apache CGI, ForceCommand, DHCP). (NVD)
CVE.org: rekord CVE‑2014‑6271. (CVE)
Red Hat: strona podatności Shellshock (jak działa, zalecenia). (Red Hat Customer Portal)
CERT/CC VU#252743: nota o wykonaniu komend przez eksport funkcji. (kb.cert.org)
CISA/US‑CERT: alerty o rodzinie błędów Bash (CVE‑2014‑7169 i pokrewne). (CISA)
MITRE ATT&CK: T1190 (Initial Access) i T1059.004 (Unix Shell). (MITRE ATT&CK)
Przykłady „in‑the‑wild”: Wired (botnety), Cisco Talos, Akamai. (WIRED)
IMDS (AWS/Azure): dokumentacja i wskazówki detekcyjne. (AWS Documentation)

Checklisty dla SOC / CISO

SOC (operacyjne):

WAF/IPS: aktywne sygnatury na wzorce Shellshock (w tym URL‑encoded).
Reguły SIEM: HTTP wzorce + łańcuch WWW → bash + próby IMDS + CloudTrail sekwencje z roli instancji.
Hunting: poszukaj procesów bash z rodzicem httpd/apache2/nginx w całej flocie.
Telemetria: włącz auditd/EDR na hostach Linux oraz pełne access/error logs.
Kwarantanna + rotacja kluczy po wykryciu nadużyć API.

CISO (strategiczne):

Polityka patch management dla komponentów publicznych (SLA dla krytycznych CVE).
Segmentacja DMZ i minimalne uprawnienia kont serwisowych.
IMDSv2 tylko + kontrola egress do 169.254.169.254 z usług WWW.
Testy podatności i testy regresji detekcji (syntetyczne dane, bez exploitów).
Przeglądy architektury: unikać CGI/Bash w ścieżkach request‑handling.