Skip to content
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

Security bug report #220

Open
gregmolnar opened this issue Aug 8, 2014 · 14 comments · May be fixed by #222
Open

Security bug report #220

gregmolnar opened this issue Aug 8, 2014 · 14 comments · May be fixed by #222

Comments

@gregmolnar
Copy link

What is the best way to report a vulnerability in rubycas-server and submit a fix? I can't see anything about this in the readme nor the wiki.

@craigsheen
Copy link

@gregmolnar
Copy link
Author

Thanks but I don't think it would be a good idea to send a PR without discussion the problem with the core members first. I guess they want to prepare a release too.

@mitfik
Copy link
Contributor

mitfik commented Aug 8, 2014

Hi @gregmolnar thanks a lot for you feedback.
I do not understand what you are afraid off by creating PR, could you explain that?
You have to remember that this is an open source project the rules here are simple, we all together working on that project. There is no secrets to hide. If there is a vulnerability, you just create an issue (with PR the best) and we will react on it as soon as possible. If the core team will not be able to provide solution fast enough, at least people will be able to use your fix or create own.
Do not wait, as if you found it, there is huge chance that someone else with "black hat" already did that.

If you still do not agree with publishing it as a regular issue with PR, please send the report to me on [email protected] I will take care of it as one of the core team.

best regards

@gregmolnar
Copy link
Author

I believe users of rubycas are not looking at github everyday but they probably have some kinda of a monitoring of the new releases so I guess in case of a security fix, a new release should be published quickly. But if someone just submits a PR and for any reason the core members doesn't really have the time to review it and release a new version, the vulnerability can be public for a period without a released fix.
Anyway I will send a PR soon.

@gregmolnar
Copy link
Author

The issue I am about to report been found in an older version of the gem. In that version it was possible to lock down the CAS server to a subdomain. Has that feature been removed? I made a simple app and had a play around but even if I set the allowed_service_ips I can be redirected to not allowed services too. Am I missing something?

@gregmolnar
Copy link
Author

I investigated this a little more and it looks like at my work someone patched rubycas-server to avoid an XSS token hijack vulnerability. I can't see any protection in rubycas master related to this.
The vulnerability is pretty simple and I created a POC app here: https://github.com/gregmolnar/cas-client-example. Basically you can just the service param in the URL, send the link to someone, he logs in, being redirected to your evil site, you get the ticket from the URL and redirect him to the correct URL. Than you can access to the service with the stolen token.
Am I missing something from the documentation or there is no protection for such a thing? I see there is an allowed_service_ips option but that doesn't seem to stop this happening.

@adamcrown
Copy link
Contributor

allowed_service_ips is ignored if no allowed IPs are defined as you can see here.

I wrote it that way to be more backwards compatible since there was previously no way to limit what services could grab potentially sensitive information as you described. And I didn't want everybody upgrading to suddenly have a broken CAS server.

However, it might be a good idea to change to a more secure default of only allowing 127.0.0.1 or even treating an empty allowed_service_ips configuration as a "deny all". And then make configuring allowed IPs an explicit setup step in the README. At the very least the new rubycas-server-core should work that way I'd think.

@gregmolnar
Copy link
Author

As far as I see the ip_allowed? method is only called to verify the service when the service is calling rubycas. Which means it is steal possible to steal the token. Have you had a chance to look at the POC app?

@adamcrown
Copy link
Contributor

Oh sorry, I should have read that more carefully. You're right ip_allowed? only protects against third-party servers getting user info, not stealing tokens.

Maybe I'm missing something again but if you were to get a ticket for http://stealyourtoken.com and then tried to use that token on say http://realsite.com, wouldn't authentication fail because the initial stealyourtoken stored service URL doesn't match the realsite service URL parameter that the realsite server would use to validate the token?

The code I'm referring to that does the service matching is here: https://github.com/rubycas/rubycas-server/blob/master/lib/casserver/cas.rb#L183.

@gregmolnar
Copy link
Author

I guess it is a proxy ticket by default so it is not locked to a service. At least in my POC I can access the app on localhost with the ticket issued to stealyourtoken.com.

@adamcrown
Copy link
Contributor

When I try it out on some of our real sites I get the following error.

The ticket 'ST-1407797912rY78jOwbfxgQeF09-x7' belonging to user 'adam' is valid, but the requested service 'https://real.biola.edu' does not match the service 'https://bogus.biola.edu' associated with this ticket.

We're not using rubycas-client though and our client doesn't do proxy tickets. So it could have something to do with that.

@gregmolnar
Copy link
Author

Your setting is probably not the default. The app I linked is a default setup of casclient and casserver and that issues and validates a proxy ticket. A possible fix would be to add a whitelist of services to the server and don't redirect to anywhere else with a token in any setup.

@gregmolnar
Copy link
Author

Any of the core members had a chance to look into this? I am happy to send a fix but not sure what solution would be accepted by the core team.

@korun
Copy link
Contributor

korun commented Aug 15, 2014

@gregmolnar, just open the PR, and then will be able to discuss about proposed solution.

@gregmolnar gregmolnar linked a pull request Aug 20, 2014 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants