Primero debo dar gracias a todos los que nos han enviado comentarios, correos, mensajes acerca de Ciberseguridad al Desnudo, sin ustedes no tenemos por qué escribir, así que GRACIAS !!!
Ahora, si leíste la historia del ataque de ProtonMail, debes haberte fijado en una de las imágenes del reporte de Akamai:
¿Cuál es el problema acá? Simple: que aunque muchos sitios en el área hispanoparlante usan SSL, no lo tienen configurado como se debe, lo cual los deja vulnerables a estos ataques, que cada vez son más comunes. Siempre hay que aclarar que cuando estamos hablando acá de SSL, realmente estamos hablando de TLS (Transport Layer Security), que es el término correcto para ello. Si se toca SSL 2 y SSL 3, entonces si estamos hablando de SSL.
Entonces como estamos tratando de combatir el desconocimiento, en este post les hablaré acerca por qué se debe usar HTTPS en todo momento, incluso si su sitio es informativo; las recientes vulnerabilidades descubiertas con respecto a SSL/TLS y cómo mitigarlas.
Bueno, y ¿Qué es TLS?
Transport Layer Security (TLS) es el predecesor de SSL (Secure Socket Layer), por eso es que ambos comúnmente son referidos como SSL. Ambos son protocolos de criptografía, diseñados para proveer una comunicación segura en una red de computadoras.
Existen varias versiones de estos protocolos que están en uso alrededor de las aplicaciones web a nivel mundial para la navegación web, correo, fax por Internet, mensajería instantánea y VoIP.
Muchos sitios como Google, YouTube, Facebook usan TLS para asegurar toda la comunicación entre los navegadores de sus clientes y sus servidores web.
En el caso de SSL, existen las versiones 1, 2.0 y 3.0 (ambas obsoletas); y para TLS 1.0, 1.1, 1.2 (en uso) y 1.3 (no está totalmente definida).
¿Qué dice la industria?
El PCI Security Standards Council, el cual define el estandar PCI Data Security Standars (PCI DSS), enfocado a las buenas prácticas para el trabajo seguro con transacciones financieras y tarjetas de crédito; emitió un comunicado en Abril de este año, de qué por qué se debe migrar de las versiones 3.0 de SSL y TLS 1.0. Pueden leerlo acá:
The time to migrate is now.For over 20 years Secure Sockets Layer (SSL) has been in the market as one of the most widely-used encryption protocols ever released, and remains in widespread use today despite various security vulnerabilities exposed in the protocol.
Fifteen years ago, SSL v3.0 was superseded by TLS v1.0, which has since been superseded by TLS v1.1 and v1.2. To date, SSL and early TLS no longer meet minimum security standards due to security vulnerabilities in the protocol for which there are no fixes. It is critically important that entities upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.
SSL has been removed as an example of strong cryptography in the PCI DSS, and can no longer be used as a security control after June 30, 2016.
La última versión del estándar PCI DSS es la versión 3.1 y pueden encontrarla acá.
Los útimos tiempos han sido convulsos en la industria de la ciberseguridad, porque se han descubierto disímiles vulnerabilidades en SSL/TLS, por lo que debemos actuar ya.
¿Cómo hacemos para saber si nuestro sitio es vulnerable?
Muchos sitios son vulnerables a los errores que comentaré más adelante, y el área latina no se queda detrás.
Para comprobarlo, escogí algunos sitios que manejan transacciones financieras en el área latina, y los escaneé usando la herramienta de Qualys´s SSL Test, la cual verifica la configuración de tus servidores con respecto al uso de TLS. Y los resultados no son nada alentadores:
¿Qué quiere decir esto en sí? La herramienta de Qualys hace un escaneo de tus servidores, y prueba los mismos contra recientes vulnerabilidades descubiertas en años recientes enfocadas en TLS, OpenSSL, suites de cifradores (como el caso de RC4). En el caso que les presento acá, Qualys le dió un grado F, lo cual puede ser bastante problemático para la empresa.
Sabiendo esto, contacté a los fundadores de la misma, y les expliqué el por qué estaban dejando de lado la seguridad de su plataforma, y qué debían hacer. Hasta la fecha, no han hecho nada, por lo que aunque no diré nombres, es tiempo de hablar sobre ello.
Vulnerabilidades recientes de TLS y OpenSSL
Para los administradores de sistemas y los Ingenieros de Sistemas que están trabajando en estas empresas, por favor: sigan las listas de seguridad de MITRE, OpenSSL, TLS y todas por el estilo, debido a que ustedes tienen la responsabilidad de proteger a sus usuarios, y créanme: hoy en día la Seguridad es un Growth Hack para todos, así que hagan su trabajo y estén al día con todos estos problemas.
Algunas de las vulnerabilidades más peligrosas son:
POODLE (CVE-2014–3566)
Los posts (1, 2) en Qualys acerca de esta vulnerabilidad están muy informativos, por lo que les aconsejo que los lean. (Están en inglés). Esta vulnerabilidad en sí lo que hace es aprovecharse de una falla en el diseño del protocolo SSL versión 3.0 (RFC6101), específicamente de la suite de ciphers CBC. El paper que describe cómo funciona está acá, donde Bodo Möller, Thai Duong y Krzysztof Kotowicz, del equipo de seguridad de Google explican de manera muy detallada cómo un atacante puede realizar un ataque POODLE (Padding Oracle On Downgraded Legacy Encryption): donde puede “apoderarse” de cookies HTTPS, y lanzar ataques de tipo Man-In-The-Middle.
Heartbleed (CVE-2014–0160)
Esta vulnerabilidad se aprovecha de un problema en la implementación de la extensión heartbeat de TLS/DTLS de OpenSSL, y puede traer problemas de corrupción de memoria en el servidor.
Las versiones de OpenSSL vulnerables a este problema son:
- OpenSSL 1.0.1 hasta 1.0.1f (inclusivo)
Para leer más acerca de Heartbleed, pueden leer su página oficial acá.
BEAST (Browser Exploit Against SSL/TLS)(CVE-2011–3389)
Esta vulnerabilidad puede acarriar en ataques MitM, donde el atacante puede apoderarse de los tokens de autenticación de la conexión por HTTPS, y pueden corromper los datos.
Pueden leer más acerca de BEAST en los siguientes links:
- BEAST paper: Here Come The ⊕ Ninja
- BEAST en Wikipedia
CRIME (CVE-2012–4929)
Esta vulnerabilidad fue descubierta por los mismos investigadores que sacaron a la luz BEAST: Juliano Rizzo y Thai Duong, y también puede usarse para ataques MitM aprovechándose del robo de sesiones por HTTPS.
Aquí puede leer la presentación que hicieron en la Ekoparty 2012.
FREAK
Ésta es otra de las vulnerabilidades que pueden ser usadas para ataques MitM, ya que permite a un atacante interceptar conexiones entre clientes vulnerables y servidores que acepten la suite de cifradores RSA_EXPORT.
Pueden leer más acerca de este ataque en su sitio dedicado. Y puede ver este pequeño resumen también acerca de FREAK y Logjam:
Si quieren leer acerca de las implicaciones peligrosas de este ataque, pueden leer el post de Matthew Green, criptógrafo y profesor de la Universidad John Hopkings:
This is the story of how a handful of cryptographers ‘hacked’ the NSA. It’s also a story of encryption backdoors, and why they never quite work out the way you want them to.
Logjam
Logjam es otro ataque dirigido al algoritmo criptográfico Diffie-Hellman el cual es usado para el intercambio de claves, y muchos protocolos de seguridad recaen sobre él: HTTPS, SSH, IPsec, SMTPS. Por lo que este ataque es considerado otro de los más serios en la actualidad. El paper que describe el ataque y sus mitigaciones está acá. También cuenta con sitio oficial.
Si quieren profundizar un poco más, pueden ver esta charla impartida por David Adrian, uno de los investigadores detrás de los ataques Logjam y FREAK, en Duo Security:
También les recomiendo ver el video de Felipe Tribaldos, uno de los Ingenieros de Sistemas de CloudFlare. Felipe impartió una excelente charla en el LACNIC 23:
Entonces, ¿Qué se puede hacer?
Estar actualizados
- Lo primero que siempre recomiendo es estar actualizado acerca de las vulnerabilidades de las plataformas que uses, ya sea OpenSSL, Apache HTTP Server, Nginx, NTP (Usado en muchas ocasiones hoy para los ataques DDoS), DNS, etc.
- Usa la herramienta de Qualys para probar tu sistema, y trata de obtener al menos un grado A (el óptimo es A+). Hay disímiles guías para hacer esto:
- Achieving Full Marks on Qualys SSL Labs (usando Nginx)
2. How I Scored an A+ on the Qualys SSL Test (con Apache)
3. Getting an “A+” on Qualys SSL Labs with Apache 2.2 on Debian Wheezy
Si no tienes cómo comprar un certificado SSL válido, puedes usar estos dos recursos
3. Switch to HTTPS for Free Now (Cómo obtener un certificado válido gratis de 2048 bits)
4. Let´s Encrypt, el proyecto de la EFF y la Linux Foundation para proveer certificados SSL gratis a todos.
5. CloudFlare también está ofreciendo este servicio por medio de Universal SSL.
Si tus sysadmins quieren conocer más acerca de TLS, SSL, Encriptación y mucho más, pueden usar estos recursos
- Is TLS Fast Yet? Por Ilya Grigorik, uno de los Developers Advocates de Google. Les aconsejo también ver las charlas: HTTPS Everywhere y Is TLS Fast Yet? de Ilya acerca de estos temas:
2. High Performance Browser Networking: What every web developer should know about networking and web performance, por Ilya también.
3. Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications, por Ivan Ristic, Director de Ingeniería en Qualys, autor de la herramienta SSL Test de Qualys. Esto debe estar en cada estante de cada empresa hoy. 200% RECOMENDADO
Usen las herramientas proporcionadas por Mozilla
Mozilla provee una wiki con las suites de ciphers recomendadas y además brinda una herramienta para darte la configuración necesario para mejorar tu implementación de TLS en Nginx y Apache HTTP Server:
Conclusiones
Las conclusiones son simples, y este Tweet lo resume muy bien:
Así que sysadmins a trabajar a por el A+ en Qualys
