Esta semana se ha revolucionado Internet con la publicación de un documento del FBI, fechado 7 de Enero de 2021, en el que se detalla lo que la institución puede conseguir de las distintas plataformas de mensajerías, bajo orden judicial, en sus investigaciones. Así, se puede saber qué se obtiene de Telegram, WhatsApp, Signal o iMessage, por ejemplo.
Figura 1: Estos son los datos que el FBI puede conseguir de
iMessage, Signal, WhatsApp o Telegram
De todos ellos, se especifica qué es posible obtener y qué no es posible, por medio de los mecanismos legales de que disponen. Así, por ejemplo, en el caso de Telegram, con cifrado extremo a extremo aplicado, y no siendo una compañía norteamericana, sino que tiene su sede en Dubai, la información que puede obtenerse está bastante limitado y solo entregan la dirección IP de conexión para terroristas confirmados. En el caso de Signal, también bastante poco, ya que solo se entrega la fecha de conexión, las fecha de registro del usuario, y la última conexión. Lo demás, no se almacena en los servidores de Signal.
Figura 2: Resume de datos de Signal y Telegram
Por otro lado, en el caso de iMessage de Apple sí que se obtiene mucha más información, ya que esta plataforma, a diferencia de Signal o WhatsApp, no tiene activado el cifrado extremo a extremo, lo que permite a los servidores de Apple iMessage tener acceso a los mensajes si lo deseara.
Figura 3: Datos a los que puede acceder el FBI de iMessage
Por supuesto, los mensajes de iMessage son eliminados de sus servidores, pero se podría activar un control de mensajes desde un punto en el tiempo en adelante, además de que si el backup de alguno de los clientes de iMessages (por ejemplo el de iPhone o MacOS) está en iCloud, se pueden acceder a los mensajes pasados, algo que vemos en el libro de Hacking iOS (iPhone & iPad) 2ª Edición.
En el caso de WhatsApp, más o menos lo mismo que iMessage. Los mensajes van cifrados extremo a extremo, pero se podrían llegar a conseguir los mensajes futuros ya que la compañía controla el end-point, así que desde un determinado instante en el tiempo en adelante se podrían acceder a los mensajes - no se especifica si lo hacen -, pero además que si el backup de WhatsApp está en iCloud, se pueden conseguir los mensajes pasados. Además de esos datos, se consiguen una serie de detalles curiosos como la agenda de contactos, grupos, conexiones, etcétera, algo que la propia compañía especifica en su web. Te recomiendo la serie de "Proteger WhatsApp a Prueba de balas"
Figura 5: Lo que se consigue de WhatsApp
Por supuesto, del resto de plataformas utilizadas también se obtienen datos que pueden verse en el documento completo. Hay información de Viber, Line, Threema, WeChat o Wickr, y puedes verlo a continuación.
Figura 6: Documento resumen. Clic en él para ampliar
Recordad que estamos hablando del FBI y de órdenes judiciales, y no estamos hablando de la NSA, y sus capacidades más allá, que vimos con las filtraciones de Edward Snowden, así que si te queda alguna duda de que si consideran que hay que acceder a tus mensajes podrían hacerlo, que tengas claro que sí que podrán.
Desde que comenzamos en octubre de 2019 con el proyecto de MyPublicInbox, que dentro de poco alcanzará su segundo año de vida, he recibido muchos mensajes en mi buzón público. En total han sido más de 700 mensajes de gente que ha contactado conmigo para cosas muy diversas. Desde plantearme una colaboración, una entrevista, una conferencia, participar en un podcast, hasta resolver alguna duda o pedir algún consejo en situación de problema. De estos últimos hay casos que he visto muchas veces, pero este que os voy a contar es diferente.
Figura 1: iPhone: Revisa con quién compartes tu localización (o si lo haces con alguien)
Me pidieron ayuda por un tema peculiar. Una persona sentía que estaba siendo vigilada por alguien ya que se encontraba con un compañero de trabajo en sitios muy extraños. Sitios donde no se suponía que esta pudiera saber que iba a estar, así que pensaba que podía tener el terminal hackeado o que le estuvieran espiando el WhatsApp porque a veces coincidía que se lo había dicho a alguien que iba a ir a una determinada cafetería, tienda o ubicación.
Contesté el mensaje con los consejos habituales para que revisara su configuración. Que mirase las sesiones de WhatsApp, que fortificara su cuenta de WhatsApp, que revisara que no le hubieran clonado la SIM, que si tenía el terminal actualizado, y que buscara si acaso ayuda para que le hicieran un análisis forense del terminal, para que descartara la presencia de un troyano.
Sin embargo, lo que no cuadraba para el tema del troyano, era que el terminal era un iPhone, algo con lo que hemos jugado mucho para escribir el libro de Hacking iOS:iPhone & iPad (2ª Edición), y para instalar una app con troyano en un iPhone hay que hacer jailbreak, tener un 0day o conseguir una configuración muy, muy, muy insegura del dispositivo. Así que seguí haciéndole preguntas, hasta que di con el problema, que resulto ser algo tan sencillo, y tan escondido delante de los ojos como que estaba compartiendo la ubicación con esa persona con iCloud, sin ella saberlo.
Figura 4: Desde iMessage se comparte la localización con el contacto
Al final, la persona había aprovechado un descuido del terminal iPhone, se había ido a iMessages, entrado en la información del Chat y seleccionado la opción de compartir ubicación para siempre. Cuando esto se produce, iPhone te avisa en el mismo chat con unos mensajes, pero esta persona, después de compartir la ubicación había debido de borrar el chat - ellos hablaban habitualmente por WhatsApp y no por iMessages -, así que la víctima no había notado absolutamente nada.
Figura 5: Apple solo te avisa por el mismo chat de iMessage
La sorpresa llegó cuando entro en las opciones de Compartir Localización de iPhone, y encontró que estaba, sin saberlo, diciéndole siempre donde se encontraba, lo que le estaba generando ese problema en su vida personal. Esa persona solo tenía que usar la app de Apple de Find My para saber siempre dónde estaba y hacia donde se dirigía.
Figura 6: Lista de personas con las que compartes tu ubicación en Find My
Todo se fraguó aprovechando un descuido en el que debió dejar el terminal desprotegido, y bastó solo eso para convertir una característica de seguridad y protección personal para avisar a tus amigos y familiares dónde estáis, en una herramienta de espionaje en su vida personal.
Figura 7: Find My Frieds en iOS
AppleNO envía un mensaje al e-mail o similares, para avisar de que has comenzado a compartir localización, y tampoco pide una confirmación con passcode para hacerlo como hace con otras características, así que está al alcance de un descuido. El atacante no necesitó utilizar ninguno de los trucos que contamos en el libro de Hacking iOS: iPhone & iPad. Solo aprovechar el descuido, así que... toma nota y revisa con quién compartes tú tu ubicación.
Si vives en España es imposible que no hayas oído o leído alguna información sobre la chica que lleva desaparecida desde el 22 de Agosto en este país. Es un caso que está copando gran parte de las informaciones en medios de comunicación como la radio, la televisión y la prensa, pero también Internet. Recientemente las redes sociales hablaban sobre una de las noticias que salieron a la luz estos días en las que se informaba que la Guardia Civil había podido acceder a los mensajes de WhatsApp recibidos pero NO leídos de Diana Quer, la chica desaparecida.
Figura 1: Cómo la Guardia Civil ha accedido a "algunos" de ellos
Como os podéis imaginar, la pregunta que se hace mucha gente es "¿Cómo han accedido a esos mensajes de WhtasApp?" pensando más en si hay alguna implicación que pueda ser utilizada de alguna forma para que a alguien le puedan espiar su WhatsApp. Yo no tengo ninguna información más allá de las que se han publicado en los medios de comunicación, pero viendo lo que se ha compartido con la opinión pública os voy a dejar mis reflexiones de cómo lo han podido hacer y las suposiciones que hago en referente a los casos de qué situaciones se han podido dar y cómo se han podido dar.
Para empezar a entender el caso, hay que comenzar por explicar que un juez está llevando la investigación y ha pedido toda la información y colaboración a la operadora de la línea de teléfono que utilizaba la chica desaparecida. Para ello, evaluando la situación concreta, el juez ha tenido que tomar la decisión que más beneficiase a la chica, haciendo premiar su derecho a la vida - ya que puede estar en una situación de peligro - antes que su privacidad, y ha solicitado que se le de toda la colaboración a la operadora de telecomunicaciones que para ayude a localizar a la persona.
Para ello, según explican los artículos, el juez ha accedido al historial de los mensajes SMS, el historial de las llamadas y el historial de posición del terminal, que se conoce por medio de las antenas de telefonía a las que está conectado el teléfono para tener cobertura.
Con esta información se puede saber que el teléfono fue visto por última vez el día 22 de Agosto en una ubicación concreta, lo que quiere decir que la persona dueña del mismo no ha vuelto a encender ese dispositivo - por decisión propia, porque el terminal se ha destruido o porque se lo ha impedido algo o alguien -.
Con el historial de SMS se podría saber quién y a qué hora tuvo una comunicación vía este sistema con ese número de teléfono. Siendo una chica joven, no es de prever que hiciera mucho uso de este medio para enviar mensajes cortos, pero los SMS se siguen utilizando a día de hoy para muchas cosas, desde comunicaciones bancarias hasta recuperación de cuentas de servicios de Internet. El análisis de estos es importante para que los investigadores puedan entender un poco más los últimos días de actividad de la chica desaparecida.
¿Se puede acceder a los mensajes de WhatsApp?
Ahora viene la parte más llamativa para los usuarios medios de Internet. ¿Ha sido capaz la operadora de darle acceso a los mensajes de WhatsApp? No, ni mucho menos, pero sí que le ha dado algo que tiene mucho valor: Un duplicado de la SIM.
Conseguir este duplicado de SIM permite que se puedan recuperar todas las cuentas de servicios en Internet que tengan como protección el número de teléfono. Es decir, que los mensajes SMS se conviertan en el primer factor de autenticación en lugar de ser el segundo como muchos creen. Con solo solicitar una recuperación de contraseña y que se envíe el código de recuperación vía SMS a la nueva SIM bastaría para poder acceder a las cuentas de Internet.
Pero no solo con el clonado de la SIM, también con la portabilidad del número de una operadora a otra, con lo que la nueva operadora generaría una nueva SIM - con claves de seguridad distintas - pero válida en la red con el número de la chica desaparecida. Con cualquiera de estas posibilidades el juez se hubiera hecho con una SIM que tuviera el número de teléfono de Diana en ella.
Con esto, se dan dos posibles situaciones para que la Guardia Civil se haya hecho con los mensajes recibidos pero no leídos de WhatsApp, que os paso a detallar ahora.
Caso 1: De la nube de WhatsApp a la nueva SIM
Como os podéis imaginar, poseyendo el número de teléfono de la chica desaparecida en una nueva SIM, lo más fácil es pensar en registrar de nuevo la cuenta de WhatsApp. Para ello, se instala la app de WhatsApp en un nuevo terminal con la SIM clonada y se solicita el registro. WhatsApp enviará un mensaje SMS a ese número con el código OTP (One-Time Password) de registro y a partir de ese momento esa app será el end-point de WhatsApp para la cuenta asociada al número de teléfono que hay en esa SIM.
Una vez registrado se podrán enviar y recibir mensajes, pero hay que tener en cuenta que desde hace un tiempo las conversaciones de WhatsApp van cifradas extremo a extremo, por lo que desde los servidores de WhatsApp llegarán cifradas con la clave pública que la app de WhatsApp que la chica utilizara en su terminal intercambió en el primer mensaje que se envió con cada contacto antes de desaparecer.
Figura 3: Claves pública de cifrado intercambiada con un contacto
Es decir, supongamos que Diana tiene como contacto de WhatsApp a Persona1 y el 14 de Junio - por elegir un día tiempo atrás - se envía un mensaje por primera vez. En ese momento se produce el intercambio de claves públicas generadas por la app de WhtasApp de Diana y la Persona1. Si Persona1 envía un mensaje el día 23 de Agosto - cuando el terminal ya estaba apagado - este mensaje de WhatsApp irá cifrado con la clave pública que Persona1 tiene de Diana y solo la persona - y app - que tenga la clave privada de Diana podrá descifrarlo. De hecho, si hay un cambio de clave pública, los contactos recibirán una alerta.
Figura 4: Aviso de que se ha cambiado la clave de cifrado de un contacto
Esto quiere decir que, si los mensajes estaban aún en lo servidores de WhatsApp y no se habían enviado al terminal de Diana, entonces aunque se enviaran - que no lo hacen, ya que WhatsApp le dice al destinatario que solicite que se le vuelvan a enviar - no podrían ser descifrados por la app si no se dan otras circunstancias:
1.- Que los servidores de WhatsApp guarden las claves generadas en todas las apps: Esto no es así, porque el sistema está diseñado para que la gente de Facebook no pueda descifrar los mensajes.
2.- Que los investigadores accedan a la app de WhatsApp en el terminal de la chica desaparecida y saquen de él la clave privada. Esto no es así, porque no se ha localizado el terminal. Si se tuviera el terminal, bastaría con poner la SIM clonada en el nuevo y listo.
3.- Que los investigadores accedan a un backup del terminal en el que haya una copia de la app y saquen la clave privada. Podrían hacerlo si hubiera un backup en algún equipo Windows o Mac de la persona o en alguna nube.
Por supuesto, como el terminal no se ha localizado, la única opción posible sería la última, que además coincide con la información que se ha publicado. Sin embargo, no parece que haya sido la opción que se usado ya que al final parece que el resultado va por otro sitio, pero... es una de las opciones viables y tendría un significado de qué paso antes de que se apagara el terminal.
Si esta fue la opción, quiere decir que los mensajes se enviaron después de que se apagara el terminal, y nunca llegaron al teléfono de la chica, por lo que el dispositivo simplemente se apagó manualmente o se quedó sin batería - como parece que decía en alguno de los mensajes que tuvo con su madre -.
Caso 2: De la nube de iCloud al equipo
La chica desaparecida tenía un iPhone, lo que abre un nuevo abanico de posibilidades. Abre la posibilidad de que haya un backup en el equipo Windows o Mac que tuviera en su casa pareado con el dispositivo, por lo que se podrían sacar datos de él - no con el bug que afecta a los nuevos backups de iOS 10 ya que es de una fecha posterior al 22 de Agosto -.
Pero lo más importante es que, con el duplicado de la SIM se podría solicitar recuperar la cuenta de iCloud y acceder al backup del terminal en la nube. La idea es tan sencilla como solicitar recuperar la cuenta asociada a iCloud y pedir la confirmación vía SMS. Si Diana no tuviera activada la Verificación en Dos Pasos se podría haber intentado responder a las preguntas secretas para acceder a una nueva contraseña y, si Apple quisiera colaborar, acceder directamente al backup de iCloud.
Descartando la colaboración de Apple, con la tarjeta SIM clonada o respondiendo a las preguntas secretas se podría haber accedido al backup, donde se ha informado que había 5 GBs de copias de seguridad. Este límite es el máximo gratuito que da Apple, así que sería una cuenta estándar de iCloud que copia datos en la nube. Además, como sabéis, la base de datos de WhatsApp en iPhone está totalmente descifrada, así que los mensajes están en claro.
Figura 6: Una Base de Datos de WhatsApp en iPhone que está en texto claro
Figura 7: Demo de descargar ficheros de backup de iPhone en El Hormiguero
Si Diana, que parece que sí, tenía una copia de su base de datos de WhatsApp en iCloud con mensajes NO leídos, entonces quiere decir muchas cosas:
1.- El mensaje salió de los servidores de WhatsApp y llegó a la app de WhatsApp de Diana donde se descifró.
2.- La app de WhatsApp hizo copia de seguridad en iCloud antes de que Diana lo viera.
3.- Puede que Diana después de se hiciera la copia de seguridad lo viera, pero que no se subiera una copia de seguridad de la base de datos a iCloud más actualizada.
Esto es importante, porque lo más probable es que se dieran estas tres circunstancias, lo que implica que, si el terminal tenía las opciones de iCloud por defecto, Diana tuviera una conexión WiFi cuando se hizo la copia de seguridad, o lo que es lo mismo, que estuviera en una ubicación de la que conocía la clave de la WiFi o una zona con WiFi abierta a la que se conectó voluntariamente. Si no, iCloud no hace copia de seguridad por 3G/4G para no gastar datos en copias de seguridad.
Figura 8: Opciones de copia de seguridad de WhatsApp. Solo con WiFi por defecto
También es importante que los mensajes sí que pudieron ser vistos por Diana y lo más importante, pudo recibir más mensajes después.
Reflexión final sobre WhatsApp
Con esta información, lo que a mí me parece es que, para recomponer la historia de los mensajes de WhatsApp hay cuatro periodos que se deben abordar de tres maneras distintas.
1.- Mensajes recibidos antes del último backup: Esta fase ya está resuelta con la recuperación de la base de datos de WhatsApp del backup de iCloud recuperando la cuenta de Apple con el duplicado de la SIM.
2.- Mensajes recibidos después de conseguir la SIM: Con el registro de la cuenta de WhatsApp con la nueva SIM, todas las apps de WhatsApp de todos los contactos de Diana recibirían la nueva clave pública y si alguien envía un mensaje en cualquier momento se podrá descifrar.
3.- Mensajes que van entre el último backup y el apagado del terminal:Estos mensajes salieron de Facebook, llegaron a la app del terminal y el sistema no hizo Backup. Facebook podría tener un registro de quién y cuándo los envió y si fueron o no recibidos.
4.- Mensajes que van desde el apagado del terminal al registro de la nueva App: Ahí se puede obtener solo quién envío algún mensaje, pero no el contenido de ellos ni cuántos fueron. Estos se puede garantizar que son mensajes que nunca llegaron a destino y por tanto no fueron leídos.
Algo más de un año después del famoso “Celebgate”, la mayoría de los usuarios de iPhone que usan Apple iCloud para almacenar sus copias de seguridad siguen siendo víctimas propicias para el mismo tipo de ataque.
Figura 1: "Robar" el backup de un iPhone en iCloud con iLoot
Tal y como explicaba Chema Alonso en la demo que hizo en el programa de televisión "El Hormiguero", si mediante un sencillo ataque de Spam Phishing o de Spear Phishing de los que se explican en el libro de Hacking iOS: iPhone & iPad, un atacante consigue la contraseña de una cuenta de AppleID que le de acceso a los servicios de Apple iCloud, hay poco que el usuario pueda hacer para salvarse.
Figura 2: Demo de robar las fotos de un backup de iPhone
Esto no sería del todo cierto, ya que Apple, tras sufrir el escándalo del Celebgate hizo una cosa bien y una cosa mal. Lo que Apple hizo bien - bajo un prisma estricto de seguridad - fue dar al usuario la posibilidad de añadir la Verificación en 2 Pasos al backup de Apple iCloud. Para explicarlo de forma sencilla, una persona puede poner la Verificación en 2 Pasos a su cuenta de Apple ID y generar una contraseña de aplicación para hacer la copia de seguridad en la nube.
Si un usuario activa esta opción de seguridad, a un atacante no le valdría con robar el usuario y la contraseña de Apple ID, y debería obtener o el terminal iPhone, laSIM del teléfono o la contraseña de aplicación. Sin embargo, no todos los usuarios lo activan. Además, para un atacante, tal y como ya contó Chema Alonso en su artículo de "Cotillear la seguridad de las cuentas de Google, Facebook y Apple", es fácil saber si este usuario ha hecho los deberes y tiene la Verificación en 2 pasos o no lo tiene.
Lo que hizo mal Apple es crear el gancho de Phishing Universal, o lo que es lo mismo, enviar una alerta de seguridad por e-mail cada vez que un usuario accedía a tu cuenta de Apple iCloud, lo que puede ser usado para engañar a las víctimas en un ataque de Phishing. Hoy en día el principal problema de la seguridad informática ha pasado de estar entre la silla y el teclado a estar agarrando el smartphone. Dentro del entorno técnico es raro que a alguien “pique” en un ataque de Phishing en el que se piden las credenciales o en el que se solicita reestablecer la contraseña de su cuenta. Si bien, en el mundo real lo más probable es que al usuario le aparezca el famoso error ID-10T y acaben miles de cuentas comprometidas, como ya se vio en el caso de Oleg Pliss donde se robaron grandes cantidades.
Figura 5: Correo que envía Apple cuando alguien accede a Apple iCloud
Como ya sabemos, para la mayoría de las empresas, la falta de formación de sus empleados en materia de seguridad informática puede ser un gran problema al que hay enfrentarse activamente para ver si la compañía está lista para enfrentarse a un ataque de phishing, y para ello lo mejor es tener a los empleados siempre alerta. En este caso más aún, si tenemos en cuenta que el “target” más común de los atacantes en todas las organizaciones, suele ser usuario de iPhone, iPad, iPod o Apple Watch (como mínimo), y no suele tener un amplio dominio en seguridad informática: El Community Manager.
Figura 6: Opción en iOS para hacer copia de seguridad en Apple iCloud
No es del todo cierto que el Community Manager sea el que menos conocimiento tiene, pero permitidme el toque de humor a costa de nuestros amigos porque para preparar mejor este ataque de Spear Phishing podemos buscar qué empleados que twittean con iPhone si la app que utilizan para poner sus twitts revela el modelo de terminal con el que lo está haciendo. Enviarle un correo de Spear Phsihing vía e-mail y robarle las credenciales puede ser trivial.
Figura 7: Un mensaje de Spear Phishing para robar claves de Apple ID
Una vez que el atacante tiene las credenciales del usuario, tan solo es necesario descargarse la copia de seguridad que el terminal iPhone o iPad guarda en los servicios de almacenamiento de Apple iCloud cada vez que el usuario carga su dispositivo.
Figura 8: Descarga de un backup de iPhone desde Apple iCloud con Elcomsoft Phone Password Breaker
Para ello puede usar programas con licencia comercial como el famoso ElcomSoft. Pero para los hackers amantes del Open Source existe una alternativa llamada iLoot. Esta herramienta es un script escrito en Python que permite descargar copias de seguridad de terminales iOS almacenadas en los servicios de Apple iCloud.
Figura 9: Funcionamiento de iLoot en un Kali Linux
Es totalmente gratuito y el código se puede descargar desde su repositorio de Github. Los pros es que no hay que pagar licencia, y los contras que no tiene interfaz gráfica ya que todo se basa en comandos. O justo al revés, si lo que quieres es poner un CRON que haga esta tarea cada hora o cada día. La manera de comenzar la descarga es tan sencilla como:
/python iloot.py (AppleID) (Password)
Esto dará como resultado un sistema de carpetas, en el que aparecerá absolutamente toda la información del sistema operativo iOS que haya en la nube. Desde la configuración de las aplicaciones, los archivos multimedia, contraseñas guardadas en el dispositivo, etcétera La cantidad de información obtenida con iLoot es inmensa. Aunque no sea una interfaz tan fácil de usar como la de ElcomSoft, es fácil moverse por las carpetas, ya que están organizadas por aplicaciones.
Figura 10: Descarga de backup de iOS en carpetas
El programa ofrece distintas configuraciones adicionales, mediante los comandos:
- Output: Cambiar el directorio donde queremos que se descarguen los archivos. - Combined: Descargar todas las copias de seguridad en un solo archivo. Por defecto lo hará en archivos separados. - Snapshot: Únicamente descargar una copia de seguridad con un ID específico. - Itunes-style: Guarda los archivos en formato iTunes. - Item-types: Descargar únicamente un tipo de archivos. Sms, fotografías, chats… - Domain: Descarga documentos que únicamente pertenecen a un determinado dominio. - Keep-existing: No vuelve a descargar documentos que se hayan descargado con anterioridad (Ninguno con el mismo nombre y peso).
Por si todavía no era fácil, Apple no avisa al usuario de que alguien está descargando una copia de seguridad ni mediante un e-mail, ni SMS, ni exigiendo un 2FA en tiempo real por que no sería práctico. Eso sí, hay que robar el usuario y la contraseña o la password de aplicación.
Conclusión
Llevo tiempo intentando convencer a la gente con la que hablo de estos temas de que la informática ya ha dejado de ser un tema futurista y alejado, la informática es el pan nuestro de cada día y cada día lo será más. Ahora, es necesario que eduquemos a las nuevas generaciones enseñándoles informática desde preescolar como una materia más, concienciándolos de las amenazas y enseñándoles las oportunidades que ofrece, en definitiva, dándoles herramientas para que se puedan defender y para que puedan construir. También a nosotros este entorno tan dinámico nos obliga a seguir aprendiendo cada día, tanto a los que a nivel profesional se ven relacionados con la informática, como a los que a nivel personal quieren usar Whatsapp o el correo electrónico. Los malos están ahí fuera, no se lo pongamos fácil.
Ayer era el día en el que Apple decidió mostrar al mundo sus nuevos productos. Un iPhone 6 más grande, más rápido y más potente, un iPhone 6 plus aún más grande, en HD, que cuesta 1.000 € si quieres el biggest of the biggers, un sistema de pagos usando NFC que en un alarde disrupción han llamado Apple Payments y por último Apple Watch, el reloj inteligente de Apple - que he de decir que me ha gustado mucho todo lo que he visto de él -. Pero... yo hoy venía a hablaros de otra cosa que para muchos usuarios quizá ha pasado más inadvertido y que también ha lanzado Apple: El Phishing Universal para Apple iCloud.
Figura 1: Apple lanza el Phishing Universal para Apple iCloud
Puesta en situación
Para los que acaben de llegar del Planeta Mercurio o de la comarca de Babia en la región de León, hace unos días se produjo el Celebgate, donde algunas actrices de Hollywood aparecieron retratadas en momentos no pensados para el gran público. Tras este incidente, hubo especulaciones, investigaciones y recriminaciones sobre los fallos de seguridad que Apple, siempre en pro de la usabilidad, había relegado a planificaciones temporales más tardías.
Sirvan todos esos pequeños ejemplos como una breve recopilación de cosas que tal vez Apple podría pensar en mejorar para que ofrecieran un mayor grado de seguridad, y que Tim Cook zanjó en una entrevista con el Wall Street Journal diciendo: "Mejoraremos la seguridad de Apple iCloud".
Las mejoras
La primera oleada de mejoras llegó, y Apple cerró el bug de Find My iPhone que permitía hacer fuerza bruta a las credenciales, para pasar a bloquear las cuentas cuando se prueban más de 30 contraseñas distintas erróneas - lo que ha abierto que algunos se dediquen a generar problemas de soporte en Apple extras -.
Figura 2: Opción para cerrar todas las sesiones de iCloud vía navegador
En la segunda, Apple ha añadido en las opciones de cuenta de Apple iCloud dos cosas: La primera la posibilidad de cerrar todas las ubicaciones abiertas de Apple iCloud por si te has dejado la sesión abierta en un sitio remoto por descuido, pero que vale para poco más si el malo tiene la contraseña o un token de acceso a iCloud.
El phishing Universal
Y ahora viene la mejor. La segunda media: Un sistema para hacer Phishing Universal a todos los usuarios de Apple iCloud. ¿Cómo? Fácil. Institucionalizando que ahora sí, desde Apple, se te va a pedir que con urgencia cambies la contraseña. Como ya teníamos el panel de control para hacer las demos que usé en el ejemplo del robo de cuentas de iCloud con Phishing, nos enviamos un correo legítimo, lo copiamos y probamos. Es genial tener ya un modelo para engañar a las víctimas sin tener que pensar en ningún otro truco. Usa siempre éste modelo para robar cuentas.
Figura 3: El correo de phishing que hay que utilizar como plantilla en español
Años llevan las entidades bancarias diciéndole al usuario cosas como "Nunca te pedimos que cambies la contraseña por e-mail" para que Apple ahora decida que sí, que es lo que te van a pedir. Así que nada, para los amigos del fraude online ahora existe una plantilla modelo para crear el correo de spam que meta urgencia en el usuario y consiga que vaya a una página de phishing que le robe las passwords, con el mismo truco que expliqué ayer para Robar contraseñas de iCloud a un usuario de iPhone. Basta con decir "Eh, tío, alguien ha entrado en tu cuenta, si no has sido tú... ¡Cambia la password!"
Ayer estuve en el programa de televisión "El Hormiguero" explicando cómo se pueden robar las fotos de un usuario de Apple iCloud que tenga un iPhone para que la gente pueda entender entender de qué forma se ha podido realizar algún robo de fotos del Celebgate, para robar las fotos desnudas de las famosas. Al final, tal y como yo suponía, no ha sido un bug único sino un trabajo de mucha gente durante mucho tiempo que se ha dedicado a coleccionar este tipo de fotografías, haciendo para ello ataques dirigidos a las cuentas de las famosas.
Figura 1: Vídeo de la demo en el programa de El Hormiguero
Entre los trucos para robar las contraseñas se ha podido encontrar el ataque por fuerza bruta a Find My iPhone, el robo mediante ataques man in the middle, el shoulder surfing o cualquier otro medio de ataque, pero seguro que muchos han optado por el ataque mucho más sencillo de Phishing dirigido. Esto en iOS, como se cuenta en el libro de Hacking iPhone, es muy sencillo debido a las WebViews y la política de Apple contra el spoofing de correo electrónico y su aplicación. Vamos a ver la demo paso por paso para que se entienda mejor.
Fase 1: Spoofing, SPF y la política de Gmail
Para hacer este ataque dirigido, el esquema que se va a utilizar es de lo más sencillo del mundo. Vamos a enviar un correo electrónico a la víctima haciéndola creer que viene de apple@apple.com. Para hacer esto nos vamos a aprovechar de que el filtro anti-spoofing de correo electrónico del dominio apple.com definido en el registro SPF (Sender Policy Framework) está configurado como un SoftFail (~s) y no como un HardFail (-s).
Figura 2: Configuración de registro SPF de apple.com
Esto quiere decir que el servidor de correo que recibe un correo del dominio apple.com que no venga de una dirección IP 17.X.X.X debería subir el scoring de posible spam, pero no darlo por malo. En el caso de que hubiera un HardFail (-s) se supone que apple.com le estaría diciendo al servidor de correo electrónico que recibe este correo que lo tire, que es falso.
Nuestra víctima de ejemplo tiene un correo electrónico creado para la ocasión de Gmail, y Google no es especialmente amigo de tirar los correos electrónicos que el registro SPF marque como SoftFail, así que, como veremos, el correo entrará en el buzón de entrada de la víctima.
Fase 2: Spam y Phishing para robar la contraseña
Para hacer el ataque, en Eleven Paths creamos un pequeño panel de control que envía el "spam" - aunque sólo sea un correo a un destinatario - con un mensaje desde el equipo de Gmail o Apple que urge a las víctimas a ir a un servidor web a revisar su configuración.
Figura 3: Panel de control web para enviar spam de phishing y capturar las claves
Por supuesto, en ese servidor web lo que hay son dos páginas de Phishing que roban el usuario y la contraseña de las víctimas y re-dirigen después a las páginas originales. Un viejo truco del mundo del fraude online. No nos hemos complicado mucho y hemos copiado el formato de los mensajes usados en campañas de verdad.
Fase 2: Alerta inútil en Gmail para iOS & Address Bar Spoofing
Cuando el mensaje de correo electrónico llega, hemos utilizado como lector Gmail para iOS. Esto es así por varios motivos. El primero de ellos es porque es el cliente oficial de Gmail para los terminales iPhone, y muchos usuarios lo utilizan y el segundo porque tiene dos debilidades dignas de resaltar.
Figura 4: En Gmail entra el e-mail de apple.com com SPF SoftFail
La primera debilidad es que tiene una alerta de navegación externa bastante inútil que informa de que se va a proceder a una navegación externa, pero la URL que el usuario ve es la de un servidor de Gmail y no la del servidor web de Phishing, con lo que ayuda a tranquilizar a la víctima y que haga clic en el enlace.
Figura 5: Alerta de external page que no informa bien y Address Bar Spoofing en la WebView
La segunda de ellas es que cuando se abre, lo hace una WebView que oculta la barra de direcciones y solo muestra el campo título de la página web, lo que ayuda a que se produzca un bug de Address Bar Spoofing de libro.
Figura 6: La contraseña se recoge en el panel del servidor de phishing
Por supuesto, en cuanto el usuario introduce su usuario y su contraseña en la web de Phishing, nosotros la enviamos a nuestro panel y después re-dirigimos la navegación del WebView a la web original de Apple y/o Gmail.
Fase 3: Acceso a Apple iCloud sin alerta ni 2FA
Con la contraseña de la víctima, el siguiente paso es bastante trivial. Basta con conectarse a Apple iCloud y descargarse el backup. Existen librerías en Python para hacer esto, pero para transmitir a la gente que esto a día de hoy no es "rocket science" hemos usado una herramienta muy conocida que se llama ElcomSoft Phone Password Breaker, que ya tiene herramientas para monitorizar backups en Apple iCloud.
Figura 7: ElcomSoft Phone Password Breaker permite descargar de iCloud
Para ello se necesita introducir el usuario y la contraseña o un token de autenticación de la cuenta y listo. No hace falta robar un segundo factor de autenticación, pues aunque el usuario tenga Verificación en Dos Pasos configurada en su cuenta de Apple ID y/o Apple iCloud, el servidor de Apple iCloud lo ignora.
Figura 8: Las credenciales para descargar el backup de Apple iCloud. Elcomsoft dice que ahora puede descargar el backup sin credenciales.
Una vez conectados a su cuenta, se pueden ver todos los dispositivos que hay, el número de serie, el UDID para preparar un troyano dirigido y el número de backups que hay disponibles de ese dispositivo.
Figura 9: Se puede personalizar lo que se desea descargar del backup
Para no descargar todo puedes personalizar la descarga del backup, y bajarte lo que te interese. En este caso las fotografías de la víctima, pero podríamos descargar la base de datos de WhatsApp - es conocido como un método para espiar WhatsApp -, la información de Facebook, Gmail, etcétera.
Figura 10: Se descarga lo seleccionado con hacer clic en Download
Una vez que se han descargado, ya lo único que hay que hacer es abrir la ubicación de descarga y tendremos acceso a las fotografías de la víctima, en este caso las de la falsa cuenta de Pablo que creamos para la ocasión.
Conclusiones
En este caso la password se roba con trucos muy conocidos y funcionales en el mundo del e-crime que todavía, a día de hoy, siguen funcionado. Tal vez porque los usuarios tienen que introducir demasiadas passwords en su vida y ya no se fijan dónde y cuándo lo hacen. Hay que intentar que cada vez que se inicia una sesión en un sitio se conozca, y por eso nosotros apostamos por algo como Latch.
Figura 11: El rollo de fotos descargado del backup de Apple iCloud
Respecto a Apple, a mí me encantaría que mejorasen la configuración del filtro SPF, que no hubiera posibilidad de hacer Brute Forcing en ningún sitio de la web - que ya está hecho según parece - que pudiera poner una clave extra de cifrado del backup - al igual que se hace en Apple iTunes -, que el segundo factor de autenticación funcionase en Apple iCloud y a ser posible que las contraseñas caducasen y se avise mejor de todos los inicios de sesión de cuentas (Ahora se envía una alerta por e-mail).
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
