Infraestructura de seguridad y HTTPS

https
La idea de escribir este post nace de haber conversado con diversos fabricantes de herramientas de prevención ante ataques informáticos principalmente perimetrales y a nivel de mensajes de aplicación que, después de recibir cierto feedback de su parte, me hace pensar que las implementaciones de la infraestructura no se están haciendo adecuadamente con este tipo de tecnologías.

En la actualidad existe infraestructura de protección que, con ciertas configuraciones, te permite protegerte ante algunos ataques enfocados en aplicaciones web: XSS, CSRF, Injection, session manipulation, DoS, etc. Además existe infraestructura que permite analizar la información, a nivel de aplicación, que fluye por las redes para detectar anomalías. En general tenemos una gran variedad de equipos e infraestructura tanto física como lógica que se basa en el análisis del tráfico de las redes para realizar su trabajo y proteger los activos, por ejemplo: Next Generation Firewalls, Web Application Firewalls, UTMs, Advanced Threat Protection, entre otros.

Con la infraestructura anterior se está teniendo un problema que está evitando que las herramientas hagan su labor de protección de manera adecuada y este problema es el cifrado de los canales de comunicación que evita que se pueda visualizar la información que fluye por el canal cifrado. Esto puede ser tanto bueno, cuando se trata de proteger la información sensible que viaja por canales no seguros, como malo, cuando un atacante envía algún script malicioso o payload por ese mismo canal cifrado.

Como sabemos existen protocolos que permiten crear túneles seguros para enviar mensajes aplicativos. Uno de los principales es TLS (que utilizado en conjunto con HTTP, nos da HTTPS). Todas las herramientas previamente mencionadas, o la gran mayoría de ellas, actualmente cuentan con soporte para analizar el tráfico HTTPS con el simple hecho de “instalarle” los certificados necesarios así como su llave privada correspondiente. A fin de cuenta, ¿cómo voy a analizar tráfico HTTPS si no le doy los certificados y la llave de los dominios a inspeccionar a las herramientas?

Los fabricantes recomiendan instalarle los certificados de los dominios o IPs donde se desee analizar tráfico protegido por TLS sin embargo lo que pocos mencionan, y se encuentran con ello hasta la fase de implementación, es que se deben deshabilitar los algoritmos denominados efímeros en la negociación del subprotocolo handshake, del protocolo TLS, estos usualmente son: Diffie-Hellman (DH), Diffie-Hellman Ephemeral (DHE) y Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Y… en qué nos afecta esto?

Estos algoritmos criptográficos permiten un mayor nivel de seguridad con un menor poder computacional (comparado por ejemplo con RSA). Las herramientas tecnológicas que manejan contenido web como servidores web, servidores aplicativos, balanceadores de carga, etc. cuentan con estos algoritmos habilitados de forma predeterminada precisamente porque la tendencia es utilizarlos cada vez más en las redes que utilicen TLS. En términos prácticos son de los mejores algoritmos que existen para la protección de ese tipo de canales, sin embargo, debido a la característica de Diffie-Hellman, no permite el descifrado de información incluso contando con el certificado y su llave privada correspondiente y por ende las mismas herramientas de protección no pueden descifrarlo ni validar la presencia de un ataque, inyección, payload o cualquier amenaza que fluye dentro de ese canal cifrado.

Esto da como resultado alguno de estos dos escenarios:

  • Si no se deshabilitan dichos algoritmos no se podrán analizar los mensajes dentro de los túneles TLS y como consecuencia tendrán que las herramientas de protección no les servirán bajo esos escenarios.
  • Si se deshabilitan los algoritmos (y se instalan los certificados y llaves privadas correspondientes) permitirán a las herramientas hacer su trabajo de protección pero las comunicaciones por TLS estarán expuestas a otros problemas de seguridad como el poder descrifrar, de forma externa, dichos paquetes incluso tiempo después de haber sido capturados de forma cifrada, o que estarían frenando la adopción de estos algoritmos más robustos y mejor diseñados para esas comunicaciones.

Debido a esta situación, la mayor parte de los ataques en Internet, a nivel aplicación, hoy día son efectuados a través de HTTPS, ya que la industria, atacantes, hackers, sabemos que si se cuenta con una mala configuración, arquitectura de seguridad defectuosa o nula, dichos ataques llegarán directamente a las aplicaciones evadiendo así cualquier control de seguridad que pudiera detenerlos en capas más externas.

Por ahora existen muy pocas soluciones a este problema. La más popular quizá es forzar a que el control de seguridad, donde se instalaron los certificados, también negocie las sesiones TLS directamente con los endpoints que se intenten conectar. Con esto, logramos que el equipo de seguridad sea quien forme el tunel TLS por completo y pueda analizar la totalidad de los mensajes entre el cliente y el equipo de seguridad. Desafortunadamente no toda la infraestructura de seguridad, para estos entornos, cuenta con la habilidad de poder ser configurada de esta forma.