Nuevo error neutraliza el arranque seguro, pero no hay necesidad de entrar en pánico. Este es el por qué


  Un gusano de dibujos animados sonríe desde una placa base.

GRUB2, uno de los programas de inicio de computadoras más utilizados en todo el mundo, tiene una vulnerabilidad que podría permitir a los atacantes ejecutar firmware malicioso en el inicio. Los investigadores dijeron el miércoles. Esto afectaría a millones o posiblemente a cientos de millones de máquinas. Si bien GRUB2 se usa principalmente en computadoras con Linux, las vulnerabilidades que aprovechan la vulnerabilidad también se pueden llevar a cabo en muchas computadoras con Windows.

La vulnerabilidad, descubierta por investigadores de la empresa de seguridad Eclypsium, es otra amenaza grave para el arranque seguro UEFI: un estándar de toda la industria que utiliza firmas criptográficas para garantizar que el software utilizado en el arranque sea confiable por un fabricante de computadoras. es clasificado. El Arranque seguro se desarrolló para evitar que los atacantes hagan un mal uso del proceso de arranque al reemplazar el software deseado con software malicioso.

Sigiloso, poderoso y difícil de desinfectar.

Los llamados kits de arranque se encuentran entre los tipos más graves de infecciones porque se ejecutan en el nivel más bajo de la pila de software. Como resultado, el malware se puede usar mejor que la mayoría de los otros programas de malware, sobrevivir a las nuevas instalaciones del sistema operativo y eludir las medidas de seguridad integradas en el sistema operativo.

Boot Hole, como lo llamaron los investigadores la vulnerabilidad, se basa en un desbordamiento del búfer en la forma en que GRUB2 analiza el texto en grub.cfg, el archivo de configuración principal para el cargador de arranque. Al agregar largas cadenas de texto al archivo, los atacantes pueden llenar en exceso el espacio asignado para el archivo y hacer que el código malicioso llegue a otras partes de la memoria, donde luego se ejecuta.

El archivo de configuración no está firmado digitalmente. El Arranque seguro no reconoce si se ha cambiado de forma malintencionada. GRUB2 tampoco utiliza la aleatorización del diseño del espacio de direcciones, la prevención de ejecución de datos y otras medidas de protección contra exploits que son estándar en los sistemas operativos. Estas omisiones hacen que sea trivial para los atacantes que ya se han establecido en la computadora de destino aprovechar el error. A partir de ahí, pueden omitir por completo cualquier protección que muchas personas esperan para evitar que los kits de arranque se agarren.

Además del informe Eclypsium, Debian proporciona una descripción general sólida aquí.

Pero hay algunos problemas importantes.

Sin embargo, la gravedad de la vulnerabilidad se compensa con algunas cosas. Primero, el atacante debe tener privilegios administrativos en la computadora o acceso físico a la computadora. El control a nivel de administrador se está volviendo cada vez más difícil de obtener en los sistemas operativos modernos debido al gran progreso realizado en el bloqueo de exploits. El acceso físico puede ser más fácil en los cruces fronterizos o en momentos similares cuando un usuario pierde temporalmente la posesión física de una computadora. Sin embargo, en la mayoría de los otros escenarios, el requisito es alto, por lo que es poco probable que muchos usuarios se vean afectados. Además, la posesión física limita severamente la escalabilidad de los ataques.

Otros dos factores que hacen que Boot Hole sea menos aterrador: los atacantes que ya tienen control administrativo o físico sobre una computadora tienen muchas otras opciones para infectarla con malware avanzado y sigiloso. También hay varias otras técnicas conocidas para evitar el arranque seguro.

"Yo diría que Secure Boot no es la base de la seguridad de la PC hoy en día porque rara vez es efectivo y, según la compañía, [Eclypsium’s] ha sido fácil de solucionar durante más de un año sin una solución a largo plazo a la vista". HD Moore, vicepresidente de investigación y desarrollo de Atredis Partners y experto en uso de software, me lo dijo. "No estoy seguro de para qué es útil el desbordamiento del búfer en GRUB2, ya que hay otros problemas si el archivo grub.cfg no está firmado". "Puede ser útil como un vector de malware, pero aun así no hay necesidad de explotar un desbordamiento del búfer si se puede usar un archivo grub.cfg personalizado para cargar en cadena el sistema operativo real".

Otros investigadores parecen estar de acuerdo con la evaluación. CVE-2020-10713 tiene una gravedad media porque se está rastreando la vulnerabilidad.

La acusación de Eclypsium mencionada por Moore involucra la revocación de una compañía de seguridad de cargadores de arranque que Kaspersky Lab usó para lanzar un disquete de rescate en computadoras deshabilitadas. La revocación causó tantos problemas que Microsoft, que supervisa el proceso de validación, deshizo el cambio. La revocación no solo resalta la dificultad de corregir errores como el agujero de arranque (más sobre eso más adelante), sino también el hecho de que ya es posible evitar el arranque seguro.

No da miedo significa no serio

Los obstáculos y las restricciones a la explotación no significan que no valga la pena tomarse en serio la vulnerabilidad. Secure Boot se creó exactamente para el escenario requerido para aprovechar Boot Hole. El riesgo aumenta por la cantidad de fabricantes de computadoras y software afectados. Eclypsium tiene una lista más completa de personas afectadas. Estos son:

  • Microsoft
  • Foro de interfaz de firmware extensible unificado
  • Oracle
  • Red Hat (Fedora y RHEL)
  • Canonical (Ubuntu)
  • SuSE (SLES y openSUSE)
  • Debian
  • Citrix
  • VMware
  • Varios fabricantes de computadoras
  • Vendedores de software, incluido el software de seguridad

Otra consideración seria es el desafío de sacar actualizaciones que no impidan permanentemente que una máquina arranque, un fenómeno a menudo llamado "ladrillo" designado. Como muestra el incidente de Kaspersky, el riesgo es real y puede tener graves consecuencias.

Arreglar el caos es un caos en sí mismo.

Las soluciones implican un proceso de varios pasos que no es trivial o, en muchos casos, rápido. GRUB2 primero debe actualizarse para abordar la vulnerabilidad y luego distribuirse a proveedores o administradores de grandes organizaciones. Allí, los ingenieros deben probar a fondo la actualización para cada modelo de computadora que admitan para asegurarse de que la máquina no se bloquee. Las actualizaciones deben repararse para las computadoras que hacen esto. Solo entonces se puede instalar la actualización en general.

Incluso entonces, es trivial para los atacantes con los privilegios descritos anteriormente restablecer GRUB2 a su versión vulnerable y explotar el desbordamiento del búfer. Aunque GRUB2 normalmente no está instalado en computadoras con Windows, los atacantes privilegiados generalmente pueden instalarlo. Para llenar este vacío, los fabricantes de computadoras deben revocar las firmas criptográficas que validan la versión anterior o el firmware de shim que carga la versión anterior.

Con este paso también existe el peligro de que las máquinas sean tapiadas. Si las firmas se revocan antes de instalar la versión GRUB2, o para las firmas de computadoras con Windows para otros componentes de inicio, antes de que se realicen pruebas exhaustivas, existe el riesgo de que millones de computadoras también se bloqueen.

Para evitar esta posibilidad, Microsoft, Red Hat, Canonical y otros fabricantes de sistemas operativos y hardware generalmente ofrecen soluciones en dos pasos. Primero, la actualización GRUB2 se lanzará después de que se haya probado y calificado como seguro para la instalación. Las firmas se revocarán luego de un período de posiblemente meses. La vulnerabilidad no se soluciona hasta que se completa el segundo paso.

Microsoft, que opera la CA que certifica las firmas UEFI autorizadas por el fabricante, hizo la siguiente declaración:

Se abordó una vulnerabilidad en el GRand Unified Boot Loader (GRUB), a menudo utilizado por Linux. Para aprovechar esta vulnerabilidad, un atacante debería tener privilegios administrativos o acceso físico a un sistema en el que el Arranque seguro está configurado para confiar en la autoridad de certificación UEFI de Microsoft. Estamos trabajando para completar las pruebas de validación y compatibilidad de un paquete de Windows Update requerido.

Un portavoz de Microsoft dijo que la compañía proporcionaría a los administradores de TI que lo necesitan una "opción de mitigación para instalar una actualización no probada". En un momento no especificado, dijo el portavoz, Microsoft lanzará una solución para la disponibilidad general. Microsoft ha publicado un artículo de base de conocimiento aquí.

Las recomendaciones de otras compañías afectadas son demasiado numerosas para proporcionarlas en la primera versión de este artículo. Por ahora, los lectores deben revisar los sitios web de las empresas afectadas. Esta publicación se actualizará más adelante para proporcionar enlaces.

Actualmente no hay necesidad de entrar en pánico. Los altos requisitos para las vulnerabilidades hacen que la gravedad de esta vulnerabilidad sea moderada. Y como se mencionó anteriormente, el arranque seguro ya es vulnerable a otras técnicas de derivación. Esto no significa que no haya razón para tomar en serio esta vulnerabilidad. Parchelo lo antes posible, pero solo después de pruebas exhaustivas, ya sea por usuarios experimentados o por fabricantes de software y sistemas operativos afectados. Mientras tanto, no pierdas el sueño.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *