La mitad de los sitios web , y su número sigue aumentando de manera constante. El protocolo reduce el riesgo de interceptación del tráfico, pero no excluye los intentos de ataque como tales. Hablaremos sobre algunos de ellos — POODLE, BEAST, DROWN y otros — y las formas de protección en nuestro material.
/ Flickr / / CC BY-SA
POODLE
La primera noticia sobre el ataque se conoció en 2014. La vulnerabilidad en el protocolo SSL 3.0 fue descubierta por el especialista en seguridad Bodo Möller y sus colegas de Google.
Su esencia consiste en lo siguiente: un hacker obliga al cliente a realizar una conexión mediante SSL 3.0, emulando interrupciones de la conexión. Luego busca en el tráfico cifrado en -modo mensajes especiales etiquetados. Mediante una serie de solicitudes falsas, el delincuente obtiene la capacidad de reconstruir el contenido de los datos que le interesan, como cookies.
SSL 3.0 es un protocolo obsoleto. Pero la cuestión de su seguridad sigue siendo relevante. Los clientes lo utilizan para evitar problemas de compatibilidad con los servidores. Según algunas estimaciones, casi el 7% de 100,000 de los sitios web más populares . También modificaciones de POODLE, que tienen como objetivo las más modernas TLS 1.0 y TLS 1.1. Este año se han reportado nuevos ataques Zombie POODLE y GOLDENDOODLE, que evaden la protección de TLS 1.2 (aún están relacionados con el cifrado CBC).
Cómo protegerse. En el caso del POODLE original, es necesario desactivar el soporte para SSL 3.0. Sin embargo, en este caso hay un riesgo de encontrar problemas de compatibilidad. Una solución alternativa puede ser el mecanismo TLS_FALLBACK_SCSV: garantiza que el intercambio de datos mediante SSL 3.0 se realice solo con sistemas antiguos. Los delincuentes ya no podrán iniciar la degradación de la versión del protocolo. La forma de protegerse contra Zombie POODLE y GOLDENDOODLE es desactivar el soporte para CBC en las aplicaciones basadas en TLS 1.2. Una solución radical sería pasar a TLS 1.3: en la nueva versión del protocolo no se utiliza cifrado CBC. En su lugar, se utilizan AES y ChaCha20 más resistentes.
BEAST
Uno de los primeros ataques a SSL y TLS 1.0, descubierto en 2011. Al igual que POODLE, BEAST Características de la encriptación CBC. Los atacantes insertan un agente de JavaScript o un applet de Java en la máquina del cliente, que reemplaza los mensajes durante la transmisión de datos a través de TLS o SSL. Dado que los atacantes conocen el contenido de los paquetes "falsos", pueden utilizar esa información para descifrar el vector de inicialización y leer los demás mensajes al servidor, como las cookies de autenticación.
A día de hoy, la vulnerabilidad BEAST sigue : servidores proxy y aplicaciones para proteger gateways de Internet locales.
Cómo protegerse. El atacante necesita enviar solicitudes regularmente para descifrar los datos. En VMware se recomienda reducir la duración de SSLSessionCacheTimeout, de cinco minutos (recomendación por defecto) a 30 segundos. Este enfoque dificultará la implementación de los planes de los atacantes, aunque tendrá un efecto negativo en el rendimiento. Además, hay que entender que pronto la vulnerabilidad BEAST podría volverse obsoleta por sí misma: a partir de 2020, los principales navegadores de soportar TLS 1.0 y 1.1. En cualquier caso, menos del 1,5 % de todos los usuarios de navegadores utilizan estos protocolos.
DROWN
Se trata de un ataque de tipo cross-protocol que utiliza errores en la implementación de SSLv2 con claves RSA de 40 bits. El atacante escucha cientos de conexiones TLS objetivo y envía paquetes especiales al servidor que utiliza SSLv2 y la misma clave privada. Utilizando , el hacker puede descifrar una de aproximadamente mil sesiones TLS del cliente.
DROWN se hizo conocido por primera vez en 2016, cuando se descubrió que estaba en el mundo. Hasta hoy, sigue siendo relevante. De las 150,000 páginas más populares, el 2% aún utiliza SSLv2 y mecanismos de cifrado vulnerables.
Cómo protegerse. Es necesario aplicar los parches recomendados por los desarrolladores de bibliotecas criptográficas que deshabilitan el soporte para SSLv2. Por ejemplo, se proporcionaron dos parches para OpenSSL (en 2016 1.0.1s y 1.0.2g). También se publicaron actualizaciones e instrucciones para deshabilitar el protocolo vulnerable en , , .
"El recurso puede ser vulnerable a DROWN si sus claves son utilizadas por un servidor externo con SSLv2, por ejemplo, un servidor de correo," señala el jefe del departamento de desarrollo Sergio Belkin. — Esta situación ocurre si varios servidores utilizan un certificado SSL compartido. En este caso, es necesario deshabilitar el soporte para SSLv2 en todas las máquinas.
Se puede comprobar si es necesario actualizar el sistema mediante un consultor especializado. — Este fue desarrollado por expertos en seguridad de la información que descubrieron DROWN. Más sobre las recomendaciones relacionadas con la protección contra este tipo de ataques se puede leer en .
Heartbleed
Una de las vulnerabilidades más grandes en el software — . Se descubrió en 2014 en la biblioteca de OpenSSL. En el momento del anuncio del error, se estimaba que el número de sitios web vulnerables — esto representa aproximadamente el 17% de los recursos protegidos en la red.
El ataque se lleva a cabo a través de un pequeño módulo de la extensión Heartbeat del protocolo TLS. Este protocolo requiere que los datos se transmitan de manera continua. En caso de un largo período de inactividad, se produce una desconexión y es necesario restablecer la conexión. Para manejar este problema, los servidores y clientes "ensucian" artificialmente el canal (), enviando un paquete de longitud aleatoria. Si era más grande que el paquete permitida, las versiones vulnerables de OpenSSL leían la memoria más allá del búfer asignado. En esta área podían encontrarse datos sensibles, incluidas las claves de cifrado y la información sobre otras conexiones.
La vulnerabilidad estaba presente en todas las versiones de la biblioteca entre 1.0.1 y 1.0.1f, así como en varios sistemas operativos: Ubuntu antes de 12.04.4, CentOS posteriores a 6.5, OpenBSD 5.3 y otros. La lista completa está disponible . Aunque se lanzaron parches contra esta vulnerabilidad prácticamente de inmediato después de su descubrimiento, el problema sigue vigente hasta hoy. En 2017, , todavía eran vulnerables a Heartbleed.
Cómo protegerse. Es necesario a la versión 1.0.1g o superior. También se pueden desactivar manualmente las solicitudes Heartbeat utilizando la opción DOPENSSL_NO_HEARTBEATS. Después de la actualización, los especialistas en seguridad de la información deben volver a emitir los certificados SSL. La sustitución es necesaria en caso de que los datos sobre las claves de cifrado hayan caído en manos de los hackers.
Suplantación del certificado
Se establece un nodo gestionado entre el usuario y el servidor con un certificado SSL legítimo que intercepta activamente el tráfico. Este nodo se presenta como un servidor legítimo, mostrando un certificado válido, lo que permite llevar a cabo un ataque MITM.
Según comandos de Mozilla, Google y varias universidades han encontrado que aproximadamente el 11% de las conexiones protegidas en la red están "escuchadas". Esto es el resultado de la instalación de certificados raíz sospechosos en las computadoras de los usuarios.
Cómo protegerse. Utilizar los servicios de proveedores Se puede verificar la "calidad" de los certificados utilizando el servicio (CT). Los proveedores de la nube también pueden ayudar en la detección de "escuchas"; ya hoy en día, algunas grandes empresas ofrecen herramientas especializadas para monitorear conexiones a través de TLS.
Otra forma de protección será el nuevo ACME, que automatiza la obtención de certificados SSL. Al mismo tiempo, añadirá mecanismos adicionales para verificar la propiedad del sitio. Más información sobre ello .
/ Flickr / / CC BY
Perspectivas de HTTPS
A pesar de varias vulnerabilidades, los gigantes de TI y los expertos en seguridad informática están seguros del futuro del protocolo. Gracias a la implementación activa de HTTPS, el creador de la WWW, Tim Berners-Lee. Según él, con el tiempo el TLS se volverá más seguro, lo que aumentará significativamente la seguridad de las conexiones. Berners-Lee incluso sugirió que en el certificados de cliente para la autenticación de identidad. Estos ayudarán a mejorar la protección de los servidores contra atacantes.
También se planea desarrollar la tecnología SSL/TLS con la ayuda de aprendizaje automático; algoritmos inteligentes se encargarán de filtrar el tráfico malicioso. En las conexiones HTTPS, los administradores no tienen la posibilidad de conocer el contenido de los mensajes cifrados, incluido el descubrimiento de solicitudes de software malicioso. Hoy en día, las redes neuronales pueden filtrar paquetes potencialmente peligrosos con una precisión del 90%. ().
Conclusiones
Los ataques a HTTPS están mayormente relacionados no con problemas en el propio protocolo, sino con el soporte de mecanismos de cifrado obsoletos. La industria de TI comienza a renunciar gradualmente a los protocolos de la generación anterior y ofrece nuevas herramientas para la búsqueda de vulnerabilidades. En el futuro, estas herramientas se volverán cada vez más inteligentes.
Enlaces adicionales sobre el tema:
Fuente: habr.com
