Share on Google+Share on FacebookTweet about this on Twitter

Introducción

Con la llegada del buen tiempo y los períodos vacacionales, no somos pocos los que emigramos a la playa para descansar, relajarnos y olvidarnos de todo durante unos días. En un mundo movido por la tecnología parece casi de obligado cumplimiento ir a donde quiera que vayamos con nuestros dispositivos, y por supuesto proveernos con conexiones datos móviles, y cuando podemos conectarnos a redes WIFI externas. Y de eso vamos a hablar hoy, de algo que parece no entrarle en la cabeza a muchos, “Conexiones WFI de terceros”.

Todos preferimos como es natural conexiones WIFI a conexiones de datos, ya sea en dispositivos móviles y ordenadores. El problema fundamental es que si nos conectamos a una red que NO CONTROLAMOS no podemos saber que está pasando realmente en ella en gran medida, y eso nos deja (o puede dejar) totalmente vendidos, como veremos más adelante. La regla debería de ser muy sencilla: Si nos conectamos a una red desconocida, no quejarse de las consecuencias, y eso va por todos aquellos que les gusta llegar a cualquier sitio y buscar alguna red abierta o alguna red segura de la que pueda obtener la contraseña.

En teoría, en un mundo perfecto, todas las comunicaciones deberían de ir cifradas punto-a-punto para que fuese imposible interceptar dicha comunicación. Ese es el planteamiento inicial de los protocolos seguros como TLS/SSL, que nacieron de la necesidad de poder enviar y recibir datos a través de Internet sin miedo a que un tercero pudiese interceptar dicha comunicación. En las redes privadas/públicas (ya sean WIFI o Ethernet) esto toma un cariz muy especial, dado que la mayoría de las veces a nuestra misma red están conectados otros usuarios, ya sean nuestros propios familiares en caso de una red doméstica, ya sea algún vecino que logró obtener nuestra clave WIFI, ya sean todos los alumnos de la red de una universidad… etc etc etc. En estas redes, cualquiera de ellos podría ser un “tercero” que malignamente quisiese interceptar la comunicación de uno de los usuarios de dicha red. Si todo el tráfico fuese en texto plano (sin cifrar), ese usuario malvado podría sin ningún esfuerzo espiar TODAS las comunicaciones desde y hacia Internet de ese usuario. La implementación de protocolos seguros como TLS/SSL imposibilita esto dado que toda la información que sale del dispositivo del usuario se manda y recibe cifrada, y la codificación se realiza en el mismo dispositivo. ¿Pero es esto fiable? Bien implementado y con políticas de seguridad correctas debería de serlo… pero ahí es donde entran los expertos en seguridad para dar tirones de oreja a los programadores, que como personas humanas cometen errores de seguridad.

Para no alarga demasiado la historia, voy a resumir muy brevemente como es posible la comunicación TLS/SSL para garantizarnos la seguridad. Quien sepa como funciona que salte la sección si lo desea.


TLS/SSL

TLS/SSL es posible a lo que podemos llamar cadenas de confianzas de certificados. Un servidor posee un certificado de seguridad que además de servirle para todas las tareas de cifrado lo identifican de forma inequívoca. De este modo cuando un usuario quiere realizar una conexión segura hacia él, lo primero que hace este servidor es enviar este certificado como carta de presentación. El dispositivo del usuario por su parte (el navegador, aplicación…) antes de realizar la configuración del canal seguro, verifica como es natural la legitimidad de dicho certificado. Si todo es correcto se crea un canal seguro de comunicación, si la aplicación que sea detecta un error en dicho certificado (ya sea por que ha sido alterado, haya caducado, sea incorrecto, se desconozca el emisor…) la comunicación debería de cerrarse de forma automática, o al menos advertir de ello con un gran “WARNING!!”

Si un tercero intentase interceptar la comunicación sencillamente “pinchando” la línea, tan solo vería pasar por él datos sin sentido, cifrados. Pronto aparecieron vectores de ataques para que este usuario (que llamaremos a partir de ahora hombre en medio y de ahí este tipo de ataques Man-In-The-Middle, MitM) pudiese intentar sortear estas medidas de seguridad. Quitando ataques conocidos a SSL/TLS y fallos de implementación existentes (como el famoso heartbleed de hace unas semanas), es imposible poder descifrar los datos que circulan por dicho canal sin poseer la “llave” de ellos. La llave de la cual depende todo en última instancia es el certificado que envía el servidor al usuario (la clave privada de este que celosamente guarda el servidor en cuestión y que jamás sale de él y que evidentemente nunca podremos obtener).

conexionnormal

Como hemos dicho, cuando el sistema funciona correctamente y no hay flecos, tan solo obtendríamos datos sin sentido de dicha comunicación. Pero… que pasaría si un atacante se colocase en medio de la comunicación de ambos e intentase impersonar/suplantar el servidor de destino de cara al usuario y impersonar/suplantar al usuario de cara al servidor?? En este nuevo modelo, el usuario sin saberlo se estaría conectándose al equipo del atacante, y sería a este al que le solicitaría el servicio (por ejemplo una web) que desearía tener acceso, en vez de al servidor real. Llegado a este punto, el atacante tan solo debería de proveer con un certificado propio al usuario ingenuo, y si la conexión se estableciese correctamente, luego por otro lado, el atacante se conectaría al servidor legítimo para “pasar” dicha información a él. Es decir, el atacante establecería en este caso dos comunicaciones seguras, una con el usuario y otra con el servidor legítimo. El usuario no podría saber que está conectado realmente al atacante en vez de al servidor legítimo, y el servidor legítimo tan solo tendría una conexión normal en sus redes con lo que tampoco podría sospechar nada. Dado que el atacante generó su propio certificado que envía al usuario, posee también su clave privada y por ello puede decodificar la información que PC Usuario<->PC MidM generan. Del mismo modo como es este quien se conecta de forma legítima al servidor externo, también posee la clave de sesión de dicha conexión, y por tanto también puede descifrar los datos entre PC MidM<->Servidor.

El nuevo modelo por tanto sería algo así:

conexionmidm

El atacante (MidM) en este caso podría ver todo el tráfico que circulase por él, aunque fuese cifrado punto a punto… o más correctamente, en este caso no sería cifrado punto a punto, sería un cifrado usuario-MidM MidM-servidor.

Esto en teoría no debería de ser posible. Para evitar precisamente este tipo de técnicas, se hace uso de la propiedad que tienen los certificados para verificar no solo su integridad, sino su autenticidad. Esto es posible gracias a que cada certificado debe de estar firmado por otros agentes certificadores, generalmente por un CA (Autoridad de Certificación) que será quien en última instancia emite dicho certificado para dicho servidor. Dicho certificado digital es firmado por el CA de tal modo que cualquier alteración revocaría su validez. Pero la dependencia de un CA no solo elimina la posibilidad de que el certificado original sea modificado, sino que además garantiza que el certificado que el emite es genuino para el servidor concreto.

Sin poder modificar el certificado original (dado que automáticamente el software del usuario rechazaría la conexión) solo queda la opción de emitir un certificado propio. El problema es que el certificado que podríamos emitir evidentemente no vendría firmado por un CA reconocido. Esto es posible porque los programas que usamos ya sean aplicaciones, gestores de correos, navegadores… poseen una base de datos que se va modificando día a día con futuras versiones de un listado de entidades certificadores de confianzas, de tal modo que si un certificado que nos haga llegar un servidor está firmado por un CA que tenemos en lista, automáticamente se da por genuino. Es algo así como un sello de calidad. Nosotros podemos crear en cualquier momento un certificado totalmente válido y supuestamente para cualquier dominio, pero ninguna entidad de certificación fiable lo firmaría. Tan solo podríamos firmarlo nosotros mismos. ¿Esto anula el certificado? No realmente, el certificado es totalmente válido de cara a cualquier software, pero dependiendo de la política que cada software aplique al encontrar un certificado firmado por CA que NO TIENEN EN SU BASE DE DATOS sucederá una cosa u otra.

Todo el mundo sabe lo que sucede en la mayoría de navegadores Webs cuando esto sucede. Aparece un cartel de advertencia avisando de que el certificado no es válido, pero nos suelen dar la opción de continuar navegando. Esto es debido a que en realidad existen muchas webs totalmente genuinas (sobre todo webs de administraciones públicas) que usan infraestructuras propias de certificación y que los navegadores aun no tienen en sus bases de datos. Si no instalamos los certificados raíces (CA) el navegador nos bombardeará con avisos constantemente. En los navegadores Webs normalmente es suficiente con una advertencia de seguridad, y es el usuario quien debe de escoger que hacer… aun así suele ser muy tedioso porque por lo general el usuario no suele entender dicho mensaje o advertencia… y generalmente rechaza la conexión aunque sea una web legítima… y luego las miles de quejas en las administraciones públicas de que los procesos en los que se hace uso el certificado digital personal solo da problemas y errores.

¿Pero que pasa con los móviles y tablets? Aquí la cosa es más compleja. Tenemos cientos de aplicaciones constantemente conectadas a Internet, y evidentemente si queremos un mínimo de seguridad presuponemos que la mayoría de esas conexiones son cifradas, y evidentemente los protocolos TLS/SSL es lo que se usa en su 95%. ¿Que política aplican los dispositivos móviles? No hay ninguna política concreta, y depende de cada Sistema Operativo o aplicación.

Por ejemplo, por lo general tanto en Android como en iOS existe un almacen de certificados digitales al estilo de los navegadores Webs, en los que se puede añadir un certificado si se desea. Por defecto ambos sistemas operativos deniegan cualquier tipo de conexión que realicen las aplicaciones si estas reciben un certificado firmado por una entidad que no tienen registrada. No obstante, ambos igualmente poseen en sus API de programación modos para evitar esta salvaguarda, de modo que una aplicación podría ser programada para que en caso de inconsistencia del certificado o de firmado por un CA que no se tenga, aceptar la conexión de todos modos. Por ejemplo, imaginar que el creador de la aplicación no usa un certificado firmado por un CA que los dispositivos tengan en su BD!! Es necesario que tengan un modo de sortear esta seguridad.


La Crónica Contada

Dicen que la curiosidad mató al gato, y a mi no me gusta quitarle vidas. Y como tantas otras cosas todo comienza por un: “Que pasaría sí…” en mi caso fue un:

“Cuantos incautos se conectarían a mi Router si añado una red WIFI abierta?” Mirándolo por el lado bueno estás prestando un “servicio” y dando WIFI a quien quiera, por otro lado esos usuarios deberían de saber que no puedes fiarte de NINGUNA conexión WIFI que no controles… y muchas veces las que controlas si no están bien aseguradas tampoco. El resto es sencillo… desvincular por seguridad la red secundaria WIFI de la primaria, redirigir todo el tráfico desde dicha interfaz del router hacia mi propio equipo en el que levanté un servidor proxy transparente para poder ver/manipular/inyectar el tráfico que quisiese y una pequeña infraestructura igualmente para inyectar certificados firmados por un CA inventado.

Es decir, todo el tráfico que se generase por usuarios conectados a mi punto de acceso “libre” pasaría por mi PC antes de llegar a su destino. Con ello automáticamente ya podría tener acceso a todo el tráfico no cifrado sin que los usuarios pudiesen hacer nada, simplemente por conectarse a un punto de acceso que no estaba protegido por una contraseña. Solo con esto podríamos escribir todo un libro sobre fallos de seguridad de tantas webs que envían en texto plano contraseñas, usuarios y datos de todo tipo… pero eso lo dejaremos para otro día, hoy se trataba de analizar tráfico cifrado.

Para poder “ver” el tráfico cifrado sin complicaciones mayores o trucos de cualquier tipo que al final puede ser culpa del usuario picar o no picar, la idea era comprobar la solidez de las aplicaciones a la hora de manejar certificados válidos firmados por CA desconocidos. La lógica dice que tan solo algunas aplicaciones móviles permitirían dicha conexión cifrada, mientras que la inmensa mayoría ni siquiera advertirían al usuario de un error de certificado y denegarían la conexión… lo cual es igualmente malo, puesto que para el usuario tan solo tendría la sensación de que algunas cosas le funcionaban y otras no.

Como era de esperar, en tan solo unos minutos ya tenía unos cuantos usuarios conectados a mi AP, la mayoría hay que decir que el tráfico era generado de forma automática por aplicaciones de fondo instaladas y otros servicios en dispositivos móviles, como evidentemente comprobaciones de correo, actualizaciones de redes sociales, datos de localizaciones… mirando el tráfico en los primeros 5 minutos algo inexplicable, la conexión realizada por un iPad en la comprobación del correo electrónico de una cuenta de hotmail… contenido protegido como era de esperar por TLS/SSL, pero la conexión no se estaba rechazando. Esto es lógico de ver en aplicaciones que no podemos tildar de “importantes”, pero si hablamos del correo electrónico la importancia es en mayúsculas:

(Nota: Como es lógico he eliminado los datos sensibles de dicho usuario)

POST /Microsoft-Server-ActiveSync?User=usuario@hotmail.com&DeviceId=AppTATATATATA190&DeviceType=iPad&Cmd=MoveItems HTTP/1.1
Host: dub405-m.hotmail.com
X-MS-PolicyKey: 0
Accept-Language: es-es
User-Agent: Apple-iPad3C6/1104.167
Accept: */*
Content-Type: application/vnd.ms-sync.wbxml
Connection: keep-alive
Cookie: laquesea
Authorization: Basic dXN1YXJpb0Bob3RtYWlsLmNvbTpwYXNzd29yZA==
Content-Length: 130
MS-ASProtocolVersion: 14.0
Accept-Encoding: gzip, deflate

Solo con la cookie de sesión sería suficiente para poder acceder al correo electrónico, aunque sería imposible conocer la contraseña de dicha cuenta como es natural. Lo que más me sorprendió fue ver que tanto el correo como la contraseña de la cuenta estaban siendo enviadas en texto plano!! En la propia cabecera del paquete en una conexión cifrada por un certificado de un CA falso. Si vemos en la cabecera del paquete:

“Authorization: Basic dXN1YXJpb0Bob3RtYWlsLmNvbTpwYXNzd29yZA==”

Para cualquiera que sepa un mínimo de codificación digital, sabrá que eso no es más que una codificación en Base64, revertido: “usuario@hotmail.com:password”.


Conclusiones

Este tipo de fallos de seguridad es muy común verlos como digo en servicios de poca confiabilidad, pero no es algo que sea ni mucho menos normal encontrar en servicios de uno de los grandes, y lo digo tanto por parte de Apple como por parte de Microsoft. Esto puede parecer un poco enrevesado y complicado, pero pensemos realmente en ello.

No tengo ahora mismo un iPad para probar, pero por el User-Agent del paquete puedo deducir que el usuario en concreto no usó la aplicación concreta del AppStore, sino que usó el gestor de cuentas por defecto en iOS para configurar su cuenta de Hotmail. Si esto es así, el fallo de seguridad recae en Apple, dado que es iOS quien en su gestor de cuentas de Hotmail no rechaza por defecto las conexiones potencialmente fraudulentas. Esto es un fallo de seguridad bastante importante!! Pensar que el primer dispositivo iOS (y el único) que se ha conectado a mi AP ya me estaba dando automáticamente su cuenta al completo (usuario y contraseña) sin que él pudiese hacer nada ni se enterase de nada. ¿Cuantos usuarios de iOS usan Hotmail?? Siempre hablando en hipotéticos, sería tremendamente sencillo robarle la cuenta de Hotmail a cualquier usuario de iOS, dado que además las comprobaciones de correo se hacen de fondo… Lo más preocupante de todo ello es si este problema no solo afecta realmente a Hotmail, sino que es un problema del gestor de correos de iOS y afecta igualmente a otros proveedores…

Existe una alternativa a ello. Que dicho usuario estuviese usando la aplicación de Microsoft y no el gestor propio de iOS, que es otra opción. En este caso la responsabilidad recaería íntegramente en Microsoft, puesto que habrían sido sus programadores los que permisivamente no ajustaron bien las políticas de seguridad.

En cualquier caso es algo realmente bochornoso y preocupante. Como digo es algo que puedes esperarte de empresas que no tienen como es natural los mismos recursos o pueden ser más… “despistados”, pero en el caso de Apple o Microsoft es algo totalmente inexcusable.

Para colmo de males, no solo se trata de que sea posible realizar un ataque MidM, sino que la aplicación (Apple o Microsoft) envía en plano la contraseña en el paquete. Sí, evidentemente se supone que es suficiente con TLS/SSL, pero a día de hoy esto es de bien sabido no ser suficientemente seguro. Tal es así que los servicios realmente decentes usan además de conexiones fiables TLS/SSL otros modos de enmascaramiento de contraseñas. Por ejemplo, habría sido tan sencillo como expresar la contraseña como un Hash MD5/SHA1 (o lo que se prefiera) con lo que habría sido imposible revertirla. Es preocupante ver que quitando el amparo de TLS/SSL los datos altamente sensibles viajan tal cual…

En comparación, Google, aun cuando uno interceptase su propio tráfico y abriese absolutamente todas las conexiones TLS/SSL instalando el certificado CA pertinente, no podría ser posible acceder a la contraseña de dicho usuario en ninguno de sus servicios dada la alta codificación de los datos fuera ya del amparo de TLS/SSL. Vale, eso no significa que sea imposible a lo mejor robar una cookie de sesión o intentar obtener más información… pero al menos la contraseña el atacante no la obtendría.

Es sumamente importante concienciar a los usuarios que aun cuando una red WIFI pueda ser tentadora, puede esconder un peligro mucho mayor de lo que uno pueda imaginar. En este caso con los datos del corroe de dicha persona podría entrar no solo impunemente en su correo, sino a cada uno de los servicios asociados a él: Paypal?? Redes Sociales? Tiendas Online? Servicios de Geolocalización si los tiene?? Agenda? No creo que sean cosas que se deban de tomar a risa o a la ligera, y mucho menos creer en la seguridad que incluso esos que llamamos “los grandes tecnológicos” nos dan. La mayor seguridad la da el sentido común señores, y por mucho que prefiramos una conexión WIFI frente a una de datos, ya no solo veamos siquiera el daño o no daño que podemos provocar a la otra persona si es una “conexión wifi robada”, sino que la peor parte nos la llevamos nosotros mismos por regla general. No pensemos nunca que somos los más listos del mundo, que tenemos aplicaciones y utilidades para robar contraseñas WIFI, que hemos tenido suerte de encontrar una red Abierta, que… porque os puedo asegurar que siempre hay alguien más listo detrás aprovechándose de todo ello.

Por supuesto la infraestructura que he levantado en 5 minutos es infinitamente mejorable, para empezar sería treméndamente sencillo enviar a cualquier usuario que se conectase a un portal de captación en el que se obligase a los usuarios a instalar un certificado para “navegar” y que dicho certificado fuese realmente el certificado del CA creado… con lo que de instalarlo el dispositivo quedaría totalmente abierto hacia el atacante, y todo el tráfico cifrado sería descifrado dado que de cara al dispositivo dicho CA sería igual de válido que cualquier otro.

Suma y sigue… suma y sigue.

El fallo ya lo he notificado a Microsoft y Apple igualmente… aunque para el caso que suelen hacer…

Feliz Primavera amigos.