Possible Security Bug: Client Override

mario_b

Hi,

i am using pfSense with OpenVPN and Client Overrides. Client Overrides works with Usernames. Everything works fine except one thing:

If the user adds a "space" in the OpenVPN Client after his Username he will be authenticated successfully ! But OpenVPN then didn't find any Clientoverides for that User and i see in the OpenVPN Logs

openvpn: user 'username ' authenticated

See the space after username … and yes there is no client override for username followed by a space. Main Problem is, then default Configuration works and that could causes that he becomes some IP Adresses which are used special. So that's also a Security Bug for me.

OpenVPN should trimm that Username he got (well to be hones, OpenVPN Client should already trim that)

Regards Mario

kpa

That does sound like a problem in the username handling with the OpenVPN service. As a quick workaround you can try to add this option into the custom options of your server:


ccd-exclusive

This will require that for successful authentication the user must have a client override file. This should make 'username ' fail but 'username' authenticate properly.

jimp

That is a little odd, but the real problem is that you are mixing security levels on the same VPN.

If you need to securely isolate someone, they should not be on the same VPN with anyone else with higher access. Setup a second VPN with a completely different CA structure, TLS key, tunnel network, etc, and then firewall it off that way.

Using ccd-excluside can help, as kpa said, but then you must define an override for every user.

Alternately, use the reverse tactic. Give users with access to more things special override settings to do that, and let the default be the insecure settings. I wouldn't do that, though, I'd still go for the second VPN for restricted access.

mario_b

Well, no i have over 40 Users and every user have different access levels … i couldn't be the solution creating for every User a own VPN.

Passing the space at the end of the Username is still a bug, and only that bug is causing that Problem.

@kpa: Nice idea - will try that Workaround tomorrow. Thanks.

Pippin

A file called "DEFAULT" with "disable" on one line in OpenVPN`s ccd directory as a workaround ?

See "–client-config-dir dir" and "--disable" in manul 2.4:
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Also, first report this on OpenVPN forum ?
https://forums.openvpn.net
and/or the mailing list:
https://sourceforge.net/projects/openvpn/lists/openvpn-users

mario_b

Morning,

so i restarted this morning the OpenVPN with "ccd-exclusive" under custom Options. And yes that solves the Security Issue.

@jimp: As i have many different users access, i have an Override per every user. That's why i said i am not mixing levels - the Security Issue without ccd-exclusive is, that you can gain access of other users with that "space" trick.

I have yesterday also send a complete Security Exploit Description to pfSense Security Team.

Thanks all for the help.

Regards Mario

jimp

I just tried this myself and putting a space after the username fails authentication with local users and RADIUS users, but can be accepted by an LDAP server.

Are you using an external authentication server? Your problem may be there, not with pfSense.

Apr 6 08:43:33 	openvpn 		user 'jimp ' could not authenticate.
Apr 6 08:43:33 	openvpn 	28014 	172.21.32.35 WARNING: Failed running command (--auth-user-pass-verify): external program exited with error status: 1
Apr 6 08:43:33 	openvpn 	28014 	172.21.32.35 TLS Auth Error: Auth Username/Password verification failed for peer

I also verified the space was passed all the way through the authentication process. Nothing in our code strips it away that I can see.

I see other similar complaints about LDAP servers and trailing spaces in filters around the Internet, but at least the references I can find lead back to it being a fact of life with how LDAP handles filters.

I have tried numerous ways of escaping the space in the LDAP filter but each time the LDAP server ignores the trailing space when matching the user. The encoding was working properly because I was also testing a user with a space in the middle of the username and that worked when the space was encoded, but the trailing space was also allowed.

I opened https://redmine.pfsense.org/issues/8439 to track it, but as far as I can tell so far it's the fault of LDAP server filter processing.

You might want to lobby to OpenVPN and see if maybe they can add an option to strip extraneous whitespace from usernames, since it has to happen in OpenVPN for it to be caught early enough to matter.

jimp

One more thing I thought of. If you use user certificates as well as user authentication, you could enable the option to enforce a match between the username and certificate common name.

maverick_slo

Ummm I use Ms ad server 2012r2 ldap and adding space to end of username fails auth…

jimp

Make sure you are trying that twice in a row, if you auth, then reconnect with another username, the server will always reject you as changing names.

I didn't have an AD structure handy to test against but I did have OpenLDAP, and it ignores the trailing space as OP describes.

maverick_slo

It fails every time.
I can`t login with my username if it has trailing space.

jimp

It's entirely possible that AD does the right thing and OpenLDAP-based systems fail that test.

Strengthens the case that it's not a pfSense issue, but a problem on the authentication server.