Nie masz jeszcze książki sekuraka o bezpieczeństwie aplikacji webowych? 20% taniej z kodem rabatowym: oferta-sekurak-20

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

17 maja 2021, 16:19 | Teksty | komentarze 24
Wieczny brak czasu na aktualizacje systemowe? W końcu udało się znaleźć chwilę na ich zainstalowanie, ale nie dokończyłeś całego procesu, bo musiałeś wybiec z biura? Czy twoje dane są bezpieczne? Tego dowiesz się z niniejszego artykułu.

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)

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Mateusz

    Ten sam problem występuje dokładnie kiedy przechowuje się klucz szyfrujący do dysku w TPM z LUKS-em. Przed na przykład aktualizacją BIOS-u, albo dodajesz tymczasowy klucz, albo musisz sobie przygotować recovery key żeby uruchomić ponownie system, bo dopiero wtedy jesteś w stanie odczytać nowe wartości PCR z TPM’a i je podpisać.

    Podejrzewam, że zarządzając flotą maszyn akurat powinniśmy być to w stanie przygotować na jednej maszynie i później zainstalować na wszystkich maszynach tego samego modelu.

    Niestety, bezpieczeństwo nie zawsze idzie z wygodą użytkownika.

    Odpowiedz
    • W przypadku LUKS podstawowym trybem jest po prostu podawanie hasła co restart – również restart wymuszony poprawkami. Hasło to jest osobne od systemowego i nie wymaga żadnych TPM, przez co jeżeli tylko potrafisz je zapamiętać, to cały schemat nie ma żadnych tymczasowych dziur.

      Odpowiedz
      • Lukasz

        W przypadku LUKS dla każdego większego środowiska podstawowy jest raczej serwer TANG. Chyba nikt sobie nie wyobraża wpisywania haseł na kilkuset serwerach po restarcie, no chyba, że mówimy o konfiguracji 5 serwerów ;)

        Odpowiedz
  2. Zdzich

    Swego czasu, po aktualizacji BIOS w moim laptopie DELL z włączonym BitLocker’em, nie mogłem wystartować systemu. Musiałem z’downgrade’ować BIOS, z’suspend’ować BitLocker, a dopiero wówczas zaktualizować BIOS, po czym Windows wystartował i ponownie włączyłem BitLocker.
    Po pewnym czasie (pewnie wskutek wielu zgłoszeń użytkowników) DELL „poszedł po rozum do głowy” i w swoim narzędziu Dell Command Update zaimplementował automatyczny suspend BitLocker’a na czas aktualizacji BIOS’u.

    Odpowiedz
  3. Świetna furtka, aby mając tylko i wyłącznie dostęp do zalogowanego Windows na czyimś komputerze (nie mając żadnych haseł), sprowokować sytuację, w której wejdziemy w posiadanie FVEK, a potem zgramy sobie cały dysk do postaci niezaszyfrowanej…

    Odpowiedz
    • CharlieK

      To jest dzialanie typu back hat. A dla white hat to jest furtka, jak ktos ma automatyczne odszyfrowywanie, klucza nie ma spietego z kontem w Microsoft, a trzeba mu zreinstalowac system w miejscu obecnej instalacji. I teraz bedzie okazja odzyskania dostepu do niezaszyfrowanych danych :)

      Odpowiedz
  4. chester

    Moim zdaniem ryzyko jest stosunkowo niewielkie bo aby ta decyzja projektowa została wykorzystana do ataku, to trzebaby albo wstrzelić się idealnie w moment aktualizacji, albo podsunąć fałszywą aktualizację, którą system uzna za poprawną. Jedno i drugie wygląda nieprawdopodobnie.
    Ale jeśli ktoś ma wyłączonego Bitlockera to ikonka wykrzyknika to zdecydowanie za mało – user może nie wiedzieć że coś jest nie tak, nigdy nie zaglądać w listę napędów itd. To powinien być popup powodujący poważny niepokój i potrzebę sprawdzenia w helpdesku/serwisie co się dzieje.

    Odpowiedz
  5. Marek

    Yup – dlateto gdzie mogę stosuję Eset Encryption Pro – kosztuje ale jak na razie nest niezawodne

    Odpowiedz
    • Krzysiu

      A papierosy są bezpieczną używką, bo jeszcze nie mam raka.

      Odpowiedz
  6. Bug z tworek

    A żeby sobie zrobić aktualizacje to nie trzeba mieć odszyfrowanego już? Da się aktualizować zaszyfrowany dysk? Na pewno o to chodzi czy to tylko tytuł na potrzeby marketingu a chodzi o to że gdy dysk jest odszyfrowany to możemy pozyskać klucze z metadanych? Bo to chyba nie jest problem bo jak dysk jest odszyfrowany to poco komu klucze, czy nie nadążam?

    Odpowiedz
    • Krzysiek

      Dysk jest cały czas zaszyfrowany, tylko niezabezpieczony klucz leży „pod wycieraczką”, w metadanych bitlockera. Wystarczy trafić na okazję, kiedy Windows podczas aktualizacji przechodzi do WinPE, wówczas można klucz podejrzeć/skopiować.

      Odpowiedz
  7. Green

    Czyli jesteśmy w stanie podpiąć taki zaszyfrowany dysk do komputera na którym jest już zainstalowany Windows (inny dysk bez bitlockera) ale jest nieaktualny i podczas jego aktualizacji dodatkowo zaszyfrowany dysk odblokować?

    Odpowiedz
  8. Ciekawski George

    Innymi słowy zamiast bawić się w FDE lepiej posiadać wydzieloną partycję na dane (nie systemową), która będziesz szyfrowana. Wtedy system będzie mógł się aktualizować bez konieczności zawieszania szyfrowania, a dane będą odpowiednio zabezpieczone. Jeżeli źle myślę, to proszę o wyjaśnienie dlaczego ;)

    Odpowiedz
    • Też polecam taki schemat dla Windows: szyfrowanie „po bożemu” partycji systemowej, a dane na osobnych partycjach szyfrowanych VeraCryptem.

      Odpowiedz
      • Dożek

        A jeżeli nie ufamy Bitlockerowi (bo nie można mu ufać: to rozwiązanie zamknięte plus firma która go stworzyła, utrzymuje i sprzedaje, współpracuje z NSA), to jak sprawić, żeby nasze poufne dane (choćmy w plikach tymczasowych, plikach programów czy pliku wymiany) nie trafiały na tę systemową partycję?

        Odpowiedz
        • itmr

          ja tam szyfruję partycje a nie dyski i nigdy nie miałem z tym najmniejszych problemów, ani za czasu truecrypta ani z veracryptem

          Odpowiedz
  9. Zetka

    @Green,
    …popłynąłeś ;) przeczytaj kto i jak przechowuje klucze

    Odpowiedz
  10. asdsad

    Ciekawe badanie, gratuluję.

    Mam dwa pytania:

    1. Jak oceniane są dyski typu self-encrypting drive (SED), z OPAL itp.? Czyli wszystko odbywa się poza systemem i nawet nie jest używany TPM – wszystko dzieje się w samym dysku. Wady? Zalety?

    2. Spotkałem się dwa razy z przypadkiem, że Win10, podpięty przy instalacji do konta w MS, na którym użytkownik _nigdy_ świadomie nie włączał BitLockera… nie mógł się odszyfrować. Trzeba było logować się na konto w MS i tam znaleźć recovery key.
    Jak to jest? – BitLocker ma jakiś trzeci stan oprócz „świadomie włączony” oraz „wyłączony”?
    Znalazłem kiedyś artykuł na stronie Dell-a, ale oni podają, że jakieś samoczynne szyfrowanie może nastąpić przy spełnieniu kilku warunków, np. wlutowana pamięć RAM. Tamte laptopy RAM miały wyjmowalny. Nie wiem o co chodziło. Kojarzycie o co biega?
    https://www.dell.com/support/kbdoc/pl-pl/000124701/automatic-windows-system-encryption-encryption-on-dell

    Odpowiedz
    • Andrzej

      Jeżeli ludzie z firmy Microsoft mają dostęp do „Recovery Key” Bitlockera, to jaki sens ma takie szyfrowanie dysku?

      Odpowiedz
    • Kubuś Puchatek

      Ja się spotkałem z przypadkiem gdy laptop DELLa z TPM po aktualizacji Win10 (nie BIOSu) zaszyfrował dysk który wcześniej nigdy nie był szyfrowany. W związku z tym na koncie MS też nie było klucza do odszyfrowania. MS umywa ręce od tego błędu, a chwila googlowania pokazuje, że nie jest to odosobniony przypadek i dotyczy nie tylko DELLi, ale też np. Lenovo. Jeśli ktoś ma sposób na odzyskanie danych z takiego dysku, niech da znać.

      Odpowiedz
      • asdsad

        Na 300% nie było tego klucza? W obu moich przypadkach był. Raz ktoś przy instalacji Win10 Home połączył się z siecią i nie umiał ominąć założenia konta w MS. Drugi raz – Win10 Pro – przy instalacji wybrał zalogowanie się kontem MS, ale podał konto służbowe – klucza nie było na „własnym koncie”, tylko admin firmy go widział.
        Instalując studencki Office 365 też widziałem jakiś krok, gdzie użytkownik zgadza się na zarządzanie komputerem przez firmę (!). Ale przyznam, że nie wiem jak to miałoby działać.
        Także ustal jakim kontem ktoś logował się do komputera. Może być to ciężkie, bo Win pamięta ostatniego użytkownika, więc możliwe, że usłyszysz „ja tylko wpisywałem PIN”. Ale musisz wydusić z użytkownika jak było. Np. przegrzeb mu maila – może ma jakieś potwierdzenie rejestracji.

        Odpowiedz
  11. Tomasz21

    Jestem laikiem w stosunku do większości uczestników: Myślę prosto, tak po chłopsku. TO WSZYSTKO JEST CHORE, łącznie z Windowsem.
    Jest takie powiedzenie; Nos dla tabakiery. Czy może jest tabakiera dla nosa?
    Wyjaśniam dla młodszych, Tabakiera, pojemnik na Tabakę, Kiedyś się używało Tabaki zamiast palić tytoń.
    pozdrawiam.

    Odpowiedz
  12. CharlieK

    No dobrze. Ale rozumiem z tresci artykulu, ze odszyfrowanie dysku nastepuje tylko przy wiekszych aktualizacjach (zmiana wersji), czy przy kazdych ? Kolejna sprawa – jak to sie ma w takim razie do TPMa sprzetowego ? Czemu klucze tam nie sa trzymane, przez co dostep do nich bylby niemozliwy (zabezpieczony) ?

    Odpowiedz
    • enko

      TPM udostępnia klucze tylko jeśli komponenty systemu się nie zmieniły, po zmianie BIOS czy jądra systemu, hash systemu się nie zgadza i TPM nie udostępni kluczy.

      Odpowiedz

Odpowiedz na Tomasz Klim