Bug 740974 - Cookies can be reused after logout and through a browser closure, possibly maliciously. [satellite-6]
Summary: Cookies can be reused after logout and through a browser closure, possibly ma...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Provisioning
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Roman Plevka
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks: 869077
TreeView+ depends on / blocked
 
Reported: 2011-09-24 01:28 UTC by Corey Welton
Modified: 2019-04-01 20:27 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-27 11:12:17 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 14338 None None None 2016-04-22 16:57:01 UTC

Description Corey Welton 2011-09-24 01:28:53 UTC
Description of problem:
If a user copies a cookie from a user currently in session, it can be used to modify an existing session, or create a new cookie that can be used even after browser has been closed.

Version-Release number of selected component (if applicable):

Katello Version: 0.1.84-1.git.0.02da736.fc14 


Steps to Reproduce:
1.  Install Cookie Manager+ in Firefox
2.  Login as admin user
3.  Create a new user, "hacker"
4.  In Cookie Manager+, find the session cookie for katello server and copy all contents (in particular, the cookie name and content) to a text editor.
5.  Logout from admin user
6.  Login as "hacker"
7.  In Cookie Manager+, find the session cookie for katello and replace the content of the cookie with that from the admin user. 
8.  Refresh katello UI.  Observe user logged in.
9.  Completely close browser; reopen and open Cookie Manager+
10. Create a new cookie from scratch, containing the details you copied in step 4, being careful to use the correct cookie name, content and server
11. Load katello server page.

  
Actual results:
In step 8, logged-in user is changed (though this might be expected and hard to defend against)
In step 11, content from a cookie can be used, even after browser session itself has been terminated - that is, after the browser has been closed - to craft a new authentication cookie.


Expected results:
Cookies should not be persistent beyond a single browser session. After the browser is closed, that cookie should be invalidated.

Additional info:
* I haven't yet tried to see if I can recreate a session on a different computer. 
* Not sure if this is really a big issue or I'm overreacting. But I figure it's worth looking into.

Comment 3 Garik Khachikyan 2011-09-27 07:14:13 UTC
rise the priority - security issues have to fixed ASAP. thanks.

Comment 4 Shannon Hughes 2011-09-29 21:12:24 UTC
i am failing to see how this is security issue with the test case given.

1) u are grabbing cookie content while LOGGED IN with credentials
2) u log out
3) now you login with another person's credentials and paste contents of cookie that were captured while logged in. in both cases u have to know credentials of each user. 

i could see this as a problem if you captured the content while logged out and you were able to log in as someone else.

Comment 5 Jan Lieskovsky 2011-11-03 13:54:42 UTC
Hi Shannon,

  thank you for your reply.

(In reply to comment #4)
> i am failing to see how this is security issue with the test case given.
> 
> 1) u are grabbing cookie content while LOGGED IN with credentials
> 2) u log out
> 3) now you login with another person's credentials and paste contents of cookie
> that were captured while logged in. in both cases u have to know credentials of
> each user. 
> 
> i could see this as a problem if you captured the content while logged out and
> you were able to log in as someone else.

I think the problem Corey is referring to is in steps 10) and 11):

10. Create a new cookie from scratch, containing the details you copied in step 4, being careful to use the correct cookie name, content and server

11. Load katello server page.

With the result:

In step 11, content from a cookie can be used, even after browser session itself has been terminated - that is, after the browser has been closed - to craft a new authentication cookie.

Thus (based on above description assuming, didn't try it) some remote attacker could just sniff the cookie content on the network. Save particular values, create new cookie, and the successfully log-in to the Katello web UI service just due knowledge of the cookie.

Assuming, what Corey is trying to say, that there isn't some random / unique value contained within the cookie, so it couldn't be used again (under different user) for replay attacks.

Corey, is this the way you thought the attack would be possible?

If not, please correct me.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Comment 6 Corey Welton 2011-11-03 14:45:58 UTC
Correct, if the cookie content is sniffed -- or in my case, copied out -- and regenerated after the user has been logged out and subsequently had his session invalidated, the cookie is essentially not rejected as invalid.

Comment 7 Corey Welton 2011-11-03 14:58:07 UTC
Shannon, i just re-read this:

3) now you login with another person's credentials and paste contents of cookie
that were captured while logged in. in both cases u have to know credentials of
each user. 

No, you don't need to know the user's credentials.  Once you copy and paste the cookie contents, you do not need to physically login. The cookie is valid - you can enter the UI system w/o actually logging in.

Comment 8 Tomas Hoger 2011-11-07 19:38:31 UTC
Does this sound like an accurate short summary of the issue?

When user selects logout action in katello webui, her session is not closed / invalidated on the server side.  Even though local cookie gets destroyed (server reply to logout request overwrites session cookie(s)), the session can be resumed by manually restoring session cookie(s) values.

Comment 9 Mike McCune 2011-12-16 17:54:27 UTC
Tomas, that sounds like an accurate summary of the issue. 

How would a attacker 'sniff' a cookie value if all our comms are on HTTPS?  

Seems to me the only way you can get access to a valid or invalid cookie is by having access to the machine running the browser where the cookie is stored which would indicate larger problems.

I'm going to move this off katello-blockers unless someone convinces us otherwise that this needs to get fixed ASAP.

Comment 10 Jeff Weiss 2011-12-16 18:10:40 UTC
How long does the cookie stay valid?  Even if it's not our job to prevent hijacking the cookie locally, if there *is* some exploit to get it, like cross site scripting, we don't want the attacker to be able to continue to use it even after the original session is logged out.

Comment 11 Tomas Hoger 2011-12-21 14:05:33 UTC
Of course, if using SSL and if app has no XSS issues, there should be no easy way for any attacker to get access to the cookie.  This still sounds like a bug, and something that probably should not be too hard to fix.

Comment 12 Mike McCune 2012-01-26 19:38:41 UTC
mass move to CFSE product.

Comment 14 Shannon Hughes 2012-02-09 14:49:04 UTC
I looked into the technical details to remove the replay attack vulnerability. The cookie data is comprised of the session data, then a '--' delimiter followed by the HMAC of the session. the user would not be able to tamper the data since its signed but there is indeed a replay attack vulnerability when i signed out and sent the same cookie headers back to the server. 

we would need to change the store mechanism from cookie_store to a db/active record store so we could delete session records on user logout. I created a session table and modified the store but looks like we have to make some changes to our session logic (especially user_sessions in views) to make this work correctly. predicting a lot of regression testing would need to be done to get the confidence rating up for robustness. 

I'll check up with a couple other team members who might see an easier path but looks like regression would take a hit since this is our session layer.

Comment 16 Bryan Kearney 2014-09-08 19:04:58 UTC
I do not believe this is an issue any longer, I am moving to ON_QA for 6.1 to verify.

Comment 17 Corey Welton 2014-10-10 17:36:33 UTC
Nope, this is still valid (and I had little reason to suspect anything was changed to fix it, tbh).  

I just copied session id from admin user, created a new user 'hacker', logged out as admin and logged back in as 'hacker', copied the session id back and voila, I was admin again.

I am not sure why we are not simply crafting a new unique session id for each login, that gets destroyed once that account is logged out.

* apr-util-ldap-1.3.9-3.el6_0.1.x86_64
* candlepin-0.9.32-1.el6.noarch
* candlepin-common-1.0.8-1.el6.noarch
* candlepin-selinux-0.9.32-1.el6.noarch
* candlepin-tomcat6-0.9.32-1.el6.noarch
* elasticsearch-0.90.10-7.el6.noarch
* foreman-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-compute-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-gce-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-libvirt-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-ovirt-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-postgresql-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-proxy-1.7.0-0.develop.201410081229git52f0bac.el6.noarch
* foreman-release-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-selinux-1.7.0-0.develop.201409301113git2f345de.el6.noarch
* foreman-vmware-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* katello-2.1.0-1.201410091751gitc9c45c1.el6.noarch
* katello-certs-tools-2.0.1-1.el6.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-2.1.0-1.201410021645git304e036.el6.noarch
* katello-repos-2.1.1-1.el6.noarch
* katello-server-ca-1.0-1.noarch
* openldap-2.4.23-32.el6_4.1.x86_64
* pulp-docker-plugins-0.2.1-0.2.beta.el6.noarch
* pulp-katello-0.3-3.el6.noarch
* pulp-nodes-common-2.5.0-0.7.beta.el6.noarch
* pulp-nodes-parent-2.5.0-0.7.beta.el6.noarch
* pulp-puppet-plugins-2.5.0-0.7.beta.el6.noarch
* pulp-puppet-tools-2.5.0-0.7.beta.el6.noarch
* pulp-rpm-plugins-2.5.0-0.7.beta.el6.noarch
* pulp-selinux-2.5.0-0.7.beta.el6.noarch
* pulp-server-2.5.0-0.7.beta.el6.noarch
* python-ldap-2.3.10-1.el6.x86_64
* ruby193-rubygem-ldap_fluff-0.3.1-1.el6.noarch
* ruby193-rubygem-net-ldap-0.3.1-2.el6.noarch
* ruby193-rubygem-runcible-1.2.0-1.el6.noarch
* rubygem-hammer_cli-0.1.3-1.201409240954gitf3c47c7.el6.noarch
* rubygem-hammer_cli_foreman-0.1.3-1.201409191432gitc38f9c8.el6.noarch
* rubygem-hammer_cli_foreman_tasks-0.0.3-2.201409091410gitc96619d.git.0.37f3704.el6.noarch
* rubygem-hammer_cli_import-0.10.4-1.el6.noarch
* rubygem-hammer_cli_katello-0.0.6-1.201410091836git8886ff0.git.0.9402d12.el6.noarch

Comment 19 Daniel Lobato Garcia 2016-04-06 09:35:07 UTC
Yes. I just triaged it and I was able to reuse the session_id from the admin. Rails 4 made a few improvements where I can't decode it now, but if it's not revoked upon logout, it'll still be available. I'm investigating how can we expire the session id on logout.

Comment 20 Daniel Lobato Garcia 2016-04-06 10:11:51 UTC
It puzzled me a bit that activerecord_session_store (db session store) would do that. Bryan, you were right after Rails 4 this shouldn't have happened.

Apparently there was a bug that sometimes would not respect the session expiry. It was fixed on http://projects.theforeman.org/issues/14338 - so we can cherrypick it for this version easily.

Comment 21 Daniel Lobato Garcia 2016-04-06 10:12:20 UTC
Connecting redmine issue http://projects.theforeman.org/issues/14338 from this bug

Comment 22 Bryan Kearney 2016-04-06 12:01:59 UTC
Upstream bug component is Provisioning

Comment 23 Roman Plevka 2016-05-23 14:53:23 UTC
VERIFIED

on sat 6.2.0 Beta (GA12.1)

The cookie is invalidated on logout:

<pre>
# after updating the 'hackers' session cookie by admin one: 
2016-05-23 10:44:31 [app] [I] Started GET "/users/8-hacker/edit" for 10.34.131.38 at 2016-05-23 10:44:31 -0400
2016-05-23 10:44:31 [app] [I] Processing by UsersController#edit as HTML
2016-05-23 10:44:31 [app] [I]   Parameters: {"id"=>"8-hacker"}
2016-05-23 10:44:31 [app] [I] Redirected to https://dell-pe-fc630-01.rhts.eng.bos.redhat.com/users/login
2016-05-23 10:44:31 [app] [I] Filter chain halted as :require_login rendered or redirected
2016-05-23 10:44:31 [app] [I] Completed 302 Found in 6ms (ActiveRecord: 0.7ms)
2016-05-23 10:44:31 [app] [I] Started GET "/users/login" for 10.34.131.38 at 2016-05-23 10:44:31 -0400
2016-05-23 10:44:31 [app] [I] Processing by UsersController#login as HTML
2016-05-23 10:44:31 [app] [I]   Rendered users/login.html.erb within layouts/login (3.3ms)
2016-05-23 10:44:31 [app] [I]   Rendered layouts/base.html.erb (1.8ms)
2016-05-23 10:44:31 [app] [I] Completed 200 OK in 12ms (Views: 6.9ms | ActiveRecord: 0.7ms)
</pre>

Comment 24 Bryan Kearney 2016-07-27 11:12:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1501


Note You need to log in before you can comment on or make changes to this bug.