Que tal.
El paper es bastante claro, por lo que leo imagino que el Ingles no es lo tuyo
De todas maneras si ves que vas a sufrir demasiado con este Proyecto siempre puedes barajar la posibilidad de cambiar de Proyecto..
Este ataque como se indica va dirigido a la renegociacion de TLS. Primero que nada deberias de ver como funcionan los pasos para establecer una comunicacion via TLS.
Como se dice en el paper, antes de establecer una sesion via TLS hay un Handshake por el cual se determinan ciertos parametros como Cypher a usar, version del Protocolo, etc. Se habla de Client Certificates y es que no solo HTTPS (se habla mayormente de TLS aplicado a HTTP(s)) Servers pueden presentar Certificados, sino tambien los HTTPS Server configurados para aceptar Certificados de clientes. Esto puede ser por ejemplo si se setea en el Server el uso de Certificados como metodo de Autenticacion para acceder a algun recurso (Carpeta en el Server, etc.).
TLS posee una caracteristica que recuerdo de algo que programamos kamsky y yo hace un tiempo, y se trata de Session Resumption. Eso es, como sabemos las transacciones HTTPS suelen ser muy costosas para el Server HTTPS, asi que Session Resumption no es mas que una ayuda para el Server y lo que ocurre es que, reconocida una Session HTTPS anteriror por el Server con un cliente en concreto, se ahorran pasos como el Handshake (a priori) y se retoma a la sesion anterior por el mismo Session ID; el Server no sufre tanto asi. Es en sesiones basadas en Client Certificates donde mas se centra este ataque por motivos a discutir.
Recuerdo que cuando estaba programando aquello siempre vi "tantadora" esta parte del Session Resumption ..
Pero lo importante aqui es la caracteristica de Renegociacion del Protocolo. Es decir, en algun momento dado en la sesion HTTPS el Cliente o el Servidor, dependiendo de quien decida Renegociar, puede emitir un Hello y asi Renegociar sobre un nuevo cypher a usar, una nueva version del Protocolo a usar (?) etc.
Ahora piensa en el ataque, esta basado en un MiTM y lo que el atacante quiere es acceder (como MiTM) a /highsecurity/index.html que esta configurado solo para Clientes con un Certificado valido, y por supuesto estamos hablando de Client Certificates y el Server ha configurado /highsecurity para solo ser accedido de esa manera. Imagina que el Cliente ha iniciado una Sesion HTTPS con el Server normalmente, y con normalmente digo que es una Sesion basada en Server based Certificates (lo "normal", donde el Server nos manda el Certificado asi corroborandonos su autenticidad). Que ocurre si en un momento dado, el Cliente quiere acceder a /highsecurity/index.html, directorio configurado en el Server para ser accedido por Client Certificates validos ?? Aqui ocurren varias cosas.
De repente en el canal HTTPS ocurre esa peticion a nivel de aplicacion (HTTP), y resulta que HTTP NO TIENE MODO de decirle (desde el Server al Cliente) al Cliente que vuelva a mandar el Request (por /highsecurity) dentro de un nuevo canal HTTPS, por lo que esto se le debe de decir al Cliente de una manera "retrospectiva". O sea, HTTP carece de un Response Code (tipo HTTP 200 OK) para este proceso. Es decir queda en manos del TLS el Renegociar el canal HTTPS para que el Cliente mande el Certificado para /highsecurity (a grosso modo!).
Resulta que para esta Renegociacion NO se usa la opcion de Session Resumption anteriorimente citada, lo cual podria ser mas seguro: Session Resumption implica retomar un contexto cryptografico anterior, mientras que Session Renegotiation implica obtener un nuevo contexto cryptografico.
Pues en el Session Renegotiation toda la renegociacion va "protegida" por el Cypher usado en el canal antiguo, pero resulta que hay un momento el la renegociacion donde la Autenticacion pierde estado, es decir, hay un "lapsus" en la autenticacion el cual el atacante puede aprovechar para que, mediante el ataque MiTM, poder inyectar en la renegociacion un plaintext a su antojo, y he aqui el ataque. El atacante eso si, via el MiTM debe hacer que el Cliente Autentique (es el Cliente el que tiene el Cypher a fin de cuentas) la transaccion (GET /highsecurity/index.html) que el atacante quiere inyectar.
Para esto se puede usar "request splicing" para asi poder inyectar meidante el MiTM el plaintext. Este ataque es explicado en el paper pero solo decir que una Requesta HTTP del cliente (todo aprovechando el "lapsus" en la Auntenticacion) es "dividida" (spliced) para que al final el Server devuelva los contenidos de /highsecurity/index.html. Como es dividido el Reques por el MiTM ? Pues primero se inyecta antes que nada, una Requesta HTTP para cualquier recurso (/DirSecure/ por ejemplo) que "dispare" la Renegociacion del canal. La segunda Requesta contendria prepuesto un GET a /highsecurity/index.html, seguido de un Ignore Header para que todo lo que le sigue (la peticion inicial del Cliente) sea Ignorado y se devuelvan los contenido de /highsecurity/index.html. Todo iria dentro de una misma Peticion, y es observable en el paper con el siguiente codigo:
char *req =
"GET /highsecurity/index.html HTTP/1.1\r\n"
"Host: example.com\r\n"
"Connection: keep-alive\r\n"
"\r\n"
"GET /evil/doEvil.php?evilStuff=here HTTP/1.1\r\n"
"Host: example.com\r\n"
"Connection: close\r\n"
"X-ignore-what-comes-next: ";
Asi pues, ese seria el buffer que contendria la inyeccion hablada. Para llevarla a cabo se habla de HTTP Pipelining y Keep-Alive (o conexiones persistentes), asi que echale un vistazo !
Bueno te deseo Suerte en el Proyecto y mirate mas que hay bastante info. Yo solo espero poder haberte aclarado algo.
Saludos.
Autor
En línea
