Re: Predefined Post Authentication Session ID Vulnerability

[Gage Bystrom <themadichib0d () gmail com>]

Ok after playing around and re-reading the advisory I was finally able
to get the PoC to work. While it is interesting once your actually see
it work I simply do not believe it warrants the severity you have
described. The man reason why I say this is because any attacker in a
position to modify a victim's session id is simply in a position to do
better things. Why go through the niche roundabout way when you can
just simply jack the authenticated session ID?

The only conceivable scenario I can think of would be in the case of a
stored XSS that isn't present after authentication, in which case
stealing the session ID before hand would be a much better avenue and
more in line with what you are trying to warn about(maybe you should
make the PoC reflect that to better illustrate your point). Even then
we are talking about a really niche attack.

Basically this sounds like a classic example of: "Yes, technically
this is abusable, but if you are worried about this, you have bigger
problems to deal with."

Speaking of xss your vuln page has one:

http://www.iosec.org/iosec_login_vulnerable.php?user=%3Cscript%3Ealert%28%22Told%20ya%20so%22%29%3C/script%3E&failed=1

not to mention an arbitrary(even non-existent users) account change:

http://www.iosec.org/iosec_login_vulnerable.php?user=admin
((after logging in, not that the result page is much))

Yeah, yeah I know it's meant to be vulnerable to begin with, but you
should really make sure a PoC vulnerable page is only vulnerable to
what you are trying to demonstrate, otherwise it can be hard to
identify if this is a serious issue or just an example of your
personal screw ups, generally speaking at least.

On Fri, Jul 13, 2012 at 1:46 AM, Gokhan Muharremoglu
<gokhan.muharremoglu () iosec org> wrote:
> You can find an example page and combined vulnerabilities below URL.
> This example login page is affected by Predefined Post Authentication
> Session ID Vulnerability.
> This vulnerability can lead a social engineering scenario or other hijacking
> attack scenarios when mixed with other vulnerabilities (such XSS).
>
> For proof of concept:
>
> http://www.iosec.org/iosec_login_vulnerable.php
>
>
> Predefined Post Authentication Session ID Vulnerability is a Vendor-neutral
> vulnerability and it let attackers to design new attack scenarios.
> A lot of web application on the Internet affected by this vulnerability.
>
> -----------------------
> Vulnerability Name: Predefined Post Authentication Session ID Vulnerability
> Type: Improper Session Handling
> Impact: Session Hijacking
> Level: Medium
> Date: 10.07.2012
> Vendor: Vendor-neutral
> Issuer: Gokhan Muharremoglu
> E-mail: gokhan.muharremoglu () iosec org
>
>
> VULNERABILITY
> If a web application starts a session and defines a session id before a user
> authenticated, this session id must be changed after a successful
> authentication. If web application uses the same session id before and after
> authentication, any legitimate user who has gained the "before
> authentication" session id can hijack future "after authentication" sessions
> too.
>
> MITIGATION
> To avoid this vulnerability, sessions must be regenerated after a successful
> login. In a session fixation attack, attacker fixates (sets) another
> person's (victim's) session identifier because of "never regenerated and
> validated" session id and this vulnerability can also lead to the Session
> Fixation attack or etc.
>
> Gokhan Muharremoglu
> Information Security Specialist
> (CEH, ECSA, CIW-Web Security Professional, Security+, EXIN 27002 ISFS)
>
> -----Original Message-----
> From: Jann Horn [mailto:jannhorn () googlemail com]
> Sent: Friday, July 13, 2012 2:06 AM
> To: Gokhan Muharremoglu
> Cc: full-disclosure () lists grok org uk
> Subject: Re: [Full-disclosure] Predefined Post Authentication Session ID
> Vulnerability
>
> On Wed, Jul 11, 2012 at 11:34:11AM +0300, Gokhan Muharremoglu wrote:
> > Vulnerability Name: Predefined Post Authentication Session ID
> > Vulnerability
> > Type: Improper Session Handling
> > Impact: Session Hijacking
> > Level: Medium
> > Date: 10.07.2012
> > Vendor: Vendor-neutral
> > Issuer: Gokhan Muharremoglu
> > E-mail: gokhan.muharremoglu () iosec org
> >
> >
> > VULNERABILITY
> > If a web application starts a session and defines a session id before
> > a user authenticated, this session id must be changed after a
> > successful authentication. If web application uses the same session id
> > before and after authentication, any legitimate user who has gained
> > the "before authentication" session id can hijack future "after
> > authentication" sessions too.
>
> Uh, so, erm, you assume that someone can steal my cookie/set it/whatever
> although the Same Origin Policy should clearly not allow that, and then,
> after I have logged in, he can't just steal my cookie? Unless you allow
> setting the session-ID via an URL or so (which would IMO be pretty stupid),
> I can't see how this is a realistic, vendor-neutral attack. Could you
> explain this a bit better? I don't get it.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

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