Beer fridge on the go

It's been a little while since my last post about the beer fridge so let's get you up to date. Since my last post:
1. My company has sponsored the fridge (so they'll pay for all the parts :-) )
2. We spent a Saturday getting to work on it.
3. It's not finished yet
4. I'm having issues with the MOSFEST/solenoid part

The basic design is as follows:
 A fridge will be locked from the inside by a set of solenoids acting as bar locks. The solenoids and the corresponding LEDs are controlled by an Arduino. The Arduino takes commands from a Raspberry Pi over serial and the Pi will have network connectivity.

 If you want to open the fridge, complete the fiendish hacking challenges on the Pi. Each challenge will control 1 or more solenoid. Unlocking the solenoid will only keep it unlocked for 30 seconds.

On the front of the fridge is a little black box. This has a set of red and green LEDs that will change whenever a lock is opened. There will also be (very importantly), a key lock that will bypass all challenges and power all the solenoids. This is because if (when) the pi or Adruino crashes, I still have a way to open the fridge. Otherwise it would be a matter of crowbar and damage.

fridge with the override lock

The next steps will be getting it in a working state. Currently there is only 1 solenoid (they are an absolute pain to mount correctly given the fridge's build and the small range of motion of the solenoid).

 I was thinking of having a Python script that sent the command over serial. The problems are that the exact serial port can change and also that writing to the serial port requires root permissions. I need to create a user to do this then Suid the python file (possible?).

 Finally it will be a matter of mounting it on the door. I'm a little worried that the condensation inside the fridge will screw with the electronics. Time will tell

SQLite injection - beyond SELECT

I work a lot with mobile and that means whenever I see SQLinjection vulns, chances are that they're in SQLite. This is a massive pain because:
a) no-one really writes guides/tools for SQLite injection
b) It's really limited (as we'll see)

Unfortunately this post is about what is not possible in SQLite injection. Hopefully it will give you a guide to where to focus attacks/defence.

SQL injection as my previous post mentioned is a subset of regular SQL. There's no command execution, file reading/writing or anything particularly cool. You can't even stack queries unless the developer is using less orthodox functions (like rawquery). In essence it normally boils down to information disclosure (i.e. reading from tables that you shouldn't).

Select Statements in Mobile SQLite

With Android you (as the attacker) will hopefully be able to inject on 'projection' variable, that is the part that goes in the "SELECT ____ FROM". This obviously allows you to redirect the statement to go to anywhere else. The ideal test is to try projection=" * FROM SQLITE_MASTER; -- ". If you can get to the master table, you can get anywhere else (unless the programmer has some custom code ready to black list you out of having fun).
Failing this you could try on the 'selection' variable and try a union statement. (see my previous post for more details

This week has been spent looking at the other commands (insert,update,delete). The goal for the attacker is to change values in other tables in the .db file. The big issue here is the table to be queried is selected before your variables get included.

Inject into INSERT statements

insert into TABLENAME(field1,field2) values (val1,val2)
 
Here you can maybe control field1 & 2 and val1 & 2. The problem is that you can't jump tables. SQLite doesn't permit UNIONs or JOINs in anything other than select statements. You can use CASE to hide SELECT statments in the middle of this but that doesn't get you much in the way of altering data powers. You also can't use table.field in the query. Essentially you are stuck altering the data within that table.

It is therefore possible for SQL injection through inference of values being changed with CASE statements to read data from a table, but it's not possible to jump to and attack other tables.

 Inject into UPDATE or DELETE statements

UPDATE table SET (val1 = val2) WHERE condition
DELETE FROM table WHERE condition

Similarly the update query permits field names (val1), updated values (val2) and where clauses (condition), but no changing of the table name. The delete function is similarly limited.

I'm scratching my head finding a more useful attack vector that somehow nests more useful things inside statements. All comments are welcome. In the meantime, this should make for some useful reading: http://www.sqlite.org/syntaxdiagrams.html

Hacking Android dynamic Broadcast Receivers

An interesting point was raised this week when the subject of attacking IPC endpoints in Android applications was being discussed.
Attacking Endpoints is a method by which a malicious application on an Android device can communicate with, and misuse functions of other applications installed on the device. This can lead to anything from information disclosure to code execution.

To find these end points it's normally a matter of checking the application's manifest file (which can be recovered from the apk)

adb shell "pm list packages"
adb shell "pm path com.example.apptotest"
adb pull /data/app/com.example.apptotest-1.apk
aapt d xmltree com.example.apptotest-1.apk AndroidManifest.xml

This process (which can be sped up with mercury), gives you a whole list of text which allows you to identify which of these end points are exported either on purpose or otherwise, and which have permissions.

This gives us a list of things to look at in code, but I believe we are missing a step here. This assumes that these are the only end points we can talk to. Obviously some require permissions that we as a malicious app might have ourselves by just asking the user for it, but for this instance the malware will have zero permissions.

It is possible to register a broadcast receiver dynamically, typically by doing the following:
registerReceiver(BroadcastReceiver myreceiver, new IntentFilter("android.some.THING"))

This is fine, and often required to listen out for an event on a device. There are 2 things that can go badly wrong here though. First if the broadcast filter is listening for an intent that isn't a restricted broadcast then the malicious app can start sending them without needing any permissions. Secondly if the receiver goes on to use the extras sent with the broadcast, or to start running other functions, then the malware has a whole new entry point to your application. Of course it would require the malware to send the broadcast at the right moment, but hell just have it send the broadcast every second and run all the time.

To protect your broadcast, you need to register permissions when you declare it (details here), secondly don't trust the data that is being sent with it. It's passing through a trust zone to arrive in your app, so validate it! Details on Android permissions can be found here.

What is Android application licensing?

I ran into this permission this morning:

com.android.vending.CHECK_LICENSE

What it means is that the app will check with Google play (aka android marketplace) that the app was bought by the user that is now running it. The application holds the public key and uses this to check the "check_license" response from Google.

Is it possible to mess with this process? Well it would depend on where the public key is stored and how Google implements the process (including obviously security of transmission).

One thing that immediately stands out is this following piece of advice from Android themselves:

A typical implementation would extract some or all fields from the license response and store the data locally to a persistent store, such as through SharedPreferences storage, to ensure that the data is accessible across application invocations and device power cycles. For example, a Policy would maintain the timestamp of the last successful license check, the retry count, the license validity period, and similar information in a persistent store, rather than resetting the values each time the application is launched.

Sharedpreferences is only secured by using the sandbox model. This means any rooted devices would permit the user to alter these values simple by editing the .xml file.

What Google have done to allow developers to defend against this is to create AESObfuscator. This encrypts the data using the Android ID as the key. Obviously this is still recoverable by the user, but certainly makes it take a little longer to perform.

I can foresee two attacks coming out of this.
 #1 - Applications on 3rd party app stores stating they can "unlock" licensed applications. They would require a r00ted device to work and could do all sorts of nefarious things in the background. Because they would not be allowed on Google Play, they would have no checking and could contain malware.

#2 - Applications implementing their own obfuscation/ trusting license info input. Their is a long history of Android applications assuming the best about files in their own sandbox and implementing their own logic and functions when using the data contained. It allows attackers who can overcome the sandbox (say by running on a rooted device) to inject data that is then used in the context of the app.

On the road with Arduino

Well the Arduino UNO kit has arrived and I'm very impressed. Lots of things to try and I'm already well beyond the flashing LED tutorial that is the electronics version of HelloWorld.

Some quick experimenting has shown that the servo is easy to position using this example. Similarly I have built up a quick serial communication app that replies to a specific string (based on this). Interestingly you need to tweak PUTTY to talk to it correctly

// Command line variables
String command; // String input from command prompt
String temp1,temp2; // temporary strings
char inByte; // Byte input from command prompt
char carray[6]; // character array for string to int // manipulation
int a,b,c; // temporary numbers

void setup(){
    Serial.begin(9600);
 }


void loop(){

    // Input serial information:
    if (Serial.available() > 0){
       inByte = Serial.read();
        // only input if a letter, number, =,?,+ are typed!
        if ((inByte >= 65 && inByte <= 90) || (inByte >=97 && inByte <=122) || (inByte >= 48 &&     inByte <=57) || inByte == 43 || inByte == 61 || inByte == 63) {
          command.concat(inByte);

        }
       
     }// end serial.available
     // Process command when NL/CR are entered:
     if (inByte == 10 || inByte == 13){
       if (command.equalsIgnoreCase("hey")){
         Serial.println("hello there!");
       }       command="";      }
}

ASCII only exploiting

So an interesting problem was given to a group of us this week. The vulnerable function in IE was controlled using an ASCII string. Most people took this as a sign that heap spraying was required and therefore used a string like "   " to point to heap space and hopefully their NOP sled.

I took the "crafty" approach and instead decided that the whole shell code could be contained in the string, not just the pointer.

msfencode (part of Metasploit) has an excellent encoder option that will encode only using alphanumeric characters. Unfortunately when you try this, you will get non alpha characters mixed in wherever it fails to find the right commands.

msfpayload windows/exec CMD=calc.exe R | ./msfencode -e x86/alpha_mixed

In this case, you will need to find a ROP gadget to move the address of the start of your shell code in to one of the registers. If you're lucky it will already be in one. You can then give it to msfencode as an argument:

 msfpayload windows/exec CMD=calc.exe R | ./msfencode BufferRegister=EAX -e x86/alpha_mixed

 If you need to go searching for ROP gadget there are a couple of tools that may help you. First check out Immunity's !gadget  command. Alternatively there's Mona, a Python add-on (https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/). These were enough to go searching through for a non-ASLR'd gadget that moved the right value to the right register.

R00t beer fridge

So as an update to the previous post, I've been doing some research over the last couple of days and found that:
a) servos are weird things that require crazy Pulse Width Modulation (PWM) to control them. This is not something Raspberry Pis do out of the box. I've seen a few cases where they use an in between piece of hardware to work around this.
b) arduinos can be made to do some crazy stuff. Like run a web server

For these two reasons I have (sadly) moved over to using Arduino. I would love to use a Pi but it's horses for courses and although I think it's possible to use a Pi for a project like this, it's just too much effort.

The Arduino will be delivered tomorrow so I can get to grips with the basics over the weekend and have the first photos next week.

It looks like the locking mechanism will be best done with Meccano. Using servos to move the locks into place will mean that they can be used without a second power source and won't "fail open" if someone was to pull the plug. It will either be a sliding bar, or a latch.