¿El "escaneo de conexión segura" de Kaspersky Antivirus está roto como Superfish?

15

Últimamente he leído mucho sobre Superfish (y software publicitario similar) y básicamente entiendo la vulnerabilidad a los ataques MITM. Pero en realidad me pregunto si el " análisis de conexión segura " de Kaspersky Antivirus está tan roto como el ejemplo de Superfish.

Me refiero a que Kaspersky instala un certificado raíz en mi computadora y "man in the middles" todas las conexiones para buscar malware. A mi entender, esto no es mejor que el desastre de Superfish ... ¿qué hace a Kaspersky más seguro?

    
pregunta mrclschstr 23.02.2015 - 21:29
fuente

1 respuesta

12

Con suerte, alguien hará las pruebas y dará una respuesta definitiva para Kaspersky para usted. Mientras tanto, aquí hay una respuesta para el caso general:

Depende.

¿La ejecución de un proxy SSL contra usted mismo debilita su postura de seguridad? Ciertamente. ¿Algún producto dado debilitará su postura de seguridad tan mala como Superfish? Eso depende mucho de la implementación, y también está sujeto a las amenazas contra el producto en sí.

Superfish falló en dos puntos críticos.

  1. Usó una contraseña débil para proteger una clave privada que no era única para cada sistema. Esto dio como resultado que la clave sea fácilmente rompible y divulgada públicamente para que cualquier persona pueda pretender ser su proxy Superfish autorizado.

  2. No se pudieron validar correctamente ciertas condiciones en los certificados SSL, lo que permitió que el proxy de Superfish aceptara certificados de otro modo no válidos y presentara el sitio web al usuario final como si fuera legítimo.

Si bien la primera parte es una ruptura importante, es el segundo bit que posiblemente sea el defecto más crítico. Sin la segunda falla, los usuarios todavía estarían relativamente bien protegidos mientras la clave permanezca secreta. (El principio de Kerckhoffs en acción). Sin embargo, dada la segunda falla, un atacante ni siquiera necesitaría la clave para lanzar un ataque Man-in-the-Middle convincente entre un usuario de Superfish y un sitio web de otro modo seguro.

Teniendo esto en cuenta, hay un par de contramedidas simples que pueden proteger en gran medida a los usuarios.

  1. Genere claves raíz únicas para cada instalación, protéjalas con contraseñas seguras y únicas, y no distribuya las claves más allá del host en el que reside el proxy. Esto evita que la divulgación de la clave de un sistema tenga un impacto sustancial en la seguridad de cualquier otro.

  2. Valide los certificados SSL correctamente y proporcione las notificaciones apropiadas al usuario cuando algo esté mal. Sin esto, la clave no importa mucho: un atacante solo necesita convencer al proxy de que su sitio es legítimo, al explotar una falla en el proceso de validación, y el proxy presentará el sitio como tal al usuario.

Consiga estas cosas correctas, y ya está listo para irse, ¿verdad? Bueno, no del todo.

Vea, ahora tenemos un problema con la presentación del certificado al usuario. Debido a que el proxy tiene que interceptar el tráfico y volver a codificarlo con sus propias credenciales, el usuario nunca ve las credenciales originales del sitio. Cada sitio parecerá tener un certificado emitido por el proxy, con marcas de fecha y hora según el momento en que el proxy generó el certificado MitM. Esto elimina completamente la capacidad del usuario para decidir qué CA o rutas de confianza son creíbles, o para reconocer cambios en el certificado a lo largo del tiempo. También evita la corroboración del certificado con otras entidades externas de confianza.

Tomemos el caso de DigiNotar, donde un atacante pudo usar una CA raíz de confianza para generar certificados falsos para los servicios de Google. Sin un proxy SSL en su lugar, se puede alertar al usuario de actividades sospechosas por uno o más de varios medios.

  • Un complemento del navegador u otra utilidad podría comparar el certificado con otros certificados vistos anteriormente en el mismo sitio por el mismo usuario y alertar al usuario sobre cambios inesperados. (p. ej., CA diferente a la anterior, nuevo certificado emitido fuera de sincronía con el vencimiento del certificado anterior, etc.)
  • Un complemento del navegador u otra utilidad podría comparar el certificado con los certificados reportados en ese sitio, por una comunidad en línea u otra autoridad confiable, y alertar al usuario sobre discrepancias inesperadas (por ejemplo: el 98% de los usuarios en su región reportan haber visto una imagen diferente). certificado que el que está viendo).
  • Un usuario diligente puede verificar el certificado con frecuencia y notar cambios inusuales.

Con un proxy, todas estas opciones ya no están disponibles para el usuario final. El propio proxy puede configurarse para observar y alertar sobre estos problemas (al igual que algunos complementos del navegador), pero en última instancia, el usuario final aún pierde la capacidad de verlo por sí mismo.

    
respondido por el Iszi 24.02.2015 - 14:39
fuente

Lea otras preguntas en las etiquetas