Tuesday, November 4, 2014

SDR Dongle and APRS with GQRX on Kali

I just upgraded my pen test machine to Kali Linux (Ubuntu was getting heavy and slow). I discovered Kali has a great collection of SDR tools and, since I have both a receive-only SDR dongle AND a HackRF platform, I thought it would be interesting to see if I can receive and decode APRS packets. Today's experiment was using GQRX, which is a user-friendly UI-based SDR utility. Here's how I did it.

  1. I may have installed GQRX from the Applications/System Tools/Add Remove Software utility. I can't remember; I added a ton of stuff.
  2. Plugged in my SDR dongle with an antenna connected
  3. Opened GQRX
  4. Set the frequency to 144.390 (US frequency for APRS)
  5. Opened the AFSK1200 decoder
And... nothing. I could hear the packets on my HT, I could see the transmission on GQRX's waterfall, but AFSK1200 Decoder wasn't receiving anything. I poked around for 20 min on the Internet. Then on a whim I switched the filter from "Normal" to "Wide" and voila! APRS packets are being decoded:


This is great, as I'm getting a "radio on a chip" in a day or two, to use with Arduino  for a rocketry/balloon telemetry package. Now I can test decoding my APRS packets.

Next up: using HackRF to decode - and then to encode - APRS packets.

Monday, October 13, 2014

Building and Using Mac-Robber on Android

My Android assessments often see users scattering files across the device. It can be tough to track all those files down, so I often resort to using mac-robber to track file system changes. What is mac-robber? It's a tool that walks the file system to determine timestamps (create and modify) for all files on your device. As such, you cannot run mac-robber unless you have a rooted device (it needs access to the full file system). See my other blog posts on rooting your Android device.

Compiling and Installing mac-robber on Android

You can learn more about mac-robber for Android and iOS here. Note that, in Sawyer's article he includes the following instruction for compiling. This is incorrect:
  arm-linux-gnueabi-gcc -static -o -mac-robber mac-robber.c
The - before mac-robber is unneccesary. The correct command is
  arm-linux-gnueabi-gcc -static -o mac-robber mac-robber.c
  1. First step is to download the source files from http://www.sleuthkit.org/mac-robber/download.php. 
  2. Next, add a repo so you can cross-compile mac-robber onto the Android platform:
    sudo add-apt-repository ppa:linaro-maintainers/toolchain
  3. Next, install the GNU compiler:
    sudo apt-get install gcc-arm-linux-gnueabi
  4. Finally, compile the source:
    arm-linux-gnueabi-gcc -static -o mac-robber mac-robber.c
Now that you have it compiled, you need to push the app to your device over ADB. Run the following commands to create a mac-robber app directory, change permissions on the directory, and push mac-robber to the device. The final step verifies to you the status of mac-robber.

john@joe:~/macrobber$ adb shell
root@flo:/ # mkdir /data/mac-robber
root@flo:/ # chmod 755 /data/mac-robber
root@flo:/ # exit
john@joe:~/macrobber$ adb push mac-robber /data/mac-robber
3557 KB/s (603897 bytes in 0.165s)
john@joe:~/macrobber$ adb shell "/data/mac-robber/mac-robber -V"
mac-robber information:
   version: 1.02 
   author: Brian Carrier
   url: http://www.sleuthkit.org
john@joe:~/macrobber$ 

This is the end of the really difficult part of the process.

Running mac-robber

Next, do whatever you're going to do with your test (I generally boot and use my application for a bit, to exercise all of its functionality). This generates a good amount of data - the more functionality you use, the mor./configuree accurate your results will be.

This commands executes mac-robber and covers the entire device:

adb shell "/data/mac-robber/mac-robber /" >attachmentopen.body

This may be more data then you need, but I find it's good to be thorough, at least until you understand the device.

OK - now you have a huge file full of timestamps. How do you interpret it? Easy - use mac-robber's companion, mactime, to scan the file and generate a time-ordered file.

Interpreting the Results

Mac-robber outputs a long text file with file change history. You'd think you could import that into mactime, but the default mactime outputs binary format, so you'll need Sleuthkit's mactime perl script if you want to do anything with the output. To use that:
  1. Download the sleuthkit from http://www.sleuthkit.org/sleuthkit/download.php
  2. CD into the extracted sleuthkit
  3. Build the sleuthkit. Note: I skipped the last step (sudo install) simply because I didn't want to run the risk of clobbering my OS's mactime with the sleuthkit's version
  4. ./configure
  5. ./make
  6. Copy "mactime" into your mac-robber directory
Now that you have a mactime app, running it's pretty simple: just run this command:

mactime -b attachmentopen.body > android.timeline

If you want to constrain to a given start date, run this command:

mactime -b attachmentopen.body 2014-01-01 > android.txt

If you're looking for data about a particular app, you can use grep to grep the output file, like this:

grep -i 'facebook' android.txt > facebook.txt

Happy sleuthing!

Friday, September 26, 2014

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.

Friday, September 19, 2014

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.

image

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!

image 

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)”
    image
  • 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:

image

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!

Saturday, September 6, 2014

WiFi Pineapple Radios

I've been slowly poking away trying to figure out definitively which antenna/radio corresponds (by default) to which WLAN. The support forums don't have much information, so I spent an hour or so today searching the web for info. I finally have it figured it, I believe.

Looking at front w/antennas on bottom:

Light Radio radio   wlan# Location
Blue AR9331 radio0  wlan0 Lower right by SD card
Red RTL8187 radio1  wlan1 Lower left near dip switches

Some of this info came from https://forums.hak5.org/index.php?/topic/33485-physically-what-is-the-wlan0wlan1-antenna/?hl=%2Bwhich+%2Bantenna

Typically WLAN0 is the access point clients connect to (the access point) and WLAN1 is the NIC used to connect to another wireless network. Why is this important?

  1. If you're trying to lure users to connect to your pineapple, having a high-gain antenna connected to WLAN0 would be helpful. That's the blue antenna, AR9331 radio, lower right by the SD card.
  2. If you're trying to connect/assess remote wireless networks (say with a Yagi directional antenna) connecting your antenna to WLAN1 would be helpful. That's the red antenna, lower left near the dip switches.
There was apparently at some point a problem with radios switching, but it seems that problem has been addressed (it was back in Sept 2013).

You can confirm this by connecting to your Wifi Pineapple over SSH:


root@Pineapple:/# cat /etc/config/wireless

config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11ng'
option macaddr '00:13:37:##:##:##'
option htmode 'HT20'
list ht_capab 'SHORT-GI-20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'

config wifi-iface
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'Pineapple5_2342'
option encryption 'none'

config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11g'
option macaddr '00:13:37:93:58:d2'
option channel '5'

config wifi-iface
option device 'radio1'
option mode 'sta'
option network 'wan'
option ssid 'HOME-8858'
option key 'Sn1ckers'
option encryption 'psk2+ccmp'

Note on MAC addresses: 
  • 00:11:37 is associated with "Orient Power Home Network Ltd (this is radio0, the AR9331)
  • 00:13:37 is also associated with "Orient Power Home Network Ltd" (this is radio1, the RTL8187)

Thursday, September 4, 2014

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:
WP_20140904_001

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:
image
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:
ttyusb0
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!

    image
  3. Now we need to modify the serial communications settings. Press “E” to open the Comm Parameters menu:
    image
  4. Press “B” until the Current comm speed is 4800:
    image
  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…
    minicom
    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:
image
I poked around quite a bit, but ultimately fixed this by editing /etc/default/ifplugd and changing the line INTERFACES=”auto” to “INTERFACES=”eth0”
image
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:
image
Pressing the Tab key will highlight the “Close Console Window” and take you to the Kismet interface, which will look like this:
kismet
(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.

Wednesday, September 3, 2014

Basic Raspberry Pi Hacks

I've put a fair amount of time into setting up Raspberry Pi images lately. Between work and fun, my son and I have four serious Pi projects on our immediate backlog:

  1. AirPi Tracker: using a cheap USB SDR dongle, track local flight paths. Why? I'm not interested in flight paths actually, just interested in Pi and using it with SDR. This project comes from the fantastic book "Raspberry Pi Hacks" (loaded with great ideas)
  2. PiGame: another project from Raspberry Pi Hacks, this sets up your Pi as an emulated game console for a series of classic games. Having three teen sons, I am thinking this one is going to be a hit.
  3. War Pi: this is the main project for the time being, creating a "war walking" 802.11 analysis device. With an Alpha wireless adapter and a GlobalSat BU-353S4 GPS, I can walk around client buildings and assess the location and signal strength of surrounding 802.11 access points (which pose the threat of employees connecting to external wireless points).
  4. Pi Fence: this project is in its infancy, but the idea is to build a Pi distro for home network security, including a firewall and an authenticated proxy (authenticated by user, not by device).
Fun projects - they all require a good basic Pi image. This article captures my lessons learned in creating that base image.

Base Pi Image

The great Pi community has created a number of Pi images (found here). They maintain and update these images often--this is the place to go to get that beginning image. I went with Raspbian for my current projects, simply because it's tried and true. For Pi Fence, I may go with a lighter OS, but for now this works.

Before you can really get started, you need to download your image. Not that difficult....

Next, you'll need get the image onto your SD card. An image isn't really a set of files, it's actually a bit-by-bit copy of a disk. You can't just drag and drop it onto an SD card and have a functioning Pi. You need to "image" it to the card.

Windows absolutely stinks at this. My Win8 machine is at the point where it can't even see a card with a Pi image on it - it's very frustrating. Luckily I do a lot of work in Linux (my personal project laptop runs Mint, and my workstation runs Ubuntu), so I have been able to work very efficiently with the SD card process. If you don't have a Linux machine, you could try running Linux in a Virtual Box virtual machine. If you have a USB SD card reader, you could (rather ironically) use a Pi to do all of this. That's what this blog post is all about - getting the image onto your card, upgrading it, customizing it, and then storing your personal image.

Step 1: Clear Your Card

You can skip this step if your card is brand-new and unformatted. Otherwise, you'll want to get rid of any file partitions and the likes which are present on your SD card. To do this, you'll want GParted (it can be done with the "fdisk" command, but it's cumbersome).

Boot GParted (it will require you to enter your password) and make sure the selected device is your SD card. It'll look roughly like this:


If the device in the upper right corner is /dev/sda, do NOT proceed. That's your computer's hard disk, and what you are about to do will completely nuke your hard drive. Select /dev/mmcblk0 or whatever is showing that's roughly the size of your SD card.

How do you know what your SD card is? Just after you insert your SD card, in a terminal window type the command dmesg. The last few lines of output will look like this:

[64576.492079] mmc0: card 0007 removed
[64580.605642] mmc0: new high speed SDHC card at address 0007
[64580.612048] mmcblk0: mmc0:0007 SD8GB 7.42 GiB 
[64580.616186]  mmcblk0: p1 p2
[64580.873309] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[64581.005227] EXT4-fs (mmcblk0p2): recovery complete
[64581.005237] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
The third line of output is the path to the SD card, proceeded by /dev/. So in my case, /dev/mmcblk0.

If your card has already had a Pi build on it, it'll look like the one above. Select each partition (in my case, /dev/mmcblk0p1 and /dev/mmcblk0p2) and from the Partition menu, select "Delete". When you've selected all the partitions to delete, you have to click the "Apply all operations" button (the last button on the left). Otherwise, none of your changes actually occur.

NOTE: deleting a partition is permanent...

Step 2: Image Your Card

The next step is to get the bits from the Pi OS image onto your card. You'll use the dd command for this. From the command line, type:
sudo dd if="base_pi_image.img" of="/dev/mmcblk0"
Notes:
  • The "if" option is the source file. Enter the path to the image you have downloaded from the Raspberry OS downloads page.
  • The "of" option is the destination--in this case, enter whatever your SD card is
Now just wait. It looks like nothing is happening, but slowly, bit by bit, that 2.x GB image is being created on your SD card. Be patient.

Once the image has been copied, you are almost ready to boot your Pi--but not quite. One of the next steps will be to upgrade the base image to include the latest kernel updates and such (stuff that's not rolled back into the base image, but that you'll want). It's a long process to upgrade your Pi OS and I think it's worth doing before you create your personal Pi image. The problem is, the base Pi image is small and leaves little room to download and install updates, so you'll need to temporarily grow your Pi image just a bit.

Step 3: Grow Your Pi Image

You may have noticed that, when you used the dd command to image your SD card, there was a large chunk of unallocated space. Don't worry - you'll get to use that space eventually. For now, we just want to grab a little bit of it, so you can upgrade your Pi OS and then create your own, updated, base image. 
You can skip this step if you don't care about having an updated personal image lying around (with 4 projects going, I wanted to do this only once).

To grow your image,
  1. Open GParted again
  2. Click on the file system partition (usually /dev/mmcblk0p2 for me)
  3. From the "Partition" menu, select "Resize/Move"
  4. Increase the size by about 500 MB (just add 500 or so to the "New Size"

Easy as Pi. Sorry, bad joke... But now that you have some extra space, you will be able to boot your Pi and update/upgrade the image.

Step 4: Update and Upgrade

The nice thing about the Linux community is that there's just so much going on out there, and people take a lot of time to actually help each other. With your Pi image set, go ahead and boot up your Pi and get connected to the network (from a personal perspective, I prefer to use ethernet but wireless is fine). Open a terminal window and type the following command:

sudo apt-get update

This will cause your Pi to search the corners of the Internet looking for updates to the software packages installed in the base OS. 

Next, you're going to start a rather long process - the process of updating the kernel itself. In the terminal window, type

sudo apt-get upgrade -y

Now would be a good time to walk the dog, play with the kids, read a book, or chat with a loved one. This can take quite some time.

When that's done, the next command is

sudo apt-get clean

This command cleans off any temporary files left over from the update and upgrade processes.

Step 5: Make Any Other Changes

There are a number of additional changes you could make at this point:
  • Networking: you have already set up networking so you could get to the Internet, but if you want to make any changes that will be part of your base image, do so. For me, I disable the wireless network and I specify a static IP address so when my Pi boots, it's a known host on my internal LAN.
  • Firewall: you may want to enable a firewall at this point, or install anti-virus (Clam is a great AV tool for Linux)
  • Add or remove applications: if there are applications you know you won't need (perhaps Scratch or another programming application) you can remove those at this time. If there are other apps you need or want, install them.
  • Disable services: there may be services running which you don't need, and disabling them means you free up system resources. Go for it.
At this point, your Pi is as up to date as it gets, and it's time to create your personal base image. 

Step 6: Create Your Personal Base Image

In this step, you'll create a base image which you can use going forward. I'm a bit of a geek, so I actually perform an added step, which is reducing the size of the base image - it's not needed, I just like to do it. I learned it from a very helpful blogpost by xalixo on the Raspberry Pi forum.
  1. Back on your main computer, insert your SD card and use the dmesg command again to make sure you know how to reference it.
  2. If you want to shrink your image again, do the following
  • Open Gparted again
  • See how much space is used on the /dev/mmcblk0p2 partition and how much is free
  1. Next, you are going to use the dd command, but in this instance you'll reverse directions and copy from the SD card to a base image.
  2. In the terminal window type sudo dd if="/dev/mmcblk0" of="personal_pi_image.img"
  3. OPTIONAL If you want to shrink your image, you can take a chance, modify the dd command, and copy fewer bytes from your card. The dd command looks like this: sudo dd if="/dev/mmcblk0" of="personal_pi_image.img" bs=1M count=2700
  • Note: the value for count should be the desired size in MB of your final image. That's what you found in step 2. Add some free space just in case.
Now you have a base image that's updated, configured how you like it, and ready to use. If you have other SD cards (I have one for each project I'm working on), copy that image onto them using the dd command from step 2 above.

Storing Your Cards

I hate having clutter on my desk. I have a lot of clutter, but I do hate it. I poked around for a "lifehack" for storing SD cards and didn't find anything I liked. Then I stumbled across an Altoids Smalls tin and realized it's perfect! I took some foam and lined the tin (with a piece in the middle to separate stacks), and I used snippets of an Avery shipping label to identify the card:

There are some who will point out there's a risk of static discharge because I'm using a metal container. True. Images are easily recreated and cards are cheap so I'm not all that concerned - that attitude will likely change when my first card is zapped. Meanwhile I *am* looking for a non-metal alternative, but needed something short-term to help.

Conclusion

That's about it - you now have one or more base images which you can use to tweak however you need. Enjoy!

Monday, August 25, 2014

Android Application Logs

Learned a great new trick today - using logcat to display Android log meesages to the console window remotely.

Background

Android OS has a log feature (android.util.Logging) which has various levels of verbosity. Developers can send messages to this log. The log isn't written anywhere on the device, it's stored in memory (it is also RIFE with interesting data - such as frequent NMEA GPS location strings).

View the Log over ADB

On a rooted Android, simply enter:

adb logcat >log.txt

and memory-based logs will flow to the log.txt file in your current working directory.

Saturday, August 23, 2014

Debugging GPS Units

I’m working to build a WarPi (see other blog posts on this effort). To get that project going, here’s what I did:

  1. First, I found an old Streets & Trips GPS unit – yah! No cost, baby…
  2. I proved it worked on my Mint box (see my blog post about it)
  3. Then I connected it to my PI and did the same thing – using Minicom, I proved it worked on the Pi
  4. Then I started the install steps to get the WarPi configured, including installing GPSD.

It was here that things fell apart. Once GPSD was installed, I ran the GPSD client to check that the GPS worked correctly – all I got was garbled text. Everything I read said garbled text is a symptom of baud rate connection issues, but I knew I had it right: 4800 7E1. Over and over I troubleshooted stuff. It didn’t matter what com settings I specified, I still got garbage.

Finally I ran across this article that indicates gpsd puts the GPS into binary mode—which explains the garbage!

Troubleshooting Tips: Important Commands

Kill GPSD: my Pi keeps flipping to British keyboard and I can’t find the pipe symbol ( | ), so it’s difficult to find GPSD’s PID. Here’s a tip for another way to kill the process:

  1. ps –C gpsd –fww is used to get the PID for gpsd
  2. sudo kill <PID> will kill gpsd

GPSCTL – controlling your GPS

In this article, I figured out how I got into binary mode (scroll to the bottom). It also lists how to get out of binary mode, which works intermittently for me, at best.

sudo gpsctl –f –n –s 4800 /dev/ttyUSB0 should reset the Pharos GPS-360 device to NMEA mode. But it doesn’t work for me.

GPSD Debug Mode

This article on setting up GPSD was helpful for putting GPSD output on the screen. The command

gpsd -D 5 -N -n /dev/ttyUSB0

should get you going.



Conclusion


For some reason, my GPS unit won’t honor the command to switch back to NMEA mode. All is not lost, however – if you let a GPS sit unpowered for 3 days, it reverts on its own. After waiting the 3 days I plugged my GPS unit back in and saw that it was in NMEA mode. It now has a second issue – it’s no longer communicating successfully with satellites (the “validity” bit is set to “V” which—while you’d think means ‘valid’—actually means there is a warning. The NMEA string contains bad data.


I understand these old Streets and Trips USB devices can take 30-45 min to pick up enough satellites the first time, so I’m letting it sit and burn electrons.


The ultimate goal here is to feed GPS data to Kismet, which can be done via gpsd or Kismet can read NMEA strings directly, so I think I’ll uninstall GPSD, let the GPS sit for a few days, then configure Kismet to read the NMEA string off serial. I also intend to invest in a modern USB GPS unit—I need something that’s robust, and my old device… just isn’t.

Friday, August 22, 2014

Disabling Windows User Accounts

Active Directory rocks – as long as you’re not a home user (in which case you don’t have it). Windows Premium is great too – unless you don’t have it. So what do you do if you’re running Windows 7 or Windows 8 and you want to manage (enable/disable) user accounts?

Or put another way: how do I disable user accounts in Windows 7 home or Windows 8 home? Simple – the net user command.

To disable an account:

net user John /active:no

To enable an account

net user John /active:yes

Lemme tell you, this feature works great when you have kids who aren’t doing their chores. Disable their account for a bit, it freaks them out and gets them committed!

Wednesday, August 20, 2014

Pulling data from Android

I do a lot of Android security assessment work lately, and there are a few commands I’m finding to be really helpful.

Pulling Data With Sudo

Sometimes it’s just a hassle to copy data with long paths and such. This is a creative solution when you have root:

adb shell su -c cat /data/data/app.package.name/databases/application.sqlite | sed 's/\r$//' > application.sqlite

Thanks to Sergei Shetsov for that tip (http://blog.shvetsov.com/2013/02/access-android-app-data-without-root.html)


In the same post, Sergei points out that you can do a backup over ADB and, if you don’t give it a password, you can pull data out of the backup:

adb backup -f ~/data.ab -noapk app.package.name

Then all you have to do is extract the data. Sergei points out that Nikolay Elenkov posted on the backup file format and provided a Java program to pack and unpack backup files.


Once you’ve got your backup, open it in your favorite file carver, or just do a quick dd command to extract it:

dd if=data.ab bs=1 skip=24 | openssl zlib -d | tar -xvf -

That’s all!


Need more info? Read Sergei’s blog post. I document things here so I have one-stop shopping; all the credit goes to Sergei for a great work-around.

Sunday, August 17, 2014

War Pi–Part 1 (the prep)

I’ve been planning to put one of my older Raspberry Pi devices to use as a “War Pi,” based on a SANS Reading Room whitepaper by Scott Christie titled “WAR PI”. This article is the adventure that got me to finally being ready to build the War Pi. The adventure took a few wrong turns right around the GPS area…

Gathering the Parts

There are a few items needed to make the War Pi:

  • Raspberry Pi (I have two 256 MB Pis and one 512 MB Pi – I’m starting with the latter)
  • USB 802.11 wireless device capabale of packet injection (I have an Alfa Networks AWUS036NH which I use for a variety of wireless ‘research’ projects)
  • USB GPS receiver (I mentioned in an earlier blog post that I found an old Microsoft Streets and Trips GPS unit, and got it working on Linux Mint; that’s what I’m using with my War Pi)
  • Power supply (don’t have one yet – I may have to make one today, or just pick one up at a local store)

Here they are, all ready to use:

warpi1

I had a 4 GB MicroSD card I wanted to use, but for some reason it can’t be recognized by Windows or by the Pi. I have research to do here…

Initial Boot and Config

I finally found an 8 GB card with a fresh (but outdated) Pi image. I modified a few settings in raspi-config:

  1. Medium overclock
  2. Enabled SSH server
  3. Boot direct to desktop
  4. Expanded the image to fill the card

And with that, I see a beautiful fresh desktop:

WP_20140810_002

Next, I’ll admit – I cheated a bit and used the WiFi Config rather than editing the wifi by hand. Call it lazy, or say I checked in my engineer card… Regardless, I set up my Alfa wireless device temporarily so I could update the Pi. First a quick

sudo apt-get update

and then a

sudo apt-get upgrade

brought me up-to-date. Of course, it’s always good to do this more than once, since dependencies are being updated and sometimes multiple rounds are helpful. Sure enough, round two resulted in another 205 MB of updates. Clearly I started with an old build of Raspbian. And not surprisingly, my Pi died in the midst of the second update – sometimes that happens.

I probably should have started with a latest OS image, but my luck reading and writing images to SD cards lately has been pretty bad, so I decided to just power through upgrading. As an aside, the full upgrade lasted over an hour—it pays to take this in little bites!

USB Conflicts

I ran into a very interesting issue – as I was adding peripherals to perform various tasks (like plugging in my wireless device or my GPS), I had a really tough time getting them to all work together happily. When I plugged in high-draw devices like the GPS, the Pi would reboot. Upon reboot, the mouse and keyboard wouldn’t work. I think there are a couple things at play here: insufficient power availability on the Pi (meaning I need a powered USB hub) and/or IRQ assignment conflicts.

UPDATE: using a powered 10-port USB replicator, I am not only running with all 4 peripherals (keyboard, mouse, Alpha and GPS), but I’m doing it without supplying power to the Pi. Interesting…

War Pi Setup

With the Pi updated, it’s time to install the main tools for War Pi: minicom, GPSD and Kismet.

  • The minicom tool isn’t called for in the whitepaper, but it’s a nice lightweight tool for proving a GPS is working.
  • GPSD is a tool for interacting with GPS. Kismet can read directly from most GPS units, so GPSD should just be there as backup, but sometimes GPSD can read from a GPS which Kismet cannot, and then Kismet can read from GPSD.
  • Kismet is an 802.11 wireless utility for detecting, sniffing, and interacting with wireless networks.
MiniCom

Setting up MiniCom was easy – just follow the instructions on my blog post about getting a Microsoft Streets and Trips GPS unit working in linux. I was able to use MiniCom to show my GPS was working – important, because I had a lot of trouble in the next step (GPSD).

GPSD

So now that the Pi is updated and running reliably, it’s time to move ahead with the WarPi instructions – next step is setting up GPSD. This was relatively easy, although something happened the first time I ran apt-get install gpsd, so when I tried the sudo dpkg-reconfigure gpsd, it failed to launch. Rerunning apt-get install gpsd fixed it.

Once GPSD was installed and configured as per the instructions, I rebooted and started the CGPS client. Interestingly enough, the GPS just started sending garbage. CGPS kept showing the GPS couldn’t connect. When I disabled GPSD and rebooted, I booted minicom and it showed nothing but garbled text. After an hour of troubleshooting (including connecting it to my linux box where it worked perfectly), still no joy. I gave up for the night.

UPDATE: in reading around, I discovered these SirF GPS receivers are quite touchy. I’m working on another blog post about them, but basically if you use a SiRF receiver with GPSD, GPSD puts it into binary mode simply because the way it determines whether or not the GPS is a SiRF device is by sending a –b command. Heisenberg in action…

By waiting 3 days, the GPS resets itself back to NMEA mode (which I’ve confirmed in minicom). Now I’m having trouble because the “Validity” bit (sixth bit in the NMEA string) is showing “V”. You’d think that means “Valid” but it actually means “WARNING”. I’ve heard these old Streets and Trips GPS units can require quite some time before picking up satellites, so I’m going to let it sit for a couple hours and see what happens.

New GPS, New Hope

Like the Jedi rising from the ashes, my new GlobalSat USB BU-353S4 worked perfectly out of the box when connected to minicom on my Linux box. I’m going to start up a new step-by-step in another blog entry, to cover the actual build process.

Lots was learned about serial communications, SiRF, and GPS. But now it’s time to go war Pi’ing.

Friday, July 25, 2014

Secure Delete on Linux

Let's face it - we do a lot that involves sensitive information. On Windows, I've installed the SDelete command from SysInternals (thank you, Microsoft, for buying them and NOT cancelling their work!). On Ubuntu, it's just as easy...

To install the secure delete tools:
user@machine:~$ sudo apt-get install secure-delete

To delete a file, just use the "srm" command:
user@machine:~$ srm filename

The more ya know...

Thursday, June 12, 2014

Microsoft Streets and Trips GPS Running on Linux Mint

I have an old Streets and Trips GPS unit - this old guy, from way back when:


Pharos light and
I have an old Dell laptop running Linux Mint. I've been wanting to build the War Pi described in this SANS Reading Room article:
http://www.sans.org/reading-room/whitepapers/incident/war-pi-34435

But I wasn't sure if I could, because I don't have an external GPS. Well, I was rooting through my junk box and found the old S&T GPS and wondered if maybe I could make it work. Sure enough:
Terminal Serial Output



I whited out the GPS strings - don't want anyone to have it easy finding my house and stopping by for autographs.

How did I do it? Dirt simple, folks:
  1. Plug in the USB GPS unit
  2. Open a terminal window and type "dmesg"
  3. Look for the serial GPS unit appearing:
    [ 1317.276429] usb 6-1: new full-speed USB device number 2 using uhci_hcd
    [ 1317.435627] usb 6-1: New USB device found, idVendor=067b, idProduct=aaa0
    [ 1317.435641] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 1317.435649] usb 6-1: Product: USB-Serial Controller
    [ 1317.435656] usb 6-1: Manufacturer: Prolific Technology Inc.
    [ 1317.435663] usb 6-1: SerialNumber: 12345678
    [ 1317.475503] usbcore: registered new interface driver usbserial
    [ 1317.475534] usbcore: registered new interface driver usbserial_generic
    [ 1317.475554] usbserial: USB Serial support registered for generic
    [ 1317.480504] usbcore: registered new interface driver pl2303
    [ 1317.480533] usbserial: USB Serial support registered for pl2303
    [ 1317.480578] pl2303 6-1:1.0: pl2303 converter detected
    [ 1317.493517] usb 6-1: pl2303 converter now attached to ttyUSB0
  4. See at the bottom, it says "ttyUSB0"? That's where the device is...
  5. If it's not installed, install minicom:
    sudo apt-get install minicom
  6. Run minicom as sudo in settings mode (sudo minicom -s)
  7. Select "Serial port setup"
  8. Set serial device to /dev/ttyUSB0 (or wherever your device showed up in dmesg)
  9. Set Bps/Par/Bits. This one is a bit obtuse - the lowest screen setting is 9600, which results in garbage streaming in. But if you press B for "<prev>", you can set the speed to 4800.
  10. Set stopbits to "7-E-1"
  11. Exit back to the minicom screen and choose "Save setup as dfl" then choose "Exit"
Bazinga - you should see serial GPS strings scrolling across the terminal window.
By the way: great article here about using the Microsoft Streets & Trips GPS unit on a Raspberry Pi.

Friday, May 23, 2014

Mak5 WifiPineapple - the basics

I've been breaking out my Hak5 Wifi Pineapple of late, and figured since I'm messing around in it, I ought to share what I've learned.

First Steps - Setting Up

The first thing I did with my Pineapple was get an open wireless LAN going. Something kinda sticky, honeypot-like... First, I logged into my Pineapple (follow the included directions to get that far), by connecting to it with my Air over wifi. This is the homescreen:


Next, I went into the "Network" bar and moved to the "Access Point" tab and gave my WLAN a better name:

Think anyone will nibble?

Network Access

A Wifi Pineapple is more fun when it is connected to the webz and can proxy unsuspecti--er, generous volunteers. So next, I connected my Pineapple to my internal network:


OK this is awesome, because now I'm proxying my communications through my WLAN to the Internet. 

Shall We Play A Game?

NOTE: there are legal ramifications to interrupting folks' wireless connectivity. I do this only when 1) I'm at home, connected to my own WLAN, and testing or 2) when clients pay me to do a wireless assessment AND I HAVE A SIGNED DOCUMENT STATING I AM AUTHORIZED.

The Pineapple is, simply put, an awesome and powerful wireless network assessment tool. What you can do is almost unlimited. For this test, though, I'm going to use the "Karma" infusion to capture open networks. Karma is basically a tool which will mimic an open network--it's a very promiscuous access point. The background on Karma is that it's a simple tool to attack any wifi-capable device.

Karma takes advantage of the completely backwards concept that your computer continuously searches for networks its previously connected to. Instead of the Starbucks wireless AP calling out "Hey I'm Starbucks - anyone wanna connect?," your device (laptop, tablet, etc.) calls out "Is anyone here the Starbucks AP?" and connecting when someone answers yes. These are called "probe requests" and they're one of a couple really stupid implementation fails on wireless. Karma... Well, Karma responds "Yes" to every request. Every request...

Want to understand how "probe requests" work? Try these sources:
  • https://scotthelme.co.uk/wifi-pineapple-karma-dnsspoof/
  • https://www.youtube.com/watch?v=avJfT9JyiiM

So 30 seconds into running Karma, here's what I have:


Somewhere within reach of my Pineapple (running the long gain antenna), devices are looking for 5 different networks. Ten minutes later, this count jumped to 12 different networks. Eventually, I even captured an association (meaning a device which had formerly connected to an open network and which was happen to get another open connection to the same network - served up by me).

Things to Know

A few things to keep in mind:
  1. Most of the tutorials say it's easier to tether over a network cable. None of my current laptops have network cables, but I'm able to tether just fine over WiFi. Don't be afraid to do it that way.
  2. USB... To do any serious logging, you need to have a USB drive connected. I do not, yet, so that'll probably be the next blog.
Happy Pineapples!


Monday, April 7, 2014

Mounting a USB Device in a Linux VM

I recently did some work for a customer. Part of the project included a security analysis of a Linux-based VM client. The client is configured to VPN into the customer’s data center, so there’s really no way to network into or out of it (not easily). My challenge was pulling a few files off the client. Solution? Not all that difficult, actually:

  1. Plug a USB device into the host machine
  2. In VMWare, connect to the USB device
  3. In linux, you need to create a mount point for the USB device, and then mount it
  4. From there, it’s a simple copy command.

mkdir –p /mnt/myusb

mount –t vfat –o rw,users /dev/sdb1 /mnt/myusb

Oops another challenge:

  • How do U know where the USB device ends up? I scratched my head for a while on that, until my buddy recommended I grep the logs.

Solution: I searched the logs for SCSI connections, by entering grep SCSI /var/log/messages and saw where the USB device had been attached.

Finally, it was a simple matter of copying the file, which was of course cp /root/myfile.txt /mnt/myusb and I was rocking!

Wednesday, March 12, 2014

Virtual Private Cloud

For a while now, I’ve been wanting to leverage a cloud service to host a scanning tool I’m working with. Given that the scan results are sensitive, I don’t really want to have the scanner publicly available. So it’s always struck me that a virtual private cloud with point-to-site VPN is the solution. Straightforward, right?

Well, no…

image

AWS doesn’t support it. I suppose I could configure something with an additional VPN server that straddles the Interwebz and the VPC but seriously? One more machine, more config, more support… blech.

 

image

Enter Azure – turns out, they support point-to-site VPN connections. It made my VPC hosting decision pretty easy.

Caveat: I didn’t look into Rackspace or the myriad of other “me-too’s!” out there. Just AWS and Azure.

You can read up on point-to-site VPNs here: http://msdn.microsoft.com/library/windowsazure/dn133792.aspx Keep in mind, this feature is currently (as of 2/2014) in CTP mode so it’s not exactly production ready. But since my site is small and won’t have a ton of traffic, I’m OK taking some chances on availability.

So finally the project kicks off today – ironically, creating the Azure VPC is quick but creating just the simple gateway? Not so much… Azure’s been churning away for 20 minutes already and still the gateway hasn’t completed. I guess I’ll capture the next step in another post.