Bluepot: A honeypot for Bluetooth attacks

Servers and PCs get the lion's share of security attention, so it is refreshing to occasionally find a security tool addressing other areas of the ubiquitous computing landscape. One such tool is Bluepot, a GPLv3-licensed honeypot for Bluetooth attacks originally written as a school project by developer Andrew Smith.

A "honeypot" is security slang for a trap designed to lure in attackers by masquerading as a vulnerable system. Generally speaking, a honeypot is used to catch attackers before they reach a genuine network resource (either to shut them down or to report them), but honeypots can also be used as purely research devices — helpful tools to profile the current vulnerability landscape. In Bluetooth attack preparedness, setting up an attractive honeypot probably means pretending to be a phone model with known exploits, known or weak PINs, or other enticing properties.

Bluepot is written in Java and distributed as a JAR file, although, despite the language choice, for the moment it runs only on Linux. This is because Smith designed the application to support the use of multiple Bluetooth adapters simultaneously, which is a feature that Windows cannot handle. The current release is version 0.1, from December 29, 2010. From the Subversion logs, it appears that the bulk of the code was written in the spring of 2010, with a cleanup phase preceding its public release in December. Smith announced the release on his blog, on which he regularly writes about honeypot development.

To get started, you must first install the Bluetooth development libraries for your distribution (presumably this is required to make use of the libraries' lower-level Bluetooth utilities in order to manipulate the adapter's hardware settings more easily). Debian and Ubuntu title the package libbluetooth-dev, while Fedora and Red Hat name it bluez-libs-devel, and openSUSE calls it bluez-devel. You must also have one or more BlueZ-supported Bluetooth adapters. With the dependencies taken care of, simply unpack the Bluepot tarball, and launch Bluepot-0.1.jar with root privileges (root is required in order to change adapter settings; if you attempt to start Bluepot without root privileges, it will not even run).

Normally, your Bluetooth adapter advertises a public name set through the GNOME or KDE tool's Bluetooth configuration utility, and a "computer" major device class. Bluepot allows you to advertise each adapter on your system with a different name, major device class, and minor device class. Historically, lower-level devices such as low-end cell phones, printers, and headsets have had most of the Bluetooth security holes exploited in the wild, particularly because few consumers update the firmware of such products. Thus, to make your honeypot the most attractive to would-be attackers, you may wish to set its name to an older-model Nokia phone and its device class to phone/cellular. Alternatively, Bluepot can randomly alter the advertised name and device class of each adapter, which is probably wise if you want to take a longer look at the attackers in your surroundings.

Attacks

Bluepot runs its adapters in discoverable mode, accepting all incoming connection requests and transfers. It tracks the OBEX (Object Exchange) protocol used to directly transfer files between devices, the RFCOMM (Radio Frequency Communication) protocol used for serial communication, and the L2CAP (Logical Link Control and Adaptation Protocol) used for transmission control.

The simplest Bluetooth attack is called bluejacking. In spite of the seeming connection to "hijacking," bluejacking is simply sending an unauthorized message of file transfer to another device, using OBEX. For the most part, modern phones and printer now refuse to accept incoming file transfers without explicit user authorization, but there are older models that still accept files from previously-paired devices, and some phones that automatically accept vCards (or any other file payload with the .vcf extension) in the interest of friendly business-card-like information exchange.

Cracking tools may allow an attacker to brute-force the four-digit numeric PIN used to initially pair new devices, which potentially allows for an attack vector to get around the previously-paired-device limitation. According to the specification, Bluetooth PINs can be up to 128 bits long; consumer electronics manufacturers tend to use 4-6 numeric digits to make them easier to remember — which also makes them far easier to brute-force. Even worse, a significant percentage of non-computer devices use easily guessed PINs like 0000 or 1234.

A far more serious exploit goes by the memorable name bluesnarfing; this attack involves remotely reading files from another device: address books, SIM contacts, photos, saved text messages and emails, etc. As with bluejacking, it works over OBEX, although it is more complex, because the remote device must authorize file browsing. The weak-PIN problem is a potential issue here, too, although most devices use encryption, and there are fewer devices that accept any form of incoming file browsing requests without explicit user authorization.

The most serious attack is referred to as bluebugging, which amounts to remotely taking over control of the target device, using it to place or route calls, send SMS or MMS messages, or consume data services. This is typically done by exploiting the Bluetooth stack in order to do a privilege escalation. In addition to these phone-centric attacks, there is an array of potential exploits not centered around cell phone usage, including uploading malware to Bluetooth devices, and hijacking or snooping audio connections.

Bluepot should be able to track and log all of these connections. In its configuration tab, you can specify a directory in which to store any files uploaded by attackers, and you can customize the OBEX and RFCOMM response messages sent, in order to better masquerade as a specific device.

Testing

News and blog coverage of bluejacking and bluesnarfing peaked in the mid-2000s, at which point there were a number of common cell phones on the market with known vulnerabilities. Most of the media coverage of the phenomenon I read involves attackers lying in wait for victims in high-traffic public locations such as mass transit points. Since I did not expect to find such nefarious behavior on display in the non-public-transport-served area where I live, I opted to test Bluepot at home instead, by using a pair of machines and a variety of Internet-provided tools.

That itself proved to be a challenge, since most of the publicly-available pen-testing tools date from the mid-2000s as well, and BlueZ, the Linux Bluetooth stack, has undergone a number of revisions since then. The Bluesnarfer tool, for example, is apparently written for BlueZ prior to the version 4.0 release, which changed a number of the setup utilities. Others, like Blooover, are written for Java MIDP-powered phones.

Nevertheless, I was able to test and verify Bluepot's ability to falsely advertise my desktop's USB Bluetooth adapter as a phone, a printer, a network access point, and several other devices, and to safely intercept OBEX file transfers. Along the way, I think I discovered what I would have to call a bug in the GNOME Bluetooth stack, namely that every Linux machine that I tested with aggressively caches the advertised names and device classes of the Bluetooth devices that it discovers when scanning for nearby connections — even when I could verify that a name change had taken place on the Bluepot machine (with hciconfig), it took a reboot of the attacker machines to pick up the updated information.

Along those lines, though, one thing I was not able to do was browse files on the Bluepot machine. That is a feature I was expecting in a honeypot application — to see which files attackers requested, and potentially to feed them bogus data in response. It is possible that Bluepot supports this and I simply could not get it to work — sadly, BlueZ 4.x on Linux is almost completely undocumented. It has improved considerably in the past two or three years, but vague and cryptic error messages (such as "Unable to find service record" in response to a failed OBEX file transfer to a paired device) are still the norm.

I had better luck with the audio device exploit tester carwhisperer, which is designed to inject a harmless audio message to un-secured car hands-free devices, and to intercept and record audio from them. Naturally there was no audio to record when using Bluepot to simulate a hands-free device, but Bluepot tracked and logged the connections admirably.

Bluepot has some basic diagnostic tools, allowing you to chart protocol traffic and file downloads over time, and to view the session logs sorted by adapter and attacker (for each attacker, it logs the Bluetooth device address). One area in which Bluepot falls short, however, is in saving these session logs: its logs its internal status in the logs directory of the unpacked tar archive, but this only includes startup, adapter initialization, and shutdown messages. It apparently attempts to log attack data with the log4j Java library, but through some misconfiguration, fails to do so, and the log settings are not configurable in the user interface. Thus, if you want to save session data, you will have to cut-and-paste information from the GUI's log tab into an external editor.

Smith is pretty open about Bluepot's feature set and limitations on the project site and on his blog; the basic framework is there to collect Bluetooth attack data, and, through multiple-adapter support and device randomization, to do so without the likelihood of discovery. It might be more powerful to masquerade as other Bluetooth addresses, or to provide some more interactive honeypot-like features (such as dummy file content), but it is still a nice starting point, and admirably simple to get started using. I don't expect to catch bluebugging criminals at my local Starbucks, but it will be tempting to take Bluepot with me to the next free software conference I attend, just to see what turns up in the hallway track.