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


  • 0

THC-Hydra

Hydxhydrara es una herramienta de auditoría que se basa en la fuerza bruta, es especialmente versátil dado que soporta un gran número de servicios con los que puede intentar comunicarse repetidamente, además es multithread (multihilo), con lo cual puede ejecutar varios intentos simultáneamente, claro está, si estos intentos no son rechazados.

https://www.thc.org/thc-hydra/

Puede utilizarse y se ha utilizado para obtener contraseñas, como ya dije, intenta comunicarse con un servicio y como ya es comprensible, al utilizar un servicio normalmente, este necesita que introduzcamos un nombre de usuario y una contraseña. Puede ser nuestro correo, nuestra cuenta de voip, o algo más interno, como la contraseña de configuración de un router wifi. Hydra automatiza el trabajo de prueba y error que supondría tener que intentar esto mismo a mano, es una de esas herramientas que funcionan con la nada sofisticada pero si eficaz técnica de la fuerza bruta.

Hydra es especialmente útil en cuanto a ataques a autenticación web. Podemos adecuar el ataque por fuerza bruta a numerosos escenarios de autenticación web, si antes previamente sabemos cual utiliza.

El descubrimiento de los métodos de autenticación de una página web nos ayudará a conformar un ataque acorde al sistema de autenticación y, a no ser que se hayan implementado unos sistemas muy restrictivos en muchos casos nos vamos a encontrar unos formularios html básicos, simplemente, por ejemplo mirando el código fuente de la página, que normalmente va a contener unas etiquetas como estas:

<form method="POST" action="login">
<input type="text" name="username">
<input type="password" name="password"> </form>

Como se ve el formulario cumple su función, recoge los datos usuario y contraseña y los envía mediante el método POST.

Vamos a poner tres ejemplos de hydra para usar la fuerza bruta contra autenticaciones web:

Ejecutar hydra para que simule la autenticación HTTP Básica. Correspondería al formulario anterior

hydra -L lista_usuarios -P diccionario 168.5.78.95 http-head /zonausuarios/

Fuerza bruta contra HTTP Digest Authentication. Digest authentication añade un poco más de seguridad a la autenticación cifrando la contraseña con el algoritmo MD5, pero básicamente el uso de hydra es el mismo

hydra -l admin -P diccionario 168.5.78.95 http-get /usuarios

Fuerza bruta para HTML Form Based Authentication

Vamos a suponer que nos encontramos una web, con un formulario de autenticación donde podemos ver estas etiquetas html:

<form name="input" action="login.php" method="post">
<input type="text" name="user">
<input type="password" name="password">

Cuando introducimos mal el usuario el sistema nos comunica un error–> Not allowed. Con esta información podemos conformar una ataque con hydra de la siguiente manera

hydra -L lista_usuarios -P diccionario 168.5.78.95
https-post-form "/index.cgi:login&name=^USER^&password=^PASS^&login=Login:Not allowed" &

La potencia de hydra reside en su flexibilidad a través de opciones que nos ofrece, ya que además de soportar una gran cantidad de servicios, podemos modificar su comportamiento, pudiendo conseguir que el ataque no sea detectado como tal si el sistema ofrece alguna protección contra numerosos intentos de autenticación.

Opciones del programa hydra:

.-R restaura una sesión previa, ya sea abortada o interrumpida

-S Conexión SSL

-s <PORT> Especifica el puerto si es distinto al puerto por defecto del servicio

-l <LOGIN> o -L <FILE> si usamos -l tendremos que poner un nombre de usuario único si usamos -L podemos hacer que hydra pruebe con una lista de usuarios

-p <PASS> o -P <FILE> Si usamos -p hydra usará una única password. Esta opción es útil cuando se conoce que un dispositivo de red contiene un usuario y contraseña por defecto en combinación con la opción -M, por ejemplo.Si usamos -P hydra usará un archivo de passwords, o más concretamente un diccionario de passwords

-e <ns> -checkeos adicionales para passwords nulos y/o intentar usar el nombre de usuario como password

-C <FILE> Podemos usar un archivo con el formato “login:pass” en vez de proporcionar las opciones -L y -P

-M <FILE> – Usando esta opción podemos decirle a hydra que ataque en paralelo a una lista de servidores

-o <FILE> Escribirá las contraseñas encontradas en un archivo FILE

-f salir después del primer login/password encontrado. Esto detiene hydra cuando encuentra un resultado positivo.

-t <TASKS> número de conexiones en paralelo que deseamos para le proceso(16 por defecto)

-w Se puede definir el tiempo de espera entre respuestas (30 por defecto)

-v / -V Define el modo de reporte mostrando el modo verbose o mostrando el login + password de cada intento

server El servidor objetivo si no hemos usado la opcion -M

service Servicio a crackear. Protocolos soportados: telnet ftp pop3[-ntlm] imap[-ntlm] smb smbnt http[s]-{head|get} http-{get|post}-form http-proxy cisco cisco-enable vnc ldap2 ldap3 mssql mysql oracle-listener postgres nntp socks5 rexec rlogin pcnfs snmp rsh cvs svn icq sapr3 ssh2 smtp-auth[-ntlm] pcanywhere teamspeak sip vmauthd firebird ncp afp.

HydraGTK es la versión GUI de hydra, y es útil para el que no quiera perder el tiempo con la consola e ir directamente al ataque, igual de potente y flexible.

hydra

Hydra es una esas herramientas que nos enseñan que es muy fácil forzar la seguridad con un mecanismo tan simple como la fuerza bruta. Ojo, no todos los usos de hydra tienen porqué ser maliciosos, pues ha sido muchas veces utilizado para recuperar contraseñas que otros habían olvidado 😉