One of my favorite cases (and I believe to many others too) is the OpenSSH Socks Proxy scenario. Remote SSH access to the proxy host is available offering flexible ways to redirect network traffic via the SSH channel. However, there exist a main drawback in the Socks Proxy case, you “can’t” use the available reverse TCP payloads delivered with the Metasploit framework (and any other similar tools). Actually, this is not 100% true. There exist some OpenSSH forward features that can be used/combined to bypass this restriction.

Many of you might say that there exist many alternatives to TCP reverse payloads such as PHP, Java, HTTP, DNS etc. That’s true, although many of them are application specific and are not fully stable under certain circumstances. Additionally, these alternatives might not be always applicable due to some exploitation restrictions.

Some others might also say that Metasploit’s meterpreter pivot features (framework routes + port forward) can be used to redirect traffic through the proxy host, avoiding Socks usage. The drawback in this case is that if the proxy host is a linux box the matching meterpreter payload is not stable enough (at least it wasn’t when this post was written).

Now that you have been convinced that under certain circumstances the Socks proxy is the only stable option, lets see how we can deal with the reverse TCP restrictions.

When a reverse TCP payload is used, the victim host tries to connect back to the requestor’s source IP address. If SSH Socks proxy is used the source IP address from the victim’s perspective is the proxy’s IP address. Consequently, the reverse TCP payload will try to connect back to the proxy and not to the attacker’s address. The Metasploit framework successfully identifies this problem and raises an error exception when a socks proxy is used with a reverse TCP payload.

The main concept to bypass this restriction is to use a forwarding mechanism in the proxy to deliver the network packets to the correct addresses when a reverse connection reaches the proxy. The presented methods are feasible when the following requirements are met:

1. Available remote SSH access to the proxy host (single user or root, each case is analyzed separately)
2. Proxy host has at least one unused firewall incoming (from the victim) allowed port
3. Proxy host can access the target host

For the rest of the article the following network topology will be used for the examine cases:

Initially lets establish the SSH Socks proxy with the pivot host and test the socks proxy connectivity via the proxychains tool:

The SSH socks proxy works and we can use it to access the victim host:

Now if we try to use the Socks proxy with a reverse TCP payload, Metasploit raises an exception:

OpenSSH port forward features can help us to bypass this restriction. Two cases will be examined according to the access level that the attacker has on the proxy host:

1. Root Access: Modify OpenSSH configuration and use the remote port forward feature
2. Single User Access: Use OpenSSH local port forward mechanism by establishing a second SSH channel

For those not familiar with local & remote SSH port forward features you can refer to the end references.

Before continuing lets disable metasploit’s reverse TCP socks proxy check to confirm both test cases under the framework. Lucky for us framework’s modular architecture makes such code hacks easy to implement. So just comment lines 68-70 at “lib/msf/core/handler/reverse_tcp.rb“

1. Root Access to Proxy Host

OpenSSH remote port forwarding feature is used to redirect incoming traffic to port 4444 on proxy host to port 53 on the attacker. As the OpenSSH manuals mentions, by default remote port forwarding will bind the proxy port (4444 in our case) on the localhost address. Binding to localhost will block victim incoming connections. So we need root access to modify the sshd configuration and enable GatewayPorts option.

When the payload is triggered the network paths are as follow:

Before proceeding to the framework usage lets check with some simple netcat connection that the setup works:

If instead of the attacker’s IP address you use the localhost address, the forward channel will work like a charm (actually this is the correct approach), although metasploit’s session manager will fail to identify the connection and will crash. Some tcpdump debugging might help at this point to clarify how this forwarders and port binds work.

Having confirmed that our proxy forwarder works lets proceed to the framework. A linux x86 reverse TCP stagged shell payload has been generated and uploaded to the victim host. To trigger the payload a relative PHP script has been placed at the web path. The tricky part while generating the payload is to use as LHOST the proxy’s IP address and as LPORT the port (4444 in this example) that is forwarded to the attacker by the proxy.

Finally lets trigger the payload via a custom auxiliary module (a single GET request) and establish the reverse connection through the socks proxy:

2. Single User Access to Proxy Host

Single user access to the proxy host means that we can’t set the GatewayPorts option at the SSHD configuration. So we need to find an alternative way to implement the forwarder. This time OpenSSH local port forward feature (-L) is used under a second SSH connection to localhost at the proxy host. The -g flag is used to bind the socket at 0.0.0.0 allowing incoming connections apart from localhost. Consequently the reverse connection path is as follow:

The usual netcat tests before proceeding to the framework:

And finally the socks proxy is also successfully working with reverse TCP payloads under the framework:

Here are all the above screenshots in a slide gallery:

Mission accomplished! We have managed to use reverse TCP payloads under SSH Socks proxies taking advantage of the various OpenSSH features. Of course someone might implement the port forwarding at the proxy host with various other ways (iptables, 3rd party tools etc). The OpenSSH way was chosen because it is already available in the SSH Socks proxy scenario and regularly pass undetected from the sysadmins, while a third party tool might trigger some alerts (of course iptables isn’t feasible in a single user access level case).

It would be ideal if the above concept can be somehow implemented in the metasploit framework, making reverse TCP payloads available under certain socks proxy scenarios.

References:

• http://www.linuxhorizon.ro/ssh-tunnel.html
• http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html
• http://www.metasploit.com
• http://seclists.org/metasploit/2009/q2/143
• http://www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
• http://www.offensive-security.com/metasploit-unleashed/Pivoting

—{ Update 11 June 2012 }—

Proxy’s port forwarding back to the attacker can be also easily implemented with netcat. Be careful while using the netcat approach at its plaintext connections might trigger IDS/IPS rulesets. For stealthier communications try to establish an encrypted channel with the proxy (ncat, netcat + stunnel etc).

A. Bechtsoudis