Thx for the information !

hmmm, even though i had saw this earlier, the implications of this type of attack where not apparent to me...until now.

Basically this technique allows you to target any website from any xss hole, not just the site with the vunerability. This means site A can be used to target site b without site C (the attackers) IP never accessing site B or even site A for that matter, and it doesn't just extend to firefox. it can be used anywhere where there is a remember my details feature.

Also supposing you can ammend the source Site B at runtime, what it to stop you from injecting a cookie stealer into the source of that. so, even it their login credentials aren't present, should they be already logged in you can captcha that data as well. Or even if you can't get their user details in clear text automatically submitting the form and then stealing the cookie.

@WhiteAcid and Rsnake - good work but i think you might have paved the way for a whole new phishing industry.



Edited 2 time(s). Last edit at 08/28/2006 11:29PM by digi7al64.

I aim to please. ;)

But to be clear, my intention definitely is not to pave the way towards any new attacks, but rather to explain the already existing holes and how they can be applied. I'm not out creating holes (writing hole ridden software) nor am I writing attack/scanning software for the same reason. Explaining the issue, however, is critical to fixing the holes, which is why demo software is key. You'll notice that not a single one of the vectors on the XSS Cheat Sheet actually steal cookies or otherwise. That part is not interesting to me. How the vectors bypass filters definitely is, though.

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

as for preventing the password managers from storing passwords, i don't think any browsers store them for logins built with flash .. that's still probably sniffable, but that's nothing new.

i dont speak ActiveScript as a second language, but i'd assume you would have to hash the name and pass with a sessionid/salt to prevent an XSS from reading it in the redirect.

However, it's far easier to read the plaintext upon submission, by making a form stealer using the DOM - something i wrote last month to get the plaintext from the login of Invision PowerBoards (the SQL database only stores the md5 hash, which won't help you log into AdminPanel without bruteforcing the hash)

..but i always love to learn more ways to skin my neighbors cat ^^
-maluc

Correction - This does have one benefit over form stealers .. in that for those using the password manager, you can use an invisible iframe to log them out, record their plaintext and log them back in without any user interaction (may require session fixation or updating their cookies, depending on the site) .. and the user should nevar notice she was evar logged out.

But applying that to all users.. you also succeed in repeatedly logging out those without the managers, everytime they view the XSSed page.. so the stealthiness is questionable

-maluc

You could always drop a cookie or otherwise watch their session to avoid logging them out over and over again. There are ways around it. ;)

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

i agree, but i'm not sure if there is a way to determine ahead of time, whether or not they use a manager .. so you would still have to logout those without managers atleast once

for sites that allow auto-login via cookies, you're right that it's easy to just record their cookies and reset them afterwards to the logged-in values. So this should work well for sites like forums .. where an attacker would otherwise have to delete the cookies of a user, in order to force them to use the login form + form stealer once.

-maluc

Ah, now I see why you are saying you wanted to log them out... you are probably right... That would definitely speed things up.

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

Perhaps there is a way to simply detect if they are using a password manager, specifically the one in Firefox(since it seems to be the main target of this) then simply not log them out if they aren't.

In regards to O.P., The textbox renders correctly for me in Opera.

- Kyran

That may or may not be possible with certain versions... one easy way to detect it is to see if the username gets popuplated or not (but that doesn't help much since I think the main problem is wether to ask the user or not at all). One of the most popuplar password managers is google's toolbar. Almost everyone has it installed, despite it being spyware, so it's hard to detect if they are using it or not, because lots of people have it. So maybe there is some other way I'm not thinking of...

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

well in the process of trying to detect the password manager.. which my guess is that it's not possible .. i found what looks like a reliable firefox test. http://maluc.sitesled.com/fftest.html

AFAIK you aren't able to change this behavior in firefox, and are unable to add an about:config file to a local proxy, invalid filename. A proxy could filter it obviously though, and greasemonkey.

Should make a thread of all reliable browser and version tests, when i compile them together.

-maluc

That's using a similair technique to detecting IE using the res:// (ie res://C:\WINDOWS\system32\shdoclc.dll/dnserror.htm) urls that rsnake wrote about, can't find a link though. Nice one though.

Good work though.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

Yah, I agree, that's excellent! I hadn't thought about that one, and it's pretty definitive too. Have you tried this under Netscape though? It might only detect the Gecko rendering engine - not the browser itself. I don't have Netscape installed on this machine that I'm on at the moment or I'd check myself.

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

Opera is somewhat based off of Gecko and it gives a false positive.

- Kyran

hrm, i tested it with opera as well, on XP SP2 version 8.54 .. maybe its since changed with version 9.

what version and OS did you run it on?

-maluc

Well i checked with Opera v9 and it does give a false positive.. while v8.54 does not. So might come in handy for version testing, combined with other signatures..

it also is a false positive for the newest netscape alteast .. i'll try to refine it later today. On a side note, netscape also seems to support the chrome:// protocol, whereas opera does not.

-maluc

so perhaps the extension detection will help further define between the Gecko browsers.

- Kyran

reliable browser testing makes me cry.. http://maluc.sitesled.com/headache.jpg

not to mention safari.. although when the likes of opera/netscape/safari/etc each only have 1% of the market share, its often not worth the trouble..

-maluc

Kyran, I think you're on to something... by detecting specific extentions that are only supported by certain browsers you can really know a lot more about the user. This is also an interesting way to detect robots that lie about what OS they are. ;)

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

With all the support Google has given Mozilla and how occasionally a google-bots user agent appears to be firefox.. I'd say there is a good chance at least a few(we all know google is a million tiny projects thus inconsistent) of the spiders used by google are modified Firefox browsers with a custom extension.

Any thoughts?

- Kyran

Google doesn't tend to pull embedded style sheet or JavaScript at all. Apparently it has on occation, but that's a rarity, and it doesn't act on the JavaScript even if it does pull it.

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

Open this in Opera.
http://opera.freehostia.com/versioncheck.html
Should work with Opera 7.6+

- Kyran

That's cute... Well if you have any Opera specific exploits that only work in a specific version I guess we now know how to accurately figure out which is which.

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

The buildnumber is rather useless except for personal debugging, but the version works no matter what your Opera is masked as. "Identify as IE" etc.

- Kyran

@Girzi

After that: Can't u just call a new xmlhttp request in the iframe to a remote php file and send the userinput?

Keep in mind that xmlhttp requests can only go to pages within the same domain.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

maluc Wrote:
-------------------------------------------------------
> i agree, but i'm not sure if there is a way to
> determine ahead of time, whether or not they use a
> manager .. so you would still have to logout those
> without managers atleast once
>
>
> -maluc
I was rereading this thread and suddenly this popped into my head.
Prior to the script injection, add a form and input named user_name or similar.

<form name="logtest"><input type="text" name="username"></form><script blah blah

The html will be loaded into the DOM, then with the script, prior to logging them out, you can check if the form logtest.username was populated by firefox/opera(If you can get them to execute the wand, or SE them into using a button like this http://operawiki.info/PowerButtons#retrievewand)/etc.

- Kyran

Nice, I hadn't thought of that.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

maluc Wrote:
-------------------------------------------------------
> well in the process of trying to detect the
> password manager.. which my guess is that it's not
> possible .. i found what looks like a reliable
> firefox test.
> http://maluc.sitesled.com/fftest.html
>
> AFAIK you aren't able to change this behavior in
> firefox, and are unable to add an about:config
> file to a local proxy, invalid filename. A proxy
> could filter it obviously though, and
> greasemonkey.
>
> Should make a thread of all reliable browser and
> version tests, when i compile them together.
>
> -maluc

I had an idea and did my own test just for fun:
http://hannil.freehostia.com/check/check.html