Rogue Accesspoint + MitM Sniffing tutorial

[imported_Deathray]

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 Script:
http://pastebin.com/f3a400f76 (5/01-09)

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"
-e
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.
-P
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.
-C 30
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:
Airbase-NG
Karmetasploit
Configuring IP Tables to NAT = share internet
Wireless Key Harvester
bt ~ # man ettercap
Dsniff suite
EvilGrade
Rogue Access Points
Rogue AP Detection
Troubleshooting, MTU
Karmetasploit (at bottom, read about MTU)
Airbase MTU bug ticket
Further replies in this thread

[imported_=Tron=]

Thank you for the write up, will have to try it out as soon as christmas is over and I get some free time on my hands again. Never had any luck playing with ettercap on an at interface, neither using it to bridge the connection or simply sniff the traffic, but might just have overlooked the -p setting to disable promiscuous mode.

Apart from that I have not noticed any restrictions using airbase-ng under VMware, and do not recall seeing any malformed packets using wireshark, but guess I will have to look into this some more.

[imported_Deathray]

Thank you for the write up, will have to try it out as soon as christmas is over and I get some free time on my hands again. Never had any luck playing with ettercap on an at interface, neither using it to bridge the connection or simply sniff the traffic, but might just have overlooked the -p setting to disable promiscuous mode.

Thank's for the comment (: , yeah I believe a lot of people have had trouble using ettercap on an at interface and I myself had a really hard time getting it to work. Ettercap likes manually configuring ip forwarding which makes it so hard to get right. I got this crazy idea which luckily made it work.
If you use the -p to disable promiscuos mode ettercap will still go in and deactivate ip forwarding for some reason. So as long as you execute echo "1" > /proc/sys/net/ipv4/ip_forward after starting ettercap with -p, it works great

Apart from that I have not noticed any restrictions using airbase-ng under VMware, and do not recall seeing any malformed packets using wireshark, but guess I will have to look into this some more.

It might just be me, but I definitely couldn't get it to work no matter what I did for some reason :S I'll edit the tutorial to point out it most likely is just me

[imported_=Tron=]

Thank's for the comment (: , yeah I believe a lot of people have had trouble using ettercap on an at interface and I myself had a hard time getting it to work. Ettercap likes manually configuring ip forwarding which makes it so hard to get right. I got this crazy idea which luckily made it work.
If you use the -p to disable promiscuos mode ettercap will still go in and deactivate ip forwarding for some reason. So as long as you execute echo "1" > /proc/sys/net/ipv4/ip_forward after starting ettercap with -p, it works great

Sounds promising. It really bugged me that I couldn't get this tool to work as I wanted, as it at least on paper is the ideal situation as you play the role of the man in the middle by default. Still don't get why ettercap won't pick up any credentials when used to bridge the at and the normal interface together though. Used in this manner it is supposed to take over the role of the iptables and perform all the forwarding by itself, which it happily did, but for some reason seemed to forget to actually sniff any passwords during the process.

It might just be me, but I definitely couldn't get it to work no matter what I did for some reason :S I'll edit the tutorial to point out it most likely is just me

As I said I will have to look into this a bit closer to be 100 % sure, but I have been playing with airbase-ng quite a bit under VMware without noticing any problems.

[StriperTS]

Thanks for documenting your attempts.. I'll give it a go later. I also noticed Malformed Packets when trying this same thing earlier.. I thought it was my Alfa card or something wrong with Airbase, but I was running in VirtualBox. Interesting if it is tied to a problem/limitation with virtual machines.

I think you have a typo in your script, on line 9, you have "airebase-ng" instead of "airbase-ng".

You can also delete "ifconfig lo up" as I think another forum member had posted that they cut and pasted something out of their configuration and it wasn't necessary for it to work. Its not doing anything bad as-is, but might save you a few questions.

While I'm picking nits, its a little confusing that you named your variable with the Internet interface "WLANIFACE" and your Wireless interface "IFACE".

Again, I think your script will work as is, but it might be confusing to others.

Thanks for posting!

-- Tom

[Revelati]

For anyone using an ALFA card you must set the MTU values to 1500 or you will get DNS errors when clients try to surf over your fake AP.

Use DNS spoofing and a forced update/evilgrade disguising a rootkit for "maximum pwnage"

You can also combine this with WINE and NetworkMiner to reconstruct most types of files being transferred over the air.

A truly scary attack, hard to detect, hard to stop, almost guaranteed a shell or at least a few passwords, I love it!

More info:
http://forums.remote-exploit.org/showthread.php?t=18863 -most recent
http://forums.remote-exploit.org/showthread.php?t=18369 -2nd thread
http://forums.remote-exploit.org/showthread.php?t=17692 -original

[imported_Deathray]

Thanks for documenting your attempts.. I'll give it a go later. I also noticed Malformed Packets when trying this same thing earlier.. I thought it was my Alfa card or something wrong with Airbase, but I was running in VirtualBox. Interesting if it is tied to a problem/limitation with virtual machines.

I think you have a typo in your script, on line 9, you have "airebase-ng" instead of "airbase-ng".

You can also delete "ifconfig lo up" as I think another forum member had posted that they cut and pasted something out of their configuration and it wasn't necessary for it to work. Its not doing anything bad as-is, but might save you a few questions.

While I'm picking nits, its a little confusing that you named your variable with the Internet interface "WLANIFACE" and your Wireless interface "IFACE".

Again, I think your script will work as is, but it might be confusing to others.

Thanks for posting!

-- Tom

Thanks for the comments . I fixed the WLANIFACE to IFACE and IFACE to WIFACE, removed the ifconfig lo up from the script(I got desperate before it started working, thought this actually helped :b), and corrected the typo on line 9, killall -9 airebase-ng. I was thinking WANIFACE instead of WLANIFACE

For anyone using an ALFA card you must set the MTU values to 1500 or you will get DNS errors when clients try to surf over your fake AP.

Use DNS spoofing and a forced update/evilgrade disguising a rootkit for "maximum pwnage"

You can also combine this with WINE and NetworkMiner to reconstruct most types of files being transferred over the air.

A truly scary attack, hard to detect, hard to stop, almost guaranteed a shell or at least a few passwords, I love it!

More info:
http://forums.remote-exploit.org/showthread.php?t=18863 -most recent
http://forums.remote-exploit.org/showthread.php?t=18369 -2nd thread
http://forums.remote-exploit.org/showthread.php?t=17692 -original

Isn't it the opposite? If you leave the MTU to 1500 you get problems. That is why I manually change the MTU to 1400 in the script, as documented many other places such as aircrack-ng. 1500 is the default that will give you problems (: . I myself have the Alfa 500 mW and have absolutely no problems configured with 1400 mtu.

[imported_=Tron=]

Thanks for the comments . I fixed the WLANIFACE to IFACE and IFACE to WIFACE, removed the ifconfig lo up from the script(I got desperate before it started working, thought this actually helped :b), and corrected the typo on line 9, killall -9 airebase-ng. I was thinking WANIFACE instead of WLANIFACE


Isn't it the opposite? If you leave the MTU to 1500 you get problems. That is why I manually change the MTU to 1400 in the script, as documented many other places such as aircrack-ng. 1500 is the default that will give you problems (: . I myself have the Alfa 500 mW and have absolutely no problems

When you fire up airbase-ng on your Alfa do you see the following lines?

14:38:12  Trying to set MTU on wlan0 to 1800
error setting MTU on wlan0
14:38:12  MTU on wlan0 remains at 1500

I ran into the problem described by Revelati which basically resulted in the clients only being able to surf a few webpages correctly while most would refuse to load. Setting the MTU of the at interface to match the MTU of the Alfa interface solved this problem.

Update: Finally got to actually try out your script and have to say that it works wonderfully, including the ettercap implementation and SSL. I did nevertheless need to modify the script to use MTU 1500 on at0, without which the previously described issue would occur. I also still seem to have problems connecting to the rogue AP when using the -P -C switches in airbase-ng. I also noticed the malformed packets in Wireshark when monitoring the wlan0 interface, this is however easily overcome by simply using the at0 interface instead, which is why I didn't notice it previously. I also seemed to be able to run mdk3 alongside airbase-ng using the same interface. I say seemed at this point as I have only confirmed that they both are able to run alongside each other without problems, but have not further investigating how well mdk3 works in this manner.

[hm2075]

looking good, especially getting ettercap working

yes mtu at 1400 is much better, any higher and certain sites stop working, for more info type in google "talktalk broadband and mtu", a common problem with talktalk broadband in the the uk for which i spent hours trying to sort a friends network out

we know it's damn difficult to crack wpa so this is where the future is.

We have a lot of things workin, just to sumarise

airbase-ng working
transparency and non transparency internet
ettercap working with mitm sniffing-- not tested but i take your word for it
dns redirector working --- i use dns poisoner
autometasploiter thingy ma bob is working too aka wireless key harvester

combine all of the above into one and we have a great tool for backtrack4 hehe

i'm looking into two things

airbase -p ---- still having problems getting a victim to connect using this
mdk3 --- finally got this working so will forcefully disconnect victim and see what happens

as for targetting a specific victim can't we create an exact ap with the same mac but on a different channel?

[letmein]

removed as didnt check properly