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 incomoda 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.
Más información:
El culo de Scarlett y el eslabón
más débil (I y II)
La pregunta secreta del caso
"Paris Hilton"
David García
Twitter: @dgn1729
