CVE-2020-3992 Cover

What to do if you were affected by CVE-2020-3992?

Were you affected by CVE-2020-3992 ransomware attack?

Firstly, let's secure your system

In order to secure a system you have to follow a few easy steps. Firstly, you have to login to your ESXi system, it can be done in two different ways:

  • ssh root@your_server_ip
  • Through direct access to the server (or KVM over Internet), you then have to press F2 and authorize yourself using your login and password combination. Once it’s done, you have to enable Console access in the Troubleshooting options. Once it’s enabled, hit Alt+F1 that will take you to login.

Once this is out of the way and you’re in, you have to make sure you prevent future attacks. The vector of an attack in case of CVE-2020-3992 was OpenSLP which has to be disabled.

 

Disable SLP

[root@ESXi:~] /etc/init.d/slpd stop
[root@ESXi:~] esxcli network firewall ruleset set -r CIMSLP -e 0
[root@ESXi:~] chkconfig slpd off

Once you execute this calls, you have to ensure that you reboot this server. It should remove the deface from the login page and you should be able to access your ESXi through webpanel again.

You can also edit message of the day to remove the annoying message from the server every time you login. In order to do that you have to edit /etc/motd

What to do next to remove encryption caused by CVE-2020-3992?

As it occurs, attackers have not encrypted the files bigger than certain size. Luckily, the flat VMDK files, were too big, so what was encrypted was configurations. You can most likely recover your files by following these steps.

First of all, locate where your VMs are residing on the server. It will be one of the subdirectories within /vmfs/volumes. In my case it was /vmfs/volumes/5fc61705-09df5078-xxxx-0cc47a0e99ce. You can find it by listing contents of each directory within /vmfs/volumes and locating the one that has folders matching your VM names.

 

Find the size of -flat.vmdk file

In order to recreate the configuration, you have to go in your VM directory for me it would be cd /vmfs/volumes/5fc61705-09df5078-34e9-0cc47a0e99ce/Webserver

Then you have to list files within this directory using ls -l 


Your output will be similar to this, note the size of Webserver-flat.vmdk is 269509197824. This is important as we’re going to use it in the next step. Run the command, make sure you substitute 12345 with the right size vmkfstools -c 12345 -d thin temp.vmdk

This command will create two files: temp.vmdk and temp-flat.vmdk. At this point we have to OVERWRITE ONLY Webserver.vmdk with the new file. We can do that using mv temp.vmdk Webserver.vmdk

Make sure you ONLY DO THAT for the base .vmdk file. Once it’s done We have to do a couple of things:

  • Open Webserver.vmdk
  • Replace “temp-flat.vmdk” at line 9 with our original name of the -flat.vmdk file, in my case it will be Webserver-flat.vmdk
  • If our server was Thick provisioned, we have to remove ddb.thinProvisioned = “1” from line 19
  • If our server was Thin provisioned, we do not remove it
  • Next, we can remove our temp-flat.vmdk file using rm -rf temp-flat.vmdk
  • We also have to copy the backup of .vmx file, as it was also most likely encrypted. In my case it would be cp Webserver.vmx~ Webserver.vmx 
  • Finally, we can remove .vmsd file as it is corrupted. In my case I would do rm -rf Webserver.vmsd
There’s a small chance that your server will work after these steps, however, there might be a chance it will not boot to operating system due to corrupted partitioning. In order to see the machine we’ll have to re-register it in the ESXi. Go to your datastore and click Register a VM.

Once it is done you’ll see:

Go through the catalogues and find your target .vmx file. In my case it would be:

If it throws an error informing the VM exists, you have to go to your Virtual Machines and deregister the machine that uses the same configuration file.

Once it’s done, repeat the registration step. At this point you can attempt to boot your virtual machine. But it is very likely that you will see the following message:

 

What to do for "Operating System not found"

It is very likely that partition information was lost due to the attack. You will have to follow a few steps in order to get it resolved:

  • Get Live image of Kali Linux from here
  • Upload it to a data store, and boot your Virtual machine using the Kali Linux ISO
  • Start the virtual machine with the ISO loaded, once it boots up open the terminal and type in the following commands
  • We want to be root so sudo su
  • Use testdisk to detect if the partition information is still there and if it works fine, you can follow this guide
  • Run extra checks such as fdisk -l, vgdisplay etc
  • If file systems are not corrupted, then you can attempt to rebuild the system.
  • Most probably your boot partition is at /dev/sda1 and your root is at /dev/sda2, but verify this information is correct for your setup.
  • mkdir /mnt/root
  • mount /dev/sda2 /mnt/root – there’s a chance that this won’t work if you’re using Logical Volume Management, in that case jump to “I have LVM what to do?”
  • mount /dev/sda1 /mnt/root/boot
  • mount -o bind /proc /mnt/root/proc
  • mount -o bind /sys /mnt/root/sys
  • mount -o bind /dev /mnt/root/dev
  • chroot /mnt/root /bin/bash
  • grub2-install /dev/sda – if this fails try to use grub-install instead
  • Reboot, disconnect ISO
  • Your system should be up and running again

I have LVM what to do?

You are here because you have most likely seen the unknown filesystem type ‘lvm2_member’ message while trying to mount /dev/sda2.

Follow this steps if that’s the case:

  • vgchange -ay
  • lvscan
  • lvdisplay
    At this point you’ll see the outputs similar to this, make a note of LV Path from the last command
  • At this point you know where to mount
  • mount /dev/ubuntu-vg/ubuntu-lv /mnt/root
  • mount /dev/sda1 /mnt/root/boot
  • mount -o bind /proc /mnt/root/proc
  • mount -o bind /sys /mnt/root/sys
  • mount -o bind /dev /mnt/root/dev
  • chroot /mnt/root /bin/bash
  • grub2-install /dev/sda – if this fails try to use grub-install instead
  • Reboot, disconnect ISO
  • Your system should be up and running again

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top