Got the same error.

The solution was simply to unload the RTL8187 and Load the R8187 driver instead as follows:

root@Blackbox:~/fakeap# rmmod rtl8187 root@Blackbox:~/fakeap# modprobe r8187

Tried putting wlan In monitor mode again

root@Blackbox:~/fakeap# airmon-ng start wlan1 Found 1 processes that could cause trouble. If airodump-ng, aireplay-ng or airtun-ng stops working after a short period of time, you may want to kill (some of) them! PID 1558 Name dhclient Chipset RTL8187 Driver r8187 (monitor mode enabled)

Interface wlan1

Well, that fixed the problem

root@Blackbox:~/fakeap# iwconfig lo eth3 wlan1 no wireless extensions. no wireless extensions. 802.11b/g Retry:on Mode:Monitor Channel=10 Bit Rate=11 Mb/s

Tx-Power=5 dBm Fragment thr:off Signal level=50 dBm Rx invalid crypt:0 Invalid misc:0 Noise level=-156 dBm Rx invalid frag:0 Missed beacon:0 Link Quality=0/100 Rx invalid nwid:0

Tx excessive retries:0

Now we can proceed to the fake ap setup process 1. Install a DHCP Server

apt-get install dhcp3-server

2. Edit /etc/dhcp3/dhcpd.conf as follows (You can change ip address, pool and dns server as needed):

ddns-update-style ad-hoc; default-lease-time 600; max-lease-time 7200; authoritative; subnet 10.0.0.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option broadcast-address 10.0.0.255; option routers 10.0.0.254; option domain-name-servers 8.8.8.8; range 10.0.0.1 10.0.0.140; }

3. Put your wlan in monitor mode

airmon-ng start wlan1

4. Start airbase-ng, you will need to specify the AP SSID and channel number

airbase-ng -e FreeWifi -c 11 -v wlan1 &

5. Airbase will create a new adapter at0 you will need to enable it and ass ign it with an ip address and subnet mask, the ip address you assign to this interface will be the default gateway that you specified in the dhcpd.conf file.

ifconfig at0 up ifconfig at0 10.0.0.254 netmask 255.255.255.0

6. Add a route

route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.254

7. Setup ip tables

iptables --flush iptables --table nat --flush iptables --delete-chain iptables --table nat --delete-chain iptables -P FORWARD ACCEPT

Eth3 is my external interface which is connected to the internet change it to whatever yours is

iptables -t nat -A POSTROUTING -o eth3 -j MASQUERADE

8. Clear dhcp leases

echo > '/var/lib/dhcp3/dhcpd.leases'

9. Create a symlink to dhcpd.pid (skipping this may cause an error when starting dhcp server)

ln -s /var/run/dhcp3-server/dhcpd.pid /var/run/dhcpd.pid

10. Start the DHCP server

dhcpd3 -d -f -cf /etc/dhcp3/dhcpd.conf at0 &

11. Dont forget to enable IP forwarding

echo "1" > /proc/sys/net/ipv4/ip_forward

Thats All Folks!

Wireless Hacking Evil Twin y Ataques MITM sobre SSL Parte VI

abril 4, 2012adastraDeja un comentarioGo to comments

1 Vote En una entrada anterior de este blog se ha mencionado el uso de airbase-ng para crear un SoftAP que permita a cualquier cliente conectarse a dicho AP como si se tratase de cualquier router, (ver el post aqu: http://thehackerway.com/2011/04/28/creando-un-fakeaccess-point-inalambrico-2/) la finalidad de crear un softAP desde el punto de vista de un atacante, es simplemente tener acceso al trafico de sus clientes, permitindole realizar ataques MITM. En este caso concreto, la tcnica conocida como Evil Twin se basa en el hecho de que pueden existir dos AP con el mismo SSID y que utilizando utilidades como aireplay-ng se pueden enviar paquetes de DeAuth a todos los clientes conectados a un AP determinado, lo que al final puede desembocar en un ataque de denegacin de servicio. Cuando un cliente se encuentra conectado en una red HotSpot, por ejemplo en un aeropuerto, un bar, un restaurante, un MacDonalds, normalmente no existen mecanismos de autenticacin intermedios, es decir, son redes que normalmente se encuentran abiertas al publico en general, lo que facilita enormemente las cosas a un atacante. Como ya se ha indicado anteriormente, cuando un cliente recibe un paquete de DeAuth por parte del AP (supuestamente del AP, pero que en realidad puede proceder de cualquier sitio) el cliente intenta realizar una reasociacin con el AP, dado que este tipo de situaciones pueden ser el resultado de problemas con la seal, por esta razn el cliente intentar por un determinado periodo de tiempo establecer nuevamente la conexin con el AP, cuya nica huella identificativa desde el punto de vista del cliente, es el SSID, si un atacante enva de manera continua e indefinida paquetes de deautenticacion a un cliente hacindose pasar por el AP, el cliente finalmente tendr que finalizar sus intentos de reasociacin dado que los paquetes recibidos por parte del atacante indican que el AP no se encuentra en disposicin de aceptar conexiones. En este punto el atacante perfectamente podr crear su propio SoftAP (tal como se indicaba en el enlace anterior) estableciendo si lo desea, un servicio DHCP para la asignacin automtica de direccin IP a dicho cliente, si el atacante establece como SSID, el mismo nombre empleado por AP original, es posible que el cliente realice una conexin con el SoftAP del atacante en lugar de hacerlo con el AP original, no obstante, para que esto ocurra, la potencia de la seal del SoftAP debe ser mayor a la potencia del AP original (con lo cual, un atacante podr utilizar mecanismos fsicos para mejorar la potencia de la seal, como por ejemplo utilizando una antena dirigida), de esta forma, el cliente encontrar primero el SoftAP y creer que se trata del AP original, en el caso de que esto no ocurra, el atacante tendr siempre en ejecucin su ataque de DeAuthentication contra el AP, lo que impedir que el cliente consiga una asociacin y lo que le obligar a seguir buscando hasta que el AP o cualquier dispositivo de software o hardware con el mismo SSID sea localizado. Este modelo es una falla de seguridad muy frecuente y fcilmente explotada por cualquier tipo de atacante sin necesidad de que cuente con un nivel de conocimientos profundo sobre redes. Para demostrar esto con un ejemplo practico, seguir los siguientes puntos, asumiendo queWLAN_7188 en el SSID del AP original, 64:68:0C:45:71:BB es el BSSID (direccin MAC) del AP. 1. Con una interfaz en modo monitor, que en este caso es mon0 recibir Beacon frames del AP utilizando airodump-ng

>airodump-ng channel 3 bssid 64:68:0C:45:71:BB mon0

2. Se asume que el canal del AP es el 3. 3. Establecer las interfaces en dicho canal.

>iwconfig wlan0 channel 3 >iwconfig mon0 channel 3

4. Iniciar el Evil Twin notar que es simplemente un Fake AP, tal como se ha comentado en una entrada anterior de este blog con el mismo SSID del AP real, una vez se inicia dicho Fake AP es necesario iniciar la interfaz virtual creada.

>airbase-ng -a CA:CA:CA:CA:CA:CA -e WLAN_7188 mon0 >ifconfig at0 up

5. Iniciar el ataque de denegacin de servicio contra el AP objetivo, para ello se enviarn paquetes DeAuth de forma indefinida contra todos los clientes de dicho AP (lo que posteriormente les obligar a intentar re-conectarse en mltiples ocasiones

>aireplay-ng deauth 0 -a 64:68:0C:45:71:BB mon0

6. Una vez establecidos los pasos anteriores, solamente es necesario esperar unos instantes y se podr ver, como en la consola donde se ha iniciado el Evil Twin comenzarn a llegar las conexiones de los clientes que intentan asociarse nuevamente con el AP real, pero que al no poder, terminan asocindose con el Fake AP, que dado que tiene el mismo SSID, a efectos prcticos para el cliente son el mismo AP.

23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188 23:46:54 Client 44:A7:CF:47:82:88 reassociated (unencrypted) to ESSID: WLAN_7188
Por que ocurre esto? La respuesta es que los clientes, en ningn momento buscan autenticarse con el cliente, ellos solamente buscan un SSID que coincida con el estn buscando, eso es todo, por esta razn no encuentra diferencia alguna entre un AP con cifrado a uno sin ningn tipo de seguridad, de igual forma intentar conectarse al AP que tenga el SSID de bsqueda y que tenga una intensidad en la frecuencia mayor, eso es todo lo que busca un cliente. Esto e un problema del protocolo de comunicaciones empleado ya que solamente existe autenticacin por un lado (el AP) sin embargo el cliente nunca verifica que el AP es quien dice ser. Esto se solucionara simplemente con un mecanismo de autenticacin mutua entre cliente y AP.

Ahora bien, esta no es la nica falla en el proceso que utilizan los clientes para acceder a redes inalmbricas, dependiendo del sistema operativo, muchos clientes almacenan localmente las conexiones que han realizado contra otros AP, almacenando en dichos repositorios el SSID y la clave del AP. Por defecto los clientes cuando tienen uno o varios AP almacenados en el repositorio de conexiones del sistema, intentan de forma automtica (nuevamente dependiendo del sistema operativo del cliente y sus correspondiente configuracin) realizar pruebas de conexin, enviando los paquetes que se han mencionado anteriormente para el descubrimiento de APs cercanos, estos paquetes son los PROBE REQUEST, de esta forma, un cliente de forma automtica enva paquetes PROBE REQUEST a todos los AP que se encuentren almacenados en su repositorio de conexiones, de esta forma y en el caso de que algn AP responda a dicha prueba con un paquete PROBE RESPONSE, el cliente automticamente intentar realizar una asociacin con dicho AP, luego el AP ser el que determine si el cliente se puede conectar o no dependiendo del esquema de autenticacin establecido. Esto que significa? Pues ocurre lo mismo que con Evil Twin, en cualquier momento se puede iniciar un AP falso utilizando un SSID conocido por el cliente y este a su vez, intentar conectarse de forma automtica y sin interaccin con el usuario, con el AP que tenga el SSID solicitado, si dicho SSID es prestado por AP malicioso, el cliente puede estar corriendo un serio riesgo. Adems de lo anterior, tambin es importante resaltar que con herramientas como airbaseng, se puede iniciar un Fake AP de tal modo que responda a TODOS los paquetes PROBE REQUEST que los clientes que se encuentran alrededor envan cuando se quieren conectar con un AP, el resultado de esto es que los clientes que tengan varias conexiones almacenadas enviarn paquetes PROBE REQUEST por el canal Broadcast y el Fake AP responder a TODOS los paquetes, con lo cual el cliente tendr la sensacin de que ha realizado una conexin a todos los AP en su lista. Un cliente (una tarjeta wireless) solamente puede tener una conexin con un AP al mismo tiempo, del mismo modo que solamente puede estar en un nico canal a la vez, por esta razn, lo ms probable es que con un AP configurado para contestar a todas las peticiones, los clientes tendrn problemas para resolver a cual AP se deben conectar e intentar conectarse a todos de forma intermitente. Para ejecutar el Fake AP en dicho modo y responder a todas las peticiones de SSID, se ejecuta el siguiente comando con airbase-ng

>airbase-ng -v -a AA:AA:AA:AA:AA:AA -P -C 15 mon0

En el comando anterior, puede apreciarse que en primer lugar no se ha establecido ningn SSID, esto es porque va a responder a las peticiones de cualquier cliente solicitando cualquier SSID, luego la opcin -v es indicada precisamente para apreciar que es exactamente lo que esta pasando (cuales peticiones de SSID se han resuelto y por cual cliente)

ATAQUES MITM SOBRE CONEXIONES SSL

Tomando como punto de partida los ejemplos que se han indicado anteriormente sobre la creacin de un SoftAP, utilizando la tcnica de Evil Twin o simplemente dejando abierta la red sin ningn tipo de autenticacin y esperando a que otros clientes se conecten. Tener a clientes que se conectan a una mquina controlada por un atacante, le da la oportunidad a este de realizar ataques interesantes que pueden llevar a comprometer completamente las comunicaciones que un usuario realiza de forma segura por internet, utilizand o servicios tales como HTTS/SSL/TLS para realizar el cifrado end-to-end con el servidor web. Para ello se puede seguir la metodologa de ataque que se indica a continuacin

El principio fundamental de este tipo de ataque radica en la capacidad que adquiere el atacante sobre la navegacin de sus vctimas, pudiendo controlar las peticiones DNS sobre servidores web y posteriormente haciendo entrega de certificados falsos a estos para que sea posible establecer la comunicacin cifrada contra el servicio real en internet. En este caso concreto el flujo de los paquetes es el siguiente: 1. La vctima, que se encuentra conectada al AP del atacante, solicita la conexin con un sitio en internet (un sitio con Soporte SSL/TLS en este caso) para iniciar sesin de forma segura, dado que para ello es necesario resolver el nombre del dominio, es necesario que el cliente realice una consulta DNS, para ello el SoftAP tendr un servidor DNS falso que retornar la direccin IP del atacante 2. El cliente recibe como respuesta una direccin IP que presumiblemente es la direccin del servicio en internet al que intenta conectarse, no obstante, en realidad es la direccin IP del atacante. 3. El atacante recibe una peticin en el puerto 443 (HTTPS) la cual ser controlada por Burp Suite (se hablar en mayor profundidad sobre Burp en prximas entradas sobre Web Hacking) el cual generar un certificado falso y lo enviar al cliente 4. La vctima, recibe una advertencia sobre un certificado del que no es posible verificar su identidad, si la vctima acepta el certificado de todas formas, la navegacin hacia el sitio remoto ser exactamente igual a como lo hace siempre, sin embargo todos los paquetes que envi (aunque utilice SSL) pasan por medio del atacante y son visualizados en texto claro, dado que el certificado utilizado por el cliente para la conexin es del atacante y este tiene la clave privada para descifrar dichos paquetes, con lo cual ver absolutamente todo (incluyendo passwords) en texto claro. Esta es la metodologa utilizada para realizar un ataque contra clientes que utilizan SSL en sus comunicaciones con otros servidores web, a continuacin se indican los pasos que se deben llevar a cabo para implementar todo esto: 1. Iniciar un Fake AP el cual tendr configurado un servicio DHCP para asignar a cada cliente una direccin IP, de tal forma que pueda continuar navegando sin problemas por internet utilizando la conexin a internet que tiene el atacante, para llevar a buen termino este paso se recomienda ver la entrada anterior en este blog donde se habla de como hacerlo aqu: http://thehackerway.com/2011/04/28/creando-un-fake-access-point-inalambrico-2/ 2. Una vez iniciado el AP y establecido las reglas del firewall correspondientes al correcto enrutamiento de los paquetes por medio de la interfaz de salida a internet, se procede a iniciar el servicio de DNSSPOOF, el cual resolver todas las peticiones DNS del cliente con la direccin IP del atacante, para ello es necesario tener instalada la suite DSNIFF la cual se puede obtener aqu: http://monkey.org/~dugsong/dsniff/ para conocer un poco ms sobre esta suite, aqu hay un articulo introductoriohttp://thehackerway.com/2011/03/29/tecnicasbasicas-de-sniffing-y-mitm/Ahora bien, para iniciar DNSSpoof solamente es necesario iniciar

una nueva consola y ejecutar esta utilidad, la cual en realidad es muy sencilla, las opciones que se incluyen son:

>dnsspoof help dnsspoof: invalid option - Version: 2.4 Usage: dnsspoof [-i interface] [-f hostsfile] [expression]
3. Como puede apreciarse, se debe indicar una interfaz de red y un fichero, el cual tendr la misma forma que el fichero de hosts de Linux. En el caso de que no se especifique un fichero de host, todas las peticiones DNS sern resultas con la direccin IP del atacante.

>dnsspoof -i at0 dnsspoof: listening on at0 [udp dst port 53 and not src 192.168.2.129]
4. En este caso la interfaz de red at0 es la interfaz del Fake AP. 5. Ahora es el momento de manipular e inyectar el trafico de la vctima utilizando Burp Suite, esta herramienta es una plataforma integrada para ejecutar pruebas de seguridad sobre aplicaciones web, contiene algunas opciones que permiten capturar, controlar y enrutar las peticiones realizadas por clientes utilizando HTTP/HTTPS. El objetivo de esta entrada no es profundizar sobre Burp Suite, esto es algo que se har prximamente en este blog. En primer lugar es necesario descargar la versin libre de esta herramienta desde aqu: http://portswigger.net/burp/download.htmlPara utilizarla solamente es necesario descomprimirla y ejecutar el fichero JAR incluido en ella. Es necesario tener una versin de Java instalada que sea como mnimo la 1.5

>java -jar burpsuite_v1.4.01.jar

6. Ahora es necesario comenzar a configurar el proxy que servir para realizar el paso final del ataque, esto se har desde Burp en la pestaa Proxy options la configuracin necesario puede apreciarse en la siguiente imagen

Como puede verse, se han establecido los puertos 80 (HTTP) y 443 (HTTPS) para recibir peticiones de los clientes que se conecten a un sitio web seguro o no seguro, en todos los casos Burp interceptar las comunicaciones, por otro lado tambin se generan certificados autofirmados con el fin de establecer conexiones seguras con HTTPS pasando por la mquina del atacante y finalmente al sitio web seguro.

7. Cuando un cliente intente contactar con cualquier sitio web, la pestaa Intercept se activar automticamente capturando los encabezados de la peticin y todos los datos que se han ingresado, en el caso de un sitio con HTTPS todos los datos sensitivos como claves y nombres de usuarios se vern en texto claro. Aunque en este vector de ataque se ha utilizado DNSSpoof, es perfectamente valido utilizar otras herramientas como por ejemplo Ettercap con su plugin dns_spoof, cualquiera de los dos mecanismos puede ser empleado con xito para la manipulacin de peticiones DNS.