Dostawcy usług hostingowych na całym świecie ostrzegają, iż nieznani aktorzy aktywnie atakują niezałatane serwery VMware ESXi, wykorzystując istniejącą lukę w zabezpieczeniach umożliwiającą zdalne wykonanie kodu w celu wdrożenia nowego systemu ransomware ESXiArgs.
Podatność oznaczona jako CVE-2021-21974 spowodowana jest problemem przepełnienia sterty w usłudze OpenSLP, który może zostać wykorzystany przez nieuwierzytelnionych aktorów w atakach o niskiej złożoności.
Istnieje już kilka oficjalnych komunikatów na temat tej kampanii. Jeden z nich pochodzi z francuskiego CERT-FR:
„Według obecnych dochodzeń złośliwa kampania wydaje się wykorzystywać lukę CVE-2021-21974, dla której łatka dostępna jest od 23 lutego 2021 r. w tej chwili atakowane systemy to hiperwizory ESXi w wersji 6.x, ale wcześniejszych niż 6.7”.
Aby zablokować nadchodzące ataki, administratorzy muszą wyłączyć podatną na nie usługę Service Location Protocol (SLP) na hiperwizorach ESXi, które nie zostały jeszcze zaktualizowane.
CERT-FR zdecydowanie zaleca jak najszybsze zainstalowanie łatki, ale dodaje, iż systemy pozostawione bez łatek również powinny zostać przeskanowane w poszukiwaniu oznak naruszenia bezpieczeństwa.
CVE-2021-21974 wpływa na następujące systemy VMware:
- wersje ESXi 7.x przed ESXi70U1c-17325551,
- wersje ESXi 6.7.x przed ESXi670-202102401-SG,
- wersje ESXi 6.5.x przed ESXi650-202102101-SG.
Francuski dostawca chmury OVHcloud jako pierwszy opublikował raport łączący tę masową falę ataków wymierzonych w serwery VMware ESXi z operacją ransomware Nevada.
„Według ekspertów z ekosystemu, a także władz, mogą one być powiązane z oprogramowaniem ransomware Nevada i wykorzystują CVE-2021-21974 jako wektor kompromitacji. Wciąż realizowane są dochodzenia w celu potwierdzenia tych przypuszczeń” – powiedział Julien Levrard, CISO OVHcloud.
„Atak jest skierowany głównie na serwery ESXi w wersji wcześniejszej niż 7.0 U3i, najwyraźniej przez port OpenSLP (427)”.
Jednak firma OVHcloud wycofała się niedługo z oskarżeń, twierdząc, iż przypisała to niewłaściwej operacji ransomware. Pod koniec pierwszego dnia ataków zaszyfrowano ponad 120 serwerów ESXi w OVHcloud. Liczby gwałtownie wzrosły w ciągu weekendu, i w tej chwili ponad 2000 urządzeń VMware ESXi na całym świecie zostało wykrytych jako zainfekowane w ramach kampanii ransomware, zgodnie z wyszukiwaniem w silniku Censys. Oczywiście liczba ta będzie się zmieniać w trakcie reinstalowania serwerów. Pewnie większość administratorów wybierze tę drogę.
W poradniku opublikowanym 6 lutego firma VMware potwierdziła, iż atak wykorzystuje starsze luki ESXi, a nie lukę zero-day.
VMware radzi administratorom, aby zainstalowali najnowsze aktualizacje dla serwerów ESXi i wyłączyli usługę OpenSLP, która teraz na nowych obrazach jest domyślnie wyłączona.
Nowy ransomware ESXiArgs
Z żądań okupu widocznych w tym ataku nie wygląda, by były one powiązane z Nevada Ransomware – wydają się pochodzić z nowej rodziny malware.
Opisywany ransomware szyfruje pliki z rozszerzeniami .vmxf, .vmx, .vmdk, .vmsd i .nvram na zaatakowanych serwerach ESXi i tworzy plik .args dla wszystkich zaszyfrowanego dokumentu z metadanymi (prawdopodobnie potrzebnymi do odszyfrowania).
Podczas gdy cyberprzestępcy stojący za tym atakiem twierdzą w notatce, iż ukradli dane, jedna ofiara zgłosiła na forach BleepingComputer, iż w przypadku jej incydentu tak nie było.
„Nasze dochodzenie wykazało, iż dane nie zostały eksfiltrowane. W naszym przypadku zaatakowana maszyna miała ponad 500 GB danych, ale typowe dzienne wykorzystanie transferu wynosiło zaledwie 2 Mb/s. Przejrzeliśmy statystyki ruchu z ostatnich 90 dni i nie znaleźliśmy dowodów na dane wychodzące” – powiedział administrator.
Ofiary znalazły również notatki z żądaniem okupu o nazwach „ransom.html” i „How to Restore Your Files.html” w zablokowanych systemach. Inni mówili, iż ich notatki to pliki tekstowe.
Nota okupowa widoczna od razu po zalogowaniu się na zainfekowany serwerMichael Gillespie z firmy ID Ransomware śledzi w tej chwili to oprogramowanie pod nazwą „ESXiArgs”. Analiza skryptu i narzędzia szyfrującego pozwoliła mu lepiej zrozumieć, w jaki sposób przeprowadzano te ataki.
W przypadku naruszenia bezpieczeństwa serwera w folderze /tmp przechowywane są następujące pliki:
- encrypt – plik wykonywalny szyfratora ELF,
- encrypt.sh – skrypt powłoki, który działa jako logika ataku, wykonując różne zadania przed wykonaniem programu szyfrującego, jak opisano poniżej,
- public.pem – publiczny klucz RSA używany do szyfrowania klucza szyfrującego plik,
- motd – żądanie okupu w formie tekstowej, które zostanie skopiowane do /etc/motd, aby było widoczne podczas logowania. Oryginalny plik serwera zostanie skopiowany do /etc/motd1,
- index.html – żądanie okupu w formacie HTML, które zastąpi stronę główną VMware ESXi. Oryginalny plik serwera zostanie skopiowany do pliku index1.html w tym samym folderze.
Michael Gillespie przeanalizował program szyfrujący i stwierdził, iż szyfrowanie jest niestety bezpieczne, co oznacza, iż żadne błędy kryptograficzne nie pozwalają na odszyfrowanie plików.
„Aby plik został zaszyfrowany, generuje 32 bajty przy użyciu bezpiecznego CPRNG RAND_pseudo_bytes OpenSSL, a ten klucz jest następnie używany do szyfrowania pliku przy użyciu Sosemanuk, bezpiecznego szyfru strumieniowego. Klucz pliku jest szyfrowany dzięki RSA (OpenSSL RSA_public_encrypt) i dołączany do końca pliku”.
Ta analiza wskazuje, iż ESXiArgs jest prawdopodobnie oparty na ujawnionym kodzie źródłowym Babuk, który był wcześniej używany przez inne kampanie ransomware ESXi, takie jak CheersCrypt i program szyfrujący PrideLocker grupy Quantum/Dagon.
Chociaż żądania okupu dla ESXiArgs i Cheerscrypt są bardzo podobne, różni je metoda szyfrowania, przez co nie jest jasne, czy to nowy wariant, czy tylko wspólna baza kodów Babuk.
Co więcej, nie wydaje się to mieć związku z oprogramowaniem ransomware Nevada, jak wcześniej wspomniało OVHcloud.
Szyfrator jest wykonywany przez plik skryptu powłoki, który uruchamia go z różnymi argumentami wiersza poleceń, w tym z publicznym plikiem klucza RSA, plikiem do zaszyfrowania, porcjami danych, które nie zostaną zaszyfrowane i rozmiarem bloku szyfrowania. Skrypt startowy wykonuje najpierw poniższe polecenie, aby zmodyfikować pliki konfiguracyjne maszyny wirtualnej ESXi (.vmx), tak by łańcuchy „.vmdk” i „.vswp” zostały zmienione na „1.vmdk” i „1.vswp”.
Modyfikacja plików VMX; źródło: BleepingComputerNastępnie skrypt kończy działanie wszystkich uruchomionych maszyn wirtualnych, wymuszając zakończenie (kill -9) wszystkich procesów zawierających ciąg „vmx”.
Potem skrypt używa polecenia „esxcli storage filesystem list | grep “/vmfs/volumes/” | awk -F’ ‘ ‘{print $2}”, aby uzyskać listę woluminów ESXi i przeszukuje te woluminy pod kątem znanych rozszerzeń dysków maszyn wirtualnych: .vmdk .vmx .vmxf .vmsd .vmsn .vswp .vmss .nvram .vmem.
Dla każdego znalezionego pliku skrypt tworzy plik [nazwa_pliku].args w tym samym folderze, który zawiera obliczony krok rozmiaru (pokazany poniżej), „1” i rozmiar pliku.
Na przykład plik server.vmx będzie miał powiązany plik server.vmx.args. Następnie skrypt używa pliku wykonywalnego „encrypt” do zaszyfrowania plików na podstawie obliczonych parametrów, jak pokazano na zrzucie ekranu poniżej.
Pętla szyfrująca pliki; źródło: BleepingComputerPo zaszyfrowaniu skrypt zastępuje plik ESXi index.html i plik motd serwera listami z żądaniem okupu, jak pokazano wyżej.
Na koniec malware przeprowadza pewne porządki, usuwając dzienniki, backdoor Pythona zainstalowanego w /store/packages/vmtools.py i inne artefakty, utrudniając inwestygację.
Plik /store/packages/vmtools.py to ten sam niestandardowy backdoor Pythona dla serwera VMware ESXi, który firma Juniper odkryła w grudniu 2022 r., umożliwiając cyberprzestępcom zdalny dostęp do urządzenia.
Wszyscy administratorzy, którzy zdecydowali się nie przywracać serwera do zera, powinni sprawdzić, czy plik vmtools.py istnieje, i upewnić się, iż zostanie usunięty.
Oficjalny komunikat OVHcloud i porady, jak się zabezpieczyć: Link
Oficjalny komunikat VMware i porady, jak się zabezpieczyć: Link
