domingo, 22 de febrero de 2009

Usabilidad y seguridad. SSLStrip


Hace unos días terminaron las BlackHat DC, y ya están listas para descarga las presentaciones, videos, etc. Entre ellas, la presentación "New techniques for defeating SSL/TLS", de M. MarlinSpike. El autor de la presentación implementa estas técnicas en una herramienta llamada sslstrip (cuyo código fuente estará disponible pronto). Sin embargo, para mí la noticia no es la existencia de esta herramienta, sino lo que nos cuenta la presentación.

La demostración es interesante, porque nos recuerda que la usabilidad de una aplicación y su seguridad también están relacionadas. Así, se introduce el concepto de "feedback positivo" y de "feedback negativo" hacia el usuario en una aplicación web, y cómo es más fácil engañar al usuario si se consigue no sólo eliminar el feedback negativo al realizar el ataque, sino además proporcionar feedback positivo.

Así, el feedback negativo es la presentación de un error "gordo y peludo" en caso de que se sospeche que el sitio podría ser falso. Es la solución que los navegadores modernos están implantando, un ejemplo es la pantalla que se ve cuando el certificado de una página no puede ser verificado. El feedback positivo, por el contrario, consiste en proporcionar mensajes que dicen que todo está bien, como puede ser el icono verde que presenta Firefox en la barra de direcciones cuando sí se ha determinado que el certificado es auténtico.

El funcionamiento de las técnicas presentadas se basa en tres puntos:
  1. cuando un sitio web quiere pasar de HTTP a HTTPS (por ejemplo, al autenticarte), se "captura" este paso mediante un proxy SSL (ataque man-in-the-middle o MITM). Hasta aquí nada nuevo. Después, se proporciona algo de feedback positivo al usuario, por ejemplo sustituyendo el icono "favicon" (el que sale en la barra de direcciones) por un candado cerrado
  2. hay muchos sitios web (bancos online, etc) que presentan un formulario cuya petición irá bajo https, en una página http. Cuando el usuario pulse en el botón correspondiente, se intercepta mediante el MITM. Generalizando, el usuario llega a SSL a partir de HTTP: a través de redirecciones, o pulsando en un enlace o un botón. Pero nunca escribiendo la url directamente, por lo que siempre hay una ocasión para el MITM
  3. Un atacante puede utilizar nombres de domino internacionales (IDN: international domain names) para crear una url que incluya los caracteres "." y "/" escritos con juegos de caracteres internacionales (por ejemplo el cirílico). A esto se le denomina homograph attack. La técnica presentada reutiliza de forma ingeniosa este "homograph attack", para conseguir una url similar a la del sitio web víctima, pero controlada por el atacante. Esto es lo novedoso. Así, en realidad, el usuario está solicitando un sitio web distinto, pero no lo percibe: es posible incluso que el sitio esté bajo HTTPS y que el usuario reciba feedback positivo pues verá un certificado SSL que es válido
La solución al problema pasaría, según comentarios, por el uso de certificados de validación extendida. También por la concienciación del usuario para que conozca el problema, qué son estos certificados, etc.

Algo más de información:
Man in the middle attacks sidestep SSL (Securityfocus)
Leetness not actually required for pwnage (DoxPara)
sslsniff (mencionada en la presentación)


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

No hay comentarios: