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

Protect request phase against CSRF when Rails is used. #809

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
7 participants
@DouweM
Copy link

commented May 25, 2015

The request phase in OmniAuth is currently vulnerable to Cross-Site Request Forgery, which allows an attacker to easily gain full access to a user's account on a site that uses OmniAuth, when used in combination with another CSRF vulnerability on the side of a connected OAuth provider.

This vulnerability was reported to us (GitLab) by Mohamed Abdelbaset Elnoby (@SymbianSyMoh), a Senior Information Security Analyst at Seekurity.com, on April 23rd. On April 24th, we reported it to the OmniAuth team via email. On May 14th, we merged our patch into the public GitLab repository.

Mr. Elnoby also gave us an example of an OAuth provider that had the CSRF vulnerability on their side that is needed to make this attack "weaponizable". The vulnerability has been reported to them.

The below description of the issue is written from GitLab’s perspective.

Connecting the GitLab account to an OAuth provider like Google works like this:

  1. User visits https://gitlab.com/users/auth/google
  2. User is redirected to a page on Google
  3. Google checks if the user is logged in
  4. If the user is logged in, Google checks if the user has authorized the GitLab.com application to use their Google account
  5. If the user has authorized the GitLab.com application to use their Google account, Google redirects back to GitLab
  6. GitLab adds the Google account to the GitLab account as an alternate identity, which means the Google account can be used to log into the GitLab account.

This is all very straightforward, and works as expected.

Note that if the Google user has already authorized the GitLab.com application to use their Google account, there is no user action needed to link the two accounts, apart from the initial https://gitlab.com/users/auth/google visit.

This means that if you can get a person who 1) is signed into Google, 2) has authorized the GitLab.com application to use it, and 3) is signed into GitLab.com, to visit https://gitlab.com/users/auth/google, their account will be linked to the Google account without any further interaction, and without any feedback to the user.

This is not a big deal if the signed in Google account belongs to the GitLab user themselves, but it is if the user is somehow signed into Google using an account belonging to an attacker. In this scenario, the GitLab account would be linked to the attacker's Google account, and the GitLab user would be none the wiser.

And let it just so be the case that that iss possible with Redacted: there exists a vulnerability on their side that allows an attacker to log into Redacted using CSRF, which means that if a user visits a specially crafted page, they will end up being logged into Redacted as the attacker.

Combining this with the described GitLab.com flow, forcing the victim to visit that specially crafted page, and directly after that, forcing them to visit https://gitlab.com/users/auth/redacted (by using an iframe, for example), will give the attacker full control over the victim's GitLab account. "Forcing them" can be as simple as sending them a link over email and getting them to click it.

To actually use the POST method rather than GET so the CSRF token is sent along, we have changed our links to the auth path from:

link_to "Log in with #{provider}", omniauth_authorize_path(:user, provider)

to:

link_to "Log in with #{provider}", omniauth_authorize_path(:user, provider), method: :post

Note that the current implementation is very specific to Rails. It needs to be, as far as I can see, since the CSRF protection needs to use the web framework’s authenticity token.

I suggest deprecating OmniAuth.config.allowed_request_methods and only allowing :post from now on, but I haven't made that change yet since I think it warrants more discussion.

People that use OmniAuth with Rails will need to change the link_to helpers and <form> tags in their own code to use POST instead of GET,
so I’m afraid this is a breaking change and can’t just go in a patch release, in SemVer terms.

cc @sferik

@DouweM DouweM force-pushed the DouweM:csrf-protection branch from eea68f0 to 4e4f65a May 25, 2015

@DouweM DouweM force-pushed the DouweM:csrf-protection branch from 4e4f65a to 561ef98 May 25, 2015

@sferik

This comment has been minimized.

Copy link
Contributor

commented May 26, 2015

Thanks for this patch. Normally, I’d merge and release a security patch immediately but I’m reluctant to do so in this case for two reasons:

  1. this is a breaking change and
  2. it contains Rails-specific code

I’d propose that we solve this by creating a new gem: omniauth-rails, that depends on omniauth and rails and contains all Rails-specific code. We could release this as version 1.0.0 and notify users of OmniAuth that they should depend on omniauth-rails instead of omniauth if they’re using OmniAuth with Rails.

I’d like to get 👍 from the original author of OmniAuth (@mbleigh) before making this change as well as the Rails security team (@tenderlove, @jeremy, @NZKoz).

If everyone agrees this is a good idea, we can move forward with this plan very quickly.

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

@sferik Moving to omniauth-rails makes sense. We'd need to get devise to move on this as well.

@sferik

This comment has been minimized.

Copy link
Contributor

commented May 26, 2015

@DouweM That should be doable. Ping: @josevalim and @carlosantoniodasilva.

@sferik

This comment has been minimized.

Copy link
Contributor

commented May 26, 2015

Two more questions:

  1. Has a CVE-ID already been assigned for this vulnerability?
  2. When I click on Seekurity.com, I get a GoDaddy parked page. Is that really the security firm with which @SymbianSyMoh is associated?
@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

  1. No, I haven't done anything on that. From our earlier interaction, I wasn't sure if the issue was as serious as I thought and if it warranted that.
  2. He says so.
@sferik

This comment has been minimized.

Copy link
Contributor

commented May 26, 2015

  1. No, I haven't done anything on that. From our earlier interaction, I wasn't sure if the issue was as serious as I thought and if it warranted that.

@DouweM I think it would be helpful to have a CVE-ID for this vulnerability, so we can reference it unambiguously. Since you are most familiar with this issue, could you please initiate that process? The process to request a CVE-ID is described here.

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

@sferik Thanks, I'll go through the motions.

@sferik

This comment has been minimized.

Copy link
Contributor

commented May 26, 2015

@sferik Thanks, I'll go through the motions.

@DouweM Thank you.

I’ve contacted the Rails Security Team, informing them of this issue and asking for their help in spreading the word once it is patched.

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

@tenderlove

This comment has been minimized.

Copy link

commented May 26, 2015

I guess I don't understand how this is a Rails specific issue. Any framework you use with Omniauth will have this problem if you're using GET requests (though this solution is for Rails apps). This patch seems fine for handling the Rails side (though I thought we'd do everything automatically if you did a link_to with a method: post)

@rafaelfranca

This comment has been minimized.

Copy link

commented May 26, 2015

@tenderlove I think this issue is not Rails specific so we don't need to handle it, @sferik only want our review in his plan.

The plan looks good. The Rails team can help to spread the word via our twitter account and the security list.

@tenderlove

This comment has been minimized.

Copy link

commented May 26, 2015

@tenderlove I think this issue is not Rails specific so we don't need to handle it, @sferik only want our review in his plan.

Gothcha. It seems good to me. The only question I have is since the link is turned in to a form, wouldn't we already take care of CSRF validation? I don't know omniauth internals. I assume it's a middleware? If Omiauth was placed after we do CSRF checking, couldn't we delete most of the code in this patch?

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

Gothcha. It seems good to me. The only question I have is since the link is turned in to a form, wouldn't we already take care of CSRF validation? I don't know omniauth internals. I assume it's a middleware? If Omiauth was placed after we do CSRF checking, couldn't we delete most of the code in this patch?

OmniAuth intercepts the request at the Rack middleware level, before it gets to the Rails controller and the protect_against_forgery before_action at all.

If Rails had a RequestForgeryProtection middleware, that would be useful here, but that wouldn't work for regular Rails controllers, since it depends on controller-level settings.

This patch basically turns protect_against_forgery into a middleware, albeit an OmniAuth-specific one, using the settings on ApplicationController.

@tenderlove

This comment has been minimized.

Copy link

commented May 26, 2015

OmniAuth intercepts the request at the Rack middleware level, before it gets to the Rails controller and the protect_against_forgery before_action at all. If Rails had a RequestForgeryProtection middleware, that would be useful here, but that wouldn't work for regular Rails controllers, since it depends on controller-level settings.

Makes sense. 👍 from me on this patch. :)

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

@sferik So what's the next step? If you create an intridea/omniauth-rails repo, I'm happy to build a gem out of this patch and move it there. I think it's better to have it under intridea than DouweM or gitlabhq, so people will know it's the "official" OmniAuth+Rails gem.

@sferik

This comment has been minimized.

Copy link
Contributor

commented May 26, 2015

@tenderlove @rafaelfranca Thanks for taking the time to review this patch.

@DouweM I just created an empty repo at https://github.com/intridea/omniauth-rails. I’ll initialize that with a gem scaffold now. Feel free to open a pull request against that repo with the same code you’ve placed here. I’ll be busy for the next few hours but will try to push out a release later on this evening.

The README of this repo should also be updated to indicate that Rails users should depend on omniauth-rails instead of directly on omniauth.

I’m going to close this pull request.

@sferik sferik closed this May 26, 2015

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

@sferik All right. I won't have time tonight, unfortunately, but I'll submit a pull request tomorrow.

@SymbianSyMoh

This comment has been minimized.

Copy link

commented May 26, 2015

Hi Guys,
Sorry for being late involving this thread, so many things happening here.
@sferik Yup, that's exactly the domain but not yet stared and the website is fully under constructions.

@DouweM

This comment has been minimized.

Copy link
Author

commented May 26, 2015

Hey @SymbianSyMoh, thanks for finding this vulnerability and reporting it to us!

I hope you don't mind that that I've taken up the task of reporting where relevant and making sure it gets patched. I've credited you here and in the CVE request: http://www.openwall.com/lists/oss-security/2015/05/26/11.

@SymbianSyMoh

This comment has been minimized.

Copy link

commented May 26, 2015

Thanks @DouweM really appreciate that 👍

@SymbianSyMoh

This comment has been minimized.

Copy link

commented May 26, 2015

@DouweM @sferik @tenderlove Should this issue be reported under this responsible disclosure rules:

  1. https://hackerone.com/ruby
  2. https://hackerone.com/rails
    Or not ?!
@rafaelfranca

This comment has been minimized.

Copy link

commented May 26, 2015

@SymbianSyMoh for this case no, it is not related to Ruby or Rails projects. But if you find something on one of these projects, those are the recommended channels.

@SymbianSyMoh

This comment has been minimized.

Copy link

commented May 26, 2015

Thanks @rafaelfranca Appreciate it

@DouweM

This comment has been minimized.

Copy link
Author

commented May 27, 2015

Pull request agains omniauth-rails submitted: omniauth/omniauth-rails#1

@SymbianSyMoh

This comment has been minimized.

Copy link

commented Nov 19, 2015

Hi Guys, I know this is a long time ago thread, but guess what? I never
received any CVE regarding this issue till now!! So what can i do to get it?

_Mohamed Abdelbaset Elnoby_Guru Programmer, Senior Information Security
Consultant & Web Application Penetration Tester at Seekurity Inc
http://www.Seekurity.com.

Contact me at:
LinkedIn
https://www.linkedin.com/in/symbiansymohFacebook
https://fb.com/symbiansymohTwitter https://twitter.com/symbiansymoh
https://twitter.com/symbiansymoh

On Wed, May 27, 2015 at 3:35 AM, Douwe Maan notifications@github.com
wrote:

Pull request agains omniauth-rails submitted: omniauth/omniauth-rails#1
omniauth/omniauth-rails#1


Reply to this email directly or view it on GitHub
#809 (comment).

@DouweM

This comment has been minimized.

Copy link
Author

commented Nov 19, 2015

@SymbianSyMoh I never got a response to the CVE request on the oss-security mailinglist, unfortunately.

@reedloden

This comment has been minimized.

Copy link

commented Sep 23, 2016

I requested a CVE from the DWF (cc @kurtseifried) for this.

@SymbianSyMoh

This comment has been minimized.

Copy link

commented Sep 23, 2016

So what is the problem?

_Mohamed Abdelbaset Elnoby_Senior Information Security Analyst & Chief
Product Security at Linio LATAM https://www.linio.com.mx, Founder at
BugBountyProgram
Platform http://www.BugBountyProgram.com, Security Advisor & Web
Application Penetration Tester at Seekurity http://www.Seekurity.com.

Contact me at:
LinkedIn
https://www.linkedin.com/in/symbiansymohFacebook
https://fb.com/symbiansymohTwitter https://twitter.com/symbiansymoh

_Let's speak encrypted. Here's my Public Key on PGP Global Directory: _Click
to download

https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x7F70C8FCAE73E1ED

On Fri, Sep 23, 2016 at 5:43 AM, Reed Loden notifications@github.com
wrote:

I requested a CVE from the DWF (cc @kurtseifried
https://github.com/kurtseifried) for this.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#809 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC_w2HVURiiMMQwLp7olZdOAVs-3PyS3ks5qs61OgaJpZM4EodU3
.

@sdogruyol

This comment has been minimized.

Copy link

commented Apr 8, 2019

Any update on this?

Fast forward to 2019, this is still valid. Any Ruby on Rails application using default Omniauthsettings are open to this vulnerability.

@reedloden @SymbianSyMoh since @DouweM had already opened a CVE, how do we proceed now?

@SymbianSyMoh

This comment has been minimized.

Copy link

commented Apr 9, 2019

@sdogruyol +1, We haven't received any CVE updates till the moment!

@reedloden

This comment has been minimized.

Copy link

commented Apr 9, 2019

I don't think a CVE was ever assigned, correct? I've assigned this CVE-2015-9284.

omniauth/omniauth-rails#1 still needs to be merged and a new version of omniauth-rails released.

I don't feel comfortable adding this to ruby-advisory-db until we have a fixed version, especially considering how old this is. Would just make a lot of people very grumpy.

Can somebody take ownership of getting the actual fix into a released version? Once that's done, I'll happily add this to ruby-advisory-db, which will notify folks to upgrade.

@sdogruyol

This comment has been minimized.

Copy link

commented Apr 15, 2019

@reedloden is there a link to assigned CVE-2015-9284?

@reedloden

This comment has been minimized.

Copy link

commented Apr 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.