So You Want to Track People with Ubertooth. . .

Dominic started a blog for Project Ubertooth recently, so I will publish most future Ubertooth related content over there. My first post is a FAQ for people wanting to use Ubertooth to track the movements of Bluetooth devices.

Bluetooth for Bad Guys

Criminals have been skimming debit and credit card information by tampering with point of sale terminals, PIN pads, gasoline pumps, and ATMs for quite a while now. The first time I heard of Bluetooth being used in such cases was from this SparkFun Electronics news blurb a couple years ago. Malicious hardware installed in a Canada retailer's PIN pad intercepted customer data and transmitted it via Bluetooth to the attacker's device, perhaps a laptop in a nearby parking lot. At the time it seemed like a clever use of the technology by a Canadian ne'er-do-well but probably not the start of a trend. I was wrong.

As Joshua Wright recently pointed out, Visa is informing merchants about similar crimes that took place around the same time in Utah. Skimmers have also been found in Florida and elsewhere. Just this week, customers of Lucky Supermarkets in California found out that a similar attack was the reason their bank accounts were recently drained. This isn't just one clever crook; this is a criminal industry at work.

The technical reasons that Bluetooth is an attractive technology for this application are nicely outlined in Joshua's article, but we wouldn't see so many actual attacks were it not for commercial availability of Bluetooth skimmers sold on the criminal underground. There is an industry producing hardware for crime just as there is an industry producing software for crime.

How can you protect yourself as a customer? The best advice I can think of is to consider the liability of payment methods. There is a reason I like to carry some cash. There is also a reason I strongly prefer to use a credit card over a bank debit card. With a credit card (in the US, at least), the financial institutions and merchants bear most of the burden of liability. As long as I check for unauthorized transactions before paying my bill every month, I don't have much to worry about. Once, many years ago, someone emptied my checking account. I figured out what had happened and managed to convince my bank that the bank's own misguided security practice had allowed it to happen, but guess who bore the burden of a zero balance until that was resolved?

How can you protect yourself if you are a retailer or financial institution? This is a much more difficult problem. For starters, you should read Joshua Wright's article and the Visa bulletin. Josh has some nice things to say about my Project Ubertooth, but he also has some criticisms, mostly pointing out features yet to be developed. The first item on his wish list is frequency hopping, something I am working on now. He also points out the need to improve Bluetooth device fingerprinting, an area of research that has been advanced in recent years primarily by JP Dunning.

When I read about real life attacks on retailers and customers, sometimes I imagine how I could use technology to catch the crooks. Frankly, it would be hard, and it would be especially hard to deploy tools that would allow more investigators to do the same. Bad guys are using Bluetooth (and potentially other wireless technologies). We need Bluetooth tools for the good guys too.

I guess, if there is a lesson to be learned from all this, it is that hardware security matters. If an attacker can get in between a user and a system, the security of the system will fail in almost any case. Advocates of the Bring Your Pwn Device (BYOD) trend might want to pay attention. (That was an honest typo, but I decided to keep it!)

comments on SP 800-121 Rev 1 draft

The following is an email I sent to NIST in response to a request for comments on the draft Guide to Bluetooth Security (NIST Special Publication 800-121 Rev. 1).

Thank you for your efforts to produce and update SP 800-121! Although I have some criticisms, your document is important and unique.

My principal concern about the guide is that the recommended practices are too weak to support the safe use of Bluetooth. Looking at the SP 800-153 draft (Guidelines for Securing Wireless Local Area Networks), I see several recommendations listed in the Executive Summary that would be just as applicable to Bluetooth:

"When planning WLAN security, consider the security not only of the WLAN itself, but also how it may affect the security of other networks."

"Have policies that clearly state which forms of dual connections are permitted or prohibited for WLAN client devices, and enforce these policies through the appropriate security controls."

"Ensure that the organization's WLAN client devices and APs have configurations at all times that are compliant with the organization's WLAN policies."

"Perform both attack monitoring and vulnerability monitoring to support WLAN security."

"Conduct regular periodic technical security assessments for the organization's WLANs."

My second concern is that it is unclear how to implement many of the recommendations. Unfortunately this is more a problem with Bluetooth itself and the available tools than with your document. Along with others in the information security community, I am working to develop Project Ubertooth into a tool that will bridge the gap as much as possible, but more needs to be done.

Third, I have some specific comments and criticisms:

It is incorrect to say that Frequency Hopping Spread Spectrum (FHSS) provides even "a limited level of transmission security." Other features of Bluetooth provide security benefits. FHSS provides interference avoidance.

It is easy to overstate the security benefits of power control. I suggest eliminating discussion of transmit power from the document.

Good job on citing some important work! (Spill/Bittau, Wool/Shaked)

Where you state, "If that device remained discoverable, its location could be tracked by an adversary", it should be corrected to state that discoverability is not required. See Spill/Bittau and this blog post:

http://ossmann.blogspot.com/2011/07/discoverability-is-not-mitigating.html

Table 4-1 is an important contribution that I will recommend to many people.

Section 4.2 "Bluetooth Threats" seems weak. The list of threats is disjointed, inconsistent, and in places dated.

Thank you again for your contribution. I hope you find some of these comments helpful.

Sincerely,

Michael Ossmann
Great Scott Gadgets
mike@ossmann.com
http://greatscottgadgets.com/

Discoverability is Not a Mitigating Factor

Four years after BlueSniff: Eve Meets Alice and Bluetooth by Dominic Spill and Andrea Bittau, people are still saying that Bluetooth vulnerabilities can be mitigated by turning off discoverability. If there is one thing that should have been learned from all of the Bluetooth security research done over the last few years, it is that a non-discoverable device is no safer than a discoverable one, but perhaps this message has been buried too deeply in technical presentations. Let me try to make this point clearer.

A discoverable Bluetooth device is one that is willing to respond to an inquiry, a single packet transmitted by any device looking for others. When you tell a device to "find new Bluetooth devices" it transmits a large number of inquiry packets and waits for responses. A discoverable device's inquiry response contains information including the device's address (BD_ADDR). This address can then be used by the inquirer to initiate a connection between the two devices.

Since most Bluetooth vulnerabilities can only be exploited once a connection is established, people used to recommend turning off discoverability. The reasoning was that, without a way to learn the target's address, an attacker would be unable to connect to the target and exploit any vulnerability. This idea that it is possible to keep a Bluetooth device address secret is completely wrong.

Turning off discoverability is like hiding the SSID of an 802.11 network. It prevents people from casually or accidentally connecting to your Bluetooth device. It might be worth doing for this reason alone, but I no longer recommend it as a security practice. Turning off discoverability does nothing to thwart skilled attackers. Worse, it creates a false sense of security and makes it harder for the good guys to notice that Bluetooth devices are in use.

A BD_ADDR is a 48 bit number (it's a MAC address) that is unique to a particular Bluetooth device. It consists of three sections, the 16 bit Non-Significant Address Part (NAP), the 8 bit Upper Address Part (UAP), and the 24 bit Lower Address Part (LAP). In order to connect to a target, an attacker needs only the UAP and LAP.

LAP sniffing is easy. Every Bluetooth packet contains the LAP in cleartext. Spill and Bittau showed how to sniff LAPs with a USRP for about $1000. Now it can be done with an Ubertooth One for about a tenth of that price. It can even be done using Travis Goodspeed's method for promiscuous sniffing with lower cost platforms. LAP sniffing has always been easy, but now the tools and methods are more well known.

The UAP is only slightly more difficult for an attacker to learn. Project Ubertooth and gr-bluetooth include software that implements automatic UAP determination based on passive observation of just a few packets. The function is integrated into the Ubertooth Kismet plugin. Even without this method, it isn't hard to figure out the 8 bit UAP. In Hacking Exposed Wireless, Second Edition, Joshua Wright showed how to determine the UAP with a simple brute force attack.

Turning off discoverable mode doesn't make your Bluetooth device any more secure. If your security model depends on secrecy of the BD_ADDR, you are doing it wrong.

And, by the way, frequency hopping doesn't help you either.

Project Ubertooth: Building a Better Bluetooth Adapter

Video of my presentation, Project Ubertooth: Building a Better Bluetooth Adapter, at ShmooCon 2011 is now online. You can download the entire video in high quality from shmoocon.org or watch it in your web browser. In the presentation, I demonstrated Ubertooth One, the world's first open source, widely available, low cost Bluetooth test tool, and I described my two year design journey starting as an electronics novice. This was one of the most fun talks I've ever given, and I want to thank ShmooCon for making it happen and everyone who attended for participating. I'm making the slides available, but, as is typical of my presentation slides, they really don't stand alone.

Shortly before the presentation, I was interviewed by Hak5. The interview covered a lot of ground and included quite a bit of discussion beyond the content of the presentation.

At ShmooCon I announced the start of a pledge period on Kickstarter to fund an initial production run of Ubertooth One boards, and the pledge goal was met in just four days! There is still time remaining in the pledge period for anyone who would like a board. Thank you to everyone who has pledged support!

first Bluetooth Low Energy packets

A package arrived today containing my first Bluetooth Low Energy equipment. Bluetooth Low Energy is a new wireless technology within the Bluetooth specification suite. It provides capabilities similar to Basic Rate Bluetooth, which has been around for ten years, but consumes less power while doing so. Consumer Bluetooth Low Energy products likely won't hit the market for a few months, but engineering development tools have recently become available.

This kit from Texas instruments contains a two small CC2540 development boards, one in the form of a keyfob and the other in a USB dongle form factor. For now I'm not interested in developing firmware for the CC2540. Frankly I'm annoyed that TI has chosen not to document the internal radio properly. Despite its limitations, however, this kit provides a quick and easy way to generate Bluetooth Low Energy wireless packets over the air, and I'm using it (so far just the keyfob) to help me develop Low Energy sniffing capability on the Ubertooth platform.

It only took a few minutes to tweak the Ubertooth code such that it would demodulate Bluetooth Low Energy packets properly, but I don't have much in the way of automated packet detection or decoding. Using a fairly crude method, I've searched through the demodulated bits to find the advertising packets transmitted by the keyfob. These are packets transmitted on one of only three advertising channels in an effort to locate another device to communicate with.

One of the key differences between Basic Rate and Low Energy is that Low Energy devices are able to locate each other and initiate communications using this advertising method much faster than Basic Rate devices ever could. Basic Rate devices waste a lot of power keeping connections alive; Low Energy devices will just tear down connections entirely and go to sleep knowing that they can wake up and find each other again very quickly. One of the reasons the method is fast is that advertising is only done on three channels, and that makes it easier for a passive observer to capture the process.

I've also captured the packets using a USRP. Glancing at the waveform and spectrogram, it is difficult to distinguish this packet from Basic Rate Bluetooth. I haven't written any GNU Radio code to demodulate the raw waveform, but I am replaying the recorded file through the USRP as a simple way to produce a repeatable test vector.

Ubertooth One on Kickstarter

At ShmooCon over the weekend, I gave the first public demonstration of Ubertooth One, a smaller and more powerful Ubertooth hardware platform. I also announced the beginning of a pledge period on Kickstarter that allows anyone to take part in the first production run of commercially available Ubertooth Ones. If you would like an Ubertooth One of your own, I encourage you to consider building one or making a pledge on Kickstarter. Thank you for your support and for helping to spread the word!

Ubertooth video and news

Video of Ubertooth Zero, a preview, my talk at ToorCon 12, is now online (part 1, part 2). This includes the first public demonstration of Bluetooth sniffing with the platform. Since ToorCon, I've been working hard on Ubertooth One hardware and software. I've had to work through some production delays and errors with Ubertooth One circuit boards, but I have a good feeling about the next revision which is in production now.

I am excited to announce that my talk, Project Ubertooth: Building a Better Bluetooth Adapter has been accepted for ShmooCon 2011. This will be a longer presentation telling the complete story of the development of Project Ubertooth and demonstrating new capabilities of the platform (hopefully with working Ubertooth One prototypes). ToorCon was a preview, but ShmooCon will be the big debut.

I posted a new file release of the Ubertooth project repository tonight. This includes the new bluetooth_rxtx firmware that is starting to resemble my vision for the USB interface. The host code doesn't do much more than the ToorCon demo at this point, but quite a bit has been done to enable future enhancements.

Bluetooth Keyboards: who owns your keystrokes?

I gave a talk at ShmooCon 2010 on the security of Bluetooth keyboards and mice. After a restoration of the ShmooCon archive, the full video is once again available. I have also published the slides and such.

Most of my previous Bluetooth work had been done using software radio techniques requiring somewhat costly hardware. For this talk I focused on what is possible for both attack and defense using low-cost off-the-shelf Bluetooth equipment. It turned out that quite a lot of interesting things were possible that had not been demonstrated before. Even so, many essential capabilities such as passive monitoring remained out of reach without more expensive hardware which is why I've since turned my attention to Project Ubertooth.

Ubertooth: first release

Tonight I uploaded the first release of Project Ubertooth, an open source wireless development platform that can be used for Bluetooth testing and research. This is a very preliminary release, but it includes the complete hardware design for Ubertooth Zero, firmware source code, and the host code needed to perform rudimentary Bluetooth sniffing as I demonstrated at ToorCon 12. Although you can download a project archive, I recommend using the Subversion repository so that you can easily keep up to date with the project as it develops.

The documentation is still a bit thin, but there are README files scattered about the project directories. The host code can be compiled with gcc on Linux. The firmware also can be compiled with a gcc toolchain (I have found the CodeSourcery package to be helpful) and can be flashed onto a board with lpc21isp. I've been using a slightly modified SparkFun FTDI Basic Breakout for this, but there are several serial programming devices that will work with lpc21isp.

Also in the repository is an early hardware design for Ubertooth One, the next generation board that I hope to have ready within a couple months. This is a more challenging design that will probably require a few revisions, so keep your expectations low if you try to build one based on the current layout.

Ubertooth Zero, a preview

Last weekend at ToorCon 12 I unveiled Project Ubertooth, something I've been working on for more than a year. The goal of the project is to produce a low cost 2.4 GHz wireless development platform suitable for Bluetooth sniffing (among other things). If you are familiar with previous work on Bluetooth monitoring, then you know that good tools are expensive. Commercial equipment costs $10,000 or more, and even the open source solution requires a hardware investment of at least $1000.

In my talk, Ubertooth Zero, a preview, I demonstrated Bluetooth sniffing for the first time with Ubertooth Zero, my first prototype hardware model. The platform is based on the Texas Instruments CC2400 wireless transceiver paired with NXP's LPC1758, an ARM microcontroller with USB. You can build an Ubertooth Zero for less than $50 in parts. The hardware design and host code are published in the svn repository at http://ubertooth.sourceforge.net/, and firmware will follow as soon as possible (probably a couple weeks). Everything is open source.

Over the coming weeks I'll be working on the next model, Ubertooth One, which I hope to have available in early 2011. It will be compatible with the Ubertooth Zero software but will have an improved RF front end, comparable to a Class 1 Bluetooth device. I hope to produce Ubertooth One commercially, making it available to those who don't want to solder 0402s, but rest assured that the product will remain fully open source. I'm also working on firmware, host software, and documentation so that the platform will be easier to build and use.

I would love to hear from you if you decide to build an Ubertooth Zero. Keep in mind that this is a preview release with much work still undone. So far I've built three working boards, one of which fetched $275 in Sunday night's ToorCon Foundation auction, supporting technology education in developing countries. I have three more that I hope to get working soon, and then I'll start work on Ubertooth One.

So far I have implemented only single channel Bluetooth monitoring. The device sits on a single channel and receives a small subset of packets from all Bluetooth devices in range (the target devices use frequency hopping, so they only transmit a small percentage of their packets on that particular channel). This is sufficient to provide a good survey of Bluetooth activity. With some work on software in the future, the platform should be capable of hopping along with a target, receiving every packet on that piconet. Once that is working, it should be possible to use the Ubertooth platform for raw frame injection, an important capability that has been out of reach of wireless security researchers since Bluetooth's introduction. The platform could also be used for several non-Bluetooth functions such as spectrum monitoring or 802.11 FHSS

ToorCon was a blast, as always. Thanks to everyone who attended the Software Defined Radio Workshop, Real Men Carry Pink Pagers, and the Ubertooth talk. Thanks to Travis for making our talk so much fun. Thanks to Dominic for making the trip from London. Thanks to George, Tim, and David for putting on a great con and making me feel so welcome. Thanks to all the friends, both old and new. Thanks(?) to Nick et al. for embarrassing the hell out of me. Thanks to Laen for running the DorkbotPDX PCB service. Most of all, thanks to Jared Boone who couldn't be at ToorCon but who has supported my effort to develop Project Ubertooth more than anyone.

ShmooCon live!

I'm giving a talk on Bluetooth keyboard security at ShmooCon this year. Live video of the talk will be provided. My talk will be at 3:00 PM EST on Saturday, February 6th in the Break It! track.

building an all-channel Bluetooth monitor

video (179M) of my presentation with Dominic Spill at ShmooCon 2009 has been posted.

toorcamp awaits

Next week Dominic and I will reprise our ShmooCon Bluetooth talk at Toorcamp, North America's first hacker camp (which happens to be taking place at a defunct Titan-1 missile silo). The nice folks from DorkbotPDX have allowed us to join their campsite. While we're there we also plan to run a software radio workshop. It is high time that more hackers learn how to use this technology.

thanks, ShmooCon

Dominic and I had a great time at ShmooCon. Our talk was fun and well attended. Video of the talk will be posted "soon." Slides (PDF, ODP, PPT) and code are up.

We met a lot of great people and had some interesting feedback and discussions of new ideas. We're still working on this stuff, so hopefully we'll have something even better to show off later this year.

see you at ShmooCon

Dominic Spill and I are presenting Building an All-Channel Bluetooth Monitor at ShmooCon this weekend. It should be fun!

narrowing the hop search

Dominic Spill has been kind enough to correspond with me about my recent work on reversing the Bluetooth hopping sequence. He pointed out some interesting ideas he had proposed last May. One essential idea I had overlooked is that 6 bits of clock can be recovered along with the partial address from (almost) any frame. These clock bits can be used to narrow the search space of possible clock values.

In my original analysis, I looked at the hopping algorithm and assumed that an observer is somehow able to accurately measure the intervals between frames captured on one or more channels. I also assumed that the observer has partial knowledge of the master's address, but I did not consider partial knowledge of the master's clock.

How can the observer measure intervals between frames? The method Dominic proposed (and I overlooked) is to decode the 6 bits of the master's clock from each frame. Differences from one frame to the next reveal information about the interval between frames. Unfortunately, the six bits of clock only describe 64 different time slot intervals, yet there is an average of 79 slots between two frames on a single channel. When observing a single channel, a difference of 47 might indicate an interval of 47 slots, but it could also represent an interval of 111 slots (47 + 64). A more direct approach would be to count the number of samples between observed frames. Perhaps the best method would be to combine direct measurement with confirmation by decoded clock values.

No matter how the intervals are determined, the 6 decoded clock bits can be used to narrow the search space. My first simulations included a search through 134217728 possible clock values. Taking advantage of the 6 known clock bits, it is possible to reduce the search space to 2097152 possible values. I ran a new set of simulations to find out how much this helps.

In order to have 95% chance of a unique match, we could observe all 79 channels for 3/8 of a second (30 channel seconds processed). Alternatively, we could observe a single channel for 3/5 of a second (3/5 channel seconds processed).

When narrowing the search space by the 6 known clock bits, the observation time required when observing all 79 channels changes very little, but the time required when observing a single channel changes considerably. This result strengthens support of my conclusion that the most efficient method to reverse the hopping sequence is to monitor a single channel.

reversing the Bluetooth hopping sequence

Monitoring Bluetooth is hard. A Bluetooth piconet (a small network of two or more Bluetooth devices) continually hops through 79 adjacent channels, each 1 MHz wide. The piconet uses one channel at a time, hopping to a new channel 1600 times each second according to a pseudo-random channel sequence based on semi-secret information.

In order to capture all the transmissions of a particular piconet, a receiver must predict and execute the piconet's hopping sequence. (An alternative approach is to capture all 79 channels simultaneously and then throw out the 78 that are unused at any particular time after identifying the channel that is active for a particular time slot. I'm considering this to be too expensive, but it can be done and will become less expensive over time.)

We can only predict the hopping sequence if we know two pieces of information. The first is a portion (the 28 lowest bits) of the piconet master device's numeric address (the "MAC address" or more properly "BD_ADDR"), and the second is the master's clock, a 28 bit integer value that increments 3200 times per second. If we know both the address and the clock at a particular time, then we can correctly predict the hopping sequence forever. We just have to use the hopping algorithm dictated by the Bluetooth specification.

In 2007, Spill and Bittau demonstrated that the necessary portion of the address can be derived from the contents of any single frame. [update: see Thierry Zoller's comment below.] It is easy to capture a frame by listening on a single channel and waiting for the piconet to hop through it. With 79 channels and 1600 hops per second, this doesn't take long. All that we are then missing is the clock.

One way to acquire the clock is to join the piconet. When we successfully join, the master shares its clock with us so that we can follow along from then on. In order to join, we need to know the entire address of the master, not just the lowest 28 bits. Since we already know part of the address, the remaining bits can be guessed fairly easily (see Josh Wright's BNAP BNAP project). Armed with the complete address, we can attempt to join the piconet. This works in a great many cases, even when you might think it shouldn't, but it is possible that we could encounter a master device that will not let us join. It is also possible that we would prefer to monitor passively and do not want to interfere with the piconet in any way.

There is a way to acquire the clock passively by observing another device joining the piconet. Unfortunately, this requires some combination of luck and patience. If we don't have an opportunity to observe a device joining the piconet, this technique doesn't help us.

It is possible to reliably determine the master's clock completely passively, and that is by reversing the hopping sequence. That is, instead of using the hopping algorithm in the forward direction (determining the sequence from the clock), we use it in reverse (determining the clock from the hopping sequence). The hopping sequence repeats every 134217728 steps (28 clock bits minus one bit because it only hops every other clock cycle) with each step calculated from the address and clock. You can think of it as a static sequence based on the address with the clock value indicating the current index or position within the sequence. Using the address, we can pre-calculate the entire sequence. If we then observe a small number of hops taken by the target piconet, we can search through the complete sequence to find the index that matches the observed hops. This index is the clock.

At first, I thought this would be a great application for a high-bandwidth (79 MHz) software radio device. We could capture all 79 channels for a fraction of a second, do a bunch of number crunching to identify target frames and reveal a short segment of the hopping sequence, and then search through the complete sequence to find the clock. Even if we can't decode all 79 channels simultaneously in real time, we can probably do real time decoding of one channel at a time after (slowly) reversing the hopping sequence. Assuming that the pseudo-random hopping sequence is reasonably random, we would only need to observe a few hops in order to have a high probability of locating a unique match within the complete sequence; five hops ought to be enough in most cases.

Unfortunately, the pseudo-random hopping sequence is a long way from being reasonably random. The algorithm does a good job of spreading nearby time slots across a wide range of channels, but it does so with a great deal of repetition in the long run. If we capture all 79 channels for five hops, our chance of finding a unique match in the complete sequence is almost nil. Even after observing fifty consecutive hops we would have less than a 50% chance of success.

To illustrate this, I simulated the results for a large number of cases (with random address and random clock). This graph shows how often an observed sequence segment turned out to be unique for various observation periods. One set of simulations was done assuming a single observed channel, one with eight adjacent channels (randomly selected), and one with all 79 channels. When observing fewer than 79 channels, we miss many of the hops, but we are able to capture a frame each time the piconet hops through one of the observed channels.

It turns out that, in order to have a 95% chance of getting a unique match while observing all 79 channels, we have to capture not five hops, but about 650! This requires an observation period of about four tenths of a second and a great deal of computation. Multiplying the four tenths of a second by the number of channels observed (79), the result is about 32 channel seconds processed. At the other end of the scale, if we only observe a single channel, it takes about 2000 total hops (out of which only about 25 will be captured) to get to a 95% chance of a unique match. It takes almost a second longer of observation, but the number of channel seconds processed is only 1.25.

Adding channels helps quite a bit less than I expected. Regardless of the number of channels observed, the important thing is to capture frames that span a long enough period of time. Since the observation of more channels involves significantly more computation and more expensive hardware, it looks like the best way to reverse the hopping sequence is to listen to a single channel until a unique match is found.

Here is the code I used for the simulations. It includes a fast (I think) implementation of the hopping algorithm. Please let me know if you find any bugs! I'd love to hear from you if you find this interesting or useful.