Increase command timeout for Python, powershell extensions

[OJ]

The default timeout for Meterpreter commands needs to be adjusted for things like the Python extension commands because these things stand a good chance of being long-running.

It'd be handy to make it configurable in the following ways:

• Globally
• Per-session
• Per-command

I'd appreciate some thoughts on how this should be done. For now, I will go ahead and add the -t parameter that will allow the default timeout to be changed, but making it more usable is the goal, so any thoughts would be appreciated.

Cheers!

[DanMcInerney]

Really need this.

[DanMcInerney]

What I've found is that although Metasploit times out all powershell_execute commands after 15 seconds, it doesn't terminate the powershell cmd. So what you do as a workaround is to simply make the original long-running PSH cmd write its output to a file. Then, after MSF sends you the Rex::Timeout error, you make another powershell_execute call. If you get "[-] powershell_execute: Operation failed: 2148734468" then you know your first PSH cmd is still running. Once your second powershell cmd returns successfully then you know long-running cmd 1 is done and you can go retrieve the output from a file written to disk.

[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.

[srborines]

Hi everyone!

Some days ago I found myself in the situation that I needed to execute a command through Meterpreter, this command was taking more than 15 seconds so I was receiving the "Timeout error", at this point I had two options:

• OPTION 1: spawn a PowerShell terminal with the command 'powershell_shell' and interact directly with it [for my case I didn't want to do this].

• OPTION 2: Extend the global Meterpreter timeout to a greater value [this was the option I selected]

So trying to find the solution to the option 2 I realized that the 15 seconds timeout it's a limitation of the Metasploit client, no the implant. It means that to extend the timeout it's as easy as before start our Metasploit modify the local ruby files in our computer with the next line:

sed -i 's/self.response_timeout/60/' /usr/src/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb

You can replace '60' with the number of seconds you want to extend the timeout, by default as we know it's 15.

Hope it helps!

[adfoster-r7]

TL;DR As a quick work around for this 'bug', you can extend the Meterpreter commands in an interactive session by setting the command timeout before interacting with the session sessions -i 3 -t 30, i.e. for specifying a 30 second timeout

---

I added extra logging to the attr_accessor that sets the response_timeout in Meterpreter. It looks like this is only a problem when you interact with the session - due to this PR overriding the default Meterpreter timeout of 300 seconds is set be 15 seconds temporarily https://github.com/rapid7/metasploit-framework/pull/4442

msf6 exploit(windows/smb/psexec) > sessions

Active sessions
===============

  Id  Name  Type                     Information                   Connection
  --  ----  ----                     -----------                   ----------
  8         meterpreter x86/windows  NT AUTHORITY\SYSTEM @ WINDEV  192.168.1.178:4444 -> 192.168.1.178:63567 (192.168.123.151)

msf6 exploit(windows/smb/psexec) > sessions -i -1
Setting the response timeout to 15
[*] Starting interaction with 8...

meterpreter > background
[*] Backgrounding session 8...
Setting the response timeout to 300

Per-command

After finding the above PR it looks like this functionality somewhat/partially exists when interacting with the session

Interacting with a session without a timeout option:

msf6 exploit(windows/smb/psexec) > sessions -i -1
Getting the response timeout as 300
Setting the response timeout to 15
[*] Starting interaction with 10...

meterpreter > 

The command times out:

meterpreter > powershell_execute 'sleep 20; echo abc'
[-] Error running command powershell_execute: Rex::TimeoutError Send timed out

With the timeout option set before interacting with the session:

msf6 exploit(windows/smb/psexec) > sessions -i -1 -t 30
Getting the response timeout as 300
Setting the response timeout to 30
[*] Starting interaction with 9...

meterpreter > 

Then the command works:

meterpreter > powershell_execute 'sleep 20; echo abc'
[+] Command execution completed:
abc

[adfoster-r7]

I was thinking in terms of implementing this ticket we could do things like:

Per-session configuration

I think a per-session timeout would be an easy add for, which could be shown with sessions -v

msf6 payload(osx/x64/meterpreter_reverse_tcp) > sessions -v

Active sessions
===============

  Session ID: 1
               Name:
               Type: meterpreter osx
               Info: adfoster @ 192.168.1.178
             Tunnel: 127.0.0.1:4444 -> 127.0.0.1:63135 (127.0.0.1)
                Via: exploit/multi/handler
          Encrypted: Yes (AES-256-CBC)
               UUID: e34319680401be4e/x64=2/osx=9/2023-08-16T09:58:49Z
            CheckIn: 8s ago @ 2023-08-16 11:03:31 +0100
   Response Timeout: 300s
Interacting Timeout: 15s
         Registered: No

The added flag option to the sessions command to configure the response_timeout per sessions timeout would need to not conflict with the option that would be added to https://github.com/rapid7/metasploit-framework/issues/5664

Globally

Reading from the values set via setg could work here We'd want to default to this global value when new sessions are created, and also in the places where response_timeout is hard coded - i.e. https://github.com/rapid7/metasploit-framework/pull/4442/files#diff-8ec504ef60a6490b277e1bbb3ea861d2b33f06f6a380d9a6177ee54c444dc67bR1601

---

MVP

But to take a step back, I think for now the real problem is the interactive session timeout is hard-coded to 15 seconds, and ignoring the 300 second default timeout that's initially set by Meterpreter sessions. Maybe we should just have a better error message:

i.e. before:

meterpreter > powershell_execute 'sleep 20; echo abc'
[-] Error running command powershell_execute: Rex::TimeoutError Send timed out

After:

meterpreter > powershell_execute 'sleep 20; echo abc'
[-] Error running command powershell_execute: Rex::TimeoutError Send timed out. Timeout currently 15 seconds, you can configure this with %grnsessions --interact <id> --timeout <value>%clr

That would allow for the existing timeout configuration option to be discovered more readily