Thursday, September 11, 2014

Hardware Hacking: I2C Injection with the Bus Pirate

Hardware Hacking

Embedded hardware hacking seems to be all the rage these days so I thought I would poke around at a few concepts and see what's doing with embedded hardware. I decided to set up a simple experiment to test some concepts that I think will be helpful to understand in the future when analyzing embedded systems, namely sniffing traffic and message injection.

The Experiment

I decided to create a simple lab involving an Arduino Uno, in this case a SparkFun RedBoard, and a BlinkM LED that can be controlled over I2C. The Arduino would have a simple sketch that will update the color of the BlinkM and using a Bus Pirate I would then sniff traffic that is occurring between the BlinkM and the Arduino. I would also like to study the process involved in using the Bus Pirate to inject messages to take control of the BlinkM and have it change to a different color. I'm not blowing anyone's skirt up with this, but I gotta start out somewhere.


The protocol used in this experiment is I2C. It is a simple two wire interface (TWI) that supports multiple masters and multiple slaves all sharing a serial bus. Aside from a power and ground I2C uses two lines to perform data transfer. The first is the Serial Data Line (SDA) and the second is the Serial Clock Line (SCL). Grossly, to the point of being misleading, simplified, each bit of data is transferred by reading if SDA is pulled high or low when SCL rises. Helpful resources to lean more about I2C can be found here and here. The main points to take away with respect to how components communicate with each other however is that each component has a read address and a write address. Before one component can talk to another, it will write the destination address (be it a read or write address) on the SDA line and then the rest of the data.

Assembling The Circuit

Creating the circuit was a fairly simple exercise. It's not difficult, it just requires some upfront investment in purchasing hardware. It's a far cry from just spinning up a new VM if software hacking is what you're used to. 

First, I plugged in the BlinkM into a breadboard.

I then connected Male to Male (M-M) jumper cables from the ground pin (PWR -) to the GND pin on the RedBoard, the power pin (PWR +) to the 5V header on the RedBoard, the data pin (I2C d) to the A4 header on the RedBoard, and the clock pin (I2C c) to the A5 header on the RedBoard.

With the circuit connected we can now focus on programming controlling the BlinkM with the RedBoard.

Programming the Circuit

Once you give power to the Arduino, you'll probably see the BlinkM light up right away. And if you're like me you'll immediately try to program it and see that it has no effect on the BlinkM and wonder why it's not working. Well, the BlinkM comes out of the box pre-programmed to run a demo script. In order to cease running the script you'll have to send it the Stop Script command documented in the manual for the BlinkM. The easiest way to do that is to load some example code that the makers of the BlinkM provide found here. The BlinkMTester sketch will give you the ability to run some basic commands to control the BlinkM and stopping the script is one option.

With that out of the way we can now program the BlinkM. For my little example I wanted to have the BlinkM change from red to green back and forth at 3 second intervals. 

With the sketch uploaded we can see the Arduino and BlinkM go into action.

The Bus Pirate

Now that we have a functioning circuit that can serve as a test bed, we can use the Bus Pirate to sniff traffic on it. The Bus Pirate is a neat little tool that can serve many different functions. It can sniff traffic over a variety of protocols such as UART, SPI, and I2C and it can also inject traffic as well. 

In order to have the Bus Pirate be able to sniff traffic on our little circuit we need to insert a couple more Male to Male wires on the SDA and SCL lines. We will then connect the MOSI Bus Pirate probe to the BlinkM's SDA line and the CLK Bus Pirate probe to the BlinkM's SCL line. Be wary of where you purchased your Bus Pirate probes because the colors will be completely off if you bought it from SeeedStudio/Adafruit vs Sparkfun. 

Sniffing I2C Traffic

Now, once you've connected to your Bus Pirate using Putty or some other serial terminal you can start sniffing the traffic being passed from the RedBoard to the BlinkM. To do this we will change the Mode of the Bus Pirate so that it is in I2C mode and then drop the Bus Pirate into sniffing mode.

From the screenshot we can see the I2C messages being sent. Each message starts with a [ character and then shows the hexadecimal value of each byte being sent, followed by a + for an ACK or a - for a NACK and is then followed by the end of the message which is the ] character. In this instance the first message sniffed corresponds to the portion of the sketch which is commanding the BlinkM to turn red. 0x12 is the write address of the BlinkM (I know we set the address to be 0x09 in the sketch, but that translates to a 0x12 write address) followed by the hexadecimal ASCII value for the h character (0x68) then followed by the 3 bytes for the hue (0x00), saturation (0x10), and brightness (0x01). Then it's followed by another message that changes the color to blue and then back to red over and over.

This let's us know that we are reading the right messages and validates the data that we think we are sending with the RedBoard. Now for the more interesting part, how to take control of the BlinkM with the Bus Pirate.

Injecting I2C Traffic

Controlling the BlinkM with the Bus Pirate will require us to mimic the message structure but using Bus Pirate syntax. In this case we need to write to the address 0x12 and send the following bytes:
  1. 0x68 - This is the h character which tells the BlinkM to fade to another color using the next 3 bytes as the HSB values
  2. 0xAA - This is the color blue
  3. 0x10 - This is the saturation value
  4. 0x01 - This is the brightness value
To send a message with this kind of structure we will type into the I2C prompt of the Bus Pirate this command:

Once you inject the command the feedback from the Bus Pirate should indicate that it received ACKs for each byte you injected.

If all goes well you should see the BlinkM turn blue when you inject the message; something that should never occur if the RedBoard is the only master on the I2C bus. Note that the color won't stay blue forever as the RedBoard will continue to send messages to change the color of the BlinkM red and green.

Success! Exciting right? Hello? <tap> <tap> Is this thing on? <tap> <tap> 

Tuesday, March 4, 2014

Tamper With Parameters In Iambic Pentameter: Hacking GoatDroid With Burp Suite in MobiSec

Today we will be looking at tampering with parameters using a proxy. This is a fairly common thing to do in web application assessments and most mobile application testing is an extension of that so we'll examine how to proxy DroidGoat's traffic through Burp.

Updating Burp Suite in MobiSec

MobiSec, unfortunately, does not come with the most up-to-date version of Burp Suite, 1.4. Currently 1.5 is offered so we'll just update to that. First we go to and download it to /opt/mobisec/pentest/burp and then we will edit the script that launches Burp which is located in /opt/mobisec/ and update the call to the jar. 

Sure, we could just run the updated Burp Suite jar manually, but now when we run Burp Suite from the menu it'll run our updated version.

Proxy Our Android Traffic

Next, we'll configure our Android Virtual Device (AVD) so that it'll pass traffic through Burp Suite. GoatDroid gives up the ability to configure a proxy through the application itself, but we'll do it this way because it's a more generic approach that will allow us to proxy traffic when we're testing any other application. We'll crack open the script that is responsible for launching AVDs through the menu just to see how they do it, /opt/mobisec/, and we'll add the necessary argument, -http-proxy, to proxy traffic and then save it to another script, say

Burp Suite's proxy runs on port 8080 by default. If you change the port it runs on, then don't forget to update your script too!

Tying It All Together

Now, we'll run Burp Suite, run GoatDroid, then our AVD, and start looking at the traffic passed through. Poking around the FourGoats application, using goatdroid/goatdroid as our credentials we see that there is a section titled Rewards. Note:  If Burp Suite is set to intercept traffic, it you will have to forward each and every request your app makes. You can go ahead and disable it for now by going to the Proxy tab and then the Intercept sub-tab and clicking the Intercept button so it reads, Intercept is off.

Within Rewards there is a tab to view My Rewards, which we don't have any...yet, and another tab to view Available Rewards. In order to unlock these achievements we'll have to checkin with the specified lat/long the requisite number of times. 

So, let's see what traffic is involved with performing a check in. Go back to the initial screen and drill into the Checkins screen. You get an indication that your device does not have a GPS location and this might be an issue. If you go ahead and click on the Check In Now button you'll be greeted with an error message. Well bugger...

Fortunately there are two ways around this. Your machine that is running the AVD will have port 5554 open on localhost. From there you can set your coordinates with this command, geo fix <long> <lat>:

Great! This should give us the lat/long so we can forge one checkin for the Steak Master Bonus! Let's go back to the Checkin screen...

Rawr! There appears to be some precision errors doing it this way. Well, there is another method of setting the lat/long on the device and that is to use the Android Debug Monitor (ADM). ADM is a useful utility, that you can launch from MobiSec by running the monitor command. ADM will then launch and give you a great deal of insight on your AVD. Things such as the filesystem, network usage, CPU usage, memory allocations, etc are exposed. We will use ADM more in future posts. In the Emulator tab, you can also set the lat/long as well. Let's attempt to set it to the coordinates that match the One Free NY Mets Ticket achievement and hit send.

Unfortunately we run into the same kinds of precision errors so this is out as well.

Parameter Tampering

In lieu of setting the coordinates through the device, another option we have is to trap the network traffic the app is having with the web service and tamper with the parameters to fool the service. If Burp Suite is not set to intercept traffic, go ahead and enable it by going to the Proxy tab and then the Intercept sub-tab and ensure that Intercept is On. Let's go ahead and click on the Check In Now button to see what we have. 

Here, we see that by clicking on the Check In Now button, we send a POST request to /fourgoats/api/v1/checkin, along with the parameters latitude=40.7548083333333334&longitude=-73.84512. This should be fairly straightforward now. We can either modify the parameters in the Raw tab or switch over to the Params tab and do it there. It can be cleaner to do it in the Params tab so we'll do that in this instance. 

Now, we have our POST request with our tampered parameters. It's good to go so we'll send it on it's way and click on Forward to send it to the web service. Going back to the app we see our first sign of success.

The tampered POST request was accepted and FourGoats thinks we checked into the Peter Luger Steakhouse. Now, we just have to do this 11 more times to unlock the reward. Normally, you'd repeat the last few steps 11 more times, but Burp Suite can speed this portion up considerably. Click on the History sub-tab of the Proxy tab and identify the POST request that was responsible for sending the forged lat/long. 

If you look at the Modified column, Burp Suite helpfully identifies items that you tampered with. This may help highlight the POST of interest. Right click on that item and select Send to Repeater.

Repeater is another tab in Burp Suite that will allow you to quickly and easily repeat POSTs or GETs. Click on the Repeater tab at the top and you should see the POST call you selected in the History sub-tab. 

If you wanted to change any parameters, you could do that here similar to how you did it in the Proxy tab, but that's not necessary this time so we can just hit the Go button 11 more times. Let's go see our rewards to see if our trick worked. 

Success! Let's go back to Repeater and punch in the other lat/longs and repeat the POST enough times to fulfill the other rewards. 

Awesome! Now where do I go to collect my cash and prizes? =P

Friday, February 28, 2014

Intro to Mobile Application Security Testing: How to install GoatDroid in MobiSec


I've started to investigate mobile application security and one of the tools that seems to be useful is MobiSec. MobiSec, like Kali or SamuraiWTF, is a Linux distro that has many tools that are geared towards the mobile application security arena.


Like many of the other Goat applications OWASP has, GoatDroid is intended to be an application that is riddled with vulnerabilities for people to find. You can find out more about the GoatDroid app here.
MobiSec does come with another sample app by SecurityCompass. You can find out more about the SecurityCompass lab here.

Setting MobiSec Up

Ok, first thing's first. We install MobiSec as a virtual machine and click through. Once that's over with, we login with mobisec/mobisec. Next thing we'll do is disable the firewall. This is normally a horrible decision to make, but in the interest of being able to focus on the task of assessing mobile applications we'll disable iptables so it isn't a distraction. You are running MobiSec behind a NAT and 7 proxies aren't you?

To disable the firewall, we'll go to System -> Administration -> Firewall configuration

You'll be asked to provide the root password, which is mobisec, and then you'll uncheck the Enabled box. 

Something else I did was update and upgrade the software packages by running a sudo apt-get update && sudo apt-get upgrade.

The next thing I did was update the Android SDK. Going to Applications -> MobiSec -> Development Tools -> Development Environments -> Android SDK Manager will open the Android SDK Manager so you can see what SDK and tools are installed. 

MobiSec 1.1 came with Android SDK Tools version 17 and Android SDK Platform Tools 11 while versions 20 and 12 were available. Go ahead and click on Install 2 packages to download the updates. You'll be greeted with a dialog to accept the user agreements for each update or you can select to accept all. 

Once you finish this, a dialog will pop up that tells you to close the manager and re-run it. Do this because new updates are available. I'm not sure why it can't just update everything to the most current version in the first go around. However, you might run into an issue if you blanket accept all of the updates. I had to uncheck the option to download anything in API 19 because I got an issue like this if I tried to:
I just updating everything else and then re-ran the manager a third and fourth time and accepted all of the available updates and it ran just fine. Is any of this mandatory? Probably not, but I just prefer to update whenever possible.

Setting Up GoatDroid

Next we'll wget the pre-packaged GoatDroid project by running this command from a terminal, wget
Then we'll unzip it with by running, unzip 
Inside the OWASP-GoatDroid-0.9 directory there should be a goatdroid-0.9.jar. Run this jar by typing, java -jar goatdroid-0.9.jar
You should see the GoatDroid application appear.

First thing to do is to configure GoatDroid. Open the configuration screen by going to Configure -> Edit Configuration. 
You will want to set the Virtual Devices Path to point to a specific device that is located in ~/.android/avd. I chose the Android_4.0.3.avd in this example. You will also want to point the SDK Path to /opt/mobisec/devtools/android-sdk. If you left the firewall enabled, you'd have to look at the Web Services tab and make the appropriate adjustments to allow connections. Otherwise just hit Update Settings.

We'll try running the FourGoats application first. Select it from the list on the left

Start the Android 4.0.3 emulator by going to Applications -> MobiSec -> Development Tools -> Emulators & Simulators -> Android 4.0.3 Emulator.

It may take a while for the emulator to boot up depending on how fast your computer is. Eventually though you should see a screen like this:

Now we'll install the GoatDroid application to your device. From the GoatDroid application, click on the Push App To Device button. You'll see a dialog saying that it is pushing the application to the device. After a little bit you should get another dialog saying that it has successfully installed the application. Go ahead and click on the Start Web Service button as well.

Look at the apps installed by clicking the top right hand corner with the 6 squares. You should now see the Four Goats app listed.

Go ahead and click on the GoatDroid application. It should take you to a login screen. First we'll need to configure the connection settings. Click the 3 little squares in the upper right hand side and click Destination Info. Next set the Host to be MobiSec's IP address and set the HTTPS port to be 9888. Hit Save and you should be taken back to the login screen.

 Use goatdroid/goatdroid to login.

And now you should be in. Test away!

This procedure is essentially the same for installing/setting up the Herd Financial app too.

So What?

This is enough to get you started, but we haven't really done anything yet in the way of assessing GoatDroid. I'll be posting how-to's as I chug along and figure this stuff out. Better hope I'm smrat enough!

Friday, February 14, 2014

How to Setup WordPress to Hack Plugins

I'm using this post to document how to install WordPress 3.8.1 on Debian 7 for the purposes of testing plugins. I'm looking on how to do more vulnerability research and WP plugins seems as good of a place as any to start poking around. It's also a good exercise in creating a LAMP stack, albeit probably not the most ideal one.

I'll skim over the part about installing Debian 7 as a virtual machine since that's mostly click through and skip to the part once you first log in.

Updating Debian and Updating the Sudoers File

Once you login the first thing you should probably do is update and upgrade everything. To do that you would normally open up a terminal and type: sudo apt-get update && sudo apt-get dist-upgrade -y
However, the user you logged in as is probably not in the sudoers file so you'll get hit with a message like this:
So before we can actually run our update and upgrade let's add user to the sudoers file. First we'll swtich user by typing the command, su. Then we'll execute the visudo command and add the user account to the sudoers file.
That should open up the sudoers file using the nano editor. Add this line, user ALL=(ALL:ALL) ALL, to the file. I inserted this line after the entry for root and then save and exit. You'll get asked what to save it as. Just save it as /etc/sudoers
Now, let's exit out of our root shell and go back to the user account. Next, we'll update the file, /etc/apt/sources.list so that it'll update itself from the most update repository of software. I had to do this extra step because I didn't choose to update Debian from the network during my install. Edit the /etc/apt/sources.list file and if you have an uncommented line starting with, deb cdrom..., comment it out and add this line, deb stable main. Your sources.list file should look like this.

Then we'll attempt to re-run our update command again.

This may or may not take some time to complete while it updates all of the software on your machine depending on if updated software was installed when you installed Debian.

Installing Our LAMP Stack

Next, let's install the necessary software to support WordPress. If you Google how to install WordPress on Debian you'll probably get 10 different results on how many packages you'll have to install. This is what I used and what worked for me. You may have to install additional packages depending on your situation. I ran this command: sudo apt-get install apache2 mysql-server mysql-client php5 php5-mysql. You should get a list of packages that will get installed:

Once the install kicks off, you'll get asked for a password for the MySQL root:

Configure MySQL

Next we'll configure MySQL. Enter into a MySQL prompt by typing, mysql -u root -p. You'll get prompted for a password.

Then we'll create a database for WordPress to use by typing, create database wordpress;

Next we'll create a user named wpuser with a password of wordpress123 for WordPress to use by typing, grant all on wordpress.* to wpuser@localhost identified by 'wordpress123';

Lastly, we'll push our configuration changes by typing, flush privileges;

Another thing you'll want to do is enable logging for MySQL. This way you can see what kind of queries are being generated. This will be helpful in understanding how to abuse SQL queries if you are trying to perform SQL injections. Open the MySQL configuration file with your editor of choice like this, sudo vim /etc/mysql/my.cnf. Then, uncomment these two lines:
#general_log_file = /var/log/mysql/mysql.log
# general_log = 1

It should look like this:

Then restart MySQL by typing, sudo service mysql restart

For future reference, when you go to pentest a plugin, you can tail the log by typing, sudo tail -f /var/log/mysql/mysql.log. You'll then see all the queries that the plugin is making. It should look similar to this:

Install FTP

Installing an FTP server is also handy because WordPress can automatically install and delete plugins for you. To do this, we'll run the command, sudo apt-get install proftpd, to install the FTP server. During the installation, you will be asked if you want to run proftpd from inetd or standalone. Choose standalone. 

To see if proftpd is running fine we'll run, sudo service proftpd status, and it should report that it is.

Installing WordPress

Now let's download and install WordPress. The most up to date version is currently 3.8.1. You can always get the most up to date version at http:/// To download it we'll run, wget http:///

Once we unzip the file by typing, unzip, we should have a directory named, wordpress. Now we will create the sub-directory that we want our test blog to reside in. I'm going to name it blog so I'll first create the necessary directory by typing, sudo mkdir /var/www/blog, and then cp -R wordpress/* /var/www/blog

Let's update the permissions of the /var/www so that the apache user, www-data, will be able to update files as necessary by typing, sudo chown -R www-data:www-data /var/www

Change directory into /var/www/blog and create a wp-config.php file by copying the sample one provided by typing, cd /var/www/blog, then, sudo cp wp-config-sample.php wp-config.php

Next open up wp-config.php with your editor of choice and we'll update some values. Since we are interested in just doing vulnerability assessments and not hardening this install of WordPress we'll make some compromises in the interest of convenience in order to speed up the installation and testing of plugins. I would not advise doing this on an install that you actually care about. Taking snapshots of your virtual machine early and often is recommended. 
First, we will make it so that the admin panel is remote accessible by setting these properties. In my case, the IP of the virtual machine is and the url to the WordPress installation is /blog
define('WP_HOME', '');
define('WP_SITEURL', '');

Then, we'll disable the automatic updating feature in WordPress. WordPress will update plugins for you if it detects there is a new one available. This is normally nice, but if you're trying to install vulnerable plugins you found on exploitdb then you probably don't want this. The first property should be good enough to disable all updating that takes place, but I threw in the second property if you just want to disable the updating of plugins. 
define('auto_update_plugin', false);

Finally, we will set the properties that WordPress needs to connect to the MySQL database you created earlier and the user you created. 
define('DB_NAME', 'wordpress');
define('DB_USER', 'wpuser');
define('DB_PASSWORD', 'wordpress123');
define('DB_HOST', 'localhost');

All in all, the properties you set should look like this:

Now we'll open up a web browser and point it to the WordPress install script to set up our blog. Navigate to, You should be presented with a welcome screen. If not, go back and recheck the properties you set in wp-config.php. You most likely messed up the database properties. 

Go ahead and fill in whatever values you'd like for the Site Title, Username, Password, and E-mail (it doesn't have to be valid). Once you're done hit the Install WordPress button and then login.

Installing Plugins Manually

We will start out with manually installing a vulnerable plugin found here, as an example. (Disclaimer: I chose this vulnerable plugin at random. I have no connection to the author of the exploit.) Download the vulnerable plugin and then click on Plugins, then Add New. From the Install Plugins screen, there should be a link that you can click on to upload a plugin in .zip format. 

In the next webpage, click on the Choose File button, select the file you just downloaded, and click the Install Now button. 

You'll be forwarded to another webpage indicating that the plugin has been uploaded, unpacked, and installed. Finally you'll want to activate the plugin by clicking the Activate Plugin link. 

Now, you'll be forwarded to the main Plugins page and you'll see that the vulnerable plugin is listed along with the Akismet and Hello Dolly plugins that came pre-installed. You should also see a ThinkIT Contact entry on the left hand side toolbar.

Replicating the Vulnerability

Excellent, now we can try to trigger the XSS vulnerability. From the description we know that we can trigger a XSS attack from this URL, wp-admin/admin.php?toitcf_current_id=[XSS]&page=toitcf. First we'll need to create a form so first, click on the ThinkIT Contact entry on the toolbar and then click on Create New Form. 

A default form will then appear. We don't care what entries these hold so we'll leave them as is and then go to the bottom and click the Save button. 

Once you hit Save, you'll be sent to the default page for the ThinkIT Contact plugin. You should now see an entry for the form you created. If you hover over the Edit link, you should notice that the link has the same format of the URL described in the exploitdb entry, Click the Edit link. 

The vulnerability description makes it sound like whatever value we pass in for toitcf_current_id parameter will get reflected. Let's try setting toitcf_current_id to have the value, 'hacked'. We should expect to see the word hacked somewhere in the webpage or perhaps in the source. Once you set toitcf_current_id to hacked in the URL load the webpage. By navigating to we were able to get the word hacked on the webpage.

The only thing left to do is to set toitcf_current_id to be some JavaScript and see if it will be executed. Navigate to<script>alert(1)</script>&page=toitcf and if all goes as planned you'll see a dialog popup with the text, 1.

And there you have it! You have been able to replicate the vulnerability described in the exploitdb entry. 

Now What...

Now you can feel free to manually install other vulnerable WordPress plugins to replicate the exploit or go through the Plugins -> Add New menu to install new plugins and do your own assessments of them to find your own vulnerabilities.

Edit: 2/16/2014 - Made updates to explain how to enable MySQL logging