[HN Gopher] Circumventing Deep Packet Inspection with Socat and ...
       ___________________________________________________________________
        
       Circumventing Deep Packet Inspection with Socat and Rot13
        
       Author : jortr0n
       Score  : 135 points
       Date   : 2022-02-27 10:50 UTC (12 hours ago)
        
 (HTM) web link (gist.github.com)
 (TXT) w3m dump (gist.github.com)
        
       | dvh wrote:
       | 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.
        
         | rwmj wrote:
         | This was my best attempt at this:                 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 -20
         | 
         | I didn't see anything very interesting in the top results.
         | 
         | Edit: The sort -u option hides words of the same length.
         | Removing that option (and the head command) gives more results,
         | but nothing that interesting.
        
       | sporksmith wrote:
       | Folks 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/
        
       | zokier wrote:
       | > 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?
        
         | ranger_danger wrote:
         | Why block all HTTP(non-S) traffic when you can inspect its
         | plaintext? At least I assume that was their thinking.
        
         | aaomidi wrote:
         | Probably to not break on unknown protocols.
        
       | MadsRC wrote:
       | 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.
        
         | pdkl95 wrote:
         | http://www.ranum.com/security/computer_security/editorials/d...
         | 
         | "The Six Dumbest Ideas in Computer Security"
         | 
         | > #1) Default Permit
         | 
         | > #2) Enumerating Badness
        
           | MiddleMan5 wrote:
           | 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"
        
           | c0balt wrote:
           | Thank you for sharing the post. It made my day so far, I
           | actually want to re-read it and take notes.
        
       | aaaaaaaaaaab wrote:
       | 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.
        
       | throw0101a wrote:
       | 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
       | 
       | for the server and tell the client not to check ("verify=0").
        
       | annoyingnoob wrote:
       | This message is double rot13 encoded for your protection.
        
         | jeffrallen wrote:
         | Hmm, I managed to decode it with quadruple rot13... Maybe check
         | your settings, could be insecure!
        
       | belter wrote:
       | 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.
        
         | throwaway984393 wrote:
         | 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
        
       | ocdtrekkie wrote:
       | 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.
        
       | sockpuppet_12 wrote:
       | 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.
        
       | xelxebar wrote:
       | Not 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.747s
        
       | jeffrallen wrote:
       | OP should use rot14, it's more secure. /s
        
         | kzrdude wrote:
         | 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.
        
           | kadoban wrote:
           | 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.
        
       | usr1106 wrote:
       | So once the maintainers of the deep packet inspection software
       | read this they will add rot13 to their code.
        
         | vermilingua wrote:
         | Which would slow down inspection by a factor of 25 if it were
         | to check the whole keyspace.
        
           | Brian_K_White wrote:
           | 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.
        
           | usr1106 wrote:
           | 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.
        
             | hedora wrote:
             | 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.
        
             | jortr0n wrote:
             | 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.
        
         | jortr0n wrote:
         | 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.
        
           | usr1106 wrote:
           | 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.
        
             | Thiez wrote:
             | > 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.
        
         | xmcqdpt2 wrote:
         | 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?
        
           | xchaotic wrote:
           | 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.
        
             | largbae wrote:
             | 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.
        
               | anderspitman wrote:
               | You don't even need root. All the important bits can be
               | done in userspace.
        
       ___________________________________________________________________
       (page generated 2022-02-27 23:01 UTC)