Bug #10881
closed
Captive Portal with AD authentication can be bypassed with just a valid username, no password required
0%
Description
We have observed that we can login to the Captive Portal with a valid username and no password (we have it set up to authenticate against an Active Directory). Writing random characters in the user field does not work, you need to know an actual user from the Active Directory. The same, if you write a valid user but an invalid password, it does not work. The big problem is that if you leave the password field empty, all you need is a username and you can bypass the Captive Portal.
We are using:
2.4.5-RELEASE-p1 (amd64)
built on Tue Jun 02 17:51:17 EDT 2020
FreeBSD 11.3-STABLE
Please let me know what other information is needed to troubleshoot this security issue (sorry, this is my first bug here).
Updated by Jim Pingle about 4 years ago
- Status changed from New to Not a Bug
- Priority changed from High to Normal
If the remote access server is accepting the login, what could pfSense do differently? pfSense sends the request and the server accepts it.
It's come up before but any of the suggested workarounds based on pfSense are kludges at best and do not prevent other things from authenticating against AD improperly.
It's an AD issue, not a pfSense issue. Fix your authentication server so it rejects those invalid logins.
https://forum.netgate.com/topic/139397/captive-portal-with-ad-ldap-authenticates-without-a-password
Updated by Aurelian Rau about 4 years ago
Jim Pingle wrote:
If the remote access server is accepting the login, what could pfSense do differently? pfSense sends the request and the server accepts it.
It's come up before but any of the suggested workarounds based on pfSense are kludges at best and do not prevent other things from authenticating against AD improperly.
It's an AD issue, not a pfSense issue. Fix your authentication server so it rejects those invalid logins.
https://forum.netgate.com/topic/139397/captive-portal-with-ad-ldap-authenticates-without-a-password
I understand your position, but this is the way AD has worked and until 2019 there is no option to stop unauthenticated binds (and upgrading is not always an option, not necessarily right away). However, there have been are still applications developed which use AD authentication and do not have this issue because using an empty password is never allowed. We too use many Windows-based and Linux-based applications with AD auth, and none works this way - authentication is not possible with just the user and no password.
The fact that the CP on pfSense allows authentication without a password while knowing how AD works is a flaw and a security risk. At least if it were documented in the pfSense documentation, one would understand the risk.
What you are saying practically, is that until everyone upgrades to Windows Server 2019 to be able to turn off unauthenticated binds, CP with AD authentication as it is by default on pfSense is not usable.
Obviously we will try then to see how we can modify the CP login page to work around this and not allow authentication with no password, but hopefully this flaw can be considered and fixed in some future version. pfSense has a good reputation and fixing an obvious security hole would help maintain that. Not even considering a fix, even if at a remote point in time really does not look good.
If nothing at all, then at least point this fact out in the pfSense documentation and warn users.
Thank you for understanding,
Aurelian
Updated by Jim Pingle about 4 years ago
pfSense is not allowing this behavior. AD is. pfSense can't fix your AD security or configuration. Period.
Having pfSense prevent empty passwords does nothing to stop AD from being a giant security gap in this case. Anything else that hits AD would have the same issue, and trying to solve it anywhere other than AD is negligent from a security standpoint. If you have a problem with that, take it up with Microsoft, not us.
There are patches in the thread I linked that some have used to hack around the awful AD behavior, but it won't be changed in pfSense releases since it's not a pfSense problem.
You could use NPS instead of using LDAP and still use AD via RADIUS.
Updated by Viktor Gurov about 4 years ago
Aurelian Rau wrote:
Jim Pingle wrote:
If the remote access server is accepting the login, what could pfSense do differently? pfSense sends the request and the server accepts it.
It's come up before but any of the suggested workarounds based on pfSense are kludges at best and do not prevent other things from authenticating against AD improperly.
It's an AD issue, not a pfSense issue. Fix your authentication server so it rejects those invalid logins.
https://forum.netgate.com/topic/139397/captive-portal-with-ad-ldap-authenticates-without-a-password
I understand your position, but this is the way AD has worked and until 2019 there is no option to stop unauthenticated binds (and upgrading is not always an option, not necessarily right away). However, there have been are still applications developed which use AD authentication and do not have this issue because using an empty password is never allowed. We too use many Windows-based and Linux-based applications with AD auth, and none works this way - authentication is not possible with just the user and no password.
The fact that the CP on pfSense allows authentication without a password while knowing how AD works is a flaw and a security risk. At least if it were documented in the pfSense documentation, one would understand the risk.
Please check the "Add option to (dis)allow unauthenticated LDAP binds" feature #9909
Updated by Aurelian Rau about 4 years ago
Viktor Gurov wrote:
Please check the "Add option to (dis)allow unauthenticated LDAP binds" feature #9909
Thank you Viktor, this is useful.
I know we all love to hate Microsoft, but that does not solve anything - this does.
Until version 2.5 comes we will use the other work-arounds.
Thank you,
Aurelian