Los navegadores web están instalados en miles de millones de dispositivos en todo el mundo, lo que los convierte en objetivos prioritarios para los ciberdelincuentes. Dado que los principales navegadores web cuentan con una enorme base de usuarios, una sola vulnerabilidad puede tener consecuencias de gran alcance. Mantener los navegadores actualizados es fundamental para protegerse contra las amenazas en constante evolución.
Para ilustrar la gravedad de las vulnerabilidades en los navegadores web, nuestros compañeros han llevado a cabo un análisis exhaustivo de CVE-2024-6778, una vulnerabilidad presente en los navegadores basados en Chromium que afecta especialmente a Chrome DevTools. En este blog se ofrece un análisis detallado de los aspectos técnicos de la vulnerabilidad, su posible impacto y las estrategias de mitigación.
Antecedentes de CVE-2024-6778
CVE-2024-6778 es una vulnerabilidad de condición de carrera descubierta en Chrome DevTools. Permite a los atacantes inyectar código HTML o JavaScript malicioso en páginas del navegador con privilegios a través de extensiones maliciosas del navegador. Según la NVD (Base de Datos Nacional de Vulnerabilidades), esta vulnerabilidad ha sido clasificada como de alta gravedad, con una puntuación CVSS de 8,8.
El alto nivel de gravedad de esta vulnerabilidad se debe a que puede permitir la ejecución remota de código, lo que puede dar lugar a la compromisión de los sistemas, el menoscabo de la confidencialidad y la reducción de la disponibilidad.
Descripción general de la seguridad de Chromium
Para comprender mejor las implicaciones de CVE-2024-6778, es importante conocer los aspectos clave del modelo de seguridad de Chromium. Chromium es la base de código abierto de navegadores como Google Chrome, Microsoft Edge, Opera y Brave. Emplea un modelo multiproceso en el que cada pestaña, también denominada «renderizador», y diversos componentes del navegador se ejecutan en procesos aislados para mejorar la estabilidad y la seguridad al limitar el alcance de posibles vulnerabilidades.
Un elemento fundamental de la seguridad de Chromium es su mecanismo de sandboxing, que impide que los procesos del renderizador accedan directamente a los recursos del sistema. En su lugar, todas las interacciones se gestionan a través de canales de comunicación entre procesos (IPC) para garantizar que solo se realicen operaciones autorizadas.
No todos los componentes de Chromium están sujetos a un aislamiento completo. Las páginas de la interfaz de usuario web, como chrome://settings y chrome://downloads, se representan en los procesos de renderizado, pero funcionan con restricciones de aislamiento parciales. Este proceso les permite acceder a las API del navegador a las que normalmente no se puede acceder a través de la web.
Por ejemplo, la página chrome://policy desempeña un papel fundamental en entornos empresariales, ya que permite a los administradores y a los usuarios configurar y aplicar políticas de seguridad del navegador. Estas políticas también se gestionan a través de la Política de grupo en los sistemas Windows.
Dado que chrome://policy puede interactuar directamente con el sistema operativo, constituye un objetivo muy atractivo para los atacantes. Aprovechando la vulnerabilidad CVE-2024-6778, que se basa en una condición de carrera dentro de Chrome DevTools, los atacantes pueden inyectar código malicioso en estas páginas, lo que supone graves riesgos de seguridad.
Análisis técnico de CVE-2024-6778
Descubrimiento
Esta vulnerabilidad se descubrió en una función de prueba introducida en la versión 117 de Chrome Enterprise. Esta función permite realizar pruebas de políticas a través de la página chrome://policy/test. Debido a la escasa documentación oficial sobre esta función, nuestros compañeros llevaron a cabo un análisis exhaustivo del código fuente de Chromium, complementado con la información proporcionada por el autor del CVE, con el fin de comprender plenamente su implementación e identificar las vulnerabilidades de seguridad asociadas.
Componentes de la gestión de políticas
El análisis del código fuente realizado por OPSWAT de OPSWAT reveló que dentro de chrome://policy/test, las políticas se gestionan mediante el Información sobre políticas interfaz y se comunicaban entre los procesos de la interfaz de usuario web y del navegador a través de la PolicyTestBrowserProxy clase. La Información sobre políticas La estructura se define de la siguiente manera:
Tras un análisis más detallado de la clase encargada de gestionar estas políticas, se identificó un método denominado aplicar políticas de prueba. Este método utiliza una API privada, establecer políticas de prueba locales, para aplicar dinámicamente una lista de políticas.
Para comprender cómo se procesan las solicitudes de políticas a través de esta API, los becarios analizan el Gestionar políticas de prueba locales método dentro del PolicyUIHandler clase:
El Gestionar políticas de prueba locales El método recupera los datos de la política a partir de los argumentos proporcionados y obtiene un puntero al Proveedor de políticas de prueba local por ejemplo, a través del conector de políticas globales del navegador. A continuación, comprueba si existe dicho proveedor antes de indicar al perfil de usuario actual que lo utilice.
Se consideró que esta verificación era insuficiente, ya que solo garantiza que proveedor_de_pruebas_local no sea nulo antes de aplicar las políticas. La creación e inicialización de proveedor_de_pruebas_local están controlados por el Crear si está permitido método:
Dentro de la Crear si está permitido método, el valor de retorno depende totalmente del resultado de la ¿Está habilitada la comprobación de políticas? función. Esta función determina si un Proveedor de políticas de prueba local La instancia se crea en función de una combinación de las preferencias del usuario y el canal de lanzamiento del navegador:
Dado que servicio_preferido se establece sistemáticamente en «null» cada vez que ¿Está habilitada la comprobación de políticas? Cuando se invoca, se omite la primera condición, por lo que la decisión de habilitación depende exclusivamente del canal de lanzamiento del navegador.
En las versiones de Chromium sin marca, el canal de lanzamiento predeterminado es Canal::DESCONOCIDO. Según la lógica de la función, Canal::DESCONOCIDO se trata de la misma manera que Canal::DEFAULT, que habilita la función de comprobación de políticas de forma predeterminada. El análisis del flujo de código reveló que la API privada establecer políticas de prueba locales se puede invocar a través de la interfaz de usuario web para aplicar políticas sin restricciones de acceso significativas.
Explotación
Al identificar y aprovechar esta API privada, un atacante puede aplicar políticas de forma arbitraria a través de la interfaz de usuario web, lo que le permite manipular ajustes como BrowserSwitcher activado, Lista de direcciones URL de cambio de navegador, Ruta alternativa del navegador, y Parámetros alternativos del navegador para ejecutar comandos. Por ejemplo, configurando Ruta alternativa del navegador en PowerShell y Parámetros alternativos del navegador a ["calc"], se pueden ejecutar comandos arbitrarios de la línea de comandos al visitar una URL concreta.
Aplicar una política de usuario malintencionado arbitraria a través de API privada
Para mostrar cómo se pueden aplicar las políticas utilizando el sector privado establecer políticas de prueba locales API en el análisis anterior, el siguiente código JavaScript es un script que establece el Habilitar el huevo de Pascua del dinosaurio política y la aplica de manera eficaz a través de la Interfaz de usuario web mediante la invocación de establecer políticas de prueba locales:
La política se puede aplicar correctamente para desactivar el Habilitar el huevo de Pascua del dinosaurio configuración.
Para lograr un mayor impacto, un atacante podría dirigirse a la Cambiador de navegador política:
Esta política permite al navegador invocar una ruta alternativa si la URL cumple determinadas condiciones. Se puede aprovechar configurando esta ruta para que apunte a un ejecutable del sistema con el fin de ejecutar comandos del sistema operativo. El siguiente código JavaScript ilustra este enfoque:
Este script realiza las siguientes tareas:
- Habilita la
Cambiador de navegadorfunción para example.com - Establece la ruta alternativa del navegador para PowerShell
- Ejecuta
calccada vez que se acceda a la URL indicada.
Simulación de una extensión maliciosa de Chrome
La identificación de API privada API permite aplicar políticas supone un importante vector de ataque para los atacantes. Para aprovechar eficazmente esta vulnerabilidad, un atacante tendría que desarrollar una extensión maliciosa de Chrome que utilice la API de Chrome DevTools API ejecutar código JavaScript malicioso.
Para demostrar el impacto potencial en el mundo real, nuestros becarios simularon un escenario en el que se instala una extensión maliciosa de Chrome en un navegador vulnerable y se utiliza para ejecutar el ataque. Las API de chrome.devtools en las extensiones de Chrome permiten a los desarrolladores ampliar e interactuar con la interfaz DevTools de Chrome.
Sin embargo, la ejecución de API de DevTools API una extensión plantea ciertos retos que deben superarse. En primer lugar, la API de DevTools solo API cuando DevTools está abierto y está inspeccionando activamente un sitio web. En segundo lugar, la API de DevTools API la ejecución de código en la interfaz de usuario web (WebUI). Esta limitación contribuye a mantener la seguridad y la integridad de la WebUI durante los procesos de desarrollo e inspección.
Señales que indican la ejecución de JavaScript a través de API de recarga
Un análisis más detallado reveló que la función `chrome.devtools.inspectedWindow.reload` carece de la verificación necesaria para confirmar si una extensión tiene permiso para ejecutar scripts en la página inspeccionada. Su única medida de protección es el servidor de extensiones de DevTools, que bloquea el acceso en cuanto cambia la URL de la página inspeccionada.
Las páginas «about:blank» heredan los permisos y el origen de la página que las abrió. Esto significa que la posibilidad de ejecutar código en «about:blank» al ser redirigido desde las señales de la interfaz de usuario web constituye una posible vulnerabilidad.
Ejecución de código en la interfaz de usuario web mediante API de recarga
La condición de carrera en chrome.devtools.inspectedWindow.reload() permite la ejecución de código en las páginas de la interfaz de usuario web de Chrome (por ejemplo, chrome://policy), que suelen estar protegidas. El exploit aprovecha la capacidad de API de recarga para inyectar código JavaScript durante las transiciones entre páginas. Así es como funciona:
- Interfaz web de destino: abre una página de la interfaz web (por ejemplo, chrome://policy) en una pestaña y activa DevTools.
- Injectar script: Utiliza la API reload() API un
script inyectadoparámetro para ejecutar código JavaScript arbitrario durante la recarga. - Aprovechamiento de una condición de carrera: La condición de carrera se produce cuando la recarga se activa antes de que los mecanismos de seguridad de la interfaz web se hayan inicializado por completo, lo que permite que se ejecute el script inyectado.
Al pasar de la página «about:blank» a «chrome://policy»:
Dado que solo se verifica la URL y no el origen de la página, tras la navegación se produce un breve lapso en el que el origen refleja la nueva página, mientras que la URL permanece sin cambios.
Si chrome.devtools.inspectedWindow.reload Si se invoca durante este intervalo, podría ejecutarse JavaScript en la página de destino sin que sea esa la intención.
Mejora de la fiabilidad en condiciones de carrera
Aprovechar la condición de carrera es intrínsecamente poco fiable debido a que depende del momento en que se produce. Además, las recargas rápidas o los scripts con errores pueden provocar fallos en la página. Un enfoque novedoso para mejorar la fiabilidad consiste en provocar intencionadamente un fallo en la página, ya que los comandos emitidos a través de DevTools suelen cancelarse durante un fallo, pero Actualizar página asignado a chrome.devtools.inspectedWindow.reload() se incluye en la lista blanca y se ejecuta tras la recarga de la página.
A continuación se muestra un modelo de flujo de trabajo para provocar un fallo en una página mediante la ejecución de una serie de comandos:
Una instrucción de depuración en un script de contenido puede provocar un fallo del sistema
El uso del depurador dos veces seguidas interrumpe el proceso de navegación en un script de contenido. Esto puede provocar un fallo al colocar estado_de_confirmación_de_navegación_ a un estado imprevisto. Este problema surge cuando RenderFrameImpl::Confirmación sincrónica de un valor nulo para el error 778318 se ejecuta, modificar _navigation_commit_state a un valor inesperado.
La primera invocación detiene la ejecución, dejando estado_de_confirmación_de_navegación_ en un estado inconsistente, y el segundo se detiene durante el COMPROBAR_EQ comprobación, que no supera la validación de estado y provoca un fallo del sistema.
Remediación
Si no actualizas periódicamente la versión de tu navegador, tu dispositivo puede quedar expuesto a graves amenazas de seguridad, especialmente aquellas relacionadas con los CVE (vulnerabilidades y exposiciones comunes). Para ayudar a mitigar este riesgo, MetaDefender ofrece una protección sólida al detectar la versión de tu navegador y comprobar si hay vulnerabilidades, incluidas las CVE conocidas, como la CVE-2024-6778.
MetaDefender Endpoint su aplicación esté actualizada y señala cualquier versión obsoleta o infectada. Además, muestra una lista de las aplicaciones instaladas que presentan vulnerabilidades conocidas, clasificadas según la gravedad del CVE, y recomienda soluciones para mitigar de forma eficaz las posibles amenazas. Si desea ver una demostración en directo sobre cómo MetaDefender Endpoint ayudarle a mitigar esos riesgos, póngase en contacto con uno de nuestros expertos hoy mismo.
