Share on Google+Share on FacebookTweet about this on Twitter

En realidad no iba a escribir nada al respecto, pero me ha hecho gracia el titular que he leído hace unos segundos:

“Virtually all Android Smartphones vulnerable to hackers” (Virtualmente todos los dispositivos Android vulnerables a los Hackers)

 

Vamos a ver. Hace un par de días, un par de señores (creo que fueron dos) publicaron que habían descubierto un problema de seguridad en Android en referencia a como estos se comunican con los servidores de Google y su potencial uso por terceras personas. Esta noticia era y es completamente cierta. El problema es que de esa noticia aparecen cientos de otras tantas que desvirtúan totalmente la noticia original. Titulares como el que he pegado al comienzo, otros que dicen que cualquier hacker puede acceder a toda la información de los terminales… bla bla bla. Así que me gustaría explicar brevemente que hay de cierto y que hay de no cierto en todo ello:

El fallo de seguridad descubierto reside en la forma en la que los servidores de Google transmiten información a nuestros dispositivos Android para actualizarnos nuestros datos como la agenda o el calendario (quizás algunos más). A día de hoy cuando accedemos a la gran mayoría de cualquier web o servicio online lo hacemos por medio de un usuario y una contraseña. Por seguridad estos datos “jamás” viajan tal cual, siendo lo más común el uso de hash para codificar la contraseña. Esto se hace por una razón muy simple, para que nadie con un Sniffer pueda leer nuestra contraseña, que se encontraría en texto plano. De nuevo por seguridad, estos datos no son enviados constantemente a dichos sites, sino que como sabemos en el peor de los casos la sesión dura hasta que nos deslogeamos de la aplicación. Todos sabemos que incluso cuando entramos en estos sitios, si marcamos la opción de “Recordar este equipo” y similares, produce que incluso cuando cerramos nuestros navegadores, si volvemos a abrirlos y accedemos a la misma web entramos automáticamente en nuestra sesión sin necesidad de introducir datos, y es más, no es que el navegador recuerde el nombre y la contraseña (que lo pueden hacer), sino que el equipo nuestro ha guardado lo que generalmente se llama un token de seguridad. En los navegadores, estos Tokens de seguridad ¿donde están? En las Cookies por supuesto. El navegador accede a la web en cuestión y dado que posee una Cookie anterior en el PC guardada de dicho site, nuestro navegador envía dicha Cookie a la web remota. El servidor en el otro lado verifica la información dentro de la cookie (y con ello los token de seguridad) y si son correctos le devuelve directamente al cliente la sesión abierta.

Este funcionamiento es el que se usa en más del 90% de todas las web en las que tenemos unos credenciales de accesos, lo que evita que nuestro usuario y contraseña sean enviados cada dos por tres, que como hemos dicho incluso cuando se requieren se envían de forma codificada. El problema es que estos Token de seguridad suelen tener una vigencia dada, en el caso de las Cookies tres cuartos de lo mismo. Es decir, que en teoría si el Token tiene una vigencia de 1 mes, si la Cookie tiene una vigencia también de un mes podremos estar entrando en dicha web sin necesidad de volver a iniciar sesión, ya que digamos que nuestra Cookie contiene la llave (El Token) necesario durante dicho período.

El problema no obstante es que igual que con un Sniffer se puede capturar un posible nombre de usuario y contraseña enviados en texto plano, se puede hacer exactamente lo mismo con una cookie o un Token (que no necesariamente tiene que enviarse por Cookie, aunque es lo más normal). Si cualquiera está con un Sniffer en la red en la que nos encontramos puede interceptar cualquier dato que no esté cifrado, incluyendo por supuesto cualquier Cookie de sesión o token que se esté retransmitiendo. La diferencia entre interceptar una Cookie o un Token frente a una contraseña es que el Token generalmente se puede revocar, además de tener una vigencia limitada, mientras que la contraseña es digamos la llave maestra. Una Cookie de sesión o un Token robado puede usarse de forma “simple” para lograr el acceso a la sesión de dicho usuario, pero no de cambiar la contraseña por ejemplo o de tener acceso a ella. También existe la otra limitación aun más grande, y es que en cualquier momento que el usuario legítimo cierre la sesión para la cual se emitió dicho Token, este deja de servir y será imposible lograr de nuevo logearse por él.

Pues bien, lo descubierto en este caso con Android es que Google no retransmite esas Cookies/Token por TLS/SSL, y por tanto pueden ser potencialmente capturados por cualquiera que coloque un Sniffer. Posteriormente podría usarse dicha Cookie/Token para acceder a los datos del servidor de Google de dicho usuario a los que dicha Cookie/Token tenían enlazados. Es decir, si capturamos un Token cuya finalidad es mantener abierta la sesión con el calendario de Google, podríamos acceder al calendario de dicho usuario, incluso modificar datos en él mientras que dicho token tenga vigencia.

A día de hoy la única forma de evitar esto es por medio de conexiones seguras SSL/TLS. El 90% de todas las web NO USAN conexiones seguras para transmitir Cookies o Token. Es más, lo raro es ver que usan estos sistemas para transmitirlas, que por supuesto no deja de ser un fallo bastante importante de seguridad. En este caso, Google tan solo usa SSL/TLS en TODAS las aplicaciones (salvo Picassa creo) en la versión 2.3.4.

 

¿Que implica realmente todo esto?

Quien esté educado en las buenas costumbres de seguridad, no tiene que preocuparse absolutamente de nada, esto no es algo que le importe. ¿Por qué? Porque la única forma de que le coloquen un Sniffer es haciendo uso de una red no segura, y si un usuario se conecta a una red no segura se está ateniendo a las consecuencias. Es decir, quien no tenga problemas en sentarse en un PC que no es suyo y que pertenece además a una red que tampoco conoce y se atreva a meter datos como tarjetas de crédito, contraseñas… os puedo asegurar que el último de sus problemas es que su aplicación no envíe por SSL ciertos datos.

JAMAS se deben de usar redes que no sean seguras. Por ahí también he leído de forma errónea que este problema se encuentra solo cuando nos conectamos a redes WIFI abiertas.. Es FALSO!! Un ejemplo sencillo, imaginar que vamos a casa de un amigo que tiene una red WIFI WPA2-PSK de la cual sabemos la contraseña. El contenido en las redes WIFI es cifrado del cliente al router y nada más, cualquier sniffer bien colocado y con la habilidad pertinente nos da acceso a dichos datos, evidentemente tenemos que estar dentro de dicha red. La única diferencia es que si la red es abierta los datos al transmitirse por aire son más vulnerables.

Solución? Evidentemente Google ya lo ha solucionado así que tan solo hay que esperar q los fabricantes vayan implementando las últimas actualizaciones de Google (yo llevo con Android 2.3.4 ya unas semanas, no es que sea una versión de ayer). Y más importante q cualquier actualización, NO USAR REDES PUBLICAS, o al menos NO TRANSMITIR DATOS QUE PUEDAN SER PRIVADOS. Si no estamos seguros de la red a la que nos vamos a conectar no pasa nada, tan solo tenemos que deshabilitar la sincronización de Android mientras usemos dicha red y listo, así nos aseguramos que nuestras aplicaciones de Google como el calendario o la agenda queden a buen recaudo.

Como he dicho, aunque no deja de ser un problema de seguridad claro, no tiene prácticamente repercusión. Se pueden interceptar por un Sniffer inifinitamente más datos de un usuario por el uso en sí que hace de las redes que porque Google no envíe dichos Token por SSL/TLS. Por eso es completamente falso afirmar que Android es completamente vulnerable a los Hackers. Android no es vulnerable, es un fallo de seguridad que de echo está ya solucionado, no da acceso a nuestra información en el teléfono, en el peor de los casos da acceso por tiempo limitado a algunos datos, y solo durante un tiempo limitado y solo cuando usemos redes WIFI ajenas en las que haya alguien a la espera para ello. Creo que hay una gran diferencia entre este tipo de vulnerabilidades (que son importantes repito) a tener una vulnerabilidad por la cual se pueda tener acceso a los datos del telefono o a controlarlo de forma completa.