04 02.2019

Dlaczego nie powinieneś pisać własnego ransomware?

W kilku ostatnich latach prawdziwą furorę robi oprogramowanie typu ransomware, szyfrujące dane na dysku czyjegoś komputera i żądające następnie okupu za ich odzyskanie. Popularność tego oprogramowania może skłaniać niektóre osoby do prób podążenia za tym trendem i napisania własnego programu tego typu w nadziei na "ustawienie się" na całe życie.

Co gorsza, jest to podsycane newsami typu "hakerzy zarobili nawet 5 milionów dolarów". Gdy jednak zgłębimy temat, raport firmy Bitdefender z 2016 roku mówi o średnich zarobkach na poziomie niecałych 29 tysięcy dolarów rocznie, za średnio 700 poświęconych na atak godzin (jednak nie precyzując sposobu wyliczenia tych godzin, a więc prawdopodobnie pomijając czas poświęcony np. na douczenie się brakujących umiejętności). Jest to więc przychód porównywalny z tym, jaki zdolny programista jest w stanie osiągnąć legalną pracą, bez narażania się na złapanie i odpowiedzialność karną.



Wirus zaszyfrował Twoje pliki? Nie płać okupu, zgłoś się do nas! Możemy spróbować odzyskać Twoje dane już od 720 zł netto.




Intencją autora ani wydawcy artykułu nie jest namawianie bądź zachęcanie do łamania prawa. Jeśli popełniłeś lub masz zamiast popełnić przestępstwo, bądź masz wątpliwości, czy Twoje działania nie będą łamać prawa, powinieneś skonsultować się z najbliższą jednostką Policji lub Prokuratury, a jeśli są one związane z pieniędzmi, dla pewności również z Urzędem Skarbowym.



Jeśli argument o legalnej pracy do Ciebie nie trafia, przyjrzyj się liście zagadnień, które musiałbyś ogarnąć, aby stworzyć naprawdę skuteczny program typu ransomware i zastanów się, czy naprawdę warto uczyć się tylu różnych zagadnień, aby być w stanie zrobić to dobrze i zminimalizować ryzyko złapania:

1. Język programowania i kompilacja
  1. Jaki język? Zwykłe C, czy coś wyższego poziomu? Radzisz sobie z obsługą pamięci i stosu w C, czy potrzebujesz do tego celu jakichś bibliotek wspomagających? Jakich bibliotek CRT chcesz użyć i dlaczego?
  2. Co jeśli w docelowym systemie nie ma zainstalowanych odpowiednich bibliotek DLL? Jak zamierzasz sprowokować ich instalację?
  3. Jaki kompilator? Czy wiesz, jakie metadane nt. systemu, czy swojej własnej licencji, osadza on w plikach wynikowych?
2. Wybór algorytmów i generowanie kluczy szyfrujących
  1. Szyfrowanie symetryczne czy asymetryczne? Rozumiesz różnice? A może szyfrowanie symetryczne plików kluczem komputera szyfrowanym asymetrycznie?
  2. W którym momencie i w którym miejscu chcesz generować klucze? Na obrabianym właśnie komputerze, czy na serwerze i potem pobierać je na komputer?

    Przy szyfrowaniu asymetrycznym, parę kluczy można wygenerować w innym miejscu i pobrać na komputer sam tylko klucz szyfrujący. W ten sposób klucz deszyfrujący w żadnym momencie nie znajduje się na komputerze ofiary, a więc nie jest możliwe jego odzyskanie, niezależnie od kwalifikacji firmy odzyskującej dane.

    W praktyce jednak szyfrowanie asymetryczne ma relatywnie słabą wydajność i z reguły stosuje się inną strategię, polegającą na tym, że generuje się unikalny "klucz sesji" (w tym przypadku klucz komputera, albo wręcz osobne klucze dla pojedynczych plików), którym szyfruje się dane symetrycznie, jednocześnie sam symetryczny klucz sesji szyfruje się asymetrycznie i usuwa z komputera jego postać jawną.

    Szyfrowanie asymetryczne jest bardzo trudne do poprawnej implementacji. Jego samodzielna implementacja od podstaw bardzo często prowadzi do błędów ułatwiających ataki na klucz, albo wprost do możliwości odszyfrowania danych bez płacenia – lub odwrotnie, do całkowitej niemożliwości odszyfrowania danych w pewnych przypadkach. Dlatego też nie należy samodzielnie implementować algorytmów asymetrycznych, ale korzystać ze znanych i dobrze przetestowanych bibliotek.

  3. Jak chcesz te klucze przekazywać, aby nie ryzykować ujawnienia swojej tożsamości, ale umożliwić klientom odszyfrowanie danych po zapłacie?
  4. Kiedy i o jakich zdarzeniach (np. pobranie klucza, rozpoczęcie i zakończenie procesu szyfrowania, raport nt. znalezionych danych itp.) program szyfrujący powinien informować autora? Jak to pogodzić z generowaniem lub pobieraniem klucza?
  5. Ofiara często przed wysłaniem pieniędzy żąda dowodu - "wyślij zaszyfrowany plik a dostaniesz rozszyfrowaną wersję" jest funkcją must-have w dzisiejszych szyfratorach (w każdym razie tych, które rzeczywiście zarabiają). Jak ją wmontować we flow obsługi kluczy i zdarzeń, aby zminimalizować ryzyko dekonspiracji (aby autor nie musiał każdorazowo pobierać odpowiedniego klucza deszyfrującego z serwera sterującego)?
3. Enumeracja zasobów, ostrożne działanie i szyfrowanie właściwe
  1. Wykrywanie uprawnień administratora komputera i administratora domeny (również uprawnień efektywnych, tj. nadanych niekoniecznie wprost przez dodanie do odpowiedniej grupy), różnicowanie zachowania programu w zależności od posiadanych uprawnień.
  2. Wykrywanie wersji systemu i ustawień UAC, próby elewacji uprawnień w systemach, w których nie spowoduje to wyświetlenia ostrzeżenia dla użytkownika.
  3. Enumeracja lokalnych plików z prawami do zapisu.
  4. Enumeracja zdalnych zasobów, unikanie wyświetlania pytań o hasło (np. w środowiskach nie-AD, typu Samba + pojedyncze komputery).
  5. Radzenie sobie z plikami otwartymi i zablokowanymi przez inne procesy (np. sqlservr.exe i pliki mdf/ldf).
  6. Strategie szyfrowania: szyfrowanie wszystkiego "na bok" w pierwszym kroku, szybkie kasowanie oryginalnych plików i podmiana w drugim kroku – albo podejście "naiwne", tj. sekwencyjne szyfrowanie po kolei.
  7. Efektywność czasowa – maksymalizacja strat, nawet jeśli użytkownik szybko zauważy infekcję, poprzez wykrywanie najbardziej istotnych typów danych i rozpoczynanie od nich.
  8. Szyfrowanie tylko fragmentów dużych plików – jak potem składować takie fragmenty plików na potrzeby odszyfrowania? Obsługa wyjątków (np. progresywnych formatów zdjęć), aby nie można było ich odbudować.
  9. Różnicowanie strategii szyfrowania w zależności od mocy obliczeniowej komputera, ilości miejsca na dysku i ilości danych do zaszyfrowania.
  10. Usuwanie backupów lokalnych (VSS, Windows Backup, Cobian i inne popularne schematy backupów).
4. Skuteczne ukrywanie się do czasu zakończenia działań
  1. Używanie mechanizmów typu svchost.exe, rundll32.exe i innych do ukrywania procesów.
  2. Unikanie debuggerów, udawanie pożytecznego programu w przypadku wykrycia debuggera, używanie pakerów i krypterów do programów wykonywalnych. Automatyzacja budowy plików binarnych i skanowania przez narzędzia typu VirusTotal (przy czym samego VirusTotal używać nie należy, gdyż wysyła on próbki producentom antywirusów).
  3. Używanie obecnych w obiegu exploitów pozwalających na elewację uprawnień, ukrywanie takich narzędzi.
  4. Infekcja wielowarstwowa – używanie kilku lub kilkunastu warstw dropperów, tj. programów, których głównym zadaniem jest ukryte ściągnięcie i uruchomienie kolejnej warstwy. Rozbijanie logiki wykrywania poszczególnych zabezpieczeń na różne warstwy.
  5. Wykrywanie oprogramowania DLP, różnicowanie zachowania programu w przypadku działania w takim środowisku.

    Szukasz rozwiązania do wykrywania i omijania systemów DLP? Nasze rozwiązanie wykrywa systemy Safetica, ObserveIT, DeviceLock i McAfee. Implementacja dla dowolnego języka. Szczegóły techniczne dostępne po podpisaniu NDA. Zadzwoń do nas, aby dowiedzieć się więcej.

  6. Wykrywanie oprogramowania antywirusowego, w tym oprogramowania typu "Internet Security", próby obchodzenia lub wyłączania go w zależności od posiadanych uprawnień, próby możliwie najbardziej efektywnego działania w środowisku z takim programem (np. maksymalizacja strat dla ofiary, zanim dojdzie do zablokowania działania przez taki program).
  7. Blokowanie możliwości ściągnięcia nowych baz wirusów programom antywirusowym.
  8. Unikanie wykrycia podejrzanego ruchu przez korporacyjne systemy analizy ruchu sieciowego, podszywanie się pod programy antywirusowe i ich próby aktualizacji baz z "nowego serwera" (tj. celem jest połączenie prób komunikacji do serwera sterującego z uruchomionym procesem programu antywirusowego, aby systemy analizy ruchu "nauczyły się" tego połączenia jako dopuszczalnego).
  9. Przerzucanie różnych "szkodliwych" działań programu na programy systemowe, które da się oskryptować (np. dodanie reguł do Windows Firewalla, dodanie certyfikatu własnego CA przez certutil.exe itp.).
5. Skalowanie kampanii
  1. Rozróżnianie sieci korporacyjnych od kablówek lub innych luźno powiązanych grup użytkowników.
  2. Koordynacja czasowa działań na wielu komputerach lub sieciach.
  3. Rozpraszanie komunikacji z serwerem sterującym na kilka różnych adresów. Możliwość zdalnej podmiany adresów IP w przyszłości.
  4. Integracja flow kampanii z możliwością ręcznego przeglądania zawartości wybranych komputerów przez autora.
6. Dystrybucja manualna
  1. Jak rozpocząć dystrybucję ręcznie, aby nie zostać przyłapanym: gdzie (kafejki internetowe to dzisiaj rzadkość), kamery w tych miejscach, kamery po drodze (i w drodze powrotnej) i inne aspekty OPSEC. Pamiętaj, że w praktyce sprawcy są identyfikowani najczęściej nie po obrazie z "miejsca zdarzenia", ale po skorelowanych ręcznie obrazach z drogi do/z tego miejsca.
  2. Szukanie dogodnych miejsc – odpowiednio wcześniej, wiarygodna historia na wypadek "small talków" z pracownikami takiego miejsca (opowiadane szczegóły związane z emocjami i uczuciami zapadają w pamięć bardziej niż szczegóły czysto komercyjne, np. spóźnienie do klienta), inne elementy OPSEC.
  3. Inne metody – np. podkładanie pen drive’ów. Tutaj również musisz pamiętać o OPSEC, w szczególności pod kątem kamer, śladów biologicznych na urządzeniu, oraz śladów metadanych z komputera, na którym preparowany jest pen drive.
7. Dystrybucja przez złośliwe maile
  1. Tworzenie kampanii – przygotowanie wiarygodnie wyglądającej treści, w tym oprawy graficznej
  2. Wersja dla programów pocztowych z wyłączonym pobieraniem obrazków z linków zewnętrznych (standard od 15 lat), osadzanie grafik w mailu przez CID
  3. Odpowiedni research w przypadku kampanii zagranicznych: znajomość lokalnych firm (np. banków, operatorów telefonii komórkowej itp.), dobre wykonanie tłumaczenia, dobry dobór materiałów graficznych.
  4. Skąd takie maile wysyłać? Jako spam z wynajętych botnetów (relatywnie niska dostarczalność, z drugiej strony naturalna bariera przed dostarczeniem na systemy o bardzo wysokim poziomie bezpieczeństwa, gdzie rośnie ryzyko szybkiego wykrycia)? Z czyichś serwerów? Z usług typu Freshmail? Jak najbezpieczniej wejść w posiadanie takich serwerów lub usług?
  5. Z jakich domen te maile wysyłać (w dobie coraz powszechniejszych zabezpieczeń typu np. SPF)? Jak te domeny bezpiecznie kupić? U "zwykłych" rejestratorów, czy "bulletproof"?
  6. Jak zorganizować pieniądze na zakup takich domen i/lub serwerów, aby nie dało się ich wyśledzić? Bitcoin lub inne kryptowaluty? Western Union i transfer przez inny kraj? Kto ma w tym pomóc, ile musi wiedzieć (+wiarygodna oficjalna historia) i jak go bezpiecznie wtajemniczyć? Przelewy od słupów w ramach integracji z inną prowadzoną działalnością?
8. Zarządzanie kampanią i pozyskiwanie interesujących danych z wybranych komputerów
  1. Panel webowy – jaki język programowania? Jak dobrze sobie radzisz w tym języku? Używasz konkretnych bibliotek albo narzędzi? Jak implementujesz połączenie z bazą danych, wykonywanie zapytań i wyświetlanie wyników?
  2. Stylometria – poczytaj więcej o tej technice ustalania potencjalnego autora kodu na podstawie stylu tego kodu. Czy jesteś autorem jakiegoś kodu open source? A może odpowiadałeś komuś na forum typu StackOverflow podając przykłady kodu?
  3. Jak zbierać dane? Trzymanie na serwerze pełnej historii danych to po pierwsze możliwość przejęcia jej w całości przez organy ścigania lub konkurencję, po drugie możliwość utraty jej w całości wskutek awarii sprzętu, o ile nie masz backupu danych (i jak taki backup zorganizować? Jakimi narzędziami, w jakich porach, unikając konwencji konfiguracyjnych typowych dla "dziennej pracy" itp.). Wreszcie po trzecie, składowanie takiej bazy na serwerze online wymaga przestrzeni dyskowej, która prawie na pewno będzie dużo droższa od przestrzeni lokalnej.
  4. Skąd taki panel hostować, aby był w miarę niezawodny? Powinien być połączony z endpointami do raportowania zdarzeń z komputerów? A może wprost przeciwnie, powinien być w całkiem innym miejscu (ale jak wtedy wymieniać dane pomiędzy serwerem sterującym a panelem)? Czy powinien być ukrytą usługą, dostępną tylko w sieci Tor? Co z niezawodnością i sytuacjami, gdy panel nie działa?
  5. Strategia tworzenia i nazywania użytkowników panelu, oraz przydzielania im uprawnień: kwestie powtarzalności loginów w innych usługach, kwestie zaufania do innych osób, po co w ogóle chcesz i czy na pewno musisz brać do pomocy inne osoby?
  6. Potrzebujesz aktywnej łączności z poszczególnymi komputerami, czy wystarczą ci pasywne informacje o zdarzeniach (2d) na tych komputerach? Na ile istotna jest dla ciebie możliwość szybkiego podglądu wybranych komputerów i zdalnego skopiowania ich zawartości? Gdzie te dane miałyby być kopiowane: na serwer sterujący, czy podany ad hoc inny serwer (7d, 7f)? Co z ograniczeniami prędkości łącza, łączami z płatnym transferem danych, czy wreszcie brakiem publicznego IP?
9. Informacja dla użytkownika o infekcji
  1. Stylometria – to pojęcie dotyczy nie tylko kodu źródłowego, ale także dowolnego innego tekstu, dla którego dostępne są materiały porównawcze. Jesteś autorem jakichś tekstów w Internecie? Albo planujesz być w przyszłości? A może twoje prace na studiach były sprawdzane programem Plagiat? Narzędzia do analizy stylometrycznej mogą wyłapać różne niuanse stylu pisania pomiędzy informacją z żądaniem okupu, a innymi tekstami twojego autorstwa.
  2. Zastanów się, czy użycie Google Translate to na pewno dobry pomysł. Jeśli tworzysz żądanie okupu dla konkretnego kraju, to pamiętaj że przeciętny poziom znajomości języka angielskiego dla populacji krajów, w których ofiary mają z czego płacić okup, wynosi 60% lub więcej. Oznacza to, że jeśli nie celujesz w jakąś konkretną niszę, żądanie napisane łamanym angielskim w zupełności wystarczy. Pozostałe kraje można pominąć – i tak ich mieszkańcy przeciętnie nie mają z czego zapłacić.
  3. Przyjrzyj się różnym przykładowym żądaniom od istniejącego oprogramowania tego typu. Istnieje korelacja pomiędzy efektownością graficzną komunikatu z żądaniem, a jego pokazywaniem w mediach (zobacz przykład WannaCrypt) – przy czym oczywiście jest to korelacja wtórna, bowiem pierwotna to oczywiście efektywność działania. Pamiętaj jednak, że za efektownością idzie charakterystyczność. Dzisiaj nie ma znanych rozwiązań do analizy stylometrycznej komunikatów graficznych, niewykluczone jednak, że takie rozwiązania powstaną w przyszłości – i to potencjalnie szybszej, niż data przedawnienia karalności twojego czynu.
10. Przyjmowanie płatności, deszyfrowanie i obsługa "klienta"
  1. Opanuj kryptowaluty – całościowo, tj. samodzielne kopanie (na potrzeby ew. alibi), współpraca z większymi kopalniami, współpraca z mixerami (pralniami), tworzenie i zarządzanie walletami, obustronna wymiana kryptowalut na realne pieniądze, bezpieczne wypłacanie tych pieniędzy itd.
  2. Potrzebujesz przemyślanego flow do przyjmowania wpłat (najlepiej na wiele walletów), prania ich, konwertowania na lokalną walutę i bezpiecznego wypłacania. Flow, w którym wszystko po drodze musi być zarejestrowane przez sieć Tor.
  3. No właśnie, a czy ten artykuł czytasz przez Tora? Pamiętaj, że każdy taki artykuł, przykład kodu na Githubie, wizyta na giełdzie kryptowalut, czy generalnie każda inna twoja aktywność może potencjalnie być śledzona – a już na pewno zostawia ślady w logach serwerów, o które to logi może w przyszłości poprosić jakaś służba. Więc jeśli nie czytasz tego tekstu przez Tora, zastanów się bardzo dokładnie, czy chcesz ten temat kontynuować :)
  4. Dekryptor – czyli kolejny program do napisania, a wraz z nim kolejne ryzyka j/w. Przemyśl, jak taki dekryptor powinien działać. I nie osadzaj w nim klucza deszyfrującego – zrób jedną wersję programu, która będzie wczytywać klucz deszyfrujący z zewnętrznego pliku. W ten sposób nie tylko radykalnie zmniejszysz sobie ilość pracy, ale też unikniesz pomyłek, np. przy kompilacji różnych wersji. Pomyśl też, jak ten program rozpowszechnić – bo raczej nie chcesz go udostępniać z serwera sterującego...


Wirus zaszyfrował Twoje pliki? Nie płać okupu, zgłoś się do nas! Możemy spróbować odzyskać Twoje dane już od 720 zł netto.


Podsumowanie

Według Badania społeczności IT 2018 zrealizowanego przez Bulldogjob, 23% osób pracujących w IT zarabia miesięcznie na rękę 9000 zł lub więcej, z mocną tendencją wzrostową w ramach tej grupy.

Jednocześnie, skuteczne ogarnięcie wszystkich w/w zagadnień dot. ransomware, które jest niezbędnym minimum do tego, aby nowy program tego typu "odniósł sukces", a jego autor nie został szybko złapany, jest osiągnięciem w zasięgu 10-15%, hipotetycznie może 20% osób z branży.

Zestawiając to z przytoczonymi na początku artykułu statystykami Bitdefender (średnie zarobki 29 tysięcy dolarów rocznie, za średnio 700 poświęconych godzin, przypuszczalnie na sam tylko rozwój programu i "obsługę" kampanii) - czyli ok. 26000 zł na rękę w skali miesiąca – kwota ta wydaje się być szokująco duża, ale głównie dla osób, które pracują poza branżą IT.

W przypadku zaś osób, które w pełni legalnie, na wygodnym etacie, zarabiają 9..12..15..20 tysięcy zł, zarobek 26 tysięcy zł kosztem bycia osobą ściganą przez najlepszych fachowców na świecie (a nie przez lokalny pion kryminalny miejscowego komisariatu) nie jest wart ryzyka. Tym bardziej, że kwota taka w żadnym wypadku nie wystarczy do tego, aby w ciągu kilku miesięcy, czy nawet lat, zebrać sumę pozwalającą na rozpoczęcie wygodnego życia pod nową tożsamością.

Jeśli więc czytasz ten artykuł i zastanawiasz się nad własnym ransomware, spójrz na powyższe liczby i przemyśl sprawę bardzo dokładnie, zanim na własne życzenie zburzysz sobie całe dotychczasowe życie.


Intencją autora ani wydawcy artykułu nie jest namawianie bądź zachęcanie do łamania prawa. Jeśli popełniłeś lub masz zamiast popełnić przestępstwo, bądź masz wątpliwości, czy Twoje działania nie będą łamać prawa, powinieneś skonsultować się z najbliższą jednostką Policji lub Prokuratury, a jeśli są one związane z pieniędzmi, dla pewności również z Urzędem Skarbowym.



Tomasz Klim
Administrator serwerów i baz danych, specjalista w zakresie bezpieczeństwa, architekt IT, przedsiębiorca. Ponad 20 lat w branży IT. Pracował dla największych i najbardziej wymagających firm, jak Grupa Allegro czy Wikia. Obecnie zajmuje się bezpieczeństwem projektów blockchainowych w Espeo Software. Chętnie podejmuje się ciekawych zleceń.


Wzbudziliśmy Twoje zainteresowanie?

Szukasz pomocy? formularz kontaktowy