Wednesday, 30 May 2012

Why Wireless Security

The article “Why we lie” in the Wall Street Journal has a great statement about why locks are fitted to our doors, and this statement fits well with wireless security.

“Another 1% will always be dishonest and always try to pick your lock and steal your television; locks won't do much to protect you from the hardened thieves, who can get into your house if they really want to. The purpose of locks, the locksmith said, is to protect you from the 98% of mostly honest people who might be tempted to try your door if it had no lock.”

The advice above is similar to some advice I was given by the local crime prevention offices, who said “Make you house look more secure than your neighbours” which whilst good for me may not of been good for my neighbours.

With wireless security we have a range of encryption controls range from the week to the strong, with all but the strongest susceptible to breaking by techniques that can be implemented by most IT literate people, however with wireless security and the vast numbers of access points available often there is an unencrypted or weak protected wireless network nearby.

We encrypted our wireless networks to protect our data and bandwidth; if everyone was honest we would not need to be worried however there are dishonest people and those who for whatever reason decided to borrow wireless bandwidth which results in the need to ensure we adequately protect our wireless networks.

The level of protection needs to be appropriate, implementable, configuring Radius servers and implementing enterprise WPA2 is in the realm of the geek and businesses, for the home user even configuring WEP can be problematic. The use of WPS has made it easier to implement security, however even this has security weaknesses.

However for the domestic user in deciding about the level of encryption they need to look at what are they protecting, whether it’s their network, the connection to the internet, or data being transmitted and look at the threats, is it the next door neighbour, or someone walking past. They should also consider the risks whether it is reduced bandwidth if limits are exceeded, lose of personal identifiable information, compromise of machines on the network, or misuse of network by downloading illegal or undesirable material, and they are impact considerations such as additional costs for excessive data, lose of identity, possible interaction with law enforcement and subsequent reputational lose.

There is also how competent they are or whether could employ or get another person to configure the network for them and if they can maintain the network, by adding new machines to the network or changing the password.

A factor to consider is if there are weakly protected networks around them then all they need to do is to make their network more inaccessible and the risk will move to the less well protected network.

Sunday, 27 May 2012

Detecting Wardriving (Probe request frames)

Continuing the theme of the last couple of entries on this blog I am looking at detecting war driving using a wireless packet sniffer to capture probe request frames being sent by a client under the control of a war driving tool. In this case I used CommView for Wifi and viStumbler as the sniffing tool and war driving tool respectively.

I was aiming to see what would the affect by of running viStumbler for a period whilst recording probe request frames. Using a laptop running CommView for Wifi, I captured the probe request packets for an approx. period of 55 mins, during which I run viStumbler for 14 mins, the resulting plot of probe request frames / min clearly identify an increase in the number of probe request frames being broadcast.


The average number of probe request frames recorded was around 8 per minute, there where 5 access points visible from the location I was running the tests from on the same channel.

This shows the techniques will work, however need to set-up some experiments to confirm the base line of requests and whether a detectable amount of requests can be recorded from a car driving past.

Friday, 25 May 2012

Probe request contents

A typical probe response will have the following information within it indicating the capabilities of the responding access point device. Giving the SSID, MAC Address, encryption supported

802.11
 Frame Control: 0x0050 (80)
  Protocol version: 0
  To DS: 0
  From DS: 0
  More Fragments: 0
  Retry: 0
  Power Management: 0
  More Data: 0
  Protected Frame: 0
  Order: 0
  Type: 0 - Management
  Subtype: 5 - Probe response
 Duration: 0x013A (314)
 Destination Address: ##:##:##:08:E0:20
 Source Address: ##:##:##:44:CA:FD
 BSS ID: ##:##:##:44:CA:FD
 Fragment Number: 0x0000 (0)
 Sequence Number: 0x09BF (2495)
Probe response
 Timestamp: 77924.059876 sec
 Beacon Interval: 0x0064 (100) - 102.400 msec
 Capability Information: 0x0411 (1041)
  ESS: 1
  IBSS: 0
  CF-Pollable: 0
  CF-Poll Request: 0
  Privacy: 1
  Short Preamble: 0
  PBCC: 0
  Channel Agility: 0
  Spectrum management: 0
  QoS: 0
  Short slot: 1
  APSD: 0
  Radio Measurement: 0
  DSSS-OFDM: 0
  Block Ack: 0
  Immediate Block Ack: 0
 SSID: <########> Supported rates
  1 Mbps
  2 Mbps
  5.5 Mbps
  11 Mbps
  18 Mbps
  24 Mbps
  36 Mbps
  54 Mbps
 Current Channel: 11 - 2462 MHz
 ERP Information: 0x00 (0)
  Non ERP present: 0
  Use Protection: 0
  Barker Preamble mode: 0
 Reserved 2f: 0x00 (0)
 RSN Information Element (802.11i)
  Version: 0x0001 (1)
  Group Key Cipher Suite: 00 0F AC 04 - CCMP
  Pairwise Key Cipher Suite Count: 0x0001 (1)
  Pairwise Key Cipher Suite List
   Cipher: 00 0F AC 04 - CCMP
  Authenticated Key Management Suite Count: 0x0001 (1)
  Authenticated Key Management Suite List
   Key Management: 00 0F AC 02 - IEEE 802.1X Key Management, preshared key
  RSN Capabilities: 0x000C (12)
 Extended Supported Rates
  6 Mbps
  9 Mbps
  12 Mbps
  48 Mbps
 Vendor specific
 Vendor specific
 Vendor specific

Detecting Wardriving

For my research one of the questions I would like to answer is how prevalent is wardriving or is it only researchers that are doing this type of activity. According to wikipedia "Wardriving is the act of searching for Wi-Fi wireless networks by a person in a moving vehicle, using a portable computer, smartphone or personal digital assistant (PDA)." Which is a definition I would agree with, when it moves from locatingWi-Fi access points to connecting to them to me that has moved away from Wardriving and starting to commit if you are within the UK an illegal act, legalisation varies around the world so I will refer to UK laws.

Although I am started with a question about wardriving, the real question is how many people are scanning for Wi-Fi networks there can connect to when they don't have authorisation to do so.

Detecting Wi-Fi networks can be done in a number of ways.

1) Listening for broadcast beacons (Passive)


Access points will broadcast there SSID and capabilities using a broadcast beacon frame at a regular interval. If you turn of "Broadcast SSID" it is this frame that is no longer broadcast.

2) Probe request & response frames (Active)


A client can issue a probe request with or without a SSID, an access point if it has a matching SSID to that within the probe will send a probe response with the access points capabilities included. If the probe response has a blank SSID then most access points will respond to the probe request with a probe response with the access points capabilities included.

3) Sniffing frames (passive)

This last method involves the client "sniffing" packet capture of frames and then decode them to identify the SSID of the Wi-Fi network.

It is impossible to detect someone using passive methods to locate a Wi-Fi network, until they connect to an access point, however this is beyond the scope of this blog entry, I'm concentrating on detecting probe request and probe responses.

Wi-Fi frames

A bit of a background to the frames used by Wi-Fi networks, the 802.11 standard defines various frame types that stations (NICs and access points) use for communications, as well as managing and controlling the wireless link.
  • Data Frames.
  • Management Frames
  • Control Frames
The first two bytes of the MAC header form a frame control field specifying the form and function of the frame. The frame control field is further subdivided into the sub-fields, the two fields I am interested are :-
  • Type: two bits identifying the type of WLAN frame. Control, Data and Management are various frame types defined in IEEE 802.11.
  • Sub Type: Four bits providing addition discrimination between frames. Type and Sub type together to identify the exact frame.
Management frames are type 0
Control frames are type 1
Data frames are type 2

Management Frames (type 0)
  • Authentication frame: subtype 11
  • Deauthentication frame: subtype 12
  • Association request frame:  subtype 0
  • Association response frame: subtype 1
  • Reassociation request frame:  subtype 2
  • Reassociation response frame: subtype 3
  • Disassociation frame:  subtype 10
  • Beacon frame:  subtype 8
  • Probe request frame: subtype 4
  • Probe response frame:  subtype 5
Identification of frames

Use a packet sniffing capable of analysing Wi-Fi packets such as CommView for WiFi or WireShark with a suitable wireless NIC we can sniff the frames being broadcast, in order to keep the exercise ethical we use a filter to ensure we only examining the Probe Request and Probe Response frames.

With wireshark we can use the following rules to formulate a filter

Management frames wlan.fc.type eq 0
Probe request wlan.fc.type_subtype eq 4
Probe response wlan.fc.type_subtype eq 5

What we are looking for is a pattern of probe requests and probe response, a person wardriving will be continually sending out probe requests with a blank SSID, which while they are in range we can detect, a person just doing a quick scan for available networks will send a short burst of probe requests with a blank SSID.

This will be continued with some examples of the findings.




Wednesday, 16 May 2012

Build your own

Found an excellent article that describes how to build minipwner which has the similar capabilities as the pineapple from Hak5

build your own article http://www.minipwner.com/index.php/minipwner-build

Devices such as the minipwner and the pineapple should not be used for illegal activities, but can provide some useful wireless testing tools and help in some pen testing scenarios

What will make these devices more useful is the use of a battery pack and there is an increasing number of battery packs design to recharge or power smartphones and tablets, these often have multiple USB sockets on them to connect USB charging cables.

The minipwner requires a Micro USB (B) connector whilst the Pineapple uses a 5.5mm barrel connector, on ebay and amazon there are a number of USB to power adaptors including 5.5mm barrel ones.