Edukacyjny ransomware to binarny lub źródłowy kod, który jest publikowany, żeby wskazać potencjalne zagrożenia, zapobiec infekcjom, zmniejszyć potencjalne szkody, poprawić bezpieczeństwo produktów oraz nauczyć użytkowników określonych zachowań.
SPECJALIŚCI WYRÓŻNIAJĄ CZTERY RODZAJE EDUKACYJNEGO RANSOMWARE.
-
SYMULATORY RANSOMWARE
Są to niezłośliwe pliki binarne, które symulują zachowania ransomware, pokazując zapisy lub zrzuty ekranowe, ale nie powodują żadnych trwałych uszkodzeń. To świetny sposób, by zademonstrować skutki ataku. Służą również do szkolenia na temat zapobiegania infekcjom, a także poprawiania technik związanych z analizą i wykrywaniem zagrożeń. W tym ostatnim przypadku, można również wykorzystać symulator szyfrowania plików w systemie.
Przykładem tego rodzaju symulatorów jest ShinoLocker stworzony przez Shota Shinogi, który był pokazywany na Blackhat 2016. ShinoLocker jest przeznaczony do szkolenia umiejętności w zakresie kryminalistyki. Studenci mogą uruchomić symulator i starają się odzyskać klucz deszyfrujący z pamięci.
ShinoLocker pozwala dostosować finalny plik binarny, włącznie z serwerem służącym do pobrania klucza szyfrującego, rozszerzeniem plików do zaszyfrowania oraz polem „“Command & Parameter”. Powstały binarny ransomware wykona wpisaną komendę i w ten sposób otwiera się możliwości do nadużyć. Oznacza to, że narzędzie może być wykorzystywane do tworzenia rzeczywistego, w pełni funkcjonalnego ransomware, o czym wspomniał serwis Bleepingcomputer należący do Lawrenca Abramsa.
Niemniej, aby zminimalizować ryzyko niewłaściwego wykorzystania narzędzia, należy podjąć odpowiednie środki bezpieczeństwa. Dlatego twórcy symulatorów powinni ograniczyć szyfrowanie plików do określonego folderu i nie udostępniać pewnych konfiguracji, zwłaszcza tych, które będą wykonywać dowolne polecenie. To utrudni zadanie osobom próbujących wykorzystać symulatory do niecnych celów.
-
CZĘŚCIOWO FUNKCJONALNY RANSOMWARE OPEN SOURCE
To kod źródłowy ransomware, który jednak nie może być wykorzystany jako w pełni funkcjonalny, ponieważ został pozbawiony pewnych integralnych części zapewniających działanie. Ten źródłowy kod może być opublikowany przez badaczy bezpieczeństwa jako proof of concept dla nowej lub nieznanej wcześniej techniki. Takie rozwiązanie pozwala lepiej kształcić specjalistów od ochrony zasobów cyfrowych, a także poprawić jakość produktów bezpieczeństwa.
Do tej kategorii, dopóki nie został rozszyfrowany, należał Linux ransomware CrytpoTrooper opracowany przez Maksyma Zajcewa. Autor powiedział Softpedii, że algorytm szyfrowania został złamany celowo. Obecnie CrytpoTrooper znajduje się on na platformie Github wraz z plikiem README.md.
Oczywiście brak części kodu sprawia, że narzędzie nie może być wykorzystywane do ataków przez osoby bez odpowiedniej wiedzy, chcące tworzyć ransomware na własną rękę. Niemniej bardziej zaawansowani twórcy szkodliwego oprogramowania mogą wykorzystać upublicznione techniki dla własnych celów. Nigdy nie ma pewności, że kody źródłowe nie trafią w ręce osób niepowołanych i nie będą dalej rozwijane. Proof of concept może zwiększyć presję na osobach odpowiedzialnych za tworzenie zabezpieczeń, a tym samym złagodzić szkodliwość samego ransomware.
-
W PEŁNI FUNKCJONALNY OPEN SOURCE RANSOMWARE
Kod źródłowy może być skompilowany do pełnowartościowego funkcjonalnego szkodnika, co rodzi wiele sporów dotyczących tego rodzaju edukacyjnego ransomware. Do tej kategorii należą projekty Hidden Tear i EDA2 autorstwa Utku Sen. Przedmiotem najnowszych dyskusji są także shc Ransomware i CryptoWire. Przeciwnicy tego typu projektów uważają, iż kody źródłowe stanowią podstawę do tworzenia złośliwego oprogramowania w rzeczywistym środowisku. Niemniej przyjrzyjmy się argumentom wysuwanym przez zwolenników tego rozwiązania.
Jeśli student chce uzyskać głębszy wgląd w zasady funkcjonowania ransomware, może zapoznać się z kilkoma dostępnymi analizami. Sposoby i techniki mające na celu maksymalizację wpływu szkodliwego oprogramowania są na tyle interesujące, żeby je obserwować przez cały czas. Niemniej osoba próbująca zrozumieć zasady działania operacji kryptograficznych ma do dyspozycji dobrze napisane podręczniki. Z kodem źródłowym można się zapoznać w bibliotece NaCl. W każdym bądź razie wymienione techniki szyfrowania mogą być przedstawiane bez publikowania ich w postaci w pełni działającego ransomware. Nie ma powodu, żeby przekazywać na tacy kod źródłowy ransomware laikom.
„Publikowanie luk nie jest złem. Hidden Tear nie został wykryty przez program antywirusowy, w dniu, kiedy go zakodowałem. Ale potem został wykryty. Luka załatana. Praca została wykonana.” – (Utku Sen)
„Script kiddies będą miały dzień polowania, ale … będą używać wykrywalnych wersji.” ( @himayyay on Twitter)
W obu oświadczeniach pojawia się podobny ton – projekty poprawiają skuteczności aplikacji bezpieczeństwa i zapobiegają infekcjom w przyszłości. Jednak rzeczywistość pokazuje, że niewykryte próbki szkodliwego oprogramowania Hidden Tear i EDA2 cały czas są rozprzestrzeniane. Wprawdzie zwykła wersja Hidden Tear jest wykrywana przez oprogramowanie antywirusowe, ale twórcy malware wykorzystują kryptery, usługi szyfrujące lub obfuskację. Są to powszechne i dostępne techniki, które pozwalają znacznie zmniejszyć skuteczność wykrywania szkodliwego oprogramowania. Takie projekty jak Hidden Tear nie są trudne do wykrycia, sprawia to zaciemnianie kodu.
Jeśli realnym celem jest poprawa bezpieczeństwa produktów, lepiej wybrać odpowiedzialny sposób ujawniania luk i przesłać próbkę z klarownym opisem i datą wykrycia, a następnie wyznaczyć rozsądny przedział czasowy przeznaczony na odpowiedź producenta. Natomiast informację o występujących nieprawidłowościach upublicznić po naprawie i ich załataniu. Wprawdzie istnieją przypadki, kiedy polityka ujawniania luk bezpieczeństwa znajduje uzasadnienie etyczne, ale na pewno nie dotyczy to ransomware.
„Celem moich działań jest zmniejszenie ryzyka związanego z działaniami script kiddies. Potrafię unieszkodliwić większość próbek, jeśli tylko dostawcy antywirusów poproszą mnie o pomoc”. (Utku Sen w odpowiedzi na artykuł Eduarda Kovacsa)
„Myślę, że nie rozumiecie sedna działania ransomware. On nie uszkadza systemu ani go nie infekuje. To po prostu szyfrowanie plików.” (Sic!, Utku Sen)
Utku Sen opublikował na blogu artykuł wskazując na występowanie celowych wad w Hidden Tear, co ułatwia łamanie szyfrów. Autor uważa, że ransomware występujący w środowisku naturalnym jest osłabiony, bowiem cyberprzestępcy korzystają z wadliwego kodu zamiast stron oferujących ransomware-as-a-service. Wady pozwoliły stworzyć darmowe narzędzie Hidden Tear Decrypter autorstwa Michaela Gillespie do deszyfrowania plików. Niemniej ten argument nie uwzględnia wszystkich poszkodowanych. Nie wszyscy są na tyle sprytni, żeby znaleźć to rozwiązanie. Poza tym ofiary ataku niekoniecznie właściwie zidentyfikują rodzaj ransomware. To nie jest też dobre uzasadnienie dla osób, które tracą czas i pieniądze na odszyfrowanie plików. W zależności od wagi ataku mogą potrzebować kilku dni, a w drastycznych przypadkach nawet miesięcy, aby w pełni odzyskać swoje cyfrowe zasoby.
Ransomware niesie ze sobą straty, pomimo tego, że nie niszcz bezpo- wrotnie plików. Przestój zawsze oznacza utratę zysku, również gdy ofiara posiada opracowaną strategię backupu. Również ułatwianie zadania cyberprzestępcom nie jest dobrym rozwiązaniem. Wiadomo, że łatwiej wykorzystać istniejący algorytm szyfrowania niż pracować nad własnym. To w pewnym stopniu zachęcania wroga do działania. To nie fikcja. W sieci pojawiły się „dzikie wersje” EDA2, których nie można odszyfrować.
-
CLOSED SOURCE PROOF-OF-CONCEPT
Niektórzy badacze opracowali ransomware, nie upubliczniając jego kodu źródłowego. To przydatne rozwiązanie wykazujące występowanie ataków na dotychczas pomijane przez hakerów platformy.
Jednym z takich przykładów jest Mac OS ransomware Mabouia. Jego autor Rafael Salema Marques nagrał wideo, na którym pokazuje atak ransomware na system IOS. Marques ujawnił kod jedynie producentom AV.
Nowe pomysły i koncepcje mogą być współdzielone, np. ransomware napisany jako MS Office makro, co pokazuje poniższy rysunek.
Proof-of-Concept z zamkniętym źródłem wydają się być bezpiecznym sposobem na opublikowanie pomysłów, choć nie może być stosowany w każdym przypadku. I staramy się być bardzo ostrożni.
Z jednej strony, jesteśmy ludźmi technicznymi, którzy od czasu do czasu lubią fajne sztuczki. Z drugiej strony dbamy o naszych klientów. Nie jest łatwo przeciwdziałać nowym zjawiskom czy wektorom ataków, niemniej wkładamy dużo trudu, aby robić to skutecznie.
NIEODPOWIEDZIALNE UJAWNIANIE KODU JEST NIEBEZPIECZNE
Chociaż ujawnianie pełnych informacji ma długą historię w InfoSec, to z pełną odpowiedzialnością twierdzimy, że ransomware nie jest do tego odpowiednim obszarem. Badacze bezpieczeństwa powinni dokładnie ważyć argumenty za i przeciw, zanim zdecydują się na publikację ransomware do celów edukacyjnych.
Szczególnie groźny jest w pełni funkcjonalny ransomware open source, taki jak np. Hidden Tear. Wady tej metody są łatwo dostrzegalne i przewyższają potencjalne (lub wyimaginowane) zyski. Lepsze efekty można osiągnąć poprzez publikację jedynie części kodu źródłowego lub dostarczając go wyłącznie osobom bezpośrednio odpowiedzialnych za usunięcie luk itp.
Argumenty przemawiające za open source ransomware nie różnią się od sarkastycznych wypowiedzi autorów CryptoWall:
“CryptoWall Project nie jest szkodliwy i nie ma zaszkodzić osobie czy należącym do niej informacjom. Projekt prowadzi się wyłącznie w celu nauczania w zakresie bezpieczeństwa informacji, a także certyfikacji produktów antywirusowych pod kątem przydatności do ochrony danych”
Podobne aluzje związane z edukacją użytkowników można znaleźć w wielu innych notkach załączonych do ransomware.
Ujawnienie kodu źródłowego nie jest remedium na występujące problemy. Wciąż istnieje wiele rozgałęzień Hidden Tear na platformie Github i cały czas powstają nowe odmiany malware bazujące na Hidden Tear i EDA2. Internet nie zapomina, podobnie jak źli chłopcy.
I choć mówi się, że na dnie puszki Pandory znajduje się nadzieja, to lepiej nigdy tego nie sprawdzać.