Archiwa: Cryptography - Strona 2 z 2 - Security Bez Tabu

Tag: Cryptography

Google obniża próg zasobów kwantowych potrzebnych do złamania kryptografii kryptowalut

Cybersecurity news

Wprowadzenie do problemu / definicja

Badacze Google Quantum AI poinformowali o istotnym obniżeniu szacunków dotyczących zasobów kwantowych potrzebnych do złamania kryptografii opartej na krzywych eliptycznych. To ważna informacja dla rynku kryptowalut, ponieważ właśnie mechanizmy ECC stanowią fundament podpisywania transakcji, ochrony kluczy prywatnych oraz autoryzacji operacji w sieciach takich jak Bitcoin i Ethereum.

Z perspektywy cyberbezpieczeństwa nie oznacza to jeszcze natychmiastowego przełomu prowadzącego do praktycznych ataków na blockchain, ale wyraźnie skraca dystans między teorią a potencjalnym wdrożeniem realnych możliwości ofensywnych. Dla organizacji zarządzających aktywami cyfrowymi to sygnał, że planowanie migracji do rozwiązań postkwantowych przestaje być odległą koncepcją badawczą.

W skrócie

Nowe szacunki Google wskazują, że złamanie problemu ECDLP-256 może wymagać około 20 razy mniej zasobów kwantowych niż zakładano wcześniej. Według przedstawionych danych atak mógłby zostać przeprowadzony przy użyciu mniej niż 1200 logicznych kubitów oraz około 90 milionów operacji Toffoliego.

  • zagrożenie dotyczy kryptografii opartej na krzywych eliptycznych, szeroko stosowanej w kryptowalutach,
  • największe znaczenie mają nowe optymalizacje obwodów kwantowych,
  • ryzyko nie jest bezpośrednie, ale horyzont zagrożenia może być bliższy niż dotąd zakładano,
  • branża blockchain i bezpieczeństwa powinna przyspieszyć przygotowania do ery postkwantowej.

Kontekst / historia

Od lat przyjmowano, że kryptografia asymetryczna używana w blockchainach pozostanie praktycznie bezpieczna aż do momentu pojawienia się wystarczająco zaawansowanych komputerów kwantowych. Głównym zagrożeniem w tym modelu jest algorytm Shora, który w środowisku kwantowym może efektywnie rozwiązywać problemy matematyczne stanowiące podstawę bezpieczeństwa ECC i RSA.

Dotychczas dominowało przekonanie, że przełamanie 256-bitowej kryptografii eliptycznej wymagałoby infrastruktury znacznie wykraczającej poza możliwości technologiczne najbliższych lat. Najnowsze ustalenia sugerują jednak, że wcześniejsze estymacje były zbyt ostrożne. Równolegle rośnie znaczenie standardów postkwantowych, a dostawcy technologii oraz instytucje standaryzacyjne coraz mocniej akcentują potrzebę rozpoczęcia migracji.

Analiza techniczna

Kluczowym zagadnieniem jest ECDLP, czyli problem logarytmu dyskretnego na krzywych eliptycznych. W modelu klasycznym pozostaje on praktycznie nierozwiązywalny dla parametrów wykorzystywanych przez największe sieci blockchain. W modelu kwantowym sytuacja wygląda inaczej, ponieważ algorytm Shora może znacząco skrócić czas potrzebny do wyprowadzenia klucza prywatnego z klucza publicznego.

Istota nowych ustaleń nie polega na odkryciu nowego typu ataku, lecz na zoptymalizowaniu obwodów kwantowych potrzebnych do realizacji już znanego scenariusza. Zespół badawczy oszacował, że atak na ECDLP-256 może być możliwy przy wykorzystaniu mniej niż 1200 logicznych kubitów i około 90 milionów operacji Toffoliego. W przeliczeniu na warstwę sprzętową może to oznaczać mniej niż 500 tysięcy kubitów fizycznych, podczas gdy wcześniejsze szacunki wskazywały nawet na około 10 milionów.

Szczególne znaczenie ma tutaj różnica między kubitami logicznymi a fizycznymi. Kubity logiczne są chronione przez mechanizmy korekcji błędów i wymagają dużej nadmiarowości sprzętowej. Oznacza to, że mimo znaczącego postępu nadal mówimy o zagrożeniu przyszłościowym, a nie o możliwości dostępnej dla obecnych platform komercyjnych.

Warto też zwrócić uwagę na sposób ujawnienia wyników. Google nie opublikował pełnych obwodów kwantowych, lecz wykorzystał model pozwalający na niezależną weryfikację twierdzeń bez dostarczania wszystkich szczegółów, które mogłyby ułatwiać odtworzenie potencjalnie niebezpiecznego ataku. To wpisuje się w praktykę odpowiedzialnego publikowania badań o wysokim znaczeniu ofensywnym.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko dla rynku kryptowalut dotyczy możliwości przejęcia środków poprzez odtworzenie kluczy prywatnych z danych publicznych zapisanych w łańcuchu bloków. Szczególnie narażone mogą być te adresy, których klucze publiczne zostały już ujawnione podczas wcześniejszych transakcji. W takim scenariuszu przeciwnik dysponujący dojrzałą infrastrukturą kwantową mógłby generować ważne podpisy i autoryzować nieuprawnione transfery.

Ryzyko ma także wymiar systemowy. Nawet jeśli pełnoskalowy atak pozostaje dziś poza zasięgiem, sama zmiana estymacji wpływa na sposób planowania migracji technologicznej. Zespoły rozwijające blockchainy, portfele, giełdy, rozwiązania custody oraz usługi HSM muszą zakładać, że okno bezpieczeństwa może być krótsze, niż wynikało z wcześniejszych modeli.

Istotny pozostaje również scenariusz „harvest now, decrypt later”. W szerszym ujęciu oznacza on gromadzenie danych dziś z myślą o ich wykorzystaniu w przyszłości, gdy odpowiednio zaawansowane systemy kwantowe będą już dostępne. W przypadku blockchainów problem jest szczególnie widoczny, ponieważ dane transakcyjne są publiczne i trwałe, a decyzje projektowe podejmowane obecnie mogą mieć konsekwencje przez wiele lat.

Rekomendacje

Organizacje odpowiedzialne za bezpieczeństwo środowisk blockchain powinny rozpocząć lub przyspieszyć pełną inwentaryzację komponentów zależnych od ECC. Dotyczy to nie tylko podpisów transakcyjnych, ale również portfeli, modułów sprzętowych, warstw integracyjnych, rozwiązań custody oraz aplikacji opartych na inteligentnych kontraktach.

  • opracować mapę zależności kryptograficznych w całej organizacji,
  • zidentyfikować adresy i portfele, w których klucze publiczne są już ujawnione na łańcuchu,
  • ocenić możliwość wdrożenia hybrydowych schematów podpisu oraz migracji do algorytmów postkwantowych,
  • przygotować procedury rotacji kluczy i plan awaryjnego przenoszenia aktywów,
  • monitorować standardy postkwantowe oraz harmonogramy wdrożeń u dostawców technologii,
  • uwzględnić zagrożenia kwantowe w modelach ryzyka, roadmapach produktowych i politykach ochrony aktywów.

Dla projektów blockchain szczególnie ważne staje się projektowanie bezpiecznych ścieżek aktualizacji protokołu, które umożliwią przejście na nowe mechanizmy kryptograficzne bez destabilizacji sieci. W środowiskach o wysokiej wartości aktywów warto rozważyć stopniowe wycofywanie rozwiązań najbardziej narażonych na przyszłe ataki kwantowe.

Podsumowanie

Nowe szacunki Google nie oznaczają jeszcze praktycznego złamania kryptografii Bitcoina czy Ethereum, ale znacząco zmieniają ocenę odległości do takiego scenariusza. Około 20-krotna redukcja wymaganych zasobów kwantowych wzmacnia argument za szybszym przygotowaniem infrastruktury, procesów i architektury bezpieczeństwa do realiów ery postkwantowej.

Dla branży cyberbezpieczeństwa, dostawców usług finansowych i całego ekosystemu kryptowalut to wyraźny sygnał ostrzegawczy. Przygotowania do migracji nie powinny być odkładane, ponieważ przewaga czasowa może okazać się mniejsza, niż wcześniej zakładano.

Źródła

  1. SecurityWeek — Google Slashes Quantum Resource Requirements for Breaking Cryptocurrency Encryption — https://www.securityweek.com/google-slashes-quantum-resource-requirements-for-breaking-cryptocurrency-encryption/
  2. Google Quantum AI — Research and publications — https://quantumai.google/
  3. NIST — Post-Quantum Cryptography Project — https://csrc.nist.gov/projects/post-quantum-cryptography
  4. IBM — What is quantum computing? — https://www.ibm.com/think/topics/quantum-computing
  5. Ethereum Foundation Documentation — Cryptography and blockchain fundamentals — https://ethereum.org/en/developers/docs/

Google przyspiesza migrację do kryptografii postkwantowej i wyznacza horyzont 2029

Cybersecurity news

Wprowadzenie do problemu / definicja

Kryptografia postkwantowa (PQC, Post-Quantum Cryptography) to zestaw algorytmów projektowanych z myślą o odporności na przyszłe ataki prowadzone przy użyciu dużych komputerów kwantowych. Dla organizacji nie jest to już wyłącznie temat badawczy, ponieważ zagrożenie dotyczy również danych przechwytywanych obecnie, które mogą zostać odszyfrowane w kolejnych latach. W tym kontekście Google sygnalizuje przyspieszenie migracji do rozwiązań postkwantowych i wskazuje rok 2029 jako ważny punkt odniesienia dla działań operacyjnych.

W skrócie

Google zwiększa tempo przechodzenia na kryptografię postkwantową, podkreślając ryzyko scenariusza „store now, decrypt later”, czyli gromadzenia zaszyfrowanych danych dziś z myślą o ich odszyfrowaniu w przyszłości. Firma zachęca do wcześniejszego wdrażania standardów PQC opracowanych przez NIST, zamiast czekania na pojawienie się w pełni dojrzałych komputerów kwantowych.

  • Priorytetem są mechanizmy wymiany kluczy i podpisy cyfrowe.
  • Zmiany obejmują usługi uwierzytelniania, środowiska chmurowe, Androida oraz podpisywanie aplikacji w Google Play.
  • Szczególną uwagę poświęcono komponentom o długim cyklu życia, takim jak korzenie zaufania, firmware i podpisy kodu.

Kontekst / historia

Przygotowania do ery postkwantowej trwają od lat, ale ostatnie działania pokazują zmianę skali i priorytetu. Kluczowym momentem było opublikowanie przez NIST finalnych standardów PQC, które dały rynkowi wspólny punkt odniesienia dla migracji. Równolegle duzi dostawcy technologiczni zaczęli przenosić temat z laboratoriów badawczych do planów produktowych i architektury bezpieczeństwa.

Google podkreśla, że rozwija podejście do crypto agility od 2016 roku, czyli zdolność do wymiany algorytmów kryptograficznych bez zakłócania działania usług. Obecnie firma wyraźnie komunikuje, że dostępny czas nie powinien być traktowany jako komfortowy bufor, lecz jako okres, który należy wykorzystać na realną transformację infrastruktury.

Analiza techniczna

Technicznie migracja koncentruje się na dwóch filarach: wymianie kluczy oraz podpisach cyfrowych. W obszarze ochrony danych przesyłanych Google stawia na ML-KEM, także w modelach hybrydowych łączących algorytmy postkwantowe z klasycznymi. Takie podejście ogranicza ryzyko wdrożeniowe i poprawia kompatybilność w środowiskach, które nie są jeszcze gotowe na pełne przejście do PQC.

Drugi obszar obejmuje podpisy cyfrowe, w tym ML-DSA i SLH-DSA. To szczególnie ważne dla łańcuchów zaufania, podpisywania oprogramowania, integralności firmware’u oraz wszystkich artefaktów, które muszą pozostać wiarygodne przez wiele lat. W praktyce oznacza to, że transformacja nie dotyczy wyłącznie szyfrowania transmisji, ale również podstaw zaufania w całym ekosystemie bezpieczeństwa.

W ekosystemie Androida zapowiedziano rozszerzenie Android Verified Boot o podpisy ML-DSA. Równolegle mechanizmy Remote Attestation i elementy związane z KeyMint mają zostać przygotowane do weryfikacji opartej na algorytmach odpornych na ataki kwantowe. To istotne z perspektywy bezpieczeństwa urządzeń końcowych, ponieważ właśnie na nich opiera się kontrola dostępu, zaufanie do urządzenia i egzekwowanie polityk bezpieczeństwa.

Zmiany mają objąć także łańcuch dostarczania aplikacji. W cyklu wydawniczym Androida 17 Google Play ma generować klucze podpisu ML-DSA dla nowych aplikacji oraz dla istniejących projektów decydujących się na migrację. W kolejnych etapach deweloperzy mają zyskać możliwość zarządzania klasycznymi i postkwantowymi kluczami w modelu hybrydowym, co oznacza początek przebudowy jednego z największych publicznych ekosystemów podpisywania kodu.

Konsekwencje / ryzyko

Największe ryzyko dotyczy danych i podpisów o długim okresie ważności. Organizacje przechowujące informacje wrażliwe przez wiele lat muszą zakładać, że dzisiejsze mechanizmy asymetryczne mogą okazać się niewystarczające wobec przyszłych zdolności obliczeniowych. Problem ten ma szczególne znaczenie dla administracji, sektora finansowego, ochrony zdrowia, telekomunikacji i operatorów infrastruktury krytycznej.

Drugie zagrożenie wiąże się z integralnością zaufanych komponentów. Jeśli w przyszłości możliwe stanie się skuteczne podważanie obecnych podpisów cyfrowych, skutkiem mogą być fałszywe aktualizacje, nadużycia w PKI, osłabienie atestacji urządzeń oraz erozja modeli zero trust. Dlatego nacisk Google na podpisy i usługi uwierzytelniania należy uznać za logiczny z punktu widzenia praktyki bezpieczeństwa.

Nie można jednak pomijać ryzyka samej migracji. Wdrożenie PQC oznacza większą złożoność środowiska, konieczność testów interoperacyjności, aktualizacji bibliotek, zmian w HSM, KMS, PKI i procesach CI/CD. Przez pewien czas wiele organizacji będzie funkcjonować w modelu przejściowym, co zwiększa znaczenie inwentaryzacji kryptografii i zarządzania zależnościami od dostawców.

Rekomendacje

Organizacje powinny rozpocząć przygotowania od pełnej inwentaryzacji użycia kryptografii asymetrycznej we wszystkich warstwach środowiska. Dotyczy to aplikacji, API, VPN, certyfikatów, systemów podpisu kodu, urządzeń mobilnych oraz komponentów embedded. Szczególny priorytet należy nadać danym o długim okresie poufności i podpisom wymagającym wieloletniej wiarygodności.

Kolejnym krokiem powinno być wdrożenie strategii crypto agility. Obejmuje ona oddzielenie logiki biznesowej od konkretnych algorytmów, modernizację bibliotek, testy kompatybilności i przygotowanie ścieżek przejścia do modeli hybrydowych. Bez takiej elastyczności nawet poprawnie zaplanowana migracja może stać się kosztowna i operacyjnie ryzykowna.

  • Priorytetyzuj ochronę danych przesyłanych przez kanały publiczne i wewnętrzne.
  • Zaplanuj migrację długowiecznych podpisów cyfrowych, korzeni zaufania i mechanizmów podpisywania kodu.
  • Monitoruj gotowość dostawców w obszarach chmury, IAM, PKI, HSM, MDM/UEM oraz platform developerskich.
  • W środowiskach mobilnych obserwuj zmiany dotyczące Android Verified Boot, Remote Attestation, KeyMint i podpisywania aplikacji.

Podsumowanie

Przyspieszenie działań Google pokazuje, że kryptografia postkwantowa wchodzi w etap praktycznych wdrożeń w kluczowych obszarach infrastruktury cyfrowej. Horyzont 2029 należy traktować jako sygnał dla rynku, że migracja do PQC nie może pozostać odległym planem strategicznym. Dla zespołów bezpieczeństwa oznacza to potrzebę równoczesnego zarządzania ryzykiem przyszłych ataków kwantowych i bieżącym ryzykiem transformacji architektury kryptograficznej.

Źródła

  • https://www.helpnetsecurity.com/2026/03/26/google-pqc-migration-timeline-2029/
  • https://blog.google/innovation-and-ai/technology/safety-security/the-quantum-era-is-coming-are-we-ready-to-secure-it/
  • https://cloud.google.com/blog/products/identity-security/how-were-helping-customers-prepare-for-a-quantum-safe-future/
  • https://www.nccoe.nist.gov/publications/fact-sheet/migration-post-quantum-cryptography-fact-sheet
  • https://csrc.nist.gov/projects/post-quantum-cryptography

CyberVolk/VolkLocker: „nowy” ransomware z krytyczną wadą kryptograficzną

Wprowadzenie do problemu / definicja luki

13 grudnia 2025 r. opisano nową usługę RaaS grupy hacktywistycznej CyberVolk o nazwie VolkLocker. Debiut okazał się nieudany z powodu poważnych błędów kryptograficznych, które umożliwiają potencjalne odszyfrowanie danych bez płacenia okupu. Ransomware korzysta z automatyzacji przez Telegram i celuje w systemy Windows oraz Linux.

W skrócie

  • Co się stało: CyberVolk uruchomił RaaS „VolkLocker”, ale implementacja szyfrowania zawiera krytyczne błędy.
  • Dlaczego to ważne: Błąd w generowaniu/przechowywaniu kluczy (m.in. hard-coded klucz AES-GCM, ślady w katalogu %TEMP%) może pozwolić ofiarom na darmową dekryptację.
  • Jak atak działa: Golang, warianty na Windows/Linux, C2 i telemetria oparte o Telegram (automatyczne powiadomienia o infekcji, zrzuty ekranu, podstawowe info o systemie).
  • Kontekst: CyberVolk to pro-rosyjska formacja hacktywistyczna rozwijająca RaaS od 2024 r.; wcześniej łączono ją z atakami DDoS i kampaniami o motywacji politycznej.

Kontekst / historia / powiązania

CyberVolk pojawił się w 2024 r. jako kolektyw hacktywistyczny łączący DDoS i ransomware. Infrastruktura rekrutacyjna i operacyjna była (i jest) silnie oparta na Telegramie, co obniża barierę wejścia dla „afiliantów”. W 2025 r. grupa wróciła z nowym „produktem” RaaS – VolkLocker – ale popełniła kardynalne błędy projektowe.

Analiza techniczna / szczegóły luki

  • Język i platformy: VolkLocker jest napisany w Go i posiada buildy dla Windows i Linux.
  • Komunikacja i automatyzacja: Wykorzystanie Telegram API/Bot do C2 i automatycznych powiadomień o infekcjach (zrzut ekranu, podstawowe dane hosta). Niektóre warianty demonstrowały dodatkowe funkcje (np. keylogging).
  • Kryptografia (błąd krytyczny):
    • Zidentyfikowano twardo zakodowany klucz AES-256-GCM w binariach.
    • W niektórych próbkach klucz zapisywany jest jawnie do %TEMP%, co tworzy „skrót” do deszyfracji.
    • Konsekwencja: w praktyce możliwe jest odzyskanie danych bez okupu, jeśli ofiara pozyska klucz z procesu/artefaktów.
  • Dowody na „choroby wieku dziecięcego”: Publiczne analizy badaczy potwierdzają niedojrzałość projektu i błędy operacyjne w najnowszych wersjach VolkLocker.

Praktyczne konsekwencje / ryzyko

  • Dla ofiar: Istnieje realna szansa na odzyskanie danych bez płatności dzięki błędom w obsłudze kluczy. Niemniej wczesne warianty mogły już zaszyfrować zasoby – konieczna jest triage i analiza pamięci/artefaktów.
  • Dla SOC/IR: Telegram-based C2 i „łatwy onboarding” afiliantów zwiększają liczbę incydentów miernej jakości, ale o dużej częstotliwości. Zespół musi przygotować szybkie playbooki pod Go-ransomware i detekcje dla ruchu/artefaktów Telegrama.
  • Ewolucja zagrożenia: Takie błędy zwykle są szybko poprawiane – okno „darmowej dekryptacji” może być krótkie w kolejnych buildach. (Wniosek inferencyjny na bazie dotychczasowych kampanii RaaS.)

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IR/SOC:

  1. Zabezpiecz artefakty: zrzuty pamięci, %TEMP%, katalogi robocze malware – szukaj hex-klucza i plików tymczasowych pozostawionych przez VolkLocker.
  2. Blokuj Telegram C2 (domeny/API, ruch wychodzący do botów) tam, gdzie to możliwe politycznie i operacyjnie.
  3. Sygnatury i YARA/EDR: zastosuj detekcje opublikowane przez badaczy (reguły pod Go, AES-GCM, ścieżki %TEMP%, artefakty procesu).
  4. Sprawdź dostępność dekryptorów w serwisach NoMoreRansom i Emsisoft – nawet jeśli dedykatora dla VolkLocker jeszcze nie ma, pojawienie się publicznego klucza może to zmienić.

Dla zespołów bezpieczeństwa/IT:

  • Segmentacja i kopie zapasowe (3-2-1, odseparowane, regularnie testowane na odtwarzanie).
  • Zasady egress ograniczające komunikację do platform komunikatorów (Telegram) z serwerów produkcyjnych.
  • Hardening stacji/serwerów i aktualizacje; monitorowanie tworzenia nietypowych plików w %TEMP%.
  • Playbook „free decrypt”: jeśli triage wskaże hard-coded key/plik z kluczem – procedura odzysku z minimalnym RTO/RPO. (Wniosek operacyjny)

Różnice / porównania z innymi przypadkami

  • Błędy klucza w RaaS zdarzały się wcześniej (np. w młodych rodzinach ransomware), ale jednoczesne hard-codowanie klucza i pozostawianie go w plikach tymczasowych to rzadkie, podwójne potknięcie zwiększające szanse na odzysk. W porównaniu z dojrzałymi rodzinami (LockBit/BlackCat) poziom OPSEC w VolkLocker jest istotnie niższy. (Wniosek porównawczy oparty na źródłach technicznych i praktyce branżowej)

Podsumowanie / kluczowe wnioski

  • CyberVolk wraca z RaaS, ale VolkLocker cierpi na poważne wady kryptograficzne, co tworzy okazję do darmowej dekryptacji w obecnych wersjach.
  • Automatyzacja przez Telegram obniża próg wejścia dla afiliantów i może zwiększyć szum incydentów – przygotuj detekcje i blokady.
  • Okno okazji może się zamknąć wraz z poprawkami – działaj szybko: artefakty, pamięć, klucze, testy dekryptorów. (Wniosek operacyjny)

Źródła / bibliografia

  1. BleepingComputer – „CyberVolk’s ransomware debut stumbles on cryptography weakness”, 13.12.2025. (BleepingComputer)
  2. SentinelOne – „CyberVolk Returns | Flawed VolkLocker…”, analiza techniczna (2025). (SentinelOne)
  3. SOC Prime – „VolkLocker ransomware detection” (Windows/Linux, hard-coded AES-GCM). (SOC Prime)
  4. SentinelOne – „CyberVolk: A deep dive into the hacktivists…” (kontekst 2024). (SentinelOne)
  5. NoMoreRansom / Emsisoft – katalogi narzędzi dekryptujących (ogólne wytyczne i potencjalne aktualizacje). (nomoreransom.org)

Hakerzy wykorzystują błąd kryptograficzny w Gladinet CentreStack/Triofox do ataków RCE

Wprowadzenie do problemu / definicja luki

11 grudnia 2025 r. pojawiły się doniesienia o aktywnym wykorzystywaniu nowej, nieudokumentowanej wcześniej podatności kryptograficznej w produktach Gladinet CentreStack i Triofox. Błąd wynika z zastosowania stałych (hardcoded) kluczy AES w komponencie odpowiedzialnym za szyfrowanie tzw. „Access Ticketów”. Atakujący, posiadając te klucze, mogą odszyfrowywać lub fałszować bilety dostępu, pobierać plik web.config z serwera i następnie doprowadzać do zdalnego wykonania kodu (RCE) poprzez nadużycie ASP.NET ViewState. Vendor potwierdził aktualizacje i przekazał IOC oraz zalecenia, a badacze obserwują ataki na co najmniej 9 organizacji z różnych sektorów.

W skrócie

  • Co się dzieje: aktywne ataki na CentreStack/Triofox z wykorzystaniem stałych kluczy AES i mechanizmu „Access Ticket”.
  • Skutki: odczyt web.config → pozyskanie machineKey → ViewState deserialization → RCE.
  • Skala: potwierdzone co najmniej 9 ofiar (stan na 10 grudnia 2025 r.). Adres źródłowy widoczny w telemetrii: 147.124.216[.]205.
  • Wersje/patch: zalecana wersja 16.12.10420.56791 (wydana 8 grudnia 2025 r.). Bezwzględnie zrotować machineKey.
  • Łańcuch z wcześniejszą luką: aktywnie wykorzystywane CVE-2025-11371 (LFI) oraz wcześniejsze CVE-2025-30406 (RCE przez ViewState).

Kontekst / historia / powiązania

Jesienią 2025 r. CISA dodała do katalogu KEV podatność CVE-2025-11371 (LFI), umożliwiającą nieautoryzowany odczyt plików – w praktyce web.config. Wcześniej opisywano także CVE-2025-30406, gdzie błędna obsługa kluczy/machineKey umożliwia RCE przez ViewState. Obecnie obserwowany błąd kryptograficzny z hardcoded kluczami AES ułatwia ten sam łańcuch ataku i jest wykorzystywany „widzianie w boju” (in the wild).

Analiza techniczna / szczegóły luki

  • Miejsce problemu: niestandardowa implementacja AES w GladCtrl64.dll; podczas startu serwisu generowane są dwie stałe 100-bajtowe sekwencje znaków (chiński i japoński tekst marketingowy), z których obliczane są klucz (32 B) i IV (16 B).
  • Mechanizm błędu: handler filesvr.dn przyjmuje parametr t (Access Ticket), podmienia znaki, dekoduje Base64 i odszyfrowuje bilety stałym kluczem/IV. Ktokolwiek te wartości odczyta (np. z pamięci procesu), może tworzyć własne, ważne bilety – np. z timestampem ustawionym na rok 9999 (nigdy nie wygasną).
  • Co dalej robi atakujący: tworzy bilet wskazujący na ścieżkę C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config, pobiera plik i wyciąga z niego <machineKey>. Następnie przeprowadza ViewState deserialization i osiąga RCE w kontekście aplikacji IIS.
  • IOC o wysokiej wiarygodności: skrót szyfrowanego ciągu odpowiadający ścieżce web.config: vghpI7EToZUDIZDdprSubL3mTZ2 – to najlepszy wskaźnik w logach HTTP.

Praktyczne konsekwencje / ryzyko

  • Przejęcie serwera aplikacyjnego (RCE) i dostęp do plików udziałów/zasobów.
  • Ruch lateralny w domenie (kradzież poświadczeń, eskalacja uprawnień).
  • Eksfiltracja danych z udziałów plikowych udostępnionych przez CentreStack/Triofox.
  • Trwałość: bilety z timestampem „9999-…” można wielokrotnie odtwarzać.
  • Sektory: potwierdzone ofiary m.in. ochrona zdrowia i technologia.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja do 16.12.10420.56791 (build z 8 grudnia 2025 r.).
  2. Rotacja machineKey we wszystkich węzłach/instancjach (to warunek konieczny – same łatki nie unieważnią zdobytych kluczy).
  3. Przegląd logów (IIS, WAF, proxy) pod kątem:
    • żądań do /storage/filesvr.dn z parametrem t=,
    • wystąpień ciągu vghpI7EToZUDIZDdprSubL3mTZ2 (wysoka trafność),
    • nietypowych błędów ViewState/ObjectStateFormatter.
  4. Weryfikacja kompromitacji: jeśli machineKey mógł wyciec, zakładaj kompromitację → rotuj klucze, unieważnij sesje, przeprowadź IR (przegląd harmonogramów zadań, usług, modułów IIS, webshelli, skryptów w katalogach aplikacji).
  5. Twardnienie konfiguracji:
    • wyłącz/ogranicz dostęp do filesvr.dn,
    • zastosuj WAF-owe reguły dla podejrzanych t= (Base64 + znaki :, |),
    • zmień domyślny machineKey i egzekwuj jego rotację proceduralnie (runbook).
  6. Śledź KEV/CVE: monitoruj status CVE-2025-11371 (LFI) i wcześniejszej CVE-2025-30406 (RCE) – łańcuchy są ze sobą silnie powiązane operacyjnie.

Różnice / porównania z innymi przypadkami

  • CVE-2025-11371 (LFI): umożliwia odczyt plików bez uwierzytelnienia (np. web.config). Sama w sobie nie daje natychmiastowego RCE, ale otwiera drzwi do pozyskania machineKey.
  • Nowy błąd kryptograficzny (brak CVE na dziś): ułatwia fałszowanie Access Ticketów dzięki stałym kluczom AES — z pominięciem innych kontroli czasu/uwierzytelniania — co przyspiesza zdobycie web.config.
  • CVE-2025-30406 (RCE): deserializacja ViewState z użyciem poznanego machineKey → pełne RCE w aplikacji.

Podsumowanie / kluczowe wnioski

  • Atakujący aktywnie łączą błąd kryptograficzny z wcześniejszymi słabościami CentreStack/Triofox, aby masowo uzyskiwać RCE.
  • Patch + rotacja kluczy to absolutne minimum; bez rotacji machineKey środowisko pozostaje narażone na ponowne wykorzystanie.
  • Najbardziej wiarygodny IOC do szybkiego huntingu w logach HTTP to: vghpI7EToZUDIZDdprSubL3mTZ2.
  • Wdrożenie kontroli prewencyjnych (WAF, ograniczenie handlerów, segmentacja) znacząco utrudni powtórny kompromis.

Źródła / bibliografia

  1. BleepingComputer: „Hackers exploit Gladinet CentreStack cryptographic flaw in RCE attacks” (11 grudnia 2025). (BleepingComputer)
  2. Huntress: „Active Exploitation of Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability” (10 grudnia 2025). (Huntress)
  3. CISA KEV – wpis dot. CVE-2025-11371 (4 listopada 2025). (CISA)
  4. Huntress: „CVE-2025-30406 – Critical Gladinet CentreStack & Triofox vulnerability exploited in the wild” (14 kwietnia 2025). (Huntress)
  5. Gladinet Support: „Hardening the CentreStack Cluster” – sekcja o aktualizacji/rotacji machineKey. (support.centrestack.com)

Microsoft: Październikowe aktualizacje powodują problemy z uwierzytelnianiem kartami inteligentnymi w Windows

Wprowadzenie do problemu / definicja luki

Październikowy zestaw poprawek Microsoftu (opublikowany 14 października 2025 r.) wywołał u części organizacji problemy z uwierzytelnianiem opartym o karty inteligentne i certyfikaty na systemach Windows 10, Windows 11 oraz Windows Server. Microsoft powiązał incydent z wprowadzonym domyślnie utwardzeniem kryptografii w usługach Windows Cryptographic Services. Sprawa została oznaczona jako znany problem (known issue), otwarty 17 października i oznaczony jako „Resolved” (z rozwiązaniem/procedurą) 20 października 2025 r. w panelu Release Health.

W skrócie

  • Objawy: brak rozpoznania kart jako dostawcy CSP w aplikacjach 32-bitowych, błędy przy podpisywaniu, awarie logowania CBA; komunikaty typu „invalid provider type specified” i CryptAcquireCertificatePrivateKey error.
  • Przyczyna: wymuszenie użycia KSP (Key Storage Provider) zamiast CSP (Cryptographic Service Provider) dla certyfikatów RSA na kartach, w ramach zabezpieczenia luki CVE-2024-30098.
  • Status: Microsoft udokumentował wykrywanie i obejście (klucz rejestru DisableCapiOverrideForRSA). Strona Release Health wskazuje stan „Resolved” od 20.10.2025 (17:49 PT).

Kontekst / historia / powiązania

Zmiana kryptograficzna jest częścią dłuższej ścieżki utwardzania tożsamości i kryptografii w Windows (m.in. modyfikacje zachowania CAPI/KSP, wzmocnienia Kerberosa i CBA w 2025 r.). W tym miesiącu Microsoft równolegle korygował inny błąd z Październikowego Patch Tuesday (niedziałające USB we Windows Recovery Environment), który naprawiono 20 października aktualizacją awaryjną KB5070773—to inny problem, ale pokazuje, że październikowe poprawki były wyjątkowo „ruchome”.

Analiza techniczna / szczegóły luki

Październikowe aktualizacje (m.in. KB5066791 dla Windows 10 22H2 i KB5066793/ KB5066835 dla gałęzi Windows 11/Server) egzekwują użycie KSP zamiast CSP dla certyfikatów RSA na kartach inteligentnych. Celem jest utrudnienie nadużyć opisanych w CVE-2024-30098 (obejście funkcji zabezpieczeń w Windows Cryptographic Services). Jeśli środowisko lub aplikacje oczekiwały starszego modelu CSP, pojawiają się błędy podczas operacji kryptograficznych i uwierzytelniania CBA.

Microsoft udokumentował również sposób detekcji ryzyka: przed wdrożeniem aktualizacji warto sprawdzić, czy w dzienniku System dla usługi Smart Card Service występuje Event ID 624 („system używa CAPI do operacji RSA”). Obecność zdarzenia wskazuje na większe prawdopodobieństwo wystąpienia problemu po aktualizacji.

Praktyczne konsekwencje / ryzyko

  • Tożsamość i dostęp: potencjalna niemożność logowania z użyciem kart inteligentnych (CBA) do stacji roboczych/serwerów oraz usług zależnych od certyfikatów użytkownika.
  • Procesy biznesowe: podpisy elektroniczne i operacje kryptograficzne w aplikacjach 32-bitowych mogą przestać działać do czasu dostosowania środowiska.
  • Utrzymanie: eskalacje do servicedesków i rolling back mogą zwiększać ryzyko ekspozycji, bo cofnięcie poprawek znosi również łatki bezpieczeństwa. Lepszą ścieżką jest kontrolowane obejście i kompatybilność po stronie aplikacji. (Wniosek na podstawie dokumentacji KB/Release Health.)

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj wpływ w logach przed wdrożeniem szerokim frontem. Szukaj Event ID 624 w dzienniku System/Smart Card Service na reprezentatywnych hostach.
  2. Jeśli już wystąpił problem – zastosuj obejście Microsoftu (per-host):
    • Otwórz Regedit → przejdź do HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais → utwórz/edytuj wartość DWORD DisableCapiOverrideForRSA i ustaw 0 → restart. (Klucz nie jest dodawany przez system/aktualizacje – trzeba go utworzyć ręcznie). Uwaga: edycję rejestru wykonuj po kopii zapasowej.
  3. Rozmawiaj z dostawcami aplikacji i PKI. Celem jest usunięcie zależności od CSP i pełna zgodność z KSP. Obejście rejestrowe traktuj jako tymczasowe. (Potwierdza to komunikacja MS w Release Health/KB).
  4. Zachowaj aktualność poprawek. Nie cofaj całych pakietów, aby nie tracić łatek bezpieczeństwa—monitoruj panel Release Health dla swojego wydania (Windows 10/11/Server) i stosuj poprawki uzupełniające.
  5. Change management: wstrzymaj globalne wdrożenia do czasu weryfikacji w pilotażu; przygotuj GPO/skrpty ustawiające DisableCapiOverrideForRSA=0 na hostach dotkniętych problemem (zgodnie z polityką organizacji). (Wniosek operacyjny na bazie dokumentacji MS.)

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

  • Smart card/KSP vs. WinRE/USB: Problemy z kartami wynikają z twardego przełączenia CSP→KSP (kompatybilność aplikacji), natomiast błąd WinRE/USB był klasycznym regresem sterowników/środowiska odzyskiwania i został naprawiony aktualizacją awaryjną KB5070773.

Podsumowanie / kluczowe wnioski

  • Październikowe łatki wymuszają KSP dla certyfikatów RSA na kartach, co poprawia bezpieczeństwo (CVE-2024-30098), ale ujawniło zależności od starego CSP w części środowisk.
  • Microsoft podał procedurę obejścia (DisableCapiOverrideForRSA=0) i oznaczył problem jako „Resolved” w Release Health (20.10.2025), jednak długofalowo należy zmigrować aplikacje i łańcuchy kryptograficzne do modelu KSP.

Źródła / bibliografia

  • BleepingComputer: „Microsoft warns of Windows smart card auth issues after October updates”, 20 paź 2025. (BleepingComputer)
  • Microsoft Release Health – Resolved issues (Windows 11 25H2): status, objawy, rejestr, daty 17–20 paź 2025. (Microsoft Learn)
  • Microsoft Support (KB) – KB5066791 (Windows 10 22H2), sekcja [Cryptography]: wymuszenie KSP i odwołanie do CVE-2024-30098. (Microsoft Support)
  • Microsoft Support/Release Health – KB5070773 (hotfix WinRE USB), tło innych problemów październikowych. (Microsoft Learn)