Recently I have been wanting a wireless IDS (WIDS) to detect nefarious wifi activity. I also had a Beaglebone Black hanging around that I wanted to put to good use. This seemed like a perfect match, and indeed it seems to be so!
I did some research on WIDSs, and although there is SUPPOSED to be several out there, nearly all that I seemed to find was commercial and Windows-based products, not something I could use myself.
About the only exception to that rule was Kismet, so I decided to give that a try. Kismet is supposed to work as a WIDS, and per its documentation should catch the following attacks:
www.wve.org) ID is included: AIRJACKSSID Fingerprint Deprecated The original 802.11 hacking tools, Airjack, set the initial SSID to 'airjack' when starting up. This alert is no longer relevant as the Airjack tools have long since been discontinued. APSPOOF Fingerprint A list of valid MAC addresses for a SSID may be given via the 'apspoof=' configuration file option. If a beacon or probe response for that SSID is seen from a MAC address not in that list, this alert will be raised. This can be used to detect conflicting access points, spoofed access points, or attacks such as Karma/Airbase which respond to all probe requests. The 'apspoof=' configuration option can specific exact SSID matches, regular expressions (if Kismet is compiled with PCRE support), and single, multiple, or masked MAC addresses: apspoof=Foo1:ssidregex="(?i:foobar)",validmacs=00:11:22:33:44:55 apspoof=Foo2:ssid="Foobar", validmacs="00:11:22:33:44:55,AA:BB:CC Kismet supports the following alerts, where applicable the WVE (Wireless Vulnerability and Exploits, D:EE:FF" When multiple MAC addresses are specified, they should be enclosed in quotes (as above). For more information about forming PCRE-compatible regular expressions, see the PCRE docs (man pcrepattern). BSSTIMESTAMP Trend/Stateful Invalid/Out-of-sequence BSS Timestamps can indicate AP spoofing. APs with fluctuating BSS timestamps could be suffering an "evil twin" spoofing attack, as many tools do not attempt to sync the BSS timestamp at all, and the fine-grained nature of the BSS timestamp field makes it difficult to spoof accurately. Some APs may reset the BSS timestamp regularly, leading to a false-positive. References: WVE-2005-0019 CHANCHANGE Trend/Stateful A previously detected access point changing channels may indicate a spoofing attack. By spoofing a legitimate AP on a different channel, an attacker can lure clients to the spoofed access point. An AP changing channel during normal operation may indicate such an attack is in process, however centrally managed networks may automatically change AP channels to less-used areas of the spectrum. References: WVE-2005-0019 CRYPTODROP Trend/Stateful Spoofing an AP with less-secure encryption options may fool clients into connecting with compromised credentials. The only situation in which an access point should reduce encryption security is when the AP is reconfigured. DEAUTHFLOOD Trend/Stateful BCASTDISCON Trend/Stateful By spoofing disassociate and deauthenticate packets an attacker may disconnect clients from a network, causing a denial-of-service which lasts only as long as the attacker is able to send the packets. References: WVE-2005-0019, WVE-2005-0045, WVE-2005-0046, WVE-2005-0061 802.11ninja.net home.jwu.edu/jwright/papers/l2-wlan-ids.pdf DHCPCLIENTID Fingerprint A client which sends a DHCP DISCOVER packet containing a Client-ID tag (Tag 61) which doesn't match the source MAC of the packet may be doing a DHCP denial-of-service to exhaust the DHCP pool. DHCPCONFLICT Trend/Stateful Clients which receive a DHCP address and continue to use a different IP address may indicate a misconfigured or spoofed client. DISASSOCTRAFFIC Trend/Stateful A client which is disassociated from a network should not immediately continue exchanging data. This can indicate a spoofed client attempting to incorrectly inject data into a network, or can indicate a client being the victim of a denial-of-service attack. DISCONCODEINVALID Fingerprint DEAUTHCODEINVALID Fingerprint The 802.11 specification defines valid reason codes for disconnect and deauthenticate events. Various client and access point drivers have been reported to improperly handle invalid/undefined reason codes. DHCPNAMECHANGE Trend/Stateful DHCPOSCHANGE Trend/Stateful The DHCP configuration protocol allows clients to optionally put the hostname and DHCP client vendor/operating system in the DHCP Discover packet. These values should only change if the client has changed drastically (such as a dual-boot system). Changing values can often indicate a client spoofing/MAC cloning attack. LONGSSID Fingerprint The 802.11 specification allows a maximum of 32 bytes for the SSID. Over-sized SSIDs are indicative of an attack attempting to exploit vulnerabilities in several drivers. LUCENTTEST Fingerprint Deprecated Old Lucent Orinoco cards in certain scanning test modes generate identifiable packets. MSFBCOMSSID Fingerprint Some versions of the Windows Broadcom wireless drivers do not properly handle SSID fields longer than the 802.11 specification, leading to system compromise and code execution. This vulnerability is exploited by the Metasploit framework. References: WVE-2006-0071 MSFDLINKRATE Fingerprint Some versions of the Windows D-Link wireless drivers do not properly handle extremely long 802.11 valid rate fields, leading to system compromise and code execution. This vulnerability is exploited by the Metasploit framework. References: WVE-2006-0072 MSFNETGEARBEACON Fingerprint Some versions of the Windows netgear wireless drivers do not properly handle over-sized beacon frames, leading to system compromise and code execution. This vulnerability is exploited by the Metasploit framework. NETSTUMBLER Fingerprint Deprecated Older versions of Netstumbler (3.22, 3.23, 3.30) generate, in certain conditions, specific packets. NULLPROBERESP Fingerprint Probe-response packets with a SSID IE tag component of length 0 can cause older cards (prism2, orinoco, airport-classic) to fail. References: WVE-2005-0019 PROBENOJOIN Trend/Stateful Active scanning tools such as Netstumbler constantly send network discovery probes but never join any of the networks which respond. This alert can cause excessive false positives while channel hopping, and is disabled by default.
It is obvious that a lot of these attacks are old and irrelevant any longer, but some of them are still good. Some of the alerts I wanted to catch were Rogue APs, Reaver Attacks, DoS attacks, and client disassociations. It looked like Kismet might be able to do most of those.
To install Kismet on the Beaglebone, I downloaded Ubuntu 13.04 from here:
http://elinux.org/Beagleboard:Ubuntu_On_BeagleBone_Black
I put this image on a card, and booted it up. Since I wanted my WIDS to be headless, I added "service ssh start" in the /etc/rc.local file.
I wanted to use the entire Beaglebone SD card, so I repartitioned the card to use all available space. This was basically running fdisk, deleting the #2 partition, and adding it back with the defaults.
>fdisk /dev/mmcblk0
-p (look at partition table)
-d (delete a partition)
-2 (partition number to delete)
-p (show the new partition table with the old partition missing)
-n (make a new partition)
-p (make it a primary partition)
- (give it the same number that was previously deleted)
-default starting point
-default ending point
-p (show the changes)
-w (if all looks good, write the changes to disk)
I edited the /etc/network/interfaces to give the Bone a static IP so I could reach it through SSH.
- iface eth0 inet static
address x.x.x.x
netmask 255.255.255.0
gateway x.x.x.1
- to prepare for kismet, I had to add a bunch of dependencies:
- apt-get install g++, libpcap-dev, libncurses-dev, libnl-dev, make
- make dep
- make, make install
- since I was going to run Kismet headless, and I wanted to be able to see the kismet "GUI" through ncurses yet still be able to get to the terminal to do stuff while kismet was running, I installed 'screen.'
- apt-get install screen
- I could then ssh into my Bone, type 'screen bash' and screen would be running. Then, when I start kismet, I can type ' d' to detach from that window and bring up a new terminal window. I can log out and everything and kismet will keep running in a background screen. If I ever want to get back into the running kismet, I just type 'screen -r' and I'll return to the kismet screen. I love screen!
- I downloaded kismet-2010-07-R1.tar.gz and unzipped it, untarred it, and ran make and make install.
- I tried Kismet, and it worked like a champ! But of course, it's configuration needed some tweaking for a WIDS (vs a packet capture system and such).
- I edited the /usr/local/etc/kismet.conf file
- ncsources=wlan0
- gps=false
- logtypes=alert,nettxt
- I edited the "apspoof" for the SSIDs on my LAN (added their MACs)
Next came the testing!
I put up a Rogue AP, and WHAM! Kismet caught it perfectly.
I disassociated all the wireless clients on my AP, and POW! Kismet caught that perfectly as well.
However, when I disassociated a single client, something I would typically do in order to get a handshake on a WPA-protected network, this slipped right by! That was unacceptable.
I looked through the source code, and found the rule that Kismet makes for that alert. With a couple of quick edits, I made a rule for a single client disassociation.
Basically, I saw that the kismet.conf file had a BCASTDISCON field for the alert in question. I copied that to make an alert called CLIENTDISASS. I also looked where this was called, and I noticed references to 'bcastdcon.' So I also copied the references from 'bcastdcon' to 'clientdisass.' In total, I edited only 4 files! These were (from the kismet directory) conf/kismet.conf, conf/kismet.conf.in, netracker.cc, and netracker.h. Here's what I made them (the changes are clearly visible):
conf/kismet.conf and conf/kismet.conf.in (they were the same):
netracker.h:
netracker.cc:
I then tested it. Kismet caught single client disassociation attacks as well as broadcast disassociations! Here's a screenshot of Kismet alerting on (from the bottom up) a Rogue AP, a broadcast disassociation, and a client disassociation:
I tried a few Reaver attacks, and they seem to give off the same 'Client deauthentication/disassociation' alerts that a deauth of a client gives. I think that this is because when the Attacker attempts to connect to an AP it legitimately gets kicked off by the real AP, triggering the deauth alert. Since none of my APs are vulnerable to a Reaver attack, this seems like an alert that I can live with for now. I'll need to put up a vulnerable AP to do some more testing if I want to refine this alert.
I am wondering what wifi hardware you used. I am presuming a USB one. If it was in the write-up I missed it. Knowing the make and model would be useful to me.
ReplyDeleteRegards,
S.