how does bluetooth scanning work

how to scan bluetooth windows 7 and how to scan bluetooth devices in android and what is bluetooth scanning, bluetooth scanning rate bluetooth scanning and reconnaissance
Dr.RajeshArora Profile Pic
Published Date:29-08-2017
Your Website URL(Optional)
8 273 Bluetooth Scanning and Reconnaissance274 Hacking Exposed Wireless: Wireless Security Secrets & Solutions ike any successful hack, the attack phase includes gaining an understanding of the technology behind your target, scanning and reconnaissance analysis, and Lconcludes with attack and exploitation. In this chapter, we’ll examine the core concepts of the Bluetooth specification, followed by a look at the tools and techniques for Bluetooth scanning and reconnaissance. This chapter covers finding a good Bluetooth adapter (as well as a good driver), multiple options for identifying Bluetooth devices near you, and steps for assessing a target once you find it. We’ll also examine techniques for leveraging OS-native and third-party tools for Bluetooth scanning with active scanners, tools for mobile platforms, and advanced techniques that utilize the Universal Software Radio Peripheral (USRP) available from Ettus Research. BLUETOOTH TECHNICAL OVERVIEW The goal of this section is to describe the interactions of Bluetooth devices at a high level, without assuming significant knowledge of the underlying protocols. We’ll cover basic concepts such as device discovery, frequency hopping, and piconets. An expanded version of this introduction, which covers a great deal more detail surrounding the nuances of the Bluetooth specification, is available online at the book’s companion website at The Bluetooth specification defines 79 channels across the 2.4-GHz ISM band, each 1-MHz wide. Devices hop across these channels at a rate of 1600 times per second (every 625 microseconds). This channel-hopping technique is known as Frequency Hopping Spread Spectrum (FHSS), and in current Bluetooth implementations, the user can get 3-Mbps of bandwidth with a maximum intended distance of approximately 100 meters. FHSS provides robustness against noisy channels by rapidly moving throughout the available RF spectrum. Any set of devices wanting to communicate using Bluetooth needs to be on the same channel at the same time, as shown in the illustration. Devices that are hopping in a coordinated fashion can communicate with each other, forming a Bluetooth piconet, the basic network model used for two or more Bluetooth devices. Every piconet has a single master and between one and seven slave devices. Communication in a piconet is strictly between a slave and a master. The channel-hopping sequence utilized by a piconet is pseudorandom and can only be generated with the address and clock of the master device. 275 Chapter 8: Bluetooth Scanning and Reconnaissance Device 1 and 2 form a piconet; they are channel hopping in step with each other. 1 8 5 4 7 6 10 2 9 12 3 11 Device 1 (master) Device 2 (slave) 5 1 8 4 7 6 10 2 9 12 3 11 Device 3 is not part of the piconet; it is unaware of the channel hopping sequence in use by the other devices. Device 3 6 4 5 10 1 2 6 3 11 8 9 7 Device Discovery Like all wireless protocols, Bluetooth has to determine whether potential peers are in range. This issue is significantly complicated when using FHSS devices. Assume, for a moment, that a device is already interacting in a piconet (hopping along with its peers), but it is also discoverable, which means it allows itself to be identified through its Bluetooth Device Address (BD_ADDR) by other devices not already in the piconet. To do this, the device must quit hopping along with its piconet peers temporarily, listen for any devices that are potentially looking for it, respond to those requests, and then catch back up with its piconet buddies. Devices that periodically check for devices looking for them are said to be “discoverable.” Many devices aren’t discoverable by default, so you must enable this feature specifically, usually for a brief period of time. A device is said to be nondiscoverable if it simply ignores (or doesn’t look for) discovery requests. The only way to establish a connection to one of these nondiscoverable devices is to determine its BD_ADDR through some other means. Protocol Overview A Bluetooth network has a surprising number of protocols. They can generally be broken up into two classes: those spoken by the Bluetooth controller, and those spoken by the Bluetooth host. For the sake of our discussion, the Bluetooth host is the laptop you are trying to run attacks from. The Bluetooth controller is sitting on the other end of your USB port, interpreting commands from the host. Figure 8-1 shows the organization of layers in the Bluetooth stack and where each layer is typically implemented. The controller is responsible for frequency hopping, baseband encapsulation, and returning the appropriate results to the host. The host is 276 Hacking Exposed Wireless: Wireless Security Secrets & Solutions PPP, IP stack, Apps Bluetooth BT profiles host (RFCOMM, BNEP, OBEX) (laptop) L2CAP HCI link Host Controller Interface (USB or serial) (HCI) Link Manager Protocol (LMP) Bluetooth controller Baseband controller, framing (silicon chipset) Radio interface, RF controller Ant Figure 8-1 Bluetooth host and controller interaction responsible for the higher layer protocols. Of particular interest is the HCI link, which is used as the interface between the Bluetooth host (your laptop) and the Bluetooth controller (the chipset in your Bluetooth dongle). When dealing with Bluetooth, keep this Host/Controller model in your mind. As hackers, the thing we most desire is control over a device. The separation of power in the model shown in Figure 8-1 means we are very much at the mercy of the Bluetooth controller. No matter how much we want to tell the Bluetooth controller, “Stick to channel 6 and blast the following packet out forever,” unless we can map this request into a series of HCI requests (or find some other way to do it), we can’t. We just don’t have that much control over the radio. Radio Frequency Communications (RFCOMM) RFCOMM is the transport protocol used by Bluetooth devices that need reliable streams- based transport, analogous to TCP. The RFCOMM protocol is commonly used to emulate serial ports, send AT commands (Hayes Command Set) to phones, and to transport files over the Object Exchange (OBEX) protocol. 277 Chapter 8: Bluetooth Scanning and Reconnaissance Logical Link Control and Adaptation Protocol (L2CAP) L2CAP is a datagram-based protocol, which is used mostly to transport higher layer protocols such as RFCOMM to other upper-layer protocols. An application-level programmer can use L2CAP as a transport protocol, operating similarly to the UDP protocol—as a message-based, unreliable data-delivery mechanism. Host Controller Interface (HCI) As mentioned previously, the Bluetooth standard specifies an interface for controlling a Bluetooth chipset (controller), leveraging the HCI interface layer. The HCI is the lowest layer of the Bluetooth stack that is immediately accessible to developers with standard hardware, accommodating remote device-friendly name retrieval, connection estab- lishment, and termination. Link Manager Protocol (LMP) The Link Manager Protocol (LMP) is the beginning of the controller protocol stack, making it inaccessible without specialized hardware. LMP handles negotiation such as low-level encryption issues, authentication, and pairing. While the controlling host may be aware of these features, and explicitly request them, the controller’s job is to determine what sort of packets need to be sent and how to handle the results. Baseband Like the LMP layer, the baseband layer is inaccessible to developers without custom hardware tools. The Bluetooth baseband specifies over-the-air characteristics (such as the transmission rate) and the final layer of framing for a packet. Bluetooth Device Addresses (BD_ADDR) Bluetooth devices come with a 48-bit address, as shown here, formed into three parts:  NAP The Nonsignifi cant Address Part consists of the fi rst 16 bits of the OUI (organizationally unique identifi er) portion of the BD_ADDR. This part is called nonsignifi cant because these 16 bits are not used for any frequency hopping or other Bluetooth derivation functions.  UAP The Upper Address Part composes the last 8 bits of the OUI in the BD_ADDR.  LAP The Lower Address Part is 24 bits and is used to uniquely identify a Bluetooth device. NAP UAP LAP 16 bits 8 bits 24 bits 278 Hacking Exposed Wireless: Wireless Security Secrets & Solutions Unlike other wireless protocols, the BD_ADDR information is held as a secret in Bluetooth networks. The BD_ADDR information is not transmitted in the header of frames as in Ethernet and Wi-Fi networks, preventing an attacker from using simple eavesdropping techniques to discover this value. Without the BD_ADDR information, attackers will find it hard to determine the frequency hopping pattern being used, increasing the difficulty of traffic eavesdropping. Bluetooth Profi les In addition to the structured Bluetooth stack layers, the Bluetooth SIG also specifies multiple application-layer profiles. These profiles define additional functionality and security mechanisms for various Bluetooth uses. Implemented on the local host, these profiles can be manipulated freely without specialized hardware. Available profiles include the Service Discovery Protocol (SDP), Advanced Audio Distribution Profile (A2DP), Headset Profile (HSP), Object Exchange Profile (OBEX), and Personal Area Network Profile (PANP). Encryption and Authentication Encryption and authentication are built into the Bluetooth standard and implemented directly in the Bluetooth controller chip as a cost-savings measure for adopters and developers. The use of encryption and authentication are optional; a vendor can choose to use neither authentication nor encryption, either encryption or authentication, or both. Bluetooth authentication is implemented through traditional pairing or through the more recently added Secure Simple Pairing (SSP). SSP was added in version 2.1 of Bluetooth, but hasn’t been widely adopted at the time of this writing. We’ll examine both authentication mechanisms next. Traditional Pairing The traditional pairing process was superseded in the Bluetooth 2.1 specification with the Secure Simple Pairing (SSP) exchange, though the traditional pairing exchange is still used by the majority of Bluetooth devices available today. Using traditional pairing, when two devices first meet, they undergo a pairing exchange, in which a security key known as the link key is derived from a BD_ADDR, a personal identification number (PIN), and a random number. Once this exchange is completed, both devices store the link key information in local nonvolatile memory for use in later authentication exchanges and to derive encryption keys (when used). If an attacker observes the traditional pairing exchange used to derive the link key, as well as a subsequent authentication exchange, then attacking the PIN selection is possible. Commonly, this is carried out in a PIN brute-force attack: a PIN guess is made and then used to derive a possible link key and the guess is validated by comparing locally computed authentication results to those observed in the legitimate exchange. We’ll examine this attack in depth in Chapter 10. 279 Chapter 8: Bluetooth Scanning and Reconnaissance Secure Simple Pairing The biggest problem with the traditional pairing scheme just outlined is that a passive attacker who observes the pairing can quickly recover the PIN and stored link key. If an attacker is able to recover the link key, he can decrypt all traffic exchanged over the Bluetooth network and impersonate legitimate devices. The Secure Simple Pairing (SSP) process attempts to prevent a passive observer from retrieving the link key, while also providing multiple authentication options for varying Bluetooth device types. SSP improves the authentication exchange in Bluetooth by leveraging public key cryptography, specifically through the Elliptic Curve Diffie-Hellman (ECDF) exchange. A Diffie-Hellman key exchange allows two peers to exchange public keys and then derive a shared secret that an observer will not be able to reproduce. The resulting secret key is called the DHKey. Ultimately, the link key is derived from the DHKey for subsequent authentication and encryption key derivation. By using a Diffie-Hellman key exchange, a strong entropy pool is available for deriving the link key. This strong entropy pool solves the biggest problem with the standard pairing derivation, where the sole source of entropy was a small PIN value. Having completed an introduction to Bluetooth technology components, we’ll continue to examine Bluetooth from an attacker’s perspective. As we examine the various attacks against Bluetooth technology, we will dig into the related technology and components supporting this worldwide standard. PREPARING FOR AN ATTACK By spending some time up-front preparing for a Bluetooth attack, you’ll reap the benefits of functional systems that out-perform off-the-shelf components. In this section, we’ll provide some guidance on selecting a Bluetooth attack device and techniques for extending the range of the device. Selecting a Bluetooth Attack Device In preparing your Bluetooth attack arsenal, one of the first—and most important— decisions you’ll need to make is selecting a Bluetooth interface with which to launch your attacks. This decision may seem fairly trivial; pick any old Bluetooth interface, plug it in, and you’re good to go. Although this method can work in close-proximity lab environments (and if you’re fairly lucky), you will likely have an entirely different experience if you try to attack a real-world target. Bluetooth Interface Power Classes The Bluetooth specification defines three functional power classes for manufacturers to follow when producing Bluetooth interfaces. These classes influence the effective use of Bluetooth technology by identifying the maximum output power of a transmitter. For example, a Bluetooth headset device does not normally require a significant distance for communication because it is often paired with a phone in the user’s pocket or on a nearby 280 Hacking Exposed Wireless: Wireless Security Secrets & Solutions desk. To get the best battery performance on headsets, implementing a device that transmits at a power level that can achieve distances greater than the intended use cases is not advisable, so most Bluetooth headsets use a moderate output-power level in the radio interface. To satisfy the needs of various Bluetooth implementations, the Bluetooth Special Interest Group (SIG) defined three operational classes with power levels ranging from 1 milliwatt (mW) to 100 mW. This power level is measured at the output of the antenna connected to the Bluetooth interface, with an effective range shown in Table 8-1. While Bluetooth developers may opt for more or less transmit output power in the Bluetooth radio to suit their specific application needs, attackers will nearly always opt for the greatest transmit power for the most effective range. Class 1 devices boasting a transmit power of 100 mW offer ranges approximating that of Wi-Fi devices, with additional range opportunities when paired with an external antenna. Fortunately, marketing teams recognize the consumer selling opportunity for devices that offer the range of Class 1 interfaces and will sometimes prominently display this as a feature on the product packaging. When Is Range Not Optimal for an Attacker? In some cases, a Bluetooth interface that provides the greatest range is not desirable. For example, consider a case in which you wish to set up a Bluetooth attack lab where Bluetooth targets will be available for developing attack skills, research, and experimentation. If this lab is within nearby physical proximity to Bluetooth devices that are not within the scope of your testing, you may inadvertently disrupt or even exploit unauthorized devices. Also, because Bluetooth uses Frequency Hopping Spread Spectrum (FHSS) in the 2.4-GHz band, a higher-power adapter will interfere with a greater number of Wi-Fi devices and other transmitters sharing this crowded band. If these situations are an issue for your organization, using Bluetooth dongles of the class 2 variety to limit the range of Bluetooth activity may be best. If even this reduced range is still an issue, consider RF blocking devices such as a Faraday cage. Extending Bluetooth Range A highly desirable attribute in a Bluetooth attack interface is the ability to extend the effective range of communication. Commonly, this is done by selecting a Class 1 dongle for a transmit capability of 100 mW, but even this optimal range of 100 meters without obstruction leaves something to be desired. To achieve an even greater range, you can shape the RF radiation pattern from the Bluetooth attack interface using a directional antenna. 281 Chapter 8: Bluetooth Scanning and Reconnaissance Power Class Maximum Output Power Estimated Range 1 100 mW (20 dBm) 100 meters (328 feet) 2 2.5 mW (4 dBm) 10 meters (32.8 feet) 3 1 mW (0 dBm) 1 meter (3.28 feet) Table 8-1 Bluetooth Interface Power Classes As Bluetooth operates in the same 2.4-GHz band as IEEE 802.11b and 802.11g devices, a number of antenna options are available. Sites such as and sell a variety of antennas of different gain properties and propagation patterns with prices ranging from US25 to 140. A limited number of commercial Bluetooth adapters are available with external antenna connectors, typically intended for industrial applications. One such product is the SENA Parani UD-100 adapter with a reverse-polarity SMA antenna connector, available through a limited number of resellers identified at Priced at 40 at the time of this writing, this product is attractive as a Bluetooth attack interface based on the chipset used (CSR) and the relatively rugged antenna connector construction, as shown here. Often, you can modify a standard Bluetooth dongle to add an external antenna connector using a soldering iron and basic hardware hacking skills. Visit the book’s companion website for a guide on modifying a Bluetooth dongle to accept an external antenna at http://www 282 Hacking Exposed Wireless: Wireless Security Secrets & Solutions RECONNAISSANCE In the reconnaissance phase of a Bluetooth attack, we’ll examine the process of identifying victim Bluetooth devices in the area through active discovery and passive discovery, using visual inspection and hybrid discovery. The goal of the discovery process is to identify the presence of Bluetooth devices, revealing each device’s 48-bit MAC address or Bluetooth Device Address (BD_ADDR). Once you have discovered a device, you can start to enumerate the services on the device, identifying potential exploit targets. You can also fingerprint the remote device and leverage Bluetooth sniffing tools to gain access to data from the piconet. Here, we’ll examine each of these steps in more detail. Active Device Discovery The first step in Bluetooth reconnaissance scanning is to simply ask for information about devices within range. Known as inquiry scanning in the Bluetooth specification, a device can actively transmit inquiry scan messages on a set of frequencies, listening for responses. If a target Bluetooth device is configured in discoverable mode, it will return the inquiry scan message with an inquiry response and reveal its BD_ADDR, timing information (known as the device clock or CLK), and device class information (e.g., the device type such as phone, wearable device, toy, computer, and so on). Multiple tools exist for active device discovery on various platforms ranging from simple command-line tools to complex GUI interfaces. Let’s examine a few of these tools on different platforms to give you an idea of the available options. Windows Discovery with BlueScanner Popularity: 4 Simplicity: 3 Impact: 3 Risk Rating: 3 BlueScanner is a free tool from Aruba Networks for Bluetooth scanning on Windows XP, Vista, and Windows 7 systems and is shown here in action. Available at http://labs, BlueScanner uses the Microsoft Windows Bluetooth drivers (see the sidebar, “Windows Bluetooth Driver Woes”) to identify and enumerate available devices, characterizing them by name, BD_ADDR, and available services. As an analysis tool, BlueScanner is unique due to the simple feature of applying a location label in the scan results, allowing you to identify any free-form string to describe the devices being discovered (e.g., “Customer AABCE,” “Corporate Office 1,” “airport,” “mall”). 283 Chapter 8: Bluetooth Scanning and Reconnaissance Double-clicking an entry in BlueScanner will open the Bluetooth Device Information dialog, which displays the device name and BD_ADDR information as well as detailed service information. Location information can also be changed for the specific device from this dialog. In the device summary view on the left, BlueScanner will identify the number of devices organized by location, type (phone, headset, laptop), and services. Clicking any individual service will display only the devices running the selected service, making it easy to identify the devices to target with the Object Exchange (OBEX) Push Server, for example. BlueScanner retains the logging information from past scans in a file called bluescanner.dat in the same directory where the program executable is installed. This file is a standard ASCII file, delimited by carriage return and linefeed characters. Using standard Windows or Unix/Linux text-handling tools, such as findstr.exe, grep, and awk, it is possible to cull data from this file for additional reporting needs. A sample Ruby script for parsing BD_ADDR information into a SQL database INSERT statement is available on the book’s companion website at Windows Bluetooth Driver Woes The BlueScanner tool from Aruba Networks relies on the Microsoft Windows Bluetooth drivers on XP, Vista, and Windows 7 systems. This might not seem like a problem; however, it is often a challenge for many BlueScanner users. 284 Hacking Exposed Wireless: Wireless Security Secrets & Solutions Although Microsoft has developed a standard Bluetooth stack of limited features, several competing Bluetooth stack manufacturers have also developed software for Windows, including Widcomm (acquired by Broadcom Corporation), T oshiba, BlueSoleil, and EtherMind. Each software manufacturer ends up competing with Microsoft to be the installed Bluetooth stack on Windows XP, Vista, and 7 systems, controlling all Bluetooth connections for the host. Unfortunately, BlueScanner is incompatible with any Bluetooth stack other than the integrated Microsoft Windows stack. In order to use BlueScanner, you often need to uninstall third-party Bluetooth stacks, allowing the Bluetooth interfaces to plug-and-play and reload the Microsoft stack drivers. However, this option is not always attractive for users, since the Microsoft stack does not include popular Bluetooth features such as the Object Exchange (OBEX) protocol, Object Push Protocol (OPP), and the Hands-Free Profile (HFP), which is popularly used between computers and a headset for Skype support. Furthermore, Microsoft’s Bluetooth stack may not support your hardware at all, making it incompatible with BlueScanner. If you want to run BlueScanner, your best option is to back up your system, ensure you have the installation CD’s for the third-party Bluetooth stack handy, uninstall the third-party Bluetooth stack, and reboot. When Windows reboots, it will attempt to install support for the driver with the native Bluetooth stack. After plug- and-play completes, start BlueScanner and click Configure Radio Information. If the Microsoft Bluetooth stack has configured your Bluetooth dongle, the local Bluetooth BD_ADDR will be listed next to the Address field. If not, try a different dongle, or read on for an alternate Bluetooth discovery tool. Linux Discovery with hcitool Popularity: 4 Simplicity: 4 Impact: 3 Risk Rating: 4 The standard Linux command hcitool can be used for Bluetooth discovery and basic enumeration. When scanning, hcitool will cache information about devices, potentially reporting the presence of devices that were once observed but are no longer within range. To force hcitool to purge the cached results, specify the flush parameter. By default, hcitool will show only BD_ADDR and device name information, but you can collect additional details by adding the all parameter. 285 Chapter 8: Bluetooth Scanning and Reconnaissance hcitool scan all flush Scanning ... BD Address: 00:1D:25:EC:47:86 mode 1, clkoffset 0x729a Device name: SCH-i760 Device class: Computer, Palm (0x120114) Manufacturer: Cambridge Silicon Radio (10) LMP version: 2.0 (0x3) subver 0x7a6 LMP features: 0xff 0xff 0x8b 0x7e 0x9b 0x19 0x00 0x80 3-slot packets 5-slot packets encryption slot offset timing accuracy role switch hold mode sniff mode park state RSSI channel quality SCO link HV2 packets HV3 packets u-law log A-law log CVSD paging scheme transparent SCO broadcast encrypt EDR ACL 2 Mbps EDR ACL 3 Mbps enhanced iscan interlaced iscan interlaced pscan inquiry with RSSI EV4 packets EV5 packets AFH cap. slave AFH class. slave 3-slot EDR ACL 5-slot EDR ACL AFH cap. master AFH class. master extended features For each device that returns a response, hcitool will display information about the device, including the BD_ADDR, the device name and device class, the radio manufacturer and link manager protocol (LMP) version, and feature enumeration details. The LMP version is useful for determining support for various security features. In the example shown, the LMP version is 2.0, predating the Secure Simple Pairing (SSP) mechanism introduced with version 2.1 of the specification. As a result, we know the only authentication requirement for this device is a PIN value and possibly an “accept” prompt on the target device. Linux Discovery with BTScanner Popularity: 4 Simplicity: 4 Impact: 3 Risk Rating: 4 While hcitool is convenient for a quick command-line search of available Bluetooth devices, it doesn’t have the ability to scan continually, only updating the display when new devices are found. For this type of scanning, the Linux tool BTScanner is a better option, providing a simple text-based interface that continually scans for Bluetooth devices, showing a single line of output for each device that has been found. BTScanner attempts to extract as much information as possible without pairing, providing a detailed information view when the user selects a Bluetooth device that has been identified. 286 Hacking Exposed Wireless: Wireless Security Secrets & Solutions Available at by selecting the Downloads link, BTScanner can also be installed through the Ubuntu package management system using apt-get or the Synaptic Package Manager: sudo apt-get install btscanner To start BTScanner, open a terminal and run the command btscanner with root privileges (sudo btscanner). BTScanner will launch with a light-grey background, displaying a listing of hotkeys available in the status window at the bottom. BTScanner uses a system where the user presses a hotkey to start or stop scanning, to save the current results to a logging file, or to start other attacks. A listing of the available hotkeys and their corresponding action is described in Table 8-2. To start scanning for Bluetooth devices, press the i hotkey. BTScanner will display the status line “starting inquiry scan” and will populate the main window with information about discovered devices, including a timestamp identifying when the Hotkey Action h Display help information identifying the available hotkey options. i Start active scanning (inquiry scanning) for Bluetooth devices in discoverable mode. b Start a brute-force discovery attack, continually guessing sequential BD_ADDR’s to discover nondiscoverable devices. This attack is not recommended. a Abort or stop the inquiry or brute-force scanning options. s Save summary details about the Bluetooth devices discovered in this session. o Open a dialog to sort the display of Bluetooth devices based on user preferences. Enter Retrieve additional detail about the selected device, including LMP information and available services. q Leave the detailed device view display, returning to the main display view. Q Quit BTScanner. Table 8-2 BTScanner Hotkey Options 287 Chapter 8: Bluetooth Scanning and Reconnaissance device was discovered, the BD_ADDR of the device, system clock information, the device class, and friendly name information, as shown here. BTScanner will use multiple Bluetooth interfaces concurrently, if more than one is present. This capability allows BTScanner to discover and enumerate devices faster than what would otherwise be possible with a single Bluetooth interface. Bugs in BTScanner Hacking tools such as BTScanner aren’t free from the bugs that plague many modern applications. Sadly, BTScanner hasn’t been actively maintained by the original author in many years and suffers from a few bugs. Disappearing Devices The devices in the BTScanner device listing have been known to appear and then disappear inexplicably. As a workaround, if devices disappear from the display listing, change the sort order by pressing the o hotkey to open the Enter A Sort Method dialog, and then press f and enter to sort by first seen. Fail to Start BTScanner requires a minimum terminal screen width of 80 characters. If you try to start BTScanner with a smaller terminal screen, you will see the status message “Finished reading the OUI database” followed by a return to the shell prompt. Make sure your terminal is at least 80-characters wide (and preferably 24-characters high) or larger before starting BTScanner. Crash on Resize If you try to resize BTScanner while it is running, it will crash with the error “Segmentation Fault.” Before starting BTScanner, make sure your terminal is sized appropriately and do not try to resize it without exiting BTScanner first. 288 Hacking Exposed Wireless: Wireless Security Secrets & Solutions One of BTScanner’s great features is the logging information generated for each device that is discovered. When you start BTScanner, it will create a directory in the user’s home directory called bts. Within this directory, BTScanner will create a directory for each node discovered, based on the device’s BD_ADDR, replacing the common colon- delimiting notation with an underscore (e.g., 00_02_EE_6E_72_D3). If you get a “Permission denied” error when you try to cd to the bts directory, switch to root privileges by running sudo su. BTScanner creates all directories and logging data such that only the root user can access them. In each device directory, BTScanner will create two files: timestamps and info. The timestamps file contains a record of each time BTScanner received a response from the device. This record can be useful in tracking down a moving Bluetooth device by observing the presence (or lack of presence) of a device over time. The info file contains detailed information about the device, including the BD_ ADDR, device manufacturer, vendor name associated with the BD_ADDR, organizationally unique identifier (OUI), MAC address prefix, and a detailed list of all the services on the device. Despite some bugs in BTScanner (see the previous sidebar), the logging and analysis capabilities are very useful for identifying discoverable devices. Unfortunately, BTScanner is no longer in active development and is, therefore, unlikely to see any bug resolution in the near future. Windows Mobile Discovery with btCrawler Popularity: 3 Simplicity: 7 Impact: 2 Risk Rating: 4 The btCrawler tool uses the integrated Bluetooth interface in a Windows Mobile device for Bluetooth discovery. Installation is as simple as downloading and launching the installer in the associated Microsoft CAB file, available at progDownload/btCrawler-Download-8353.html with Pocket Internet Explorer. After launching btCrawler, tap the Scan button to start the Bluetooth discovery process. After approximately 12 seconds, btCrawler will display a list of all the discoverable devices in the area, as shown next. The first column (Major Class) allows you to tap on a selected device. Once a device is selected, you can select SDP to open a new window that will enumerate all the remote services on the target device. 289 Chapter 8: Bluetooth Scanning and Reconnaissance btCrawler will only scan for a short duration before stopping. Each time you tap the Scan button, btCrawler deletes the list of previously observed devices before starting a new scan. In addition to discovery, btCrawler also includes limited attack support with the ability to transfer files to a remote device and the ability to send a vCard to a designated target. We’ll talk more about these attacks later in this chapter. btCrawler uses the integrated Bluetooth adapter in the Windows Mobile device, which will most likely be a Class 2 Bluetooth interface. As a result, btCrawler is only able to identify Bluetooth devices within a relatively short range of approximately 10 meters. What About the iPhone? Other tools are available for Bluetooth device discovery, but they aren’t recommended for practical use due to the relative complexity of making them work—or their general lack of features. For example, iPhones that have been jailbroken can use the Cydia application to install the SweetTooth discovery application. At the time of this writing, SweetTooth only displays the device name for discoverable Bluetooth devices, failing to include the BD_ADDR, device type, or any other pertinent information. Hopefully, development will continue on this tool to make additional detail accessible to the user. Sadly, Apple restricts developers from using the native iPhone Bluetooth function- ality for device discovery. As a result, iPhone users will not likely have any reasonable Bluetooth discovery tools outside of what’s available with jailbroken devices. 290 Hacking Exposed Wireless: Wireless Security Secrets & Solutions Mitigating Active Discovery Techniques Active discovery tools require that devices be in discoverable mode to be identified, making active discovery an opportunistic attack; the attacker targets devices that respond to inquiry requests because they are easy to identify. Mitigating this attack is straightforward: don’t leave your Bluetooth device in discoverable mode. While this advice is sound, its implementation is sometimes more difficult. For example, many devices require that one device be in discoverable mode for the initial pairing exchange, creating a window of opportunity for an attacker to exploit the network. Other devices are vulnerable to poor Bluetooth implementations that require the user to discover and select her target every time she wants to use the wireless medium, forcing her to keep her device in discoverable mode. Still other devices may place the system in discoverable mode for a short time after a specific event, such as device power-on. This vulnerability is characteristic of many Motorola phones, where at power-on they enter discoverable mode automatically for 60 seconds. If the circumstances are correct (such as when a plane lands and passengers all turn on their phones), an attacker can use active discovery to identify Bluetooth devices, even if only for a short time. Once an attacker has the BD_ADDR information, they are free to attack the device, even if the device leaves discoverable mode. Of all the tools that we’ve examined so far in this chapter, the target device must be in discoverable mode to be identified. Bluetooth security best practices dictate that end- users should make their devices nondiscoverable after the pairing exchange completes for an added level of security, evading active discovery tools. Now, let’s examine additional techniques you can use to identify Bluetooth devices configured in nondiscoverable mode. Passive Device Discovery The Bluetooth specification doesn’t require that two devices wishing to communicate go through the inquiry scan exchange. As a consequence, if you determine a device’s address through some outside technique (such as reading it in the documentation), the device has to treat your connection the same as if you had discovered it actively. This section covers passive techniques that can yield a device’s BD_ADDR. Visual Inspection Sometimes, simple visual inspection is all that is necessary to identify a Bluetooth device. Since Bluetooth is considered a valuable feature for many devices, its presence is often proudly featured and denoted on products with blue LEDs and the Bluetooth SIG logo. For example, consider the device shown here. This photograph was taken at the author’s local supermarket where all cash registers are outfitted with a handheld barcode scanner used for ringing in larger items. The use of the Bluetooth logo clearly identifies that the device uses Bluetooth technology for communication. 291 Chapter 8: Bluetooth Scanning and Reconnaissance Casual scanning of the area near the cash registers revealed that the devices were all configured in nondiscoverable mode. Upon closer inspection of the scanner base, however, you can see the device displays a barcode with its BD_ADDR, as shown next. Using the first three bytes of the BD_ADDR information (00:0C:A7) and the IEEE OUI allocation list (, we identified the device manufacturer as Metro (Suzhou) Technologies Co., Ltd. Visiting the Metro Technologies website indicated that the child company, Metrologic, produces this Bluetooth barcode scanner known as the MS9535 VoyagerBT. Going to the Metrologic website led us to the PDF version of the user’s guide for this scanner, disclosing the default PIN information for the device. The disclosure of BD_ADDR information printed on the device is not an uncommon occurrence. Since two devices must share BD_ADDR information to complete the pairing exchange, the information has to be input in some fashion, either through the inquiry request/response process, manually, or through some other method. For simple devices that lack a LCD display and have few configurable options, manual input is not an option. Using active discovery would be possible, but differentiating two discoverable devices in the same area would be difficult (e.g., you wouldn’t know if you were paired with the correct device). 292 Hacking Exposed Wireless: Wireless Security Secrets & Solutions Such is the case for the CodeXML Bluetooth Modem, manufactured by Code Corporation. This Bluetooth device provides wireless connectivity between an optical scanner and a backend computer system. The data sheet for the product indicates that “security set-up is quick and easy, …simply plug the modem into your computer and start transmitting wireless data… and …transmit and receive Bluetooth signals up to 100 meters” ( The CodeXML Bluetooth Modem is actually an embedded device accepting scancode data over the Bluetooth interface and passing it to the host over a USB, PS/2, or serial interface, effectively emulating a keyboard to the host. The handheld optical scanner device scans a barcode printed on the device to initiate the pairing process, authenticating with a default PIN of 12345678. Once the pairing process is complete, the values that the optical scanner receives from barcodes are sent to the CodeXML device and passed through to the host PC as if it were entered directly at the keyboard. Code Corporation advocates the use of the CodeXML Bluetooth Modem and optical scanners in the government (citing the Department of Defense, law enforcement, and the Department of Motor Vehicles), healthcare, manufacturing, and reseller markets. In this author’s experience, the handheld scanners are common at technology vendor expositions, where a company representative scans the badge of attendees to collect contact information before handing out swag (pens, t-shirts, Snorty the Sourcefire pig squeeze toys, etc.). Due to a lack of input interfaces on the CodeXML Bluetooth Modem and the optical scanner, the two devices rely on barcode information being scanned and passed through to the CodeXML device over the Bluetooth Serial Port profile. For customers who do not have a CodeXML Bluetooth Modem available, Code Corporation makes instructions available on how to leverage a Bluetooth USB interface on a Windows XP system to accept the data from the scanner. In these instructions, Code Corporation walks the customer through the process of disabling all security associated with the Bluetooth Serial Port profile (, while also providing a web-based interface to generate a barcode that represents the BD_ADDR of the customer ’s Bluetooth interface used on the host (, a sample of which is shown here. A nefarious attendee who has established a malicious Bluetooth host (configured according to Code Corporation’s instruction sheet) within the 100-meter range of the optical scanner device could replace his attendee barcode with that of the BD_ADDR of the malicious host. Once scanned, the handheld scanner would continue to operate, but would send all the data collected to the attacker instead.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.