Se actualiza el estándar USB-C con USB Type-C Authentication Program

El estándar USB-C ha sufrido una actualización, lo que permitirá hacer uso de criptografía para autenticar los dispositivos conectados. Las implicaciones derivadas de esta actualización no son menores, pues permitirán una correcta certificación de dispositivos y mejorar la seguridad. Este nuevo estándar recibe el nombre de USB Type-C Authentication, y nos permitirá asegurar que un punto de conexión físico es genuino.

Por ejemplo, si quieres cargar un dispositivo en un puerto USB en lugares como aeropuertos, restaurantes o cafeterías, tu móvil podría permitir sólo cargar a través de cargadores certificados, de tal manera que las posibilidades abiertas para un atacante de cara a la inyección de malware en nuestro dispositivo o la inutilización del mismo al aplicar una corriente superior a la permitida quedaran muy restringidas. Tanto en este blog como en elladodelmal ya hemos hablado de los peligros a los que los usuarios se exponen a ataques BadUSB en el caso de conectarse a puntos de carga USB públicos.

El nuevo estándar permite que los dispositivos se autentiquen utilizando canales de suministro de datos o de energía, por lo que se podrá verificar un cargador sin establecer un intercambio de datos con cualquier dispositivo. Además, la autenticación tiene lugar inmediatamente antes de que el acceso al dispositivo se permita por parte del usuario. Los cables con esta nueva certificación cuentan con control sobre las políticas de seguridad que emplea el dispositivo con el que se conecta, además de un cifrado de 128 bits, firmado digital y generación de hashes aleatorios. Con respecto al cifrado, tanto la gestión de certificado del programa como del archivo PKI, el USB-IF se ha decantado por DigiCert para su gestión. Cualquier detalle adicional sobre este nuevo estándar queda especificado en el siguiente enlace.

Figura 1. Cables USB-C conectados a un MacBook Pro (2018) de 15 pulgadas

Actualmente, el proceso de certificación sólo es una recomendación. Por ahora, queda a elección de los fabricantes la implementación del mismo. Sin embargo, estamos ante un gran paso para el canal de conexión que aspira a convertirse en el puerto por defecto de todos los dispositivos del mercado en un futuro cercano.  

Este protocolo es lo que más se asemeja a MFi con respecto al USB Tipo C. Sin este certificado, un cable no puede conectarse a dispositivos  iPod, iPhone, iPad y AirPlay. Cabe la posibilidad de que a lo largo de 2019 la empresa de Cupertino avance en la implementación este estándar en sus dispositivos con USB-C. Esperemos que conforme continúe la generalización de este puerto, el proceso de certificación se vuelva obligatorio.

Bailando en el volcán: El cifrado de iMessage NO es bueno #iMessage #Apple #cifrado

Con ese título tan poético - pero en inglés - ha sido presentado un artículo en la última conferencia USENIX SECURITY donde unos investigadores han analizado y desmontado el sistema de cifrado que se utiliza en iMessage. Este sistema de cifrado ha sufrido ya múltiples vulnerabilidades, pero después de leer este trabajo parece que la culpa de todo la tiene el no seguir las buenas prácticas de cifrado que se recomiendan en todos los estándares.

El whitepaper si titula exactamente "Dancing on the lip of the Vulcano: Chosen Cyphertext Attacks on Apple iMessage" y describe una a una las debilidades que pueden explotarse por no haber utilizado los estándares marcados por la comunidad de investigadores en materia de criptografía.

Figura 1: Dancing on the lip of the vulcano

En el punto 4 se enumeran las principales debilidades que luego se pasan a explotar en diferentes casos. Estas son:

1) Servidor de claves y registro: Este servidor está controlado solo por Apple y además de significar un único punto de fallo puede significar el control total de todas las comunicaciones.

Figura 2: Cómo Apple podría interceptar tus iMessages

Ya hubo investigadores que explicaron cómo podría hacerse esto y, en el caso del registro de dispositivos, si alguien registra un nuevo dispositivo y se anula la alerta de seguridad que le llega al usuario significaría el espionaje completo de iMessage por cualquier gobierno. 

2) Ausencia de Forward Secrecy: No implementa esta buena práctica, por lo que las claves de cifrado son válidas siempre y por tanto pueden ser usadas para descifrar mensajes pasados, por ejemplo, en un caso de un terminal perdido o robado. 

3) Replay and Reflection Attacks: Estos ataques ya fueron explotados en WhatsApp, y parece que iMessage no introduce ninguna protección contra este tipo de ataques. 

4) Ausencia de Certificate Pinning en versiones antiguas de iOS: Las técnicas de Certificate Pinning ayudan a evitar cualquier ataque de suplantación de servidor o de man in the middle, pero en las versiones antiguas de iOS el cliente iMessage no lo soporta, por lo que podría realizarse.

5) No uso de protocolos estándar: Esto le lleva a Apple a cometer errores resueltos por no seguir los estándares que ya implementan las buenas prácticas de criptografía. Al final, Facebook decidió usar el sistema estándar del hacker Moxie Marlinspike para mejorar el cifrado de WhatsApp.

Figura 3: Recomendaciones a largo plazo

Al final, los investigadores hacen demostraciones de cada una de estas debilidades y terminan con unas recomendaciones a corto plazo para solventar estas debilidades, pero dejan una recomendación a largo plazo que merece la pena que veáis tal y como ellos la ponen.

Una puerta lateral en iPhone que puede robar tus claves

La noticia de hoy es uno de esos experimentos que a los fanáticos de la seguridad nos atrae. La noticia es que un grupo de investigadores de Israel y Australia hicieron recientemente un experimento con las ondas electromagnéticas generadas por el dispositivo, en este caso un iPhone. Los investigadores focalizaron especialmente en las emisiones que ocurrían cuando ciertas partes de un software específico era ejecutado. El software elegido para las pruebas fueron las siguientes librerías: OpenSSL, iOS CommonCrypto, CoreBitcoin y Bitcoin Core.

Los investigadores encontraron que a veces podían diferenciar entre dos tipos de cálculo aritmético en el código utilizado para un tipo específico de firma digital (ECDSA). Mediante el seguimiento de este tipo de operaciones y el orden de éstas, se puede decir lo que está ocurriendo en el interior del dispositivo. Por lo tanto, si la entrada es la clave criptográfica en sí, su estructura interna produce una especie de ritmo electromagnético que filtra información sobre qué bits son 1 y qué bits son 0.

Figura 1: iPhone y material necesario

¿Qué se puede hacer? En primer lugar no asustarse. Este tipo de ataque es difícil de lograr, a menos que el usuario disponga de todo el equipamiento necesario para montar el escenario ideal. El atacante necesita realizar mediciones de varias miles de firmas digitales diferentes utilizando la misma clave con el fin de tener la oportunidad de averiguarla. Si hablamos de miles de firmas digitales, hablamos de una gran cantidad de actividad en el AppStore. Si usted tiene iOS 9 o posterior, ninguna de las aplicaciones que utiliza Apple incorporan las librerías descritas anteriormente. En otras palabras, aunque el atacante decida llevar a cabo este ataque, tiene una probabilidad de éxito muy baja.

Apple dice NO a orden judicial de desbloquear un iPhone

Apple le ha dicho no a una orden judicial en el que se le pedía ayuda para ayudar a hackear el iPhone del tirador de San Bernardino, ataque ocurrido en 2015. Apple ha sido ordenado por un Juez Federal de los Estados Unidos a ayudar al Departamento de Justicia a desbloquear un iPhone utilizado por uno de los tirados implicados en los ataques de San Bernardino el diciembre pasado. El juez obliga a que Apple desactive la característica de seguridad incorporada en el sistema operativo que hace que después de 10 intentos fallidos de desbloqueo el terminal elimine datos. Este hecho permitiría al FBI utilizar fuerza bruta para poder desbloquear el terminal sin poner en riesgo los datos.

El director del FBI James Comey dijo que la agencia no ha sido capaz de acceder al terminal, incluso 2 meses después de recogerlo. Apple dice que no almacena las claves de descifrado para iPhone en sus servidores, ya que permanecen en el dispositivo. La característica que piden que Apple deshabilite solo puede ser deshabilitada una vez se acceda al terminal, y no podrá ser hecho por Apple en remoto.

Figura 1: Passcode en iPhone

El juez Federal dijo que Apple puede crear software para evitar la función de seguridad, pero esencialmente es una petición para que Apple cree una puerta trasera para el iPhone. Lo más probable es que Apple no haga caso a la orden del juez. Incluso si Apple encuentra la manera de desactivar la función de quitar dicha característica, el FBI aún tiene que encontrar una manera de realizar fuerza bruta de manera eficiente. El CEO de Apple, Tim Cook, ha emitido un comunicado público en el que señala que la empresa se opuso a la orden judicial y explica su postura sobre la necesidad del cifrado, las implicaciones de la sentencia y la amenaza que podría suponer para la seguridad de los datos. ¿Privacidad o Seguridad?

Las apps bancarias en iOS siguen teniendo debilidades respecto a 2013

La seguridad de las aplicaciones de banca móvil ha mejorado mucho en los últimos años, aunque todavía existe un margen de mejora que se debe cumplir. Se ha publicar por parte de IOActive un reporte en el que se hace una comparativa con el año 2013. En este reporte se pretende observar las mejoras o no mejoras que se han llevado a cabo.

La conclusión que podemos sacar del informe es que la seguridad en las apps móviles ha mejorado en los dos últimos años, aunque las apps siguen siendo vulnerables. La investigación se llevó a cabo sobre 40 aplicaciones de banca para iOS de todo el mundo. La investigación se limito a buscar debilidades de seguridad del lado del cliente, no incluyendo ninguna prueba del lado del servidor. La metodología de pruebas se explica con detalle en el artículo publicado por IOActive. 

Figura 1: Resumen debilidades apps bancarias 2015

Hay 5 de las 40 aplicaciones auditadas que no validaban la autenticidad de los certificados SSL presentados, por lo que son susceptibles a ataques Man in the Middle. Más de un tercio de las aplicaciones contenían enlaces no seguros en toda la aplicación. Esta diferencia permitiría a un atacante interceptar tráfico e inyectar código arbitrario Javascript o HTML en un intento de crear un indicador o entrada falsa para estafas. 

Además, un 30 por ciento de las aplicaciones no validan los datos entrantes dejándolos potencialmente vulnerables a inyecciones de Javascript. Los resultados son una mejora de lo que se vio en 2013, tal y como puede verse en la imagen. Esto llama la atención, ya que en 2015 no es que hayan mejorado mucho, pero como se ve es una mejora respecto al pasado.

Figura 2: Comparativa entre 2013 y 2015

La prueba también cubrió el análisis binario. En esta fase se vio que el 15 por ciento de las aplicaciones almacenan información sin cifrar, como por ejemplo acerca de los clientes, las transacciones de éstos, etcétera. Los ficheros dónde se almacena esta información son ficheros SQLite en texto plano. 

Como conclusiones, el consultor Ariel Sanchez indica que la mayoría de las aplicaciones han aumentado la seguridad de los datos mediante la validación de certificados. A pesar de que los números se han reducido en general, todavía hay un gran número de aplicaciones que almacenan datos inseguros en el sistema.

Según un estudio el 80% de las apps de iOS tienen fallos en el cifrado

La firma Veracode ha publicado un estudio dónde se extraen varias conclusiones acerca de las vulnerabilidades en el software. La más impactante es que más del 80% de aplicaciones móviles para iOS tienen fallos en el cifrado. Estas cifras son muy altas y el informe se puede descargar desde el sitio web de Veracode. La fuente de información utilizada para la generación del reporte ha sido una plataforma que la firma tiene en la nube, la cual ha analizado más de 1,5 billones de líneas de código fuente. Tras el análisis de este código han podido llevar a cabo un diagnóstico y detección de ciertas carencias en el software.

Los resultados del informe van más allá de las vulnerabilidades criptográficas, pero si nos centramos en lo que se puede encontrar en el informe sobre el tema es sorprendente. Existe una alta prevalencia de problemas criptográficos en iOS y Android. Cómo se puede ver en la siguiente imagen existe un gran número de vulnerabilidades criptográficas sobre las apps de estos sistemas.

Figura 1: Listado Top 10 errores criptográficos en apps

Además, el informe habla de las vulnerabilidades más genéricas según el contexto de CWE y el MITRE. Incluso en el informe se puede ver como se hace un análisis de los lenguajes que pasan los test de OWASP y el porcentaje de éxito. El test es pasado en un 44% por Objective-C, el lenguaje de iOS. Hay que detallar que este resultado es el segundo mejor, solamente por detrás de C/C++, que tiene un 60%. El propio Android o Javascript se encuentran por detrás en este ranking.

Figura 2: Resultados de OWASP para los lenguajes

En definitiva, un interesante reporte que se ha presentado hace unos días y que muestra la evolución de los riesgos y vulnerabilidades en lenguajes y plataformas. Los resultados en el tema criptográfico hacen reflejar que algo no se está haciendo bien por parte de los desarrolladores y que se debe mejorar. Seguiremos atentos en Seguridad Apple a estos informes que reflejan las mejoras o no del mundo del desarrollo seguro.

Apple libera el código fuente de las librerías criptográficas

En un esfuerzo por hacerse más transparentes ante los ojos de los investigadores de seguridad, los ingenieros de Apple han decidido publicar bajo licencia Open Source las librerías criptográficas que utilizan tanto en los sistemas iOS como OS X. La idea es que puedan ser revisadas por los expertos en criptografía y puedan localizar cualquier fallo en ellas, además de garantizar que no tienen ninguna puerta trasera. Las librerías de Common Crypto no vienen con interfaces asociadas, por lo que no están listas para poder ser utilizas en apps de iOS o en OS X, pero sí para ser revisadas.

Recordemos que Apple sufrió un ataque público masivo con el famoso bug de Goto Fail; Goto Fail, e hizo a muchos dudar de las medidas de seguridad contra espionaje que pudiera estar utilizando Apple. Además, eso le hizo merecedor del Pwnie Award al Most Epic Fail.

Figura 1: Liberías criptográficas de Apple publicadas bajo licencia Open Source

Estas librerías forman parte del Security Framework de Apple que también está liberado como Open Source, lo que garantiza que a los expertos en seguridad, a los estudiosos de las técnicas criptográficas y a los interesados en la tecnología en general, Apple les ha dado cosas que leer para un buen rato. Veremos qué se descubre en un tiempo.

Apple patenta "Guárdame estos datos secretos" en iPhone

En una petición de patente recientemente publicada Apple ha descrito algo que bien podría ser utilizado en muchas películas. Consiste en cifrar un archivo o backup de archivos y dejarlo cifrado temporalmente guardado en el terminal iPhone de un amigo en la red. Es decir, se utiliza el terminal iPhone de alguien en la red para guardar unos archivos en él, por ejemplo, fotos, documentos o datos de aplicaciones. Lógicamente, para que la persona en la que se deposita temporalmente el backup no pueda acceder a ellos se utiliza un sistema de cifrado que impida - al menos inicialmente - al depositario ver el contenido.

Figura 1: Patente Secure Ad Hoc Data Backup to Nearby Friend Devices

La patente, titulada "Secure Ad-Hoc Data Backup to Nearby Friend Devices", describe el sistema completo, con una frase descubrimiento de estos servicios, una fase de cifrado fuerte de los datos que se realiza en el terminal de origen y una transferencia del backup ya cifrado al dispositivo receptor.

Figura 2: Descripción de la arquitectura del servicio

Después, ese backup solo podrá ser descifrado cuando regrese de nuevo al mismo dispositivo y se introduzcan las claves. Vamos, una tecnología que bien podríamos haber visto en The Transporter o Mission:Impossible.....oh! wait!.

Oracle Java 8 Update 51 para OS X acaba con RC4

Esta semana Oracle puso en circulación una nueva versión de Java 8, en concreto la Update 51 que soluciona muchos problemas de seguridad. Es importante que vayas al panel de control de Java en las Preferencias del Sistema y actualices a la última versión de Oracle Java cuando salga una nueva versión, ya que si no tu equipo podría estar en riesgo frente a exploits que estén siendo utilizados en Internet.

Figura 1: Oracle Java 8 Update 51 para OS X

En concreto, esta nueva versión soluciona varios fallos de seguridad, pero es significativo que se ha bloqueado - después de la aparición del estudio de RC4 No More - el uso del algoritmo RC4 en cualquier punto del sistema.

Figura 2: Bug Fixes en Oracle Java 8 Update 51

Con esta nueva actualización Java soluciona los problemas de seguridad acumulados durante este mes, y se actualiza la lista de certificados raíz de confianza para eliminar RC4 de todas las CA y poner los nuevos certificados usados por ellas. 

Certificados Digitales inseguros en dominios de Apple: BEAST, Lucky13, Perfect Secrecy o Bar Mitzvah

En una de las pruebas que hemos realizado con diversos plugins que el servicio de Pentesting Persistente Faast para verificar la seguridad de los certificados digitales hemos podido localizar rápidamente algunas debilidades en algunos certificados digitales que está utilizando la compañía. Apple y su dominio apple.com es uno de esos mega-dominios que algunas compañías tienen. Seguramente Apple pase varias auditorias al año, pero sus dominios son tan grandes y dinámicos que están en constante crecimiento y cambio.

Por estas razones, las herramientas clásicas de escaneo no son tan flexibles como para poder escanear este tipo de dominios. En una charla sobre bug bounties y Google a la que asistimos recientemente, comparaban a Google y su dominio google.com como un universo, el cual crece y cambia tan rápido que ni el propio Google puede controlarlo. Debido a este tipo de situaciones las grandes empresas optan por los famosos programas de bug bounty y por la necesidad de realizar un Pentesting Persistente como se hace con Faast.

¿Qué prueban los plugins de certificados digitales de Faast?

Las pruebas que se realizan sobre los certificados digitales son varias y podemos recopilarlas por las vulnerabilidades, recomendaciones y notificaciones que el sistema proporciona al usuario. A continuación se muestra el listado de vulnerabilidades detectadas por estos plugins:

• Poodle SSL. Apple ya lo sufrió en su sistema operativo y lo parchearon de urgencia, además de que le apareció en varios certificados usados en Apple.com.

• CRIME. La compresión DEFLATE permite a un atacante obtener las cabeceras de las peticiones web en texto plano a través de este ataque, evolucionado de BEAST. CVE-2012-4929.

• Lucky 13. Con este ataque a TLS se puede obtener el cuerpo de los mensajes que circulan por la conexión a partir de ataques basados en leaks de tiempo.

• OpenSSL CCS (Change Cipher Spec) Injection. Bug de seguridad definido en el CVE-2014-0224.

• Insecure Renegotiation Enabled. Este bug fue presentado hace tiempo y abre los ataques de TLS-Renegotiation CVE-2009-3555. Faast también comprueba si está deshabilitada la renegociación segura.

Figura 1: Dominios de Apple.com con certificados que tienen renegociación segura deshabilitada

• BEAST. El archifamoso ataque descrito por Thai Duong y Juliano Rizzo para descifrar conexiones SSL controlando un padding.

• RC4 Cipher Suites habilitada. Estos algoritmos abren la puerta a los ataques de Bar Mitzvah. 

• FREAK. También hablamos de esto, ya que se tuvo que parchear en todos los sistemas operativos de Apple. El bug de FREAK se basa en los algoritmos de cifrado de exportación EXP.

Otras vulnerabilidades que se verifican, pero que tienen que ver con el certificado y no con el protocolo que se utiliza son las siguientes:

• Caducidad del certificado. Es importante detectar, sobretodo si tenemos muchos dominios, cuales certificados se encuentran caducados o tienen fecha próxima a su caducidad.  

• Certificado emitido para otro dominio. Esto es algo más común de lo que a priori podíamos pensar. En muchas organizaciones se reutilizan ciertos certificados, provocando que el navegador u otras aplicaciones no puedan validar realmente la identidad del certificado.

• Caducidad cercana del certificado. Como se mencionó anteriormente, se evalúa el tiempo de validez del certificado. Hay que recordar que a Apple ya se le caducó el certificado digital de uno de los servidores de Software Updates el año pasado y esta detección temprana lo hubiera resuelto.

Figura 2: Certificado de Apple.com que se caducó

• Certificado autofirmado. Esto es algo común en ciertas organizaciones. Estamos enseñando mal a nuestros usuarios realizando estas acciones, ya que generalmente el navegador va a inidicar que no se ha podido validad la identidad del certificado, mientras que el usuario aceptará la conexión. Esto puede ser un vector a técnicas MiTM.

• KeyStrength débil. En algunas ocasiones las claves utilizadas para realizar el cifrado son demasiado cortas, convertiéndose en débiles. Esto también es evaluado por Faast.

• Certificado inválido. El certificado puede presentar ciertos campos con un mal formato o alguna cadena de confianza no válida.

Por último, en notificaciones y recomendaciones el servicio de Faast comprueba lo siguiente:

• SSLv3 y SSLv2 habilitado. Esto es una mala práctica, la cual puede desembocar en una vulnerabilidad como Poodle. Como hemos dicho, esto ya afectó a Apple en el pasado.

• TLS 1.2. deshabilitado. Es altamente recomendable que TLS 1.2 esté habilitado en el sistema, Faast lo revisa.

Por supuesto, Faast se encuentra en constante desarrollo y nuevos plugins se implementan y se añaden al flujo. Últimamente tenemos mucho trabajo con el tema de certificados, ya que las útlimas vulnerabilidades nos hacen estar entretenidos con ello.

¿Qué se ha localizado?

En la siguiente imagen vemos de un vistazo rápido el que se ha detectado con Faast. El número que aparece al lado de cada vulnerabilidad o debilidad indica sobre cuantos dominios se ha encontrado este fallo.

Figura 3: Resultados de BEAST

Algunos de los dominios con más detecciones por parte de Apple son support.apple.com, discussions.apple.com, areas.apple.com, manuals.info.apple.com o tips.apple.com. Estos dominios son vulnerables, por ejemplo a BEAST. 

Figura 4: Certificados digitales vulnerables a Lucky 13

Otros dominios como locate.apple.com o idmsa.apple.com, el cual es utilizado durante una sesión con el Apple ID, también son afectados, por ejemplo por Lucky 13. Además, estos dominios tienen habilitados el algoritmo RC4 los cuales son criptográficamente inseguros y vulnerables a ataques de Bar Mitzvah.

Figura 5: Certificados digitales vulnerables a ataques de Bar Mitzvah

Seguiremos estudiando la evolución constante de estos dominios y de los certificados digitales que tienen instalados. Hay que recordar que en el pasado ya hicimos una evaluación sobre certificados digitales de Apple y encontramos Poodle. Nosotros apostamos por un pentesting persistente para todas las organizaciones, pequeñas y grandes, y pensar en que el pentesting no es cuestión de auditorias puntuales al año, si no es una necesidad del día a día.

Apple parchea Freak en iOS, OS X y Apple TV entre otros bugs

Apple ha sacado un paquete de actualización para varios productos, entre los que se encuentran iOS, OS X y el Apple TV. El Security Update corresponde con el 2015-002 y, además de parchear la vulnerabilidad de Freak que ya vimos que le afectaba, trae diversas actualizaciones de seguridad que son importante corregir cuanto antes, así que no dejes pasar más tiempo e instala esta nueva actualización en tu sistema operativo lo antes posible para dejarlo seguro.

¿Qué es lo que se ha parcheado exactamente en cada sistema?

• iCloud Keychain. Para OS X Yosemite 10.10.2 existían múltiples buffer overflow que podían ser utilizados por un atacante, con privilegios en la red, para ejecutar código arbitrario. CVE-2015-1065.
• IOAcceleratorFamily. Se parchea en las versiones OS X Mountain Lion 10.8.5, OS X Mavericks 10.9.5 y OS X Yosemite 10.10.2. Un atacante podría ejecutar código arbitrario con el máximo privilegio. CVE-2015-1066.
• IOSurface. Se parchea en las versiones OS X Mountain Lion 10.8.5, OS X Mavericks 10.9.5 y OS X Yosemite 10.10.2. Un atacante puede ejecutar código con el máximo privilegio. CVE-2015-1061.
• Kernel. Se parchea en OS X Yosemite 10.10.2. A través de lo que se indica en el CVE-2014-4496 se puede lekear direcciones del kernel y del heap, pudiendo ser utilizadas para realizar un bypass de la protección ASLR.

Figura 1: Descripción de parche de Freak en el Security Update 2015-002

Por último, el Security Update 2015-002 parchea Freak, CVE-2015-1067, el cual podría permtir a un atacante degradar la seguridad utilizando claves criptográficas inseguras y de este modo poder espiar comunicaciones. La actualización está disponible para iOS 8.2, Apple TV 7.1, OS X Mountain Lion 10.8.5, OS X Mavericks 10.9.5 y OS X Yosemite 10.10.2.

FREAK: Factoring RSA Export Keys afecta a Safari

Esta semana se ha publicado una investigación que revela cómo, una debilidad de seguridad introducida por el gobierno de los Estados Unidos para no permitir que países extranjeros utilizasen criptografía segura, ha generado un problema de seguridad en todo el mundo - incluyendo Estados Unidos -. Esto se debe a que, productos como OpensSSL o Apple TLS/SSL venían con algoritmos de cifrado RSA permitidos para exportación al extranjero que usaban cifrado con RSA de 512 bits de longitud, algo que para los años 90 era "decentemente seguro" pero ni mucho menos invulnerable para la NSA.

Hace décadas, estos algoritmos han dejado de ser seguros para nada. Con los años, OpenSSL y Apple TLS/SSL han seguido manteniendo soporte de estos protocolos de "cifrado para exportación", y navegadores como Android o Apple Safari permiten negociar estos algoritmos de cifrado. Esto permite que se pueda hacer un ataque, al que se ha denominado Freak - de Man In The Middle impersonando un servidor web si tanto el servidor web como el cliente permiten la negociación de estos algoritmos de cifrado inseguros. El siguiente vídeo muestra su funcionamiento.

Figura 1: Vídeo demostrativo de FREAK

Ya ha habido partes de seguridad en OpenSSL y Apple ha prometido parchear todas las versiones de Apple Safari que aún permiten negociar este tipo de algoritmos de cifrado para exportación. Curioso que Estados Unidos inyecte un fallo de seguridad criptográfico y acabe afectándole.

Apple cifrará con TLS el intercambio de e-mails en iCloud

Apple ha decidido dar un paso adelante para aumentar la seguridad del servicio de correo electrónico iCloud añadiendo cifrado extremo a extremo para los mensajes enviados desde me.com e icloud.com. El cambio de Apple, viene por la presión que tienen las grandes empresas, especialmente las que disponen de servicios de correo electrónico. El objetivo que se marcó Apple es cifrar los datos en tránsito tanto como sea posible para dificultar a las agencias de inteligencia, como la NSA que puedan obtener la información, al menos públicamente.

En otras palabras, agencias como la NSA disponen de la capacidad de recopilar grandes cantidades de datos sin cifrar. Algunos proveedores de correo electrónico, como por ejemplo Google o Microsoft, han estado utilizando el cifrado TLS desde hace tiempo. Apple ha decidido utilizar TLS, Transport Layer Security, para llevar a cabo el cifrado en la capa de transporte cuando un mensaje es enviado entre servidores de correo de Apple iCloud y Me.com. 

Lo que es cierto es que existen ciertos problemas debido a la naturaleza de la criptografía de clave pública que sustenta a TLS. Ambas partes, es decir tanto servidor que envía como servidor que recibe deben utilizar este mecanismo para conseguir que los mensajes permanezcan ilegibles por terceros que tengan la capacidad de interceptar dicho tráfico.

Figura 1: Funcionamiento del túnel TLS cifrado entre dominios de iCloud

Lo que es algo que, a priori, puede parecer lógico y sencillo de montar tiene sus problemas. Generalmente, los usuarios pueden utilizar distintos proveedores de correo electrónico, por lo que para que un servidor de Apple pueda cifrar el tráfico en tránsito con el servidor de correo electrónico de otro proveedor puede suponer algún que otro problema. Entonces, los mensajes enviados desde iCloud para servidores de correo de otros proveedores sin soporte TLS son entregados sin cifrar.

Funcionamiento TLS

El protocolo TLS proporciona una capa de seguridad a los paquetes que se envían en la capa de transporte. Para ello se debe crear este canal seguro, por lo que existe una fase de intercambio de mensajes entre los servidores, extremo a extremo, para poder fijar el canal seguro.

El primer mensaje enviado es quién inicia la comunicación. Mediante el envío de un mensaje ClientHello se especifica un listado de cifrados, métodos de compresión disponibles por parte del cliente. Además, se añade la versión del protocolo más alta conocida y unos bytes aleatorios, los denominados Challenge de cliente o desafío. El servidor responde con un ServerHello, en el que el servidor elige ciertos parámetros de conexión, en función de lo que haya expuesto el cliente en el mensaje previo. Cuando estos parámetros son conocidos, cliente y servidor intercambian certificados, actualmente del tipo X.509.

Figura 2: Negociación de desafío

En este punto, tanto cliente y servidor negocian la clave secreta, la cual es denominada master secret. La clave secreta se engloba dentro de la criptografía simétrica. Generalmente, esta master secret se envía cifrándola con una clave pública del destinatario y enviándola. Al llegar la clave secreta es descifrada con la clave privada del receptor. En otras ocasiones se puede utilizar el algoritmo de intercambio de Diffie-Hellman para distribuir la clave secreta. Los datos restantes referidos a claves se derivan a partir del master secret. Ahora, ambos extremos disponen de la información necesaria para poder enviar información de manera segura extremo a extremo. Para mayor detalle se puede consultar los RFC pertenecientes a TLS:

• RFC 2246. TLS 1.0.
• RFC 4346. TLS 1.1.
• RFC 5246. TLS 1.2.

Ejemplo técnico 1: Envío entre proveedores con soporte TLS

A continuación hablamos de un ejemplo en el que el usuario alice@me.com envía un correo a bob@mac.com. Ambos usuarios tienen un correo electrónico perteneciente a Apple y el correo electrónico será enviado entre servidores de la compañía con soporte TLS. Cuando Alice genere el correo electrónico y lo envíe el servidor de correo saliente realizará la generación de la comunicación segura con el servidor de correo entrante, también puede ser conocido como destino. El escenario quedaría como el siguiente:

El servidor me.com realiza el ClientHello como se explicó anteriormente hasta lograr el conocido como "Encrypted TLS Tunnel". Todo el contenido del correo electrónico circula por dicho túnel y se encuentra protegido. Esto es importante para que ninguna corporación o propietario de elementos de red que haya en medio en el camino pueda interceptar los mensajes o saber del contenido de los correos electrónicos.

Ejemplo técnico 2: Envío entre proveedores con y sin soporte TLS

En el sencillo, y altamente probable, caso de alice@me.com envíe un correo electrónico a un amigo, joshua@mailnoseguro.com, que tenga como proveedor de correo electrónico la empresa ficticia mailnoseguro.com no se podrá llevar a cabo la protección del canal cuando el correo salga del servidor de me.com. En este caso puede haber interceptación de correos electrónicos por entidades con el poder para colocarse en medio, o simplemente porque el tráfico pasa por ellos.

Conclusiones

Esta medida ha sido la última de una serie de modificaciones técnicas y declaraciones públicas de Apple para conseguir que el público quite el foco sobre que los correos electrónicos de los usuarios de Apple es visualizado por agencias de inteligencia. La sombra de que Apple ha cooperado con el gobierno de los EEUU ha hecho daño en la imagen internacional de la compañía. Apple sigue anunciando que la privacidad para ellos es algo prioritario, y que sus usuarios utilizan el hardware y software más seguro del mundo, pero los hechos constatados hacen pensar que esto no es así al cien por cien.

Figura 3: Porcentaje de correos entrantes y salientes de iCloud

Google ha puesto a disposición de los usuarios un sitio web dónde se puede visualizar el porcentaje de correos electrónidos entrantes y salientes que se canalizan a través del propio Gmail u otros proveedores, por ejemplo iCloud. En la siguiente imagen se puede visualizar los números pertenecientes a iCloud. Los datos que se arrojan desde este sitio web es que los usuarios están siendo protegidos mediante la implementación de TLS en sus servidores.

Las gráficas sobre iCloud indican que desde hace una semana casi todo el correo electrónico entrante y saliente se encuentra cifrado. Esto es un cambio respecto a lo que Google publicó a principios de verano, dónde se mostró que casi ninguno de los correos entrantes y saliente de los dominios de Apple se cifraban.

PhotoCrypt e Image Crypt: Cifrado AES de fotos en OS X

De vez en cuando, cuando el tiempo nos lo permite, revisamos el contenido de la Mac App Store en busca de herramientas de seguridad  que sean curiosas o nuevas y que puedan estimularnos mentalmente o ayudarnos en nuestro día a día. En una de esas últimas revisiones de la tienda encontramos las utilidades PhotoCrypt e ImageCrypt, un par de herramientas para OS X que son básicamente la misma solución pero en version Lite o gratuita y completa o de pago y que permiten proteger archivos de formatos de imagen usando un algoritmo de cifrado AES con una clave, que puede ser de longitud variable de 1 a 16 caracteres.

Tras descargar PhotoCrypt, la versión gratuita, probamos con un archivo PNG, en concreto la foto que contaba la noticia del uso de Windows para hacer MacBook. La usabilidad es extremadamente sencilla y puede verse que más o menos el archivo queda irreconocible al ojo.

Figura 1: Uso de PhotoCrypt en OS X. Foto sin cifrar y foto cifrada.

Sin embargo, al probar con diferentes contraseñas de diferentes tamaños se puede ver como en algunas fotografías se pueden ver los contornos o formas de los objetos que están en la fotografía. Esto es porque el cifrado del archivo se hace con la contraseña pero con fragmentos de la fotografía, así que si hay zonas que son más o menos iguales, acabarán dando resultados gráficos más o menos iguales.

Figura 2: La misma imagen cifrada con dos contraseñas distintas

Desde luego, no es lo mejor cuando se quiere proteger un contenido, ya que un atacante podría reconocer un color en un pixel y hacer un ataque de fuerza bruta al sector de la fotografía cifrado con esa clave y probar todas las combinaciones de passwords de 1 a 16 caracteres - o al menos una gran parte de ellos - para sacar la original. Dicho esto, para una protección del día a día puede que sea más que suficiente.

Figura 3: ImageCrypt en la Mac App Store

La versión completa de la app, llamada ImageCrypt, viene acompañada con el soporte de un número mayor de formatos, solo por si fuera una solución útil para ti.

WebPG: Firmar y cifrar correos de Gmail en Mac OS X

Con la aparición de End to End de Google para proteger el correo electrónico de Gmail ha vuelto a la actualidad la problemática en cuanto a usabilidad que presentan las claves PGP. Utilizar este tipo de mecanismo para cifrar y firmar el contenido de los correos electrónicos es algo necesario hoy en día, pero nos encontramos con la pobre integración que suele tener con los clientes de e-mail más utilizados. Esto es una razón de peso por la que no termina de despegar en cuanto a número de usuarios.

Otra razón de peso es la complejidad que puede suponer explicar el funcionamiento a un usuario no avanzado. Por esta razón complementos como WebPG ayudan a facilitar el uso de este tipo de tecnologías.

Instalación de WebPG en Google Chrome para OS X

La instalación es sencilla, ya que se dispone de un complemento disponible en el Store de Chrome. La última versión disponible es la 0.9.4, y se integra fácilmente con el navegador elegido. Para esta prueba hemos elegido el navegador Google Chrome en OS X Mavericks.

Figura 1: Instalación a través del Store de Chrome

Al final todo se resume a hacer clic sobre el botón de "Install" y esperar a su instalación. Después tendremos disponible el complemento en el navegador. Arriba a la derecha de la ventana del navegador aparecerá el icono de WebPG. Para que la instalación se realice correctamente se debe tener en cuenta que se necesita instalado en el equipo las GPGTools for OS X.

Configuración de WebPG en Google Chrome para OS X

Desde el propio navegador se puede abrir las opciones de WebGP y visualizaríamos algo similar a lo que se ve en la imagen.

Figura 2: Opciones de configuración de WebPG

En las opciones de configuración se pueden llevar a cabo las siguientes acciones:

• Habilitar la utilización de las claves PGP.
• Cifrar con una clave por defecto.
• Habilitar la integración con Gmail. Esta opción es muy interesante y se encuentra en fase experimental.
• Automáticamente firmar los mensajes de Gmail.
• Enlazar una identidad de Gmail al complemento. Con esta funcionalidad se da permisos a la aplicación para realizar acciones de cifrado y firmado en los correos electrónicos dentro de la cuenta que se configure. 

Enlazar una identidad es sencillo, solamente se debe clicar sobre el link "Link new GMAIL identity" para, tras autenticarse, que dicha cuenta quede configurada. En la imagen se puede visualizar los permisos que se le otorgan a WebPG, si se aceptan.

Figura 3: Enlazar una identidad de Gmail

En la parte de opciones avanzadas en la configuración del complemento se debe indicar el directorio del usuario de GnuPG, el directorio dónde está instalado GnuPG y el servidor de claves dónde se deben buscar las claves públicas de otros contactos.

Figura 4: Configuración de WebPG

Envío de correos firmados y/o cifrados de Gmail con PGP y WebPG

Tras configurar esto disponemos del complemento preparado para funcionar. Abrimos la cuenta que hayamos enlazado y al dar a envíar email podemos ver el botón WebPG. Este botón nos proporciona diferentes acciones como son:

• Solo firmado. Esta opción permite ver las claves privadas disponibles, con las que se quiere firmar.
• Solo cifrado. Esta opción permite ver las claves públicas de destinatarios. Para poder cifrar debemos tener la clave pública del destinatario del correo electrónico.
• Cifrado y firmado. Las dos acciones a la vez. 
• Cifrado y firmado simétrico, mediante el uso de una clave o contraseña que permita firmar y cifrar.

Figura 5: Firmado con PGP de un correo electrónico en Gmail

Cada día salen nuevas aplicaciones que intentan integrar y hacer más sencillo el uso de estos mecanismos. Por su definición no son sencillos de llevar a todos los usuarios, ya que por falta de conocimientos pueden perderse en el uso de las claves. Gracias a complementos como WebPG se puede utilizar de manera sencilla las claves PGP en el día a día.

Los nuevos bugs de OpenSSL sí afectan a productos Apple

Cuando se produjo el fallo de HeartBleed, los productos de Apple no se vieron demasiado afectados. En parte porque habían migrado hacia otras librerías criptográficas por motivos puramente técnicos para muchas partes de sus software, en parte porque la librería que están distribuyendo en algunas versiones era más antigua que la afectada. No obstante, no se salvaron en todos los productos, y en la gama de Airport Base Station tuvieron que actualizar el firmware para solucionar el archifamoso bug de Heartbleed.

Figura 1: Versión de OpenSSL en OS X Mavericks 10.9.3

Ahora, han salido nuevos bugs que afectan a versiones que van desde la 0.9.8 en adelante, por lo que el software de tu OS X queda afecatado por estos fallos. El parcheo lo puedes hacer manualmente o esperar a que una nueva revisión del software de OS X distribuya las nuevas versiones.

Figura 2: Versiones afectadas por uno de los nuevos bugs de OpenSSL

Por otro lado, por supuesto, el software de los productos de AirPort Base Station, que ya fue afectado, vuelve a quedar en la lista de productos vulnerables y deberá corregirse. Este tipo de cosas, en un software de seguridad tan popular es lo que ha molestado a la comunidad de Internet. No debería pasar.

AESCrypt for OS X: Cifrar volúmenes con AES en OS X

El tema de la criptografía está de moda en el mundo de la seguridad debido a la inquietante noticia de TrueCrypt. Uno de los misterios del mes, que continua con el anuncio desde el grupo de Suiza que se va a hacer cargo de él. La herramienta que tratamos hoy es una de las que comentamos ayer como alternativas a TrueCrypt para OS X, llamada AESCrypt para OS X la cual proporciona para OS X una interfaz gráfica y una tool de línea de comandos.

Figura 1: Opciones de aescrypt

La línea de comandos proporciona opciones para cifrar y descifrar archivos o volúmenes, por ejemplo DMG, mediante el uso de una contraseña o un archivo de clave. Su sintaxis como se puede visualizar es bastante sencilla.

La herramienta dispone de otro componente software que es la GUI. Esta interfaz se debe instalar por separado y se puede obtener desde el sitio web de AESCrypt. La interfaz propone un contenedor dónde se puede fácilmente cifrar archivos mediante el uso de una contraseña o mediante el uso de un keyfile.

Figura 2: Interfaz de aescrypt

Nosotros hemos tenido algún problema para ejecutar la GUI en la última versión de OS X Mavericks, por lo que se recomienda que si se tiene que utilizar la herramienta se haga a través de la línea de comandos.

Como curiosidad indicar que existe compatibilidad con plataformas PowerPC, por lo que la aplicación puede ser utilizada en versiones antiguas de equipos Mac. Además, tal y como se puede ver en la imagen existe una versión para el sistema operativo iOS, lo cual es interesante para proteger los documentos importantes, o por ejemplo los adjuntos del correo electrónico.

Figura 3: AES Crypt para descarga

Para cifrar archivos con la herramienta a través de la línea de comandos se recomienda copiar el binario en la ruta /usr/local/bin, la cual pertenece a la variable de entorno $PATH. Ahora podemos utilizar el binario desde el terminal sin necesidad de invocarle desde la ruta dónde se encuentre descargado. La sintaxis es sencilla aescrypt -e -p XXX , dónde el significado de los parámetros se indica a continuación:

• -e representa la acción de cifrar, encrypt. 
• -p indica la contraseña que se quiere utilizar para cifrar el archivo con AES. 
• -k en vez de utilizar una contraseña se puede utilizar un keyfile.

Figura 4: Cifrar archivos

Ahora, y para comprobar que podemos recuperar la imagen que acabamos de cifrar, eliminamos mediante el uso del comando rm la imagen sin cifrar. Mediante el uso de la sintaxis aescrypt -d, se solicita la clave con la que se generó la key con la que se cifró el fichero. Una vez descifrado el archivo, se vuelve a tener un archivo idéntico al original.

Figura 5: Descifrar archivos

Antes de cerrar el artículo de hoy queríamos mostrar el contenido del fichero de la imagen cifrada. Como se puede visualizar la cabecera muestra que es un archivo de tipo AES. Es más, se puede ver que no es una imagen cuando se ejecuta la aplicación file sobre el nombre del fichero.

Esta imagen nos permite visualizar que el cifrado se realiza sobre toda la imagen, y que si olvidamos la clave con la que se cifró, no podríamos recuperar la imagen original, por lo que se recomienda que utilicemos contraseñas que podamos recordar.

Figura 6: Archivo cifrado con AES

Se recomienda el uso de este tipo de aplicaciones para proteger nuestros documentos más privados, y de este modo conseguir que en caso de que nuestro sea comprometido la información siga siendo inaccesible. En muchas ocasiones, protegemos el sistema con cifrado de disco, pero éste no nos valdrá si vulneran el equipo estando esté encendido. Por otro lado, si nos protege si nos robasen el equipo, ya que al estar apagado no se podría acceder a archivos de disco.

El tipo de cifrado que presentamos aquí aplican una capa de seguridad, o de paranoia según como se mire, a la información que albergamos en nuestro disco. Es totalmente recomendable utilizar un cifrado de disco, y después para archivos más importantes o muy críticos un cifrado a nivel de archivo.