Di pembahasan sebelumnya sudah dituliskan bahwa babuk tidak punya kelemahan, sehingga tanpa key, kita tidak bisa mendekrip data yang sudah dienkrip. Analisis tentang enkripsinya ini benar, tapi ada fakta lain yang tidak dituliskan banyak orang yaitu: babuk asli, dan varian yang menyerang PDN hanya mengenkrip 520MB pertama file data virtual machine.
Dalam banyak kasus, 50-100% data bisa kembali, karena memang tidak kena enkrip. Dalam kebanyakan sistem operasi, 520MB awal dari sebuah disk hanya berisi sistem operasi saja, jadi semua data masih aman. Akan saya jelaskan bagimana recovery bisa dilakukan, dan kasus-kasus di mana recovery ini bisa gagal.
Tadinya saya ingin menunda menuliskan ini karena kemarin braincipher membuat pernyataan ini:
Saya tidak ingin dianggap “third party” yang membantu recover data, sehingga akibatnya data akan dipublish. Tapi sekarang mereka sudah membuat pernyataan baru, bahwa data sudah dihapus, jadi sudah tidak apa-apa.
Contents
Source code babuk
Source code babuk sudah bocor di internet sejak beberapa tahun lalu. Sudah ada banyak turunan malware babuk, karena mudah sekali mengcompilenya. Varian yang dipakai menyerang PDN hanya berbeda di extensionnya (.encrptd) dan keynya, sisanya sama.
Tapi perlu diingat ya: jika kena varian babuk lain mungkin sifatnya sangat berbeda, tergantung kreativitas programmernya.
ESXI
Seperti sudah dibahas sebelumnya, ransomware babuk mengenkripsi virtual machine di ESXI. Nah pertama kita perlu memahami dulu apa itu ESXI, data apa yang dienkrip oleh Babuk dan gimana recoverynya.
ESXI adalah hypervisor (software untuk menjalankan virtual machine) dari Broadcom, saya pernah menulis pengalaman memakai ESXI di artikel saya yang lain dari 2022. Dari pengalaman susah payah mengakali ESXI, saya jadi lebih tahu internalnya.
Tiap virtual machine akan masuk ke satu folder di bawah direktori /vmfs/volumes/NAMAVOLUME/direktori-vm. Sebuah virtual machine terdiri dari beberapa file:
- file vmx, berisi deskripsi virtual machine (berapa memori yang dialokasikan ke mesin ini, berapa CPU virtualnya, dsb)
- file vmdk berisi disk image, berisi data disk (sistem operasi dan semua data lain ada di di sini). Ini semacam “harddisk virtual”.
- file log, berisi informasi startup
- file nvram, berisi konfigurasi UEFI
Masih ada file-file lain, misalnya jika virtual machine disuspend akan tercipta file baru, jika ada snapshot akan tercipta file baru. Penjelasan semua file ini bisa dilihat di situs resminya. Di antara semua file ini, yang paling penting adalah file VMDK, jadi nanti yang direcover adalah file ini.
Pertama saya jelaskan dulu kenapa file lain tidak penting.
File vmx/nvram/log
File VMX hanya berisi deskripsi virtual machine. Kita bisa membuat virtual machine baru, dan segala macam konfigurasi bisa diganti (misalnya jumlah RAM, virtual CPU dsb), lalu kita bisa attach VMDK, dan akan bisa diboot.
File NVRAM hanya berisi konfigurasi UEFI (ini semacam BIOS, sudah pernah saya bahas di sini). Dan file log tentunya tidak penting sama sekali, hanya berisi log startup.
Analoginya, kalau komputer kita rusak, tinggal pindahkan harddisk ke komputer lain, yang penting adalah harddisknya/VMDKnya.
File VMDK (Virtual Machine Disk)
Ketika membuat virtual machine di ESXI, ada 3 opsi file VMDK: “Thin provisioned”, “Thick Provisioned, lazily zeroed”, and “Thick provisioned, eagerly zeroed”. Opsi defaultnya adalah yang tengah: “Thick provisioned, lazily zeroed”.
Untuk jenis yang “thick”, artinya: space akan dialokasikan segera. Jika eagerly zeroed, maka space yang dialokasikan ini akan dikosongkan dulu (ditimpa dengan nol), sedangkan lazily zeroed hanya akan dinolkan nanti kalau memang akan dibaca. Recovery VMDK jenis thick ini yang mungkin dilakukan.
Untuk jenis “thin” provisioned, artinya: alokasi tidak benar-benar dilakukan sekarang. Nanti kalau misalnya ada request buat menulis ke sektor petama, maka akan dituliskan di disk, lalu ada penulisan ke sektor terakhir, akan dituliskan di lokasi berikutnya. Intinya: untuk file jenis ini, jika headernya tertimpa, akan sulit recoverynya. Format VMDK ini terbuka buat yang mau belajar.
Jenis terakhir ini kadang dipakai untuk overprovisioning, artinya: meski harddisk cuma sekian ratus gigabyte, bisa berpura-pura ukurannya sampai ribuan gigabyte.
Asumsi saya, kebanyakan orang akan memakai defaultnya, yaitu thick provisioned, lazily zeroed.
Jika kita punya file VMDK ini, kita bisa membuat VM baru,lalu menambahkan file VMDK ke dalam virtual machine. Jadi file VMDK ini tidak bergantung pada file VMX, bisa berdiri sendiri. Satu virtual machine bisa punya banyak VMDK.
Enkripsi oleh Babuk
Jadi bagaimana babuk mengenkripsi file? tidak seperti ransomware lockbit yang stealth, misterius, dan bisa jalan otomatis di latar belakang, penyerang perlu masuk dulu ke ESXI lalu menjalankan enkriptornya secara manual.
Cara masuknya biasanya hanya dua: via bug ESXI (jika belum dipatch), via password (jika tahu passwordnya). Setelah masuk, penyerang menjalankan enkriptor dari command line. Seperti ini.
di contoh itu, saya hanya mengenkrip satu direktori, jika ingin semua VM, tinggal diganti dengan /vmsf, enkriptornya otomatis rekursif mengenkrip semuanya.
Perhatikan: enkriptornya ini multithread, berusaha mengenkrip banyak file sekaligus. Tapi jika diinterupsi, hasilnya adalah: file nya semua akan corrupt. Cara yang saya tuliskan di sini akan bisa digunakan untuk recovery file yang corrupt ini. Cara cepat mengecek apakah corrupt adalah dengan melihat apakah file log setelah didekrip menjadi teks, jika masih biner, artinya sudah corrupt.
Perlu diperhatikan: dengan key, recovery lebih gampang, karena semua file bisa kembali normal (jika enkriptor tidak ada bugnya). Recovery yang saya bahas adalah recovery data, masih perlu install ulang sistem operasi.
Tentunya attacker yang pintar akan menghapus file enkriptor ini, salah satu penyebab kenapa kemungkinan pihak PDN tidak mengetahui ransomware apa yang menyerang. Jika cara menghapusnya kurang bagus, bisa direcover dengan teknik forensik.
Sebuah file VMDK ukurannya puluhan sampai ratusan GB. Akan sangat lama mengenkrip semua. Seperti pembahasan sebelumnya, Lockbit mengambil pendekatan mengenkrip sekian gigabyte di awal, dan tiap N gigabyte. Pendekatan babuk lebih sederhana: hanya mengenkrip 520MB pertama. Tiap file keynya berbeda, key ini kemudian dienkrip dengan master key, ditambahkan di akhir file (32 byte terakhir file adalah kunci tapi terenkripsi).
Dari mana bisa tahu ini? dari reverse engineering dekriptor yang diberikan. Tapi andaikan tidak ada dekriptorya, analisis forensik digital bisa menunjukkan ini yang terjadi.
Bug dekriptor babuk
Bug di sini artinya kelemahan proses dekripsinya yang menyebabkan file bisa corrupt. Bukan bug yang membuat file bisa dibongkar tanpa key. Dekriptor babuk memulai dengan memotong key di akhir file, mendekrip file, lalu merename .encrptd menjadi nama aslinya. Nah jika ini diinterupsi, keynya sudah dipotong (dengan fungsi truncate64), jadi jika diulangi akan gagal. Contoh interupsi yang mungkin terjadi:
- window ssh ditutup
- tidak sengaja pencet control-c
- out of memory, process dikill
- mati lampu, dsb
Di kode program, batasan enkripsinya adalah 512MB (0x20000000), tapi karena data dibaca tiap kelipatan 10MB, maka yang dienkrip adalah 520MB.
Dari analisis dekriptornya: selalu hanya 520MB yang dienkrip tidak peduli ukuran VMDK-nya. Ini berbeda dengan lockbit yang ukurannya bervariasi, dan juga mengenkrip data di tengah-tengah.
Recovery tanpa key
Sekarang setelah jelas bahwa 520 MB VMDK ini corrupt, maka berikutnya adalah: apakah bagian 520MB ini sangat penting? Ternyata dalam kebanyakan kasus hanya file sistem operasi, partisi recovery dan atau boot loader saja yang kena, data di dalamnya aman.
Sebagai POC (proof of concept), saya menginstall banyak OS di ESXI, mengenkrip datanya, lalu mencoba melakukan recovery.
Mari kita lihat beberapa OS populer, dan bagaimana alokasi filenya secara default. Kebanyakan (mungkin 99%) orang akan menekan enter dan continue di layar instalasi, jadi nilai default ini penting.
Linux
Ubuntu akan mengalokasikan 1.7GB di depan untuk partisi boot. Artinya partisi data benar-benar aman.
Berbagai turunan redhat (centos, almalinux, rocky, dsb) juga memakai layout serupa. Untuk kasus ini, kita perlu melakukan: testdisk, lalu write partition, dan kemudian partisinya langsung bisa dimount.
kpartx -av test.vmdk #lihat outputnya
mount /dev/mapper/loopXpY /media #sesuaikan nomor loop dan partisinya
Tapi bagaimana jika versi Linuxnya tidak membuat partisi terpisah pada opsi defaultnya? Contoh paling populer adalah Debian. Opsi defaultnya adalah: semua file di partisi yang sama.
Kita pastikan bahwa meskipun satu partisi, OS-nya memakai 1.4GB, jadi semua file baru yang kita tambahkan setelah instalasi OS akan berada di lokasi yang tidak dienkrip oleh ransomware.
Untuk pembuktian, sebelumnya saya buat dulu file yang akan direcover nantinya.
Kita bisa mensimulasikan enkripsi dengan dd if=/dev/zero of=file.vmdk count=1 block=520M conv=notrunc, atau beneran menjalankan enkriptor yang source codenya bisa dicompile sendiri.
Lalu kita bisa menjalankan testdisk (bisa didownload dari sini). Ternyata partisi hilang (karena memang tertimpa), tapi kita bisa melakukan search partition. Hasilnya, partisi ketemu, kita bisa menuliskan partisi ini ke file (perhatikan: buat backup file sebelum mengerjakan ini).
Tapi daftar filenya tetap hilang, karena root superblock hilang. Jika kita pilih List, muncul pesan filesystem may be damaged.
Berikutnya kita bisa melihat superblock. Agak panjang penjelasannya, tapi ext4 memakai banyak superblock yang berisi daftar file di direktori. Jadi meski ada yang hilang, sisanya masih bisa direcover.
Berdasarkan pesannya, kita bisa melakukan ini (saya ganti -p dengan -y agar fixing otomatis, tidak perlu menjawab yes, saya gunakan superblock pertama).
sudo kpartx -av debian-to-encrypt-flat.vmdk.encrptd
sudo fsck.ext4 -y -b 163840 -B 4096 /dev/mapper/loop1p1
Perhatikan bahwa file-file kembali, tapi masuk ke lost+found.
Bagaimana dengan data yang tadi saya masukkan? berhasil direcover,
Jadi dalam kasus satu partisi ini, seharusnya semua data bisa tetap kembali.
Windows
Bagaimana dengan Windows? saat ini ada 3 versi Windows server yang masih banyak digunakan: Windows server 2016, Windows Server 2019, dan Windows server 2022. Saya tidak menemukan market share masing-masing Windows, tapi dari survey kecil-kecilan saya, banyak yang masih memakai 2019, bahkan masih memakai 2016, masih sedikit yang memakai 2022. Dari sumber tidak resmi yang saya dapatkan, jumlah VM yang memakai Windows di PDN hanya sekitar 10%.
Windows Server 2016
Ada partisi recovery, system, dan reserved sebelum partisi utama, jadi partisi ini yang akan dienkrip braincipher, dan data tetap aman karena posisinya mulai dari 566MB.
Testdisk akan bisa dipakai untuk recover partisi, dan ekstrak partisi terakhir. Filesystem NTFS akan utuh.
Windows Server 2019
Ini juga masih sama dengan Windows Server 2016. Recovery yang sama bisa dilakukan.
Windows Server 2022
Di sini agak sulit recoverynya, karena sebagian file Windows akan tertimpa. Defaultnya Partisi recovery dipindah ke belakang, dan banyak yang protes dengan keputusan microsoft ini.
Recovery partisi dengan testdisk bisa dilakukan, tapi partisi NTFS akan corrupt. Teorinya mirror dari MFT ada di akhir file, dan bisa digunakan , tapi ketika saya coba masih gagal. Jika dicek lebih dalam harusnya bisa direcover, seperti pernah saya bahas di artikel saya yang ini.
Kasus data sulit kembali
Berikut ini kemungkinan data sulit dikembalikan:
- memakai thin provisioned disk
- memakai layout partisi yang tidak standard
- memakai filesystem yang tidak standard (tidak disupport testdisk)
- memakai multiple disk di satu VM (disk kedua dst tidak ada sistem operasinya, jadi terenkrip datanya 520MB pertama )
Penutup: masalah membongkar ransomware
Ada dilema dalam membongkar ransomware dan menerbitkan hasilnya. Seseorang yang mendapatkan masalah yang sama akan terbantu . Tapi di sisi lain: besok pembuat ransomware tahu kelemahan ransomwarenya, dan akan memperbaikinya, dan korban berikutnya tidak bisa recover dengan cara yang sama.
Tapi tanpa diberitahu pun, para pembuat ransomware ini selalu memperbaiki diri, jadi opsinya adalah:
- Tidak menerbitkan write-up seperti ini, orang yang kena tidak bisa recover, pembuat ransomware mungkin akan memakai teknik yang sama, atau mungkin memperbaiki diri karena menyalin fitur malware lain
- Menerbitkan write-up, orang yang kena bisa recover, pembuat ransomware pasti akan memperbaiki diri dan mengubah cara enkripnya
Kebanyakan pembuat antivirus/malware setuju dengan pendekatan kedua, jadi pendekatan ini yang saya ambil. Kita tidak boleh berharap bahwa ransomware selalu ada bugnya, karena kebanyakan memang tidak ada bugnya.
Setelah memahami bahwa yang menyerang adalah babuk, sepertinya agak terlalu gegabah mengumumkan bahwa semua data tidak bisa direcover. Dengan pemahaman forensik yang baik, sebagian besar data seharusnya tetap aman.
Teknik recovery dengan testdisk ini tidak bisa dipakai kalau OS dan Data diinstall langsung di hardisk/baremetal ya, karena tidak ada .vmdk sebagai ‘virtual disk’ yang ter enkrip. Menarik artikelnya, terimakasih.
Testdisk bisa dipakai untuk recovery baremetal juga. Asalkan ada bloxk device, testdisk bisa mencoba membaca & recover isinya. Masalahnya adalah: isinya yg rusak bagian mana saja dari partisi filesystemnya. Ada kerusakan yg bisa direcocer sebagian, ada yg tidak bisa sama sekali.
Artikel yang sangat bagus dan mendidik dan membuka pandangan.
Mengenai pilihan virtual disk: thin provisioned dan thick provisioned, saya ingin sharing pengalaman saja. Sejak saya mulai bekerja di IT, saya sudah menyentuh lumayan banyak sistem virtualisasi. Baik itu menggunakan VMWare, Hyper-V, Xen, Oracle VM, RVM, Openstack, dsb. Sudah pasti sebanyak itu sistem memang digunakan bukan oleh satu saja perusahaan. Bank biru, Bank hijau, Bapaknya Bank di indonesia, Perusahaan telekomunikasi merah, dan lain2. Mengenadi konfigurasi virtual disk yang dipakai oleh mereka semua, saya belum pernah melihat ada satu pun yang memakai Thick provisioned. Semua pakai Thin. Thin provisioning tidak terlalu menjadi masalah karena disk tidak disimpan hanya dalam satu mesin fisik saja, melainkan merupakan cluster storage. Beberapa menggunakan HCI. Jika pemakaian dimonitor dengan baik dan jika akan penuh langsung ditambah disk-nya, atau bahkan menambah node, semua aman. Biasanya jika penggunaan mencapai 60-70% mulai dilakukan pengadaan penambahan kapasitas, tergantung seberapa cepat kapasitas storage terisi.
Kemudian bagaimana jika disk yang dipakai penuh dan terlambat menambah kapasitas? Ya, pernah terjadi hanya sekali seumur saya bekerja. Di suatu Bank. Akibatnya memang dahsyat: Seluruh disk yang dipakai VM di satu cluster menjadi read only. Ratusan, hampir seribu VM mati dan layanan berhenti selama sehari penuh. Memang hampir semua berhasil direcover, namun beberapa database corrupt dalam menulis transaksi terakhir dan roll back 1-2 menit. Tidak terlihat besar rollback 1-2 menit, tapi untuk Bank besar, itu dahsyat sekali.
Bagaimana dengan jika yang thin provisioning terkena ransomware seperti ini? ya memang lebih sulit.
ternyata saya salah, kirain thin provisionednya VMware desktop sama dengan ESXI
di desktop, yg thin itu bakal dipecah jadi banyak file, dan ada struktur data khusus, susah recovery
Ternyata thin provisioned-nya ESXI itu cuma sparse file biasa (https://superuser.com/questions/1682124/why-in-esxi-is-the-file-size-of-a-thin-provisioned-virtual-disk-the-same-size-as)
barusan testing dan beneran ternyata, yg thin pun bisa direcover
Konfigurasinya bisa macam2. Iya kalau default ESXI single node, bisa jadi disimpan dalam single sparse file. Tergantung apa yang dipakai dan mau dipasang bagaimana. Kalau untuk suatu instansi tertentu, saya pikir sampel konfigurasinya harus melihat spesifik dari mereka juga. VMWare punya VSAN. Storage di VSAN skemanya bisa macam2. Bisa jadi menggunakan satu storage controller terpisah, bisa jadi HCI. Bisa jadi volume langsung menggunakan disk groupnya, dimapping langsung ke block device. Bisa jadi di atas diskgroup dibuat fikesystem dulu & volume ditaruh di atas filesystem tsb.
Entahlah konfigurasi mereka bagaimana, saya hanya sedikit2 mengamati dari luar saja.
Semua akses file di dalam ESXI akan memakai layer VMFS, ini akan menjadi layer yang menerjemahkan akses file seolah-olah mengakses sektor biasa (seperti sparse file), apapun backing di belakangnya.
Tapi saya terbuka dibuktikan salah. Mungkin bisa dicoba konfigurasi mana yang menyebabkan file tidak bisa direcover, nanti bisa saya coba.