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

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

DEEPSEC: Intelligent Bluetooth fuzzing – Why bother?

1 Comment Posted by on November 17, 2011

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

Fuzzing

  • 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>

Testcase: AT+BRSF=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

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

Multi-Profile

  • 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”

Downsides

  • 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
Conference, Security , ,

One response to “DEEPSEC: Intelligent Bluetooth fuzzing – Why bother?”

  1. Pingback: First Press Coverage of DeepSec 2011 –