Check Point Research opisało wczoraj, 28 kwietnia, błąd w ransomware VECT 2.0: przy plikach większych niż 131 072 bajty malware traci część danych niezbędnych do pełnego odszyfrowania. Badacze potwierdzili ten mechanizm w analizowanych odmianach dla Windows, Linux i ESXi. Dla właściciela procesu oznacza to, że scenariusz ransomware musi zakładać trwałą utratę danych i drogę odtworzenia niezależną od sprawcy.

Zadajmy pytanie, na które wiele zespołów zna złą odpowiedź: co zrobimy, jeśli kopie zapasowe zawiodą? Zła odpowiedź brzmi: „w ostateczności zapłacimy i dostaniemy narzędzie do odszyfrowania”. Opis VECT 2.0 pokazuje, dlaczego ta furtka nie istnieje. Jeśli malware traci część danych potrzebnych do pełnego odszyfrowania pliku, żadne narzędzie nie odtworzy go w całości, bo brakującej informacji nie ma już nawet sprawca. Zapłata nie zmieni tego wyniku. Plan, w którym okup jest ostatnim wyjściem, w zderzeniu z VECT 2.0 przestaje być planem. Organizacja ma wtedy tylko to, co przygotowała sama: kopie, z których da się wrócić, i sposób pracy na czas, gdy systemu nie ma.

Próg 131 072 bajtów zamienia szyfrowanie w niszczenie

Według Check Point Research problem dotyczy plików większych niż 131 072 bajty. Dla takich plików VECT 2.0 traci część danych, bez których pełne odszyfrowanie jest niemożliwe. Z punktu widzenia ofiary efekt przypomina więc narzędzie do nieodwracalnego uszkadzania plików, choć sprawca projektował program do szyfrowania. Tytuł publikacji badaczy ujmuje to wprost: ransomware z założenia, wiper przez przypadek.

Drugi element opisu waży równie dużo. Badacze potwierdzili ten mechanizm w analizowanych odmianach dla Windows, Linux i ESXi. Obecność ESXi na tej liście oznacza, że przegląd planu odtworzenia powinien objąć bazy danych i maszyny wirtualne.

Gdy sprawca sam nie potrafi odszyfrować plików, okup przestaje być opcją odtworzenia.

Procedura zakłada odszyfrowanie, którego sprawca nie zapewni

Nie oceniamy procedur żadnej konkretnej organizacji. Przyłóżmy natomiast opis Check Point Research do własnych dokumentów. Jeśli scenariusz ransomware w planie ciągłości działania kończy się punktem „negocjacje ze sprawcą” albo „zakup narzędzia do odszyfrowania”, to przy VECT 2.0 ten punkt dla plików powyżej 131 072 bajtów nie zadziała.

Druga rozbieżność dotyczy testów. Deklaracja „mamy kopie zapasowe” mówi o tym, że kopie powstają. Nie mówi, czy da się z nich odtworzyć bazę danych albo maszynę wirtualną w czasie, który proces wytrzyma. Przy VECT 2.0 odtworzenie z kopii jest jedyną drogą, więc niesprawdzona kopia oznacza, że organizacja nie wie, czy w ogóle ma plan.

Trzecia dotyczy izolacji. Skoro badacze potwierdzili błąd w odmianie dla ESXi, kopia przechowywana w tym samym środowisku wirtualizacji, z tymi samymi uprawnieniami administracyjnymi, może podzielić los oryginału. Przyjmijmy ostrożne założenie, że kopia, do której malware może dosięgnąć, nie jest niezależną ścieżką odtworzenia.

Niesprawdzona kopia zapasowa daje zarządowi poczucie bezpieczeństwa, a przy VECT 2.0 nie ma za nią drugiej linii.

Właściciel procesu podejmuje trzy decyzje przed incydentem

Z opisu VECT 2.0 wynikają trzy decyzje: test odtworzenia, izolacja kopii i plan pracy zastępczej. Każda wymaga właściciela po stronie biznesu, obok administratora w dziale IT.

Test odtworzenia rozstrzyga, czy kopie spełniają swoją rolę. Właściciel procesu powinien znać wynik ostatniej próby dla bazy i maszyny wirtualnej, od których zależy jego praca, wraz z datą i czasem trwania. Izolacja kopii rozstrzyga, czy incydent na Windows, Linux albo ESXi może jednocześnie objąć system produkcyjny i jego kopię. Plan pracy zastępczej rozstrzyga, kto i na jakiej podstawie uruchamia proces bez systemu, zanim odtworzenie się zakończy.

Koszt tych decyzji pozostaje w materiale nieokreślony i nie podajemy kwot. Odpowiedzialność da się jednak przypisać od razu. Jeśli decyzja o uruchomieniu procesu zastępczego nie ma wskazanej osoby, w dniu incydentu zapadnie przypadkiem albo za późno.

Polskie firmy używają tych samych platform

Nie znamy ofiar VECT w Polsce ani miary wzrostu tej rodziny malware, więc nie przypisujemy jej krajowego zasięgu. Windows, Linux i ESXi to jednak powszechne środowiska firmowe, więc opis Check Point Research nadaje się jako punkt odniesienia dla krajowych przeglądów planów ciągłości.

Źródłem jest otwarta analiza techniczna badaczy z 28 kwietnia, z podaną datą publikacji. Do zlecenia przeglądu dołączmy link do tej analizy, aby osoba odpowiedzialna za kopie mogła sama sprawdzić, na czym opiera się prośba.

Co z tym zrobić w poniedziałek

  1. Sprawdź datę ostatniego testu odtworzenia. Poproś administratora o wynik ostatniej próby odtworzenia jednej bazy danych i jednej maszyny wirtualnej, od których zależy twój proces. Zapisz datę, czas trwania i to, czy odtworzenie zakończyło się pełnym sukcesem.
  2. Ustal, czy kopia jest odizolowana. Zapytaj, czy kopie tych systemów są dostępne z tych samych kont administracyjnych i z tego samego środowiska ESXi co produkcja. Odpowiedź „nie wiem” zapisz jako ustalenie do uzupełnienia, z nazwiskiem osoby odpowiedzialnej.
  3. Wskaż decydenta procesu zastępczego. Sprawdź w planie ciągłości działania, kto uruchamia pracę bez systemu i na jakiej podstawie. Jeśli scenariusz ransomware zakłada odszyfrowanie po zapłacie, oznacz ten punkt do przepisania.

Opis VECT 2.0 pokazuje, że sprawca może zniszczyć dane, nawet nie chcąc tego zrobić. Plan odtworzenia oparty na jego narzędziu zależy wtedy od jakości cudzego kodu. Organizacja, która sprawdziła kopie, odizolowała je i wie, kto uruchamia pracę zastępczą, nie musi pytać sprawcy o nic.

Źródła

Redakcja cyberinsight.pl.