Circumventing Deep Packet Inspection with Socat and Rot13
gist.github.comNot at all the main point, but tr can do rot13 and more; plus GNU Coreutils' implementation is fast:
$ time openssl rand -base64 1000000000 | tr a-z n-za-m >/dev/null
real 0m1.073s
user 0m1.327s
sys 0m0.644s
$ time openssl rand -base64 1000000000 | rot13 >/dev/null
real 0m19.225s
user 0m20.101s
sys 0m0.747sFolks interested in the state of the art of this kind of DPI evasion might want to check out obs4, which is a "look-like nothing obfuscation protocol", and the default pluggable transport for connecting to tor bridges from places where tor is blocked.
obs4: https://github.com/Yawning/obfs4
obs4 in tor: https://support.torproject.org/glossary/obfs4/
I love this! Using a 2000+ year cipher to circumvent Deep Packet Inspection seems almost poetic.
I feel like the article missed out on mentioning one key thing: Using a deny-list doesn’t work. It’s much more viable to default block and allow the stuff you know you’ll allow. Defaulting to allow and blocking stuff you don’t want is how you end up being owned by rot13.
http://www.ranum.com/security/computer_security/editorials/d...
"The Six Dumbest Ideas in Computer Security"
> #1) Default Permit
> #2) Enumerating Badness
Reading point #4 on a site called "Hacker News" seems rather ironic.
I wonder how you might encourage deeper introspection into software infrastructure security vulnerabilities, both from closed source companies and from obscure open source projects, without "spreading breadcrumbs for the roaches"
Thank you for sharing the post. It made my day so far, I actually want to re-read it and take notes.
In case someone is not aware, socat allows for TLS connections with the OPENSSL-LISTEN and OPENSSL options:
* http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPE...
* http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPE...
Just create a self-signed certificate:
openssl req -newkey rsa:2048 -nodes -keyout socat.key -x509 -days 1000 \
-subj '/CN=www.mydom.com/O=My Company Name LTD./C=US' -out socat.pem
The method is interesting as a mental exercise and its archaeological interest. If you are a company employee be careful about trying these or any other type of tunneling or deep packet inspection circumvention methods.
Some companies mention in their employment contracts these type of circumvention activities, unless explicitly allowed, are a firing offense.
At one job I tunneled out of work to my home PC, and the head security guy found out and made a big stink, and I got fired
It's interesting how the pendulum of ideas swings back and forth over history, similar problems arise and similar solutions to them resurface also. It would be great to see that on some kind go graph or timeline.
> They permit SSL to some known websites (for https), but the moment I try to create an SSL or SSH connection to an unknown server (eg. to the bastion box), their gateway instantly terminates the TCP connection!
They are clearly already whitelisting connections, but still allow unidentified connections through?! What sort of logic is that?
Why block all HTTP(non-S) traffic when you can inspect its plaintext? At least I assume that was their thinking.
Probably to not break on unknown protocols.
This message is double rot13 encoded for your protection.
Hmm, I managed to decode it with quadruple rot13... Maybe check your settings, could be insecure!
I don't get it. Why did you need SSH at all? The task was completed the moment a TCP connection was established to your server.
So once the maintainers of the deep packet inspection software read this they will add rot13 to their code.
The author only used rot13 to make a point about the failure mode of inspection. DPI is only there to stop everyday employees from bypassing security policies inadvertently, not to stop an actual attacker. An attacker could use any number of other approaches: hiding payloads in innocuous keywords, using actual encryption, steganography, what have you.
I'm not a security expert but we had those kind of measures at a previous job and AFAIK they are there so that a lazy employee (me) doesn't just skip configuring their tools to go through Artifactory out of laziness and introduce a supply chain vulnerability. If "pip install XYZ" just worked out of the box, how likely would it be that all 10k devs in your organization would bother configuring it to avoid PYPI?
I don’t get the scenario he tested where he has access to both sides and can freely install cyphers on the server and what not. If you have just installed vpn endpoint and send whatever packets you feel like.
I think the point is that the perimeter security doesn't provide the security that the client imagined. Gaining root on any endpoint in the network (and then finding an endpoint you can control anywhere else on the internet) gives you a way in and out of the company network.
You don't even need root. All the important bits can be done in userspace.
The use of rot13 was just an amusement in this case given its vintage. Replacing rot13 with any other simple stdin/stdout transcoder should be simple to do via the socat invocation, eg base64, a sed replace command, gzip/gunzip, even an actual symmetric encryption protocol like AES, etc.
So if you contol both ends any kind of obfuscation will defeat deep packet inspection, as long as the same obfuscation is not widely used so that the inspection software can check for it.
But if you do not control both ends, let's say you want many customers or even the public to connect to your server that's not an option.
> as long as the same obfuscation is not widely used so that the inspection software can check for it.
I imagine there are only so many things you can detect with DPI before the network connection becomes (even more) prohibitively slow. And you can check for rot13 or base64 or common compression algorithms (but beware of zip bombs), but you can't check for properly encrypted data since it will appear as random bits.
Which would slow down inspection by a factor of 25 if it were to check the whole keyspace.
There is no special limit of 25 possible keys.
The keyspace is essentially infinite, because of 2 things:
1 you don't have to worry about control bytes (aka "binary")
2 unicode
rot13 using 1/2 of the 26 letter English a-z alphabet is just an arbitrary limit for visual appearance and limitation of the channel in bbs/newsgroup posts.
Things like rot18 and rot47 already widen the alphabet significantly up from 26 to include numbers, punctuation, and more of the "printable" ascii from 0-127, while still avoiding control bytes like null etc.
But this example is using rot13 in a channel passing binary data already, so there is no point avoiding the control bytes like null etc.
So without going to unicode the limit would already be 255.
But the alphabet, and thus the key space, is practically infinite with unicode. Merely your bandwidth goes down when you get to say, 16 encoded bytes per plaintext byte.
In fact, you don't even need to bother 'rotating' anything, you can just pick a random number anywhere from 1 to the zillions, and simply add that number to the plaintext values and subtract from the ciphertext. Rather than rotating, it's just transposing, but that's all rotating is anyway.
You don't even need to install any package like bsdgames either. You can do the encode/decode directly in bash, not even very many lines.
Where does the keyspace come from? rot13 has no keys.
Of course you could do rot2 - rot24 and all the other combinations. Is that were the factor 25 comes from?
The deep inspection needs to look only at the first couple of bytes of each new a TCP connection. So it's not that disrupting. After 2 bytes you can already skip for a vast fraction of other traffic.
You'r right, the rot13 command is a shell wrapper around: ` exec /usr/bin/caesar 13 "$@" ` Forcing the key to be 13. You can obviously invoke /usr/bin/caesar with any of the 25 keys.
The underlying tool (caesar) will infer the key if you forget to pass it in. It does so without brute forcing.
Applying this to DPI wouldn't be too bad.
This is why rolling your own crypto often works in practice if you are a smaller operator: Nobody ****ing expects it, and there's a good chance nobody cares enough to investigate manually what you did or add support to commercial products to handle it.
I once did rot13 on /lib/firmware/* (not just 13 but 0-255), piped it via 'strings' command and find longest word in English corpus (/usr/share/dict/*). I forget what I found but it's trivial to replicate.
This was my best attempt at this:
I didn't see anything very interesting in the top results.cd /lib/firmware ( find -name '*.xz' -exec xzcat {} \; ; find -type f -a \! -name '*.xz' -a -exec cat {} \; ) | rot13 | grep -aEo '\w+' | awk '{print length, $0 }' | sort -nsru | head -20Edit: The sort -u option hides words of the same length. Removing that option (and the head command) gives more results, but nothing that interesting.
So it may not be an effective security measure but at least it stops your staff from doing online banking or shopping on work devices.
Or it would if they realised their credentials are in the DPI log files.
OP should use rot14, it's more secure. /s
double rot13 has an unfortunate meet-in-the-middle weakness but triple rot13 was invented for this very purpose. I hope he makes the upgrade.
For anyone not in on the joke, this is a real crypto concept/weakness/attack https://en.m.wikipedia.org/wiki/Meet-in-the-middle_attack (obviously only a joke with rot13). It's most famously the reason that 3DES is a thing, instead of just double.
Thanks, and I'm happy this joke I've been saving landed on its feet when I threw it out.