A estas alturas, cuando solo una pequeña porción de la humanidad aun no
ha visto las
fotos hot de Jennifer Lawrence posando 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.
Imaginemos cómo sería la situación:
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é?!....La…pu…madre!!…" El resto de la historia 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 es 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 para Apple.
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 la
hermosa Jennifer Lawrence
metiendo 500 contraseñas en 60 segundos en el set de rodaje mientras la
esperan para la siguiente toma?
Tarjeta roja para Apple.
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.
¿Entonces cómo descubrir una contraseña 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 para crear la contraseña son las siguientes:
- 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 ya sabemos como debe lucir la contreseña que usa la
hermosa Jennifer Lawrence y además nos ahorra tiempo ya que 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.
¿Cómo luciría la contraseña de Jennifer Lawrence?
Veamos, ¿Alguien se imagina a nuestra actriz favorita activando la doble
autenticación?
No, ¿verdad?, ¿Os imagináis también a la famosa metiendo una
contraseña robusta y a prueba de hackers?
Tampoco.
Con las reglas arriba mencionadas una contraseña que deje pasar el
sistema como válida tendría que ser más o menos así:
- 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.
Un posible resultado podría ser: 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.
