Llegamos a ustedes gracias a:



Alertas de Seguridad

Un error en el cargador de arranque GRUB2 de Linux

Rompe el Secure Boot en la mayoría de las computadoras y servidores

[18/08/2020] El personal de mantenimiento del sistema operativo, los fabricantes de computadoras y los proveedores de software de seguridad y virtualización han trabajado juntos durante los últimos meses para coordinar una respuesta unificada a una vulnerabilidad que permita a los atacantes eludir la verificación de integridad del proceso de arranque, una de las características clave de seguridad de las computadoras modernas. La falla se encuentra en el cargador de arranque GRUB2 de Linux, pero debido a cómo se implementa el Secure Boot, también se puede usar para comprometer el proceso de arranque de Windows y otros sistemas.

La instalación de las actualizaciones, que se anunciaron hoy en todas las computadoras y dispositivos afectados, requerirá pruebas y despliegues manuales y, probablemente, llevará mucho tiempo. Es razonable esperar que algunos sistemas nunca se actualicen, permaneciendo vulnerables al malware de nivel de arranque y a las modificaciones no autorizadas del firmware.

¿Qué es Secure Boot y cómo funciona?

Secure Boot es un mecanismo estandarizado para verificar criptográficamente la integridad de todos los componentes involucrados en el proceso de arranque de una computadora, hasta que el sistema operativo se inicializa y se hace cargo de la ejecución. Secure Boot es una función de la Interfaz de Firmware Extensible Unificada (UEFI, por sus siglas e inglés), que ha reemplazado el firmware BIOS previo en todas las computadoras modernas.

Casi todas las implementaciones de UEFI se envían con una clave raíz que pertenece a Microsoft, y establece la raíz de confianza para toda la plataforma. Esto se conoce como la Microsoft 3rd Party UEFI Certificate Authority (CA). Una vez que el Secure Boot se enciende en una computadora, cada componente de arranque debe firmarse con una clave vinculada a esta CA para que se inicie el sistema operativo, lo que significa que las distribuciones de Linux también deben tener sus cargadores de arranque firmados por Microsoft.

GRUB2, abreviatura de Grand Unified Bootloader versión 2, es el cargador de arranque estándar utilizado por la mayoría de los sistemas Linux. Este es un software relativamente complejo que soporta muchas funciones y configuraciones, por lo que cada distribución de Linux mantiene su propio cargador de arranque basado en GRUB2.

Para evitar que Microsoft vuelva a firmar sus archivos binarios de GRUB cada vez que se les realiza una modificación o una actualización, los proveedores de Linux le solicitan a Microsoft que firme un código mucho más simple llamado cargador de arranque "shim, que luego se utiliza para verificar e inicializar GRUB. Los shims generalmente contienen un certificado controlado por la distribución de Linux, lo que da a sus encargados la libertad de firmar sus binarios GRUB y otros componentes del sistema operativo con sus propios certificados, que ahora forman parte de la cadena de confianza.

Las computadoras se envían con UEFI, que tiene un certificado de plataforma Microsoft en su interior. Este certificado se utiliza para validar otros componentes que forman parte de la cadena de arranque, incluidos los cargadores de arranque shim firmados por Microsoft para otros sistemas operativos como Linux. Luego, los cargadores de arranque shim verifican los cargadores de arranque basados en GRUB que están firmados por los propios responsables de distribución de Linux.

Una vulnerabilidad desencadena toda una auditoría de GRUB

Los investigadores de la firma de seguridad Eclypsium encontraron una vulnerabilidad de desbordamiento del búfer en la forma en que GRUB2 analiza el contenido de su archivo de configuración llamado grub.cfg. Si bien el binario GRUB generalmente está firmado, su archivo de configuración no los está ya que está destinado a ser editado por los administradores del sistema que deseen cambiar las diferentes opciones de cómo se inicializa el sistema operativo o que deseen agregar entradas de inicio, cuando configuran computadoras con múltiples opciones de sistemas operativos.

Al agregar contenido específicamente diseñado en el archivo de configuración, los atacantes pueden aprovechar la vulnerabilidad para ejecutar código malicioso en el contexto del cargador de arranque de confianza, antes de que se inicie el sistema operativo. Esto les da una posición muy privilegiada, así como persistencia en el sistema, y un control total sobre el sistema operativo y su núcleo. Los ataques a nivel de arranque, conocidos como rootkits de arranque o simplemente bootkits, solían ser bastante comunes hace una década y fueron una de las razones principales por las que se creó Secure Boot.

Tales ataques aún existen y pueden apuntar a sistemas que no tienen habilitado Secure Boot. Por ejemplo, los programas de ransomware Petya y NotPetya eran conocidos por encriptar el Master Boot Record (MBR) de las computadoras. Una pandilla cibercriminal, conocida como FIN1, utilizó una utilidad para modificar el Volume Boot Record (VBR) del sistema e iniciar su backdoor, Nemesis, antes de que Windows o el software de seguridad tuvieran la oportunidad de iniciarse completamente.

Secure Boot no es una solución perfecta y, en el pasado, las vulnerabilidades en ciertas implementaciones de UEFI han permitido a los atacantes eludir la verificación, pero esos ataques generalmente se limitaron a fabricantes de computadoras específicos o variantes de UEFI. Sin embargo, la vulnerabilidad GRUB2 encontrada por Eclypsium puede tener un impacto mucho más amplio debido a la versatilidad de GRUB: se puede usar para iniciar diferentes sistemas operativos -incluido Windows, por ejemplo- en configuraciones de arranque dual o múltiple.

Esto significa que si los atacantes desean instalar un bootkit en una computadora con Windows con Secure Boot habilitado pueden reemplazar el cargador de arranque de Windows con un shim firmado de una distribución de Linux y una versión de GRUB2 que tiene esta vulnerabilidad. Luego pueden configurar GRUB2 para iniciar Windows y aprovechar la vulnerabilidad con el fin de obtener persistencia y control del sistema operativo. Esto no romperá la cadena de confianza, porque el cargador de arranque shim de Linux y GRUB2 tendrán firmas válidas y vinculadas a la clave de Secure Boot de Microsoft dentro de UEFI.

Reemplazar el cargador de arranque de Windows con GRUB2 requiere que el atacante tenga privilegios de administrador en el sistema, al igual que modificar el archivo de configuración de GRUB2 en Linux, pero Secure Boot fue diseñado para proteger la integridad del proceso de arranque, incluso en tales casos.

"En primer lugar, uno de los objetivos de diseño explícitos de UEFI Secure Boot es proteger contra este tipo de ataque, incluso cuando alguien ha obtenido privilegios de administrador en el sistema, le comentó el investigador principal de Eclypsium, Jesse Michael, a CSO. "Se supone que el administrador no puede desactivar el Secure Boot sin algún tipo de certificación de presencia física. Al ingresar al BIOS UEFI y elegir las opciones del BIOS, puede desactivar el Secure Boot, pero no se supone que pueda hacerlo desde el runtime dentro del sistema operativo.

La vulnerabilidad encontrada por Eclypsium se rastrea como CVE-2020-10713 y tiene una calificación de 8.2 (alta) en el Common Vulnerability Scoring System (CVSS), pero no es la única. Después de que la compañía informó en privado sobre la vulnerabilidad, los equipos de seguridad de Oracle, Red Hat, Canonical y VMware realizaron una auditoría de seguridad de la base del código GRUB2, la cual resultó en la búsqueda y reparación de docenas de otras vulnerabilidades y operaciones de códigos peligrosos. Algunos de ellos también tienen identificadores CVE (CVE-2020-14308, CVE-2020-14311, CVE-2020-14309 y CVE-2020-14310) pero otros no.

Problemas con la revocación de confianza de Secure Boot

Esta revisión de código fue necesaria porque revocar la confianza en las versiones vulnerables de GRUB2 es un proceso complicado que requiere un gran esfuerzo de colaboración de la industria, por lo que hacerlo cada pocos meses, cuando se encuentra un nuevo defecto, no es práctico. Las distribuciones de Linux actualizarán sus cargadores de arranque para usar una versión actualizada de GRUB2, pero ¿qué evitaría que los atacantes, con acceso de administrador a un sistema, reemplacen la versión actualizada por una versión anterior y vulnerable, que esté firmada con el certificado contenido en el cargador de arranque shim? En otras palabras, ¿qué se requiere para evitar un ataque de degradación en este caso?

Existe un mecanismo establecido, pero no es muy sencillo. El mecanismo de Secure Boot de UEFI tiene una lista de revocación llamada dbx, que puede contener una lista de binarios del cargador de arranque en la lista negra, incluso si están firmados con un certificado válido. Esta lista se almacena en el mismo chip de memoria flash donde se almacena el firmware UEFI, pero se puede actualizar desde el interior del sistema operativo con una utilidad especial que, con el fin de garantizar que las solicitudes de actualización sean legítimas, también utiliza verificación y validación criptográfica.

Todos los cargadores de arranque shim de Linux existentes, o los archivos binarios de GRUB, que se han firmado directamente -no a través de un shim- deben agregarse a esta lista de revocación en cada computadora o dispositivo afectado. Los investigadores de Eclypsium afirman a CSO que la lista de revocación tendrá alrededor de 200 entradas diferentes. Las distribuciones de Linux, cuyos shims se incluirán en la lista negra, deberán obtener nuevas shims firmadas por Microsoft y actualizar sus instaladores, las shims y los cargadores de arranque GRUB2.

Canonical -que mantiene Ubuntu- y Debian son dos excepciones porque usaron certificados intermedios para firmar sus cargadores de arranque, que están vinculados a sus propios certificados CA de confianza UEFI. Solo tienen que revocar y poner en la lista negra su certificado de intermediario, generar uno nuevo y firmar los nuevos cargadores de arranque con él.

"Uno de los problemas que surgió es que el alcance de esto es tan amplio y ha habido muchas partes diferentes involucradas, afirma Michael. "Creo que hay alrededor de 70 personas en uno de los grupos de coordinación que tiene todas las distribuciones y proveedores afectados que hemos identificado hasta ahora. Debido a que esto ha sido tan doloroso, ha habido un esfuerzo por tratar de hacer algunas mejoras en el proceso y arreglar algunos problemas técnicos. Están tratando de impulsar las cosas para que los proveedores configuren las cosas más como Canonical y Debian, donde solo necesitan revocar un solo certificado en lugar de múltiples shims o múltiples instancias de GRUB. Entonces, la idea es que, la próxima vez que esto suceda, queremos que sea menos doloroso.

Otro problema es que este mecanismo de revocación de Secure Boot UEFI no se ha utilizado ampliamente en el pasado y podría tener diferencias de implementación de un sistema a otro o de un proveedor a otro. En febrero, Microsoft lanzó una actualización de Windows que actualizó el dbx UEFI para poner en la lista negra a un cargador UEFI vulnerable incluido con Kaspersky Rescue Disk, que podría usarse para evadir el Secure Boot. La actualización provocó fallas de arranque en algunas computadoras y Microsoft se vio obligado a detenerlo.

En este nuevo caso, la actualización de revocación que será firmada por Microsoft será opcional y deberá instalarse manualmente, al menos al principio, para que los administradores puedan probarlos en todo tipo de dispositivos.

"Si usted es un administrador de TI para un ambiente empresarial, querrá probar esto en cada modelo que haya implementado en su ambiente antes de sacarlo, comenta Michael a CSO. "Asegúrese de que no haya problemas de compatibilidad. Los discos de rescate, o los datos y los medios de recuperación en caso de desastre, así como las imágenes doradas y las imágenes de instalación que tienen las aplicaciones específicas de la empresa, también necesitarían actualizarse y estar listas para funcionar antes de que las envíe, porque si usted las envía a alguien en su campo, un sistema se cae y los medios de rescate no arrancan. Va a tener un mal día, o tal vez exista un contexto de arranque de red que las personas tienen en el centro de datos, donde el Secure Boot está activado, pero están haciendo un arranque de red, por lo que los medios de arranque también deben actualizarse.