BLOG DE XXL-MAN

Ya que estamos bien entrados en 2017 parece que todo el mundo tiene plena conciencia de lo importante que es garantizar unas mínimas medidas de seguridad en todos los servicios web. Lo que aún no queda tan claro, es que todos los recursos asociados a un servicio además deben seguir las mismas directrices y el mismo rigor de securización para no ser el eslabón frágil de la cadena: Una cadena es tan fuerte como el eslabón más débil.

Por hacer una analogía que me encanta, y que tomo prestada de mi compañero Félix Gómez y muy rollo gamer a lo AGE OF EMPIRES: Si nuestro sistema lo consideramos la típica fortaleza medieval y levantamos las medidas de defensa más feroces en nuestras murallas y el puente levadizo principal, de nada servirá si por la parte trasera hay una puerta débil y nada vigilada. Los malos entrarán por la parte más fácil haciendo inútiles cuantos esfuerzos y recursos hayamos empleado en otras partes. Algo que bien nos explicaba Chema Alonso en su artículo “DO THE BASICS: LOW HANGING FRUIT” http://www.elladodelmal.com/2015/11/do-basics-elimina-el-low-hanging-fruit.html

Parte de la conferencia DO THE BASICS con nombres de usuario de army.mil a tiro de Google (Ejército USA)

Puede que parezca baladí, pero este fallo de no proteger todos los recursos asociados lo presentó la mismísima APPLE en su servicio Find-My-Phone, el cual permitía fuerza bruta y que parece que fue vulnerado por un script llamado iBrute al que se le atribuye el famoso celeb-hack, que accedió a un montón de fotos comprometidas de famosas de Hollywood mostrando sus encantos (https://github.com/hackappcom/ibrute/blob/master/id_brute.py)

Captura de iBrute probando contraseñas APPLE

Definamos para los menos expertos que significa un ataque de fuerza bruta: Significa probar todas las contraseñas posibles hasta dar con la válida. Es decir, por ejemplo, si tuviéramos que probar el pin de una tarjeta bancaria, que sabemos que consta normalmente de 4 dígitos, sería probar desde el 0000 al 9999, por tanto, 10.000 combinaciones posibles.

Las medidas básicas ante este tipo de ataques son por ejemplo, hacer saltar un mecanismo ante intentos fallidos (bloqueo de cuenta o retraso entre peticiones) o incluir un captcha para evitar que el acceso se pueda hacer mediante un sistema automatizado (comúnmente llamado bot) Por tanto, y siguiendo con el ejemplo bancario, lo que hace nuestro banco es normalmente si fallamos 3 veces el PIN, capturar la tarjeta y pedirnos que pasemos por la oficina, para evitar que un supuesto delincuente que se haga con la tarjeta pueda hacer intentos hasta dar con el pin y por tanto obtener acceso a todo nuestro saldo (Bloqueo de cuenta). Un retraso entre peticiones es lo que cualquier teléfono Android hace si introducimos varias veces mal el patrón de desbloqueo: Nos hace esperar 30 segundos hasta el 4º intento, y ese retraso va aumentando a medida que fallemos de nuevo.

El sistema de bloqueo puede parecer una buena idea, pero para un atacante malicioso podría significa una denegación de servicio (DOS, no confundir con DDOS) ya que tras varios intentos no válidos, la cuenta queda bloqueada. Si sabemos el nombre de la cuenta y el tiempo de bloqueo, podemos hacer ese número de intentos de forma automatizada cada intervalo de tiempo bloqueando por siempre la cuenta del legítimo dueño.

Para mi demostración elegí probar con las apps de ligoteo, y entre ellas, SHAKN, que tiene aparte de su app móvil, también un acceso web completo a través de https://app.shakn.com/#/login

Donde llegué a probar más de 10000 intentos fallidos de login sin que mi acceso ni mi cuenta de prueba fueran restringidos. Y eso sin introducir ningún cambio de navegador (falseando el user-agent) ni retraso entre peticiones. Se pueden hacer hasta 4 intentos por segundo.

Después de comprobar que no hay restricciones, el resto es cuestión de tiempo, y recordemos que en ElevenPaths siempre decimos que los malos tienen mucho. Para minimizar este tiempo, podemos acudir a elegir cuentas víctima y ya sólo tener que probar contraseñas bien por fuerza bruta o por ataques de diccionario.

Probando contraseñas contra una cuenta de prueba en SKAKN

Continuando con las definiciones “a nivel de todos”, definiré ataque de diccionario como aquel en el que se usan las combinaciones más comunes, en vez de TODAS las combinaciones. Por si no sabéis hasta qué punto esto influye en el número de pruebas y por tanto en el tiempo de acceso a una cuenta víctima, podéis buscar por internet listas de contraseñas más comunes. Y funciona, vaya que si funciona, incluso hay pruebas que aseguran que usando una lista de 1.000 contraseñas accedemos al 98% de cuentas, o lo que es lo mismo, que 98 de cada 100 personas está usando una contraseña de esa lista. (http://omicrono.elespanol.com/2013/07/las-1000-contrasenas-mas-usadas-sirven-para-iniciar-sesion-en-el-98-1-de-las-cuentas-abiertas/)

Pero incluso podemos encontrar por internet diccionarios desde 10.000 (https://pastebin.com/E76ndEmV ) a  10 millones de passwords: https://xato.net/today-i-am-releasing-ten-million-passwords-b6278bbe7495 . Si tu contraseña “habitual” está en esa lista, ya sabes lo que tienes que hacer! Es más: NO DEBERIAS TENER UNA CONTRASEÑA HABITUAL!!

Pero, ¿y las cuentas víctima? ¿De dónde las sacamos? Bueno eso depende de si nos interesa una cuenta o simplemente queremos acceder a cuentas, sean las que fuere. O probar a cuantas cuentas podemos acceder de todo el sistema: dependerá mucho de cual sea nuestro objetivo. Suplantar una sola cuenta puede significar que usurpando esa identidad podamos atacar a otros usuarios haciéndonos pasar por esa persona, por poner un solo ejemplo.

En el caso de Instagram, que también sufrió esta vulnerabilidad explotada en Diciembre de 2015 por el script https://github.com/chinoogawa/instaBrute/blob/master/instaBrute.py Instabrute, los nombres de cuenta los podemos sacar de la propia URL, por ejemplo, en mi caso sé que alguien registró por ejemplo la cuenta XXLMAN : https://www.instagram.com/xxlman/. Este tipo de “descubrimiento” de cuentas se hace en todas las redes públicas, por ejemplo, TWITTER. Por tanto, es fácil descubrir si una cuenta existe o no, y por tanto, probar contraseñas en aquellas que existen solamente, reduciendo considerablemente el tiempo de captura de credenciales.

Si la solución de fuerza bruta para las cuentas de usuario no nos complace, podemos elegir una víctima. Sería cuestión de obtener su email bien por ingeniería social, bien haciéndonos pasar por la propia APP con un mensaje directo…. O bien podemos hacer algo de hacking con buscadores para ver cuanta gente nos da directamente su email registrado en SHAKN, como en cualquier otro servicio web. Por si os interesa ver todo lo que está a la vista de todo el mundo (y no debería) e iniciaros en el Open-Source Intelligence os recomiendo encarecidamente el libro “Hacking con buscadores” de 0xWord. (http://0xword.com/es/libros/20-libro-hacking-buscadores-google-bing-sodan-robtex.html)

Usuarios publicando su email registrado en SHAKN

Quede como conclusión de este artículo que todo servicio web, app o empresa con servicios online debe mantener una política uniforme de seguridad para todas sus servidores, servicios y facetas accesibles en internet, ya que cada recurso secundario es una potencial vulnerabilidad y debe tratarse de forma separada con los mismos patrones y el mismo rigor que los principales. Y como no, recordar la importancia de usar segundos factores de autenticación (2FA) para que no todo dependa de que nuestra contraseña caiga en malas manos. Para este cometido ElevenPaths ofrece a todas las empresas su servicio LATCH o el más novedoso y cómodo MOBILE CONNECT donde ya puedes olvidarte de las contraseñas para siempre.

NOTA IMPORTANTE: Esta grave vulnerabilidad fue notificada hace a SHAKN antes de la publicación de este artículo  como caso de uso de éxito de la temática. Gracias a dicha notificación la web ya no es vulnerable a este tipo de ataques. Durante la realización de esta prueba no se accedió de forma ilegal a ningún dato ya que la cuenta era de prueba y propia. Antes de realizar este tipo de test siempre hay que tener la implicación legal y la responsabilidad ética de no hacer nada perjudicial al entorno donde se ejecuta. Este artículo solo tiene intención de formar y educar en seguridad digital y responsabilidad en el uso de las tecnologías y es publicado en nombre propio.

Andres Naranjo @TheXXLMAN Nov’2017
#LaChampionsDeHackers