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

Powershell import #2075

Closed
wants to merge 19 commits into from
Closed

Conversation

sempervictus
Copy link
Contributor

Thank you @meatballs for kicking me in the posterior to do this properly (#2073).

g0tmi1k and others added 2 commits July 4, 2013 13:27
If the regex fails then the entire moudle would too
Add Rex powershell parser:
 reads PSH, determines functions, variables, blocks
 compresses and cleans up the code it's read, obfuscates
 handles string literals and reserved variable names
 extracts code blocks and functions for reuse
  turns powersploit into a useful sub-component for MSF
Rewire Msf powershell modules
 Make use of Rex parser
 Handles payload generation, substituions
 Brings convenience methods - byte array generation and download
 Re-add .NET compiler
  Compiles .NET code (C#/VB.NET) in memory
  Can generate binary output file (dynamic persistence)
  Handles code-signing (steal cert with mimikatz, sign your bin)
  Not detected by AV (still...)
 Update payload generation
  GZip compression and decompression (see Rex module as well)
  msftidy violations for space efficiency - each char counts
Re-submit psexec-psh
 Makes use of updated Msf and Rex modules
 Runs shellcode in-memory (in a hidden PSH window)
 Completely bypasses all AVs tested for the last year...
@Meatballs1
Copy link
Contributor

I fear that such a large pull is going to go the way of the previous one... Can we start off simple with 1 module (e.g. psexec) and just the dependencies for that?

There's also #2037 which will cause conflicts at some stage.

@sempervictus
Copy link
Contributor Author

We can probably split this into core/exploit & post PRs (along with removing g0tm1lk's work which somehow made this branch). As far as the variable repetition issue, i think that's resolved in my code already.
This is still missing modules for actually building the .NET code (there's some other proprietary code in there i need to remove) and powersploit ports into MSF as i've not had time to reach out to Matt Graeber to get permission for it (MSIL injection and the like).

I think we should be able to comfortably convert the other PSH related PRs into this codebase and make use of the Rex parser/builder for dealing with PSH down the line.

@Meatballs1
Copy link
Contributor

@sempervictus I think this pull is waiting on:

Removing @g0tmi1k's PR
psexec_psh.rb deconflicting with whats already in trunk now
Splitting up into smaller chunks:

Post module can be submitted on its own?
Incremental adjustments to the library classes?

Hopefully @dark0perator and @obsuresec will drum up more powershell demand ;)

@g0tmi1k
Copy link
Contributor

g0tmi1k commented Jul 20, 2013

How did my stuff end up here!? :s

@Meatballs1
Copy link
Contributor

@sempervictus's bad branch management ;)

RageLtMan added 4 commits July 20, 2013 19:26
@g0tm1lk: no clue, you must've pwned me in your sl33p. :)
Resolve conflicts from old code being pulled into master.

Conflicts:
	lib/msf/core/exploit/powershell.rb
	modules/exploits/windows/smb/psexec_psh.rb
Remove .NET compiler, post lib and modules.
This is temporary and rather messy. Since the internals for
dealing with PSH code have moved to Rex there may be a hiccup or
two here. This was my original attempt at basic PSH integration
and does not make use of the new libraries and namespaces in
this PR.

Will introduce the updated modules and libraries in separate PR.
@sempervictus
Copy link
Contributor Author

Lets see how this goes - i've cut out post and .NET work for now, leaving just the core requirements. I need to finish with some client related work and i'll cut up new PRs for the post libs, PSH modules (execute in memory to your heart's content), and the in-mem .NET compiler.

@devs: for testing, shoot something running powershell with the new psexec_psh module for functional purposes.
Then, find a .ps1 file on your machine and:

s =Rex::Exploitation::Powershell::Script.new <your_file>
s.code
s.functions
s.compress_code

and so forth.
Makes life easier when you're up @ the Msf::... level, the psh code already does what we need.
I've tested this a reasonable amount, any feedback on parsing/processing failures would be great
@egypt: you're welcome to install every vendor's AV to see what they say. The actual binary executing the wraper + shellcode is a well known and trusted system bin which doesnt look that weird accessing the net when heuristics engines look @ it. If you ask them to look @ unsafe .NET calls, take a look @ https://github.com/mattifestation/PowerSploit/blob/master/CodeExecution/Invoke-ShellcodeMSIL.ps1, which avoids the problem rather neatly.

@Meatballs1
Copy link
Contributor

lib/msf/core/exploit/powershell.rb has lots of merge conflicts in it

@Meatballs1
Copy link
Contributor

modules/exploits/windows/smb/psexec_psh.rb also appears to be overwritten with a completely different file! 🐙

@sempervictus
Copy link
Contributor Author

They are overwrites, problem is that the PR resurrecting psexec_psh is based on old code from my framework, which has been superceded by these components as well as other private libs.

As you can see by my commit/PR history there's a ton of work in my framework which isnt in master. I tend to make large PRs and work in lib which probably doesnt help. This is the first time i've run into the problem of having someone resurrect conflicting (out of date) work. Sorry for all the confusion.

@todb-r7
Copy link

todb-r7 commented Jul 21, 2013

Unfortunately, you're going to have to untangle these conflicts before we can start to validate it. Otherwise, it's a guessing game to determine your intent.

@sempervictus
Copy link
Contributor Author

@todb-r7: any chance i can put back the post lib and modules? They all run off the same base in Rex::Exploitation and Msf::Core::Exploit.

Intent is for us to have a unified mechanism for working with powershell code. Allow framework and modules to have a central interface and reduce hackery.

@todb-r7
Copy link

todb-r7 commented Jul 21, 2013

@sempervictus sorry it's just hard to see what the changes intended are in my phone, I'll (or someone) will take a look on a proper computer.

@Meatballs1
Copy link
Contributor

@sempervictus I'm happy to help get this landed but psexec_psh is still overwritten with completely the wrong file.

Replace powershell lib which snuck in as psexec_psh.
Introduce psexec_psh module which uses the Rex and Msf PSH
methods provided in the lib import.
@sempervictus
Copy link
Contributor Author

Thank you @Meatballs1. Too many branches, not nearly enough time these days.

def exploit
command = cmd_psh_payload(payload.encoded)
register_options([
OptBool.new('PERSIST', [false, 'Run the payload in a loop']),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I re-factored these to the mixin library as they are not referenced in the module but are referenced in the mixin so it makes more sense, to me, for them to be there?

@Meatballs1
Copy link
Contributor

I'll see if I can correct the merge issues with psexec_psh should be pretty straightforward

Looks good from here, though we may want to address the all caps opt names.
# Build script object
psh = PshScript.new(script_in)
# Invoke enabled modifiers
datastore.select {|k,v| k =~ /^PSH::(strip|sub)/ and v == 'true' }.keys.map do |k|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this work with the renaming of the functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, i run with sub_vars and sub_funcs all the time. This was written before the recent commits adding unique random var generation, so handles that in the psh Rex lib. If you're seeing bugs in testing, would love to reproduce and fix in the Rex layer.

sempervictus pushed a commit to sempervictus/metasploit-framework that referenced this pull request Jul 31, 2013
This is the core post component broken out from rapid7#2075.
Includes new post library leveraging the rex and msf namespace
changes in lib.
Includes basic modules for script and command execution. These
modules can be used a simple base for complex powershell execution
from post modules and RC scripts.
@@ -68,16 +68,21 @@ def initialize(info = {})
[ 'URL', 'http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx' ]
]
))

register_options([
OptBool.new('DryRun',[false,'dry run',false]),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a better description

@Meatballs1
Copy link
Contributor

Dev Required

  • Naming convention of PSH:: should be lower_case
  • Integrate the Rex::RandomIdentifierGenerator into the PSH exe functions
  • Other small comments

Testing Required, doesn't look like this affects too much existing functionality - post modules/scripts not affected.

  • Check .ps1 generation still works correctly - msfvenom/msfpayload/psh_web_delivery
  • Check psexec_psh still works correctly

fail_with(Exploit::Failure::NoAccess, "#{peer} - Unable to authenticate with given credentials: #{autherror}")
ensure
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This disconnect causes the module to fail, should be placed back within the rescue. My bad!

@Meatballs1
Copy link
Contributor

I have submitted a PR to sempervictus repository to advance this sempervictus#18

@jvazquez-r7
Copy link
Contributor

According to github there are conflics to solve before we can proceed with this. Please fix them or warn us if github is wrong :)

@Meatballs1
Copy link
Contributor

I have merged some of the conflicts in #2557 but that is also in need of some deconfliction!

@jvazquez-r7
Copy link
Contributor

This pull request is creating conflicts and can't be landed, please @sempervictus feel free to fix the conflicts and reopen again once ready.

In Addition, according to @Meatballs1 , some of the conflicts are already merged on #2557, which as far as I understand is the same thing than this pull request. So I guess work can be done on #2557, right?

Meatballs1 added a commit that referenced this pull request Jul 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants