Wstęp
Sage jest nową rodziną ransomware, wariantem CryLockera. w tej chwili jest rozprowadzany przez tych samych aktorów, którzy zwykle rozsyłają Cerbera, Locky’ego oraz Sporę.
Głównym wektorem infekcji jest malspam i złośliwe załączniki. Emaile z kampanii są puste, bez żadnego tekstu i zawierają jedynie plik .zip. W załączniku znajduje się złośliwy dokument programu Word z makrem pobierającym i instalującym ransomware.
Po uruchomieniu ransomware’u zostaje pokazane okno UAC Windowsa, które jest wyświetlane w pętli do momentu, aż użytkownik ostatecznie zgodzi się na nadanie praw administracyjnych aplikacji.
Na końcu rozpoczynany jest proces szyfrowania i pliki są przetwarzane:
Wiadomość z żądaniem okupu kieruje nas do panelu w sieci Tor, ale zanim możemy się zalogować musimy rozwiązać captchę:
W końcu jesteśmy witani przez „przyjazny użytkownikowi” panel:
Można choćby porozmawiać z twórcami malware (ale nie testowaliśmy tej opcji):
Co ciekawe, próbka nie usuwa się z systemu po infekcji, ale kopiuje się do folderu %APPDATA%\Roaming, i szyfruje wszystkie pliki ponownie po każdym restarcie komputera (do momentu aż zostanie zapłacony okup).
Analiza techniczna
Po tym krótkim wprowadzeniu, skoncentrujemy się bardziej na stronie technicznej, ponieważ Sage 2.0 nie jest zupełnie wtórną rodziną i kilka rzeczy nadaje się do opisania.
Główna funkcja programu wygląda tak:
Jak widzimy, po drodze wiele rzeczy jest sprawdzanych i komputer jest identyfikowany na kilka sposobów. Ciekawsze rzeczy jakie znaleźliśmy to m.in.:
Parametr służący do debugowania
Prawdopodobnie nie wszystko w kodzie działało od razu jak trzeba, ponieważ istnieje w nim parametr (przekazywany z linii poleceń) służący do testowania działania konfiguracji malware’u:
I rzeczywiście, jeżeli zostanie przekazany, robi to co powinien:
Prawdopodobnie twórca zapomniał usunąć ten fragment kodu z ostatecznej wersji, bo funkcja ta jest bezużyteczna poza okresem programowania.
Sprawdzenie języka
Twórcy Sage’a 2.0 lubią niektóre kraje bardziej niż inne:
Funkcja ta sprawdza layouty klawiatury użytkownika:
- next == 0x23 -> białoruski
- next == 0x3F -> kazachski
- next == 0x19 -> rosyjski
- next == 0x22 -> ukraiński
- next == 0x43 -> uzbecki
- next == 0x85 -> sacha (jakucki)
Niestety, język polski nie trafił na listę wyjątków Sage’a w obecnej wersji. Może w przyszłości?
Namierzanie użytkownika
Sage próbuje poznać lokalizację swojego hosta odpytując maps.googleapis.com z aktualnym SSID sieci Wi-Fi oraz adresem MAC:
Plik kanarka
Przed szyfrowaniem próbka sprawdza czy istnieje specjalny plik:
Dzięki temu twórcy malware nie muszą się przejmować przypadkowym uruchomieniem swojego dzieła i zaszyfrowaniem własnego dysku. Ale jeżeli plik nie zostanie znaleziony, szyfrowanie jest rozpoczynane.
Lista szyfrowanych rozszerzeń
Nie są szyfrowane oczywiście pliki – tylko te z rozszerzeniami pasującymi do whitelisty:
Szyfrowanie
Jak zwykle to najciekawsza część kodu każdego ransomware. Sage 2.0 szczególnie wyróżnia się pod tym względem, ponieważ szyfruje pliki korzystając z kryptografii krzywych eliptycznych.
Do szyfrowania użyta została krzywa eliptyczna postaci y^2 = x^3 + 486662x^x + x, z punktem bazowym x=9, określona nad ciałem skończonym zdefiniowanym przez liczbę pierwszą p = 2^255 – 19. Te wartości nie są wybrane przypadkowo – ta krzywa jest zwana również Curve25519 i należy do jednych z najnowocześniejszych współczesnych metod szyfrowania. Nie tylko jest to jedna z najszybszych krzywych eliptycznych, ale jest też mniej podatna na słabe generatory losowości. Została zaprojektowana przy uwzględnieniu możliwych ataków kanałem bocznym (side channel), unika wielu potencjalnych problemów implementacyjnych oraz (prawdopodobnie) nie ma backdoora stworzonego przez żadną trzyliterową agencję.
Klucz publiczny używany podczas generacji współdzielonego sekretu jest zapisany na stałe w próbce. Dokładny kod wygląda tak (struktury i funkcje nazwane przez nas):
Jest to prawidłowa implementacja protokołu krzywych eliptycznych Diffiego-Hellmana (ECDH), ale ponieważ klucze prywatne nie są nigdzie zapisywane, sekret może odzyskać jedynie strona będąca w posiadaniu klucza prywatnego serwera.
Funkcja ta może wyglądać skomplikowanie, ale prawie wszystkie jej składowe to funkcje opakowujące prymityw ECC – nazwany przez nas CurveEncrypt. Na przykład szukanie pasującego klucza publicznego to po prostu mnożenie przez punkt bazowy (który jest równy 9, czyli jeden bajt 9 i 31 zer):
Liczenie współdzielonego sekretu jest bardzo podobne, ale zamiast stałego punktu bazowego używamy klucza publicznego:
Z powodu własności Curve25519, konwertowanie między sekwencją dowolnych losowych bajtów i kluczem prywatnym jest bardzo proste – wystarczy maskować kilka bitów i ustawić jeden:
Dodatkowo z tego powodu generowanie klucza prywatnego jest trywialne (wystarczy wylosować 32 bajty i skonwertować je do klucza prywatnego):
To wszystko jeżeli chodzi o generowanie klucza. Co z szyfrowaniem plików? Użyty jest algorytm ChaCha (to chyba pierwsza rodzina szyfrująca tym algorytmem, mimo iż Petya używa bardzo zbliżonego algorytmu Salsa20), a klucz ChaCha jest dopisywany do końca pliku, po zaszyfrowaniu dzięki Curve25519:
Gdzie funkcja AppendFileKeyInfo dokleja na koniec danych zaszyfrowany klucz oraz klucz publiczny:
Nie wiemy czemu została użyta ChaCha zamiast AES – prawdopodobnie to tylko próba wyróżnienia się albo paranoja przed wyimaginowanymi tylnymi furtkami agencji rządowych.
Podsumowując, istnieją dwa zbiory kluczy plus jedna para kluczy na każdy zaszyfrowany plik:
Kiedy ransomware kończy swoje operacje, znamy tylko my_public, sh_public, fl_shared, a potrzebujemy odzyskać chachakey żeby zdeszyfrować plik – nie zrobimytego bez znajomości prywatnych części.
Ten schemat szyfrowania jest dobrze przemyślany, ponieważ umożliwia szyfrowanie offline – nie ma potrzeby łączyć się z C&C i negocjowania kluczy szyfrujących. Wystarczy klucz publiczny, zapisany na stałe w programie. Zakładając iż twórcy złośliwego systemu nie popełnili drastycznych błędów implementacyjnych (a nie mamy powodu podejrzewać żeby to zrobili), odzyskanie zaszyfrowanych plików jest niemożliwe. Oczywiście zawsze jest możliwość, iż klucze szyfrujące zostaną wcześniej upublicznione przez kogoś.
Dodatkowe informacje
Reguły Yara:
Hashe (sha256):
- sample 1, 362baeb80b854c201c4e7a1cfd3332fd58201e845f6aebe7def05ff0e00bf339
- sample 2, 3b4e0460d4a5d876e7e64bb706f7fdbbc6934e2dea7fa06e34ce01de8b78934c
- sample 3, ccd6a495dfb2c5e26cd65e34c9569615428801e01fd89ead8d5ce1e70c680850
- sample 4, 8a0a191d055b4b4dd15c66bfb9df223b384abb75d4bb438594231788fb556bc2
- sample 5, 0ecf3617c1d3313fdb41729c95215c4d2575b4b11666c1e9341f149d02405c05
Więcej materiałów:
- https://www.govcert.admin.ch/blog/27/saga-2.0-comes-with-ip-generation-algorithm-ipga – krótka, ale bardzo bogata analiza przeprowadzona przez szwajcarski CERT.
