Compañía Eclypsium dos vulnerabilidades en el firmware del controlador BMC enviado con Lenovo ThinkServers que permiten a un usuario local cambiar el firmware o ejecutar código arbitrario en el lado del chip BMC.
Un análisis más detallado mostró que estos problemas también afectan el firmware de los controladores BMC utilizados en las plataformas de servidores Gigabyte Enterprise Servers, que también se utilizan en servidores de empresas como Acer, AMAX, Bigtera, Ciara, Penguin Computing y sysGen. Los BMC problemáticos utilizaban firmware MergePoint EMS vulnerable desarrollado por el proveedor externo Avocent (ahora una división de Vertiv).
La primera vulnerabilidad es causada por la falta de verificación criptográfica de las actualizaciones de firmware descargadas (solo se utiliza la verificación de suma de comprobación CRC32, al contrario de NIST para utilizar firmas digitales), lo que permite a un atacante con acceso local al sistema cambiar el firmware del BMC. El problema, por ejemplo, se puede utilizar para integrar profundamente un rootkit que permanece activo después de reinstalar el sistema operativo y bloquea futuras actualizaciones de firmware (para eliminar el rootkit, necesitará utilizar un programador para reescribir el flash SPI).
La segunda vulnerabilidad está presente en el código de actualización del firmware y permite la sustitución de comandos personalizados que se ejecutarán en el BMC con el nivel más alto de privilegios. Para atacar, basta con cambiar el valor del parámetro RemoteFirmwareImageFilePath en el archivo de configuración bmcfwu.cfg, a través del cual se determina la ruta a la imagen del firmware actualizado. Durante la próxima actualización, que puede iniciarse mediante un comando en IPMI, este parámetro será procesado por el BMC y utilizado como parte de la llamada popen() como parte de la cadena para /bin/sh. Dado que la cadena para formar el comando de shell se crea utilizando la llamada snprintf() sin el escape adecuado de caracteres especiales, los atacantes pueden sustituir su propio código para la ejecución. Para aprovechar la vulnerabilidad, debe tener derechos que le permitan enviar un comando a través de IPMI al controlador BMC (si tiene derechos de administrador en el servidor, puede enviar un comando IPMI sin autenticación adicional).
Gigabyte y Lenovo estaban al tanto de los problemas ya en julio de 2018 y publicaron actualizaciones antes de su divulgación pública. lenovo actualizaciones de firmware del 15 de noviembre de 2018 para los servidores ThinkServer RD340, TD340, RD440, RD540 y RD640, pero corrigieron solo una vulnerabilidad en ellos que permite la sustitución de comandos, ya que durante la creación de una línea de servidores basada en MergePoint EMS en 2014, la verificación de firmware mediante firma digital aún no se distribuyó ampliamente y no se anunció originalmente.
El 8 de mayo de este año, Gigabyte lanzó actualizaciones de firmware para placas base con el controlador ASPEED AST2500, pero al igual que Lenovo, solo solucionaron la vulnerabilidad de sustitución de comandos. Las placas vulnerables basadas en ASPEED AST2400 aún no están actualizadas. gigabytes también sobre la transición al uso del firmware MegaRAC SP-X de AMI. Se ofrecerá un nuevo firmware basado en MegaRAC SP-X para sistemas previamente suministrados con firmware MergePoint EMS. La decisión se tomó tras el anuncio de Vertiv de finalizar el soporte para la plataforma MergePoint EMS. Al mismo tiempo, no se ha informado nada sobre la actualización del firmware en servidores fabricados por Acer, AMAX, Bigtera, Ciara, Penguin Computing y sysGen basados en placas Gigabyte y equipados con firmware vulnerable MergePoint EMS.
Recuerde que BMC es un controlador especializado instalado en servidores que tiene su propia CPU, memoria, almacenamiento y sondeo de sensores, lo que proporciona una interfaz de bajo nivel para monitorear y controlar el hardware del servidor. Con la ayuda de BMC, independientemente del sistema operativo que se ejecute en el servidor, puede monitorear el estado de los sensores, administrar la energía, el firmware y los discos, organizar el arranque remoto a través de la red, garantizar el funcionamiento de la consola de acceso remoto, etc.
Fuente: opennet.ru