Масовен ESXiArgs ransomware напад ги таргетира VMware ESXi серверите ширум светот

Администраторите, хостинг провајдерите и French Computer Emergency Response Team (CERT-FR) предупредуваат дека напаѓачите активно ги таргетираат VMware ESXi серверите незакрпени поради двегодишната remote code execution ранливост за да шират нов ESXiArgs ransomware.

Следено како CVE-2021-21974, безбедносниот пропуст е предизвикан од heap overflow проблем во OpenSLP услугата што може да се експлоатира од неавтентицирани напаѓачи во помалку сложени напади.

„Како сегашните истраги, овие кампањи за напади ја искористуваат CVE-2021-21974 ранливоста, за која е достапна закрпа од 23 февруари 2021 година“, изјави CERT-FR.

„Системите кои во моментов се насочени ќе бидат ESXi хипервизорите во верзијата 6.x и пред 6.7”.

За да ги блокираат дојдовните напади, администраторите треба да ја оневозможат ранливата Service Location Protocol (SLP) услуга на ESXi хипервизорите кои сè уште не се ажурирани.

CERT-FR силно препорачува да се примени закрпата што е можно поскоро, но додава дека системите оставени незакрпени треба исто така да се скенираат за да се бараат знаци на компромис.

CVE-2021-21974 влијае на следните системи:

ESXi верзии 7.x пред ESXi70U1c-17325551

ESXi верзии 6.7.x пред ESXi670-202102401-SG

ESXi верзии 6.5.x пред ESXi650-202102101-SG

Францускиот cloud провајдер OVHcloud, исто така, денеска објави извештај во кој го поврзува овој масовен бран напади насочени кон VMware ESXi серверите со Nevada ransomware операцијата.

„Според експертите од екосистемот, како и властите, тие можеби се поврзани со Nevada ransomware и користат CVE-2021-21974 како алатка за компромис. Истрагата сè уште е во тек за да се потврдат тие претпоставки“, изјави Julien Levrard , OVHcloud CISO.

„Нападот првенствено ги таргетира ESXi серверите во верзија пред 7.0 U3i, очигледно преку OpenSLP портата (427)”.

Приближно 3.200 VMware ESXi сервери ширум светот се компромитирани во ESXiArgs ransomware кампањата, според Censys пребарувањето.

Сепак, од белешките за откуп што се гледаат во овој напад, тие не се поврзани со Nevada Ransomware и дека се од нова ransomware група.

Почнувајќи од пред околу четири часа, жртвите погодени од оваа кампања, исто така, почнаа да известуваат за нападите на BleepingComputer форумот, барајќи помош и повеќе информации за тоа како да ги повратат своите податоци.

Ransomware ги шифрира датотеките со екстензии .vmxf, .vmx, .vmdk, .vmsd и .nvram на компромитирани ESXi сервери и креира .args датотека за секој шифриран документ со метаподатоци (најверојатно потребни за дешифрирање).

Додека напаѓачите зад овој напад тврдат дека украле податоци, една жртва на BleepingComputer форумот пријавила дека тоа не било случај во нивниот инцидент.

„Нашата истрага утврди дека податоците не се инфилтрирани. Во нашиот случај, нападнатата машина имаше над 500 GB податоци, но типична дневна употреба од само 2 Mbps. Ја прегледавме статистиката за сообраќајот за последните 90 дена и не најдовме докази за излезни податоци трансфер“, изјави админот.

Жртвите нашле и белешки за откуп со име „ransom.html“ и „How to Restore Your Files.html“ на заклучени системи. Други изјавија дека нивните белешки се датотеки со обичен текст.

Michael Gillespie од ID Ransomware моментално го следи ransomware под името „ESXiArgs“, но за BleepingComputer изјави дека додека не најдеме примерок, нема начин да се утврди дали има слабости во шифрирањето.

За погодените, безбедносниот истражувач Enes Sonmez креираше водич што може да им овозможи на администраторите да ги обноват своите виртуелни машини и бесплатно да ги обноват нивните податоци.

BleepingComputer има посветена ESXiArgs тема за поддршка каде луѓето ги пријавуваат своите искуства со овој напад и добиваат помош од машините за обнова.

Минатата ноќ, администратор извади копија од ESXiArgs енкрипторот и поврзаната shell скрипта и ја сподели во темата за поддршка на BleepingComputer.

Анализирањето на сценариото и шифрирањето ни овозможи подобро да разбереме како биле извршени овие напади.

Кога серверот е пробиен, следните датотеки се зачувуваат во папката /tmp:

encrypt – извршен ELF енкриптор

encrypt.sh – shell скрипта која делува како логика за нападот, извршувајќи различни задачи пред да се изврши шифрирањето, како што е опишано подолу

public.pem – јавен RSA клуч што се користи за шифрирање на клучот што шифрира датотека

motd – белешката за откуп во текстуална форма која ќе се копира на /etc/motd за да се прикаже при најавување. Оригиналната датотека на серверот ќе се копира на /etc/motd1

index.html – белешката за откуп во HTML форма која ќе ја замени почетната страница на VMware ESXi. Оригиналната датотека на серверот ќе се копира во index1.html во истата папка

Michael Gillespie од ID Ransomware го анализирал енкрипторот и го известил BleepingComputer дека шифрирањето е, за жал, безбедно, што значи дека нема криптографски грешки кои дозволуваат дешифрирање.

„Public.pem што го очекува е јавен RSA клуч (моја претпоставка е RSA-2048 врз основа на гледање на шифрирани датотеки, но кодот технички прифаќа каков било валиден PEM).“, објави Gillespie во темата за поддршка на форумот.

„За датотеката да се шифрира, таа генерира 32 бајти користејќи го безбедниот CPRNG на OpenSSL RAND_pseudo_bytes, а овој клуч потоа се користи за шифрирање на датотеката користејќи Sosemanuk, безбедна шифра за пренос. Клучот за датотека е шифриран со RSA (OpenSSL’s RSA_public_encrypt) и е додаден на крајот на датотеката.”

„Употребата на Sosemanuk алгоритмот е прилично уникатна и обично се користи само во ransomware добиен од Babuk (ESXi варијанта) изворниот код. Можеби ова е случај, но тие го изменија за да користат RSA наместо Babuk Curve25519 имплементацијата“.

Оваа анализа покажува дека ESXiArgs најверојатно се заснова на протечениот Babuk изворен код, кој претходно бил користен од други ESXi ransomware кампањи, како што се CheersCrypt и PrideLocker енкрипторот на групата Quantum/Dagon.

Иако белешката за откуп за ESXiArgs и Cheerscrypt се многу слични, методот на шифрирање е различен, што го прави нејасно дали ова е нова варијанта или само заедничка база на кодови на Babuk.

Изгледа дека ова не е поврзано со Nevada ransomware, како што претходно беше споменато од страна на OVHcloud.

Енкрипторот се извршува со shell script датотека што ја стартува со различни аргументи на командната линија, вклучувајќи ја датотеката со јавен клуч RSA, датотеката што треба да се шифрира, деловите од податоци што нема да бидат шифрирани, големината на блок за шифрирање и големината на датотеката.

Овој енкриптор се активира со помош на encrypt.sh shell скриптата која делува како логика зад нападот, што накратко ќе го опишеме подолу.

Кога ќе се стартува, скриптата ќе ја изврши следнава команда за да ги измени конфигурациските датотеки на ESXi виртуелната машина (.vmx), така што низите „.vmdk“ и „.vswp“ ќе се променат во „1.vmdk“ и „1.vswp“.

Скриптата потоа ги терминира сите виртуелни машини кои работат со force – terminating (kill -9) на сите процеси што ја содржат низата „vmx“ на сличен начин како оваа статија за поддршка на VMware.

Скриптата потоа ќе ја користи листата на датотечен систем за складирање esxcli | grep “/vmfs/volumes/” | awk -F” “”{print $2}” команда за да се добие список со ESXi томови.

За секоја пронајдена датотека, скриптата ќе креира [file_name].args датотека во истата папка, која го содржи чекорот за пресметана големина (прикажан подолу), ‘1’ и големината на датотеката.

На пример, server.vmx ќе има поврзана датотека server.vmx.args.

Скриптата потоа ќе ја користи извршната датотека „encrypt“ за да ги шифрира датотеките врз основа на пресметаните параметри, како што е прикажано на сликата од екранот подолу.

По шифрирањето, скриптата ќе ги замени ESXi index.html датотеката и motd датотеката на серверот со белешките за откуп, како што е опишано погоре.

Конечно, скриптата врши одредено чистење, отстранувајќи го она што изгледа како backdoor инсталиран на /store/packages/vmtools.py [VirusTotal] и бришејќи различни линии од следните датотеки:
/ var / spool / cron / crontabs / root
/ bin / hostd – probe.sh
/ etc / vmware / rhttpproxy / endpoints.conf
/ etc / rc. local . d / local . sh

Ова чистење и спомнувањето на /store/packages/vmtools.py е многу слично на приспособен Python backdoor за ESXi серверот, забележан од Juniper во декември 2022 година.

Сите администратори треба да проверат дали постои оваа vmtools.py датотека за да се уверат дека е отстранета. Доколку се најде, датотеката треба веднаш да се отстрани.

Конечно, скриптата го извршува /sbin/auto-backup.sh за да ја ажурира конфигурацијата зачувана во /bootbank/state.tgz датотеката и го стартува SSH.

Ова е приказна во развој и ќе се ажурира со нови информации кога ќе стане достапна…

Ажурирање 2/4/23: Додадени технички детали за нападот. – Lawrence Abrams

Ажурирање 2/5/23: Ажурирано со нов број на шифрирани ESXi сервери и метод за враќање на виртуелните машини.

 

Извор: BleepingComputer