Apple, Google, Microsoft y Mozilla han anunciado su plan de deshabilitar TLS 1.0 y 1.1 en 2020

Los cuatro titanes de la industria han anunciado recientemente su plan de sustituir el protocolo Transport Layer Security (TLS) 1.0 y 1.1 por otras versiones más seguras y modernas del mismo. En un artículo publicado en el blog de WebKit el ingeniero de software de Apple Christopher Wood presentó la posibilidad de sustituir las versiones 1.0 y 1.1 de TLS por la versión 1.2 y la reciente versión 1.3. Wood, que está especializado en infraestructuras públicas y servicios de encriptación define TLS como un protocolo de seguridad de internet crítico a la hora de proteger el tráfico web que viaja entre los clientes y los servidores.

El protocolo nació con la intención de ofrecer confidencialidad e integridad a la información sensible de los usuarios y eso sigue haciendo, sin embargo las versiones a sustituir se remontan a 1999. Para salvaguardar a los usuarios de una potencial explotación de vulnerabilidades de navegador y frente a posibles ataques man-in-the-middle, Wood sugirió actualizar el protocolo y aseguró que la versión 1.2 de TLS se ajusta más a las necesidades actuales de la red. Además Christopher declaró que Apple sustituirá las versiones del protocolo en futuras actualizaciones programadas con el lanzamiento de una nueva versión de iOS y macOS en marzo de 2020.

Figura 1: Apache también se despide de TLS 1.0 y 1.1.

En la actualidad Apple utiliza TLS 1.2 como versión estándar, haciendo que cerca del 99.6% de las conexiones realizadas con safari utilicen esta versión más moderna del protocolo. Como un esfuerzo por parte de la industria para realizar esta transición de las versiones más anticuadas a las actuales, Google Chrome, Microsoft Edge y Mozilla Firefox dejaran de ofrecer soporte para TLS 1.0 y 1.1 al mismo tiempo que Safari. Actualmente el navegador con mayor índice de uso de estos anticuados protocolos es Firefox con tan solo un 1.2% de las conexiones que realiza, cifras considerablemente bajas.

Guía de seguridad en macOS (Parte 3)

Llegamos al final de nuestra serie de artículos sobre la seguridad en macOS con una entrada sobre las conexiones de red, el control de dispositivos hardware y la política de privacidad que impera en Apple. Con esto hemos tratado todas las aristas que componen la seguridad y fortificación del sistema operativo de Mac.

Apple actualiza la guía de seguridad de iOS

Apple ha publicado una versión actualizada de su guía de seguridad para iOS, en la cual se detallan las características añadidas en iOS 11.2 (lanzado el 4 de diciembre del pasado año) y de iOS 11.1 (octubre de 2017). La compañía compartió este documento por primera vez en junio del año 2012 y lo ha estado actualizando desde entonces. Esta última iteración contiene nuevos detalles y datos sobre Apple Pay Cash, certificaciones de seguridad y programas, Touch ID y Face ID, Notas compartidas, CloudKit y encriptación de extremo a extremo, TLS, pagos con Apple Pay desde la red, Sugerencias de Siri y la función de iPad compartido.

En el documento se explica que tanto para iOS 11 como para macOS High Sierra, los certificados SHA-1 no serán permitidos para conexiones TLS a no ser que sean de confianza para el usuario y certifiquen que las claves RSA más cortas de 2048 bits estén deshabilitadas. El documento también explica detalladamente la seguridad del sistema peer-to-peer utilizado en Apple Pay Cash lanzado en junio de 2017. Al parecer, la información provista a Apple cuando configuraba el sistema va a ser compartida con su banco asociado (Green Dot Bank) y con Apple Payments Inc. (Una filial poseída por la empresa y creada para proteger la privacidad de sus clientes a través del almacenamiento y procesado de información).

Figura 1: Guía de Seguridad en iOS actualizada

“Esta información y datos sobre transacciones serán usadas para la resolución de problemas, prevención de fraudes y propósitos reglamentarios, pero el resto de la compañía no sabe a quién envías o con quien intercambias dinero”, puntúa Apple en el documento.

Hace unos meses con el lanzamiento del Face ID, Apple publicó un documento en el que se explicaba la seguridad y el funcionamiento de su nuevo sensor biométrico. Esta información ha sido también incluida en la actualización de la guía de seguridad de iOS. Para todos aquellos interesados en conocer un poco más sobre la seguridad de iOS y sus servicios asociados la actualización de este White paper puede resultar de bastante interés.

Confide: La aplicación de mensajería de los empleados de la Casa Blanca

La aplicación de mensajería Confide puede estar siendo utilizada por los ayudantes del nuevo presidente de los Estados Unidos Donald Trump. Al parecer la aplicación se apoya en criptografía robusta, aunque algunos expertos en seguridad se muestran escépticos. Los rumores de que los asesores del nuevo presidente estén utilizando esta aplicación ha puesto a la aplicación bajo el microoscopio de la seguridad. El medio nacional, Washington Post, mencionó que la Confide ha sido construída por una startup de Nueva York y es utilizada por algunos empleados de la Casa Blanca para comentar en privado algunos rumores que puedan ocurrir allí dentro. 

La aplicación consta de un chat secreto, el cual dice borrar los mensajes según son leídos. Los asistentes y empleados, temerosos de ser acusados de filtrar a la prensa, intentan utilizar aplicaciones que no deje huellas o mensajes de una forma descontrolada. Todo lo que se envía se debe eliminar. Confide no es la primera vez que está en el punto de mira. En el año 2014, ya salió a la luz mediática, debido a que fue puesta como un ejemplo de aplicación de mensajería segura. Lo que no se detalló es como hace la implementación del cifrado extremo a extremo, ni el borrado de los mensajes. Estos detalles no se dieron por la empresa.

Figura 1: Confide

Confide está disponible para iOS y Android. Utiliza, básicamente, el estándar OpenPGP para utilizar clave pública y utiliza AES para el cifrado de mensaje. Intercambia claves públicas entre usuarios a través de conexiones TLS 1.2 con Certificate Pinning. Algunos expertos indican que el fabricante de la aplicación puede forzar la posible escucha de conversaciones, sustituyendo las claves de los usuarios. En teoría, esto es algo complejo de realizar. Según Jonathan Zdziarski, el cifrado parece funcionar como la mayoría de las aplicacioens extremo a extremo, dónde se generan claves públicas y privadas. Eso sí, cree que no ha pasado una revisión suficiente por el CIO de la Casa Blanca, por lo que aquí están las dudas de si se está metiendo algo seguro en la Casa Blanca o no.

Decenas de aplicaciones de iOS inseguras en la AppStore

Decenas de aplicaciones de iOS, populares, son vulnerables a la interceptación de datos protegidos por el protocolo TLS. De estas aplicaciones decenas, alrededor de 75, no utilizan buenas prácticas para proteger los datos de los usuarios. Esto es, sin duda, una afirmación o noticia grave, ya que impacta en el manejo de los datos de los usuarios y algo que deberá ser revisado. La noticia ha sido puesta en conocimeinto para el público por los investigadroes de Sudo Security Group, los cuales descubrieron este hecho inesperado para muchos.

Algunas aplicaciones de iOS en la AppStore habían sido implementadas con carencias en el cifrado y sus comunicaciones, pudiendo ser vulnerables a ataques de man in the middle. Las aplicaciones podrían ser engañadas por un certificado falso enviado por un proxy, permitiendo que su seguridad de la capa de transporte pueda ser descifrada y visualizada a medida que se envía el tráfico hacia Internet.

Figura 1: Generación de certificado con OWASP ZAP

El descubrimiento fue inicialmente el resultado del análisis realizado por los investigadores de la empresa. A través del uso de un servicio que realiza un análisis estático de binaios de aplicaciones de la App Store. El presidente de la empresa Sudo verificó que las aplicaciones descubiertas por el sistema eran vulnerables en el laboratorio, utilizando para ello un proxy de red configurado con su propio certificado. Esta es una práctica que en muchas auditorías se utiliza y que para muchos no es nuevo, pero impacta ver como las aplicaciones más populares no utilizan Certificate Pinning para mejorar la seguridad de los usuarios.

iOS 9 soluciona 101 bugs de seguridad (Ahí es nada)

El sistema operativo de iOS ha sido liberado con un gran número de agujeros de seguridad parcheados. A Apple ya le ha pasado varias veces que cuando comienza un nuevo número de versión, en este caso de la 8 a la 9, la descarga es más grande de lo normal. Por ejemplo, la versión 8.4.1 estaba en 50 MB o en OTA a través de 1,2 GB. La nueva versión está alrededor de los 2 GB en lo que a fichero IPSW se refiere realizando la descarga completa del firmware. 

Los cambios y nuevas características de seguridad que forman parte de la seguridad de iOS 9 son las siguientes:

• Passcode de 4 dígitos a 6: De esta forma el tiempo y las combinaciones de fuerza bruta aumentan exponencialmente.
• Doble factor de autenticación (2FA) en iOS 9: Necesita el uso de El Capitan OS X 10.11, la cual se encuentra aún en beta.
• Bloqueo de extensiones en el navegador Safari.

En realidad las partes más importantes que se han solventado o mejorado en términos de seguridad son las actualizaciones que se han tenido que liberar en esta versión. Otros de los bugs que se solventan en iOS 9 hacen indicar que el software saldría sin ellos parcheados, siendo parcheado el día 16 de Septiembre. 

Figura 1: Cambio del nuevo Passcode de 6 digitos

En estas actualizaciones hay todo tipo de vulnerabilidades que han sido parcheadas, como por ejemplo: 

• Ejecución de código remota potencialmente explotables a través del WebKit y el núcleo de Javascript.
• Leaks. El acceso a la memoria del kernel puede provocar estas fugas de información.
• Denegar el servicio o crashear el dispositivo.
• Suplantaciones de identidad enviando un correo electrónico falso que parece provenir de un contacto de la libreta de direcciones. 
• Visualización de tráfico que circula a través de conexiones TLS debido a un error en el manejo de un certificado. 
• Spoofing. Falsear un sitio web que parece que se encuentra con la dirección URL legítima.

En la lista podemos encontrar 101 entradas de vulnerabilidades, aunque quizá haya una que se lleve el premio, y es una vulnerabilidad que permite determinar una clave privada a un atacante. Se puede deducir tras la observación de muchos intentos de firma o de descifrado qué clave privada RSA se tiene.

Figura 2: 101 bugs solucionados en iOS 9

Como se puede ver la salida de iOS 9 trae muchas novedades y muchos agujeros de seguridad tapados, más de 67 importantes. Por esta razón, os recomendamos actualizar vuestro sistema y poder estar un poco más seguros con el nuevo sistema operativo.

Pobres medidas de seguridad en los SmartWatches según un informe de HP

HP ha publicado algunos informes que han generado mucha expectación, como su ya famoso informe sobre seguridad en dispositivos móviles, dónde nos sorprendían con datos como que el 90% de las apps eran vulnerables. Hoy HP nos sorprende con un informe dónde se cuentan las principales vulnerabilidades en 10 de las marcas mas vendidas de relojes inteligentes. El estudio revela fallos, que a priori podríamos pensar ya estaban solucionados en otro tipo de sistemas. 

El informe indica que el mercado de relojes inteligentes está creciendo rápidamente. Alrededor de unos 6,8 millones de relojes se vendieron en 2014, mercado dominado en gran parte por Samsung, aunque el lanzamiento del Apple Watch hizo cambiar todo, dominando con el 75% de las ventas, vendiendo 4 millones de relojes durante el segundo trimestre de 2015.

Algunos analistas indican que el mercado de relojes inteligentes se encuentra en la infancia en comparación con el de teléfonos inteligentes, han estimado que cerca de 350 millones de relojes entrarán en uso en todo el mundo en 2018, cifras muy optimistas. La noticia que HP mostraba al mundo a través de su informe es que estos relojes son un riesgo para la seguridad, ¿Cómo reaccionan las empresas?

Figura 1: Fallos de seguridad expuestos en el informe de HP

Como se puede ver en este extracto del informe de HP, existen diferentes fallos que ponen en riesgo la seguridad de los dispositivos, y por lo tanto del ámbito de uso de estos relojes. Si éstos son utilizados en el ámbito empresarial, puede suponer una brecha de seguridad para este entorno, por lo que debe ser tenido en cuenta por la gente de TI.

Autenticación y autorización insuficiente, malas políticas de contraseñas, enumeración de usuario, recolección de cuentas, son algunos ejemplos de los fallos encontrados en esta categoría. El 30% de los dispositivos falló en esto. Un dato curioso en el informe es el dato sobre el cifrado en la capa de transporte. El 100% de los relojes implementaban este mecanismo de seguridad, aunque el 40% eran vulnerables a poodle, permitían cifrados débiles o utilizaban todavía SSLv2. En algunas ocasiones parecen que a los diseñados les vale con que aparezca en las especificaciones el uso de SSL/TLS sin mirar más allá.

El software y firmware inseguro es algo de lo más crítico. El 70% de los relojes que evaluó HP tenían problemas para proteger la actualización de firmware, incluso llevando a cabo esto sin cifrado. Por último el tema del almacenamiento de información y la privacidad de ésta. Todos los dispositivos recolectan y almacenan información personal, como por ejemplo, direcciones, fechas de cumpleaños, peso, frecuencia cardíaca. Esta información puede quedar expuesta debido a la enumeración de cuentas y el uso de contraseñas débiles en algunos productos.

El informe de HP no es más que un reflejo del mundo en el que vivimos, la tecnología avanza con paso firme y los mercados crecen a esa velocidad, pero la seguridad no lleva el mismo ritmo, por lo que nos encontramos con situaciones como la que se refleja en el informe. 

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.

Apple Safari 7 se defiende de BEAST en OS X Mavericks

En el año 2011 en las conferencias Ekoparty en Buenos Aires, los investigadores en seguridad Thai Duong y Juliano Rizzo realizaron una demostración del exploit denominado BEAST, Browser Exploit Against SSL/TLS, utilizando para ello un Applet de Java. Antes de hablar de la noticia en sí, la mitigación de este ataque por parte del navegador de Apple, hablaremos de qué es BEAST y en qué afecta realmente a los usuarios. BEAST afecta a TLS 1.0 y SSL 3.0.

La mayoría de los sistemas de cifrado están basados en dos hechos fundamentales:

• El atacante no conoce el mensaje que se envía por el canal.
• El atacante no conoce la clave utilizada para cifrar el mensaje que circula por el canal.

En el mundo de la seguridad se conocía desde hace años que TLS/SSL era potencialmente vulnerable, fue enunciada por Phillip Rogaway en el año 2002. Por lo tanto BEAST no ha revelado ninguna cosa que no se supiera, pero ha demostrado con las acciones necesarias a llevar a cabo la explotación real de la vulnerabilidad, es más, BEAST ha conseguido realizar una prueba de concepto de algo teórico y que parezca "sencillo".

¿Cómo funciona BEAST?

En primer lugar el atacante debe insertar código en la sesión actual del navegador de la víctima, por ejemplo utilizando un iframe embebido en un sitio web. El código inyectado debe obligar al navegador de la víctima a incluir un fragmento conocido de texto sin formato. Es muy importante este hecho ya que servirá de código de estudio, a través del canal SSL.

Para llevar a cabo esta acción lo más sencillo sería utilizar, por ejemplo Javascript. El atacante debe capturar tráfico SSL de la víctima, por lo que lo más sencillo sería utilizar un ataque ARP Spoofing, en una red local IPv4, o con algún ataque en una red IPv6, por ejemplo, o algún tipo de rastreador. En este punto el atacante dispondrá de un ejemplo de texto sin formato y un fragmento cifrado con el cual se podrá llevar a cabo el criptoanálisis. El objetivo podría ser conseguir una cookie de sesión, una contraseña, etcétera.

Video 1: Ejemplo de Beast explotado con un Apple Safari 5

Recomendaciones

Las recomendaciones para mitigar el impacto de la vulnerabilidad son:

• Debido a que el atacante necesita de tiempo para descifrar el mensaje, si la cookie de sesión se invalida antes de que el atacante consiga su objetivo, el ataque no tendrá éxito.
• Cerrar la sesión correctamente al abandonar un sitio SSL. 
• Evitar la visita de recursos no seguros, es decir evitar la inyección de código, evitar el uso de una red no segura, donde pudieran haber "vecinos" o equipos adyacentes no fiables.

El nuevo Apple Safari 7 en OS X Mavericks

Apple ha habilitado una nueva característica en su reciente actualización de OS X Mavericks, la cual neutraliza los ataques criptográficos BEAST. La funcionalidad para mitigar este ataque en Apple Safari 7 estaba implemente en código desde principios de 2012, en la versión OS X Mountain Lion, pero no había sido habilitada hasta la nueva versión del sistema operativo OS X Mavericks 10.9.

Por otro lado, si se quieren habilitar las mitigaciones contra BEAST en OS X Mountain Lion en el navegador de Apple Safari, se debe ejecutar la siguiente instrucción y después reiniciar el navegador:

 sudo defaults write /Library/Preferences/com.apple.security SSLWriteSplit -integer 2

Apple parcha B.E.A.S.T. en XCode... casi 1 año después

En Septiembre del 2011, Juliano Rizzo y Thai Dong sorprendían de nuevo a mundo desde la Ekoparty - conferencia que se está acostumbrando a este tipo de situaciones - con la publicación de B.E.A.S.T. (Browser Explotation Against SSL & TLS) recogido en su famoso paper "Here como the Ninjas". En aquella presentación, demostraron cómo era posible descifrar la comunicación SSL & TLS de una comunicación si se controla un padding en el comienzo del algoritmo de cifrado. Rápidamente aparecieron las aplicaciones que implementaban este tipo de técnicas, y todos los fabricantes de tecnología SSL & TLS tuvieron que parchar sus sistemas.

Figura 1: Thai y Juliano en la Ekoparty 2010

Sin embargo, Apple no ha actualizado XCode, el entorno IDE de desarrollo contra este bug hasta esta semana, en la que por medio del Apple Security Advisory APPLE-SA-2012-07-25-2 Xcode 4.4 comunicaba a la comunidad de investigadores de seguridad que publicaba un parche en la librería neon para solucionar el bug con CVE-2011-3389, es decir, el de B.E.A.S.T. Esto evitaría que tus aplicaciones con soporte SSL o TLS fueran vulnerables a este bug.

No solo ha solucionado este bug, sino que en el mismo advisory se encuentra un parche para el bug CVE-2011-3389 que puede permite a las Helper Tools construidas con XCode acceder a cualquier dato almacenado en el keychain por cualquier aplicación, lo que llevaría a que una aplicación maliciosa de la App Store, accediera al keychain de otras, algo que es más que probable que Apple haya descubierto en activo en aplicaciones de la App Store.

En definitiva, Apple actualiza XCode a la versión 4.4, por lo que si estás realizando software o quieres hacerlo, te recomendamos que instales la nueva versión cuanto antes, ya que depende del IDE que tus aplicaciones quede seguras frente a estos bugs.