Los riesgos de la inspección SSL

Recientemente , SuperFish y PrivDog han recibido cierta atención debido a los riesgos que ambos introdujeron a los clientes debido a defectos de implementación. Mirando más de cerca estos tipos de aplicaciones  he llegado a darme cuenta de algunas cosas.

En este blog, voy a explicar

  • Las capacidades de SSL y TLS no son bien entendidas por muchos.
  • La inspección SSL está mucho más extendida de lo que yo sospechaba.
  • Muchas aplicaciones que realizan inspecciones SSL tienen fallas que ponen a los usuarios en mayor riesgo.
  • Incluso si la inspección SSL se realizó al menos tan bien como en los navegadores, el riesgo que se presenta a los usuarios no es cero.

De Fondo

SSL y TLS se utilizan para dos propósitos principales:

  • Autenticación del servidor con el que se está comunicando un cliente.
  • Cifrado de datos enviados entre el cliente y el servidor.

Algunas personas pueden asumir que SSL o TLS intentan alcanzar las metas mencionadas de manera puntual. Esta es una suposición inválida. SSL y TLS prácticamente pueden lograr la autenticación y encriptación seguras sólo de forma punto-a-punto, no de extremo a extremo. ¿Cuál es la diferencia? Veamos primero el caso en el que la comunicación punto a punto es también de extremo a extremo:

El cliente tiene la capacidad de verificar comunicaciones seguras sólo con el siguiente punto con el que se está comunicando. En el caso anterior, el cliente establece una conexión SSL o TLS directamente con el sistema de destino. El software cliente verifica que el sistema al que está conectado ha sido verificado por uno de los potencialmente cientos de certificados de la raíz CA que pueden estar presentes en el sistema. Si el sistema al que se está comunicando es lo que el usuario espera es otra historia.

Cuando un usuario carga un sitio web en su navegador que debe estar protegido con HTTPS (y posteriormente SSL o TLS), ese navegador solo confirma que el sistema con el que se está comunicando proporciona un certificado emitido por uno de los servidores raíz CA en las que confía el navegador. Confía implícitamente en que cada entidad emisora ​​de certificados raíz ha realizado la debida diligencia para verificar la identidad del servidor al que se está conectando. A veces, las CA de raíz se engañan . También confía en que cada raíz CA ha tomado las medidas adecuadas para proteger sus propios sistemas. A veces, las raíz CA se ponen en peligro . Vea el blog de Moxie Marlinspike, SSL y el futuro de la autenticidad , para más detalles sobre estos problemas .

Considere el caso de las recientes vulnerabilidades de SuperFish y PrivDog. Esas aplicaciones instalan un nuevo certificado de CA raíz de confianza. Tenga en cuenta el uso específico del término “de confianza” aquí. No estamos hablando de nada a lo largo de la línea de confianza utilizada por las aplicaciones PGP y GPG, donde el usuario indica explícitamente un nivel de confianza con claves individuales. Un “certificado de raíz CA de confianza” es simplemente uno que puede ser utilizado por el software del cliente sin generar advertencias. No tiene nada que ver con la “confianza” que es la confianza que un usuario tiene en algo.

Por suerte para el usuario final, tanto SuperFish como PrivDog instalan certificados de raíz CA de confianza que tienen indicaciones claras de que son de SuperFish y Privdog, respectivamente. Sin embargo, no hay absolutamente nada que impida que una aplicación instale un certificado con un nombre más engañoso, como “VeriSign”.

Ahora, considere el caso donde un usuario con PrivDog o Superfish instalado está visitando un sitio a través de HTTPS porque está proporcionando información confidencial, como un nombre de usuario y una contraseña. Si su navegador no se queja del certificado, en el mejor de los casos eso significa que cualquier sistema con el que está hablando ha sido emitido por una de las raíces CA de confianza, incluyendo SuperFish o Privdog.

Si alguien quiere verificar que un certificado es emitido por una autoridad de certificado “real”, por ejemplo, comprobando la huella digital del emisor, los pasos necesarios para hacerlo pueden variar de navegador a navegador. Algunos navegadores, como Microsoft Internet Explorer, ni siquiera permiten ver un certificado hasta después de haberlo aceptado, lo que puede dificultar que incluso un profesional de seguridad determine si está conectado a la máquina que él/ella piensa .

El software de nivel de host como Superfish o Privdog es sólo el comienzo, sin embargo. Como resultado, hay un montón de aplicaciones a nivel de red, dispositivos y dispositivos que hacen la inspección SSL . Secure gateways web, firewalls, productos de prevención de pérdida de datos (DLP), y otras aplicaciones parecen haber saltado en el carro de inspección de SSL. Claro, puede haber razones por las que un administrador de red quiera buscar en el tráfico que debería estar protegido por SSL o TLS, pero lo que la gente puede no darse cuenta son los impactos de seguridad de desplegar software que no hace la inspección SSL al menos tan bien como en los navegadores. Considere el siguiente diagrama:

En el escenario anterior, el cliente sólo puede verificar que se está comunicando con el software de inspección SSL. El cliente no tiene conocimiento de qué técnica utiliza el software de inspección SSL para validar certificados SSL. Y quizás lo más importante, si hay puntos adicionales entre el software de inspección de SSL y el sistema de destino es imposible que el cliente lo determine. ¿Existe un atacante entre el software de inspección SSL y el servidor de destino? El cliente no tiene forma de saberlo. Debido a esta falta de transparencia, el cliente debe asumir que el software de inspección SSL está haciendo todo perfectamente. Desafortunadamente, el software de inspección SSL no lo hace todo perfectamente.

Errores comunes de SSL

En mi análisis del software que realiza la inspección SSL, he observado que el software de inspección SSL comete una variedad de errores:

1) Validación incompleta de la validez del certificado ascendente
Algún software de inspección de SSL no logra validar los certificados de los sistemas a los que se conecta. En algunos casos, el software puede intentar realizar alguna validación del certificado, pero la validación puede ser insuficiente.

Riesgos : Los clientes no pueden saber si están conectados a un sitio legítimo o no.

2) No transmitir la validación del certificado de arriba hacia arriba al cliente
En algunos casos, el software de inspección SSL realiza la validación de los certificados ascendentes, pero no transmite los resultados de la validación al cliente.

Riesgos : Los clientes no pueden saber si están conectados a un sitio legítimo o no.

3) Sobrecarga del campo Canonical Name (CN) del certificado
Algún software de inspección de SSL intenta transmitir la validez del certificado ascendente al cliente a través del campo CN del certificado. Por ejemplo, Komodia SSL Digestor cambia el CN ​​para comenzar con “verify_fail” si el certificado proporcionado por el servidor es inválido por cualquier razón. Hay una serie de problemas con esta técnica. El error más obvio es que el error real transmitido al usuario por lo general no tiene nada que ver con el fracaso.

Riesgos : Es posible que los usuarios de los sistemas cliente no sepan por qué falló la validación del certificado o incluso si falló. Un atacante puede especificar un campo Nombre alternativo de la asignatura para especificar cualquier dominio para el que se especifique que es válido, lo que da como resultado un navegador que no muestra una advertencia de certificado.

4) Uso de la capa de aplicación para transmitir la validez del certificado
Para transmitir la validez del certificado al cliente, algunos inspectores SSL proporcionan contenido web (por ejemplo, HTML) al cliente, describiendo lo que está mal con el certificado. Los mecanismos normales a través de los cuales el software de cliente determina y muestra la validez del certificado aún pueden indicar que el certificado está bien.

Riesgos : No todo lo que se accede a los datos mediante HTTPS es un ser humano que utiliza un navegador web. Por ejemplo, el cliente puede ser una aplicación que se comunica con un servidor que utiliza datos JSON. Esta falla también causa un uso inconsistente de los indicadores de validez SSL (por ejemplo, “¿Dónde puedo buscar el candado de nuevo?”).

5) Uso de una cabecera HTTP de User-Agent para determinar cuándo validar un certificado
Algún software decidirá selectivamente cuándo validar los certificados ascendentes basados ​​en el encabezado HTTP User-Agent proporcionado por el cliente. Es probable que esta técnica se utilice junto con la técnica descrita anteriormente, en la que se transmite la validez del certificado en la capa de aplicación.

Riesgos: No todos los clientes web pueden recibir validación de certificados. Varias versiones de navegador web y software que no sea navegador pueden estar exentos de validación.

6) Comunicación antes de la advertencia
Al detectar un error de certificado, algunas aplicaciones de inspección SSL enviarán la solicitud del cliente al servidor antes de presentar una advertencia al usuario.

Riesgos : Un atacante todavía puede ver o modificar datos sensibles.

7) Certificado de igual raíz CA 
Algunas aplicaciones de inspección SSL utilizan e instalan el mismo certificado de raiz CA de confianza para cada instalación de la aplicación.

Riesgos : Un atacante puede extraer la clave privada del software y firmar todos los sitios visitados con el certificado de raíz CA universalmente confiable.

Considere el caso en el que una aplicación de inspección SSL funciona impecablemente. Es decir, no tiene ninguno de los siete defectos anteriores, o defectos similares a ellos. Valida la identidad del servidor ascendente basado en su propio almacén de certificados de raíz CA de confianza. Sin embargo, el cliente no tiene visibilidad en qué raíz CA  confía el software de inspección SSL, en particular si se trata de un dispositivo independiente en la red. El uso del software de inspección SSL reduce o impide completamente que los clientes validen con éxito la identidad de los servidores con los que se están comunicando.

Dada la arquitectura de SSL y TLS, los usuarios la tienen bastante difícil para tomar una decisión de seguridad basada en la información que se les proporciona. Una vez que el concepto de la inspección SSL es lanzado en la mezcla, sólo hace que la decisión más difícil.

Software Potencialmente Afectado

Al realizar una búsqueda en la web para ” inspección ssl “, pude construir una lista de aplicaciones que podrían verse afectadas por varias de las vulnerabilidades descritas anteriormente. El hecho de que un producto aparezca en la lista no significa necesariamente que contenga alguna de las siete vulnerabilidades anteriores. La lista de aplicaciones posiblemente afectadas incluye lo siguiente:

A10 vThunder
Arbor Networks Pravail
Filtro web Baracuda
Filtro web de la escuela BASCOM
Bloxx Filtro Web
Blue Coat SSL Visibility Appliance
Cisco ScanCenter
Citrix NetScaler AppFirewall
Clearswift SECURE Web Gateway
ContentKeeper
Suite de administración de Internet Cymphonix
Dell SonicWALL
EdgeWave iPrism Web Security
ESET Smart Security
F5 BIG-IP
Fortinet FortiGate
Fidelis Security XPS
Finjan Vital Security (pdf)
GFI WebMonitor
GigaMon GigaSmart
Protección de red de seguridad de IBM
Iboss Web Security
Imperva Incapsula
ISHERIFF Seguridad en la nube
Dispositivos IDP Juniper
Kaspersky Anti-Virus
Decodificador SSL de Komodia
M86 Secure Web Gateway (pdf)
McAfee Web Gateway y Firewall Enterprise (pdf)
Microsoft Forefront TMG
Netnanny
NextGig Netronome
Optenet WebFilter (pdf)
Palo Alto PAN-OS
Protección de Internet en la nube de Panda
PrivDog
Radware AppXcel
Gateway de Seguridad Web eSafe de SafeNet
Sangfor IAM (pdf)
Smoothwall Secure Web Gateway
Sophos Cyberoam
Dispositivo SSL de Sourcefire
Calamar
Symantec Web Gateway
Tecnologías Thomason Next Gen IPS
Trend Micro Deep Security (pdf)
Trustwave WebMarshal , Secure Web Gateway
Untangle NG Firewall
Venafi TrustAuthority
Supervisión de VSS vInspector (pdf)
Proxy de WatchGuard HTTPS
Wavecrest CyBlock
WebSense Content Gateway
WebTitan
Qbik WinGate
Inspección SSL de WolfSSL
Zscaler
Firewall de ZyXel
Una vez más, sólo porque un producto esté en la lista, no significa que es necesariamente vulnerable.

Conclusión

SSL y TLS no proporcionan el nivel de seguridad de extremo a extremo que los usuarios pueden esperar. Incluso en ausencia de la inspección SSL, hay problemas con la forma en que los navegadores transmiten información SSL a los usuarios . El hecho de que la ” inspección SSL ” es una frase que existe, debe ser una bandera roja de que lo que usted cree que SSL está haciendo por usted está fundamentalmente roto. Complementando el problema están los errores que los autores del software de inspección SSL están haciendo.

Es posible que los administradores de sistemas deseen volver a evaluar si desean implementar capacidades de inspección SSL en su entorno.

Si tiene conocimiento de productos que realizan inspecciones SSL pero no se enumeran anteriormente, o si tiene información sobre qué productos contienen las vulnerabilidades, envíenos sus comentarios.

US-CERT ha publicado la Alerta Técnica TA17-075A sobre este tema. En el sitio badssl.com  hace que sea más fácil probar los efectos de la interceptación HTTPS, y también hace que sea posible probar los comportamientos HTTPS mucho más profundamente . Para probar su propio entorno de inspección HTTPS:

Visite www.badssl.com usando un navegador que tiene conexión directa (no interceptada) a Internet.

Visite cada uno de los sitios de prueba de color rojo que se enumeran para confirmar el comportamiento de su navegador. En muchos casos, un navegador moderno se negará a mostrar los sitios vinculados a rojo.

Complete las mismas pruebas en la misma versión del navegador, pero en una configuración de red donde se está interceptando el tráfico HTTPS.
Comparar cómo se comporta el navegador en una configuración en la que se realiza la interceptación HTTPS en contra del comportamiento en el que el navegador tiene una conexión a Internet no interceptada. Si un navegador interceptado permite la conectividad a cualquiera de las pruebas que están bloqueadas en modo no interceptado, esto es una indicación de una debilidad introducida por la interceptación HTTPS.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.