Using SSH Socks Proxies with MSF Reverse TCP Payloads

anestisb — Fri, 08 Jun 2012 20:04:22 +0000

Regularly pentesters need to redirect their network traffic through various proxy hosts to access private network subnets, bypass firewall restrictions or hide their traces. Identifying those needs, professionals have armored their tool arsenal with various tunneling and forwarding tools in order to work efficiently under various network architectures and testing cases. Each working case strongly depends on the proxy host’s running services and obtained access level to those services.

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:

Available remote SSH access to the proxy host (single user or root, each case is analyzed separately)
Proxy host has at least one unused firewall incoming (from the victim) allowed port
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:

Root Access: Modify OpenSSH configuration and use the remote port forward feature
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:

—{ 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).

root@proxy:~# mkfifo pipe

root@proxy:~# nc -nvlp 4444 0pipe

A. Bechtsoudis

Kippo – SSH Honeypot

anestisb — Sun, 27 Mar 2011 14:25:04 +0000

As part of the network administration in the Network Operation Center (NOC) of the Computer Center Laboratory, we must secure the server & network infrastructure from internal or external malicious activities. Crucial base server & network nodes have been independently secured against the majority of the attacks. But the challenge is to be able to secure the non-crucial hosts, such as the user’s machines with access to servers and network devices from lower levels of the infrastructure. The obstacle to the whole concept is that we are on an university network, which include people with different levels of computer & IT knowledge, plus the big number of services and experimental technologies that are taking place. So we must implement security countermeasures that are unseen to the end users or simple enough to be adopted by any user into the university infrastructure.

On the of the security forensics approach is: “Allow attacks in a sandbox environment, analyze them and learn from them!“. Following this approach, we have come across with the honeypot mechanisms. Honeypots are mechanisms implemented in the networks that are designed to lure malicious activities in order to analyze them. They have low and easy to bypass security & access, forming a great trap for botnets and inexperienced hackers. The experience level that the attacker should have in order to get trapped in a honeypot host or network, depends on the honeypot’s interaction level and its implemented services. That’s why the honeypots are classified into low and high interaction. With low interaction offering emulated services (limited interaction) and high interaction offering full functionalities.

We have chosen a solution somewhere in the middle of the interaction scale. We were looking for something easy to setup due to our demands and easy to analyze its collection data for analysis. So we choose the Kippo, which is a medium interaction SSH honeypot. Kippo logs ssh bruteforce attacks and offers shell interaction to analyze the executed commands of the attacker. Its features include fake debian 5 based shell, fake filesystem that can be easily altered by the user, saving the wget downloaded files for analysis and UML compatible log files.

On part of our goal has been achieved by analyzing the malicious files that attackers have downloaded from infected web servers. We will continue running Kippo for a short period because we have discovered that moderators of large botnets retain a blacklist where they record IPs of hosts that aren’t real machines (such as honeypots). We come into great surprise when we realize that all the attacks we have recorded so far, were executed by a human and not any botnet script. And the goal of all the attackers was to turn the machine into a scanning zombie that launches bruteforcing attacks over the network. Additionally, most of the attackers tried to run an IRC server in order to mass control their infected hosts. We have recorded their IRC channels and the using code and we will keep an eye on their tactics.

In the near future we plan to establish a higher interaction level honeypot and honeynet, in order to analyze more advanced attacking techniques.

Here are some tty sessions of attacking tries that we have recorded from our honeypot, plus a python script that can be used to show the shell interaction from the attack:

Download Logs + PlayScript

Additionally with my affiliate John Kalantzis from the UNIX Administration Team we have conducted a presentation in PLUG about SSH Security and the use of Kippo honeypot. The slides from the presentation can be downloaded from here:

Presentation (.pdf 84 kb)

The Kippo honeypot project run with the collaboration of John Kalantzis.