Researcher Bypasses Google Password Alert For Second Time
Trailrunner7 writes with this excerpt: A security researcher has developed a method–actually two methods–for defeating the new Chrome Password Alert extension that Google released earlier this week.
The Password Alert extension is designed to warn users when they're about to enter their Google passwords into a fraudulent site. The extension is meant as a defense against phishing attacks, which remain a serious threat to consumers despite more than a decade of research and warnings about the way the attacks work.
Just a day after Google released the extension, Paul Moore, a security consultant in the U.K., developed a method for bypassing the extension. The technique involved using Javascript to look on a given page for the warning screen that Password Alert shows users. The method Moore developed then simply blocks the screen, according to a report on Ars Technica. In an email, Moore said it took him about two minutes to develop that bypass, which Google fixed in short order.
However, Moore then began looking more closely at the code for the extension, and Chrome itself, and discovered another way to get around the extension. He said this one likely will be more difficult to repair.
"The second exploit will prove quite difficult (if not near impossible) to resolve, as it leverages a race condition in Chrome which I doubt any single extension can remedy. The extension works by detecting each key press and comparing it against a stored, hashed version. When you've entered the correct password, Password Alert throws a warning advising the user to change their password," Moore said.
The Password Alert extension is designed to warn users when they're about to enter their Google passwords into a fraudulent site. The extension is meant as a defense against phishing attacks, which remain a serious threat to consumers despite more than a decade of research and warnings about the way the attacks work.
Just a day after Google released the extension, Paul Moore, a security consultant in the U.K., developed a method for bypassing the extension. The technique involved using Javascript to look on a given page for the warning screen that Password Alert shows users. The method Moore developed then simply blocks the screen, according to a report on Ars Technica. In an email, Moore said it took him about two minutes to develop that bypass, which Google fixed in short order.
However, Moore then began looking more closely at the code for the extension, and Chrome itself, and discovered another way to get around the extension. He said this one likely will be more difficult to repair.
"The second exploit will prove quite difficult (if not near impossible) to resolve, as it leverages a race condition in Chrome which I doubt any single extension can remedy. The extension works by detecting each key press and comparing it against a stored, hashed version. When you've entered the correct password, Password Alert throws a warning advising the user to change their password," Moore said.
Surprisingly, with Chrome, if you enter your Google password in the Subject box of a new comment and then press the "Submit" button, the warning dialog comes up and your post won't get sent until you confirm it. Only discovered that because my Google password is (well, was) "systemd?".
You are not alone. This is not normal. None of this is normal.
Basically the first exploit was something like a pop-up blocker that blocked the alert page from being displayed. The second one is to refresh the page at every keystroke so that the key-logging and watching extension never sees the full password, so it does not alert the user. A page that calls the refresh method for every key stroke is suspicious. The alert extension could look for this behavior and report it. Even the first exploit involving the pop-up blocker could be scanned for. The trigger for the alert-window-blocker must be obfuscated to escape detection.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
After reading the summary, I went ahead and downloaded the extension to see if I could figure out a way to bypass it. I tried a few more obvious methods first, all of which were detected by the extension.
My 4th attempt at bypassing the extension seems to work just fine though. It works by binding the window.onkeyup and window.onkeydown methods, determining which character corresponds to the key being pressed, then appending that character to the username or password fields if one of them has focus. Once the value has been added to the appropriate field, the event is cancelled using e.preventDefault(). I put a proof-of-concept up on my site in case anyone is interested. Here's the raw code for that page if you don't want to go to some random SlashDot poster's website.
This method only took a few minutes for me to come up with, so I'm probably not the first one to figure this out, but I thought I'd share anyways.
... on ars technica: http://arstechnica.com/security/2015/05/01/googles-new-version-of-password-alert-blocking-bypass-is-bypassed/. This one also has the original author of the exploit commenting on his findings.
Slashdot: stuff for news, nerds that matter, matter for news, stuff that nerd
It's always bothered me that the primary way that an extension will add extra UI elements around the edge of the page is to modify the page DOM itself, making it possible for the extension to be detected by the code within the page monitoring for particular elements. For example, this makes it trivial to detect FlashBlock, Ghostery and other such extensions in their default configurations.
Instead, Chrome should provide a real API for overlaying captions onto the page that is independent of the page itself.
A simple approach would be to just overlay another page rendered over the top, with its background defaulting to transparent and with some magic to pass mouse click events on the transparent part through to what's underneath.
Another approach would be to use a mechanism similar to "shadow DOM" to allow the extension to replace or extend the rendering of a particular DOM element in a way that doesn't actually impact the DOM tree the page sees. Although the page can "see" into the shadow DOM today, there's little reason why this "extension shadow DOM" couldn't be hidden from the page-level API altogether and visible only to the extension that created it.
Being able to manipulate the real page DOM remains useful for some extensions, so this ought to be an additional API rather than a replacement for the existing API.
Of course this only addresses the first vulnerability. The second vulnerability seems troublesome in that it waits until you've already entered your password before doing any action, which suggests that a page with a JS keylogger running in it could capture the password and submit it via XMLHttpRequest before the extension gets a chance to warn you about it.