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 10:49:06 +0100
From: Benji <me@...ji.com>
To: Gokhan Muharremoglu <gokhan.muharremoglu@...ec.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Predefined Post Authentication Session ID
	Vulnerability

Yes, god Jann, you're such a moron.

On Fri, Jul 13, 2012 at 9:46 AM, Gokhan Muharremoglu
<gokhan.muharremoglu@...ec.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@...ec.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@...glemail.com]
> Sent: Friday, July 13, 2012 2:06 AM
> To: Gokhan Muharremoglu
> Cc: full-disclosure@...ts.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@...ec.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/