Questions about this topic? Sign up to ask in the talk tab.

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

From NetSec
Jump to: navigation, search
(Created page with "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 ...")
 
Line 1: Line 1:
−
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.  
+
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.  
  
−
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:
+
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.
  
−
1) Android doesn't automatically check an application's file permissions.
+
This is especially true on Android OS:
−
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) 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.
  
−
1) It uses root to run these binaries.
+
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.
−
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:
+
This can land an app developer in hot water for multiple reasons:
−
rw-rw-rw
+
 
−
rwx-rw-rw
+
*1) The application uses root to run these binaries.
−
rw-rw--w-
+
*2) A hacker can write to those files and have them execute a payload
−
-w--w--w-
+
*3) Executing payloads <s>is never a good thing for the user</s> 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))
 +
 
 +
 
 +
 
 +
----
  
−
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):
 
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):
Line 30: Line 42:
  
 
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 :)
 
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:
 
Citation:

Revision as of 06:52, 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))



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

Retrieved from "http://nets.ec/index.php?title=Who_dropped_a_payload_on_the_Android_smartphone&oldid=9657"