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 l
e 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 ataque
APT 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
apps hací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 Messages que es capaz de localizar las páginas borradas y recomponer los datos para extraer qué registros fueron borrados de cualquier base de datos
SQLite.
A la hora de realizar un pentest, es necesario disponer de herramientas potentes con las que nos sentamos cómodos trabajando para así agilizar nuestro trabajo y tener mejores resultados. No es algo diferente en el mundo del hacking iOS, por ello, es necesario que nos actualicemos y probemos las herramientas existentes para escoger la que mejor se adapte a nuestras necesidades. Por ese motivo, hoy queremos dejar aquí este artículo facilitando unas herramientas disponibles en la red.
