evasion: onkeypress calling window.location.href about password-alert HOT 11 CLOSED

Yeah, the keypress-reload one is particularly odd -- and interesting.

I'm not actually sure it works -- since I think the background.js page has per-tab hashing that (should?) ignore reloaded pages.

from password-alert.

Looks like the team is already on this, Pull #25

from password-alert.

You pasted a couple of unrelated things -- the tweet at https://twitter.com/Paul_Reviews/status/594116252613873664 is an interesting concept (the others are different / patched).

from password-alert.

Thanks Jericho.

Correct, the keyboard event generation (the pastebin link) has been fixed in github, but not pushed out to the Chrome Web Store yet.

Nick's correct that background.js has per-tab hashing. Repeatedly setting window.location.href doesn't confuse the per-tab hashing. However occasionally the page refresh happens before the keypress event has made it to the keypress handler in our content_script. This causes our content_script to miss some keypresses in this case.

from password-alert.

Apologies! The downside of a 140 character medium and RT hell =) Glad you guys are on top of it.

from password-alert.

Repeatedly setting window.location.href doesn't confuse the per-tab hashing. However occasionally the page refresh happens before the keypress event has made it to the keypress handler in our content_script. This causes our content_script to miss some keypresses in this case.

Ah so "onkeypress calling window.location.href" should be fixed by #28 because the plugin gets key press first. This is still an issue if "onkeydown calling window.location.href" but this and #29 are now basically the same.

The "fix" for these is to change:
window.addEventListener('keypress', passwordalert.handleKeypress_, true);
to
window.addEventListener('keydown', passwordalert.handleKeypress_, true);

but this complicates things with caps lock, non-US keyboards, and passwords with non-standard characters (ie Alt+0255).

from password-alert.

@Sc00bz Agreed. I'm working on a commit that will switch to keydown events. However I haven't found a library to convert keydown event keyCode values into characters. As you mention, it's a complicated conversion.

from password-alert.

It's actually impossible because you can't detect if caps lock is on or off without the key press event. So you have to try both or assume caps lock is off.

from password-alert.

My current approach tries both hashes -- one hash where caps lock is initially on and one hash where caps lock is initially off.
Examining keypress events and correlating them with keydown events could also reveal the initial caps lock state. If we see a keydown event of {keyCode: 65, shiftKey: false} and then a keypress for 'A' we know that capslock is on. If an evasion technique is interfering with us seeing keypress events, then we'd have to fall back to trying both hashes.

from password-alert.

Might also be worth parsing DEL (ASCII 127) here, which isn't sent to keypress, but could be grabbed with keyDown. (I seem to mistype my own password a lot while testing...)

from password-alert.

This is fixed in source, but not yet pushed to users. If you try it out and find otherwise, please let me know!

from password-alert.