You are here: Home » None

Protocolos ChaCha20 y Poly1305 para reforzar conexiones HTTPS

by Esteban on April 30, 2014 2 Comments

A comienzos de este año, Google implementó en Chrome un nuevo conjunto de cifrado TLS (cipher suite) que funciona tres veces más rápido que AES-GCM en los dispositivos que no tienen hardware de aceleración para AES, incluyendo a la mayoría de los celulares con Android, dispositivos portables personales tales como Google Glass y también computadoras antiguas. Esto mejora la experiencia del usuario, reduce la latencia y ahorra batería al reducir la cantidad de tiempo empleado en cifrar y descifrar la información.

Para lograr esto, Adam Langley, Wan-Teh Chang, Ben Lauriey implementaron nuevos algoritmos -ChaCha20 para cifrado simétrico y Poly1305 para autenticación- en OpenSSL y NSS (Network Security Services) en marzo de 2013. Fue un esfuerzo complejo que requirió la implementación de una nueva capa de abstracción en OpenSSL para dar soporte apropiado al modo de cifrado AEAD - Authenticated Encryption with Associated Data. AEAD permite que el cifrado y la autenticación sucedan concurrentemente, haciéndolo más sencillo de usar y optimizar que los antiguos y comunmente usados modos tales como el CBC. Por otra parte, los recientes ataques contra RC4 y CBC también impulsaron a hacer este cambio.

Los beneficios de este nuevo conjunto de cifrado incluyen: 

  • Mayor seguridad: ChaCha20 es immune a los ataques Padding-Oracle, tales como el Lucky13, que afecta el modo CBC que se usa en TLS. Por diseño, ChaCha20 también es inmune a los ataques de sincronización. Revise la descripción detallada de las debilidades de los conjuntos de cifrado de TLS en este post.
  • Mejor rendimiento: ChaCha20 y Poly1305 son muy rápidos en dispositivos móviles y personales, ya que por sus diseños son capaces de aprovechar las instrucciónes de CPU comunes, incluyendo el juego de instrucciones vectoriales ARM. Poly1305 también ahorra ancho de banda, ya que su salida es de solo 16 bytes comparado con HMAC-SHA1, el cual es de 20 bytes. Esto representa una reducción del 16% de la recarga de red TLS que se produce cuando se usan conjuntos de cifrado más antiguos como RC4-SHA o AES-SHA. La aceleración esperada comparada con AES-GCM para varias plataformas se puede ver resumido en el siguiente cuadro.

 

En febrero de 2014, caso todas las conexiones HTTPS realizadas desde los navegadores Chrome en dispositivos Android a sitios de Google han utilizado este nuevo conjunto de cifrado. Planeamos hacerlo disponible como parte de la plataforma Android en una futura versión. Si quiere verificar cual conjunto de cifrado utiliza actualmente, en un dispositivo Android  o en el escritorio, simplemente haga click en la barra de dirección URL y vea la solapa de conexión. Si Chrome está utilizando ChaCha20-Poly1305, verá la siguiente información:
 


ChaCha20 y Poly1305 fueron diseñados por el Prof. Dan Bernstein de la Universitidad de Illinois en Chicago. El diseño simple y eficiente de estos algoritmos combinados con la extensa investigación de antecedentes que recibieron de la comunidad científica nos hace confiar en que estos algoritmos traeran la seguridad y la velocidad necesarias para las comunicaciones móviles seguras. Por otra parte, la selección de algoritmos que son gratuitos para que todos los usen también está en linea con nuestro compromiso por la transparencia y apertura.



Si se accede a GMail con Google Chrome, ya se puede ver el uso de dichos protocolos.

Quisieramos agradecer a la gente que hizo esto posible:  Dan Bernstein quien inventó e implementó tanto ChaCha20 como Poly1305, Andrew Moon por su implementación de código abierto de Poly1305, Ted Kravitz por su implementación de código abierto de ChaCha20 y Peter Schwabe por su trabajo de implementación. Esperamos que habrá incluso una mayor adopción de este conjunto de cifrado, y esperamos ver que otros sitios deprecien AES-SHA1 y RC4-SHA1 en favor de AES-GCM y ChaCha20-Poly1305 ya que estos ofrecen una alternativa más segura y rápida. Los borradores de estandar IETF para este conjunto de cifrado están disponibles aquí y aquí

 

Fuente:
Google Online Security Blog

Seria vulnerabilidad en biblioteca OpenSSL Heartbleed.

by Esteban on April 11, 2014 0 Comments

En las últimas horas se han disparado las alertas por las los peligros en seguridad que provoca una vulnerabilidad que tenía la librería criptografica OpenSSL, apodada #Heartbleed. Esta vulnerabilidad ha sido descubierta por Neel Mehta del equipo de Google Security, y el CVE reservado (CVE-2014-0160) fue creado el 3 de Diciembre de 2013.

El sitio web http://heartbleed.com/ creado a tal efecto por la empresa finesa Codenomicon defensic reune valiosa información respecto de esta vulnerabilidad.

El bug Heartbleed

El bug Heartbleed es una seria vulnerabilidad en la popular librería de software criptográfico OpenSSL. Esta debilidad permite robar información protegida, en condiciones normales, por el cifrado SSL/TLS utilizado para asegurar Internet. SSL/TLS proveen seguridad a las comunicaciones y privacidad en Internet para las aplicaciones como la web, correo electrónico, la mensajería instantánea y algunas redes privadas virtuales (VPNs).

El bug Heartbleed le permite a cualquiera en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves pprivadas usadas para identificar a los proveedores de servicios y para cifrar el tráfico, los nombres y contraseñas de usuarios y el contenido. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y usuarios, y suplantar a los servicios y a los usuarios.
 

¿Cómo detener la fuga(de información)?

En tanto se use la versión vulnerable de OpenSSL, ésta puede ser abusada. La versión reparada de OpenSSL ha sido publicada y ahora debe ser instalada. Los proveedores y distribuidores de sistemas operativos, proveedores de appliances, proveedores de software independientes deben adoptar el arreglo y notificar a sus usuarios. Los proveedores de servicio y usuarios deben instalar el arreglo en cuanto esté disponible para sus sistemas operativos, equipos de red y software que utilicen.

Los profesionales de seguridad están alertando de las implicancias prácticas mencionando por ejemplo que muchos sitios web protegidos con SSL "esos con direcciones https://" padecen de esta vulnerabilidad. Indican que a los efectos prácticos uno debiera considerar que su usuario y contraseña ha sido comprometido.

También conexiones VPN que usen SSL, mensajería instantanea que utilicen la librería OpenSSL están afectados hasta tanto se actualice el software con la versión reparada de OpenSSL.

Es mucha la información que se puede encontrar en Twitter y en http://heartbleed.com/ sobre esta vulnerabilidad y las soluciones que van llegando.

Comprobando un sitio web

Un consultor independiente de criptografía, italiano, Filippo Valsorda, preparó una página para comprobar si un servicio web es vulnerable a esta falla de seguridad #heartbleed, y asi entonces uno puede saber si puede o no confiar en que el tráfico (nuestro usuario y contraseña y otros datos) está protegido de forma apropiada, o no.

 

No fue inicialmente así el caso para el correo Yahoo! y de Hotmail / Outlook que aparecían vulnerables. Aunque al mediodía ya se reportaban como no afectados:

  • All good, mail.yahoo.com seems not affected!
  • All good, login.live.com seems not affected!
  • Otros sitio populares como Gmail, Facebook, Twitter, Linkedin también son seguros.

Una de las cuestiones que plantea esta vulnerabilidad es la necesidad de asegurarse que las claves privadas de los certificados SSL no hayan sido comprometidas. En ese caso si no se regenera el certificado, cabe la posibilidad que un atacante pueda continuar leyendo el trafico cifrado SSL, si hubiera obtenido las claves privadas mientras la vulnerabilidad estuvo activa.


Impacto tras explotación

La información que se podría obtener sería la siguiente:


  1. Claves privadas
  2. Usuarios y contraseñas utilizadas en servicios vulnerables
  3. Información sensible utilizada por servicios vulnerables
  4. Direcciones de memoria y su contenido que podría permitir evadir mecanismos de mitigación ante exploits.

¿Qué páginas se encuentran afectadas?

Unas cuantas... y muchas.



Se ha puesto a disposición de todos un listado del TOP 1000 portales web según el ranking de ALEXA, mostrando si son vulnerables o no. El listado corresponde con el estado de dichas webs durante la tarde de ayer cuando fue confeccionada tras la ejecución de la herramienta de comprobación de manera masiva.

 

 

Shodan también han publicado una lista de dispositivos vulnerables.

¿Mi servidor es vulnerable?

Rápidamente, comenzaron a publicarse herramientas que permitían tanto comprobar si un servidor es vulnerable, tanto como para obtener la información tras su explotación (aplicación en Python) o de forma masiva.
Si se ejecuta esta aplicación se verá una salida como muestra la imagen, demostrando que el servidor es vulnerable.

Se puede conocer qué versión se tiene instalada y si la misma es vulnerable, con el siguiente:
openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

El miércoles pasado se implementó el módulo de esta vulnerabilidad para Metasploit. En GitHub se encuentra el módulo preparado para descargarse y probarse. El módulo es de tipo Auxiliary, por lo que recordaros que se asume como funcionalidad extra, no relacionada con la explotación de vulnerabilidades, pero útiles en cualquier pentesting.

Hay otras entradas que muestran más códigos que se pueden utilizar:

NMap también ha publicado un módulo para el análisis de múltiples servidores y rangos completos de direcciones IP.


  1.  Instalar la última version de Nmap
  2. Descarga el script https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse  a la carpeta "scripts" de Nmap
  3. Descargar la libreria https://svn.nmap.org/nmap/nselib/tls.lua a la carpeta "nselib" de Nmap
  4. Ejecutar: nmap --script-updatedb

Para comprobarlo en una URL determinada:
nmap -vv -p 443 --script ssl-heartbleed dominio.com -oN resultado.txt

Para comprobar un rango:
nmap -vv -p 443 --script ssl-heartbleed 000.000.000-000.* -oN rango.txt

Fuente: Segu-Info.

 

www.estebanrojas.com