Analiza ransomware napisanego 100% w Javascripcie – RAA

17 sierpnia 2016, 09:45 | Teksty | komentarzy 17
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

14 czerwca 2016r., znalazłem informację o nowym ransomware o nazwie RAA. Kilka serwisów związanych z bezpieczeństwem określiło go jako pierwsze tego rodzaju oprogramowanie napisane w całości w JavaScripcie, włącznie z algorytmem szyfrującym pliki na dysku komputera ofiary.

Dzięki informacjom otrzymanym od @hasherezade, która na co dzień zajmuje się analizą złośliwego oprogramowania, pobrałem kod źródłowy RAA i przystąpiłem do analizy.

Jako programista, który stale ma do czynienia z językiem JavaScript, w swojej analizie skupiłem się głównie na jego działaniu, bez wchodzenia w szczegóły implementacyjne – np. obiektów Windows Script Hosts, które RAA intensywnie wykorzystuje do operacji na plikach w zainfekowanym systemie. Jeśli ktoś chciałby poznać działanie tych obiektów dokładniej, może skorzystać z linków które zamieściłem w opisie niektórych fragmentów kodu.

Analiza

W poszczególnych jej etapach opiszę wszystkie funkcje wchodzące w skład głównej logiki RAA oraz prześledzę wykonanie kodu od początku aż do momentu, w którym pojawia się informacja o okupie, a pliki na twardym dysku są już zaszyfrowane.

Dla osoby na co dzień pracującej z nowoczesnym językiem programowania JavaScript, pierwszy kontakt z RAA pozwala stwierdzić, że jest to jeden wielki spaghetti code, w którym definicje funkcji oraz ich wywołania mieszają się ze sobą, i w którym zastosowane są nawet definitywnie odradzane mechanizmy języka, takie jak instrukcje skoków do etykiet (wyjaśnienie jak działają, znajduje się w opisie jednego z fragmentów poniżej).

W repozytorium w serwisie GitHub znajduje się plik raa.js, który zawiera oryginalny, nie zmodyfikowany kod JavaScript analizowanego ransomware. Przy pierwszym podejściu do analizy starałem się nadać zmiennym i funkcjom bardziej „przyjazne” nazwy, ale po pewnym czasie zrezygnowałem – stwierdziłem, że nie poprawia to czytelności kodu.

W tym podejściu wyodrębniłem trzy główne części programu (wspomniany wyżej plik z kodem źródłowym  znajduje się tutaj):
*/ biblioteka CryptoJS – linie od 1 do 482
*/ główna część kodu RAA – linie od 485 do 1082
*/ część kodu generująca dokument w formacie RTF z informacją dla zainfekowanego użytkownika – linie od 1083 do końca pliku

Biblioteka CryptoJS

Jest ogólnie dostępną, otwartoźródłową biblioteką udostępnianą także GitHub (fork),  szeroko wykorzystywaną w wielu projektach. CryptoJS zawiera implementacje wielu popularnych algorytmów kryptograficznych lub funkcji mieszających, w tym wykorzystywanego w RAA AES-a.

Początek

Na poniższym schemacie przedstawiłem kolejność wywołań głównych metod, z których część zawiera własne, zdefiniowane wewnątrz pomocnicze funkcje realizujące dodatkowe operacje, np. filtrowanie tablic z nazwami plików.

Pierwsza wykonywalna instrukcja kodu, to proste przypisanie wartości zwracanej przez funkcję YUIMqkFkI() do zmiennej TBucypWw. Gdy przyjrzymy się co zawiera funkcja YUIMqkFkI() okaże się, że to prosty  prosty algorytm zwracający pięcioznakową sekwencję wygenerowaną poprzez losowy wybór znaków z ciągu WKQttPJDfsQE:

Jak okaże się dalej, ten pięcioznakowy klucz, zapisany w TBucypWw, jest używany przez RAA w wielu innych miejscach. Na potrzeby tego artykułu przyjmijmy, że jego wartośc to „xW5Gf”.

Poznajcie Pony

Następnym wykonywalnym fragmentem kodu jest:

W przypadku gdy do skryptu zostaną przekazane jakieś argumenty, program nie wykona żadnych operacji.
W przeciwnym razie wykonają się dwie funkcje, które omówię poniżej.

Funkcja  nYuMHHRx()

Zmienna tpcVJWrQG zdefiniowana na samym początku, zawiera kilkudziesięciobajtowy ciąg w Base64, na którym wykonywanych jest kilka operacji (odkodowanie danych z Base64, przekształcenie z użyciem metody JavaScript operującej na ciągach – replace()). Następnie, tworzony jest obiekt ActiveX o nazwie ADODB.Stream oraz nowy obiekt WScript.shell, który m.in. umożliwia uruchamianie komend wiersza poleceń systemu Windows:

Kolejna linia:

pozwala obiektowi ADODB.Stream traktować ciągi znaków JavaScript, jako dane binarne (ta definicja stosowana jest w analizie kilkakrotnie, zatem nie będę jej ponownie przytaczał w kolejnych etapach badania).

Następne linijki to utworzenie nowego pliku w następującej ścieżce:

\MyDocuments\doc_atatched_xW5Gf

i zapisanie do niego zawartości odczytanej ze zdekodowanego ciągu w Base64. Ostatnim elementem funkcji jest instrukcja uruchomienia WordPada, z argumentem będącym przed chwilą utworzonym plikiem:

Plik jest dokumentem w formacie RTF – jego zawartość przedstawia poniższy zrzut ekranu, który znajduje się w moim repozytorium.

extracted_rtf_screen

Rys. 1. Zrzut ekranu zawartości dokumentu w formacie RTF

Funkcja NWvQtGjjfQX()

Druga z funkcji zawiera następujący kod:

Zawartość zmiennej data_pn została przeze mnie zmniejszona, by zachować czytelność (oryginalnie zawiera ona bardzo długi, losowy ciąg znaków). Dwie kolejne zmienne – cmd oraz key_cmd, służą do wygenerowania dec_cmd (ciąg cmd jest dekodowany z użyciem klucza key_cmd i algorytmu AES).

Zmienna dec_cmd okazuje się być wykonywalnym fragmentem kodu JavaScript, natomiast opisana powyżej operacja z AES to ciekawa metoda obfuskacji kodu JavaScript, która wymaga jednak użycia takiej biblioteki  jak CryptoJS, do uzyskania kodu w czytelnej postaci.

Jego zawartość prezentuje poniższy listing:

Kod ten jest wykonywany przez ostatnią przed return; instrukcją w funkcji NWvQtGjjfQX():

Jego funkcjonalność jest zbliżona do kodu opisanego wcześniej: utworzenie pliku, zapisanie do niego zawartości ciągu data_pn poddanego kliku kolejno następujących po sobie przekształceniom, a następnie jego uruchomienie. Plik ten znajduje się w repozytorium i jest to – wg analizy – malware o nazwie Pony. Więcej o Pony można przeczytać tu  lub tu.

Oznacza to, że poza szyfrowaniem plików RAA uruchamia na komputerze ofiary trojana.

Modyfikacja rejestru Windows

Kolejna funkcja zajmuje się modyfikacją rejestru Windows sprawiając, by ransomware był uruchamiany po każdym restarcie systemu i kontynuował swoją pracę:

Odpowiedzialny za uruchamianie jest wpis w rejestrze w gałęzi HKCU\Software\Microsoft\Windows\CurrentVersion\Run\.

Na starcie, ransomware sprawdza czy w rejestrze znajduje się już wpis w gałęzi HKCU\Raa-fnl\ (jest on tworzony na samym końcu „działalności RAA”) – poprzez próbę jego odczytu. Brak wpisu powoduje wyrzucenie wyjątku,
a w jego instrukcji catch, wartość wcześniej zadeklarowanej zmiennej QCY ustawiana jest na 0. W dalszej części funkcji, QCY równe 0 powoduje utworzenie wpisu w rejestrze uruchamiającego RAA, a następnie wywołanie funkcji HxBG().

Połączenie ze zdalnym serwerem

izzU() to dość kompleksowa funkcja, wykonująca „najgorszą” z punktu widzenia użytkownika część kodu. Rozpoczyna swoją pracę od wygenerowania identyfikatora GUID, który jest wg dokumentacji Microsoft unikalnym identyfikatorem używanym do rozpoznania konkretnego komponentu w aplikacji.

Następnie, wywoływana jest funkcja get_HZtSmFNRdJM(), która inicjalizuje tablicę KrvABjTTXNS wartościami zwróconymi ze zdalnego serwera. Tutaj wykorzystałem wnioski z innej analizy RAA, udostępnionej na blogu firmy ReaQta. Przyczyną był fakt, że – w czasie gdy przeprowadzałem własną analizę kodu RAA – zdalny serwer z którym ransomware się komunikował, już nie działał.

Adres serwera jest na stałe zakodowany w funkcji get_HZtSmFNRdJM():

Szybkie sprawdzenie pozwoliło ustalić IP serwera (188.40.248.65), który okazał się częścią sieci zlokalizowanej
w Niemczech, wykorzystywaną przez rumuńską firmę hostingową THC Projects. Jak już wspomniałem, w dniu
w którym analizowałem ten fragment kodu, serwer nie działał, a domena startwavenow.com była zawieszona:

Sam kod odpowiedzialny za połączenie jest dość standardowy (opis poniżej):

Tworzony jest obiekt umożliwiający wysyłanie żądań HTTP:

Następnie, wykonywany jest niżej przytoczony fragment kodu:

Gdy przyjrzymy mu się dokładniej, nie ma on większego sensu, szczególnie użycie tablicy MOSKn i zmiennej pointer_MOSKn – tak naprawdę kod wykona się tylko raz, gdy serwer zwróci (a właściwie – gdyby  zwracał :) ) wartość, która zostanie przypisana do zmiennej aka.

Z informacji na blogu ReaQta wynika, że aka zawiera dwuelementową tablicę, której elementy zostaną użyte w późniejszym procesie szyfrowania plików (VKw zostanie użyty jako klucz dla operacji szyfrowania):

Enumeracja folderów i plików

Kolejny wykonywalny fragment kodu inicjalizuje tablicę kAgTDYi i do jej pierwszego elementu przypisuje rezultat wykonania funkcji kth():

Prześledźmy zatem, co się w niej dzieje:

Obiekt ActiveX o nazwie Scripting.FileSystemObject umożliwia operacje na systemie plików, natomiast jego właściwość Drives jest iteratorem, umożliwiającym przechodzenie po kolejnych dyskach. kth() zwraca więc listę wszystkich dostępnych na zainfekowanej maszynie dysków logicznych (C:, D: itd.).

Następnym fragmentem jest:

Funkcja iKTzQKbfDJs() wywołuje dwie inne, krótkie funkcje OFTEml() oraz YlDrqb():

OFTEml() otrzymuje jako argument utworzoną wcześniej listę dysków i zwraca ją ponownie, usuwając jedynie „puste” wpisy.

Następnie, dla każdego dysku wywoływana jest funkcja YlDrqb():

Jej zadaniem jest utworzenie na każdym z dysków, pliku o następującej nazwie:

var dir = kth + „!!!README!!!” + TBucypWw + „.rtf”; // –> C!!!README!!!xW5Gf.rtf

Jak widać, użyty w niej jest pięcioznakowy klucz wygenerowany na samym początku analizy – w pierwszej wywoływanej funkcji. Jest to jedno z wielu miejsc, w którym jest on wykorzystywany. Unikalny klucz zapisany w zmiennej TBucypWw, ma zapewne utrudnić identyfikowanie plików związanych z RAA na zainfekowanym systemie (gdyż jego wartość dla każdej maszyny będzie inna).

Zawartość każdego z tych plików generuje funkcja wywoływana w tej linijce:

W funkcji VGCDtihB() generowany jest kolejny dokument w formacie RTF,  zawierający notę o wysokości „okupu”, który należy uiścić w celu otrzymania klucza deszyfrującego. Metoda generowania jest podobna do wcześniejszych – to kilka następujących po sobie manipulacji długim ciągiem znaków w Base64:

Kolejny fragment kodu to funkcja, która w pętli „dostarcza” algorytmowi szyfrującemu wszystkie pliki z listy zwróconej z funkcji nXmsNjMpKTv():

Dzieje się tu sporo, prześledźmy zatem wszystko po kolei.

Tablica sNaZfrOWc inicjalizowana jest rezultatem wykonania funkcji nXmsNjMpKTv():

Wywołanie:

wykonuje funkcję LMz() dla każdego z dysków. LMz() zawiera długą listę warunków „if…else”, które sprawdzają każdy plik pod kątem dopasowania jego nazwy do wzorca. Jeśli plik pasuje – jest on dodawany do jednego, bardzo długiego ciągu znaków składających się z podobnych nazw plików, a nazwy te odseparowane są od siebie znanym nam już, pięcioznakowym kluczem „xW5Gf” zapisanym w zmiennej TBucypWw:

Tylko trzy wystąpienia w nazwie pliku sprawiają, że nie jest on brany pod uwagę w tym procesie: ciąg .locked (który tworzy sam RAA w procesie szyfrowania) oraz znaki ~ i $.

Z tak zapisanego ciągu znaków, tworzona jest tablica – przy pomocy funkcji split(). Jako separator użyty zostaje klucz zapisany w zmiennej TBucypWw.  Tablica ta zostaje poddana „oczyszczeniu” z pustych elementów przez funkcję OFTEml():

Funkcja HHiAp() przeprowadza podobną operację, ale operuje na nazwach folderów. W odróżnieniu od LMz(), lista tworzona przez nią nie zawiera folderów, które mają być pominięte w procesie szyfrowania (WINDOWS, RECYCLER, Program Files, Temp, AppData i podobne, kluczowe dla działania systemu foldery). Ma to zapobiec omyłkowemu zaszyfrowaniu pliku koniecznego do prawidłowego działania komputera, a tym samym jego unieruchomienie i niemożność zadziałania całego procesu wymuszenia okupu za klucz deszyfrujący:

Dygresja: to może być skuteczna metoda obrony przed RAA – jeśli wszystkie pliki będą trzymane w jednym z tych folderów, RAA nie zaszyfruje żadnego z nich, a tym samym nie będzie miał za co wyłudzić okupu :)

Szyfrowanie

Pętla w funkcji PLnEyqCPKHV() kończy cały proces, szyfrując każdy z plików:

Zanim to jednak nastąpi, inne funkcje zawarte w KWgwJwOlqJcs() wykonuje jeszcze kilka operacji przed samym szyfrowaniem.

Najpierw, dwie zmienne inicjalizowane są przez funkcję rStinsVp(), której argumentem jest zwrócony z serwera klucz:

Funkcja rStinsVp():

zwraca dwuelementową tablicę, która zawiera dwa elementy: 32-elementową tablicę czterocyfrowych, losowych liczb oraz drugi element, którym jest wybrany losowo z VKw 32-znakowy ciąg znaków. Jako, że zawartość VKw pozostała dla mnie nieznana z powodu nie działającego serwera z którym łączył się RAA, użyłem innego, losowo wybranego ciągu znaków i uruchomiłem rStinsVp() podając ten ciąg jako argument zamiast VKw.

Przykładowy rezultat wykonania:

Następnym krokiem po inicjalizacji tych dwóch zmiennych, jest funkcja udpIHxN():

W pierwszej kolejności tworzony jest obiekt ADODB.Stream wykorzystywany do manipulacji plikami w podobny sposób, w jaki odbywało się to już wcześniej w kodzie ransomware. Następnie, do obiektu wczytywana jest zawartość aktualnie „obrabianego” pliku (pamiętajmy, że cała operacja odbywa się w pętli – indywidualnie dla każdego przeznaczonego do zaszyfrowania pliku) oraz sprawdzany jest rozmiar pliku.

W zależności od jego wielkości, podejmowane są różne kroki:

  • jeśli rozmiar pliku zawiera się w przedziale od 6122 bajtów do 4,76 MB (dokładnie 4882 kB) – wówczas tworzona jest tablica hXpHGpZ, następnie w tablicy tej zapisane zostają fragmenty pliku podzielonego na losowej wielkości części. W dalszej kolejności, tablica z fragmentami pliku przesyłana jest  do funkcji jMvqmKSQu(),
  • jeśli plik jest większy niż 4,76 MB, ale mniejszy niż 476 MB – wywoływana jest funkcja qqJ() z plikiem jako argumentem,
  • jeśli rozmiar pliku jest mniejszy lub różny 6122 bajtom – jest on użyty bezpośrednio jako argument dla funkcji jMvqmKSQu().

Pliki o rozmiarze większym niż 476 MB, nie są brane pod uwagę w procesie szyfrowania.

Przyjrzyjmy się jeszcze, co jakie operacje wykonują funkcje jMvqmKSQu() oraz qqJ().

W zależności od zawartości tablicy hXpHGpZ oraz tego, czy jest ona dwu- czy jednowymiarowa (to zależy, jakiej wielkości plik był przesłany do niej uprzednio jako argument), funkcja zapisuje zawartość pliku do zmiennej DftonCbPCyQR, dodając własne metadane. Następnie, tak przygotowany ciąg trafia już bezpośrednio do funkcji szyfrującej zawartość pliku algorytmem AES:

Zwrócona zaszyfrowana zawartość pliku zastępuje oryginalny plik, a do jego nazwy zostaje dodane rozszerzenie .locked (to zapobiega jego ponownemu zaszyfrowaniu, zapewnianemu poprzez mechanizm wyszukiwania plików przeznaczonych do operacji zaszyfrowania, opisanej wcześniej):

Wykorzystana tu metoda obiektu ADODB.Stream, MoveFile jest opisana dokładniej na stronie MSDN.

Funkcja, która odpowiada za szyfrowanie większych plików (pomiędzy 4,76 a 476 MB) jest troszkę bardziej rozbudowana:

Najpierw, tworzone są dwa obiekty ADODB.Stream:

Następnie, plik zostaje zaszyfrowany po podzieleniu go na fragmenty (każdy fragment zostaje zaszyfrowany osobno) oraz zapisaniu każdego fragmentu w osobnym ciągu znaków (oba obiekty operują na ciągach znaków JavaScript tak, jakby były to dane binarne):

Wreszcie, zaszyfrowane fragmenty są zapisywane razem jako jeden plik, a do jego nazwy dodawane jest rozszerzenie .locked:

Zakończenie

Gdy RAA zaszyfruje już wszystkie przeznaczone do tego pliki, w rejestrze Windows tworzony jest wpis (sprawdzany na samym początku), informujący o zakończeniu procesu:

Ostatnim krokiem, jest wyświetlenie użytkownikowi komunikatu z kwotą do zapłaty za klucz deszyfrujący i danymi kontaktowymi:

Podsumowanie

RAA jest dowodem na to, że JavaScript – język, którego przeznaczeniem miała być obsługa interakcji z użytkownikiem na stronie www – może być użyty dosłownie do wszystkiego. RAA to nie jedyny przykład, warto zapoznać się np. z analizą wpisów o innym ransomware – Locky, który używa napisanego w JavaScripcie downloadera binarnej części ransomware lub zawiera taką binarkę bezpośrednio w sobie:

„From Locky with love” autorstwa @hasherezade
„Return of Locky”
„Locky ransomware now embedded in JavaScript”

W obliczu rosnącej popularności JavaScript, będziemy świadkami coraz częstszych przypadków złośliwego oprogramowania podobnego do Locky, czy opisanego tutaj RAA. Obfuskacja kodu JavaScript pozwala na omijanie detekcji przez programy antywirusowe na wiele sposobów (proces deobfuskacji opisany w „Return of Locky” przedstawia jeden z wielu możliwych wariantów zaciemniania kodu JavaScript), a sam kod jest łatwy w napisaniu i utrzymaniu (np. nie wymaga kompilacji i jest go łatwo zaadaptować na potrzeby zupełnie innej platformy).

Rafał ‚bl4de’ Janicki 

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



Komentarze

  1. Świetna analiza bl4de.
    Czy istnieje jakiś prosty sposób na to aby wykryć, że kod został zaciemniony?

    pzdr!

    Odpowiedz
  2. p

    Niżej link do rozsyłanego ostatnio Crypt0l0cker’a również napisanego w js, który trafił jakiś czas temu do mnie ;)
    http://pastebin.com/jFdyBjJ9

    Odpowiedz
    • Uwaga tylko żeby się nie zarazić…

      Odpowiedz
    • bl4de

      Dzieki za linka, rzuce na to okiem pozniej :)

      Odpowiedz
  3. Wojtek

    W opisie modyfikacji rejestru piszecie:
    „W dalszej części funkcji QCY różne od 0 powoduje utworzenie wpisu w rejestrze uruchamiającego RAA”,
    a nie powinno być równe zeru.
    Linia 27: if (AFtKLHIjDtkM < 2 && QCY == 0) …
    Tak mi się wydaje

    Odpowiedz
    • bl4de

      Tak, sluszna uwaga, dzieki!

      Odpowiedz
  4. zero one

    Java i Flash to za przeproszeniem – syf. Od początku miało to to służyć „odpowiednim” celom. Jak zawsze pod przykrywką wygody czy ładniejszego wyglądu. Tak uważam odkąd sięgnę pamięcią. Mało kto oczywiście się ze mną zgadza. :P
    Albo taki NET Framework – parszywy zamulacz OSów. ;D

    Odpowiedz
    • Hmm…tylko to Javascript, który z Javą ma tyle wspólnego co ham z hamsterem :)

      Odpowiedz
    • DaBomb

      Może kolega chciał właśnie pochwalić wybór autora tego kodu? :) Że Java be, ale JavaScript zajęliśmy :D

      Odpowiedz
  5. Krzysiek

    Jakie remedium? Wyłączyć javascript? Ewentualnie jakieś inne pomysły?

    Odpowiedz
  6. Bry

    Czy taki skrypt wymaga jakiejkolwiek interakcji ze strony użytkownika czy jest uruchamiany bezpośrednio po wejściu na stronę i omija blokady przeglądarki?

    Odpowiedz
    • bl4de

      Hej,

      Zarażenie się czymś takim przebiega podobnie, jak każdym innym malware – drive-by-download, kliknięcie w załącznik do maila itd.

      Ten kod nie jest przeznaczony do działania w przeglądarce i nie jest w niej wykonywany. Jest uruchamiany w systemie Windows przez mechanizm Windows Scripts Host i jego wbudowany silnik JavaScript (czyli generalnie możesz napisać program dla Windows w JavaScript i uruchomić go, jakby był natywnym, skompilowanym programem dla tego systemu).

      Odpowiedz
  7. Phx

    Nie jestem programista dlatego mam pare pytan.:

    1. skąd jest dostępny czysty kod programu, twórca sam go udostępnił ? czemu nie jest zaciemniony ? Z tego co wiem w przypadku plików exe nie jest tak łatwo.

    2. Czemu akurat Java Script ? Czy jest trudniej wykryć go przez AV ?

    3. Czy ten ransomware przez to ze jest napisany w javie przy odpowiedniej modyfikacji jego działania mógłby też działać na linuksie i macku ?

    Odpowiedz
    • Q

      Musiał byś się trochę namęczyć, żeby przepisać na nodejs, a tam nie ma obiektów windowsa

      Odpowiedz
    • M

      Odpowiem na Twoje trzecie pytanie. JavaScript i Java to całkowicie inne języki. Mają one inną składnię, uruchamianie, środowisko. Jedyne co mają wspólne to część nazwy.

      Odpowiedz
    • bl4de

      Hej,

      1. Kod takiego ransomware, czy każdego innego szkodliwego oprogramowania staje się dostępny do analizy, gdy np. osoba, która zidentyfikuje go jako szkodliwy prześle go do analizy osobie bądź firmie, kto się tym zajmuje. Są serwisy internetowe, które pozwalają też zbadać plik pod kątem tego, czy nie jest właśnie jakimś malware (np. malwr.com)

      Kod tego akurat konkretnego ransomware, nawet gdyby był zaciemniony, ostatecznie musiałby być dostępny w możliwej do odczytania postaci z bardzo prostej przyczyny: wszystkie silniki JavaScript operują na takim samym kodzie, który jest kompilowany i interpretowany podczas uruchomienia (polecam poczytać jak działa JIT (Just In Time compiler) JavaScript’u :).
      Technicznie nie ma więc możliwości sporządzić pliku w języku JavaScript w taki sposób, by był on niemożliwy do przeanalizowania zanim trafi do silnika JS przeglądarki, node.js, WSH czy dowolnego innego środowiska uruchomieniowego JS

      2. Czemu JavaScript – to pytanie należałoby zadać twórcy RAA :) Co do możliwości wykrycia go przez antywirusy – na to pytanie także nie znam odpowiedzi – analizowałem RAA jedynie pod kątem tego, jak używając tylko JavaScript można napisac w pełni funkcjonalny kod ransomware, który zadziała w systemie operacyjnym, takim jak Windows. Nie zagłębiałem się w ogóle w kwestie takie, jak proces zarażenia, wykrycia czy usunięcia go z systemu.

      3. Sam mechanizm szyfrowania plików (iteracja po drzewie katalogów i plików, zastąpienie każdego pliku jego zaszyfrowaną formą itd.) jest jak najbardziej możliwa np. w Node.js, przypuszczam, że w Linuksie, gdzie np. Gnome 3 Shell był (jest?) napisany w JavaScript też byłoby to jak najbardziej możliwe. Do tego wystarczy biblioteka taka, jak CryptoJS dołączona bezpośrednio w kodzie ransomware (jak w przypadku RAA) oraz metody umożliwiające odczyt i zapis plików (co posiada między innymi moduł fs – https://nodejs.org/dist/latest-v4.x/docs/api/fs.html)

      Głównym probelem pozostaje natomiast sam wektor ataku i zarażenie systemu. Problemem byłoby ominięcie bądź eskalacja uprawnień użytkownika, który uruchomił ransomware, gdyby RAA musiał „dodać” się gdzieś, by uruchamiać się przy restarcie systemu. Konstrukcja systemów *nix i ich system uprawnień znacząco komplikują tutaj sprawę.

      Ale technicznie rzecz biorąc, odpowiedź na Twoje pytanie brzmi: tak, jest możliwe, by po odpowiednich modyfikacjach RAA zadziałał na OSX lub Linuksie. Jedyne, co musiałbyś zrobić, to uruchomić go ręcznie i z prawami root’a, by mógł zmodyfikować (zaszyfrować) pliki, do których nie masz uprawnień.

      Odpowiedz
      • autostart

        @bl4de, po eskalacja do roota? Chodzi o szyfrowanie dokumentów a nie plików systemowych, więc wystarczy iterować po /home/user z prawami bieżącego usera, a autostart w .bashrc, dconf, ~/.config/autostart i pewnie wiele innych sposobów

        Odpowiedz

Odpowiedz