Metasploit-framework: client.platform missing "windows" platform

Created on 10 Jan 2017  Â·  24Comments  Â·  Source: rapid7/metasploit-framework

Steps to reproduce

  1. Get Meterpreter on Windows Server 2012 R2 with SYSTEM privileges.
  2. run enum_vmware or run process_memdump
  3. You’ll get “[-] This version of Meterpreter is not supported with this Script!”

How'd you do it?
Looking on the source code have both scripts shows that it will only run on “client.platform =~ /win32|win64”
Checking the variable with IRB shell throws “windows”. Adding “windows” to both scripts solves the issue.
However, I am not sure that this is the right solution.

System stuff

Kali Linux

Metasploit version

version
Framework: 4.13.10-dev
Console : 4.13.10-dev

OS

Kali Linux

It’s important to mention that searching for “client.platform =~ /win32|win64” on Metasploit repository returns 45 results although I’m not sure it is relevant for all.

Also, I am not sure that it only happens on 2012R2

Most helpful comment

Checking for client.platform == 'windows' isn't enough these days either :) Having the platform set to windows rather than win32, for example, was done for a few reasons. The main one being that arch was already in the client.arch, and so was rather redundant. However, the platform can be set to windows for php and python payloads as well. If you want to check for a native meterpreter on windows you need to make sure that the platform is windows and that the arch is either ARCH_X86 or ARCH_X64. An example of this is here: https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/persistence.rb#L229

As far as updating all the scripts goes, that's not going to happen any time soon. If you want this particular script to be updated, feel free to modify it and submit a PR. However, as already alluded by others, these scripts are deprecated in favour of post modules. If there's no post module that does what you're looking to do, then... the same process applies :)

All 24 comments

Scripts are no longer supported and are deprecated in favor of post modules. As per my initial assessment in https://github.com/rapid7/metasploit-framework/issues/7789, the enum_vmware script don't have a corresponding post module at the moment. However you can use post/windows/gather/memory_grep instead of the process_dump script in order to dump and grep a pattern from a process memory.

Dang, right as I was about to comment, lol. Thanks, @void-in. Sorry, @ClearGateTeam. That is the correct fix, though. If you want to submit a patch, you're welcome to.

wvu@kharak:~/metasploit-framework/scripts/meterpreter:master$ git grep -E 'win(32|64)' | wc -l
      76
wvu@kharak:~/metasploit-framework/scripts/meterpreter:master$ 

@wvu-r7 You and me have this tendency to pick and comment on an issue at the same time :)

I'm not that familiar with the inner works of Metasploit.

Is there a reason why the client.platform is windows instead of win32 or win64?

Yeah, one sec.

I think it was #7507, @ClearGateTeam. Scripts have been deprecated for literally years now, btw. If you heard about them from Metasploit Unleashed, the advice is a bit dated.

If you're not comfortable submitting a patch, I could fix this quickly, but then there'd be 74 other fixes to make, too... So do we fix these as we go or rm all of them? :P

I think scripts are still useful, but they've largely been outmoded by post modules. While we don't have complete feature parity between the two, we'd like that to happen before we move on scripts.

In my opinion as there are scripts that don't have a corresponding post module yet, it would be great if you can add windows to all of them, what do you think?

p.s - @void-in , I don't think memory_grep post module will assist me as I want to dump the entire memory of a process and not part of it.

@ClearGateTeam: Adding windows to all of them isn't as simple as a search and replace, though. Scripts will need to be refactored. 59 of them, to be exact. That's putting a lot of time into something that's already deprecated. I think we can fix these as we go. What do you think?

ok. didn't know that

@wvu-r7 For those scripts which have the exact functionality available in the post modules. we can literally rm-ed them and there won't be any functionality lost. I am working on the exact functionality parity you mentioned in https://github.com/rapid7/metasploit-framework/issues/7789 to make sure everything is documented when the time comes to get rid of these scripts.

@void-in: Great, thank you. Just trying to be sensitive to people's workflows. :)

@ClearGateTeam: No idea if this would work or not, but notice how it's not a simple search/replace:

wvu@kharak:~/metasploit-framework:master$ git diff
diff --git a/scripts/meterpreter/enum_vmware.rb b/scripts/meterpreter/enum_vmware.rb
index c19a8fb200..64b51eae2c 100644
--- a/scripts/meterpreter/enum_vmware.rb
+++ b/scripts/meterpreter/enum_vmware.rb
@@ -297,7 +297,7 @@ def enum_vmwarewrk
     end
   end
 end
-if client.platform =~ /win32|win64/
+if client.platform == 'windows'
   if check_vmsoft
     vmware_products = check_prods()
     if vmware_products.include?("VMware VirtualCenter")
diff --git a/scripts/meterpreter/process_memdump.rb b/scripts/meterpreter/process_memdump.rb
index 3d8c825364..42f7d46960 100644
--- a/scripts/meterpreter/process_memdump.rb
+++ b/scripts/meterpreter/process_memdump.rb
@@ -147,9 +147,9 @@ def get_mem_usage( pid )
         # Note: As we get the raw structure back from railgun we need to account
         #       for SIZE_T variables being 32bit on x86 and 64bit on x64
         mem = nil
-        if( @client.platform =~ /win32/ )
+        if @client.arch == ARCH_X86
           mem = pmc[12..15].unpack('V').first
-        elsif( @client.platform =~ /win64/ )
+        elsif @client.arch == ARCH_X64
           mem = pmc[16..23].unpack('Q').first
         end
         return (mem/1024)
@@ -165,7 +165,7 @@ def get_mem_usage( pid )
 end

 # Main
-if client.platform =~ /win32|win64/
+if client.platform == 'windows'
   if resource
     resource.each do |r|
       next if r.strip.length < 1
wvu@kharak:~/metasploit-framework:master$ 

If that took me 5 minutes, and there are 74 other changes to make, then it would take me approximately 6 hours to fix all the scripts, assuming no breaks and consistent complexity, only for the scripts to be removed in the future. No thanks. :(

@wvu-r7 thank you for the explanation.

I just didn't understand yet what is the meaning of windows , can you explain ?

There are some false positives in there, and I rounded down on the time, but you get the point!

@ClearGateTeam: Did you read #7507, which I linked above?

@wvu-r7 not yet.

Well, in short, arch already contains the arch, such as ARCH_X86. No need to put it in platform like win32, so windows became the new thing. It's more consistent, it's more correct, and it allows for new features @OJ has been working on.

(That's my personal understanding. Please correct me if you had other reasons, @OJ. :)

Checking for client.platform == 'windows' isn't enough these days either :) Having the platform set to windows rather than win32, for example, was done for a few reasons. The main one being that arch was already in the client.arch, and so was rather redundant. However, the platform can be set to windows for php and python payloads as well. If you want to check for a native meterpreter on windows you need to make sure that the platform is windows and that the arch is either ARCH_X86 or ARCH_X64. An example of this is here: https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/persistence.rb#L229

As far as updating all the scripts goes, that's not going to happen any time soon. If you want this particular script to be updated, feel free to modify it and submit a PR. However, as already alluded by others, these scripts are deprecated in favour of post modules. If there's no post module that does what you're looking to do, then... the same process applies :)

@OJ ok I understand

I'm closing this out. If you feel the need to update the two scripts, @ClearGateTeam, send a patch! It's pretty easy. :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ejholmes picture ejholmes  Â·  3Comments

miholtz picture miholtz  Â·  3Comments

bugshere picture bugshere  Â·  3Comments

BaconBombz picture BaconBombz  Â·  3Comments

Acidical picture Acidical  Â·  3Comments