Proceso de inyección de paquetes en Redes WIFI utilizando Commview for WIFI

Este manual fue corregido y en algunas partes se resaltaron las diferentes opciones y otras mejoras mínimas para separar las secciones,  se conservo el contenido original al 100%, se descargo de http://www.seguridadwireless.net   Me pareció interesante el contenido, pero es muy largo, pesado y difícil de llegar hasta el final, incluso para quien esté empapado en el tema. Quizás este sea mas apropiado para ponerlo en un fichero PDF igualmente lo publicare para que esté a disposición de mas gente.

Manual del Proceso de inyección de paquetes con CommView for WIFI en castellano 

Commview for WIFI Quizás sea uno de los mejores programas para auditorias Wireless en Windows, este manual se creo hace muchos años por Hwagm, para la versión 5.2, pero sigue siendo operativo al día de hoy y no encontraras ninguno igual en todo la red.

Descargar de la versión de evaluación del Commview for wifi

Manual pdf de la pagina oficial del Commview

1.- Antecedentes
2.- ¿Cuantos tipo de inyección importantes existen en Linux?
2.1.- Ataque 0: desautentificación de clientes
2.2.- Ataque 1: falsa autentificación
2.3.- Ataque 2: Reenvío interactivo de paquetes
2.4.- Ataque 3: Reinyección de trafico
2.5.- Ataque 4: El "chopchop" de KoreK (predicción de CRC)
3.- ¿Que tipos de inyección podemos efectuar en Windows?
3.1.- Desautentificación de clientes
3.2.- Falsa autentificación
3.3.- Reinyección de trafico en Windows
4.- Inyectando trafico con CommView
4.1.- Recordatorio de los "Alias"
4.2.- ¿Como efectuar un Ataque 0 o desauntetificación de clientes?
4.3.- Obtención del handshake sobre encriptación WPA-PSK
4.4.- Descubrir el ESSID oculto de una conexión Wireless
4.5.- Conseguir una falsa autentificación en Windows para redes Wireless sin clientes
4.6.- Reinyección de trafico en Windows

 

1.- Antecedentes

La inyección de trafico en redes WIFI, sus razones y sus motivos están mas que explicado en la Biblia de seguridad, pero nunca se pudo hacer en Windows de forma correcta, solo en Linux. Pero este hecho ha cambiado drásticamente, y supone un cambio bastante a tener en cuenta en la auditoria Wireless. Últimamente han salido muchos live CD que recopilan multitud de herramientas para la auditoria, pues bien los desarrolladores de software para entornos Windows (un gigante que camina con pasos muy pesados) han visto la necesidad de desarrollar nuevas herramientas para tales propósitos, aun así considero al entorno Linux el mejor sistema para la auditoria Wireless, pero nunca nos debemos a cerrar a nada, comentaremos en este manual la forma de inyectar trafico de forma correcta en una plataforma Windows.

Todavía no se ha conseguido la eficacia del sistema Linux y difícilmente se conseguirá debido a la multitud de programadores libres que trabajan en GNU/Linux, pero podemos decir que los primeros pasos se han dado satisfactoriamente, y en este manual, único en lenguaje castellano podremos aprender la inyección de trafico en Windows.

Para realizar nuestros propósitos, nos basaremos en una aplicación comercial que corresponde al CommView para WIFI. Ya hemos comentado en el Manual básico de funcionamiento (el cual deberías leer antes que este) que es una aplicación comercial de pago, pero existe la versión de evaluación  con algunas limitaciones, pero aun así dicha versión de evaluación es suficiente para la inyección de trafico en Windows. De hecho este manual ha sido realizado en su totalidad con dicha versión de evaluación.

Para que podáis entender como funciona, que tarjetas son compatibles y como debe de ser configurado y actuado para poder capturar trafico (modo monitor) previo paso al análisis de la inyección de trafico. No tengáis prisa por entenderlo a la primera vez, entiendo vuestras inquietudes pero seguid los pasos indicados de forma correcta y finalmente obtendréis unos resultados muy buenos y no solo eso sino que también tendréis un conocimiento único de como funcionan las conexiones Wireless al tener acceso a información "casi" a nivel de código maquina.

Es importante remarcar que solamente es necesario 1 tarjeta Wireless para hacer todo el trabajo de ataque y por supuesto una tarjeta para hacer el trabajo de "conejillo de indias". Para el ataque solo hace falta una porque se puede capturar e inyectar a la vez, es mas, la propia aplicación obliga a que nuestra tarjeta este capturando trafico para poder inyectar, si lo se, es un concepto nuevo al que no estamos acostumbrados todavía, ya que anteriormente era al revés, es decir, estábamos deseosos que nuestras tarjetas pudieran inyectar a la vez que capturar cuando los primeros drivers de Linux no lo permitían.

Aun así el control de la inyección no será total para todas las tarjetas, sino para determinadas en especial, pero esta claro que si pasan el test de la aplicación que comento en el manual básico del Commview, podrán seguramente capturar e inyectar a la vez. Estas serán la únicas pruebas de autodiagnóstico que podremos realizar, previo paso de efectuar el trabajo sobre campo directo. Es en este punto, donde Linux es mejor que Windows, ya que permite la inyección con un numero mucho mas elevado de tarjetas y de chipset. Esperemos que los desarrolladores de software tomen nota y avancen sus investigaciones en la creación de nuevos drivers.

Las pruebas han sido efectuadas con mis propios equipos y en ningún momento mis ataques han afectado a redes de terceros que no sean las mías propias, si bien deseáis un conocimiento mayor sobre la auditoria Wireless, lo ideal es trabajar con 3 tarjetas mas un punto de acceso.

Resumiendo:

1. una tarjeta para usar con Commview for WIFI
2. una tarjeta para conexión normal al punto de acceso AP, la  cual será atacada mediante diferente formas y será usada como conejillo de indias, 
3. una tercera tarjeta para usarla con un sniffer diferente ya testeado hasta a la saciedad, por ejemplo el airodump o el winairodump y comparar resultados.

De hecho esto no es necesario, ya que Commview for WIFI permite ver si la inyección es correcta o no.  Pero como siempre es necesario en los primeros pasos de una demostración de algo nuevo, confirmar los resultados mediante aplicaciones alternativas que ya sabemos que funcionan bien.

Y además he usado un 4 elemento para la comprobación de la inyección y es mi famoso vigila bebe para niños, que trabaja en un rango de frecuencias exactamente al mismo que la banda de frecuencias para el estándar 802.11b/g que es el habitual en las redes Wireless (2.4GHz).

 

 

 

2.- ¿Cuantos tipo de inyección importantes existen en Linux?

Si echamos un vistazo a la Biblia de seguridad veremos cuatro tipos importantes de inyección en Linux, que normalmente denominamos como ataques.

2.1.- Ataque 0: Desautentificación de clientes

Este ataque es probablemente el más útil para recuperar un ESSID oculto (no difundido) y para capturar "saludos" WPA forzando a los clientes a reautentificarse. También puede ser usado para generar peticiones ARP en tanto que los clientes Windows a veces vacían su cache de ARP cuando son desconectados. Desde luego, este ataque es totalmente inservible si no hay clientes asociados. Normalmente es más efectivo fijar como blanco una estación específica. Aunque podemos realizar una denegación de servicio masiva con una tarjeta.

2.2.- Ataque 1: Falsa autentificación

Este ataque es particularmente útil cuando no hay clientes asociados: creamos la dirección MAC de un cliente falso, la cual quedará registrada en la tabla de asociación del AP. Esta dirección será usada para los ataques 3 (reinyección de peticiones ARP) y 4 (desencriptación WEP "chopchop"). Es mejor preparar la tarjeta de ataque con la misma MAC que el cliente falso de esta forma el controlador puede enviar ACKs de forma mas adecuada.

2.3.- Ataque 2: Reenvío interactivo de paquetes

Este ataque te permite elegir un paquete dado para reenviarlo; a veces proporciona resultados más efectivos que el ataque 3 (Reinyección de trafico). Podrías usarlo, por ejemplo, para intentar el ataque "redifundir cualesquiera datos", el cuál sólo funciona si el AP realmente reencripta los paquetes de datos WEP.

2.4.- Ataque 3: Reinyección de trafico

Es el clásico ataque de reinyección de petición ARP es el mas efectivo para generar nuevos IVs, y funciona de forma muy eficaz. Puede que tengas que esperar un par de minutos, o incluso más, hasta que aparezca una petición ARP; este ataque fallará si no hay tráfico.

2.5.- Ataque 4: El "chopchop" de KoreK (predicción de CRC)

Este ataque, cuando es exitoso, puede desencriptar un paquete de datos WEP sin conocer la clave. Incluso puede funcionar con WEP dinámica. Este ataque no recupera la clave WEP en sí misma, sino que revela meramente el texto plano. De cualquier modo, la mayoría de los puntos de acceso no son en absoluto vulnerables. Algunos pueden en principio parecer vulnerables pero en realidad tiran los paquetes menores de 60 bytes. Este ataque necesita al menos un paquete de datos WEP.

 

3.- ¿Que tipos de inyección podemos efectuar en Windows con el CommView 5.2 para WIFI?

3.1.- Desautentificación de clientes

Es el denominado ataque 0 o desauntetificación de clientes, valido para redes Wireless tanto con seguridad WEP como WPA. La recuperación de clave WPA requiere el uso de ficheros o diccionarios auxiliares.

Se puede incluso realizar una petición de denegación masiva, deshabilitando a todos los clientes o una en particular, y dejar fuera de servicio el nodo Wireless al completo el tiempo que se quiera. Esto es muy peligroso, y recordad de no hacerlo nunca en ninguna instalación que no sea la vuestra.

Es valido para generar petición de ARP encriptado y poder efectuar posteriormente la reinyección de trafico.

También permite localizar los nombres de redes (ESSID) ocultos, ya que este nombre si se emite de forma transparente en el inicio de la conversación entre punto de acceso y cliente, luego veremos como hacerlo

3.2.- Falsa autentificación 

Respecto al ataque 1, (falsa autentificación), mis resultados en Windows no han sido positivos, consigo editar un paquete para realizar un forzado de cliente, lo puedo enviar pero mi punto de acceso me lo rechaza constantemente. Podríamos pensar que es algo normal, pero mi router es el Zyxel de Telefónica, y es el router que mayor numero de ataques suele aceptar, como en Linux me funciona a la primera, puedo determinar que mis resultados no han sido concluyentes, y no citare en ningún momento la forma de efectuarlo hasta que no lo consiga.

Llegados a este punto es hora de especificar la forma teórica de como se reinyecta trafico en Windows.

3.3.- Reinyección de trafico en Windows 

Es puramente la reinyección de trafico o reinyección de petición de ARP, y su finalidad es aumentar la velocidad de la captura de datos para no hacer   largas horas de captura. Esta claro que solo es posible hacerlo con clientes, en caso contrario esta por ver, pero......... podemos servirnos del ataque 1 , generando así un cliente ficticio y posteriormente reinyectar con los datos obtenidos del cliente falso. Pero como vuelvo a repetir, esto esta todavía por ver..............

En Windows y mediante esta aplicación no tiene sentido hablar de ataques 2 y 3 ya que se indexan conjuntamente. Es un concepto totalmente nuevo donde se pueden unificar ambas formas de hacerlo, recordad que en el ataque 3 era la propia aplicación que interpretaba si la petición de ARP encriptado era correcto o no, lo intuía, en Windows es algo similar pero tu decides que paquete se debe de mandar, y esto es mas parecido al ataque 2. Pero la base teórica es la misma que el ataque 3, es decir capturamos una petición de ARP encriptado del cliente hacia su punto de acceso, y luego se lo reenviamos constantemente al punto de acceso, generando nuevas respuesta ARP desde el punto de acceso, y con IV únicos y validos.

Si la red a analizar ya tiene un cliente y el trafico es elevado, con la simple captura en modo monitor, será mas que suficiente, pero este proceso de reinyección puede ser tan efectivo, que pueden tomarse datos suficientes en 10 minutos para una red de poco trafico o incluso muchos menos tiempo si la misma tiene un trafico considerable. ¿Pero será nuestra tarjeta capaz de soportar tantas lecturas seguidas?, eso solo lo veréis al probarlo, pero yo diría que quizás si, pero podrá soportarlo nuestro ordenador o mejor aun, podrá sopórtalo esta aplicación aunque se trabaje con buffer, yo tengo aun algunas dudas.

Es importante señalar que ciertos AP (puntos de acceso) se saturan con mucha reinyección de trafico, es mas incluso se resetean, esto le pasa habitualmente a mi punto de acceso integrado en mi router.

Este ataque es muy efectivo en Windows. No es exactamente igual al ataque 3 y 2 en Linux sino que mantiene algunas características de ambos. Posteriormente veremos como realizarlo.

Respecto al tema de inyectar un archivo lo mismo ya que se pueden grabar los paquetes que queramos y que se han óptimos para conseguir la reinyección de tráfico

La reinyección de trafico puede realizarse de varias formas,

• o bien observamos el trafico en la pantalla de paquetes, hasta observar cuales son las peticiones de ARP encriptados, (yo ya me lo conozco de memoria),
• o podemos efectuar un ataque 0, y esperar a la petición de ARP y aplicando una serie de reglas de filtrado.

Al igual que Linux se puede reutilizar una petición ARP, de hecho siempre funciona así debido a que los paquetes se graban en el buffer de datos y luego se inyectan, pero dichos paquetes también se pueden guardar en un fichero particular y volver a usar cuando se requiera. De esta manera al ser una versión de evaluación y tener ciertas limitaciones del numero de capturas, podemos estar seguro que los 5000 datos son IVs únicos y validos, eso si tendrás que realizar varias capturas durante el día.

Mediante el CommView podemos conseguir un nivel de trafico mas alto enviando paquetes de ARP cifrados, el punto de Acceso responderá con paquetes de respuesta ARP, generando así tráfico adicional. Mientras que el ARP original es siempre el mismo y no ayuda de forma directa a obtener una nueva inicialización del vector IV ya que tienen el mismo contenido los paquetes de respuesta ARP si serán diferentes unos de otros y por lo tanto se usaran para la recuperación de claves WEP. Es decir si captamos una petición de ARP y la enviamos al punto de acceso, este responderá con paquetes de respuesta ARP donde aparecerán nuevos IV validos, uno por cada petición.

En sistemas de encriptación WPA no tiene sentido hablar de reinyección de trafico, esta no vale para nada, solo será efectivo el ataque 0, localizando así el famoso "handshake" que tiene lugar en el inicio se sesión cuando se intercambian las claves.

 

 

 

 

4.- Inyectando trafico con CommView

Antes de empezar os comentare que no aparece ninguna MAC real visible ya que las he convertidas todas en Alias, por ejemplo para mi punto de acceso la he definido como "MIap" y la tarjeta cliente como "mi54g", es mas cómodo trabajar de esa forma, y el programa se encarga de interpretar y de pasar los alias a direcciones MAC en hexadecimal.

Trabajaremos en el canal 1 y el nombre del AP es"Policía" (ESSID), en todo momento el AP del router está configurado de forma que el ESSID esté oculto.

Lógicamente el tipo de encriptación dependerá del ataque que estemos realizando en cada momento. Si es pura reinyección de trafico solo será para encriptación WEP, si hablamos de desautentificación o bien podemos tener WPA o WEP, pero si mencionamos la desautentificación solo para recuperar el handshake, lógicamente estamos hablando desencriptación WPA.

 

 

4.1.- Recordatorio de los "Alias"

Si seleccionáis un punto de acceso o estación, y pulsáis el botón secundario del ratón, os saldrá un menú contextual, entre otra cosas permite crear "Alias", los alias son etiquetas que se dan a las direcciones MAC que están en hexadecimal, para recordarlas mejor. También es interesante ver como media palabra de la dirección MAC, es decir las 3 primeras no salen en hexadecimal sino que sale el nombre del fabricante, todo esto es configurable y editable a través de menús.

La información es variada. Podemos ver valores máximos, mínimos, y la medida instantánea de cualquier punto de acceso o de una estación, los mismo para la velocidad de conexión. Esto es muy útil ya que podemos determinar de que estándar son. Y me sirvió mucho de ayuda para comprobar el tema de la inyección de trafico con mis equipos, ya que comparaba los resultados con este aplicación con otro sniffer, pero para eso otro sniffer solo tenia una tarjeta que capturaba trafico en el estándar 802.11b, pues bien mediante esta pantalla como sistema de monitorización iba separando los equipos de forma que la cobertura no fuese mala y la velocidad de comunicación se mantuviera por debajo de los 11Mbs, mi punto de acceso es de modo compartido.

Los puntos de acceso se muestran como AP y las estaciones o clientes se muestran como STA. Si queremos saber si una estación cliente esta autentificado o intenta asociarse a un punto de acceso, podemos verlo fácilmente en la ventana de paquetes. Los nodos Wireless se muestran como ADHOC.

Tenemos la opción de crear "Alias" esto es muy útil ya que evitamos trabajar con valores hexadecimales. Lo vemos de manera rápida ya que es muy sencillo.

Paso 1.

Paso 2.

Paso 3.

Cuando se inicie la exploración o las capturas ya aparecerán los "Nodos" con sus "Alias". Y va perfecto sobre todo a la hora de analizar los paquetes.

En este caso mi propio nodo AP tiene el nombre de red (ESSID) de forma oculta ( es Policía).

Para que aparezcan las redes inalámbricas en la pantalla de "Nodos" recordad de usar el botón "Iniciar Exploración". Y la aplicación este configurada de esa forma. Durante la captura, también pueden ser visibles los nodos, si lo hemos configurado al respecto.

 

 

4.2.- ¿Como efectuar un Ataque 0 o desautentificación de clientes?

En primer lugar ponemos la aplicación a capturar datos, botón "Play"

Mediante la barra de menús del programa nos dirigimos hasta "Reasociación de nodo".

Esta incluido en <Herramientas> y de la lista seleccionamos "Reasociación de modo".

La pantalla que mostrara la aplicación será la siguiente:

Si hemos dedicado un poco de tiempo a crear alias a partir de los datos obtenidos en la ventana de "Nodos", en la lista que hay debajo de la etiqueta: "Enviar una solicitud de desautorización desde esta AP:" tendremos definidas todos los que hemos creado, pero siempre que en ese momentos estemos en proceso de captura y sean detectadas por la aplicación, es decir, estemos por así decirlo online. Pero no asocia las estaciones a los puntos de acceso, solo te muestra lo que en ese momento esta detectando, todos los AP y las STA del canal de captura elegido. Por lo tanto solo permitirá hacer ataques a los nodos visibles en ese momento, pero podemos cometer el error de mandar una desautentificación incorrecta, por que el cliente elegido puede no estar asociado al nodo principal que hemos escogido. Lo único que puede pasar es: nada. En mi caso selecciono "MIap", y en la ventana de "Direcciones de Clientes" selecciono "mi54g". Estos alias se crearon en la ventana de "Nodos" donde se definían los puntos de acceso como "AP" y los clientes como "STA".

Vemos el canal actual, que esta seleccionado y capturando. Definimos el numero de paquetes a enviar y el intervalo entre cada paquete. Decir que, un solo envió de paquetes puede ser mas que suficiente.

También podemos definir si queremos realizar una denegación de servicios masiva a todos los clientes mediante selección de "Enviar a todos los clientes" o bien fijar la casilla "Enviar a clientes seleccionados", en ese caso marcaremos a los clientes que queremos desautentificar, en este caso fijare mi cliente único, que como ya dije es "mi54g".

Para realizar una desauntetificación completa, agresiva y total, podemos marcar "Enviar a todos los clientes", definir el numero de paquetes a enviar y aumentar el intervalo en milisegundos. Esto realmente es una putada si se hace para redes de terceros, y rotundamente si lo hacéis tendréis mi desaprobación y solo os podrán llamar "niñatos lammers", con un solo paquete es suficiente para desautentificar brevemente a un cliente y obtener los resultados deseados, pero como lo vais a probar solo con vuestras redes, podéis hacerlo el numero de veces que queráis, no así con redes de terceros, donde no debéis ni siquiera de hacer un simple ataque de denegación de servicios Wireless, porque además ya no esta de moda. Y recordad que no todos los clientes pueden que estén asociados al AP seleccionado.

Solo quedaría pulsar el botón "Enviar Ahora". Como veis es la mar de sencillo.

Como comprobamos que es efectivo este ataque, muy simple, tenéis varias formas, vamos a verlas:

Veamos el icono de conexión Wireless de nuestro ordenador, o sea en la barra de estado del Windows.

Antes de efectuar la desauntetificación:

Todo esta correcto, efectuamos el ataque 0 y:

Como el ataque es muy breve enseguida tendremos de nuevo:

Ya que Windows se recupera de forma automática.

Nota: A veces cuando estamos usando el Messenger notamos que nuestra conexión se pierde momentáneamente y en seguida se recupera, si la instalación es correcta y la cobertura es buena y no estamos en movimiento, pensar que ha sido "algún graciosillo" que esta intentado comprobar como funciona este programa sin hacerlo en sus propias conexiones.

Otra forma de verlo, es realizando un ping constante mediante la consola del sistema, par acceder a ella por si no lo sabéis ejecutar "cmd" en la opción de "Ejecutar" habilitado en el Menú de Inicio de vuestro escritorio Windows.

Veis la información que aparece entre medias, eso es debido a que la desauntetificación se ha realizado con éxito. En el caso de la reinyección de trafico que trataremos después, si realicéis una inyección con un numero de paquetes por segundo muy elevado, también produciréis micro cortes en las conexiones, y depende del router incluso se puede llegar a reiniciar. Perdiendo totalmente la conexión y por lo tanto la reinyección de trafico ya que el punto de acceso dejara de responder a nuestras peticiones.

Existe otra forma que yo habitualmente uso y es detectar las interferencias momentáneas localizadas en un vigila-bebe.

También puede notarse con una "radio" normal y corriente aunque las frecuencias de trabajo sean diferentes. Esto me lo acabo de inventar, pero probarlo y a ver que pasa.

Nota importante: Veis que este proceso es muy simple, y así lo es, pero justo en el momento de desautentificación y autentificación automática posterior han pasado cosas muy interesantes y que podemos interpretar. Luego las analizaremos.

Si la aplicación no esta en modo de captura, al ordenar el comando "Enviar ahora" aparecerá el siguiente mensaje;

Deberemos pulsar OK, y posteriormente pulsar el botón de "Play" o iniciar captura a través de la barra de menús. Con la siguiente visualización en pantalla:

Antes de iniciar la captura hay que tener en cuenta en el canal que se esta trabajando. No solo para este tipo de ataques sino también para la reinyección de trafico y para todas las capturas en general.

Pulsamos el botón de "Capturar" y ahora ya podemos iniciar nuevamente la "Reasociación de nodo":

Y seguidamente:

Recordad que solo se mostraran los AP y estaciones online que se detecten en ese mismo canal.

También podemos realizar este tipo de ataque de una manera diferente, la cual me gusta mucho ya que permite controlar de forma mas directa los procesos que tiene lugar en las comunicaciones Wireless. Es decir podemos generar nosotros mismo un paquete para desautentificación de un cliente con solo saber el BBSID (dirección MAC del punto de acceso) y la MAC del cliente. Para saber si una estación es cliente de un AP solo hay que mirarlo en la pestaña de "Paquetes" y interpretar los mensajes y paquetes, pero es realmente fácil pero que muy fácil de ver, basta con observar si se producen algunos mensajes de la siguiente forma. AP--->STA, o STA--->AP, y siempre con nuestro color favorito como color del texto, como indicador de que el dato es bueno, luego lo veremos.

Para realizar este forma manual de denegación Wireless, usamos la barra de menú y:

Nos desplazamos hasta "Herramientas" y seleccionamos "Generador de paquetes", nos saldrá la pantalla de "Generador de paquetes" la cual podemos configurar para enviar todo tipo de paquetes de forma manual. Vemos como he configurado el paquete yo mismo para desautentificar al cliente:

El tamaño de un paquete de desautentificación de un cliente siempre es de longitud 26, pues eso es lo primero que tendremos que hacer.

Tenemos 2 áreas principales, la de la izquierda sirve para interpretar el paquete creado y la de la derecha para generar el paquete.

En verde corresponde a la cabecera del paquete y en este caso siempre tiene que ser: A0 00 98 00

En azul tenemos la dirección MAC del punto de acceso, esta aparece 2 veces, y porque?Muy fácil respuesta, el destino es e mismo AP y el nombre de BSSID también es el mismo AP, no tiene mas. Ambas serian la misma dirección MAC del punto de acceso que seria en este caso: 00 13 49 00 11 22

Y el origen; pues la tarjeta cliente que actúa como "conejillo de indias", o sea su dirección MAC, la que podemos ver de color rojo, En este caso seria: 00 80 5A 33 44 55

Y la parte mas importante, lo que esta como no.... en fucsia, corresponde a una desautentificación "voluntaria" emitida por la tarjeta cliente: 90 2A 08 00, este valor debe ser siempre fijo.

He puesto entre comillas "voluntaria" por que realmente no es así, sino que es inyectado por la tarjeta que opera bajo esta aplicación.

Si traducís "Diassociated" al castellano , el resultado seria "desasociado" pero es una mala interpretación del programa, porque lo que realmente no estas es autentificado, y lógicamente tampoco asociado.

Podemos determinar los paquetes por segundo que queramos mandar, en este caso solo 1 ya que el paquete de desautentificación solo es uno, y el numero de veces que queremos realizar esta operación mediante la selección en tiempo. También podemos hacerlo "Continuamente".

Si fijamos a 5 el Tiempo(s), se mandara un forzado de desautentificación cada segundo y durante 5 veces.

Recordar que la tarjeta de ataque debe de estar iniciada en modo de captura, si no volverá a salir el mensaje:

Esto siempre es así, y realmente prefería que no lo fuera, ya que veréis que es un poco lió. Es decir se tendría que separar el modo de adaptador abierto para la captura y para la inyección. Pero es la única forma de que se indique a la aplicación en que canal estamos trabajando.

Anteriormente habíamos dejado pendiente lo siguiente: "justo en el momento de desautentificación y autentificación automática posterior han pasado cosas muy interesantes y que podemos interpretar. Luego las analizaremos".

Pues bien, ahora será el momento de hacerlo.

 

 

 

4.3 .- Obtención del handshake sobre encriptación WPA-PSK

En primer lugar citar que si estamos ante un nodo con encriptación WPA, necesitamos filtrar solo los contenidos de los paquetes e ignorar las balizas (beacons).

Y también es interesante filtrar mediante "Reglas avanzadas" el trafico de solo el nodo a analizar para la recuperación de claves WPA. El filtro pare ese nodo y todos los que queráis podéis realizarlos "Regla avanzadas"

Lo vemos:

Mirad como lo configuro:

En la formula indico que solo deseo capturar trafico que "venga de" o "vaya a" un AP determinado.

Los valores de dirección MAC pueden ser copiados con el ratón directamente en la ventana "Nodos", tal como lo vemos aquí, pero seleccionándolo en el menú contextual mediante "Copiar Dirección Física (MAC)":

También es posible en la ventana "Paquetes".  Es evidente que en esta ultima captura tenemos que desplazar el indicador del selector del ratón situado en la orden "Crear Alias..." hasta la orden "Copiar Dirección Física (MAC)".

Luego en las reglas simplemente usáis las teclas de pegar, "Control + V", aunque también podéis usar los "Alias" en la reglas, pero para este caso me parece mas profesional que aparezcan los términos hexadecimales. Solo es una manía, vosotros hacedlo como os plazca, ambas maneras son validas.

Bien resumimos, tenemos el modo de captura configurado para que solo acepte capturas de paquetes de datos, y solo captamos trafico de ese nodo en particular mediante la validación de reglas avanzadas.

Iniciamos captura como siempre, recordad botón "Play":

Indicamos en que "Canal" se debe de iniciar la captura.

Iniciamos "Capturar" y ejecutamos la desautentificación como ya sabemos hacerlo, si hemos equivocado el canal, lógicamente no tendremos los AP y clientes deseados, y si estos no están ONLINE no podremos des autentificarlos.

Volvemos a recordar la generación de paquetes de forma manual:

Tanto de una forma u de otra enviamos la reasociación de nodo y esperamos un rato. Posteriormente grabamos los paquetes obtenidos, es decir los pasamos del buffer a un fichero.

  También podéis dejar la aplicación en modo de grabación automático, y realizáis determinado ataques separados en tiempo, quizás esto ultimo sea lo mejor. En cuanto detengáis la captura, los datos de buffer pasaran al archivo si se esta en modo de guardar de forma automática. Si el guardado automático no estuviera habilitado nos dirigimos hasta la pantalla de "Paquetes" y los guardamos de forma manual.

Posteriormente usáis el "Visor de Registro", realizáis una conversión de datos a formato  tcpdump conforme a lo explicado en el manual base. Y quizás obtendréis el famoso "handshake", lo demás ya es historia y de sobras lo sabéis (me refiero a la recuperación de la contraseña WPA a partir del handshake y del uso de diccionarios.

 

 

 

4.4 .- Descubrir el ESSID oculto de una conexión Wireless (nodo)

Como ya sabemos maniobrar con el programa vamos a ser mas directos.

En primer lugar filtramos al igual que anteriormente, el trafico de ese nodo.

En segundo lugar, aceptamos en este caso, todos los tipos de paquetes excepto los paquetes de datos.

Pasamos a capturar. Y efectuamos el ataque 0 de la forma que queramos, de la forma mas fácil es así:

Y de la forma mas interesante es así:

Nos vamos a la ventana de "Paquetes" para interpretar todo lo que esta pasando.

¿que podemos ver y interpretar?

Estos datos corresponden a los primeros en realizarse después de efectuar un ataque 0 y en el momento preciso que Windows reactiva la comunicación.

Si observamos el primer mensaje MNGT/PROBE RESP. donde el origen es el punto de acceso y el destino es el cliente, en la parte de abajo nos mostrada el nombre de la red (ESSID), solo hay podemos verlo, en el caso de que este oculto.

¿Que hubiera pasado si hubiésemos aceptado también los paquetes de datos?.

Pues lo mismo, pero añadiendo los paquetes de datos encriptados que puede tener lugar la secuencia seria la siguiente:

Esta captura es muy buena y nos permite ver todo lo que pasa.

El paso numero 73 corresponde al forzado de la desautentificación, esta es la cuarta forma que tenemos para poder observar que el ataque ha sido enviado correctamente.

En el paso numero 74 podemos volver a ver el nombre de essid, y del numero 73 al 81 quizás podíamos tener guardado el famoso intercambio de claves para redes con encriptación WPA.

Nota: El ataque 0 colabora respecto a la reinyección de trafico, pero he descubierto una alternativa donde este proceso (desautentificación de clientes - ataque 0) ya no es tan prioritario, aun así lo explicaremos y matizaremos en el apartado siguiente.

 

 

4.5.- Conseguir una falsa autentificación en Windows para redes Wireless sin clientes

Como ya he dicho anteriormente mis pruebas no han sido concluyentes, y no puedo garantizar que pueda ser realizado de forma efectiva.

 

 

4.6.- Reinyección de trafico en Windows

Es muy simple pero muy eficaz. Y obviamente solo valido para encriptación WEP

Anteriormente ya hemos explicado de forma teórica como tiene lugar la reinyección de trafico en Windows, es decir necesitamos una petición de ARP encriptado desde el cliente al punto de acceso. Y aquí esta el error que muchas personas cometen al confundir los conceptos teóricos. Este paquete no puede ser generado de forma manual al igual que se puede hacer con el  ataque 0 y quizás el ataque 1. Esto se debe a que dicha petición esta encriptada.

Es un paquete especial que genera el cliente hacia su AP, los cuales si saben las claves.

Parece que no se pueda hacer nada, pues si, si que se puede hacer. Sabemos que esta petición es hecha por el cliente y además sabemos que características especiales debe de tener este tipo de petición.

Debe de ser de 68 bytes de largo, tiene como origen la propia dirección MAC de la estación (en este caso si cliente) del nodo analizado, tiene como la destinación de Broadcast (FF:FF:FF:FF:FF:FF) y tiene configurado en la cabecera el ToDS igual a True (1), pues bien con esta información ya no es suficiente.

Solo hay que analizar y observar en que momento se produce esa petición, capturarla y mandarla posteriormente al AP.

Es igual los datos que contenga y como este formada, con las limitaciones de partida podemos determinar posibles peticiones de ARPs, pues para verificar si son realmente peticiones validas, se las inyectamos al AP, esto si podemos hacerlo. Si realmente es una petición de ARP, el punto de acceso nos responderá con un IV único y valido, acelerando así el proceso de recuperación de claves WEP, otra cosa es que luego en la practica sea fácil o difícil de lograr.

Además, sabemos que "quizás" se produce esa petición tras la autenticación entre cliente y AP y es ahí donde entra en juego el Ataque 0 (al cual hemos dedicado gran parte de este manual), ya que después de realizarlo se puede producir una autenticación automática visible por nuestra tarjeta de captura, pudiendo entonces captar posibles peticiones validas e inyectarlas al AP.

Bien, como nos preparamos y como configuramos nuestra aplicación para ello, muy fácil:

Paso 1: Permitimos el trafico de cualquier tipo de paquetes.

Como siempre ignoramos los beacons (balizas).

Procedemos a configurar la captura para filtrar mediante "Reglas avanzadas" las características fundamentales que deben de tener las peticiones de ARP encriptadas por parte de los clientes validos. En este caso no será necesario filtrar el trafico de ningún nodo, ya que la posibilidad de capturar dos peticiones validas de diferentes redes en el mismo momento es muy reducida, si bien podemos  crear una regla avanzada para cumplir con todos estos requisitos.

¿Como filtro las posibles peticiones?

Lo vemos con el ejemplo siguiente:

Antes que nada pulsamos sobre el botón "Evaluar".

Tenemos ya de esta forma validada la regla, con limitación de tamaño, el broadcast y parte de la cabecera (tods)

También puede valer solo con (size = 68) and (tods=1).

Podéis probar, si queréis, sin ninguna regla mas, ya que fácilmente se observa cual es la petición de ARP. Luego lo veremos mejor, si es la primera que lo hacéis si recomiendo que uséis este regla tal como lo he explicado.

También incluso se puede probar sin necesidad de efectuar ningún ataque de desautentificación, ya que dicha petición se localizar y observar con un poco de practica. Pero es cierto que con el ataque 0 todo es mucho mas rápido.

Por lo tanto pasemos a efectuar el ataque cero, pero antes de nada un inciso. Es muy importante que después de haber localizado la petición de ARP encriptado recordad de volver a deshabilitar estas reglas y filtrar solo para recibir paquetes de datos. Es importante deshabilitar la regla (solo capturar posibles peticiones) porque sino la aplicación se bloquea sola así misma y no se obtendrás datos ningunos para la recuperación de claves WEP, o sea IV validos.

Lo vemos:

Iniciamos capturas como siempre y efectuamos el ataque 0:

En este caso, si os recomiendo usar el ataque mediante la barra de menú y no de forma manual con el "Generador de paquetes".

Vamos a la pestaña de paquetes y esperamos:

Vemos que realmente hubiera valido captando solo paquetes de datos al ser esta petición del tipo ENCR.DATA pero así podemos observar mas cosas, entre ellas si el nombre de essid oculto que ya expliquemos anteriormente.

Por lo tanto hubiera bastado con el siguiente filtro:

en lugar de:

Sea de una forma u de otra pasamos a probar si realmente es una petición de ARP encriptada valida para ese AP, podemos parar la captura para pensar lo que estamos haciendo. Yo así lo aconsejo.

Seleccionamos todos los paquetes y mediante el ratón secundario del ratón pulsamos en "Enviar paquete(s)". Este menú contextual permite la opción "Todo" o "Seleccionado", pues en este caso le decimos todos, pero podría haber sido uno en particular, ya que cada uno corresponde a una velocidad de transmisión diferente, quizás sea recomendable mandar el de menor velocidad por si la cobertura entre AP y STA no es muy buena.

Vemos la opción "Enviar Paquete(s)" --------->"Todos".

Y después de elegir ese opción, no mostrara una pantalla tal como esta:

El numero máximo esta situado en 2000 paquetes por segundo (es recomendable bajarlo).

Seleccionamos "Continuamente" y enviamos mediante el botón "Enviar", pero antes, no olvidemos de deshabilitar las reglas avanzadas de filtrado para que la aplicación no se anule así mismo. Y filtramos para aceptar solo paquetes de datos.

Si no anulamos la regla de petición de ARP, seguirá a la espera de peticiones de ARP. Y anulara la captura de todo el resto de trafico.

Por lo tanto deshabilitamos las reglas avanzadas tal que así:

Podéis añadir la regla avanzada para que solo capture trafico de un nodo en particular.

Comprobamos que el filtro de paquetes solo permite la captura de datos ignorando las balizas, los paquetes de administración y de control.

Iniciamos captura en canal correspondiente:

Fijamos la cantidad de paquetes por segundo, seleccionamos la opción de enviar "Continuamente".

A continuación ya podemos enviar los paquetes mediante el botón "Enviar".

Y como resultado quizás obtengamos una buena reinyección de trafico.

Si observamos cada uno de ellos, veríamos un IV diferente y valido para cada fila, esto es síntoma de que la reinyección de trafico ha tenido éxito. Observar en vuestro equipo como el numero de líneas cambia su ritmo a un o mucho mas mayor.

¿Como puedo hacer lo mismo sin necesidad de utilizar la desautentificación o reasociación de nodo?

Partimos de la base que ya sabemos como esta compuesta este tipo de peticiones, pues podemos hacerlo sin necesidad de desautentificar (ataque 0) a ningún cliente. Y como lo hacemos:

Primero, nada de reglas.

Segundo: solo paquetes de datos.

Iniciamos captura como siempre en el canal especificado:

Cuando veamos algo parecido a ENCR.DATA con origen en cliente (STA), tamaño 68 según la columna y destino Broadcast, pues paramos la captura. Fijaros bien que en "Mas detalles" nos indica WEP-Can't decrypt. Recordad que este tipo de peticiones no se puede generar de forma automática. Pero una vez capturada, quizás si puedas reinyectar trafico.

Si comparamos con los datos de partida a priori parece una posible una petición valida.

Pues seleccionamos exclusivamente estas líneas de paquetes. Y los preparamos para enviar o inyectar (este paso ya esta explicado anteriormente). Recordad que puede ser interesante solo mandar la petición de velocidad mas baja.

Volvemos a iniciar la captura como siempre (cuando tengáis practica no necesitareis parar tantas veces el proceso de captura)

Y inyectamos de la forma que explique antes:

Si realmente era una petición buena, enseguida lo veremos, si no es así, volverlo a probar.

Durante el proceso de reinyección podemos para el proceso y ver como reacciona la captura de paquetes (los que se muestran casi instantáneamente en la pestaña de "Paquetes".

También es posible observar como reacciona la captura solo a reinyecciones parciales. El numero de reinyecciones parciales se limita o se fija en la casilla "Tiempo(S)".

En cualquier fila de color fucsia que indique ENCR.DATA, podéis observar en el área inferior de la pantalla un IV.

Siempre serán de 6 dígitos hexadecimal, o sea 4bits para cada dígitos hexadecimal, en total siempre 24 bits. Recordad el tema de claves explicados en la pagina de complementos del conversor universal, recordad que comentábamos que solo se usaban 40 bits y 104 bits reales para encriptación WEP de 64 y 128, pues hay tenéis la diferencia de bits, lo que corresponden al vector IV, que se emiten de forma publica y que con un cierto trafico capturado permiten la recuperación de claves WEP.

Si tenéis problemas para realizar este último proceso, no dudéis en usar el ataque 0, y gestionar las reglas que creáis oportunas.

Y como me gusta contrastar los resultados, os paso una captura de la tercera tarjeta que usaba como informe adicional y validación de resultados. Si disponéis de un numero de tarjetas validas y adecuadas podéis comprobar con se paralizan los "Data" en el airodump y como vuelven a aumentar si reiniciamos el envió de las peticiones validas de ARP encriptados al punto de acceso. O si solo enviamos un solo paquete o varios.

Además para mayor seguridad limitar a cero el trafico entre vuestra tarjeta y vuestro punto de acceso, así verificáis que la reinyección de trafico es correcta.

Aunque dispongáis de un buen punto de acceso, probar también de realizar un ping y quizás observareis que el punto de acceso no responde en un 100% a todos ellos, ya que esta muy ocupada enviando respuestas a las peticiones realizadas por el envió de paquetes con petición de ARP encriptado.

¡conseguido la inyección de trafico en Windows!

Afirmamos que se puede inyectar trafico en Windows de forma correcta, por lo tanto el nivel de seguridad de la redes Wireless sobre todo con cifrado WEP son accesibles tanto en Windows como Linux de forma muy rápida. Si bien Linux sigue siendo el mejor sistema operativo para analizar el estado de tus redes inalámbricas.

Para el posterior trato de las capturas de datos realizadas durante la reinyección de trafico y exportarlas a otros formatos (por ejemplo a formato compatible con tcpdump), recordad de leer el manual básico del Commview donde se explica la forma de hacerlo y las aplicaciones externas a este programa que se deben usar para la recuperación de contraseñas WEP/WPA.