Vulnerabilidad de BMC de 22 años expone 24.000 servidores a ataques

Introducción

Más de 24.000 servidores con interfaces de gestión Baseboard Management Controller (BMC) accesibles desde internet exponen hashes de autenticación antes del login, según un reporte de la firma de seguridad Lava. El problema se originó en una vulnerabilidad de 22 años en el protocolo IPMI 2.0 (CVE-2013-4786), que permite a atacantes recuperar contraseñas débiles o predeterminadas sin necesidad de fuerza bruta en línea. Este fallo, presente en la mayoría de las plataformas de servidores, otorga acceso privilegiado a funciones críticas como reinicio de host, actualizaciones de firmware y cambios de configuración a nivel de hardware.

Los BMC son componentes esenciales para la gestión remota de servidores, incluso cuando el sistema operativo no está funcionando. Su compromiso puede convertir un único equipo expuesto en un punto de entrada oculto para moverse lateralmente por la red de gestión del data center, con graves consecuencias para la seguridad física y lógica de la infraestructura.

Qué ocurrió

La vulnerabilidad CVE-2013-4786, introducida en 2004 en el protocolo IPMI 2.0, permite obtener hashes derivados de contraseñas durante el proceso de autenticación. Según el advisory de NIST, un atacante no autenticado que pueda alcanzar el puerto UDP 623 puede solicitar una respuesta del mensaje RAKP (Role-Based Authentication Key-Pair) del BMC y extraer un código HMAC-SHA1 calculado con la contraseña de la cuenta y valores de sesión conocidos. Este hash puede luego ser cracking offline, sin generar múltiples intentos de login que activarían mecanismos de bloqueo.

Lava escaneó internet y encontró 36.862 interfaces IPMI accesibles desde la red. De estas, 24.217 (65,7%) exponen hashes de autenticación antes del login, permitiendo ataques offline. Peor aún: 6.240 sistemas aceptan un usuario vacío con una contraseña débil, y 2.340 tienen cuentas nombradas (como Admin o root) con passwords incluidos en wordlists públicas. Además, algunos BMC utilizan formatos de contraseñas predeterminadas predecibles, como variantes del nombre del fabricante o del modelo del servidor.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

El impacto de esta vulnerabilidad es severo para los equipos de infraestructura y seguridad. Los BMC tienen permisos elevados: permiten apagar o encender servidores, modificar configuraciones de BIOS/UEFI, y acceder a consolas seriales sobre IP (Sol). Un atacante que comprometa un BMC puede:

• Persistencia: Instalar firmware malicioso en el SPI flash del servidor, sobreviviendo reinstalar el sistema operativo.
• Movimiento lateral: Usar la red de gestión (often en una VLAN separada pero con acceso a todos los servidores) para atacar otros BMC o sistemas de monitoreo.
• Sabotaje: Apagar equipos críticos o alterar configuraciones de hardware para causar downtime.
• Robo de datos: Montar un disco virtual sobre la red (via IPMI) y leer información sensible del host, incluso si el OS está apagado.

El riesgo es particularly alto en data centers donde:

• Los BMC están expuestos a internet (común en cloud bare-metal o hosting).
• Se usan credenciales por defecto o contraseñas simples.
• No hay monitoreo de tráfico hacia los puertos UDP 623 (IPMI) o TCP 443/80 (web interfaces de BMC).

La explotation de esta vulnerabilidad ha sido vinculada a ataques de ransomware y compromisos de redes internas en el pasado. CISA ha advertido previamente sobre el exploitation activo de vulnerabilidades en BMC, como en el caso de AMI BMC (CVE-2023-41314).

Detalles técnicos

Mecanismo de la vulnerabilidad

CVE-2013-4786 afecta el protocolo IPMI 2.0, específicamente el proceso de autenticación RAKP (definido en la especificación IPMI v2.0, sección 22.11). Durante el exchange de mensajes:

1. El cliente envía un mensaje Get Authentication Capabilities (RAKP message 1).
2. El BMC responde con Authentication Capabilities (RAKP message 2), que incluye:

– Un session challenge: un string aleatorio.

1. El cliente envía un message Get Session Challenge (RAKP message 3).
2. El BMC responde con Session Challenge (RAKP message 4), que incluye:

– Un authentication code: HMAC-SHA1 del hash de la contraseña del usuario concatenado con el session challenge.

El problema es que el authentication code en el paso 4 se calcula como:

HMAC-SHA1(PasswordHash, [SessionChallenge | 0x00...])

Un atacante puede interceptar este message (via UDP 623) y usar el session challenge conocido para probar contraseñas offline con herramientas como ipmibrute o Hashcat. El modo de hash es 18700 en Hashcat (IPMI PBKDF2).

Versiones afectadas

La vulnerabilidad afecta a implementaciones de IPMI 2.0 en BMC de múltiples fabricantes, incluyendo:

• Supermicro: X9, X10, X11 series (firmware antes de version 3.73 para X10/X11).
• Dell: iDRAC6, iDRAC7, iDRAC8 (algunas versiones).
• HPE: iLO 3, iLO 4 (antes de iLO 4 2.53).
• Lenovo: BMC firmwares antes de 2018.
• AMD: EPYC Server Software (AGESA) antes de version 1.0.0.6.
• Intel: Server Platform Services (SPS) antes de version 4.1.

La lista no es exhaustiva, ya que IPMI es un estándar implementado por muchos vendors. BMC más modernos (IPMI 2.0+ con HPE PEF o similar) pueden mitigar el riesgo si tienen protección contra fuerza bruta, pero la exposición del hash sigue presente.

Vectores de exploit

• Red: Escaneo de UDP 623 para identificar hosts con IPMI accesible.
• Herramientas: nmap con script ipmi-version o metasploit (module auxiliary/scanner/ipmi/ipmi_version).
• Cracking offline: Usar Hashcat con mode 18700:

  hashcat -m 18700 hashes.txt wordlist.txt
  

• Credenciales por defecto: Probar combinaciones comunes como Admin:admin, root:calvin, o ADMIN:ADMIN.

Qué deberían hacer los administradores y equipos técnicos

Mitigación inmediata

1. Bloquear acceso externo a IPMI:

– Usar VPN o jump hosts para acceder a IPMI desde redes de confianza.

1. Cambiar credenciales:

– Eliminar cuentas por defecto (como Admin o root) si no son necesarias.

1. Deshabilitar autenticación anónima:

– En Dell iDRAC: deshabilitar Anonymous Login en Security > Authentication.

1. Actualizar firmware:

– Dell: aplicar updates de iDRAC según el advisory DSA-2019-086.

– HPE: actualizar iLO 4 a version 2.53 o posterior (HPE advisory).

Monitoreo y hardening

1. Monitorear tráfico IPMI:

     alert udp any any -> $HOME_NET 623 (msg:"IPMI RAKP message 4"; content:"|00 00 00 00 00 00 00 00|"; depth 8; sid:1000001;)
     

– Usar herramientas como ipmitool para auditar logs de BMC:

     ipmitool -I lan -U <user> -P <password> -H <bmc_ip> sdr elist
     

1. Segmentar la red de gestión:

– Implementar ACLs para restringir el tráfico entre BMC y otros sistemas.

1. Hardening de BMC:

– Configurar TLS para Redfish y web interfaces (evitar HTTP plaintext).

– Habilitar Secure Boot para el BMC (si disponible) para prevenir firmware malicioso.

1. Escaneo de vulnerabilidades:

Validación

Verificar que las mitigaciones fueron efectivas:

• Intentar obtener el hash de autenticación con metasploit:

  msfconsole -q
  use auxiliary/scanner/ipmi/ipmi_version
  set RHOSTS <bmc_ip>
  run
  

Si el output no incluye un authentication code, la vulnerabilidad está mitigada.

• Probar con credenciales débiles para confirmar que ya no funcionan.

Conclusión

CVE-2013-4786 es un recordatorio de que vulnerabilidades antiguas en componentes de gestión fuera de banda pueden tener un impacto devastador. Aunque el fallo tiene 22 años, la combinación de exposiciones a internet, credenciales por defecto y la capacidad de cracking offline lo mantiene relevante. Los equipos de infraestructura deben priorizar la protección de los BMC: bloquear el acceso externo, rotar credenciales, actualizar firmware y monitorear actividad sospechosa. En entornos cloud o bare-metal, considerar el uso de servicios que provean IPMI virtualizado con controles de seguridad integrados (ej. AWS EC2 Dedicated Hosts con IAM para acceso IPMI).

Fuentes

https://www.securityweek.com/decades-old-bmc-vulnerability-exposes-thousands-of-data-centers-to-attacks/

https://nvd.nist.gov/vuln/detail/CVE-2013-4786