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

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

Tag Archives: fuzzing

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

A little bit of fuzz

Original by Boon Lee Fam (fam89)

A few weeks back I was on the search for a list of valid Linux commands to help with a weird fuzzing task I had. As  I couldn’t find anything that did the job, I ended up creating a few files with valid operating system commands for this purpose.

Not wanting them to disappear (as these things tend to do) I thought I’d share them here with you along with a few other files I created. Who know, they might come in useful for people in the lookout for these sort of things, or who come across weird fuzzing scenarios. It happens more often than you’d think 😉

These operating system command lists were gathered from openly available sources and converted to lowercase, 1 command per line, for ease of use with programs like Burp Suite. If you have any additions to these, please feel free to let me know.

In addition to these command lists I also put together a few other lists that might come in useful.

I’d like to thank Gareth Heyes for linking me to his JavaScript Functions list and paradoxengine, timb_machine for there help getting the Action list together. The WSDL list is an accumulation from 125 openly available .wsdl files found using the simple Google dork filetype:wsdl

* I’m currently working to get these included and maintained as part of the excellent FuzzDB project from Adam Muntner.