Cryptographic issues

[socram8888]

FYI, in case you want to know, I've been glazing through the current cryptography a tiny bit, and I've found at least the following issues:

1. Data is not authenticated, thus you can use somebody else's session after he has authenticated with the proxy.
2. The forwader does not validate the server. This means you can use a MitM to get a session to the proxy. This could be fixed by doing a three-way authentication in which the client also requests sends the server a challange and checks it after having authenticated itself.
3. The forwarder can be used as an oracle: since the client does not add any random value to the challange, a MitM could get the password hashed with any salt the attacker could want, and use that for authenticating itself against the real server.
4. The password is not properly derivated using a password-stretching function. Bruteforcing a MD5, or even a SHA512-hashed password is relatively easy and quick.

For 1 you could add an IV to every packet, and then HMAC-ing the data. For 2 and 3, I'd recommend to get some ideas from existing private-key authentication sequences, such as the three-way authentication Mifare Ultralight C NFC tags use (see 7.5.5). For 4, I'd recommend using PBKDF2, scrypt, Argon, or another well-known password-stretching functions.

Doing cryptography is really hard, and having a false sense of security is even worse than having no security at all. Thus in my opinion, I would recommend that you remove all existing authentication, and lock down the functionality to forwarding to a fixed service, and let it handle all the authentication+encryption. This would be the easiest route for you.

If you want to keep the ability to connect to several services, you may want instead to add an IP whitelist (such as only letting connecting to ocserv, SSH, OpenVPN, etc... and let them do the crypto)

[cdpxe]

We analyzed the security of ptunnel (original version of the program) from a covert channel protocol perspective in this paper (open access): https://onlinelibrary.wiley.com/doi/full/10.1002/sec.1471 where we also highlight some attacks on ptunnel. Maybe they are applicable to ptunnel-ng, too (did not check it, yet). See Sections 4.3 for attacks and 5.1 for some ideas how to improve ptunnel. Section 6.1 covers the attack impacts on ptunnel.

Thanks for keeping ptunnel project going with ptunnel-ng! Looking foward to see future releases!

[cdpxe]

PS. Here is a survey (but from 2014) on how to design improved covert channel-internal control protocols (see Sect. 3): https://link.springer.com/article/10.1007/s12243-014-0423-x#Sec15 (again: not from a crypto perspective, but from an information hiding perspective).

[utoni]

FYI, in case you want to know, I've been glazing through the current cryptography a tiny bit, and I've found at least the following issues:

1. Data is not authenticated, thus you can use somebody else's session after he has authenticated with the proxy.

This is part of the TODO.

2. The forwader does not validate the server. This means you can use a MitM to get a session to the proxy. This could be fixed by doing a three-way authentication in which the client also requests sends the server a challange and checks it after having authenticated itself.

True, the insecure challenge response authentication was always an issue in ptunnel and ptunnel-ng.

3. The forwarder can be used as an oracle: since the client does not add any random value to the challange, a MitM could get the password hashed with any salt the attacker could want, and use that for authenticating itself against the real server.

Not true, the client adds of course a 24 byte random value to the challenge which is used for the generated password hash.

4. The password is not properly derivated using a password-stretching function. Bruteforcing a MD5, or even a SHA512-hashed password is relatively easy and quick.

What is your definition of "easy and quick" for salted hashes?

For 1 you could add an IV to every packet, and then HMAC-ing the data. For 2 and 3, I'd recommend to get some ideas from existing private-key authentication sequences, such as the three-way authentication Mifare Ultralight C NFC tags use (see 7.5.5). For 4, I'd recommend using PBKDF2, scrypt, Argon, or another well-known password-stretching functions.

Doing cryptography is really hard, and having a false sense of security is even worse than having no security at all. Thus in my opinion, I would recommend that you remove all existing authentication, and lock down the functionality to forwarding to a fixed service, and let it handle all the authentication+encryption. This would be the easiest route for you.

You are not forced to use any cryptography at all at the moment. Just skip the -P option.

If you want to keep the ability to connect to several services, you may want instead to add an IP whitelist (such as only letting connecting to ocserv, SSH, OpenVPN, etc... and let them do the crypto)

This contradicts your MitM statement and is also unnecessary since there is already a stable iptables command.

[utoni]

@cdpxe Thanks for this information. I will carefully read the paper.

[socram8888]

Not true, the client adds of course a 24 byte random value to the challenge which is used for the generated password hash.
https://github.com/lnslbrty/ptunnel-ng/blob/master/src/challenge.c#L81-L93

Sorry but I did not see any random values added to the response. I only see a sort-of HMAC with the random data sent by the server.

What is your definition of "easy and quick" for salted hashes?

Within the ability to be cracked by a script kiddie with a few GPUs. The salting does prevent rainbow tables for being used, but does nothing against bruteforcing passwords. Heck, with just a bunch of 1080 you can easily beat a 8 letter password with caps, lower and number within less than an hour.

[utoni]

Not true, the client adds of course a 24 byte random value to the challenge which is used for the generated password hash.
https://github.com/lnslbrty/ptunnel-ng/blob/master/src/challenge.c#L81-L93

Sorry but I did not see any random values added to the response. I only see a sort-of HMAC with the random data sent by the server.

see https://github.com/lnslbrty/ptunnel-ng/blob/master/src/challenge.c#L59-L73

What is your definition of "easy and quick" for salted hashes?

Within the ability to be cracked by a script kiddie with a few GPUs. The salting does prevent rainbow tables for being used, but does nothing against bruteforcing passwords. Heck, with just a bunch of 1080 you can easily beat a 8 letter password with caps, lower and number within less than an hour.

I agree. But this is not a major issue since one can simply use secure passwords.