¿Cuál es el problema?
Tres vulnerabilidades fueron publicadas recientemente por la asesoría de seguridad de VMware e impactan vCenter Server o ESXi - CVE-2021-21972, CVE-2021-21973, CVE-2021-21974.
Versiones afectadas de vCenter:
- 7.0 anterior a 7.0 U1c
- 6,7 antes de 6,7 U3l
- 6.5 anterior a 6.5 U3n
Versiones de ESXi afectadas:
- 7.0 antes de ESXi70U1c-17325551
- 6.7 antes de ESXi670-202102401-SG
- 6.5 antes de ESXi650-202102101-SG
Sin embargo, CVE-2021-21972 es una vulnerabilidad crítica de ejecución remota de código según Tenable. Utilizando los datos que alimentan nuestra ASM Platform, el equipo de Censys encontró 6.868 hosts en Internet que ejecutaban esta versión potencialmente vulnerable de vCenter de VMware. Los principales países en los que se detectaron hosts son Estados Unidos, China, Alemania, Francia y Reino Unido.
|
Por país |
% del total |
| Estados Unidos |
1641 |
24% |
| China |
592 |
9% |
| Alemania |
447 |
7% |
| Francia |
390 |
6% |
| Reino Unido |
242 |
4% |
Hemos profundizado en nuestra búsqueda para determinar que sólo el 38% se ejecuta realmente en la nube pública, la mayoría en Amazon AWS. A continuación se ofrece un desglose más detallado.
¿Por qué es importante?
Las recientes vulnerabilidades reveladas por VMware en relación con su software vCenter son excepcionalmente malas noticias para los administradores responsables de mantener una infraestructura virtual segura. Estas vulnerabilidades afectan a piezas clave de la infraestructura crítica permitiendo a un atacante no autenticado subir archivos arbitrarios a servidores de infraestructura crítica y también ejecutar código arbitrario en esos servidores con privilegios de usuario SYSTEM (en servidores Windows). Los administradores que ejecutan vSphere en Linux pueden tener un poco menos de pánico ya que el acceso es más contenido, pero el acceso a nivel de sistema es todavía alcanzable.
Si todavía no está corriendo como un loco hacia su portátil para 1) asegurarse de que no está exponiendo vCenter a todo Internet y 2) pulsar el botón "actualizar ahora", probablemente debería planteárselo si está ejecutando uno de los casi 7.000 servidores potencialmente vulnerables en Internet. Existe código para explotar estas vulnerabilidades, por lo que es importante actuar con rapidez para mitigar el riesgo.
Puede utilizar la siguiente consulta de ejemplo para comprobar su propia infraestructura, sólo tiene que sustituir 8.8.8.8 por su dirección IP o rango CIDR: https://censys.io/ipv4/help?q=%22ID_VC_Welcome%22+AND+ip%3A+8.8.8.8
Estas vulnerabilidades combinadas son un momento especial de "oh mierda" para los administradores. Cualquiera en Internet que pueda utilizar su servidor vCenter como un servicio CDN de memes de gatos es malo, pero considere algunas de las otras cosas a las que un atacante podría ser capaz de acceder. Por ejemplo, cualquier sistema que se ejecute en el servidor vSphere podría estar comprometido y debería inspeccionarse en busca de cambios u otros IoC. Además, debido a que los servidores vSphere a menudo agregan diferentes segmentos de red, un atacante podría pasar de la red vSphere a los interiores de la oficina o centro de datos de una organización, accediendo potencialmente a servicios que son demasiado sensibles para estar conectados directamente a Internet. Los administradores querrán vigilar otros sistemas que estén conectados o potencialmente conectados a redes compartidas con el servidor vSphere.
Censys también ha enviado un pull request a recog para una mejor identificación de vCenter en el futuro. Con este cambio, los clientes que utilizan recog directamente, o que utilizan productos que utilizan recog, se beneficiarán de la nueva capacidad de identificar y asegurar más fácilmente estos servicios.
¿Qué hago al respecto?
Su primer paso debe ser identificar los activos potencialmente afectados por la vulnerabilidad. Hemos utilizado las siguientes consultas para ayudar a la comunidad a identificar los activos afectados que deben investigarse y corregirse.
https://censys.io/ipv4/help?q=%22ID_VC_Welcome%22+AND+ip%3A+8.8.8.8
https://censys.io/ipv4?q=%22VMware+vSphere+is+virtual+infrastructure%22+AND+ip%3A+8.8.8.8
Una vez que encuentre estos activos afectados, tendrá que aplicar la solución o actualizar sus dispositivos vSphere. Ninguna de las dos cosas son divertidas y pueden ser difíciles de hacer sin perder funcionalidad o crear tiempo de inactividad, pero en este caso dudamos que alguien se oponga.
A continuación, dado que se trata de un RCE crítico para todos los propietarios, deberá comprobar cada servidor vSphere en busca de archivos inesperados, nuevos servicios, puertos abiertos que no esperaba, nuevas cuentas u otras cosas inusuales para su entorno. Es muy común que un atacante establezca persistencia al comprometer un servicio o servidor como este, por lo que tendrá que ser meticuloso y probablemente ampliar su búsqueda más allá del propio servidor vSphere.
Encontrará instrucciones para solucionar el problema aquí: https://kb.vmware.com/s/article/82374
Recursos
