Noticias
Plug and Pwn: enchufan un USB falso y Windows 11 se entrega sola en cinco minutos, sin un solo clic
Dos investigadores del equipo de hacking de Accenture en España presentaron en DEF CON 34 un ataque llamado Plug and Pwn que aprovecha algo que Windows hace todos los días sin avisarle a nadie: cuando enchufás un dispositivo USB, el sistema puede descargar un paquete desde Windows Update y ejecutar código del fabricante con permisos de NT AUTHORITY\SYSTEM, el nivel más alto de la máquina. Sin privilegios de administrador, sin ventana de UAC y —en su demostración más incómoda— sin que haya nadie con la sesión iniciada.
No es una filtración ni un rumor. Es el kit de publicación de una charla oficial de la conferencia, con el código y las herramientas publicados para que cualquiera reproduzca la parte de Plug and Play. La demo central corre contra una Windows 11 completamente actualizada, sin nadie logueado y sin nada preinstalado, y termina en una consola con permisos de SYSTEM en unos cinco minutos.
Antes de que tires todos los pendrives a la basura: la parte que da miedo y la parte que te puede pasar a vos no son la misma, y esa distinción es justo la que se pierde en los titulares.
- Qué es Plug and Pwn y por qué Windows Update queda en el medio
- Cinco minutos, cero clics y nadie con la sesión abierta
- El mismo truco por RDP, sin enchufar absolutamente nada
- La advertencia de 2021 que quedó en un posteo
- La pelea pública por la clave de registro que apaga media cadena
- Microsoft ya no firma esto, pero lo viejo sigue estando
- ¿Y esto qué significa para vos?
- Preguntas frecuentes
Qué es Plug and Pwn y por qué Windows Update queda en el medio
La charla se llama «Plug And Pwn: Weaponizing Windows PnP Auto-Install» y la dieron Alejandro «0xedh» Hernando y Borja «borjmz» Martínez, los dos del equipo de hacking de Accenture en España, el viernes 7 de agosto en la pista principal 4 de DEF CON 34, la edición que se hizo del 6 al 9 de agosto en Las Vegas. Sesenta minutos, con etiqueta de demo y de exploit. En la ficha oficial declaran el tamaño del trabajo: se pasaron «la mayor parte de un año» mapeando esta superficie de ataque y analizaron unos 7.000 paquetes.
El mecanismo que abusan se llama co-installer y no es un bug: es una función documentada de Windows. Cuando conectás un dispositivo nuevo, el sistema lee sus descriptores, arma un identificador de hardware, busca el paquete de driver que corresponda y —si hace falta— lo baja de Windows Update y lo instala. Si ese paquete trae un co-installer, un ejecutable de soporte o un servicio, todo eso corre por un camino privilegiado. En palabras de los investigadores en el sitio de la investigación, ese software «entra en un camino privilegiado que el usuario nunca aprobó mediante un aviso de UAC».
La frase que resume el hallazgo es esta: Plug and Play se convierte en el cargador. No hace falta ser administrador para dejar algo corriendo en la máquina; alcanza con lograr que Windows crea que apareció cierto hardware.
| Dato | Detalle |
|---|---|
| Nombre | Plug and Pwn (y su variante remota, «NoPlug & Pwn») |
| Presentado en | DEF CON 34, pista principal 4, 60 minutos |
| Investigadores | Alejandro Hernando y Borja Martínez (Accenture España) |
| Qué se obtiene | Ejecución de código como NT AUTHORITY\SYSTEM |
| Objetivo de la demo | Windows 11 totalmente actualizada, sin sesión iniciada, sin nada preinstalado |
| Tiempo de la cadena física | Unos cinco minutos |
| Avisos de UAC | Cero. Que es exactamente el problema |
Cinco minutos, cero clics y nadie con la sesión abierta
La demostración física encadena dos fallas de dos fabricantes distintos, ninguna grave por separado. Los investigadores emulan dispositivos USB con FaceDancer, un framework que permite definir a mano los descriptores con los que una computadora identifica lo que le enchufaron; a BleepingComputer le dijeron que lo corrieron con hardware Cynthion y GreatFET sobre una computadora Linux chica.
La secuencia, tal como la documentan los autores en el kit de la investigación:
- Se emula un dispositivo Sierra Wireless. Windows instala su software, que corre como SYSTEM y expone una tubería con permisos de lectura y escritura para «Todos». Cualquier usuario local —o de dominio— puede conectarse y llamar a la función que cambia el DNS de la máquina.
- Se emula un dispositivo Sony FeliCa. Su co-installer, firmado, descarga archivos de configuración por HTTP en texto plano y confía en todo lo que recibe. Como el DNS ya está en manos del atacante, esos «servidores de Sony» son los del atacante.
- Se explota el nombre del archivo. El componente arma el destino tomando todo lo que viene después de la última barra de la URL, sin filtrar puntos ni barras invertidas. Resultado: escritura arbitraria de archivos como SYSTEM, apuntada a
System32. - Se vuelve a emular el dispositivo Sierra para que Windows cargue la biblioteca recién plantada. Ahí termina: código propio corriendo como SYSTEM, antes de que ningún usuario inicie sesión.
Los propios investigadores lo describen sin épica: «dos bugs de baja severidad, de dos fabricantes distintos, encadenados en ejecución de código arbitrario como SYSTEM». Ese es el punto de toda la charla —que las piezas que por separado parecen defendibles, juntas no lo son—, y también el motivo por el que no reportaron todos los escenarios como vulnerabilidades nuevas: muchos no son fallas por sí solas y recién se vuelven explotables al combinarse con otra funcionalidad.
El mismo truco por RDP, sin enchufar absolutamente nada
La objeción obvia a todo lo anterior es que hay que estar ahí, con algo en la mano. Los investigadores se adelantaron con una segunda variante, «NoPlug & Pwn», que no usa hardware: abusa de la redirección de USB por RDP, la función que hace que un dispositivo enchufado en tu laptop aparezca dentro de una sesión remota. El servidor arma el dispositivo Plug and Play a partir de los descriptores que le manda el cliente, y textual de la fuente: «el cliente describe el hardware, y el servidor simplemente le cree. No tiene por qué haber un dispositivo real del otro lado».
Escribieron un cliente RDP en Python, se autenticaron como usuario común y anunciaron un dispositivo inventado. Para la demo eligieron una cámara Intel RealSense, cuyo driver está firmado por Microsoft y se instala desde Windows Update: durante la instalación, su co-installer deja un ejecutable en una carpeta que un usuario normal puede escribir y lo corre como SYSTEM. Con eso, un secuestro clásico de biblioteca se dispara en remoto.
Ahora el freno, que importa tanto como el ataque: solo funciona donde la redirección de USB está habilitada —común en escritorios virtuales administrados, dice Hernando—, la compuerta es una política de grupo (fDisablePNPRedir), y hacen falta credenciales válidas. El analista Will Dormann agrega que la redirección por RemoteFX «no viene habilitada por defecto». No es un ataque contra una PC hogareña desde internet.
| Vector | Qué necesita el atacante | ¿Sirve contra una PC de casa? |
|---|---|---|
| Cadena física (Sierra + Sony) | Acceso físico al puerto USB. Ni clics ni sesión iniciada | Sí, si alguien llega a la máquina |
| NoPlug & Pwn (RDP) | Credenciales válidas + redirección de USB habilitada en el servidor | Prácticamente no: es escenario corporativo y VDI |
| Wacom + Atheros | Ser usuario común y poder emular las identidades USB de los dos fabricantes (con Cynthion o FaceDancer, o por RDP) + un reinicio | Solo si el atacante además puede emular USB: no es una escalada de software pura |
La advertencia de 2021 que quedó en un posteo
Nada de esto es completamente nuevo, y los investigadores no fingen lo contrario. En 2021 se demostró públicamente una versión mucho más simple del mismo truco con el instalador de Razer Synapse: se conectaba un mouse Razer, Windows bajaba y lanzaba el instalador con permisos de SYSTEM, y desde su interfaz se podía abrir un PowerShell que heredaba esos permisos. BleepingComputer lo probó entonces y confirmó que daba SYSTEM en unos dos minutos.
Hernando marcó la diferencia con precisión: «El bug de Razer es la misma familia. La diferencia es que fuimos por el camino de instalación en sí, en lugar de ir por el instalador de un fabricante». Y agregó lo que separa esta investigación de aquella: «Algunas de nuestras cadenas no necesitan clics ni sesión iniciada, y una corre sobre RDP sin ningún hardware».
| Razer Synapse (2021) | Plug and Pwn (2026) | |
|---|---|---|
| Qué se abusa | El instalador de un fabricante | El camino de instalación de Windows |
| Interacción del usuario | Hacía falta operar la interfaz del instalador | Cero clics en la cadena física |
| ¿Sesión iniciada? | Sí | No hace falta |
| ¿Hardware real? | Un dispositivo Razer | Ninguno: se emulan los descriptores |
| Variante remota | No | Sí, por redirección USB de RDP |
| Fabricantes involucrados | Uno | Sierra Wireless, Sony, Intel, Wacom y Atheros |
La pelea pública por la clave de registro que apaga media cadena
Acá aparece lo más interesante del caso, y es una discusión que se dio en público entre gente con nombre y apellido. Will Dormann, analista de vulnerabilidades conocido por haber advertido sobre el caso Razer en su momento, publicó dos días antes de la cobertura una crítica bastante frontal.
PlugAndPwn parece ser esto, pero con esteroides. Solo que, en el fondo, sigue siendo abuso de co-installers. Mencioné en esa época que podés bloquear toda esta clase de vulnerabilidad poniendo en 1 el valor
Will Dormann — ver postDisableCoInstallers, dentro de HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer. Me parece decepcionante que el sitio de plugandpwn no haga NINGUNA MENCIÓN a DisableCoInstallers. Supongo que demostrar un exploit en el escenario es más importante que compartir cómo puede protegerse la gente. 🤷♂️
La crítica sigue siendo cierta al día de hoy: buscamos el término en el sitio de la investigación y no aparece ni una vez. En el mismo hilo, otros lo relativizaron.
Quizá simplemente no lo sabían (probable, sobre todo si no lo mencionan en absoluto) o descubrieron que hay demasiadas excepciones para que esa clave de registro funcione (menos probable, seguramente lo habrían presentado también). Mejor evitemos pintar un panorama apocalíptico, que ya tenemos bastante en la vida real.
PhilLovesCats (@Phalzu en Mastodon) — ver post
Dormann no aflojó: contestó que si alguien se tomó el trabajo de armar un sitio elaborado y presentar en una conferencia de mucho público, se reserva el derecho de juzgar cuánto esfuerzo se puso en pensar en los defensores, comparado con lo que él mismo —»un armchair quarterback«— notó cinco años atrás.
Lo relevante es que BleepingComputer le llevó la objeción al investigador, y su respuesta no coincide con la de Dormann. Para Hernando, la clave ayuda pero no cierra el tema:
Ayuda, y rompería partes de lo que mostramos. Sin embargo, no detiene la clase de ataque. Deja intactas la enumeración de Plug and Play, la resolución vía Windows Update, la preparación de drivers, el procesamiento de INF y los servicios instalados por INF.
Alejandro Hernando, investigador — vía BleepingComputer
Y no es una opinión: la cadena de Wacom + Atheros lo demuestra, porque se apoya en un servicio instalado por un archivo INF y no por un co-installer. Es decir, el interruptor que Dormann recomienda no la tocaría. Lo que Hernando sí recomienda para equipos sensibles es combinarla con restricciones de instalación de dispositivos o listas de hardware permitido, y apagar la redirección de dispositivos PnP en los hosts de RDP y VDI que no la necesiten.
Microsoft ya no firma esto, pero lo viejo sigue estando
Hay un detalle que ordena todo el panorama y que no sale de la investigación sino de la documentación de Microsoft, con fecha exacta: «a partir de enero de 2023, los paquetes de driver que contengan un co-installer ya no son firmados por el portal del Centro de Desarrollo de Hardware». Microsoft cerró la puerta para los paquetes nuevos hace más de tres años. El problema es que eso no borra los viejos, que siguen firmados y siguen estando disponibles.
Los investigadores se toparon justo con eso al revisar el componente de Atheros: encontraron que coincidía con una falla ya documentada de 2019 y, en sus palabras, «asumimos que Microsoft habría revocado el certificado y que el paquete ya no se instalaría. Spoiler: todavía se instala».
La nota de origen menciona esa falla al pasar, sin fecha ni descripción, así que fuimos a buscarla al registro oficial de CVE: es CVE-2019-10617, está a nombre de Qualcomm (dueña de Atheros), se publicó el 21 de noviembre de 2019 y la descripción encaja exactamente con el uso que le dieron: «usuarios de bajo privilegio pueden acceder a la configuración del servicio, que contiene datos de registro que los administradores usan para crear o borrar entradas en el registro». Está clasificada como un problema de permisos en el host Bluetooth, y su referencia oficial es el boletín de seguridad de Qualcomm de octubre de 2019.
Casi siete años después, ese paquete todavía se instala. Ese es el hueco real: no es que Windows tenga una falla nueva, es que arrastra un catálogo enorme de software firmado hace años que sigue siendo entregable a pedido.
¿Y esto qué significa para vos?
Vamos a la parte honesta, porque el titular da para más miedo del que corresponde y no vamos a vender eso. Si usás una PC en tu casa y nadie más la toca, tu riesgo directo con Plug and Pwn es bajo hoy: la variante remota necesita credenciales tuyas y una configuración que no viene activada, y la variante física necesita que alguien llegue con algo en la mano hasta tu puerto USB.
Donde sí cambia la cuenta es en oficinas, coworkings, locales con equipos compartidos y PyMEs con escritorios virtuales. Ahí «alguien llega hasta el puerto USB» deja de ser hipotético, y una escalada a SYSTEM sobre una Windows 11 completamente al día es exactamente el tipo de cosa que no aparece en ningún informe de vulnerabilidades pendientes, porque no hay ninguna pendiente.
Lo segundo, que es donde más humo se vende: ningún producto de seguridad evita que Windows instale el paquete. Esa parte son drivers y componentes firmados por sus fabricantes que bajan por el canal legítimo, y ahí un antivirus no tiene qué marcar — el mismo motivo por el que, como contamos hace unos días, un antivirus no tiene motivo para frenar a una herramienta de administración remota firmada. Ahora, decir «no sirve para nada acá» también sería falso: las tres cadenas terminan con un archivo propio del atacante —una biblioteca en System32, un CRYPTBASE.dll, un PocPortMon.dll— y eso ya no está firmado por nadie. Ahí la detección por comportamiento tiene algo que mirar. Lo que no existe es lo que impida el paso anterior.
Lo que sí se puede hacer, en orden de sensatez:
- No dejar equipos desbloqueados y sin vigilancia, que suena a consejo de abuela pero es literalmente el requisito de la cadena física.
- En empresas: apagar la redirección de dispositivos PnP —la directiva se llama
fDisablePNPRedir— en los servidores RDP y VDI que no la necesiten. Es la recomendación textual del investigador y desactiva la variante remota entera. - El valor
DisableCoInstallers, que hace más de lo que esta nota podría dar a entender. Ojo con la precisión: no es una clave nueva, es un valor DWORD de 32 bits puesto en 1 dentro de una clave que ya existe. Hernando reconoce que rompe «algunos de los ataques demostrados, incluido el de Sony FeliCa y el de Intel RealSense por RDP»: las dos demos del título. Lo que deja en pie es la cadena de Wacom + Atheros, que viaja por INF. Es una medida para quien administra equipos, y por definición implica que el software de fabricante que viaja en esos paquetes deje de instalarse solo.
Un último dato, menos tranquilizador de lo que suele contarse. Le preguntaron a Hernando si el ataque se puede hacer con aparatos chicos y portátiles, y respondió que el hardware de la investigación ya es lo bastante portátil como para llevarlo encima, y que una Raspberry Pi en modo gadget teóricamente también serviría. El Flipper Zero, en cambio, no: no hay backend de FaceDancer para ese aparato, y su modo BadUSB sirve para dispositivos HID —teclado o mouse—, pero manejar descriptores compuestos arbitrarios «sería un proyecto de firmware». O sea: no hace falta un laboratorio, pero tampoco alcanza con el gadget del cajón.
Preguntas frecuentes sobre el ataque por USB
¿Me pueden hackear la PC solo con enchufarme un pendrive común?
Un pendrive común de fotos, no. El ataque necesita un aparato que emule descriptores USB a medida —los investigadores usaron FaceDancer con hardware específico— para hacerse pasar por dispositivos de determinados fabricantes. Un pendrive normal no puede mentir sobre qué es.
¿Hay que instalar un parche de Windows para estar cubierto?
No hay un parche que resuelva esto, y esa es la parte incómoda: la demostración corre contra una Windows 11 totalmente actualizada. No se explota una falla del sistema, sino su comportamiento normal de instalación combinado con software viejo de terceros que sigue firmado.
¿Mi antivirus me protege de este ataque?
No del todo. La instalación del driver y del co-installer no la frena: son componentes firmados que bajan por Windows Update. Sí queda margen en el último paso, donde el atacante escribe un archivo propio sin firma. La defensa principal acá es el acceso físico y la configuración de instalación de dispositivos.
¿Se puede ver la charla completa en video?
Todavía no. Al momento de publicar esta nota, el sitio de la investigación marca la grabación de la charla, las diapositivas y los videos de demostración como pendientes de publicación por parte de DEF CON. Lo que sí está disponible es el código de las pruebas de concepto.
