Download Bluetooth Security - Lab 10 | Internetwork Security | ECE 4112 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
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 materials 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 with 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 one 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 connect 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:
Master-master connection. This setup is one in which all the Bluetooth 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-master 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 Bluetooth-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 preprogrammed 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 slaves. 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
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 other 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 technically 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 Products [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 that 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 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?
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 scenario.
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)
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 method 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 connected 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 problems 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 to 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 occur 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 them (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.
Figure 3. Bluetooth installation program. First click the button for “Click to Install”. At this point unless you want to change where 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 restart 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 Windows virtual machines and restarting them, you will notice an additional icon on the taskbar.
- To get started on configuring the Bluetooth device, right click on the icon as shown in Figure
- Figure 4. Start Using Bluetooth
- After selecting to “Start Using Bluetooth” you will be prompted by the “Initial Bluetooth Configuration Wizard”. Click Next.
- 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 virtual machine use the name “XP2”. Leave the Computer Type as “Desktop”. Click
a “fun” attack (usually to scare or to flirt) rather than a malicious one. Another limiting factor is that the attacks 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 simply 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:
- Right Click on the Bluetooth icon on the taskbar and select “Advanced Configuration”
- 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 OK to save the changes and exit the configuration window.
- 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.
- You will be presented 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 and select the XP2, then click Open.
Figure 7. Remote device list.
- After a few moments a tool tip will pop up on the Bluetooth icon informing you that the XP 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.
- Switch 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 few 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 more 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 possibly 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 enabled device. First you will need to modify a security setting on the device that will be sending the contact.
- On XP1, right click on the Bluetooth icon and select Advanced Configuration.
- Select the Client Applications tab.
- Select PIM Item Transfer and click Properties.
- Uncheck the box for “Secure Connection”. Intended Usage of Contact Exchange Now you just need to create and send the contact.
- Right Click on the contact and select Action->Send To Bluetooth->Other…
- Select to send the contact to XP2 as you did before.
- After a short time check the contents of the contact on XP2 and notice that it is now a copy of modified contact sent from XP1. Take a screenshot of the modified user on XP2 (Screenshot #2) In the realm of computers the significance of this attack may seem only an annoyance rather 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 consider 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 : Configure 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 ensures 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 while 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 option 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 the 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 using 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, and then use RedFang from the Red Hat 4 host to find the hidden device. 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:
tar xfzv redfanf.2.5.tar.gz
cd redfang-2.
make
At this point you may not 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 Bluetooth 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 XP1 device into undiscoverable mode.
- On XP1, right click on the Bluetooth icon and select Advanced Configuration.
- 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.
Counter Measures Use long pairing codes: (covered in previous section) Avoid default pairing codes: Developers and manufactures 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 life 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 devices. 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 greater 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 Link 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. Moreover, 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 presence. 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 >
Possible Additions 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, the 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 Bluetooth 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 attacks 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.
Appendix A
Setting up Shared Folders in VMWare
- Make sure that the virtual machine is “Powered Off” (not just suspended).
- In the menu go to VM Settings
- Click on the Options tab
- Select “Shared Folders”
- Click “Add…”
- Name it however you would like.
- 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.
- Make sure “Enable this share” is selected, and click OK.
- Click OK again.
- 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.
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?
