• Saltar al contenido principal
  • Saltar a la barra lateral principal
  • Saltar al pie de página

Una al Día

Boletín de noticias de Seguridad Informática ofrecido por Hispasec

Usted está aquí: Inicio / Auditoría / La arquera y su manzana

La arquera y su manzana

2 septiembre, 2014 Por Hispasec 3 comentarios

A estas alturas, cuando solo una pequeña porción de la humanidad aun no ha visto a la señorita Lawrence posar en una incómoda intimidad, merece la pena analizar lo ocurrido sin las prisas que demandan los titulares en llamas o el siempre juego del hambre por las visitas.
Una mañana te despiertas en tu mansión de Hollywood y después de la ducha matinal para desperezarte, te vistes con tu albornoz más suave y delicado y te pones a leer el guión que te envió ayer tu representante. Cuando vas por el segundo párrafo y la cosa se ponía interesante suena tu teléfono móvil, el mismo que vas a destrozar contra la pared en breves momentos.
«¡¿Cómo?!….¡¿Qué?!….Me…en…la…» El resto de la historia (completamente inventada) se deja a la imaginación. Cambiemos de personaje.
Días antes de que una docena de iPhones encontraran su fatal destino presas de la rabia y la impotencia, un usuario de 4chan presumía tener en su poder montones de fotos privadas (también vídeos) de famosas que iba a liberar, incluso pedía donaciones a su cuenta de PayPal por si algún alma caritativa le quería agradecer el «esfuerzo«. Lo que parecía una fantasmada, fruto de la imaginación incontinente de un púber alienado por las hormonas, término por ser cierto. Cientos de fotos intimísimas de cientos de las mujeres más deseadas en este planeta (y dentro de miles de años quizás en otros) terminaron expuestas a los desorbitados ojos de millones de seres humanos.
Aquí se acaba lo que todo el mundo sabe. Comencemos con lo que nos interesa.
¿Fue un hackeo de iCloud?
Si y no. A pesar de lo que muchos medios generalistas anunciaron, nadie penetró en los sistemas de la nube de Apple. No se explotó ninguna vulnerabilidad directa. El problema se encontraba en la API de «FindMyPhone» de Apple. Concretamente esta llamada REST (hay un supuesto script que parece haber sido usado para el ataque – https://github.com/hackappcom/ibrute):
«https://fmipmobile.icloud.com/fmipservice/device/’+apple_id+’/initClient»
Donde el ‘apple_id‘ se debe introducir el correo de la víctima. Exacto, el atacante debe saber de antemano el correo de la cuenta asociada a iCloud a la que quiere acceder. ¿Cómo era posible saber el correo de una famosa? Existen muchas teorías, alguno sería sencillo de averiguar o quizás pululaba por ahí, el caso es que obteniendo la agenda de contactos de una famosa el resto era ir tirando de la caña.
El ataque se hacía de manera combinada, con listas de correos y listas de contraseñas por lo que se trataba de un ataque de longitud cuadrática. «Por cada correo prueba estas 500 contraseñas…«. Esto genera un ruido impresionante en los registros de eventos que ni a un IPS de segunda división se le pasa por alto, en el supuesto claro de que hubiera alguno… ¿Lo habría?
Viendo el código:
Observamos como el User-agent y otros valores son fijos. Y vemos algo que llama mucho la atención: El UDID del dispositivo origen de las peticiones es pseudoaleatorio, falso como el cartón piedra y cuando la combinación usuario/contraseña es correcta Apple no hace una comprobación adicional de ese UDID rechazando, a pesar de la validez de la contraseña, la petición. Tarjeta amarilla.
Lo segundo y que es lo que ha llegado a las rotativas, es la falta de límite de intentos de acceso a una cuenta determinada. Como dijimos un par de párrafos arriba los servidores de Apple se tragaban cualquier número de peticiones con resultado erróneo. ¿Os imagináis a Jennifer metiendo 500 contraseñas en 60 segundos en el set de rodaje mientras la esperan para la siguiente toma? Tarjeta roja.
Otro asunto es que la autenticación se hacía a través de la autenticación básica implementada por el protocolo HTTP. Concatenación de usuario y contraseña, símbolo ‘:’ mediante y eso lo pasamos por un codificador en base64. Eso no es un hash, es simplemente una cadena codificada. La lista de passwords, supuestamente usada, no son hashes MD5 o SHA1 o lo que sea. Son contraseñas en texto claro que van a ser codificadas y enviadas para su comprobación al servidor de «FindMyIphone«. Luego si no nos equivocamos, en algún momento esas contraseñas podrían estar almacenadas con un simple base64.
Por cierto, varios usuarios de Reddit comprobaron que el script funcionaba hasta que Apple parcheó los servidores que tiene repartidos por el mundo.
La política de contraseñas de Apple
Apple mantiene una política de contraseñas estándar, con posibilidad de activar doble factor de autenticación y la extremadamente desaconsejable y completamente insegura segunda vía a través de preguntas personales. Con las redes sociales colmadas de datos personales voluntariamente expuestos, hoy día tiene más sentido ir mintiendo en absolutamente todas las preguntas que decir la verdad.
Volvamos a las contraseñas, que son las protagonistas (con el permiso de la Lawrence) del ataque.
Las reglas son declarativas y siguen una lógica AND:
         Al menos tienen que tener una letra.
         Al menos una letra capital.
         Al menos un número.
         No deben contener caracteres secuencialmente idénticos.
         No debe ser la misma cadena que el nombre de usuario.
         Al menos debe contener 8 caracteres.
         No debe ser una contraseña común (conocida)
         No ha de haberse usado durante el año anterior.
Con todas estas reglas y una lista de gritones de contraseñas tenemos, no como construir una contraseña, sino como filtrar esa lista de contraseñas a través de expresiones regulares y quedarnos con una lista más ligerita y certera. Por ejemplo de nada nos serviría ir probando una secuencia de números o palabras que no contengan una mayúscula o passwords con menos de 8 caracteres.
¿Qué pinta tendría el password de una famosa?
Veamos, ¿Alguien se imagina a nuestra actriz favorita activando la doble autenticación? No, ¿verdad? Es posible que Noomi Rapace si, pero el resto seguro que no. ¿Os imagináis también a la famosa metiendo una contraseña robusta y a prueba de hackers?
Con las reglas arriba mencionadas una contraseña que deje pasar el sistema como válida tendría una pinta parecida a esta. Por cierto, cuando el sistema comienza a responder con mensajes del tipo «Contraseña no válida, debe tener al menos…» vamos relajando la complejidad porque el humano termina cansándose de la dichosa maquinita y cansancio y relax son el efecto y la consecuencia. Una tarea repetitiva termina bajando la guardia del que la realiza.
Una letra capital: la primera letra
Al menos un número: posiblemente dos (días, años, edad…) y al final, es típico.
Al menos 8 caracteres: de acuerdo, dos cifras al final nos deja 6 letras al comienzo.
No deben repetirse caracteres: perfecto, estrechamos el universo.
No debe ser igual al nombre de usuario: menos intentos todavía.
Y lo más importante y que está en la cabeza de la gran mayoría: tienes que memorizarlo.
Obviemos el resto de reglas. ¿Convincente?:
Jlawrence90
Evidentemente no es la contraseña (eso esperamos) simplemente la base sobre la que ir construyendo contraseñas inspiradas en la reglas que en principio deberían servir para robustecerlas y lo que conocemos de la persona objetivo.
Por cierto. ¿Alguien sabe como se llama el perro de Jennifer Lawrence?
 
Más información:
El culo de Scarlett y el eslabón más débil (I y II)
http://unaaldia.hispasec.com/2011/10/el-culo-de-scarlett-y-el-eslabon-mas_14.html
http://unaaldia.hispasec.com/2011/10/el-culo-de-scarlett-y-el-eslabon-mas.html
La pregunta secreta del caso «Paris Hilton»
http://unaaldia.hispasec.com/2005/02/la-pregunta-secreta-del-caso-hilton.html
David García
dgarcia@hispasec.com
Twitter: @dgn1729

 

Acerca de Hispasec

Hispasec Ha escrito 6939 publicaciones.

  • View all posts by Hispasec →
  • Blog

Compártelo:

  • Twitter
  • Facebook
  • LinkedIn
  • Reddit
  • Telegram
  • WhatsApp

Publicaciones relacionadas

Publicado en: Auditoría

Interacciones con los lectores

Comentarios

  1. Anónimo dice

    4 septiembre, 2014 a las 2:32 pm

    Buen artículo y con respuestas sencillas y lógicas ante la maraña de desinformación por parte de medios de comunicación y empresa

    Responder
  2. Anónimo dice

    4 septiembre, 2014 a las 2:55 pm

    Estuvo bueno. Me gustó el tono relajado sin dejar de ser técnico.

    Responder
  3. Juan DAVILA dice

    8 septiembre, 2014 a las 7:24 pm

    Si todos los profesores fuéramos así…, gracias David !!!

    Responder

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Barra lateral principal

Buscar

Síguenos

siguenos en twitter

UAD360 EDICIÓN 2022

https://www.youtube.com/watch?v=go_CSWK56yU

Populares de UAD

  • Tamagotchi para hackers: Flipper Zero
  • Campañas de phishing utilizan Flipper Zero como cebo
  • Evasión de CloudTrail en AWS a través de API no documentada
  • Las apps de mensajería y videoconferencia te escuchan incluso cuando estás "muteado"
  • ¿Qué es DMARC? La necesidad de la protección del correo electrónico

Entradas recientes

  • Evasión de CloudTrail en AWS a través de API no documentada
  • Parches de enero 2023: Microsoft corrige 98 vulnerabilidades
  • UAD se abre a la comunidad
  • Campañas de phishing utilizan Flipper Zero como cebo
  • Vulnerabilidades críticas en productos de Synology
  • Más de dos docenas de errores de WordPress explotados por un nuevo malware de Linux
  • Descubierta una nueva campaña de malware que se propagaba a través de los anuncios de Google
  • Correo electrónico
  • Facebook
  • LinkedIn
  • RSS
  • Twitter

Footer

UAD

UAD nació a raíz de un inocente comentario en un canal IRC hace 24 años. A través de los archivos, un lector curioso puede ver cómo ha cambiado (o no) la seguridad de la información desde entonces.

Aviso Legal

  • Aviso Legal
  • Términos y Condiciones
  • Política de Privacidad
  • Política de Cookies

Copyright © 2023 · Hispasec Sistemas, S.L. Todos los derechos reservados

Este sitio web utiliza cookies propias y de terceros para fines analíticos y para mostrarte publicidad (tanto general como personalizada) relacionada con tus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas), para optimizar la web y para poder valorar las opiniones de los servicios consultados por los usuarios. Para administrar o deshabilitar estas cookies haz clic en: Configurar Cookies


Rechazar todo Aceptar Todo
Configurar Cookies

Resumen de privacidad

Este sitio web utiliza cookies para mejorar su experiencia mientras navega por el sitio web. De estas, las cookies que se clasifican como necesarias se almacenan en su navegador, ya que son esenciales para el funcionamiento de las funcionalidades básicas del sitio web. También utilizamos cookies de terceros que nos ayudan a analizar y comprender cómo utiliza este sitio web. Estas cookies se almacenarán en su navegador solo con su consentimiento. También tiene la opción de optar por no recibir estas cookies. Pero la exclusión voluntaria de algunas de estas cookies puede afectar su experiencia de navegación.
Necesaria
Siempre activado
Las cookies necesarias son absolutamente esenciales para que el sitio web funcione correctamente. Estas cookies garantizan funcionalidades básicas y características de seguridad del sitio web, de forma anónima.
CookieDuraciónDescripción
cookielawinfo-checkbox-analytics11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Análisis".
cookielawinfo-checkbox-functional11 monthsLa cookie está configurada por el consentimiento de cookies de GDPR para registrar el consentimiento del usuario para las cookies en la categoría "Funcional".
cookielawinfo-checkbox-necessary11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. Las cookies se utilizan para almacenar el consentimiento del usuario para las cookies en la categoría "Necesario".
cookielawinfo-checkbox-others11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Otro.
cookielawinfo-checkbox-performance11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Rendimiento".
viewed_cookie_policy11 monthsLa cookie está configurada por el complemento de consentimiento de cookies de GDPR y se utiliza para almacenar si el usuario ha dado su consentimiento o no para el uso de cookies. No almacena ningún dato personal.
Analítica
Las cookies analíticas se utilizan para comprender cómo interactúan los visitantes con el sitio web. Estas cookies ayudan a proporcionar información sobre métricas, el número de visitantes, la tasa de rebote, la fuente de tráfico, etc.
GUARDAR Y ACEPTAR