Archiwa: AI - Strona 47 z 50 - Security Bez Tabu

Tag: AI

USA uruchamia „Scam Center Strike Force” przeciw chińskim sieciom oszustw krypto — co to oznacza dla obrony?

Wprowadzenie do problemu / definicja luki

Departament Sprawiedliwości USA (DOJ) ogłosił 12 listopada 2025 r. powołanie międzyagencyjnej Scam Center Strike Force — zespołu uderzeniowego do rozbijania transnarodowych ośrodków oszustw inwestycyjnych („pig-butchering” / romance-baiting) powiązanych z chińskimi strukturami przestępczymi i działających głównie w Azji Południowo-Wschodniej. W inicjatywę zaangażowane są m.in. FBI, US Secret Service, Departament Skarbu (OFAC) oraz partnerzy sektorowi. Cel: identyfikacja przepływów, seizury krypto, dezintegracja infrastruktury oraz ściganie organizatorów.

W skrócie

  • Skala strat: amerykańskie ofiary straciły w 2024 r. ok. 10 mld USD, a dynamika rok do roku to ok. +66%.
  • Zakres działań: odzyskiwanie setek milionów USD w krypto, sankcje na podmioty wspierające scam-centers, uderzenia w infrastrukturę (w tym łączność).
  • Wektor ataku: socjotechnika w kanałach SMS/WhatsApp/Telegram/portale randkowe + „fałszywe inwestycje” na customowych platformach z obsługą krypto.

Kontekst / historia / powiązania

Nowy zespół wpisuje się w szerszą linię działań USA przeciw skamom krypto. W październiku 2025 r. Departament Skarbu ogłosił największą jak dotąd akcję przeciw sieciom cyberprzestępczym w Azji Płd-Wsch., wyznaczając sankcje i odcinając wybrane podmioty od systemu finansowego USA. W maju 2025 r. OFAC sankcjonował infrastrukturę sieciową ułatwiającą skamy (hurtowe zakupy IP, hosting). Te precedensy torują drogę do szybszego blokowania kanałów płatniczych i serwerów.

Równolegle media branżowe i śledcze wskazują na wykorzystywanie łączności satelitarnej przez obozy scamowe w Mjanmie/regionie Mekongu — DOJ uzyskał nakazy zajęcia/wygaszenia wybranych terminali jako element „deny & degrade” infrastruktury.

Analiza techniczna / szczegóły zagrożenia

Łańcuch ataku (high-level TTPs):

  1. Initial access (socjotechnika): cold outreach przez SMS/RCS („Hi, is this Anna?”), komunikatory/dating apps; pivot na „mentoring inwestycyjny”. TTPs: T1566.002 (Spearphishing via Service), T1204 (User Execution).
  2. Delivery/Infrastructure: domeny „investment” z realnymi wykresami, walletami kontrolowanymi przez TCO; rotacja ASN/VPS/proxy; czasem IP z puli dostawców infrastruktury z Azji Płd-Wsch. (zidentyfikowane w działaniach sankcyjnych). TTPs: T1583 (Acquire Infrastructure), T1036 (Masquerading).
  3. Command & Control/Payment: mix USDT/TRC-20, ETH, BTC; warstwowanie/mixing, szybkość cash-out; edukowana obsługa ofiary 1:1. TTPs: T1030 (Data Transfer Size Limits), T1133 (External Remote Services). (Wnioski z publicznych materiałów DOJ/mediów.)
  4. Hardening narracji: deepfake’y/AI do „proof of funds”, pseudo-dashboardy z naliczaniem zysków; kontrolowane „withdrawal test” na małych kwotach.

Wskaźniki i sygnały telemetryczne (przykłady do SIEM/EDR/DLP):

  • Nietypowe sesje przeglądarkowe do nowych domen inwestycyjnych bez reputacji (<=14 dni), z wysokim „first-seen in org” + brak certów EV.
  • Transfery krypto z firmowych urządzeń/przeglądarek nie wykorzystywanych dotąd do crypto-ops.
  • SMS-y z frazami „Hi, is this X?”, „mentor”, „USDT”, „Kraken VIP/OTC”, „quantitative trading bot”, „copy-trading”.

Praktyczne konsekwencje / ryzyko

Dla SOC/CSIRT/DFIR: spodziewaj się większej współpracy organów ścigania (zapytania o logi, szybkie zabezpieczenia kont i urządzeń), a także rosnącej liczby seizure notices dla giełd/kantorów i żądań zamrożenia środków. Incidenty łączą się z wyciekiem danych osobowych ofiar (KYC, selfie), co zwiększa ryzyko wtórnych fraudów/wyłudzeń.

Dla compliance/AML: sankcje OFAC i nowe desygnacje (np. grupy i spółki w Mjanmie) wymagają screeningu kontrahentów, IP, merchantów i adresów on-chain; niezgodność = ryzyko wtórne/regulator.

Dla świadomości użytkowników: język „romance/investment mentoring” pozostaje dominujący; konieczne są kampanie anty-stygmatyzacyjne, bo ofiary często milczą — to utrudnia detekcję i odzyski. (Trend potwierdzany publicznie w materiałach prasowych i śledczych).

Rekomendacje operacyjne / co zrobić teraz

1) Kontrole prewencyjne (IT/SOC)

  • Blokowanie świeżych domen inwestycyjnych: polityka DNS „newly-registered domain (NRD) deny” dla kategorii finance/investment + branżowe listy reputacyjne.
  • Policy hardening dla komunikatorów/dating apps na urządzeniach firmowych (MDM).
  • TLS inspection + HTTP category logging dla ruchu do giełd/kantorów z sieci firmowej; w razie potrzeby segmentacja i wyjątki HR.

Sigma (detekcja fraz w proxy/HTTP/EDR-URL):

title: Suspicious Investment Scam Landing
id: 8c8a1fce-6bde-4b06-bcc3-ssc-scam-landing
status: experimental
logsource:
  category: proxy
  product: webproxy
detection:
  selection:
    cs_host|contains:
      - "quant" 
      - "mentor" 
      - "vip" 
      - "otc"
    cs_uri|contains:
      - "crypto"
      - "usdt"
      - "copy-trading"
  condition: selection
fields:
  - c_ip
  - cs_host
  - cs_uri
level: medium
tags:
  - attack.T1583

2) Playbook DFIR (skrót)

  • Triaging przeglądarek: odzysk zakładek/auto-fill/Service Worker/IndexedDB z domen „inwestycyjnych”.
  • Wallet forensics: zrzut rozszerzeń (MetaMask/OKX/Trust) + historię transakcji; ścieżka SignMessage i Approve (ERC-20).
  • Chain tracing: szybka weryfikacja heuristic clusters i service exposure na adresach ofiary (open-source first).

Przykładowe komendy (Bitcoin/Ethereum, open APIs):

# BTC: podgląd transakcji i heurystyka (mempool.space / Blockstream)
curl -s https://mempool.space/api/address/$(cat suspect_btc.addr) | jq '.chain_stats'

# ETH: salda i transfery ERC-20 (OKLink public API lub Etherscan - wstaw swój klucz)
curl -s "https://api.etherscan.io/api?module=account&action=txlist&address=0xADDR&startblock=0&endblock=99999999&sort=asc&apikey=<KEY>" | jq '.result[] | {hash, to, value}'

3) AML/FinCrime

  • Screening adresów on-chain pod kątem sankcji OFAC (listy SDN + własne watch-listy); wprowadzić real-time rule „first-hop to/from sanctioned cluster = freeze & escalate”.
  • Travel Rule dla VASP: automatyczna wymiana danych przy transferach powyżej progów + enhanced due diligence dla kierunków wysokiego ryzyka (Birma, Kambodża, Laos).

4) Retrospektywa w SIEM (szybkie zapytania)

Splunk (proxy + EDR + SMS-gateway):

index=proxy OR index=edr OR index=smsgw
| eval ioc=coalesce(uri, dest_domain, sms_body)
| search ioc="USDT" OR ioc="copy-trading" OR ioc="quantitative" OR ioc="mentor" OR ioc="VIP OTC"
| stats count by src_user, src_ip, dest_domain, uri, sms_sender, sms_body

Różnice / porównania z innymi przypadkami

  • Strike Force vs. pojedyncze śledztwa: to stała, międzyagencyjna jednostka koordynująca dochodzenia, sankcje, zajęcia krypto i operacje na infrastrukturze; wcześniej dominowały rozproszone sprawy i doraźne akcje.
  • Dołożenie komponentu infrastrukturalnego (np. łączność satelitarna) — krok poza klasyczne „seize wallet”, uderzenie w enablerów działania obozów oszustw.
  • Kontynuacja linii OFAC/Treasury: od sankcji na sieci i operatorów (Q2–Q4 2025) do zgranego „whole-of-government” z DOJ.

Podsumowanie / kluczowe wnioski

  • Scam Center Strike Force to zapowiedź częstszych seizur, sankcji i takedownów infrastruktury wspierającej „romance/investment-baiting”.
  • Dla obrony: wzmocnij kontrole komunikatorów, filtry NRD, detekcje fraz i chain-screening; przygotuj playbook odzysku środków i ścieżkę szybkiej współpracy z organami.
  • Dla compliance: aktualizuj listy sankcyjne, wdrażaj Travel Rule i ciągłą analizę przepływów do regionów wysokiego ryzyka.

Źródła / bibliografia

  • U.S. Attorney’s Office (DOJ) — ogłoszenie „Scam Center Strike Force”, 12.11.2025. (justice.gov)
  • Bloomberg — omówienie skali i celu Strike Force (~10 mld USD strat). (Bloomberg)
  • BleepingComputer — przegląd inicjatywy i TTP oszustów. (BleepingComputer)
  • U.S. Treasury (OFAC) — duża akcja przeciw sieciom cyberprzestępczym w Azji Płd-Wsch. (10.2025). (U.S. Department of the Treasury)
  • Reuters — sankcje przeciw dostawcy infrastruktury wspierającej skamy (05.2025). (Reuters)

OWASP Top 10 2025 – Kluczowe Zagrożenia I Porady Bezpieczeństwa

OWASP Top 10 w praktyce: krótki kontekst zanim przejdziemy dalej

OWASP Top 10 to globalny standard opisujący 10 najpoważniejszych ryzyk bezpieczeństwa aplikacji webowych. Najnowsza edycja – OWASP Top 10 2025 – została właśnie opublikowana (po raz ósmy, poprzednio w 2021 roku) i przynosi ważne zmiany. Dla studentów i początkujących specjalistów cyberbezpieczeństwa znajomość tej listy jest kluczowa.

Czytaj dalej „OWASP Top 10 2025 – Kluczowe Zagrożenia I Porady Bezpieczeństwa”

RCE w ImunifyAV/AI-Bolit: zdalne wykonanie kodu z poziomu skanera AV. Miliony serwisów Linux w zasięgu ataku

Wprowadzenie do problemu / definicja luki

W popularnym skanerze z rodziny Imunify – module AI-Bolit dostarczanym w Imunify360, ImunifyAV+ oraz darmowym ImunifyAV – wykryto krytyczny błąd pozwalający na zdalne wykonanie kodu (RCE) podczas analizy złośliwych, obfuskowanych plików PHP. Luka dotyczy wersji przed 32.7.4.0. Dostawca (CloudLinux/Imunify) wydał poprawki i zaleca natychmiastową aktualizację do ≥ 32.7.4.0; backport dla starszych gałęzi Imunify360 pojawił się 10 listopada 2025 r.

Kluczowe: wektor ataku uruchamia się w trakcie skanowania – skaner, próbując „odkleić” warstwy obfuskacji, może wykonać funkcje wskazane przez napastnika (np. system, exec, shell_exec, passthru, eval).

W skrócie

  • Zagrożone: instalacje Imunify360/AV+/AV z komponentem AI-Bolit < 32.7.4.0.
  • Ryzyko: RCE z uprawnieniami procesu skanera; na hostingu współdzielonym może to oznaczać pełne przejęcie serwera.
  • Wektor: specjalnie przygotowane, obfuskowane pliki PHP skanowane przez AI-Bolit (deobfuskacja wymuszona w integracji Imunify).
  • Stan: poprawka dostępna; brak CVE w momencie publikacji; oficjalna notka w bazie wiedzy, wzmianka w changelogu.
  • Akcja: update do 32.7.4.0+, audyt artefaktów po ewentualnym RCE, ograniczenie uprawnień procesu skanera, izolacja.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy AI-Bolit ma problem z wykonywaniem nieufnych danych. W 2021 r. Talos opisał RCE (CVE-2021-21956) wynikające z PHP unserialize w AI-Bolit (dot. wersji 5.8–5.10.2), naprawione w 5.11.3. Obecna podatność jest innej natury, ale podobnie dotyka ścieżki analizy złośliwych próbek.

Wg źródeł publicznych, o problemie w 2025 r. informowano od końca października; 4 listopada pojawił się wpis w Zendesk (Knowledge Base) pt. „Ai-Bolit security vulnerability before v32.7.4.0”; 10 listopada – backport; 12–13 listopada – publikacje techniczne i prasowe.

Analiza techniczna / szczegóły luki

Miejsce błędu

  • AI-Bolit stosuje heurystyki i moduły deobfuskacji do rozklejania łańcuchów base64/gzinflate/pack/chr/ord/....
  • Krytyczna część logiki wywołuje funkcje przez call_user_func_array na nazwach funkcji odzyskanych z próbki (np. system, shell_exec, eval) – bez walidacji.
  • W CLI deobfuskacja bywa domyślnie wyłączona, ale integracja Imunify (Python wrapper) zawsze przekazuje --deobfuscate dla wszystkich typów skanów (tła, on-demand, user-initiated, rapid).

Wymagania ataku

  • Napastnik umieszcza plik PHP zawierający specjalnie przygotowany, obfuskowany ładunek (np. w katalogu strony lub katalogu tymczasowym), który trafi do skanera AI-Bolit.
  • W trakcie deobfuskacji skaner wykonuje zakodowane ciągi jako nazwy funkcji i argumenty → RCE.
  • Patchstack publikuje PoC, który podczas skanowania tworzy plik w /tmp – dowód wykonania komendy.

Poprawka

  • Vendor dodał whitelistę funkcji bezpiecznych i „deterministycznych” (np. base64_decode, gzinflate, strrev, chr, ord, …) oraz blokadę arbitralnych wywołań.

Praktyczne konsekwencje / ryzyko

  • Hosting współdzielony (cPanel/Plesk): jeśli skaner działa z podwyższonymi uprawnieniami (częste), exploity mogą umożliwić eskalację poza pojedynczy vhost – do roota w niektórych, źle utwardzonych konfiguracjach.
  • Zaciemnienie śladów: ładunki są z natury obfuskowane; logi skanera mogą nie zapisać jednoznacznej sygnatury. Trzeba polować na artefakty boczne (np. tworzone pliki w /tmp, nieoczekiwane połączenia wychodzące z procesu skanera PHP).
  • Łańcuchy ataków: możliwe dołożenie web-shelli, modyfikacja wp-config.php, wstrzyknięcie crontabów użytkowników, pivot na inne konta poprzez wspólne ścieżki/UID. (Wniosek z natury RCE skanera działającego globalnie na hostingu.)

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa aktualizacja

  • Docelowa wersja: AI-Bolit/Imunify AV 32.7.4.0 lub nowsza.
  • Oficjalne potwierdzenie i komunikat KB: „Ai-Bolit security vulnerability before v32.7.4.0” (CloudLinux Zendesk).

cPanel/WHM – systemy RPM (Alma/RHEL/CentOS):

# sprawdź pakiety Imunify/AI-Bolit
rpm -qa | egrep -i 'imunify|ai-bolit'

# aktualizacja z repozytoriów Imunify
yum clean all && yum -y update imunify* ai-bolit* imunify-antivirus* imunify360*

# restart usług powiązanych (przykładowo)
systemctl restart imunify360 imunify-antivirus || true

Debian/Ubuntu (Plesk/VPS):

apt-get update
apt-get install --only-upgrade imunify* ai-bolit* imunify360*
systemctl restart imunify360 imunify-antivirus || true

Uwaga: nazwy paczek różnią się między dystrybucjami/integracjami. W razie wątpliwości – sprawdź dpkg -l | grep -i imunify / rpm -qi <pakiet>.

2) Weryfikacja, czy wersja jest już bezpieczna

Ponieważ AI-Bolit to komponent, w praktyce sprawdzamy wersję paczek Imunify oraz binariów w /opt/ai-bolit/:

# szybkie tropy wersji
strings /opt/ai-bolit/ai-bolit.php 2>/dev/null | egrep -i 'version|ai-bolit'
# lub:
grep -i version /opt/ai-bolit/* 2>/dev/null

# Imunify360/AV wersje pakietów
imunify360-agent version 2>/dev/null || true
rpm -qa | grep -i ai-bolit || dpkg -l | grep -i ai-bolit

(Dostawca nie publikuje jednolitego polecenia „–version” dla AI-Bolit w każdej dystrybucji; opieramy się więc na wersjach pakietów i artefaktach plikowych). Informacja o wymaganej wersji pochodzi z BleepingComputer/KB.

3) Działania kompensacyjne (jeśli patch musi poczekać – niezalecane)

  • Izoluj skaner: uruchamiaj w kontenerze/sandboxie z mnim. uprawnieniami (AppArmor/SELinux profil, noexec na /tmp, ograniczenia sieciowe).
  • Zabroń deobfuskacji w trybie standalone (CLI) – nie w pełni skuteczne w integracji Imunify, która i tak wymusza --deobfuscate.
  • UCIĄĆ możliwości wykonania: mounty nodev,nosuid,noexec dla partycji tymczasowych (/tmp, /var/tmp, dev/shm).

4) Polowanie na ślady (triage po incydencie)

Skorzystaj z informacji o PoC (tworzenie pliku w /tmp), a także ogólnych wzorców RCE z PHP:

# 1) Artefakty PoC oraz potencjalnych ładunków
find /tmp -maxdepth 1 -type f -mmin -4320 -printf '%TY-%Tm-%Td %TT %p %s\n' | egrep 'l33t|def|tmp|\.php'

# 2) Nietypowe wywołania procesu skanera (czas skanów)
ps -eo user,pid,ppid,lstart,cmd | egrep -i 'ai-bolit|imunify|php'

# 3) Ostatnio zmieniane pliki w vhostach (web-shelle, .php w uploadach)
find /home /var/www -type f -mtime -2 -iname '*.php' -printf '%p %TY-%Tm-%Td %TT %u:%g %s\n' | head

# 4) Crontaby i autostarty użytkowników
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

# 5) Grep na funkcje wysokiego ryzyka w drzewach WWW
grep -R --include=*.php -nE '(shell_exec|system|passthru|eval\()' /var/www /home/*/public_html 2>/dev/null

Dodatkowo przejrzyj logi serwera w oknach czasowych skanów oraz outbound (egres) procesu PHP/ai-bolit.

5) Utwardzanie na przyszłość

  • Uruchamiaj skanery pod odseparowanym użytkownikiem, bez roota; ogranicz CAP_*.
  • Włącz LSM (AppArmor/SELinux) z profilami dla procesu skanera.
  • W hostingach współdzielonych: CageFS/CloudLinux, mod_suexec/php-fpm per-user, izolacja sieciowa i systemowa per konto.
  • Monitoring integralności (AIDE/OSSEC/Wazuh) + alerty na tworzenie plików wykonywalnych w /tmp.

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

  • CVE-2021-21956 (AI-Bolit unserialize) – RCE przez niebezpieczne deserializacje; naprawione w 5.11.3.
  • Obecna luka (2025) – RCE przez wykonywanie funkcji odzyskanych z obfuskowanego kodu podczas deobfuskacji; brak CVE w chwili pisania, naprawa w 32.7.4.0 i nowszych.
    Wspólny mianownik: powierzchnia ataku w silniku analizy skanera. Wnioski dla vendorów: deobfuskacja powinna być czysto syntaktyczna, nigdy „egzekucyjna”.

Podsumowanie / kluczowe wnioski

  • Jeśli używasz Imunify360/ImunifyAV(+), zaktualizuj natychmiast do ≥ 32.7.4.0.
  • Potraktuj środowisko jak potencjalnie naruszone, jeśli skany uruchamiano na niezaufanych plikach w okresie przed aktualizacją – wykonaj triage i threat hunting.
  • Nawet narzędzia bezpieczeństwa wymagają zasady najmniejszych uprawnień i izolacji; skaner AV nie powinien móc zniszczyć całego hosta.

Źródła / bibliografia

  1. BleepingComputer – „RCE flaw in ImunifyAV puts millions of Linux-hosted sites at risk”, 13 listopada 2025 (szczegóły wersji, kontekst wdrożeń, backport 10 XI). (BleepingComputer)
  2. Patchstack – „Critical: Remote Code Execution via Malicious Obfuscated Malware in Imunify360 AV (AI-Bolit)”, 12 listopada 2025 (analiza techniczna, PoC, wymuszenie --deobfuscate, opis łatki). (Patchstack)
  3. CloudLinux/Imunify – Knowledge Base: „Ai-Bolit security vulnerability before v32.7.4.0.”, wpis z 4–12 listopada 2025 (oficjalna notka i zalecenie aktualizacji). (cloudlinux.zendesk.com)
  4. NVD/Cisco Talos – CVE-2021-21956 (porównanie z wcześniejszym RCE w AI-Bolit, 2021). (NVD)

Adobe łata 29 podatności w InDesign, InCopy, Photoshop, Illustrator, Pass, Substance 3D Stager i Format Plugins (Patch Tuesday – 11 listopada 2025)

Wprowadzenie do problemu / definicja luki

11 listopada 2025 r. Adobe wydało comiesięczne aktualizacje zabezpieczeń usuwające 29 podatności w pakiecie aplikacji kreatywnych. Poprawki dotyczą: InDesign (APSB25-106), InCopy (APSB25-107), Photoshop (APSB25-108), Illustrator (APSB25-109), Illustrator na iPad (APSB25-111), Adobe Pass (APSB25-112), Substance 3D Stager (APSB25-113) oraz Adobe Format Plugins (APSB25-114). W większości chodzi o luki krytyczne prowadzące do RCE po przetworzeniu złośliwych plików/formatów. Adobe klasyfikuje je priorytetem 3 (niska spodziewana eksploatacja), a firma nie ma dowodów na aktywne wykorzystanie tych błędów w momencie publikacji.

W skrócie

  • Zakres: 8 biuletynów, 29 CVE (Creative Cloud/Format Plugins, aplikacje DTP/grafika, SDK Pass).
  • Najpoważniejsze skutki: RCE (InDesign, InCopy, Photoshop, Illustrator, Stager, Format Plugins) i security feature bypass w Adobe Pass (SDK Android).
  • Status exploitów: brak informacji o „in the wild” dla listopadowych biuletynów; priorytet 3 dla wszystkich.
  • Kontekst ryzyka: w październiku Adobe potwierdzało wykorzystanie w praktyce luki w Adobe Commerce/Magento (CVE-2025-54236) oraz publiczne PoC dla AEM Forms (CVE-2025-54253/54254). To inne produkty, ale pokazuje zainteresowanie ekosystemem Adobe.

Kontekst / historia / powiązania

Adobe od lat publikuje paczki poprawek w rytmie Patch Tuesday. W 2025 r. widzieliśmy już serie aktualizacji m.in. dla ColdFusion, Commerce oraz AEM Forms; część miała PoC lub realne wykorzystanie. Dzisiejsza paczka dotyczy przede wszystkim klienta końcowego (DTP/grafika). Trend Micro ZDI podkreśla, że w listopadzie jest 8 biuletynów i 29 CVE, z których część (Format Plugins) pochodzi od ich badaczy.

Analiza techniczna / szczegóły luki

Produkty i biuletyny

  • InDesign – APSB25-106: luki krytyczne → RCE; wersje naprawcze ID21.0 / 20.5.1 (Win/macOS). Priorytet 3.
  • InCopy – APSB25-107: krytyczne RCE (Win/macOS). Priorytet 3.
  • Photoshop – APSB25-108: heap-based buffer overflow → RCE; CVE-2025-61819 (CVSS 7.8). Priorytet 3.
  • Illustrator – APSB25-109: krytyczne RCE; naprawa m.in. do 29.8.3 i 30.0. Priorytet 3.
  • Illustrator (iPad) – APSB25-111: krytyczne RCE. Priorytet 3.
  • Adobe Pass (Android SDK) – APSB25-112: incorrect authorization / security feature bypass, CVE-2025-61830 (CVSS 7.1), aktualizacja do 3.8.0. Priorytet 3.
  • Substance 3D Stager – APSB25-113: krytyczne RCE. Priorytet 3.
  • Adobe Format Plugins – APSB25-114: wiele błędów, m.in. CWE-122 heap overflow → RCE; przykładowe CVE: CVE-2025-61837, CVE-2025-61838; aktualizacja do 1.1.2. Priorytet 3.

Klasy podatności (przekrojowo)

  • Memory corruption / heap overflow (CWE-122) → wykonanie kodu przy parsowaniu plików (PSD/AI/INDD/format plugins).
  • Incorrect authorization / security feature bypass (SDK Pass) → eskalacja możliwości w przepływach uwierzytelniania OTT/TVE.

Priorytet Adobe (co oznacza „3”?)

Priorytet 3 wg Adobe oznacza niski poziom oczekiwanej eksploatacji i brak pilności „typu 0-day”, ale zalecane jest zaplanowane wdrożenie. To nie jest ocena CVSS, lecz priorytetu wdrożeniowego.

Praktyczne konsekwencje / ryzyko

Wejścia atakujące: złośliwe pliki .indd / .icml / .psd / .ai lub rzadkie formaty obsługiwane przez Format Plugins (np. import/eksport). Atakujący może dostarczyć plik e-mailem/OneDrive/SharePoint, w repozytorium assetów, lub przez łańcuch dostaw (stock, paczki template’ów). Jedno „otwarcie” przez designera może wystarczyć, by uzyskać wykonanie kodu w kontekście użytkownika.

Środowiska wysokiego ryzyka: agencje kreatywne, działy marketingu, prepress, wydawnictwa – zwykle z szerokim spektrum zewnętrznych plików i krótkimi SLA.

Ryzyko wtórne: po inicjalnym RCE możliwe przemieszczenie boczne (tokeny SSO w pamięci, kradzież materiałów pod NDA, implanty w pluginach/skriptach CEP/UXP).

SDK Pass: dla zespołów mobile/OTT – błąd autoryzacji może naruszać przepływy logowania w aplikacjach TVE, prowadząc do obejścia kontroli dostępu.

Rekomendacje operacyjne / co zrobić teraz

A. Inwentaryzacja i szybka walidacja wersji

Windows (PowerShell):

# Sprawdź zainstalowane wersje kluczowych aplikacji Adobe (CC)
$paths = @("Adobe InDesign 2025","Adobe InCopy 2025","Adobe Photoshop 2025","Adobe Illustrator 2025")
$base = "HKLM:\SOFTWARE\Adobe"
Get-ChildItem $base -Recurse | Where-Object { $paths -contains $_.PSChildName } |
  ForEach-Object {
    $name = $_.PSChildName
    $ver = (Get-ItemProperty $_.PSPath).Version
    [pscustomobject]@{Product=$name;Version=$ver}
  }

macOS:

# przykładowo
mdls -name kMDItemVersion "/Applications/Adobe InDesign 2025/Adobe InDesign 2025.app"
mdls -name kMDItemVersion "/Applications/Adobe Illustrator 2025/Adobe Illustrator 2025.app"

Porównaj z wersjami docelowymi z biuletynów (np. InDesign ID21.0/20.5.1, Illustrator ≥29.8.3/30.0, Photoshop ≥26.9, Format Plugins 1.1.2, Adobe Pass SDK 3.8.0).

B. Dystrybucja aktualizacji

  • Środowiska zarządzane: Adobe Admin Console / pakiety wdrożeniowe (CC dla firm) – „self-service” wyłączyć do czasu aktualizacji; rollout falami (pilot → szerokie).
  • Użytkownicy końcowi: Creative Cloud Desktop → „Updates”. W działach o wysokiej ekspozycji na pliki zewnętrzne nadać wyższy priorytet.
  • Zespoły mobile: zaktualizować Adobe Pass Authentication Android SDK do 3.8.0, przetestować regresje, wydać hotfix w sklepach.

C. Tymczasowe ograniczenia ryzyka (jeśli nie możesz zaktualizować „od ręki”)

  • Segmentacja stanowisk DTP (VLAN/ACL), aplikacja listy dozwolonych dla wtyczek i skryptów (UXP/CEP).
  • Odcinanie makr/automatyzacji w przepływach importu plików od nieznanych kontrahentów.
  • Sanityzacja plików: konwersja przez „bezpieczniejszy” łańcuch (np. otwarcie w świeżym kontenerze/VDI).
  • AppLocker/WDAC: zezwól wyłącznie na podpisane binaria Adobe z aktualnych wersji.

D. Detekcje i telemetry (SOC)

IOA dla RCE w aplikacjach Adobe:

  • Niespodziewane child-processy od InDesign.exe / Photoshop.exe / Illustrator.exe (np. powershell.exe, wscript.exe, cmd.exe).
  • Wzorce DLL search order hijack/side-loading w katalogach profilu użytkownika.
  • Nietypowe wywołania CreateRemoteThread, VirtualAllocEx, z procesów Adobe do innych procesów użytkownika.

Przykładowe reguły (Sigma – uproszczone):

title: Adobe App Spawns Scripting Interpreter
logsource: { category: process_creation, product: windows }
detection:
  parent:
    Image|endswith:
      - '\InDesign.exe'
      - '\Photoshop.exe'
      - '\Illustrator.exe'
  child:
    Image|endswith:
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cmd.exe'
  condition: parent and child
level: high

Splunk (Process child):

index=sysmon EventCode=1
(ParentImage="*\\InDesign.exe" OR ParentImage="*\\Photoshop.exe" OR ParentImage="*\\Illustrator.exe")
(Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\cmd.exe")
| stats count by _time, host, ParentImage, Image, CommandLine

Dla Pass SDK (Android): testy bezpieczeństwa przepływów auth (wrong-issuer, token reuse, forged state), weryfikacja CVE-2025-61830 i aktualizacji zależności do 3.8.0.

E. Polityki i szkolenia

  • Edukacja zespołów kreatywnych: nie otwieramy niezweryfikowanych paczek projektów i presetów/wtyczek.
  • Wymuszaj aktualizacje przy starcie aplikacji (przez narzędzia MDM/Endpoint Management).

Różnice / porównania z innymi przypadkami (2025)

  • Commerce/Magento (IX–X 2025): potwierdzone wykorzystanie w praktyce (CVE-2025-54236) – wysoki priorytet operacyjny dla e-commerce; dzisiejsze biuletyny Creative Cloud nie mają statusu exploited.
  • AEM Forms (X 2025): publiczne PoC (CVE-2025-54253/54254) – inny segment produktu (serwer), ale sygnał, że atakujący inwestują w ekosystem Adobe.
  • Dzisiejsze luki: skupione na klientach (desktop/iPad/SDK) i parsowaniu formatów, co preferuje atak plikowy i soc-eng, a nie ataki serwerowe.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj ASAP: InDesign, InCopy, Photoshop, Illustrator (desktop + iPad), Substance 3D Stager, Format Plugins oraz Adobe Pass SDK.
  • Skoncentruj się na zespołach pracujących z zewnętrznymi plikami – to oni najczęściej będą wektorem inicjalnym.
  • Zaplanuj rollout (priorytet 3 ≠ „zignorować”): okno serwisowe w tym tygodniu, telemetry + blokady child-processów.
  • Mobile/OTT: wydaj update SDK Pass (3.8.0) i przetestuj przepływy auth.

Źródła / bibliografia

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”