Clicky

Error crítico del cargador de arranque GRUB2 afecta a miles de millones de sistemas Linux y Windows

Categoría: Seguridad
Visitas: 968
BootHole

Denominado 'BootHole', podría permitir a los atacantes eludir la función de arranque seguro

Un equipo de investigadores de ciberseguridad reveló ayer detalles de una nueva vulnerabilidad de alto riesgo que afecta a miles de millones de dispositivos en todo el mundo, incluidos servidores y estaciones de trabajo, computadoras portátiles, computadoras de escritorio y sistemas IoT que ejecutan casi cualquier distribución de Linux o sistema de Windows.

Denominada 'BootHole' y rastreado como CVE-2020-10713, la vulnerabilidad reportada reside en el gestor de arranque GRUB2, que, si se explota, podría permitir a los atacantes eludir la función de arranque seguro y obtener acceso persistente y sigiloso de alto privilegio a los sistemas de destino.

El arranque seguro (Secure Boot) es una característica de seguridad de la Interfaz de firmware extensible unificada (UEFI) que utiliza un cargador de arranque para cargar componentes críticos, periféricos y el sistema operativo al tiempo que garantiza que solo se ejecute un código firmado criptográficamente durante el proceso de arranque.

"Uno de los objetivos de diseño explícitos de Secure Boot es evitar que el código no autorizado, incluso ejecutado con privilegios de administrador, obtenga privilegios adicionales y persistencia previa al SO deshabilitando Secure Boot o modificando la cadena de arranque", explica el informe.

Vulnerabilidad del cargador de arranque GRUB2

Descubierto por investigadores de Eclypsium, BootHole es una vulnerabilidad de desbordamiento de búfer que afecta a todas las versiones de GRUB2 y existe en la forma en que analiza el contenido del archivo de configuración, que generalmente no está firmado como otros archivos y ejecutables, lo que brinda a los atacantes la oportunidad de romper el root del hardware del mecanismo de confianza.

IMG

Para tener en cuenta, el archivo grub.cfg se encuentra en la partición del sistema EFI y, por lo tanto, para modificar el archivo un atacante aún necesita un punto de apoyo inicial en el sistema de destino con privilegios de administrador que eventualmente le proporcionarán al atacante una escalada adicional de privilegios y persistencia en el dispositivo.

Aunque GRUB2 es el gestor de arranque estándar utilizado por la mayoría de los sistemas Linux, también es compatible con otros sistemas operativos, núcleos e hipervisores como XEN.

"El desbordamiento del búfer permite al atacante obtener una ejecución de código arbitrario dentro del entorno de ejecución UEFI, que podría usarse para ejecutar malware, alterar el proceso de arranque, parchear directamente el núcleo del sistema operativo o ejecutar cualquier cantidad de otras acciones maliciosas", dijeron los investigadores.

Por lo tanto, para explotar la falla BootHole en los sistemas Windows, los atacantes pueden reemplazar los cargadores de arranque predeterminados instalados en sistemas Windows con una versión vulnerable de GRUB2 para instalar el malware rootkit.

"El problema también se extiende a cualquier dispositivo de Windows que use el arranque seguro con la Autoridad de certificación UEFI de terceros de Microsoft", dice el informe.

Según el informe detallado de los investigadores [PDF] esta vulnerabilidad puede tener importantes consecuencias, y eso se debe principalmente a que el ataque permite a los piratas informáticos ejecutar código malicioso incluso antes de que se inicie el sistema operativo, lo que dificulta que el software de seguridad detecte la presencia de malware o lo elimine.

IMG

Además de esto, el investigador también agregó que "el entorno de ejecución UEFI no tiene asignación aleatoria de diseño de espacio de direcciones (ASLR) o prevención de ejecución de datos (DEP/NX) u otras tecnologías de mitigación de exploits típicamente encontradas en los sistemas operativos modernos, por lo que crear exploits para este tipo de vulnerabilidad es significativamente más fácil".

Solo instalar actualizaciones y parches no resolvería el problema

Los expertos de Eclypsium ya se han puesto en contacto con entidades relacionadas de la industria, incluidos proveedores de sistemas operativos y fabricantes de computadoras, para ayudarlos a solucionar el problema.

Sin embargo, no parece ser una tarea fácil solucionar el problema por completo.

Simplemente instalar parches con el gestor de arranque GRUB2 actualizado no resolvería el problema, porque los atacantes aún pueden reemplazar el gestor de arranque existente del dispositivo con la versión vulnerable.

Según Eclypsium, incluso "la mitigación requerirá que se firmen y se implementen nuevos gestores de arranque, y los gestores de arranque vulnerables deberían ser revocados para evitar que los adversarios utilicen versiones más antiguas y vulnerables en un ataque".

Por lo tanto, los proveedores afectados necesitarían primero lanzar las nuevas versiones de sus shims de cargador de arranque para ser firmadas por la UEFI CA de terceros de Microsoft.

Finalmente, también debe actualizarse la lista de revocación UEFI (dbx) en el firmware de cada sistema afectado para evitar ejecutar este código vulnerable durante el arranque.

Es probable que este proceso de mitigación de múltiples etapas lleve años para que las organizaciones completen los parches.

"Sin embargo, la implementación completa de este proceso de revocación probablemente será muy lenta. Las actualizaciones relacionadas con UEFI han tenido un historial de inutilización de dispositivos, y los proveedores deberán ser muy cautelosos. Si la lista de revocación (dbx) se actualiza antes de que se actualice un gestor de arranque y una shim de Linux, no se cargará el sistema operativo", advirtieron los investigadores.

En un aviso publicado ayer, Microsoft reconoció el problema, informando que está "trabajando para completar la validación y las pruebas de compatibilidad de una actualización de Windows requerida que aborde esta vulnerabilidad".

También recomendó a los usuarios aplicar parches de seguridad tan pronto como se implementen en las próximas semanas.

Además de Microsoft, muchas distribuciones populares de Linux también han publicado avisos relacionados que explican la falla, las posibles mitigaciones y la línea de tiempo en los próximos parches de seguridad.

Aquí hay una lista de todos los avisos:

Red Hat (Fedora and RHEL)
Canonical (Ubuntu)
SuSE (SLES and OpenSUSE)
Debian
Ubuntu
VMware
Microsoft
HP