How to Stop Bluetooth Insecurities

Bluetooth can be found in newer versions of everything from PDAs to cell phones, but the technology is far from secure. Companies can employ a number of defenses against Bluetooth's risks.

As the number of Bluetooth devices grows, are security managers aware of a similarly growing security concern?

“There are very real risks for Bluetooth-enabled devices,” notes Ollie Whitehouse, director of security architecture for @stake, a security consulting and research firm. “These risks will proliferate as adoption becomes more widespread and the devices vary from their default configurations.”

To help organizations assess and mitigate such concerns, @stake released a report, “War Nibbling: Bluetooth Insecurity,” which Whitehouse authored.

“War nibbling” is a play on “war driving”—a term for cruising the streets looking for unsecured wireless LANs (WLANs) to log onto. War driving is itself a derivation of “war dialing,” the practice (somewhat ancient, though still practiced) of dialing phone numbers with a modem, looking for modems, then exploiting any known vulnerabilities to gain access.

To be precise, says Whitehouse, war nibbling is “the process of mapping Bluetooth devices within an organization.” Bluetooth is similar to WLAN in that it allows devices to communicate wirelessly. Bluetooth, however, does so over much shorter ranges—up to 100 meters with class 1 devices. Class 2 and 3 devices—currently much more common—can only communicate at up to about 10 meters.

Today Bluetooth can be found in newer versions of everything from PDAs to cell phones, laptops to computer peripherals.

First-up on the list of possible methods of exploiting Bluetooth, Whitehouse notes that Bluetooth headers “are not encrypted, which can lead to a possible avalanche of potential attacks against the link layer.”

Beyond that type of attack, he lists three other probable attack vectors: “Locating discoverable Bluetooth devices, locating non-discoverable Bluetooth devices, and enumerating service information.” Turns out the first attack is easy, if devices have been set to be discoverable—a default for many Bluetooth devices.

Even devices set to be non-discoverable, however, turn out to be discoverable.

Whitehouse writes, “Devices that are marked non-discoverable should still in theory respond to direct name and services inquiry requests … to facilitate service and name updates.” It turns out the theory was valid. Whitehouse wrote a tool, RedFang v0.1, which brute-forces the Bluetooth radio to respond to a query. Some have critiqued his attack method, saying it would take an inordinate amount of time, yet Whitehouse says with the right set-up, it could be done relatively rapidly. He also notes that the forthcoming Bluetooth 2.1 specification should make such attacks take longer.

Companies, however, can use a number of defenses, says Whitehouse. These include: “Hiding your devices, personal firewalls, [and] bonding information checks.”

Hiding devices is a feature—a simple checkbox—in many (if not all) Windows 2000 implementations of Bluetooth. Bonding information checks look at the Bluetooth settings for a device or operating system to see which devices the user has explicitly allowed to bond with his Bluetooth device, and to verify that passwords (PINs) are in place.

Personal firewalls are a future defense. Whitehouse says at least one company is developing a firewall to block inappropriate devices from accessing a Bluetooth device. He also notes that the 1.2 Bluetooth specification, though not yet public, appears to have an anonymity feature for masking physical addresses, which could improve security.

For more information, see the “War Nibbling: Bluetooth Insecurity” report:

About the Author

Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.