Jak dostać się do danych zabezpieczonych BitLockerem? Zrób sobie aktualizację systemową

Jak zawsze w świecie IT trudno o dobry i dopracowany standard. Linuks ma LUKS-a, Apple używa rozwiązania FileVault, a Windows swojego BitLockera.

W gruncie rzeczy każde z ww. rozwiązań spełnia to samo zadanie: zapewnia pełne szyfrowanie dysku (ang. full disk encryption, FDE). Dzięki temu, nawet w przypadku fizycznego przejęcia naszego urządzenia lub dysku przez osoby nieuprawnione, możemy mieć pewność, że zgromadzone na nim dane pozostaną poufne. No, a przynajmniej w przypadku, gdy użyliśmy wystarczająco silnego hasła.

Szyfrowanie, któremu można zaufać?

BitLocker jest z nami już długo, bo od czasów systemu Windows Vista. Część osób prywatnych i organizacji, dla których szyfrowanie dysków urządzeń z systemem Windows stało się koniecznością, opierała się użyciu rozwiązania Microsoftu.

BitLocker to rozwiązanie zamknięte. O ile użyty algorytm, czyli AES (Advanced Encryption Standard) oraz jego tryby szyfrowania blokowego – CBC i XTS znajdują się w domenie publicznej i zostały poddane wielu ewaluacjom, to sama implementacja (konkretny kod, w konkretnym języku programowania) pozostaje własnościowa.

W świecie „krypto” to wystarczający powód, aby być nieufnym. Nawet perfekcyjny algorytm o matematycznie udowodnionych właściwościach może być podatny na ataki po błędnie wykonanej implementacji. Istnieje cała klasa podatności o nazwie side-channel attacks, opisująca to zagadnienie.

Oczy wielu użytkowników zwróciły się w stronę rozwiązań otwartych, takich jak TrueCrypt. Jednak nie na długo.

Szybko okazało się, że „duże” aktualizacje (tzw. feature update) systemu Windows są niekompatybilne z różnorakimi metodami szyfrowania dysku, które pochodzą od dostawców niezależnych od Microsoftu. Internet zalała fala postów, sfrustrowanych użytkowników, których urządzenia zamieniły się w cegły tuż po restarcie urządzenia, wymuszonym instalacją aktualizacji.

Przyczyna jest prosta, część aktualizacji dla systemów Windows korzysta ze środowiska Windows Preinstallation Environment (Windows PE, WinPE), które jest systemem operacyjnym samo w sobie i tak samo jak „klasyczny” Windows, wymaga dedykowanych sterowników, aby rozumieć użyte szyfrowanie pełno dyskowe i współpracować z nim.

Pomimo tego część użytkowników starała się pozostać przy rozwiązaniach otwartoźródłowych, deszyfrując cały dysk przed instalacją aktualizacji i szyfrując go ponownie po zakończeniu tego procesu.

W środowisku biznesowym, było to co najmniej uciążliwe. Mechaniczne 2.5 calowe dyski nierzadko potrzebowały 24 lub więcej godzin, na wykonanie ww. cyklu, a urządzeń były dziesiątki, setki.

Tym samym nawet najbardziej świadomi użytkownicy, zmęczeni całym procesem, przeprosili się w końcu z BitLockerem.

Dzisiaj problem WinPE i tzw. 3rd party encryption solutions jest już mniej dokuczliwy, jednak trudno spotkać duże środowisko oparte na systemach Windows, które używa czegoś innego niż BitLocker.

Bo z BitLockerem wszystko działa…

Tutaj dochodzimy do sedna sprawy.

Zdaje się, że wielu użytkowników, którzy „męczyli się” z TrueCryptem lub od zawsze używali BitLockera, zaakceptowało fakt, że rozwiązanie to jest bezproblemowe, nie zadając dodatkowych pytań.

Zatem w jaki sposób rozwiązanie FDE od Microsoftu radzi sobie z wcześniej opisanymi problemami? Nijak. W razie potrzeby po prostu pozostawia nasze urządzenie i dane bez ochrony. Szok? To dopiero początek.

Jak działa BitLocker?

Uruchomienie w miarę nowoczesnego komputera PC w sposób gwarantujący, że jego komponenty nie zostały zmanipulowane, jest procesem szalenie skomplikowanym.

Dodatkowo sam BitLocker jest dość elastyczny i pozwala na konfigurowanie sposobu wprowadzania hasła pozwalającego uzyskać dostęp do danych. Mamy tutaj możliwość skorzystania m.in. z TPM (Trusted Platform Module), PIN-u, hasła tekstowego, a nawet zewnętrznego klucza USB.

BitLocker to po prostu niskopoziomowy sterownik. Tak długo jak uzyskujemy dostęp do dysku za pomocą funkcji dostarczanych przez system Windows, jego praca jest dla nas przezroczysta.

Microsoft zdecydował się więc na szyfrowanie głównego klucza o nazwie FVEK (Full Volume Encryption Key), który zapewnia bezpieczeństwo naszych danych za pomocą serii innych kluczy – VMK (Volume Master Key).

W skrócie, każdy VMK to klucz zaszyfrowany inną metodą dostępu. Dzięki temu możemy jednocześnie uzyskać dostęp do naszych danych za pomocą zarówno hasła tekstowego, jak i Recovery Key.

Całość danych jest zapisana na chronionym wolumenie, w metadanych oznaczonych nagłówkiem -FVE-FS- (część informacji jest także przechowywana w TPM, jeśli takowy jest w użyciu).

Proces przygotowania BitLockera do pracy wygląda więc następująco:

·  Użytkownik podaje dane potrzebne do odszyfrowania jednego z kluczy VMK lub TPM, po upewnieniu się, że system nie został zmanipulowany, i uwalnia klucz VMK;

·  za pomocą klucza VMK deszyfrowany jest klucz FVEK;

·  klucz FVEK pozwala na szyfrowanie i deszyfrowanie danych zgromadzonych na dysku.

Każda z metod pozwalających na dostęp do klucza VMK, to tzw. KP (Key Protector), każdy klucz VMK (pozostający poza TPM) jest więc zaszyfrowany za pomocą KP.

W trakcie aktualizacji komponentów naszego urządzenia, zajdzie szereg procesów, w których nie będziemy w stanie odszyfrować zawartości dysku, a tym samym wykonać czynności związanych z modernizacją, np.:

·  po wykonaniu aktualizacji BIOS-u, TPM stwierdzi, że w systemie została dokonana manipulacja i nie uwolni klucza VMK;

·  środowisko WinPE może nie umieć porozumieć się z modułem TPM, a tym samym nie zdoła uzyskać klucza VMK.

Jak w takich sytuacjach radzi sobie BitLocker?

Brutalna rzeczywistość

Prześledźmy proces instalacji aktualizacji typu feature update dla środowiska Windows 10.

Z pomocą powyższego zrzutu ekranu możemy opisać sytuację, w jakiej obecnie znajduje się nasz system:

·  Dysk urządzenia został w pełni zaszyfrowany za pomocą funkcji BitLocker. Szyfrowanie zostało pomyślnie zakończone dla całego dysku. Algorytm to XTS-AES-128.

·  Obecny system operacyjny to Windows 10 Professional w wersji 1903, kompilacja 18362.449.

·  System Windows zakończył pobieranie aktualizacji do wersji 20H2 i wyświetlił monit o wykonanie ponownego rozruchu celem dokończenia instalacji.

·  Na dysku C:, w katalogu głównym, znajduje się m.in. plik secret.txt, do którego dostęp możliwy jest jedynie w przypadku znajomości hasła BitLockera.

Zobaczmy, jak w tym samym momencie wyglądają metadane związane z funkcją BitLocker.

Narzędzie bdeinfo zwraca informację, że dostępne są dwa KP:

·  Password – to nasze hasło,

·  Recovery password – to nasz klucz odzyskiwania.

Program także wyraźnie informuje, że nie ma możliwości odblokowania wolumenu. Dane są bezpieczne.

Zgodnie z „prośbą” systemu Windows, wykonajmy więc ponowny rozruch. Ale tylko do momentu wyłączenia komputera. Nie uruchamiamy go ponownie.

Kolejne spojrzenie na metadane ujawnia nowy Key Protector o numerze 2, typu Clear Key!

Czym jest nowy KP? To ciąg znaków, którym została zaszyfrowana kolejna kopia klucza VMK, zapisany w postaci… jawnego tekstu. System Windows podczas zamykania ustawił BitLockera w tryb pracy nazwany Suspended.

Skoro posiadamy dostęp do ciągu znaków, którym zaszyfrowany jest VMK, to znaczy, że w konsekwencji mamy dostęp do wszystkich danych na dysku. Sprawdźmy to.

Próba zamontowania wolumenu kończy się sukcesem!

Mamy dostęp do danych zgromadzonych na dysku, w tym do zawartości wcześniej wspomnianego pliku secret.txt.

Co więcej za pomocą narzędzia dislocker możemy pozyskać klucz FVEK.

Ciekawostką jest, że system nie informuje użytkownika w żaden sposób, że jego dane nie będą chronione w czasie aktualizacji.

Co dzieje się dalej? Instalacja aktualizacji systemowej jest kontynuowana.

A po jej całkowitym zakończeniu, Key Protektor o numerze 2 zostaje usunięty z metadanych.

Jest to jednak mało pocieszające, bo jeżeli w trakcie aktualizacji ktoś zdołał pozyskać zawartość klucza FVEK, nadal będzie w stanie odszyfrować nasz dysk, bez potrzeby posiadania jakiegokolwiek hasła czy innego klucza.

W tym miejscu, bardzo ważne jest, aby zrozumieć, że zaprezentowane działanie mechanizmu nie jest błędem ani podatnością. Jest to decyzja projektowa podjęta przez Microsoft. Sposób, w jaki działa BitLocker.

Rozwiązanie Microsoftu rodzi w sytuacje, które mogą powodować problemy i doprowadzić do tego, że chwilowo BitLocker przestaje chronić nasze dane.

Proza życia

Mechanizm “zawieszania” szyfrowania nie jest ściśle powiązany z aktualizacjami systemowymi. Jest to jeden z trybów pracy BitLockera. Na stronach Microsoftu znajdziemy szczegółowe informacje, jak możemy sami go obsługiwać.

Szyfrowanie możemy „zawiesić” na określoną liczbę ponownych rozruchów lub na czas nieokreślony.

Główne niebezpieczeństwo, jakie niesie ze sobą ten mechanizm, to fakt, że nie mamy żadnych gwarancji, że po wprowadzeniu BitLockera w tryb Suspended, w późniejszym czasie Key Protector typu Clear Key zostanie usunięty.

Warto więc od czasu do czasu sprawdzić, jak skonfigurowany jest BitLocker, któremu powierzyliśmy funkcję szyfrowania danych. Zwłaszcza w środowisku Active Directory, gdzie urządzeń są setki, a co za tym idzie i prawdopodobieństwo wystąpienia problemu większe.

Tak jak na powyższym zrzucie ekranu, wolumen dla którego „zawieszono” szyfrowanie otrzymuje ikonę wykrzyknika. Stosowną informację przedstawia także narzędzie manage-bde.

Podsumowanie

W niniejszym artykule przedstawiłem sposób na potencjalny atak na urządzenia używające szyfrowania pełno dyskowego BitLocker.

Daleki jestem od negatywnej oceny tego narzędzia: działa sprawnie, korzysta ze sprawdzonych algorytmów. Jednak część decyzji projektowych Microsoftu wydaje się co najmniej nietrafiona. A Wy co myślicie o trybie Suspended? Koniecznie dajcie znać w komentarzach.

–Krzysztof Bierówka (hackuje w securitum.pl)