Admin, penyedia hosting, dan Tim Tanggap Darurat Komputer Prancis (CERT-FR) memperingatkan bahwa penyerang secara aktif menargetkan server VMware ESXi yang belum ditambal terhadap kerentanan eksekusi kode jarak jauh berusia dua tahun untuk menyebarkan ransomware ESXiArgs baru.
Dilacak sebagai CVE-2021-21974, kelemahan keamanan disebabkan oleh masalah luapan heap di layanan OpenSLP yang dapat dieksploitasi oleh pelaku ancaman yang tidak diautentikasi dalam serangan dengan kompleksitas rendah.
“Seperti penyelidikan saat ini, kampanye serangan ini tampaknya mengeksploitasi kerentanan CVE-2021-21974, yang tambalannya telah tersedia sejak 23 Februari 2021,” kata CERT-FR.
“Sistem yang saat ini ditargetkan adalah hypervisor ESXi dalam versi 6.x dan sebelum 6.7.”
Untuk memblokir serangan masuk, admin harus menonaktifkan layanan Service Location Protocol (SLP) yang rentan pada hypervisor ESXi yang belum diperbarui.
CERT-FR sangat menyarankan untuk menerapkan tambalan sesegera mungkin tetapi menambahkan bahwa sistem yang tidak ditambal juga harus dipindai untuk mencari tanda-tanda kompromi.
CVE-2021-21974 memengaruhi sistem berikut:
- ESXi versions 7.x prior to ESXi70U1c-17325551
- ESXi versions 6.7.x prior to ESXi670-202102401-SG
- ESXi versions 6.5.x prior to ESXi650-202102101-SG
Penyedia cloud Prancis OVHcloud juga telah menerbitkan laporan hari ini yang menghubungkan gelombang besar serangan yang menargetkan server VMware ESXi dengan operasi ransomware Nevada.
“Menurut para ahli dari ekosistem serta otoritas, mereka mungkin terkait dengan ransomware Nevada dan menggunakan CVE-2021-21974 sebagai vektor kompromi. Investigasi masih berlangsung untuk mengonfirmasi asumsi tersebut,” kata OVHcloud CISO Julien Levrard .
“Serangan tersebut terutama menargetkan server ESXi dalam versi sebelum 7.0 U3i, tampaknya melalui port OpenSLP (427).”
Ransomware ESXiArgs baru
Namun, dari catatan tebusan yang terlihat dalam serangan ini, mereka tampaknya tidak terkait dengan Ransomware Nevada, dan tampaknya berasal dari keluarga ransomware baru.
Mulai kira-kira empat jam yang lalu, korban yang terkena dampak kampanye ini juga mulai melaporkan serangan di forum BleepingComputer, meminta bantuan dan informasi lebih lanjut tentang cara memulihkan data mereka.
Ransomware mengenkripsi file dengan ekstensi .vmxf, .vmx, .vmdk, .vmsd, dan .nvram pada server ESXi yang disusupi dan membuat file .args untuk setiap dokumen terenkripsi dengan metadata (mungkin diperlukan untuk dekripsi).
Sementara pelaku ancaman di balik serangan ini mengklaim telah mencuri data, satu korban melaporkan di forum BleepingComputer bahwa itu tidak terjadi dalam insiden mereka.
“Investigasi kami telah menentukan bahwa data belum disusupi. Dalam kasus kami, mesin yang diserang memiliki lebih dari 500 GB data tetapi penggunaan harian biasanya hanya 2 Mbps. Kami meninjau statistik lalu lintas selama 90 hari terakhir dan tidak menemukan bukti transfer data keluar,” kata admin.
Korban juga menemukan catatan tebusan bernama “ransom.html” dan “How to Restore Your Files.html” pada sistem yang terkunci. Yang lain mengatakan bahwa catatan mereka adalah file teks biasa.
Michael Gillespie dari ID Ransomware saat ini sedang melacak ransomware dengan nama ‘ESXiArgs’, tetapi mengatakan kepada BleepingComputer bahwa hingga kami dapat menemukan sampel, tidak ada cara untuk menentukan apakah enkripsi memiliki kelemahan.
Bagi mereka yang terpengaruh, peneliti keamanan Enes Sonmez membuat panduan yang memungkinkan admin membangun kembali mesin virtual mereka dan memulihkan data mereka secara gratis.
BleepingComputer memiliki topik dukungan ESXiArgs khusus di mana orang-orang melaporkan pengalaman mereka dengan serangan ini dan menerima bantuan untuk memulihkan mesin.
Detail teknis ESXiArgs
admin mengambil salinan enkripsi ESXiArgs dan skrip shell terkait, lalu membagikannya di topik dukungan BleepingComputer.
Menganalisis skrip dan enkripsi memungkinkan kami untuk lebih memahami bagaimana serangan ini dilakukan.
Saat server dibobol, file-file berikut disimpan di folder /tmp:
mengenkripsi – Enkripsi ELF dapat dijalankan.
encrypt.sh – Skrip shell yang bertindak sebagai logika serangan, melakukan berbagai tugas sebelum mengeksekusi enkripsi, seperti yang dijelaskan di bawah.
public.pem – Kunci RSA publik yang digunakan untuk mengenkripsi kunci yang mengenkripsi file.
motd – Catatan tebusan dalam bentuk teks yang akan disalin ke /etc/motd sehingga ditampilkan saat login. File asli server akan disalin ke /etc/motd1.
index.html – Catatan tebusan dalam bentuk HTML yang akan menggantikan beranda VMware ESXi. File asli server akan disalin ke index1.html di folder yang sama.
Michael Gillespie dari ID Ransomware menganalisis encryptor dan memberi tahu BleepingComputer bahwa enkripsi, sayangnya, aman, artinya tidak ada bug kriptografi yang memungkinkan dekripsi.
“Public.pem yang diharapkan adalah kunci RSA publik (tebakan saya adalah RSA-2048 berdasarkan melihat file terenkripsi, tetapi kode tersebut secara teknis menerima PEM yang valid),” Gillespie memposting di topik dukungan forum.
“Untuk mengenkripsi file, file menghasilkan 32 byte menggunakan CPRNG RAND_pseudo_bytes aman OpenSSL, dan kunci ini kemudian digunakan untuk mengenkripsi file menggunakan Sosemanuk, sebuah stream cipher yang aman. Kunci file dienkripsi dengan RSA (RSA_public_encrypt OpenSSL), dan ditambahkan ke akhir file.”
“Penggunaan algoritma Sosemanuk agak unik, dan biasanya hanya digunakan pada ransomware yang berasal dari source code Babuk (varian ESXi). Mungkin ini masalahnya, tetapi mereka memodifikasinya untuk menggunakan RSA alih-alih implementasi Curve25519 Babuk.”
Analisis ini menunjukkan bahwa ESXiArgs kemungkinan didasarkan pada kode sumber Babuk yang bocor, yang sebelumnya telah digunakan oleh kampanye ransomware ESXi lainnya, seperti CheersCrypt dan enkripsi PrideLocker grup Quantum/Dagon.
Meskipun catatan tebusan untuk ESXiArgs dan Cheerscrypt sangat mirip, metode enkripsinya berbeda, sehingga tidak jelas apakah ini varian baru atau hanya basis kode Babuk yang dibagikan.
Selain itu, ini tampaknya tidak terkait dengan ransomware Nevada, seperti yang disebutkan sebelumnya oleh OVHcloud.
Enkripsi dijalankan oleh file skrip shell yang meluncurkannya dengan berbagai argumen baris perintah, termasuk file kunci RSA publik, file yang akan dienkripsi, potongan data yang tidak akan dienkripsi, ukuran blok enkripsi, dan file ukuran.
usage: encrypt <public_key> <file_to_encrypt> [<enc_step>] [<enc_size>] [<file_size>]
enc_step – number of MB to skip while encryption
enc_size – number of MB in encryption block
file_size – file size in bytes (for sparse files)
Encryptor ini diluncurkan menggunakan skrip shell encrypt.sh yang bertindak sebagai logika di balik serangan, yang akan kami jelaskan secara singkat di bawah.
Saat diluncurkan, skrip akan menjalankan perintah berikut untuk mengubah file konfigurasi mesin virtual ESXi (.vmx) sehingga string ‘.vmdk’ dan ‘.vswp’ diubah menjadi ‘1.vmdk’ dan ‘1.vswp’.
Skrip kemudian menghentikan semua mesin virtual yang berjalan dengan menghentikan paksa (membunuh -9) semua proses yang berisi string ‘vmx’ dengan cara yang mirip dengan artikel dukungan VMware ini.
Skrip kemudian akan menggunakan ‘esxcli storage filesystem list | grep ‘/vmfs/volume/’ | awk -F’ ‘ ‘{print $2}” perintah untuk mendapatkan daftar volume ESXi.
Skrip akan mencari volume ini untuk file yang cocok dengan ekstensi berikut:
.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmem
Untuk setiap file yang ditemukan, skrip akan membuat file [file_name].args di folder yang sama, yang berisi langkah ukuran yang dihitung (ditampilkan di bawah), ‘1’, dan ukuran file.
Misalnya, server.vmx akan memiliki file server.vmx.args terkait.
Skrip kemudian akan menggunakan ‘encrypt’ yang dapat dieksekusi untuk mengenkripsi file berdasarkan parameter yang dihitung, seperti yang ditunjukkan pada screenshot di bawah.
Terakhir, skrip melakukan beberapa pembersihan, menghapus apa yang tampaknya merupakan backdoor yang diinstal ke /store/packages/vmtools.py [VirusTotal] dan menghapus berbagai baris dari file berikut:
Setelah enkripsi, skrip akan mengganti file index.html ESXi dan file motd server dengan catatan tebusan, seperti dijelaskan di atas.
/var/spool/cron/crontabs/root
/bin/hostd-probe.sh
/etc/vmware/rhttpproxy/endpoints.conf
/etc/rc.local.d/local.sh
Pembersihan berbagai file konfigurasi Linux dan potensi backdoor
Pembersihan ini dan penyebutan /store/packages/vmtools.py sangat mirip dengan backdoor Python kustom untuk server ESXi yang dilihat oleh Juniper pada Desember 2022.
Semua admin harus memeriksa keberadaan file vmtools.py ini untuk memastikannya telah dihapus. Jika ditemukan, file tersebut harus segera dihapus.
Terakhir, skrip mengeksekusi /sbin/auto-backup.sh untuk memperbarui konfigurasi yang disimpan di file /bootbank/state.tgz dan memulai SSH.
Sumber : bleepingcomputer.com
