Archiwa: Admin - Strona 31 z 33 - Security Bez Tabu

Tag: Admin

CISA dodaje pięć nowych luk do katalogu KEV: Oracle E-Business Suite, Microsoft SMB, Kentico Xperience i starsza luka w Apple WebKit

Wprowadzenie do problemu / definicja luki

20 października 2025 r. amerykańska CISA dodała pięć nowych podatności do katalogu Known Exploited Vulnerabilities (KEV) – listy luk z potwierdzoną aktywną eksploatacją w środowiskach produkcyjnych. Dla administracji federalnej USA oznacza to obowiązek szybkiego remediowania, ale lista KEV jest de facto priorytetyzatorem patchy także dla sektora prywatnego na całym świecie. Nowe wpisy obejmują m.in. Oracle E-Business Suite, Windows SMB Client, Kentico Xperience oraz starszą lukę w Apple WebKit/JavaScriptCore.

W skrócie

  • CVE-2025-61884 (Oracle E-Business Suite, Runtime/Configurator) – SSRF, zdalnie i bez uwierzytelnienia, umożliwia dostęp do zasobów wewnętrznych. Patch: Security Alert Oracle z 11–12 października 2025.
  • CVE-2025-33073 (Microsoft Windows SMB Client) – improper access control / EoP (eskalacja uprawnień po sieci). Załatane przez Microsoft w czerwcowych aktualizacjach 2025.
  • CVE-2025-2746 (Kentico Xperience, Staging Sync Server, digest/empty SHA1 username) – bypass uwierzytelniania, krytyczna.
  • CVE-2025-2747 (Kentico Xperience, Staging Sync Server, password type = None) – bypass uwierzytelniania, krytyczna. Poprawki dostępne (hotfixy > 13.0.178).
  • CVE-2022-48503 (Apple WebKit/JavaScriptCore) – RCE przez treść WWW (bounds check). Załatane w 2022 r. (iOS/iPadOS 15.6, macOS 12.5, Safari 15.6, tvOS 15.6, watchOS 8.7).

Termin dla FCEB (USA): do 10 listopada 2025 r. (remediacja nowych pozycji). Dla wszystkich innych organizacji – rekomendowane niezwłoczne działania.

Kontekst / historia / powiązania

  • Oracle EBS było już w październiku w centrum uwagi z powodu dwóch głośnych luk (w tym RCE CVE-2025-61882). Najnowsza CVE-2025-61884 to kolejny krytyczny element łańcucha ataku wykorzystywany w kampaniach wyłudzeniowych i eksfiltracyjnych.
  • Kentico Xperience: dwa różne błędy w module Staging Sync Server umożliwiają ominięcie uwierzytelnienia i przejęcie obiektów administracyjnych; to typowy „pre-auth” krok prowadzący do RCE.
  • Microsoft SMB Client (CVE-2025-33073): znany wektor lateral movement; po załataniu nadal wymaga utwardzenia konfiguracji SMB.
  • Apple WebKit (CVE-2022-48503): starsza, ale wciąż eksploatowana luka w JSCore, co dowodzi, że długo nieaktualizowane urządzenia pozostają atrakcyjnym celem.

Analiza techniczna / szczegóły luki

Oracle E-Business Suite – CVE-2025-61884 (SSRF):

  • Komponent: Runtime (Oracle Configurator).
  • Wektor: zdalny, bez uwierzytelnienia; SSRF pozwala proxy’ować żądania do zasobów wewnętrznych (np. serwisy admin, metadane chmurowe), potencjalnie eskalując do RCE w łańcuchu ataku.
  • Status: Security Alert i poprawki dostępne od 11–12.10.2025.

Windows – CVE-2025-33073 (SMB Client, EoP):

  • Charakter: improper access control w kliencie SMB; umożliwia eskalację uprawnień w kontekście sieciowym po uwierzytelnieniu (typowo w ramach ruchu wewnętrznego).
  • Status: załatane w June 2025 (Patch Tuesday).

Kentico Xperience – CVE-2025-2746 / CVE-2025-2747 (Auth bypass):

  • Moduł: Staging Sync Server (SOAP).
  • 2746: obsługa pustych nazw użytkownika (SHA1) w digest auth → przejęcie obiektów administracyjnych.
  • 2747: obsługa password type = None → analogiczny bypass.
  • Zasięg: wersje do 13.0.172/178 (zależnie od CVE).
  • Skutek: pre-auth takeover CMS i typowe przejście do RCE poprzez import obiektów/zadań.

Apple – CVE-2022-48503 (WebKit/JavaScriptCore):

  • Błąd: niewłaściwe sprawdzanie zakresów (bounds); przetworzenie złośliwej treści WWW → RCE.
  • Załatane od lipca 2022 w szeregu platform (iOS/iPadOS/macOS/Safari/watchOS/tvOS). Eksploatacja w 2025 dotyczy głównie niezaktualizowanych urządzeń.

Praktyczne konsekwencje / ryzyko

  • Oracle EBS (SSRF): ryzyko eksfiltracji danych i pivotu do usług wewnętrznych (np. API, usługi konfiguracyjne, metadane chmurowe). W kampaniach obserwowano dalszą eskalację i wymuszenia.
  • Windows SMB Client: ułatwia ruch boczny po początkowym wstępie (np. po phishingu), szczególnie w sieciach z szeroko otwartym SMB i słabą segmentacją.
  • Kentico Xperience: pełne przejęcie CMS i możliwość wstrzyknięcia złośliwych artefaktów do łańcucha CI/CD treści, a następnie drive-by na użytkowników końcowych.
  • Apple WebKit: RCE z przeglądarki na urządzeniach nieobsługiwanych/nieaktualnych – cenne cele dla ataków ukierunkowanych i masowych (watering hole).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa inwentaryzacja i priorytetyzacja pod kątem nowych wpisów KEV (SBOM, CMDB, EDR, skanery, zapytania do MDM/Intune/Jamf). Traktuj KEV jako backlog „patch-first”.
  2. Oracle EBS (CVE-2025-61884):
    • Zastosuj Security Alert/patch Oracle bez zwłoki.
    • W krótkim terminie – egress filtering z hostów EBS oraz deny-list do metadanych chmurowych/IMDS, WAF z regułami SSRF, segmentacja sieci.
  3. Windows (CVE-2025-33073):
    • Upewnij się, że June 2025 CU jest wdrożony wszędzie; wymuś SMB signing, ogranicz NTLM, egzekwuj firewall hostowy i LAPS.
  4. Kentico Xperience (CVE-2025-2746/2747):
    • Aktualizuj do hotfixów > 13.0.178 (lub zgodnie z zaleceniami producenta); jeśli Staging Sync Server nie jest niezbędny – wyłącz; wymuś TLS/mTLS i IP allow-list na endpointach stagingu.
  5. Apple (CVE-2022-48503):
    • Wycofaj lub zaktualizuj urządzenia do wersji zawierających łatę (min. iOS/iPadOS 15.6, macOS 12.5, Safari 15.6 itd.). W MDM dodaj reguły blokujące przeglądarki na EOL.
  6. Detekcja i hunting (przykłady):
    • Szukaj nietypowych wywołań HTTP z EBS do adresów wewnętrznych/IMDS, wzorce SSRF (HTTP 169.254.169.254, metadane chmury).
    • Koreluj anomalie SMB (nietypowe sesje, masowe enumeracje, wzrost STATUS_ACCESS_DENIED) po ostatnich logowaniach z niskich poziomów uprawnień.
    • Logi Kentico: żądania do endpointów Staging SOAP bez prawidłowego kontekstu uwierzytelnienia; nagłe zmiany obiektów administracyjnych.
  7. Zarządzanie ryzykiem biznesowym: wpisz nowe CVE do Risk Register, przypisz SLA < 14 dni (dla KEV – najlepiej 7–10 dni), egzekwuj kompensacje (WAF, segmentacja) tam, gdzie patch chwilowo niemożliwy.

Różnice / porównania z innymi przypadkami

  • SSRF (Oracle) to wektor często niedoszacowany – w przeciwieństwie do klasycznego RCE, SSRF bywa „cichym” krokiem do pivotu; porównaj z wcześniejszymi kampaniami na IMDS w chmurze.
  • Auth-bypass w Kentico to przykład pre-auth przejęcia panelu CMS – podobnie jak znane łańcuchy w innych CMS, ale tutaj Sync Server jest unikatowym komponentem API.
  • SMB EoP przypomina inne luki w ekosystemie Windows, gdzie słaba segmentacja zamienia medium-severity w krytyczne ryzyko lateral movement.

Podsumowanie / kluczowe wnioski

  • Dodanie pięciu pozycji do KEV to jasny sygnał: eksploatacja trwa.
  • Priorytet 1: Oracle EBS (SSRF) oraz Kentico (auth-bypass), ponieważ dają szybkie przejęcie środowisk internetowych.
  • Priorytet 2: Windows SMB (EoP) – kluczowe dla ograniczenia ruchu bocznego.
  • Higiena podstawowa: aktualizacje Apple/WebKit na urządzeniach zalegających w starszych wersjach.
  • Termin dla agencji FCEB: 10.11.2025 – dobry celowy SLA także dla firm prywatnych.

Źródła / bibliografia

  1. CISA – Alert z 20 października 2025: „CISA Adds Five Known Exploited Vulnerabilities to Catalog”. (CISA)
  2. The Hacker News – „Five New Exploited Bugs Land in CISA’s Catalog — Oracle and Microsoft Among Targets” (lista CVE, termin 10.11.2025). (The Hacker News)
  3. Oracle – Security Alert: CVE-2025-61884 (E-Business Suite). (Oracle)
  4. NVD – CVE-2025-33073 (Windows SMB Client). (NVD)
  5. NVD – CVE-2025-2747 (Kentico Xperience, Staging Sync Server). (NVD)

Everest ransomware bierze na siebie odpowiedzialność za atak na Collins Aerospace. Co to oznacza dla lotnictwa w Europie?

Wprowadzenie do problemu / definicja luki

Grupa ransomware Everest ogłosiła, że to ona stoi za włamaniem do Collins Aerospace (spółka RTX), którego skutki odczuwalne były w całej Europie — od paraliżu odpraw po wielogodzinne opóźnienia. Nowa deklaracja na stronie wycieków grupy pojawiła się 17–18 października 2025 r., kilka tygodni po tym, jak Collins potwierdził incydent ransomware dotyczący oprogramowania do boardingu pasażerów. Wcześniej służby i media nie wskazywały jednoznacznie sprawców ataku.

W skrócie

  • Co się stało: Collins Aerospace padł ofiarą ataku ransomware, który zakłócił odprawy i nadawanie bagażu na lotniskach m.in. w Londynie (Heathrow), Brukseli, Dublinie i Berlinie. ENISA potwierdziła charakter ataku jako ransomware.
  • Nowy element: Grupa Everest publicznie przypisała sobie odpowiedzialność i zapowiedziała publikację wykradzionych danych.
  • Stan formalny: RTX w zgłoszeniu inwestorskim podał, że chodziło o oprogramowanie do boardingu pasażerów; spółka nie spodziewa się istotnego wpływu finansowego. Równolegle w Wielkiej Brytanii zatrzymano (warunkowo zwolniono) mężczyznę w związku ze sprawą, lecz śledztwo trwa.

Kontekst / historia / powiązania

Atak z września 2025 r. wymusił ręczną obsługę pasażerów na wielu lotniskach i spowodował odwołania lotów. W tamtym czasie nie było potwierdzonej identyfikacji grupy. Dopiero teraz Everest przypisuje sobie odpowiedzialność, ujawniając wpis na stronie wycieków i zapowiadając „transze” danych. Media branżowe i regionalne odnotowały ten zwrot, podkreślając związek ze wcześniejszym chaosem na lotniskach.

Analiza techniczna / szczegóły luki

  • Wektor uderzenia: RTX wskazał na „passenger boarding software” – klasę systemów krytycznych dla procesu odprawy i wejścia na pokład (CUTE/CUPPS), wdrażanych u wielu przewoźników i operatorów. Uderzenie w taką warstwę oprogramowania ma efekt kaskadowy (łańcuch dostaw).
  • Taktyki sprawców (TTPs) – wnioskowanie na podstawie znanych kampanii ransomware i deklaracji Everest: kradzież danych (double extortion), szyfrowanie zasobów produkcyjnych, groźba publikacji danych w razie braku okupu. Informacje z wpisów monitorujących leak-site Everest wskazują na publikację wpisu dotyczącego Collins/RTX w dniach 17–18 października.
  • Skala i propagacja zakłóceń: zakłócenia objęły wiele hubów (Heathrow, Bruksela, Berlin, Dublin), co potwierdza wrażliwość sektora lotniczego na jednopunktowe awarie po stronie dostawcy.

Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne: przestoje w odprawach, ręczne procesy, korki w terminalach, utrata slotów, domino w siatce połączeń.
  • Ryzyko prawne i reputacyjne: potencjalny wyciek danych pasażerów lub partnerów, presja regulacyjna (NIS2, RODO), roszczenia kontraktowe. (Deklaracje publikacji danych przez Everest zwiększają ryzyko wtórnych nadużyć).
  • Ryzyko finansowe: choć RTX raportował brak „materialnego” wpływu, koszty incydentu po stronie linii i lotnisk (opóźnienia, personel, rekompensaty) mogą być znaczące – zwykle nieujmowane w raporcie dostawcy.

Rekomendacje operacyjne / co zrobić teraz

Dla operatorów lotnisk i linii lotniczych:

  1. Modelowanie ryzyka łańcucha dostaw (CUPPS/CUTE/MUSE i integracje) – klasyfikacja komponentów „single point of failure”, audyty i plany awaryjne z realnym RTO/RPO.
  2. Segmentacja i „blast radius” – oddzielenie sieci operacyjnych (airside/landsid e), kontrola lateral movement, tiered admin, „break-glass” konta offline.
  3. Kontrole tożsamości – phishing-resistant MFA dla kont uprzywilejowanych, rotacja kluczy API integrujących DCS/Departure Control.
  4. Telemetria i EDR/XDR – pełne logowanie na serwerach aplikacyjnych i brokerach integracyjnych (SITA/Amadeus itp.), korelacja zdarzeń z IOC/TTP grup ransomware.
  5. Kopie zapasowe i runbooki manualne – offline immutable backups + ćwiczenia tabletop z przejściem na manual check-in/boarding.
  6. Zarządzanie dostawcami – kontraktowe SLA bezpieczeństwa, SBOM, dowody testów backup/restore, regularne red team/supply chain ćwiczenia.

Dla dostawców oprogramowania lotniczego:

  1. Bezpieczny rozwój i hardening (CISA/ENISA good practices dla oprogramowania krytycznego), izolacja tenantów, kontrola aktualizacji.
  2. Detekcja exfiltracji – DLP na warstwie aplikacyjnej, egress filtering, honeytokens w danych PII.
  3. Plan odpowiedzialnej komunikacji – spójne advisory dla klientów (IOC, TTP, reguły detekcji, kroki naprawcze).

(Praktyki powyżej wynikają z dobrych praktyk dla incydentów ransomware w infrastrukturze krytycznej oraz z charakteru tego ataku potwierdzonego przez RTX/ENISA).

Różnice / porównania z innymi przypadkami

  • Wobec typowych ataków na linie lotnicze: tu głównym celem był dostawca oprogramowania, a nie pojedynczy przewoźnik. To tłumaczy szeroki, wielolotniskowy efekt.
  • Na tle „głośnych” kampanii (np. Scattered Spider): motywacja Everest wpisuje się w trend łączenia okupu z „prestiżem” w środowisku przestępczym – co podkreślali eksperci po wrześniowym chaosie.

Podsumowanie / kluczowe wnioski

  • Deklaracja Everest domyka najważniejszy znak zapytania: kto uderzył w Collins Aerospace. Formalnego potwierdzenia organów na razie brak, ale wpisy na leak-site i relacje branżowe są spójne czasowo.
  • Rdzeniem incydentu był atak ransomware na oprogramowanie do boardingu, co obnażyło kruchość łańcucha dostaw lotniczych.
  • Organizacje lotnicze powinny potraktować zdarzenie jako case study i wzmocnić segmentację, planowanie ciągłości działania oraz egzekwowanie wymagań bezpieczeństwa wobec dostawców.

Źródła / bibliografia

  • Cybersecurity Dive: „RTX confirms hack of passenger boarding software involved ransomware” (26 września 2025). (Cybersecurity Dive)
  • Reuters: „Airport chaos highlights rise in high-profile ransomware attacks…” (22 września 2025). (Reuters)
  • Reuters: „UK police arrest man over hack that affected European airports” (24 września 2025). (Reuters)
  • CyberNews: „Collins Aerospace attack claimed by Everest…” (18 października 2025). (Cybernews)
  • Security Affairs: „Everest Gang takes credit for Collins Aerospace breach” (18 października 2025). (Security Affairs)

Adobe AEM Forms (CVE-2025-54253) już wykorzystywana w atakach: co muszą zrobić zespoły bezpieczeństwa

Wprowadzenie do problemu / definicja luki

CISA ostrzegła, że krytyczna podatność w Adobe Experience Manager (AEM) Forms na JEE, śledzona jako CVE-2025-54253, jest aktywnie wykorzystywana. To błąd konfiguracji prowadzący do zdalnego wykonania kodu (RCE), oceniony na CVSS 10.0. Adobe załatało problem w trybie out-of-band na początku sierpnia 2025 r., ale w obiegu znajdował się już publiczny PoC, co ułatwiło atakującym przygotowanie kampanii.

W skrócie

  • Produkt / wersje: AEM Forms na JEE w wersjach 6.5.23.0 i starszych są podatne. Wydanie naprawcze: 6.5.0-0108. Wpływ: zdalne wykonanie kodu bez uwierzytelnienia.
  • Status: CISA dodała lukę do KEV (Known Exploited Vulnerabilities) – potwierdzona eksploatacja „in the wild”. Federalne agencje USA muszą załatać systemy do 5 listopada 2025 r.
  • Powiązana luka: CVE-2025-54254 (XXE, CVSS 8.6) również naprawiona w tym samym pakiecie, ale na razie nie jest na liście KEV.

Kontekst / historia / powiązania

Adobe opublikowało biuletyn APSB25-82 5 sierpnia 2025 r., rekomendując pilną aktualizację do AEM Forms na JEE 6.5.0-0108. W notatce zaznaczono, że dla CVE-2025-54253 i CVE-2025-54254 istniał publiczny PoC. 16 października 2025 r. niezależne serwisy (SecurityWeek, HNS) wskazały, że CISA dodała CVE-2025-54253 do KEV, co oznacza obserwowaną eksploatację w realnych atakach.

Analiza techniczna / szczegóły luki

Istota problemu to błędna konfiguracja pozostawiająca w interfejsie administracyjnym AEM Forms włączony Apache Struts „devMode” oraz łańcuch z ominięciem uwierzytelnienia, co razem umożliwia atakującemu wykonanie wyrażeń OGNL i eskalację do RCE – i to bez interakcji użytkownika. Wektor jest prosty (niska złożoność), a atak może był kierowany na endpoint związany z debugowaniem (np. /adminui/debug).

W biuletynie Adobe potwierdzono:

  • CVE-2025-54253 – „Incorrect Authorization”, RCE, CVSS 10.0
  • CVE-2025-54254 – XXE, odczyt plików, CVSS 8.6
    Patch docelowy: AEM Forms na JEE 6.5.0-0108; wersje dotknięte: 6.5.23.0 i starsze.

Dodatkowa dokumentacja Adobe dla administratorów precyzuje, które warianty nie są podatne (Forms na OSGi, Workbench, Cloud Service) i opisuje ścieżki aktualizacji/hotfixów dla Service Packów 18–23 oraz starszych.

Praktyczne konsekwencje / ryzyko

  • Pre-auth RCE na serwerze aplikacyjnym, często z uprawnieniami usługi AEM Forms (np. JBoss/WebLogic/WebSphere), daje napastnikowi trwały foot-hold.
  • Niska złożoność i brak interakcji użytkownika zwiększają prawdopodobieństwo automatycznych skanów i masowej eksploatacji.
  • Publiczny PoC plus wpis w KEV → realne ryzyko ransomware, web-shelli i pivotu do sieci wewnętrznej.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizuj natychmiast: do AEM Forms na JEE 6.5.0-0108 (APSB25-82). Jeżeli używasz SP 18–22, zastosuj odpowiednie hotfixy zgodnie z instrukcją Adobe; dla 6.5.23.0 dostępny jest hotfix zbiorczy.
  2. Zweryfikuj ekspozycję: AEM Forms na JEE nie powinien być dostępny z Internetu (zwłaszcza /adminui/*). Ogranicz dostęp do panelu admina do zaufanych sieci/VPN i wymuś MFA.
  3. Tymczasowe środki twardnienia (jeśli patchowanie wymaga okna):
    • Zablokuj na WAF/proxy /adminui/debug i inne endpointy admin UI; odfiltruj wzorce OGNL.
    • Upewnij się, że Struts devMode jest wyłączony w środowiskach produkcyjnych.
  4. Higiena uprawnień i segmentacja: uruchamiaj AEM Forms z minimalnymi uprawnieniami i odseparuj serwer w strefie DMZ z ograniczonym egress. (Wniosek operacyjny na bazie wektora RCE).
  5. Detekcja i reagowanie:
    • Sprawdź logi aplikacyjne i reverse proxy pod kątem żądań do /adminui/debug oraz ładunków OGNL.
    • Szukaj nietypowych procesów dziecka (np. cmd, powershell, /bin/sh) uruchamianych przez proces aplikacyjny AEM/JEE.
    • Wdroż reguły EDR/NDR/WAF na znane ciągi OGNL oraz nienaturalne nagłówki/parametry. (Wniosek techniczny na podstawie opisu wektora).
  6. Walidacja naprawy: po aktualizacji zweryfikuj wersję i komponenty zgodnie z poradnikiem Adobe (Service Pack + wymienione EAR/WAR/JAR).
  7. Termin krytyczny (USA): jeżeli podlegasz BOD 22-01, termin remediacji to 5 listopada 2025 r.

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

  • CVE-2025-54253 (CVSS 10.0) – błąd konfiguracji (Struts devMode + auth bypass), RCE bez uwierzytelnienia; KEV → potwierdzona eksploatacja.
  • CVE-2025-54254 (CVSS 8.6) – XXE w usługach webowych AEM Forms (odczyt plików), naprawiona w tym samym wydaniu, obecnie brak potwierdzenia eksploatacji w KEV.
  • CVE-2025-49533 – dodatkowe RCE w GetDocumentServlet, również ujęte w dokumentacji łagodzenia Adobe dla AEM Forms 6.5. (Warto uwzględnić w pełnym cyklu patchowania).

Podsumowanie / kluczowe wnioski

  • To jest incydent „patch-now”: publiczny PoC + wpis w KEV + niska złożoność ataku.
  • Aktualizacja do 6.5.0-0108 i twardnienie dostępu do admin UI to minimum operacyjne.
  • Zespoły powinny przeprowadzić threat hunting po wzorcach OGNL i śladach RCE oraz zablokować ekspozycję AEM Forms na Internet.

Źródła / bibliografia

  • SecurityWeek: ostrzeżenie o wykorzystywaniu CVE-2025-54253 i kontekst KEV/BOD. (SecurityWeek)
  • Adobe APSB25-82: wersje podatne, wersja naprawcza 6.5.0-0108, oceny CVSS. (Adobe Help Center)
  • Adobe Experience League: przewodnik łagodzenia, zakres dotkniętych/wyłączonych wariantów, kroki hotfix. (Experience League)
  • Help Net Security: szczegóły techniczne (Struts devMode, OGNL, /adminui/debug), status KEV i terminy. (Help Net Security)
  • The Hacker News: podsumowanie wpływu, wersje, termin remediacji dla agencji federalnych. (The Hacker News)

Fortinet i Ivanti łatają luki o wysokiej istotności – październik 2025

Wprowadzenie do problemu / definicja luki

15 października 2025 r. Fortinet i Ivanti opublikowały październikowe biuletyny bezpieczeństwa, w których zaadresowano szereg podatności – w tym kilka o istotności „high”. Fortinet udostępnił łącznie 29 nowych porad, m.in. dla FortiOS, FortiPAM/FortiSwitchManager, FortiDLP i FortiIsolator. Ivanti wydało poprawki dla EPMM i Neurons for MDM oraz wskazówki do Endpoint Manager (EPM).

W skrócie

  • FortiOS (CVE-2025-58325, High, CVSS 7.8): lokalny uwierzytelniony użytkownik może zyskać możliwość wykonania komend systemowych przez obejście ograniczeń CLI. Łata dostępna; dotyczy wielu gałęzi 6.4–7.6.
  • FortiPAM / FortiSwitchManager (CVE-2025-49201, High): słabe uwierzytelnianie (CWE-1390) umożliwia zdalne obejście autoryzacji i wykonanie nieautoryzowanych poleceń przez spreparowane żądania HTTP.
  • FortiDLP (m.in. zależność Apache Tika): ryzyko ujawnienia danych/SSRF wynikające z podatności w bibliotece Tika używanej przez FortiDLP; dodatkowo luki podnoszące uprawnienia.
  • Ivanti EPMM & Neurons for MDM: kilka luk o wysokiej istotności, m.in. zdalne wykonanie kodu (po stronie uprzywilejowanego admina), obejście MFA i możliwość „unenroll” urządzeń; producent nie notuje exploitów „in the wild”.

Kontekst / historia / powiązania

Urządzenia Fortinet i platformy Ivanti były wielokrotnie na celowniku atakujących – część wcześniejszych luk trafiała do katalogu KEV CISA i była wykorzystywana w łańcuchach ataku na sieci brzegowe. Obecny pakiet poprawek wpisuje się w comiesięczny cykl łatania producentów i ma ograniczyć możliwość pivotowania przez kompromitację urządzeń zarządzających i filtrujących ruch. Przegląd i liczby dla października podał m.in. SecurityWeek.

Analiza techniczna / szczegóły luki

FortiOS – CVE-2025-58325 (High)

  • Wada: „Incorrect Provision of Specified Functionality” (CWE-684) w obsłudze CLI; pozwala lokalnemu, uwierzytelnionemu użytkownikowi na wykonanie komend systemowych z podwyższonymi uprawnieniami (eskalacja).
  • Zakres wersji: 7.6.0; 7.4.0–7.4.5; 7.2.5–7.2.10; 7.0.0–7.0.15; wszystkie 6.4.* (wg NVD).
  • Ocena ryzyka: CVSS 3.1: 7.8 (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H).
  • Status: poprawki dostępne; Fortinet opublikował poradę PSIRT (FG-IR-24-361).

FortiPAM / FortiSwitchManager – CVE-2025-49201 (High)

  • Wada: słabe mechanizmy uwierzytelniania (CWE-1390) umożliwiające brute force/obejście logowania i wykonanie nieautoryzowanych poleceń.
  • Zakres wersji: FortiPAM 1.5.0; 1.4.0–1.4.2; 1.3.0–1.3.1; 1.2.0; 1.1.0–1.1.2; 1.0.0–1.0.3; FortiSwitchManager 7.2.0–7.2.4.
  • Wpływ: potencjalny RCE/komendy w kontekście aplikacji.
  • Status: łatki i porada PSIRT (FG-IR-25-010).

FortiDLP / FortiIsolator i inne komponenty

  • FortiDLP: podatności, w tym wynikające z użycia Apache Tika, mogą prowadzić do ujawnienia danych lub SSRF; dodatkowo dwa wewnętrzne EoP do LocalService/Root.
  • FortiIsolator (CVE-2024-33507, High): manipulacja ciasteczkami umożliwia deautoryzację adminów (bez uwierzytelnienia) lub nadanie uprawnień zapisu (po uwierzytelnieniu).
  • Inne produkty: aktualizacje m.in. FortiProxy, FortiManager, FortiAnalyzer, FortiWeb, FortiSOAR, FortiSIEM, FortiSASE. (Szczegółowe listy w biuletynach Fortinet).

Ivanti – EPMM i Neurons for MDM (październik 2025)

  • EPMM: trzy luki o „high severity” umożliwiające wykonanie kodu przez uwierzytelnionego admina; jedna luka „medium” (zapis na dysk).
  • Neurons for MDM: dwie luki „high” – jedna pozwala adminowi „unenroll” dowolne urządzenie (znika z UEM UI), druga to obejście MFA; dodatkowo luka „medium” w API ujawniająca wrażliwe dane bez uwierzytelnienia.
  • Status: poprawki dostępne; brak informacji o aktywnej eksploatacji.

Praktyczne konsekwencje / ryzyko

  • Ryzyko lateral movement: przejęcie urządzeń brzegowych/UEM ułatwia pivotowanie w sieci i eskalację uprawnień w domenie.
  • Zakłócenie widoczności i kontroli: „unenroll” urządzeń w MDM odcina je od polityk, co zwiększa powierzchnię ataku w mobilnym ekosystemie.
  • Utrata poufności: luki w FortiDLP/Apache Tika mogą odsłonić dane i/lub umożliwić SSRF do zasobów wewnętrznych.
  • Uprzywilejowany dostęp: obejście uwierzytelniania (FortiPAM/FortiSwitchManager) lub wykonanie komend przez CLI (FortiOS) może skutkować trwałym umocnieniem się atakującego.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj natychmiast FortiOS, FortiPAM/FortiSwitchManager, FortiDLP/FortiIsolator oraz Ivanti EPMM i Neurons for MDM do wersji wskazanych w najnowszych poradach producentów. Priorytet: systemy z dostępem administracyjnym z sieci i komponenty brzegowe.
  2. Zweryfikuj ekspozycję usług (GUI/API/SSO/CLI) – ogranicz dostęp administracyjny do sieci zarządzającej/VPN, wprowadź allow-listy IP i MFA.
  3. Rotacja haseł i kluczy dla kont serwisowych/adminów na urządzeniach Fortinet/Ivanti; sprawdź, czy nie doszło do nieautoryzowanych logowań.
  4. Przejrzyj logi pod kątem IOC: nieudane/masowe próby logowania (FortiPAM/FortiSwitchManager), nietypowe komendy w CLI (FortiOS), niespodziewane unenrolle w MDM, błędy API i anomalie ruchu wychodzącego (potencjalny SSRF).
  5. Segmentacja i least privilege: minimalizuj wpływ ewentualnego naruszenia; rozdziel płaszczyzny zarządzania od ruchu użytkowników.
  6. Zarządzanie zależnościami: jeśli używasz funkcji zależnych od bibliotek typu Apache Tika, monitoruj wersje i politykę aktualizacji.

Różnice / porównania z innymi przypadkami

  • Lokalne vs. zdalne wektory: CVE-2025-58325 wymaga konta lokalnego (AV:L), ale daje wysoki wpływ i może połączyć się z innymi błędami do pełnego przejęcia. Z kolei CVE-2025-49201 ma wektor sieciowy (AV:N), co podnosi priorytet twardego ograniczenia ekspozycji usług HTTP/GUI.
  • UEM/MDM jako cel: luki w Ivanti nie wymagają zero-day do masowego nadużycia – wystarczy skompromitowane konto admina lub błędy konfiguracji, by wyłączyć ochronę urządzeń mobilnych (unenroll) lub ominąć MFA.

Podsumowanie / kluczowe wnioski

  • Październikowe poprawki Fortinet i Ivanti zamykają istotne luki, które w złych rękach mogą stać się elementem skutecznych łańcuchów ataku.
  • Administratorzy powinni niezwłocznie aktualizować wskazane produkty, ograniczyć powierzchnię ataku (ekspozycja GUI/API/CLI), włączyć ścisłe monitorowanie i przeprowadzić przegląd logów pod kątem anomalii.
  • Brak doniesień o aktywnej eksploatacji to okno możliwości na bezpieczne wdrożenie łatek, zanim pojawią się publiczne PoC lub masowe skanowanie.

Źródła / bibliografia

  1. SecurityWeek: „High-Severity Vulnerabilities Patched by Fortinet and Ivanti” (15.10.2025). (SecurityWeek)
  2. Fortinet PSIRT (FG-IR-24-361): Restricted CLI command bypass – CVE-2025-58325 (14.10.2025). (fortiguard.fortinet.com)
  3. NVD: CVE-2025-58325 – FortiOS CLI command bypass (14.10.2025). (NVD)
  4. Fortinet PSIRT (FG-IR-25-010): Weak authentication in FortiPAM/FortiSwitchManager – CVE-2025-49201 (14.10.2025). (fortiguard.fortinet.com)
  5. Ivanti: „October 2025 Security Advisory – Neurons for MDM / EPMM” (październik 2025). (forums.ivanti.com)

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

Wprowadzenie do problemu / definicja incydentu

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

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

W skrócie

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

Kontekst / historia / powiązania

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

Analiza techniczna / szczegóły luki

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

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

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

CISA dodaje 5 nowych luk do katalogu KEV (14 października 2025) — co to oznacza dla Twojej organizacji

Wprowadzenie do problemu / definicja luki

14 października 2025 r. amerykańska CISA dodała pięć nowych, aktywnie wykorzystywanych luk do katalogu Known Exploited Vulnerabilities (KEV). Dodanie do KEV oznacza, że istnieją wiarygodne dowody nadużyć „in the wild”, a dla agencji federalnych wyznaczany jest twardy termin remediacji zgodnie z dyrektywą BOD 22-01. W praktyce to także sygnał „patch now” dla sektora prywatnego.

W skrócie

  • Nowe CVE w KEV (5):
    • CVE-2025-24990 — Windows (sterownik Agere Modem, „untrusted pointer dereference”).
    • CVE-2025-47827 — IGEL OS 10 (obejście Secure Boot przez użycie klucza po dacie ważności).
    • CVE-2025-59230 — Windows Remote Access Connection Manager (podniesienie uprawnień).
    • CVE-2016-7836 — SKYSEA Client View (zdalne wykonanie kodu, CVSS 9.8).
    • CVE-2025-6264 — Rapid7 Velociraptor (błędne domyślne uprawnienia → wykonanie poleceń).
  • Dlaczego teraz? Fala wpisów koreluje z październikowym Patch Tuesday (Microsoft) i świeżymi obserwacjami nadużyć (m.in. Velociraptor w incydentach ransomware).
  • Termin (FCEB): dla nowych pozycji z 14.10.2025 CISA wyznacza deadline 4 listopada 2025. To dobra praktyka także dla firm prywatnych.

Kontekst / historia / powiązania

Katalog KEV to „lista wstydu” produktów z lukami, które naprawdę są wykorzystywane. Wpis do KEV wymusza na podmiotach federalnych priorytetową remediację (zwykle w 21 dni), a w wyjątkowych sytuacjach — szybciej. W 2025 r. KEV był wielokrotnie uzupełniany falami po Patch Tuesday oraz po publicznych raportach o nadużyciach (np. ransomware wykorzystujący Velociraptor).

Analiza techniczna / szczegóły luki

1) CVE-2025-24990 — Microsoft Windows (sterownik Agere Modem)

  • Typ/efekt: dereferencja niezaufanego wskaźnika w sterowniku, potencjalne EoP/RCE w zależności od kontekstu wywołania.
  • Kontekst: sterownik jest dostarczany z wieloma wersjami Windows; Microsoft oznaczył problem jako eksploatowany.
  • Działania: usuń/wyłącz sterownik tam, gdzie niepotrzebny; zastosuj poprawki Microsoftu.

2) CVE-2025-47827 — IGEL OS 10 (Secure Boot bypass)

  • Typ/efekt: bypass Secure Boot — użycie klucza po dacie ważności w module igel-flash-driver umożliwia podmianę obrazu rootfs (SquashFS) i uruchomienie niepodpisanego systemu.
  • Wpływ: fizyczny napastnik może osiągnąć trwałą, wczesną persystencję (bootkit).
  • Termin KEV: dodane 14.10 → due 04.11.2025 (wpis CISA odnotowany w NVD).
  • Działania: aktualizacja do IGEL OS v11+; wymuszenie poprawnego łańcucha zaufania i weryfikacji podpisów.

3) CVE-2025-59230 — Windows RASMAN (Elevation of Privilege)

  • Typ/efekt: Improper Access Control → lokalne EoP do SYSTEM.
  • Wektor: lokalny, niski poziom złożoności (AC:L).
  • Działania: wdrożyć poprawki z październikowego Patch Tuesday; uzupełnić detekcje na nietypowe użycia usług RAS.

4) CVE-2016-7836 — SKYSEA Client View (RCE)

  • Typ/efekt: Improper Authentication w połączeniu TCP z konsolą zarządzającą → RCE bez uwierzytelnienia; CVSS 3.x: 9.8 (CRITICAL).
  • Status KEV: dodane 14.10.2025 z terminem 04.11.2025.
  • Działania: aktualizacja powyżej wersji 11.221.03; segmentacja sieci, ograniczenie dostępu do portów zarządzania.

5) CVE-2025-6264 — Rapid7 Velociraptor (default permissions)

  • Typ/efekt: artefakt Admin.Client.UpdateClientConfig nie wymagał dodatkowego uprawnienia; użytkownik z rolą Investigator mógł zdalnie zaktualizować konfigurację klienta i wykonać polecenia → przejęcie endpointu.
  • Kontekst nadużyć: wykorzystywane w realnych atakach (m.in. kampanie ransomware); wpis do KEV z terminem 04.11.2025.
  • Działania: aktualizacja do wersji z łatką; przegląd ról/uprawnień i artefaktów; telemetria na „nietypowe” aktualizacje konfiguracji klienta.

Praktyczne konsekwencje / ryzyko

  • Łańcuchy ataków mieszanych: lokalne EoP w Windows (CVE-2025-59230, CVE-2025-24990) świetnie łączą się z ucieczkami z przeglądarek/aplikacji jako etap 2 eskalacji.
  • Uderzenie w kontrolę rozruchu: obejście Secure Boot (IGEL) umożliwia „pre-EDR” trwałość — klasyczne narzędzie APT i operatorów ransomware.
  • Nadużywanie narzędzi „dobrych”: Velociraptor w rękach napastnika zmniejsza szanse detekcji (Living-off-the-Land Tooling).
  • Dziedzictwo w środowisku: stary SKYSEA (2016) pokazuje, że legacy potrafi wrócić jako „nowo” eksploatowane, jeśli pozostało w ekosystemie.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytet łatania do 4 listopada 2025 (lub szybciej w środowiskach wysokiego ryzyka):
    • Windows: wdrożyć pełny zestaw poprawek z Patch Tuesday (X.2025); osobno usunąć/wyłączyć sterownik Agere tam, gdzie niepotrzebny.
    • IGEL OS: aktualizacja do v11+, weryfikacja implementacji Secure Boot, odświeżenie kluczy.
    • Velociraptor: aktualizacja do wersji z łatką; przegląd ról (odebranie zbędnego COLLECT_CLIENT), ograniczenie artefaktów administracyjnych; monitorowanie nietypowych update’ów konfiguracji.
    • SKYSEA: aktualizacja powyżej 11.221.03; izolacja hostów zarządzania; wymuszenie TLS i list ACL na portach zarządzania.
  2. Detekcja i hunting (propozycje szybkich use-case’ów):
    • Windows EoP: nietypowe uruchomienia/usługi RAS, anomalie w sterownikach, ładowanie ltmdm64.sys (Agere).
    • IGEL: integralność łańcucha rozruchu, zmiany w partycji rozruchowej, niestandardowe obrazy SquashFS.
    • Velociraptor: zdarzenia „UpdateClientConfig”, modyfikacje polityk klienta, uruchomienia powłoki/VS Code z procesu agenta.
  3. Higiena uprawnień i ekspozycji: minimalizacja ról „Investigator” w Velociraptorze; ograniczenie dostępu do konsol (SKYSEA) sieciowo i VPN; app allow-listing dla narzędzi z uprawnieniami systemowymi.
  4. Zarządzanie ryzykiem dostawców/OT: jeśli używasz IGEL lub SKYSEA w środowiskach kiosków/terminali/OT, zaplanuj okno serwisowe i rollback plan — obejście Secure Boot w terminalach może zniweczyć kontrolę zaufania na brzegu.

Różnice / porównania z innymi przypadkami

  • Stara luka, nowe nadużycia: CVE-2016-7836 (SKYSEA) przypomina inne „archeologiczne” wpisy KEV — podatności latami „znane”, ale wciąż wykorzystywane tam, gdzie oprogramowanie przetrwało w niszach.
  • LOLBIN vs. LOTool: w 2024–2025 dużo mówiliśmy o LOLBIN-ach; przypadek Velociraptora to LOTool — legalne narzędzie admina użyte jako wektor ataku (podobnie jak nadużycia RMM/EDR).

Podsumowanie / kluczowe wnioski

  • KEV = kolejka „MUST-DO”: pięć nowych pozycji to czytelny backlog na najbliższe dni.
  • Zwróć uwagę na łańcuch startowy i narzędzia admina (IGEL, Velociraptor) — to wektory o wysokiej wartości dla napastników.
  • Nie zapominaj o legacy: nawet „odległe” CVE (SKYSEA 2016) wracają, jeśli produkt nadal żyje w środowisku.
  • Termin dla FCEB: 4 listopada 2025 — rozsądny SLA także dla sektora prywatnego.

Źródła / bibliografia

  1. CISA — Strona główna (zapowiedź alertu z 14.10.2025). (CISA)
  2. NVD (NIST) — CVE-2016-7836 (SKYSEA) — opis, CVSS 9.8, wpis do KEV z terminem 04.11.2025. (NVD)
  3. NVD (NIST) — CVE-2025-59230 (Windows RASMAN) — opis EoP. (NVD)
  4. NVD (NIST) — CVE-2025-6264 (Rapid7 Velociraptor) — opis błędnych uprawnień. (NVD)
  5. NVD/CVE.org / analizy Patch Tuesday — CVE-2025-24990 (Agere driver) — rekord CVE; dodatkowy kontekst eksploatacji i rekomendacji z przeglądu Patch Tuesday (Tenable). (CVE)

RMPocalypse: nowy atak łamie gwarancje „confidential computing” AMD (CVE-2025-0033)

Wprowadzenie do problemu / definicja luki

Badacze z ETH Zürich opisali atak RMPocalypse pozwalający obejść gwarancje integralności AMD SEV-SNP (Secure Encrypted Virtualization – Secure Nested Paging). Błąd oznaczony jako CVE-2025-0033 wynika z warunku wyścigu podczas inicjalizacji RMP (Reverse Map Table) przez AMD Secure Processor (ASP/PSP) i umożliwia uprzywilejowanemu hipernadzorcy zapis do pamięci RMP, co unieważnia kontrolę własności stron i łamie integralność gościa. AMD potwierdziło problem w biuletynie AMD-SB-3020 (opublikowany 13 października 2025 r.).

W skrócie

  • Identyfikator: CVE-2025-0033 (CVSS v3.1: 6.0 / v4.0: 5.9 – „Medium”).
  • Wpływ: utrata integralności pamięci gościa SEV-SNP; w praktyce może prowadzić także do utraty poufności (atakujący kontroluje RMP).
  • Wymogi ataku: uprawnienia admin/host (złośliwy lub przejęty hipernadzorca).
  • Zasięg: procesory EPYC generacji 7003/8004/9004/9005 (w tym nowe Turin); warianty Embedded – część z poprawkami planowanymi na późniejsze terminy.
  • Mitigacje: aktualizacje SEV firmware/µcode lub nowe AGESA/PI (dostarczane do OEM/CSP; wymagane aktualizacje BIOS/hostów).
  • Dostępność exploita: badania akademickie; brak informacji o atakach w naturze w momencie publikacji, ale ryzyko jest realne dla modeli zagrożeń „złośliwy operator hosta/hipernadzorcy”.

Kontekst / historia / powiązania

SEV-SNP to fundament wielu ofert Confidential Computing dla VM-ów w chmurach publicznych – zapewnia szyfrowanie pamięci i integralność mapowań poprzez RMP. ETH od lat analizuje powierzchnię ataku na SEV-SNP (np. WeSee, Heracles); RMPocalypse to kolejny dowód, że „root w hypervisorze” pozostaje krytycznym przeciwnikiem nawet dla TEE opartych o CPU. Artykuł naukowy został zaprezentowany na ACM CCS 2025.

Analiza techniczna / szczegóły luki

Reverse Map Table (RMP) przechowuje metadane bezpieczeństwa dla wszystkich stron DRAM i egzekwuje własność stron (host vs. konkretna CVM). Aby uniknąć „kurczak-i-jajko”, inicjalizację RMP wykonuje ASP, a x86-rdzenie i hypervisor nie powinny móc modyfikować RMP.

Badacze wykazali, że podczas inicjalizacji RMP istnieje okno czasowe (race), w którym ASP nie chroni wystarczająco buforów RMP w DRAM. Uprzywilejowany hypervisor może wstrzyknąć zanieczyszczone linie cache/jednorazowy zapis w RMP, a następnie wymusić ich spłukanie – skutkuje to dowolnym nadpisaniem wpisów RMP. Jedno 8-bajtowe nadpisanie może skompromitować całą tabelę, ponieważ kolejne kontrole integralności opierają się na już zanieczyszczonym RMP.

W efekcie możliwe są demonstracje: fałszowanie atestacji, włączenie debug na CVM produkcyjnym, replay VMSA, wstrzyknięcia kodu. Zespół zreprodukował atak na Zen 3/Zen 4/Zen 5.

Praktyczne konsekwencje / ryzyko

  • Modele chmurowe: w modelu zaufania „CSP=możliwy przeciwnik”, przejęcie warstwy hosta/hipernadzorcy (lub złośliwy insider) może obejść integralność SEV-SNP dla uruchomionych CVM, co otwiera drogę do eskalacji do poufności (np. wycieki kluczy/sekretów po wstrzyknięciu kodu).
  • Multi-tenant/on-prem: ryzyko dotyczy też operatorów HCI/virtualizacji z zaufaniem dzielonym; separacja tenantów może zostać podkopana, jeśli host jest podatny i uprzywilejowany użytkownik jest złośliwy/skompr.
  • Ryzyko operacyjne: możliwe restarty hostów/CVM w oknach serwisowych CSP podczas wdrażania firmware (wpływ na SLA). Microsoft zapowiedział mitygacje w klastrach Azure Confidential Computing.

Rekomendacje operacyjne / co zrobić teraz

Dla dostawców chmury i operatorów (CSP/hosting):

  1. Inwentaryzacja generacji EPYC i statusu SEV-SNP na hostach.
  2. Wdrożenie poprawek AMD-SB-3020:
    • aktualizacja SEV FW + µcode lub ścieżka AGESA/PI zgodnie z tabelami w biuletynie (np. Milan: SEV FW 1.37.23 + µcode 0x0A0011DE; Genoa: SEV FW 1.37.31 + µcode 0x0A101156; Turin: SEV FW 1.37.41 itd.). Planowanie okien zgodnie z datami dla OEM.
  3. CIS/Hardening hypervisora: minimalizacja powierzchni uprzywilejowanego kodu, wzmocnienie ścieżek administracyjnych i audytu (least privilege, JIT/JEA, PAM).
  4. Monitorowanie anomalii CVM: polityki wykrywania nietypowych resetów/zmian w atestacji i włączenia debug.

Dla klientów korzystających z Confidential VM (Azure/GCP/AWS na AMD):

  1. Sprawdź komunikaty CSP – aktualizacje/rekonfiguracje mogą wymagać restartów zasobów. (Azure ACC zapowiedział działania; analogicznych komunikatów oczekuj w innych chmurach).
  2. Weryfikuj atestację CVM po każdym restarcie/rotacji – automatycznie egzekwuj polityki „fail-closed”, jeśli atestacja nie spełnia profilu (TCB wersje/firmware).
  3. Segmentacja i minimal trust: klucze o najwyższej wrażliwości trzymaj w HSM/KMS z ograniczeniem ekspozycji w CVM (np. podpisy „off-box”).
  4. Plan awaryjny: jeśli workload ma rygorystyczne wymagania integralności, rozważ czasowe wyłączenie SNP-CVM na hostach bez patchy lub migrację do hostów zweryfikowanych przez CSP.

Różnice / porównania z innymi przypadkami

  • WeSee (2024) uderzał w mechanizm #VC i interakcje VM–hypervisor; RMPocalypse celuje w inicjalizację RMP i jest bardziej deterministyczny przy uprawnieniach hosta.
  • Heracles (2025) – atak wybranej wiadomości na SEV-SNP; RMPocalypse łamie rdzeń integralności mapowań i w konsekwencji może umożliwić podobne efekty (np. spoofing atestacji), lecz inną drogą.
  • W odróżnieniu od pobocznych kanałów (np. ciphertext SC), tutaj jednorazowy zapis 8 bajtów w RMP podczas okna inicjalizacji wystarcza do „rozsypania” gwarancji.

Podsumowanie / kluczowe wnioski

  • RMPocalypse obnaża podatność „chwili zerowej” – jeśli RMP nie jest w pełni chronione w trakcie inicjalizacji, cały łańcuch zaufania SEV-SNP może zostać trwale podważony dla danej instancji.
  • Działaj teraz: operatorzy i CSP powinni wdrożyć firmware wg AMD-SB-3020, a klienci wymuszać atestację i obserwować komunikaty CSP o oknach serwisowych.
  • Długofalowo: redukcja zaufania do hipernadzorcy musi mieć odbicie w projektach TEE – inicjalizacja krytycznych struktur (jak RMP) nie może w żadnym momencie polegać na założeniu, że host jest „uczciwy”.

Źródła / bibliografia

  1. SecurityWeek – RMPocalypse: New Attack Breaks AMD Confidential Computing (14 października 2025). (SecurityWeek)
  2. AMD – AMD-SB-3020: SEV-SNP RMP Initialization Vulnerability (13 października 2025) – detale CVE, produkty i wersje FW/µcode/AGESA. (AMD)
  3. Schlüter B., Shinde S. – RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (CCS 2025, preprint PDF). (shwetashinde.org)
  4. ETH Zürich – ETH researchers uncover vulnerability in confidential cloud environments (artykuł uczelni, 2 dni temu). (ETH Zürich)
  5. The Hacker News – RMPocalypse: Single 8-Byte Write Shatters AMD’s SEV-SNP Security (14 października 2025). (The Hacker News)