Posibles causas del filtrado de fotos de famosos desde iCloud

 

¿Quién está detrás de esta acción?

 

La lista de celebrities hackeadas fue publicada por un usuario anónimo con ID ffR+At7b y UggsTju5. Su identidad es hasta ahora desconocida. Todavía no hay certeza si es un único usuario el que está detrás de esta filtración.

Uno de ellos podría ser el joven de 26 años de Lawrenceville, Georgia, cuya identidad ya se ha hecho pública. Ha admitido haber tratado de vender en Reddit fotos de desnudos por US$100, bajo el seudónimo BluntMastermind, pero niega ser el responsable de esta filtración.

No obstante, parece que tiene suficientes conocimientos (al ser administrador de servidores) y ha publicado pantallazos con gran similitud a los de 4chan (aunque defiende que son imágenes trucadas).

Además, en el espacio de 4chan, donde fue publicada la información, es /b/ – Random, utilizado para colgar trabajos artísticos de ficción.

La descripción de este espacio es "Only a fool would take anything posted here as fact" (Solo un tonto tomaría como cierto lo publicado aquí).

Las cuentas de Twitter (e.g @Callux) que han publicado las imágenes han sido clausuradas y algunas celebrities han amenazado con emprender acciones legales contra estos usuarios.

¿Cómo accedieron a esas imágenes?

 

A día de hoy, todavía se desconoce cómo se ha producido esta filtración.

Asumiendo que se hubiera producido una brecha de seguridad en iCloud, podrían apuntarse distintas hipótesis:

• Brecha de seguridad Cross-site: Las direcciones de email y las claves se han obtenido por una brecha/filtración de otro sitio web. Si éstas fueran las mismas claves que utilizan para identificarse en iCloud, sería fácil acceder a lo almacenado en esta nube. Esta parece ser la hipótesis más probable. 

 

• La infraestructura de iCloud ha sido hackeada: lo que daría acceso a fotos no cifradas o a otros servicios de Apple como el de recuperación de claves. No tenemos conocimiento de que iCloud haya sido atacada. 

 

• Ataque de fuerza bruta sobre iClouds: Dos investigadores, Andrey Belenko y Alexey Troshichev, demostraron que era posible y desarrollaron una herramienta llamada iBrute. Apple parcheo esta vulnerabilidad el 1 de septiembre de 2014. Esta hipótesis es la menos probable ya que implicaría que los atacantes han tenido acceso, en primer instancia, a los AppleID . Las celebrities, al igual que cualquier usuario, no siempre utilizan claves complejas para proteger sus cuentas, aunque sí cuidan la privacidad de sus cuentas de correo electrónico, para no recibir spam de sus fans. 

 

• La red Wifi de los Premios Emmy ha sido hackeada: Esta hipótesis implicaría que los certificados han sido comprometidos o que un SSL desconocido ha sido aprovechado por los hackers (con capacidad para secuestrar un sistema WiFi). Este es el escenario menos plausible.

 

• También es posible que no se haya producido ninguna brecha de seguridad en iCloud, o que no sea la única. De hecho parece posible que varios hackers hayan reunido las fotos procedentes de varios sitios.

 

• Algunas de las imágenes parece que han sido tomadas con dispositivos Android o webcam. No hay razón para que estas imágenes estén en iCloud, a no ser que fueran movidas a esta nube por sus propietarios.

 

• El PhotoStream de Apple solo mantiene la foto que se sube a iCloud durante 30 días. Este hecho no cuadra con las declaraciones realizadas por algunas celebrities que afirman que las imágenes eran antiguas. 

 

• Además de fotos, se han filtrado vídeos. iCloud no sincroniza la subida de vídeos. 

¿Ha sufrido iCloud algún ataque más durante este año?

 

Sí. En marzo de 2014 un hacker aprovechó una funcionalidad de Find My iPhone de Apple para bloquear los dispositivos iPhone y pedir un rescate por su liberación.

¿Qué puede hacer Apple para evitar este tipo de ataques?

 

• Apple utiliza el sistema de autenticación de doble factor en My Apple ID, no para las cuentas en iCloud. 

 

• Contar con un sistema de doble autenticación en iCloud podría haber prevenido al menos una parte de la filtración: la combinación de ID/claves procedente de brechas de otras bases de datos no hubiera sido suficiente para identificarse en iCloud y descargarse las fotos. 

 

• Hay que tener en cuenta que Dropbox cuenta con un el sistema de autenticación de doble factor, como servicio opcional. 

¿Qué pueden hacer los usuarios para no ser hackeados?

 

1. Utilizar diferentes claves para las distintas cuentas y servicios que tengamos. Si compartimos claves en varias cuentas, al menos cambiar la clave de Apple.
2. Utilizar una clave robusta.
3. Recordar que la nube no es inviolable y, consecuentemente, aplicar el sistema de autenticación de doble factor siempre que sea posible.

Respecto a iCloud, se puede evitar la subida automática de fotos desde un dispositivo Apple a la nube desabilitando Settings → iCloud → Photos → My Photo Stream.

Microsoft publica parches de septiembre

Microsoft ha publicado el boletín de seguridad mensual correspondiente a septiembre de 2014, que incluye cuatro actualizaciones de software para resolver diversas vulnerabilidades y exposiciones comunes (una de ellas crítica) y que afectan a sistemas operativos Microsoft Windows, navegadores Internet Explorer, software de servidor de Microsoft, Microsoft .NET Framework y Microsoft Lync Server.

Además, Adobe ha publicado un boletín de seguridad que soluciona 12 vulnerabilidades que afectan al popular reproductor Flash. Los problemas podrían permitir a un atacante ejecutar código y eludir restricciones de seguridad.

Las consecuencias potenciales de estas vulnerabilidades van desde la ejecución remota de código, la elevación de privilegios, la denegación de servicio a la omisión de característica de seguridad.

Los parches de seguridad pueden descargarse automáticamente desde Windows Update y se recomienda actualizar equipos informáticos a la mayor brevedad. Las vulnerabilidades corregidas son:

• MS14-052. Actualización de seguridad acumulativa para Internet Explorer (2977629) Crítica. Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma pública y treinta y seis vulnerabilidades de las que se ha informado de forma privada en Internet Explorer. La más grave de estas vulnerabilidades podría permitir la ejecución remota de código si un usuario, mediante Internet Explorer, visita una página web especialmente diseñada. Un intruso que aprovechara estas vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario actual. Los clientes cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos. 

 

• MS14-053. Una vulnerabilidad en .NET Framework podría permitir la elevación de privilegios (2990931) Importante. Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft .NET Framework. La vulnerabilidad podría permitir la denegación de servicio si un atacante envía una pequeña cantidad de solicitudes especialmente diseñadas a un sitio web habilitado para .NET. De forma predeterminada, ASP.NET no se instala cuando Microsoft .NET Framework se instala en alguna edición compatible de Microsoft Windows. Para que se vean afectados por la vulnerabilidad, los clientes deben instalar y habilitar manualmente ASP.NET mediante su registro con IIS. 

 

• MS14-054. Una vulnerabilidad en Programador de tareas de Windows podría permitir la elevación de privilegios (2988948) Importante. Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la elevación de privilegios si un atacante inicia sesión en un sistema afectado y ejecuta una aplicación especialmente diseñada. Para aprovechar esta vulnerabilidad, un atacante debe de tener unas credenciales de inicio de sesión válidas y ser capaz de iniciar una sesión local. Los usuarios anónimos o los usuarios remotos no pueden aprovechar esta vulnerabilidad. 

 

• MS14-055. Vulnerabilidades en Microsoft Lync Server podrían permitir la denegación de servicio (2990928) Importante. Esta actualización de seguridad resuelve tres vulnerabilidades de las que se ha informado de forma privada en Microsoft Lync Server. La más grave de estas vulnerabilidades podría permitir la denegación de servicio si un atacante envía una solicitud especialmente diseñada a un servidor Lync.

¿Los juegos del Hambre o los juegos del Hacking?

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.