November 17, 2011
Posted by on
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
- 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
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
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
- 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.
- 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)
- Simple Secure pairing (Bluetooth 2.1 and newer)
- L2CAP connection to PSM 1 (SDP) rarely requires 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.
- 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
- Codenomicon – Fuzzing Bluetooth Slides –> PDF
- Intelligent Bluetooth fuzzing – Why bother? –> Overview
September 6, 2010
Posted by on
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’m currently working to get these included and maintained as part of the excellent FuzzDB project from Adam Muntner.