¿Es CVE-2013-2566 un ataque práctico contra RC4 o aún es conceptual?

Como Matthew Green lo pone , el ataque "está justo al borde de la viabilidad". Conceptualmente se aplica a cualquier protocolo que use RC4, aunque algunos son más vulnerables que otros.

La debilidad de RC4 es un sesgo en los primeros bytes de salida. Desde la clave, RC4 genera un largo flujo de bytes pseudoaleatorios, y el cifrado es solo un byte por byte XOR de los datos para cifrar con ese flujo. Por lo tanto, cuando los mismos datos se cifran varias veces (con una clave distinta cada vez), el sesgo en la salida de RC4 se traduce en una recuperación de los datos secretos. Por ejemplo, suponga que el 17º byte de salida tiene un valor de 0x42 más a menudo que los otros 255 posibles valores de byte (un número ilustrativo ficticio). Como el mismo mensaje se cifra repetidamente, su 17º byte (llamémoslo x ) se XORedizará con el 17º byte de la salida de RC4. El atacante, observando todos los mensajes cifrados, puede notar que el 17º byte de salida es, digamos, más a menudo 0x7C que cualquier otro valor. El atacante luego inferirá que el valor observado 0x7C corresponde a los casos en que el octeto 17 de la salida RC4 es 0x42. Luego concluirá que x XOR 0x42 = 0x7C, es decir, que x = 0x3E. El atacante acaba de recuperar un byte de texto plano.

El punto importante es que solo los primeros bytes de la salida RC4 tienen sesgos que se pueden explotar en un tiempo "razonable". Los sesgos siguen siendo leves; se necesitan millones de encriptaciones observadas, todas con los mismos datos secretos, para observar de manera confiable dichos sesgos.

En una configuración web (con HTTPS), el ataque se vería así:

• El navegador de la víctima conoce una cookie que desbloquea una sesión en algún sitio (llamémosla www.example.com . El atacante quiere esa cookie.
• El atacante controla el contexto de red de la víctima. De manera realista, el atacante ejecuta un punto de acceso WiFi en un lugar público, y la víctima se conectó a él, creyendo que el restaurante o la biblioteca le proporcionaron un AP y decidió pasar unas horas.
• El atacante inyecta un Javascript hostil en la respuesta a una solicitud HTTP (no HTTPS) desde el navegador a algún sitio (no www.example.com ). Ese Javascript activará repetidamente una llamada HTTP GET a https://www.example.com , por ejemplo. creando una etiqueta oculta <img> en la página web.
• Cada llamada activada por el malvado Javascript implica una conexión SSL / TLS, con la cookie en ella, en un lugar predecible. Además, el atacante inyecta en la conexión un paquete RST justo después de la llamada, para forzar que se cierre la conexión y, por lo tanto, una nueva conexión con un nuevo saludo y una nueva tecla RC4 cada vez.

De manera realista, el atacante realmente no puede esperar más de, digamos, diez conexiones por segundo aproximadamente, por lo que un millón de llamadas tomará más de un día y una noche completos. Además, todas estas conexiones llegan al sitio de destino ( www.example.com ), lo que puede generar algunas alertas. Si el atacante puede perseguir el ataque a toda velocidad durante aproximadamente 30 horas, entonces podrá adivinar uno o unos pocos bytes de cookie (los bytes que aparecen en el flujo en una posición donde los sesgos RC4 son más importantes). / p>

La conclusión es que el ataque está, de hecho, al borde de la viabilidad: se puede demostrar en condiciones de laboratorio, pero no se ha detectado en la naturaleza. Sin embargo.

Para WPA / TKIP, se pueden aplicar los mismos principios, pero es más práctico porque en ese protocolo, cada paquete individual tiene su propio flujo RC4, que comenzó nuevamente con una clave específica del paquete. Recoger un millón de paquetes es más fácil que observar un millón de conexiones TCP con un protocolo de enlace TLS . Sin embargo, la debilidad no está restringida de ninguna manera a ese único protocolo; es consustancial a RC4 y lo seguirá en cualquier protocolo que use RC4.

Puede ser anotado que cuando SSH usa RC4, usualmente lo hace bajo el nombre "arcfour128" o "arcfour256"; en ambos casos, esto es RC4, pero con los primeros 1536 bytes de salida eliminados. Estos son bytes con los sesgos más grandes. Por lo tanto, estas variantes RC4 son bastante más fuertes que las RC4 planas (conocidas como "arcfour" en la terminología SSH).

Para los nuevos diseños de protocolo, no use RC4. Si realmente necesita ir más allá de algunos AES / GCM "normales", considere los cifrados de flujo del eSTREAM portfolio : Son más seguros y más rápidos que RC4. Pero recuerda que el diseño del protocolo es difícil .