New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication bypass in validateCAS20 #228

Closed
ngocdh opened this Issue Apr 6, 2017 · 16 comments

Comments

Projects
None yet
4 participants
@ngocdh

ngocdh commented Apr 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jfritschi

jfritschi Apr 6, 2017

Contributor

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

Contributor

jfritschi commented Apr 6, 2017

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

@jfritschi jfritschi added this to the 1.3.5 milestone Apr 6, 2017

@jfritschi jfritschi self-assigned this Apr 6, 2017

@ngocdh

This comment has been minimized.

Show comment
Hide comment

ngocdh commented Apr 7, 2017

Thanks

@gboddin

This comment has been minimized.

Show comment
Hide comment
@gboddin

gboddin Apr 7, 2017

Contributor

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

Contributor

gboddin commented Apr 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gboddin

gboddin Apr 7, 2017

Contributor

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.

Contributor

gboddin commented Apr 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ngocdh

ngocdh Apr 7, 2017

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.

ngocdh commented Apr 7, 2017

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.

gboddin added a commit to gboddin/phpCAS that referenced this issue Apr 7, 2017

jfritschi added a commit that referenced this issue Apr 8, 2017

Fixed potential auth bypass issue on old/insecure CAS servers (#229)
* Fixed potential auth bypass issue on old/insecure CAS servers (apereo/phpCAS#228)
@jfritschi

This comment has been minimized.

Show comment
Hide comment
@jfritschi

jfritschi Apr 8, 2017

Contributor

@ngocdh Can you verify the fix?

Contributor

jfritschi commented Apr 8, 2017

@ngocdh Can you verify the fix?

@ngocdh

This comment has been minimized.

Show comment
Hide comment
@ngocdh

ngocdh Apr 8, 2017

@jfritschi It's good now

ngocdh commented Apr 8, 2017

@jfritschi It's good now

@jfritschi

This comment has been minimized.

Show comment
Hide comment
@jfritschi

jfritschi Apr 10, 2017

Contributor

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

Contributor

jfritschi commented Apr 10, 2017

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

@ngocdh

This comment has been minimized.

Show comment
Hide comment
@ngocdh

ngocdh Apr 10, 2017

@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.

ngocdh commented Apr 10, 2017

@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 comment has been minimized.

Show comment
Hide comment
@jfritschi

jfritschi Apr 11, 2017

Contributor

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

Contributor

jfritschi commented Apr 11, 2017

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

@jfritschi jfritschi closed this Apr 11, 2017

@ngocdh

This comment has been minimized.

Show comment
Hide comment
@ngocdh

ngocdh Apr 11, 2017

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

ngocdh commented Apr 11, 2017

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

@marinaglancy

This comment has been minimized.

Show comment
Hide comment
@marinaglancy

marinaglancy Jul 7, 2017

Contributor

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

Contributor

marinaglancy commented Jul 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ngocdh

ngocdh Jul 7, 2017

Hi @marinaglancy ,

Here you are: CVE-2017-1000071.

Ngoc

ngocdh commented Jul 7, 2017

Hi @marinaglancy ,

Here you are: CVE-2017-1000071.

Ngoc

@jfritschi

This comment has been minimized.

Show comment
Hide comment
@jfritschi

jfritschi Jul 8, 2017

Contributor

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

Contributor

jfritschi commented Jul 8, 2017

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

@ngocdh

This comment has been minimized.

Show comment
Hide comment

ngocdh commented Jul 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jfritschi

jfritschi Jul 8, 2017

Contributor

Okay, thanks for clearing that up!

Contributor

jfritschi commented Jul 8, 2017

Okay, thanks for clearing that up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment