YellowKey omija BitLocker: analiza nowego zero-day w Windows i ryzyka dla konfiguracji TPM-only - Security Bez Tabu

YellowKey omija BitLocker: analiza nowego zero-day w Windows i ryzyka dla konfiguracji TPM-only

Cybersecurity news

Wprowadzenie do problemu / definicja

BitLocker to wbudowany w system Windows mechanizm szyfrowania dysków, wykorzystywany do ochrony danych przechowywanych na stacjach roboczych, laptopach i serwerach. Najnowsze doniesienia dotyczą luki typu zero-day określanej jako YellowKey, która może umożliwiać dostęp do woluminów chronionych przez BitLocker w określonych scenariuszach rozruchowych.

Kluczowe znaczenie ma tutaj zależność między modułem TPM, procesem uruchamiania systemu oraz środowiskiem odzyskiwania Windows RE. W praktyce problem nie polega na złamaniu samej kryptografii, lecz na obejściu mechanizmów kontrolujących dostęp do już odblokowanego woluminu.

W skrócie

  • YellowKey to publicznie ujawniony zero-day dotyczący obejścia ochrony BitLocker.
  • Atak ma znaczenie przede wszystkim dla konfiguracji BitLocker działających w trybie TPM-only.
  • Proof-of-concept wykorzystuje specjalnie przygotowane artefakty systemu plików podczas uruchamiania Windows RE.
  • Skutkiem może być uruchomienie powłoki z dostępem do odszyfrowanego woluminu.
  • Równolegle opisano także GreenPlasma, osobną podatność lokalnej eskalacji uprawnień.

Kontekst / historia

Informacje o YellowKey pojawiły się publicznie 13 maja 2026 roku wraz z publikacją materiałów proof-of-concept przez badacza działającego pod pseudonimem Chaotic Eclipse, znanego również jako Nightmare Eclipse. Upublicznienie techniki przed wydaniem poprawki zwiększa ryzyko szybkiego powielania ataku przez innych badaczy, zespoły red team oraz potencjalnie także podmioty ofensywne.

Sprawa wpisuje się w szerszą debatę wokół responsible disclosure i relacji między badaczami a producentami oprogramowania. Z perspektywy organizacji najważniejsze jest jednak nie to, kto i dlaczego ujawnił szczegóły, lecz fakt, że dostępny jest publiczny PoC, który obniża próg wejścia do testów praktycznych.

Tłem dla całego problemu jest również sposób działania BitLockera. Mechanizm ten może korzystać wyłącznie z TPM albo z dodatkowych zabezpieczeń pre-boot, takich jak PIN. To właśnie różnica między automatycznym odblokowaniem a wymuszeniem dodatkowego sekretu decyduje o poziomie ekspozycji na opisywany scenariusz.

Analiza techniczna

Z opublikowanych opisów wynika, że YellowKey wykorzystuje specjalnie przygotowane pliki FsTx umieszczane na nośniku USB lub w niektórych wariantach na partycji EFI. Następnie urządzenie jest uruchamiane w środowisku odzyskiwania Windows RE, gdzie dochodzi do przetwarzania logów transakcyjnych NTFS i zmiany zachowania procesu odzyskiwania.

W efekcie zamiast standardowego interfejsu odzyskiwania możliwe ma być uruchomienie powłoki poleceń. Najistotniejsze jest to, że w tym momencie wolumin chroniony przez BitLocker może być już odblokowany przez TPM, co otwiera drogę do dostępu do danych bez znajomości klucza odzyskiwania i bez łamania szyfrowania metodami kryptograficznymi.

Oznacza to, że YellowKey nie jest klasycznym atakiem na algorytmy szyfrujące. To obejście bezpieczeństwa oparte na przejęciu kontroli nad etapem rozruchu i odzyskiwania w sytuacji, gdy system sam udostępnia klucz odszyfrowania w zaufanym kontekście sprzętowym.

Według dostępnych analiz bieżący wariant PoC jest szczególnie istotny dla urządzeń skonfigurowanych w trybie TPM-only. W takim modelu samo fizyczne posiadanie urządzenia i możliwość ingerencji w proces rozruchu mogą być wystarczające do przeprowadzenia ataku, o ile inne zabezpieczenia firmware i boot chain nie zostały odpowiednio zaostrzone.

Równolegle opisano również GreenPlasma, podatność lokalnej eskalacji uprawnień. Choć nie jest ona tożsama z YellowKey, może stanowić element szerszego łańcucha ataku, zwłaszcza w scenariuszach, w których napastnik uzyska już lokalny dostęp do systemu i będzie dążył do podniesienia uprawnień do poziomu SYSTEM.

Konsekwencje / ryzyko

Najbardziej narażone są organizacje wykorzystujące BitLocker bez dodatkowego PIN-u startowego, szczególnie na laptopach służbowych, stacjach administracyjnych i urządzeniach, do których możliwy jest fizyczny dostęp. Ryzyko rośnie także w środowiskach serwerowych poza ściśle kontrolowanymi lokalizacjami oraz tam, gdzie rozruch z nośników zewnętrznych nie został odpowiednio ograniczony.

Potencjalne skutki obejmują odczyt i kopiowanie danych, pozyskanie wrażliwych artefaktów uwierzytelniających, modyfikację systemu operacyjnego oraz przygotowanie trwałej kompromitacji po ponownym uruchomieniu urządzenia. W środowiskach korporacyjnych może to prowadzić do naruszenia poufności danych, incydentów związanych z tożsamością oraz eskalacji ataku na dalsze segmenty infrastruktury.

Warto przy tym zaznaczyć, że nie każda implementacja BitLocker jest automatycznie podatna w takim samym stopniu. Skala zagrożenia zależy od konfiguracji pre-boot, polityk UEFI/BIOS, ochrony fizycznej urządzeń oraz tego, czy organizacja wymusza dodatkowe uwierzytelnienie przed odblokowaniem dysku.

Rekomendacje

Najważniejszym działaniem ograniczającym ryzyko jest odejście od konfiguracji TPM-only wszędzie tam, gdzie model zagrożeń uwzględnia fizyczny dostęp do urządzenia. W praktyce oznacza to wdrożenie BitLockera z pre-boot PIN oraz dodatkowe wzmocnienie zabezpieczeń firmware.

  • Zweryfikować, które urządzenia korzystają z BitLocker bez PIN-u startowego.
  • Wymusić dodatkowe uwierzytelnienie pre-boot na systemach o podwyższonej wrażliwości.
  • Ograniczyć możliwość startu z zewnętrznych nośników.
  • Zabezpieczyć ustawienia UEFI/BIOS hasłem i ograniczyć nieautoryzowane zmiany konfiguracji.
  • Monitorować integralność partycji EFI oraz komponentów rozruchowych i odzyskiwania.
  • Wzmocnić kontrole fizycznego dostępu do urządzeń końcowych i serwerów.
  • Przygotować procedury reagowania na incydenty związane z manipulacją pre-boot.
  • Śledzić publikację poprawek i priorytetowo testować je po udostępnieniu.

Zespoły bezpieczeństwa powinny także potraktować ten przypadek jako przypomnienie, że szyfrowanie danych spoczynkowych nie działa w próżni. Ostateczna odporność środowiska zależy również od bezpieczeństwa rozruchu, poprawnej konfiguracji firmware, kontroli dostępu fizycznego oraz właściwej segmentacji uprawnień administracyjnych.

Podsumowanie

YellowKey to istotne obejście ochrony BitLocker, które pokazuje ograniczenia konfiguracji opartych wyłącznie na TPM. Publiczna dostępność PoC zwiększa prawdopodobieństwo szybkiego testowania tej techniki w praktyce, zwłaszcza tam, gdzie urządzenia mogą trafić w ręce osoby mającej fizyczny dostęp.

Dla organizacji najważniejsze pozostaje szybkie ustalenie poziomu ekspozycji, wdrożenie dodatkowego uwierzytelnienia przed startem systemu oraz wzmocnienie zabezpieczeń firmware i procedur operacyjnych. Ujawnienie GreenPlasma dodatkowo pokazuje, że lokalne błędy eskalacyjne mogą wzmacniać skuteczność bardziej złożonych łańcuchów ataku na platformę Windows.

Źródła

  1. BleepingComputer — Windows BitLocker zero-day gives access to protected drives, PoC released — https://www.bleepingcomputer.com/news/security/windows-bitlocker-zero-day-gives-access-to-protected-drives-poc-released/
  2. Microsoft Learn — BitLocker Overview — https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/
  3. Microsoft Learn — BitLocker countermeasures — https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures
  4. Microsoft Learn — BitLocker FAQ — https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/faq
  5. Microsoft Learn — Windows Recovery Environment (Windows RE) technical reference — https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment–windows-re–technical-reference