Difference between revisions of "Who dropped a payload on the Android smartphone"
Chantal21I (Talk | contribs) |
AlizaLorenzo (Talk | contribs) |
||
(One intermediate revision by one other user not shown) | |||
Line 33: | Line 33: | ||
− | + | 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 | + | 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: | Citation: | ||
− | Application: dSploit v1.028b | + | Application: dSploit v1.028b |
− | + | ||
− | + | ||
− | + |
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