El XSS universal: Un desastre contra la privacidad de Android

“No podía creerlo, pero después de varias pruebas, parece que es verdad: en el navegador de Android es posible cargar JavaScript arbitrario en cualquier página”. Con esta introducción de Joe Vennix, del equipo de Metasploit, se presenta el último “desastre de privacidad” en Android (ha habido varios, al menos clasificados como desastres, y Joe ha desarrollado exploit para algunos…). Pero este es un poco especial, por su sencillez y alcance.

Rafay Baloch lo descubrió a principios de septiembre. Un fallo en el navegador por defecto de Android que permite eludir la política de SOP (Same Origin Policy) en las páginas. A efectos prácticos, significa que si se visita una web de un atacante con el navegador por defecto, el atacante podría tener acceso a toda la información de cualquier página. No solo la información explícita sino obviamente a las cookies (si no están protegidas) y por tanto, pueden robar las sesiones de las webs.

¿SOP?

La política del mismo origen en los navegadores es el fundamento de su seguridad. Básicamente (excepto objetos con “src”, y el “location”) significa que el JavaScript de una página no puede mezclarse con otra. Está restringido a la web que lo lanza y no puede salir de ahí. Si lo hiciera, tendría acceso prácticamente al control total de cualquier otra web.

El “truco” en este caso, estaba en introducir un carácter nulo al principio de la declaración del javaScript.
Por ejemplo así:

Ocurre que muchas páginas impiden en su propio código que sean llamadas por un iframe, y abortan su ejecución si se saben que son llamadas así. Sin embargo, se solucionó rápido. Usando “sandbox” u opciones x-frame es posible eludir esto. Es más, ya lo han sacado en un módulo de mestasploit que hace el XSS completamente universal.

¿Es tan grave?

Otros problemas previos (que también fueron muy graves), también fueron sencillos de explotar, pero este es grave por lo sencillo de entender y explotar. Afecta a cualquier versión menos la 4.4, lo que viene siendo un 75% de los Android actualmente en activo. También es grave que exista ya un sencillo módulo de metasploit, y que sea tan fácil de configurar. El atacante solo debe “obligar” a la víctima a visitar una web. Y debe hacerlo con el navegador por defecto… que es el que la mayoría usará. De hecho, parece que se usa tanto como Chrome para móviles.

Fuente: www.netmarketshare.com

En cualquier caso, si la web utiliza la protección “HTTPonly” para la cookie, en principio no podría ser robada por JavaScript, pero sí se podría acceder al contenido de una web (aunque estuviera cerrada la pestaña, basta con que la sesión se encontrase activa). Esto implicaría, que si se tiene la sesión abierta, y se visita una web del atacante, este podría leer correos si se consultó el webmail hace poco, datos bancarios si la sesión del banco aún está abierta, etc.

Obviamente, el usuario debe utilizar otro navegador para protegerse ahora mismo, o esperar un parche… cosa que, como de costumbre en los móviles, es complicado que ocurra a corto plazo.

Los comandos en metasploit para que un atacante prepare una página para robar el contenido de una web, serían tan sencillos como estos:

Otros desastres en Android

Este es el enésimo fallo en Android que “afecta a la inmensa mayoría de dispositivos Android”. En realidad, siempre que se encuentre un fallo en cualquier plataforma, afectará a una inmensa mayoría de esos dispositivos… pero es cierto que con Android se es más propenso a utilizar estos titulares, con porcentajes o números incluidos. Recordemos brevemente algunos de ellos:

• En marzo, con HeartBleed, se anunció que 50 millones de sistemas Android también se veían afectados.

• En junio, se anunciaba que un desbordamiento de pila (que permitía la ejecución de código) en el KeyStore de Android afectaba al 86% de los dispositivos Android.

• En julio, los Android desde 2010 estaban en riesgo, porque el Fake ID permitía suplantar el certificado de cualquier app. Esto era el 82% de los dispositivos.
• La vulnerabilidad “Master key” en el verano de 2013, también afectaba al 99% de los Android, y permitía modificar el apk sin romper la firma criptográfica.

Aun así, parece que todavía no se ha detectado que estos fallos hayan sido explotados de forma masiva por atacantes.