Apple, el brute forcing and #TheFappening

  • 0

Apple, el brute forcing and #TheFappening

findmyiphone
Estos días ha ocurrido algo que era de esperar, otra vez se nos confirma que la seguridad en los móviles esta infravalorada.

La providencia me hizo escribir un post al respecto justo antes de que comenzase el periodo estival, “owasp mobile security” donde describí en gran parte cuales eran las principales amenazas para la seguridad de los móviles y su categorización según OWASP.

 

A la luz salió entonces este script, como no, en python con el nombre id_brute.py, descargable en id_brute.py

Pues no ha tardado mucho tiempo en producirse lo que muchos temían, un fallo de seguridad bastante grave ha hecho que se vulnere la privacidad de gente famosa. La ley de Murphy se vuelve a cumplir.

Apple en este caso, ha sido víctima de un ataque de fuerza bruta a datos privados de usuarios de su nube, a través de un script escrito en python que brutea las credenciales del usuario de una aplicación concreta.

Ha habido muchas declaraciones acerca de quien tiene la culpa, algunos dicen que si apple, otros que la app, algunos incluso hablan de los famosos y sus claves.

Arrojando un poco de luz sobre todo esto:

Supuestamente para utilizar un servicio apple solicita varios tokens, sin embargo en el script, se puede leer esta línea de código donde el ID del iphone (uno de estos tokens de seguridad) se crea como una variable estática, de hecho el comentario en el código es “créala aleatoriamente!”.

¿Según esto, apple habría obivado ese token a la hora de acceder a la nube?

#make it random!
"deviceUDID": "0123456789485ef5b1e6c4f356453be033d15622",

Otros hablan de un ataque más dirigido, ¿Es posible que el hacker utilizase alguna técnica de phising para extraer esos Ids y luego usarlos en su script? Se habla de que es posible que el hacker sacase los datos de los IDs a través del servicio “Find My Iphone”, también, al perecer con un ataque de fuerza bruta.

 

 

En cualquier caso, a nuestro modo de ver, el gran fallo es de apple. Puesto que, los servicios de almacenamiento en la nube son de ellos y ellos son los que deberían encargarse de la seguridad. Ellos son los responsables últimos de que sus APIs manejen estos tokens supernecesarios de seguridad y ellos deberían ser los que aclarasen cual a sido el problema. Esta descrito como M5 Poor Authorization and Authentication Según la categoría OWASP para este tipo de riesgo. No porque la autorización sea pobre, sino porque no ofrece ninguna prevención contra la fuerza bruta aparentemente.

En cuanto a las fotos, nada espectaculares, ni siquiera excitantes, algunas un poco íntimas, en internet se han creado canales con el nombre #TheFappening, subreddits, etc y cientos de salidos las han guardado cual Golum con el anillo de poder (su tesoro). Algunos famosos se lo han tomado mejor que otros y se prepara una lluvia de demandas.

En cualquier caso, volvemos a insistir: Las passwords tienen que ser seguras, confiar la seguridad a un grupo pequeño pero poderoso de compañías, no va a hacer más que esas compañías sean objetivo de continuos ataques a sus usuarios, es lógica pura.

Entramos en una era donde confiamos la seguridad de nuestros datos a potencias extranjeras, empresas multinacionales, etc sin pararnos a pensar en la seguridad de nuestros datos. No voy a cuestionar aquí los beneficios de la nube, si no obstante los beneficios de una nube con sistemas de cifrado de datos en el almacenamiento o simplemente que las aplicaciones cifren los datos de los usuarios.

Sinceramente creemos que nunca se sabrá la verdad de como se hizo el ataque. Apple dirá que sus sistemas son seguros, que no han tenido brechas de seguridad. Los expertos de seguridad crearan teorías mas o menos elaboradas sobre como pudo pasar. Y el usuario … seguirá siendo el usuario, que con tener su móvil “chulo” de ultima generación que tenga unos iconos superchulos, estará satisfecho. Al final todos pensamos que “Eso nunca me puede pasar a mi”. Lo malo es que si te puede pasar. En eso vamos a agradecer al hacker darnos una lección sobre seguridad, ya que si los que padecieran esta intromisión no fueran famosos quizás nadie prestaría atención a la seguridad de sus dispositivos


  • 1

OWASP Mobile Security Project

Selección_004Ahora que se acercan las vacaciones, empezamos o a pensar en la cantidad de nuevas vulnerabilidades encontradas para los distintos sistemas operativos de los móviles de los últimos meses, pues son fechas en las que tendemos a utilizar estos, en especial los que tienen acceso a redes 3G/4G y por supuesto incorporan tecnología wireless, vamos, lo que se dice un  smartphone.

Así que la gran pregunta es si se puede usar el móvil con seguridad y privacidad cuando estamos fuera de casa, a sabiendas de los riesgos que supuestamente corremos al conectarnos a redes desconocidas y/o no confiables. Tanto es así que hasta se ha creado una agencia europea. ENISA es la agencia europea por la información y la seguridad en la red y en su web podemos encontrar su propio top 10 de estos riesgos. Si profundizamos en esta web podemos ver que hay una descripción de los posibles ataques y sus posibles ejecuciones, pero siendo un poco crítico con Enisa tengo que decir que tienen que actualizar la información, si bien, Enisa sigue de cerca y tiene colaboración con OWASP, he observado que la información que está exponiende corresponde mayormente al año 2010 y que dicha información tiene en mi humilde opinión una catalogación menos precisa de estos riesgos. De hecho los riegos 1,2 y 3 que Enisa clasifica vienen englobados en la categoría M2 de OWASP.

Top Ten Smartphone Risks. EU Enisa

OWASP es sin duda la fundación que en este momento ofrece una auténtica metodología de trabajo en torno a la seguridad bajo una perspectiva libre y eficiente, así que ¿Por qué no vamos a hacerles más caso y ver que nos ofrecen al respecto?. En estos momentos el este proyecto tiene poco más de unos años de desarrollo pero es prometedor 
OWASP Mobile Project 2012 Goals

Selección_005

En el siguiente vídeo se nos muestra el Top 10 de vulnerabilidades encontradas en los últimos 3 años, esto es, desde el 2011, para dispositivos móviles. Cuales son los nuevos y últimos ataques y sus tipos. Que está cambiando respecto a estos 3 últimos años en cuanto al tipo de ataques y sus riesgos, además nos da una perspectiva general de como está en este momento la seguridad en el entorno del mundo del smartphone, a esta presentación le han puesto de título OWASP Top 10 Mobile Risks: 2014 Reboot, creo con la doble intención de hacer entender que el proceso de auditoría de seguridad en continuo y como un toque de atención a desarrolladores y empresas para que pongan más esfuerzos en desarrollar tecnología confiable y segura.

 


A la izquierda las viejas amenazas y su antigua clasificación (en gris), a la derecha la nueva clasificación de las amenazas.

Selección_007Selección_008

Traduciendo todo esto:

M1 Weak Server Side Controls: Ataques del lado del servidor. Los atacantes buscan vulnerabilidades en los servidores y una vez explotadas estas vulnerabilidades inyectan código maliciosos que luego intentarán apoderarse de nuestro terminal o ejecutar más código malicioso en el.
M2 Insecure Data Storage: Almacenamiento inseguro de datos. Se refiere mayormente a la perdida o robo de dispositivos móviles y el almacenamiento inseguro de los datos que este contiene.
M3 Insufficient Transport Layer Protection: Insuficiencia en la capa de transporte. Como se protege el transporte de los datos respecto a terceros que podrían estar ecuchando.
M4 Unintended Data Leakage: Se refiere a la perdida de datos por desentendimiento entre las aplicaciones y por ejemplo, el sistema operativo, hardware nuevo, nuevas configuraciones.
M5 Poor Authorization and Authentication: Pobre autorización y autenticación. Ya sean tokens u otros modos de autorización, una aplicación que se precie tiene siempre que evitar estos errores graves de seguridad.
M6 Broken Cryptography:  Criptografía rota. Mala praxis a la hora de utilizar criptografía obsoleta o rota.
M7 Client Side Injection: Inyecciones del lado del cliente. Siempre que un usuario este expuesto, puede existir la posibilidad de verse atacado por algún exploit o sniffing directamente contra su terminal. Inyección de código malicioso del lado del cliente.
M8 Security Decisions Via Untrusted Inputs: Decisiones de seguridad a través de entrada no confiables. Se supone que una aplicación móvil debería solo interactuar con otras aplicaciones confiables, dado que el si la aplicación utiliza software no confiable este podría contener código que aún no siendo malicioso podría ser aprovechado para realizar un ataque contra un terminal.
M9 Improper Session Handling: Impropio mantenimiento de la sesión. Mantener la vigilancia de las sesiones es tan importancia como su establecimiento en condiciones de seguridad. Si no se crean mecanismos para controlar una sesión ya sea mediante tokens u otros sistemas, es posible que alguien pudiera aprovechar el momento propicio para suplantar la misma.
M10 Lack of Binary Protections: Falta de protección en binarios. Es un tema controvertido puesto que existe mucho software bajo licencia GNU. Pero se hace referencia a que cualquier desalmado podría apoderarse de los posibles beneficios que podría generar una aplicación en el mercado si no se protegen adecuadamente los binarios. Mediante por ejemplo ingeniería reversa.


Conclusiones: Día a día nos encontramos con noticias de spyware, malware, y todo tipo de software malicioso orientado a los móviles, hay q tener clara dos cosas. Una, el smartphone almacena información personal y dos, es un ordenador con conectividad, por lo tanto es subceptible sufrir ataques por ejemplo contra la privacidad, tales como que nos “espien el whatsapp”. Sería de sentido común popularizar la idea de que la privacidad es una obligación más que un ocultamiento y de que un teléfono no es tan personal como muchos se creen.

Más info y presentaciones
Top Ten Mobile Risks
OWASP Mobile Security Project