Ubertooth - building and using

I'm working on a pen test for a client, which includes some bluetooth signal analysis. I decided to go a step above and actually do some ubertooth work--and immediately found myself in over my head. My first step was to buy a HackRF device, hoping I could use it for several purposes but soon discovered that the ubertooth tools aren't built for HackRF platform. After a good week beating on that, I gave up and had the Hak5 folks overnight me an Ubertooth.

I have followed the Ubertooth build guide to a T, but when I plugged in my ubertooth and tried to use the Spectrum Analyzer (as described in the Getting Started Guide), I encountered problems.

FeedGnuPlot

My first problem was:

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools$ ubertooth-specan -G -q | feedgnuplot --stream 0.5 --domain --3d

The program 'feedgnuplot' is currently not installed. You can install it by typing:

sudo apt-get install feedgnuplot

ubertooth-specan: command not found

Yah, oops - that's an easy fix:

jo@ubuntubox:~$ sudo apt-get install feedgnuplot

Reading package lists... Done

Building dependency tree       

Reading state information... Done

The following extra packages will be installed:

  aglfn gnuplot-qt

Suggested packages:

  gnuplot-doc

The following NEW packages will be installed:

  aglfn feedgnuplot gnuplot-qt

0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.

Need to get 1,014 kB of archives.

After this operation, 3,354 kB of additional disk space will be used.

Do you want to continue? [Y/n] y

BTBB CMake Error

The next error I got was at the bottom of the first set of command text above, also here:

ubertooth-specan: command not found

Hmm. CD'ing into the tools folder I realized duh - I hadn't build the tools yet. So the timeless march begins:

mkdir build

cd build

cmake ..

make

sudo make install

But wait, error! 

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools/build$ cmake ..-- The C compiler identification is GNU 4.8.2

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

CMake Error at src/CMakeLists.txt:24 (find_package):

  By not providing "FindBTBB.cmake" in CMAKE_MODULE_PATH this project has

  asked CMake to find a package configuration file provided by "BTBB", but

  CMake did not find one.

  Could not find a package configuration file provided by "BTBB" with any of

  the following names:

    BTBBConfig.cmake

    btbb-config.cmake

  Add the installation prefix of "BTBB" to CMAKE_PREFIX_PATH or set

  "BTBB_DIR" to a directory containing one of the above files.  If "BTBB"

  provides a separate development package or SDK, be sure it has been

  installed.

CMake Warning (dev) in CMakeLists.txt:

  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.8)

  should be added at the top of the file.  The version specified may be lower

  if you wish to support older CMake versions for this project.  For more

  information run "cmake --help-policy CMP0000".

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!

See also "/home/jo/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools/build/CMakeFiles/CMakeOutput.log".

What the...? 

This took some research, but I finally found the following comment from Govind-mukundan on the GreatScott Github issues discussion:

Thanks a lot for your information (I'm a bluetooth noob so have lots of reading up to do). I'll try to do some more tests tomorrow and add the capture. I also have some BLE devices and I'm curious to see them in action.
To add on the build requirements - in the setup guide it's mentioned that to install the wireshark plugin you should run:
$ cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/wireshark/libwireshark1/plugins ..
But this didn't work for me (I couldn't find the btbb inside the wireshark filters). I tried both libwireshark1 and libwireshark3 folders. However the instructions inside the README at libbtbb/wireshark/plugins/btbb/ says that you should run
$ cmake .
That did work for me, perhaps this should be updated in the guide too? It's all quite confusing :)

This actually works!

ubertooth-specan

The Getting Started says to run "ubertooth-specan" as explained in the readme. When I tried the read-me's command line, I kept getting errors:

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools$ ubertooth-specan -G -q | feedgnuplot --stream 0.5 --domain --3d

ubertooth-specan: command not found

After building and rebuilding I realized - there is no ubertooth-specan. The tool is ubertooth-specan-ui! So I modified the command and voila - another error!

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools$ ubertooth-specan-ui -G -q | feedgnuplot --stream 0.5 --domain --3d 

Traceback (most recent call last):

  File "/usr/local/bin/ubertooth-specan-ui", line 260, in <module>

    window = Window()

  File "/usr/local/bin/ubertooth-specan-ui", line 227, in __init__

    self._device = self._open_device()

  File "/usr/local/bin/ubertooth-specan-ui", line 250, in _open_device

    return Ubertooth(device)

  File "/usr/local/lib/python2.7/dist-packages/specan/Ubertooth.py", line 38, in __init__

    self._device.set_configuration()

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 559, in set_configuration

    self._ctx.managed_set_configuration(self, configuration)

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 91, in managed_set_configuration

    self.managed_open()

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 70, in managed_open

    self.handle = self.backend.open_device(self.dev)

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 733, in open_device

    return _DeviceHandle(dev)

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 618, in __init__

    _check(_lib.libusb_open(self.devid, byref(self.handle)))

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 571, in _check

    raise USBError(_str_error[ret], ret, _libusb_errno[ret])

usb.core.USBError: [Errno 13] Access denied (insufficient permissions)

Well, alright, this one is easy - USB permissions. The readme talks about a few fixes that I haven't implemented yet - I simply ran the same command as sudo and voila for real - introducing "Ubertooth Spectrum Analyzer"

I am happily seeing 2.4 gHz spectrum.

Flipping the “Production” bit on a Nexus 7

As a security researcher, I’m constantly battling the lack of access on my retail Nexus 7. I spent about 12 hours today messing with this, rooting the device and modifying boot images. Each time, my device would get stuck in a “soft-brick/bootloop’.

It was frustrating.

I followed every step-by-step I could find, continuously modding the setting in build.prop but to no avail. Funny enough – the trick I was using to root and recover my device is what ended up offering a solution!

Root Your Device, For Real

There are a number of roots out there, but none as good as “Nexus Root Toolkit’ by WugFresh. I was a little hesitant, but believe me – if you follow EVERY STEP (esp deleting and installing drivers) it works fantastic.

Run through the wizard. Follow the YouTube videos. A child can do this.

But Not Really

However, after you’ve rooted your device, you’re still in “Production” mode and you still can’t get root in shell. To accomplish that, you need to flip the production bit. But, as mentioned, I could never figure out how to flip the bit and then restore the boot image. Whenever I flashed the image back onto the device, it would go into a continuous reboot. At some point, however, I was poking around the Nexus Root Tooklit UI and saw the “Advanced Utilities” option to temporarily boot on an opened image.

I used it a couple times to see what was going on with my device – it would boot on the “modified boot image,” even when it wouldn’t boot on my slightly modified image. And when I adb shell’ed into the device, I had that wonderful root option!

 

It was only around hour 11.5 that I realized I could have flashed that image (their modified boot image) onto the boot partition, and my device would no longer be in production mode.

So it’s simple…

• Launch NRT
• Click “Advanced”
• Under “Boot Flash Image,” switch the option from “Boot (Temporary)” to “Flash (Permanent)”
  
• Select the modified boot image in the \data\modified boot image directory in the NRT install folder
• Let it flash

Your device is now no longer in production mode – you can mount it as root:

Further Research

I’m sure I could simply flip that bit somehow, but I just haven’t figured out how. After a full 12 hours (on top of an 8-hour work day), I decided to just move on. Anyone with better ideas – leave a comment!

WarPi–The Build

In my other blog post, I documented the stop/start challenge I had building a War Pi. Now that all the equipment is ready, it’s time to actually start building. I’ve picked up a number of tips and tricks along the way, and I’ll be documenting them here.
The War Pi is a Raspberry Pi project running Kismet, with GPS enabled. The project is a SANS Gold Paper project by Scott Christie; you can read the paper here. For the WarPi to work “mobile”, you need the following:

• Raspberry Pi
• SD Card (4 GB or larger)
• Alfa wireless network adapter
• USB GPS
• USB battery pack
• Misc USB cables

Here’s my setup:

Operating System

The first step was choosing from the several options for operating systems. The folks at RaspberryPi.org are awesome about building, updating and releasing operating systems (you can find them here). I chose Raspbian because it is the most common OS, and because it was the base OS for the WarPi build. There’s potentially a reason to go with one of the OS’s (for instances, Arch Linux), to have a smaller kernel and such. For the purpose of this project, sticking with the norm is probably the best solution.

Configuring the OS

I’ve written a longer blog on how to image, update, upgrade, and reimage the Raspberry Pi operating system, you can read it here. These are the steps I took to get to my current base image.

Customizing the Hostname

My base image includes SSH server running at startup, so I can get logged in whenever it’s live on a network. One thing I like to do is customize my hostname—in this case, it’ll be “WarPi”. Some people recommend a stealthier name, but given that the WarPi will only be used for client engagements, I want to be completely transparent.
There’s a nice article on the steps to accomplish this. You can read it here.

Expanding Filesystem

Scott Christie’s article calls for expanding the file system as a first step. I don’t do this, because once the system is built I want to image it back off. If I expand the file system, my image will be quite large (my card is 6 GB). So I’ll hold off until all the apps are installed and working.
Next: build the WarPi.

Installing Applications

Scott Christie’s WarPi build follows these steps:

1. Install and configure GPSD (the GPS Daemon)
2. Install and configure Kismet
3. Auto-start Kismet

GPSD – The Good, the Bad, the Ugly

In my initial efforts to build a WarPi, I was using an older Microsoft Streets and Trips GPS device. My early proof of concept was just using it with minicom to review serial communications – that worked fine and I blogged a bit about it. When I combined GPSD and my old GPS unit, however, I ran into trouble and learned a lot about debugging GPS units. Unfortunately, it appears GPSD fried my old SiRF GPS unit – even though I’ve got it back to NMEA mode, the unit cannot get a GPS fix anymore. So I’m understandably wary of GPSD. In some testing I did the other day, I discovered that Kismet works fine with my new GPS unit in NMEA mode over serial, so my plan now is to skip the GPSD installation and let Kismet speak serial/NMEA to the GPS.
Therefore, my build steps will be:

1. Test the GPS
2. Install and configure Kismet for serial NMEA GPS
3. Test Kismet with the GPS
4. Auto-start Kismet

Step 1: Testing the GPS

Install Minicom

Minicom is a great little serial tool, but it doesn’t come preinstalled in the OS, so we’ll be installing that prior to using the GPS. Simple:
sudo apt-get install minicom
And voila – you have minicom installed! To make sure it works, enter the following:
sudo minicom –s
And the minicom app will start at the settings screen:

Just choose “Exit from Minicom” by arrowing down—we have to get the GPS working before we can use minicom.

Connect the GPS

When you connect the GPS over USB, the sudden change in power can cause your Pi to restart. The best strategy is to shut down your Pi, connect the GPS, and then power up.
Once the system boots, you’ll need to discover your GPS’s “location” in the system. Type the dmesg command and scroll through the output looking for “USB-Serial” or such. Eventually you’ll see a series of entries for the GPS, ending in “pl2303 converter now attached to ttyUSB0” or something similar, as highlighted below:

Now you’re ready to use minicom to view NMEA strings coming from the GPS. Type:
sudo minicom –s
to enter the settings screen. Let’s get going!

1. First select “Serial Port Setup” by mousing down to it and pressing the Enter key.
2. Next, press the “A” key, then backspace and edit the entry to read /dev/ttyUSB0 (or wherever your GPS unit ended up). Then press “Enter” to set your changes.
   
   NOTE: the location for your GPS is case sensitive!
   
   
3. Now we need to modify the serial communications settings. Press “E” to open the Comm Parameters menu:
   
4. Press “B” until the Current comm speed is 4800:
   
5. Make sure the “Current” reads 4800 8N1 as above. If it doesn’t, press “Q” to set the second half of the string.
6. Once the settings are correct, press “Enter” to exit each screen (two times).
7. Now arrow down to “Save setup as dfl” and press “Enter”
8. Next, arrow down to “Exit” and press “Enter”. You will drop directly into minicom and see NMEA strings pass by…
   
   The big white box is an attempt to anonymize my location.
9. To close out of minicom, press “Ctrl+A” then press “Q” and choose to leave without reset.

Installing Kismet

It’s actually not an “install” per-say, but a download and build. Christie’s instructions are still accurate – the link is correct as of September 2014, and the instruction steps are all accurate. I’ll summarize:

1. First perform the wget command to download the source.
2. Next, install the dependencies as documented
3. Then extract the source
4. Then prepare the code to compile and install
5. Finally, make and install Kismet

The make part… That takes a long time. Be patient—go for a walk with the dog, spend time with family, etc.

UPDATE: 03/2016
NOTE that there is a bug in Kismet, so it places access points all over the antarctic. Not kidding. See this Kismet forum article for details on how to fix it (you're going to have to modify code).

If you look for the K7JTO repository on Github, you can download the updated Kismet files, or just hand-fix them yourself.

Configuring WLAN0 Out

By default, Raspbian wants to hot-plug and use a wireless device as much as it does an ethernet device. Kismet however wants full access to the WLAN device, so it will squawk at you:

I poked around quite a bit, but ultimately fixed this by editing /etc/default/ifplugd and changing the line INTERFACES=”auto” to “INTERFACES=”eth0”

This instructs ifplugd to only look at eth0 to autoconfig, and not to the WLAN. Inconvenient if I actually want it to auto-configure a WLAN connection, but I actually don’t want it to. Kismet needs full control of wlan0.

Smoke Test

This is a good time to make sure Kismet is working. It’s simple – just type
sudo kismet
If it’s working, you’ll get a bunch of prompts as recorded in the whitepaper. Eventually you’ll see the Kismet server logs, which will look like this:

Pressing the Tab key will highlight the “Close Console Window” and take you to the Kismet interface, which will look like this:

(GPS coordinates blanked out)
If you’ve gotten this far, you are golden – configure Kismet to auto-start and to log output and you have a WarPi. Congrats!
From this point on, you can follow the WarPi directions in the article and everything should go just fine. NOTE that you might want to use dd again to make a base WarPi image so you don’t have to go through all of this again if your card dies or something.

Why Combine Static Code Analysis with Manual Pen Testing?

As company culture becomes more security focused, the company eventually decides to perform a penetration test against their application assets. As a consultant, I'm often asked to provide a broken down cost for "big rocks" in the process. Companies today are thinking quite narrowly--they want a penetration test when really the goal is to assess their application. My challenge has been to demonstrate the value of the full application assessment and help companies get beyond the pen test requirement.

What's an app assessment? Well, it's a mix of white- and black-box activities which result in fact-based risk decision making. There are generally five components to an application assessment:

1. Application review: what are the goals, business needs for an application, what kinds of data are stored in the app, what are the technologies behind the app?

2. OWASP ASVS: this tool captures key security decisions implemented in the application. It's an exhaustive form (level 3, which is usually applicable to healthcare and other sensitive applications, contains over 150 validation points).

3. Static code analysis: automated review of application source code. At Caliber, we are big fans of our partners at Checkmarx SCA. I'll blog on "2nd gen" SCA tools sometime. The key here is that SCA can generally find more vulnerabilities in certain categories faster than I can do it manually. For instance, XSS or SQLi vulnerabilities. These generally need to tested for one control at a time, with at times multiple permutations of inout text. Manually or even with dynamic application analysis, this can take days. Automated tools accomplish this in minutes or hours.

4. Manual penetration test: this is the traditional pen test activity everyone thinks about. With SCA involved earlier, I can spot check validity of results, and focus my efforts on topics like session management, authentication and business logic.

5. Analysis: data from each phase is assembled into a report, from which it can be assessed and prioritized.

Just pen testing alone *does* mimic what an attacker will do, with one significant difference: a paid pen test functions under time constraints. A determined attacker will take days or even weeks to profile and attack an application. This is one of the reasons why performing all 5 steps in an app assessment is beneficial: white-box assessments get to the same vulnerabilities, more quickly.

When it's time to do security on your web and mobile apps, don't just request a pen test. Go for the full assessment--sure it might cost a bit more, but you and I will both sleep better knowing you are more secure!