Głupota programisty na ratunek ofiarom złośliwego oprogramowania

Złośliwe oprogramowanie szyfrujące pliki użytkownika i żądające okupu w zamian za klucz szyfrujący należy do najbardziej uciążliwych problemów. Na szczęście czasem autor kodu okazuje się być marnym programistą i pliki można odzyskać.

Do tej pory naszym ulubionym przykładem porażki twórców oprogramowania szyfrującego pliki był przypadek programu BitCrypt. Jego autor w trakcie definiowania parametrów klucza szyfrującego RSA pomylił bajty z cyframi i klucz zamiast mieć 128 bajtów (1024 bity) miał tylko 426 bitów (128 cyfr). Dzięki temu możliwa była jego faktoryzacja na domowym komputerze (nam  przy jednej okazji zajęło to ok. doby) i odzyskanie zaszyfrowanych plików. Tym razem autor innego podobnego programu popełnił nie jeden, ale kilka ciekawych błędów.

Trudy analizy wstecznej

Specjaliści z firmy Check Point przyjrzeli się blisko programowi DirCrypt, który nie tylko szyfruje wszystkie ważne pliki na komputerach swoich ofiar, ale także pozostaje aktywny i szyfruje również wszystkie nowo tworzone dokumenty. Skutki działania programu łatwo można zidentyfikować, ponieważ wszystkie pliki zaszyfrowane przez złośnika otrzymują nowe rozszerzenie .enc.rtf. Próba ich otwarcia wyświetla informację o tym, jak można odzyskać ich zawartość.

Kod złośnika jest złożony i celowo zaciemniony. Badacze próbowali zlokalizować funkcję szyfrującą pliki szukając w kodzie wystąpienia ciągu „enc.rtf”, ale okazało się, że wszystkie ciągi tekstowe zostały osobno zaszyfrowane w kodzie. Aby zacząć analizę kodu musieli najpierw znaleźć i odszyfrować wszystkie kluczowe ciągi. W tym celu poszukali w pliku bloku danych o dużej entropii, który nie wydaje się pełnić żadnej roli, za to często sięgają do niego (wykorzystując różne parametry) inne funkcje. Kiedy już zlokalizowali podejrzany fragment, znaleźli funkcję go odczytującą. Funkcja dekodująca była dość złożona, zatem zamiast ją analizować, po prostu wykorzystali ją do odszyfrowania ukrytych ciągów tekstowych i przekazania ich do dalszej analizy.

Kiedy już dysponowali odszyfrowaną kopią złośnika, okazało się, że ciąg „enc.rtf” występuje w kodzie tylko jeden raz. Bezpośrednio przed wywołaniem zmiany nazwy pliku znajdowała się tylko jedna funkcja i badacze przyjęli hipotezę, że jest to funkcja szyfrująca. Kiedy się jej przyjrzeli ich podejrzenia się potwierdziły. Funkcja odczytywała kolejne fragmenty plików, szyfrowała ich zawartość po czym zapisywała je w tych samych miejscach na dysku, z których zostały odczytane. Pozostało już tylko spojrzeć na funkcję odpowiedzialną za proces szyfrowania.

Błędna implementacja algorytmu szyfrującego

Analiza kodu funkcji szyfrującej szybko wskazała, że używany jest szyfr RC4. Implementacja szyfrowania jest jednak obarczona poważnymi błędami. Jednym z ciekawszych jest wywoływanie funkcji szyfrującej, za każdym razem inicjowanej tym samym kluczem, osobno dla każdego pliku. Oznacza to, że każdy plik jest szyfrowany w oparciu o ten sam, identyczny strumień danych (poprzez operację XOR). CO to oznacza w praktyce? Jeśli znamy jawną treść dowolnego zaszyfrowanego pliku, wtedy wystarczy wykonać operację XOR na tekście jawnym i zaszyfrowanym, by odzyskać treść strumienia szyfrującego. Oczywiście dobrze, by plik znany miał duży rozmiar, ponieważ jeśli będzie miał np. długość 100 KB, to umożliwi odzyskanie jedynie pierwszych 100 KB każdego innego pliku. Co jednak, jeśli nie mamy wersji jawnej żadnego pliku? W tej sytuacji z pomocą przychodzą chociażby pliki multimedialne domyślnie obecne w każdej instalacji systemu Windows.

Kiedy badacze spojrzeli na kolejny fragment kodu, musieli mocno przytrzymać się swoich krzeseł. Najwyraźniej autor programu nie miał pojęcia, co zrobić z kluczem szyfrującym i postanowił… zapisać go pod koniec szyfrowanych plików. Dzięki tej wyśmienitej decyzji możliwe okazało się odszyfrowanie każdego pliku.

Ale nie tak szybko

Niestety szyfrowanie RC4 nie było jednym, użytym przez autora oprogramowania. Bez wątpienia ze względu na wydajność procesu miało ono sens w przypadku szyfrowania dużych plików, ale autor programu postanowił dodatkowo zabezpieczyć się przed odzyskiwaniem plików przez swoje ofiary i pierwsze 1024 bajtów każdego pliku zaszyfrował algorytmem RSA. Niestety badaczom nie udało się znaleźć klucza prywatnego. Czy to oznacza, że pliki są nie do odzyskania? Oczywiście nie! Zależy to jedynie od ich formatu. W części przypadków nadpisanie pierwszego kilobajta pliku w ogóle nie wpływa na możliwość odzyskania zawartych w nim danych – dotyczy to np. w dużym stopniu dokumentów MS Office. Badacze opracowali zatem skrypt, który potrafi odszyfrować część pliku, zaszyfrowaną w RC4 i odbudować nagłówek pliku .DOC w celu odzyskania jego zawartości.

Podobny błąd – szyfrowanie jedynie pierwszych 512 bajtów pliku – popełnił także autor programu CryptorBit (prawdopodobnie nasz rodak). W sieci dostępne są narzędzia, umożliwiające odzyskiwanie zaszyfrowanych w ten sposób plików. Z kolei w ręce innych badaczy „wpadły” klucze szyfrujące innego popularnego programu, CryptoLockera, umożliwiając stworzenie narzędzia odszyfrowującego pliki.

Żaden z opisywanych powyżej przypadków nie pobije najgłupszego chyba programu wymuszającego okup – Browlock na platformę Android, którego można oszukać podając mu nieprawidłowy kod Moneypack, ponieważ program nie ma możliwości weryfikacji ich poprawności. Pozostaje nam się cieszyć, że autorzy złośliwego oprogramowania popełniają tak trywialne błędy, umożliwiające użytkownikom pokonanie ich wynalazków.