Saltar al contenido

Bypass en Secure Boot (GRUB2) pone peligro a millones de equipos

BootHole, vulnerabilidad en GRUB2 afecta a Linux y Windows

Cientos de millones de equipos de todo el mundo (y no estoy exagerando) estarían ahora mismo en peligro en lo que respecta a su funcionalidad de arranque seguro, conocida como Secure Boot, un estándar de la industria en su implementación sobre GRUB2.

GRUB2 es lo que se conoce como bootloader o cargador de arranque de Linux, conocido como GRand Unified Bootloader version 2). Sirve para organizar el arranque de los diferentes sistemas en base a la preferencia del usuario.

Secure Boot, por suparte, es un estándar de la industria que se asegura de que un dispositivo pueda iniciarse con software confiable, exclusivamente.

Cuando un ordenador se inicia, el firmware comprueba el firmware de los drivers UEFI (Unified Extensible Firmware Interface), además de las apps EFI y el propio sistema operativo. Si la verificación es exitosa, se da el control del equipo al sistema operativo, en caso contrario se bloquea.

BootHole, vulnerabilidad en GRUB2 afecta a Linux y Windows

Resulta que han descubierto una vulnerabilidad en la implementación de GRUB en su segunda versión (CVE-2020-10713) que podría permitir a los atacantes evadir esta protección y ejecutar código arbitrario en el sistema durante el arranque, incluso si Secure Boot está implementado y realizando sus comprobaciones.

Esta vulnerabilidad recibe un CVSS de 8.2 según RedHat y es catalogada como “moderada” por Microsoft.

Elysium es la firma de seguridad que ha dado con este gran problema, denominado BootHole porque se da un “agujero” en el proceso de inicio, tratándose técnicamente de una vulnerabilidad de buffer overflow, de una forma que el GRUB2 parsea (interpreta) contenido de su archivo de configuración (grub.cfg)

El fichero de configuración de GRUB2 normalmente es un archivo de texto y habitualmente no está firmado, como otros ejecutables de sistema. Es decir, el sistema no se entera normalmente de si el bootloader ha sido alterado.

De esta forma los atacantes consiguen persistencia en el equipo. El archivo de configuración está cargado y parseado en la inicialización del GRUB, justo tras ser cargado por el bootloader inicial, llamado SHIM.

Durante la fase de parseo, los valores de configuración se copian a los búferes internos almacenados en memoria. Los tokens de configuración mayores que el búfer interno acaban desembocando una condición de desbordamiento de búfer.

Boletín RedHat

Una vez dentro, esto otorga un control elevado sobre los dispositivos. Por eso nos recomiendan monitorizar los sistemas informáticos en busca de amenazas, sobre todo ransomware, que emplee cargadores de arranque vulnerables para dañar los equipos.

Equipos afectados y mitigación

Literalmente, portátiles, sobremesas, servidores, son vulnerables, siendo extensivo a dispositivos IoT, dispositivos de conectividad o red, sistemas SCADA o de producción industrial y casi cualquiera que imaginemos.

La mitigación es costosa y puede ser peligrosa porque requiere que el programa afectado sea firmado y desplegado en los equipos, siendo revocados los programas anteriormente vulnerables.

En el lado del proveedor, la mitigación requiere del lanzamiento de nuevos bootloaders para todas las versiones de Linux, así como para los Shims de cada distribuidor para que sean firmados por la entidad de certificación Microsoft Third-Party UEFI.

Hasta que esto no sea solucionado, cualquier dispositivo que confíe en la CA UEFI de Microsoft será susceptible de que un atacante use una versión vulnerable del shim (cargador inicial del arraque) y GRUB2 para atacar el sistema.

Antes de entrar en producción…

Microsoft publicará en cuanto sea posible actualizaciones para dbx firmados, que podrán aplicarse a los sistemas afectados para bloquear los shims que puedan usarse para lanzar versiones vulnerables de GRUB.

Pero debido al riesgo de “romper” por completo el arranque de sistemas productivos, estos nuevos dbx serán proporcionados bajo demanda en lugar de lanzarse masivamente como parte de un proceso automático.

Fuentes adicionales:

Microsoft: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011

Alejandro Ver todo

Trabajo como consultor de ciberseguridad y me gusta lo que hago. Aficionado a la informática / tecnología en general, me gusta compartir con la gente lo poco que sé. También soy aficionado al deporte y los videojuegos.

Deja tu comentario (puedes hacerlo de forma anónima)

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .

A %d blogueros les gusta esto: