EspañolDEF CON Diez errores ya corregidos en Quick Share de Google para Windows podrían haber sido explotados para escribir archivos nuevos de forma inalámbrica en las PC de las víctimas sin su aprobación y, en última instancia, ejecutar código de forma remota en las máquinas de esas víctimas mediante la combinación de un puñado de otras vulnerabilidades. El líder del equipo de investigación de seguridad de SafeBreach, Or Yair, y el investigador de seguridad senior Shmuel Cohen demostraron el ataque de ejecución de código remoto (RCE), denominado QuickShell, y en DEF CON hoy discutieron el trabajo que se llevó a cabo en este proyecto: Es decir, sondear el protocolo de comunicación de Quick Share, realizar pruebas de fuzzing y luego buscar manualmente vulnerabilidades y, finalmente, crear una cadena RCE completa. Después de compartir sus hallazgos con Google, el gigante de la web emitió dos CVE en junio que cubren las 10 fallas de Quick Share que SafeBeach descubrió. Se trata de CVE-2024-38271, un fallo de denegación de servicio que obtuvo una calificación de gravedad CVSS de 5,9 sobre 10, y CVE-2024-38272, un error de omisión de autorización con una puntuación CVSS de 7,1. Google ha corregido todos los fallos y SafeBreach confirmó que ya no es posible ejecutar la cadena RCE. Google no quiso hacer comentarios. Como parte de la solución del problema de RCE en Windows (que es bastante complejo y no trivial de explotar, pero muy interesante de ver cómo se desarrolla), Google corrigió un error que permitía a los atacantes forzar el envío de archivos a dispositivos Windows y Android cercanos a través de Quick Share. Dentro del código, Quick Share, similar a AirDrop de Apple, es una herramienta de intercambio de archivos peer to peer que permite a las personas enviar y recibir archivos entre dispositivos cercanos. Utiliza varios protocolos de comunicación, incluidos Bluetooth, Wi-Fi, Wi-Fi Direct, Web Real-Time Communication (WebRTC) y Near-Field Communication (NFC). Además, utiliza la API Nearby Connections de Google para descubrir e intercambiar datos con dispositivos cercanos. Quick Share es el resultado de la fusión del programa Nearby Share de Google, similar a AirDrop, con Quick Share de Samsung en enero de este año. La aplicación no solo está disponible para Android, sino también para Windows, por lo que puede usarla para transferir archivos entre dispositivos móviles y PC. Tenga en cuenta que para que dos dispositivos, ya sean teléfonos u ordenadores, intercambien archivos a través de Quick Share, ambos extremos deben dar su consentimiento a la transferencia: el usuario que envía debe ofrecer un archivo y el receptor debe aceptarlo a través de la interfaz de usuario. «Es un proyecto bastante complejo de hacer en Windows», dijo Cohen de SafeBreach a The Register. «Implica varios métodos de comunicación y todo se vuelve muy complejo. Y como investigador de seguridad, siempre te gusta observar programas o diseños complejos, porque complejo significa que probablemente tendrán errores». Fuzz’n’logic Después de estudiar los diversos protocolos involucrados en el proceso de intercambio de archivos, el dúo decidió crear una herramienta de fuzzing para probar Quick Share para Windows. Aunque esto provocó algunos fallos reproducibles, no les proporcionó el error que esperaban que se pudiera explotar de forma útil. Por ejemplo, era posible bloquear repetidamente Quick Share en Windows al compartir un archivo con un nombre de archivo que contuviera caracteres UTF-8 no válidos, lo que por sí solo podría ser bueno para hacerle una broma a alguien. «Nos permitió bloquear Quick Share», dijo Yair sobre el fuzzing, «y uno de ellos obligó a Quick Share a abrir sin fin un solo archivo en la carpeta de Descargas. De modo que podemos nombrar un archivo en la carpeta de descargas de la víctima, y ​​eso abrirá, cerrará, abrirá, cerrará, repetidamente, el mismo archivo, para siempre». A continuación, los investigadores pasaron a buscar vulnerabilidades lógicas en el código. El código del protocolo de comunicación de Quick Share «es extremadamente genérico, lleno de clases abstractas y base y una clase de controlador para cada tipo de paquete», señalan los dos en un artículo que se compartirá junto con su presentación en DEF CON hoy. Como señalamos, normalmente un destinatario tiene que aceptar en la pantalla de la aplicación recibir un archivo por aire de un remitente. Así es como se supone que funciona ese intercambio bajo el capó, según el dúo: Sin embargo, el código estaba estructurado de tal manera que inadvertidamente permitía al par enviar un paquete PayloadTransfer directamente a la aplicación para realizar una transferencia, saltándose por completo las etapas de introducción y aceptación del paquete, y evitando la necesidad de cualquier aceptación del respondedor. El software, tanto la versión de Windows como la de Android, notamos, simplemente tomaría el archivo automáticamente y lo guardaría. Los malhechores podrían usar esto para enviar datos, incluso contenido altamente ilegal, al dispositivo de un objetivo. Esto también funcionó independientemente del modo de descubrimiento que la aplicación estuviera configurada para usar, ya sea que la aplicación fuera visible para todos o no, e incluso si la aplicación estaba configurada para aceptar solo archivos de los contactos del usuario. Puede ver una demostración de esta omisión de aceptación de transferencia de archivos a continuación. Video de Youtube El equipo de SafeBreach también pudo usar Quick Share para obligar a un dispositivo objetivo a conectarse a una red Wi-Fi de su elección durante aproximadamente 30 segundos, después de lo cual Quick Share devolvió la máquina a su red Wi-Fi original. Este mecanismo se proporciona para que, si es posible, la aplicación pueda mejorar la conectividad entre dos dispositivos para acelerar la transferencia de archivos. Permite que Quick Share utilice Wi-Fi para esa transferencia en lugar de un protocolo inalámbrico más lento. Durante ese tiempo, un atacante podría intentar intervenir en el tráfico inalámbrico de la víctima, aunque casi todo está cifrado en tránsito en la capa de aplicación al menos en estos días, y como solo había unos 30 segundos para hacer algo nefasto, es posible que piense que este era un callejón sin salida. A continuación, encontraron un ataque de cruce de ruta que, irónicamente, era posible para el código de Quick Share responsable de eliminar las cadenas de cruce de ruta. Pero si bien esto permitió al investigador crear un archivo fuera de la carpeta de descargas, el código requería que el nombre del archivo comenzara con «Descargas» y el archivo siempre tenía que estar en la carpeta del usuario. Así que todavía no había RCE. Para entonces ya tenían 10 vulnerabilidades que podían hacer lo siguiente, según la pareja: El poder del pensamiento creativo «La parte más difícil en realidad no fue técnica en absoluto. Fue pura creatividad», dijo Yair. «Intentamos pensar: ¿cómo podemos escalar estas vulnerabilidades para convertirlas en algo mayor? Y se nos ocurrió este flujo». Ese flujo, que vincula cinco errores menores para lograr RCE, primero implicó extender el ataque de secuestro de Wi-Fi más allá de los 30 segundos y mantener la PC de la víctima en la red controlada por el atacante. Lo lograron haciendo que la computadora de la víctima se uniera a la red maliciosa, luego bloqueando inmediatamente la aplicación con una de las vulnerabilidades de denegación de servicio anteriores y aprovechando el hecho de que Quick Share crea una tarea programada de Windows que cada 15 minutos verifica si la aplicación está ejecutándose. Si no se está ejecutando, la tarea reinicia Quick Share. Entonces, se usa Quick Share para hacer que el objetivo se una a una red maliciosa, se bloquea su Quick Share para que no haga que el usuario vuelva a la red anterior, se espera a que la tarea programada inicie Quick Share nuevamente y ahora el atacante tiene a su víctima en una conexión Wi-Fi persistente controlada por el atacante. Ese malhechor ahora, en esta posición, tiene tiempo de interceptar el tráfico de Internet de la víctima y entrometerse en él. A continuación, para este RCE inteligente pero ciertamente involucrado, el atacante debe esperar a que la víctima descargue (por ejemplo) un instalador de aplicaciones de Internet a través de la red maliciosa. Incluso si este programa de instalación se descarga mediante una conexión HTTPS, es posible que el espía de la red descubra el programa que el usuario desea a partir del nombre de host del servidor de descarga remoto. Durante el protocolo de enlace no cifrado al comienzo de la conexión, el nombre de host completo del servidor, como code.visualstudio.com, es visible para el espía. Para adivinar el programa que se está obteniendo, el dúo miró no solo el nombre de host sino también el tamaño de la descarga. Si sabe, por ejemplo, que hay disponible un instalador .exe de 123 MB en (por ejemplo) amazingeditor.example.com y usted, como espía de Wi-Fi, ve a su víctima descargando 123 megabytes aproximadamente de ese servidor usando su navegador, puede estar seguro de que está obteniendo ese instalador. La pareja explicó: Y finalmente, en el momento justo, el atacante engaña al Quick Share de la víctima para que sobrescriba el ejecutable que está obteniendo y guardando el navegador en la carpeta de descargas del usuario, reemplazando el .exe legítimo por uno malicioso al enviar a la fuerza un archivo con exactamente el mismo nombre. Ayuda que Quick Share y, por ejemplo, Chrome usen la misma carpeta para las descargas. «Evitará que alguien elimine este archivo o lo modifique», dijo Cohen. «Entonces, digamos que el [victim’s browser] intenta sobrescribir nuestro archivo con el original, digamos un instalador de Spotify, no podrá sobrescribir nuestro archivo pero notificará a la víctima que todo está bien, y Spotify se está descargando, y puede hacer clic aquí para ejecutarlo». Por supuesto, la víctima no estará ejecutando Spotify cuando abra el programa, sino algún código malicioso elegido por el atacante, y luego se acabó el juego. Complicado, pero factible, y en cualquier caso, ahora parcheado. En general, el equipo dijo que encontró e hizo que Google corrigiera lo siguiente: Escritura remota de archivo no autorizada en Quick Share para Windows Escritura remota de archivo no autorizada en Quick Share para Android Conexión Wi-Fi forzada remota en Quick Share para Windows Travesía remota de directorio en Quick Share para Windows DoS remoto en Quick Share para Windows – Bucle sin fin DoS remoto en Quick Share para Windows – Error de afirmación DoS remoto en Quick Share para Windows – Error de afirmación DoS remoto en Quick Share para Windows – Excepción no controlada DoS remoto en Quick Share para Windows – Excepción no controlada DoS remoto en Quick Share para Windows – SafeBreach afirma que trabajó en estrecha colaboración con el fabricante de Chrome para resolver las vulnerabilidades y agregó que los empleados de Google se mostraron cooperativos y receptivos a su divulgación responsable. Imaginamos que el sector de la seguridad de la información publicará en algún momento su artículo sobre esta investigación aquí, donde aloja sus otros avisos. ®