full-disclosure - Re: Predefined Post Authentication Session ID Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 13 Jul 2012 09:07:09 -0700
From: Tim <tim-security@...tinelchicken.org>
To: Gage Bystrom <themadichib0d@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Predefined Post Authentication Session ID
 Vulnerability

I have not read the PoC.  Nor do I care to.  However, I do want to
point out one aspect of session fixation that I think many people
overlook, as I think has been indicated by some responses on this
thread.  If this is not news to many of you, I appologize.  Just
trying to raise awareness.

Suppose an application runs solely over HTTPS and assigns cookies
with the secure flag.  However, user sessions are assigned before
login and they don't refresh their session cookies upon user login.
In this case, users are still vulnerable to MitM:

1. An attacker gains access to view and modify unencrypted traffic
between a user and the application.

2. The attacker accesses the site (in this case: https://example.com/)
as an unauthenticated user and obtains a session cookie.

3. A victim's browser, at some point before the victim logs in to the
application, makes a request to any non-HTTPS web page. (This could
include web mail sites, search engines, etc)  Let's call this site
third-party.example.org for the sake of argument.

4. Attacker injects into a HTTP response (coming from
third-party.example.org) which causes the victim's browser to
request some page under the non-SSL version of example.com.  This
could happen through a redirect, injection of an image tag, or any
number of other things.  Anything to force the victim's browser to
send one request to the HTTP version of example.com is sufficient.

5. Upon attempting to access the HTTP version of the vulnerable
application (which of course doesn't exist), the attacker again
intercepts this and replaces the HTTP response.  In this response, a
Set-Cookie header is included which provides the victim's browser with
the application session that the attacker retrieved in step 2.

6. Later, the victim logs into the application normally.  Even though
the session cookie was assigned over a faux HTTP version of the site
without the secure flag set, the victim's browser sends it along to
the HTTPS site without knowing the difference.  The site can't tell
the cookie was set insecurely.

7. Since the attacker knows the session cookie, the account can be
easily hijacked once the victim establishes an authenticated session
with it.

This is complicated, but it's not that much more complicated than what
existing MitM tools, such as sslstrip, already do.  

Note that another variant of this attack is possible if the victim's
browser silently accepts third-party cookies (which most do by
default) and is able to convince a user to visit any malicious site.
In this case, no MitM is necessary.

Using HTTP cookies for session authentication is, and always has been,
a bad idea.  They are simply not designed for this application.  We
need something better. 

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/