This is probably my first real tutorial. I will try to write it the way I would like to read a tutorial (:
I'm not quite sure the explanation of what airbase is doing is correct as there isn't that much documentation at the time being, so
verification/correction would be greatly appreciated together with comment's in general maybe also towards the script. Enjoy
Tools of trade:
dhcpd (Our dhcp server)
Airbase-ng Included in the latest Aircrack-NG. Make sure you get the latest before attempting this. (fast-track -> update -> aircrack-ng)
Ettercap (Our sniffer)
All contained in BackTrack3 final, just remember to update Aircrack
First off, make sure that your wireless card supports injecting.
Secondly, I had an extremely hard time getting airbase-ng to work. Clients could connect to the rogue AP, but the data seen in Wireshark on the at0 interface shows nothing else than "Malformed Data". I found out that booting BackTrack3 properly instead of running it through vmware fixed the problem. So keep that in mind if you are using VMWare and it won't work (just remember to check Wireshark first to confirm). Also, a lot of the troubleshooting being done with airbase-ng is often linked with the MTU of both the wireless interface, and the at0 interface. The script is hardcoded to change the MTU to 1400 on at0, you may wan't to do some additional research with MTU and airbase if experiencing problems.
Thirdly, please go far far away if you have bad intentions. I see this as a hobby and an opportunity to learn and have fun with friends when they borrow my wifi :b. Respect the law and other people's privacy Also, a BIG also, running this script without removing the -P and -C 30 with wifi equipment nearby, not owned by you, actually means committing a crime in most countries. Keep that in mind before attempting anything!
I made this script that executes the entire attack, read every line find out what is happening.
The only prerequisite is that you edit /etc/dhcpd.conf to reflect this configuration: http://pastebin.com/f1859fad7 and that you have another interface, for example eth0 which has access to the internet. (The script will ask you which interface). *Note: I haven't tested using another wireless defice to forward the internet, only an ethernet device - so it may or may not work.
I chose to use Open DNS as the domain name server to avoid configuration of a dns on the rogue access point. Lazy??
The scenario is this:
The attacker configures a rogue access point that will have 3 ways of attaining clients.
"airbase-ng -e "Free WiFi" -P -C 30 -v wlan0"
1. The Rogue AP created by airbase, will name the ESSID to whatever you choose when running the script. This could be for example "Free WiFi" that may tempt people to connect.
2. The Rogue AP will respond to all probes from clients regardless of the ESSID. In other words, if there is an accesspoint nearby named "Bush Network", when a client attempts to connect to that network he will first send a probe. If we get lucky, airbase-ng will respond to this probe quicker than the legitimate access point resulting in the client connecting to OUR ap.
Running disassociation attacks simultaneously on other access points is a very effective way of making clients connect to your rogue access point. Compare it to gaining a WPA handshake, instead of waiting for the client to connect to a random AP, you disassociate and hope the client is configured to connect automatically. But I haven't had luck doing that with the same network card without creating a lot of lag on the access point, using another network card worked although.
3. The Rogue AP will begin broadcasting the same ESSID's of the captured broadcast probes from other Access points (or other Windows boxes probing for a certain AP), tricking the client to connect once again. This option may pressure your network card pretty much so you may choose to leave it out if you experience an unstable rogue AP.
Once the clients are connected they will receive an IP address through the dhcp server, and a DNS configuration pointing to Open DNS to resolve. The script will also ask you when it starts which interface is connected to the internet (for example eth0), to properly configure the IP forwarding between your rogue AP and the Internet.
The script will then start ettercap and listen on at0 which is the interface that airbase-ng created. All traffic will be manipulated by it. So just like when ARP poisoning, ettercap will setup fake SSL certifications and you could also try playing with some filters. Ettercap is the tool that will filter all the traffic going through the access point and extract all passwords and other valuable information. You could also use other various tools such as dsniff, urlsnarf, msgsnarf etc. on the at0 interface. You could also fire up Wireshark and listen on at0 to capture everything. I logged onto the rogue AP with another computer and my Gmail password was easily sniffed, but if you've played with ettercap before - nothing new. But hope you liked the read, feel free to say whatever you wan't!
Conclusion: Even though WPA is near impossible to crack when using a strong key, a rogue AP can easily trick clients to connecting to the wrong AP without them even knowing! Also, use your imagination. You own the network, you can do whatever you want. Run your own dns pointing legitimate domain names to phishing sites, try karmetasploit, evilgrade, run a filter in ettercap telling people that even though this AP is unencrypted, connecting to it is still a crime, or save the script for school time when wifi crashes and people wan't to get online! (just remember to comment out the ettercap part )
Oh and by the way, I learned all of this bit by bit here at our forums and other places (except ettercap on a tun/at*, yipee ), this is more of a summarization than me doing anything wonderful. So respect to the people who helped out (:
Additional reading and related content:
Configuring IP Tables to NAT = share internet
Wireless Key Harvester
bt ~ # man ettercap
Rogue Access Points
Rogue AP Detection
Karmetasploit (at bottom, read about MTU)
Airbase MTU bug ticket
Further replies in this thread