Tag Archive: iCloud


iClud

Un grupo llamado Turkish Crime Family fue responsable de haber robado más de 300 millones de cuentas de iCloud que ahora amenazan con borrar si Apple no paga el rescate por 75.000 dólares o 70.000 euros que solicitan a la compañía de la manzana en criptomonedas (Bitcoin o Ether) o bien 100.000 dólares (92.500 euros) en tarjetas regalo de iTunes

Ese es el rescate que unos ciberdelincuentes demandan a Apple. El grupo, que se hace llamar Turkish Crime Family, asegura haber robado 300 millones de cuentas de iCloud que amenazan con borrar el próximo 7 de abril si la corporación no acepta su chantaje, según indica la firma de seguridad Panda.

Varias capturas de pantalla muestran el intercambio de información entre Apple y los ciberdelincuentes quienes subieron un vídeo a YouTube con la finalidad de enseñar la manera como cometían el delito iniciando sesión en varias de las cuentas referentes a iCloud y accediendo al contenido de los usuarios y borrándolo o controlándolo de manera remota.

Al parecer Apple no está dispuesta a pagarles a los ciberdelincuentes nada por atentar contra la ley. Las contraseñas que consiguieron vulnerar fueron obtenidas mediante un robo a servicios de terceros previamente comprometidos.

Por el momento Apple ha declarado que se encuentran trabajando con las autoridades en la búsqueda de información sobre los implicados en el caso. De cualquier manera la empresa les ha hecho conocer a los usuarios métodos seguros para poder resguardar la seguridad de sus dispositivos Apple tales como evitar compartir sus contraseña en varios sitios de forma simultánea así como activar la verificación de dos pasos.

Fuente | Elgrupoinformatico.com

todo-sobre-ios7

Apple suele ser muy opaca a la hora de explicar cómo funciona su sistema operativo móvil, iOS. Por eso resulta curioso ver toda la información que comparten en un paper sobre la seguridad en iOS, que expone los sistemas que usan para proteger los datos de sus usuarios.

Quizás esta publicación tenga algo que ver con el fallo de SSL de hace unos días. Sea como sea, el documento es una lectura recomendada si tenéis curiosidad por la criptografía y seguridad, aunque es bastante técnico.

> Arranque y actualización del sistema

Apple pretende que el sistema sea seguro desde el primer momento. ¿Cómo lograr eso? Con una cadena de confianza que empieza en la ROM de arranque. Este segmento de memoria es sólo de lectura y se crea durante la fabricación del teléfono. Entre otras cosas, contiene la clave pública del certificado raíz de Apple.

Con la clave pública podemos verificar la firma y asegurarnos que los datos firmados no han variado absolutamente nada desde que Apple los creó y firmó con su clave privada. De esta forma, el cargador de arranque verifica la firma del LLB (Low Level Bootloader). Este a su vez comprobará la firma de la siguiente etapa de arranque, iBoot, que finalmente verificará la firma del núcleo de iOS.

Esta cadena de confianza asegura que todo lo que se está ejecutando en el dispositivo está firmado por Apple. Teóricamente, no podríamos crear un SO alternativo y cargarlo en un iPhone: la verificación fallaría al cargar el núcleo y nos aparecería la pantalla de “Conectar a iTunes” para restaurar el teléfono.

Cupertino también tiene preparado un sistema de verificación para evitar los downgrades, instalación de versiones antiguas del sistema. La razón es impedir a posibles atacantes instalar versiones antiguas que tengan fallos de seguridad.

El proceso se llama System Software Authorization: se crea una especie de “firma” del sistema que se envía a Apple junto con un ID del dispositivo y un código (nonce) único para cada verificación.

Los servidores de Apple verifican que efectivamente esa versión de iOS se puede instalar y devuelve una autorización firmada al dispositivo. Al incluir el ID y el nonce, Apple se asegura de dos cosas respectivamente: que no estás reutilizando una autorización para otro dispositivo (por ejemplo, puedes instalar iOS 6 en un iPhone 3GS, pero no en un iPhone 5) y que no estás reutilizando autorizaciones que ya fueron usadas.

> Secure Enclave y criptografía hardware

secureenclave

La seguridad de Secure Enclave comienza en el momento en el que se arranca el sistema por primera vez. Durante la fabricación, se “imprime” en el chip un ID único (UID), que Apple dice no conocer y que no es accesible por ninguna otra parte del sistema. Ese UID se combina con una clave temporal para generar la clave de cifrado de la memoria de Secure Enclave, de tal forma que lo que se guarde ahí no podrá ser leído (teóricamente, como siempre) por nadie más.

Secure Enclave no es la única parte del sistema que cuenta con criptografía directamente enhardware. iOS cuenta con Data Protection, una característica para cifrar todos los datos sensibles, activada por defecto para todas las aplicaciones en iOS 7 cuando el usuario crea una contraseña de bloqueo.

Para poder cifrar esos archivos, Apple usa un sistema de criptografía hardware que se interpone entre la memoria del sistema y el disco de datos. Cuando leemos un archivo (por poner dos ejemplos, un ejecutable de una aplicación o un correo), pasa por el procesador criptográfico que cifra y descifra los archivos según corresponda, usando AES 256. Las claves de cifrado están de nuevo embebidas en el procesador, y ni el software ni el firmware pueden acceder a ellas.

> Touch ID y contraseñas de bloqueo

touchid

Una de las características estrella del iPhone 5S es Touch ID. En este paper se profundiza más en cómo funciona el sistema, que está muy vinculado con las contraseñas de bloqueo del teléfono.

Al configurar tu huella dactilar, se escanea tu dedo y se guarda en la memoria de Secure Enclave. Tras ser analizada para obtener los rasgos que la identifican, la imagen de tu huella se elimina del teléfono. Los rasgos se guardan en el sistema de archivos del iPhone cifrados por Secure Enclave. Según Apple, esos datos cifrados no se envían a ningún servidor, ni se guardan en iCloud o iTunes.

¿Cómo funciona el proceso de bloqueo y desbloqueo? Mientras iOS está funcionando, los archivos que usen se descifran con una clave que está en memoria. Al bloquearse, esas claves se agrupan y se cifran con una clave que almacena el sistema Touch ID. En ese momento los archivos protegidos, como tus correos, aplicaciones o datos confidenciales de tus cuentas, se vuelven inaccesibles. Sin clave no hay ficheros, y sin ficheros no puedes hacer nada.

Así, cuando el teléfono está bloqueado, se mete en su caparazón, por así decirlo. Uno pensaría que bloquear el teléfono es sólo superficial y sólo sirve para evitar que tus amigos cambien los nombres de tus contactos cuando tú no miras. La realidad es que la protección es mucho más profunda. El teléfono está realmente bloqueado y no puede seguir funcionando porque no tiene acceso a los archivos cifrados.

Al desbloquear el iPhone con la huella dactilar o con la contraseña, se recuperan las claves y el sistema sigue funcionando normalmente accediendo a los ficheros protegidos.

> Seguridad en iMessage: quizá no tan seguro

messages-1

El paper de Apple también explica cómo funciona la seguridad en iMessage. El sistema usa cifrado de punto a punto, de tal forma que (en teoría, como veremos más adelante) los de Cupertino no pueden ver qué mensajes estás enviando.

Cuando vinculas un dispositivo con tu cuenta de iMessage, se crean dos pares de clave pública/privada: uno para cifrar y otro para firmar. Las claves privadas se quedan en tu dispositivo y las públicas se envían al IDS, el directorio de usuarios de iMessage almacenado en los servidores de Apple.

¿Cómo se envían los mensajes? Supongamos que Alicia quiere enviar un mensaje a Bernardo, que es todo un fan de Apple y tiene un iPhone, un iPad, un Macbook y un iMac. Alicia escribe el mensaje en iMessage y le da a enviar. Entonces, la aplicación se conecta a IDS y mira los registros de Bernardo. Ve que tiene varios dispositivos y se descarga las claves públicas de cada uno de ellos junto con la dirección a la que enviarles el mensaje.

El iMessage de Alicia cifra el mensaje con la clave pública del iPhone de Bernardo, de tal forma que sólo ese dispositivo podrá descifrarlo con su clave privada, y lo envía a la dirección correspondiente. Hace lo mismo con cada uno de los dispositivos de Bernardo, enviando un mensaje cifrado a cada uno.

Si el mensaje incluye adjuntos, el iMessage de Alicia subirá cada adjunto cifrado a iCloud. El mensaje que se envíe a Bernardo contendrá información para descargar y descifrar el archivo desde iCloud.

Sin embargo, este esquema tiene fallos. Decíamos que en el directorio se guardan las claves públicas de los dispositivos de Bernardo. Ahora bien, ¿cómo sabemos que esos dispositivos son realmente de Bernardo? ¿Qué pasa si Bartolo, el hermano gemelo malvado de Bernardo, entra en los servidores de Apple e inserta la clave pública y dirección de su iPhone? A Bartolo le llegarían todos los mensajes de Bernardo, y Alicia no tendría forma de detectarlo.

Ese es el fallo del esquema de iMessage. Y es que no hace falta que sea Bartolo el superhacker quien entre a los servidores. Pensando mal, podríamos imaginarnos que Apple podría colocar claves públicas a petición de la NSA para espiar a ciertos usuarios. O quizás, si tu iPhone no ha sido actualizado, alguien podría manipular las respuestas del servidor IDS de Apple e introducir claves públicas adicionales para ver los mensajes que envías.

> iCloud Keychain, contraseñas en la nube

icloud

Para acabar, repasemos cómo funciona iCloud Keychain, el servicio de Apple que permite sincronizar contraseñas en varios dispositivos. La idea del Keychain de iCloud es, curiosamente, que las contraseñas no se almacenan en iCloud, al menos no de forma permanente. Lo que se almacena es un círculo de confianza que incluye las identidades de cada uno tus dispositivos.

Al activar Keychain por primera vez en tu cuenta, tu teléfono crea un par de clave pública y clave privada. La clave pública se almacena en el círculo de confianza, que se firma con la clave privada y con una clave derivada de tu contraseña de iCloud.

Cuando añades otro dispositivo a iCloud Keychain, este crea su par de claves y, al detectar que ya hay otros dispositivos vinculados, crea una petición de vinculación. Esa petición o ticket contiene la clave pública del dispositivo, y está firmada con la clave derivada de la contraseña de iCloud. La petición se envía a iCloud.

En ese momento tienes que usar el teléfono en el que ya esté configurado iCloud Keychain, que habrá detectado que hay una petición pendiente y te preguntará con un popup si quieres añadir la nueva identidad. Si aceptas e introduces tu contraseña de iCloud, se verifica la firma y se añade la clave pública al círculo de confianza. De nuevo, el círculo se firma con la clave privada y la clave derivada. El nuevo dispositivo también firma el círculo con su clave privada.

El funcionamiento puede parecer bastante lioso (de hecho, lo es). Hagamos una analogía. iCloud Keychain es un club elitista del cual tú eres el presidente. Si alguien quiere entrar, primero tiene que preguntarte a ti el santo y seña. Después va al club y les dice a los miembros que quiere entrar, y les da el santo y seña. Ellos te preguntan si el santo y seña es válido. Si lo es, el nuevo miembro es bienvenido al club.

A la hora de enviar los datos, se hace entre los clientes. Si creas una nueva contraseña en tu iPhone y hay que sincronizarla en tu Macbook, el iPhone cifra la nueva entrada con la clave pública del Macbook y se la envía directamente a través de iCloud.

De esta forma, tus contraseñas se guardan en tus dispostivos. Se transmiten de tal forma que nadie más que el dispositivo destino puede descifrarlas.

Por otra parte, cada dispositivo envía una copia de seguridad de tus contraseñas a los servidores de Apple. Ahí se guarda cifrada con tu código de seguridad de iCloud, de tal forma que si pierdes tu dispositivo puedes recuperar las contraseñas. Las copias de seguridad están almacenadas en uncluster de servidores seguros, que cifran las copias de nuevo con una clave única para cada servidor. A la hora de recuperar la copia, se verifica que el usuario conoce el código de seguridad de iCloud sin pedirlo directamente (no sale del teléfono). Si todo sale bien, se envía la copia al usuario y se recuperan las contraseñas.

Como medida de seguridad adicional, el firmware de esos servidores borra automáticamente los registros si se tratan de desbloquear 10 veces sin éxito o si se intenta modificar el propio software de los servidores.

Estos son los aspectos más destacados del paper de Apple. Desde luego, es muy de agradecer tener tantas explicaciones sobre un aspecto en el que Apple es normalmente muy opaca. De nuevo, si tenéis curiosidad, en el PDF hay más datos y más técnicos, como por ejemplo el sistema de cifrado de archivos o cómo ejecutan sólo aplicaciones autorizadas en el teléfono.

Fuente | iOS Security

«Creo que hoy en día es completamente imprudente ofrecer este tipo de servicio sin una autenticación de dos factores, pues de lo contrario el servicio se hace propenso a técnicas básicas de robo de datos»

Costin G. Raiu, director del equipo de investigación y análisis global (GReAT) de la compañía de seguridad informática Kaspersky Lab, expresó sus dudas sobre el recién lanzado servicio iCloud de Apple en términos de seguridad y privacidad. «Creo que hoy en día es completamente imprudente ofrecer este tipo de servicio», aseguró Raiu en un comunicado difundido por la empresa.

A continuación lea el comunicado completo redactado por el mismo Raiu:

«Tras el lanzamiento de iCloud para desarrolladores por parte de Apple, la batalla para dominar el mercado de los sistemas operativos centrados en la nube finalmente ha estallado. Por supuesto, el verdadero punto clave en esto es el iOS5, el nuevo sistema operativo de Apple que aprovechará al máximo el uso de la nube. Esto indica que Apple se mueve en la misma dirección que Google y Microsoft al diseñar y planear la implementación de un sistema operativo que esté completamente integrado con la nube. Es más, la declaración de Steve Jobs sobre el interés de Apple en crear un sistema operativo que no dependa del sistema de almacenamiento local de archivos reafirma esta conclusión.

¿Y qué significa esto desde el punto de vista de la seguridad? Básicamente estamos hablando de la misma clase de riesgos inherentes a ChromeOS (el sistema operativo de Google). Todo su contenido digital podrá ser accesible a aquel que conozca su contraseña. Creo que hoy en día es completamente imprudente ofrecer este tipo de servicio sin una autenticación de dos factores, pues de lo contrario el servicio se hace propenso a técnicas básicas de robo de datos.

Por supuesto, aunque la seguridad de hecho sea mejorada con métodos de autenticación multifactoriales, no cambia el hecho de que toda la información está disponible en la nube, en un solo lugar. Justamente como lo acaba de aprender Sony recientemente, la nube no siempre es impenetrable. Al contrario, su naturaleza fundamental la hace un blanco interesante para los cibercriminales, y sin duda seguirán enfocados en vulnerarla.

En el caso hipotético de que tanto la nube como el dispositivo del cliente fueran 99.99% seguros, todavía existe otro punto vulnerable: la red que comunicará, enviará, recibirá y autenticará a los clientes. Desde este punto de vista, podríamos enfrentarnos a un nuevo brote de ataques en la capa de la red, en donde la información del usuario puede ser interceptada, falsificada, denegada o distorsionada. Por lo tanto, podremos ser testigos de nuevos y más sofisticados ataques en este ámbito».

Fuente