Powershell Improvements - Auto Arch Detection, Size Reduction

[Meatballs1]

This is basically my PR to @sempervictus's branch #2075

It builds a better framework for performing Powershell command execution -> shellcode execution.

One of the main features I'm trying to do is that powershell will spawn the correct process for the payload architecture.

More and more modules are starting to poke at the powershell functionality so I would rather get these in earlier rather than later.

Specced

Some may not be the best specs ever written but at least they exercise most code paths

rspec spec/lib/rex/exploitation/powershell* spec/lib/msf/core/exploit/powershell_spec.rb 
Msf::Exploit::Powershell ...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Rex::Exploitation::Powershell::Function ..
Rex::Exploitation::Powershell::Obfu .........
Rex::Exploitation::Powershell::Output ..............
Rex::Exploitation::Powershell::Param .
Rex::Exploitation::Powershell::Parser ...........
Rex::Exploitation::Powershell::PshMethods .....
Rex::Exploitation::Powershell::Output ...
Rex::Exploitation::Powershell ...

Finished in 4.29 seconds
543 examples, 0 failures

Features

• The payload auto detects the architecture of the runtime environment that it is executed within. This allows it to spawn a new powershell process if the shellcode targets a different architecture. This means powershell exploits have an Automatic target rather than specifying x86/x64. Obviously this doesn't work with x64 shellcode on an x86 target but x86 shellcode should be properly universal.
• It reduces the size of the final payload. This means we can execute a full meterpreter payload in a fully base64 encoded -e command around < 5700 chars. This makes the cmd exec a lot more usable as there are a lot less bad characters to worry about.
• Unencoded payloads can be generated < 2200 characters which could be helpful if command injection is more limited in size. (By editing the source powershell we should be able to drop this further).
• More flexible techniques for generating powershell command lines and arguments are used so these aren't hardcoded strings within modules. No more gsubbing of bad characters if possible!

Options

cmd_psh_payload options:

• :use_single_quotes => Encapsulates the final -c command in single quotes. e.g. -c 'echo 1' (~2200)
• :encode_inner_payload => b64 encodes the inner payload (~5230)
• :encode_final_payload => b64 encodes the final payload e.g. -e blah. (~5700)
• :remove_comspec => Remove %COMSPEC% and just rely on powershell.exe.
• :no_full_stop => Remove .exe from powershell (incase . is a bad char)
• :no_equals => Remove == from base64 encoded final payload (incase = is a bad char)
• :shorten => Shorten command line args e.g. -Command -> -c

Update Modules

Current modules that need to be fixed up regarding these changes:

• windows/http/oracle_endeca_exec
• windows/local/current_user_psexec
• windows/local/ms13_005_hwnd_broadcast
• windows/local/wmi
• windows/browser/ie_unsafe_scripting
• windows/smb/psexec_psh
• windows/misc/psh_web_delivery
• windows/local/powershell_cmd_upgrade.rb
• windows/misc/hp_dataprotector_exec_bar.rb

Potential PR conflicts:

#2551

#2307

#2468

#2402

Verification: Auto Arch Targeting using psh_web_delivery

• x86 payload on x86 system
• x86 payload on x64 Process
• x86 payload on SYSWOW64 Process
• x64 payload on x64 Process
• x64 payload on SYSWOW64 Process

[sempervictus]

@Meatballs1 check your repo, i think we got out of sync in Post. I've re-added my Post module to your branch with some fixup. I'll PR DotNet and associated Psh/DotNet modules once this lands, so as not to keep this held up any longer.

[Meatballs1]

Will look to merge in your Post stuff when we get this landed :)

[sempervictus]

Please whack me when we have a window? I should have some more code to push
in a bit.

On Fri, Jun 20, 2014 at 5:50 PM, Meatballs1 [email protected]
wrote:

Will look to merge in your Post stuff when we get this landed :)

—
Reply to this email directly or view it on GitHub
#2557 (comment)
.

[sempervictus]

Did this die on the vine or are we rebasing somewhere? There's a lot of useful work in here...

[Meatballs1]

I'm going to re-open it when other PR gets landed. I cant keep updating 19 PRs when they are just sat around gathering no love :(

[sempervictus]

@Meatballs1 I feel your pain on the open PRs, though i've learned to see it as a sort of compliment that our work requires serious review. However, if we drop this out of the active queue it will never hit, and i assume you probably have derived work internally as well by now. I spend too much time merging upstream with my work, and have moved most of my really scandalous code into plugins, but if this doesnt merge then at least you and i will, again, be cleaning out interrim-submitted hackery to get around PSH idiosyncrasies to accomplish what we have here (without the "good practices").
I vote we re-open and nag @todb-r7 until its committed or @hmoore-r7 turns us into toads ;)
I can re-PR the thing if you want me to have stewardship over this, but TBH you've been invaluable in getting this work into upstream both in terms of code and diplomatic effort with the powers that be.

@r7 This is a healthy body of work with a ton of value. It comes up in almost every discussion i have with client security staff and AV vendors have asked about it after realizing it walks lazy circles around them. Moreover, since R7 bases the commercial offering on the framework, one could reason that the capabilities this exposes would be of significant value to paying customers.

@devs, aside from the need to sleep and eat on occasion, is there anything we can address which is holding up this PR?

[jhart-r7]

8191 or 8192? In the unlikely event that the command is exactly 8192 characters, this will incorrectly raise (or the error message is incorrect, depending on your POV)

[sempervictus]

CR space? I think the original code was 8192, but this actually makes more sense. I believe we can thank @Meatballs1 for catching that.

(sorry for the edit, original response was sent from mobile mail client)

On Jul 16, 2014 3:19 PM, "Jon Hart" [email protected] wrote:

In lib/msf/core/exploit/powershell.rb:

•    final_payload = "'#{final_payload}'"
  

•  end
  

•  command_args[:command] = final_payload
  

• end

• psh_command = generate_psh_command_line(command_args)

• if opts[:remove_comspec]

•  command = psh_command
  

• else

•  command = "%COMSPEC% /b /c start /min #{psh_command}"
  

• end

• vprint_status("Powershell command length: #{command.length}")
• if command.length > 8191

8191 or 8192? In the unlikely event that the command is exactly 8192
characters, this will incorrectly raise (or the error message is incorrect,
depending on your POV)

—
Reply to this email directly or view it on GitHub
https://github.com/rapid7/metasploit-framework/pull/2557/files#r15021129
.

[Meatballs1]

I think this was probably the case but I can't remember for sure now :)

[Meatballs1]

@sempervictus My plan was to re-open this as my only PR except @scriptjunkie had some momentum on my other pull so was hoping for that to land. Then I can continue with just one PR at a time. Having this open was also making me not want to land any other Powershell stuff as it just meant more additional work and testing for me :(

This needs fixing up against:

modules/exploits/multi/script/web_delivery
exploits/windows/local/ms14_009_ie_dfsvc
exploits/windows/local/ms13_097_ie_registry_symlink

as well as potential conflicts with #2585

[jhart-r7]

What is the behavior when no location to save the file to? I'm assuming that it it just drops it in pwd much like most downloader-like tools, but it might be worth being explicit here in the documentation (since you took the time to write it and it is so nice)

[Meatballs1]

It should throw a 'WebException' if filename is null or Empty.

I will modify this so it doesn't take a default

[hdm]

Offhand, the use of str[start...end] versus str[start,length] seems wrong in a few places. It seems a few exploit modules are still broken or not compatible with this change based on the checkboxes above. As for why it is blocked @sempervictus , see @Meatballs1 comment above.

[Meatballs1]

Nb the unchecked modules above probably are compatible, just i havent had environment to test (a few I have tested in previous iterations but haven't got round to in latest commit). I dont forsee any issues with these

[Meatballs1]

@hmoore-r7 Whats wrong with string[range]?

[Meatballs1]

I have come to the conclusion this is just pre-commit fixes to @sempervictus's code originally submitted in January 2013 and there's no reason to delay any further.