Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: Bluetooth

DEEPSEC: Intelligent Bluetooth fuzzing – Why bother?

Intelligent Bluetooth fuzzing – Why bother?

Tommi Mäkilä & Jukka Taimisto

Been testing Bluetooth since 2005 as part of the UPF (UnPlugFest)

UnPlugFest –> https://www.bluetooth.org/login/default.aspx?ReturnUrl=/events/upf/unplugfests.htm

Carkits testing bonanza 2011

  • 15 different carkits tested
  • Found problems in 13 of them
  • Some in-car kits required dealer servicing after testing
  • 10 crashes with L2CAP – No Pairing required
  • Tested HFP and A2DP profiles


  • Automated and efficient blackbox testing method to find software flaws
  • Large amounts of anomalous (unexpected, invalid) inputs are sent
  • If the software fails it indicates a software bug

Bluetooth Fuzzing

  • No baseband, HCI or LMP fuzzing (controller stack)
  • Model based fuzzing
  • About 35 different protocols/profiles
  • On average 10,000 test cases/profiles
  • No special hardware required

Effective Anomalies

Anomalies that worked: Length Field

  • Under and overflows in length fields are very efficient
  • Good/Old technique
  • Especially good when applied to TLV structures

Anomalies that worked: TLV

  • TLV structures are hard to parse
  • Anomalies in different parts of TLV structures yield good results
  • Multi-field anomalies

Anomalies that worked: Data structure fuzzing

  • Oldest trick in the book
  • Simple overflowing using AAAAA works wonders

Expected: AT+BRSF=47<CR>


Anomalies that worked: Data structure repeats

  • Repeating of valid data structures causes slow or no response from the device.
  • Likely an issue where the parser attempts to decode everything until resources are exhausted

Anomalies that worked: Flooding data

  • No fuzzing needed… simple sent a huge block of data (32K of data)
  • Some chipsets can’t handle flooded data
  • Requires hardware reset to recover
  • Possible a stack issue… likely to be an issue across many systems if this is the case

Common components

  • Many profiles use either AT commands (SPP) or OBEX
  • Different profiles may not share AT or OBEX parsers, instead implementing their own
  • Same anomalies, same device, different profiles == different results
  • Example: AT command anomaly does not work against HSP (Streaming Protocol), but crashes HFP (Hands Free Profile)

Intelligent Bluetooth Fuzzing

  • We could develop more intelligent anomalies
  • Multi-field anomalies
  • Instead of parsers, attack state machines
  • Multi-profile anomaly injection
  • Bluetooth low energy?

Fuzzing multi-fields means it’s harder to isolate the exact condition that caused the crash. Root cause analysis is more difficult.

Sequence anomalies

  • Rearrange or repeat messages within the sequence
  • More efficient against profiles with complex sequences
  • Combine with anomalised messages for additional fun


  • Use combination of profiles to open attack vector
  • Useful against client riles
    • SDP Client
    • AVRCP to trigger A2DP
    • HFP to trigger PBAP (PhoneBook Access Profile)

Why Fuzzing Works

You’re not supposed to do that!” –> surprisingly common response when an anomaly is explained.

Lack of negative testing and eduction

So What?” –> It’s only a $5 headset!

What if this attitude was taken when implementing medical devices. Where is the line drawn!

It’s not easy” –> Writing code is hard, robust code is harder

Combine this with ambiguous specifications and tight schedules, it is surprising that things even work

Bluetooth Security Measures

Pairing is the most common security method in place.
  • Legacy pairing (Bluetooth 2.0 and older)
    • Commonly a 4 digit pin
  • Simple Secure pairing (Bluetooth 2.1 and newer)
  • L2CAP connection to PSM 1 (SDP) rarely requires pairing

Evading pairing

  • Social Engineering
  • SSP downgraded to legacy pairing
    • Backwards compatibility with Bluetooth 2.0 or older
  • In SSP JustWork pairing does not require any authentication
    • For devices without input or display possibilities
  • Known PINS (0000, 1234)
  • Anomalies to L2CAP
  • Fuzz the device into not requiring pairing (seen on occasion)

Other Security measures

  • Non-discoverable devices
    • May still accept connections
  • Dedicated pairing mode
  • Use SDP query to enable services
    • Requires SDP server on “attacker”


  • Complex sequences needed for service activation
  • Increases the number of error in legitimate use
  • You need ti make sure all profiles use the same security measures

Hiding the problem

  • Focus has been on preventing unauthorised access
  • The underlying implementations are still insecure
  • Instead of developing more complex security measures, focus more on the robustness of the implementation.

Fault propagation

  • Anomalies can propagate to interconnected systems
  • Unprotected backends systems
  • Unauthenticated servers
  • Apply the same to carkits and in-car kits to spread to further systems

Links :

  • Codenomicon – Fuzzing Bluetooth Slides –> PDF
  • Intelligent Bluetooth fuzzing – Why bother? –> Overview

Bluetooth fun

Well I’m finally getting a chance to update my blog after a few weeks of Semi holiday. Saw some interesting things in London, just a pity I was too slow with the camera. I saw an error message on an advert screen that would have made Johnny Long proud. IP address and all….

As some people who read this blog are probably aware, I like to play about with Bluetooth when I’m on a trip. After all when you’re in a train of a bus, there’s not much else to do. I’ve been using the Bloover app from Trinite group for a while now, just for scanning the local area and looking at what devices are pumping out information. The application is a simple java install and even works on my ancient Nokia phone from before the dawn of Metasploit (or dawn of time if you prefer). All you need is support for J2ME on your phone and you’re laughing. After a couple of long(ish) train journeys to and from London, I had amassed quite a list of Bluetooth names (Some of which are Shown below). Knowing what a battery hog bluetooth can be, I really wonder about some peoples phone use. After all nobody in my cabin on the train was using a bluetooth headset, infact most where just shouting into their headsets doing the usual thing where they think everybody needs to know about their life. Anyway lets ignore that fact before people start to draw up analogies to people blogging 😉

Amongst the usual names like Nokia, SDH-900 and various other brand/model names, there was a distinct pattern emerging. A good percentage of people simply give their name as the Bluetooth broadcast ID, the rest say something about their character (I’m looking at your Thrustmeister). It’s all very entertaining, at least it gave my Girlfriend and I endless fun. However on the more serious side, the uses for this in a Social Engineering situation could be amusing. Sitting in a coffee shop snooping on Bluetooth ID’s until you can pinpoint who’s phone belongs to who. If you can find a Bluetooth Broadcast ID displaying a name, or a company name, then the follow-up conversation becomes so much easier. After all, nobody wants to admit that they’ve totally forgotten their first boyfriend/girlfriend back at high-school or the Boss from the Canadian office.

Tip of the day.. turn off your bluetooth when you’re not using it. End of story…