Foro Wifi-libre.com

Ataque "Tick Tock" (tic-tac) de t6_x  :
  Una nueva forma de llevar un ataque pixie wps examinando el tiempo necesario a la verificación byte por byte de los r-hashes

  Después impulsar y regalarnos el "nuevo reaver para pixie dust" (la versión 1.5.2., cf. Reaver modificado para Pixie Dust )", t6_x  vuelve al ataque con una forma original y experimental de poner de pie un ataque tipo "pixie dust" ( cf. "Pixie Dust" ataque de fuerza bruta offline para generar el PIN valido)
  Es entonces el compañero t6_x quien ha tenido esta idea brillante que nos presenta el compadre soxrok2212 en este tema del foro kali Linux : WPS Tick Tock Attack
 

¿En que consiste?...

  T6_x ha examinado de muy cerca el código de Hostpad.
Hostpad es como lo sabéis (o no ) una herramienta de código libre muy empleada y que permite, entre otras cosas, crear puntos de acceso. Lo que hace el éxito de Hostpad es que con un fichero de configuración bastante simplón podemos crear una verdadero punto de acceso.
  Lo que ha encontrado mas concretamente es que Hostpad usa una función mal pensada para verificar/comprobar los hashes.
  Aqui teneís dicha función :

int os_memcmp (const void * s1, const void * s2, size_t n)
{
    const unsigned char * p1 = s1 * s2 = P2;

    if (n == 0)
        return 0;

    while (* p1 == * p2) {
        p1 ++;
        p2 ++;
        n--;
        if (n == 0)
            return 0;
    }

    return * p1 - p2 *;

  Esta función se encuentra en las versiones 0.5.9 hasta 2.0.
Es decir que no esta empleada en las ultimas ultimas versiones de Hostpad.... pero la gran mayoría de los routers que usan Hostpad suelen usar versiones "afectadas"

  Viendo esta función seguro que mas de uno se pregunta en que y porque esta función vulneraria el protocolo WPS
Ahí esta el truco :

...En analizar el tiempo de respuesta después un M4

• El mensaje M4 se manda al punto de acceso y contiene R-Hash1 (donde tenemos a nuestra primera mitad) y R-Hash2 ( en base de la segunda mitad )

• Una vez esto hecho el router pilla el RS-1, RS-2, las laves publicas  y las dos mitades de PIN valido para generar una cadena (hash) y comparar si la cadena que hemos mandado corresponde a la cadena formada con el verdadero PIN

  Estas comprobaciones de las cadenas (hashes) se realizan mediante la función expuesta justo arriba
  El "Problema" : la verificación se hace "byte por byte".
Es decir que se verifica el primer byte de la cadena que hemos hecho con el PIN que hemos probado. Si es valido, se pasa al segundo. Pero si no es valido el router no verifica nada mas y manda un NACK y se acaba el proceso.

Dicho de otra forma : cuanto mas tardemos en recibir una respuesta del router, mas octetos hemos acertados
Y como somos nosotros (el cliente) quien manda el RS-1 y RS-2 y que conocemos las llaves publicas... tendremos unos erores al momento de las mitades de PIN.
Mas o menos temprano en funcción de nuestro nivel de acierto al momento preciso que se analysan las mitades de PIN
La cosa esta en medir con exactitud el tiempo de respuesta y podremos llegar a un especie de brute force byte por byte.
Soxrok2212 evalua a 1000 - 4000 PIN necesarios para hacer un brute force completo (si no hemos tenido suerte) y t6_x ha obtenido resultados positivos usando una implementación "a lo bruto"
  La idea es muy buena...
  ...Se trata ahora de interesarnos a esta vía y mejorarla entre todos.

*recopilatorio versiones de hostpad

  Pixie dust nos esta abriendo puertas y nos ha hecho tomar conciencia de que podemos ir mas allá del brute force tal y cual lo conocíamos con reaver
Seguiremos de muy cerca las tribulaciones de nuestros compadres

  ¡Hasta pronto!