¿Qué tipos de ataques previene SSL?

Introducción

SSL y TLS son protocolos que se utilizan para cifrar los canales de comunicación entre dispositivos de red. Se utilizan para vincular la identidad de sistemas, usuarios, sitios web, etc., mediante certificados digitales. Estos certificados digitales son emitidos por autoridades de certificación internas de confianza o por autoridades de certificación públicas. Los certificados internos son de confianza entre los dispositivos de red de la empresa, mientras que los certificados públicos son de confianza para los dispositivos de red de todo el mundo.

Estos certificados contienen la identidad de las entidades finales y un par de claves criptográficas, compuesto por una clave pública y una privada. La clave pública se distribuye junto con el certificado, mientras que las claves privadas son protegidas por las entidades. Un canal de red se cifra con este par de claves, lo que garantiza la seguridad de los datos comunicados entre estos dispositivos de red contra manipulaciones o alteraciones.

Sin embargo, a pesar de todas estas medidas de seguridad, siempre existen vulnerabilidades y brechas tecnológicas y de proceso que permiten a los hackers explotar y robar datos. En este blog, analizaremos algunos de los desafíos de SSL/TLS comunes a los exploits.

SSL frente a TLS

TLS (Seguridad de la Capa de Transporte) es el sucesor del protocolo SSL (Capa de Conexión Segura) para autenticación y cifrado. Actualmente, TLS 1.3 se considera el más seguro en comparación con sus predecesores y está definido en el RFC 8446. SSL y TLS versión 1.2 están obsoletos debido a vulnerabilidades y ataques a estos protocolos, como ROBOT, LogJam y WeakHD.

Estos ataques han explotado la forma en que se intercambian claves entre el cliente y el servidor durante la fase de negociación. Si bien se han mitigado con la introducción de TLS 1.2, aún existen vulnerabilidades a ataques de degradación como POODLE. Estas vulnerabilidades se han mitigado en TLS 1.3, que protege el protocolo de enlace durante la negociación cliente-servidor.

¿Qué ataques previene SSL/TLS?

SSL/TLS es el estándar de facto en seguridad en internet/en línea. Estos protocolos se utilizan para cifrar los datos que se envían a través de un medio no seguro (Internet) entre un equipo cliente y un servidor (un sitio web alojado en un ordenador). Esto previene muchos tipos de ataques. Incluso si un hacker intercepta datos cifrados, no puede leerlos ni utilizarlos para fines beneficiosos sin la clave privada utilizada para el proceso de descifrado.

Los hackers del mundo buscan constantemente maneras de romper los estándares de facto de internet, como SSL/TLS. La naturaleza altamente beneficiosa de la vulnerabilidad SSL/TLS obliga a los atacantes a esforzarse al máximo, lo que expone a las organizaciones al riesgo de infracciones y caídas imprevistas del sistema. Los siguientes ejemplos de ataques describen algunas de las técnicas de explotación de SSL/TLS más comunes, su impacto en las empresas y sugerencias para prevenirlos.

A continuación se explican los ataques SSL más comunes.

Ataque de renegociación de SSL

Los ataques de renegociación de SSL buscan explotar la vulnerabilidad descubierta en el procedimiento de renegociación de SSL, que permite a un atacante inyectar texto plano en las solicitudes de la víctima. Los atacantes que logran secuestrar una conexión HTTPS pueden añadir sus propias solicitudes a la conversación entre el cliente y el servidor. El atacante no puede descifrar la comunicación cliente-servidor, por lo que es diferente de un ataque típico de intermediario.

Para corregir la vulnerabilidad de renegociación en SSLv3, debe dejar de permitir la renegociación en el servidor. Se propuso una extensión de indicación de renegociación para TLS que corrige la vulnerabilidad y requiere que el cliente y el servidor incluyan y verifiquen información sobre protocolos de enlace previos en cualquier protocolo de renegociación.

Ataques de degradación de SSL/TLS

Un ataque de degradación de SSL/TLS engaña a un servidor web para que negocie conexiones con versiones anteriores de TLS que hace tiempo fueron abandonadas por ser inseguras. El atacante intenta entonces interceptar o alterar la información aprovechando vulnerabilidades en las versiones anteriores del protocolo o en los algoritmos criptográficos.

A continuación se presentan los ataques Downgrade más infames de la historia:

• Ataque de caniche

  En el ataque POODLE (Padding Oracle on Downgraded Legacy Encryption), se explota una vulnerabilidad (CVE-2014-3566) para interceptar comunicaciones cifradas con SSLv3. En este ataque, el atacante puede robar datos confidenciales como contraseñas, cookies de sesión, etc., para suplantar a un usuario legítimo. El reciente... Informe de vulnerabilidades de aplicaciones web de Acunetix 2020 El estudio muestra que hasta un 3.9 % de los servidores web siguen siendo vulnerables a POODLE, ya que aún utilizan SSLv3 para cifrar sus comunicaciones. Para solucionar el ataque POODLE en su servidor web, configúrelo para que admita TLS 1.2 o protocolos superiores.

• Ataque extraño

  El ataque FREAK (Factorización de Claves de Exportación RSA) funciona explotando los conjuntos de cifrado de exportación deliberadamente débiles, introducidos para cumplir con las agencias reguladoras de exportación de criptografía de EE. UU. FREAK engaña al servidor para que utilice un conjunto de cifrado de exportación con módulos RSA de 512 bits o menos. La intención inicial era permitir que los conjuntos de cifrado fueran descifrados únicamente por la Agencia de Seguridad Nacional (NSA); sin embargo, esta clave puede descifrarse fácilmente con la potencia informática actual. Para solucionar esto en su sitio web, debe deshabilitar la compatibilidad con cualquier conjunto de cifrado de exportación en el software que utilice SSL/TLS.

• Ataque de atasco

  El ataque Logjam, descubierto en mayo de 2015, permite a un atacante interceptar una conexión HTTPS degradando la conexión a grupos Diffie-Hellman de 512 bits de grado de exportación. Esto es similar al ataque FREAK, salvo que Logjam ataca el intercambio de claves Diffie-Hellman en lugar del intercambio de claves RSA, como en el caso del ataque Freak. Para solucionar esto, debe desactivar la compatibilidad con todos los conjuntos de cifrado Diffie-Hellman de grado de exportación en sus servidores. Esto no permitirá que un atacante degrade la conexión a la clave de exportación DH de 512 bits.

Ataques de ahogamiento

DROWN es una vulnerabilidad grave que afecta a servidores compatibles con conjuntos de protocolos SSL/TLS actuales, explotando su compatibilidad con protocolos obsoletos e inseguros. Esto permite a los atacantes aprovechar un ataque contra conexiones que utilizan protocolos actualizados que, de otro modo, serían seguros. DROWN explota una vulnerabilidad en los protocolos y la configuración del servidor, en lugar de un error de implementación específico.

DROWN permite a los atacantes romper el cifrado y leer o robar comunicaciones confidenciales. Para protegerse contra ataques DROWN, los propietarios de servidores deben asegurarse de que sus claves privadas no se utilicen en ningún software de servidor que permita conexiones SSLv2. Servidores web, SMTP, IMAP y POP son ejemplos de servidores compatibles con conexiones SSLv2.

Ataque de truncamiento

Un ataque de truncamiento de TLS bloquea las solicitudes de cierre de sesión de la víctima, de modo que el usuario permanece conectado a un servicio web sin saberlo. Al enviar la solicitud de cierre de sesión, el atacante inyecta un archivo sin cifrar. TCP Mensaje FIN para cerrar la conexión. El servidor no recibe la solicitud de cierre de sesión y desconoce la terminación anormal. Para evitarlo, SSLv3 y posteriores utilizan un protocolo de enlace de cierre, de modo que el destinatario sabe que el mensaje no ha finalizado hasta que se realiza esta operación.

Ataque Sweet32

El ataque Sweet32 descifra los cifrados de bloque de 64 bits utilizados en modo CBC mediante un ataque de cumpleaños. Para ejecutarlo, el atacante utiliza ataques de intermediario o inyecta JavaScript malicioso en una página web para capturar suficiente tráfico y lanzar un ataque de cumpleaños. Para protegerse contra el ataque Sweet32, evite el uso de cifrados de bloque de 64 bits antiguos y desactive los conjuntos de cifrado que utilizan DES/3DES.

MITM (Ataque del hombre en el medio)

Los ataques de intermediario (MITM) ocurren cuando un hacker logra obtener acceso no autorizado e interceptar la comunicación segura entre el emisor y el receptor. Existen diversas maneras en que un hacker puede realizar ataques MITM, como acceder a las claves privadas SSL/TLS que vinculan la autenticidad del certificado y a los puntos finales no seguros. En algunos casos, las claves privadas de una autoridad de certificación intermedia mal protegida pueden verse comprometidas, lo que tiene un impacto mucho mayor en todos los certificados emitidos por esta.

 En algunos casos, los ataques MITM también pueden ocurrir si el sistema de punto final es vulnerable y un atacante logra agregar un certificado falso de CA raíz de confianza a la lista de autoridades raíz de confianza. Muchas organizaciones no pueden gestionar los ciclos de vida de los certificados, lo que provoca que los certificados comprometidos o caducados no se revoquen ni renueven. En tal caso, existe una alta probabilidad de que un atacante continúe usando dichos certificados revocados para establecer confianza con los sitios comprometidos y espiar las comunicaciones en canales seguros.

Ataques de eliminación de SSL

In Eliminación de SSLUn atacante se configura como un enrutador y establece conexiones HTTPS con servidores de internet. Normalmente, el usuario final se conecta con el atacante a través de la conexión HTTPS no segura creyendo que se trata de un enrutador autenticado. El atacante puede entonces leer la comunicación, reenviar la solicitud al servidor y devolver la respuesta al usuario. El objetivo de estos ataques es leer datos como nombres de usuario, contraseñas y cualquier dato relacionado con pagos que el atacante pueda explotar posteriormente.

Ataques de secuestro de SSL

El secuestro de sesión, también conocido como secuestro de cookies, consiste en explotar una sesión válida mediante el acceso no autorizado a la información de la clave/ID de sesión. En este proceso, cuando el usuario intenta iniciar sesión en la aplicación web, el servidor instala una cookie remota temporal en el navegador del cliente para autenticar la sesión. Esto permite que el servidor remoto recuerde el estado de inicio de sesión del cliente. Para ejecutar el secuestro de sesión, un hacker necesita conocer la información del ID de sesión del cliente. Esto se puede obtener de diferentes maneras, como engañando al usuario para que haga clic en un enlace malicioso que contiene un ID de sesión preparado.

Mediante ambos métodos, el atacante puede tomar el control de la sesión objetivo usando el ID de sesión robado en su propia sesión de navegador. Finalmente, el servidor es engañado haciéndole creer que la conexión del atacante es la misma que la sesión original del usuario real. Para protegerse contra el secuestro de SSL, evite conectarse a URL no seguras (HTTP), tenga cuidado al conectarse a redes wifi públicas, utilice cookies seguras, utilice antimalware tanto en los clientes como en los servidores, y desconecte las sesiones inactivas.

Ataques de vulnerabilidad SSL/TLS

Al igual que con otros protocolos, los protocolos SSL/TLS también presentan sus propias fallas. A continuación, se presentan ataques que afectan a SSL/TLS 1.2 y versiones anteriores.

• Ataque de la BESTIA

  Los ataques BEAST (Browser Exploit Against SSL/TLS) afectan a SSL 3.0 y TLS 1.0 al explotar la vulnerabilidad (CVE-2011-3389). En este ataque, el atacante puede explotar una vulnerabilidad en la implementación de CBC (cipher block chaining) en TLS 1.0. Esto le permite descifrar los datos cifrados entre dos usuarios/sistemas inyectando los paquetes manipulados en flujos TLS mediante técnicas MITM.

  Estas técnicas permiten al atacante adivinar el vector de inicialización utilizado con el mensaje inyectado. Posteriormente, puede comparar los resultados con los del bloque que desea descifrar. Este ataque requiere acceso al navegador del equipo del cliente (víctima). Para ejecutarlo con éxito, el atacante podría usar otros vectores de ataque en las etapas iniciales. Para contrarrestar este ataque, utilice navegadores compatibles con TLS 1.1 o superior.

• Ataque del CRIMEN

  En los ataques CRIME (Filtración de información sobre la relación de compresión facilitada), se explota el mecanismo de los algoritmos de compresión, cubierto por la vulnerabilidad (CVE-2012-4929). Generalmente, el método de compresión se incluye en el mensaje de saludo del servidor en respuesta al mensaje de saludo del cliente para reducir el ancho de banda requerido para el intercambio de datos. Para facilitar este proceso, el servidor envía el método de compresión (DEFLATE es el más común) al cliente, mientras que envía el método de compresión "NULL" si no se requiere compresión.

  Una de las principales técnicas utilizadas por los algoritmos de compresión consiste en reemplazar las secuencias de bytes repetidas en el mensaje con un puntero a la primera instancia de dicha secuencia. Cuanto mayor sea la repetición de las secuencias, mayor será la tasa de compresión. Para solucionar este ataque, utilice su navegador para que sea compatible con el protocolo TLS más reciente (TLS 1.3).

• Ataque BREACH

  El ataque BREACH (Reconocimiento y Exfiltración del Navegador mediante la Compresión de Hipertexto) busca explotar el mecanismo de compresión utilizado por HTTP en lugar de TLS, como ocurre en los ataques CRIME. Esta vulnerabilidad figura en la base de datos NIST NVD como CVE-2013-3587. Puede explotarse incluso con la compresión TLS desactivada. Esto se logra redirigiendo el tráfico del navegador del cliente (víctima) a cualquier URL de terceros con TLS habilitado y monitorizando el tráfico entre el servidor y el cliente mediante técnicas de ataque MITM. Los servidores web que utilizan compresión HTTP reflejan las entradas/secretos del usuario en los cuerpos de respuesta HTTP y son propensos a ser vulnerables. Para controlar esta vulnerabilidad, puede desactivar la compresión a nivel HTTP, separar los secretos de las entradas del usuario y enmascarar los secretos.

• Ataque de sangrado del corazón

  Heartbleed fue un ataque crítico que descubrió la vulnerabilidad en la extensión Heartbeat de la biblioteca openssl y figura en la base de datos NIST NVD como CVE-2014-0160. La extensión Heartbeat se utiliza para mantener una conexión activa mientras ambas partes permanezcan conectadas.

  Comprendamos la funcionalidad Heartbleed en la biblioteca OpenSSL. El cliente envía el mensaje de latido con los datos y el tamaño al servidor. El servidor responde con los datos recibidos y el tamaño del cliente. La vulnerabilidad Heartbleed buscaba explotar que, si el cliente enviaba una longitud de datos falsa al servidor, este respondía con datos aleatorios de su memoria para cumplir con el requisito de longitud especificado por el cliente.

  Los datos aleatorios sin cifrar de la memoria del servidor pueden contener información crítica, como claves privadas, datos de tarjetas de crédito y otra información confidencial. Para corregir la vulnerabilidad Heartbleed, actualice a la última versión de la biblioteca openssl o recompile la versión instalada con el indicador "DOPENSSL_NO_HEARTBEATS".

¿Cómo protegerse de los ataques SSL?

Como se explicó en las secciones anteriores sobre algunos de los ataques SSL más comunes, es importante que las organizaciones revisen sus políticas de seguridad relacionadas con la protección SSL. Implementar SSL o TLS por sí solo no garantiza la seguridad de su infraestructura ni de su negocio. En cambio, debe gestionarse con las políticas, los procesos y los procedimientos adecuados para minimizar los riesgos. Además, existen diversas técnicas y herramientas disponibles en el mercado para proteger su empresa. Sin embargo, la selección de dichas herramientas o productos de seguridad depende de la naturaleza y los objetivos de seguridad de su empresa y debe decidirse tras un análisis exhaustivo de todos los aspectos de la seguridad.

Causas comunes de ataques en una red empresarial

Evite los certificados autofirmados

Con frecuencia, los sistemas se configuran para usar certificados autofirmados que no están firmados ni emitidos por una autoridad de certificación autorizada y de confianza. Estos certificados autofirmados no contienen las credenciales ni la información válidas del emisor. Además, podrían usar algoritmos débiles y obsoletos, como SHA1 o RSA, con una seguridad de clave débil. Estos servidores son fáciles de explotar para ataques, y un usuario malicioso podría alojar código malicioso en ellos. Los certificados autofirmados solo deben usarse para pruebas y nunca en sistemas de producción. Además, un servidor nunca debe confiar en certificados autofirmados.

Evite los certificados comodín

El uso de un certificado comodín en un servidor web público aumenta el riesgo de que una organización sea utilizada por hackers para alojar sitios web maliciosos en diversas campañas. Para solucionar este problema, las organizaciones deben evitar el uso de certificados comodín en sistemas de producción, especialmente en los públicos. En su lugar, utilicen certificados específicos para cada dominio y subdominio.

Evite las autoridades de certificación desconocidas

Mantener la confianza entre ambas partes depende de la fiabilidad de una CA. En la práctica, muchos clientes podrían confiar en CA desconocidas y poco populares en el mercado porque ofrecen una solución más económica. Esto podría resultar costoso a largo plazo, ya que los atacantes podrían comprometer dichas CA y suplantar la identidad de la CA legítima para robar gran cantidad de información crítica. Para protegerse, las organizaciones deben identificar todas las CA y certificados de fuentes desconocidas y no confiables, y descartarlos o reemplazarlos con CA y certificados de fuentes confiables.

Atacante que utiliza comunicación cifrada

En el mundo actual, los atacantes utilizan el cifrado como herramienta contra las organizaciones. Cada vez más ciberdelincuentes utilizan la comunicación cifrada SSL/TLS para implantar malware en redes y sistemas empresariales. A medida que esta tendencia cobra impulso, un informe de Gartner indica que el 50 % de los ataques de red dirigidos a empresas utilizarán cifrado.

Inspeccionar y descifrar este tipo de tráfico se convertirá en una tarea engorrosa para las empresas, especialmente cuando no tienen la capacidad de hacerlo. Para solucionar esto, las organizaciones deben aprovechar las soluciones de seguridad de red para imponer políticas web salientes al tráfico SSL. También deben distinguir cuidadosamente qué perfiles de tráfico cifrado deben considerarse para el descifrado, tanto entrante como saliente.

Evite utilizar certificados SSL/TLS caducados

Los certificados SSL/TLS caducados son la causa más común de interrupciones del servicio en todo el mundo. Microsoft sufrió una infame interrupción en su servicio Azure y tuvo que otorgar créditos de servicio a sus clientes, lo que les ocasionó enormes pérdidas. Los certificados caducados también hacen que las organizaciones sean vulnerables a ataques MITM (Man-in-the-Middle), ya que los atacantes pueden aprovecharse fácilmente de los certificados caducados.

Para proteger a su organización de esto, todos los certificados vencidos deben eliminarse inmediatamente del sistema y reemplazarse con certificados activos/válidos.

Evite los ataques de phishing

Los ataques de phishing buscan explotar la vulnerabilidad emocional humana para engañar a los usuarios y proporcionarles información confidencial o personal. Cuando los usuarios reciben un enlace en formato HTML para proporcionar información personal, deben tener en cuenta si el enlace es seguro o no. Un enlace seguro tiene "https" en la barra de direcciones, mientras que un enlace no seguro solo tiene "http".

Para protegerse de este tipo de ataques de phishing, SSL/TLS le avisa si la página HTML a la que intenta acceder no es segura. Además, si abandona una página segura y accede a otra no segura, SSL/TLS le avisa igualmente. Como práctica recomendada, los usuarios siempre deben usar URL/sitios web auténticos para evitar ataques de phishing.

Utilice SSL estricto

En SSL estricto, también conocido como SSL completo, se realiza una validación adicional de la identidad del servidor de origen para evitar el espionaje activo y la modificación de su tráfico en Internet. En la práctica, SSL/TLS cifra la comunicación entre el cliente y el sitio web/servidor. Sin embargo, los ataques MITM engañan a los usuarios/clientes para que interactúen con la versión falsa del sitio web/servidor legítimo sin que ellos lo sepan. Aquí es donde entra en juego el SSL estricto. SSL obliga al navegador del cliente a comprobar el certificado de autenticación de cualquier sitio web para asegurarse de que sea válido. Los ataques MITM no pueden alterar los certificados de autenticación, de ahí el propósito del SSL completo.

¿Cómo puede ayudar Encryption Consulting?

Encryption Consulting ofrece una solución especializada en gestión del ciclo de vida de los certificados. Administrador de CertSecureDesde el descubrimiento y el inventario hasta la emisión, implementación, renovación, revocación y generación de informes, CertSecure ofrece una solución integral. La generación inteligente de informes, las alertas, la automatización, la implementación automática en servidores y la inscripción de certificados añaden niveles de sofisticación, convirtiéndolo en un recurso versátil e inteligente.