Date: Fri, 13 Jul 2012 14:23:39 +0300
From: Gokhan Muharremoglu <gokhan.muharremoglu@...ec.org>
To: "'Gage Bystrom'" <themadichib0d@...il.com>,
	<full-disclosure@...ts.grok.org.uk>
Subject: Re: Predefined Post Authentication Session ID
	Vulnerability

Ok. It seems i have to explain this vulnerability's effects with another
scenario.

This is a real life scenario and i wrote it in a Turkish article for
National Information Security Portal which is run by TUBITAK.

Article in Turkish with scenario =>
http://www.iosec.org/oturum_oncesi_tanimli_cerez.pdf

I  will explain it in English now.

There are KIOSK/Terminal machines at bank branches in Turkey. Customers can
reach to the regular Internet banking applicaton from here. 
But these machines are restricted with policies and you can not view any
other web site or close browser page. But you can type in to the address
bar.
All you can do is to enter bank's internet web application. 

Here is the scenario (taken from real life):

1. Type "javascript:alert(document.cookie)" to the address bar and copy all
information including Session ID.
2. Wait for a victim who logs in to the KIOSK.
3. After he/she logins, use your copied Session ID to login as him/her. 
 
In this scenario;
There was no same-origin restrction,
There was no httpOnly cookie tag.

Always remember "A chain is only as strong as its weakest link". This is a
vulnerability, it's attacker's and conditions' decision how to use it.

You can use wider vision to consider about real life scenarios. 

Gokhan Muharremoglu

-----Original Message-----
From: Gage Bystrom [mailto:themadichib0d@...il.com] 
Sent: Friday, July 13, 2012 1:40 PM
To: Gokhan Muharremoglu; full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] Predefined Post Authentication Session ID
Vulnerability

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%22
Told%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@...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/

Powered by blists - more mailing lists