En febrero de este año salió a la luz un advisory de VMWare haciendo mención a tres vulnerabilidades, entre las que destacaba una presente en el componente OpenSLP en ESXi.
Lo crítico es que ahora, sólo meses después, ya la hemos visto siendo utilizada en ciberataques de tipo ransomware, donde los atacantes hacen uso de la misma para cifrar por completo las máquinas virtuales.
En ataques que hemos analizado, incluyendo uno involucrando al ransomware Babuk (aka Babyk Ransomware), los atacantes hacen uso de esta vulnerabilidad para lograr la ejecución de código remoto como root sobre el host de ESXi, con lo cual logran detener las máquinas virtuales y realizar el cifrado directamente sobre éstas, en lugar de su contenido. Esto claramente dificulta cualquier tipo de medida de disaster recovery y análisis sobre los mismos servidores, como pueden ser los controladores de dominio que hoy suelen ser el punto central usado por los atacantes para distribuir el ransomware también al resto de la red.
Esta vulnerabilidad, identificada como CVE-2021-21974 y de tipo heap overflow, fue categorizada como Importante bajo un CVSSv3 de 8.8 en parte por la facilidad que supondría para un atacante explotarla y el impacto de la misma. A partir de la misma, los atacantes logran la ejecución de código remoto como root sobre el host de ESXi sin necesidad alguna de autenticación, siendo sólo necesario para llevar a cabo el ataque contar con conectividad contra el servidor a través del puerto 427.
Por su parte VMWare ha indicado las tres versiones de ESXi donde se encuentra resuelta la vulnerabilidad, siendo las siguientes:
ESXi 7.0: ESXi70U1c-17325551
ESXI 6.7: ESXi670-202102401-SG
ESXi 6.5: ESXi650-202102101-SG
Adicionalmente, se ha indicado un workaround al parcheo que consiste en la desactivación del servicio a partir de los siguientes pasos:
- Detener el servicio en el host de ESXi con el comando /etc/init.d/slpd stop
Esto sólo puede hacerse cuando el servicio no está en uso, puede confirmarse el estado operacional del mismo con el comando
esxcli system slp stats get - Desactivar el servicio con el comando esxcli network firewall ruleset set -r CIMSLP -e 0
- Hacer que la desactivación del servicio sea persistente a través de reinicios con el comando chkconfig slpd off
Una vez realizado esto, puede validarse que el cambio haya quedado efectivo de forma persistente con el comando chkconfig –list | grep slpd cuyo output debería ser slpd off
Si por algún motivo tuviese que echarse atrás el cambio, es posible habilitar e iniciar el servicio nuevamente a partir de los siguientes comandos:
-
esxcli network firewall ruleset set -r CIMSLP -e 1
-
chkconfig slpd on
-
/etc/init.d/slpd start
Lucas Leong (https://twitter.com/_wmliang_), de Trend Micro Zero Day Initiative, hizo una demo sobre esta vulnerabilidad además de reportarla a VMWare:
