Vulnerabilidad de RCE con un clic en el software de controladores preinstalado de ASUS

 (mrbruh.com)
2 puntos por GN⁺ 2025-05-12 | 1 comentarios | Compartir por WhatsApp
  • ASUS DriverHub, que puede instalarse justo después de iniciar sesión en Windows, podía llevar a ejecución de código con privilegios de administrador con solo visitar un sitio web específico, debido a la forma en que conectaba el sitio web con un servicio local
  • DriverHub funciona en segundo plano sin GUI, y driverhub.asus.com enviaba solicitudes al servicio HTTP/WebSocket local en 127.0.0.1:53000; la verificación de Origin permitía dominios con el formato driverhub.asus.com.*
  • El endpoint UpdateApp descargaba archivos si la URL solo contenía la cadena .asus.com, y al ejecutar archivos firmados por ASUS con privilegios de administrador, no eliminaba los archivos que fallaban la verificación de firma
  • El exploit final descargaba en orden un calc.exe no firmado, un AsusSetup.ini manipulado y el AsusSetup.exe firmado, para luego lograr RCE con privilegios de administrador mediante SilentInstallRun=calc.exe
  • ASUS confirmó la distribución del parche en abril de 2025, y el 9 de mayo de 2025 se publicaron CVE-2025-3462 y CVE-2025-3463; según los registros de transparencia de certificados, no se observaron señales de explotación activa significativa antes de la divulgación

DriverHub local RPC conectado al sitio web

  • Tras comprar una motherboard ASUS, justo después de iniciar sesión en Windows aparecía una notificación solicitando privilegios de administrador para completar la instalación de ASUS DriverHub
  • DriverHub no funciona como una GUI separada, sino como un proceso en segundo plano, y en driverhub.asus.com se indican los controladores necesarios y los elementos a actualizar
  • El sitio web se comunica por RPC con el proceso local de DriverHub en ejecución
    • El servicio local funciona en el puerto fijo 53000 de 127.0.0.1
    • La estructura permite que el sitio web o el servicio envíen solicitudes API a este puerto local
  • Si la protección de este RPC no es suficiente, un atacante puede abusar de ello para instalar aplicaciones maliciosas

Bypass de la verificación laxa de Origin

  • DriverHub no aceptaba solicitudes de cualquier sitio web: estaba diseñado para responder a solicitudes cuyo encabezado Origin fuera driverhub.asus.com
  • El problema era que la verificación no era una comparación exacta, sino más cercana a una comprobación por inclusión de cadena o comodín
    • No era una comparación directa como origin == driverhub.asus.com
    • Al establecer driverhub.asus.com.mrbruh.com como Origin, la solicitud era permitida
  • Un atacante podía aprovechar este comportamiento para acceder al RPC local de DriverHub desde un dominio con formato driverhub.asus.com.*

Endpoints RPC expuestos

  • Mediante el JavaScript del sitio web y la descompilación de ejecutables se identificaron varios endpoints RPC
  • Los principales endpoints son los siguientes
    • Initialize: devuelve si el software está instalado y la información básica de instalación
    • DeviceInfo: devuelve el software ASUS instalado, los drivers .sys instalados, los componentes de hardware y la dirección MAC
    • Reboot: reinicia inmediatamente el dispositivo objetivo sin confirmación
    • Log: devuelve un archivo comprimido con todo el registro de DriverHub
    • InstallApp: realiza la instalación mediante ID de app o de driver; los ID de app están hardcodeados en un archivo XML proporcionado por el instalador de DriverHub
    • UpdateApp: descarga y ejecuta la URL de archivo proporcionada para autoactualizar DriverHub

Cómo UpdateApp creó las condiciones para RCE

  • La solicitud UpdateApp funciona con la siguiente forma
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • El comportamiento observado de UpdateApp proporcionaba varias condiciones necesarias para la cadena de RCE
    • El parámetro Url debía incluir la cadena .asus.com, pero también se aceptaban formas como example.com/payload.exe?foo=.asus.com
    • El archivo se guardaba con el nombre de archivo especificado al final de la URL
    • Se podían descargar archivos sin importar la extensión
    • Si el archivo era un ejecutable firmado por ASUS, se ejecutaba automáticamente con privilegios de administrador
    • Si era un ejecutable firmado por ASUS, se ejecutaba aunque no fuera el instalador de DriverHub
    • Aunque el archivo descargado fallara la verificación de firma, no se eliminaba
  • Al principio parecía difícil lograr RCE por la validación de firma, pero la combinación del comportamiento que dejaba archivos tras un fallo de firma con la lógica de instalación de ejecutables firmados por ASUS abrió una vía de bypass

Cadena de exploit usando AsusSetup.ini

  • El paquete del driver WiFi de ASUS incluía AsusSetup.exe, AsusSetup.ini y SilentInstall.cmd
  • Al ejecutarse, AsusSetup.exe leía los metadatos del driver desde AsusSetup.ini
  • Si AsusSetup.exe se ejecuta con la bandera -s, realiza una instalación silenciosa sin GUI y ejecuta el elemento especificado en SilentInstallRun dentro de AsusSetup.ini
    • DriverHub usa la bandera -s para la instalación silenciosa
    • El archivo INI original especificaba un script cmd para instalación automática sin interacción
    • En SilentInstallRun también se podía indicar otro ejecutable

  • Secuencia final del ataque

    • El usuario visita un sitio web con un dominio del tipo driverhub.asus.com.*
    • El sitio solicita mediante UpdateApp el ejecutable PoC calc.exe
    • calc.exe se descarga, pero no se ejecuta porque falla la verificación de firma
    • El archivo no se elimina y permanece ahí
    • El sitio solicita mediante UpdateApp un AsusSetup.ini manipulado
    • Este archivo también se descarga, pero no se ejecuta
    [InstallInfo]
SilentInstallPath=.\\
SilentInstallRun=calc.exe
    • El sitio solicita mediante UpdateApp el binario firmado por ASUS AsusSetup.exe
    • AsusSetup.exe se ejecuta con privilegios de administrador después de descargarse
    • Como DriverHub lo ejecuta con -s, lee AsusSetup.ini
    • Según SilentInstallRun=calc.exe, calc.exe se ejecuta con privilegios de administrador

Desde el reporte hasta la publicación del CVE

  • La cronología del manejo de la vulnerabilidad fue la siguiente
    • 2025-04-07: descubrimiento inicial de la vulnerabilidad
    • 2025-04-08: confirmación de que escalaba a RCE
    • 2025-04-08: reporte de la vulnerabilidad a ASUS
    • 2025-04-09: recepción de respuesta automática de ASUS
    • 2025-04-17: tras un contacto de seguimiento, ASUS entregó el parche completado y una build para validación
    • 2025-04-18: ASUS confirmó la distribución del parche
    • 2025-05-09: se publicaron CVE-2025-3462 con puntuación 8.4 y CVE-2025-3463 con puntuación 9.4

Posibilidad de explotación y rastros observados

  • Justo después del reporte, se ejecutó en un VPS un script que rastreaba actualizaciones de certificate transparency para comprobar si se registraban dominios driverhub.asus.com.*
  • Según otros sitios web de registros de transparencia de certificados, los dominios y subdominios solían aparecer en los logs en menos de un mes
  • Al revisar un mes después, los únicos sitios que coincidían con la expresión regular eran dominios de prueba
  • Con este criterio, era poco probable que hubiera existido una explotación activa importante antes del reporte

Respuesta de ASUS y problemas pendientes

  • ASUS no ofrece bug bounty; en su lugar, respondió que pondría el nombre del investigador en el hall of fame
  • Más tarde, otro investigador de seguridad, leonjza, ya había reportado el mismo problema de verificación de Origin en febrero de 2025, y ASUS lo corrigió recién en esta corrección
    • ASUS no informó este hecho por separado
    • En la página de cve.org solo aparecía ese investigador en los créditos, y respondieron que no reflejarían créditos adicionales
  • Al enviar el reporte de vulnerabilidad mediante el Security Advisory form de ASUS, Amazon CloudFront detectó el PoC adjunto como una solicitud maliciosa y bloqueó el envío
    • Fue necesario eliminar parte del código PoC y enviar en su lugar un enlace a un video grabado
  • En DriverHub, si en vez de instalar individualmente cada driver recomendado se presiona “Install All”, también se instalan ArmouryCrate, la versión personalizada de CPU-Z de ASUS, Norton360 y WinRAR
  • La descripción del CVE de ASUS expresaba de forma demasiado limitada el alcance y el impacto del RCE
    • La descripción incluía una frase en el sentido de que “está limitado a motherboards y no afecta a laptops ni desktop computers”
    • En realidad, afecta a cualquier computadora con DriverHub instalado, incluidas desktops y laptops
    • En vez de hablar de ejecución de código arbitrario o remoto, se expresó como que “untrusted sources pueden afectar el comportamiento del sistema”

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-12
Opiniones en Hacker News

  • La divulgación responsable y sus consecuencias han sido casi desastrosas para la humanidad. Para que las empresas se tomen más en serio la seguridad de sus clientes, tienen que sentir mucho más dolor, con mucha más frecuencia.
    Si les das un mes y hasta les sirves la solución en bandeja, no pasa de convertirse en un ticket más en el backlog. Si cada vez que surge un problema de seguridad se vuelve una noticia lo bastante grande en línea como para involucrar al CEO, y tienen que encontrar una solución en horas en vez de meses, actuarían de forma mucho más proactiva. Claro, los usuarios finales serían los más perjudicados, pero desde el momento en que compraron ASUS ya están sufriendo.

    • La velocidad de respuesta de ASUS esta vez fue bastante buena, y no veo un gran problema aquí. ASUS no negó el bug, no amenazó con demandar por ingeniería inversa del software y lo parcheó rápido.
      En la época previa a la divulgación responsable, este proceso probablemente habría tomado meses y hasta habría intervenido la policía. A los usuarios comunes no les importan las vulnerabilidades y hacen operaciones bancarias desde teléfonos que llevan tres años sin recibir actualizaciones. Si las noticias siguen lanzando CVE por todos lados, la gente se hartará del discurso de “todas las empresas son pésimas” y se volverá insensible incluso cuando llegue una amenaza real.
      La UE está impulsando otra solución. La nueva regulación de ciberseguridad impedirá vender en tiendas productos con vulnerabilidades conocidas. Si ASUS sigue metiendo la pata, sus motherboards se convertirán en inventario muerto, y las tiendas tampoco querrán vender hardware de ASUS. Esto no aplica solo al hardware de computadoras, sino también a refrigeradores y lavadoras inteligentes. Si descubres una vulnerabilidad en un lavavajillas, y el fabricante no incluyó una forma de actualizar el firmware, podrías generar millones de dólares en inventario inutilizable para la industria.
    • El nombre “divulgación responsable” es irónico. En la práctica, se parece más a un enfoque completamente irresponsable.
      La mayoría de las empresas manejan la divulgación de forma pésima. No corrigen a tiempo, digamos en una semana; no dan el crédito adecuado; no informan a los usuarios; y no aprenden de sus errores. La divulgación limitada y retrasada irresponsablemente refuerza ese comportamiento.
      La forma realmente responsable es revelarlo de inmediato, por completo y públicamente. Si hace falta, se puede hacer de forma anónima para protegerse. Solo después de que la empresa afectada demuestre repetidamente que responde bien, podría ganarse el derecho a un aviso previo muy breve, por ejemplo de unos 5 días hábiles.
      Que a esta divulgación limitada, retrasada e irresponsable se le llame “divulgación responsable” es en sí mismo un ejemplo de neolengua.
    • El punto central es la legislación de responsabilidad. A los fabricantes de autos se les ordenan recalls y reparaciones, pero las empresas de software y hardware reciben muy poca presión.
      Los clientes deberían poder recibir, por ejemplo, un reembolso completo por dispositivos defectuosos que tengan CVE sin corregir.
    • Citando a CGPGrey: la primera solución que se te ocurre suele ser terrible e ineficaz.
      Una buena cultura de seguridad y protección incentiva a los participantes a no ocultar los problemas. Las empresas son entidades codiciosas y harán lo que sea para ocultar sus errores de seguridad.
      Si se divulga a todo el mundo un problema legítimo y corregible que puede arreglarse en un mes, también aumenta mucho la probabilidad de que sea explotado.
    • Podría existir una idea de negocio así. Quizá ya exista: crear un servicio intermediario y agregador de divulgaciones.
      Protegería la privacidad de los informantes, verificaría vulnerabilidades de seguridad y confirmaría que todas las vulnerabilidades que se publiquen sean realmente explotables. Publicaría en ciclos definidos y cobraría a las empresas una suscripción a un “feed temprano” para recibir por adelantado las divulgaciones que les afecten. Con ese dinero se compensaría a los informantes, se cubrirían los costos operativos y quedaría algo de ganancia.
      En otras palabras, sería un mercado de bug bounties algo hostil hacia las empresas. Me pregunto si eso sería legal o si se consideraría extorsión.

  • Es amarga la parte donde preguntaron si ASUS tenía un bug bounty y respondieron que no, pero que en su lugar podían poner el nombre en un “salón de la fama”.
    Es sarcasmo: se entiende, ASUS debe ser una pequeña startup sin capital para pagar recompensas.

    • También es comprensible para una empresa pequeña como Cisco. Cisco hizo algo parecido durante años con numerosos servicios en línea que adquirió.
      Cisco fue más allá y hasta olvidó su página de avisos de seguridad, así que cualquier reconocimiento ahora desapareció en el vacío.
    • Si no hay bug bounty, los exploits terminan en el mercado negro o se van a divulgación completa.
    • Al ver una respuesta así, no dan ganas de volver a comprar productos ASUS.
    • No sé de dónde salió la expresión “Asus es una pequeña startup”. Asus fabrica motherboards y componentes de PC al menos desde los 90.

  • No sorprende. El software de ASUS es pésimo y, en términos de seguridad, se acerca a ser una empresa con problemas recurrentes por falta de prevención.
    https://www.techspot.com/news/95425-years-gigabyte-asus-moth...
    https://www.reddit.com/r/ASUS/comments/tg3u2n/removing_bloat...
    https://www.reddit.com/r/ASUS/comments/ojsq80/nahimic_servic...

  • La parte en la que, al revisar los logs de transparencia de certificados, se concluyó que probablemente no se había explotado activamente antes del reporte porque los únicos dominios que coincidían con driverhub.asus.com.* eran sus propios dominios de prueba, solo se sostiene si no hay certificados wildcard.
    Si alguien tenía un wildcard, podría haberlo explotado sin aparecer en la transparencia de certificados.

    • Los certificados wildcard solo aplican a un único nivel de etiqueta. *.example.com. no sirve para test.test.example.com., pero sí para test.example.com.
      Si alguien hubiera obtenido un wildcard para *.asus.com.example.com., podría haber levantado un servidor web bajo driverhub.asus.com.example.com. y hacerlo parecer válido.
    • Es una buena idea, así que acabo de verificarlo, y confirmé que no había nada sospechoso en los registros wildcard.
    • Sí, ese punto ciego de los certificados wildcard existe. Si un atacante hubiera tenido un certificado wildcard para .example.com, podría haberlo explotado con el dominio driverhub.asus.com. sin que apareciera específicamente en los logs de transparencia de certificados.
      Por eso, monitorear solo los logs de transparencia de certificados no es suficiente para detectar este tipo de vulnerabilidad de toma de subdominios.
    • Además, me pregunto si también habría funcionado un certificado autofirmado. Esos certificados no entran en los logs de transparencia.
      Y también queda la duda de si realmente tenía que ser HTTPS.

  • Que el desenlace sea “mi WiFi integrado todavía no funciona, y tuve que comprar un adaptador WiFi USB externo. Gracias, DriverHub” significa que todo este proceso fue literalmente trabajo en vano.

    • El post del blog en sí estuvo bueno.
    • El driver WiFi más reciente no funciona, así que hay que usar una versión anterior.

  • La parte en la que, al enviar el reporte de vulnerabilidad mediante el formulario de seguridad de ASUS, Amazon CloudFront consideró el PoC adjunto como una solicitud maliciosa y lo bloqueó, parece un aviso de que un firewall de aplicaciones web es un antipatrón: https://thedailywtf.com/articles/Injection_Rejection

  • Eso de “se entiende, ASUS es una startup pequeña” quiere decir que es una pequeña startup con apenas 15 mil millones de dólares de capitalización de mercado.
    Lo realmente difícil de entender no son solo sus productos mediocres, sino que traten así incluso a investigadores que hicieron un trabajo enorme por sus clientes.
    Da pena por los investigadores que hacen este tipo de trabajo y aun así son ignorados o menospreciados. Es demasiado injusto.
    Lo único que uno puede hacer es no comprar productos ASUS.

  • Preguntó si ASUS tenía bug bounty, y ASUS respondió que no, pero que en su lugar pondrían su nombre en el “salón de la fama”. Es sarcasmo: se entiende, ASUS es una startup pequeña y seguramente no tiene capital para pagar recompensas.
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • O quizá sea sarcasm.com ;)

  • Enlace obligatorio al video de Scumbag Asus.
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    “ASUS nos envió un correo la semana pasada diciendo que querían venir esta semana a nuestra oficina para tener una ‘conversación abierta’ sobre el problema. Dijimos que sí, pero respondimos que la conversación tenía que ser grabada. Después de todo, ellos dijeron que querían una conversación abierta. Luego no hubo respuesta durante 5 días. Así que ASUS tuvo la oportunidad de corregir esto. Estábamos reteniendo el video para darles esa oportunidad. Pero en cuanto dijimos ‘bien, solo que lo vamos a grabar para dejar constancia de lo prometido’, llegó el silencio”.

    • Aun así, ¿existe algún fabricante de motherboards que sea “básicamente decente”? ¿O todos los grandes tienen historias parecidas?
      Pregunto por un amigo que pronto va a armar una PC nueva.
    • Esto da rabia, pero me pregunto cuál sería la defensa más sólida y verosímil de la postura de ASUS.
      Probablemente la realidad vaya más por este lado: persiguen ganancias y, como aun así se salen con la suya, no tienen por qué quedar mal en un registro grabado; mejor dedicar ese tiempo a marketing.

  • Que no haya bug bounty es ridículo. De ahora en adelante no compraré productos ASUS.

    • Debe ser porque son una “startup pequeña”.
    • El software y el soporte al cliente de Asus son terribles, y siempre lo han sido.