-
Notifications
You must be signed in to change notification settings - Fork 0
Szyfrowanie dyskow
Szyfrowanie dysków twardych staje się z roku na rok coraz bardziej popularne. Szczególnie od roku 2018, gdy zaczęło obowiązywać RODO, szyfrowanie dysków w większych firmach stało się de facto standardem dla laptopów i innych urządzeń mobilnych, zabezpieczanych w ten sposób na wypadek kradzieży urządzenia.
Funkcjonariusz wspiera 4 najbardziej istotne metody szyfrowania (patrz poniższa tabela). Oczywiście samo "wsparcie" nie wystarczy - aby możliwa była eksfiltracja danych z zaszyfrowanego dysku, potrzebujesz klucza szyfrującego (najczęściej w postaci hasła, lub tzw. klucza odzyskiwania). Funkcjonariusz zapewnia pełną automatyzację obsługi takich kluczy (np. automatyczne wyszukanie klucza pasującego do danego dysku), ale Twoją rolą jest dostarczenie kluczy (np. zakup od przekupionego pracownika IT).
Funkcjonariusz zapewnia Ci pełne bezpieczeństwo na wypadek zagubienia lub odebrania Ci pod przymusem dysku: partycja ze zbieranymi danymi, jak również z wgranymi kluczami szyfrującymi i z kodem samego Funkcjonariusza jest zaszyfrowana. Bez znajomości hasła LUKS nie jest możliwe udowodnienie faktu eksfiltracji danych ani odróżnienie Funkcjonariusza od zwykłego Kali Linuxa.
Funkcjonariusz wspiera poniższe metody szyfrowania i typy kluczy:
Metoda szyfrowania | Wspierane | Nie wspierane |
---|---|---|
Apple FileVault | - hasło użytkownika | |
- klucz odzyskiwania | ||
Bitlocker | - klucz odzyskiwania | - hasło użytkownika |
- jawny klucz | - PIN | |
- pliki FVEK/VMK | ||
- interakcja z modułem TPM | ||
LUKS | - hasło użytkownika (8 slotów) | - plik z kluczem |
VeraCrypt | - hasło użytkownika | - PIN |
- plik z kluczem |
Funkcjonariusz wspiera poniższe typy partycji i systemy plików dla poszczególnych metod szyfrowania:
Metoda szyfrowania | Wspierane | Nie wspierane |
---|---|---|
Apple FileVault | - system plików APFS | - system plików HFS+ |
Bitlocker | - system plików NTFS | - system plików FAT |
LUKS | - wszystkie systemy plików | |
VeraCrypt | - partycje systemowe | - partycje bezsystemowe |
- systemy plików wspierane przez FUSE | - ukryte wolumeny | |
- całe dyski systemowe | ||
- partycje TrueCrypt |
Funkcjonariusz używa 2 rodzajów kluczy szyfrujących:
- klucze przypisane do konkretnego dysku twardego (dopasowane po numerze seryjnym dysku)
- klucze nieprzypisane
Algorytm montowania nowych dysków (i partycji) jest bardzo prosty:
- pobranie numeru seryjnego dysku
- załadowanie listy kluczy (skryptem
get-drive-encryption-keys.sh
): klucze przypisane do tego numeru seryjnego (zarówno te skonfigurowane ręcznie, jak i te znalezione automatycznie wcześniej) na początku, potem klucze nieprzypisane z usuniętymi duplikatami - przeiterowanie tej listy, aż zostanie znaleziony pasujący klucz
- pasujący klucz jest zapisywany w katalogu z przypisanymi kluczami przez skrypt
save-drive-encryption-key.sh
Klucze te składowane są w katalogu "keys directory" - jest to po prostu wybrany katalog na zaszyfrowanej partycji z danymi. Zawiera on wiele plików, które w nazwie mają numer seryjny dysku twardego, a w rozszerzeniu metodę szyfrowaia, np. NS11N546911301H05.bitlocker
.
Większość takich plików zawiera dokładnie 1 klucz, który pasuje do wszystkich zaszyfrowanych partycji na tym dysku (najczęściej zaszyfrowana jest tylko jedna partycja, albo wszystkie partycje używają tego samego klucza). Jeśli poszczególne partycje na tym samym dysku używają różnych kluczy, wówczas plik taki zawiera kolejne klucze w kolejnych liniach, z usuniętymi duplikatami.
Położenie i działanie katalogu z kluczami różni się pomiędzy Funkcjonariuszem, a Funkcjonariuszem Mobilnym:
Katalog ten jest wskazywany przez skrypt /opt/drivebadger/internal/kali/get-keys-directory.sh
i znajduje się na zaszyfrowanej partycji z danymi. Jeśli nie istnieje, jest tworzony automatycznie przy starcie eksfiltracji danych.
Przykładowe nazwy plików wraz z pełną ścieżką:
/run/live/persistence/sda3/.files/.keys/TNS5193TGS38SG.apfs
/run/live/persistence/sda3/.files/.keys/NS11N546911301H05.bitlocker
/run/live/persistence/sda3/.files/.keys/SanDisk_SD9SN8W2T00_19259H456424.veracrypt
TNS5193TGS38SG
, NS11N546911301H05
i SanDisk_SD9SN8W2T00_19259H456424
to przykładowe numery seryjne dysków (niektóre typy dysków mają w numerze seryjnym oznaczenie modelu, inne nie).
Funkcjonariusz Mobilny nie wspiera szyfrowania dysku z danymi ani karty MicroSD z systemem, więc dla Twojego bezpieczeństwa, obsługa kluczy w tym trybie działa nieco inaczej:
-
katalog z kluczami domyślnie nie istnieje i musi być stworzony ręcznie (jako podkatalog
.support/.keys
,.files/.keys
lubfiles/keys
na dysku docelowym) - dopóki nie zostanie utworzony, klucze będą trzymane w katalogu
/etc/drivebadger/keys
- jeśli używasz wielu dysków docelowych, dla każdego z nich możesz osobno zdecydować, gdzie mają być trzymane klucze
Takie podejście pozwala lepiej przygotować się na sytuacje awaryjne - zależnie od okoliczności, wystarczające może być wówczas zniszczenie samej karty pamięci.
Klucze takie są konfigurowane poprzez mechanizm repozytoriów konfiguracyjnych, w postaci plików /opt/drivebadger/config/keys-*/*.keys
, a dokładniej plików o nazwach:
-
bitlocker.keys
dla Bitlockera -
veracrypt.keys
dla VeraCrypta -
luks.keys
dla LUKS -
filevault.keys
dla Apple FileVault
przy czym możesz wgrać wiele takich plików (po jednym każdego typu na katalog) - np. dzieląc posiadane listy kluczy na działy, piętra itp.
Cała obsługa kluczy do dysków podzielone jest na 6 skryptów:
Ten skrypt jest odpowiedzialny za ładowanie listy kluczy szyfrujących, które mają zostać przetestowane na danej partycji. Dostaje on w parametrach:
- metodę szyfrowania
- ścieżkę do katalogu z kluczami
- numer seryjny dysku twardego
Klucze są ładowane w odpowiedniej kolejności:
- najpierw klucze przypisane do dysku o podanym numerze seryjnym
- potem klucze nieprzypisane, z odfiltrowanymi duplikatami znalezionymi wśród kluczy przypisanych
Jeśli chcesz zaimplementować niestandardową kolejność ładowania kluczy, filtrowanie wybranych kluczy, albo jakoś inaczej zmienić domyślne zachowanie Funkcjonariusza względem kluczy, powinieneś zacząć właśnie od tego skryptu.
Skrypt ten po prostu zapisuje dopasowane klucze w katalogu z kluczami - dzięki temu skrypt get-drive-encryption-keys.sh
załaduje je na początku listy.
Ten skrypt występuje w dwóch wersjach:
-
/opt/drivebadger/internal/kali/get-keys-directory.sh
- Funkcjonariusz -
/opt/drivebadger/internal/mobile/get-keys-directory.sh
- Funkcjonariusz Mobilny
Zwraca on ścieżkę do katalogu z kluczami (patrz wyżej).
Ten skrypt również występuje w dwóch wersjach:
-
/opt/drivebadger/internal/kali/show-key-stats.sh
- Funkcjonariusz -
/opt/drivebadger/internal/mobile/show-key-stats.sh
- Funkcjonariusz Mobilny
Wyświetla on statystyki skonfigurowanych kluczy. Przykładowa tabelka generowana przez ten skrypt:
encryption mode | keys assigned to drives | repo keys unassigned | common | total repo keys | unique repo keys
--------------------------------------------------------------------------------------------------------------
apfs | 1 | | | |
bitlocker | 1 | 1643 | 1 | 1644 | 1644
luks | | 22 | | 22 | 22
veracrypt | 8 | 142 | 8 | 150 | 150
Jak widać z powyższej tabeli:
- skonfigurowane za pomocą repozytoriów są 1644 klucze Bitlocker, 150 kluczy VeraCrypt i 22 klucze LUKS
- spośród nich, 8 kluczy VeraCrypt i 1 klucz Bitlocker, zostały wcześniej dopasowane do dysków
- dodatkowo został wgrany 1 klucz Apple FileVault powiązany z dyskiem twardym (dodany ręcznie od razu z powiązaniem)
© 2020-2022 Tomasz Klim Payload.pl, Wszelkie prawa zastrzeżone.