Who dropped a payload on the Android smartphone

Preface: 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.

One of the main problems to look for when attacking a system is improper file permissions (On Linux OS). If a hacker can write to the system and then get a user to take the bait, they are absolutely golden. Nothing is better than overwriting a chmodded 777 file just to watch a user execute it and think the binary just doesn't work.

This is especially true on Android OS:

• 1) Android doesn't automatically check an application's file permissions.
• 2) Android doesn't 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 for a hacker to make it look like either (a)the app the user downloaded was malicious or (b)the app just stopped working.

An example of this type of simple attack is a vulnerability in an Android application called dSploit (version 1.028b)(This has since been patched), which has all the binaries in /data/data/it.evilsocket.dsploit/files/tools/ as rwxrwxrwx.

This can land an app developer in hot water for multiple reasons:

• 1) The application uses root to run these binaries.
• 2) A hacker can write to those files and have them execute a payload
• 3) Executing payloads is never a good thing for the user will probably result in a bad time.

One way to check if an application is vulnerable is to download it to a rooted device, run

 ls -l -R /data/data

and see what pops up. If an 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-

This type of exploit can also be used to leverage root on any android device if one has access to an application that is owned by root / system and has insecure file permissions. (ex: (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