Archiwa: AI - Strona 83 z 86 - Security Bez Tabu

Tag: AI

Microsoft łata aktywnie wykorzystywaną lukę w jądrze Windows (CVE-2025-62215). Co to znaczy dla Twojej organizacji?

Wprowadzenie do problemu / definicja luki

Podczas listopadowego Patch Tuesday (11 listopada 2025 r.) Microsoft załatał aktywnie wykorzystywaną lukę podniesienia uprawnień w jądrze Windows – CVE-2025-62215. To błąd klasy race condition: atakujący, który ma już możliwość uruchomienia kodu w systemie (np. jako zwykły użytkownik), może „wygrać wyścig” i uzyskać uprawnienia SYSTEM, przejmując pełną kontrolę nad hostem. Microsoft potwierdził obserwacje exploitów w atakach w świecie rzeczywistym (szczegóły kampanii nie zostały ujawnione) i przypisał odkrycie MSTIC/MSRC.

Równocześnie opublikowano łatki do ~63 podatności (według BleepingComputer), w tym czterech oznaczonych przez Microsoft jako „krytyczne” (m.in. GDI+/Graphics Component, Office, Visual Studio, Nuance PowerScribe 360).

W skrócie

  • CVE-2025-62215 (Windows Kernel, EoP) – błąd race condition, pozwala uzyskać SYSTEM po lokalnym wykonaniu kodu; aktywnie wykorzystywany.
  • Zakres aktualizacji – ok. 63 luk (59 „Important”, 4 „Critical” wg ZDI), z czego 29 to EoP i 16 RCE (zestawienie liczbowo różni się nieznacznie między źródłami, zależnie od tego, czy liczone są też aktualizacje Chromium/Mariner).
  • Priorytet – traktować jako pilne; typowy łańcuch: zdalny RCE + lokalny EoP (CVE-2025-62215) = pełne przejęcie hosta.
  • Dodatkowy kontekst – to „lżejszy” miesiąc po październikowej kumulacji (ponad 170 CVE); mimo mniejszej liczby poprawek, ryzyko pozostaje wysokie ze względu na zero-day.

Kontekst / historia / powiązania

Relacje branżowe (SecurityWeek, BleepingComputer, ZDI, Cisco Talos, Qualys) są spójne: mamy jedną potwierdzoną 0-day w kernelu i kilka klas podatności, które często pojawiają się w łańcuchach ataków (Office/GDI+/DirectX/WinSock/CLFS). Talos podaje dla CVE-2025-62215 ocenę CVSS 7.8 i podkreśla „low complexity” przy spełnionych warunkach lokalnego uruchomienia kodu.

Warto odnotować, że Windows 10 przeszedł na ESU (płatne przedłużenie poprawek), co w wielu środowiskach komplikuje zgodność patch-managementu i priorytetyzację.

Analiza techniczna / szczegóły luki

CVE-2025-62215 – Windows Kernel EoP (race condition)

  • Warunek powodzenia: atakujący musi mieć lokalny dostęp i możliwość wykonania kodu (np. po udanym RCE, makrze Office, sideloadingu DLL, LPE przez sterownik, itp.).
  • Mechanizm: współbieżny dostęp do współdzielonego zasobu w jądrze bez właściwej synchronizacji umożliwia modyfikację stanu/struktur i eskalację do NT AUTHORITY\SYSTEM po „wygraniu wyścigu”. Microsoft explicite podkreśla, że exploit wymaga „wygrania race condition”.
  • Łańcuchy ataku w praktyce:
    • Phish → Office RCE (np. CVE-2025-62199/62205/62216) → CVE-2025-62215 (EoP) → trwałość (LsaAddAccountRights, usługi, harmonogram) → C2.
    • Drive-by/plik graficzny → GDI+ RCE (CVE-2025-60724) → kernel EoP.
    • Dev/CI środowiska → VS/Agentic AI RCE (CVE-2025-62214/62222) → kernel EoP.

Inne ważne pozycje (wybór):

  • GDI+ RCE (CVE-2025-60724, CVSS 9.8) – potencjalnie bez interakcji na serwisach parsujących pliki; bardzo groźne w systemach serwerowych skanujących/konwertujących dokumenty.
  • DirectX Graphics Kernel EoP (CVE-2025-60716) – również z elementem race condition (Talos: „high complexity”).
  • CLFS EoP (CVE-2025-60709) – komponent historycznie atrakcyjny dla APT/crimeware (często eksploatowany w poprzednich latach).

Praktyczne konsekwencje / ryzyko

  • Eskalacja po „pierwszym wstrzyknięciu” – 0-day w kernelu zamyka łańcuch ataku, podnosząc uprawnienia z User do SYSTEM; utrudnia triage, bo telemetrycznie wygląda jak „local exploit”, gdy faktyczny wektor był zdalny.
  • Ucieczka z kontenerów/aplikacji „piaskownicy” – w środowiskach z AppContainer/WDAG/ciężkim hardeningiem eskalacja do SYSTEM może obejść izolację.
  • Skutki dla IR/SOC: krótkie okno detekcji; artefakty race condition bywają skąpe; trzeba łączyć alerty z fazy pre-EoP (phish/plik) z nietypowymi zdarzeniami jądra.

Rekomendacje operacyjne / co zrobić teraz

1) Priorytetowe wdrożenie poprawek

  • Windows (wszystkie wspierane edycje): wdrożyć listopadowe cumulative updates. Zgodnie z relacjami branżowymi aktualizacja łata CVE-2025-62215 oraz inne CVE o wysokim ryzyku (GDI+, Office, DirectX).

PowerShell – szybkie sprawdzenie poziomu łatek na hostach

# ostatnie zainstalowane aktualizacje jakościowe
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# sprawdzenie dostępnych aktualizacji (wymaga PSWindowsUpdate)
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -MicrosoftUpdate

# ciche zainstalowanie wszystkich aktualizacji i restart poza godzinami pracy
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot -AutoReboot

Intune – wymuszenie cyklu aktualizacji
Device > Windows > Update rings for Windows 10 and later → Ustaw krótki „Deadline for quality updates” (np. 2 dni) + „Grace period” 0–1 dzień dla krytycznych stacji.

WSUS/SCCM
Zatwierdź „Security Updates” z datą 2025-11-11 dla grup „Pilot” (24–48 h), następnie „Broad” (72–120 h) po smoke-teście zgodności.

2) Weryfikacja wdrożenia

PowerShell – weryfikacja konkretnego KB

# przykładowo sprawdź czy host ma listopadowy CU (KB będzie zależeć od wersji Windows)
$kb="KB5xxxxx"  # wstaw właściwy numer z dokumentacji wydanej dla Twojej wersji
(Get-HotFix -Id $kb -ErrorAction SilentlyContinue) -ne $null

Uwaga: numer KB różni się per wersja (23H2/24H2/25H2/Server). Zweryfikuj dla swojej gałęzi podczas publikacji w MSRC/Release Notes.

3) Wzmocnienie detekcji (MDE/Sysmon/SIEM)

Sysmon – zdarzenia warte korelacji:

  • Event ID 1/5/7/11 (ProcessCreate, ProcessTerminated, ImageLoaded, FileCreate) dla anomalii wokół win32k, ntoskrnl, sterowników grafiki/CLFS;
  • Nietypowe wątki w procesach niskoprzywilejowych prowadzące do zmian usług/kluczy LSA.

Microsoft Defender for Endpoint – zapytania KQL (Advanced Hunting):

// Podejrzane podniesienia uprawnień po niedawnym otwarciu dokumentu
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | where FileName in~ ("cmd.exe","powershell.exe","rundll32.exe","reg.exe")
) on DeviceId
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc
// Szybka detekcja tworzenia usług po EoP
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
| where InitiatingProcessAccountName !in~ ("SYSTEM","LOCAL SERVICE","NETWORK SERVICE")

4) Twarde ograniczenie wektorów wstępnych (do czasu pełnego patchowania)

  • Blokada podglądu w Office / Ochrona przed makrami – błąd Office RCE (CVE-2025-62199/62205/62216) może być łączony z EoP; ogranicz Preview Pane i makra z internetu.
  • Filtrowanie plików graficznych/metafili (GDI+ RCE, CVE-2025-60724) w bramkach, DLP, serwerach konwersji.
  • WDAC / AppLocker – polityki ograniczające uruchamianie binariów spoza zaufanych ścieżek.
  • EDR: monitoruj nietypowe TokenElevationType, SeDebugPrivilege, tworzenie usług, modyfikacje LSA/TTY.

5) Zarządzanie ryzykiem w Windows 10 (ESU)

Jeśli utrzymujesz Windows 10, zaplanuj ESU lub migrację do Windows 11; listopadowe łatki są pierwszym cyklem ESU i brak ich wdrożenia otwiera lukę na hostach „legacy”.

Różnice / porównania z innymi przypadkami

  • Wzorzec „RCE + EoP” jest typowy: w ostatnich latach wiele kampanii łączyło dokument/preview-based RCE (Office/GDI+) z kernel EoP (CLFS/win32k/DirectX). Bieżący zestaw CVE dokładnie wpisuje się w ten schemat.
  • Dynamika Patch Tuesday: po „ciężkim” październiku (ZDI raportował ~177 CVE) listopad wygląda spokojniej liczbowo, ale jakościowo mamy 0-day w kernelu – więc priorytet pozostaje wysoki.

Podsumowanie / kluczowe wnioski

  • CVE-2025-62215 to realne, potwierdzone zagrożenie: aktywny exploit + eskalacja do SYSTEM. Potraktuj jako priorytet P0.
  • Zastosuj listopadowe aktualizacje na Windows/Office/VS/DirectX/GDI+ jak najszybciej, ze szczególnym naciskiem na stacje użytkowników i serwery parsujące dokumenty.
  • W SOC skup się na korelacji: źródłowe zdarzenie (phish/plik) → nietypowe procesy → trwałość po EoP.
  • Jeśli masz Windows 10, upewnij się, że włączone są kanały ESU albo przyspiesz migrację.

Źródła / bibliografia

  1. SecurityWeek – „Microsoft Patches Actively Exploited Windows Kernel Zero-Day” (11.11.2025). Potwierdzenie 0-day (CVE-2025-62215), klasa błędu (race condition), zakres miesiąca. (SecurityWeek)
  2. BleepingComputer – „Microsoft November 2025 Patch Tuesday fixes 1 zero-day, 63 flaws” – liczby, lista kategorii, przypisanie MSTIC/MSRC. (BleepingComputer)
  3. Zero Day Initiative – „The November 2025 Security Update Review” – komentarz techniczny, kontekst (liczby, porównanie do października), akcent na łańcuch RCE→EoP. (Zero Day Initiative)
  4. Cisco Talos – „Microsoft Patch Tuesday for November 2025 — Snort rules and prominent vulnerabilities” – CVSS, krytyczne wpisy (GDI+/Office/VS/DirectX), zasady Snort. (Cisco Talos Blog)
  5. Qualys – „Microsoft Patch Tuesday, November 2025 Security Update Review” – podsumowanie kategorii, opisy GDI+/Office/DirectX, potwierdzenie charakteru CVE-2025-62215. (Qualys)

Popularna biblioteka JavaScript expr-eval z krytyczną luką RCE (CVE-2025-12735)

Wprowadzenie do problemu / definicja luki

W bibliotece expr-eval (popularny parser i ewaluator wyrażeń matematycznych w JavaScript) ujawniono krytyczną podatność pozwalającą na zdalne wykonanie kodu (RCE) po przekazaniu złośliwego obiektu „kontekstu” do funkcji evaluate(). Problem został oznaczony jako CVE-2025-12735, a według oceny CISA (CVSS 3.1) ma wagę 9.8 – CRITICAL. Luka dotyczy zarówno oryginalnego pakietu expr-eval, jak i aktywnie utrzymywanego forka expr-eval-fork (naprawa dostępna od wersji 3.0.0).

W skrócie

  • Co: RCE poprzez złośliwe funkcje w obiekcie kontekstu przekazywanym do Parser.evaluate().
  • Zakres: expr-eval (oryginalny projekt) i expr-eval-fork (fork).
  • Nasilenie: CVSS 9.8 (CISA ADP).
  • Status poprawek: stabilna poprawka w expr-eval-fork v3.0.0; dla oryginalnego repo istnieje PR z łatą (#288), ale brak nowego wydania. Rekomendowana migracja do forka 3.0.0+.

Kontekst / historia / powiązania

expr-eval jest powszechnie używany w kalkulatorach webowych, narzędziach edukacyjnych, finansowych oraz – coraz częściej – w systemach NLP/AI, które parsują fragmenty matematyczne z tekstu. Oryginalne repozytorium jest rozwijane nieregularnie; społeczność utrzymuje forka expr-eval-fork, który wcześniej rozwiązywał inne kwestie bezpieczeństwa i utrzymania. CERT-CC i NVD odnotowują, że biblioteka ma setki zależności pośrednich, co zwiększa zasięg oddziaływania podatności.

Analiza techniczna / szczegóły luki

Przyczyna: Funkcja evaluate() przyjmuje obiekt context (zbiór zmiennych i funkcji dostępnych w wyrażeniu). Brak prawidłowej walidacji/ograniczeń umożliwia przekazanie obiektów-funkcji, które parser następnie wywołuje w trakcie ewaluacji. To otwiera drogę do wykonywania niepożądanego kodu – w środowisku Node.js nawet do wywołań systemowych. NVD klasyfikuje problem jako skutkujący przejęciem poufności, integralności i dostępności (C:H/I:H/A:H).

Stan poprawek:

  • expr-eval-fork: wydanie 3.0.0 zawiera allowlist bezpiecznych funkcji, mechanizm rejestracji funkcji użytkownika i testy wymuszające ograniczenia.
  • expr-eval (oryginalne): istnieje Pull Request #288 od CERT-CC z analogiczną łatą; brak potwierdzanej publikacji nowej wersji w npm.

Identyfikatory i doradztwa: CVE-2025-12735, GHSA-jc85-fpwf-qm7x (GitHub Advisory).

Minimalny przykład zagrożonego wzorca (edukacyjnie, bez payloadu)

import { Parser } from 'expr-eval';

// Niebezpieczne: bezkrytyczne przekazywanie "context" z funkcjami od użytkownika
const parser = new Parser();
const expr = parser.parse('customFn(x) + y');

// "context" pochodzi np. z wejścia użytkownika (to błąd!)
const unsafeContext = {
  x: 2,
  y: 3,
  // użytkownik może wstrzyknąć dowolną funkcję
  customFn: (n) => n * 10,
};

console.log(expr.evaluate(unsafeContext));

Wniosek: Sam fakt, że funkcje z kontekstu są wywoływane, stanowi wektor wykonania kodu. W Node.js zamiast nieszkodliwego n * 10 atakujący może próbować odwołań do zasobów środowiska. Naprawa polega na odrzuceniu funkcji z kontekstu, whitelisting i jawnej rejestracji dopuszczalnych funkcji.

Praktyczne konsekwencje / ryzyko

  • Aplikacje serwerowe (Node.js): ryzyko RCE i dostępu do zasobów hosta, w tym plików, poświadczeń czy usług sieciowych. CVSS 9.8 od CISA odzwierciedla pełen kompromis (C/I/A = H).
  • Front-end (przeglądarka): brak bezpośredniego dostępu do systemu, ale możliwość nadużyć (kradzież tokenów, interakcje z API w kontekście użytkownika).
  • Łańcuch dostaw: biblioteka jest zależnością pośrednią w wielu projektach — podatność może „dotrzeć” do Was nawet, jeśli nie importujecie jej wprost.

Rekomendacje operacyjne / co zrobić teraz

1) Szybka weryfikacja zależności

  • SBOM/grep: # npm npm ls expr-eval expr-eval-fork || true # pnpm pnpm ls expr-eval expr-eval-fork || true # yarn yarn why expr-eval || true
  • Skan doradztw: sprawdź GHSA i CVE w pipeline (np. npm audit, GitHub Dependabot).

2) Aktualizacja i pinning

  • Preferowany wariant: natychmiast **migruj do expr-eval-fork ≥ 3.0.0. npm i expr-eval-fork@^3.0.0 # lub w package.json ustaw: # "overrides": { "expr-eval": "npm:expr-eval-fork@^3.0.0" } Jeśli używacie pakietu, który pośrednio ciągnie expr-eval, rozważcie overrides/resolutions albo zgłoście issue do maintenera.
  • Oryginalny expr-eval: dopóki nie ma wydania z łatą, nie polegajcie na tym pakiecie w kontekście niezaufanego wejścia. PR #288 istnieje, ale brak gwarancji release’u.

3) Dodatkowe twarde zabezpieczenia (defense-in-depth)

  • Blokada funkcji w kontekście: nie przekazuj żadnych funkcji z danych użytkownika; jeśli musisz, stosuj allowlistę i własną fabrykę funkcji.
  • Sandboxing: w Node.js rozważ izolację ewaluacji (np. oddzielny proces/VM, worker_threads, ograniczone uprawnienia).
  • WAF / filtrowanie: ogranicz długość, znaki i słowa kluczowe w wyrażeniach, jeżeli użytkownicy dostarczają stringi do ewaluacji.
  • Logowanie i detekcja anomalii: monitoruj nietypowe wyrażenia i błędy parsera.

4) Testy regresyjne – przykład „bezpiecznego” wzorca po aktualizacji

import { Parser } from 'expr-eval-fork';

// jawna rejestracja dopuszczalnych funkcji
const allowed = {
  abs: Math.abs,
  ceil: Math.ceil,
  floor: Math.floor,
  // ...lista minimalna, bez funkcji dostępowych
};

const parser = new Parser({ functions: allowed });

// Do wyrażenia przekazujemy wyłącznie PRYMITYWY (liczby/napisy/boole)
// i ewentualnie nazwy dopuszczonych funkcji; brak dowolnych obiektów-funkcji
const expr = parser.parse('abs(x) + ceil(y)');
const safeContext = { x: -3.14, y: 2.2 };

console.log(expr.evaluate(safeContext)); // 6

5) Działania w CI/CD

  • Wymuś fail build przy wykryciu expr-eval < bezpiecznych wersji (policy as code).
  • Dodaj overrides/resolutions w monorepo i lockfile maintenance.
  • Publikuj nową wersję swoich bibliotek, aby konsumenci dostali zależność z poprawką (tzw. republish chain).

Różnice / porównania z innymi przypadkami

  • Analogiczne klasy błędów: CWE-94 („Improper Control of Code Generation”) – sytuacje, gdy system pozwala na wstrzyknięcie kodu poprzez „rozszerzalne” mechanizmy (np. eval-like, dynamiczne funkcje, konteksty). W expr-eval problem był subtelny, bo dotyczył wywoływania funkcji z kontekstu, a nie tylko parsowania tekstu. (Por. wpisy doradcze GHSA/NVD.)
  • Różnica do klasycznych XSS/RCE: tu łańcuch dostaw oraz biblioteka „bezpieczna zamiast eval” paradoksalnie stała się wektorem RCE przy niewłaściwej walidacji/konfiguracji.

Podsumowanie / kluczowe wnioski

  • CVE-2025-12735 to krytyczna luka w expr-eval umożliwiająca RCE przez złośliwe funkcje w kontekście evaluate().
  • Najbezpieczniejsza ścieżka: migracja do expr-eval-fork 3.0.0+, pinning i republish bibliotek zależnych.
  • Nawet po aktualizacji stosuj zasadę najmniejszego zaufania wobec wejścia użytkownika i allowlistę funkcji.
  • Zweryfikuj łańcuch zależności – podatność często wchodzi pośrednio.

Źródła / bibliografia

  • BleepingComputer: pierwsze doniesienia, status patchy i rekomendacja migracji do expr-eval-fork 3.0.0. (BleepingComputer)
  • NVD (CVE-2025-12735) – opis, metryki, referencje, CVSS 9.8 wg CISA-ADP. (NVD)
  • CERT-CC Vulnerability Note VU#263614 – opis techniczny, wpływ na projekty AI/NLP, zalecenia. (kb.cert.org)
  • GitHub PR #288 (silentmatt/expr-eval) – propozycja łaty od CERT-CC, status w oryginalnym repo. (GitHub)
  • GitHub Advisory (GHSA-jc85-fpwf-qm7x) – doradztwo bezpieczeństwa. (GitHub)

LPI Security Essentials (Moduł 022.4) -Szyfrowanie Danych

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.4) -Szyfrowanie Danych”

Microsoft ujawnia „Whisper Leak”: atak boczny ujawniający temat rozmów z LLM mimo szyfrowania

Wprowadzenie do problemu / definicja luki

Microsoft opisał nowy atak boczny na zdalne modele językowe (LLM), nazwany Whisper Leak. Pozwala on pasywnemu podsłuchującemu — np. operatorowi sieci, atakującemu w tej samej sieci Wi-Fi lub obserwatorowi na łączu — wnioskować o temacie rozmowy z chatbotem, mimo że ruch jest szyfrowany (HTTPS/TLS). Skuteczność ataku wynika z analizy metadanych ruchu: rozmiarów i czasów nadejścia pakietów podczas strumieniowania odpowiedzi modelu. To nie jest błąd kryptograficzny TLS, tylko nadużycie informacji ujawnianej przez samą naturę strumieniowania tokenów.

W skrócie

  • Co wycieka? Nie treść wiadomości, lecz klasa/temat rozmowy (np. pytania o pranie pieniędzy, zdrowie, politykę).
  • Jak? Klasyfikator uczy się wzorców z sekwencji rozmiarów pakietów i odstępów czasowych przy strumieniowaniu odpowiedzi.
  • Skuteczność: Microsoft raportuje dla wielu popularnych modeli wyniki >98% AUPRC; w scenariuszu 1 rozmowa na 10 000 „szumu” możliwa jest 100% precyzja przy 5–50% pokrycia przypadków docelowych.
  • Kto załatał? Po jawnej koordynacji dostawcy tacy jak OpenAI, Mistral, Microsoft, xAI wdrożyli pierwsze obfuscatory strumienia (dodawanie losowego tekstu / parametry API) i inne utrudnienia.
  • Ryzyko: Realne dla użytkowników w środowiskach podwyższonego nadzoru (ISP, sieci publiczne), organizacji korzystających z LLM w wrażliwych domenach (prawo, zdrowie, compliance).

Kontekst / historia / powiązania

Whisper Leak wpisuje się w rosnące portfolio ataków kanałami pobocznymi na LLM:

  • Token-length side-channel (USENIX ‘24) — na podstawie długości tokenów (wnioskowanej z rozmiarów pakietów) rekonstruowano częściowo odpowiedzi oraz temat rozmowy.
  • Remote timing attacks (2024) — wykorzystują zależności czasowe w efektywnym wnioskowaniu (np. speculative decoding) do rozpoznawania właściwości promptu/odpowiedzi.

Microsoft buduje na tych pracach, łącząc rozmiary i timingi pakietów w jeden wektor cech i pokazując, że to wystarcza do trafnego klasyfikowania tematów w ruchu szyfrowanym.

Analiza techniczna / szczegóły luki

Założenie ataku: napastnik passive network observer ma podgląd do ruchu TLS między klientem a usługą LLM, ale go nie deszyfruje.

Powierzchnia ataku: większość klientów LLM strumieniuje odpowiedź — tokeny (lub małe grupy tokenów) są wysyłane na bieżąco. Dla TLS oznacza to ciąg pakietów o pewnych rozmiarach i przerwach. Ponieważ rozmiar szyfrogramu ~ rozmiarowi plaintextu + stałe narzuty, wzorce długości i czasu stają się „odciskiem palca” danego tematu i sposobu generacji.

Pipeline Whisper Leak (upraszczając):

  1. Zbieranie próbek: generowanie zestawu wariantów pytań z wrażliwego tematu (POC: „legalność prania pieniędzy”) oraz dużego zbioru losowych pytań-szumu; rejestrowanie ruchu (np. tcpdump) dla różnych dostawców/modeli.
  2. Ekstrakcja cech: sekwencje (size_i, Δt_i) z ruchu TLS podczas strumieniowania.
  3. Uczenie: klasyfikatory sekwencji (LightGBM, Bi-LSTM, DistilBERT z bucketami rozmiaru/czasu).
  4. Ewaluacja: metryka AUPRC na zbiorze ekstremalnie niezrównoważonym (np. 1:10 000 target:noise). Wynik: >98% dla wielu usług; w praktycznym modelu nadzoru wysoka precyzja przy istotnym recall.

Dlaczego to działa?

  • Autoregresja i (niekiedy) optymalizacje efektywności wprowadzają zależne od danych różnice czasowe.
  • TLS nie ukrywa rozmiarów i timingów rekordów/aplikacyjnych ramek; to metadane.

Minimalny PoC zbierania cech (edukacyjnie):

# przechwyć sesję HTTPS do dostawcy LLM (np. domena api.*)
sudo tcpdump -i eth0 -w llm.pcap 'tcp port 443 and host api.example-llm.com'

# wyodrębnij rozmiary i interwały z PCAP (pyshark)
import pyshark, numpy as np
cap = pyshark.FileCapture('llm.pcap', display_filter='tcp && tls')
sessions = {}
for p in cap:
    key = (p.ip.src, p.tcp.stream) if 'TLS' in p else None
    if not key: continue
    ts = float(p.sniff_timestamp)
    size = int(p.length)  # długość ramki
    sessions.setdefault(key, []).append((ts, size))
features = []
for k, seq in sessions.items():
    seq.sort()
    dts = np.diff([t for t,_ in seq], prepend=seq[0][0])
    feats = list(zip([s for _,s in seq], dts))
    features.append(feats)
print("sesji:", len(features))

(Powyższe służy naukowym ćwiczeniom nad detekcją wewnętrzną — nie do nadużycia).

Praktyczne konsekwencje / ryzyko

  • Model zagrożeń: ISP, operator chmury pośredniczącej, współużytkownicy Wi-Fi, każdy z możliwością passive sniffing.
  • Co można wywnioskować? Temat konwersacji (np. przestępczość finansowa, medyczne zapytania, poglądy polityczne). To wystarczy do profilowania i wyzwolenia działań (cenzura, targetowanie).
  • Sektory wrażliwe: prawo, zdrowie, finanse, sektor publiczny, media/NGO w krajach restrykcyjnych.
  • Skala: badanie obejmowało 28 modeli głównych dostawców; część z nich osiągała wyniki umożliwiające nadzór na masową skalę.

Rekomendacje operacyjne / co zrobić teraz

Dla dostawców/usług LLM (serwer)

  1. Obfuskacja strumienia odpowiedzi — dodawanie losowego tekstu o zmiennej długości do chunków strumieniowych (wprowadzono m.in. w OpenAI, Azure; Mistral dodał dedykowany parametr). Silnie obniża skuteczność ataku.
  2. Batching tokenów (np. wysyłanie co 3–5 tokenów zamiast pojedynczych) — wygładza wzorce. Trade-off: większa latencja „pierwszego znaku”.
  3. Packet injection / cover traffic — wtryski dodatkowych ramek/”szumu” (koszt: 2–3× narzut pasma).
  4. Tryb niestreamingowy (opcjonalny) — umożliwienie klientom żądania odpowiedzi bez strumienia dla zapytań wrażliwych.
  5. Ciągła ewaluacja — testy regresyjne pod kątem wycieków metadanych (AUPRC/ROC na syntetycznych zbiorach tematów).

Dla integratorów/architektów (klient, brzeg)

  • Wyłącz strumieniowanie dla przepływów „tajemniczych” (domyślnie stream=False / brak streamu w większości SDK). Segmentuj ruch (oddzielny endpoint/trasowanie dla zapytań wrażliwych).
  • Preferuj dostawców z wdrożonymi mitigacjami (OpenAI, Azure, Mistral, xAI — wg stanu na 7–9 listopada 2025).
  • VPN/zero-trust egress na wyjściu organizacji (utrudnia lokalnym przeciwnikom korelację strumienia, choć nie eliminuje ataku u dostawcy/ISP).
  • Buduj detektory anomalii na własnych bramach (np. wykrywanie nietypowych wzorców TLS/HTTP2 dla usług LLM, by lokalnie oceniać ryzyko ekspozycji).

Dla zespołów bezpieczeństwa (SOC/Blue)

  • Policy awareness: oznacz tematy wrażliwe i wymuś polityki non-streaming + dostawcy z mitigacjami.
  • Monitoring: rejestrowanie metryk egress (rozmiary rekordów, jitter) w kanałach do usług LLM, by audytować zgodność.
  • Szkolenia użytkowników: nie zadawać pytań o wysokiej wrażliwości przez LLM w sieciach niezaufanych (hotele, kawiarnie).

Przykładowe „kontrole” w praktyce (demo):

  • Blokowanie strumieniowania po stronie reverese-proxy (np. endpoint „sensitive” przekierowany do niestreamingowej ścieżki API).
  • Kontrola jakości dostawcy — test A/B: wysyłaj paczkę 100 pytań „sensitive” i 10 000 pytań „noise”; mierz AUPRC własnym klasyfikatorem metadanych — jeśli > próg (np. 0.9), eskaluj do zmiany dostawcy/konfiguracji.

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

  • Whisper Leak vs. Token-length (Weiss et al. 2024): Weiss celował w rekonstrukcję treści bazując na długościach tokenów; Whisper Leak skupia się na klasyfikacji tematu na bazie rozmiarów i timingów pakietów — skuteczne nawet, gdy usługodawca grupuje tokeny.
  • Whisper Leak vs. Remote Timing (Carlini & Nasr 2024): Carlini/Nasr eksploitują optymalizacje efektywności (np. speculative decoding) i subtelne różnice czasowe; Whisper Leak korzysta z makro-wzorca strumienia (rozmiar+czas) i działa na popularnych usługach.

Podsumowanie / kluczowe wnioski

  • Metadane ruchu LLM potrafią zdradzić temat rozmowy mimo TLS.
  • Atak jest praktyczny przy masowym nadzorze (ISP/Wi-Fi), co rodzi realne ryzyka dla prywatności i compliance.
  • Mitigacje istnieją, ale to trade-off koszt/latencja/jakość i nie dają pełnej eliminacji — potrzebny defense-in-depth po stronie dostawcy i rozsądna higiena użytkowania po stronie klienta.

Źródła / bibliografia

  1. Microsoft Security Blog — Whisper Leak: A novel side-channel attack on remote language models (7 listopada 2025). (Microsoft)
  2. McDonald, Bar-Or — Whisper Leak: a side-channel attack on Large Language Models (arXiv, 5 listopada 2025). (arXiv)
  3. Weiss et al. — What Was Your Prompt? A Remote Keylogging Attack on AI Assistants (USENIX Security 2024 / arXiv). (arXiv)
  4. Carlini, Nasr — Remote Timing Attacks on Efficient Language Model Inference (arXiv, 22 października 2024). (arXiv)
  5. The Hacker News — Microsoft Uncovers ‘Whisper Leak’ Attack That Identifies AI Chat Topics in Encrypted Traffic (8 listopada 2025). (The Hacker News)

GlassWorm znowu na OpenVSX: trzy nowe rozszerzenia VS Code z ukrytym malware

Wprowadzenie do problemu / definicja luki

Na OpenVSX (alternatywny rejestr rozszerzeń VS Code) wykryto powrót kampanii GlassWorm – zestawu złośliwych rozszerzeń wykorzystujących niewidzialne znaki Unicode do ukrywania i wykonywania JavaScriptu. Nowa fala obejmuje 3 rozszerzenia (m.in. ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs) i według bieżących raportów odnotowała łącznie >10 tys. pobrań. Kampania kontynuuje wcześniej opisane techniki: C2 w łańcuchu Solana, kradzież tokenów GitHub/npm/OpenVSX oraz danych portfeli krypto z 49 popularnych wtyczek.

W skrócie

  • Co się stało: po październikowych czyszczeniach OpenVSX znów pojawiły się 3 zainfekowane rozszerzenia z ukrytym ładunkiem GlassWorm.
  • Jak działa: payload jest schowany w znakach PUA/VS (Private Use Area/Variation Selectors) – „puste” w edytorze, ale dekodowane i wykonywane przez JS. C2 i aktualizacje są osadzane w transakcjach Solana (trwałość, anonimizacja, niskie koszty).
  • Po co: kradzież sekretów (GitHub, npm, OpenVSX), drenaż krypto, tworzenie SOCKS proxy/HVNC i budowa infrastruktury przestępczej na stacjach devów.
  • Skala i spór: OpenVSX informował, że incydent z października był „opanowany” i że nie była to autonomiczna samoreplikacja; jednak badacze widzą „samopowielanie” przez kradzież i użycie poświadczeń.
  • Nowość: potwierdzone wejście na GitHub (commity z doklejonym, ukrytym dekoderem + eval) – to rozszerza wektor poza marketplace.

Kontekst / historia / powiązania

Pierwsza fala GlassWorm została opisana 20 października 2025 r., gdy wykryto pakiet zainfekowanych rozszerzeń na OpenVSX i w marketplace Microsoftu (łączny licznik pobrań szacowany na ok. 35,8 tys., choć mógł być sztucznie zawyżony przez atakujących). 2 listopada OpenVSX ogłosił rotację tokenów i dodatkowe zabezpieczenia po wykryciu wycieku >550 sekretów; jednocześnie podkreślił, że kod nie był „samoreplikującym się” robakiem w klasycznym sensie. 6 listopada badacze Koi i Aikido pokazali jednak nową falę oraz pivot na GitHub. 8 listopada media potwierdziły trzy świeże rozszerzenia na OpenVSX.

Analiza techniczna / szczegóły luki

1) „Niewidzialny” ładunek

  • Atak wykorzystuje PUA/VS (np. zakresy U+E000–U+F8FF, U+FE00–U+FE0F), które nie renderują się w edytorze, ale są parsowane przez dekoder w JS. Typowy wzorzec: dekoder mapujący punkty kodowe → bajty → eval. Na GitHub widziano jednolinijkowy wariant, który dołączał dekoder na końcu pliku.

2) Kanał C2/aktualizacji w Solanie

  • Rozszerzenia pobierają następne etapy na podstawie transakcji Solana (w polach danych trzymane są base64 z URL-ami serwerów C2). Rozwiązanie trudne do zdejmowania (odporne, tanie, anonimowe). Backup: Google Calendar z linkiem base64 w tytule wydarzenia.

3) Zdolności końcowe

  • Kradzież tokenów/logowań (GitHub/npm/OpenVSX), portfeli krypto (49 wtyczek), uruchamianie SOCKS proxy, HVNC (ukryty VNC) – praktycznie przejęcie stacji deweloperskiej jako węzła przestępczego.

4) Infrastruktura i IOC

  • Koi w nowej fali wskazało, że używana jest ta sama infrastruktura (zaktualizowane wskaźniki C2 publikowane w Solanie; przykładowo w raporcie widnieją adresy 199.247.10.166 oraz 199.247.13.106:80/wall jako punkty komunikacji/eksfiltracji).

Praktyczne konsekwencje / ryzyko

  • Łańcuchowe kompromitacje: kradzione tokeny wydawnicze pozwalają wstrzykiwać złośliwe aktualizacje do innych rozszerzeń/repozytoriów/teamów.
  • Trwałość i trudne wyłączenie: C2 na blockchainie zmniejsza skuteczność klasycznych Takedownów. Zmiana transakcji → nowy endpoint → „samoleczenie” C2.
  • Ryzyko finansowe i reputacyjne: wyciek sekretów organizacji, kradzież krypto, nadużycie zasobów (proxy, botnet z dev-workstation).
  • Rozszerzenie wektora: pojawienie się ukrytych commitów na GitHub (AI-like, wiarygodne modyfikacje) utrudnia code review i detekcję.

Rekomendacje operacyjne / co zrobić teraz

0) Szybkie kroki IR (dla SOC/ITSec)

  1. Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
    • ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs.
  2. Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
  3. Rotuj sekrety: patche PAT/ghp, npm tokens, OpenVSX tokens, klucze do CI/CD; wymuś 2FA i SSO. (OpenVSX przeszedł już rotację tokenów, ale Twoja organizacja musi zrobić to samo).

1) Wykrywanie „niewidzialnego” kodu (proste skrypty)

Linux/macOS – skan katalogów rozszerzeń VS Code/VSCodium

# VS Code i VSCodium: typowe ścieżki
EXT_DIRS=("$HOME/.vscode/extensions" "$HOME/.vscode-oss/extensions" "$HOME/.vscode-insiders/extensions")
# Znaki PUA/VS: U+E000–U+F8FF, U+FE00–U+FE0F, U+E0100–U+E01EF
for d in "${EXT_DIRS[@]}"; do
  [ -d "$d" ] || continue
  echo "[*] Skanuję $d"
  grep -RIl --include='*.js' --include='*.ts' \
    -P "[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]" "$d" || true
done

Windows (PowerShell)

$paths = @("$env:USERPROFILE\.vscode\extensions", "$env:USERPROFILE\.vscode-oss\extensions")
$pattern = '[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]'
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem -Recurse -Include *.js,*.ts -Path $p |
      Select-String -Pattern $pattern -AllMatches | Select-Object Path,LineNumber
  }
}

Prosty YARA snippet (heurystyka):

rule Invisible_Unicode_PUA_Eval_JS {
  meta: author="BlueTeam" description="GlassWorm-like hidden code"
  strings:
    $pua = /[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]+/u
    $eval = /eval\s*\(/ nocase
  condition:
    uint16(0) == 0xFFFE or uint16(0) == 0xFEFF or filesize < 5MB and $pua and $eval
}

2) Usuwanie podejrzanych rozszerzeń

# VS Code
code --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
code --uninstall-extension ai-driven-dev.ai-driven-dev
code --uninstall-extension adhamu.history-in-sublime-merge
code --uninstall-extension yasuyuky.transient-emacs

# VSCodium
codium --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
codium --uninstall-extension ai-driven-dev.ai-driven-dev
...

3) Twardnienie łańcucha wydawniczego

  • Sekrety: ogranicz TTL tokenów, wprowadź krótko żyjące PAT, automatyczną re-rotację po wykryciu wycieku; secret scanning w CI. (Zgodne z kierunkiem zmian deklarowanych przez OpenVSX).
  • Publikacja rozszerzeń: SBOM + skan artefaktów przed publikacją, signowanie, zasada 4-oczu na „release”.
  • Review kodu: wymuś widoczność znaków niewidzialnych w IDE i Diffach (np. włącz „Render Control Characters” w VS Code, używaj pre-commit hooków skanujących PUA). (W raporcie Aikido wskazano, że interfejsy nie zawsze oznaczały te znaki).
  • Egress i DNS: blokady do znanych IOC oraz monitorowanie zapytań powiązanych z Solaną używaną jako kanał C2 (telemetria proxy, NetFlow/Zeek).

Różnice / porównania z innymi przypadkami

  • Klasyczne „tylne drzwi” w npm (post-install, skrypty lifecycle) były wyraźniejsze w kodzie; tutaj ładunek „nie istnieje gołym okiem” i potrafi przenikać code review.
  • C2 w Solanie to nowszy trend utrudniający Takedown – w porównaniu do typowych domen/URL na VPS, które łatwiej zawiesić.
  • Spór o „worma”: OpenVSX wskazuje, że brak autonomicznej replikacji; badacze argumentują, że automatyczne aktualizacje + wykorzystanie wykradzionych tokenów de facto umożliwia rozprzestrzenianie się w ekosystemie. Wniosek operacyjny: dla obrony nie ma to znaczenia – ścieżka propagacji i tak omija kontrole.

Podsumowanie / kluczowe wnioski

  • Niewidzialny kod + blockchain C2 + kradzież sekretów = bardzo skuteczny model ataku na ekosystemy developerskie.
  • Nowa fala na OpenVSX pokazuje, że nawet po rotacji tokenów atakujący szybko wracają – potrzebne są krótkie TTL, skanowanie podczas publikacji i silne procesy w organizacjach.
  • Blue Teamy powinny wdrożyć skan PUA, bloki IOC, telemetrię egress i procedury IR wyspecjalizowane dla stacji developerskich (zależne od IDE/marketplace).

Źródła / bibliografia

  1. BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
  2. BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
  3. Eclipse Foundation (OpenVSX) – aktualizacja bezpieczeństwa, rotacje tokenów i stanowisko nt. „self-replicating” (27.10.2025; podsumowane także 02.11.2025). (Eclipse Foundation Staff Blogs)
  4. Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
  5. Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)

Ollama i NVIDIA: nowe luki uderzają w infrastrukturę AI. Co musi zrobić dział SecOps?

Wprowadzenie do problemu / definicja luki

Badacze ujawnili świeży zestaw podatności w popularnych elementach infrastruktury AI: w silniku modeli Ollama oraz w stosie NVIDIA (Triton Inference Server i Container Toolkit/GPU Operator). Część błędów umożliwia zdalne wykonanie kodu (RCE) bez uwierzytelnienia lub ucieczkę z kontenera do hosta, co wprost zagraża klastrom Kubernetes i serwerom GPU. Informacje o nowych lukach i ich naprawach potwierdza m.in. serwis Dark Reading oraz biuletyny producentów.

W skrócie

  • Produkty narażone (przykłady):
    • Ollama – m.in. nowsze zgłoszenia: CVE-2025-51471 (token-steal/bypass auth), wcześniejsze: CVE-2024-37032 (RCE „Probllama”), CVE-2024-28224 (DNS rebinding), plus błędy DoS/overflow.
    • NVIDIA – Container Toolkit/GPU Operator: CVE-2025-23266 (krytyczny container escape, CVSS 9.0) i CVE-2025-23267 (link-following/DoS).
  • Wpływ: przejęcie serwera inferencji, kradzież modeli i danych, eskalacja uprawnień z kontenera do hosta, dostęp do innych workloadów na tym samym węźle GPU.
  • Naprawy:
    • NVIDIA Container Toolkit ≥ 1.17.8 (oraz odpowiednie wersje GPU Operator/Device Plugin/MIG Manager).
    • Ollama – aktualizacja do wydań z łatami (m.in. po CVE-2024-37032 oraz po CVE-2025-51471).

Kontekst / historia / powiązania

Od 2024 r. infrastruktura AI trafia coraz częściej na celownik: Wiz Research opisał RCE w Ollama (CVE-2024-37032, „Probllama”) – łatwe do sprowokowania przez błędy walidacji i brak natywnego uwierzytelniania, zwłaszcza w domyślnie publicznych wdrożeniach Docker. NCC Group wcześniej udowodniło, że DNS rebinding pozwala atakować lokalne instancje Ollama przez przeglądarkę ofiary. Równolegle 2025 przyniósł NVIDIAScape – krytyczny escape w Container Toolkit. Trend potwierdzają media branżowe: środek ciężkości badań przesuwa się z prompt-injection do warstwy infrastruktury (serwery inferencji, rejestry modeli, kontenery GPU).

Analiza techniczna / szczegóły luki

Ollama

  1. CVE-2024-37032 („Probllama”) – RCE
    • Wada w obsłudze manifestów przy /api/pull pozwalała na path traversal i arbitrary file write/read, co w deploymentach Docker (root, 0.0.0.0) dawało prostą ścieżkę do RCE (np. przez manipulację ld.so.preload). Zalecana aktualizacja do wersji z 08.05.2024+.
  2. CVE-2024-28224 – DNS rebinding
    • Atak z poziomu przeglądarki ofiary omijał Same-Origin Policy, umożliwiając zdalny dostęp do API Ollama na localhost, eksfiltrację plików oraz operacje na modelach. Naprawione w v0.1.29; rekomendowane m.in. sprawdzanie nagłówka Host i TLS, także dla loopback.
  3. CVE-2025-51471 – kradzież tokenów / obejście auth
    • Cross-Domain Token Exposure: złośliwy WWW-Authenticate realm z /api/pull mógł wykradać tokeny i obchodzić kontrolę dostępu. Dotyczyło Ollama 0.6.7; patrz NVD/GitHub Advisory i poprawki projektu.

Wniosek: w praktyce te trzy klasy błędów łączą się w łańcuch ataku: rebinding ⇒ token-steal ⇒ pull/push z prywatnego rejestru ⇒ RCE/eksfiltracja.

NVIDIA Container Toolkit / GPU Operator

  • CVE-2025-23266 (CVSS 9.0) – błąd w hookach inicjalizacji kontenera; w pewnych konfiguracjach umożliwiał ucieczkę z kontenera i wykonanie kodu z podwyższonymi uprawnieniami na hoście.
  • CVE-2025-23267 (CVSS 8.5) – podatność w hooku update-ldcache; specjalnie spreparowany obraz mógł prowadzić do link following, skutkując manipulacją danymi/DoS.
  • Wersje naprawcze: Toolkit 1.17.8, GPU Operator 25.3.2, Device Plugin 0.17.3, MIG Manager 0.12.2; dodatkowe uwagi dla RHEL/OpenShift i notatka, że konfiguracje z crun nie są dotknięte 23266.

Praktyczne konsekwencje / ryzyko

  • Kradzież modeli i promptów, modyfikacja wag i artefaktów (supply-chain modeli), sabotaż inferencji.
  • Pivot z kontenera do hosta GPU (23266) ⇒ dostęp do innych namespace’ów/kontenerów na węźle, wyciek danych klientów i eskalacja w klastrze.
  • Ataki z przeglądarki na lokalne dev-maszyny (DNS rebinding) ⇒ eksfiltracja dokumentów/projektów R&D.
  • Ryzyko compliance: naruszenia izolacji danych, IP leakage, utrata integralności modeli.

Rekomendacje operacyjne / co zrobić teraz

1) Patch & wersje

  • NVIDIA: zaktualizuj Container Toolkit → 1.17.8, GPU Operator → 25.3.2, Device Plugin → 0.17.3, MIG Manager → 0.12.2. Dla OpenShift – użyj tagów v1.17.8-ubi8 / v0.12.2-ubi9. Jeśli używasz crun – 23266 nie dotyczy, ale 1.17.7 nadal wymaga łat na 23267.
  • Ollama: zaktualizuj do wersji usuwających CVE-2024-37032 i CVE-2025-51471 (sprawdź release notes projektu). Minimalnie ≥ v0.1.34 dla „Probllama”, naprawa 0.6.7-related dla token-steal.

2) Minimalizacja ekspozycji

  • Nie wystawiaj API Ollama publicznie. Jeśli musisz – wymuś reverse proxy z auth (OIDC/Basic) i TLS:
# Nginx (skrót)
server {
  listen 443 ssl http2;
  server_name ollama.example.com;
  ssl_certificate ...; ssl_certificate_key ...;

  auth_basic "Restricted";              # tymczasowo
  auth_basic_user_file /etc/nginx/.htpasswd;

  location / {
    proxy_set_header Host $host;
    proxy_pass http://127.0.0.1:11434;
  }
}

(Wiz podkreśla brak natywnego auth w wielu wdrożeniach; reverse proxy to „must”.)

  • W instancjach lokalnych wymuś bind tylko do loopback:
# Linux (systemd override)
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=127.0.0.1"

3) Twardnienie kontenerów i K8s

  • Zabroń --privileged i host-mountów; używaj rootless (jeśli możliwe), seccomp/apparmor i redukcji capabilities:
# PodSecurityContext (skrócone)
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  seccompProfile: { type: RuntimeDefault }
  capabilities: { drop: ["ALL"] }
  • Segmentuj sieć przy pomocy NetworkPolicy – oddziel inference od reszty:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-only-proxy, namespace: ai }
spec:
  podSelector: { matchLabels: { app: ollama } }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { name: ingress } }
      ports: [{ protocol: TCP, port: 11434 }]

4) Rejestry modeli i „model supply chain”

  • Pin’uj hashy warstw, weryfikuj źródła (allow-list domen/rejestrów), skanuj artefakty przed „pull”. (W RCE „Probllama” wektor przechodził przez /api/pull z prywatnego rejestru.)

5) Detekcja i IR

  • Wskaźniki podejrzanej aktywności (przykłady):
    • Nietypowe żądania /api/pull z zewnętrznych adresów, 4xx/5xx na /api/push, powtarzające się tworzenie modelu z niestandardowymi FROM.
    • W nodach GPU: logi runtime wskazujące na modyfikacje ld.so.preload, anomalie w hookach OCI, nieautoryzowane biblioteki preload (23266/23267).
  • Reguły (przykład Falco):
- rule: Write to ld.so.preload
  desc: Potential container escape via ld.so.preload manipulation
  condition: >
    evt.type in (open, openat) and fd.name = "/etc/ld.so.preload" and
    proc.name not in (ldconfig)
  output: "Process %proc.name wrote to ld.so.preload (user=%user.name container=%container.id)"
  priority: CRITICAL

Różnice / porównania z innymi przypadkami

  • Ollama – błędy głównie na styku API i walidacji danych (path traversal, token-steal, DNS rebinding), a więc ataki zdalne poprzez HTTP i łańcuchy z udziałem przeglądarek/serwerów proxy.
  • NVIDIA Container Toolkit/GPU Operator – błędy w hookach OCI i przepływie inicjalizacji, skutkujące eskalacją z kontenera do hosta (breakout), co zagraża całemu węzłowi i sąsiadującym workloadom.

Podsumowanie / kluczowe wnioski

  1. Zaktualizuj wszystko, co dotyczy stosu AI – najpierw Toolkit 1.17.8 / GPU Operator 25.3.2, potem Ollama do wersji z łatami na RCE, rebinding i token-exposure.
  2. Nie wystawiaj surowych endpointów inferencji do Internetu; dodaj auth i TLS na brzegu.
  3. Odchudź uprawnienia kontenerów, stosuj Pod Security i NetworkPolicy, monitoruj anomalia w hookach OCI i modyfikacje ld.so.preload.
  4. Traktuj modele jak łańcuch dostaw – weryfikuj źródła i hashe, skanuj pliki GGUF/manifesty przed użyciem.

Źródła / bibliografia

  • Dark Reading — przegląd nowych luk w Ollama i NVIDIA Triton/Toolkit (7 listopada 2025). (Dark Reading)
  • NVIDIA Security Bulletin: Container Toolkit (CVE-2025-23266, CVE-2025-23267) oraz wersje naprawcze. (NVIDIA Support)
  • Wiz Research: „Probllama” — CVE-2024-37032 (RCE w Ollama), wektory i mitigacje. (wiz.io)
  • NCC Group: CVE-2024-28224 (DNS rebinding w Ollama), szczegóły ataku i zalecenia. (NCC Group)
  • NVD: CVE-2025-51471 (Cross-Domain Token Exposure w Ollama 0.6.7), status i referencje. (NVD)

Daylight pozyskuje 33 mln dol. na „agentowe” MDR. Co to oznacza dla SOC-ów?

Wprowadzenie do problemu / definicja luki

Skalowanie operacji bezpieczeństwa (SOC) rozbija się dziś o dwa twarde limity: czas reakcji i liczbę ludzi. Klasyczne MDR-y (Managed Detection and Response) odciążają zespoły, ale nadal cierpią na przeciążenie alertami i „eskalowanie zamiast rozwiązywania”. Startup Daylight proponuje alternatywę: połączenie agentowych systemów AI z nadzorem doświadczonych analityków, aby dostarczać rezultaty (containment, remediacje) zamiast samych powiadomień. Firma właśnie ogłosiła rundę 33 mln USD (Series A), która ma przyspieszyć rozwój platformy oraz modułów dla Identity Threat Response i Cloud Workload Protection.

W skrócie

  • 33 mln USD Series A prowadzone przez Craft Ventures; udział m.in. Bain Capital Ventures i Maple VC. Całkowite finansowanie: 40 mln USD.
  • Daylight określa swój model jako MASS – Managed Agentic Security Services: autonomiczne agentowe AI + nadzór analityków 24/7.
  • Cel rundy: ekspansja w USA, rozwój platformy operacji bezpieczeństwa i uruchomienie modułów dla tożsamości oraz chmury.
  • Firma deklaruje wdrożenia „w mniej niż godzinę”, „do 90% mniej false positives” i klientów w USA/EU (m.in. The Motley Fool, Cresta, McKinsey Investment Office). (Deklaracje producenta)
  • Założyciele: Hagai Shapira (CEO) i Eldad Rudich (CTO) – weterani Unit 8200.

Kontekst / historia / powiązania

Runda ogłoszona 4–5 listopada 2025 r. następuje trzy miesiące po seedzie 7 mln USD i wpisuje się w trend przyspieszonego finansowania narzędzi AI-native SecOps. W tle mamy eksplozję ataków napędzanych AI, rosnące środowiska hybrydowe i chroniczny deficyt talentów w SOC. Daylight pozycjonuje MASS jako ewolucję MDR: agenci AI wykonują monitoring, triage, dochodzenia kontekstowe i wstępne remediacje, a analitycy podejmują decyzje o wyższym ciężarze.

Analiza techniczna / szczegóły podejścia

Architektura MASS (wysnuta z opisów publicznych):

  • Warstwa agentowa (AI-core): zestaw wyspecjalizowanych agentów wykonujących korelację sygnałów, priorytetyzację, „case building” oraz autonomiczne działania (np. izolacja hosta, blokada konta, polityka w EDR/IdP), z możliwością pracy cloud/on-prem/hybryda.
  • Nadzór ekspercki (human-in-the-loop): analitycy „kalibru PhD” potwierdzają hipotezy, rozszerzają zakres dochodzenia, zatwierdzają remediacje wysokiego ryzyka i utrzymują „guardrails” dla agentów.
  • Integracje i czas wartości: producent podkreśla szybkie wdrożenie (<1h) i pracę „w istniejącej infrastrukturze” – to sugeruje gotowe konektory do EDR/XDR, SIEM, IdP, chmur. (Deklaracje producenta)
  • Nowe moduły: Identity Threat Response i Cloud Workload Protection mają rozszerzyć autonomię poza klasyczne endpointy.

Różnica semantyczna: Daylight używa pojęcia MASS aby odróżnić się od „AI-assisted MDR”. Klucz to agentowość (samodzielne działanie agentów w granicach polityk) zamiast samego „copilota” do analizy zdarzeń.

Praktyczne konsekwencje / ryzyko

Plusy dla SOC:

  • Skrócenie MTTD/MTTR dzięki automatycznym dochodzeniom i remediacjom niskiego ryzyka.
  • Redukcja alert fatigue i kosztów eskalacji; potencjalnie mniej ról L1/L2, więcej „SRE-like SecOps”.

Ryzyka i „ciemne pola”:

  • Zaufanie do agentów: konieczne twarde guardrails, audyt działań i „two-person rule” dla akcji destrukcyjnych (np. masowe disable kont).
  • Bias danych i halucynacje: agentowe systemy oparte na LLM muszą mieć deterministyczne playbooki i walidację efektów.
  • Vendor lock-in & integracje: rzeczywista głębokość integracji z EDR/XDR/IdP/SaaS będzie decydować o skuteczności poza presales demo.
  • Regulacje/zgodność: ścieżki audytu, eDiscovery i zgodność z politykami tożsamości (zwłaszcza w UE).
    (Ocena własna na podstawie publicznych opisów architektury.)

Rekomendacje operacyjne / co zrobić teraz

  1. Pilot 60–90 dni: wybrane segmenty (np. wybrane OU w IdP, część floty EDR, wycinek chmury). Zdefiniuj KPI: MTTD/MTTR, % zautomatyzowanych remediacji, precyzja triage.
  2. RACI dla agentów: policy gates dla akcji o wysokim wpływie (disable użytkownika, kwarantanna zasobu chmurowego).
  3. Playbooki „deterministyczne”: ustandaryzowane runbooki SOAR jako „rails” dla agentów; logowanie decyzji i wyników.
  4. Ocena integracji: sprawdź konektory do twoich krytycznych systemów (IdP, EDR/XDR, chmury, SaaS).
  5. Model zagrożeń AI: włącz AI threat modeling (np. ryzyka „model misuse”, nadmierna autonomiczność, eskalacja uprawnień).
  6. Due diligence dostawcy: SLA na czas reakcji analityków, transparentność działań agentów, mechanizmy „kill-switch”.

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

  • Klasyczny MDR/XDR: zwykle „detect → alert → escalate”, ograniczona automatyzacja i często ręczne dochodzenia. Daylight twierdzi, że przechodzi do „detect → investigate → resolve” z agentami AI, a człowiek nadzoruje tylko trudne przypadki.
  • „AI-assisted SOC copilot”: narzędzia pomagające analitykom pisać zapytania lub streszczać alerty. MASS aspiruje do autonomii operacyjnej w ramach polityk (containment/remediacje), co zbliża je do „autonomic SOC”.

Podsumowanie / kluczowe wnioski

  • Runda 33 mln USD (Series A) potwierdza popyt na agentowe podejście do SecOps. MASS ma ambicję dostarczać wynik, nie tylko alert.
  • Sukces wdrożeń będzie zależeć od jakości integracji, dojrzałości guardrails i przejrzystości działań agentów.
  • Dla CISO to realna ścieżka do skrócenia MTTR bez liniowego zwiększania etatów – ale wymaga świadomego pilotowania, kontroli zmian i audytu.

Źródła / bibliografia

  1. SecurityWeek: Daylight Raises $33 Million for AI-Powered MDR Platform (05.11.2025). (SecurityWeek)
  2. Blog Daylight (Hagai Shapira): Lighting the Next Chapter… (04.11.2025). (daylight.ai)
  3. SiliconANGLE: Daylight Security raises $33M… (04.11.2025). (SiliconANGLE)
  4. CTech / Calcalistech: Cyber startup Daylight raises $33 million… (04.11.2025). (ctech)
  5. Daylight – About / Leadership. (daylight.ai)