728 x 90

Ransomware od podstaw – część 8, zarządzanie kampanią i jej owocami

Ransomware od podstaw – część 8, zarządzanie kampanią i jej owocami

Dzisiaj rozwiniemy nieco wątki z części piątej, dotyczące panelu webowego. Właściwy program szyfrujący to bowiem dopiero połowa sukcesu. Na drugą połowę składa się m.in. właśnie panel umożliwiający efektywną obsługę „klienta”.

O panelu tym zaczęliśmy pisać w części piątej, gdzie wspomnieliśmy o niezbędnych mechanizmach od strony funkcjonalnej. Dzisiaj skupimy się na tym, jak taki panel zrealizować od strony stricte technicznej, zaś w części dziesiątej wrócimy do tematu raz jeszcze, aby opisać konkretne flowy związane z obsługą „klienta”, czyli wyceną okupu, indywidualnymi negocjacjami, przyjęciem płatności i przekazaniem dekryptora.

Zasady naczelne

Zanim przejdziesz do myślenia o którymś ze szczegółowych aspektów panelu, zapamiętaj dwie zasady naczelne, którymi powinieneś się kierować projektując taki panel:

1. Minimalizm

Zarówno w ilości zbieranych danych (nie zapominaj, że Twoim celem są pieniądze, a nie „trofea” związane z poszczególnymi „klientami”), jak i w formie – np.:

  • zwykłe, proste, „surowe” zapytania GET są dużo lepsze od „ładnego” REST API
  • zwykłe zapytania SQL są dużo lepsze od narzędzi ORM – a jeszcze lepsze jest zastosowanie zwykłych plików CSV lub tekstowych zamiast jakiejkolwiek bazy danych

2. Nie rób niczego tak, jak byś to zrobił w „dziennej” pracy.

Przede wszystkim dotyczy to stosowania narzędzi, technik i standardów wspomagających pracę zespołową nad dużymi projektami, np.:

  • testy jednostkowe
  • wzorce projektowe
  • frameworki, serwery aplikacji, biblioteki ORM i inne mechanizmy typowe dla danego języka
  • standardy formatowania i komentowania kodu
  • nazewnictwo plików, katalogów, zmiennych czy czegokolwiek innego

To oczywiście nie oznacza, że musisz na siłę tworzyć źle wyglądający kod – natomiast zdecydowanie trzymaj się domyślnego sposobu formatowania kodu narzuconego przez jakiś edytor lub IDE. Najlepiej też aby edytor ten, jak i jego domyślny sposób formatowania kodu, były:

  • inne od tych, których używasz w „dziennej” pracy
  • w miarę popularne (nie używaj zbyt niszowych narzędzi)
  • łatwe do uruchomienia, bez konieczności instalacji dodatkowych pluginów, słowników, czy innych dodatków – względnie dostępna jest wersja już wyposażona w komplet potrzebnych dodatków

Implementacja panelu

  • Jaki język programowania?
  • Jak dobrze sobie radzisz w tym języku?
  • Czy w ramach dotychczasowego doświadczenia w tym języku używasz jakichś konkretnych bibliotek, frameworków lub innych narzędzi? A jak sobie radzisz bez ich użycia?
  • Jak implementujesz połączenie z bazą danych, wykonywanie zapytań i wyświetlanie wyników? (nie chodzi o kwestie bezpieczeństwa, a o sposób implementowania charakterystycznych elementów – np. iterujesz po wyniku za pomocą funkcji mysql, czy mapując wynik na obiekt i działając na obiekcie?)

Stylometria

Poczytaj więcej o tej technice ustalania potencjalnego autora kodu na podstawie stylu tego kodu (albo tekstu).

  • Czy jesteś autorem jakiegoś kodu open source?
  • Odpowiadałeś komuś na forum typu StackOverflow, podając przykłady kodu?
  • A może Twój kod napisany dla jakiejś firmy „wyciekł” i jest/był nielegalnie dostępny w Internecie?
  • A co z projektami uczelnianymi? Mogły zostać wrzucone do systemów antyplagiatowych również po ukończeniu przez Ciebie studiów.

Jak zbierać dane?

Trzymanie na serwerze pełnej historii danych:

  • to możliwość przejęcia jej w całości przez organy ścigania lub konkurencję
  • to możliwość utraty jej w całości wskutek awarii sprzętu, o ile nie masz backupu danych (i jak taki backup zorganizować, aby niechcący się nie zdeanonimizować: do jakich miejsc, jakimi narzędziami, w jakich porach, unikając konwencji konfiguracyjnych typowych dla „dziennej pracy” itp.)
  • wymaga przestrzeni dyskowej, która prawie na pewno będzie dużo droższa od przestrzeni lokalnej, niezależnie od tego, na jakich zasadach rozliczasz się za hosting

Skąd go 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? scp czy raczej https?
    • Jak podzielić dane na części, aby nie utrudniało to pracy, a jednocześnie aby nie pchać w kółko wielkich plików z tymi samymi danymi?
    • Która strona transmisji powinna być widoczna (publiczne IP lub przekierowanie portu)?
    • Która strona transmisji powinna posiadać klucz pozwalający na nawiązanie łączności?
  • Czy powinien być ukrytą usługą, dostępną tylko w sieci Tor?
  • Co z niezawodnością i sytuacjami, gdy panel nie działa? A co gdy nie działają endpointy do raportowania zdarzeń? Potrzebujesz jakiegoś mechanizmu „spróbuj ponownie” po stronie programu szyfrującego, czy wolisz po prostu zostawić takie przypadki samym sobie?
    • HA w większości przypadków nie rozwiązuje problemu, bo co jeśli problem z łącznością jest po stronie szyfrowanego komputera, a nie po stronie serwera?

Kolejne osoby do pomocy w „biznesie”

  • Po co w ogóle chcesz i czy na pewno musisz brać do pomocy inne osoby? Ogólna zasada w kryminalistyce jest taka, że w grupie 2-osobowej ryzyko wpadki wzrasta o 50% z samego tylko powodu współpracy 2 osób, w grupie 3-osobowej o 75% itd.
  • Jak chcesz zarządzać uprawnieniami do poszczególnych funkcji w panelu? Zwykłe http auth i potem operowanie na zmiennej z nazwą zalogowanego użytkownika? Czy może jakaś forma operowania na rolach/grupach dostępowych? (pamiętaj o zasadach naczelnych!)
  • Na jakim etapie znajomości/współpracy/zaufania chcesz tworzyć nowych użytkowników?
  • Jak chcesz weryfikować, czy nie są to podstawione osoby? Albo inaczej: jak chcesz minimalizować swoje straty, jeśli taka osoba okaże się być np. funkcjonariuszem policji?
  • Czy chcesz implementować w panelu mechanizmy typu honeypot, weryfikujące uczciwość takich użytkowników wobec Ciebie i np. automatycznie blokujące im uprawnienia w przypadku zarejestrowania niepożądanych aktywności?
  • Co z nazewnictwem kont? Zdajesz sobie sprawę, że szukanie powiązań pomiędzy nazwami użytkowników (w tym pomiędzy różnymi stronami) to jedna z podstawowych metod śledczych w IT?
  • Jak ci użytkownicy mogą sobie bezpiecznie (aby tylko oni je znali) zmieniać hasła? Czy też potrzebują do tego Twojej pomocy?

Kopiowanie danych z szyfrowanych komputerów

  • Potrzebujesz aktywnej łączności z poszczególnymi komputerami, czy wystarczą ci pasywne informacje o zdarzeniach na tych komputerach? Pamiętasz o tym, co pisaliśmy w części piątej? Jeśli mimo wszystko potrzebujesz więcej danych, to w jakim celu?
  • Na ile istotna jest dla ciebie możliwość szybkiego podglądu wybranych komputerów i zdalnego skopiowania ich zawartości? Chcesz tą zawartość kopiować przed czy po zaszyfrowaniu (masz klucz, więc sobie rozszyfrujesz)? Przed czy po pokazaniu użytkownikowi komunikatu o infekcji?
  • Gdzie te dane miałyby być kopiowane: na serwer sterujący, czy podany ad hoc inny serwer?
  • Co z ograniczeniami prędkości łącza, łączami z płatnym transferem danych, czy wreszcie brakiem publicznego IP?
  • Jakiego protokołu chciałbyś użyć? Czy wymaga on przekazania na komputer ofiary klucza pozwalającego na zdalny dostęp do Twojego serwera? Co jeśli z jakichś losowych przyczyn utracisz dostęp do tego komputera, zanim zdążysz trwale usunąć ten klucz?

W kolejnej części – informowanie użytkownika o infekcji.


Intencją autorów ani wydawcy treści prezentowanych w magazynie PAYLOAD nie jest namawianie bądź zachęcanie do łamania prawa. Jeśli popełniłeś lub masz zamiar 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.

Nie zezwala się na użycie treści prezentowanych w magazynie PAYLOAD, ani produktów dostępnych w sklepie PAYLOAD, do celów popełniania przestępstw lub przestępstw skarbowych.