Capturing packets with CRC errors in wireshark...

While doing some experiments with the co-channel interference, (there is lot of interference in 2.4 GHz band) i was expecting an increase in the number of packets having CRC errors. I knew that theoretically, i should be seeing a lot more malformed packets in wireshark having CRC error. But as I did not see any such packets, I knew something was wrong.

Again, as I was using, madwifi-ng with the atheros card, looking into the driver code helped me. I came to know that packets with crc errors were being dropped by the driver itself. These packets were not propagated to the application( in my case, wireshark, thats why i was unable to see those packets). Here is the snapshot of the driver code, which was dropping the packets.

In file net80211/ieee80211_monitor.c
Function :ieee80211_input_monitor
-----------------------------------------------------------------------------------
/* Discard CRC errors if necessary */
if (ds->ds_rxstat.rs_status & HAL_RXERR_CRC) {
if (vap->iv_monitor_crc_errors == 0) continue;
}
-----------------------------------------------------------------------------------
What it means is, it will not process and continue to next packet if ds->ds_rxstat.rs_status has CRC error bit set to 1. We will still process the packet if vap->iv_monitor_crc_errors is a non-zero value. Now trying to find out where it is set, I came to know about some interesting proc entries. Lets concentrate on this issue first.

In file net80211/ieee80211_linux.c
This is the function which sets that value..
------------------------------------------------------------------------------------------------------------------
static int
IEEE80211_SYSCTL_DECL(ieee80211_sysctl_monitor_crc_errors, ctl, write, filp, buffer,
lenp, ppos)
{
struct ieee80211vap *vap = ctl->extra1;
u_int val;
int ret;

ctl->data = &val;
ctl->maxlen = sizeof(val);
if (write) {
ret = IEEE80211_SYSCTL_PROC_DOINTVEC(ctl, write, filp, buffer,
lenp, ppos);
if (ret == 0)
vap->iv_monitor_crc_errors = val;
} else {
val = vap->iv_monitor_crc_errors;
ret = IEEE80211_SYSCTL_PROC_DOINTVEC(ctl, write, filp, buffer,
lenp, ppos);
}
return ret;
}
-------------------------------------------------------------------------------------------------------------------
So setting proc entry monitor_crc_erros to 1, enables the propagation of these crc error packets to the application.
#echo ‘1′ > /proc/sys/net/ath0/monitor_crc_errors # Disable CRC error checking

Other interesting proc entries i found were:
#echo ‘1′ > /proc/sys/net/ath0/monitor_phy_errors # Disable PHY error checking

When packet is passed from driver to application, a header is appended to the packet, having information like noise, RSSI, signal strength, data rate,frame length, timestamps etc. I knew about only two headers, namely prism header and radiotap header before looking into the code. Browsing through the code helped me to understand this also.(Lucky me...). I had never seen radiotap header in any of my captures, so I was under impression that madwifi-ng driver always appends with prism header. I had seen radiotap header only with ath5k driver. Anyways, what i came to know after code browsing is:

You can send packets either with prism, radiotap or with no header at all (direct 802.11 packet). There is one more atheros descriptor, i donno what it is about. This is how you can tell driver to append a particular header.
echo ‘801′ > /proc/sys/net/ath1/dev_type # only 802.11 headers
echo ‘802′ > /proc/sys/net/ath1/dev_type # prism2 headers
echo ‘803′ > /proc/sys/net/ath1/dev_type # radiotap headers
echo ‘804′ > /proc/sys/net/ath1/dev_type # atheros descriptors

I can set which headers i want in my packet capture. When i set dev_type to 804, wireshark popped up a warning saying, "libpcap does not support arptype 804", so i dont know how and where this arptype is used.

Thats all for this post friends..... Happy Sniffing....

Setting up a simple honeypot AP..

In this post, we will see how we can use honeypots to connect to unassuming clients.
I am assuming here that we dont have an AP which we can set up as we want. All we have is a laptop, any atheros based wireless card and backtrack. Though these simple things i m going to explain here would work well with most of the backtrack versions, i am using BT3. BT4 -beta too has been released and i will move to that soon.

So, we can have our wireless card in four modes:
1.Monitor mode: This is the mode in which our card listens to the wireless traffic.
2.AP mode: In this mode, wireless card acts as an access point.
3.Managed Mode: Also known as station mode, card acts as a wireless client.
4.Ad-Hoc Mode: We can make wireless card to work in ad-hoc mode.

For honeypot we will put our card in AP mode. Assuming we are using madwifi-driver, this is how we can set up a honeypot.

Explanation :

• The first command "iwconfig" shows all wireless interfaces in the machine. In this case, these are "eth1" and "ath0". Both are in managed mode so connected to different networks, "Back-Off" and "Jhoom Barabar Jhoom" respectively. ath0 is atheros chipset based wireless card.
• As we have to put atheros card in AP mode, we first destroy that using "wlanconfig ath0 destroy".
• Then we create a new interface in AP mode.
• Then we set the channel (i.e. 7) and essid of AP ( Free-WiFi).

Now our wireless interface ath0 will be seen as an open AP. To have layer 3 connectivity with the client, we can start dhcp server also.
Create a dhcpd.conf file like this:
ddns-update-style ad-hoc;
subnet 192.168.1.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option domain-name "google.com";
range dynamic-bootp 192.168.1.7 192.168.1.49;
default-lease-time 21600;
max-lease-time 43200;
}

Create a rc.dhcpd:
#!/bin/sh
# /etc/rc.d/rc.dhcpd

dhcpd_start() {
if [ -x /usr/sbin/dhcpd -a -r /etc/dhcpd.conf ]; then
echo "Starting Dhcp..."
/usr/sbin/dhcpd -cf /etc/dhcpd.conf ath0
fi
}

dhcpd_stop() {
killall dhcpd
}

dhcpd_restart() {
dhcpd_stop
sleep 2
dhcpd_start
}

case "$1" in
'start')
dhcpd_start
;;
'stop')
dhcpd_stop
;;
'restart')
dhcpd_restart
;;
*)
# Default is "start", for backwards compatibility with previous
dhcpd_start
esac

To start dhcp server on BT3, follow these steps:
#mkdir /var/state/dhcp (create only if it does not exist)
#echo " " > /var/state/dhcp/dhcpd.leases
#cp dhcpd.conf /etc/
#cp rc.dhcpd /etc/
#chmod 755 /etc/rc.dhcpd
#/usr/sbin/dhcpd -cf /etc/dhcpd.conf

Now the connecting client will also get IP address from attacker's machine. What else can be done from here onwards, we will see in the next posts.

The Interceptor

I was just going through some sites, and came across "Interceptor". I liked it and think its worth mentioning here. " The Interceptor is a wireless wired network tap."
http://www.digininja.org/interceptor/

What i liked most about it is the idea of flashing the AP and making it do some interesting things. All the attacker has to do is to reach the victim's location once and tap the wired network with this newly flashed fon+ AP. Now attacker can listen to all wired network traffic of that network without ever going there again. What makes it more interesting that it provides double security over the air, so anyone sniffing the air too woud'nt be able to tell what traffic it is. Only the person having control of fon+ can intercept the traffic on the victim's wired network.

Following are my understanding about Interceptor....

1. Interceptor uses fon+ AP as a tap device. fon+ has two wired interfaces, and one wireless interface through which it will send tapped network information in the air.
2. Wireless interface is atheros chipset based and all modules used by interceptor are compiled for mips platform. ( fon+ is on mips platform), so we cannot simulate it on our x86 laptop (I thought of simulating it on a laptop having two wired interfaces and one atheros based wireless client card).
3. Tap device (fon+) will bridge its wired interfaces so that all the traffic passes through and victim's network administrator woudnt have any way of knowing something might be wrong.
4. Besides, passing data from one wired interface to other, it sends it to wireless interface also which is an encrypted AP(security used is WPA2-PSK).
5. On top of it, tap device(fon+) will be running a vpn client to encapsulate all traffic in VPN tunnel.
6. The other linux machine, will act as wireless client connected to tap device and will be running VPN server. A tap interface is created on this linux machine, on which we can sniff the data, which is flowing through in victim's tapped network.

A good tutorial is given here:
http://www.digininja.org/interceptor/install_walkthrough.php

Now, i am just waiting for this fon+ ( also known as la fonera) to come in my hands, and really try it out.

Honeypot .... What is this??????

A lot of research has been done on the security of WiFi infrastructure. So many vulnerabilities either in the protocol or in their implementation have been discovered for launching different types of attacks on Access Points. At the same time, wireless client's security has not been given that much attention. I am more interested in finding vulnerable clients, and if possible, getting information from the client. In some cases, we can have complete control over wireless client, how???, that we will see later.
Generally, APs in enterprises are configured with the best security possible, so trying to get access to the enterprise network is quite difficult. But clients keep moving, they connect to the secure AP within enterprise, but who stops them from connecting to other APs when they are travelling??? Everyone wants internet access on the move, and for them, hotspots are easily available at coffee-shops, airports etc. So my point is, finding a client which might be vulnerable is easier. Depending on what information we can get from the client, a misconfigured client can give access to its enterprise network also.

First of all, if a wireless client is connected to an Open AP, all your layer 2 data traffic will be unencrypted. So if you are surfing web, i can read all your data. You dont need to worry about your username/passwords if you are using https (Secure http protocol) as it will provide you application layer security. So, if you are connected to some legitimate AP, and accessing internet over https, all an attacker can do is passively sniff you http data, which in most cases not at all useful for attacker :) . Apart from this, attacker can also do a DoS attack, but again, attacker woudnt get anything besides disrupting the client connection.

So there, the concept of honeypot comes into picture. "HoneyPot is a type of WiFi attack, where a hacker sets its service set identifier (SSID) to be the same as an access point at the local hotspot or corporate wireless network. This results in the unassuming client connecting to hacker's access point instead of legitimate AP." If the attacker is successful in getting the client connected to his AP, now at least layer two traffic is in control of the attacker. So after having a basic idea of what a honeypot is, we will continue in the next posts with the evolution of honeypot over last few year and how it can be integrated with other tools to make it more potent.

So if you guys are interested in having hands on ..... be ready with these items :)
1. Any linux machine will do, but i would recommend using "Backtrack" . Its freely available on www.remote-exploit.org/backtrack.html
2. Madwifi-ng wireless driver (BackTrack has it)
3. Any atheros based wireless card (cisco/netgear etc)

Beyond WiFish-Finder

In the previous post, we saw how wifish-finder can find the security settings of SSIDs configured on our wireless client. So the natural question that comes into mind is......ok great! You have found the security settings on my SSID's in PNL, but how are you gonna use this information?? How does it make my client vulnerable??

The answer is: Your client is vulnerable if any of the SSIDs in your client is configured to connect to an open/weakly-secured AP. Any attacker can use this info to set up a "Honeypot AP" with same security settings and your client will connect to honeypot AP. Now, as your client has been associated to attacker's AP, layer 2 connection has already been made. If your client is configured to use dhcp address and attacker's AP is running dhcp server, wireless client will get an IP from the attacker's honeypot AP. At this time, attacker has layer-3 connection also with your client. I will not describe what an attacker do ,once he has layer 3 connection, in this post, but i will definitely put some more posts explaining what more can be done.

Access Points which can be considered as weakly-secured APs are:
1. Open Auth/No encryption
2.Open Auth/WEP encryption ( WEP key can easily be broken)
3.Shared Key Auth/WEP encryption (SKA just makes it easier to crack the key)
4.WPA/WPA2 -PSK (only dictionary attack is possible, so if you choose a strong key, its safe)

The most secure configuration as of now is WPA/WPA2 using 802.1x authentication. We will see in the coming posts that how a MITM attack is possible in some cases even if the client is configured with most secure configuration ( WPA/WPA2, 802.1x,PEAP).

WiFish-Finder

I m starting this blog with WiFish-Finder, a wireless client vulnerability assessment tool which has just been presented in Defcon 17.
http://www.defcon.org/html/defcon-17/dc-17-speakers.html#Ahmad

What the tool does: This tool gives the security and authentication settings of the SSID's configured in the wireless client's PNL.

Now before we go further and try to understand how the tool does it, we first need to understand the basics of how a wireless client connects to a network.
When a wireless client refreshes the wireless network list, it is presented with a list of wireless networks in the vicinity. This list is known as ANL(Available Network List). This list is populated by collecting the beacons and probe responses sent from the AP's in which they advertise their supported rates, security settings etc. There is one more list known as PNL(preferred network list) which stores wireless network configuations it has connected to in the past. The wireless interface keeps probing for the networks in the PNL, and if it gets one such network, it tries to connect to that network.

For this tool, as we are interested in finding a vulnerable client i.e. a client which is configured to connect to an open/weakly-secured SSID, we will focus on PNL. To know the security settings of SSID's configured in wireless client, tool has to collect association request from the client(as only assoc request has this information). But wireless client woudnt send assoc request if security settings sent by AP in probe response does not match with the security settings of configured SSID.

So how the tool does it: The tool listens for probe requests, and send probe responses. If it does not get assoc request for that SSID/client, next time it gets probe request for same SSID/client, it changes the security in probe responses. WiFish-Finder keeps doing it till it gets assoc request from the client. As the tool maintains the list per client per SSID, it is able to differentiate if same SSID has been configured with different security settings on different clients.

What you need to have:
1. A linux machine having a wireless driver supporting packet injection in monitor mode. (madwifi-ng)
2. A wireless card (cisco a/b/g)

Tool is available here for download :
http://blog.airtightnetworks.com/wifish-finder/

If you find any problem running this tool, please feel free to comment on this post. I will try to reply ASAP. Next version of the tool having PEAP vulnerability detection will be uploaded soon. I will be explaining that feature when the next version is available.