viernes, 2 de agosto de 2013

Timing Attacks [I]

¡Saludos!

   Desde que hace un par de meses, mientras hacía la primera andanada de exámenes, Seth me envió este enlace sobre cómo podían extraer el e-mail asociado a un usuario en Reddit  a traición (pues no tenía tiempo para indagar más) me he estado cruzando de forma repetida con artículos que tratan este tipo de ataque. Los llamados de forma genérica "Timing Attacks".

  A grandes rasgos este tipo de ataque se basa en la extracción de información a partir de la diferencia de tiempo que se genera entre peticiones que nosotros podemos manipular. Un claro ejemplo donde se aplica este tipo de ataque es en la explotación de inyecciones SQL a ciegas utilizando peticiones pesadas ( como mostraba Chema Alonso hace unos años), generando de esta forma retardos  en las respuestas a partir de los cuales podemos ir deduciendo entre peticiones que van dando TRUE o FALSE, como en cualquier blind SQLi.


     En el caso de las aplicaciones web se puede aplicar esta técnica para, por ejemplo, enumerar los usuarios registrados. Normalmente en  foros, blogs, y CMSs en general que mantienen un sistema de usuarios,  a la hora de realizar el logueo primero se comprueba que el usuario es válido y si éste lo és, se procede a comprobar si la contraseña (o mejor dicho el hash generado a partir de ésta) coincide con el que está almacenado en la base de datos. Este proceso en dos pasos se realiza  para optimizar los recursos, ya que en caso de que el usuario no sea válido nos evitamos el tener que realizar las operaciones para calcular el hash.


    Si nosotros intentamos loguearnos con un usuario existente usando como contraseña una cadena de caracteres muy larga, en primer lugar comprobará si el usuario está registrado. Como está registrado pasará al paso dos, contrastar el hash que se genera a partir de la contraseña que hemos puesto con el que tiene almacenado y aquí es donde viene la magia: al ser una cadena muy larga va a tardar en hacer los cálculos y en mandarnos la respuesta el servidor, apareciendo un retardo. Este retardo en la respuesta del servidor será síntoma de que el usuario existe.


   En resumidas cuentas: si el usuario existe, tardará más en llegarnos; si no existe la respuesta será más rápida. Si hacemos unas cuantas pruebas para calcular unos tiempos de referencia  con los que poder discriminar entre usuarios registrado y no registrados, podremos hacer fácilmente una herramienta que nos haga un listado por fuerza bruta. Una vez conocidos los usuarios se podría lanzar otro ataque con un diccionario con las 1000 passwords más comunes, por ejemplo.


   En este artículo se pone en práctica esta técnica contra algunos CMSs comunes.


Byt3z
5 0verl0ad Labs: Timing Attacks [I] ¡Saludos!    Desde que hace un par de meses, mientras hacía la primera andanada de exámenes, Seth me envió este enlace sobre cómo podían e...
< >