Descubren vulnerabilidad de RCE con un clic en el software de drivers preinstalado de ASUS

• Se descubrió una vulnerabilidad de ejecución remota de código (RCE) con un clic en el software DriverHub de ASUS
• Debido a una validación débil del origin en local, un sitio web malicioso puede lograr ejecución con privilegios de administrador mediante RPC
• Al abusar del endpoint UpdateApp, es posible ejecutar código malicioso combinando un ejecutable firmado por ASUS con un archivo ini manipulado
• La vulnerabilidad fue divulgada como CVE-2025-3462 y CVE-2025-3463, y ASUS distribuyó un parche rápidamente
• Al momento del reporte de la vulnerabilidad, no se confirmó explotación real, y ASUS recompensó con una mención en el salón de la fama en lugar de bug bounty

---

Introduction

• Todo comenzó con una historia sobre la compra de nuevos componentes para PC
• Al comprar una motherboard ASUS, la opción de instalación automática de software desde el BIOS viene activada por defecto
• Por no desactivar la opción por accidente, después de iniciar sesión en Windows apareció una solicitud de permiso para instalar DriverHub
• Como necesitaba el driver de WiFi, por curiosidad instaló DriverHub

DriverHub

• DriverHub es un proceso en segundo plano que funciona sin GUI
• Se comunica con driverhub.asus.com para indicar qué drivers necesitan instalación o actualización
• En local ofrece una API HTTP (puerto 53000) vía RPC
• El sitio web puede enviar solicitudes API a este servicio local para gestionar directamente los drivers
• Se identificó que si la seguridad era deficiente, un atacante podría enviar solicitudes arbitrarias

Finding the Vulnerability

• Se probó si un sitio web podía enviar solicitudes RPC arbitrarias al backend de DriverHub
• Estaba diseñado para responder solo cuando el Origin fuera “driverhub.asus.com”
• Se confirmó que la verificación de Origin se hacía con un match tipo wildcard como origin.includes("driverhub.asus.com")
• Al cambiar el Origin a “driverhub.asus.com.mrbruh.com”, se descubrió que la solicitud era permitida
• Con esto se confirmó un riesgo grave: un atacante podía hacer llamadas RPC desde un sitio malicioso

The Extent of the Damage

• Mediante reversing y análisis de JavaScript se identificó la lista de endpoints de API disponibles en segundo plano
• Endpoints principales:
  • Initialize: devuelve el estado e información de instalación
  • DeviceInfo: devuelve software ASUS instalado, drivers, hardware y dirección MAC
  • Reboot: realiza un reinicio inmediato
  • Log: devuelve un conjunto de archivos de registro
  • InstallApp: instala una app o driver del ID especificado
  • UpdateApp: descarga y ejecuta un archivo ejecutable desde la URL especificada (si está firmado por ASUS, se ejecuta automáticamente)
• En particular, se observó que UpdateApp podía ser explotado

Achieving RCE

• Se analizó en detalle el endpoint UpdateApp
• El parámetro “Url” exige que incluya .asus.com, aunque existían posibilidades de bypass, y el nombre del archivo depende del final de la URL
• Solo los ejecutables firmados por ASUS se ejecutan automáticamente, pero incluso los archivos no firmados se descargan y no se eliminan
• Se evaluó un ataque de timing para reemplazar el archivo justo antes de su ejecución tras pasar la verificación de firma, pero no era práctico
• Al analizar la estructura del paquete del driver WiFi de ASUS, se identificó que la propiedad SilentInstallRun de AsusSetup.ini podía usarse para ejecutar comandos arbitrarios
• Cadena de ataque final:
  1. El atacante induce el acceso a un sitio web en un subdominio driverhub.asus.com.*
  2. El sitio solicita un calc.exe malicioso mediante UpdateApp (solo se descarga, no se ejecuta)
  3. Solicita un AsusSetup.ini personalizado (SilentInstallRun=calc.exe, también sin ejecución)
  4. Solicita un AsusSetup.exe firmado, que se ejecuta automáticamente con privilegios de administrador y, con la bandera -s, lee el ini y ejecuta calc.exe
• Como resultado, se logra una ejecución remota de código arbitrario (RCE) con privilegios de administrador y con un clic

Reporting Timeline (DD/MM/YYYY)

• 07/04/2025: se descubrió inicialmente la vulnerabilidad
• 08/04/2025: se demostró el RCE y se reportó la vulnerabilidad
• 09/04/2025: se recibió la respuesta automática de ASUS
• 17/04/2025: se distribuyó el parche y se recibió la build corregida
• 18/04/2025: se confirmó que el parche estaba en vivo
• 09/05/2025: se publicaron CVE-2025-3462 (8.4 puntos) y CVE-2025-3463 (9.4 puntos)

Assessing the Damage

• Justo después de reportar la vulnerabilidad, se escribió un script para rastrear certificate transparency
• Se monitoreó el historial de emisión de certificados para subdominios driverhub.asus.com.*
• Tras un mes de monitoreo, aparte de las pruebas propias no apareció ningún sitio que coincidiera con el filtro
• Se confirmó que no había indicios de explotación previa

Bug Bounty

• Se consultó a ASUS si habría pago de bug bounty, pero fue rechazado
• En su lugar, la recompensa fue una mención en el salón de la fama (hall of fame)
• Se añadió una explicación sobre la falta de una política de bounty, pese a que ASUS es una gran empresa

Fun Notes

• Al enviar el formulario de Security Advisory de ASUS, la PoC fue bloqueada por Amazon CloudFront como si fuera una solicitud maliciosa
• Al hacer clic en “Install All” en DriverHub, se fuerza la instalación de otro software (como Norton360, WinRAR, etc.)
• La descripción del CVE es ambigua y no refleja correctamente los hechos, lo que puede llevar a interpretar erróneamente que “desktop/laptop no están afectados” (en realidad, afecta a todos los dispositivos con DriverHub instalado)
• El WiFi sigue sin funcionar, así que fue necesario comprar un adaptador WiFi USB externo
• Para consultas: Signal: paul19.84, correo contact [at] mrbruh.com

[GN⁺]

Opinión de Hacker News

• El resultado de la Responsible Disclosure se siente como un desastre para la humanidad; las empresas tendrían que sufrir dolores más grandes y más frecuentes para tomarse en serio la seguridad de sus clientes. Si descubres un problema y les das un mes junto con la solución para que lo arreglen, para la empresa no es más que otro ticket en el backlog. Pero si la situación termina en las noticias en línea y hasta el CEO tiene que intervenir, encontrarán una solución en cuestión de horas. Claro, al final quienes más sufren son los usuarios, pero de todos modos, con solo comprar ASUS ya están sufriendo.
  • Esta vez la respuesta de ASUS fue relativamente rápida: no negaron el problema, no demandaron a la persona que hizo la ingeniería inversa y aplicaron un parche de inmediato. Antes, este tipo de incidentes podía tardar meses o incluso terminar con la policía involucrada. A la gente común ni siquiera le importan las vulnerabilidades; vivimos en un mundo donde hacen operaciones financieras desde teléfonos que llevan 3 años sin actualizarse. Aunque llenes los medios con temas de CVE, la gente solo se volverá insensible. En Europa, con las nuevas regulaciones, está prohibido vender productos con vulnerabilidades conocidas, así que si ASUS sigue así, las motherboards se les van a quedar acumuladas en las bodegas y los distribuidores no van a querer venderlas. Esto también aplica a los electrodomésticos; por ejemplo, si un lavavajillas tiene una vulnerabilidad, esa industria también podría sufrir un golpe grande.
  • El nombre “Responsible” Disclosure es, irónicamente, una conducta completamente irresponsable. La mayoría de las empresas ni parchean en una semana, ni reconocen el mérito, ni notifican a los usuarios, ni aprenden de sus errores. Una divulgación lenta y limitada más bien incentiva ese comportamiento. Lo realmente responsable es divulgarlo de inmediato, de forma completa y pública. Y si se construye confianza en que la empresa sí responde bien, entonces quizá se podría considerar un aviso previo de unos 5 días hábiles. Llamar “responsible disclosure” a una divulgación lenta y parcial no es más que un juego de palabras.
  • La raíz del problema es la falta de legislación sobre responsabilidad del producto. Los fabricantes de autos tienen obligaciones de retiro, pero sobre las empresas de software y hardware la presión es demasiado débil. Creo que el cliente debería poder recibir un reembolso completo por un producto con una vulnerabilidad (CVE) que no ha sido corregida.
  • Para citar a CGPGrey, la primera solución que se nos ocurre casi siempre es mala y no funciona. Una buena cultura de seguridad debería fomentar no ocultar los problemas internos. Las empresas son codiciosas y esconden todos los problemas de seguridad. Si se divulga todo en cuanto se descubre, incluso problemas que podrían arreglarse en un mes quedarían expuestos ante todos y aumentaría mucho la posibilidad de explotación.
  • Tengo una idea de negocio, aunque quizá ya exista: una plataforma pública o de intermediación que proteja la privacidad del reportante, verifique la explotabilidad real de la vulnerabilidad, haga anuncios públicos en fechas establecidas, y donde las empresas puedan pagar por suscribirse a un feed anticipado de lo que las afecta; ese dinero se usaría para recompensar al reportante, cubrir costos operativos y repartir ganancias. Se parece a un marketplace de bug bounty, pero desde la perspectiva de la empresa sería un poco más hostil. Me pregunto si eso sería legal o si se consideraría extorsión.
  • Sigo insistiendo en que, como en otras industrias, debe existir responsabilidad legal por los defectos del producto. La mayoría de la gente no tolera productos defectuosos salvo por un precio muy bajo, y no hay razón para que el software sea la excepción.
  • Si simplemente se publica la vulnerabilidad al día siguiente, eso sí sería una verdadera motivación. Pasar vergüenza también ayuda a mejorar la siguiente medida de seguridad.
  • Ese tipo de exageraciones como “un desastre para la humanidad” es un ejemplo clásico de cómo arruinar el punto central.
• Le pregunté a ASUS si daban bug bounty y me dijeron que, en su lugar, pondrían mi nombre en el Hall of Fame. Da un poco de amargura, como si fuera un chiste de que ASUS es solo una pequeña startup sin capital para pagar recompensas.
  • Empresas pequeñas como Cisco hacen algo parecido: no pagan nada y solo te ponen el nombre. Cisco incluso se olvidó de su página de avisos de seguridad, así que ni siquiera quedó la oportunidad de recibir reconocimiento.
  • Si no hay bug bounty, la única opción es vender el exploit en el mercado negro o publicarlo por completo.
  • Situaciones como esta hacen que no quiera volver a comprar productos ASUS nunca más.
• La calidad del software de ASUS también es mala, y es una empresa que sigue causando problemas de seguridad. Antes ya hubo incidentes de malware UEFI en motherboards, y además vienen con software innecesario preinstalado que da flojera hasta desinstalar. Hay muchos casos de quejas, así que vale la pena tenerlos en cuenta.
  • No es la primera vez que pasa algo así. Ya hubo casos parecidos antes, y hasta dejé registro en mi antiguo blog.
• Dijeron que no hubo explotación porque solo su propio dominio de prueba (driverhub.asus.com.*) cumplía las condiciones, pero eso solo sería cierto si nadie hubiera registrado por separado un subdominio de driverhub. Si se aplicara un wildcard, podría no aparecer en los logs de transparencia de certificados y sí permitir explotación.
  • Los certificados wildcard solo cubren subdominios de un nivel. Por ejemplo, *.example.com sirve para test.example.com, pero no para test.test.example.com. Si alguien hubiera usado un wildcard *.asus.com.example.com, entonces driverhub.asus.com.example.com sí podría ser válido.
  • Dijo que era una buena idea y que lo revisó enseguida, y que por ahora no parece haber nada sospechoso con certificados wildcard.
  • Es correcto señalar ese punto ciego de los certificados wildcard. Si un atacante hubiera tenido un certificado wildcard para .example.com, sí habría podido explotar esto fuera del verdadero driverhub.asus.com. Por eso, monitorear únicamente los logs de CT no basta para detectar perfectamente este tipo de vulnerabilidades de toma de control de subdominios.
• Me llamó la atención la parte donde ASUS respondió algo como: “somos una pequeña startup, no tenemos bounty, pero te ponemos en el Hall of Fame”, cuando en realidad es una corporación gigante con una capitalización bursátil de más de 15B.
  • Recomendaron sarcasm.com como broma sarcástica.
• Como el Wi‑Fi integrado no funcionaba, usé un adaptador Wi‑Fi USB externo, pero gracias a DriverHub no sirvió de nada. Se suponía que era la solución, y terminó siendo una decepción.
  • El post del blog en sí estuvo entretenido de leer.
  • Los drivers más recientes de Wi‑Fi no funcionaban, así que tuve que usar una versión anterior.
• ASUS es una gran empresa con una capitalización de mercado de 15 mil millones de dólares, pero aun así no da una compensación adecuada y además menosprecia el esfuerzo de sus clientes e investigadores. Con ese trato, se entiende perfectamente lo frustrados que deben sentirse los investigadores. La conclusión es que lo mejor es no comprar productos ASUS.
• Al enviar el bug report, el archivo PoC fue detectado por Amazon CloudFront como una solicitud maliciosa y el envío quedó bloqueado. Este tipo de WAF (Web Application Firewall) termina siendo más bien una mala práctica o un mal ejemplo.
• Entiendo totalmente la queja sobre el problema del Wi‑Fi integrado. En realidad, basta con revisar el modelo del chipset y descargar el driver por separado desde lugares como station-drivers, y eso toma unos segundos. No me gusta ASUS por este tipo de molestias, y detesto especialmente las opciones del BIOS que interactúan directamente con el sistema operativo.
• Me gustan los productos ASUS, pero siempre desactivo las apps de soporte que vienen preinstaladas desde UEFI. Antes se instalaba la versión completa de ROG Armory Crate y era molesto quitarla. Incluso después de que ASUS adquirió el negocio NUC de Intel, siguieron manteniendo las actualizaciones del BIOS, pero empezaron a agregar por defecto apps de instalación como MyASUS. Por suerte existe una opción para desactivarlo, y parece que si actualizas desde un BIOS de Intel NUC viene desactivado por defecto.