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.