Archiwa: NIST - Strona 64 z 69 - Security Bez Tabu

CVE‑2025‑43300 — ImageIO out‑of‑bounds write (Apple iOS/iPadOS/macOS) — mapowanie MITRE ATT&CK

TL;DR

Luka CVE‑2025‑43300 to błąd zapisu poza bufor (CWE‑787) w ImageIO, wyzwalany podczas przetwarzania specjalnie przygotowanego pliku graficznego (m.in. DNG). Apple potwierdza doniesienia o wykorzystaniu w atakach ukierunkowanych. Patch dostępny m.in. w iOS/iPadOS 18.6.2, 17.7.10, 16.7.12, 15.8.5 oraz macOS Sequoia 15.6.1 / Sonoma 14.7.8 / Ventura 13.7.8. Z perspektywy ATT&CK zdarzenie odwzorowujemy na T1203/T1658 (Exploitation for Client Execution). SOC powinien szukać koincydencji: (1) napływ/miniaturyzacja obrazu (DNG/RAW/JPEG‑L) → (2) awarie/EXC_BAD_ACCESS w QuickLook*/ImageIO → (3) sieć z procesów sandboxowanych, a następnie pilnie aktualizować urządzenia.


Krótka definicja techniczna

CVE‑2025‑43300 to out‑of‑bounds write w frameworku ImageIO prowadzący do korupcji pamięci podczas parsowania złośliwego obrazu. Wektor ataku jest sieciowy (np. treści w komunikatorach, podgląd miniatur, przeglądarka/QuickLook), a wyzwolenie może następować bez pełnej interakcji użytkownika w określonych przepływach, jednak oficjalny wektor CVSS NVD oznacza UI:R. Błąd został naprawiony „poprawioną kontrolą zakresów”.


Gdzie występuje / przykłady platform

  • iOS / iPadOS: poprawki w 18.6.2 (20 VIII 2025), backporty: 16.7.12 i 15.8.5 (15 IX 2025), 17.7.10 (20 VIII 2025).
  • macOS: Sequoia 15.6.1 / Sonoma 14.7.8 / Ventura 13.7.8 (20 VIII 2025).
  • CISA KEV: luka dodana 21 VIII 2025 (termin dla agencji federalnych: 11 IX 2025).
  • Konsekwencje dla SOC: dotyczy stacji macOS oraz urządzeń iOS/iPadOS w BYOD/COPE, MDM i środowiskach hybrydowych (M365/Slack/WhatsApp jako nośnik obrazów). (Łańcuchy ataków z WhatsApp CVE‑2025‑55177 były publicznie raportowane).

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

ImageIO to systemowy framework odpowiedzialny za dekodowanie/miniaturyzację wielu formatów (w tym RAW/DNG). Błąd dotyczy ścieżki dekodowania — w analizach poprawek wskazywano na komponenty RawCamera i JPEG Lossless w DNG; naprawa polega na dołożeniu warunków granicznych (bounds check), co sugeruje klasyczne przepisanie poza zaalokowanym buforem przy niespójności metadanych vs strumień JPEG‑L. Taki prymityw bywa szczególnie cenny, bo może prowadzić do RCE w kontekście procesu przetwarzającego obraz (np. QuickLook* lub serwisy komunikatora). Apple odnotował „ekstremalnie wyrafinowany atak” na wąską grupę celów; niezależne raporty prasy branżowej potwierdzają łańcuchy z udziałem WhatsApp (oddzielna CVE po stronie aplikacji).


Artefakty i logi

Źródło / PlatformaArtefakt / LogCo obserwowaćPrzykład/Id
macOS Unified Loggingprocess == "QuickLookUIService" / QuickLookSatellite / ThumbnailsAgentcrashe/EXC_BAD_ACCESS wokół parsowania obrazu; korelować z otwarciem/miniaturą pliku .dnglog show --last 1h --predicate 'process CONTAINS "QuickLook" AND (eventMessage CONTAINS "EXC_BAD_ACCESS" OR eventMessage CONTAINS "abort")'
macOS CrashReporter~/Library/Logs/DiagnosticReports/*.crashsygnatury KERN_INVALID_ADDRESS dla QuickLook*/aplikacji wyzwalającejWpisy „Exception Type: EXC_BAD_ACCESS (SIGSEGV)” w czasie otwarcia/preview DNG.
Quick Look cache (forensics)/private/var/folders/.../C/com.apple.QuickLook.thumbnailcache (index.sqlite / thumbnails.data)ślady miniatur plików przetwarzanych przez QuickLookUwaga: dostęp ograniczony od Mojave; nadal użyteczne w analizie powłamaniowej.
iOS sysdiagnose/Unified Logszrzuty AUL/sysdiagnoseanomalia w logach ImageIO/QuickLook w oknie atakuMetodyka akwizycji AUL/sysdiagnose do IR.
EDR telemetry (macOS/iOS)Process/File/Crash/Networksekwencja: plik .dng → crash QuickLook*/aplikacji → outbound z procesu sandboxOgólna metodyka korelacji (proces/plik/sieć).
M365 Defender (AH)DeviceCrashEvents/DeviceProcessEvents/DeviceFileEventszdarzenia z hostów macOS (iOS jeśli wspierane przez MDM/defender)Wzorce zapytań w sekcji 7.
CloudTrail[nie dotyczy] (luka kliencka na Apple OS)
K8s audit / ESXi[nie dotyczy]
M365 Audit (Unified Audit Log)[nie dotyczy]

Detekcja (praktyczne reguły)

Sigma (macOS, proces crash + korelacja z DNG)

title: macOS QuickLook/ImageIO Crash After DNG Handling (CVE-2025-43300 Lead)
id: 4a1e2a2d-3f2d-4e05-9f60-ql-dng-crash
status: experimental
description: Detects crashes of QuickLook*/ImageIO-related processes shortly after handling .dng images (possible exploitation attempt of CVE-2025-43300)
author: Badacz CVE
date: 2025/11/11
references:
  - https://support.apple.com/en-us/124925
  - https://nvd.nist.gov/vuln/detail/CVE-2025-43300
logsource:
  product: macos
  category: process_crash
detection:
  sel_proc:
    Image|endswith:
      - "/QuickLookUIService"
      - "/QuickLookSatellite"
      - "/com.apple.quicklook.ThumbnailsAgent"
  sel_msg:
    Message|contains:
      - "EXC_BAD_ACCESS"
      - "SIGSEGV"
  near_file:
    TargetFilename|endswith: ".dng"
  timeframe: 5m
  condition: sel_proc and sel_msg and near_file
fields:
  - Image
  - ParentImage
  - TargetFilename
  - Message
  - CrashType
falsepositives:
  - Uszkodzone/niestandardowe pliki DNG z aparatów
  - Znane błędy QuickLook (wysokie CPU/mem)
level: high
tags:
  - attack.t1203
  - attack.t1658

Splunk (SPL)

Crash + korelacja z DNG w oknie 5 min

(index=edr OR index=os) (sourcetype=mac:crashreporter OR sourcetype=mac:unifiedlog)
(process_name="QuickLookUIService" OR process_name="QuickLookSatellite" OR process_name="com.apple.quicklook.ThumbnailsAgent")
("EXC_BAD_ACCESS" OR "SIGSEGV" OR "KERN_INVALID_ADDRESS")
| eval _time_crash=_time
| join type=inner host
    [ search index=edr sourcetype=mac:file (file_path="*.dng" OR file_name="*.dng")
      | bin _time span=5m
      | stats earliest(_time) as first_seen by host file_path process_name ]
| where abs(_time_crash - first_seen) <= 300
| table _time host process_name file_path Message

KQL (Microsoft 365 Defender, Advanced Hunting)

let crashWin = 5m;
let crashes = DeviceCrashEvents
| where OSPlatform == "macOS"
| where ProcessName in~ ("QuickLookUIService","QuickLookSatellite","com.apple.quicklook.ThumbnailsAgent")
| where CrashType has_any ("EXC_BAD_ACCESS","SIGSEGV","KERN_INVALID_ADDRESS")
| project DeviceId, CrashTime=Timestamp, ProcessName, CrashType;

let dng = DeviceFileEvents
| where OSPlatform == "macOS"
| where FileName endswith ".dng"
| project DeviceId, FileTime=Timestamp, FileName, FolderPath, InitiatingProcessFileName;

crashes
| join kind=innerunique (dng) on DeviceId
| where CrashTime between (FileTime .. FileTime + crashWin)
| project CrashTime, DeviceId, ProcessName, CrashType, FileName, FolderPath, InitiatingProcessFileName
| order by CrashTime desc

AWS CloudTrail / CloudWatch (zapytanie)

[brak danych / nie dotyczy] — luka dotyczy endpointów Apple, nie usług AWS.

Elastic EQL (endpoint)

sequence by host.id with maxspan=5m
  [file where file.extension == "dng" and
     process.name in ("IMTransferAgent","Messages","Safari","Finder")]
  [process where process.name in ("QuickLookUIService","QuickLookSatellite","com.apple.quicklook.ThumbnailsAgent")
     and (event.action == "crashed" or message like "*EXC_BAD_ACCESS*" or message like "*SIGSEGV*")]

Źródła kontekstowe: Apple advisories; ATT&CK T1203/T1658; Unified Logging/QuickLook procesy.


Heurystyki / korelacje

  • Łańcuch czasowy: pojawienie się nowego .dng (z komunikatora/WWW/preview) → crash QuickLook*/aplikacji → nietypowy ruch sieciowy z procesu sandbox (np. krótkie połączenia TLS do świeżych domen).
  • Artefakty miniatur: świeże wpisy w Quick Look cache powiązane z plikiem, nawet jeśli został usunięty.
  • Kampanie łańcuchowe: jeśli w telemetrii widać WhatsApp/Messages poprzedzające crash oraz aktualizacje łatające CVE‑2025‑55177, podnieś priorytet incydentu.

False positives / tuning

  • Uszkodzone lub nietypowe DNG z aparatów/oprogramowania RAW mogą powodować crashe QuickLook bez intencji atakującego. Ogranicz reguły do korelacji DNG + crash + źródło z sieci/komunikatora.
  • Znane problemy wydajnościowe QuickLook (wysokie CPU/awarie) mogą generować szum — filtruj po rozszerzeniu .dng i wąskim oknie czasowym.

Playbook reagowania (SOC/IR)

  1. Triage & isolacja: odseparuj urządzenie (macOS/iOS) od sieci. Zanotuj wersję OS i poziom łatek.
  2. Zbierz dowody:
    • macOS: log collect --last 2h --output ~/suspect.logarchive oraz ostatnie .crash dla QuickLook/aplikacji.
    • iOS: wywołaj sysdiagnose zgodnie z procedurą IR/MDM i zabezpiecz backup.
  3. Łańcuch zdarzeń: skorelkuj plik .dng (DeviceFileEvents/EDR) z crash (DeviceCrashEvents) i ruch sieciowy procesu.
  4. Eradykacja: usuń/freeze nośnik (wiadomość/załącznik), zablokuj domeny IOC jeśli są znane.
  5. Remediacja: aktualizuj do wersji zawierających poprawkę (poniżej) i wymuś update przez MDM.
  6. Hunt wsteczny (30–90 dni): wyszukaj sekwencje DNG → crash QuickLook; sprawdź skrzynki/komunikatory osób wysoko‑profilowych.
  7. Raportowanie: jeśli masz przesłanki łańcucha z WhatsApp, oznacz incydent jako high‑confidence targeted i eskaluj do CSIRT.

Przykłady z kampanii / case studies

  • Apple: w opisach łatek firma wskazała na wysoce wyrafinowany atak na wybrane osoby.
  • CISA KEV: CVE dodane 21 VIII 2025 (patch compliance dla instytucji federalnych do 11 IX 2025).
  • Media / analizy: doniesienia o łańcuchu z CVE‑2025‑55177 (WhatsApp) oraz backportach poprawek przez Apple.
  • Reverse engineering/patche: analiza Quarkslab wskazuje na ścieżkę DNG + JPEG Lossless (RawCamera) i dodane sprawdzenia granic. (Używaj do zrozumienia ryzyka, nie do ofensywy).

12) Lab (bezpieczne testy)

Tylko bezpieczne środowisko testowe / brak exploitów. Celem jest weryfikacja telemetrii i reguł.

  1. Próbki DNG (nieszkodliwe): pobierz legalne przykładowe DNG z publicznych datasetów (np. strony producentów aparatów).
  2. macOS — generowanie miniatur:
    • qlmanage -p ~/Samples/*.dng (podgląd) oraz log stream --style syslog --predicate 'process CONTAINS "QuickLook"' — weryfikuj, że pipeline telemetryczny widzi akcję. (Apple Developer)
  3. Korelacja w SIEM: odtwórz zapytania z sekcji 7 i sprawdź, czy pojawiają się zdarzenia File→Process/Crash (bez crasha, ale z wejściem i logami).
  4. iOS (MDM): dostarcz nieszkodliwy obraz .dng do urządzenia testowego (np. przez AirDrop/MDM Content Push), zbierz sysdiagnose i sprawdź logi ImageIO/QuickLook. (pat_h/to/file)

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK):

  • M1051 – Update Software: wymuszaj szybkie wdrożenie wersji z poprawką.
  • M1040 – Behavior Prevention on Endpoint: reguły EDR blokujące anomalię decode/parserów obrazów.
  • M1031 – Network Intrusion Prevention: sygnatury/heurystyki na C2 po udanym wyzwoleniu.

Powiązane techniki:

  • T1203 / T1658 (egzekucja), T1189 (wejście przez WWW) / T1566 (dostarczenie w wiadomości), w zależności od scenariusza.

Źródła / dalsza lektura

  • Apple advisories: iOS/iPadOS 18.6.2 (20 VIII 2025); macOS Sequoia 15.6.1, Sonoma 14.7.8, Ventura 13.7.8; iPadOS 17.7.10; backporty 16.7.12 i 15.8.5 (15 IX 2025). (Apple Support)
  • NVD/CVE details (CVSS/KEV/chronologia): (CVE Details)
  • MITRE ATT&CK: T1203 (Enterprise), T1658 (Mobile), wersjonowanie v18.0. (MITRE ATT&CK)
  • Opis kampanii/łańcucha z WhatsApp: The Hacker News (backport + łańcuch CVE‑2025‑55177). (The Hacker News)
  • Analiza techniczna patcha/ścieżki DNG/JPEG‑L: Quarkslab. (Quarkslab Blog)
  • Kontekst ImageIO/0‑click powierzchni parsowania: badania o ImageIO/QuickLook i Unified Logging. (googleprojectzero.blogspot.com)

Checklisty dla SOC / CISO (krótko)

SOC (operacyjne):

  • Czy SIEM/EDR ma reguły z sekcji 7 (crash QuickLook*/ImageIO + .dng)?
  • Czy korelujesz zdarzenia plikowe .dng z procesami QuickLook*/aplikacją w oknie ≤5 min?
  • Czy włączono hunting retrospektywny 30–90 dni dla sekwencji DNG → crash → sieć?
  • Czy MDM wymusza aktualizacje do wersji z poprawką?

CISO (strategiczne):

  • SLA patchowania Apple OS zredukowane <14 dni dla VIP/HTA.
  • Polityka monitoringu komunikatorów (telemetria endpointowa) dla załączników obrazów.
  • Testy tabletop dot. 0‑day/0‑interaction w kanałach mobilnych.
  • Przegląd pokrycia ATT&CK: T1203/T1658 + mitigacje M1051/M1040/M1031.

Rekomendacja: potraktować CVE‑2025‑43300 jako priorytet krytyczny na urządzeniach VIP i w zespołach wysokiego ryzyka, wdrożyć aktualizacje i utrzymywać reguły detekcji oparte na sekwencji zdarzeń, nie na pojedynczym sygnale.

CVE-2025-55177 — WhatsApp (iOS/macOS): niepełna autoryzacja komunikatów synchronizacji urządzeń połączonych

TL;DR

CVE‑2025‑55177 to błąd niepełnej autoryzacji w mechanizmie „Linked devices” WhatsAppa (iOS/macOS), który pozwalał niepowiązanemu napastnikowi wymusić przetwarzanie treści spod dowolnego URL na urządzeniu ofiary. Sam w sobie ma umiarkowane CVSS (5.4), ale w łańcuchu z iOS/macOS ImageIO (CVE‑2025‑43300) mógł prowadzić do zero‑click RCE i instalacji spyware w silnie ukierunkowanych kampaniach. Zalecane: aktualizacja WhatsApp ≥ 2.25.21.73 (iOS) / 2.25.21.78 (Business iOS, Mac), włączenie Lockdown Mode dla użytkowników wysokiego ryzyka, przegląd urządzeń połączonych, telemetria sieciowa dla procesu WhatsApp.


Krótka definicja techniczna

Luka wynika z CWE‑863: Incorrect Authorization – niekompletne sprawdzenia uprawnień dla komunikatów synchronizacji urządzeń połączonych w WhatsApp. Skutkiem było wywołanie przez napastnika przetwarzania zdalnej zawartości (arbitrary URL) na urządzeniu ofiary, co w praktyce umożliwiało „podrzucenie” potencjalnie szkodliwej treści parserom systemowym (np. ImageIO).


Gdzie występuje / przykłady platform

  • iOS/iPadOS: WhatsApp < 2.25.21.73, WhatsApp Business < 2.25.21.78 (iPhone/iPad).
  • macOS: WhatsApp < 2.25.21.78.
  • Inne środowiska (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365): brak bezpośredniego wpływu; obserwacje i detekcje mogą jednak korzystać z SIEM/XDR w tych domenach (np. Microsoft Defender XDR, Elastic). [brak natywnego telemetry w CloudTrail/K8s/M365 dla tej luki]

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

Mechanizm Linked devices w WhatsApp umożliwia synchronizację danych czatu między urządzeniem głównym a urządzeniami wtórnymi. W CVE‑2025‑55177 brakowało pełnej autoryzacji wiadomości synchronizacyjnych, przez co osoba niepowiązana mogła spowodować, że klient pobrał/przetworzył treść z arbitralnego URL. W połączeniu z CVE‑2025‑43300 (ImageIO) – zero‑day w parserze obrazów Apple – przetworzona treść mogła wyzwolić korupcję pamięci i wykonanie kodu bez interakcji użytkownika (zero‑click), co zaobserwowano w kampanii ukierunkowanej na ograniczoną liczbę ofiar (≤200). Skuteczność wynika z połączenia: (1) braku UI (brak kliknięcia), (2) „legitymizacji” ruchu przez aplikację zaufaną oraz (3) łańcuchowania z podatnością systemową.


Artefakty i logi

Źródło / ArtefaktPlatformaPrzykład pól/EIDCo szukaćŚcieżka/Notatka
Unified Logs (OSLog)macOSprocess, eventMessage, subsystemWejścia procesu WhatsApp tuż przed crash/alertem, wzmianki o ImageIO, nietypowe URLPrzegląd przez Console.app lub log show; crashy szukaj w DiagnosticReports.
Crash ReportsmacOSRaport .crashCrashe procesu WhatsApp z ramkami ImageIO/CFNetwork~/Library/Logs/DiagnosticReports/ oraz /Library/Logs/DiagnosticReports/.
sysdiagnose / logarchiveiOS/macOSlogarchiveChronologia zdarzeń WhatsApp/CFNetwork, domeny zdalneGenerowanie sysdiagnose i analiza system_logs.logarchive.
Microsoft Defender XDRmacOS/iOS (MTD)DeviceNetworkEvents (RemoteUrl, InitiatingProcessFileName)Połączenia WhatsApp do domen spoza allowlisty (np. *.whatsapp.com/.net, *.fbcdn.net, *.facebook.com)Schemat Advanced Hunting.
Elastic / ECSmacOSevent.category: network, process.name, destination.domainNietypowe domeny pochodzące od procesu WhatsAppEQL/Detection rules.
MDM (Jamf/itd.)iOSinwentarz wersji appWersje < 2.25.21.73/78Procedury zbierania sysdiagnose / inwentarz aplikacji.
CloudTrail / K8s audit / M365Nie dotyczy bezpośrednio (aplikacja kliencka na iOS/macOS)[brak danych / poza zakresem]

Detekcja (praktyczne reguły)

Uwaga: reguły są defensywne i mają charakter wzorców do tuningu pod własne źródła logów; nie opisują sposobu nadużycia.

Sigma

title: WhatsApp connects to non-owned domains (macOS)
id: 5e7f6c7a-1b0b-4b1a-a1c3-WhatsApp-NonOwnedDomains
status: experimental
description: Detects WhatsApp initiating network connections to domains outside known Meta/WhatsApp CDNs which may indicate CVE-2025-55177 abuse chain.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-55177
  - https://www.whatsapp.com/security/advisories/2025
logsource:
  category: network_connection
  product: macos
detection:
  selection:
    ProcessName|contains:
      - "WhatsApp"
  filter_allowed_domains:
    DestinationDomain|endswith:
      - ".whatsapp.com"
      - ".whatsapp.net"
      - ".fbcdn.net"
      - ".facebook.com"
  condition: selection and not filter_allowed_domains
fields:
  - DestinationIp
  - DestinationPort
  - DestinationDomain
  - ProcessName
level: medium
tags:
  - attack.T1658
  - attack.T1203

Wymagane dopasowanie pól do źródeł w Twoim SIEM; logsource i pola zgodne z konwencją Sigma.

Splunk (SPL)

index=endpoint OR index=network
| eval pname=coalesce(process_name, process, Image, InitiatingProcessFileName)
| search pname="WhatsApp" OR pname="WhatsApp Helper"
| eval domain=coalesce(dest_domain, DestinationHostname, url, RemoteUrl)
| where NOT (like(domain, "%.whatsapp.com") OR like(domain, "%.whatsapp.net")
             OR like(domain, "%.fbcdn.net") OR like(domain, "%.facebook.com"))
| stats values(domain) as domains, dc(domain) as uniq by host, pname, dest_ip, dest_port
| where uniq>0

KQL (Microsoft Defender XDR – Advanced Hunting)

DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("WhatsApp", "WhatsApp Helper")
| where isnotempty(RemoteUrl)
| where not(
    RemoteUrl endswith ".whatsapp.com" or
    RemoteUrl endswith ".whatsapp.net" or
    RemoteUrl endswith ".fbcdn.net" or
    RemoteUrl endswith ".facebook.com")
| summarize count(), make_set(RemoteUrl, 10) by DeviceName, bin(Timestamp, 1h)

Pola i tabela zgodne z dokumentacją DeviceNetworkEvents.

CloudTrail query (AWS CLI/CloudWatch)

Nie dotyczy bezpośrednio. Jeśli jednak Twoja organizacja loguje ruch proxy do CloudWatch (np. ALB/CloudFront), zastosuj CloudWatch Logs Insights dla dzienników HTTP, filtrując UA/hosty procesu WhatsApp — przykład do adaptacji:

fields @timestamp, @message
| filter @message like /WhatsApp/ and not @message like /whatsapp\.com|whatsapp\.net|fbcdn\.net|facebook\.com/
| sort @timestamp desc
| limit 100

Elastic / EQL

network where
  process.name == "WhatsApp" and
  not (destination.domain matches "*.whatsapp.com" or
       destination.domain matches "*.whatsapp.net" or
       destination.domain matches "*.fbcdn.net" or
       destination.domain matches "*.facebook.com")

Składnia i kontekst EQL wg dokumentacji Elastic.


Heurystyki / korelacje

  • Sekwencja czasowa: (a) nietypowe połączenie WhatsApp → obca domena → (b) crash/restart aplikacji lub wpisy ImageIO/CFNetwork → (c) ostrzeżenia MTD/XDR nt. anomalii. Koreluj w oknie ±5 min.
  • Kontekst użytkownika: ofiary o profilu wysokiego ryzyka (dziennikarze, NGO, VIP) – priorytet IR. (zero‑click, wysokie TTP APT/komercyjny spyware).
  • Wersje aplikacji/OS: detekcja urządzeń z wersjami poniżej bezpiecznych buildów WhatsApp i OS‑ów z CVE‑2025‑43300 przed poprawką.

False positives / tuning

  • Legalne media/CDN’y inne niż .whatsapp. / .fbcdn. mogą generować ruch (np. podgląd linków, załączniki) — dostosuj allowlistę do telemetrii.
  • Środowiska z TLS inspection / proxy: domena docelowa może być zastąpiona domeną proxy — filtruj po SNI/http_host w logach L7.
  • Aplikacje towarzyszące (np. komponenty WebKit Network/Helper na macOS) mogą mieć inne nazwy procesu — rozszerz listę InitiatingProcessFileName.
  • Brak crashy nie wyklucza próby — atak może nie trafić w podatny parser lub warunki wyścigu.

Playbook reagowania (IR)

  1. Triage i ograniczenie ryzyka
    • Zidentyfikuj urządzenia z WhatsApp < 2.25.21.73 (iOS) / < 2.25.21.78 (Business iOS, Mac). Wymuś aktualizację.
    • Rozważ Lockdown Mode dla użytkowników wysokiego ryzyka (iPhone/iPad/Mac).
    • W WhatsApp: przegląd i usunięcie nieznanych urządzeń połączonych (Linked devices).
  2. Zachowanie materiału dowodowego
    • Na iOS: wygeneruj sysdiagnose (czas, data) i zabezpiecz logarchive.
    • Na macOS: zarchiwizuj Crash Reports i Unified Logs związane z WhatsApp/ImageIO.
  3. Łowy zagrożeń
    • Uruchom reguły z sekcji 7 w XDR/SIEM; skoreluj z domenami, które nie należą do Meta/WhatsApp.
  4. Eradykacja i odtworzenie
    • Aktualizacje OS ze ścieżki CVE‑2025‑43300 (iOS/iPadOS/macOS), reboot.
    • Zresetuj sesje, odśwież tokeny push, rotuj klucze E2E (wylogowanie i ponowne sparowanie urządzeń) — zgodnie z polityką prywatności/ryzyka.
  5. Komunikacja
    • Poinformuj użytkowników o incydencie i konieczności aktualizacji; rozważ noty do zespołu prawnego/PR przy potencjalnej ingerencji spyware.

Przykłady z kampanii / case studies

  • Eksploatacja łańcuchowa: WhatsApp (CVE‑2025‑55177) → Apple ImageIO (CVE‑2025‑43300) → zero‑click na iOS/macOS; ≤200 celów globalnie, profil wysokiego ryzyka.
  • Potwierdzenie KEV (CISA): luka dodana do Known Exploited Vulnerabilities 2025‑09‑02.
  • Doniesienia branżowe: vendor advisories i analizy potwierdzają użycie luki w wysoko ukierunkowanych atakach z łańcuchowaniem do CVE‑2025‑43300.

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w środowisku testowym / bez symulacji eksploitu. Celem jest weryfikacja widoczności i reguł.

macOS

# Sprawdź wersję aplikacji (App Store build)
mdls -name kMDItemVersion "/Applications/WhatsApp.app"

# Szybki podgląd aktywności procesu w logach z ostatnich 2h
log show --last 2h --predicate 'process == "WhatsApp"' --style syslog | head

# Wykaz bieżących połączeń sieciowych aplikacji
sudo lsof -i -a -c WhatsApp

iOS (bez jailbreak)

  • Wygeneruj sysdiagnose (kombinacja przycisków zg. z instrukcją Apple), zgraj i załaduj system_logs.logarchive do narzędzia analitycznego.

XDR/SIEM

  • Uruchom zapytania z sekcji 7 i zweryfikuj, że połączenia do dozwolonych CDN nie generują alertów (tuning allowlisty).

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK):

  • M1051 — Update Software: aktualizacje WhatsApp i OS (iOS/iPadOS/macOS).
  • M1042 — Disable or Remove Feature or Program: ogranicz lub wyłącz „Linked devices” dla grup wysokiego ryzyka (polityka MDM).
  • M1021 — Restrict Web‑Based Content: filtrowanie URL/SNI, SSL inspection z ostrożnością, polityki DLP dla mediów.

Powiązane techniki (do rozważenia w polu):

  • T1071.001 — Web Protocols (C2/Delivery przez HTTP/HTTPS) dla etapów późniejszych lub alternatywnych ścieżek.

Źródła / dalsza literatura

  • NVD — CVE‑2025‑55177 (opis, CVSS CNA 5.4, CWE‑863, KEV): „Incomplete authorization of linked device synchronization messages…”. (NVD)
  • CVE.org — rekord (Meta CNA). (CVE)
  • WhatsApp Security Advisories 2025 (wersje naprawcze; łańcuch z CVE‑2025‑43300). (whatsapp.com)
  • CISA KEV (dodanie do katalogu 2025‑09‑02). (CISA)
  • Apple / CVE‑2025‑43300 (ImageIO, out‑of‑bounds write; backporty): wsparcie i NVD. (Apple Support)
  • Unit 42 (kontekst łańcuchów zero‑click); The Hacker News, SecurityWeek (streszczenia). (Unit 42)
  • Apple forensics i logi: sysdiagnose / logarchive / Crash Reports (ścieżki). (Apple Podcasts)
  • ATT&CK Mobile/Enterprise (T1658, T1664, T1203; v18). (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC:

  • Wdrożone reguły z sekcji 7 (XDR/SIEM) + allowlista domen Meta/WhatsApp.
  • Raport urządzeń z wersjami WhatsApp < 2.25.21.73/78 i OS bez łatki CVE‑2025‑43300.
  • Procedura zbierania sysdiagnose/logarchive i Crash Reports gotowa na żądanie IR.
  • Korelacje: połączenie WhatsApp → obca domena + wpisy ImageIO/crash w ±5 min.

CISO:

  • Polityka MDM: wymuszona aktualizacja WhatsApp/OS; Lockdown Mode dla wysokiego ryzyka.
  • Przegląd i ograniczenie Linked devices w organizacji (edukacja + kontrola).
  • Potwierdzona zgodność z CISA KEV (SLA na patching).
  • Test stołowy: scenariusz zero‑click na urządzeniach mobilnych (triage + komunikacja).

CVE‑2014‑6271 — “Shellshock”

TL;DR

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


Krótka definicja techniczna

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


Gdzie występuje / przykładowe platformy

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

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

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


Artefakty i logi

WarstwaŹródłoPole / EIDWskaźnik / wzorzecNotatki
Aplikacja WWWApache/nginx access/errorUser-Agent, Referer, URI, statusWzorzec funkcji Basha w nagłówkach/parametrach (np. sekwencja funkcja+trailing)Często wzrost 4xx/5xx przed właściwym RCE
System (Linux)auditdtype=EXECVERodzic: httpd/apache2/nginx/cgi-fcgi → dziecko: /bin/bash -c …Łańcuch procesów po RCE
System (Linux)syslog/journaldkomunikaty serwisu WWW/CGINagłe spawny powłoki, błędy CGIKoreluj z access logami
EDR/telemetriaProcesy/siećbash uruchomiony przez konto serwisu WWW + wyjścia do InternetuW tym wywołania narzędzi typu curl/wget
Chmura AWSCloudTrailuserAgent, sourceIPAddress, eventNamePo RCE — nagłe API (np. ListBuckets, GetCallerIdentity, AssumeRole) z roli instancji / nietypowe UACzęsto po próbie dostępu do 169.254.169.254 (IMDS) z hosta ofiary.
K8sAudit logverb, objectRef, userAgentNiespodziewane create pods/exec/attach z SA serwisu WWW; enumeracja secretsEfekt wtórny po RCE w podzie
M365Unified Audit Log[brak bezpośredniego wektora]Koreluj tylko, gdy atak przechodzi w chmurę SaaS

Detekcja (praktyczne reguły)

Sigma (HTTP/CGI — próby Shellshock)

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

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

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

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

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

KQL (Defender for Endpoint / Azure)

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

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

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

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

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

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

Heurystyki / korelacje (co łączyć)

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

False positives / tuning

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

Playbook reagowania (IR)

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

Przykłady z kampanii / case studies

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

Lab — przykładowe kroki

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

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

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


Mapowania (Mitigations, powiązane techniki)

Mitigacje ATT&CK:

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

Powiązane techniki:

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

Źródła / dalsza literatura

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

Checklisty dla SOC / CISO

SOC (operacyjne):

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

CISO (strategiczne):

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

CVE-2014-0160 — „Heartbleed” (OpenSSL TLS/DTLS Heartbeat memory disclosure)

TL;DR

Heartbleed to krytyczna luka w OpenSSL 1.0.1–1.0.1f (oraz 1.0.2‑beta/beta1), w implementacji rozszerzenia TLS/DTLS Heartbeat (RFC 6520). Błędny brak kontroli długości powoduje odczyt do 64 KB pamięci procesu na żądanie, co umożliwia wyciek kluczy prywatnych, haseł, tokenów i ciasteczek sesyjnych — bez śladów w standardowych logach. Naprawa: OpenSSL 1.0.1g lub kompilacja z -DOPENSSL_NO_HEARTBEATS, plus rotacja kluczy/certyfikatów i reset sesji/haseł. CVSS v3.1: 7.5 (HIGH).


Krótka definicja techniczna

CVE‑2014‑0160 to buffer over-read w funkcjach przetwarzających komunikaty Heartbeat w OpenSSL (TLS i DTLS). Złośliwy pakiet żąda odesłania większej liczby bajtów niż faktyczny payload, co skutkuje ujawnieniem fragmentu pamięci procesu serwera/klienta. Błąd dotyczy OpenSSL 1.0.1 (do 1.0.1f włącznie) i został naprawiony w 1.0.1g (07.04.2014).


Gdzie występuje / przykłady platform

  • Linux/Unix: usługi HTTPS (Apache/Nginx), proxy, poczta (IMAPS/POP3S/SMTPS), VPN (np. OpenVPN), serwery aplikacyjne — jeśli linkują do OpenSSL 1.0.1*. Przykładowe dystrybucje z podatnymi pakietami: Debian Wheezy, Ubuntu 12.04.4, CentOS 6.5, FreeBSD 10.0 itd.
  • Urządzenia/IoT/appliance: część routerów/telefonów VoIP/przełączników używających OpenSSL 1.0.1* (stan historyczny).
  • Windows/AD: IIS/Schannel nie były podatne; ryzyko dotyczy aplikacji na Windows, które samodzielnie używały podatnego OpenSSL.
  • Chmury: własne instancje/obrazy z OpenSSL 1.0.1*, komponenty kontenerowe; w AWS/Azure/GCP po stronie klientów/serwerów, a także wszędzie tam, gdzie terminacja TLS odbywa się na oprogramowaniu z OpenSSL 1.0.1*. (Do detekcji przydają się logi IDS oraz logi operacji na certyfikatach, np. ACM/CloudTrail).

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

Rozszerzenie TLS/DTLS Heartbeat (RFC 6520) pozwala okresowo „pingować” drugą stronę bez renegocjacji. W podatnych wersjach OpenSSL błędnie ufano deklarowanej długości payloadu. Napastnik wysyła HeartbeatRequest z małym payloadem i zawyżoną długością; OpenSSL odsyła żądaną liczbę bajtów, dogaszając brakujące bajty z pamięci procesu (do 64 KB na żądanie). Atak można wykonywać wielokrotnie, aż do pozyskania wartościowych artefaktów (klucze prywatne X.509, hasła, tokeny sesji). Naprawa w 1.0.1g dodała kontrolę zakresu i odrzucanie niepoprawnych żądań. Skuteczność ataku wynika z: (1) prostoty (brak uwierzytelnienia), (2) braku śladów w typowych logach aplikacji, (3) wysokiej wartości wycieku (tajemnice kryptograficzne).


Artefakty i logi (SOC)

Źródło/logPole/artefaktWzorzec/anomaliaUwagi
IDS (Suricata/Snort)alert.signature / event.signature„Heartbleed” / „OpenSSL TLS heartbeat read overrun” / „CVE‑2014‑0160”SIDs Snort VRT: 30510–30517 (GID 1). Najpewniejszy sygnał.
Zeeknotice / skrypt ssl/heartbleedAlerty dot. niepoprawnych rekordów HeartbeatWsparcie dodane 2014‑04‑08.
ALB/ELB (AWS) – Connection/Access LogsTLS pola: protokół, cipher, status/connection_statusPiki błędów/nieudanych handshake (pośrednio); korelować z alarmami IDSDo analizy zmian wzorców TLS, nie wykrywa samego Heartbleed.
CloudTrail (AWS ACM/IAM/ACM‑PCA)eventNameImportCertificate, RequestCertificate, UpdateServerCertificate, DeleteServerCertificateŚlad rotacji certyfikatów po łataniu/kompromitacji.
Web serwer (Apache/Nginx)error/accessNietypowe resety połączeń, wzrost 4xx/5xx (wtórnie)Korelacja pomocnicza; zapis TLS payloadu brak. [Uzupełniające]
Windows EIDSchannel/IIS niepodatne; brak natywnych EID dla samej luki. [N/D]
K8s auditpatch/update na Deployment/PodRolling update obrazów po aktualizacji OpenSSLArtefakt zmian remediacyjnych, nie wykrycia. [Ogólne]

Detekcja (praktyczne reguły)

Sigma (IDS → SIEM)

title: Heartbleed (CVE-2014-0160) Detected by IDS
id: 1e1a5bb3-9e6f-45f0-9d7e-ids-heartbleed
status: stable
description: Alerty IDS/IPS wskazujące na próby/wykrycia ataku Heartbleed.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2014-0160
  - https://blog.snort.org/2014/04/sourcefire-vrt-certified-snort-rules_8.html
  - https://zeek.org/2014/04/detecting-the-heartbleed-bug-using-bro/
logsource:
  product: network
  service: ids
detection:
  selection:
    signature|contains:
      - 'Heartbleed'
      - 'heartbeat read overrun'
      - 'CVE-2014-0160'
    # alternatywnie dla Suricata EVE:
    alert.signature|contains:
      - 'Heartbleed'
      - 'heartbeat read overrun'
  condition: selection
fields:
  - src_ip
  - dest_ip
  - dest_port
  - signature
  - classification
falsepositives:
  - Rzadkie; możliwe skanery audytowe (np. nmap ssl-heartbleed)
level: high
tags:
  - attack.T1190
  - attack.T1212

(Źródła reguł i nazewnictwa sygnatur: Snort VRT SIDs 30510–30517; Zeek script ssl/heartbleed.)

Splunk (SPL)

(index=ids (sourcetype=suricata OR sourcetype=snort) OR source="*eve.json")
| spath
| eval sig=coalesce('alert.signature','signature')
| search sig="*Heartbleed*" OR sig="*heartbeat read overrun*" OR sig="*CVE-2014-0160*"
| stats earliest(_time) as first latest(_time) as last values(dest_port) count by src_ip dest_ip sig
| convert ctime(first) ctime(last)

KQL (Microsoft Sentinel / Log Analytics)

Opcja A – CommonSecurityLog (appliance IDS):

CommonSecurityLog
| where DeviceVendor in~ ("Snort","Suricata")
| where Message has_any ("Heartbleed","heartbeat read overrun","CVE-2014-0160")
| summarize cnt=count(), first=min(TimeGenerated), last=max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Message

Opcja B – własna tabela SuricataEve_CL:

SuricataEve_CL
| where event_type_s == "alert"
| where alert_signature_s has_any ("Heartbleed","heartbeat read overrun","CVE-2014-0160")
| summarize cnt=count(), first=min(TimeGenerated), last=max(TimeGenerated) by src_ip_s, dest_ip_s, dest_port_d, alert_signature_s

CloudTrail Lake (AWS) — ślad rotacji certyfikatów po incydencie

SELECT eventTime, eventSource, eventName,
       userIdentity.accountId AS account, userIdentity.type AS actorType,
       requestParameters.certificateArn AS certArn
FROM   aws_cloudtrail_logs
WHERE  eventSource IN ('acm.amazonaws.com','iam.amazonaws.com','acm-pca.amazonaws.com')
  AND  eventName   IN ('ImportCertificate','RequestCertificate','UpdateServerCertificate','DeleteServerCertificate')
  AND  eventTime BETWEEN from_iso8601_timestamp('2025-11-01T00:00:00Z') AND from_iso8601_timestamp('2025-11-08T23:59:59Z')
ORDER BY eventTime DESC;

(Dokumentacja CloudTrail/ACM potwierdza logowanie tych akcji.)

Elastic / EQL / Kibana KQL

EQL:

network where event.module == "suricata" and event.kind == "alert" and
 (suricata.eve.alert.signature : "*Heartbleed*" or
  suricata.eve.alert.signature : "*heartbeat read overrun*")

Kibana KQL:

event.module:"suricata" and event.kind:"alert" and suricata.eve.alert.signature:("*Heartbleed*" OR "*heartbeat read overrun*" OR "*CVE-2014-0160*")

Heurystyki / korelacje (co łączyć)

  • Korelacja IDS ↔ rotacja certyfikatów: alerty Heartbleed na IP serwera + w ciągu 24–72 h zdarzenia ImportCertificate/UpdateServerCertificate (CloudTrail) ⇒ potwierdzenie remediacji lub panic‑rotacji.
  • Anomalie ruchu TLS: wzrost krótkich połączeń do 443/IMAPS/SMTPS z tej samej klasy adresów podczas skanów/eksfiltracji. [wspierające]
  • Ryzyko wtórne: po wycieku klucza prywatnego — podszywanie się (MITM) i odszyfrowanie zarejestrowanego ruchu bez PFS; korelować z wymianą certyfikatów i wymuszaniem PFS.

False positives / tuning

  • Fałszywe pozytywy są rzadkie — sygnatury na poziomie TLS są precyzyjne. Najczęstsze przypadki: testy nmap ssl-heartbleed lub skanery zgodności. Whitelistuj źródła skanerów.
  • Brak alertu ≠ brak ataku — historycznie ataki nie musiały zostawiać śladów w logach aplikacyjnych; rely na IDS/Zeek.

Playbook reagowania (IR)

  1. Izolacja & inwentarz: zidentyfikuj hosty z OpenSSL 1.0.1–1.0.1f/1.0.2‑beta*.
  2. Łatowanie: aktualizacja do OpenSSL 1.0.1g lub nowszej gałęzi; alternatywnie rekompilacja z -DOPENSSL_NO_HEARTBEATS (krótkoterminowo).
  3. Rotacja kryptografii: wygeneruj nowe klucze prywatne, ponownie wydaj certyfikaty, unieważnij stare (CRL/OCSP); w chmurze weryfikuj ślad w CloudTrail (ACM/IAM/ACM‑PCA).
  4. Unieważnienie sesji: wymuś re‑logowanie użytkowników, rotuj tokeny/cookies.
  5. Reset haseł: jeśli wyciek dotyczył serwisów z authem — wymuś zmianę.
  6. Hunting: przeszukaj IDS/Zeek pod kątem wzorców Heartbleed i anomalii TLS; koreluj ze zmianami certyfikatów.
  7. Komunikacja: zgodnie z wymogami regulacyjnymi (np. healthcare — przykłady incydentów niżej).

Przykłady z kampanii / case studies

  • Canada Revenue Agency (CRA) — kradzież 900 numerów SIN w oknie 6h tuż po ujawnieniu luki; zatrzymano podejrzanego.
  • Mumsnet (UK) — reset ~1,5 mln haseł po incydencie powiązanym z Heartbleed.
  • Community Health Systems (USA) — wyciek danych 4,5 mln pacjentów; wektor przypisano exploitacji Heartbleed.
  • Konsekwencje systemowe — Heartbleed przyspieszył powstanie Core Infrastructure Initiative (funding krytycznych OSS).

Lab — przykładowe komendy

Wyłącznie w kontrolowanym środowisku i na własnych hostach.
Celem jest weryfikacja detekcji, nie ofensywa.

Uruchomienie podatnego serwisu (Docker):

# przykładowy obraz demo (podatny OpenSSL)
docker run -d --name hb -p 8443:443 vulnerables/cve-2014-0160

Test wykrycia (Nmap NSE – bezpieczne sprawdzenie):

nmap -p 8443 --script ssl-heartbleed 127.0.0.1

(Nmap skrypt ssl-heartbleed jednoznacznie wskazuje podatność.)

IDS/Zeek:

  • Włącz reguły ET/Suricata lub Snort VRT (SIDs 30510–30517).
  • Zeek: załaduj skrypt policy/protocols/ssl/heartbleed.bro (obecnie w master).

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK Enterprise):

  • M1051 Update Software — szybkie łatowanie (OpenSSL ≥1.0.1g).
  • M1031 Network Intrusion Prevention — IDS/IPS z sygnaturami Heartbleed.
  • (Dodatkowo) M1048 Application Isolation and Sandboxing, M1050 Exploit Protection — ograniczenie skutków.

Powiązane techniki ATT&CK:

  • T1190 Exploit Public-Facing Application — wektor wejścia.
  • T1212 Exploitation for Credential Access — pozyskanie sekretów.
  • T1210 Exploitation of Remote Services — ruch boczny po kompromitacji.

Źródła / dalsza lektura

  • NVD — opis i CVSS v3.1: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). (NVD)
  • Heartbleed.com — zakres wersji i kontekst operacyjny. (heartbleed.com)
  • RFC 6520 — TLS/DTLS Heartbeat Extension. (RFC Editor)
  • OpenSSL 1.0.1g — release notes (fix CVE‑2014‑0160). (slackware.cs.utah.edu)
  • CISA alert — charakterystyka luki i wyciek porcji 64 KB. (CISA)
  • Snort/Suricata — sygnatury wykrywające Heartbleed (SIDs 30510–30517) + dokumentacja aktualizacji reguł. (Snort Blog)
  • Zeek — detekcja Heartbleed. (Zeek)
  • AWS — CloudTrail/ACM (logowanie operacji na certyfikatach) i Connection Logs ALB. (AWS Documentation)
  • Case studies: CRA, CHS, Mumsnet. (TIME)

Checklisty dla SOC / CISO

SOC (operacyjnie):

  • Włączone reguły IDS/IPS na „Heartbleed” (Snort/Suricata/Zeek).
  • Dashbord/alert: korelacja IDS HeartbleedCloudTrail Import/UpdateServerCertificate.
  • Monitoring anomalii TLS (krótkie połączenia, skoki błędów).
  • Procedura natychmiastowej rotacji certyfikatów/kluczy i unieważniania sesji.

CISO (strategicznie):

  • Potwierdzona eliminacja OpenSSL 1.0.1* w środowisku (obrazy bazowe/kontenery).
  • Wymuszenie PFS i polityki silnych zestawów szyfrów.
  • Testy podatności (skan nmap NSE) — wyłącznie autoryzowane.
  • Plan komunikacji i notyfikacji (zgodność regulacyjna); lekcje z incydentów (CRA/CHS).

Uwaga końcowa: Heartbleed to historyczna luka, ale nadal pojawia się w długowiecznych obrazach/urządzeniach. Minimalna obrona to łatanie (M1051), IDS/IPS (M1031) oraz rotacja kryptografii po każdym podejrzeniu ekspozycji.

CVE-2025-52881 — runc: procfs write-redirect

TL;DR

CVE‑2025‑52881 to luka w runc (>=1.0, dotyczy m.in. Docker/containerd/CRI‑O), która pozwala przekierować zapisy do /proc podczas startu nowego kontenera (wyścigi + współdzielone montowania). Skutkiem może być ominięcie etykiet LSM, zapis do niebezpiecznych plików procfs (np. core_pattern, sysrq-trigger), DoS hosta lub ucieczka z kontenera (ATT&CK T1611). Naprawiono w runc 1.2.8, 1.3.3, 1.4.0‑rc.3 – aktualizacja jest kluczowa.


Krótka definicja techniczna

W runc 1.2.7 / 1.3.2 / 1.4.0‑rc.2 atakujący może przekierować operacje zapisu runc do alternatywnych plików procfs poprzez zestaw wyścigów przy współdzielonych montowaniach (np. symlink w tmpfs), co umożliwia zarówno bypass LSM (zapisy do proc/self/attr/*), jak i semi‑dowolny zapis do plików /proc/sys/* (np. kernel/core_pattern), prowadząc do eskalacji/ucieczki lub DoS.


Gdzie występuje / przykłady platform

  • Linux / kontenery OCI: Docker, containerd, CRI‑O (runc jako runtime).
  • Kubernetes (K8s): klastry korzystające z runc na węzłach roboczych (w tym minikube/kind).
  • Chmury: EKS/ECS/Fargate, AKS, GKE oraz Amazon Linux / Bottlerocket – dostawcy opublikowali zaktualizowane AMI/obrazy; AWS podkreśla brak ryzyka „cross‑customer”, ale rekomenduje aktualizacje.
  • Środowiska buildów: Docker BuildKit / docker buildx build (równoległe uruchomienia z niestandardowymi mountami).

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

Mechanizm CVE‑2025‑52881. Runc podczas startu kontenera wykonuje różne zapisy do procfs (np. etykiety LSM w proc/self/attr/*, ustawienia sysctl w proc/sys/*). Przy odpowiednio przygotowanej sytuacji wyścigu z współdzielonymi montowaniami (shared mounts) atakujący może sprawić, że ścieżka docelowa zapisów „wskoczy” na inny plik procfs (m.in. przez symlink w tmpfs), co omija wcześniejsze zabezpieczenia (z 2019 r.) sprawdzające „czy to jest procfs”, bo przekierowanie dalej wskazuje na procfs – tylko nie ten plik. Dzięki temu można m.in.:

  • Wyłączyć lub ominąć stosowanie LSM (AppArmor/SELinux) do procesu kontenera,
  • Zapisać w /proc/sys/kernel/core_pattern i wykorzystać „kernel upcalls” do wykonania pomocy core dump na hoście,
  • Zapisać do /proc/sysrq-trigger i wywołać awaryjne akcje jądra (DoS).

Klasa problemu łączy CWE‑363 (Race Condition enabling link following) i CWE‑61 (Symlink Following).

Konsekwencja w ATT&CK. To typowy wektor T1611: Escape to Host – ucieczka z kontenera do hosta, z potencjałem późniejszej persystencji i ruchu bocznego. MITRE wskazuje kontenery/ESXi/Linux/Windows jako platformy dla tej techniki (w tym kontekście dotyczy Linux/runc).

Wersje naprawione: runc 1.2.8 / 1.3.3 / 1.4.0‑rc.3 (wiele commitów + aktualizacja filepath-securejoin). Dystrybucje (Ubuntu, Amazon Linux/Bottlerocket) opublikowały pakiety i nowe AMI.


Artefakty i logi (tabela)

WarstwaŹródłoPole/IDCo obserwować
Host Linuxauditd / eBPF (tracee/falco)syscall=open/openat/openat2/write + namePróby zapisu do proc/self/attr/*, proc/sys/*, zwł. core_pattern, sysrq-trigger; procesy: runc, containerd-shim-runc-v2, crio.
Host Linuxjournald/kmsgkernelPaniki/rebooty, wpisy o sysrq, błędy LSM/labelingu podczas startu kontenera.
Container runtimecontainerd/crio logsBłędy montowań, ostrzeżenia o symlinkach/„dangling symlink”, retry na start.
Kubernetes auditcreate/update Podspec.containers[].volumeMounts[].mountPropagationBidirectional lub nietypowe mounty wpływające na współdzielenie montowań; korelować z nietypowymi startami podów.
Kubernetes eventsEventsWarning przy montowaniu woluminówOstrzeżenia dot. mount propagation, hostPath; częste restarty.
ECS/EKS (CloudTrail)RegisterTaskDefinition, RunTask, EKS AMI rolloutsJSON payloadWzorce: linuxParameters.tmpfs, nietypowe mountPoints, masowe nowe TaskDefinition po stronie CI/CD. (Indykator zmian/eksperymentów, nie samego ataku).
M365[nie dotyczy] (luka jest w runc/Linux).
Windows EID[nie dotyczy] (runc nie dotyczy Windows containers/runhcs).

Detekcja (praktyczne reguły)

Sigma (Linux/auditd) — wykrycie „niebezpiecznych” zapisów do procfs przez runc/CRI:

title: Runc/CRI writes to dangerous procfs targets (CVE-2025-52881 class)
id: 6b7e7b7c-6a6f-4d2a-9d3b-52881d3f0cve
status: experimental
description: Detect runc/containerd/crio writing to procfs targets linked to container escape/DoS
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-52881
  - https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm
logsource:
  product: linux
  service: auditd
detection:
  syscall:
    syscall|contains:
      - open
      - openat
      - openat2
      - write
  proc_targets:
    name|contains:
      - "/proc/sysrq-trigger"
      - "/proc/sys/kernel/core_pattern"
    name|startswith:
      - "/proc/self/attr/"
      - "/proc/sys/"
  procs:
    exe|endswith:
      - "/runc"
      - "/containerd-shim-runc-v2"
      - "/crio"
  condition: syscall and procs and proc_targets
level: high
tags:
  - attack.t1611
  - cve.2025-52881

Splunk (SPL) – auditd + journald

(index=linux_audit OR sourcetype=linux:audit) ("type=SYSCALL" OR "SYSCALL=")
| rex field=_raw "exe=(?<exe>[^ ]+)"
| rex field=_raw "name=(?<name>[^ ]+)"
| search exe IN ("/usr/bin/runc","/usr/sbin/runc","/usr/bin/containerd-shim-runc-v2","/usr/bin/crio") 
| search name="/proc/sysrq-trigger" OR name="/proc/sys/kernel/core_pattern" OR name LIKE "/proc/self/attr/%"
| stats count min(_time) as first max(_time) as last by host exe name
| where count>0

KQL (Azure / Defender for Containers + K8s Audit)

// K8s audit: podejrzana propagacja montowań
KubeAudit
| where verb in ("create","update")
| where objectRef.resource == "pods"
| extend m = tostring(requestObject.spec.containers[0].volumeMounts)
| where m has "mountPropagation" and m has "Bidirectional"
| project TimeGenerated, userAgent, user.username, namespace=tostring(objectRef.namespace), pod=tostring(objectRef.name), requestObject
// Linux syslog z AMA: wzmianki o sysrq/core_pattern (proxy dla DoS/escape symptomów)
Syslog
| where ProcessName in~ ("runc","containerd-shim-runc-v2","crio")
| where SyslogMessage has_any ("sysrq-trigger","core_pattern","/proc/self/attr/")
| project TimeGenerated, Computer, ProcessName, SyslogMessage

AWS – CloudTrail (CLI/JMESPath) — heurystyka zmian definicji z mountami/tmpfs

Uwaga: CloudTrail nie rejestruje operacji wewnątrz kontenera. Poniższe służy do wykrywania zmian definicji z ryzykowną konfiguracją, które mogą ułatwić wyścigi z montowaniami.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RegisterTaskDefinition \
  --query "Events[?contains(CloudTrailEvent,'\"tmpfs\"') || contains(CloudTrailEvent,'\"mountPoints\"') || contains(CloudTrailEvent,'\"privileged\":true')].[EventTime,Username,Resources]"

Dla EKS: monitoruj rollouty AMI/NodeGroup po publikacjach AWS (patchowane runc w nowych AMI).

Elastic / EQL (Elastic Defend)

file where
  event.category == "file" and event.action in ("open","openat","write") and
  process.name in ("runc","containerd-shim-runc-v2","crio") and
  file.path regex~ """^/proc/(sysrq-trigger|sys/.*|self/attr/.*)"""

Heurystyki / korelacje

  • Korelacja czasu: Pod/Task start → w ~sekundach pojawiają się zapisy do /proc przez runc → następnie nietypowe zdarzenia jądra (sysrq/panika) albo procesy na hoście uruchomione przez helpery kernela (rdzeń → core_pattern).
  • Konfiguracje sprzyjające: mountPropagation: Bidirectional, nadużycia tmpfs/symlinków w łańcuchu build/run, kontenery uprzywilejowane w pipeline’ach.
  • Łańcuchy z innymi lukami: 31133/52565 + 52881 (bypass LSM) → pełny container escape.

False positives / tuning

  • Legalne zapisy runc do /proc/self/attr/* (etykietowanie LSM) – zwykle pojedyncze, na starcie. Ogranicz alerty do:
    • Listy docelowych plików: sysrq-trigger, core_pattern, inne proc/sys/* poza whitelistem;
    • Częstotliwości (burst > X w sekundę);
    • Kontekstu: nietypowe mount propagation / uprzywilejowany kontener / nieznany obraz.
  • W środowiskach z narzędziami testowymi (np. chaos‑engineering) uwzględnij wyjątki czasowe.

Playbook reagowania (IR)

  1. Triage & izolacja: cordon/drain węzła K8s z incydentem; w ECS – wycofaj dotknięte instancje/AMIs; odetnij od sieci segment management.
  2. Weryfikacja wersji: sprawdź runc --version na węzłach; jeżeli <1.2.8/1.3.3/1.4.0‑rc.3 → patch ASAP.
  3. Artefakty: zrzut /var/log/audit/audit.log, journalctl -k, logi containerd/CRI‑O, K8s audit.
  4. Łowy zagrożeń: wyszukaj zapisy do core_pattern / sysrq-trigger; sprawdź, czy nie doszło do restarów/panik; poszukaj procesów hosta tworzących się bezpośrednio po starcie kontenera.
  5. Eradykacja: odtwórz węzły na patchowanych AMI/obrazach (EKS/ECS/Bottlerocket/AL2023) i redeploy workloadów.
  6. Utwierdzenie: egzekwuj PSS/Pod Security Standards; blokuj mountPropagation: Bidirectional; minimalne przywileje; eBPF/Falco policy dla procfs; rotation sekretów.
  7. Retrospektywa: SCM/CI – kto zmienił definicje mountów/tmpfs? Wyciągnij wnioski do „policy as code”.

Przykłady z kampanii / case studies

  • TeamTNT / Hildegard / Peirates – historycznie obserwowano użycie uprzywilejowanych kontenerów, hostPath i innych wzorców prowadzących do Escape to Host (T1611); MITRE pokazuje te przykłady w procedurach techniki.

Uwaga: To analogiczne taktyki „ucieczki do hosta”, nie specyficzne exploity CVE‑2025‑52881.


Lab— przykładowe komendy

Wyłącznie w odizolowanym labie. Poniższe testy nie wykonują destrukcyjnych zapisów; służą jedynie do weryfikacji detekcji.

A. Ścieżka detekcyjna na procfs (bezpieczne cele)

# 1) Włącz auditd reguły (minimal): monitoruj open/write do procfs przez runc
sudo auditctl -w /proc/self/attr/ -p wa -k runc_proc_attr
sudo auditctl -w /proc/sys/ -p wa -k runc_proc_sys

# 2) Uruchom „zwykły” pod (minikube/kind) i obserwuj start – runc pisze do /proc/self/attr/*
#    Detektory powinny złapać pojedyncze, krótkie zapisy (baseline).

# 3) W kontenerze wykonaj bezpieczne odczyty/zapisy:
kubectl run test --image=alpine --restart=Never -- sh -c 'echo 0 >/proc/self/oom_score_adj; cat /proc/self/status >/dev/null; sleep 2'
#    (oom_score_adj na 0 — bezpieczne; brak sysrq/core_pattern!)

B. Heurystyka K8s: mountPropagation

# manifest (do testu reguł K8s-audit; NIE używać na prod)
apiVersion: v1
kind: Pod
metadata: { name: mp-test, namespace: default }
spec:
  containers:
  - name: c
    image: alpine
    command: ["sh","-c","sleep 60"]
    volumeMounts:
      - name: v
        mountPath: /mnt
        mountPropagation: Bidirectional     # <- trigger detekcji
  volumes:
  - name: v
    emptyDir: {}

Zastosuj i potwierdź, że KQL z sekcji 7 zwraca zdarzenie.


Mapowania (Mitigations, powiązane techniki)

Mitigations (MITRE ATT&CK):

  • M1051 Update Software – aktualizuj runc/AMI/OS (naprawa: 1.2.8/1.3.3/1.4.0‑rc.3).
  • M1048 Application Isolation & Sandboxing / PSS – ogranicz syscalle, blokuj uprzywilejowane kontenery i propagację montowań.
  • M1038 Execution Prevention – obrazy minimalne, filesystem read‑only.
  • M1026 Privileged Account Managementnon‑root w kontenerach.

Powiązane techniki ATT&CK:

  • T1611 Escape to Host (główna),
  • T1190 Exploit Public‑Facing Application – typowy wektor dojścia do kontenera przed ucieczką.

Źródła / dalsza lektura

  • MITRE ATT&CK T1611: Escape to Host – opis, wersja 1.6 (24.10.2025). (MITRE ATT&CK)
  • NVD CVE‑2025‑52881 – opis, CVSS v4.0, lista commitów naprawczych. (NVD)
  • GitHub Security Advisory (opencontainers/runc, GHSA‑cgrx‑mc8f‑2prm) – szczegóły techniczne, skutki, wersje fixed. (GitHub)
  • runc releases 1.2.8 / 1.3.3 / 1.4.0‑rc.3 – noty wydania z informacją o 3 CVE. (GitHub)
  • oss‑sec ogłoszenie (Aleksa Sarai) – 3 luki runc, łańcuchowanie z 31133/52565 i rola 52881 jako LSM bypass. (SecLists)
  • Ubuntu CVE‑2025‑52881 / USN‑7851‑1 – status pakietów (wysoki priorytet). (Ubuntu)
  • AWS Security Bulletin AWS‑2025‑024 – wpływ na EKS/ECS/Bottlerocket/AL2023 (brak ryzyka cross‑customer, aktualizacje AMI). (Amazon Web Services, Inc.)

Checklisty dla SOC / CISO

SOC

  • Czy mamy sygnatury/audyt zapisu do procfs przez runc/CRI i K8s‑audit dla mountPropagation?
  • Czy EKS/ECS/hosty mają aktualne AMI/obrazy z runc ≥1.3.3 (lub backport)?
  • Baseline: typowy profil zapisów proc/self/attr/* na starcie kontenera – odstępstwa = alert.
  • Korelować starty kontenerów z anomaliami jądra (sysrq/paniki/rebooty).
  • Monitorować definicje podów/tasków pod kątem uprzywilejowania/propagacji montowań.

CISO / Platform

  • Patch policy: runc/OS/AMI w 48h; roll‑back plan; skan statusu dystrybucji (Ubuntu/AL/… ).
  • PSS/PSA: zakaz privileged, hostPID, mountPropagation: Bidirectional bez wyjątku.
  • Runtime ochrony: eBPF (Falco/Tracee, Elastic Defend) z regułami na procfs.
  • Bezpieczne buildy: kontrola docker buildx i mountów w pipeline; SBOM i image signing.
  • Ćwiczenia IR: scenariusz container escape (ATT&CK T1611) w planie ćwiczeń.

CVE-2025-52565 — runc: ucieczka z kontenera przez montowanie /dev/console (race + symlink)

TL;DR

W runc (silnik OCI używany m.in. przez Docker, containerd, CRI‑O) występuje błąd sprawdzania podczas montowania /dev/pts/$n na /dev/console dla kontenerów z przydzielonym terminalem. Ze względu na wyścigi i śledzenie symlinków atakujący, który kontroluje konfigurację/obraz uruchamianego kontenera, może przekierować bind‑mount i uzyskać możliwość zapisu do chronionych plików w procfs (np. /proc/sysrq-trigger, /proc/sys/kernel/core_pattern), co w praktyce umożliwia DoS hosta lub ucieczkę na hosta. Luka dotyczy m.in. runc 1.0.0‑rc3–1.2.7, 1.3.0‑rc.1–1.3.2 oraz 1.4.0‑rc.1–rc.2; naprawiona w 1.2.8, 1.3.3 i 1.4.0‑rc.3. CVSS v4 (CNA): High (8.4).


Krótka definicja techniczna

CVE‑2025‑52565 to luka w runc, w której bind‑mount /dev/pts/$n → /dev/console wykonywany jest przed zastosowaniem maskedPaths/readonlyPaths. Przy niewystarczających walidacjach możliwe jest podstawienie symlinka i „nadpisanie” celu mountu ścieżką prowadzącą do wrażliwych plików procfs, co może skutkować eskalacją do ATT&CK T1611: Escape to Host.


Gdzie występuje / przykłady platform

  • Linux (host): dystrybucje korzystające z runc (Docker/Containerd/CRI‑O).
  • Kubernetes (AKS/EKS/GKE, on‑prem): każdy klaster, w którym runtime CRI używa runc; pod z tty: true może inicjować wadliwy montaż konsoli.
  • Chmury (AWS/EKS/ECS): AWS potwierdził wpływ nowych luk runc na uruchamianie nowych kontenerów; brak ryzyka między‑klienckiego w usługach zarządzanych (izolacja nie opiera się o kontenery jako granicę bezpieczeństwa).
  • Dystrybucje (Ubuntu/SUSE itd.): doradztwa bezpieczeństwa publikują statusy i aktualizacje pakietów runc.

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

Podczas inicjalizacji kontenera z terminalem runc bind‑mountuje „slave” pty (/dev/pts/$n) pod /dev/console. Przed zaaplikowaniem maskedPaths/readonlyPaths dochodzi do okna czasu, w którym atakujący może podmienić źródło na symlink wskazujący docelowo na ścieżki w procfs. Efekt: zapisy do plików typu /proc/sysrq-trigger (natychmiastowe działania systemowe → DoS) bądź modyfikacja /proc/sys/kernel/core_pattern (przekierowanie core dumpów do programu — wektor eskalacji/persistencji). Łańcuch jest koncepcyjnie podobny do CVE‑2025‑31133, lecz dotyczy innego etapu montowania konsoli. Błąd naprawiono, dodając m.in. walidacje inode, bezpieczne ponowne otwieranie ścieżek i wsparcie TIOCGPTPEER.

Zakres wersji: 1.0.0‑rc3–1.2.7, 1.3.0‑rc.1–1.3.2, 1.4.0‑rc.1–rc.2 → fixed: 1.2.8, 1.3.3, 1.4.0‑rc.3. CWE: 61 (symlink following) oraz 363 (race enabling link following). CVSS v4 (CNA GitHub): 8.4 High (na NVD brak jeszcze własnej oceny). Uwaga: w opisie GHSA pojawia się alternatywna ocena 7.3 High; różnice wynikają z aktualizacji metryk przez źródła.


Artefakty i logi (co zbierać)

ŹródłoArtefakt / logNa co patrzećUwagi
Linux auditdSYSCALL=mount (MS_BIND), open/openat → ścieżki w /proc/sys*, /proc/sysrq-triggerPróby zapisu/otwarcia do ww. plików z procesów uruchamianych w cgroupach kontenerowych (/kubepods/, /docker/, /containerd/).Wysoka wartość dowodowa w korelacji z utworzeniem nowego kontenera.
Sysmon for LinuxEID 11 (FileCreate), EID 1 (ProcessCreate)Tworzenie/zapis do /proc/sys/kernel/core_pattern lub akcji na /proc/sysrq-trigger; łańcuch procesów wskazujący na runc, containerd-shim, dockerd.Wymaga właściwego mapowania pól.
K8s auditcreate Pod/Containerspec.containers[].tty=true lub stdin=true dla obrazów z niskim zaufaniem; nagłe serie interaktywnych podów.Warto mieć polityki OPA/Gatekeeper zakazujące TTY w produkcji.
Docker/containerddzienniki demonaUtworzenie z Config.Tty=true (Docker) lub WithTTY=true (containerd).Pola zależne od journald/syslog.
AWS CloudTrail / CloudWatch Logs (EKS/ECS)RegisterTaskDefinitioncontainerDefinitions[].pseudoTerminal=true (ECS)Pole pseudoTerminal odpowiada --tty.
M365[nie dotyczy]N/D

Detekcja (praktyczne reguły)

Sigma (Linux/auditd) – zapis do krytycznych procfs z kontenera

title: Linux Procfs Write Indicative of Container Escape (CVE-2025-52565 family)
id: 8c2d8b38-6a6d-4ef0-9c43-52565a01
status: experimental
description: Wykrywa próby zapisu do /proc/sysrq-trigger lub /proc/sys/kernel/core_pattern wykonywane przez procesy działające w cgroupach kontenerowych.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-52565
  - https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r
logsource:
  product: linux
  service: auditd
detection:
  selection_paths:
    (file.name|endswith):
      - "/proc/sysrq-trigger"
      - "/proc/sys/kernel/core_pattern"
  selection_syscalls:
    syscall|in:
      - open
      - openat
      - creat
      - write
  container_hint:
    cwd|contains:
      - "/docker/"
      - "/kubepods/"
      - "/containerd/"
  condition: selection_paths and selection_syscalls and container_hint
fields:
  - auid
  - exe
  - comm
  - cwd
  - uid
  - saddr
level: high
tags:
  - attack.t1611
  - cve.2025-52565

Splunk (SPL) – auditd → zapisy do procfs z przestrzeni kontenera

index=linux sourcetype=audit*
(| file IN ("/proc/sysrq-trigger","/proc/sys/kernel/core_pattern")
 OR msg IN ("/proc/sysrq-trigger","/proc/sys/kernel/core_pattern"))
 (syscall IN ("open","openat","creat","write"))
 (cwd="*kubepods*" OR cwd="*docker*" OR cwd="*containerd*")
| stats count min(_time) as first_seen max(_time) as last_seen by host exe comm uid file cwd

KQL (Azure/Microsoft Sentinel – Syslog lub AMA)

Syslog
| where ProcessName has_cs "runc" or ProcessName has_cs "containerd" or ProcessName has_cs "dockerd"
| where SyslogMessage has "/proc/sysrq-trigger" or SyslogMessage has "/proc/sys/kernel/core_pattern"
| where SyslogMessage has_any ("open","write","mount")

CloudTrail/CloudWatch Logs Insights – ECS task def z TTY

fields @timestamp, userIdentity.principalId, eventName, requestParameters.containerDefinitions
| filter eventSource = "ecs.amazonaws.com" and eventName="RegisterTaskDefinition"
| filter requestParameters.containerDefinitions like /"pseudoTerminal":\s*true/
| sort @timestamp desc

Elastic / EQL – pliki procfs

file where
  event.action in ("modification","open") and
  file.path in ("/proc/sysrq-trigger","/proc/sys/kernel/core_pattern") and
  process.container.id != null

Heurystyki / korelacje

  • Nowy kontener z TTY (tty: true / pseudoTerminal: true) + w krótkim czasie próby zapisu do procfs.
  • Nietypowe obrazy/źródła (rejestry spoza allowlist) + TTY + privileged: false (brak konieczności bycia privileged → sygnał zaskakujący).
  • Zmiana core_pattern → koreluj z nagłą aktywnością debugerów/potoków na hoście.
  • Seria nieudanych montowań (MS_BIND) z kontekstu runc w tym samym oknie czasowym co tworzenie pody/konternera.

False positives / tuning

  • Automatyka hosta (configuration management) może legalnie modyfikować core_pattern (Ansible/Puppet/sysctl) — zwykle poza cgroupami kontenerów. Whitelistuj znane narzędzia/ścieżki exe.
  • Sesje debug (kubectl exec -it) w środowiskach deweloperskich z TTY — oznacz jako low risk, jeśli obraz i namespace są zaufane.
  • Agreguj tylko z kontenerów (process.container.id != null / ścieżka cgroup).

Playbook reagowania (SOC / Blue Team)

  1. Identyfikacja
    • Alarm z reguł (powyżej) → zapisz host, container_id, image, pod, namespace, user.
    • Sprawdź wersję runtime: runc --version; crictl --version 2>/dev/null; docker info 2>/dev/null | grep -i 'runc\|containerd'
  2. Tymczasowa izolacja
    • K8s: kubectl cordon <node> i kubectl drain <node> --ignore-daemonsets --delete-emptydir-data (jeśli incydent dotyczy węzła).
    • Zatrzymaj/podmroź podejrzane workloady: kubectl delete pod <pod> -n <ns> lub skaluj do zera.
  3. Triage hosta
    • Zweryfikuj core_pattern i artefakty: cat /proc/sys/kernel/core_pattern dmesg --ctime | egrep -i 'sysrq|core_pattern' ausearch -f /proc/sysrq-trigger -ts recent
  4. Łatanie
    • Zaktualizuj runc min. do 1.2.8/1.3.3/1.4.0‑rc.3 (wraz z restartem node). Sprawdź doradztwa dystrybucyjne (Ubuntu/SUSE).
  5. Hardening
    • Włącz polityki: blokuj TTY w prod (OPA Gatekeeper „Disallow Interactive TTY”).
    • Wymuś readOnlyRootFilesystem, seccomp, ograniczenia capabilities, oraz deny‑listy hostPath.
  6. Dowody/raport
    • Zachowaj logi: auditd, kube‑apiserver audit, journald (dockerd/containerd), CloudTrail.
    • IOC: obrazy, digests, namespace, użytkownik/API client.

Przykłady z kampanii / case studies

  • Zbiorcze doradztwa AWS: trzy luki runc (CVE‑2025‑31133/52565/52881) — brak ryzyka cross‑tenant, zalecenia aktualizacji platform zależnych od runc.
  • Analizy branżowe (Sysdig/ARMO): opisują wektory ucieczki przez procfs i praktyczne wskazówki detekcyjne w środowiskach kontenerowych.
  • oss‑sec: ogłoszenie do vendorów o trzech poważnych lukach runc umożliwiających zapis do dowolnych plików /proc i full breakout.

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w odizolowanym labie/VM, nie w produkcji. Celem jest weryfikacja detekcji i twardnienia, nie eksploatacja.

  1. Weryfikacja wersji i polityk runc --version kubectl get psp,podsecuritypolicies 2>/dev/null || true
  2. Uruchomienie kontrolowanej pracy z TTY (sygnał do telemetrii) kubectl run tty-demo --image=busybox --restart=Never --tty=true --stdin=true -- sh -c 'sleep 300' # Sprawdź w kube-audit/CloudTrail/ECS czy widać tty/pseudoTerminal=true
  3. Walidacja reguł
    • Sprawdź, czy alerty NIE pojawiają się dla zwykłych kontenerów bez TTY.
    • Zasymuluj „niegroźne” odczyty procfs (bez zapisu), aby upewnić się, że reguły nie generują FP dla read‑only.
  4. Hardening
    • Zastosuj OPA Gatekeeper k8sdisallowinteractivetty i sprawdź blokadę tworzenia podów z tty: true.

Mapowania (Mitigations, powiązane techniki)

  • Mitigations (ATT&CK):
    • M1051 Update Software (aktualizacja runc)
    • M1048 Application Isolation and Sandboxing (seccomp, blokada mount, deny hostPath)
    • M1026 Privileged Account Management (brak root/privileged)
    • M1038 Execution Prevention (read‑only FS, minimalne obrazy)
  • Techniki powiązane: T1068 Exploitation for Privilege Escalation (eksploitacja podatności w celu ucieczki), T1610 Deploy Container (wykorzystywanie specjalnie zbudowanego obrazu).

Źródła / dalsza lektura

  • NVD: opis, zakres, wersje, CVSS, CWE. (NVD)
  • GHSA opencontainers/runc (szczegóły techniczne, patchset, metryki). (GitHub)
  • AWS Security Bulletin (EKS/ECS). (Amazon Web Services, Inc.)
  • Ubuntu CVE tracker (opis dystrybucyjny). (Ubuntu)
  • Sysdig: przegląd i detekcja dla trzech CVE runc. (sysdig.com)
  • ARMO: omówienie skutków i zaleceń. (armosec.io)
  • oss‑sec: zawiadomienie do vendorów. (seclists.org)
  • MITRE ATT&CK T1611 Escape to Host (opis techniki, mitigacje). (MITRE ATT&CK)
  • ECS pseudoTerminal (API). (AWS Documentation)

Checklisty dla SOC / CISO

SOC (operacyjnie):

  • Włącz zbieranie auditd + kube‑audit + dzienniki runtime (docker/containerd) na węzłach.
  • Aktywuj reguły detekcji dla zapisu do /proc/sysrq-trigger i /proc/sys/kernel/core_pattern z kontekstu kontenera.
  • Koreluj tworzenie podów/kontenerów z TTY (tty: true / pseudoTerminal:true).
  • Utrzymuj inventory wersji runc i sygnalizuj wersje < 1.2.8 / 1.3.3 / 1.4.0‑rc.3.
  • Testuj polityki Gatekeeper blokujące TTY w prod.

CISO (strategicznie):

  • Zleć natychmiastowe aktualizacje runc w całym łańcuchu (Docker/containerd/CRI‑O, node AMI).
  • Wymuś standardy bezpieczeństwa kontenerów: brak privileged, brak hostPath do ///proc, seccomp/SELinux, RO‑rootfs.
  • Wprowadź „no‑TTY‑by‑default” w produkcji oraz przegląd wyjątków.
  • Ustal RTO/RPO dla incydentów kontenerowych i gotowość do cordon/drain węzłów.

Status ryzyka: High (CNA CVSS v4 8.4). Zastosuj aktualizacje runc (≥1.2.8/1.3.3/1.4.0‑rc.3) i polityki ograniczające TTY, a także zbieraj telemetrię z hostów i warstwy orkiestracji do korelacji zdarzeń.

LPI Security Essentials (Moduł 022.1) – Hash Vs Szyfrowanie

Zanim zaczniesz

Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.

Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.

Czytaj dalej „LPI Security Essentials (Moduł 022.1) – Hash Vs Szyfrowanie”