Protocolos Olvidados: IPMI

En post anteriores hemos mencionado la importancia de prestar especial atención a todos los servicios que nuestros activos informáticos brindan a nuestra red interna. Un ejemplo claro era mencionar protocolos tales como NTP en donde encontramos una funcionalidad que, bajo la sensación de seguridad actual, pareciera no tener tanta injerencia dentro de los activos más críticos, pero justamente como detalla ese post, encontramos que ese recurso olvidado, es de vital importancia para los otros servicios que dependen de la variable tiempo, como consecuencia de ello pudimos mostrar cómo pueden llegar a elaborarse vectores de ataque aplicados a ese protocolo que habitualmente no se encuentra observado en el espectro de los que los administradores de sistema tienen en cuenta a la hora de monitorear la salud de los mismos.

Como bien sabrán, no es el único protocolo desatendido dentro de los servicios que acostumbramos a proteger, ya que al tener tanta diversidad de tecnologías dentro de las empresas nos encontramos no solo con la falta de conciencia, a la hora de comprender todos los protocolos, sino también la falta de capacidad técnica para poder darles el tratamiento y la atención que merecen, hoy en este post vamos a conversar sobre otra joya para los atacantes que sigue pasando desapercibida, el protocolo IPMI (Intelligent Platform Management Interface), con el que funcionan las interfaces BMC (Baseboard Management Controller).

El protocolo IPMI

La Interfaz de Gestión de plataforma inteligente, es un conjunto de especificaciones relacionadas con una interfaz ethernet particular asociada a un subsistema que provee capacidades de administración y monitoreo independiente del host principal (Como una mamushka de computadoras). Cuando hablamos de host principal, hablamos de su hardware (su “CPU”), el firmware y el sistema operativo. IPMI permite definir un conjunto de interfaces para que los administradores de los sistemas puedan realizar administración “fuera de banda”. Nos provee la posibilidad de administrar y monitorear el estado de salud de una computadora que podría llegar a estar apagada o que podría estar con algún problema que impida la respuesta habitual, o permitir la ejecución de tareas de mantenimiento como la reinstalación del sistema operativo de forma completamente remota, sin depender de la red principal ni de los mecanismos habituales.

Sin este protocolo, dichas tareas requerirían que un administrador este físicamente frente a la computadora, ingrese un medio con la ISO del sistema operativo y complete el proceso de instalación utilizando un monitor y un teclado. Con IPMI podemos montar una imagen de forma remota simulando una instalación física.

Utilizando mensajes estandarizados, un sistema de administración basado en IPMI puede administrar múltiples servidores que dialoguen a este nivel de red. Estas funciones pueden trabajar en tres escenarios diferentes:

 •  Antes del arranque del sistema (Permitiendo el monitoreo remoto o cambiar alguna configuración de la BIOS)
 •  Cuando el sistema se está apagando (Para determinar por qué está ocurriendo esto, teniendo en cuenta que en ocasiones esto ocurre de forma no planificada)
 •  Luego de una falla en el sistema operativo.

Dentro de las cuestiones a monitorear encontramos variables técnicas como la temperatura, la ventilación, las fuentes, pero también una intrusión física hacia el hardware (como conectar un usb) o algún registro que pueda brindar ayuda respecto del mal funcionamiento que podría ocurrir dentro de una instalación. Este protocolo fue publicado por Intel en 1998 y actualmente es soportado por más de 200 fabricantes, en los que se incluye Cisco, Dell, HP, Intel y un largo etcétera. Los sistemas utilizan por lo general la versión 2.0 que puede ser administrada a través de puerto serie sobre la LAN (Tomen nota de este punto para conversar más adelante), para poder funcionar el protocolo necesita de los siguientes componentes:

 •  Baseboard Management Controller (BMC): Un microcontrolador alojado dentro del motherboard del servidor, es una pequeña computadora basada en un System on a Chip (SoC) ARM, con una controladora gráfica incluida. Algunos fabricantes utilizan soluciones no ARM, pero actualmente el principal SoC dedicado a esto es el AST2500. Estos SoCs están acompañados de un almacenamiento flash y varios controladores de entrada y salida.
En la imagen que se muestra a continuación podemos ver como está conectado el controlador BMC en un motherboard Intel S1200V3

En esta otra imagen podemos visualizar cómo se compone internamente el BMC (AST2500). Allí podemos apreciar en detalle todas las partes que interactúan dentro del chip.

El mismo tiene múltiples conexiones hacia el sistema principal, teniendo la habilidad de monitorear el hardware tal como hemos conversado previamente. Las formas de acceder al mismo pueden ser a través de un puerto serie o a través de un KVM (Keyboard Video & Mouse) virtual. Para comprender mejor cómo funciona podemos hacer una analogía de este SoC con una RaspberryPi y su diagrama de componentes. (Como se muestra en la imagen a continuación)

 •  Intelligent Chassis Management Bus (ICMB): Es utilizada como una interfaz de control entre distintos chassis (Definiendo como chassis a la unidad dentro del Rack que contiene cierta cantidad de servidores), permitiéndole comunicarse a través de una interfaz serie cableada.
 •  Intelligent Platform Management Bus: Sirve para extender el BMC e interconectar diferentes placas.
 •  IPMI Memory: Es la memoria que se utiliza para almacenar los logs del sistema, datos almacenados en reposo, entre otras cosas.
 •  Interfaces de comunicación: Interfaces locales, puertos serie, interfaces de LAN y PCI.

La administración de estas interfaces ocurre a través de la red LAN que todos conocemos, observando la siguiente ilustración podemos ver como un administrador logra conectarse hacia el BMC a través del puerto 623/UDP/TCP utilizando IPMI.

Cabe aclarar que el sistema principal puede ser apagado, pero el módulo IPMI “siempre” va a estar encendido y una conexión hacia la LAN para poder utilizarse, debido a que por lo general todos los BMC de los servidores se encuentran interconectados entre sí. Para traficar los datos que se requieren para las tareas de mantenimiento, se genera una interconexión que puede verse de la siguiente manera:

Hasta ahora no vemos nada extraño, tenemos una red paralela a la LAN que interconecta todos los BMC y sirve para monitorear el estado de salud de los dispositivos. Entonces ¿Dónde ocurre el principal problema? ¿Está en el desconocimiento de estos servicios o en la forma en la que están implementados? Es muy probable que los administradores del área que se encarga de los servidores sean conscientes de la existencia de las controladoras BMC, para poder monitorear sus interfaces, por lo que el problema no estaría en mayor medida en el aparente desconocimiento de este tipo de protocolos. Al ser el BMC una computadora dentro de otra y tener acceso a la LAN el problema es el “mismo de siempre” si no existe una segmentación adecuada que proteja estos recursos, todas las fallas que esta controladora pueda llegar a tener van a estar expuestos, ampliando la superficie de ataque de esta red permitiendo a los atacantes acceder a estos recursos.

Considerando la última imagen, si un atacante tiene visibilidad sobre el Endpoint que administra la red BMC (Punto 1 marcado en la ilustración) o en su defecto la misma red se comunica sin ningún tipo de problema con nuestra red LAN dejando expuesta la red BMC (Punto 2 marcado en la ilustración):

Estamos en presencia de una potencial brecha de seguridad que deja expuestas las interfaces IPMI ampliando la superficie de ataque, como se muestra en el siguiente escenario:

Por lo que podríamos decir que el atacante no solo tiene acceso al monitoreo de los servidores, sino que también podría pasarse de chasis a chasis llegando a servidores alojados en áreas no autorizadas de la infraestructura, como encontramos en el detalle de la imagen anterior, en donde vemos que en el camino azul, a partir de una vulnerabilidad encontrada en un BMC (Correspondiente a un servidor particular) el atacante accede al CMC y luego va pasando de chasis a chasis hasta acceder al servidor deseado fuera de su rango de acción original o en su defecto seguir el camino 1 detallado anteriormente en donde el atacante accede al Endpoint no controlado que tiene acceso al RMC (Que sí puede visualizar todos los CMC correspondientes).

Es importante mencionar que como profesionales en ciberseguridad debemos controlar estos puntos no solo mitigando las potenciales vulnerabilidades, sino también limitando la visibilidad que los atacantes pueden tener sobre estos recursos que a simple vista y sin conocer cómo funcionan se encuentran habitualmente fuera del rango de interés de protección.

Para poder identificar si estos servicios tienen visibilidad con nuestra red interna, podemos realizar los siguientes pasos. Nos posicionamos en cualquier punto de la red y luego podríamos ejecutar los siguientes comandos para realizar una enumeración de los mismos, realizando un pentesting interno orientado a determinar la viabilidad de estas potenciales exposiciones.

Escaneo y Enumeración:

En esta etapa procedemos a ejecutar una serie de escaneos que me van a permitir identificar una respectiva visibilidad asociada a estas interfaces. El atacante en esta etapa busca tener ojos respecto de estos recursos desatendidos.

 • Ejecutar los siguientes comandos con NMAP desde un punto de la red de servidores para visualizar si estas comunicaciones se encuentran operativas (Recuerden que el servicio puede estar tanto por UDP como por TCP, por lo que se aconseja enumerar ambos segmentos)
 •  Luego procedemos a identificar que versión de IPMI está siendo utilizada en esos servicios encontrados previamente. Utilizando un exploit auxiliar en Metasploit y para UDP un script en Nmap:

 •  Es recomendable documentar todos los host para luego ejecutar una prueba de segmentación desde todos los puntos posibles de la red, desde los cuales no deberían verse estos servicios.


Obtención del acceso al BMC:

Recordando los casos vistos previamente, si los servicios son accesibles y se encuentran identificados, debemos lograr acceder a través de estos puertos que se encuentran abiertos y visibles. Para ello podemos realizar varias pruebas listadas a continuación:

 •  IPMI Authentication Bypass via Cipher 0: Esta vulnerabilidad encontrada por Dan Farmer en el protocolo IPMI 2.0 hace referencia a que el tipo de cifrado cipher 0 , que indica que el usuario utiliza autenticación sin formato, en realidad permite el acceso con cualquier contraseña. Probablemente, el problema podría llegar a afectar a todas las implementaciones IPMI 2.0.

- La misma se puede identificar utilizando el siguiente exploit auxiliar con metasploit: use auxiliary/scanner/ipmi/ipmi_cipher_zero

- Luego de la identificación podríamos explotar la falla utilizando la herramienta ipmitool, ejecutando los comandos detallados en la siguiente captura:

 •  IPMI 2.0 RAKP Authentication Remote Password Hash: También podemos preguntarle al servidor por el hash MD5 o SHA1 de cualquier usuario y si el usuario existe estos Hashes serán devueltos respectivamente (Si repetimos el paso del ataque anterior podemos primero con ipmitool relevar los usuarios existentes para luego solicitar los respectivos hashes). Para ello existe un módulo de metasploit que nos ayuda a recolectarlos.
- use auxiliary/scanner/ipmi/ipmi_dumphashes
 •  IPMI Anonymous Access: Si al enumerar los usuarios nos encontramos con que existen campos vacíos, puede que sean usuarios que nulos, si repetimos los pasos anteriores podemos llegar a configurarles una contraseña a cada uno de ellos.

 •  IPMI SuperMicro - Passwords en texto plano: En este caso IPMI 2.0, responde a una autenticación del tipo HMAC utilizando SHA1 y MD5. Este proceso tiene una debilidad marcada, pero muchas veces se requiere acceso al password en texto plano para calcular el respectivo Hash. Al igual que las contraseñas de los motherboard de una infraestructura, los usuarios que mantienen estas instalaciones suelen colocar la misma contraseña para todos los BMC, por lo que en muchas ocasiones basta con acceder a un BMC particular y extraer las contraseñas del directorio /nv/PSBlock o en su defecto /nv/PSStore. El siguiente paso es calcular el hash correspondiente al valor obtenido de esas rutas y realizar la autenticación respectiva.
 •  Fuerza Bruta: Todas las instalaciones son vulnerables a ataques de fuerza bruta y en algunos casos mantienen sus configuraciones originales por defecto. Por lo que acceder a la información necesaria para ejecutar este ataque es de vital importancia luego de haber realizado la correspondiente enumeración. Algunos datos de ejemplo pueden ser los siguientes:

Obtención del acceso al Host:

Una vez que accedimos a la interfaz virtual KVM del respectivo BMC, resta acceder al Host en cuestión. Aquí en esta instancia depende del tipo de sistema operativo que tenga el servidor principal correspondiente al BMC, en esta instancia podemos obtener acceso de varias maneras.

 •  En el caso de sistemas Linux, simplemente reiniciando el servidor desde nuestro KVM podríamos por ejemplo editar el Grub, agregando la clásica línea init=/bin/bash, en la instrucción de Linux y luego iniciar la secuencia de arranque, presionando F10

 •  Luego al obtener el prompt de root podríamos blanquear la contraseña de root o en su defecto crear otro usuario con los respectivos comandos.
 •  En el caso de sistemas Windows; Podríamos utilizar el KVM para cargar una ISO de Hirens Boot CD, para luego utilizar el NTPWEdit a la hora de blanquear la clave del usuario administrador local.

Posibles soluciones

Cabe aclarar que existen varias formas de mitigar estos problemas. Si bien en el caso de que no usemos IPMI los riesgos bajan considerablemente. No debemos dejar de lado la atención sobre los correspondientes BMC. Los pasos para verificar esto serían los siguientes:

 •  Asegurarnos de que las pruebas de segmentación sobre estas interfaces hayan dado negativas, en el caso de ser positivas tenemos una amplia superficie de ataque sobre la cual el atacante puede trabajar sin inconvenientes. Recuerden que en toda KillChain, el objetivo es frenar al atacante cuanto antes para evitar mayores problemas. Si dejamos ciego al atacante aplicando una correcta segmentación y seguridad en profundidad, podemos minimizar estos riesgos.
 •  Actualizar las controladoras BMC vulnerables, existen varios parches que podrían aplicarse a estos firmwares, en el caso de contar con un firmware SuperMicro, les dejamos un enlace en las referencias para que puedan seguir dichas guía.
 •  Para realizar un parcheo seguro deberán bloquear el puerto 623 momentáneamente para poder ejecutar la actualización de forma correcta.
 •  Cambiar los usuarios y contraseñas por default; Colocar contraseñas seguras para que sea más complejo poder calcular el hash y la Sal
 •  Implementar una correcta arquitectura de RED; En este paso asegurarnos que desde internet no se vean los servicios IPMI, es muy común encontrar en Shodan estos servicios habilitados.
 •  Segmentar la red de Management para evitar el acceso desde cualquier punto de la LAN implementando una DMZ interna con un firewall dedicado a esta situación.

Conclusión

Consideramos que es importante comprender las tecnologías para mantenerlas protegidas se entiende que es difícil aplicar soluciones una vez que todas las plataformas se encuentran en producción, por lo que una vez identificado el riesgo, o visto en alguna noticia. Convertir estos conceptos en prácticas rutinarias tiene un impacto directo sobre nuestra arquitectura, no sean vulnerabilidades nuevas, pero no estaremos seguros si no verificamos.