TAGS
Hoy en día, Laura Poitras y Jake Appelbaum habló en la conferencia 31C3 y en colaboración con Der Spiegel publicó un interesante artículo sobre la NSA.
El; sumario "TL DR" de lo que sigue a continuación es: Si configura la VPN IPSec basada adecuadamente, no se ven afectados. Siempre use Confidencialidad directa perfecta ( "PFS = yes" cosa que está por defecto en libreswan IPsec) y evitar PreSharedKeys (authby = secreto que no es el predeterminado en libreswan IPsec). Si realmente necesita usar PSK, utilizar un secreto compartido fuerte que no puede ser obligado bruta. La NSA tiene su propia versión de que se ejecuta en millones de dólares el valor de CPUs. Además, la NSA se cuela en el router para robar sus PSK de modo que puedan descifrar todo el tráfico.
Actualización 1: desde los medios de comunicación-35513.pdf ( "TURMOIL / APEX / APEX Alto Nivel Descripción Documento"):
CES requiere por lo general los paquetes de ambos lados de un intercambio de IKE y el conocimiento de la clave asociada pre-compartida (PSK) con el fin de tener la oportunidad de recuperar una clave para el cifrado correspondiente (ESP). Un objetivo importante de APEX es acceder a las dos caras de los intercambios de claves de tráfico de interés "
Actualización 2: Para detener la NSA HappyDance, acabo de libreswan IPsec para advertir sobre PSK débiles con un mensaje de notificación al administrador de sistemas que a partir del 1 de julio de 2015 libreswan rechazará aquellas PSK débiles. Para determinar la fuerza de la PSK, utilicé el valor. Si el PSK tiene una entropía de Shannon de menos de 3,5, una advertencia sonora y en 6 meses que se niegan a usar ese PSK.
Actualización 3: Sólo para que quede claro - Para romper IKE PSK, primero tiene que romper el intercambio DiffieHellman inicial, que suele ser modp1024 o MODP1536 en los casos graves (y MODP2048 en los buenos casos). La excepción a esto es IKEv1 modo dinámico, en el que el MAC calcula con el PSK como clave secreta se envía fuera de peligro. Como resultado se puede montar un ataque de diccionario en línea.
IPsec no es IKE
En primer lugar, vamos a aclarar las cosas un poco. Aunque todo el mundo está hablando de romper IPsec, lo que realmente quieren decir es romper el Internet Key Exchange (IKE) que se utiliza para negociar y crear claves simétricas que se utilizan con IPsec para el cifrado y el descifrado. sí IPsec puede utilizar varios sistemas de cifrado y algoritmos. Se puede utilizar un cifrado independiente (AES, Camelia, serpiente, TWOFISH, 3DES, etc) integridad (SHA2, SHA1, AES_XCBC, MD5, etc.) de modo o se puede utilizar un sistema de cifrado AEAD que combina estos dos en uno (AES GCM, AES CCM, GCM camelia, etc)
Pero Jake dice que deje de usar IPsec
Nada de lo dicho por Jake o publicado por Der Spiegel indica cualquier ataque a estos sistemas de cifrado o algoritmos. Incluso el uso de MD5 dentro de IPsec (HMAC-MD5) no es tan débil como la gente por lo general creen que es confundiéndolo con el uso no hmac de MD5. Los comentarios Jake hizo y el material en las diapositivas publicadas muestran los ataques contra los débiles configuraciones IKE, compromisos del router, y posiblemente en contra de algunos aceleradores de hardware IPsec. A continuación son mis observaciones relativas a las diapositivas que son interesantes en el contexto de IKE e IPsec.
El enfoque del equipo de descifrado VPN se encuentra con IPsec y SSH. Creo que se ajusta el despliegue. Estos dos protocolos son los protocolos de cifrado más ampliamente utilizado para transferir datos a granel. Mientras que la comunidad hacker podría centrarse en OpenVPN, no es ahí donde el verdadero despliegue es. La mención de PPTP es curioso. Por lo que veo, PPTP es básicamente muerto como una tecnología VPN, a pesar de que sigue siendo ampliamente utilizado en Rusia como una técnica de encapsulación para los ISP para conectar usuarios finales. Es probable que sólo aparece allí por intercepción, ya que es tan trivial que hacer, que también podría recogerla.
Esta diapositiva es más difícil de dar sentido a. Creo que aquí el NSA está hablando de IKE e IPsec combinado, aunque ellos lo llaman IPsec. Tal vez una vez que descifrar el tráfico, entra en xkeyscore? Ellos no parecen utilizar xkeyscore como una entrada para romper el IKE PSK? Me divierte con el nombre VULCAN-DeathGrip lo que podría indicar que el hifn (ahora Exar) tarjeta aceleradora de Vulcan IPsec podría tener un defecto en ella que les permite descifrar esos VPN IPsec. Además, espero que enmascaran adecuadamente sus scripts de Perl para el tráfico malicioso descifrado: P
Esta es probablemente la más interesante de diapositivas. Es, básicamente, establece que las VPN IPsec están en peligro por compromisos de router que roban el IKE PSK. Esto podría ser un buen momento para actualizar el firmware del router a la última versión, y cambiar a nuevas PSK fuertes (o cambiarlo a RSA en lugar 2048+) El AppID se refiere al nombre de la firma xkeyscore. Me alegro de ver que IKEv2 finalmente se está poniendo en, incluso dentro de la NSA :)
En esta diapositiva se está mencionando guiones IPsec, lo que podría hacer referencia a la secuencia de comandos genericIPSec_wrapper.pl se ha mencionado anteriormente. Esto indica claramente una fuerza bruta motor de descifrado de IKE PSK. Si está utilizando PSK débiles, la NSA descifra el tráfico de IKE que les dará las claves para descifrar el tráfico de IPsec. Activación de la SSP le ayudará un poco, pero ultimtely que debería realmente sólo cambiar al uso de la autenticación RSA (o ECP) y pase alltogether de PSK. Tenga en cuenta que la norma FIPS impide la continuación del uso de PSK para IKE / IPsec. La NSA sabe que es demasiado peligroso y débil.
Nota para la NSA, por favor ver que dice así:
La ortografía "IPsec" se prefiere y utiliza en este y todos los estándares de IPsec relacionados. El resto de las capitalizaciones de IPsec (por ejemplo, IPSec, IPSec, IPSec) están en desuso.
En la diapositiva 31 se afirma: IPSec: 6640 (protocolos) y 6648 (puertos)
No sé lo que se refiere a. puertos de transporte backhaul posibles o parte de un puerto de API?
En la diapositiva 33 se afirma: Necesidad todas las piezas (IKE y ESP para IPSec)
Esto realmente muestra que la NSA está rompiendo IPsec mediante la ruptura de IKE, que en su mayoría parece reducirse a PSK débiles y sin PFS. Y de nuevo, en caso de que todavía no la obtuvo en la diapositiva 39:
"TAO tiene los archivos de configuración que nos proporcionaron los PSK para permitir la explotación pasiva"
Por lo que su VPN IPsec está consiguiendo propiedad debido a que su puerta de enlace VPN consiguió propiedad! Ejecutar su VPN en un equipo dedicado, preferentemente de código abierto, y bloquear el acceso remoto a través de SSH hacia abajo usando claves de alta seguridad y filtrado de IP.
Y la última pepita interesante es en la página 40:
"NSP tenía un implante que permite la explotación pasiva con sólo ESP".
He leído esto en el sentido de que el hardware o el software del sistema que ejecuta IPsec se vio comprometida, haciendo que se envíe protocolo válido paquetes ESP, pero la creación de los de tal manera que éstos pudieran ser descifrados sin conocer las claves de sesión ESP (de IKE). Posiblemente por subvertir el generador de números hardware o funciones relacionadas con IV / / nonces de ICV que parecen ser al azar, pero no lo eran. O menos probable si el hardware / software estaba usando bytes de relleno para revelar las claves de descifrado.
Conclusión
En todo caso, yo diría que IPsec e IKE han resistido los ataques de la NSA. El hecho de que la NSA necesita implantes y necesita utilizar ataques de fuerza brutce contra IKE PSK muestra que a pesar de su naturaleza fregadero de la cocina, IKE e IPsec están haciendo bastante bien si se configura correctamente y ejecuta en un host seguro. Sin embargo, una mala configuración de IKE es algo que hicimos un mal trabajo de prevención. Podemos y debemos tener más automática IKE / IPsec implementa utilizando las configuraciones por defecto fuertes.
Y usted debe recibir una respuesta del equipo Libreswan en los próximos dos meses con respecto a eso. Encriptación oportunista: Segunda ronda
.
