Estudio revela graves fallos en las apps de banca para iOS

Estudio revela graves fallos en las apps de banca para iOS

Casi todos los bancos hoy en día, por no decir todos, cuentan con apps para el sistema operativo iOS que permita a sus clientes gestionar sus cuentas desde terminales iPhone o iPad. Con 40 de las apps, pertenencientes todas ellas a bancos del Top 60 mundial, el investigador Ariel Sánchez, de la conocida empresa consultora en seguridad informática IOActive, decidió hacer un estudio mirando la calidad y seguridad de las mismas. Las apps fueron elegidas de bancos distribuidos geográficamente por todo el mundo, tal y como se puede ver en este gráfico.

Figura 1: Distribución de los bancos dueños de las apps auditados en este estudio

En solo 40 horas de trabajo, probando una serie de tests de seguridad orientados a validar la seguridad únicamente del código del cliente, es decir, sin mirar ni probar nada en el lado del servidor. Para las pruebas se utilizaron las herramientas ootol, el popular Burp Pro y conexiones SSH al terminal con jailbreak sobre el que se corrieron las apps. El resultado del número de bugs encontrados está recogido en la siguiente gráfica.

Figura 2: Resumen de vulnerabilidades encontradas en las apps
Según se publica en los resultados, algunos datos arrojan apps peligrosas:

- 40 % de las apps no validan la autenticidad del certificado del servidor: Es decir, que no hacen las validaciones oportunas para comprobar que es el correcto, como podría ser hacer un uso de Certificate Pinning lo que dificultaría la posibilidad de hacer ataques Man in the middle. Esto es algo que en el pasado le ocurrió a la propia app de Paypal para iOS.

- 90 % de las apps contienen links en las UIWebViews que no van bajo SSL: lo que permite interceptación de datos e inyección de comandos JavaScript/HTML en el cliente para hacer ataques que permitan robar datos e incluso enviar mensajes SMS o e-mails desde el terminal.

Figura 3: Códigos JavaScript/HTML inyectados bajo un ataque man in the middle

Entre otros ataques, por supuesto está como se ve en la imagen superior la posibilidad de inyectar un falso formulario de login que haga phishing a través de la UIWebView para robar las credenciales. El formulario de este ejemplo es el siguiente código inyectado.

Figura 4: Código inyectado para hacer el robo de credenciales con un falso login

- El 70 % de las apps no tenían una autenticación de segundo factor disponible: En estos casos hace referencia a que los usuarios se pudieran autenticar con tokens RSA, validación con mensajes enviados por SMS o el uso de alguna tecnología similar a Latch para aprobar si la cuenta está activa o desactivada - puedes probarlo en el banco de pruebas Nevele Bank -.

- Ficheros de log con información sensible: La mayoría de los ficheros de log cuando se produce un crash de la app contenían información sensible filtrada que podrían ayudar a un creador de exploits a preparar un 0day contra esa app en el cliente en un esquema de ataqueAPT client-side.

Figura 5: Informe de crash con información leakeada

A esto hay unir que menos del 20 % de las apps no tenían activadas las opciones de Position Independent Executable (PIE) y Stack Smashing Protection que ayudarían a dificultad la creación de exploits consistentes.

- Uso incorrecto de información de debugging en el ASL: También la mayoría de las appshacían el uso abusivo de datos al Apple System Log, dando como resultado fugas de información que podrían ser accedidas por otras apps dentro del mismo terminal.

En una segunda parte del estudio se hizo un análisis estático de las apps utilizando las herramientas de ingeniería inversa como gdb, IDA Pro, Clutch o IPCU, pudiendo sacar datos más que jugosos de cómo están construidas algunas apps, como pueden ser los siguientes:

- Credenciales de desarrollo hardcoded en el código: En una app se pudo acceder a un usuario y contraseña utilizado en proceso de desarrollo de la app que se había quedado en la compilación.

Figura 6: Credenciales usadas en el desarrollo de la app almacenadas en el código

- Fuga de información de infraestructura: En muchas apps era posible conocer la estructura del sitio del servidor sólo con analizar el código, donde se puede acceder a URLs internas de la organización escritas en él.

Figura 7: Información de URLs de las apps

- Fugas de informaciones menores: También algunas apps contenían información de los servidores internos utilizados y rutas de ficheros de los equipos de los desarrolladores.

Figura 8: Direcciones IP internas y rutas locales de usuarios desarrolladores

Por último, muchas de las apps hacen uso de almacenamiento inseguro de información, algunas de ellas en bases de datos SQLite sin cifrar que permiten acceder a datos de las cuentas de los clientes de las apps de forma muy sencilla.

Figura 9: Bases de datos SQLite con información sensible sin cifrar

Hay que recordar que el uso de bases de datos SQLite puede llevar a que mucha de la información que de ellas se borra pueda ser recuperado por servicios como Recover Messagesque es capaz de localizar las páginas borradas y recomponer los datos para extraer qué registros fueron borrados de cualquier base de datos SQLite.

seguridadapple.com