¡Hola!
Sigo entreteniendome con NodeJS y las redes wifi. En esta ocasión estaba probando a desautenticar usuarios conectados enviando paquetes deauth, para lo cual estaba cazando las MACs con airodump-ng. Cual fue mi sorpresa cuando no me aparecía uno de mis ordenadores -el que quería echar fuera de la red- como asociado a mi AP. Como se puede apreciar en la imagen únicamente me aparece asociado 1 solo ordenador, cuando deberían de aparecerme los 3, o como mínimo otro más, pues estaba navegando por él y generando tráfico que debiera de ser detectado. Nada.
En ese momento pensé: pues si airodump-ng no me lo está pillando, probemos a hacernos un escáner a ver si lo pillamos nosotros. Por supuesto que existen muchos escáneres geniales que podrían haberme solucionado la papeleta (o incluso simplemente usando WireShark y parseando el PCAP con un script en PERL) pero la idea es utilizar algo creado por uno mismo y de esta forma seguir aprendiendo.
La única información que quiero obtener son el nombre de la red, su mac, y quién esta conectado, ya que es lo único que necesito para mandar el deauth. Entonces… ¿de donde sacamos esos datos?
Lo primero que nos debería de venir a la mente son los beacons . Básicamente son frames cuya función es indicar la presencia de un punto de acceso. Se envían de forma automática contínuamente y contienen mucha información, entre ella la MAC del AP y el ESSID con el nombre de la red – es decir, gran parte de lo que necesitábamos-.
Los beacons parece que pueden aportarnos toda la información sobre el AP y tan sólo nos quedaría buscar en otra parte quien está asociado, pero… ¿nos quedamos sólo con este frame? La respuesta es un rotundo NO. No podemos recopilar datos únicamente de los beacons porque si la red se encuentra oculta éstos van con el ESSID vacío, de tal forma que no podríamos ver el nombre de la red. Luego toca buscar dónde más aparece el ESSID.
Y nuestra respuesta está en los probe response frames. Cuando un AP recibe un probe request, ésta va a responderle con un probe response donde vendrá el ESSID -y disfruten de esto- que no es ocultado. En los probe request también puede aparecer la red, pero no los utilizaremos porque cuando un equipo tiene guardada una red oculta, éste envía contínuamente probe request para ver si ese AP está disponible. Incluso si la red está totalmente fuera del alcance. Es decir, contínuamente está preguntando “¿Está la red Sífilis aqui? ¿Está la red Sifilis aquí?” , por lo que si utilizásemos estos frames podríamos creer que existe una red cuando en realidad no está ni cerca: simplemente hemos pillado a un ordenador preguntando.
¡Ya sólo nos queda averiguar quien está asociado a cada AP! Tras mirar unos cuantos minutos capturas de WireShark concluí que los paquetes RTS podrían ser un buen candidato del que obtener información: aparecen tanto la dirección de quien envía el paquete como de quien la recibe, por lo que tan sólo nos quedaría correlar esta información con el listado de AP que obtenemos de los beacons y probe response y mostrarla.
El resultado final es este:
Ahora sí estamos pillando los 3 ordenadores que estaban conectados en esa red. Si os fijais la tercera red que se muestra tiene el nombre vacío debido a que se trata de una red oculta (el beacon tenia el nombre vacio) pero sin embargo justo debajo aparece su nombre (0verl0ad). Ésto es debido a que ha conseguido extraer la información de los probe response.
En caso de que no hubiese nadie mandando probe request (para que responda) no podríamos saber el nombre real de la red…pero sí la longitud del ESSID. Eso significa que podremos bruteforcearlo con probe requests hastsa que obtengamos un probe response que nos indique que el string era el correcto (este es el siguiente script que tengo en mente ).
Vuelvo a repetir lo que dice al inicio, existen múltiples escáneres que podría haber usado, la idea era simplemente jugar un rato y solventar un problema.
