Q
RC OD
E a través de una aplicación móvil para escanear las insignias de los expositores de proyectos de seguridad de la información.
El año pasado, visitamos una gran exposición de proyectos de seguridad de la información en Londres. En preparación, nos enviaron nuestros pases en forma de archivos PDF “imprímalo usted mismo”.
Inmediatamente notamos dos tipos de códigos de barras. Curiosamente, el código QR parecía demasiado denso, dado que es suficiente para almacenar solo la identificación del participante. Siendo curiosos por naturaleza, lanzamos un escáner QR y recibimos el contenido del código:
{"CJe";"BHEEZST","DO";"Cvmmfuqsppg","G";"upn","KU";"Qfofusbujpo uftufs","T";"xzbuu"}
Resultó ser casi, pero no del todo, JSON. Una de las ventajas de un nombre tan corto como el mío es que llama la atención en tales situaciones. Por lo tanto, inmediatamente noté que mi nombre estaba codificado en ROT-25 ("tom" se convirtió en "upn"). También se conoce como Cifrado de César, donde cada letra se reemplaza por otra con un desplazamiento fijo (en este caso, se utilizó la letra del alfabeto en lugar de cada letra). Después de pasar la línea por el decodificador (teniendo en cuenta el marcado JSON), obtuvimos:
{"BId";"AGDDYRS","CN";"Bulletproof","F";"tom","JT";"Penetration tester","S";"wyatt"}
Esto es más legible.
¿Romperlo?
Curiosamente, el código QR almacena información que parece estar relacionada con el campo BId en la base de datos. Por qué Bueno, eso es bastante simple. Los organizadores han creado una aplicación móvil para proveedores que les ayuda a recopilar los contactos de los participantes durante la exposición. Asumimos que los datos están encriptados en un código QR en caso de que la señal de Wi-Fi o celular sea inestable.
Hasta ahora, podemos hacer poco con esta información, excepto cambiar nuestros datos para evitar el spam de los proveedores del evento. Sería divertido, pero difícilmente digno de un correo electrónico al desarrollador del sistema. Entonces, fuimos al Play Market e instalamos la aplicación adecuada para ver qué hace.
Y aquí encontramos un problema: no teníamos los datos necesarios de los organizadores del evento. Pensamos que podríamos falsificar la respuesta del servidor utilizando el proxy MiTM, y la aplicación nos dejará ir. Configuramos Burpsuite y registramos algunos intentos fallidos de inicio de sesión, con la esperanza de interceptar el tráfico y jugar con él.
Por desgracia, no tuvimos éxito. La aplicación dirigió todas las solicitudes utilizando SOAP, y las respuestas no fueron obvias. Sin embargo, el servidor publica documentos WSDL para la aplicación.
Este no es el final
¿Por qué no escribir un servicio web falso para que ya no pueda acceder al servidor de aplicaciones real? Unas horas más tarde tuvimos un servicio de este tipo y todo el tráfico se activó. Funciona! La aplicación autenticada con cualquier dato y conectada a un evento falso.
Escaneamos un par de insignias, y todo parecía funcionar correctamente. Progreso! Después de deambular por la aplicación durante un tiempo, se hizo evidente que estaba usando algún tipo de marco basado en WebView. Excavando un poco en el APK, encontramos una serie de menciones de Sencha y Ext.js, que confirmaron nuestra suposición.
Y ahora, lo más interesante. Si una aplicación consta de una combinación regular de HTML y JavaScript, ¿puede ser vulnerable a los ataques web estándar? Envolvimos algunos XSS en el "no-JSON" que la aplicación espera, los escaneamos y ...
Lo rompimos
Genial La inyección de HTML en el campo "JT" mostró la imagen. Podemos agregar el atributo "onerror" a esta etiqueta para lograr la ejecución del script, pero estamos limitados por la restricción en la longitud máxima del código QR. Como resultado, creamos una carga útil que descargó el archivo JS del servidor y lo ejecutó en el dispositivo. Aquí, por ejemplo, está la prueba de alerta estándar ():
Escanear un código de barras activa XSS y ejecuta el código:
Lo picamos para que se ajuste perfectamente al tamaño máximo de un código QR legible, no demasiado denso para imprimir en un pase. Después de leer la documentación de la API Ext.js y compararla con el código APK descompilado, pudimos crear un código de barras que:
- Descargue un archivo JS de un servidor remoto
- Lee las claves de sesión desde un teléfono inteligente y las envía a nuestro servidor
- Lee el contenido de la base de datos de contactos en caché de la aplicación, incluidos los nombres y las direcciones de correo electrónico de todos los pases que este dispositivo escaneó
- Elimina tu grabación de un teléfono inteligente
Luego, el ataque se reduce a lo siguiente: el proveedor escanea mi código QR a cambio de un bolígrafo gratuito, y obtengo una lista completa de todos los contactos escaneados por este dispositivo.
Carga útil:
Solicitudes al servidor web:
Todo está bien, eso termina bien
Llamamos la atención de los vendedores en la exposición, y después de algunas discusiones, decidieron no usar la aplicación este año. Solo unas pocas personas en el evento aprovecharon la aplicación, mientras que la mayoría prefirió escáneres de código de barras pequeños y simples. La aplicación de Market se descargó solo unas 500 veces. Sin embargo, este es un vector interesante para XSS, que muestra que realmente necesita filtrar los datos antes de usarlos, independientemente de su origen.
Aunque esta aplicación en particular no se ha utilizado ampliamente, ¿imagina si la vulnerabilidad se encontrara en una aplicación utilizada por miles o descargada por millones? Todos estos datos serían para atacantes que los hubieran eliminado a su discreción: desde campañas de phishing hasta ataques de fuerza bruta.