El senador Wyden insta a los federales a descartar las VPN más antiguas, inseguras y de acceso público

El senador Ron Wyden imploró el lunes a un trío de líderes federales que encabezaran una campaña integral para purgar las redes privadas virtuales más antiguas e inseguras a las que se puede acceder directamente a través de la Internet pública desde las agencias federales.

“Durante demasiado tiempo, las agencias federales y los contratistas gubernamentales han sufrido ciberataques devastadores debido a su dependencia de servidores VPN heredados, inseguros y con acceso a Internet para otorgar a los empleados acceso remoto”, Wyden, demócrata de Oregon. escribió en su misiva a altos funcionarios de la Oficina de Gestión y Presupuesto, la Agencia de Seguridad de Infraestructura y Ciberseguridad y el Instituto Nacional de Estándares y Tecnología. Deberían coordinar “exigir la adopción de tecnología de acceso remoto moderna y segura en todo el gobierno federal”, dijo.

Estas VPN sirven como una “puerta de entrada” digital accesible a través de la Internet pública que permite que los dispositivos móviles y los empleados remotos inicien sesión, dijo Wyden en una carta reportada por primera vez por CyberScoop.

Wyden hizo referencia a varios ataques que han afectado a agencias federales, incluidos los ataques ArcaneDoor a los firewalls de Cisco, las exposiciones de credenciales FortiBleed en las puertas de enlace de Fortinet y las vulnerabilidades que los piratas informáticos explotaron en los dispositivos VPN de Ivanti y Check Point.

«Las soluciones modernas de acceso remoto eliminan por completo esta vulnerabilidad. En lugar de dejar una puerta abierta accesible desde la Internet pública, las soluciones modernas brindan acceso remoto sin difundir su presencia», afirmó. «Esto efectivamente hace que estos servidores sean invisibles, asegurando que los piratas informáticos no puedan atacar un punto de entrada que no pueden ver».

Las agencias deberían alejarse de lo que un informe del Servicio de Investigación del Congreso a Wyden llamó un enfoque de “castillo y foso” de asumir que cualquier persona dentro de la red está autorizada a acceder a los recursos de una organización de los que dependen las VPN al extender puentes virtuales a una fuerza laboral más remota, dijo. En cambio, deberían centrarse en una arquitectura de confianza cero que utilice un enfoque de nunca confiar y siempre verificar, dijo.

Además, CISA, OMB y NIST deben cambiar fundamentalmente la forma en que el gobierno federal aborda las vulnerabilidades de las agencias, escribió Wyden.

«El gobierno federal ha quedado atrapado en un interminable juego de 'golpear al topo' en respuesta a compromisos generalizados de las tecnologías heredadas de acceso remoto», afirmó. «Para mantener las redes federales en línea, CISA se ha visto obligada a emitir repetidamente directivas de emergencia extraordinarias y mandatos de parches hiperacelerados. Estos mandatos de emergencia reactivos son insostenibles para los equipos federales de ciberseguridad y no abordan la cuestión fundamental de que estos fallos son inherentes al uso de dispositivos heredados de acceso remoto».

CISA necesita emitir una directiva operativa vinculante que dé a las agencias dos años para eliminar por completo los sistemas heredados de acceso remoto de cara al público, dijo. El NIST necesita emitir estándares de implementación para la transición a arquitecturas de confianza cero.

La OMB necesita emitir un memorando que indique a las agencias que prioricen el gasto en arquitectura de confianza cero. Y OMB necesita trabajar en equipo con CISA y el Departamento de Defensa para actualizar las reglas de adquisiciones para impedir que las agencias y los contratistas de defensa compren soluciones de borde de red, VPN u otras soluciones de acceso remoto a menos que un proveedor proporcione una certificación de que cumple con los estándares de confianza cero del NIST, escribió Wyden.

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

11 antiguas cuñas UEFI de Linux firmadas por Microsoft podrían permitir a los atacantes evitar el arranque seguro – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto 11 aplicaciones antiguas de Interfaz de firmware extensible unificada (UEFI) firmadas por Microsoft de las que se podría abusar para evitar el arranque seguro en la mayoría de los sistemas que utilizan el estándar de firmware moderno.

«Un atacante que explote una de estas aplicaciones vulnerables puede ejecutar código que no es de confianza durante el arranque del sistema, permitiendo la implementación de bootkits UEFI maliciosos u otro malware», dijo el investigador de ESET Martin Smolár. dicho en un informe publicado hoy.

Los cargadores de arranque UEFI exponen cualquier máquina basada en UEFI que confíe en Microsoft «Corporación Microsoft UEFI CA 2011«Certificado de autoridad certificadora (CA) UEFI de terceros, independientemente del sistema operativo instalado. El certificado se utiliza para firmar componentes de arranque de terceros destinados a ejecutarse bajo arranque seguro. Expiró el 27 de junio de 2026 y ha sido reemplazado por Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.

El shim es un gestor de arranque UEFI liviano y de código abierto que actúa como intermediario entre el firmware de la placa base de una computadora y el sistema operativo Linux. Su objetivo principal es permitir que las distribuciones de Linux se inicien cuando el arranque seguro está habilitado. Vale la pena señalar que el shim en sí está firmado con una clave en la que confía el firmware, principalmente una firma de Microsoft, ya que sus certificados vienen preinstalados en dispositivos basados ​​en UEFI.

Ciberseguridad

La secuencia procede de la siguiente manera: el firmware UEFI carga el shim y valida su firma con la CA de Microsoft almacenada en el firmware. Luego, el shim valida el cargador de arranque de segunda etapa (en la mayoría de los casos, GRUB 2) con su propio certificado de proveedor integrado. GRUB 2 finalmente valida el kernel utilizando el mismo certificado de proveedor.

La compañía eslovaca de ciberseguridad dijo que los shims, obsoletos pero confiables, pueden explotarse para ejecutar código arbitrario cuando se inicia el sistema, lo que permite a los delincuentes implementar kits de arranque UEFI como Bootkitty, HybridPetya o BlackLotus incluso cuando las protecciones de arranque seguro están habilitadas.

Desde entonces, Microsoft ha revocado los gestores de arranque UEFI del proyecto shim de código abierto, principalmente de la versión 0.9 y anteriores, como parte de su Actualización del martes de parches de junio de 2026 tras la divulgación responsable a principios de febrero. La lista de los cargadores de arranque afectados se encuentra a continuación:

  • Spyrus WTGCreator del cargador de cuñas UEFI (0.7 o inferior)
  • RedHat RedHat Enterprise Linux (7.2) desde el cargador de cuñas UEFI (0.9)
  • RedHat CentOS (7.2) del cargador de cuñas UEFI (0.9)
  • Software Baramundi baramundi Management Suite (hasta 2024R1) desde UEFI shim loader (0.8)
  • WhiteCanyon/Blancco WipeDrive (8.0.0 a 8.1.3) del cargador de cuñas UEFI (0.7)
  • Junta de Examen de Matriculación de Finlandia Abitti 1 (1.0) del cargador de cuñas UEFI (0.8)
  • NTC IT ROSA, LLC ROSA Linux (R10, R9) del cargador de cuñas UEFI (0.9)
  • Oracle America, Inc. OracleLinux (7.2) del cargador de cuñas UEFI (0.9)
  • PC-Doctor, Inc. Centro de servicio PC Doctor (15, 16) del cargador de cuñas UEFI (0.9)
  • OpenSuse OpenSuse UEFI Cargador de cuñas (0.9)
  • OpenSuse OpenSuse Shim (2.1) del cargador UEFI Shim (0.9)

Una consecuencia de esta laguna jurídica es que un atacante podría aprovechar estos cargadores de arranque shim susceptibles para eludir los mecanismos de seguridad más nuevos haciendo uso de la técnica de ataque «traiga su propio controlador vulnerable» (BYOVD) para ejecutar código arbitrario durante la fase de arranque inicial, incluso antes de que se inicialice el sistema operativo.

Los sistemas Linux también vienen con una característica de seguridad llamada lista de permitidos de clave de propietario de máquina (MOK) que permite a los usuarios autorizar la carga de controladores no firmados mientras UEFI Secure Boot está activo. Aunque se introdujo una lista de denegados MOK en la versión 0.9 de shim como una forma de revocar certificados de firma antiguos asociados con un binario UEFI vulnerable y volver a firmar versiones parcheadas.

En este contexto, un atacante podría reemplazar el shim actualizado de la víctima con un shim UEFI más antiguo firmado por Microsoft y evitar la aplicación de la lista de denegados MOK aprovechando el hecho de que la lista de permitidos todavía confía en el certificado antiguo. Esto, a su vez, podría permitir que el shim de un atacante cargue binarios vulnerables sin restricciones y obtenga la ejecución de código arbitrario.

Eso no es todo. El ataque también subvierte el Secure Boot Advanced Targeting (SBAT), que está diseñado para revocar componentes de arranque vulnerables en lugar de mantener una enorme lista de bloqueo de hashes criptográficos individuales correspondientes a cada archivo. Dicho de otra manera, el mecanismo se utiliza para actualizar la generación mínima aceptable cada vez que se descubre una vulnerabilidad en un componente de la cadena de arranque. Si un intento de arranque utiliza una versión anterior y vulnerable, el sistema lo bloquea y arroja un error.

El Centro de Coordinación CERT (CERT/CC), en un aviso emitido el mes pasado, dijo que los cargadores de arranque específicos del proveedor no se han actualizado para abordar las vulnerabilidades en el proyecto ascendente después de que se conocieron públicamente y se solucionaron.

«Como resultado, los cargadores de arranque vulnerables permanecieron firmados y confiables para los sistemas de arranque seguro porque no habían sido revocados a través de la lista de revocación DBX firmada por Microsoft», dijo. anotado. «Esto creó una exposición a largo plazo en la cadena de suministro en la que los componentes de arranque obsoletos y vulnerables aún podían ejecutarse en sistemas completamente parcheados».

Ciberseguridad

El resultado es que un atacante con privilegios administrativos o la capacidad de modificar el proceso de arranque podría abusar de uno de los cargadores de arranque vulnerables mencionados anteriormente para eludir las protecciones de arranque seguro y ejecutar código arbitrario antes de que se cargue el sistema operativo, allanando el camino para una persistencia arraigada que puede sobrevivir a los reinicios del sistema operativo y, en algunos casos, a su reinstalación.

Debido a que todo esto ocurre antes de que se inicialicen el sistema operativo y los productos de seguridad, el código malicioso ejecutado a través de los cargadores de arranque también puede eludir la detección mediante controles de seguridad integrados y soluciones de detección y respuesta de endpoints (EDR).

Los problemas se rastrean bajo los identificadores CVE. CVE-2026-8863 y CVE-2026-10797, este último haciendo referencia a un problema de larga data en una corrección que permitía omitir el mecanismo de revocación basado en certificados modificando el encabezado de firma del gestor de arranque de la segunda etapa.

ESET ha advertido que la caducidad del certificado «Microsoft Corporation UEFI CA 2011» no influye en el proceso de verificación de Secure Boot siempre que los gestores de arranque firmados con el certificado caducado no sean revocados explícitamente mediante hash.

«Lo que hace que estas viejas correcciones sean peligrosas no es una vulnerabilidad novedosa, es que no se necesita ninguna vulnerabilidad nueva para evitar el arranque seguro UEFI», dijo ESET. «Un atacante no necesita primitivos de explotación complicados: solo una copia de un binario shim antiguo, aún confiable, pero no revocado y una comprensión básica de cómo funcionan los shims UEFI. Eso es suficiente para eludir una característica de seguridad tan esencial como UEFI Secure Boot».