My contribution to the increasing entropy, and eventual heat death of the universe
In my case this was I believe caused by avahi lookups taking priority.
In nsswitch.conf I had:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
I changed this to:
hosts: files dns mdns4_minimal [NOTFOUND=return] dns mdns4
and all was well.
Vivek’s video for this part is here.
In this part Vivek shows us how to modify the requests as they pass though the system in a man in the middle attack. This allows us to change web requests and intercept SSL connections (though this will give an error on the client, it is usually ignored by the user).
We’re going to use DNS spoofing. The tool used is called dnsspoof.
This will sniff on an interface, whenever it sees a DNS request it will reply with the attacker machines IP.
We’re carrying on from the previous part, with a bridge setup which routes all traffic via our host to the internet.
0. We can run dnsspoof on the bridge as follows:
dnsspoof -i mitm
This will trigger on all DNS traffic not originating from the attacker machine.
The external DNS will ALSO reply. However dnsspoof will respond first, and therefore will be used.
1. Try and correct to a site from your client.
You should see the DNS lookup in the dnsspoof window.
2. Now all traffic will be going to our machine, but our machine doesn’t know how to reply. So we need to run a proxy here.
We use a proxy server included with backtrack called Burp suite.
Select Backtrack->Web Application Analysis->Web (frontend)->Burp suite from the programs menu.
NOTE: I couldn’t find this on backtrack 5 R1. To run Burp suite here I did the following:
cd /pentest/web/burpsuite sh ./suite.bat
This will start a proxy on port 8080 by default. This is no good because requests are coming in on port 80 and 443 (for ssl)
Click Proxy, options, enter 80 in “local listener port” and click add.
Enter 443 in “local listener port” and click add.
3. Try and connect to a site on your client again. It’ll screw up. This is because the client isn’t configured to use a proxy…
4. Click on the port 80 line in burp suite. Select “support invisible proxying for non-proxy aware clients”. (do the same for port 443).
5. Select the intercept tab. Load a page on the client.
You should see the web request in burp suite. Remove the intercept. And try and load a page on the client.
You should see that it loads normally. You can also see the DNS requests in dnsspoof.
6. Turn the intercept on, and search for “antivirus” on the client. Note that you see the search in the intercept.
7. You can now edit the intercepted request, change “antivirus” to “pwned”. And click “forward”. You should see that your client gets search requests for the word “pwned”.
Neat! You can automate a lot of this using burpscript to other proxy servers such as delicate.
8. Now, enter gmail.com on your client.
You will get an error saying “Can not verify server identity”. Burp proxy, is performing the signing itself, and this is causing the error.
However, must users will just hit continue though this. Beyond this point, the login will look fine. Enable intercepts again. Login on the client, and you’ll be able to see the password in the intercept window.
Vivek has other videos on this see:
Vivek’s video is here.
In the unencrypted man in the middle attack, we deauth the client from the regular AP and reconnect it to our own fake AP.
We can either connect the client to a new wired (or 3G) internet connection or we can connect back to the real AP.
In our setup we’re going to get our victim to connect to our fake AP, and then send the traffic out to the internet via a different access point.
We’ll use the alfa card to create a fake AP. We’ll use the laptops built in wifi card to connect to our other AP.
0. Setup your network card in VirtualBox/VMWare, using “NAT” is probably your best option.
1. Bring up eth0 in backtrack
ifconfig eth0 up
2. Bring up an access point with SSID SecurityTube
ifconfig wlan0 up airmon-ng start wlan0 iwconfig wlan0 channel 1 airbase-ng -ssid SecurityTube mon0
3. Bridge the interfaces
Run this in a new terminal window:
ifconfig at0 up brctl addbr mitm brctl show #will show the bridge, but no interfaces added brctl addif mitm eth0 brctl addif mitm at0 ifconfig eth0 0.0.0.0 up #not sure why this is needed! ifconfig at0 0.0.0.0 up
If you do ifconfig, you’ll see a new bridge, mitm. Bring up the interface:
ifconfig mitm dhclient3 mitm
The dhclient command, gets an IP address, this will come from the virtualbox dhcp server.
4. Go to the airbase-ng window. Connect a device to the fake network you created.
The device will get a IP address from VirtualBox.
5. Open up wireshark, start a capture on at0. Open a webpage on your client.
You should see a lot of traffic in wireshark. You should be able to view pages on your client via the laptops internet connect.
All packets have to go though us, this is a little better than passively sniffing cleartext packets and all packets /MUST/ go through us.
Vivek’s video is here.
This video discusses the Alfa card in some detail. The frequency range the card operates on depends on your country. This limits which channels can be used, and the transmission power. Vivek shows us how to change the current country so as to increase the number of channels available and transmit power.
0. Start backtrack, leave the alfa card disconnected.
1. Monitor kernel messages in one terminal:
tail -f /var/log/messages
2. Plug in you alfa card.
3. You should see lines in your kernel messages that read:
cfg80211: Calling CRDA to update world regulatory domain cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max eirp) cfg80211: (2402000 KHz - 2472000 KHx @ 40000 KHz), (300 mBi, 2000 mBm) ...
You can check these frequency ranges against the Wifi frequency table (wikipedia).
Transmit power is measured in dBm. 30dBm = 1W.
The table in kernel messages show EIRP (effecive isotropic radiated power). It’s a measure of the effective transmit power of a device calculated as:
EIRP = Transmit Power (in dBm) + Antenna Gain (in dBi) – Cable loss (in dBm)
4. Bring up the alfa card, and select channel 1.
Open another terminal and enter the following:
ifconfig wlan0 up iwconfig wlan0 channel 1 iwconfig [/sourecode] In the iwconfig output you should see that the frequency is listed as 2.412GHz and it's transmiting at 20 dBm. 5. Change the transmit power of the card: [sourcecode language="bash"] iwconfig wlan0 txpower 30
You’ll notice if you try this you get an error as follows:
Error for wireless request "Set Tx Power" (8B26) :
SET failed on device wlan0 ; Invalid argument.
However, we can switch our card between regulatory domains:
ifconfig wlan0 down iw reg set US ifconfig wlan0 up
Look at your kernel message terminal. You should see that the regulatory domain has change to the US. And that the eirp has change to 2700 mBm for channel 1.
Try changing the power again:
iwconfig wlan0 txpower 27
However if you setting the power beyond 27 you’ll still receive and error. Setting a channel of 12 or above will also cause the following error:
Error for wireless request "Set Frequency" (8B04)
SET failed on device wlan0 ; Invalid argument.
The least restrictive countries are BO and BZ. You can set these are before as:
ifconfig wlan0 down iw reg set BO ifconfig wlan0 up iwconfig wlan0 channel 13 iwconfig wlan0 txpower 30
You should receive no errors. However you should be aware that using the card in this manner may be illegal in your country.
RSS