Masowy atak ransomware ESXiArgs na serwery VMware ESXi

Administratorzy, dostawcy usług hostingowych oraz francuski zespół CERT-FR (Computer Emergency Response Team) ostrzegają, że napastnicy aktywnie biorą na cel serwery VMware ESXi, niezałatane przeciwko dwuletniej luce zdalnego wykonywania kodu, która umożliwia atak ransomware ESXiArgs.

 

Jak to możliwe?

 

Luka, oznaczona jako CVE-2021-21974, spowodowana jest błędem przepełnienia sterty w usłudze OpenSLP, który może zostać wykorzystany przez nieupoważnione osoby w mało skomplikowanych atakach.

“Jak wynika z aktualnych badań, te kampanie ataku wydają się wykorzystywać lukę CVE-2021-21974, dla której łata jest dostępna od 23 lutego 2021 r.”, przekazał CERT-FR. “Systemami będącymi obecnie celem ataku byłyby hiperwizory ESXi w wersji 6.x i wcześniejsze niż 6.7”.

 

Aby zablokować nadchodzące ataki, administratorzy muszą wyłączyć podatną na atak usługę Service Location Protocol (SLP) na hiperwizorach ESXi, które nie zostały jeszcze zaktualizowane. CERT-FR zdecydowanie zaleca jak najszybsze zastosowanie poprawki, ale dodaje, że systemy pozostawione bez łatki powinny być również skanowane w poszukiwaniu oznak przejęcia.

 

Przebieg ataku

 

CVE-2021-21974 wpływa na następujące systemy:

•    ESXi w wersji 7.x przed ESXi70U1c-17325551
•    ESXi w wersji 6.7.x przed ESXi670-202102401-SG
•    ESXi w wersji 6.5.x przed ESXi650-202102101-SG

 

 

Francuski dostawca chmury OVHcloud po raz pierwszy opublikował raport łączący tę masową falę ataków skierowanych na serwery VMware ESXi z operacją ransomware Nevada.

 

“Według ekspertów z ekosystemu, jak również autorytetów, mogą one być związane z ransomware Nevada i wykorzystują CVE-2021-21974 jako wektor ataku. Śledztwo wciąż trwa, w celu potwierdzenia tych przypuszczeń” – powiedział OVHcloud CISO Julien Levrard.

“Celem ataku są przede wszystkim serwery ESXi w wersji przed 7.0 U3i, najwyraźniej poprzez port OpenSLP (427)”.

Pod koniec pierwszego dnia ataków zaszyfrowanych było około 120 serwerów ESXi.

Jednak liczby te szybko wzrosły w ciągu weekendu – obecnie na całym świecie wykryto 2 400 urządzeń VMware ESXi skompromitowanych w kampanii ransomware, wg. Censys search. W opublikowanym 6 lutego poradniku VMware potwierdziło, że atak ten wykorzystuje starsze błędy w ESXi, a nie lukę zero-day.

Firma radzi administratorom, aby zainstalowali najnowsze aktualizacje dla serwerów ESXi i wyłączyli usługę OpenSLP, która jest domyślnie wyłączona od 2021 roku. Niektórzy administratorzy dotknięci tym atakiem powiedzieli, że nie mają włączonego SLP [1, 2], dodając dalsze zamieszanie co do sposobu naruszenia serwerów.

Ogólnie rzecz biorąc, kampania ransomware nie odniosła większego sukcesu, biorąc pod uwagę dużą liczbę zaszyfrowanych urządzeń, według Ransomwhere – usługi śledzenia płatności okupu – odnotowano tylko cztery wpłaty na łączną kwotę 88 000 dolarów.

Brak wpłat okupu jest prawdopodobnie spowodowany przewodnikiem odzyskiwania VMware ESXistworzonym przez badacza bezpieczeństwa Enesa Sonmeza, dzięki któremu wielu administratorów może odbudować swoje maszyny wirtualne i odzyskać dane za darmo.

 

Nowy ransomware ESXiArgs

 

Jak jednak wynika z notatek o okupach widzianych w tym ataku, nie wydają się być one powiązane z Nevada Ransomware i wydają się pochodzić z nowej rodziny ransomware.

Począwszy od niespełna kilku dni, ofiary dotknięte tą kampanią zaczęły również zgłaszać ataki na BleepingComputer’s forum, prosząc o pomoc i więcej informacji o tym jak odzyskać swoje dane.

Ransomware szyfruje pliki z rozszerzeniami .vmxf, .vmx, .vmdk, .vmsd i .nvram na skompromitowanych serwerach ESXi i tworzy plik .args dla każdego zaszyfrowanego dokumentu z metadanymi (prawdopodobnie potrzebnymi do odszyfrowania).

Chociaż aktorzy zagrożeń stojący za tym atakiem twierdzą, że wykradli dane, jedna z ofiar poinformowała na forum BleepingComputer, że w ich incydencie się to nie wydarzyło.

“W wyniku naszego śledztwa ustaliliśmy, że dane nie uległy infiltracji. W naszym przypadku zaatakowana maszyna miała ponad 500 GB danych, ale typowe dzienne użycie wynosiło tylko 2 Mbps. Przejrzeliśmy statystyki ruchu z ostatnich 90 dni i nie znaleźliśmy żadnych dowodów na transfer danych na zewnątrz” – powiedział administrator.

Ofiary znalazły również notatki okupu o nazwie “ransom.html” i “How to Restore Your Files.html” na zablokowanych systemach. Inni mówili, że ich notatki to pliki plaintext.

ESXiArgs ransom note (BleepingComputer)

 

Michael Gillespie z ID Ransomwareśledzi obecnie ransomware pod nazwą “ESXiArgs”, ale powiedział BleepingComputer, że dopóki nie uda się znaleźć próbki, nie ma możliwości określenia, czy ma on jakieś słabości w szyfrowaniu.

BleepingComputer ma dedykowany temat wsparcia ESXiArgs, gdzie ludzie zgłaszają swoje doświadczenia z tym atakiem i otrzymują pomoc w odzyskaniu maszyn.

 

Szczegóły techniczne ESXiArgs

 

Jeden z administratorów odzyskał kopię szyfratora ESXiArgs i związanego z nim skryptu powłoki i podzielił się nim w grupie wsparcia BleepingComputer.

Analiza skryptu i szyfratora pozwoliła nam lepiej zrozumieć, jak przeprowadzono te ataki.

Po naruszeniu serwera, w folderze /tmp zapisywane są następujące pliki:

    encrypt – Program wykonywalny ELF encryptora.
    encrypt.sh – Skrypt powłoki, który działa jako logika ataku, wykonując różne zadania przed wykonaniem szyfratora, jak opisano poniżej.
    public.pem – Publiczny klucz RSA używany do szyfrowania klucza szyfrującego plik.
    motd – Okup w formie tekstowej, który zostanie skopiowany do /etc/motd, aby był wyświetlany przy logowaniu. Oryginalny plik serwera zostanie skopiowany do /etc/motd1.
    index.html – Okup w formie HTML, który zastąpi stronę główną VMware ESXi. Oryginalny plik serwera zostanie skopiowany do index1.html w tym samym folderze.

Michael Gillespie z ID Ransomware przeanalizował szyfrator i powiedział BleepingComputer, że szyfrowanie jest niestety bezpieczne, co oznacza, że żadne błędy kryptograficzne nie pozwalają na odszyfrowanie.

“public.pem, którego oczekuje, to publiczny klucz RSA (moje przypuszczenie to RSA-2048 na podstawie patrzenia na zaszyfrowane pliki, ale kod technicznie akceptuje każdy ważny PEM)”, napisał Gillespie w temacie wsparcia na forum.

“Dla pliku do zaszyfrowania, generuje 32 bajty za pomocą bezpiecznego CPRNG OpenSSL RAND_pseudo_bytes, a ten klucz jest następnie używany do szyfrowania pliku za pomocą Sosemanuk, bezpiecznego szyfru strumieniowego. Klucz pliku jest szyfrowany za pomocą RSA (OpenSSL RSA public encrypt) i dołączany do końca pliku.”

“Wykorzystanie algorytmu Sosemanuk jest raczej niespotykane i zazwyczaj jest stosowane tylko w ransomware pochodzącym z kodu źródłowego Babuk (wariant ESXi). Być może tak jest w tym przypadku, ale zmodyfikowali go, aby użyć RSA zamiast implementacji Babuka – Curve25519.”

Analiza ta wskazuje, że ESXiArgs jest prawdopodobnie oparty na wyciekłym kodzie źródłowym Babuk, który był wcześniej wykorzystywany przez inne kampanie ransomware ESXi, np. CheersCrypt oraz szyfratorze grupy Quantum/Dagon – PrideLocker.

Podczas gdy notatki o okupie dla ESXiArgs i Cheerscrypt są bardzo podobne, metoda szyfrowania jest inna, co czyni niejasnym, czy jest to nowy wariant, czy po prostu wspólna baza kodowa Babuk.

Ponadto nie wydaje się to być związane z ransomware Nevada, o czym wcześniej wspominał OVHcloud.

Szyfrator jest wykonywany przez plik skryptu powłoki, który uruchamia go z różnymi argumentami wiersza poleceń, w tym plikiem klucza publicznego RSA, plikiem do zaszyfrowania, fragmentami danych, które nie będą szyfrowane, rozmiarem bloku szyfrowania i rozmiarem pliku.

 

 

 

Szyfrator ten jest uruchamiany za pomocą skryptu powłoki encrypt.sh, który pełni rolę logiki ataku, co pokrótce opiszemy poniżej.

 

Po uruchomieniu skrypt wykona następujące polecenie modyfikujące pliki konfiguracyjne maszyny wirtualnej ESXi (.vmx) tak, aby ciągi ‘.vmdk’ i ‘.vswp’ zostały zmienione na “1.vmdk” i “1.vswp”.

 

Modyfikacja plików VMX
Źródło: BleepingComputer

 

Następnie skrypt kończy pracę wszystkich działających maszyn wirtualnych poprzez wymuszenie zakończenia (kill -9) wszystkich procesów zawierających ciąg ‘vmx’ w sposób podobny do tego z artykułu pomocy technicznej VMware.

Dalej skrypt użyje polecenia ‘esxcli storage filesystem list | grep “/vmfs/volumes/” | awk -F’ ‘ ‘{print $2}”, aby uzyskać listę woluminów ESXi.

Skrypt będzie przeszukiwał te woluminy w poszukiwaniu plików pasujących do następujących rozszerzeń:

.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmem

Dla każdego znalezionego pliku skrypt utworzy w tym samym folderze plik [nazwa_pliku].args, który zawiera obliczony krok wielkości (pokazany poniżej), ‘1’ oraz rozmiar pliku.

Na przykład, server.vmx będzie miał powiązany plik server.vmx.args.

Następnie skrypt użyje pliku wykonywalnego “encrypt” do zaszyfrowania plików w oparciu o obliczone parametry, jak pokazano na zrzucie ekranu poniżej.

Modyfikacja plików VMX Rutyna do tworzenia plików .args i szyfrowania plików
Źródło: BleepingComputer

Po zaszyfrowaniu skrypt zastąpi plik ESXi index.html oraz plik motd serwera notatkami o okupie, jak opisano powyżej.

 

Na koniec skrypt wykonuje pewne czynności porządkowe, usuwając logi, usuwając backdoora Pythona zainstalowanego w /store/packages/vmtools.py [VirusTotal], oraz usuwając różne linie z następujących plików:

/var/spool/cron/crontabs/root
/bin/hostd-probe.sh
/etc/vmware/rhttpproxy/endpoints.conf
/etc/rc.local.d/local.sh

 

Czyszczenie różnych plików konfiguracyjnych Linuksa i potencjalnego backdoora
Źródło: BleepingComputer

 

Plik /store/packages/vmtools.py to ten sam niestandardowy backdoor Pythona dla serwera VMware ESXi odkryty przez Juniper w grudniu 2022 r., pozwalający aktorom zagrożeń na zdalny dostęp do urządzenia.

Wszyscy administratorzy powinni sprawdzić istnienie tego pliku vmtools.py, aby upewnić się, że został on usunięty. Jeśli zostanie znaleziony, plik powinien zostać natychmiast usunięty.

Na koniec wykonywany jest skrypt /sbin/auto-backup.sh w celu aktualizacji konfiguracji zapisanej w pliku /bootbank/state.tgz i uruchamia SSH.

 

Co zrobić w sytuacji tak dużego zagrożenia? Jak postępować? Jak nie poddać się panice i stworzyć możliwie skuteczną linię obrony? Skontaktuj się z naszymi ekspertami, którzy służą pomocą nie tylko w tym konkretnym przypadku.