Archiwa: Security News - Strona 257 z 259 - Security Bez Tabu

Kategoria: Security News

Firefox 144 łata luki wysokiego ryzyka (MFSA 2025-81). Co musisz wiedzieć

Wprowadzenie do problemu / definicja luki

14 października 2025 r. Mozilla opublikowała poradę bezpieczeństwa MFSA 2025-81, która opisuje zestaw podatności naprawionych w Firefox 144. Większość z nich ma wysoki poziom wpływu i obejmuje m.in. błędy bezpieczeństwa pamięci, eskalację wpływu między procesami oraz problem w silniku JS umożliwiający modyfikację niewymazywalnych właściwości obiektów.

W skrócie

  • Aktualizacja do Firefox 144 usuwa m.in. UAF w komponencie audio/wideo, błąd OOB R/W wyzwalany przez tekstury WebGL, wyciek informacji przez malicious IPC, oraz możliwość zmiany właściwości obiektu JS oznaczonych jako niewpisywalne.
  • Łatki są skorelowane z wydaniem 144.0 (desktop i Android); odpowiednie biuletyny wydano też dla linii ESR oraz Thunderbirda.
  • Co najmniej część błędów dotyczy również ESR i Thunderbirda; NVD już śledzi np. CVE-2025-11709 (WebGL → OOB R/W).

Kontekst / historia / powiązania

Mozilla konsekwentnie stosuje sandboxing i separację procesów, ale historia poprawek pokazuje, że błędy na styku procesu treści i procesu uprzywilejowanego wciąż bywają krytyczne — zwłaszcza gdy atak zaczyna się od złośliwej strony WWW i kończy na naruszeniu pamięci w procesie przeglądarki o wyższych uprawnieniach. Wraz z Firefox 144 i równoległymi MFSA dla ESR potwierdzono ten trend, publikując zestaw łatek w jednym cyklu wydawniczym.

Analiza techniczna / szczegóły luki

Najważniejsze wpisy z MFSA 2025-81:

  • CVE-2025-11708 — UAF w MediaTrackGraphImpl::GetInstance() (wysoki): klasyczny use-after-free w grafie ścieżek mediów; potencjalnie prowadzi do awarii lub wykonania kodu po dereferencji zwolnionego wskaźnika.
  • CVE-2025-11709 — OOB R/W w procesie uprzywilejowanym przez zmanipulowane tekstury WebGL (wysoki): proces treści może wymusić odczyty/zapisy poza zakresem w bardziej uprzywilejowanym procesie. Dotyczy też ESR/Thunderbird.
  • CVE-2025-11710 — wyciek informacji międzyprocesowych (wysoki): złośliwe komunikaty IPC mogły skłonić proces przeglądarki do ujawnienia bloków pamięci procesowi niższego zaufania.
  • CVE-2025-11711 — modyfikacja własności JS oznaczonych jako non-writable (wysoki): obejście ograniczeń atrybutów deskryptora własności w JS, z potencjałem na naruszenie założeń izolacji skryptów.
  • Android (średnie/niski): m.in. otwieranie linków z sandboxed iframe w zewnętrznych aplikacjach bez wymaganej zgody; spoofing paska adresu przy zdarzeniu visibilitychange; ograniczenia prezentacji hosta w Custom Tabs sprzyjające podszywaniu.
  • Zbiorcze „Memory safety bugs” (wysokie): tradycyjny pakiet błędów bezpieczeństwa pamięci załatanych w gałęziach 144/140.4/115.29.

Z perspektywy deweloperskiej wydanie 144 wprowadza także zmiany w platformie (MDN/Firefox 144 for developers), co pomaga osadzić poprawki w harmonogramie rozwojowym.

Praktyczne konsekwencje / ryzyko

  • Zdalne wykonanie kodu (RCE) lub eskalacja wpływu są możliwe poprzez łańcuchy exploitów zaczynające się od treści WebGL/JS i kończące na błędach pamięci w procesie uprzywilejowanym.
  • Utrata poufności danych procesu przeglądarki (CVE-2025-11710) przez wycieki pamięci via IPC.
  • Ataki socjotechniczne na Androidzie (spoofing UI, otwieranie zewnętrznych aplikacji) zwiększają ryzyko phishingu i eskalacji poza przeglądarkę.
  • Z punktu widzenia zespołów IT: rządy i CERT-y już rekomendują niezwłoczne aktualizacje w środowiskach Windows/Android, co podnosi priorytet wdrożenia.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj do Firefox 144 na desktopie i Androidzie; w środowiskach korporacyjnych przejdź do ESR 140.4 lub 115.29 zgodnie z polityką.
  2. Włącz wymuszone aktualizacje przez MDM/Intune/GPO dla stacji roboczych; priorytet: urządzenia z akceleracją WebGL, użytkownicy uprzywilejowani, systemy Windows. (Potwierdzenie wersji docelowych: MFSA/Release Notes).
  3. Monitoruj telemetry i crash-reports po aktualizacji, szczególnie rozszerzenia korzystające z Native Messaging (CVE-2025-11719 dot. Windows). Rozważ tymczasowe wyłączenie podejrzanych rozszerzeń.
  4. Twarde ustawienia na Androidzie: zablokuj otwieranie zewnętrznych aplikacji z iframe, edukuj użytkowników o fałszywych paskach adresu, rozważ ograniczenie użycia Custom Tabs w appkach korporacyjnych.
  5. Testy regresyjne dla aplikacji WebGL/Canvas (QA): sprawdź zgodność po stronie front-endu i ewentualne feature-flags. Podpieraj się dokumentacją dla deweloperów 144.

Różnice / porównania z innymi przypadkami

  • WebGL jako wektor do procesu uprzywilejowanego nie jest nowy, ale ten przypadek (CVE-2025-11709) łączy OOB R/W z przełamaniem granicy procesów — podobnie jak wcześniejsze luki klasy cross-process memory corruption. Różnicą jest tu rola manipulowanych tekstur jako triggera.
  • JS non-writable property bypass (CVE-2025-11711) to kategoria rzadziej spotykana niż typowe UAF/OOB; bardziej zagraża spójności modeli bezpieczeństwa opartych na założeniach o niezmienności właściwości.

Podsumowanie / kluczowe wnioski

  • Wydanie Firefox 144 zamyka ciąg błędów wysokiego ryzyka, z których najgroźniejsze dotyczą pamięci i granic między procesami.
  • Dla SOC/IT: traktuj aktualizację jako pilną, szczególnie na Windows i Androidzie, oraz przeglądnij polityki dotyczące rozszerzeń i WebGL.
  • Dla zespołów web/dev: sprawdź wpływ na ścieżki WebGL/Canvas i zachowanie JS po stronie klienta.

Źródła / bibliografia

  1. Mozilla Foundation Security Advisory 2025-81: „Security Vulnerabilities fixed in Firefox 144” (14.10.2025). (Mozilla)
  2. Firefox 144 — Release Notes (desktop, 14.10.2025). (Firefox)
  3. NVD — CVE-2025-11709 (WebGL → OOB R/W) – zakres i dotknięte produkty. (NVD)
  4. MDN — „Firefox 144 for developers” (kontekst zmian). (MDN Web Docs)
  5. GovCERT Hong Kong — alert zbiorczy dot. MFSA 2025-81/-82/-83/-84/-85 (rekomendacje aktualizacji). (govcert.gov.hk)

Roaring Access: pre-auth root RCE w RTU Sixnet (Red Lion) — analiza i rekomendacje

Wprowadzenie do problemu / definicja luki

Claroty Team82 opublikował szczegóły dwóch krytycznych podatności (CVSS 10.0) w sterownikach RTU Red Lion Sixnet — rodzinach SixTRAK i VersaTRAK. Połączenie błędów w implementacji protokołu Sixnet Universal (UDR) umożliwia zdalne wykonanie poleceń jako root bez uwierzytelniania (pre-auth root RCE). Producent udostępnił poprawki; CISA wydała odpowiedni komunikat doradczy.

Kontekst / historia / powiązania

CISA opisała problem w ICSA-23-320-01 (16 listopada 2023 r.), wskazując na wpływ na środowiska ICS/OT (energia, woda/ściek, transport, produkcja). Claroty 14 października 2025 r. ujawniło techniczne detale po okresie embarga, gdy poprawki były już dostępne.

Analiza techniczna / szczegóły luki

Warstwa auth w UDR (UDP 1594). Standardowa komunikacja narzędzi konfiguracyjnych (np. Sixnet IO Tool Kit) używa UDR/UDP z wyzwaniem-odpowiedzią opartym o MD5 (hash z username:RTU:password + challenge + index + losowe 4 bajty). Każdy pakiet zawiera odpowiedź auth i jest weryfikowany po stronie RTU.

Błąd #1 — obejście auth (CVE-2023-42770). Ten sam serwis nasłuchuje również na TCP/1594. Implementacja dla TCP przetwarza pakiet bez weryfikacji sufiksu uwierzytelniania, co pozwala ominąć mechanizm auth i wykonać dowolne funkcje UDR jako niezalogowany klient.

Błąd #2 — wykonanie poleceń (CVE-2023-40151). Jedna z funkcji UDR (kody 0xd0 0x1e) umożliwia wykonanie polecenia powłoki Linuksa na RTU; w badanych urządzeniach polecenia uruchamiane są z uprawnieniami root. W połączeniu z obejściem auth po TCP prowadzi to do pre-auth RCE z pełnymi uprawnieniami.

Wnioski z inżynierii wstecznej. Claroty wskazuje różne ścieżki w binarium sxether_client: dla UDP wywoływana jest ścieżka get_message_authenticated(...), natomiast dla TCP — get_message(...), bez walidacji.

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie RTU: dowolne polecenia jako root (zmiana logiki procesu, sabotaż, trwała persystencja).
  • Ruch rozgłoszeniowy: UDR obsługuje adresowanie rozgłoszeniowe (0xFF), co może ułatwić hurtowe wykonanie komend na wielu RTU w segmencie.
  • Niski próg ataku: zdalny wektor, brak interakcji użytkownika, brak wymaganych uprawnień → szybka eksploatacja po uzyskaniu dostępu sieciowego. (Parametry CVSS na to wskazują).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe aktualizacje firmware’u SixTRAK/VersaTRAK do wersji wskazanych przez Red Lion / HMS.
  2. Segmentacja i kontrola dostępu:
    • Zablokuj TCP/1594 na granicach segmentów OT; dopuszczaj tylko autoryzowane stanowiska inżynierskie i preferuj UDP/1594 wyłącznie w sieciach zaufanych.
    • Trzymaj RTU za zaporami i poza bezpośrednim dostępem z Internetu (zalecenie CISA).
  3. Monitorowanie/detekcja:
    • Reguły IDS/IPS na połączenia TCP do 1594 oraz charakterystyczne ramki UDR (nagłówek 6-bajtowy, CRC 0x1D0F).
    • Alarmuj na pakiety z destination 0xFF (broadcast UDR).
  4. Twardnienie urządzeń:
    • Wyłącz/ogranicz funkcję zdalnego wykonania poleceń, jeśli urządzenie/wersja na to pozwala; wymuś silne uwierzytelnianie i polityki haseł dla kont Sixnet. (na bazie zaleceń producenta/CISA).
  5. Higiena podatności:
    • Utrzymuj proces zarządzania CVE, sprawdzając NVD/CISA i biuletyny HMS pod kątem kolejnych aktualizacji.

Różnice / porównania z innymi przypadkami

  • Wzorzec „UDP bezpieczny / TCP nie”: rzadki, ale groźny — ta sama logika protokołu zaimplementowana różnie w dwóch stosach transportowych; połączenie z funkcją remote shell eskaluje wpływ do CVSS 10.0.
  • W OT to nie tylko „błąd aplikacji”: funkcja utrzymaniowa (zdalny shell) bywa akceptowalna operacyjnie, ale musi być osłonięta spójną kontrolą auth niezależnie od transportu.

Podsumowanie / kluczowe wnioski

  • Kombinacja CVE-2023-42770 (bypass auth TCP) i CVE-2023-40151 (remote shell jako root) daje pre-auth RCE na RTU Sixnet.
  • Zaktualizuj teraz i odetnij TCP/1594; egzekwuj segmentację sieci oraz monitoruj anomalie UDR.
  • Traktuj narzędzia inżynierskie i protokoły utrzymaniowe jako krytyczne powierzchnie ataku w ICS/OT.

Źródła / bibliografia

  1. Claroty Team82 — pełna analiza techniczna („Roaring Access”, 14 października 2025). (Claroty)
  2. CISA ICSA-23-320-01 — Red Lion SixTRAK / VersaTRAK RTU (16 listopada 2023). (CISA)
  3. NVD — CVE-2023-42770 (auth bypass, CVSS 10.0). (NVD)
  4. NVD — CVE-2023-40151 (remote shell jako root). (NVD)
  5. HMS Networks — strona biuletynów bezpieczeństwa / aktualizacje Red Lion. (hms-networks.com)

Tajwan: NSB raportuje skok ataków cybernetycznych i operacji wpływu z Chin (2025)

Wprowadzenie do problemu / definicja luki

Tajwańskie Biuro Bezpieczeństwa Narodowego (NSB) przedstawiło parlamentowi raport o gwałtownym wzroście aktywności cybernetycznej i operacji wpływu przypisywanych Chinom. Administracja rządowa notuje średnio 2,8 mln prób naruszeń dziennie w 2025 r., co oznacza wzrost o 17% r/r. Główne cele to obronność, telekomunikacja, energia i systemy medyczne. Równolegle obserwowany jest rozwój „armii trolli” i kampanii dezinformacyjnych, coraz częściej wspieranych generatywną AI.

W skrócie

  • Skala: 2,8 mln zdarzeń/dzień w sieciach rządowych; +17% vs 2024.
  • Vektory: spear-phishing, exploity dnia zerowego/„niskiego dnia”, lateral movement, living-off-the-land (LOTL), ataki na łańcuch dostaw i konta chmurowe. (Wnioski na podstawie trendów PRC APT i raportów branżowych).
  • IO/psychowojna: skoordynowane sieci kont, memy i treści krótkie, narracje antyrządowe i anty-USA, rosnące użycie GenAI.
  • Cele sektorowe: obrona, telekom, energia, zdrowie – zarówno szpiegostwo, jak i przygotowanie pod operacje zakłócające.
  • Geopolityka: eskalacja oskarżeń dwustronnych PRC–TWN; incydenty informacyjne wykorzystywane do presji politycznej.

Kontekst / historia / powiązania

Wzmożona aktywność Chin wobec Tajwanu trwa od lat, ale 2024–2025 przyniosły intensyfikację działań: od kampanii dezinformacyjnych w cyklu wyborczym po działania psychologiczne i „nazywanie po nazwisku” przeciwników informacyjnych. Równocześnie Taipei publicznie ostrzegało, że Pekin wykorzystuje generatywne AI do skalowania wpływu w mediach społecznościowych i obniżania zaufania do sojuszu z USA.

Google TAG od lat śledzi sieć DRAGONBRIDGE (Spamouflage) – rozległy ekosystem pro-PRC, który rozlewa się na wiele platform. Mimo niskiego organicznego zaangażowania treści, skala i upór aktora czynią go użytecznym narzędziem saturującym informacyjnie przestrzeń publiczną.

Analiza techniczna / szczegóły luki

TTPs obserwowane/oczekiwane w tym kontekście:

  1. Wejście początkowe: spear-phishing z załącznikami Office/OneNote, linki do hostów złośliwych, nadużycia OAuth, ataki na słabe MFA/bez-MFA; zewnętrzne exploity w VPN/WAF/NGFW. (Uogólnienie na bazie kampanii PRC APT z ostatnich lat.)
  2. Utrzymanie i eskalacja: web-shell’e (np. China Chopper-like), implanty bezplikowe, LOLBins (PowerShell, WMI), kradzież tokenów chmurowych.
  3. Ruch boczny: RDP/SMB, nadużycia AD (DCSync, Golden/Silver Tickets), tunelowanie przez serwery C2 w chmurze.
  4. Cele danych: systemy rządowe i rejestry medyczne (PII/PHI), planowanie obronne, konfiguracje sieci krytycznych.

Warstwa informacyjna (IO):

  • Produkcja treści: krótkie wideo, memy, grafiki – coraz częściej generowane LLM/AI, co ułatwia lokalizację narracji.
  • Dystrybucja: wieloplatformowe sieci kont, cross-postowanie i „podsłony” kont, które TAG cyklicznie usuwa (np. aktywność DRAGONBRIDGE).
  • Narracje: krytyka władz Tajwanu, zniechęcanie do współpracy z USA, wzmacnianie treści pro-Pekin.

Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne dla sektora publicznego: większe prawdopodobieństwo wycieku danych obywateli i informacji wrażliwych dot. obronności.
  • Krytyczna infrastruktura: ryzyko pre-positioning (zakładanie przyczółków na wypadek kryzysu), które może skutkować zakłóceniami w telekomunikacji, energii lub służbie zdrowia.
  • Środowisko informacyjne: obniżanie zaufania społecznego przez kampanie IO, trudniejsze różnicowanie prawdy/fałszu z powodu GenAI.
  • Ryzyko reputacyjne i prawne: eskalacja oskarżeń PRC↔TWN tworzy presję na transparentność i zgodność działań cyber w instytucjach publicznych i firmach współpracujących z rządem.

Rekomendacje operacyjne / co zrobić teraz

  1. Twardnienie dostępu:
    • Wymuszaj FIDO2/Passkeys + politykę „phishing-resistant MFA”; blokuj starsze protokoły (IMAP/POP).
    • Wdrażaj Conditional Access i segmentację dostępu uprzywilejowanego (PAW).
  2. Higiena chmurowa:
    • Monitoruj tokeny odświeżania, nadużycia OAuth, nieużywane aplikacje enterprise; rotuj klucze i sekretne zasoby regularnie.
  3. Patching priorytetowy:
    • „Top 10” ekspozycji perymetru: VPN, e-mail gateways, WAF/NGFW, publikowane serwisy IIS/Apache/Nginx; SLA <7 dni dla krytyków, <24 h przy exploitach „na wolności”.
  4. Detection & Response:
    • Reguły EDR/XDR dla LOLBins (PowerShell/WMI), token-theft, anomalii OAuth, nietypowego użycia certyfikatów i Mimikatz-like; hunt na web-shelle w katalogach niestandardowych.
    • Telemetria DNS/HTTP dla C2 w chmurze (VPS, storage, CDN) i rotating domains.
  5. Ochrona danych i ciągłość:
    • Segmentacja sieci, backup 3-2-1 + testy odtworzeniowe, szyfrowanie PII/PHI w spoczynku i w ruchu.
  6. Odporność informacyjna:
    • Playbooki reagowania na dezinformację: szybkie dementi, „prebunking” narracji, znakowanie treści syntetycznych, współpraca z platformami ds. nadużyć.
  7. Ćwiczenia i testy:
    • Purple-team z TTP aktorów PRC (spear-phish → web-shell → AD); testy tabletop z wątkiem IO (kto komunikuje co, kiedy i jak).
  • Tajwan vs. Zachód: część TTP (phishing, exploity perymetru) jest wspólna, ale skala i intensywność IO wobec Tajwanu jest wyższa ze względu na bliskość geopolityczną i długotrwały spór o suwerenność.
  • Rok 2025 vs. 2024: wzrost wolumenu ataków o ~17% i wyraźniejsze ślady użycia GenAI po stronie przeciwnika.

Podsumowanie / kluczowe wnioski

Tajwan raportuje rekordową presję w cyberprzestrzeni: miliony prób naruszeń dziennie oraz skoordynowane operacje wpływu, coraz częściej wsparte generatywną AI. Dla podmiotów publicznych i operatorów krytycznych to sygnał do podniesienia gotowości – od MFA odpornego na phishing, przez przyspieszone łatanie perymetru i zaawansowany hunting, po procedury reagowania na dezinformację i „prebunking”.

Źródła / bibliografia

  • The Record by Recorded Future – „Taiwan reports surge in Chinese cyber activity and influence operations”, 14 października 2025. (The Record from Recorded Future)
  • Reuters – „Taiwan flags rise in Chinese cyberattacks, warns of 'online troll army’”, 14 października 2025. (Reuters)
  • Taipei Times – „Government network hit by over 2.8 million cyberattacks a day”, 13–14 października 2025. (Taipei Times)
  • Google Threat Analysis Group (TAG) – „New efforts to disrupt DRAGONBRIDGE spam activity”, 26 czerwca 2024. (blog.google)
  • Reuters – „Taiwan says China using generative AI to ramp up disinformation…”, 8 kwietnia 2025. (Reuters)

Qantas potwierdza publikację skradzionych danych klientów. Co wiemy i jak się chronić?

Wprowadzenie do problemu / definicja luki

Australijskie linie Qantas potwierdziły, że przestępcy opublikowali część danych skradzionych podczas incydentu z początku lipca 2025 r. Dane znajdowały się w zewnętrznej platformie używanej przez centrum kontaktowe przewoźnika, a nie w głównych systemach Qantas. Firma uzyskała nakaz sądowy (NSW Supreme Court) ograniczający dostęp i dalszą publikację informacji oraz prowadzi analizę zakresu ujawnienia.

W skrócie

  • Zakres: do ~5,7 mln rekordów klientów, w tym imię i nazwisko, e-mail, numer Qantas Frequent Flyer (czasem także adres, telefon, data urodzenia, preferencje posiłków, płeć). Brak haseł, PIN-ów, danych kart czy paszportów.
  • Źródło incydentu: kompromitacja platformy strony trzeciej powiązanej z obsługą klienta, a nie bezpośrednio systemów Qantas.
  • Sprawcy: kolektyw Scattered LAPSUS$ Hunters powiązany z ekosystemem ShinyHunters/Scattered Spider/LAPSUS$, który w ostatnich tygodniach szantażował wielu klientów Salesforce i zaczął publikować dane po odrzuceniu żądań.
  • Status organów ścigania: FBI i partnerzy czasowo zdjęli część domen używanych do publikacji, ale przestępcy szybko przenieśli infrastrukturę i kontynuowali wycieki.

Kontekst / historia / powiązania

Publikacja danych Qantas wpisuje się w szerszą kampanię wymierzoną w dziesiątki marek korzystających z rozwiązań Salesforce. To ta sama fala, w której potwierdzono m.in. ujawnienie ~7,3 mln kont Vietnam Airlines (nazwy, e-maile, telefony, daty urodzenia, identyfikatory lojalnościowe). Równolegle media i służby informowały o przejęciach/leaku danych innych dużych firm; trend wskazuje na łańcuchowy efekt dostawców oraz ponowną aktywizację „supergrupy” łączącej znane gangi wyłudzeniowe.

Analiza techniczna / szczegóły luki

  • Wektor i środowisko: incydent dotyczył „third-party platform” używanej przez contact center Qantas, a więc systemu obsługującego dane klientów (CRM/CS). Tego typu środowiska często integrują się z CRM (np. Salesforce) i wieloma kanałami komunikacji, co zwiększa powierzchnię ataku i ryzyko przenikania danych między tenantami/instancjami.
  • TTPs grupy: Scattered LAPSUS$ Hunters łączą taktyki grup znanych z inżynierii społecznej/voice-phishingu (vishing), przejmowania tożsamości operatorów wsparcia i nadużyć uprawnień w środowiskach SaaS. Kampania była połączona z szantażem i groźbą publikacji na nowych/lewarowanych „leak sites”; część infrastruktury została chwilowo zdjęta przez organy ścigania.
  • Zakres danych: według Qantas – głównie identyfikatory kontaktowe i lojalnościowe; brak haseł, kart, paszportów. Mimo to kombinacje pól (np. imię+e-mail+FF number+telefon) zwiększają skuteczność phishingu i SIM-swap/social engineering.

Praktyczne konsekwencje / ryzyko

  • Phishing & brand impersonation: spodziewany wzrost wiadomości podszywających się pod Qantas (np. „zmiana lotu”, „zwrot punktów/bon”), z wykorzystaniem numerów Frequent Flyer lub znajomości preferencji posiłków do uwiarygodniania. Qantas już ostrzega klientów przed takimi kampaniami.
  • Fraudy punktowe: choć dane nie wystarczają do logowania, wiedza o stanie konta/poziomie może posłużyć do socjotechniki (przejęcie sesji przez support scam, wyłudzenie kodów 2FA).
  • Ataki międzykanałowe: dopasowanie rekordów z innymi wyciekami (OSINT) podnosi ryzyko kradzieży tożsamości o niskiej intensywności (np. weryfikacje KYC light u partnerów programów).

Rekomendacje operacyjne / co zrobić teraz

Dla klientów Qantas:

  1. Traktuj każdą prośbę „od Qantas” o kliknięcie/udostępnienie danych jako potencjalny scam; samodzielnie wejdź na qantas.com lub użyj oficjalnej aplikacji.
  2. Włącz/utwardź MFA we wszystkich kluczowych usługach (mail, operator, bank); preferuj apki TOTP zamiast SMS.
  3. Monitoruj skrzynkę i konto lojalnościowe; rozważ alerty bezpieczeństwa i blokady zmian profilu przez support bez dodatkowej weryfikacji.

Dla zespołów bezpieczeństwa (linie/lotnictwo, retail, travel):

  • SaaS threat modeling: przegląd integracji z call center/CRM (mapa przepływów danych, zasada najmniejszych uprawnień, separacja tenantów).
  • Hardening dostawców: wymuś MFA phishing-resistant, rotację tokenów API, ograniczenia IP i JIT access dla zespołów zewnętrznych.
  • DLP & UEBA pod SaaS: czujniki anomalii eksportów (duże wolumeny, nietypowe pola), alerty na nietypowe kwerendy.
  • Playbook „data-leak extortion”: gotowe komunikaty, ścieżka prawna (injunction), sekwencja sekwestracji danych i takedown treści; koordynacja z organami (ACSC/FBI).

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

Incydent Qantas różni się od głośnych ataków na Optus/Medibank z 2022 r. – tu mówimy o wycieku z platformy zewnętrznej oraz o kampanii na wielu klientów jednego ekosystemu SaaS, z silnym komponentem szantażu medialnego. Podobieństwo w stosunku do aktualnych wycieków (np. Vietnam Airlines) to profil danych (kontaktowych/lojalnościowych) i wektor SaaS-owy.

Podsumowanie / kluczowe wnioski

  • Qantas potwierdza publikację części skradzionych danych, ale bez haseł i dokumentów tożsamości; ryzyko dotyczy głównie phishingu i nadużyć socjotechnicznych.
  • To element większej kampanii Scattered LAPSUS$ Hunters przeciwko użytkownikom ekosystemu Salesforce; mimo działań organów ścigania wycieki trwają.
  • Organizacje powinny traktować SaaS supply-chain na równi z on-prem w analizie ryzyka, a użytkownicy – wdrożyć podstawowe higieny kont (MFA, weryfikacja źródeł).

Źródła / bibliografia

  1. Qantas – „Information for customers on cyber incident” (aktualizacja 12.10.2025). (Qantas)
  2. Recorded Future News (The Record) – „Qantas confirms cybercriminals released stolen customer data” (14.10.2025). (The Record from Recorded Future)
  3. Reuters – „Qantas says customer data released by cyber criminals…” (12.10.2025). (Reuters)
  4. Dark Reading – „Feds Shutter ShinyHunters Salesforce Extortion Site” (ok. 10.10.2025). (Dark Reading)
  5. Have I Been Pwned – „Vietnam Airlines Data Breach” (październik 2025) – kontekst kampanii. (Have I Been Pwned)

CISA: nowy alert ICS – podatności w module Rockwell Automation 1715 EtherNet/IP Comms (ICSA-25-287-01)

Wprowadzenie do problemu / definicja luki

14 października 2025 r. CISA poinformowała o jednym nowym doradztwie ICS – ICSA-25-287-01 – dotyczącym Rockwell Automation 1715 EtherNet/IP Communications Module (seria 1715-AENTR). Jest to komponent stosowany w redundancji I/O w środowiskach OT/ICS. Doradztwo opisuje problem(y) bezpieczeństwa prowadzące do odmowy usługi (DoS) i utraty komunikacji CIP, co może wpływać na dostępność sterowania procesowego.

W skrócie

  • Kogo dotyczy: użytkownicy modułu Allen-Bradley 1715 EtherNet/IP (1715-AENTR) w systemach redundantnych I/O.
  • Co jest nie tak: podatności umożliwiające DoS – m.in. poprzez specyficzne komunikaty/pakiety CIP powodujące utratę komunikacji z modułem. (Szczegóły w doradztwie CISA).
  • Skutek: zatrzymanie lub degradacja wymiany danych I/O, możliwa utrata dostępności funkcji sterowania.
  • Co zrobić: zastosować aktualizacje/zalecenia producenta, segmentację i filtrowanie ruchu, twardą kontrolę dostępu do sieci OT.

Kontekst / historia / powiązania

CISA regularnie publikuje zbiory doradztw ICS – 14.10.2025 r. ogłoszono właśnie pojedyncze doradztwo skupione na linii 1715. W poprzednich tygodniach agencja publikowała większe paczki doradztw (np. 30.09 i 09.09), co podkreśla utrzymujące się ryzyka w ekosystemie Rockwell/ABB i innych dostawców OT. Najnowszy alert jest kontynuacją tej serii i wskazuje, że wektor DoS w komponentach komunikacyjnych EtherNet/IP pozostaje istotny.

Analiza techniczna / szczegóły luki

Doradztwo ICSA-25-287-01 opisuje problem(y) prowadzące do DoS w module 1715. Z informacji CISA wynika, że komunikacja CIP z przygotowanymi (crafted) ładunkami może doprowadzić do utraty komunikacji z modułem, co skutkuje niedostępnością usługi po stronie urządzenia. (Wskazane są scenariusze, w których specyficzne sekwencje/częstotliwość żądań wywołują błąd i reset/utratę łączności). Szczegółowe atrybuty – w tym zakres wersji i wektory – opisuje karta doradztwa CISA.

Uwaga redakcyjna: CISA niekiedy przypisuje też numery CVE w późniejszych aktualizacjach kart ICSA. Jeśli Twoje procesy GRC wymagają CVE, sprawdź kartę doradztwa producenta i indeksy advisory Rockwell (Trust Center), które są uzupełniane po walidacji.

Praktyczne konsekwencje / ryzyko

  • Dostępność procesu: DoS na łączności CIP może czasowo pozbawić sterownik aktualnych danych I/O z szafy 1715, wpływając na logikę sterowania, redundancję i reakcję na stany awaryjne.
  • Skutki operacyjne: możliwe przejście do stanów bezpiecznych przez moduły I/O, opóźnienia sterowania, a w skrajnych przypadkach przestoje instalacji (w zależności od konfiguracji SIS/HA i watchdogów).
  • Łańcuch dostaw: linia 1715 jest powszechnie wykorzystywana w przemyśle (proces, chemia, nafta-gaz, energetyka). Zakłócenia mogą mieć wpływ na KPI OT (OEE, dostępność, MTBF).

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj ekspozycję
    • Zidentyfikuj wszystkie 1715-AENTR i sprawdź ich wersje firmware/konfigurację sieci. Zachowaj inwentarz w CMDB/asset inventory OT.
  2. Zastosuj poprawki i zalecenia producenta
    • Monitoruj Trust Center / Security Advisories Rockwell i wdrażaj publikowane aktualizacje/mitigacje (w tym firmware, jeśli dostępny). Testuj w środowisku QA/HIL przed produkcją.
  3. Ogranicz powierzchnię ataku w sieci OT
    • Segmentacja (ISA/IEC-62443 z poziomami/zonami), deny-by-default między IT-OT, filtrowanie CIP/EtherNet/IP tylko do zaufanych hostów, brak routingu do Internetu.
    • Zastosuj listy ACL na przełącznikach/industrial firewalls oraz rate-limiting ruchu do modułów 1715. (Dobrą praktyką jest również odseparowanie serwera WWW modułu, jeśli nie jest wymagany operacyjnie). [praktyki ogólne na podstawie zaleceń producenta/CISA]
  4. Monitoring i detekcja
    • Ustaw reguły w IDS/IPS OT na anomalie CIP, monitoruj reset/timeout połączeń, logi urządzeń i zliczanie błędów I/O. Koreluj w SIEM (runbooks SOC/IOC pod DoS CIP).
  5. Plany ciągłości działania
    • Przejrzyj procedury failover i stany bezpieczne. Zweryfikuj, czy zachowania w przypadku utraty I/O są zgodne z HAZOP i analizą ryzyka procesu. (W razie niezgodności – aktualizacja logiki i test FAT/SAT).

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

W przeszłości CISA i Rockwell publikowali liczne doradztwa dot. EtherNet/IP i komponentów komunikacyjnych (np. ControlLogix Ethernet Modules). Dzisiejsze doradztwo koncentruje się jednak na modułach redundancji I/O 1715, które pełnią inną rolę niż moduły sieciowe ControlLogix – ich degradacja wpływa przede wszystkim na dostępność ścieżki I/O w architekturach wysokiej dostępności, zamiast – lub oprócz – typowych implikacji dla ruchu routowalnego w całej szynie.

Podsumowanie / kluczowe wnioski

  • CISA (14.10.2025): Jeden nowy ICS Advisory ICSA-25-287-01 dla Rockwell 1715 EtherNet/IP Comms – głównie ryzyko DoS/utrata komunikacji CIP.
  • Priorytet: inwentaryzacja 1715-AENTR, aktualizacje/mitigacje producenta, segmentacja i kontrola ruchu CIP, monitoring anomalii.
  • Cel: utrzymanie dostępności sterowania i ograniczenie skutków potencjalnego DoS w środowiskach o wysokiej krytyczności.

Źródła / bibliografia

  • CISA – CISA Releases One Industrial Control Systems Advisory (14 października 2025). (CISA)
  • CISA – ICSA-25-287-01: Rockwell Automation 1715 EtherNet/IP Comms Module (karta doradztwa). (CISA)
  • Rockwell Automation – Security Advisories (Trust Center) – wytyczne producenta dot. podatności i aktualizacji. (Rockwell Automation)
  • Rockwell Automation – 1715-AENTR (EtherNet/IP Communications Adaptor Module) – dokumentacja produktu. (Rockwell Automation)
  • CISA – Zestawienia doradztw ICS (wrzesień 2025) – kontekst publikacji. (CISA)

Harvard pierwszą potwierdzoną ofiarą ataku z wykorzystaniem zero-day w Oracle E-Business Suite

Wprowadzenie do problemu / definicja luki

Harvard University potwierdził, że padł ofiarą kampanii cyberprzestępczej wymierzonej w system Oracle E-Business Suite (EBS), gdzie wykorzystano krytyczną podatność typu zero-day. Na stronie wycieku Cl0p opublikowano ponad 1 TB danych rzekomo wykradzionych z Harvardu, co czyni tę instytucję pierwszą oficjalnie potwierdzoną ofiarą głośnej fali ataków na EBS.

W skrócie

  • Cel: środowiska Oracle E-Business Suite (12.2.x).
  • Luka: CVE-2025-61882 – zdalna, bez uwierzytelniania, umożliwiająca RCE; wykorzystywana w atakach przed publikacją poprawek. Oracle wydał pilny alert bezpieczeństwa.
  • Skala: według Google/Mandiant – dziesiątki organizacji objęte szeroko zakrojoną kampanią wymuszania okupu.
  • Status Harvardu: uczelnia potwierdziła incydent i prowadzi dochodzenie; dotknięta ma być „ograniczona liczba podmiotów” powiązanych z niewielką jednostką administracyjną.
  • Dalsze ryzyko: CISA dodała CVE-2025-61882 do katalogu KEV (aktywnie wykorzystywane luki) – natychmiastowe łatanie jest priorytetem.

Kontekst / historia / powiązania

Google Threat Intelligence i Mandiant od 29 września 2025 r. śledzą falę e-maili szantażowych kierowanych do kadry kierowniczej organizacji z informacją o kradzieży danych z EBS. Kampania była aktywna jeszcze przed udostępnieniem łat i – według badań – mogła rozpocząć się nawet kilka tygodni wcześniej. Przestępcy powołują się na markę Cl0p; obserwowane TTP wskazują na wyspecjalizowane grupy zajmujące się włamaniami do systemów pośrednich/ERP.

Analiza techniczna / szczegóły luki

CVE-2025-61882 (Oracle E-Business Suite)
Oracle opisuje podatność jako możliwą do wykorzystania zdalnie i bez uwierzytelnienia, potencjalnie prowadzącą do zdalnego wykonania kodu (RCE). Atak odbywa się „przez sieć” i nie wymaga konta w systemie, co znacznie ułatwia wyzyskanie przez skanery i botnety. Oracle opublikował dedykowany alert z instrukcjami łatania.

CVE-2025-61884 (Oracle EBS Runtime UI – ujawnienie informacji)
Równolegle Oracle wydał awaryjną poprawkę dla kolejnej luki w EBS (12.2.3–12.2.14), która może ułatwiać dostęp do wrażliwych zasobów (eskalacja skutków kradzieży danych/rekonesans). Obie luki razem zwiększają powierzchnię ataku i ułatwiają łańcuchy eksploatacji.

Dowód aktywnej eksploatacji (KEV)
Wpis CISA KEV dla CVE-2025-61882 formalnie potwierdza eksploatację „in the wild” i nakłada presję na szybkie wdrożenie poprawek przez instytucje publiczne i operatorów usług kluczowych.

Praktyczne konsekwencje / ryzyko

  • Ryzyko masowej eksfiltracji danych ERP: moduły EBS (finanse, HR, łańcuch dostaw) zawierają dane wysoko wrażliwe; kompromitacja jednego komponentu może skutkować hurtową kradzieżą rekordów i dokumentów. Potwierdza to przypadek Harvardu (publikacja 1+ TB danych na stronie wycieku).
  • Ryzyko wtórnych włamań: wyciek kont/kluczy integracyjnych z EBS może umożliwiać lateral movement do innych systemów (CRM/HR/finanse). Wnioski z analizy Google/Mandiant wskazują na charakter kampanii „data theft + extortion”.
  • Ryzyko operacyjne: nawet krótkie okno między publikacją PoC (lub prywatnego exploita) a instalacją poprawek wystarcza do automatycznych skanów i przejęć serwerów EBS wystawionych do Internetu. CISA klasyfikuje tę lukę jako aktywnie wykorzystywaną.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast patchować: zastosować poprawki z alertów Oracle dla CVE-2025-61882 i CVE-2025-61884 na wszystkich wspieranych wersjach EBS (12.2.3–12.2.14). Priorytet dla serwerów dostępnych z Internetu/VPN.
  2. Izolacja i ekspozycja: ograniczyć publiczną ekspozycję EBS (WAF, IP allow-list, TLS mTLS, ZTNA), rozdzielić strefy zgodnie z zasadą najmniejszych uprawnień. (Wniosek na bazie charakterystyki luki—zdalna, bez uwierzytelnienia.)
  3. Telemetria i hunting:
    • przejrzeć logi HTTP/Reverse Proxy pod kątem anomalii do końca lipca 2025 r. (GTIG raportuje wcześniejszą aktywność kampanii),
    • szukać masowych transferów, niespodziewanych jobów EBS/Concurrent Processing i nietypowych plików w katalogach aplikacyjnych.
  4. IR i ocena wycieku: jeśli EBS był dostępny z Internetu, założyć kompromitację i przeprowadzić post-exfiltration IR (rotacja kluczy integracyjnych, wymuszenie SSO/MFA, przegląd ról, DLP). (Wniosek wynikający z potwierdzonej eksfiltracji danych w Harvardzie).
  5. Zgodność i notyfikacje: sprawdzić obowiązki prawne (np. zgłoszenia naruszeń, informowanie partnerów), biorąc pod uwagę charakter danych ERP. (Rekomendacja ogólna wynikająca z klasy danych ujawnianych w tej kampanii).

Różnice / porównania z innymi przypadkami

W odróżnieniu od wcześniejszych fal wymuszeń na łańcuchu dostaw (np. kampanie wymierzone w MFT czy oprogramowanie backupowe), obecna kampania atakuje rdzeniowy system ERP (EBS), co bezpośrednio przekłada się na hurtowy dostęp do danych biznesowych. Również nietypowa jest szybka sekwencja dwóch alertów Oracle (RCE i ujawnienie informacji), co sugeruje intensywny rekonesans napastników i/lub odkrywanie kolejnych wektorów w tej samej powierzchni aplikacyjnej.

Podsumowanie / kluczowe wnioski

  • Atak na Oracle EBS z wykorzystaniem CVE-2025-61882 ma charakter szerokiej kampanii; Harvard to pierwsza publicznie potwierdzona ofiara z >1 TB danych na stronie wycieku.
  • Łatanie i twardnienie EBS to priorytet dnia dzisiejszego; CISA klasyfikuje lukę jako aktywnie wykorzystywaną (KEV).
  • Organizacje powinny przyjąć założenie o możliwej eksfiltracji i prowadzić hunting wsteczny co najmniej od końca lipca/września 2025 r., zgodnie z ustaleniami GTIG/Mandiant.

Źródła / bibliografia

  • SecurityWeek: Harvard Is First Confirmed Victim of Oracle EBS Zero-Day Hack (14 października 2025). (SecurityWeek)
  • The Record: Harvard says ‘limited number of parties’ impacted by breach linked to Oracle zero-day (13 października 2025). (The Record from Recorded Future)
  • Oracle Security Alert – CVE-2025-61882 (RCE, EBS). (Oracle)
  • Oracle Security Alert – CVE-2025-61884 (ujawnienie informacji, EBS Runtime UI). (Oracle)
  • Google Threat Intelligence: Oracle E-Business Suite Zero-Day Exploited in Extortion Campaign (9 października 2025). (Google Cloud)

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)