Dlaczego hackowanie aplikacji webowych jest proste? Zapisz się na darmowe szkolenie od sekuraka.

Przyspieszony kurs łamania kryptografii Hive ransomware ;-)

21 lutego 2022, 12:53 | Teksty | komentarze 4

Najpierw złe wieści, wbrew informacjom kolportowanym przez wiele mediów, nie ma prostej metody na odszyfrowanie Hive, szczególnie w nowszych wersjach. Tak czy siak Hive popełnił pewne błędy kryptograficzne podczas implementacji swojego szyfrowania, w tym tekście się nim przyjrzymy, poznamy też nieco sposób działania tego ransomware.

Błędy w implementacji kryptografii ransomware’a Hive, który jako jeden z niewielu nadal atakuje m.in. szpitale, pozwoliły badaczom w środowisku laboratoryjnym odtworzyć większość klucza master (głównego klucza kryptograficznego), a następnie odszyfrować dane. Do odtworzenia głównego klucza kryptograficznego potrzebne było stosunkowo dużo par plików zaszyfrowanych i niezaszyfrowanych, co w praktyce oznacza, że zaproponowany przez badaczy atak może być jednak niepraktyczny i nieprzydatny dla ofiar, które rzadko dysponują dostateczną liczbą plików oryginalnych niezbędnych do odtworzenia klucza master. 

Opublikowana przez południowokoreańskich badaczy analiza dotyczy historycznego wariantu ransomware’a Hive, obserwowanego od lutego do lipca 2021 roku, niespotykanego w aktualnych infekcjach. Od tego czasu atakujący zmienili m.in. sposób szyfrowania plików. Pokazujemy, jak odszyfrowaliśmy pliki z aktualnych infekcji bez potrzeby wykorzystania głównego klucza kryptograficznego.

Klucz master

10 MB klucz master – główny klucz kryptograficzny, z którego wycinane są fragmenty potrzebne do tworzenia kluczy szyfrujących pliki, generowany jest losowo i przechowywany w postaci jawnej w pamięci przez cały proces szyfrowania (od rozpoczęcia do zakończenia szyfrowania). Oznacza to, że jeśli przed zakończeniem szyfrowania, pomimo braku specjalistycznych narzędzi, np. zostanie zawieszona (ang. suspend) maszyna wirtualna lub zahibernowany system operacyjny maszyny, z której odbywa się szyfrowanie, klucz master można wyekstrahować z pliku VMEM (VMware) lub hiberfil.sys (Windows).

Po zakończeniu szyfrowania na dysku maszyny, z której szyfrowane były pliki (czasami z jednej maszyny można zaszyfrować np. udziały sieciowe innych), pozostawiany jest jedynie szyfrogram zawierający zaszyfrowany klucz master plik z rozszerzeniem *.key.hive. 

Szyfrowanie plików

Hive szyfruje z wykorzystaniem logicznej funkcji XOR pliki z nowym kluczem, unikatowym (jednorazowym) dla szyfrowanego pliku. 

Zacznijmy słowem wyjaśnienia od doświadczonego kryptologa:

Jest to stara technika szyfrowania tzw. szyfr z kluczem jednorazowym (algorytm Vernama). Nie wykorzystuje złożonych algorytmów matematycznych do szyfrowania danych (jak np. AES), a jedynie prostą funkcję XOR, która każdy bit szyfrowanego ciągu “składa” z bitem klucza kryptograficznego. Oznacza to, że długość klucza (liczona w bitach) musi być równa długości szyfrowanego tekstu/pliku. Siłą tego “algorytmu” jest wykorzystanie unikalnego (w pełni losowego) klucza kryptograficznego (dawniej nazywanego gamą jednorazową), bez którego znajomości odszyfrowanie pliku (wiadomości) jest niemożliwe. W przypadku gdy szyfr ten jest używany pomiędzy oddalonymi użytkownikami, problemem jest dystrybucja klucza, który staje się kluczowym materiałem do odszyfrowania tekstu. Jeśli klucz zostanie przechwycony (poznany), wówczas dekryptaż  szyfrogramu nie stanowi już żadnego problemu. Równie istotne jest unikanie wielokrotnego używania tego samego klucza jednorazowego, gdyż to ułatwia atak na zaszyfrowany tekst. Historia zna już przypadki, gdy użycie po latach tego samego klucza, doprowadziło do odszyfrowania tajnych wiadomości.

W przypadku (jak w omawianym ransomware Hive) szyfrowania plików lokalnie, przy użyciu klucza jednorazowego, istotna jest umiejętność rozwijania klucza jednorazowego. Pamiętając, że na każdy bit szyfrowanej wiadomości przypada bit klucza, oznacza to, że do zaszyfrowania np. 1 TB danych wymagany jest klucz o tej samej długości. Aby zredukować długość klucza jednorazowego stosuje się techniki jego “rozwijania” z wykorzystaniem różnych algorytmów. Przy atakach ransomware Hive ustalono mechanizm rozwijania klucza, opierając się na ciągu losowym długości 1 MB i stałym pliku 1 KB. Sam mechanizm oraz próba jego przełamania stanowi opracowanie analiz Koreańskich badaczy.

Na marginesie, mechanizm rozwijania klucza w ataku ransomware Hive jest dość prymitywny, co świadczy, że za atakującymi nie zawsze stoi duża wiedza i doświadczenie.

– Michał Czmoch, Krypton Polska

Klucz składa się z dwóch ciągów znaków (1MB i 1KB) z losowo wybranych miejsc (offsetów) z wcześniej wygenerowanego klucza master.

Rysunek 1. Dobieranie dwóch części klucza szyfrującego (rysunek 5 w oryginalnym artykule badaczy)

Generowanie klucza szyfrującego przebiega w następujący sposób:

Wygeneruj Klucz_1: 

  1. wylosuj losową liczbę R1,
  2. wyznacz położenie (offset) z wykorzystaniem funkcji R1 modulo 0x900000,
  3. wykopiuj 1 MB (0x100000) z klucza master, zaczynając od położenia wyznaczonego w poprzednim kroku,

modulo 0x900000 gwarantuje, że klucz nie będzie dopełniony np. zerami lub śmieciową zawartością, ponieważ klucz ma długość 1 MB (0x100000), a klucz master, do którego dobierany jest Klucz_1 ma 10 MB (0x1000000), czyli 0x900000 + 0x100000

Wygeneruj Klucz_2: 

  1. wylosuj losową liczbę R2,
  2. wyznacz położenie (offset) z wykorzystaniem funkcji R2 modulo 0x9FFC00,
  3. wykopiuj 1 KB (0x400) z klucza master, zaczynając od położenia wyznaczonego w poprzednim kroku,

modulo 0x99FC00 gwarantuje, że klucz nie będzie dopełniony np. zerami lub śmieciową zawartością, ponieważ klucz ma długość 1 KB (0x400), a klucz master, z którego dobierany jest Klucz_2 ma 10 MB (0x1000000), czyli 0x99FC00 + 0x000400

Wygeneruj Klucz_szyfrujący:

  1. Wykonaj operację Klucz_1 XOR Klucz_2 (powtórzony 1024 razy).

Oznacza to, że Klucz_2, który ma długość 1 KB, jest używany 1024 razy.

Liczby R1, R2 oraz md5 klucza master dołączane są do nazwy zaszyfrowanego pliku.

Dodatkowo, ransomware Hive nie szyfruje całych plików. Próbka badana przez Koreańczyków dzieli szyfrowane pliki w zależności od rozmiaru nawet na tysiące mniejszych kawałków i uszkadza 4 KB (0x1000) w każdym z bloków. Koreańczycy nie piszą o tym, jednak można sprawdzić, że każdy z uszkodzonych bloków szyfrowany jest kolejnym fragmentem klucza.

Rysunek 2. Sposób uszkadzania plików (rysunek 6 w oryginalnym artykule)

Rysunek 3. Sposób uszkadzania plików – plik 128 KB, część uszkodzona – kolorowa, część nieuszkodzona – czarna (sekurak)

Atak na klucz master 

Koreańscy badacze przeprowadzili atak kryptologiczny polegający na próbie odtworzenia głównego klucza kryptograficznego z jego fragmentów wykorzystywanych do generowania kluczy szyfrujących dla pojedynczych plików. W tym celu potrzebne były pary plików: zaszyfrowany i niezaszyfrowany, z których otrzymywano fragmenty klucza master. 

Badanie przeprowadzono w dwóch środowiskach – laboratoryjnym oraz możliwie najbardziej zbliżonym do środowiska użytkownika. Pierwsze środowisko składało się z plików wygenerowanych przez badaczy, w związku z czym dysponowali oryginalnymi (niezaszyfrowanymi) plikami. W drugim przypadku, oryginalne pliki pozyskiwane były z Internetu, backupów oraz wiadomości e-mail.

W środowisku laboratoryjnym, aby uzyskiwać ponad 90% klucza master, potrzebnych było znacznie więcej par plików, niż w tym drugim (realnym).

Tabela 1. Rezultat odtworzenia klucza master do liczby i rozmiaru plików, z których był odtwarzany w środowisku laboratoryjnym (tabela 4 w oryginalnym artykule)

Tabela 2. Rezultat odtworzenia klucza master do liczby i rozmiaru plików, z których był odtwarzany w środowisku możliwie najbardziej zbliżonym do środowiska użytkownika (tabela 5 w oryginalnym artykule)

Następnie badacze sprawdzili, czy z wykorzystaniem odtworzonych kluczy master są w stanie odszyfrować pliki. Odszyfrowali odpowiednio 72% plików w środowisku laboratoryjnym i 82% w drugim środowisku.

Rysunek 4. Wynik eksperymentu (1, 2) odtwarzania klucza master oraz (3, 4, 5) odszyfrowywania plików  (rysunek 11 w oryginalnym artykule)

Nowe warianty Hive

Analizując najnowszą publicznie dostępną próbkę ransomware’a Hive, zauważyć można dodatkowo zmiany, które utrudniają przeprowadzenie ataku kryptograficznego na klucz master. Jednocześnie łatwiejsze jest uzyskanie zadowalającej liczby kluczy szyfrujących, aby naprawić uszkodzone pliki, ponieważ klucze nie są już unikatowe (jednorazowe) i odtworzenie mniejszej liczby kluczy pozwala odszyfrować większą niż jeden liczbę plików (klucze mogą być wykorzystywane wielokrotnie) niż w przypadku zaszyfrowania historycznymi wariantami Hive.

Aktualne warianty Hive inaczej uszkadzają pliki niż w przypadku historycznej próbki analizowanej przez południowokoreańskich badaczy.

Rysunek 6. Porównanie tego samego pliku uszkodzonego próbką aktualną i historyczną (sekurak)

Początkowe 3 KB nie są uszkadzane, a pierwsze uszkodzenie występuje od offsetu 0xC00 i ma rozmiar 0x400, czyli 1 KB (poprzednio uszkadzane były również pierwsze 0x1000). Aktualne warianty Hive nadal uszkadzają fragmenty o rozmiarze 4 KB (poza pierwszym, który ma 1 KB), ale nie oznacza to, że skala uszkodzeń jest odwrotnie proporcjonalna do rozmiaru pliku. Nawet małe uszkodzenia, np. w skompresowanych archiwach, mogą uniemożliwiać ich naprawę bez pozyskania kluczy szyfrujących (i deszyfrujących jednocześnie, co wynika wprost z własności funkcji XOR, wykorzystywanej do szyfrowania).

Bez uważnej analizy zawartości pliku można błędnie ocenić skalę i wpływ uszkodzeń, czyli fakt, że pliki nie zostały uszkodzone i będą sprawne po usunięciu rozszerzenia dodawanego przez aktualne warianty Hive. Sama zmiana nazwy pomaga bardzo rzadko i w nielicznych przypadkach, np. dla plików o rozmiarze co najwyżej 0xC00 (3 KB). 

Przedstawione poniżej logo sekuraka wyświetla się, ponieważ nagłówek pliku BMP znajduje się w nieuszkodzonych fragmentach pliku. Końcowy pasek jest częściowo biały (nieuszkodzony), ponieważ zawiera się w pierwszych 3 KB bitmapy zapisywanej w little endian (ostatni piksel zapisywany jest jako pierwszy).

Rysunek 7. Zaszyfrowany Sekurak – uszkodzone są jedynie fragmenty pliku BMP
(sekurak)

Rysunek 8. Nagłówek uszkodzonego pliku BMP z logiem sekuraka (sekurak)

Dodatkowo w większości przypadków usunięcie (utracenie) informacji o kluczu szyfrującym (md5 klucza master i offsetów Klucza_1 i Klucza_2) bardzo utrudnia, a czasem wręcz uniemożliwia, odszyfrowanie uszkodzonych fragmentów plików, nawet po zakupie narzędzia deszyfrującego od atakujących. Po usunięciu z dysku pliku z rozszerzeniem *.key.[identyfikator], w którym umieszczony jest zaszyfrowany główny klucz kryptograficzny (plik ten może być identyfikowany przez oprogramowanie antywirusowe lub antymalware’owe jako podejrzany), wykasowaniu z nazwy pliku informacji o liczbach R1, R2 potrzebnych do ustalenia, od którego miejsca z klucza master pozyskuje się odpowiednio 1 MB i 1 KB ciągi znaków, czyli o tym, jakie klucze Klucz_1 i Klucz_2 są potrzebne, aby wygenerować Klucz_szyfrujący oraz pliku, z którego jest generowany, bardzo trudne (a czasami niemożliwe) jest odszyfrowanie plików – zwłaszcza z wykorzystaniem narzędzi deszyfrujących dostarczanych przez atakujących, które potrzebują tych danych do ponownego wytworzenia kluczy. 

Z własności funkcji XOR wynika, że aby otrzymać tekst w postaci jawnej, należy ponownie użyć tego samego klucza (do odszyfrowania szyfrogramu potrzebny jest ten sam klucz szyfrujący, którym ten tekst został zaszyfrowany). Atakujący wyraźnie przed tym ostrzegają w pozostawianych notatkach.

Rysunek 9. Fragment notatki (ransomnote) pozostawionej przez sprawców (sekurak)

W ogólnym przypadku, nowe warianty Hive uszkadzają w plikach do 255 fragmentów rozmiarze 0x1000 i jeden (pierwszy) o rozmiarze 0x400, czyli razem do 0xFF400 (255 x 4 KB + 1 x 1 KB).

Rysunek 10. Obliczanie liczby części (chunków) do zaszyfrowania (sekurak)

Rysunek 11. Obliczanie położenia (offsetu) uszkodzonych części (sekurak)

Rysunek 12. Sposób szyfrowania (sekurak)

Offsety, od których wycinane są fragmenty klucza master potrzebne do generowania kluczy szyfrujących pliki, są często ponownie wykorzystywane. Oznacza to, że klucz nie jest unikatowy (jednorazowy) dla każdego pliku, jak to było w przypadku historycznych wariantów Hive’a analizowanych przez południowokoreańskich badaczy.

Rysunek 13. Wylistowane przykładowe zaszyfrowane pliki (aktualna próbka)

Szyfrując aktualną próbką odpowiednio duże pliki o różnych rozmiarach, ale tej samej znanej zawartości (np. wypełnione zerami), można łatwo sprawdzić, że kolejne fragmenty tych plików zostały uszkodzone (szyfrowane, XOR-owane) z wykorzystaniem tego samego klucza, jeśli tylko mają dodane takie samo rozszerzenie. Z uszkodzonych (zaszyfrowanych) kawałków plików można otrzymać do 255 kawałków o długości 0x1000 i 1 o długości 0x400, czyli 255 x 4 KB + 1 KB (tracone są niewykorzystywane pierwsze 3 KB klucza szyfrującego).

Rysunek 14. Porównanie uszkodzonych fragmenty plików 1 GB oraz 10 MB, po usunięciu nieuszkodzonych fragmentów (sekurak)

Następnie, korzystając z własności funkcji XOR i znając oryginalną zawartość pliku, można uzyskać klucz wykorzystywany do szyfrowania konkretnego pliku i użyć go do odszyfrowania wszystkich innych, które są zaszyfrowane z wykorzystaniem tego samego klucza (generowanego na podstawie tych samych par Klucza_1 i Klucza_2, pozyskiwanych z tego samego klucza master). 

Zawartość_oryginalna ⊕ Klucz_szyfrujący = Zawartość_zaszyfrowana

Zawartość_zaszyfrowana ⊕ Zawartość_oryginalna = Klucz_szyfrujący

Zawartość_zaszyfrowana ⊕ Klucz_szyfrujący = Zawartość_oryginalna

Rysunek 15. Odszyfrowanie zaszyfrowanej zawartości z wykorzystaniem funkcji XOR (sekurak)

Proof of Concept by sekurak

W wyniku zaszyfrowania nowym wariantem Hive’a, znajdujemy pliki o takim samym rozszerzeniu dodanym przez złośliwą próbkę (potrzebne będą również pliki oryginalne).

Plik 1 o rozmiarze 4 MB

4m.C5gnXxISrNX5Brt-Pn4ZlvtPI2r28-qpp9SO6B2jgAX_AAAAAAAAAAA0.qmam4

Plik 2 o rozmiarze 100 MB

100m.C5gnXxISrNX5Brt-Pn4ZlvtPI2r28-qpp9SO6B2jgAX_AAAAAAAAAAA0.qmam4

Z Pliku 1, od offsetu 0xC00, kopiujemy pierwszy zaszyfrowany fragment o rozmiarze 1 KB (0x400) (4m_chunk_encrypted).

Rysunek 16. Pierwszy zaszyfrowany fragment Pliku 1 (sekurak)

Z oryginalnego Pliku 1, od offsetu 0xC00, kopiujemy fragment o rozmiarze 1 KB (0x400) (4m_chunk_plaintext).

Rysunek 17. Tekst jawny (fragment oryginalnego Pliku 1) odpowiadający zaszyfrowanemu fragmentowi Pliku 1 (sekurak)

Wykonujemy operację XOR, aby uzyskać klucz potrzebny do odszyfrowania pierwszego uszkodzonego fragmentu pliku.

4m_chunk_encrypted ⊕ 4m_chunk_plaintext = 4m_key_1

Rysunek 18. Klucz potrzebny do odszyfrowania pierwszego zaszyfrowanego fragmentu (sekurak)

Następnie wykorzystujemy klucz uzyskany z pliku 4 MB, aby odszyfrować pierwszy zaszyfrowany 1 KB fragment pliku 100 MB (0x400 od offsetu 0xC00).

Rysunek 18. Porównanie pierwszego odszyfrowanego fragmentu Pliku 2 z odpowiadającym mu fragmentem oryginalnego Pliku 2 (sekurak)

W ten sposób, odnajdując kolejne nieuszkodzone fragmenty o rozmiarze 4 KB każdy, można odszyfrować kolejne fragmenty Pliku 2, korzystając z kluczy z Pliku 1. Aby odszyfrować Plik 2, nie jest potrzebne odtworzenie całego klucza master. Wystarczy odtworzenie konkretnego klucza, którym zaszyfrowano dany plik, a ponieważ klucze w nowych wariantach Hive’a nie są jednorazowe, to uzyskując jeden klucz, można odszyfrować wszystkie pliki zaszyfrowane z jego użyciem.

Aktualne warianty Hive’a do szyfrowania plików wykorzystują mniejszą liczbę kluczy niż te historyczne i trudniej jest przeprowadzić atak na klucz master. Z drugiej strony stosunkowo łatwo można uzyskać zadowalającą liczbę kluczy potrzebnych do odszyfrowania plików, ponieważ potrzeba ich po prostu mniej. Niestety, aktualne warianty ransomware’a Hive nie szyfrują już m.in. katalogu Program Files, więc uzyskanie zadowalającej liczby plików oryginalnych, przy wykorzystaniu których można byłoby odtworzyć klucze szyfrujące wykorzystywane do uszkadzania plików może być procesem mozolnym i długotrwałym.

Czasami z pozoru całkiem niezłe pomysły na tworzenie “lockerów” (tak rosyjskojęzyczni aktorzy nazywają złośliwe programy szyfrujące) przez błędy w ich implementacji przegrywają z prostymi narzędziami.

Potrzebujesz wsparcia po infekcji ransomware? Pisz do nas:

~anna@sekurak.pl

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



Komentarze

  1. R

    Czy kroki 5 i 6 są prawidłowo opisane?

    Odpowiedz
  2. Racja, poprawiona jedna rzecz.

    Odpowiedz
  3. R

    krok 6: chyba powinno być „wykopiować 1 KB (0x400)”, nie MB (0x99FC00)?

    Odpowiedz
  4. R

    to jeszcze:
    10MB powinno być chyba oznaczone 0xA00000, a nie 0x1000000.
    A 0x99FC00 jest błędnie zapisane. Raczej w tych miejscach powinno być 0x9FFC00

    Proponuję nie publikować tego komentarza, a tylko, jeśli mam rację, poprawić w tekście dla innych czytających.

    Odpowiedz

Odpowiedz