Se publicó recientemente alguna investigación que mostró que la función SmartScreen de Windows 8 envía ciertos detalles sobre todas las aplicaciones. que instales en Microsoft.
Ignorando las violaciones obvias de la privacidad, ¿qué otros problemas de seguridad podría causar esto? El artículo aborda algunos problemas de SSL, pero dice que no se ha verificado que sean vulnerables.
En realidad, el artículo no dice que el cliente SmartScreen use SSLv2; solo dice que el servidor a los contactos de SmartScreen estaría encantado de aceptar conexiones entrantes utilizando el protocolo SSLv2. Sería sorprendente si SmartScreen utilizara SSLv2: lo más plausible es que Microsoft reutilizara su propio código existente para un cliente SSL, y ese código hace SSLv3 + de forma predeterminada. El uso de SSLv2 implicaría un esfuerzo adicional sin ganancia.
Además, la mayoría de lo que se dice sobre la seguridad de SSLv2 (en este artículo o en cualquier otro lugar) está cubierto por una capa pesada de FUD . SSLv2 tiene problemas , suficientes para justificar que no se use (especialmente porque SSLv3 y TLS están disponibles), pero no tanto como lo que generalmente se sugiere. Consulte, por ejemplo, esta página ; se afirma que:
- integridad del mensaje comprometida. La autenticación de mensajes SSLv2 utiliza la función MD5 y es insegura.
- ataque del hombre en el medio. No hay protección del apretón de manos en SSLv2, lo que permite un ataque de hombre en el medio.
- ataque de truncamiento. SSLv2 se basa en TCP FIN para cerrar la sesión, por lo que el atacante puede falsificar un TCP FIN y el interlocutor no puede saber si fue un fin legítimo de los datos o no.
- Integridad de mensaje débil para cifrados de exportación. Las claves criptográficas en SSLv2 se usan tanto para la autenticación de mensajes como para el cifrado, por lo que si se negocian esquemas de encriptación débiles (por ejemplo, claves de 40 bits), el código de autenticación de mensajes usa la misma clave débil, que no es necesaria.
El primer punto es francamente FUD. Es una reacción instintiva: "¡MD5? ¡MALO MALO MALO!". No está comprobado. No estoy no diciendo que MD5 es sólido como una roca; pero afirmo que la verificación de integridad en SSLv2 no es tan fácil de superar.
El segundo punto es, en el mejor de los casos, confuso y engañoso. Los "ataques de intermediario" a los que se alude son los siguientes: en SSL (v2, v3 + ...), tanto el cliente como el servidor pueden admitir varios conjuntos de cifrado; el cliente envía la lista de suites que admite y el servidor elige una. Con SSLv2, un atacante que está en posición de hacer un MitM puede alterar la lista enviada por el cliente, para obligar al cliente y al servidor a usar un conjunto de cifrado específico (dentro del conjunto de conjuntos que ambos admiten , por supuesto). La alteración no se detecta más adelante (mientras que, en SSLv3 +, se detectaría al final del protocolo de enlace). Luego, según el razonamiento, SSLv2 es débil porque el atacante puede obligar al cliente y al servidor a usar un "conjunto de cifrado débil" (por ejemplo, uno con claves de 40 bits). ¿Pero puede? De hecho, el atacante puede forzar el uso de una suite de cifrado que tanto el cliente como el servidor ya estaban listos para aceptar , y esa es la debilidad. Lo que rompe el ataque es la actualización optimista a conjuntos de cifrado más fuertes cuando están disponibles; pero la debilidad real es cuando el cliente y los servidores aceptan usar claves de 40 bits.
El cuarto punto es más de lo mismo: dice que si una tecla es débil y se usa para dos usos, al romperla se puede atacar a los dos. Pero la verdadera debilidad aquí es usar una tecla débil.
Sólo el tercer punto es realmente cierto: un atacante puede forzar el cierre de una conexión, y las máquinas no pueden saber si el interlocutor fue el propósito del cierre. Este es un problema grave con HTTP / 1.0 sin el atributo Content-Length pero no con otros protocolos, incluido HTTP como se usa en la actualidad.
Resumen: SSLv2 está "roto", pero no tanto como se rumorea. No, un atacante no puede descifrar instantáneamente una conexión SSLv2. Y personalmente, considero altamente improbable que el cliente SmartScreen use SSLv2; tendría demasiado poco sentido.
(Ninguno de los anteriores dice nada acerca de los problemas de privacidad con SmartScreen).
Suponga que la conexión SSL es segura Si asume que la conexión SSL es segura y el servidor de Microsoft es bueno, no mucho.
Pero si asumimos que el dispositivo ha sido pirateado o si una aplicación obtiene permisos adicionales, entonces un atacante podría hacer cosas malas. Reemplace la clave pública de Microsoft o escuche a escondidas en el punto final. Podría haber muchas cosas malas ... pero eso ocurre después de que el usuario ya es de su propiedad ...
Si esto es solo una conexión SSL falsa, no puedo pensar en ningún nuevo vector de ataque que se abra ... solo un nuevo activo que podría interesar a los hackers.
Supongamos que la conexión SSL no es segura los atacantes MITM podrían obtener la información que Microsoft le pasara a Microsoft. Posiblemente no permita a los usuarios descargar nuevas aplicaciones, aprobar la descarga e instalación de aplicaciones malintencionadas o usar la información para lanzar ataques dirigidos contra el usuario.
Creo que personalmente necesito ver un documento técnico o algo sobre qué hace la pantalla inteligente y exactamente qué información envía antes de que pueda decir o asumir más ...
Al analizarlo, hay dos preocupaciones generales que estaría investigando: 1.) Qué datos se están enviando y 2.) Cómo se están enviando.
El artículo describe el método de transmisión: SSLv2 a un servidor de Microsoft en Redmond. Seguridad bastante básica, pero como SSLv2 es inseguro, supongamos que un atacante puede romper esto.
Las conexiones SSLv2 inseguras no son nada nuevo, ni los ataques y las vulnerabilidades que podríamos lanzar sobre ellas, por lo que la siguiente pregunta es ¿cómo difiere esto de cualquier otra conexión SSLv2 insegura de su sistema? Eso nos lleva a la pregunta 1: qué datos se envían. En este caso, sabemos que estamos enviando un inventario ordenado de todas las aplicaciones en un sistema.
La respuesta obvia es que para un atacante, esto es extremadamente útil. Poniéndolo todo junto, tengo una conexión SSL rota con un sistema cuyo software se conoce íntimamente. A partir de ahí, es solo una cuestión de bajar la lista de exploits conocidos para cada uno de esos programas (o escribir nuevos).
En mi opinión, todo esto simplemente agrega otro vector de ataque con el maravilloso beneficio adicional de poder adquirir rápidamente una huella digital preempaquetada de la carga de software de un sistema. Supongo que depende de usted si cree que el riesgo merece la pena porque Microsoft "evalúa su software por usted". Por razones de privacidad y seguridad, lo desactivaría, pero si no te preocupa la privacidad, al menos espero hasta que obtengan un método de transmisión más seguro.