Message-ID: <CAM2Hf5nG=+6JEVdN=0-xgdZEM=2de_ctMk_SCjBuD8OvC4_B-g@mail.gmail.com>
Date: Fri, 13 Jul 2012 09:37:36 -0700
From: Gage Bystrom <themadichib0d@...il.com>
To: Tim <tim-security@...tinelchicken.org>, 
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Predefined Post Authentication Session ID
	Vulnerability

See now this is something I can get behind, as that's a scenario where this
attack can achieve something that arbitary js normally could not do, or at
least I'm more uncertain if other methods would work in that situation, and
its a situation that is going to be reasonably common and not some super
niche scenario. So thanks.

As for OP, its sad if you don't care about the context of a vulnerability
at all, but if that's your choice then fine but its gunna be your loss in
the long run.
On Jul 13, 2012 9:07 AM, "Tim" <tim-security@...tinelchicken.org> wrote:

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

Content of type "text/html" skipped

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

Powered by blists - more mailing lists