RedTeam Pentesting Blog

RedTeam Pentesting GmbH - Blog

9 May 2023

Introducing resocks - An Encrypted Back-Connect SOCKS Proxy for Network Pivoting

Compromising a host in a company’s perimeter often creates the opportunity to pivot into an internal network. From there on, each additional compromised system may grant us access into further subnets. Pivoting like this is second nature to pentesters, but let’s step back and look at this scenario in detail in order to understand why we created our newest open-source tool resocks - a secure reverse SOCKS5 proxy (reverse as in reverse shell, not as in reverse proxy).

Suppose we want to route our traffic through a compromised system into adjacent networks that we can’t reach directly. While there are countless techniques to achieve this, many come with significant downsides. Forwarding ports is cumbersome and may allow other parties to also access the forwarded ports. As penetration testers, we don’t want to expose our customers’ networks like this. SSH supports dynamic port forwarding, but it is often not available on Windows hosts and reverse SSH connections to traverse NAT require some thought and setup. For example, the trust-on-first-use approach for verifying the SSH host key is not an option when you assume a machine-in-the-middle which may intercept the connection. Instead, we wanted a solution with as little friction as possible. This is where resocks comes into play.

resocks in Action

The program resocks is written in Go and compiles to a single binary that is deployed on the attack system as well as the compromised host. It can be run in one of two modes: listener and relay. First, on the attack system resocks is run in listener mode, opening a TCP port to accept incoming connections. On the compromised host (called “relay host” from now on), resocks is run in relay mode and instructed to connect back to the attack system, establishing a secure channel that can traverse NAT.

When the secure channel is established successfully, the listener instance running on the attack system opens up a SOCKS5 server port and routes all traffic through the secure channel to the relay host and from there to the target. Think of it as combining the back-connect technique used by reverse shells with the dynamic forward function of SSH.

resocks Overview

You might have noticed we keep saying “secure” channel. resocks secures the channel using a common connection key that can be generated ad-hoc. However, just generally claiming that something is secure has actually very little meaning unless we’ve defined a clear threat model which we aim to defend against. So let’s do that!

Threat Model: Attacking the Attackers

Establishing a clear threat model is one of the most important steps in the development of security-related applications. We cannot recommend enough to both formulate and communicate a threat model. Unfortunately, especially offensive tools often lack a threat model and do not consider the attackers using such tools (such as pentesters) being themselves targeted by other malicious attackers.

In contrast, resocks was designed with the following attacker models in mind:

  • A: Malicious Observer: Attackers with network access between the listener and the relay host should not be able to see the SOCKS5 traffic that is routed through the secure channel.
  • B: Malicious Listener: Attackers should not be able to run their own resocks listener and redirect a resocks connection to it, as this would grant them access to the relay host’s network and services.
  • C: Malicious Relay: Attackers should not be able to connect to an existing listener in order to be able to receive the traffic that was meant to be routed through the relay host.

In a pentest, all three scenarios would endanger the customer. Scenarios A and C allow attackers to observe the pentesters at work. This endangers the customer, as the network traffic may contain vital hints about the vulnerabilities that are exploited by the pentesters. Scenario B allows attackers themselves to directly attack internal networks of the customer through the relay deployed by the pentesters. This demonstrates that even offensive tools used by pentesters can be worthwhile targets for actual attackers.

One thing these attacker models have in common is that they assume an attacker somewhere in between the listener and the relay. However, attackers could also already have access to the host on which the listener or the relay runs. This creates the following two additional attacker models:

  • D: Malicious User on Listener System: Malicious users on the system hosting the listener are generally able to connect to the SOCKS5 proxy or extract the connection key.
  • E: Malicious User on Relay System: A malicious user on the system hosting the relay can generally extract the connection key.

In contrast to attacker models A, B and C, resocks was not designed to defend against D and E and only provides somewhat limited defense-in-depth measures against such attackers.

Securing the Tunnel

Defending against a malicious observer of the traffic between listener and relay (model A) obviously mandates encryption of the traffic. When taking malicious listeners or relays into account, we need to establish trust between the legitimate listener and relay. These are the primary concerns from a security perspective, however, they have to be balanced with ease-of-use, convenience and implementation complexity.

One of the first things that comes into mind when looking at these security demands is TLS. With client certificates in addition to server certificates, TLS can be used to establish a mutually trusted connection (commonly called mTLS). Additionally, modern TLS offers perfect forward secrecy. However, manual certificate management is certainly not convenient to do in practice. A certificate would either have to be deployed alongside the relay or embedded into the relay binary. The former method introduces more initial steps required to use resocks on a newly compromised host while the latter requires users to re-build resocks on-demand. Both scenarios are obviously deal breakers for ease-of-use and convenience. In order to limit implementation complexity, we also decided against implementing a custom protocol.

Finally, we came up with a way to tame the setup cost of TLS: A certificate generation scheme based on a compact shared key. We first generate a so-called connection key that we share between the listener and relay. The connection key acts as a seed for an ed25519 key that is used to create a self-signed CA certificate. So you can say that the connection key is the ed25519 key.

Why do we use ed25519 specifically? In contrast to for example RSA, it does not rely on entropy for signing, which enables us to deterministically generate the same (byte-identical) CA certificate on both the listener and the relay given the same connection key. Under the hood, TLS with ed25519 uses an algorithm called Edwards-curve Digital Signature Algorithm (EdDSA), which was created as a successor to the Elliptic Curve Digital Signature Algorithm (ECDSA):

As with other discrete-log-based signature schemes, EdDSA uses a secret value called a nonce unique to each signature. In the signature schemes DSA and ECDSA, this nonce is traditionally generated randomly for each signature—and if the random number generator is ever broken and predictable when making a signature, the signature can leak the private key, as happened with the Sony PlayStation 3 firmware update signing key.

In contrast, EdDSA chooses the nonce deterministically as the hash of a part of the private key and the message. Thus, once a private key is generated, EdDSA has no further need for a random number generator in order to make signatures, and there is no danger that a broken random number generator used to make a signature will reveal the private key.

Additionally, the connection key is small enough to be conveniently passed as a command-line argument. In the next step, both the listener and the relay independently generate completely random keys to be used for independently generated client or server certificates. Finally, both components can use the identical CA key to sign their client or server certificates. As a result, the client and server certificates can be used to establish a mutually trusted connection.

Key-Based TLS

We found that simply passing the 256-bit seed values for ed25519 keys as a 43 character string to both components is convenient enough in practice. As a result, we have begun to use this approach to secure the traffic of other tools we have developed for internal use. We also published our Go implementation kbtls (Key-Based TLS) as a library which is used by resocks. While we are unaware of any security risks caused by this technique, it does use TLS in a slightly unconventional way, so please let us know if you are aware of any security concerns.

With this out of the way, let’s take a look at how resocks can improve your life as a pentester.

Designing resocks

The corner stone of resocks' user experience is the listener. One of the key concerns of the listener is to convey the current state of resocks. Is the listener waiting on reverse connections from the relay system? Or is the relay already connected and the SOCKS proxy is ready to use? Initial testing showed that a traditional logging-style output did not convey the current state effectively in scenarios where the relay system frequently disconnects and re-connects (which sometimes happens during a pentest). Based on this experience we chose a stateful display. After all, what could convey state better than a stateful display? Here’s what it looks like in practice:

The next user experience issue is the connection key. Of course, having to specify a matching connection key still introduces some friction, even if it is way better than manual certificate management. That’s why resocks offers multiple ways to handle the connection key. As shown above, resocks listen displays a newly generated connection key by default that can be copied and passed to the relay as follows:

# relay: connect back to listener at 10.0.2.2
$ resocks 10.0.2.2 --key "ilKync+DujFREmiXlYB+/+UpXsUhuFJIeOwFloZWItk"
connected to 10.0.2.2:4080

However, this connection key becomes invalid when the listener is restarted, as it generates a new connection key by default. A static key could also be passed to the listener via --key to avoid generating a new key, but a static key can also be conveniently stored in an environment variable:

$ export RESOCKS_KEY="$(resocks generate)"

In order to avoid having to set the same environment variable on the remote relay system, resocks can also just embed a pre-generated connection key during compilation as follows:

$ go build -ldflags="-X main.defaultConnectionKey=$(resocks generate)"

This binary can then be used to start both the listener and the relay without having to pass the connection key for each run.

Remember the threat models we discussed before? We stated that resocks was not explicitly designed to protect against scenarios D and E: A malicious user on the listener or relay system. For some specific cases of these scenarios, alternate ways to specify the connection key can offer some protection. If the malicious user can see process listings including command-line arguments, the connection key will be exposed if it is passed via the --key option. In this case, an environment variable or a connection key compiled into the binary may be a better choice as long as the binary is not readable for the attacker. Unfortunately, if the malicious actor uses the same account or a high-privileged account you are out of luck.

One of the reasons we developed resocks in the first place was that the proxy feature of Metasploit’s meterpreter was often quite unreliable and could crash the whole meterpreter session. This experience made us think about resilience (for example against unreliable network connections) during the development of resocks. For instance, we added the option --reconnect-after to the relay to make the relay recover from intermittent connection issues. With the following command you can start a relay that re-connects after one second when the connection is interrupted:

$ resocks 10.0.2.2 --reconnect-after 1s --key "ilKync+DujFREmiXlYB+/+UpXsUhuFJIeO..."

The listener will wait for the relay to reconnect by default unless you specify --abort-on-disconnect. By default, the reconnect feature is disabled in order to avoid situations where a misconfigured resocks instance keeps on living forever attempting to connect.

One of the advantages of using Go for resocks is that it can easily be cross-compiled for almost any operating system without any special setup. Just specify the target operating system using the $GOOS environment variable during compilation:

$ GOOS=windows go build

For a list of available operating system ($GOOS) and architecture ($GOARCH) combinations, run the following command:

$ go tool dist list

Of course, we have not tested all of these targets, but we expect that resocks works at least as a relay in most cases.

Open Source at RedTeam Pentesting

We are always proud to be able to contribute to the InfoSec community by releasing our offensive tools. If you like resocks, check out our name resolution spoofer pretender (blog post) or our HTTP fuzzer monsoon (blog post) and stay tuned for future releases which we announce here and on our social media.