SSLStrip

Aprovechando que estuve probando una nueva herramienta, me atrevo a escribir unas líneas para plasmar aquí los resultados, lo aprendido y una que otra divagación propia de una mente ávida de conocimiento.

Como sabemos, hace menos de un mes tuvo lugar la conferencia blackhat, esta vez en Washington. Dentro de las muchas presentaciones, una, expuesta por Moxie Marlinspike abordaba la seguridad de SSL, en específico, la charla se llama New Techniques for defeating SSL. Para Marlinspike la investigación de este tema no es nueva, de hecho, en el 2002 liberó la herramienta sslsniff que aprovechaba un error en la implementación de SSL de algunos navegadores para firmar el certificado de un dominio, con otro, engañando al usuario.

El ataque se basaba en la cadena de confianza, técnicamente hablando utilizaba la cadena de certificados para lograr su objetivo. Una autoridad certificadora válida (CA) firma un certificado válido, pero este último certificado no deberia poder ser usado para firmar mas certificados, obvio no?. Sin embargo, debido a una mala implementación y la no especificación ni lectura del campo basicConstraints, un atacante dueño de un certificado válido, a través de sslsniff que utiliza openssl, firma un certificado fraudulento y dado que la ruta de certificación es válida, el navegador víctima lo toma como válido. Esto significa que cualquiera con un certificado válido podía (ya no es posible debido a que ya fue corregido) crear y firmar otro certificado válido para cualquier otro dominio.
Más info sobre este bug: Aqui. Y el advisor.

En esta oportunidad, la herramienta presentada, sslstrip, no explota una vulnerabilidad propiamente dicha, sino que implementa una ingeniosa manera de engañar a un usuario haciéndole creer que se encuentra en una comunicación cifrada HTTPS cuando en realidad todo el tráfico es HTTP en texto plano. SSLStrip está desarrollado en python y no es otra cosa que un servidor proxy transparente que hace algunas cosas inusuales.

Actualmente el ataque que conozco para "jugar" con comunicaciones HTTPS consta de un MITM con envenamiento ARP. Sin embargo, cualquier usuario avispado dudará en ingresar sus credenciales luego de la advertencia presentada por el navegador respecto al famoso certificado inválido. Hace poco me comentaban que herramientas como ettercap mejoran esta técnica al tomar la información del certificado válido como el Common Name la exponen en el certificado creado por la herramienta para hacer confiar al usuario. Sin embargo, la advertencia siempre se mostrará, y eso no queremos.

La advertencia es mostrada debido a que se crea una comunicación segura en los 2 canales del envenamiento ARP, es decir, uno entre el usuario y el atacante y otro entre el atacante y el servidor Web. Dado esto, es el atacante quien crea su certificado "self signed" y al comprobar el browser del usuario, determinará que no es vállido mostrando esa fea advertencia.

He aquí la innovación de SSLStrip: entre el atacante y el usuario existe una comunicación HTTP sin cifrar y entre el atacante y el Web server existe la comunicación cifrada (Ver imagen). Para esto, SSLStrip que básicamente funciona como un proxy que intercepta comunicaciones HTTP, previo ARP Poison, analiza el tráfico enviado por el usuario y sustituye las comunicaciones cifradas por no cifradas de manera que el usuario visualiza la página que busca, pero sin cifrar. Esto se logra simplemente cambiando cualquier dirección que apunte a un recurso https por un http ya sea links href o redireciones Location.

Esto es posible debido a que normalmente, para llegar a un recurso cifrado HTTPS primero se ingresa mediante HTTP, es decir, la mayoría de veces la única manera de llegar a un cifrado SSL se da a través de links (href) y redirecciones (Location). Me pregunto ¿cuántas personas ingresan a un portal web escribiendo el https adelante?. De hecho conozco varios, incluso algunos demasiado neuróticos al punto que sólo quieren chatear por canales cifrados o que paran con un token en el bolsillo para conectarse a la VPN de su casa para de ahi navegar seguro jajaja, pero son pocos.

Regresando al tema, existen páginas muy conocidas, que presentan todo en HTTP y tan sólo son los Form Action los que apuntan a recursos https entre ellas conocidos bancos gringos o un proveeder de webmail muuuy conocido. Dado esto, SSLStrip sólo tiene que cambiar el link del Form Action para que las credenciales sean enviadas por HTTP logrando capturar las credenciales y significando esto ninguna diferencia para el usuario en cuanto a la visualización.

Veamos como SSLStrip hace el cambio y los resultados conseguidos.

Esta es la versión de el formulario de logueo de Google segura.

Esta es la versión de el formulario de logueo de Google con SSLStrip.

De misma forma, PayPal seguro:

Paypal inseguro:




Es importante mencionar que SSL no está roto, la debilidad (ya que no es una vulnerabilidad) de la que SSLStrip se aprovecha se encuentra en todo el contexto: usuarios no concientizados, portales Web con malos diseños que intentan presentar una idea de seguridad, navegadores, protocolos,etc.

Cabe resaltar que los mecanismos de autenticación que emplean tokens OTP no se encuentran a salvo de este tipo de ataques, pues una vez autenticados podemos usar las cookies de sesión y utilizar los recursos privados, a los cuales no deberíamos tener acceso.

Existen varios métodos para evitar este tipo de ataques, pero en todos es necesario que los usuarios sean concientizados. Entre los métodos para evitar este ataque tenemos:

Desde el lado del cliente:

• Escribir directamente https en la barra de direcciones, con esto primero iniciamos un canal cifrado y dentro de dicho canal se envían las peticiones http, si algún proxy intenta suplantar al servidor o modificar la información que viaja por este canal, el usuario podrá percatarse de ello gracias a las advertencias de los navegadores.

• Verificar la información de seguridad de la web mostrada por el navegador, es decir verificar que se esté usando https, se puede usar https y confundir al usuario usando una técnica llamada homograph attack, pero no si el sitio web usa certificados de validación extendida.

Desde el lado del servidor:

• Evitar usar páginas de autenticación en HTTP con envío a HTTPS o HTTP.

• Evitar el uso de frames, iframes.

• No usar contenido sin cifrar dentro de una web con https, por ejemplo si desean usar alguna imagen, un archivo de javaxript o cualquier otro control, deben ser solicitados vía HTTPS.

• Recordar a los desarolladores que poner un gif de un candadito al costado de donde ingresan las credenciales no convierte a la página en segura.

• En aplicaciones donde se manejan datos muy valiosos se puede considerar implementar la autenticación mutual con certificados.

• En las páginas donde el usuario ingresa información sensible, personal o confidencial, se debe prohibir el tráfico http y por defecto usar HTTPS.

Bueno, eso es todo por ahora, agradecimientos a CC por la ayuda más técnica, hasta otra ocasión.