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

Revision as of 05:58, 15 November 2012

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))

There are multiple ways to prove an application vulnerable, be they "White Hat" or "Black Hat"(Using dSploit as an example):

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

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

Overall, if proven vulernable, the attacker is in a good position:

• They now have root access
• They are running an arbitrary payload as root with the capability of hiding itself from the user
• The payload is capable of being executed to appear as a different application, disguising entry.

Citation: Application: dSploit v1.028b