Difference between revisions of "Who dropped a payload on the Android smartphone"
Chantal21I (Talk | contribs) |
AlizaLorenzo (Talk | contribs) |
||
Line 39: | Line 39: | ||
cat /data/data/com.self.made.malicious.app/payload/compiled.android.botnet > /data/data/it.evilsocket.dsploit/files/tools/nmap | cat /data/data/com.self.made.malicious.app/payload/compiled.android.botnet > /data/data/it.evilsocket.dsploit/files/tools/nmap | ||
− | Overall, if proven | + | Overall, if proven vulnerable, the attacker is in a good position: |
* They now have root access | * They now have root access | ||
* They are running an arbitrary payload as root with the capability of hiding itself from the user | * They are running an arbitrary payload as root with the capability of hiding itself from the user |
Latest revision as of 06:25, 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 userwill 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 vulnerable, 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