Tunneling Through Deep Packet Inspection

Introduction

Deep packet inspection is technology that is implemented to monitor traffic based on a set of rules and it is most often found being used on a network perimeter where it can highlight patterns that are indicative of compromise.

Deep packet inspection devices may be configured to only allow specific transport protocols into, out of, or across the network. For example, a network administrator could create a rule that terminates outbound SSH traffic.

HTTP Tunneling

One Deep Packet Inspection (DPI) solution is terminating all outbound traffic except HTTP. In addition, all inbound ports are blocked except TCP/8090. We can't rely on a normal reverse shell as it would not conform to the HTTP format and would be terminated at the network perimeter by DPI. We can't create an SSH remote port forward for the same reason. The only traffic that will reach our attackbox is HTTP, so we could, for example, make requests with Wget and cURL.

In this case, the FIREWALL/INSPECTOR device has replaced the simple firewall. In addition, MULTISERVER03 is blocked on the WAN interface.

We have credentials for the PGDATABASE01 server, but need to figure out how to SSH directly there through CONFLUENCE01. We need a tunnel into the internal network, but it must resemble an outgoing HTTP connection from CONFLUENCE01.

HTTP Tunneling with Chisel

The scenario above is the perfect scenario for Chisel, an HTTP tunneling tool that encapsulates our data stream within HTTP. It also uses the SSH protocol within the tunnel so our data will be encrypted.

Chisel uses a client/server model. A Chisel server must be set up, which can accept a connection from the Chisel client. Various port forwarding options are available depending on the server and client configurations. One option that is particularly useful for us is reverse port forwarding, which is similar to SSH remote port forwarding.

We will run a Chisel server on our attackbox, which will accept a connection from a Chisel client running on CONFLUENCE01. Chisel will bind a SOCKS proxy port on the attackbox. The Chisel server will encapsulate whatever we send through the SOCKS port and push it through the HTTP tunnel, SSH-encrypted. The Chisel client will the decapsulate it and push it wherever it is addressed. When running, it should look somewhat like the following diagram:

The traffic between the Chisel client and server is all HTTP-formatted. This means we can traverse the deep packet inspection solution regardless of the contents of each HTTP packet. The Chisel server on our Kali machine will listen on TCP port 1080, a SOCKS proxy port. All traffic sent to that port will be passed back up the HTTP tunnel to the Chisel client, where it will be forwarded wherever it's addressed.

Start Chisel on Attackbox

Starting the Chisel server with the --reverse flag means that when the client connects, a SOCKS proxy port will be bound on the server.

Before we start the server, we copy the Chisel client binary to CONFLUENCE01. The Chisel server and lcient are run from the same binary, they're just initialized with either server or client as the first argument.

If our target host is running a different operating system or architecture, we have to download and use the compiled binary for that operating system from the Chisel Github releases page.