¿Alguna herramienta MITM para forzar un conjunto de cifrado SSL débil?

Question

¿Alguna herramienta MITM para forzar un conjunto de cifrado SSL débil?

#1 de Thomas Pornin (13 votos)

9

Digamos que estoy tratando de revertir las comunicaciones de ingeniería entre una aplicación de Android y un servidor web mediante HTTPS.

Al principio, intenté hacer MITM utilizando webmitm y un certificado falso. Pero la aplicación no se inició porque la aplicación no confía en el certificado falso utilizado por webmitm. (Digamos que la aplicación tiene su propia manera de decidir en qué certificado confía y no puedo importar el certificado falso a Android como certificado de confianza)

Así que llego a otro enfoque. Noté que tanto la aplicación como el servidor web admiten cifrados débiles (por ejemplo, TLS_RSA_EXPORT_WITH_RC4_40_MD5). Así que estoy pensando, en lugar de usar un certificado falso como un puente, hay alguna herramienta mitm que solo cambie el paquete de saludo del cliente para imponer cifrados débiles y reenviar el certificado original del servidor sin descifrar o cifrar nada en el medio.

En otras palabras, cuando la aplicación envía "Hello Webserver, soy compatible con los siguientes conjuntos de cifrado: XXX YYY ZZZ. Por favor, elija uno", la herramienta mitm intercepta este paquete y lo cambia a "Hello Webserver, solo admita TLS_RSA_EXPORT_WITH_RC4_40_MD5 "y reenvíelo al servidor web. Dado que ambos soportan este conjunto de cifrado, lo utilizarán para el resto de la comunicación. Y la herramienta mitm simplemente reenvía todo entre ellos, y registra todos los paquetes. Y luego trato de descifrar los paquetes grabados sin conexión.

¿Alguna idea?

tools tls man-in-the-middle reverse-engineering

pregunta user15580 13.01.2014 - 21:12

fuente

1 respuesta

Lea otras preguntas en las etiquetas tools tls man-in-the-middle reverse-engineering

bcrypt: sal aleatoria vs sal computada Almacenamiento del historial de contraseñas antiguas e información

score 13 · Accepted Answer

Lo que estás tratando de hacer será ... difícil. El punto principal es que al final del protocolo de enlace, el cliente y el servidor se envían mensajes Finished , bajo la protección de los algoritmos y claves que se acaban de negociar; y el contenido de estos mensajes son valores hash calculados en todos los mensajes de intercambio anteriores, incluidos ClientHello y ServerHello . Lo que esto significa es que si el cliente y el servidor no ven el mismo ClientHello (porque lo alteró en tránsito), entonces el contenido del mensaje Finished no coincidirá y el protocolo de enlace fallará.

Para modificar con éxito el ClientHello , debe romper el cifrado de inmediato , y no fuera de línea: debe recuperar las claves de cifrado al final del protocolo de enlace y antes reenviar los mensajes Finished , para que pueda ajustar el contenido.

El cifrado de 40 bits está dentro del ámbito de lo tecnológicamente viable. Un primer problema es que con el conjunto de cifrado de exportación, la clave de 40 bits es solo una clave intermedia; La clave final se expande a 128 bits. La fuerza bruta todavía es factible, pero las tablas precomputadas (tablas arco iris ...) no lo son. Un problema mayor es que, dado que debe ajustar el contenido de los mensajes Finished , no solo debe romper las claves de cifrado, sino también las claves MAC, que son grandes (128 bits).

Su única opción restante, entonces, es romper la clave RSA utilizada por el servidor. Teóricamente, con TLS_RSA_EXPORT_WITH_RC4_40_MD5 , la clave pública del servidor debe tener un tamaño máximo de 512 bits. Una clave RSA de 512 bits se puede romper, pero sigue siendo un gran esfuerzo para un aficionado. Se ha informado que una sola PC de escritorio puede lograrlo en dos meses; más recientemente, un tipo factorizó una clave RSA de 512 bits por 75 dólares En tres días (75 dólares en CPU alquilados). Si prueba una conexión al servidor con un cliente (por ejemplo, la herramienta de línea de comandos de OpenSSL: openssl s_client ) que afirma ser compatible solo con TLS_RSA_EXPORT_WITH_RC4_40_MD5 , verá el certificado enviado por el servidor. Si la clave pública del servidor es solo de 512 bits, entonces puede imaginar romperla. Sin embargo, tenga en cuenta que es totalmente posible que el servidor no respete la restricción a las claves de 512 bits para "cifrar datos de exportación" (ya que dichas regulaciones de exportación se han eliminado hace más de una década).

Si puede romper la clave RSA del servidor, entonces puede hacerse pasar por el servidor, es decir, usar el propio certificado del servidor (necesariamente válido a los ojos del cliente) para su ataque Man-in-the-Middle. Si no puedes, y no hay forma de que puedas crear un certificado falso que el cliente acepte, entonces no veo ninguna forma de lograr lo que quieres hacer.