Evitando la visibilidad de Netflow en el tráfico SSL

4

En un protocolo de enlace SSL, el nombre de host está visible la mayor parte del tiempo ya que es necesario para validar el certificado a través de HTTP. Netflow puede así recoger el nombre común del intercambio de certificados, revelando el nombre de host .

¿Sería mejor que un servidor de C & C usara un certificado autofirmado con IP como nombre común (desde los proveedores legítimos no permiten eso ) con una IP estática y sin nombre de dominio, de modo que cuando Netflow consulta, solo ve la dirección IP ? Dado que las IP de C & C cambian con frecuencia, sería difícil para cualquiera Investigaciones para distinguir cualquier metadatos de esto. Además, los certificados de SSL y los nombres de dominio dejan rastros en whois, y podrían ser migajas para la investigación. El certificado se realiza entre servidores sin interacción del usuario, y la seguridad no es clave, por lo que la firma automática es aceptable.

    
pregunta George 22.01.2018 - 15:30
fuente

1 respuesta

3

Si bien un cliente de C & C ocultaría su objetivo real al no usar SNI, sería sospechoso, especialmente porque no usa SNI con HTTPS mientras que todos los demás lo hacen. Podría ser mejor entonces afirmar que se conecta a un objetivo inocente configurando la extensión SNI en consecuencia, pero en realidad se conecta al servidor C & C. Esto solo necesita un poco de manipulación en la pila TLS y no es mucho más difícil de hacer para un atacante experimentado.

Pero como el servidor envía el certificado del servidor de forma clara con un protocolo de enlace TLS completo, aún se puede verificar si el certificado devuelto por el servidor coincide con el nombre dado en SNI y también es emitido por una CA de confianza. Para evitar esto, el cliente de C & C podría intentar simular una conexión reanudada cada vez. Para hacer esto, se necesita más manipulación con la pila TLS, por lo que podría ser más sencillo utilizar un protocolo que se parezca al TLS para engañar a la detección, pero no es un TLS real. Creo que esto es lo que Skype ha hecho al menos en el pasado para evitar los cortafuegos y quizás todavía lo haga hoy.

Otro enfoque sería utilizar franqueamiento de dominios , es decir, (mal) usar un sistema que sirve múltiples dominios en el La misma dirección IP, sirve el certificado basado en la extensión SNI en el protocolo de enlace de TLS, pero sirve el contenido real basado en el encabezado del Host que está cifrado dentro de TLS y, por lo tanto, no es accesible cuando se realiza una inspección pasiva. En este caso, parece que el cliente se conecta a un sitio inocente mientras que en realidad se conecta a su maestro C & C.

Si el atacante controla partes relevantes del servidor (por ejemplo, porque fue secuestrado) también podría (continuar) sirviendo un sitio casi inocente y luego usar solo una ruta específica para la comunicación de C & C. Dado que la ruta de la URL no es visible cuando se realiza una inspección pasiva de HTTPS, probablemente parece que el cliente solo está accediendo a datos inocentes en este sitio.

Aún así, SNI no es lo único que se puede detectar con un análisis pasivo. El apretón de manos del cliente también muestra qué tipo de cifrados soporta y la preferencia y una variedad de extensiones TLS y su orden. También un patrón significativo del tráfico, como el tamaño de la solicitud y la respuesta o el tiempo, todavía son visibles, incluso si el tráfico está cifrado. Esto también se puede usar a menudo para tomar huellas digitales del cliente y, por lo tanto, distinguir el navegador típico de otros clientes y quizás los conocidos clientes de C & Cisco ha hecho investigación interesante en esta área.

    
respondido por el Steffen Ullrich 22.01.2018 - 16:43
fuente

Lea otras preguntas en las etiquetas