Hace cosa de un año salieron a la luz 2 Ransomware que atacaban al entorno de VMware vSphere del cual pensábamos que estábamos seguros. Muy lejos de la realidad.

Lo que hacían los atacantes es a través de unos exploits en Windows se conectaban a los ESXi apagando las máquinas virtuales y cifrando los “.VMDK” y todos los ficheros que estaban dentro de los datastores VMFS

Os dejamos unos enlaces con información sobre estás vulnerabilidades para comprobar si nuestros ESXi están afectados:

VMSA-2019-0022 (vmware.com)

VMSA-2020-0023.3 (vmware.com)

Si quieres saber como recuperar un “.VMDK” encriptado continua leyendo 😊

1º ¿Cómo consiguen acceder a nuestro entorno VMware?

Estos bugs que se han detectado se aprovechan del (SLP) Service Location Protocol, protocolo que usan los dispositivos en la misma red para descubrir a otros dispositivos. Incluyendo obviamente a los ESXi.

Esta vulnerabilidad permite a un atacante que esté en la misma red enviar peticiones SLP a un ESXi y tomar el control. Esta vulnerabilidad la explotan aun con mayor facilidad si los vCenter Servers tienen configurado SSO.

Un usuario administrador del dominio con privilegios en VMware debido a la configuración del Sigle Sign-On que se vea comprometido por alguno de estos Ransomware va a tener full control sobre los ESXi, conectándose a ellos apagando las máquinas virtuales y cifrando todos los ficheros que vean a nivel de datastore como pueden ser los: “.VMDK, .VMX etc”

locked

2º Como recuperar una Virtual Machine que ha sido encriptada a nivel de Datastore

Como ya hemos explicado anteriormente, estos Ransomware encriptan a nivel del Datastore, encriptando todos los ficheros de las máquinas virtuales que allí se encuentran. Encriptan todos los ficheros menos los flat-vmdk que son los ficheros de mayor tamaño que hacen referencia a los discos duros de esas máquinas virtuales.

Estos ficheros no los encriptan porque en la mayoría de los casos son muy grandes y tardarían mucho en encriptarse, lo que hacen es encriptar el resto de los ficheros para hacer inservibles el mayor número de máquinas virtuales en el menor tiempo.

Como recuperar un Disco VMDK afectado por un Ransomware en VMware

Partimos de la base de que los atacantes han borrado también las copias de seguridad y lo único que tenemos es el flat-vmdk para recuperar la máquina virtual:

1. Nos conectamos al ESXi con nuestro root user
 
2. Accedemos al datastore de la MV:
cd /vmfs/volumes/DATASTORE_NAME/VM_NAME
 
3. Identificamos la controladora ISCSI editando un fichero .vmx: scsi1.virtualDev = “lsilogic”
 
4. Revisamos el tamaño exacto del disco VMDK: ls -l vmdisk0-flat.vmdk
-rw——- 1 root root 4294967296 Oct 11 12:30 vmdisk0-flat.vmdk
 
5. Usamos vmkfstools para crear un disco temporal:
# vmkfstools -c 4294967296 -d thin temp.vmdk
 
Se crean los ficheros temp.vmdk y temp-flat.vmdk
 
6. Borramos el temp-flat.vmdk temporal que se genera, no lo necesitamos:
rm -i temp-flat.vmdk
 
7. Renombramos temp.vmdk con el mismo nombre que tenga la MV que queremos recuperar :
mv -i temp.vmdk vmdisk0.vmdk
 
8. Borramos la linea ddb.thinProvisioned = “1” si él “vmdisk0.vmdk” no estaba configurado como disco thin. Si está como thin entonces dejamos la línea y no la borramos. Podemos editar el fichero con “vi”
 
Example
 
# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType=“vmfs”
 
# Extent description
RW 8388608 VMFS “vmdisk0-flat.vmdk”
 
# The Disk Data Base
#DDB
 
ddb.virtualHWVersion = “4”
ddb.geometry.cylinders = “522”
ddb.geometry.heads = “255”
ddb.geometry.sectors = “63”
ddb.adapterType = “lsilogic”
ddb.thinProvisioned = “1”
 
 
9. Para comprobar la consistencia del descriptor lanzamos el siguiente comando:
vmkfstools -e filename.vmdk
 
Si el descriptor es consistente nos aparecerá:
Disk chain is consistent.
 
Si el descriptor no es consiste nos aparecerá lo siguiente
Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).
 

Dejo un enlace a YouTube con un Video Tutorial de VMware:

How to recreate a missing Virtual Machine Disk Descriptor File (VMDK) – YouTube

3º ¿Cómo podemos prevenir este tipo de ataques en nuestros ESXi?

Aparte de emplear la lógica en cuanto, no abrir emails o enlaces de dudosa procedencia y descargar o ejecutar scripts asociados. Vamos a dar unos consejos de securización a la hora de configurar nuestro entorno VMWare:

  • Separar las redes con VLANs:Recordar que aprovechaban el exploit de hacer autodiscover con el SLP de los equipos que estaban en la misma red. Por ello es conveniente separar la red de Management de vSphere de la red de las maquinas virtuales y los usuarios.
  • Mantener actualizados los ESXi:Es fundamental tener actualizados los ESXi porque van corrigiendo todos los exploits y bugs que van saliendo, es muy recomendable agendar una tarea de revisión y parcheo mensual o cada 2 meses.
  • Configuración del SSO:En el caso de usar Single Sign-On para tener acceso al vCenter con nuestros usuarios del dominio, se recomienda limitar los permisos, ya que si tu cuenta de admin del dominio se ve comprometida pueden acceder de manera instantánea a los ESXi y borrarte y/o cifrarte todo el contenido.
  • Usuarios dedicados y rotación de claves:Se recomienda el uso de cuentas dedicadas, y con rotación de contraseñas cada 3 o 6 meses.
Como recuperar un Disco VMDK afectado por un Ransomware en VMware

Conclusión

Estamos en un mundo hiper-conectado donde estamos expuestos todo el tiempo, el mejor antivirus es el propio usuario, debemos aplicar las buenas practicas para minimizar el riesgo y la exposición.

¡Hasta pronto!

¡Sigue Aprendiendo!

Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼

>> Más info
0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like