Tag: Windows

TL;DR

• CVE-2025-61884 dotyczy Oracle E-Business Suite (EBS) → Oracle Configurator → komponent Runtime UI w wersjach 12.2.3–12.2.14 i jest zdalnie wykorzystywalna bez uwierzytelnienia przez HTTP/HTTPS.
• Ocena producenta/NVD wskazuje na wysoki wpływ na poufność (CVSS 3.1: 7.5, C:H / I:N / A:N), czyli przede wszystkim nieautoryzowany dostęp/wyciek danych.
• W praktyce jest opisywana jako pre-auth SSRF (nazwa w KEV/NVD oraz alerty branżowe/instytucjonalne), a publiczne raporty łączą ją z aktywnym wykorzystywaniem i publicznie dostępnym PoC.
• W ATT&CK najlepiej mapuje się do T1190 – Exploit Public-Facing Application (Initial Access); MITRE wskazuje m.in. WAF, filtrowanie ruchu i patching jako kluczowe mitygacje.

Krótka definicja techniczna (1 akapit)

CVE-2025-61884 to podatność w publicznie wystawionym komponencie webowym (Oracle Configurator Runtime UI), która umożliwia niezalogowanemu atakującemu doprowadzenie aplikacji do zachowań niezamierzonych (w raportach klasyfikowanych jako SSRF) i w konsekwencji uzyskanie dostępu do wrażliwych zasobów/danych; w ATT&CK odpowiada temu T1190 (Initial Access) – wejście przez podatną aplikację dostęp­ną z Internetu.

Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)

• Windows: rzadziej jako host EBS, ale jeśli front (proxy/WAF) lub komponenty pośrednie są na Windows — interesują logi IIS/reverse proxy oraz EDR na hoście aplikacji. (Rdzeń CVE jest jednak w komponencie EBS/Configurator).
• AD: pośrednio — EBS bywa spięty z AD/SSO. Skutkiem może być ekspozycja danych i późniejsza eskalacja (np. kradzież konfiguracji, identyfikatorów, mapowań).
• AWS: częsty scenariusz: EBS na EC2 + ALB/WAF + CloudWatch Logs. W kontekście SSRF szczególnie ważne: egress z serwera i ochrona przed dostępem do metadata endpoint (169.254.169.254).
• Azure: analogicznie (App Gateway WAF / Front Door + Log Analytics). SSRF → ryzyko dostępu do metadanych instancji i tokenów, jeśli egress nie jest ograniczony.
• GCP: podobny model (LB/WAF, logi HTTP LB, kontrola egress).
• K8s: rzadziej dla EBS, ale jeśli komponent jest „opakowany” lub stoi za ingress — logi ingress + korelacja z egress kontenera.
• ESXi: nie dotyczy bezpośrednio CVE, ale MITRE wskazuje T1190 także dla infrastruktury (gdy aplikacje/zarządzanie są wystawione).
• M365: brak bezpośredniego wektora; może być użyte w łańcuchu (np. dalsza eksfiltracja).

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

Kontekst CVE-2025-61884 w łańcuchu Initial Access

W przypadku Oracle EBS/Configurator Runtime UI, atakujący nie potrzebuje konta — wystarczy dostęp sieciowy do HTTP/HTTPS i podatnej wersji. To jest „książkowy” wariant T1190, bo aplikacja publicznie wystawiona staje się bramą do danych/zasobów.

Co realnie daje podatność

• Oficjalny opis (Oracle/NVD) wskazuje na dostęp do „sensitive resources” oraz nieautoryzowany dostęp do krytycznych danych w ramach tego, co Oracle Configurator udostępnia.
• W metadanych NVD/KEV podatność nazywana jest SSRF, a CISA-ADP przypisało m.in. CWE-918 (SSRF) oraz inne CWE, co sugeruje albo wieloprzymitywowy błąd, albo różne interpretacje łańcucha (ważne: Oracle zwykle nie publikuje pełnych detali technicznych).
• Publiczne raporty wskazują, że poprawka wiązała się m.in. z walidacją parametru typu return_url, co jest typowym miejscem dla nadużyć SSRF/redirect/CRLF — dla SOC to cenna wskazówka do polowania w logach.

Dlaczego to jest skuteczne (z perspektywy atakującego)

• Pre-auth (brak loginu) + niska złożoność (AC:L) = bardzo szybkie skanowanie Internetu i automatyzacja.
• „Systemy biznesowe” (EBS) często zawierają dane finansowe/HR/procesowe, więc nawet „tylko” poufność (C:H) ma wysoki wpływ operacyjny.
• MITRE rekomenduje podejście multi-signal (żądanie → błędy → proces/egress), bo same żądania HTTP nie zawsze wystarczą do pewnego potwierdzenia skutecznej eksploatacji.

Artefakty i logi

Detekcja (praktyczne reguły)

Poniższe przykłady celują w telemetrię HTTP/WAF i klasyczne sygnały SSRF/probing. Wg publicznych raportów aktywność obejmowała m.in. endpointy UiServlet/SyncServlet oraz parametry redirekt/URL.

Sigma (gotowa reguła)

Dopasuj mapowanie pól do Twojego parsera (ECS, Splunk CIM, IIS, Nginx itp.).

title: Oracle EBS Configurator Runtime UI - Suspicious SSRF / return_url Patterns (CVE-2025-61884)
id: 2a2c9c6d-6d2b-4b5a-9c86-5b2f7a3f3b7d
status: experimental
description: |
  Detects suspicious requests to Oracle E-Business Suite (Oracle Configurator Runtime UI) endpoints
  with URL/redirect parameters suggestive of SSRF/probing related to CVE-2025-61884.
author: Badacz CVE
date: 2025/12/23
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_endpoint:
    url.path|contains:
      - "/configurator/UiServlet"
      - "/OA_HTML/configurator/UiServlet"
      - "/OA_HTML/SyncServlet"
  selection_param:
    url.query|contains:
      - "return_url="
  selection_ssrf_indicators:
    url.query|contains:
      - "http://"
      - "https://"
      - "file://"
      - "gopher://"
      - "ftp://"
      - "169.254.169.254"
      - "127.0.0.1"
      - "localhost"
      - "%0d%0a"
      - "%0D%0A"
  condition: selection_endpoint and selection_param and selection_ssrf_indicators
falsepositives:
  - Rare legitimate redirect flows using absolute URLs (tune by source IP ranges, auth/session cookies, user agents, rate)
level: high

Splunk (SPL)

(index=web OR index=waf OR index=proxy)
| eval path=coalesce(url_path, uri_path, cs_uri_stem, request_path)
| eval query=coalesce(url_query, uri_query, cs_uri_query, query_string)
| where like(path, "%/configurator/UiServlet%")
   OR like(path, "%/OA_HTML/configurator/UiServlet%")
   OR like(path, "%/OA_HTML/SyncServlet%")
| where isnotnull(query) AND match(lower(query), "return_url=")
| where match(lower(query), "(http://|https://|file://|gopher://|ftp://|169\\.254\\.169\\.254|127\\.0\\.0\\.1|localhost|%0d%0a)")
| stats count as hits min(_time) as first_seen max(_time) as last_seen values(status) as status values(useragent) as ua by src_ip, host, path
| sort - hits

KQL (Azure / Microsoft Sentinel)

WAF / reverse proxy w Log Analytics (przykład ogólny):

let suspiciousPaths = dynamic([
  "/configurator/UiServlet",
  "/OA_HTML/configurator/UiServlet",
  "/OA_HTML/SyncServlet"
]);
AzureDiagnostics
| extend path = tostring(requestUri_s), query = tostring(queryString_s), clientIp = tostring(clientIP_s)
| where path has_any (suspiciousPaths)
| where query has "return_url="
| where query has_any ("http://","https://","file://","gopher://","ftp://","169.254.169.254","127.0.0.1","%0d%0a")
| summarize hits=count(), first_seen=min(TimeGenerated), last_seen=max(TimeGenerated),
            ua=makeset(userAgent_s, 5) by clientIp, path
| order by hits desc

CloudTrail query (AWS CLI/CloudWatch)

Dla tej klasy zdarzeń CloudTrail zwykle nie pomoże (to nie są API calls), ale sensowny jest CloudWatch Logs Insights na AWS WAF logs:

fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, action, terminatingRuleId
| filter httpRequest.uri like /\/configurator\/UiServlet|\/OA_HTML\/configurator\/UiServlet|\/OA_HTML\/SyncServlet/
| filter httpRequest.args like /return_url=/ 
| filter httpRequest.args like /http:\/\/|https:\/\/|169\.254\.169\.254|127\.0\.0\.1|localhost|%0d%0a/i
| stats count() as hits, min(@timestamp) as first_seen, max(@timestamp) as last_seen,
        values(action) as actions, values(terminatingRuleId) as rules
  by httpRequest.clientIp, httpRequest.uri
| sort hits desc

Elastic/EQL przykłady

Kibana KQL (logi HTTP/WAF w ECS):

url.path : ("/configurator/UiServlet" or "/OA_HTML/configurator/UiServlet" or "/OA_HTML/SyncServlet")
and url.query : ("return_url=" and ("http://" or "https://" or "file://" or "gopher://" or "ftp://" or "169.254.169.254" or "127.0.0.1" or "localhost" or "%0d%0a"))

EQL (korelacja inbound → outbound, jeśli masz EDR + network events):

sequence by host.id with maxspan=5m
  [network where network.direction == "inbound"
    and url.path in ("/configurator/UiServlet", "/OA_HTML/configurator/UiServlet", "/OA_HTML/SyncServlet")]
  [network where network.direction == "outbound"
    and destination.ip in ("169.254.169.254","127.0.0.1")]

Heurystyki / korelacje (co łączyć)

Korzystaj z podejścia „multi-signal correlation” (MITRE):

1. Sygnał 1 — inbound probing: nietypowe żądania do servletów Configurator/Sync, często z zewnętrznych adresów i bez kontekstu sesji.
2. Sygnał 2 — WAF / error spike: wzrost blokad WAF, 4xx/5xx w krótkim oknie czasu. (Cloudflare dodał nawet dedykowaną detekcję „Oracle EBS – SSRF – CVE-2025-61884”).
3. Sygnał 3 — egress anomalia: serwer EBS inicjuje połączenia do nietypowych hostów (wewnętrznych, link-local, metadata). To jest kluczowe przy SSRF.
4. Sygnał 4 — data exfil: duże odpowiedzi HTTP (bytes out) / długie czasy odpowiedzi dla endpointów Runtime UI, szczególnie bez typowego flow aplikacyjnego.
5. Sygnał 5 — kontekst zagrożenia: CVE zostało dodane do KEV (NVD pokazuje daty dodania i deadline), co zwiększa priorytet i uzasadnia hunting retrospektywny.

False positives / tuning

Typowe FP i jak je ograniczać:

• Legalne użycie redirectów: jeśli aplikacja używa parametru return_url do nawigacji — dopuszczalne, ale zwykle:
  • pochodzi z wewnętrznych adresów IP/VPN,
  • ma spójny user-agent,
  • występuje w obecności cookie/sesji.
    Tuning: ogranicz detekcję do źródeł spoza korporacyjnych CIDR, dodaj warunek braku sesji, dodaj próg częstotliwości (rate).
• Skanery podatności w organizacji: wpisz je na allowlistę (IP/UA), ale zachowaj osobny dashboard „security scanning activity”.
• WAF sygnatury: jeśli korzystasz z Cloudflare — śledź nową regułę dla CVE-2025-61884 jako sygnał, ale koreluj z ruchem „allowed”, bo część kampanii może próbować obejść WAF przez inne ścieżki (np. bez WAF lub przez inne punkty wejścia).

Playbook reagowania (kroki + komendy)

Natychmiastowe ograniczenie ryzyka (containment)

1. Odetnij Internet → Runtime UI / EBS (tymczasowo: allowlist VPN/bastion/WAF). MITRE wprost rekomenduje ograniczenie ekspozycji usług oraz segmentację/DMZ.
2. Włącz/zaostrz WAF (jeśli masz Cloudflare — zweryfikuj, czy działa reguła dla CVE-2025-61884).
3. Ogranicz egress z serwera EBS (SSRF „żyje” egress’em).

Przykład (Linux, defensywnie – blokada metadata; dopasuj do polityk):

sudo iptables -A OUTPUT -d 169.254.169.254 -j REJECT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j REJECT

Patching i weryfikacja

• Zastosuj Oracle Security Alert z 11 października 2025 (Rev 1); Oracle wskazuje, że wersje spoza wsparcia mogły nie być testowane, ale „prawdopodobnie” wcześniejsze też mogą być dotknięte → jeśli masz starsze EBS, traktuj to jak ryzyko wysokie i planuj upgrade.

Hunting (retrospektywnie 30–90 dni)

Szybkie grepy (ścieżki dopasuj do Oracle HTTP Server / reverse proxy):

# Szukanie podejrzanych endpointów
zgrep -RniE "(/configurator/UiServlet|/OA_HTML/SyncServlet|/OA_HTML/configurator/UiServlet)" /var/log/* 2>/dev/null

# Szukanie podejrzanych wskaźników SSRF/CRLF w query
zgrep -RniE "return_url=.*(http://|https://|169\.254\.169\.254|127\.0\.0\.1|%0d%0a)" /var/log/* 2>/dev/null

Jeśli podejrzewasz skuteczną kompromitację

• Traktuj to jak incydent o możliwym wpływie na dane: identyfikacja zakresu wycieku, powiadomienia, analiza kont/SSO integracji.
• Publiczne raporty opisują złożone łańcuchy exploitacji w ekosystemie EBS (różne CVE i różne łańcuchy); nawet jeśli CVE-2025-61884 ma CVSS tylko na poufność, w praktyce SOC powinien sprawdzić, czy nie wystąpiły sygnały „post-exploit”.

Przykłady z kampanii / case studies

• Dodanie do KEV (widoczne w NVD) sugeruje dowody aktywnego wykorzystania i podbija priorytet patchowania/huntingu (NVD pokazuje „Date Added: 2025-10-20” oraz deadline).
• CSA Singapur opublikowała alert wprost o aktywnej eksploatacji SSRF i podała, że PoC jest publicznie dostępny.
• Media branżowe raportowały, że exploit/PoC miał zostać ujawniony publicznie (m.in. w wątku „ShinyHunters”), a Oracle wypuścił poprawkę out-of-band.
• Kontekst kampanii extortion wokół Oracle EBS był szeroko opisywany, m.in. przez Reuters (z zastrzeżeniem, że ocena prawdziwości części twierdzeń napastników bywała na tamtym etapie niepewna).

Lab (bezpieczne testy) — przykładowe komendy

Cel labu dla Blue Team: zweryfikować ekspozycję, widoczność w logach i skuteczność detekcji, bez „odtwarzania exploitów”.

1. Sprawdź ekspozycję portów i usług (host EBS / reverse proxy):

sudo ss -lntp | egrep ':(80|443)\s'

2. Wygeneruj kontrolowany „ruch testowy” do standardowej strony (bez payloadów CVE), aby upewnić się, że logi trafiają do SIEM:

curl -kI https://twoj-host-ebs.example/ | head

3. Test parsowania i reguł detekcji na „sztucznych” wpisach logów (bez kontaktu z EBS):

cat <<'EOF' > /tmp/test_access.log
203.0.113.10 - - [23/Dec/2025:10:00:00 +0000] "GET /OA_HTML/SyncServlet?return_url=http://example.com/ HTTP/1.1" 200 1234 "-" "lab-test-agent"
EOF

Następnie odpal swoje pipeline’y (Filebeat/Fluent Bit/Splunk UF) na pliku testowym i sprawdź, czy reguła (Sigma/SPL/KQL) łapie zdarzenie.

4. Sprawdź, czy WAF raportuje sygnatury dla CVE-2025-61884 (np. w Cloudflare jest to osobna detekcja w managed rules).

Mapowania (Mitigations, Powiązane techniki)

ATT&CK

• Technika: T1190 – Exploit Public-Facing Application
• Taktyka: Initial Access
• ATT&CK (katalog): v18 (aktualizacja październik 2025)
• Last Modified (T1190): 24 Oct 2025

Mitigations (MITRE)

Dla T1190 MITRE podkreśla m.in.:

• M1050 Exploit Protection / WAF,
• M1037 Filter Network Traffic (zwłaszcza ograniczenie egress),
• M1035 Limit Access to Resource Over Network,
• M1030 Network Segmentation,
• M1051 Update Software,
• M1016 Vulnerability Scanning,
• M1048 Application Isolation and Sandboxing.

Powiązane techniki (często w tym samym łańcuchu)

• T1210 Exploitation of Remote Services (gdy exploit przeradza się w ruch lateralny)
• T1041 Exfiltration Over C2 Channel / T1567 Exfiltration Over Web Service (jeśli dane są wyprowadzane)
• (Kontekstowo) techniki związane z SSRF → dostęp do metadanych chmurowych i nadużyciem IAM (zależne od środowiska).

Źródła / dalsza literatura

• Oracle: Security Alert CVE-2025-61884 (opis, risk matrix, wersje dotknięte, parametry CVSS). (Oracle)
• NVD: CVE-2025-61884 (CVSS vector, wersje 12.2.3–12.2.14, wątek KEV i nazwa SSRF, lista CWE z CISA-ADP). (NVD)
• MITRE ATT&CK: T1190 (definicja, mitygacje, strategie detekcji, data modyfikacji). (MITRE ATT&CK)
• CSA Singapore: alert o aktywnej eksploatacji i PoC. (Cyber Security Agency of Singapore)
• Canadian Centre for Cyber Security: kontekst patchy i KEV. (Canadian Centre for Cyber Security)
• Cloudflare: emergency WAF release z detekcją dla CVE-2025-61884. (Cloudflare Docs)
• BleepingComputer: tło kampanii, PoC leak, SSRF/return_url jako trop huntingowy. (BleepingComputer)
• Google Cloud (Mandiant/GTIG): kontekst wielu łańcuchów exploitacji w EBS (ważne dla „post-exploit” huntingu). (Google Cloud)
• Reuters: tło kampanii extortion wokół Oracle EBS (ostrożnie z atrybucją). (Reuters)

Checklisty dla SOC / CISO

SOC (operacyjnie, 24–72h)

• Zidentyfikuj wszystkie instancje Oracle EBS/Configurator Runtime UI i czy są publicznie dostępne.
• Wdróż/zweryfikuj patch z Security Alert (11 Oct 2025) na dotkniętych wersjach 12.2.3–12.2.14.
• Włącz korelację: (inbound endpointy) + (WAF/error spike) + (egress anomalia).
• Retrospektywny hunting: UiServlet/SyncServlet + return_url + wskaźniki SSRF/CRLF.
• Jeśli widzisz sygnały skutecznej eksploatacji: uruchom IR (triage danych, izolacja hostów, analiza egress).

CISO (zarządczo)

• Traktuj CVE-2025-61884 jako „exploited-in-the-wild” (KEV) i ustaw priorytet patchowania/izolacji jak dla krytycznych systemów biznesowych.
• Wymuś polityki: WAF + segmentacja + ograniczenie egress dla aplikacji publicznych.
• Upewnij się, że monitoring obejmuje warstwę aplikacyjną i sieciową (bez tego SSRF bywa „ciche”).