Skip to main content

Beaglebone Black as a Wireless Intrusion Detection System (WIDS)

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:

    Kismet supports the following alerts, where applicable the WVE (Wireless
    Vulnerability and Exploits, 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:CCD: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.  

Comments

  1. 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.

    Regards,
    S.

    ReplyDelete

Post a Comment

Popular posts from this blog

ADS-B plotting with Kali (and other SDR goodies)

Recently I wanted to try some Software Defined Radio stuff.   
I had a RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T. that I got from: http://www.amazon.com/gp/product/B00C37AZXK/ref=oh_details_o04_s00_i00?ie=UTF8&psc=1
But, even though this dongle would break out FM radio stations, and ATC frequencies (like the local Ground Control, tower, and even ATIS), which was cool, it wouldn't break out ADS-B.   
Thus, I bought a Vantech Green Mini RTL2832U R820T DVB-T SDR DAB FM USB DIGITAL TV Tuner Receiver RTL-SDR Project + DAB dongle Tuner MCX Input from Amazon, and tried this.  
This dongle was able to listen to the 1090MHz frequency required for ADS-B (as it goes from 25MHz to 1700MHz).  There were tons of Windows programs out there for breaking out and plotting ADS-B Mode S broadcasts, but not many for Linux.  
For Kali Linux, here's how I got it running and plotting planes around my home:
0) before you start, you should do an apt-get update to ensure you hav…

Temper Temperature monitor on a Beaglebone Black

Beaglebone Black as a temperature monitor:

Recently I wanted to monitor the temperature of my shed.  I thought I'd use a small computer such as a Raspberry Pi or a Beaglebone or Odroid.

My Raspberry Pi boxes were all in use, so I grabbed my Beaglebone, which was doing nothing.

I flashed it with the Debian9.32018-03-054GB SDIoTimage, but that seemed like it was running lots of bloatware and the ethernet interface wouldn't take a static IP with /etc/network/interfaces.

So I went with the Debian9.32018-01-284GB SDLXQTi image instead.  I still had the same problem, that lots of junk was running, and I couldn't configure my interface by modifying /etc/network/interfaces

So my first step was to get rid of all the bloatware.  If you're using a Raspberry Pi or something, you can skip this and just go to the second step below

STEP 1--Remove Blotatware from Beaglebone Black:

With some searching, I came across this post:
https://www.linuxquestions.org/questions/linux-newbie-8/inte…