Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Boletín semanal de ciberseguridad 13-19 febrero Vulnerabilidad de elevación de privilegios en Windows Defender El investigador de SentinelLabs Kasif Dekel ha descubierto una nueva vulnerabilidad en Windows Defender que podría llevar activa más de doce años....
ElevenPaths ElevenPaths Radio – 2×04 Entrevista a Juan Cobo ¿A qué responsabilidades y retos se enfrenta un CISO en su día a día? Nos lo cuenta en este episodio Juan Cobo, CISO Global de Ferrovial.
ElevenPaths Noticias de Ciberseguridad: Boletín semanal 7-13 de noviembre Vínculos entre Vatet, PyXie y Defray777 Investigadores de Palo Alto Networks han indagado en las familias de malware y metodologías operativas utilizadas por un actor amenaza que ha logrado pasar...
Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Boletín semanal de ciberseguridad 13-19 febrero Vulnerabilidad de elevación de privilegios en Windows Defender El investigador de SentinelLabs Kasif Dekel ha descubierto una nueva vulnerabilidad en Windows Defender que podría llevar activa más de doce años....
ElevenPaths Noticias de Ciberseguridad: Boletín semanal 1-7 de agosto Base de datos de más de 900 servidores empresariales Pulse Secure VPN Se ha detectado una publicación en foros underground que muestra la existencia de una base de datos con...
ElevenPaths Internet se ha roto, otra vez (I) Poco se puede aportar ya al fallo de implementación criptográfica Heartbleed (ya tenemos disponibles plugins para FOCA y Faast). Se trata de un grave problema que tendrá (y es...
Área de Innovación y Laboratorio de ElevenPaths ElevenPaths pasa a formar parte del Atlas de Ciberseguridad de la Comisión Europea El Área de Innovación y Laboratorio de ElevenPaths ha sido incluida como como parte del Atlas de Ciberseguridad de la Comisión Europea, una plataforma de gestión del conocimiento que...
Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Todo lo que vimos en Security Innovation Day 2015 (II): tu móvil, tu identificador único Tu número de móvil, tu llave de acceso En ElevenPaths estamos cambiando la forma en la que los usuarios interactúan y se relacionan en el mundo digital. El móvil se...
ElevenPaths Historias de #MujeresHacker: Laura iglesias, experta en ciberseguridad y hacking en Telefónica Esta semana os traemos el relato de Laura Iglesias, una de las expertas en ciberseguridad con más experiencia en ElevenPaths y una de las mujeres que cree que la diversidad...
Perfect Forward Secrecy: ¿Existe el secreto perfecto y permanente?ElevenPaths 19 mayo, 2014 El atacante se dedicaba a “esnifar” conversaciones en redes internas, a través de cualquier técnica que le permitiera obtener el tráfico de sus víctimas. Para el tráfico cifrado, no sustituía certificados ni usaba sslstrip o cualquier otro método que pudiera poner en guardia al espiado. Simplemente atrapaba y almacenaba el tráfico cifrado por SSL. “Algún día esto podría serme útil”, pensó. Hasta que llegó el 7 de abril de 2014. Entonces desempolvó varios gigabytes de información y sonrió. ¿Tenía motivos? Ese día se dio a conocer Heartbleed y se demostró que era posible obtener la clave privada TLS/SSL de los servidores. Si se daba prisa, podría obtener las claves de los lugares vulnerables más populares, y con ella, descifrar todo el tráfico esnifado días o años atrás. Solo tendría que arrancar Wireshark, indicar en la configuración la clave privada robada gracias a Heartbleed, y cargar el tráfico cifrado que obtuvo en su día… ¿O no? No tan rápido. Las bases del cifrado RSA es un algoritmo de firma digital, creación de claves… y también de criptografía asimétrica. Diffie-Hellman es solo un algoritmo de intercambio de claves secretas en un entorno en el que un atacante podría tener acceso al canal de comunicación. Pero con la criptografía asimétrica (RSA), en realidad, también es posible intercambiar información por un canal inseguro: basta calcular una clave aleatoria, cifrarla con la clave pública del receptor y este la descifraría con su clave privada. Así intercambian y comparten clave y con ella cifrarían de forma simétrica la conversación. Con estas dos filosofías “presentes”, SSL/TLS puede ser implementado de muchas formas, y todo depende de la suite de cifrado que utilice el servidor. Veamos: En una conversación SSL/TLS “típica con RSA”, el servidor se autentica a sí mismo (muestra su certificado y el cliente lo valida) y luego ambos acuerdan cifrar la conversación. En resumen (aunque hay una master y una premaster) los servidores cifran una contraseña y se la intercambian. Si un atacante robase la clave privada del servidor, podría descifrar todas las conversaciones pasadas, porque podría obtener la premaster key, deducir de ella la master y tener el tráfico en claro. En este esquema el fallo es que se usa la clave privada del servidor (que es permanente hasta que caduque el certificado) tanto para autenticarse como para cifrar. Por tanto, en este entorno donde se utiliza RSA y cifrado asimétrico, descifrar conversaciones retroactivamente sería posible una vez obtenida la clave privada (gracias a Heartbleed, por ejemplo). La ciphersuite usada en el servidor sería, por ejemplo RSA_WITH_AES_256_CBC_SHA y sus combinaciones (RSA_WITH_RC4, RSA_WITH_AES_128….) Pero no todos los servidores funcionan así, todo depende de la suite de cifrado. La solución para evitar ese descifrado retroactivo es usar una clave permanente (en el certificado) para autenticar, y otras efímeras (calculada al vuelo) para cifrar. ¿Cómo? Separar autenticación y cifrado RSA se puede seguir usando para autenticar, pero el intercambio de claves para el cifrado puede hacerse con Diffie Hellman (DH), que para eso es un algoritmo de intercambio de claves. Como matemáticamente sus valores son aleatorios y se usan una sola vez, se llaman efímeros (DHE). A su vez hay dos formas de implementar Diffie Hellman. Esquema de funcionamiento de Diffie-Hellman.Fuente: Wikipedia. Con número discretos. Con un rendimiento peor. Con curvas elípticas (ECDHE). Se consigue una seguridad muy buena con números más pequeños, y por tanto el rendimiento no decae tanto. Lo malo es que no todos los navegadores lo soportan. Una idea de lo reciente que es, es que openSSL lo implementó en su versión 1.0.0. A este uso de intercambio de claves efímeras (normalmente con DH en el contexto de SSL), se llama Perfect Forward Secrecy (PFS). Las cipher suites usadas en los servidores, serían por ejemplo DHE_RSA_WITH_DES_CBC_SHA y sus múltiples variantes. Nada impide usar claves RSA “efímeras” para intercambiar una clave maestra con la que cifrar la información. De hecho se hacía antes (con TLS 1.0). Pero es lento en comparación con DHE. Y tenía un problema adicional precisamente por ser lento… para ahorrar tiempo, se generaban al vuelo claves RSA muy cortas, de forma que con el tiempo podrían llegar a ser rotas por fuerza bruta. ¿Entonces se puede ser descifrar retrospectivamente o no? Será más fácil o no dependiendo de la suite de cifrado usada en el servidor. Pero en realidad, lo más probable es que el atacante descrito arriba, pueda seguir sonriendo. Aunque el servidor hubiera tomado la precaución (y las molestias, porque no es muy soportado, requiere software moderno, etc) de utilizar PFS, todavía habría una oportunidad para el atacante. SSL cuenta con dos sistemas para “acortar” el tiempo de handshake cuando un cliente se conecta a un servidor. Memoriza sus estados y consigue así una conexión más rápida, facilita el single-sing-on, etc. Estos mecanismos son: Sessions IDs: Tanto servidor como cliente recuerdan sus estados, y ambos se comunican con un ID que identifica ese estado. El cliente lo usa para indicarle al servidor que “busque” en memoria la conexión de ese cliente concreto. El problema es que si hay muchos front-ends, cada servidor puede haber ofrecido un ID diferente al cliente, y para solucionarlo se deben guardar en disco y compartirlo, cosa que no es buena idea. Si por el contrario estos IDs se mantienen en memoria, rotan a menudo. Session tickets: Con este método (activo por defecto en OpenSSL), es el servidor el que firma y envía el estado cifrado al cliente, y “se olvida”. Un cliente toma un ticket de sesión de un servidor, y una vez validado, le puede servir para otro front-end diferente (en un cluster, por ejemplo) y no tener que empezar de nuevo. Esos tickets son como una especie de pases temporales de sesión que ahorran tiempo a todos. Se generan y se cifran independientemente, y, por la forma que trabaja TLS, su fortaleza es menor (utiliza un cifrado más débil). Así que, en cierta medida, si se usan tickets de sesión, el secreto es tan fuerte como el del cifrado durante el intercambio de estos tickets, no el del cifrado de la información “real”. Y lo que es peor, la información para cifrar los tickets no rota demasiado. Se suelen generar en memoria del servidor. Si es un solo servidor SSL el que maneja toda la información, este puede mantener el mismo ticket de sesión desde que arranca el servicio en memoria hasta que sea reiniciado. RFC sobre session tickets. Fuente: tools.ietf.org/html/rfc5077 Por tanto, si con Heartbleed se obtuvo un ticket de sesión además de la clave privada, es posible que se pudiera obtener toda la información cifrada con los tickets, y con ella deducir las conversaciones durante la validez de ese ticket… que podrían haber sido días y días atrás. Sergio de los Santos ssantos@11paths.com @ssantosv Cómo añadir Latch a la cuenta de servicios MovistarDescubriendo los activos de una organización (I)
Área de Innovación y Laboratorio de ElevenPaths ElevenPaths pasa a formar parte del Atlas de Ciberseguridad de la Comisión Europea El Área de Innovación y Laboratorio de ElevenPaths ha sido incluida como como parte del Atlas de Ciberseguridad de la Comisión Europea, una plataforma de gestión del conocimiento que...
Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Boletín semanal de ciberseguridad 13-19 febrero Vulnerabilidad de elevación de privilegios en Windows Defender El investigador de SentinelLabs Kasif Dekel ha descubierto una nueva vulnerabilidad en Windows Defender que podría llevar activa más de doce años....
Martiniano Mallavibarrena La nueva fuerza de trabajo digital y los riesgos alrededor de la robótica de procesos (RPA) En estos últimos años, son muchas las empresas de distintos sectores que han optado por basar su transformación digital en la automatización de procesos (RPA – Robot Process Automation),...
ElevenPaths ¿Qué es la VPN y para qué sirve? Las conexiones VPN no son nada nuevo, llevan con nosotros mucho tiempo, siempre unidas al ámbito empresarial. La gran versatilidad y sus diferentes usos ha hecho que cada vez...
Juan Elosua Tomé Nueva versión de FARO: crea tu propio plugin y contribuye a su evolución Hoy venimos a presentaros una nueva versión de FARO, nuestra herramienta open source de detección de información sensible de la que ya os hemos hablado en este mismo blog...