Slashdot Mirror


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.

7 of 35 comments (clear)

  1. I found it works on Slashdot by squiggleslash · · Score: 4, Funny

    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.
    1. Re:I found it works on Slashdot by NotInHere · · Score: 2
  2. I don't know why he says it can't be blocked. by 140Mandak262Jamuna · · Score: 3

    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
  3. Another way to bypass it by FalleStar · · Score: 5, Informative

    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.

    1. Re:Another way to bypass it by swillden · · Score: 2

      Nicely done.

      I expect this may turn into something of an arms race between phishing page authors and Google. The cleverest phishers may be able to stay consistently ahead of the extension, but I expect that they'll have to work for it... or would if significant numbers of people used the extension. I just checked the Chrome Web Store and so far there have only been 67K downloads. That's something but it's a long, long way from universal coverage.

      The positive aspect of that is that as long as usage remains low, it won't make sense for phishers to bother trying to defeat it, which means it will offer good protection to the few who do.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  4. Use the original article by thrill12 · · Score: 2

    ... 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
  5. Chrome extension model is flawed by Anonymous Coward · · Score: 2, Interesting

    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.