SANS Penetration Testing

The Bluetooth Dilemma

[Editor's Note: Did you see the security bulletin from Visa about the new credit card skimming attacks that rely on Bluetooth? Josh Wright did. In this excellent article, Josh analyzes Visa's recommendations that organizations begin scanning for unidentified Bluetooth signals and pairings in retail environments. If you, as a penetration tester, ethical hacker, or incident handler, were told to implement this Visa recommendation in your environment, would you know where to start? Josh covers the available tools, their significant limitations, and more. Nifty stuff! -Ed.]

The Bluetooth Dilemma

By Josh Wright

Since the introduction of Bluetooth technology, it has been a mainstay protocol, present on nearly all mobile phones on the market as well being commonly found on headsets, wireless keyboards, video game consoles, and possibly some other devices you may not have given much thought to: payment card skimmers.

A few weeks ago, Visa published their regular Visa Bulletin newsletter for merchants, describing a trend in which PIN entry devices (PEDs) are being stolen from retail locations. Video surveillance information indicates that PEDs are stolen during business hours and replaced with modified versions designed to skim payment card number and PIN information in a matter of seconds. An integral component of these modified PEDs is a Bluetooth radio implanted by the criminal.

Visa is a little late in reporting this type of activity to merchants. In 2009, several victims reported fraudulent ATM withdrawals from their bank accounts from locations in Los Angeles. Subsequent analysis by the authorities indicated that the PIN and payment card information was compromised at a series of 7-Eleven stores in Utah. Upon dismantling the gas pumps in these stores, authorities identified the presence of PIN and mag-stripe skimmers with an added Bluetooth radio component, shown below.



The Problem with Skimming

Criminals have a critical problem with payment card skimming systems: they need to collect the data after their modified in-store PED skimmed it. Anytime a criminal returns to the scene of a prior PED theft and replacement, they risk the chance of being caught. A reasonably low-tech solution is to suck the collected payment card and PIN information over a wireless device, preventing them from having to touch or go close to the compromised PED.

Selecting the wireless protocol to use for obtaining this information is an interesting analysis of what is attractive to an adversary. I imagine their requirements are similar to this:

  • Must be cheap
  • Must be small to fit inside cramped PED cases
  • Must have sufficient range to collect the data without going too near the device
  • Must be difficult to detect

Certainly, bad guys could leverage WiFi for the purpose of delivering skimmed data, though it is probably not the cheapest option. WiFi fails, however, in the last requirement in that there are a large number of tools available today to detect unauthorized WiFi activity.

An alternative option is to leverage cellular devices, and while this would provide tremendous range for delivering data and would be difficult to detect and differentiate from legitimate activity through wireless analysis techniques, it would be expensive to maintain any kind of a service contract and will likely be too large if extracted from a typical cell phone circuit board.

Bluetooth, however, is very cheap and can be purchased as a standalone CF card. With Bluetooth Class 1 devices, a bad guy would get 100M or more range when equipped with high-gain 2.4 GHz antennas. The biggest win, in my opinion, is that Bluetooth is difficult to detect and characterize.

In Visa's bulletin, excerpted below, they present several mitigation strategies for dealing with stolen and manipulated PEDs, including periodic scanning for unidentified Bluetooth activity. Based on this bulletin, one could easily envision a penetration tester, vulnerability assessor, or incident handler to be tasked with finding unauthorized Bluetooth devices in a retail or other environment. This is easy to ask for but difficult to implement, however, due to the nature of Bluetooth and Frequency Hopping Spread Spectrum (FHSS).

What You Need To Know About Bluetooth in 1 Minute

The most common method for Bluetooth to communicate is by rapidly channel hopping through a series of channels that is different for each Bluetooth network. In Bluetooth, a master device (which initiates the Bluetooth connection) uses its Bluetooth Device Address (BDADDR) to select a frequency hopping pattern that will be shared by all devices participating in the Bluetooth network. This is unlike WiFi devices, shown in the spectral graph below, that stay on a single channel for the majority of their operation.

Since devices must know the BDADDR ahead-of-time, Bluetooth includes functionality where a device may be marked as discoverable. When a device is discoverable, it will periodically scan a smaller set of channels and listen for inquiry request frames. When an inquiry request is observed, the device responds with an inquiry response message that discloses its BDADDR.

The Bluetooth Dilemma

Visa is recommending that merchants start to periodically scan for Bluetooth devices. If this analysis was designed to look for discoverable Bluetooth devices, then several tools are available for Windows and Linux systems such as BlueScanner (shown below and available at and BTScanner ( These tools can help analysts find discoverable devices, but it's unlikely that they will discover credit card skimming Bluetooth devices.

When a device is configured as non-discoverable, it is very difficult to identify the full BDADDR, since the device does not openly listen for or respond to inquiry request messages. This makes Bluetooth a very attractive wireless technology for credit card skimmers, since, without the BDADDR, it is very difficult to capture the activity in a Bluetooth network. It's likely that credit card skimming devices will be configured in non-discoverable mode if the bad guys want to evade detection.

With Cisco's acquisition of wireless firm Cognio, they obtained the Wireless Spectrum Expert product, now integrated into Cisco APs and rebranded as Cisco Clean Air Technology. Unlike fixed radio systems that are designed to handle only a specific wireless protocol, the Cognio technology was designed to capture raw radio signals, applying multiple techniques to identify the nature of the wireless activity in the area. As a result, Cisco users can identify very limited information about Bluetooth devices in the area, even when they are configured in non-discoverable mode as shown below.

In this example, the Cisco Spectrum Expert device has identified a Bluetooth device whose BDADDR ends in 9E:8B:33 (this address is actually a Bluetooth device searching for other discoverable devices in the area). Unfortunately, this is all that Cisco can tell you about Bluetooth devices. While the Cognio technology can identify and characterize the nature of wireless devices, it does not include the ability to frequency hop along with a target device and cannot tell you, for example, the class of device, or the services the device supports (such as file transfer or audio headset).

This brings us to the Bluetooth Dilemma. Simply stated, there is no solution for accurately detecting and characterizing non-discoverable Bluetooth devices in use. Visa can suggest merchants perform scanning, but there simply isn't a currently available viable solution that adequately addresses the problem, not in a mobile form and definitely not in a distributed enterprise-ready form.

Answers, Not Just Problems

Fortunately, with the support of the open source community and largely from the Herculean efforts of Mike Ossmann, a low-cost hardware device may be the answer to the Bluetooth Dilemma in the form of the Ubertooth, shown below.

The Ubertooth is commercially available from several sites in the US and UK including,, and for approximately $120. Although currently targeting hobbyists, developers, and enthusiasts, the Ubertooth is able to integrate with the Kismet wireless scanning platform to identify Bluetooth activity in the area and enumerate 3-4 bytes of the BDADDR passively. Being able to enumerate the 4th byte of the BDADDR is significant since it allows the analyst to then leverage the partial address to reach out and actively enumerate discovered devices to obtain information about the Bluetooth device including type, friendly name, class, and accessible services.

Today, however, this is still a very manual process, and not quite enterprise-ready. We need additional development and support in this area in order to have a viable solution for identifying malicious Bluetooth transmitters. Still, if your management insists that you start monitoring for unauthorized Bluetooth devices along the lines of the stated intensions of the Visa bulletin, you'd be wise to ask them to shell out some money for an Ubertooth device so you can begin experimenting. Also, make sure you explain to them the limitations of the current detection and identification technology identified in this article.

Josh's Wish List

While we are currently lacking the tools to detect non-discoverable Bluetooth devices, we are reasonably close to having tools to address problem. Here is a list of what I would like to see to help me both in Bluetooth penetration tests and in detecting Bluetooth PED hacks and other unauthorized devices:

Ubertooth Frequency Hopping Capture - The Ubertooth is capable of frequency hopping along with other devices in a piconet once it observes the lower 4 bytes of the BDADDR. With frequency hopping support, this would allow the Ubertooth to become a passive Bluetooth packet sniffer for only the price of the hardware. With passive capture abilities, we could gather more information about Bluetooth devices in an area, but it would likely be limited to in-use activity. If the PED skimmer is not currently active, there would be little activity to observe with which to characterize the device.

Integrated Ubertooth and Bluetooth Dongle - With the Ubertooth's ability to capture the lower 4 bytes of the BDADDR, a standard Bluetooth dongle could be used to actively enumerate identified Bluetooth devices. Although possibly a little unsightly, the combination of two USB devices would provide the needed information to quickly and accurately characterize devices in the area.

Bluetooth Device Fingerprinting Database - End-users will need more than "this is a phone" or "this is a keyboard" in the evaluation results. What would be more useful is to characterize a device by platform, function, and possible threat vector. For example, the Bluetooth chip, class, type, and services on PED skimmers may be common among devices but different than other approved Bluetooth devices, presenting an opportunity to develop a "Bluetooth IDS" platform. The Blueprint tool attempted to provide such functionality, though the technique used by this project for fingerprinting would require further analysis to determine its viability. A big part of such a system will be false-positive analysis, since consumers will walk in and out with Bluetooth devices on a constant basis that introduces no threat to the merchant.

Windows Support - I love Kismet, which runs on Linux, but for a Bluetooth identification and analysis system to be effective, we will need it to run on a Windows platform with a pleasant GUI.

Distributed Monitoring Support - Not initially, but for effective analysis we will need a distributed monitoring system that runs in a lightweight embedded platform that can be powered using Power Over Ethernet (POE) 802.3af or 802.3at. It's easy to envision a point in which merchants want the ability to deploy a single fixed-location monitoring sensor deployed near PEDs to constantly monitor for malicious Bluetooth devices, sending results back to a central server that can be evaluated by an analyst.

Wrapping Up

Bluetooth has, for quite some time now, been an interesting security problem. Initially, however, the Bluetooth security problem was that common uses of Bluetooth would leave users and organizations exposed to audio eavesdropping attacks, wireless keyboard keystroke sniffing attacks, buffer overflow exploits and more. With the notice from Visa and the 7-Eleven gas pump skimmer compromises, however, Bluetooth seems to be moving into yet another vertical: criminal enterprises.


-Josh Wright


Posted October 22, 2011 at 11:10 PM | Permalink | Reply


Great write-up ''" thanks for posting. Quick question: how do the bad guys communicate with the skimmer-connected Bluetooth device in the future to collect their data? Can they pair their two bluetooth devices with one another prior to deploying one with the skimmer? Or can they pair with the device when they return to the scene without discoverable mode as long as they already know the BDADDR? An alternate possibility is that the secondary device is placed into discoverable mode, and the skimmer-connected device is constantly sending inquiry request frames, although this seems unnecessarily "noisy", and could result in an exchange of data with an unauthorized device.
Very interesting topic; thanks again.

Posted October 26, 2011 at 6:57 PM | Permalink | Reply

Joshua Wright

DDR, this is a great question. Unfortunately, we really don't know. There hasn't been sufficient forensic analysis on these devices to determine exactly how criminals are using them.
It is possible to pair with the skimmer in advance, and then get close enough to reconnect to suck out the payment card data, making the connection process (and bad-guy exposure) minimal. Even in the pairing exchange, it isn't necessary to be in discoverable mode since you can key in the remote BDADDR manually to avoid having either device discoverable. If the bad guys are smart, they'll have configured their Bluetooth connection in advance to avoid any unnecessary visibility that could give them away.

Posted November 2, 2011 at 8:50 PM | Permalink | Reply


I cant recall ever seeing a "program too big to fit in memory" error
when using python. My guess is you probably got that error when
trying to convert the program to an EXE and that you were missing a
string terminator or other delimiter from the source. If you need
another example of it working you can find one in the post I did on
Pauldotcom here:

Posted February 6, 2015 at 4:41 PM | Permalink | Reply

Zoey Lopez

We have a issue with the post, where am i able to get in touch with the person responsible?

Post a Comment


* Indicates a required field.