Background and Theory:

lowlyoutstandingΚινητά – Ασύρματες Τεχνολογίες

24 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

85 εμφανίσεις


1

ECE4112 Internetwork Security

Lab

X
: Bluetooth Security


Group Number: ____________

Member Names: _______________________ _______________________


Date Assigned:

Due Date:

Last Edited on: April 22, 2006


Please read the entire lab and any extra material
s carefully before starting. Be sure to start early
enough so that you will have time to complete the lab. Answer ALL questions on the
Answer
Sheet

and be sure you turn in ALL materials listed in the
Turn
-
in Checklist

on or before the
date due.


Goal:
This

lab will introduce you to several security issues involved in Bluetooth enabled
devices.


Summary:

In this lab you will be learning about several techniques to attack Bluetooth
devices, as well as how to defend against them.
This lab will provide you wit
h a thorough
understand of how Bluetooth devices work.


Requirements:



Red Hat WS 4



SPI Dynamics VMware machine



3 USB Bluetooth Dongles


Background and Theory:


Bluetooth

is nothing but a wireless communication standard that lets devices communicate with
o
ne another with a range of 10 meters (approximately 33 feet). In other words, Bluetooth is the
protocol

that allows Bluetooth
-
enabled devices to transfer files, photographs, and other data as
long as they are
in range
. Many wireless
-
hacking related attacks

involve the Bluetooth
communication standard at some level or the other. Hence, it’s a good idea for both crackers and
even potential victims to become conversant with the Bluetooth communication standard.


The Bluetooth communication protocol can connec
t a variety of Bluetooth
-
enabled devices,
and not just two similar devices (like two mobile phones), but two dissimilar devices (like a PDA
and a computer). The protocol can also be used in conjunction with other network protocols. For
example, a Bluetooth
-
enabled mobile phone can connect to a computer and then use the
computer to connect to the Internet. Almost all Bluetooth communication setups can be divided
into two main categories:




2



Master
-
master connection.

This setup is one in which all the Bluetoot
h devices that are
a part of the communication have the keyboards and can dynamically communicate with
one another. For example, when two mobile phones are connected, both Bluetooth
devices have an input device. Hence, the connection is known as a master
-
m
aster
connection. In such connections, you can actively enter data and communicate with the
other Bluetooth device.



Master
-
slave connection.

This setup has one device without an input device. For
example, the connection between a mobile phone and a Blueto
oth
-
enabled headset can be
described as a master
-
slave connection. Since a mobile phone has a keypad, you actively
control the data entry and communication with the headset. The device on the other end,
which does not have an input device, relies on prepro
grammed instructions to carry out
the communication.


Network Architecture [1]


Figure 1. Example Connectivity and Members


The Bluetooth system supports both point
-
to
-
point and point
-
to
-
multi
-
point connections.
Units that are within the range can set up

an ad
-
hoc connection. Two or more Bluetooth units
that share the same channel form a piconet. To regulate traffic on the channel, one of the
participating units becomes a master of the piconet. Any unit may be a master and the remaining
members become sla
ves. Nodes may request to exchange roles if desired. The master is
responsible for synchronization as well as controlling all traffic on the channel. The master
employs a polling scheme to avoid collisions and all traffic is routed through the master first
.

Several Piconets can be established and linked together ad hoc, where each piconet is
identified by a different frequency hopping sequence. A collection of piconets constitute a
scatternet. All users participating on the same piconet are synchronized to
this hopping sequence.
The topology can best be described as a multiple piconet structure. Up to eight mobile hosts can
actively participate in a piconet but it contains several "sleeping" members. Units may belong to

3

several piconets, but not simultaneous
ly. If a unit is a master and it leaves its piconet to
participate in another, then all traffic is suspended until it returns.


Bluetooth Protocol


Like any other protocol, Bluetooth uses a predefined procedure to establish a connection. Most
Bluetooth co
nnections are established by the following setups:


1.

Discovery:

device scans for target device and hopefully discovers it.

2.

Pairing:

Devices exchange pairing code and other information.

3.

Binding:

devices exchange encryption key and make the connection bind
ing.


Discovery

Before any two Bluetooth
-
enabled devices can start communicating with one another,
they must carry out a procedure known as
discovery
. In other words, the enabled devices need to
find each other. Typically, a Bluetooth device scans for ot
her Bluetooth devices within range.
Once a Bluetooth device has discovered the correct destination Bluetooth device, only then can
data transfer start.


Pairing


Pairing comes after Bluetooth device have discovered each other. The pairing process is
to Bl
uetooth what the TCP/IP handshake is to two computers on the Internet. It allows the two
Bluetooth
-
enabled devices (that are trying to setup a communication channel with one another)
to exchange important information like address, version, and
pairing code
. Consider the pairing
code to be something like a password. Only once this pairing process has been completed
successfully can the two devices communicate with proper access rights and privileges.



Without the entry of the correct pairing code, the Blue
tooth connection request will not
be accepted. It is important to note that in case of a master
-
master Bluetooth connection, users at
both ends are required to enter the pairing code. For example, when two mobile phones are
attempting to connect through Bl
uetooth, users at both ends must enter a pairing code. On the
other hand, in case of a master
-
slave connection, the master user is required to enter the pairing
code, while the slave automatically reads the pairing code from its programmed instructions. Fo
r
example, when a mobile phone is trying to connect to its handset, then the pairing code has to be
entered at the phone end. It is automatically read from preprogrammed instructions at the headset
end.


When users at both ends enter an identical pairing
code, a link key is generated. This
link
key

then carries out the third step, known as
binding
. It is important to node that certain devices
may not require pairing for data transfer to start. In other words, pairing is often an optional
process that binds

connections with only devices that one communicates regularly with. Paired
devices are also easier to locate and recognize.


Binding


Once the pairing codes have been exchanged, the devices dynamically (on the fly)
generate and share an encryption key. I
t is this
encryption key

that keeps each Bluetooth

4

connection unique and binding. This binding nature also means that a connection between two
devices can be used only by those two devices. No other device can interfere, or snoop, on the
connection. In oth
er words, if a Blue tooth connection has been established between two mobile
phones, then a third, arbitrary, in
-
range mobile phone cannot eavesdrop on the data transfer. This
only means that at any point of time, a Bluetooth
-
enabled device should technica
lly know all
devices with which it is communicating. At the binding stage, the connection between the two
Bluetooth devices is said to be
established
.


Readers interested in the detailed functionality of the Bluetooth protocol should refer to chapter 3
of

“Bluetooth Demystified” by Nathan J. Muller.


Bluetooth Specs

In order to bring things to closure on the background information on Bluetooth, the table
below gives technical specifications of Bluetooth products.


Table 1. Performance Characteristics of
Bluetooth Product
s [4
]


Feature/Function

Performance

Connection Type

Spread spectrum (frequency hopping)

Spectrum

2.4 GHz ISM band

Transmission Power

1 milliwatt (mW)

Aggregate Data Rate

1 Mbps using frequency hopping

Range

Up to 30 feet (3 meters)

Supported Station

Up to eight (8) devices per piconet

Voice Channels

Up to three (3)

Data Security

For authentication, a 128
-
bit key; for
encryption, the key size is configurable
between 8 and 128 bits

Addressing

Each device has a 48
-
bit MAC address tha
t
is used to establish a connection with
another device.


Pre
-
lab Questions:




QPL.1: What is the different between master
-
master and master
-
slave connection?


QPL.2: Who is required to enter the pairing code during Bluetooth connection?


QPL.3:
What i
s the difference between Bluetooth wireless technologies and other
technologies, such as UWB, 802.11g, 802.11a, 802.11b, WLAN, Wi
-
Fi, AirPort, Infrared,
and Zigbee?


QPL.4: What happens when a master in a piconet switches into another ad
-
hoc network?



5

Lab
Scenario:



For this lab you will set up Bluetooth devices on your Red Hat 4.0 host machine and then on two
virtual machines (Windows) that will communicate with each other.


Beyond transferring files from the NAS, the network connection from the Red Hat
4.0 host and
the virtual machines will not be utilized during this lab. Figure 2 describes the setup after all of
the Bluetooth devices are connected with the understanding that an actual network connection
exists between the host and each of the virtual

machines. Note that in the figure due to hardware
limitations the Red Hat 4.0 host is only scanning for devices. It will not be able to follow the
communication and would have an unlikely chance of even finding the communication at any
given time.




Figure 2.

Lab
s
cenario
.


Section 1: Setup


1.1

Setting up Bluetooth on Linux


Check if BlueZ is installed

First, check to make sure that your Red Hat 4.0 host machine has the BlueZ
(http://www.bluez.org/) Bluetooth protocol stack installed. Attempt to use

the following
commands to determine if this is the case:


# hciconfig


# hcitool


# hcidump


# (clt+c)


6

If all of these commands ran without any problems (if no output was generated or help was
displayed then everything is installed), then you may skip pas
t the section and start setting up the
windows virtual machines for Bluetooth connectivity.

However, if you begin to experience any
problems when using the Linux tools, it is suggested that you use these directions to reinstall
BlueZ incase your previous
installation has some error.


Installing BlueZ on Linux

First you will need to obtain the following 4 files from the NAS under the fol
der for lab
X
:


bluez
-
libs
-
2.25.tar.gz


bluez
-
utils
-
2.25.tar.gz


bluez
-
firmware
-
1.1.tar.gz


bluez
-
hcidump
-
1.30.tar.gz

Place

all four archives into the same directory and run the following commands starting in that
directory to install all four sets of files.




# tar xfzv bluez
-
libs
-
2.25.tar.gz


# cd bluez
-
libs
-
2.25


# ./configure


# make && make installing


# cd ..


# tar xfz
v bluez
-
firmware
-
1.1.tar.gz


# cd bluez
-
firmware
-
1.1


#
./configure

libdir=/lib


# make && make install


# cd ..


# tar xfzv bluez
-
utils
-
2.25.tar.gz


# cd bluez
-
utils
-
2.25


# ./configure


# make && make install


# cd ..


# tar xfzv bluez
-
hcidump
-
1.30.tar.
gz


# cd bluez
-
hcidump
-
1.30


# ./configure


# make && make install


Now that the Bluez Bluetooth protocol stack is installed on your Red Hat 4.0 host machine, you
are ready to begin working with the Windows virtual machines.


1.2

Setting up Bluetooth on Window
s


As previously stated, you will be using two Windows virtual machines during this lab to
demonstrate some of the possible uses of Bluetooth and some simple exploits that rely on faults
in the actual protocol. To set up the virtual machines you will nee
d to do two main things, place
the WIDCOMM4.zip file on to each machine and get a separate Bluetooth device connect to
each. For the file, simply retrieve the archive from the folder for lab XX on the NAS. The
second part will sometimes be a bit tricky
.


7


First Method for Connecting USB Bluetooth dongle

The simplest way to accomplish this will be to insert the usb Bluetooth dongle while the virtual
machine has focus. Typically, this will give device priority to the virtual machine. If you
receive
an error message indicating that the device is in use from “hci_usb”, then you will need
to use the more extensive method for getting the usb dongle connected to the virtual machine.


Second Method for Connecting USB Bluetooth dongle

If the pervious met
hod failed, then you will need to open a terminal on the Red Hat 4.0 host and
run the following command:


# rmmod hci_usb

On occasion the hci_usb module has been know to cause a segmentation fault at this point which
will completely freeze the system. If

this occurs your only option is to manually turn off the
machine, remove all the usb devices and restart th machine. If after restarting, the mouse and/or
keyboard seem to be not functioning, unplug and reconnect each from the usb ports where they
are c
onnected and functionality should return. Log back into the Red Hat 4.0 host and before
starting up vmware check the directories of each virtual machine for and WRITELOCK files and
remove them. Experience has shown the following to work if you had probl
ems with the
pervious method. Before starting any virtual machines, insert one usb dongle and run the
command


# rmmod hci_usb

Then insert another usb dongle and run that command again. Run the following command to
make sure that neither is connected t
o the Red Hat 4.0 Host:


# hciconfig

If nothing happens then you are good. If any devices are listed then try the rmmod command
again.


The previously mentioned segmentation fault only seems to occur when a virtual machine is
started, but if it does oc
cur again, restart the machine once manually, then restart it again cleanly
from the operating syetem after logging in. Then repeat the procedures for interesting one and
using rmmod, and then inserting the other and using rmmod


At this point both usb
Bluetooth dongles should be connected to the machine, but neither is
claimed by the Red Hat 4.0 host. Now start up both virtual machines. Make XP1 the virtual
machine with focus and select from the vmware toolbar menu

VM
-
>Removable Devices
-
>USB Devices
-
>Kensington Bluetooth EDR Dongle.

Repear for XP2, this time choosing the Kensington Bluetooth EDR Dongle (Port 1).


Installing the WIDCOMM Drivers (do for each virtual machine)

Now that both windows virtual machines have a Bluetooth device connected to the
m (windows
may have already installed some default drivers for use with the device), you will need to unzip
the WIDCOMM4.zip archive and run the setup.exe file located in the
“Kensington 4.0.1.2400”
folder. You should be presented with the screen shown in

Figure 3.




8



Figure 3.

Bluetooth installation program.


First click the button for “Click to Install”
. At this point

u
nless you want to change w
h
ere the
software is installed to on the system, then
you should
just click through the menu
and
accept
the
licensing agreement when prompted. After installing, you will
be prompted to
resta
rt the virtual
machine. You should do so before continuing.


Setting up the WIDCOMM Software (do for each virtual machine)

After installing WIDCOMM on each of the Win
dows virtual machines and restarting them,
you
will notice an additional icon on the taskbar.

1.
To get started on configuring the Bluetooth device, right click on the icon as shown in Figure
3.



Figure
4
.

Start Using Bluetooth


2. After selecting to

“Start Using Bluetooth” you will be prompted by the “Initial Bluetooth
Configuration Wizard”. Click Next.

3. On the next screen

(shown in Figure 4)

enter “XP1” as the computer name for the first
Windows virtual machine and when setting up the second vi
rtual machine use the name “XP2”.
Leave the Computer Type as “Desktop”
. Click


9



Figure 5
.
Bluetooth computer name and type setup.


4.

Click Next on the following two screens. When you are presented with the option to click
Skip do so. Then click Fini
sh.


Q
1.1
: What is the range of Bluetooth transmitter/receivers?



Q
1.2
: How is Bluetooth used?


Q
1.3
: Will Bluetooth and Wireless LAN (WLAN) interfere with each other?


Section 2:
Friendly
BlueJacking


BlueJacking is the process of sending an anonymous me
ssage from a Bluetooth
-
enabled phone to
another within a range of 10 meter (~33 feet). A recipient won’t know the source of a
BlueJacking message. Also, BlueJacking allows people to send free messages to one another.


BlueJacking is possible due to a smal
l loophole in the initialization stage of the Bluetooth
communication protocol. Before any two Bluetooth
-
enabled devices can communicate with one
another, the devices exchange information during an initial handshake period. During the period,
the initiatin
g Bluetooth device’s name is required to be displayed on the target Bluetooth device
screen. At that step, the initiating device can send a user
-
defined field to the target device. This
field is used during BlueJacking to send the anonymous message. This a
ttack is sometimes also
known as the
OBEX push attack
, since it allows attackers to push data to the victim mobile
phone.


Typically
BlueJacking does not remove or modify any data stored on the victim’s
Bluetooth device. Although BlueJacking cannot cause
any permanent damage to a mobile phone,
it can definitely be irritating and disruptive. Hence, on most occasions, BlueJacking proves to be
a “fun” attack (usually to scare or to flirt) rather than a malicious one. Another limiting factor is

10

that the attack
s can be executed only when both the Bluetooth
-
enabled devices are within 10
meters of one another.


Q2.
1
: How can games utilize OBEX protocol in Bluetooth enabled devices?




Friendly
BlueJacking

Demonstration


To perform the most basic BlueJacking simp
ly change the name given to the Bluetooth device on
the first virtual machine and attempt to initiate a connection to the second virtual machine. The
following procedures will accomplish this:

1.

Right Click on the Bluetooth icon on the taskbar and sele
ct “Advanced Configuration”

2.

The first tab in labeled General. On this tab you are able to change the name
of
this computer
as it is seen by other Bluetooth devices.
Change the name to any message you want to appear
on the XP2 machine. Then click O
K to save the changes and exit the configuration window.

3.


Right click on the icon again. This time select Quick Connect
-
>File Transfer
-
>
Find Devices
(shown in Figure 6).




Figure 6.

Sending the message via Bluejacking technique.


5.

You will be presen
ted for a window and after WIDCOMM is done scanning for local
Bluetooth devices you screen should resemble Figure 7.

More than the XP2 machine may be
listed. Ignore all of the others an
d select the XP2, then click Open.





11

Figure 7.
Remote device list
.


5.

After a few moments a tool tip will pop up on the Bluetooth icon informing you that the XP2
machine is requesting a PIN code for the connection. Do as the tool tip instructs and click on it.
Enter any PIN you would like and click OK.

6. Switc
h to the XP2 machine. A similar tool tip should have appeared in the same location.
This time instead of having the name “XP2” listed, the name you entered in place of XP1 should
be present in the message. If it has not already appeared then wait a f
ew seconds.
Take a
screenshot of the message (Screenshot #1)
.



At this point feel free to change the name of the Bluetooth device on the first Windows virtual
machine back to XP1 using the same method employed to change it to the message.


The message

you sent should have appeared similar to the message shown in Figure 8.




Figure 8.

You’ve been BlueJacked.


In a windows environment, the message appears very small contained in a tool tip; however, on
cell phones the senders name would typically be m
ore prominent due to the smaller screen. For
this reason, BlueJacking can be used as a form of messaging between blue people using
Bluetooth devices on which the name can be modified.


Section
3
: Contacts and Malicious BlueJacking


The second (and poss
ibly malicious) use of BlueJacking is to initiate a business card exchange (a
relatively common thing at business conventions). To do this using WIDCOMM and Windows,
Outlook Express can be used to create the contact and push it to a nearby Bluetooth

enabl
ed
device. First you will need to modify a security setting on the device that will be sending the
contact.

1. On XP1, right click on the Bluetooth icon and select Advanced Configuration.

2. Select the Client Applications tab.

3. Select PIM Ite
m Transfer and click Properties.

4. Uncheck the box for “Secure Connection”.


Intended Usage of Contact Exchange

Now
you just need to create and send
the contact.

1.
On XP1, start Outlook Express and click cancel if prompted to create a new user account.


2. Click on the Contacts button near the bottom left and select “New Contact…”.


12

3. Enter all of the fields as shown in Figure 9.

First is set to “Henry”. Last is set to “Owen”.
And an email address of “henry.owen@ece.gatech.edu” was added to the

E
-
Mail Addresses.




Figure 9.

New outlook contact.


4.
After creating
the

contact,
open the Address Book in Outlook Express.

5. Right Click on the contact and select Action
-
>Send To Bluetooth
-
>
Other…

6. You will receive a prompt to select a Bluetoot
h device to which you will send the contact
after a short time spent scanning for nearby devices. Select the XP2 device from the list and
click Open.

7. On the XP2 machine, start Outlook Express (again canceling the request to make a new
account). Not
ice that on the contact list an entry has been added for “Henry Owen”
. If you
want, you can double check that this contact contains all of the information entered on the XP1
machine. If the contact is not already listed then wait a few moments as it tra
nsfers from the
XP1 machine.



Malicious Usage of Contact Exchange

When used as intended pushing a contact seems harmless.

However, notice that very little
indication was given that this contact was sent from XP1. You might have notice a tool tip
indic
ating the PIM item transfer but it disappears very quickly.

Now to demonstrate how this
information can be used with a malicious intent you will modify the contents of the contact on
XP2.

1. On XP1, open the Address Book in Outlook Express, right clic
k on the contact “Henry
Owen”, and select Properties.

2. On the Name tab (the second one from the left), you can modify the copy of this contact on
XP1. Change the
email address
and any other fields
to anything you like and click OK.

3. Right Click on

the contact and select Action
-
>Send To Bluetooth
-
>Other…

4. Select to send the contact to XP2 as you did before.


13

5. After a short time check the contents of the contact on XP2 and notice that
it is now a copy of
m
odified contact sent from XP1.


Take a

screenshot of the modified user on XP2 (
S
creenshot #2)


In the realm of computers the

significance of this attack may seem only an annoyance r
ather than
exploitive and damaging
; however consider for a moment the typical entries in most cell phone
contact
lists. Attackers can guess commonly used names such as “Home” or “Work” and
replace the number for the contact with a number that charges the caller some arbitrary
connection fee.
The WIDCOMM software can actually be configured to require a pairing for

the contact exchange; however, for cell phones, contact (or business card as it is commonly
called) exchange typically just prompts the user to either accept or reject a PIM item transfer
from a particular user. Most cell phones do not let users know in

advance the contents of the
PIM item transfer (i.e., the contact name being sent). At large business conventions, it is fairly
common to receive another person’s business card in this manner, so many people may just
simply accept the contact without con
sider that it might be something malicious.


BlueJacking Countermeasures




Disable Bluetooth
: Only enable Bluetooth when it is needed and disable it while in
crowded places or upon receiving an anonymous message.



Employ Undiscoverable/Hidden mode
: Configu
re Bluetooth settings and putting the
Bluetooth device in the Undiscoverable or Hidden mode is a more practical
countermeasure. A Bluetooth device can be set to this option after pairing it with any
Bluetooth
-
enabled devices or accessories in use. This ens
ures that when an attacker (who
is not in the allowed list) searches for Bluetooth devices, your Bluetooth device will not
show up. At the same time, you can continue using Bluetooth to connect to other devices.



Don’t answer
: Do not accept any messages wh
ile you are in a crowded place.


Q3
.
1

Can changing the phone name in a Bluetooth enabled phone be a countermeasure?
Why or why not?


Section
4
: RedFang


When setting up the Bluetooth devices on the Windows virtual machines, you might have
noticed an optio
n to make the Bluetooth device undiscoverable. While in this mode, the device
will not respond to simple scans; however, a simple and robust proof of concept exists called
RedFang that proves that it is possible to discover such a device. Even though th
e device will
not respond to scans, it still will respond to direct requests targeted at its address. RedFang
takes advantage of this and performs a brute force traversal of all possible addresses. The
process take a very large amount of time when usin
g only one Bluetooth device, but the program
supports usage of multiple devices to speed up the process.
In this lab to

speed up this process
but still prove that undiscoverable devices can still be found, you will put the XP1 machine into
such a mode, a
nd then use
RedFang from the Red Hat 4 host to find the hidden device.



14

First you will need to retrieve the file redfang.2.5.tar.gz from the lab XX folder on the NAS.
From the directory where the archive is located, execute the following commands:



# t
ar xfzv redfanf.2.5.tar.gz


# cd redfang
-
2.5


# make

At this point you may n
ot actually have a USB Bluetooth Dongle connected and active on the
Red Hat 4.0 host. For this section you will need only XP1, so turn off XP2 then unplug and
reinsert the USB B
luetooth Dongle that it was being used by that virtual machine. To configure
this Bluetooth device on the Red Hat 4 host simply run the following command to bring up the
device after inserting it:


# hciconfig hci0 up

Then
to check that it is working


#
hcitool scan

The result should show XP1 and its address (more could be listed if any other Bluetooth enabled
devices are nearby).
Make note of this address since it will be used when finding the hidden
device.


Now, follow these directions to place the XP
1 device into undiscoverable mode.

1. On XP1, right click on the Bluetooth icon and select Advanced Configuration.

2. Select the Accessibility tab and deselect the option “Let Other Bluetooth devices discover this
computer” (Figure
10).




Figure 10.

Making the Bluetooth device hidden from scans.


To prove that the device can still be found, run the following command from the redfang
-
2.5
directory

where “address” is the address of XP1 without all of the colons between the octets
:


# fang
-
r address
-
a
ddress


15


The device should have been found and some information displayed about it in the terminal.


Take a screen shot of RedFang results (Screenshot #3).


Section 5
: Additional Bluetooth Vulnerabilities


BlueSnarfing


Many Bluetooth enabled devices have a

variety of sensitive data stored on them: from address
book contact to personal photographs, from private messages to business cards. An even larger
number of people assume that the data stored on their Bluetooth device is completely secure.
Unfortunately
, that is not at all true. It is possible for an attacker to connect to your Bluetooth
device and gain access to all personal data on it.


Bluesnarfing
is the process of connecting, via Bluetooth, to a vulnerable mobile phone without
the victim’s knowledg
e and gaining access to sensitive data. If your mobile device has Bluetooth,
you are probably vulnerable to BlueSnarf attacks. If an attacker is within 10 meters and has the
right tools, he can easily break into your device and steal all data stored on it.


In addition, a
BlueSnarfer can forward or initiate phone calls, if your mobile device is a Bluetooth enabled
phone.


The previous section discusses how a BlueJacker can push anonymous messages onto a victim’s
mobile phone using OBEX push. BlueSnarfing c
an be described as the comple opposite. It is an
attack wherein the attacker can steal data from a vulnerable mobile phone using
OBEX pull
. In
other words, OBEX protocol pulls data.


BlueSnarfing Countermeasure



Longer pairing code
:

The Bluetooth protocol
allow s16
-
digit pairing codes.
Unfortunately, many applications continue to use only 4
-
digit pairing codes. This makes
Bluetooth
-
enabled devices using a short pairing code vulnerable to brute force attacks
executed with the help of a Bluetooth
-
enabled comp
uter. Hence, an attacker can use brute
force to crack the pairing code and execute further malicious activities. Unfortunately,
most people have the tendency to select and use short pairing codes.



Pair Code Cracking


We have already seen how important a
nd integral pair codes are to the Bluetooth communication
protocol. A very interesting paper titled “Cracking the Bluetooth PIN,” written by Yaniv Shaked
and Avishai Wool, explains the process of cracking the PIN of a Bluetooth device. You can find
the pap
er at
http://www.eng.tau.ac.il/~yash/shaked
-
wool
-
mobisys05/
.


Counter Measures



Use long pairing codes:
(covered in previous section)


16



Avoid default pairing codes:
Developers and manufact
ures must avoid using default
pairing codes; attackers can easily guess and crack such codes. In other words, it is very
important for applications to ensure tha the input values that are used to generate the
challenge responses are random enough to make l
ife for an attack tougher.




Delete unwanted pairing:
Check the paired devices list on your device and remove any
Bluetooth pairing you do not want.



Unit Key Attacks


Several Bluetooth
-
enabled devices use one unit key for connections with all other device
s. This
means that the same unit key has to be shared and sent to all devices with which it
communicates. Hence, all trusted devices that communicate with such Bluetooth devices must
have access to its unit key. A trusted device can be used to impersonate
the identity of a
vulnerable device and eavesdrop on all data transfer. Although unit keys are not recommended
by the latest Bluetooth implementation, they exist to provide backward compatibility.


BlueSmacking
-

“The ping of Death”


Each Blutooth
-
enabled

mobile device has a restriction on data packet size. In other words, the
Bluetooth implementation is not designed to handle packets greater than a predefined maximum.
During a Blusmack Attack, the attacker creates an oversized data packet having a size gr
eater
that the maximum allowable size and sends it to the victim mobile device. A mobile phone
receiving an oversized packet will likely perform just as the attacker would like.


The BlueSmacking MDOS attack makes use of a protocol known as the
Logical Li
nk Control
and Adaptation Layer Protocol (L2CAP
)
. This protocol is part of the Bluetooth communication
suite that conveys
quality of service (QoS)
. In other words, Bluetooth’s L2CAP layer is
something like the ICMP function for the TCP/IP protocol suite. M
oreover, this protocol has a
number of features that check for and prevent any potential errors that could occur during data
transfer. Among other things, L2CAP layer allows a Bluetooth
-
enabled device to request an echo
from another device testing its pres
ence.


Theoretical

BlueSmacking Attack

(works on some cell phone)

The
Linux Bluez package
, a Bluetooth implementation for the Linux platform, ships with number
of standard tools including l2ping. By default, the l2ping utility normally sends a data packet

of
20bytes. However, in BlueSmacking, the attacker manually customizes the size of the outgoing
data packer. The data packet’s size is easily customized with l2ping tools’s

s size

argument.


l2ping [
-
S source address ] [
-
c count ] [
-
s size ] [
-
f ] <

address >




17

Possible A
dditions to the Lab


Man
-
in
-
middle attacks


Bluetooth allows the DESTINATION device to authenticate the identity of the SOURCE
device by asking it to compute the challenge response (which is required for authentication).
However, th
e DESTINATION identity is never authenticated by the source. This means
Bluetooth vulnerable to a number of man
-
in
-
middle attacks, where an attacker pretends to be an
authentic DESTINATION device.


Brute force attacks


A number of people set their Bluetoo
th device to Hidden mode. Such a strategy also
protects your privacy by hiding the device’s
media access control (MAC)

address, which is
basically the phone’s device’s unique identity. However, brute force can obtain the MAC address
even if it is in Hidden

mode. For example, the Redfang tool is one of the most dangerous such
crackers.


Denial
-
of
-
services (DoS attacks)


Bluetooth is nothing but radio signals working in the 2.4 GHz frequency range. This
makes it vulnerable to interference (jamming) or DoS at
tacks by a number of other noisy
appliances like phones, microwave ovens, and more. Bluetooth uses a process called frequency
hopping, changing its operating frequency to make it difficult to carry out a jamming attack, but
it is still possible.

























18

References


[1]

Network Architecture

<
http://bwrc.eecs.berkeley.edu/Research/Pico_Radio/docs/networkTopo/bluetoothTopo.htm
>


[2]
BlueZ
:
Official Linux Bluetooth protocol stack
.
<
http://www.bluez.org/
>


[3]
Gehrmann, Christian, and Joakim Per
sson.
Bluetooth Security (Artech House Computer
Security Series)
. Colorado:
Artech House Publishers, 2004.


[4]
Muller, Nathan.
Bluetooth Demystified
. New York:
McGraw
-
Hill Professional Publishing,
2000.


[5]
RedFang archive
<
http://zone
-
h.org/en/download
/category=74/
>


19

Appendix A


Setting up Shared Folders in VMWare


1.

Make sure that the virtual machine is “Powered Off” (not just suspended).

2.

In the menu go to VM


Settings

3.

Click on the Options tab

4.

Select “Shared Folders”

5.

Click “Add…”

6.

Name it however you wou
ld like.

7.

Enter the path of the folder on the host machine that you want to make available to the
virtual machine. Typing in “/” will make the entire host filesystem available.

8.

Make sure “Enable this share” is selected, and click OK.

9.

Click OK again.

10.

Power
up the virtual machine.


In Linux, the share appears under
/mnt/hgfs

In Windows, access it by typing
//.host/Shared Folders

in the run box of in the explorer address
bar.















20

Answer Sheet Lab 9


Group Number:
_____________


Member Names:

________
______________ _______________________


Pre
-
lab:



QPL.1:
What is the different between master
-
master and master
-
slave connection?









QPL.2:
Who is required to enter the pairing code during Bluetooth connection?








QPL.3:

What is the difference

between Bluetooth wireless technologies and other technologies,
such as UWB, 802.11g, 802.11a, 802.11b, WLAN, Wi
-
Fi, AirPort, Infrared, and Zigbee?








QPL.4:
What happens when a master in a piconet switches into another ad
-
hoc network?







21

Section 1
:



Q
1.1
:
What is the range of Bluetooth transmitter/receivers?










Q
1.2
:
How is Bluetooth used?









Q
1.3
:
Will Bluetooth and Wireless LAN (WLAN) interfere with each other?









Section 2:


Screenshot #1


Q2.1
:
How can games utilize Bluetooth

option?













22

Section 3:


Screenshot #2



Q3.1
:
Can changing the phone name in a Bluetooth enabled phone be a countermeasure? Why or
why not?














Section 4:



Screenshot #3


General Questions


H
ow long did it take you to complete this lab?

Was it an appropriate length lab?






What corrections and or improvements do you suggest for this lab? Please be very specific
and if you add new material give the exact wording and instructions you would give to
future students in the new lab handout.
You may cross out and edit the text of the lab on
previous pages to make minor corrections/suggestions. General suggestions like add tool
xyz to do more capable scanning will not be awarded extras points even if the statement is
totally true. Specific text

that could be cut and pasted into this lab, completed exercises,
and completed solutions may be awarded additional credit. Thus if tool xyz adds a
capability or additional or better learning experience for future students here is what you
need to do. You

should add that tool to the lab by writing new detailed lab instructions on
where to get the tool, how to install it, how to run it, what exactly to do with it in our lab,
example outputs, etc. You must prove with what you turn in that you actually did th
e lab
improvement yourself. Screen shots and output hardcopy are a good way to demonstrate
that you actually completed your suggested enhancements. The lab addition section must

23

start with the title “Lab Addition”, your addition subject title, and must sta
rt with a
paragraph explaining at a high level what new concept may be learned by adding this to
the existing laboratory assignment. After this introductory paragraph, add the details of
your lab addition.


Turn In Checklist


1)

Completed Answer Key

2)

3 Screenshots