Difference between revisions of "Who dropped a payload on the Android smartphone"

Revision as of 05:21, 15 November 2012

This write up is about the amazing inability with app developers of (root necessary) applications that fail to secure their file permissions which can lead to a device running a binary payload without the users knowledge all while looking like the attacker didn't do a damn thing.

The main problem some of us look for when attacking a system is improper file permissions if it's linux. If we can write to it and then get a user to run it, we are absolutely golden. Nothing is better than just overwriting a chmodded 777 file just to watch a user execute it and think the binary just doesn't work. This is especially true in Android because:

1) Android doesn't automatically check an application's file permissions. 2) Android does not stop another application from writing to a known file with rw*rw*rw* permissions. 3) Applications that use root usually have a binary included somewhere for their functions which allows us to make it look like either the app they downloaded was malicious or the app just stopped working.

An example of this type of simple attack can be used on the Android application called dSploit. The version we will be attacking is v1.028b (Has since been patched because I disclosed to the developer) which has all the binaries in /data/data/it.evilsocket.dsploit/files/tools/ as rwxrwxrwx. This can be very bad for the app developer for multiple reasons.

1) It uses root to run these binaries. 2) We can write to those files and have them execute a payload 3) Executing payloads is never a good thing for the user.

How do we find if an application is vulnerable to an attack like this? Well, we download it to a rooted device we own and we just run "ls -l -R /data/data" and see what pops up. If you see that a popular application has rwxrwxrwx on a binary it runs as root, then that is fine and dandy. Other acceptable but less common permissions include: rw-rw-rw rwx-rw-rw rw-rw--w- -w--w--w-

Another fun part of this type of exploit is that it can also be used to leverage root on any android device if you have an application that is owned by root / system and has f***ed file permissions but that is a well known method (ro.kernel.qemu=1 in /data/local.prop)

Now, how can we prove that the application is vulnerable? Well, for the white hats, we will just have it run something like this (Using dSploit as an example):

echo "echo lol > /sdcard/test" > /data/data/it.evilsocket.dsploit/files/tools/tcpdump

The black hats however can run something more along the lines of:

cat /data/data/com.self.made.malicious.app/payload/compiled.android.botnet > /data/data/it.evilsocket.dsploit/files/tools/nmap

This is good for the attacker all because now we have root, we are now running something that will always run as root + hide itself from the user, and it's always fun to make a payload be executed under the pretext of another application so we don't get in trouble :)

Citation: Application: dSploit v1.028b

NOTE: SHAMELESS PLAGIARISM