Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not able to find a proper encoder with Fetch Payloads #18572

Closed
cdelafuente-r7 opened this issue Nov 24, 2023 · 2 comments · Fixed by #18720
Closed

Not able to find a proper encoder with Fetch Payloads #18572

cdelafuente-r7 opened this issue Nov 24, 2023 · 2 comments · Fixed by #18720
Assignees
Labels
bug not-stale Label to stop an issue from being auto closed payload

Comments

@cdelafuente-r7
Copy link
Contributor

cdelafuente-r7 commented Nov 24, 2023

This issue came out while working on this PR. This comment gives more details.

When some BadChars are set, Framework tries to find a suitable encoder according to the platform and the architecture. With a fetch payload, it fails:

[-] Exploit failed: cmd/linux/http/x64/meterpreter/reverse_tcp: All encoders failed to encode.

When setting the payload to a standard command payload (e.g. cmd/unix/reverse_bash), it works.

I found out the payload platforms are all set to linux platforms:

From: /Users/cdelafuente/dev/src/metasploit-framework/lib/msf/core/encoded_payload.rb:567 Msf::EncodedPayload#compatible_encoders:

    562: def compatible_encoders
    563:   arch = reqs['Arch'] || pinst.arch
    564:   platform = reqs['Platform'] || pinst.platform
    565:   require 'pry';binding.pry
    566:
 => 567:   encoders = []
    568:
    569:   framework.encoders.each_module_ranked(
    570:     'Arch' => arch, 'Platform' => platform) { |name, mod|
    571:     encoders << [ name, mod ]
    572:   }
    573:
    574:   encoders
    575: end

[1] pry(#<Msf::EncodedPayload>)> pinst.platform
=> #<Msf::Module::PlatformList:0x00007fbf69abf1f0 @platforms=[Msf::Module::Platform::Linux, Msf::Module::Platform::Linux]>
[2] pry(#<Msf::EncodedPayload>)> pinst.arch
=> ["cmd"]

So, no encoder is found with both a cmd architecture and a linux platform:

[1] pry(#<Msf::EncodedPayload>)> encoders
=> [["generic/none", Msf::Modules::Encoder__Generic__None::MetasploitModule], ["generic/eicar", Msf::Modules::Encoder__Generic__Eicar::MetasploitModule]]

While with a command payload, the unix platform is correctly set:

[1] pry(#<Msf::EncodedPayload>)> pinst.platform
=> #<Msf::Module::PlatformList:0x00007fbf68dd6ce0 @platforms=[Msf::Module::Platform::Unix]>

Steps to reproduce

  1. Use an exploit that supports Fetch Payloads (e.g. linux/http/vinchin_backup_recovery_cmd_inject)
  2. Make sure some BadChars are specified in the info hash (e.g. 'Payload' => { 'BadChars' => "\"'<>&" })
  3. Do: set payload cmd/linux/http/x64/meterpreter/reverse_tcp
  4. set the required options
  5. Do: exploit

Try again with a command payload cmd/unix/reverse_bash. It should work now.

Expected behavior

The exploit should execute without encoding errors.

Current behavior

It fails with this error:

[-] Exploit failed: cmd/linux/http/x64/meterpreter/reverse_tcp: All encoders failed to encode.
@smcintyre-r7
Copy link
Contributor

Easiest way to fix this might be to check if you can add linux as a platform to the existing encoders where unix is already listed.

Copy link

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.

@github-actions github-actions bot added the Stale Marks an issue as stale, to be closed if no action is taken label Dec 29, 2023
@smcintyre-r7 smcintyre-r7 added the not-stale Label to stop an issue from being auto closed label Dec 29, 2023
@github-actions github-actions bot removed the Stale Marks an issue as stale, to be closed if no action is taken label Jan 1, 2024
@smcintyre-r7 smcintyre-r7 self-assigned this Jan 18, 2024
@smcintyre-r7 smcintyre-r7 moved this to In Progress in Metasploit Kanban Jan 18, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in Metasploit Kanban Jan 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug not-stale Label to stop an issue from being auto closed payload
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants