Archiwa: Firewall - Strona 18 z 24

CVE-2025-64446: krytyczna podatność 0-day w Fortinet FortiWeb (path traversal) aktywnie wykorzystywana

W skrócie

Co: Path traversal prowadzący do zdalnego wykonania poleceń z uprawnieniami administracyjnymi na FortiWeb.
Kto: Atakujący bez uwierzytelnienia (z Internetu).
Status: 0-day – wykorzystywany zanim opublikowano advisory; obecnie dostępne poprawki. Wpis w CISA KEV.
Wpływ: Pełne przejęcie WAF-a, tworzenie kont admina, modyfikacja polityk, pivot w głąb sieci.
Co robić teraz: Natychmiastowy upgrade do wersji naprawionych, ograniczenie ekspozycji HTTP/HTTPS, monitoring logów, polowanie na ślady nadużyć.

Kontekst / historia / powiązania

Pierwsze sygnały o nieznanym exploicie na urządzenia Fortinet pojawiły się na początku października. 13–14 listopada niezależni badacze (m.in. watchTowr) zreprodukowali błąd i opublikowali wstępne ustalenia, po czym Fortinet wydał PSIRT FG-IR-25-910 oraz przypisał CVE-2025-64446. W tym samym czasie liczne firmy (Tenable, Rapid7, Arctic Wolf) ostrzegły o aktywnej eksploatacji; CISA dodała lukę do KEV.

Analiza techniczna / szczegóły luki

Wektor ataku. Błąd to relative path traversal w interfejsie HTTP/HTTPS FortiWeb, który umożliwia napastnikowi odwołanie się do niezamierzonych ścieżek i zasobów aplikacji/OS. Skutkiem jest ominięcie kontroli i możliwość wykonywania komend administracyjnych lub wywoływania wrażliwych funkcji. W praktyce to RCE/privilege abuse osiągalne bez logowania.

Wersje podatne / naprawione (Fortinet PSIRT):

Podatne: 7.0.0–7.0.11, 7.2.0–7.2.11, 7.4.0–7.4.9, 7.6.0–7.6.4, 8.0.0–8.0.1
Naprawione: 7.0.12+, 7.2.12+, 7.4.10+, 7.6.5+, 8.0.2+
Fortinet zaleca także ograniczenie dostępu do interfejsu zarządzania HTTP/HTTPS wyłącznie do sieci wewnętrznej (nie wystawiać publicznie).

Starsze gałęzie (ustalenia badaczy). WatchTowr wskazuje, że 6.4 ≤ 6.4.3 oraz 6.3 ≤ 6.3.23 również wykazują podatność w podobnym łańcuchu błędów – co jest ważne dla środowisk, gdzie utrzymuje się EoL-owe wydania. (Traktuj jako dane badawcze; weryfikuj z PSIRT).

Ocena ryzyka (CVSS). NVD klasyfikuje lukę jako krytyczną: niski nakład atakującego, brak interakcji użytkownika, pełne naruszenie C/I/A.

Praktyczne konsekwencje / ryzyko

Przejęcie FortiWeb – tworzenie/zmiana kont admina, zmiana polityk WAF (np. wyłączenie ochrony dla krytycznych aplikacji).
Lateral movement – FortiWeb często „widzi” ruch do aplikacji biznesowych; kompromitacja może dać dane uwierzytelniające i ścieżki pivotu.
Sabotaż bezpieczeństwa aplikacji – atakujący może tolerować własny ruch (np. wstrzyknięcia SQL, SSRF) przez manipulację regułami WAF.
Utrata poufności i integralności logów – możliwość wyciszenia alertów/telemetrii.
Ataki łańcuchowe – po FortiWeb możliwe ataki na CI/CD, ERP, bankowość internetową itp., które WAF chroni.

Rekomendacje operacyjne / co zrobić teraz

1) Patching – priorytet awaryjny

Zaktualizuj FortiWeb co najmniej do: 8.0.2 / 7.6.5 / 7.4.10 / 7.2.12 / 7.0.12. Zaplanuj restart/okno serwisowe i weryfikuj wersję po aktualizacji.
CLI (na FortiWeb): # sprawdzenie wersji execute version get system status # (jeśli używasz HA) sprawdź stan klastra diagnose system ha status

2) Ograniczenie ekspozycji zarządzania

Nie wystawiaj HTTP/HTTPS management na Internet. Ogranicz do mgmt-VLAN/VPN (ACL/Firewall policy). Jeżeli musisz, użyj source IP allowlist i MFA w bastionie.

3) Szybka kontrola narażenia (bezpieczna)

Z zewnątrz: zweryfikuj, czy porty mgmt nie są dostępne: nmap -p 80,443,8443 <adres_FortiWeb> --script http-enum,http-title
Z urządzenia: upewnij się, że admin-scp, telnet, http są wyłączone na interfejsach publicznych.

4) Detekcja i polowanie na oznaki nadużyć

Logi FortiWeb (przykładowe wzorce):

Nietypowe żądania z „../” w ścieżce lub parametrach (path traversal).
Niespodziewane logowania admin z rzadkich AS/GeoIP.
Zmiany polityk/konfiguracji poza oknami serwisowymi.

Splunk (HTTP logs z FortiWeb/syslog):

index=network OR index=forti sourcetype=fortiweb:http
| rex field=uri_path "(?<dotdots>\.\.\/)"
| stats count by src_ip, http_method, uri_path, user, _time
| where dotdots!=""

Sigma (pseudoreg. do konwersji):

title: FortiWeb Suspicious Path Traversal
logsource:
  product: fortinet
  service: fortiweb
detection:
  selection:
    c-uri|contains: "../"
  condition: selection
level: high

Wskazówka: sprawdź tworzenie nowych kont admin w krótkim okresie po nieudanych/niestandardowych żądaniach HTTP. (Kilka raportów wskazuje, że atakujący potrafią tworzyć konta administracyjne po udanym nadużyciu.)

5) Twardnienie (hardening)

Wymuś TLS-only na mgmt i certificate pinning po stronie operatorów gdzie to możliwe.
Ogranicz dostęp do /api/ i endpointów administracyjnych wyłącznie z sieci zaufanych.
Włącz alerting na zdarzenia systemowe: tworzenie kont, zmiana polityk, restart usług, import konfiguracji.
W SIEM dodaj rule chain: „żądania z ../” → „event admin create/modify” → „policy change”.

6) Testy bezpieczeństwa (bez PoC exploita)

Skany zależności/wersji i porównanie z matrycą podatnych/nienarażonych.
Wykorzystaj skanery, które już dodały detekcję (np. wtyczki Tenable; sprawdzaj aktualizacje feedów).

Uwaga operacyjna: Z uwagi na aktywne kampanie i publiczne exploity, tempo skanów i prób nadużyć prawdopodobnie wzrośnie. Wprowadź czasowe reguły rate-limit/geo-block na IP spoza twojej strefy działalności.

Różnice / porównania z innymi przypadkami Fortinet

W porównaniu z wcześniejszymi głośnymi błędami (np. CVE-2024-21762 w SSL-VPN czy CVE-2022-40684 bypass autoryzacji) – tutaj wektor to GUI/API FortiWeb, a nie VPN. Jednak skutek jest równie krytyczny: niezalogowany napastnik może osiągnąć admin RCE.
Podobnie jak w poprzednich incydentach, luka trafiła do CISA KEV, co jest silnym sygnałem wymogu szybkiej remediacji w sektorze publicznym i komercyjnym.

Podsumowanie / kluczowe wnioski

Krytyczna 0-day (CVSS 9.1) w FortiWeb, aktywnie nadużywana – działaj natychmiast.
Zaktualizuj do 8.0.2 / 7.6.5 / 7.4.10 / 7.2.12 / 7.0.12; nie wystawiaj GUI na Internet.
Monitoruj logi pod kątem path traversal i nieoczekiwanych zmian administracyjnych; rozważ polowanie na artefakty po 13–14 listopada.
Zweryfikuj starsze gałęzie (6.3/6.4) – w części środowisk mogą być podatne wg badań; zaplanuj upgrade ścieżki życia.

Źródła / bibliografia

Fortinet PSIRT FG-IR-25-910 – „Path confusion vulnerability in GUI” (listy wersji naprawionych, zalecenia dot. ekspozycji HTTP/HTTPS). (fortiguard.fortinet.com)
NVD: karta CVE-2025-64446 (opis, wektor CVSS, wpływ). (NVD)
watchTowr Labs: techniczne wnioski i zakres wersji w starszych gałęziach; łańcuch prowadzący do nadużyć admin. (watchTowr Labs)
Tenable: przegląd incydentu, ostrzeżenie o aktywnej eksploatacji, odniesienia do wtyczek skanujących. (Tenable®)
CISA KEV: potwierdzenie statusu „known exploited”. (CISA)

OWASP Top 10 2025 – Kluczowe Zagrożenia I Porady Bezpieczeństwa

OWASP Top 10 w praktyce: krótki kontekst zanim przejdziemy dalej

OWASP Top 10 to globalny standard opisujący 10 najpoważniejszych ryzyk bezpieczeństwa aplikacji webowych. Najnowsza edycja – OWASP Top 10 2025 – została właśnie opublikowana (po raz ósmy, poprzednio w 2021 roku) i przynosi ważne zmiany. Dla studentów i początkujących specjalistów cyberbezpieczeństwa znajomość tej listy jest kluczowa.

Czytaj dalej

„IndonesianFoods”: dziesiątki tysięcy złośliwych paczek na npm z samoreplikującym się „robakiem” (Big Red)

Wprowadzenie do problemu / definicja zjawiska

Badacze bezpieczeństwa odkryli szeroko zakrojoną kampanię spamowo-szkodliwą w ekosystemie npm, w której opublikowano dziesiątki tysięcy paczek zawierających samoreplikujący się kod („robaka”), masowo generujący i publikujący nowe, losowo nazwane pakiety. Incydent jest przypisywany operatorowi posługującemu się językiem indonezyjskim i bywa określany jako „IndonesianFoods” lub „Big Red”. Celem nie jest klasyczne wykradanie sekretów, lecz zalew rejestru tysiącami artefaktów i nadużycie infrastruktury (w tym możliwa monetyzacja przez ekosystem tea.xyz).

W skrócie

Skala: od ~44–80 tys. i więcej złośliwych paczek, wykrytych na dziesiątkach kont npm. Nazwy generowane z list słów (przymiotniki/zwierzęta/kolory) oraz słowników z indonezyjskimi imionami i potrawami.
Mechanizm: prosty skrypt (Node.js) modyfikuje package.json/package-lock.json, usuwa private: true, nadaje losową wersję i publikuje kolejne paczki w pętli (co kilka sekund).
Wektory nadużycia: ponowne użycie zapisanych poświadczeń npm ofiary; możliwy cel: nagrody/„reputacja” w tea.xyz, SEO/pozycjonowanie lub „próba generalna” przed realnym ładunkiem.
Ryzyko: zanieczyszczenie wyników wyszukiwania, wzrost prawdopodobieństwa przypadkowej instalacji i zatrucie łańcucha dostaw (w CI/CD).

Kontekst / historia / powiązania

Kampania trwa co najmniej od 2023/2024 r., ewoluując od zwykłego spamu do robakopodobnej automatyzacji w 2025 r. (auto-publikacja i szybkie replikowanie). Część obserwacji wiąże aktywność z mechanizmami punktacji/nagród tea.xyz, co tłumaczy presję na masę i widoczność. Niezależne raporty (SecurityWeek, SourceCodeRed, JFrog) różnią się liczbami (43–80 tys.+), ale są spójne co do automatycznej pętli publikacji i słowników nazw. Dodatkowe doniesienia prasowe wskazują na 67–100 tys. paczek w miarę trwania sprzątania i nowej publikacji.

Analiza techniczna / szczegóły

1) Generowanie metadanych i nazwy

Warianty wykorzystują m.in. bibliotekę unique-names-generator oraz własne słowniki (imiona/potrawy/adjektywy/zwierzęta/kolory), np. annoyed_raccoon_z3n albo indah-ketoprak73-riris.

2) „Odblokowanie” publikacji

Skrypt usuwa pole private: true z package.json, aby erzac-projekt Next.js stał się publicznie publikowalny: let packageData = JSON.parse(fs.readFileSync("package.json")); if (packageData.private === true) { delete packageData.private; } // wersja i nazwa nadawane losowo… exec("npm publish --access public", cb); (fragmenty logiczne opisane w analizie JFrog).

3) Samoreplikacja i tempo

Po publikacji skrypt czeka losowy krótki czas i uruchamia cykl od nowa. W praktyce nowe paczki pojawiają się co ~7 sekund, aż do limitów lub błędów 429 (rate-limit).

4) Poświadczenia npm

Pętla używa zapisanych tokenów/npmrc użytkownika (prawdopodobnie na zainfekowanej maszynie) do publikacji pod jego kontem. To nie jest „kradzież sekretów na zewnątrz”, tylko nadużycie już obecnych uprawnień.

5) IoC i artefakty

JFrog publikuje sumy SHA-256 plików autopublikujących i listę obserwowanych kont npm; pojawiają się też adresy powiązane z tea.xyz w plikach konfiguracyjnych (tea.yaml). Warto wzbogacić skanery o te artefakty.

Praktyczne konsekwencje / ryzyko

Zatrucie łańcucha dostaw (SDLC/CI/CD): łatwiej o pomyłkową instalację paczki „o normalnym wyglądzie”, szczególnie przy luźnych constraintach wersji (^, ~) i braku blokad wersji.
Noise & discovery risk: zespoły SCA/SAST/DevSecOps dostają tysiące „śmieciowych” trafień, co utrudnia triage i może ukryć prawdziwe ataki.
Eskalacja scenariusza: ta sama infrastruktura może być „przełączona” na realny ładunek (np. infostealer, crypto-theft), a nie jedynie spam—JFrog wskazuje taki wariant jako prawdopodobny „dry run”.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań do wdrożenia od razu, od punktów krytycznych po „twardnienie” procesu.

A. Reagowanie i hunting

Zablokuj i odśwież tokeny npm (szczególnie na maszynach buildowych):

# pokaż aktualne tokeny
npm token list
# unieważnij podejrzany token (wstaw ID)
npm token revoke <token-id>
# wymuś 2FA dla publikacji
npm profile enable-2fa auth-and-writes

Przegląd ostatnich publikacji pod Twoją nazwą/npm org (czy „ktoś” nie publikował śmieci w Twoim imieniu):

# szybki podgląd zmian w Twojej organizacji przez API npm
curl -s "https://registry.npmjs.org/-/org/<twoja-org>/package?format=json" | jq '.'

Skanuj lockfile i node_modules pod wzorce nazw ze słowników (adjectives/animals/colors, indonezyjskie imiona/potrawy) i znane IoC (hash’e z raportu JFrog). Przykładowy skrypt huntujący w repo:

# szukaj podejrzanych nazw w package-lock.json / pnpm-lock.yaml / yarn.lock
grep -E -i "(rendang|ketoprak|sambel|nasi|goreng|_z3n|meadowlark|raccoon)" \
  package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

# weryfikuj SHA plików autopublikujących, jeśli występują
shasum -a 256 **/auto.js **/publishScript.js **/index.js 2>/dev/null

(doposaż bazę IoC o hash’e i konta z raportu JFrog).

Wymuś „allow-listy” w prywatnym mirrorze/proxy rejestru (Artifactory/Nexus/JFrog/Frog Curation, Sonatype Firewall): odrzuć publikacje z nowych, niesprawdzonych kont i paczki pasujące do wzorców nazw. (JFrog deklaruje, że dodał te paczki do katalogu złośliwych).

B. Higiena zależności i buildów

Twarde pinowanie wersji + blokady (package-lock.json, pnpm-lock.yaml, yarn.lock) oraz „frozen-lockfile” w CI: npm ci --ignore-scripts # lub pnpm install --frozen-lockfile yarn install --frozen-lockfile
Wyłącz npm install ze „skryptami” (--ignore-scripts) w środowiskach build/test, jeżeli to możliwe.
Provenance i podpisy: egzekwuj npm provenance/Sigstore, SBOM (CycloneDX/SPDX) oraz polityki „only-allow”: npx only-allow pnpm # przykład wymuszenia jednego menedżera
Segmentacja uprawnień: tokeny npm z zakresem tylko do odczytu w CI; publikacja z osobnych, minimalnych runnerów; tajemnice w dedykowanych OIDC+STS zamiast statycznych tokenów.
Alerting na anomalie publikacji: jeśli Twój zespół publikuje biblioteki na npm—dodaj reguły UEBA: „więcej niż N publikacji w 1h”, „nowa paczka z nieznanej przestrzeni nazw”, „nieznany maintainer”.

C. Blokada znanych kont/nazw

W firewallu rejestru/SCA skonfiguruj deny-listę kont i prefiksów nazw z raportów (np. veylatea, użytkownicy z list JFrog/SourceCodeRed), oraz reguły detekcji tea.yaml/*_publish*.js.

Różnice / porównania z innymi przypadkami (wrzesień 2025: „Shai-Hulud”)

Cel i ładunek:
- IndonesianFoods/Big Red – głównie spam i samoreplikacja; brak bezpośredniego exfiltracji sekretów w payloadzie.
- Shai-Hulud (IX–X 2025) – kradzież sekretów/poświadczeń, trojanizacja istniejących popularnych paczek (np. @ctrl/tinycolor), masowe modyfikacje package.json, wstrzykiwanie skryptów, re-publikacja pod kompromitowanymi maintainerami.
Wejście do ekosystemu:
- IndonesianFoods – tworzenie nowych tysięcy paczek-wydmuszek.
- Shai-Hulud – przejęcie istniejących paczek o dużym zasięgu.
Ryzyko krótkoterminowe:
- IndonesianFoods – ryzyko przypadkowej instalacji i zanieczyszczenia supply chain.
- Shai-Hulud – natychmiastowe ryzyko wycieku sekretów i eskalacji w CI/CD.

Podsumowanie / kluczowe wnioski

Mamy do czynienia z przemysłową automatyzacją produkcji paczek npm: prosta logika, ale duża skala i ciągła replikacja.
Nawet jeśli obecny ładunek w „IndonesianFoods/Big Red” nie kradnie danych, ten sam pipeline może w dowolnym momencie przerzucić się na realne malware.
Obrona to kombinacja: twarde pinowanie + „frozen” instalacje + ignore-scripts w CI, podpisy/provenance, allow-listy/deny-listy w repozytoriach pośredniczących, segmentacja tokenów i monitoring anomalii publikacji.

Źródła / bibliografia

SecurityWeek — „Tens of Thousands of Malicious NPM Packages Distribute Self-Replicating Worm” (13 listopada 2025). (SecurityWeek)
JFrog Security Research — „Big Red – Indonesian-based Self-replicating Malicious Spam Campaign detected in npm” (11 listopada 2025) — analiza techniczna, IoC. (research.jfrog.com)
SourceCodeRed — „‘IndonesianFoods’ worm publishes more than 78,000 malicious NPM packages” — pierwsze odkrycia, tempo publikacji, słowniki nazw. (sourcecodered.com)
BleepingComputer — „New ‘IndonesianFoods’ worm floods npm with 100,000 packages” — tło czasowe 2023–2025 i wątek TEA. (BleepingComputer)
CISA / Sysdig — materiały porównawcze nt. kampanii „Shai-Hulud” (wrzesień 2025) — inny typ celu (exfiltracja sekretów). (CISA)

SOC Alert Triage

Od hałasu do sygnału – logika triage w SOC

Wyobraź sobie, że jako analityk SOC L1 patrzysz na ekran zalewu alertów: dziesiątki sygnalizacji typu „Email oznaczony jako phishing”, kilka „Podejrzana lokalizacja logowania VPN” i jedno groźnie brzmiące „Wykryto Mimikatz na hoście”. Co teraz? Którym alertem zajmiesz się najpierw i dlaczego? Taka scena to codzienność w Security Operations Center. Tutaj do gry wchodzi triage alertów – proces decydujący o tym, czy potencjalny atak zostanie szybko zauważony, czy zginie w tłumie false positive.

Czytaj dalej

SAP łata krytyczne luki w SQL Anywhere Monitor i Solution Manager (listopad 2025)

Wprowadzenie do problemu / definicja luki

11 listopada 2025 r. SAP opublikował pakiet poprawek bezpieczeństwa obejmujący 18 nowych i aktualizacje wcześniejszych not bezpieczeństwa. Wśród nich znalazły się co najmniej dwie luki o krytycznej wadze: maksymalnie poważna słabość w SQL Anywhere Monitor (Non-GUI) oraz bardzo poważna podatność w SAP Solution Manager umożliwiająca wstrzyknięcie kodu. Informacje te potwierdzają komunikaty SAP oraz niezależne serwisy branżowe.

W skrócie

SQL Anywhere Monitor (Non-GUI): luka z kategorią HotNews (CVSS 10.0), związana z twardo zakodowanymi poświadczeniami i zarządzaniem kluczami/sekretami. Skutkiem może być zdalne wykonanie kodu (RCE) bez uwierzytelnienia.
SAP Solution Manager: podatność CVE-2025-42887 (CVSS 9.9). Brak sanityzacji danych wejściowych w zdalnie wywoływanym module funkcji (RFC) pozwala uwierzytelnionemu atakującemu wstrzyknąć kod i przejąć pełną kontrolę nad systemem.
SAP zachęca do pilnego wdrożenia not bezpieczeństwa z listopadowego Patch Day.

Kontekst / historia / powiązania

Ekosystem SAP regularnie otrzymuje poprawki w comiesięcznym cyklu „Security Patch Day”. Listopadowe wydanie wpisuje się w trend z 2025 r., w którym kilkukrotnie łatano luki o ocenie 9.8–10.0 w NetWeaver/AS Java i komponentach towarzyszących. Dodatkowe omówienia od partnerów (Onapsis, SecurityBridge) wskazują, że bieżący zestaw obejmuje trzy krytyczne problemy (dwie „dziesiątki” i jedną „9.9”), w tym SQL Anywhere Monitor oraz Solution Manager.

Analiza techniczna / szczegóły luk

1) SQL Anywhere Monitor (Non-GUI) — „hardcoded credentials” / zarządzanie sekretami

Opis: w obrazie/usłudze monitora wykryto twardo zakodowane poświadczenia (np. konto serwisowe / klucz), co umożliwia nieautoryzowany dostęp do zasobów monitora, a w konsekwencji zdalne wykonanie kodu na hostach, które monitor obsługuje lub na samym komponencie.
Klasyfikacja: HotNews, CVSS 10.0. Noty SAP identyfikują obszar jako BC-SYB-SQA-ADM (SQL Anywhere Monitor).
Wektory ataku: zdalne, sieciowe, bez interakcji użytkownika; brak uwierzytelnienia po stronie atakującego (w przypadku wykorzystania ujawnionych stałych sekretów).
Skutki: RCE, eskalacja uprawnień, przejęcie monitoringu oraz lateral movement do serwerów baz danych/instancji, które Monitor nadzoruje.

2) SAP Solution Manager — CVE-2025-42887 (code injection przez RFC)

Opis: brak sanityzacji danych wejściowych w zdalnie wywoływanym module funkcji (Remote-Enabled Function Module, RFC/FM) umożliwia wstrzyknięcie kodu przez uwierzytelnionego użytkownika (niski poziom uprzywilejowania). NVD klasyfikuje podatność jako CWE-94 (Improper Control of Code Generation), z metryką AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
Skutki: pełne przejęcie systemu Solution Manager (konf., integralność i dostępność na poziomie „High”). Istotny jest fakt, że SolMan często integruje się z wieloma systemami satelitarnymi (landscape), co multiplikuje ryzyko łańcuchowe.
Doniesienia prasowe podkreślają wagę CVE-2025-42887 i wskazują ocenę 9.9.

Praktyczne konsekwencje / ryzyko

RCE i przejęcie środowiska: w przypadku SQL Anywhere Monitor atakujący może uzyskać natychmiastowy dostęp systemowy oraz pivotować do baz danych i serwerów aplikacyjnych SAP.
Atak wewnątrz-organiczny/„low-priv”: CVE-2025-42887 wymaga autoryzacji, ale w dużych krajobrazach SAP niski poziom uprawnień użytkownika technicznego bywa powszechny. To otwiera drogę do abuse of RFC, z możliwością skryptowania wywołań FM i eskalacji na SolMan.
Łańcuch dostaw IT/OT: SolMan jako „central brain” ALM dotyka transportów, jobów, interfejsów — kompromitacja przenosi się na krajobraz produkcyjny.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania (0–24 h)

Zidentyfikuj ekspozycję:
- Odszukaj instancje SQL Anywhere Monitor (Non-GUI) i sprawdź, czy są osiągalne z sieci korporacyjnej/Internetu. W skanerze/CMDB szukaj nazw usług/procesów zawierających sqlanywhere / dbmon / monitor. (Wiele wdrożeń publikuje porty admin/HTTP monitora.) Źródło o krytyczności i RCE:
- W Solution Manager przejrzyj listę RFC-destinations (SM59) oraz logi Security Audit Log i dev_rfc* pod kątem anomalii wywołań modułów FM.
Wdróż noty SAP (Patch Day XI-2025):
- Zastosuj odpowiednie SAP Security Notes z 11.11.2025 r. (SNOTE/transporty/SUM zależnie od komponentu). Informację o wydaniu i priorytetach potwierdza SAP.
- Dla SQL Anywhere Monitor zastosuj notę HotNews (identyfikowaną przez partnerów jako Note 3666261 dot. CVE-2025-42890). Wdrożenie usuwa podatny komponent/sekrety lub wymusza ich bezpieczne zarządzanie.
Segmentacja i ograniczenie dostępu:
- Tymczasowo ogranicz do zaufanych zarządców/VPN dostęp sieciowy do monitora i interfejsów SolMan (firewall, NAC, ZTNA).

2) Krótkoterminowo (1–7 dni)

Rotacja sekretów/kont serwisowych używanych przez monitor i powiązane bazy/usługi. (Hardcoded credentials -> ryzyko wtórnego użycia).
Hardening RFC w SolMan:
- Przegląd uprawnień technicznych użytkowników RFC (SU01/PFCG).
- Wymuś whitelisting zdalnych FM: ogranicz do niezbędnych, monitoruj wywołania z SM59 i ST03N. Podstawa: charakter podatności RFC/code-injection.
Detekcje w SIEM/IDS (przykładowe reguły):
- Wzorce nietypowych wywołań RFC z nowymi parametrami/ładunkami (korelacja z logami SAProuter/Gateway).
- Alerty na niespodziewane połączenia wychodzące z hosta monitora (pivot).
Testy regresyjne po patchowaniu: monitorowanie stabilności krajobrazu ALM.

3) Średnioterminowo (do 30 dni)

Przegląd ekspozycji SAP do Internetu (AS Java, NetWeaver, SolMan, monitory, integracje).
SBOM & secret management: wdrożenie skanów sekretów i cyklu rotacji (np. HashiCorp Vault/Azure Key Vault), weryfikacja kontenerów/obrazów pod kątem wstrzykniętych kluczy.
Ćwiczenia IR specyficzne dla SAP: scenariusz „kompromitacja SolMan/monitoring”.

Przykładowe komendy/akcje operacyjne (dla zespołów)

Zgromadzenie listy RFC-destinations (raport w SAP GUI):
- Transakcja SM59 → Utilities → Display/Compare → Eksport do CSV → korelacja w SIEM.
Szybki skan z zewnątrz (na własnej infrastrukturze): # przykładowy Nmap na znanych portach admin/HTTP monitora (dostosuj do swojej sieci!) nmap -sV -p 80,443,8080,8090,50013,50014 <zakres_IP> --open -oA sap-sqlanywhere-monitor
Poszukiwanie artefaktów w logach RFC (host aplikacyjny): # przykładowo na serwerze z plikami trace SAP (ścieżki dostosuj) grep -iE "CALL_FUNCTION|RFC|REMOTE.*FUNCTION" /usr/sap/<SID>/DVEBMGS*/work/dev_rfc*

Różnice / porównania z innymi przypadkami

Insecure deserialization (AS Java, CVE-2025-42944, CVSS 10.0) z października/listopada 2025 dotyczył kanału RMI-P4 w AS Java (zdalne RCE) — inny komponent i inna klasa błędu niż omawiane tu hardcoded credentials oraz RFC code injection. Wciąż jednak wpisuje się w szerszy wzorzec krytycznych błędów SAP w 2025 r., wymagających szybkiego patchowania.
Wcześniejsze „n-daye” w 2025 pokazały, że opóźnienia w aktualizacjach prowadzą do realnych kompromitacji (kampanie nadużywające luk NetWeaver). Wniosek: nawet „tylko” SolMan/RFC czy monitor mogą stać się wektorem pierwotnym. (Kontekst trendu i ostrzeżenia branżowe).

Podsumowanie / kluczowe wnioski

Patch now: SQL Anywhere Monitor (Non-GUI) – HotNews (CVSS 10.0) oraz CVE-2025-42887 w Solution Manager (CVSS 9.9) to luki wysokiego ryzyka. Wdrożenie not SAP z 11.11.2025 r. powinno być priorytetem.
Zabezpiecz sekrety i RFC: usuń stałe poświadczenia, rotuj konta serwisowe; w SolMan ogranicz i monitoruj wywołania RFC.
Monitoruj oznaki RCE/pivotu: nietypowe połączenia z hostów monitorujących, anomalia w logach RFC/Gateway.
Ucz się z 2025: krytyczne luki SAP pojawiają się regularnie — potrzebny jest stały cykl: asset inventory → szybkie patchowanie → detekcje nadużyć → ćwiczenia IR.

Źródła / bibliografia

SAP Support Portal – Security Patch Day (listopad 2025): liczba not, zalecenia wdrożenia. (SAP Support Portal)
SecurityWeek – omówienie luk (hardcoded credentials/RCE w SQL Anywhere Monitor; krytyczność pakietu). (SecurityWeek)
NVD – karta CVE-2025-42887 (Solution Manager, code injection przez RFC; metryka CVSS/CWE). (NVD)
Onapsis – przegląd listopadowych not SAP, kontekst i akcent na SQL Anywhere Monitor + SolMan. (Onapsis)
SecurityBridge – zestawienie not z numerami (m.in. Note 3666261 / CVE-2025-42890, SQL Anywhere Monitor – HotNews 10.0). (SecurityBridge)

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.

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)