Archiwa: Security News - Strona 218 z 343 - Security Bez Tabu

Pentagon oznacza Anthropic jako „Supply Chain Risk”. Co to znaczy dla bezpieczeństwa, kontraktów i użycia AI w obronności?

Wprowadzenie do problemu / definicja luki

Pod koniec lutego 2026 r. amerykańskie kierownictwo resortu obrony ogłosiło zamiar formalnego uznania firmy Anthropic (twórcy modelu Claude) za „supply chain risk” dla bezpieczeństwa narodowego. W narracji publicznej brzmi to jak „czarna lista” — ale w praktyce chodzi o instrumenty prawno-zamówieniowe, które pozwalają ograniczać lub blokować wykorzystanie określonych technologii w łańcuchu dostaw instytucji państwowych, zwłaszcza w systemach wrażliwych.

Kluczowe jest to, że spór nie dotyczy klasycznego incydentu cyber (np. wykrytego backdoora), tylko warunków użycia modeli AI w zastosowaniach wojskowych — w tym masowej inwigilacji krajowej oraz w pełni autonomicznych systemów rażenia.


W skrócie

  • Sekretarz resortu obrony (w materiałach źródłowych: „Department of War”) ogłosił skierowanie działań, by uznać Anthropic za „Supply Chain Risk to National Security”.
  • Anthropic twierdzi, że impas negocjacyjny wynikał z dwóch „wyjątków”, których firma nie chciała dopuścić w kontraktach: masowej inwigilacji Amerykanów oraz w pełni autonomicznych broni.
  • Spór wywołał efekt domina: wątek kontraktów na modele AI dla sieci niejawnych i twardych „guardrails” został natychmiast podchwycony przez konkurencję (OpenAI) i media.
  • W tle jest przepis 10 U.S.C. § 3252, który opisuje działania zakupowe i tryb postępowania w sprawach „supply chain risk”.

Kontekst / historia / powiązania

Z publicznych oświadczeń wynika, że Anthropic wcześniej współpracował z administracją USA w środowiskach o podwyższonej wrażliwości: firma podkreśla wdrożenia w sieciach niejawnych i zastosowania „mission-critical” (m.in. analiza wywiadowcza, planowanie, cyberoperacje).

Punktem zapalnym stał się postulat rządu, by resort mógł używać modelu „do wszystkich legalnych celów” (w tym potencjalnie takich, których Anthropic nie chce wspierać kontraktowo), oraz spór o to, czy dostawca AI może narzucać ograniczenia użycia w sferze obronnej.

Równolegle temat stał się elementem politycznej eskalacji: pojawił się komunikat o wygaszaniu użycia technologii Anthropic w agencjach federalnych w horyzoncie 6 miesięcy oraz wątek natychmiastowych ograniczeń dla kontrahentów wojskowych.


Analiza techniczna / szczegóły decyzji

1) „Supply chain risk” w tym przypadku = narzędzie zakupowe, nie „dowód infekcji”

Warto oddzielić dwie warstwy:

  • Warstwa cyber: klasycznie „supply chain risk” kojarzy się z ryzykiem sabotażu/kompromitacji komponentu w łańcuchu dostaw (np. biblioteka, firmware, poddostawca).
  • Warstwa kontraktowo-regulacyjna: 10 U.S.C. § 3252 opisuje uprawnienia i tryb prowadzenia działań zakupowych związanych z ryzykiem łańcucha dostaw (w tym ograniczanie ujawniania podstaw decyzji) oraz formalne wymagania dot. oceny i notyfikacji.

Artykuł The Hacker News podkreśla dodatkowo, że — według stanowiska Anthropic — ewentualna kwalifikacja w oparciu o 10 U.S.C. § 3252 miałaby dotyczyć użycia Claude w ramach kontraktów resortu, a nie „globalnego” zakazu świadczenia usług dla innych klientów. To istotne dla firm prywatnych i integratorów, bo ogranicza (przynajmniej w teorii) zakres rażenia decyzji.

2) Spór o „guardrails” – dwa punkty krytyczne

Anthropic publicznie wskazuje dwie czerwone linie, których nie chce dopuścić kontraktowo:

  • masowa krajowa inwigilacja,
  • w pełni autonomiczne systemy broni.

Z kolei Reuters opisuje, że OpenAI w swoim kontrakcie z resortem obrony akcentuje analogiczne „red lines” (m.in. brak masowej inwigilacji, brak kierowania autonomiczną bronią, brak wysokostawkowych decyzji automatycznych) oraz „warstwowe zabezpieczenia” wdrożenia w sieciach niejawnych. To pokazuje, że rynek próbuje „produktować” zgodność i kontrolę użycia jako element oferty.


Praktyczne konsekwencje / ryzyko

Dla kontraktorów i dostawców robiących biznes z wojskiem USA

  • Ryzyko compliance: jeśli komunikaty o zakazie „commercial activity” dla kontraktorów resortu byłyby egzekwowane szeroko, firmy muszą szybko ustalić, czy i gdzie używają Claude (np. w narzędziach do analizy dokumentów, SOC, red-teamingu, automatyzacji raportów).
  • Ryzyko dostaw i podwykonawców: nawet jeśli prawnie zakres jest węższy (spór o interpretację 10 U.S.C. § 3252), w praktyce audyty łańcucha dostaw i polityki zakupowe potrafią działać „ponad literą” — przez wymagania umowne, certyfikacje i oświadczenia.

Dla organizacji komercyjnych poza sferą wojskową

  • Ryzyko reputacyjne i vendor-risk: głośna etykieta „supply chain risk” może wymuszać dodatkowe oceny ryzyka dostawcy (TPRM), nawet jeśli formalnie nie dotyczy klientów cywilnych.
  • Ryzyko ciągłości usług: jeśli część ekosystemu (np. integratorzy pracujący równolegle dla DoD i cywila) zacznie ograniczać użycie Claude, mogą pojawić się migracje do alternatywnych modeli i zmiany w łańcuchu narzędzi.

Dla bezpieczeństwa informacji

Paradoksalnie, konflikty o „guardrails” mogą podbijać presję na:

  • uruchamianie modeli na środowiskach odseparowanych,
  • twardsze kontroly dostępu, logowania i audytowalności,
  • formalizację zasad: czego model nie może robić w środowiskach krytycznych.

Rekomendacje operacyjne / co zrobić teraz

Jeśli Twoja organizacja jest dostawcą, integratorem lub podwykonawcą w ekosystemie obronnym (USA lub sojuszniczym), potraktuj to jak incydent compliance z ryzykiem operacyjnym:

  1. SBOM/AI-BOM dla AI: zinwentaryzuj użycie modeli Anthropic/Claude (API, wtyczki, narzędzia z wbudowanym Claude, automatyzacje, pipeline’y).
  2. Segmentacja przypadków użycia: oddziel zastosowania „core” (np. analiza danych wrażliwych) od peryferyjnych (np. copywriting, summarization), bo to determinuje priorytet migracji.
  3. Kontrola dostawców: sprawdź, czy Twoi dostawcy (np. platformy bezpieczeństwa, narzędzia do obsługi ticketów, chatboty) nie korzystają z Claude „pod maską”.
  4. Plan migracji: przygotuj wariant „switch” na alternatywne modele (technicznie: abstrakcja warstwy LLM, kompatybilność promptów, testy regresji bezpieczeństwa).
  5. Polityka użycia AI: spisz wprost zakazane klasy zastosowań (np. decyzje wysokostawkowe bez człowieka w pętli; generowanie celów; masowe profilowanie osób), bo to minimalizuje ryzyko kontraktowe i prawne — niezależnie od dostawcy.

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

W dyskusjach publicznych pojawia się porównywanie „supply chain risk” do działań wobec firm postrzeganych jako ryzyko państwowe. Tutaj jednak wyróżnikiem jest to, że mówimy o amerykańskim dostawcy AI i sporze o dopuszczalne use-case’y, a nie o wykazanej kompromitacji technicznej produktu w łańcuchu dostaw.

Druga różnica: wątek AI ma „warstwę normatywną” — dostawcy chcą wbudować ograniczenia użycia w umowy i wdrożenia, a administracja oczekuje szerokiej dyspozycyjności technologii „dla wszystkich legalnych celów”. To konflikt modelu odpowiedzialności, a nie tylko ryzyka cyber.


Podsumowanie / kluczowe wnioski

  • Oznaczenie Anthropic jako „supply chain risk” jest w tej historii przede wszystkim narzędziem presji kontraktowo-politycznej związanej z ograniczeniami użycia AI, a nie klasycznym komunikatem o kompromitacji.
  • Fundamentem formalnym jest 10 U.S.C. § 3252 (mechanizmy działań zakupowych w kontekście ryzyka łańcucha dostaw), ale interpretacja realnego zasięgu ograniczeń może stać się osią sporu prawnego i compliance.
  • Dla firm współpracujących z obronnością kluczowe jest szybkie TPRM + inwentaryzacja użycia modeli i przygotowanie planów migracji / substytucji.
  • Równolegle konkurencja (np. OpenAI) stara się pokazać, że „guardrails” da się zapisać w umowach i wdrożyć warstwowo — co będzie rosnącym standardem w kontraktach na AI w środowiskach krytycznych.

Źródła / bibliografia

  1. The Hacker News – opis decyzji i tło sporu (28 lutego 2026). (The Hacker News)
  2. Anthropic – oświadczenie dot. komentarzy sekretarza (27 lutego 2026). (Anthropic)
  3. Anthropic (Dario Amodei) – stanowisko ws. warunków użycia i współpracy (26 lutego 2026). (Anthropic)
  4. Reuters – szczegóły „guardrails” w umowie OpenAI z DoD i kontekst decyzji (28 lutego 2026). (Reuters)
  5. U.S. Code – 10 U.S.C. § 3252 (ramy dot. „supply chain risk”). (U.S. Code)

Kimwolf: kim jest botmaster „Dort” i dlaczego ta historia ma znaczenie dla obrony sieci?

Wprowadzenie do problemu / definicja luki

Kimwolf to wyjątkowo duży i „ruchliwy” botnet, który łączy klasyczne możliwości DDoS z mechaniką typową dla ekosystemu residential proxy: wykorzystuje urządzenia końcowe jako przekaźniki, a następnie (co kluczowe) próbuje penetrować sieci lokalne ofiary, szukając kolejnych podatnych hostów. To przesunięcie ciężaru z „tylko DDoS” na automatyczne rozprzestrzenianie się wewnątrz sieci sprawia, że temat dotyczy nie tylko operatorów usług online, ale też SOC-ów w firmach i instytucjach.


W skrócie

  • Dziennikarz śledczy Brian Krebs opublikował 28 lutego 2026 r. analizę OSINT dotyczącą tego, co można wiarygodnie ustalić o operatorze Kimwolf działającym pod nickiem „Dort”.
  • Według relacji, po wcześniejszych publikacjach o Kimwolf doszło do eskalacji nękania: DDoS, doxingu, mail-bombingu oraz incydentu typu swatting wymierzonego w badacza.
  • Niezależnie od wątku tożsamości, Kimwolf technicznie wyróżnia się m.in. użyciem DNS-over-TLS (DoT), szyfrowaniem/ukrywaniem wskaźników C2 oraz rozwiązaniami opartymi o ENS (Ethereum Name Service) w celu utrudnienia przejęć i takedownów.
  • Telemetria z ochrony DNS wskazuje, że sygnały powiązane z Kimwolf (zapytania DNS do domen infrastruktury) pojawiały się w istotnym odsetku środowisk organizacyjnych, co sugeruje realną ekspozycję także poza „domowym IoT”.

Kontekst / historia / powiązania

Wątek „kim jest Dort” jest w dużej mierze historią o tym, jak publiczne ślady (fora, GitHub, komunikatory, stare aliasy) potrafią łączyć aktywność z różnych etapów życia: od cheatów i sceny gamingowej po narzędzia ułatwiające nadużycia (np. omijanie CAPTCHA, tymczasowe e-maile) i – finalnie – operacje botnetowe. Krebs opisuje też, że osoba łączona z tym pseudonimem zaprzecza udziałowi w części nowszych aktywności i podnosi możliwość przejęcia kont / podszycia się.

Ważne: dla bezpieczeństwa operacyjnego organizacji tożsamość operatora bywa mniej istotna niż wniosek z tej historii: po ujawnieniu słabego punktu w łańcuchu infekcji (w tym przypadku w ekosystemie usług proxy) grupa przestępcza może przejść w tryb odwetu i zastraszania – a jednocześnie szybko adaptować infrastrukturę.


Analiza techniczna / szczegóły luki

1. Warstwa C2 i „utrudnianie życia” obrońcom

Z analiz XLab wynika, że Kimwolf:

  • kapsułkuje zapytania DNS w DNS-over-TLS (port 853), co ogranicza widoczność dla części klasycznych mechanizmów inspekcji i utrudnia proste korelacje domen ↔ próbki;
  • ukrywa/transformuje wskaźniki C2 (m.in. proste operacje XOR dla wyliczenia „prawdziwego” IP po rozstrzygnięciu domeny), co komplikuje IOC-based hunting;
  • po kolejnych próbach takedownów wzmocnił odporność, przenosząc część logiki na ENS/Ethereum (tzw. EtherHiding) – C2 może być publikowane/rotowane przez rekordy związane z domeną ENS, a samo źródło jest trudniejsze do „wyłączenia” klasycznymi metodami.

2. Model rozprzestrzeniania i „wejście do sieci lokalnej”

Kimwolf jest opisywany jako botnet, który w praktyce korzysta z realiów rynku residential proxy: urządzenie końcowe (czasem legalnie zainstalowany komponent/SDK) staje się punktem zaczepienia, a następnie wykorzystywane jest do skanowania i prób infekcji innych urządzeń „za NAT-em” w tej samej sieci.

3. Skala i profil ataków DDoS

Cloudflare opisuje „ekosystem” Aisuru–Kimwolf jako zdolny do hiperwolumetrycznych ataków DDoS (rzędu dziesiątek Tbps / miliardów pps) i podkreśla, że Kimwolf jest wyspecjalizowaną „androidową” gałęzią większej rodziny.


Praktyczne konsekwencje / ryzyko

  1. Ryzyko wewnętrzne (east-west): jeśli Kimwolf (lub operatorzy, którzy korzystają z zainfekowanych hostów jako proxy) osiągną foothold w sieci biurowej, kolejnym etapem może być automatyczne rozpoznanie i infekcja podatnych urządzeń lokalnych.
  2. Ryzyko dla dostępności usług: nawet jeśli Twoja organizacja nie jest celem, DDoS-y tej skali potrafią generować efekty uboczne po stronie operatorów i dostawców upstream.
  3. Ryzyko „wymuszeń” i nękania: opisywana eskalacja (doxing, swatting, groźby) przypomina, że w konfliktach wokół botnetów granica między cyber a fizycznym zastraszaniem potrafi się zacierać.

Rekomendacje operacyjne / co zrobić teraz

Szybkie „must do” dla SOC / IT

  • Zrób inwentaryzację Android TV boxów/SmartTV i „dziwnych” IoT w sieci firmowej (tak, one często lądują w biurach i salach konferencyjnych).
  • Segmentacja sieci: IoT/AV w osobnym VLAN, z restrykcyjnym ruchem wychodzącym i brakiem dostępu do zasobów krytycznych.
  • Monitoring DNS i polityki blokowania: przeglądaj logi pod kątem zapytań do znanych domen/infrastruktury botnetowej i rozważ ochronny DNS, w tym blokowanie podejrzanych rozstrzygnięć (np. bogon / nietypowe odpowiedzi).
  • Widoczność DoT: jeżeli polityka na to pozwala, ogranicz/monitoruj bezpośrednie DoT do publicznych resolverów (np. ruch na 853) z segmentów, które nie powinny tego robić.

Dla zespołów odpowiedzialnych za dostępność (DDoS)

  • Zweryfikuj, czy Twoja ochrona DDoS obejmuje scenariusze „burst/hit-and-run” i carpet bombing oraz czy masz procedury eskalacji do ISP/CDN.

Dla zespołów bezpieczeństwa ludzi (anti-harassment)

  • Jeśli Twoi badacze/administratorzy występują publicznie, przygotuj playbook na doxing i swatting: kontakt z lokalną policją, „PIN/hasło” do weryfikacji zgłoszeń, procedury komunikacji kryzysowej. (To wynika z obserwowanego wzorca nękania w tej sprawie).

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

  • Mirai i pochodne historycznie pokazały, jak wycieki kodu i masowa eksploatacja IoT budują botnety „z fabryki”, ale Kimwolf wyróżnia się naciskiem na Android/TV boxy oraz elementy proxying/monetyzacji.
  • Aisuru–Kimwolf (wg Cloudflare) to relacja „parent ↔ wariant”: wspólna filozofia DDoS, ale Kimwolf jest „wyspecjalizowany” w Androidzie i realiach rynku residential proxy.
  • Na tle wielu botnetów Kimwolf ma nietypowo dużo mechanizmów „anty-takedown”, w tym ENS/Ethereum jako kanał przenoszenia wskaźników C2.

Podsumowanie / kluczowe wnioski

  • Historia „kim jest Dort” pokazuje nie tylko wartość OSINT, ale też to, jak szybko operatorzy botnetów potrafią przejść od operacji technicznych do kampanii nękania.
  • Kimwolf to problem obrony warstwowej: IoT/Android w sieci, widoczność DNS/DoT, segmentacja, a także gotowość na DDoS o dużej dynamice.
  • Nawet jeśli nie jesteś „celem”, telemetria DNS sugeruje, że sygnały powiązane z Kimwolf mogą pojawiać się w środowiskach organizacyjnych z zaskakującą częstotliwością – warto to sprawdzić w logach.

Źródła / bibliografia

  1. Brian Krebs, Who is the Kimwolf Botmaster “Dort”?, 28 lutego 2026. (krebsonsecurity.com)
  2. Infoblox Threat Intelligence, Kimwolf: Howls from Inside the Enterprise (telemetria DNS i rekomendacje obrony). (Infoblox)
  3. Cloudflare Learning Center, What is the Aisuru-Kimwolf botnet? (skala i charakterystyka ataków). (Cloudflare)
  4. QiAnXin XLab, Kimwolf Exposed… (DoT, ENS/EtherHiding, techniczne detale). (奇安信 X 实验室)
  5. Barracuda Networks Blog, Malware Brief: New wave of botnets driving DDoS chaos, 29 stycznia 2026. (Barrcuda Blog)

ClawJacked: podatność pozwalająca złośliwym stronom przejąć lokalne agenty OpenClaw przez WebSocket

Wprowadzenie do problemu / definicja luki

ClawJacked to nazwa łańcucha podatności/opcji projektowych, które pozwalały dowolnej odwiedzanej stronie WWW (złośliwej lub przejętej) nawiązanie połączenia z lokalnie uruchomioną bramą (gateway) OpenClaw i stopniowe przejęcie kontroli nad agentem AI. W praktyce wystarczało samo wejście na stronę – bez instalowania wtyczek czy „marketplace skills”.

Sedno problemu nie leży w „magii AI”, tylko w klasycznym założeniu: „localhost jest zaufany”. W nowoczesnych przeglądarkach to założenie bywa fałszywe, bo JavaScript uruchomiony na zewnętrznej domenie potrafi zestawić połączenie WebSocket do usług na 127.0.0.1, jeśli te usługi nie bronią się poprawnie.


W skrócie

  • Atak startuje od wejścia użytkownika na złośliwą stronę.
  • JavaScript otwiera WebSocket do localhost na porcie bramy OpenClaw.
  • Następuje szybki brute force hasła (brak/obejście limitów dla połączeń z localhost).
  • Po zalogowaniu skrypt rejestruje się jako zaufane urządzenie (auto-akceptacja pairingu z localhost, bez promptu).
  • Efekt: atakujący zyskuje kontrolę administracyjną nad agentem: odczyt konfiguracji, logów, enumeracja węzłów/urządzeń, a dalej – wykonywanie działań w imieniu agenta.
  • OpenClaw wydał poprawkę (release 2026.2.25, 26 lutego 2026) hardeningując uwierzytelnianie WebSocket i blokując ciche auto-parowanie dla „obcych” klientów przeglądarkowych.

Kontekst / historia / powiązania

Wiadomość o ClawJacked pojawiła się w momencie, gdy ekosystem agentów OpenClaw jest już pod ostrzałem: od problemów z bezpieczeństwem instancji wystawionych do sieci, po ryzyko wynikające z „skills supply chain”. The Hacker News opisuje m.in. równoległe łatki (np. scenariusze log poisoning przez WebSocket do publicznie dostępnych instancji) oraz przypadki złośliwych „skills” wykorzystywanych do oszustw kryptowalutowych.

Z perspektywy obrony to ważne: agent AI działa jak „super-integracja” – ma dostęp do narzędzi, kont, danych, a często także możliwość wykonywania akcji. Dlatego przejęcie agenta bywa równoznaczne z przejęciem środowiska pracy.


Analiza techniczna / szczegóły luki

1. Mechanika ataku (łańcuch ClawJacked)

Oasis Security opisało pełen łańcuch w pięciu krokach:

  1. ofiara odwiedza stronę atakującego,
  2. JavaScript otwiera WebSocket do localhost na porcie bramy OpenClaw (WebSocket nie jest automatycznie blokowany „klasyczną” polityką cross-origin w tym scenariuszu),
  3. brute force hasła z wysoką częstotliwością, bo mechanizmy throttling/rate-limit nie obejmowały loopback/localhost,
  4. ciche „pairing” jako zaufane urządzenie (auto-approve z localhost, bez interakcji użytkownika),
  5. pełna kontrola: interakcja z agentem, zrzut konfiguracji, enumeracja podłączonych węzłów, odczyt logów.

2. Dlaczego to działało: „implicit trust” + brak kontroli źródła (Origin)

Kluczowe są dwa elementy:

  • Brak sensownej weryfikacji Origin dla WebSocket (lub zbyt liberalne traktowanie klientów przeglądarkowych).
  • Traktowanie localhost jako strefy zaufanej, co skutkowało m.in. słabszym egzekwowaniem ograniczeń logowania oraz automatycznym zatwierdzaniem pairingu.

3. Co zmieniono w poprawce

W release 2026.2.25 OpenClaw wskazuje bezpośrednio utwardzenia wokół „Gateway WebSocket auth”: m.in. enforcement origin checks dla klientów przeglądarkowych, throttling nieudanych prób hasła także dla localhost oraz zablokowanie cichego auto-pairingu dla przeglądarkowych klientów innych niż kontrolny interfejs UI.


Praktyczne konsekwencje / ryzyko

Po przejęciu sesji atakujący może wykorzystywać uprawnienia agenta do działań „pośrednich”, które w realnym środowisku są krytyczne:

  • przeszukiwanie historii komunikatorów (np. Slack) pod kątem sekretów/API keys,
  • odczyt prywatnych wiadomości,
  • eksfiltracja plików z podłączonych węzłów/urządzeń,
  • wykonywanie poleceń (jeśli agent ma do tego drogę przez integracje/węzły).

Dla organizacji to często nie jest „tylko incydent na laptopie developera”, ale ryzyko kaskadowe: przejęte tokeny i integracje mogą dać dostęp do repozytoriów, pipeline’ów CI/CD, sekretów w konfiguracjach i środowiskach chmurowych.


Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj OpenClaw co najmniej do 2026.2.25 (to wersja wskazywana jako zawierająca naprawę łańcucha ClawJacked).
  2. Traktuj „localhost” jak sieć niezaufaną:
    • nie zwalniaj loopback z rate-limitów,
    • nie auto-zatwierdzaj pairingu/urządzeń na podstawie IP.
  3. Ogranicz ekspozycję bramy: jeśli masz możliwość, ogranicz nasłuch do minimalnego interfejsu, kontroluj firewallem procesy/porty, rozważ izolację profilu (np. osobna maszyna/VM dla agentów).
  4. Audyt uprawnień agenta: przegląd integracji, tokenów, kluczy, zakresów oraz zasad „least privilege”.
  5. Monitoring i detekcja: loguj i alertuj na nietypowe próby auth/pairingu, skoki liczby połączeń WebSocket do gateway, oraz anomalie w działaniach agenta (np. odczyt dużych wolumenów danych, masowe „search” po sekretach).

Różnice / porównania z innymi przypadkami

ClawJacked vs. CVE-2026-25253 („1-click RCE”)

W obiegu pojawiają się równolegle dwa wątki, które łatwo pomylić:

  • ClawJacked (Oasis): nacisk na cross-origin WebSocket do localhost + brute force + auto-pairing i przejęcie kontroli nad agentem z poziomu przeglądarki; naprawa wskazywana w linii 2026.2.25.
  • CVE-2026-25253 (NVD/MITRE): opis dotyczy sytuacji, w której OpenClaw przed 2026.1.29 pobiera gatewayUrl z query string i automatycznie zestawia połączenie WebSocket bez promptu, wysyłając token; CVSS 8.8 (wektor: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).

Część publikacji medialnych zestawia te tematy razem (bo oba dotyczą WebSocket i „1-click” scenariuszy), ale w obronie warto rozdzielać: inne są warunki wejścia, inny „root cause” i inne wersje graniczne.


Podsumowanie / kluczowe wnioski

  • „Lokalnie uruchomione” nie oznacza „bezpieczne” – przeglądarka może stać się mostem do usług na localhost, jeśli te nie egzekwują Origin/rate-limitów i zbyt ufają loopback.
  • ClawJacked pokazuje typowy anty-wzorzec: upraszczanie DX kosztem security (auto-pairing, brak throttlingu dla localhost).
  • Najpilniejsze działanie: aktualizacja do 2026.2.25 oraz audyt uprawnień i integracji agenta, bo przejęcie agenta to często przejęcie tożsamości i dostępu do narzędzi.

Źródła / bibliografia

  • The Hacker News — „ClawJacked Flaw Lets Malicious Sites Hijack Local OpenClaw AI Agents via WebSocket” (28.02.2026). (The Hacker News)
  • Oasis Security (PRNewswire) — opis łańcucha ataku i rekomendacje (26.02.2026). (PR Newswire)
  • CSO Online — kontekst „localhost trust” i ryzyko operacyjne (27.02.2026). (CSO Online)
  • GitHub Releases — OpenClaw v2026.2.25: utwardzenia WebSocket auth/origin checks/throttling/auto-pairing (26.02.2026). (GitHub)
  • NVD (NIST) — CVE-2026-25253: opis i metryki CVSS (publikacja 01.02.2026, modyfikacja 13.02.2026). (NVD)

Wyciek danych Canadian Tire: nawet 38,3 mln kont e-commerce w zestawie opublikowanym w sieci

Wprowadzenie do problemu / definicja luki

Canadian Tire Corporation (CTC) potwierdziła incydent bezpieczeństwa dotyczący bazy e-commerce, w której znajdowały się dane klientów kilku marek detalicznych. Sprawa wróciła na nagłówki pod koniec lutego 2026 r., gdy zestaw danych związany z tym incydentem został dodany do serwisu Have I Been Pwned (HIBP), co ułatwiło weryfikację, czy konkretne adresy e-mail znalazły się w wycieku.

W praktyce nie mówimy tu o „jednym sklepie”, tylko o wspólnej infrastrukturze kont online dla m.in. Canadian Tire, SportChek, Mark’s/L’Équipeur i Party City, co znacząco zwiększa skalę oddziaływania incydentu.


W skrócie

  • Incydent wykryto 2 października 2025 r. i dotyczył konkretnej bazy e-commerce (nie całej infrastruktury).
  • Według HIBP wyciek obejmuje ok. 42 mln rekordów, w tym 38,3 mln unikalnych adresów e-mail.
  • Dane zawierają m.in. imię i nazwisko, e-mail, a w opublikowanym zestawie także adresy i numery telefonów; hasła były przechowywane jako hashe PBKDF2.
  • CTC podkreśla, że incydent nie obejmował Canadian Tire Bank ani programu lojalnościowego Triangle Rewards.

Kontekst / historia / powiązania

CTC poinformowała o incydencie w komunikacji z października 2025 r., wskazując na nieautoryzowany dostęp do bazy danych związanej z kontami e-commerce. W komunikacie opisano kategorie danych i zapewniono, że podatność została usunięta oraz że firma współpracuje z zewnętrznymi ekspertami, by wzmocnić zabezpieczenia.

W lutym 2026 r. temat ponownie zyskał rozgłos, bo HIBP dodał wpis „Canadian Tire” z opisem skali oraz struktury danych (m.in. PBKDF2 dla haseł) i liczebności unikalnych adresów e-mail.


Analiza techniczna / szczegóły luki

1) Co zostało naruszone (warstwa danych):
CTC wskazywała na „basic personal information” powiązane z kontami e-commerce (w tym m.in. e-mail i hasła w postaci zaszyfrowanej/zhashowanej) oraz – dla części osób – informacje o dacie urodzenia i ucięte dane kart płatniczych.

2) Co pokazuje materiał w HIBP (warstwa „wyciek w obiegu”):
HIBP opisuje zestaw jako ok. 42 mln rekordów i 38 mln+ unikalnych e-maili, z polami takimi jak: imię i nazwisko, telefon, adres, oraz hasła jako PBKDF2. Dla części rekordów mają występować także daty urodzenia oraz „partial credit card data” (np. typ karty, data ważności, zamaskowany numer).

3) Dlaczego PBKDF2 ma znaczenie (i dlaczego nie jest „tarczą absolutną”):
PBKDF2 to funkcja KDF zaprojektowana do spowalniania łamania haseł. Jeśli jednak użytkownik miał słabe/krótkie hasło albo hasło było ponownie użyte gdzie indziej, atakujący mogą:

  • próbować crackingu offline (w zależności od parametrów PBKDF2),
  • stosować credential stuffing w innych serwisach,
  • budować bardzo wiarygodny phishing na podstawie danych kontaktowych.
    Same hashe PBKDF2 to lepiej niż „plain text”, ale przy skali dziesiątek milionów rekordów presja atakujących na automatyzację rośnie.

Praktyczne konsekwencje / ryzyko

Najbardziej prawdopodobne scenariusze nadużyć po takim wycieku to:

  • Phishing i vishing „pod markę” (Canadian Tire / SportChek / Mark’s / Party City): mając e-mail, telefon i adres, przestępcy mogą przygotować wiadomości podszywające się pod „weryfikację konta”, „dopłatę do przesyłki”, „zwrot” czy „podejrzaną transakcję”.
  • Credential stuffing: jeśli użytkownik reuse’ował hasło, ryzyko przejęcia kont w innych usługach jest realne (nawet jeśli samo konto Canadian Tire ma dodatkowe zabezpieczenia).
  • Uwiarygodnianie kradzieży tożsamości: data urodzenia (nawet w podzbiorze) w połączeniu z adresem i telefonem zwiększa „jakość” profilu ofiary do oszustw finansowych i socjotechniki.
  • Ataki na kanały odzyskiwania dostępu: numer telefonu bywa wykorzystywany w próbach przejęcia numeru (SIM-swap) lub w podszywaniu się w kontakcie z helpdeskiem.

Warto też zaznaczyć, że CTC komunikowała brak wpływu na bank i Triangle Rewards, co ogranicza zakres potencjalnych nadużyć w tych konkretnych ekosystemach.


Rekomendacje operacyjne / co zrobić teraz

Jeśli kiedykolwiek zakładałeś(aś) konto e-commerce u Canadian Tire / SportChek / Mark’s/L’Équipeur / Party City:

  1. Zmień hasło (w tym serwisie) na długie i unikalne; najlepiej wygenerowane w menedżerze haseł.
  2. Jeśli to hasło było używane gdziekolwiek indziej: zmień je wszędzie, zaczynając od poczty e-mail i kont finansowych.
  3. Włącz MFA/2FA tam, gdzie to możliwe (zwłaszcza e-mail).
  4. Sprawdź swój adres e-mail w HIBP i potraktuj wynik jako sygnał do „higieny haseł” w całym swoim ekosystemie kont.
  5. Uważaj na kontakty „z działu bezpieczeństwa” proszące o kod, dopłatę, „potwierdzenie danych” — szczególnie przez SMS/telefon.

Z perspektywy organizacji (blue team / SOC / IAM):

  • dodaj domeny i brandy do reguł antyphishingowych (słowa kluczowe, szablony tematów),
  • wprowadź wymuszenie resetu haseł + detekcję credential stuffing (rate limiting, bot mitigation),
  • przeanalizuj parametry KDF (koszt PBKDF2, unikalne sól, rotacja) i politykę haseł,
  • oceń ekspozycję danych w systemach e-commerce (minimalizacja pól, retencja, segmentacja baz).

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

  • Wyciek „e-commerce database” vs. ekosystem finansowy/lojalnościowy: CTC podkreśla, że incydent nie dotyczył Canadian Tire Bank ani Triangle Rewards — to częsty podział w dużych grupach: osobne systemy i osobne rejestry ryzyka.
  • Hashe PBKDF2 vs. hasła jawne: PBKDF2 znacząco utrudnia masowe łamanie haseł, ale przy takiej skali i typowych praktykach użytkowników (reuse) nadal należy zakładać wysoki poziom wtórnych nadużyć.
  • Różnice w liczbach: firma opisywała zakres incydentu w kategoriach „kont/danych” w komunikacji październikowej, natomiast HIBP agreguje i normalizuje zestaw danych „w obiegu” (rekordy, unikalne e-maile), co bywa źródłem rozbieżności w narracji liczbowej.

Podsumowanie / kluczowe wnioski

Incydent Canadian Tire to przykład, jak „jedna” baza e-commerce może w praktyce oznaczać dziesiątki milionów użytkowników wielu marek. Nawet jeśli nie doszło do naruszenia systemów bankowych i lojalnościowych, sam pakiet PII (e-mail/telefon/adres) plus hashe haseł (PBKDF2) jest wystarczający do szeroko zakrojonych kampanii phishingowych i prób przejęć kont przez credential stuffing.


Źródła / bibliografia

  • SecurityWeek – opis skali (38,3 mln e-maili / ~42 mln rekordów) i kontekstu dodania do HIBP (28 lutego 2026). (SecurityWeek)
  • Have I Been Pwned – wpis „Canadian Tire” (typy danych, PBKDF2, liczby rekordów). (Have I Been Pwned)
  • Canadian Tire Corporation – strona „Cyber Incident” (zakres systemów i zapewnienia dot. Bank/Triangle Rewards). (corp.canadiantire.ca)
  • Canadian Tire Corporation – komunikat prasowy z 14 października 2025 r. (oś czasu i charakter incydentu). (corp.canadiantire.ca)
  • Digital Commerce 360 – kontekst biznesowy i streszczenie ujawnionych kategorii danych (15 października 2025). (Digital Commerce 360)

4,8 mln USD w kryptowalutach skradzione po tym, jak koreański urząd skarbowy ujawnił seed frazę portfela

Wprowadzenie do problemu / definicja luki

W świecie kryptowalut „seed phrase” (fraza odzyskiwania, zwykle 12/24 słowa) to najważniejszy sekret — równoważnik „master key”, który pozwala odtworzyć portfel na dowolnym urządzeniu i przenieść wszystkie środki bez fizycznego dostępu do sprzętowego portfela (np. Ledger) ani znajomości PIN-u. Dlatego ujawnienie seeda nie jest „wyciekiem danych”, tylko praktycznie oddaniem pełnej kontroli nad aktywami.

Dokładnie taki scenariusz wydarzył się w Korei Południowej: w oficjalnych materiałach prasowych opublikowano zdjęcia, na których było widać niezamaskowaną frazę odzyskiwania dla przejętego portfela. Chwilę później aktywa zniknęły z adresu.


W skrócie

  • Po publikacji materiałów promujących akcję przeciw dłużnikom podatkowym, ujawniono mnemonic/seed portfela z przejętymi kryptowalutami.
  • Z adresu wyprowadzono 4 mln tokenów PRTG (Pre-Retogeum) o wartości ok. 4,8 mln USD (raporty podają też równowartość ok. 6,4 mld KRW).
  • Według analizy on-chain napastnik najpierw zasilił portfel niewielką ilością ETH na opłaty gas, a następnie przetransferował tokeny (w relacjach: kilka transakcji).
  • Policja wszczęła postępowanie i analizuje przepływ środków.

Kontekst / historia / powiązania

Incydent dotyczy portfela przejętego w ramach działań wobec 124 osób wskazywanych jako „wysokokwotowi / uporczywi” dłużnicy podatkowi. W komunikacji publicznej akcentowano sukces operacji i wartość zabezpieczonych aktywów, ale to właśnie materiały „dowodowe” stały się nośnikiem wycieku kluczowego sekretu.

Co istotne, koreańskie media i policja wskazują, że nie jest to odosobniony problem „custody” w instytucjach — w przestrzeni publicznej w Korei Południowej pojawiały się w ostatnich miesiącach inne kontrowersje związane z przechowywaniem zabezpieczonych kryptowalut.


Analiza techniczna / szczegóły luki

1) Klasa podatności: „sekret w materiale publicznym”

To nie był atak na kryptografię ani „złamanie” hardware walleta. To klasyczny błąd operacyjny: secret exposure w treści publikowanej publicznie (zdjęcie w wysokiej rozdzielczości, brak redakcji/maskowania).

W praktyce to odpowiednik opublikowania:

  • hasła root do serwera w PDF-ie,
  • prywatnego klucza API w repozytorium,
  • zdjęcia karty z kodami jednorazowymi.

2) Dlaczego seed phrase „omija” hardware wallet

Hardware wallet (Ledger i podobne) chroni klucz prywatny w urządzeniu, ale seed phrase to źródło deterministycznego odtworzenia kluczy (BIP-39/BIP-44 w typowych konfiguracjach). Jeśli ktoś ma seed, może:

  • odtworzyć portfel w innym kliencie,
  • podpisać transakcje „u siebie”,
  • wyprowadzić środki bez kontaktu z oryginalnym urządzeniem.

3) Mechanika kradzieży widoczna on-chain

Relacje wskazują, że napastnik:

  1. dorzucił trochę ETH na adres-ofiarę, aby zapłacić gas,
  2. wykonał transfery tokenów PRTG na kontrolowany adres (w mediach: kilka transakcji).

To wzorzec często spotykany przy drenażu tokenów z „pustych” adresów: tokeny są na adresie, ale nie ma ETH na opłaty — atakujący „sponsoruje” gas, bo i tak wychodzi na plus.


Praktyczne konsekwencje / ryzyko

Dla instytucji publicznych i organów ścigania

  • Utrata aktywów o wartości milionów USD w sytuacji, w której środki miały zasilić budżet państwa lub służyć jako dowód.
  • Ryzyko odpowiedzialności (audyt, kontrola, procedury, a potencjalnie także wątki prawne dot. ochrony informacji i należytej staranności — lokalnie może to podchodzić pod naruszenia przepisów o bezpieczeństwie informacji).
  • Erozja zaufania do kompetencji instytucji w obszarze „virtual asset custody”.

Dla organizacji i firm (lekcja uniwersalna)

Ten case pokazuje, że w bezpieczeństwie kryptowalut najczęściej przegrywa się nie z „hackerem 0-day”, tylko z:

  • procesem publikacji treści,
  • brakiem klasyfikacji informacji,
  • nieprzetestowanym workflow redakcji/maskowania,
  • brakiem nadzoru „four-eyes”.

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś instytucją, która zabezpiecza kryptowaluty (custody)

  1. Zakaz fotografowania seeda / materiałów odzyskiwania w procesach operacyjnych (to powinno być traktowane jak materiał „TOP SECRET”).
  2. Procedura redakcji i walidacji publikacji:
    • automatyczne wykrywanie fraz 12/24 słów (DLP + detekcja wzorców),
    • obowiązkowy przegląd przez drugą osobę (4-eyes),
    • publikacja wyłącznie wersji „media-safe” z zaszytą metryką: kto zatwierdził, kiedy, z jakiej checklisty.
  3. Model custody klasy enterprise: multi-sig / MPC, rozdział obowiązków, kontrola dostępu, logowanie działań, procedury awaryjne.
  4. Runbook „seed exposed”: jeśli doszło do ujawnienia — natychmiastowa migracja środków na nowe adresy, monitoring i alertowanie, eskalacja do SOC/CSIRT.

Jeśli jesteś użytkownikiem indywidualnym / firmą trzymającą środki na hardware wallet

  • Traktuj seed jak „jedyny klucz do sejfu”: nigdy zdjęcie, nigdy chmura, nigdy komunikatory.
  • Gdy istnieje podejrzenie ujawnienia seeda: przenieś środki na nowy portfel (z nową frazą) i unieważnij stary adres jako magazyn wartości.

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

  • Kradzież przez ujawniony seed vs klasyczny malware/phishing: tu nie ma potrzeby infekować komputera ofiary ani kraść PIN-u — seed daje pełnię kontroli „z definicji”.
  • Błąd custody w instytucji vs „self-custody” użytkownika: instytucje mają zwykle procedury i audyty, ale gdy traktują krypto jak „zwykły przedmiot dowodowy”, przegrywają na podstawach (klasyfikacja informacji + publikacje PR). Ten przypadek jest wręcz podręcznikowy.

Podsumowanie / kluczowe wnioski

  1. Seed phrase to master key — jej ujawnienie oznacza natychmiastową utratę kontroli nad portfelem.
  2. Incydent w Korei Południowej pokazuje, że realne straty w kryptowalutach często wynikają z błędów proceduralnych, a nie zaawansowanych exploitów.
  3. Organizacje przejmujące krypto (zajęcia komornicze, dowody rzeczowe, zabezpieczenia) muszą wdrożyć profesjonalny model custody (multi-sig/MPC) oraz procesy DLP i redakcji publikacji.

Źródła / bibliografia

  • BleepingComputer — opis incydentu, kontekst publikacji zdjęć i szczegóły transferów. (BleepingComputer)
  • Maeil Business Newspaper (mk.co.kr) — relacja lokalna, opis ujawnienia „mnemonic” w materiałach prasowych oraz komentarze ekspertów. (매일경제)
  • Korea JoongAng Daily — informacja o wszczęciu działań policji i wątkach prawnych/śledczych. (Korea Joongang Daily)
  • Cointelegraph (via TradingView) — dodatkowe szczegóły i szerszy kontekst problemów custody w Korei Południowej. (TradingView)

QuickLens: przejęte rozszerzenie Chrome kradło krypto i uruchamiało ataki ClickFix

Wprowadzenie do problemu / definicja luki

Incydent z QuickLens – Search Screen with Google Lens to klasyczny przykład supply chain attack na ekosystem rozszerzeń przeglądarki: narzędzie, które wyglądało legalnie i miało realną bazę użytkowników, zostało przejęte (po zmianie właściciela) i zaktualizowane w sposób, który umożliwił dystrybucję złośliwych ładunków oraz kradzież danych – w tym danych umożliwiających przejęcie kryptowalut.

Kluczowy element tej historii to wykorzystanie ClickFix – techniki socjotechnicznej, w której ofiara jest nakłaniana do wykonania „czynności naprawczej” (np. uruchomienia polecenia lub „weryfikacji”), co w praktyce uruchamia etap infekcji.


W skrócie

  • QuickLens miał ok. 7 tys. użytkowników i w pewnym momencie otrzymał nawet wyróżnienie w Chrome Web Store.
  • 17 lutego 2026 pojawiła się wersja 5.8, która zawierała złośliwe skrypty: komponent ClickFix oraz funkcje kradzieżowe (infostealer).
  • Rozszerzenie żądało nowych uprawnień i miało reguły modyfikujące ruch/odpowiedzi stron w sposób ułatwiający wstrzyknięcie złośliwego JS.
  • Google usunęło rozszerzenie ze sklepu, a Chrome automatycznie je wyłączało u użytkowników.

Kontekst / historia / powiązania

Najgroźniejsze w atakach na rozszerzenia przeglądarkowe jest to, że nie musisz „czegoś podejrzanego instalować” w dniu ataku. W tym przypadku:

  • QuickLens startował jako funkcjonalny dodatek do wyszukiwania obrazem (Google Lens) w przeglądarce.
  • Po czasie doszło do zmiany właściciela (co jest częstym wektorem nadużyć: kupno „czystej” wtyczki z reputacją i użytkownikami, a potem podmiana aktualizacji).
  • Wersja 5.8 weszła jako „zwykła aktualizacja” — to dokładnie ten moment, w którym zaufanie użytkownika do dodatku działa przeciwko niemu.

Równolegle warto zauważyć, że ClickFix to nie pojedyncza kampania, tylko rosnąca rodzina schematów socjotechnicznych. Microsoft i Kaspersky opisują, jak atakujący modyfikują „wabiki” (fałszywe CAPTCHA, „naprawa błędu”, „weryfikacja”), żeby użytkownik sam uruchomił etap infekcji.


Analiza techniczna / szczegóły luki

1. Co zmieniła złośliwa aktualizacja

Z opisu analizy wynika, że wersja 5.8:

  • poprosiła o dodatkowe uprawnienia, m.in. związane z przechwytywaniem/obróbką żądań oraz regułami dostępu hostów (istotne, bo to rozszerza realny „zasięg” ataku do wielu witryn),
  • zawierała plik reguł, który usuwał nagłówki bezpieczeństwa z odpowiedzi stron, m.in. Content-Security-Policy (CSP), X-Frame-Options i X-XSS-Protection. To ważne, bo takie nagłówki utrudniają wstrzykiwanie i uruchamianie nieautoryzowanych skryptów.

W praktyce mówimy o scenariuszu, gdzie rozszerzenie:

  1. ma szerokie uprawnienia,
  2. potrafi osłabić ochronę po stronie przeglądarki/strony,
  3. może uruchamiać/ładować logikę ataku w kontekście stron, które odwiedza ofiara.

2. ClickFix jako mechanizm „domknięcia” infekcji

ClickFix w typowym ujęciu (wg Microsoft) zaczyna się od doprowadzenia ofiary do strony-wabika i przekonania jej do wykonania akcji, która skutkuje uruchomieniem złośliwego kodu (często przez polecenia/uruchomienie skryptu). To podejście jest skuteczne, bo część zabezpieczeń automatycznych gorzej radzi sobie z atakiem „wykonanym ręką użytkownika”.

CERT Orange Polska opisuje ClickFix jako socjotechnikę nastawioną na to, aby ofiara „sama się zainfekowała”, zwykle poprzez uruchomienie poleceń, które ściągają kolejne etapy (stealery/RAT-y).


Praktyczne konsekwencje / ryzyko

W tym incydencie zagrożenia były wielowarstwowe:

  • Kradzież kryptowalut: BleepingComputer wskazuje na próby przejęcia środków i rekomenduje migrację funduszy do nowego portfela, jeśli korzystasz z wymienionych portfeli.
  • Eksfiltracja danych z usług webowych: wśród działań wymieniono m.in. scraping zawartości Gmail oraz pozyskiwanie danych z Facebook Business Manager i YouTube.
  • Ryzyko przejęcia kont (hasła/tokens/sesje): jeśli rozszerzenie miało dostęp do przeglądarki i treści stron, konsekwencją mogą być kradzieże poświadczeń lub przejęcia sesji.
  • Zasięg i „cicha” dystrybucja: użytkownik nie musi nic ponownie instalować — wystarczy autoaktualizacja rozszerzenia.

Dodatkowo pojawiły się relacje, że celem mogli być też użytkownicy macOS (w kontekście stealerów). W tym konkretnym fragmencie redakcja zaznaczała brak pełnej weryfikacji niezależnej.


Rekomendacje operacyjne / co zrobić teraz

Jeśli QuickLens był zainstalowany w Twoim środowisku (domowym lub firmowym), potraktuj to jak incydent:

  1. Usuń rozszerzenie i sprawdź, czy nie pozostały powiązane komponenty/profil przeglądarki.
  2. Wymuś reset haseł do kluczowych usług (priorytet: poczta, konta reklamowe, giełdy/portfele krypto, SSO) oraz rozważ unieważnienie sesji (log out from all devices).
  3. Skan stacji (EDR/AV) + przegląd mechanizmów persistence (autostart, LaunchAgents/LaunchDaemons na macOS, harmonogram zadań na Windows).
  4. Jeśli używasz krypto: przenieś środki do nowego portfela (nowy seed), zwłaszcza jeśli używałeś portfela w przeglądarce na tej samej maszynie.
  5. Higiena rozszerzeń w firmie:
    • polityka allowlist (tylko zatwierdzone rozszerzenia),
    • monitoring zmian uprawnień (alert, gdy dodatek nagle żąda nowych permissions),
    • okresowe audyty rozszerzeń oraz telemetryka przeglądarek.

Różnice / porównania z innymi przypadkami

  • ClickFix zwykle kojarzy się z fałszywymi CAPTCHA i „instrukcjami naprawy” na stronach (często po wejściu z reklamy, phishingu lub na skompromitowaną witrynę). QuickLens pokazuje, że ClickFix może być też dostarczany przez zaufany łańcuch aktualizacji (rozszerzenie), a nie tylko przez pojedynczy landing page.
  • W klasycznych kampaniach ClickFix finałem bywają stealery/RAT-y uruchamiane po komendzie użytkownika. CERT Orange i Microsoft wymieniają tę kategorię zagrożeń jako typowy skutek techniki.

Podsumowanie / kluczowe wnioski

QuickLens to ostrzeżenie, że:

  • nawet „normalne” rozszerzenie z historią i użytkownikami może stać się złośliwe po zmianie właściciela i aktualizacji,
  • uprawnienia oraz możliwość manipulowania ruchem/nagłówkami bezpieczeństwa to czerwone flagi, które powinny uruchamiać alert w organizacji,
  • ClickFix dalej ewoluuje i działa dlatego, że przenosi krytyczny krok infekcji na użytkownika (a więc poza część automatycznych barier).

Źródła / bibliografia

  1. BleepingComputer – opis incydentu QuickLens, daty, mechanika złośliwej aktualizacji, działania i rekomendacje. (BleepingComputer)
  2. Microsoft Security Blog – analiza łańcucha ataku ClickFix i powodów skuteczności tej techniki. (Microsoft)
  3. Kaspersky – warianty ClickFix i ewolucja „wabików” oraz metod dostarczania. (Kaspersky)
  4. CERT Orange Polska – ClickFix w praktyce (mechanika socjotechniki, konsekwencje, przykładowe łańcuchy infekcji). (CERT Orange)
  5. SC Media – przykłady kampanii ClickFix z fałszywymi CAPTCHA i kradzieżą danych/portfeli. (SC Media)

Microsoft testuje „bezpieczny tryb” dla plików BAT/CMD w Windows 11: blokada modyfikacji w trakcie uruchomienia i mniej kosztowne sprawdzanie podpisu

Wprowadzenie do problemu / definicja luki

Pliki wsadowe .bat i .cmd są „starym” mechanizmem automatyzacji, ale w praktyce nadal napędzają mnóstwo procesów: logon scripts, instalacje, naprawy, narzędzia helpdesku, taski w harmonogramie, procedury odzyskiwania czy operacje w środowiskach z ograniczonym dostępem do PowerShella.

Ich słabym punktem jest to, że są tekstowe i łatwo je zmienić — a w pewnych scenariuszach atakujący może próbować podmienić zawartość skryptu w trakcie jego wykonywania (klasa problemów typu TOCTOU: time-of-check vs time-of-use). Microsoft właśnie testuje mechanizm, który ma ograniczyć ten wektor.


W skrócie

W najnowszych kompilacjach Windows 11 Insider Microsoft dodaje opcję uruchamiania BAT/CMD w bardziej „sztywnym” trybie:

  • Skrypt wsadowy nie może zmienić się podczas wykonania (system ma go „zablokować” w trakcie uruchomienia).
  • Gdy w środowisku działa Code Integrity, system ma wykonywać walidację podpisu tylko raz (zamiast narzutu „per instrukcja/linia” w skrypcie), co ma poprawić zarówno bezpieczeństwo, jak i wydajność.
  • Funkcja jest opisywana jako kontrola dla administratorów oraz autorów polityk Application Control for Business.

Ważna uwaga: w źródłach pojawia się różne nazewnictwo wartości rejestru (szczegóły niżej) — to normalne na etapie Insider, ale trzeba to brać pod uwagę w testach i automatyzacji.


Kontekst / historia / powiązania

Zmiana została ogłoszona w kanałach Insider (m.in. wpis Windows Insider Blog) i jest komunikowana jako rozszerzenie kontroli dla:

  • administratorów systemów (ustawienia lokalne, rejestr),
  • autorów polityk App Control for Business (czyli praktycznie następcy/ewolucji podejścia WDAC w kierunku łatwiejszego zarządzania).

Drugi element układanki to Code Integrity oraz ochrona oparta o wirtualizację (HVCI / „Memory integrity”), które w wielu organizacjach są elementem twardych baseline’ów bezpieczeństwa. Jeśli CI jest włączone, Microsoft chce ograniczyć koszt weryfikacji podpisów podczas wykonywania dłuższych skryptów.


Analiza techniczna / szczegóły luki

1. „Locking” plików wsadowych podczas wykonania

Idea jest prosta: jeśli BAT/CMD jest uruchomiony, system ma zapewnić, że jego treść nie zmieni się w trakcie działania. Ma to utrudnić scenariusze, w których:

  • skrypt startuje jako „zaufany” (lub podpisany),
  • a następnie jest podmieniany „w locie” na złośliwą wersję, zanim dojdzie do wykonania dalszych poleceń.

W praktyce sprowadza się to do wprowadzenia bezpieczniejszego trybu przetwarzania, który „zamraża” wejście skryptu na czas jego wykonania.

2. Gdzie i jak to włączyć

Z komunikatów wynika, że tryb da się włączyć:

  • przez wartość w rejestrze w gałęzi Command Processor,
  • oraz przez kontrolę w mechanizmie polityk aplikacyjnych (manifest/ustawienie dla autorów polityk App Control).

Rozbieżność nazwy klucza:

  • Windows Insider Blog wskazuje wartość LockBatchFilesWhenInUse (DWORD 0/1) pod HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor.
  • BleepingComputer opisuje to jako LockBatchFilesInUse w tym samym miejscu.

Na etapie Insider to może oznaczać: doprecyzowanie nazewnictwa, korektę w kolejnych buildach albo różnice między gałęziami/kanałami. W praktyce: automaty wdrożeniowe powinny wykrywać build i weryfikować faktyczną obsługiwaną nazwę (np. poprzez test w labie i kontrolę zachowania, a nie tylko „set registry and pray”).

3. Podpisy i Code Integrity: „walidacja tylko raz”

Drugi element jest szczególnie ciekawy dla środowisk z włączonym Code Integrity. Microsoft deklaruje, że:

  • wcześniej w tym trybie walidacja mogła odbywać się z większym narzutem,
  • teraz ma być wykonana jednorazowo, co redukuje koszt i daje bardziej przewidywalny runtime dla dłuższych skryptów.

To jest ważne, bo długie, „linijkowe” BAT-y potrafią być krytyczne dla operacji (np. deployment w nocy), a każdy dodatkowy narzut potrafi wydłużyć okna serwisowe.


Praktyczne konsekwencje / ryzyko

Co zyskujesz

  • Większa odporność na manipulację skryptem w trakcie wykonania (ważne przy skryptach uruchamianych z udziałów sieciowych, repo narzędziowych, katalogów roboczych z szerokimi uprawnieniami, itp.).
  • Mniej kosztowna weryfikacja podpisu w scenariuszach z Code Integrity, co może poprawić stabilność i czas wykonywania automatyzacji.

Co może pójść nie tak

  • Skrypty, które same siebie modyfikują (tak, to się zdarza…), generują kolejne pliki wsadowe „w locie” w tym samym miejscu lub polegają na nietypowym łańcuchu include/call mogą zachowywać się inaczej.
  • Jeśli organizacja ma rozbudowane pipeline’y, które „podmieniają” treść BAT-a podczas rollout’u, blokada może ujawnić ukryte problemy procesowe (brak wersjonowania, brak atomowych podmian, złe uprawnienia do udziałów).

Rekomendacje operacyjne / co zrobić teraz

  1. Nie włączaj tego na produkcji w ciemno – potraktuj jako zmianę semantyki wykonywania BAT/CMD. Zacznij od labu/VM z buildem Insider.
  2. Zidentyfikuj „krytyczne” skrypty wsadowe (logowanie, deployment, naprawy, runbooki) i sprawdź:
    • czy skrypt jest wykonywany z lokalnego dysku vs udział sieciowy,
    • kto ma prawo zapisu do lokalizacji,
    • czy w trakcie działania nie następuje „podmiana” pliku przez inne narzędzia.
  3. Jeśli używasz Application Control for Business, podejdź do tego „politykowo”: wymuś spójność uruchamiania w organizacji poprzez mechanizmy App Control, zamiast lokalnych „tweaków”.
  4. Dopnij higienę repozytoriów skryptów:
    • atomowe wdrożenia (np. zapis do nowej nazwy + rename),
    • minimalizacja uprawnień zapisu,
    • podpisywanie, jeśli to ma sens w twoim modelu zaufania.
  5. W środowiskach z HVCI/Memory integrity zweryfikuj wpływ na czasy wykonań — Microsoft sugeruje poprawę, ale realny efekt zależy od tego, jak i gdzie uruchamiasz skrypty.

Różnice / porównania z innymi przypadkami

  • Smart App Control / App Control to kontrola „czy coś w ogóle może się uruchomić” (zależnie od podpisu/reputacji/polityki).
  • Opisywana zmiana dla BAT/CMD dotyka dodatkowo integralności skryptu w czasie wykonania oraz kosztu weryfikacji przy Code Integrity. To inny poziom: nie tylko „allow/deny”, ale też „runtime hardening”.

Podsumowanie / kluczowe wnioski

Microsoft testuje w Windows 11 Insider mechanizm, który:

  • ma uniemożliwiać modyfikację BAT/CMD w trakcie uruchomienia, ograniczając klasyczny wektor TOCTOU,
  • oraz ma zmniejszać narzut walidacji podpisu w środowiskach z Code Integrity (walidacja „raz na start”).

Dla organizacji, które wciąż polegają na wsadówkach, to potencjalnie bardzo sensowna zmiana — pod warunkiem, że przejdzie przez testy kompatybilności i nie rozjedzie istniejących procesów automatyzacji.


Źródła / bibliografia

  1. Windows Insider Blog – ogłoszenie kompilacji z nową kontrolą dla BAT/CMD i opisem „signature validation only once”. (Windows Blog)
  2. BleepingComputer – omówienie nowości i sposobu włączenia (Insider). (BleepingComputer)
  3. Microsoft Learn – Application Control for Windows / Smart App Control (kontekst polityk aplikacyjnych). (Microsoft Learn)
  4. Microsoft Learn – Virtualization-based protection of code integrity (HVCI/Memory integrity) – kontekst „Code Integrity”. (Microsoft Learn)