Slipstream

Nytro · December 6, 2020

Slipstream

This is a proof of concept for the NAT slipstreaming vulnerability discussed here.

Building

slipstream has no external dependencies and does not depend on CGO. You can build the executable and/or cross compile for other platforms using the go compiler with the following command:

go build

Usage

slipstream will produce a single executable that is both the server and client. You must first setup the server on a remote host that it outside of your NAT:

./slipstream -l -lp 5060

You can then use slipstream to connect to the host outside of your NAT and let it attempt to connect back to you:

./slipstream -ip <local ip> -host <remote host> -rp 5060 -lp <local port>

Why another implementation?

After spending many hours attempting to get the original code working with no success I was left at a point of not knowing if my router was simply not vulnerable, I had misconfigured the code, the code was broken, or there were other implementation details stopping it from working. Eventually I was shown another implementation of the attack that skipped over the web based delivery instead focusing just on exploitation of the ALGs. This code is heavily based on that implementation though provides an end to end client and server to make testing simpler and avoids using an HTTP client to send the request due to issues discovered.

What about web based delivery?

At time of writing the major browser vendors (Chromium and Firefox) have since provided mitigations against this through blocking outbound connections to port 5060. It's theoretically possible that this could be bypassed by switching to a different port or attempting to use a different ALG altogether. I'm assuming SIP was chosen due to it's similarity to HTTP and widespread use. In testing some of the higher end enterprise gear we discovered that due to slight differences (the / used in the HTTP path, the HTTP version, rather than SIP/2.0, and differing headers) some networking equipment fails to parse the SIP requests generated by an HTTP client and simply drops them at the router. Given that it's been blocked by browsers and delivery is unreliable by HTTP client no attempt was made to port the newer webscan technique for local ip discovery for web based delivery or identify a browser bypass.