Authentication bypass in validateCAS20

[ngocdh]

Hello,
I found a way to abuse failure message from old CAS server to bypass authentication, even if latest phpCAS is used.
The CAS20 validation function is like this:

//from line 3166 of https://github.com/Jasig/phpCAS/blob/master/source/CAS/Client.php
public function validateCAS20(&$validate_url,&$text_response,&$tree_response, $renew=false)
{
	//some checks
	} else if ($tree_response->getElementsByTagName("authenticationSuccess")->length != 0) {
		//success
	} else if ( $tree_response->getElementsByTagName("authenticationFailure")->length != 0) {
		//failure
	} else {//exception and stuff
}

A normal authenticationFailure message is like this:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationFailure code='INVALID_TICKET'>
    ticket 'ST-1234-d0VsoOn9nd0xEjVSnVXd' not recognized
  </cas:authenticationFailure>
</cas:serviceResponse>

In old CAS server version, it was possible to inject xml tag in the ticket so that the failure message become:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationFailure code='INVALID_TICKET'>
    ticket 'ST-1234-d0VsoOn9nd0xEjVSnVXd</cas:authenticationFailure><cas:authenticationSuccess><cas:user>admin</cas:user></cas:authenticationSuccess><cas:authenticationFailure code='INVALID_TICKET'>' not recognized
  </cas:authenticationFailure>
</cas:serviceResponse>

Now check the php code above and guess what happens: authentication success! The authenticationfailure elements are ignored.

Again, this is only possible when latest phpCas is configured to authenticate against old CAS server. Still, that does exist.
Some other CAS clients might also be vulnerable, I didn't verify though.
Dau Huy Ngoc from Deloitte France

[jfritschi]

Thanks for the report. I will have a look an verify.

[ngocdh]

Thanks

[gboddin]

Looking closely into this, @jfritschi let me know if I can help.

PS: if this is true, we have a zero-day with full-disclosure prior patching, it would be wise to treat this issue on a non-public tracker

[gboddin]

After analysis , I tend to think it's mostly a server issue. Would be nice to have some upstream filtering just in case though, that's for sure.

[ngocdh]

Yeah Gregory as I already stated, the issue is only exploitable with a vulnerable server version.

However, the final validation is in the client, and in this case phpCas interprets a failure message as a success.

[jfritschi]

@ngocdh Can you verify the fix?

[ngocdh]

@jfritschi It's good now

[jfritschi]

@ngocdh Can you give us a reference to the original CAS server side issue? Do you know which versions were affected?

[ngocdh]

@jfritschi I don't have any reference to the server side issue and how it was raised. I know that 2.x is vulnerable, not sure until which version.
To verify if the server is patched, just go to [casURL]/serviceValidate. If the error message is HTML-encoded (meaning ' is encoded as "& # 3 9 ;" without spaces), then it's not vulnerable.

[jfritschi]

This CAS server issue was probably fixed in this issue in 2010:
https://issues.jasig.org/browse/CAS-885
This would mean only CAS server versions before 3.3.5.1 or 3.4.2.1 would be affected

[ngocdh]

@jfritschi you're probably right. They didn't see the risk of authentication bypass though. Thanks for the information.

[marinaglancy]

Hello,

Moodle is shipped with CAS library and we picked just this fix into stable supported versions. We will upgrade CAS to 1.3.5 in the next major release (3.4 scheduled for November 2017), we normally don't do full upgrade of third party libraries in the stable versions.

I saw that you've included this fix in your release notes as "Security fixes" but I did not find a CVE for it. Do you have CVE for this fix? Thanks in advance

[ngocdh]

Hi @marinaglancy ,

Here you are: CVE-2017-1000071.

Ngoc

[jfritschi]

@ngocdh This does not look like a valid CVE? Are you sure?

[ngocdh]

Yes @jfritschi, information about it can be found here: https://github.com/distributedweaknessfiling/DWF-CVE-Database/tree/master/2017/1000xxx
This is a new format.

[jfritschi]

Okay, thanks for clearing that up!