Bluetooth Defense Kit

1. Bluetooth Defense Kit Bruce Potter …with help from Will Davis August, 2006

2. Don’t Believe Anything I Say • "Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything simply because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations. But after observation and analysis, when you find that anything agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it.” - Buddha • By Day, Senior Associate for Booz Allen Hamilton • By Night, Founder of The Shmoo Group and restorer of hopeless Swedish cars

3. Cut to the Chase • The most effective way to prevent Bluetooth attacks: • Turn off discoverable mode • We have no code to release today • Tried to implement BT Defense capability with no reverse engineering, non-device specific, and no vendor assistance… turned out to be very difficult • Damn near every Bluetooth vulnerability to date is an implementation error, not a break in the protocol • The protocol is complicated and hard to implement

4. Anecdotal: IP Stack Versus BT Stack • The BT stack is a complicated animal with MUCH less prior art than Ethernet/IP (going on 30 years) • Wanted to make my own BT stack diagram for this talk, I turned to some books and images.google.com • Apparently there are several hundred different Bluetooths based on the results searching for “BT Stack”

5. IP Stack • http://docs.sun.com/source/806-4075/images/ipov.fig88.epsi.gif

6. IP Stack • http://www.industrialethernetu.com/images/TCIP.gif

7. IP Stack • http://en.wikipedia.org/wiki/Internet_protocol_suite

8. Bluetooth Stack • http://www.htwm.de/~lec/twiki/pub/Public/BluetoothStack/protocol_stack.jpg

9. Bluetooth Stack • http://www.palowireless.com/bluearticles/images/stack.jpeg

10. Bluetooth Stack? • http://www.fh-bochum.de/fb3/sr-lab/uploads/RTEmagicC_bt-stack.gif.gif

11. Bluetooth Crash Course • 2.4 GHz, Frequency Hopping, Personal Area Network Technology • NOT WiFi! • Pairing - Mechanism for establishing long term trust between two BT devices • RFCOMM - Wireless serial port emulation (basically)

12. Bluetooth Crash Course • AT Commands - You remember these, right? Used to control some devices across an RFCOMM connection • Discoverable mode - When a device wants to be found, it will respond to other devices sending inquires • Service Discovery - A bit like port scanning, but the remote end doesn’t try to hide anything (Service Discovery Protocol, SDP)

13. State of the Union • Current version of Bluetooth Core Spec is 2.0 • Enhanced Data Rate (EDR) now allows for up to 3Mb/s… with basically the same power consumption • Security is largely unchanged from 1.1 spec • As of Nov 2005, 9.5 Million BT radios were being shipped each week • At that rate, that’s one radio for every 8 people on the planet each year • 9.5 million was up from 4.75 million just 4 months prior • Makes WiFi look pretty wimpy from a market penetration (closest guess I can make is 200 million WiFi chips/year, about 40% of the # of BT chips • Profiles govern how like devices talk to each other • In the past, a confusing experience… now we have icons to clear things up

14. Common Deployment Scenarios • Unlike WiFi, Bluetooth has generally stayed where it was supposed to • Mobility - Cell phones and ear buds, car hands free kits, network access • Every state that passes “no handheld cell use” laws impacts BT sales positively • Cable replacement - mouse, keyboard, camera • New uses - printers, mp3 players, etc… • While there is a network access profile, very few products to use it (ie: T-Mobile didn’t ditch WiFi hotspots in favor of Bluetooth Hotspots) • Performance can be… well, just horrible

15. BT Stack Vendors WIDCOMM (common with first wave of radios) Toshiba Microsoft (going to be REAL common soon) CSR Extended Systems Open Interface Bluez (Open Source) BT Chip Manufactures CSR Broadcom TI Infineon The Industry Players (a subset)

16. In order to defend, we must first understand the threats “Probe him and learn where his strength is abundant and where deficient” - Sun Tzu

17. Contemporary Bluetooth Attacks and Vulnerabilities • Trifinite.org has been leading the charge of publicly disclosed Bluetooth attacks • Others such as @stake and TSG have tackled some BT security issues as well • Most of what has been really damaging have been poor implementations • Rush to market leads to poor security • Super complicated protocol stack leads to poor security • Lack of security training for developers leads to poor security • Trifinite.org has lots of attack tools • Bluediving (bluediving.sourceforge.net) has Linux based impls of most of their tools • I’ll let Major do demos of his tools… he’s better at it than I

18. The Real Risk? • Shhhh… don’t tell anyone, but there hasn’t been a huge impact on global commerce or enterprise security due to wireless insecurity (WiFi or Bluetooth) • Hell, sales of the Sidekick went up after Paris’ Sidekick got 0wn3d • Does that excuse us from dealing with this problem? • No • Is Bluetooth security still an issue for those worried about targeted attacks? • Yes • Should we temper our response to ensure we stay within the bounds of reality? • Absolutely

19. “Why so Little Interest in Bluetooth Security?” • Honestly, we haven’t yet solved the discovery problem • WiFi device discovery is what blew open the WiFi Security world • When Shipley gave his talk at DefCon 9, the community was at a tipping point (to use a buzz word) • Free/open software and about $300 worth of gear allowed us to find every 802.11 device within a 1/4 mile radios • To have the same kind of success with BT, you have to spend about $10k • $10k is a lot of disposable income to kick around • Without finding the device, you can’t attack it • Not sexy enough… yet

20. Breakdown of the Current Attacks and Vulnerabilities

21. Stupid Defaults • Hard configured PINs - Only an issue at pairing time, but allows for attacks like Car Whisperer • For the BT virgins in the audience, the PIN is _only_ used at pairing time, not for every comms initiation • No authentication - duh! Even for things like automatic vCard acceptance (Sony) this is sketchy at best. • Profiles turned on by default - This is the same as keeping unneeded network services from running • If you don’t need it, don’t run it (don’t expose it) • A quick demo of service discovery of audience equipment

22. More Stupid Defaults • Poor per-profile default - Each profile is like an application… it can have bad defaults • Ie: I had a Belkin BT CF adapter that had the filesharing profile defaulted to world writeable and shared the entire filesystems • Discoverable by default - Why make it that much easier for an attacker? • Anyone been attacked in non-discoverable mode by an unknown device? • Also, discoverable mode sucks down battery faster • Audience demo

23. Shedding Some Light on Discovery • Seriously… the best defense is keeping discoverable mode off

24. Link-Level Attacks • Resetting the link key - In Shaked and Wool’s Paper (http://www.eng.tau.ac.il/~yash/Bluetooth/) they describe a way to force a device to lose it’s link key and try and repair • Basically, fake the BDADDR and repeatedly fail to bring up a secure channel, and the device will assume you “lost” the link key • If a device has a default PIN, you can then automatically set up a trust relationship • Cleartext data - Just like on the web, sometimes people forget to encrypt what they should encrypt • Usually need a protocol analyzer to make use of this

25. Location Tracking • Location Based - It’s RF.. You can track people. Not much you can do about it • http://braces.shmoo.com - We tracked attendees while they were at BlackHat USA 2004 • Had about 64 individuals we tracked for 2 days. Only a few hundred lines of code plus 4 laptops… pretty cheap • For some, location tracking is a plus • Aalborg Zoo is using “Bluetags” to track kids… Legoland using something similar

26. Human Interface Issues • Lack of feedback and control/config options for the user • Go ahead… try to modify the profiles available on your phone or PDA (Mac’s actually do this pretty well) • Rogue devices • A name is not an authentication credential. Don’t trust a device just b/c it’s friendly name is something you recognize • But.. What other ways are there to identify a device? • Social engineering • Change the name of your phone to something confusing (such as PIN1234) and then attempt to pair with random devices… you might actually get someone to do it.

27. Bad Implementation • Exposing functionality prior to authentication - This is the basis for the BlueSnarf attack • AT commands are sent to the phone that retrieve the address book • The phone for some reason assumes this is OK and gives you all the data • Packet-o-death - Dear God… haven’t we learned this problem yet? • Bluesmack sends a big l2ping packet to the device in an effort to kill it • Protocol fuzzing in general is a dandy way to knock over BT devices (and pretty damn easy to implement)

28. Bluetooth Defense Techniques • Great… now we need to figure out how to defend Bluetooth • Enterprise security tools are largely geared towards the infrastructure • With BT there is no real “infrastructure” • Many devices that touch the enterprise are not corp owned • We haven’t even figured out how to secure WiFi clients yet • HotSpot Defense Kit was a reasonable success (even if v2 never materialized) • Many host-based network security products now attempt rogue AP detection • Bluetooth is more prevalent, and the deployment scenarios are far more varied • All the more reason to work to lock it down • User needs a way to protect themselves from bad implementations

29. BT Defense - Some Advice • Security products need to be usable • There’s a corollary here that says “in complicated and emerging technologies, only users can recognize attacks” • Another corollary says that “products rushed to market don’t have the best security” • It turns out, like rogue access point defense, this is not rocket science… but yet it’s not a readily available capability for the user • Hell, it’s not readily available for developers either

30. Defense Mechanism - User Notification and Authorization • User should have the ability to be notified and authorize all connections and connection types • Inquiry scans (discovery), service discovery, RFCOMM connections, any particular profile that’s being accessed • I can sit in a bar all day and search for discoverable devices without being detected.. That’s just silly • Architecturally needs to be non-bypassable • User should have the ability to whitelist based on MAC addr, device key, or other values

31. Defense Mechanism - Configuration Options • Limiting access of trusted devices - Just because you’ve paired with a device doesn’t mean it should be able to do _everything_ • Per profile limits, connection limits, etc.. • Changing PINs • Even some of the PIN helpers are pretty lame. • Must have better PIN management • Better protection of Link Keys • More secure storage of Link Keys (TPM?) • If a device suddenly “loses” it’s Link Key, red alert should be sounded

32. Defense Mechanism - Profile Specific Guidance • For all devices, if new profiles suddenly are offered, don’t allow the connection • Ie: if your headset was just a headset yesterday, but now has OBEX and file transfer support, you may be under attack by a Linux box • Handsfree/Headset - Whitelist AT commands that can be used (AT+RING, AT+CKPD, etc) • Serial Port - Implement fuzzing detection • OBEX - Require auth _always_ • File Access - Sanity checks for data leaving the device

33. Defense Mechanism - Signature Based IDS • Some of the attack tools these days stick out like a sore thumb • As Madden would say, they “run it up the gut” • We should be looking for these footprints • Due to the nature of Bluetooth, this would have to be on a per device basis (a central monitoring infrastructure such as WIDS won’t work) • Ie: alert/shutdown BT on attempts to get telecom/pb.vcf|cal.vcs|devinfo.txt without authentication

34. Stack Changes Needed to Implement BT Defense • Ability to whitelist BDADDRs • Sure they can be spoofed, but it’s a start… • Ability to scan connecting devices to verify the device is the type and specie of device you expect • This kind of “connect back” is much more socially acceptable in wireless PAN’s • Allows for device profiling • Notification hooks • At all sensitive points discussed before, provide hooks to audit actions and make decisions based on those actions

35. Bluetooth Defense Kit - Demo • HAHAHA! • http://bluetooth.shmoo.com/ for source code once we get something working • Probably going to focus on IPC hooking to intercept and modify low level BT-related messages

36. Before We Finish Up.. Summer of Code, TSG Style • The Shmoo Group was given the opportunity to mentor 4 projects under the Google Summer of Code • http://code.google.com/soc/ • Firekeeper (Student: Jan Wrobel, Mentor: Len Sassman) • Browser-level Intrusion Detection via rulesets designed to detect and block malicous websites (neat, given Jeremiah Grossman’s talk) • Prototype available on firekeeper.mozdev.org • GPGGreasemonkey (Student: Kerry McKay, Mentor: Bruce Potter) • Client side mail encryption for webmail via FFX ext. • Currently have implementation for Gmail and Yahoo • svn checkout svn://e.shmoo.com/var/repos/gpgwebmail

38. SOC • Online Rainbow Tables Lookup (Student: Keith Larimore, Mentor: Freshman) • Focused on increasing speed • Completed: Basic search capabilities with Web interface, queuing, completion emails • In progress: DNS query Interface • Open Security Framework (Student: Soren Bleikertz,Mentor:Pravir Chandra) • A framework to simplify network security analysis

39. Summary/Questions?