Hi, Its can be considered a minor weakness because it makes easier to successfully perpetrate a bruteforce attack. Using common passwords and guessing the username using the wildcards.
A valid username and a password is required to you simulate if you system have or not this vulnerability. Andrew, i tried to find other ways to use it but i could not achieve. In this scenario if you try user * and password * sometimes you could achieve. :org.springframework.ldap.SizeLimitExceededException: [LDAP: error code 4 - This search operation has sent the maximum of 1000 entries to the client]; nested exception is javax.naming.SizeLimitExceededException: [LDAP: error code 4 - This search operation has sent the maximum of 1000 entries to the client]; remaining name 'ou=Users, dc=xxxxx, dc=com, dc=br' If you need to upgrade or not your server its up to you to decide! On Thu, Jan 22, 2015 at 6:41 PM, Andrew Morgan <[email protected]> wrote: > On Thu, 22 Jan 2015, Paul B. Henson wrote: > > >> From: Jérôme LELEU Sent: Thursday, January 22, 2015 6:49 AM > >> > >> Yes indeed, you should upgrade to close the vulnerability if you use > >> LDAP authentication. > > > > You know, if you're going to announce a "holy crap upgrade now" security > > issue, it would be nice to get a little advance notice that it's coming > > 8-/. > > > > I don't quite understand this vulnerability. According to the > > announcement (http://seclists.org/oss-sec/2015/q1/205), it says "CAS > > Server 3.5.2 allows remote attackers to bypass LDAP authentication via > > crafted wildcards". > > > > Then under the description it says "A valid username and password > > required." It further says "The login will be sucessfully only if the > > ldap bind search return one unique member." > > > > If you need to know a valid username and the correct password for that > > username, how exactly are you "bypassing" authentication? It sounds like > > if you specify a wildcard that matches one and exactly one identity in > > your directory, *and* you supply the correct password for that identity, > > you successfully authenticate? Again, I don't understand how that can be > > considered to bypass authentication? It looks like the only ramification > > is that you can successfully authenticate with a string that isn't > > exactly the username, and that string is then presumably provided to the > > application you are trying to authenticate to? So instead of the > > application thinking the user "henson" logged in, it would think the > > user "hens*" logged in? Presumably undesirable, with potentially unknown > > ramifications depending on the application, but still not bypassing > > authentication. > > > > Also, I can't seem to reproduce it on my deployment. The LDAP wildcard > > "henso*" matches one and exactly one entry in my directory. If I type > > "henso*" and my correct password into the CAS login form, it tells me it > > is invalid. > > > > If I try the example in the announcement: > > > > curl -k -L -d "username=henso%2A&password=XXXXXXXXX" > > https://auth.csupomona.edu/cas/v1/tickets > > > > All I get in return is the CAS login page. > > > > Is this vulnerability dependent on how you have LDAP configured? I am > > using the FastBindLdapAuthenticationHandler mechanism. I don't believe > > there is any way for this vulnerability to apply to my configuration, as > > attempting to directly bind with the provided wildcard will always fail. > > Perhaps the vulnerability is only applicable to people using the > > BindLdapAuthenticationHandler, which would perform a wildcard search and > > find an entry which it would then try to bind as? > > > > Please clarify the issues surrounding this vulnerability so users can > > respond appropriately. My initial impression is that if you are using > > the FastBindLdapAuthenticationHandler you are not affected, so perhaps > > instead of announcing "You must upgrade if you use LDAP authentication" > > you should announce "You should upgrade if you are using the > > BindLdapAuthenticationHandler for LDAP authentication"? I also don't > > think the CVE should have a title that it bypasses authentication, as > > you're hardly bypassing authentication if you are required to know the > > username and password for the account 8-/. More accurately, it seems you > > can simply misrepresent your username to an application. > > You aren't effected when you use FastBindLdapAuthenticationHandler. > > This vulnerability works on my CAS server, but the attributes that are > released to applications are still correct because they are resolved by > the LdapPersonAttributeDao. > > It's hard to call this a vulnerability, which is probably why they didn't > release it as such. More like, "here's CAS v3.5.3 which fixes a security > related bug." > > I've been trying to think of ways to pass LDAP filter characters into the > username to make it do something interesting, but I haven't thought of > anything interesting. Maybe you can confuse some CAS clients, if the > username is passed along. > > Andy > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- Grato, Tozo -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
