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 ...")
 
 
(2 intermediate revisions by one other user not shown)
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
+
−
rw-rw--w-
+
−
-w--w--w-
+
  
−
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)
+
*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 <s>is never a good thing for the user</s> will probably result in a bad time.
  
−
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):
+
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:
  
−
echo "echo lol > /sdcard/test" > /data/data/it.evilsocket.dsploit/files/tools/tcpdump
+
  rw-rw-rw
 +
  rwx-rw-rw
 +
  rw-rw--w-
 +
  -w--w--w-
  
−
The black hats however can run something more along the lines of:  
+
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))
  
−
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 :)
 
  
 +
----
  
  
 +
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
  
−
Citation:
+
  cat /data/data/com.self.made.malicious.app/payload/compiled.android.botnet > /data/data/it.evilsocket.dsploit/files/tools/nmap
−
Application: dSploit v1.028b
+
  
 +
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.
  
−
NOTE: SHAMELESS PLAGIARISM
+
Citation:
 +
Application: dSploit v1.028b

Latest revision as of 07: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 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 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

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