Slashdot Mirror

← Back to Stories (view on slashdot.org)

Academics Claim Google Android 2FA Is Breakable (theregister.co.uk)

Posted by BeauHD on from the two-factor-authentication dept.

totalcaos writes: Attackers who control the [browser on the] PC of a user consuming Google services (Gmail, Google+ etc) can surreptitiously push and activate apps on the user's mobile device, bypassing SMS-based two-factor authentication (2FA) via the phone. How Anywhere Computing Just Killed Your Phone-Based Two-Factor Authentication is a paper that explains the wider issues of phone-based 2FA. Herbert Boss, professor of systems and security at Vrije Unversiteit Amsterdam, who co-authored the mobile security paper with the two PhD students, disclosed the vulnerability to Google but they "still [refuse] to fix it."

16 of 48 comments (clear)

  1. duplicate by Anonymous Coward · · Score: 5, Informative

    https://it.slashdot.org/story/...

  2. Fixable by phone-side installation prompt by Todd+Knarr · · Score: 2

    Fix should be simple: when an app's installed remotely from the browser, queue the installation and put up a notification asking the user to confirm the installation. Installation doesn't proceed until the user responds affirmatively to the prompt (if they respond negatively, the installation's de-queued). The authors are right, though, that the more tightly you integrate the browser-based services with the phone the less you can depend on the separation of the two for security. What's different here is that it's showing that tight integration between Google's services and the phone affects vendors other than Google.

    1. Re:Fixable by phone-side installation prompt by SmilingBoy · · Score: 2

      I think you miss the premise of the paper. The PC that you use to access Google services is under control of an attacker. Therefore, even if 2FA is turned, it will not actually be requested if it is accessed from the computer in question.

    2. Re:Fixable by phone-side installation prompt by chill · · Score: 5, Interesting

      If the your main PC that is used to control your Google accounts, including permissions, is under the control of bad actors, you're screwed either way.

      They could always just turn off 2FA from the PC.

      This paper is akin to bitching if someone got a hold of my phone in my home, where location based trust is used and keeps the phone unlocked, then the bad actor could install stuff then.

      Duh!

      It is next to impossible to ensure security if the bad guys have control of the actual hardware.

      P.S. -- You misunderstood the premise of the person you were replying to. They are saying turn on 2FA for accessing your Google accounts ON THE PC. That way you need control of not only the PC, but the phone as well to essentially get control. Perfect? No. A much bigger hurdle? Yes.

      --
      Learning HOW to think is more important than learning WHAT to think.
    3. Re:Fixable by phone-side installation prompt by msauve · · Score: 5, Interesting

      I think you missed the point of the GP - Google also support s 2FA for the PC web browser, which requires you have the phone in order to complete the sign on. The authors say they "assume that the attacker already has control over the victim's PC," but that's not right. They assume that they not only have the PC, but a running browser which the user left logged into Google services. The paper just glosses over this.

      Simply having access to someone's PC and Google credentials is not enough if they have turned 2FA on for the web, they would also need the phone to complete the sign on on the PC. If they have control of both factors (name/password and phone), it is not a failure of 2FA, that's exactly how 2FA is intended to work. And, if you're going to base a claim on such a poor premise, why not simply premise it on the attacker having the phone itself, already logged into Google services, which makes the whole thing even easier?

      This is a very poor paper. Having started with that faulty premise, they go on through a bunch of stuff which simply doesn't matter. Perhaps I'll write a similar paper about how water is wet. I'll also point out that the paper also claims a similar vulnerability for Apple's iOS, which the summary ignores. That seems pointedly biased.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    4. Re:Fixable by phone-side installation prompt by TheRaven64 · · Score: 2

      The authors say they "assume that the attacker already has control over the victim's PC," but that's not right. They assume that they not only have the PC, but a running browser which the user left logged into Google services

      If the user is using much Google stuff, then that's pretty easy. Just wait until they log into gmail and open an invisible tab with the same cookie. And if that asks for authentication then pop up a thing in the gmail tab saying 'for extra security, Google needs you to authenticate again'. Now you've compromised their Google account and you can install the 2FA trojans for everything else.

      --
      I am TheRaven on Soylent News
    5. Re:Fixable by phone-side installation prompt by mlts · · Score: 2

      How is this different from someone who manages to get a RAT on a victim's computer and control iTunes, installing/buying/removing apps at will? iOS is pretty much "vulnerable" to the same thing.

    6. Re:Fixable by phone-side installation prompt by chill · · Score: 2

      It is essentially the same thing. Unless you absolutely trust nothing, this is a possibility. The problem comes because there is a limited amount of trust based on things like other device ownership, location and paired association.

      I like the convenience I get from my phone not locking when I'm at home, or when it is paired via BlueTooth to my car radio. I made the conscious choice to weaken the security and not require manual unlocking in those situations.

      Because of my home PC being the main control point for everything I have, if that is ever taken over, I'm fairly well screwed. I *could* make it much harder, requiring 2FA (not via phone) for logging in to my home PC and not saving any accounts or passwords, but it is a much bigger pain-in-the-ass than is justified by risk likelihood.

      --
      Learning HOW to think is more important than learning WHAT to think.
  3. Is this a proof of concept? by Errol+backfiring · · Score: 2

    The second link is to a google doc, which is a possible attack vector according to the submission. Should I visit this link with my android phone? Or is someone really not thinking clearly?

    --
    Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
  4. Link uses Google PDF viewer to read the paper by Anonymous Coward · · Score: 2, Funny

    Is that the exploit?

  5. Interesting but not sure how 'practical' it is by trawg · · Score: 5, Informative

    I glanced through some of the Android parts of the paper; it describes these as 'practical attacks' but it also opens with "we assume that a victimâ(TM)s PC has been compromised, allowing an attacker to perform Man-in-the-Browser (MitB) attacks", so it would appear the immediate risk would be at least on the low side. Unless your PC is pwned, but of course if that's the case, you're in trouble already.

    For Android, the paper describes a mechanism by which a malicious app can be published to the Google Play store, then silently installed and activated through a Google Chrome plugin trojan (installed as part of the PC pwnage). There are more [interesting] details about how that process works and circumvents some existing Google tricks intended to stop it (e.g., static analysis of apps).

    At this point, the app can now intercept SMS tokens that are sent to you as part of 2FA.

    I was mostly interested to see if there were vulnerabilities in the Google Authenticator mechanism/implementation; it seems that this is not the case. It basically just takes advantage of the fact that Google offer a way to skip the Google Authenticator by using an SMS instead, although I guess this requires that your Google account is set up with a phone number (which may or may not be a requirement?).

    The end of the paper notes that "Google believes that our proposed attack is not feasible in practice". I feel like eventually we'll see a bunch of common trojans that are set up to mess with 2FA. I kind of think that this is a pretty involved process with a lot of room for things to go wrong (for the attackers) so how effective it is remains to be seen. (I also wonder with Android M if the permissions model is different enough so that the SMS reading permission needs to be invoked on a per-app basis? But that might be work-aroundable anyway.)

    1. Re:Interesting but not sure how 'practical' it is by karmatic · · Score: 2

      "I was mostly interested to see if there were vulnerabilities in the Google Authenticator mechanism/implementation; it seems that this is not the case."

      For the standalone authenticator, the security largely comes from the security of the built-in hash function. If that's broken, so are a lot of things.

      Barring that, the goal would be to extract the secrets from the app. Google likes to use time-based, which means that a cloned token won't get out of sync, and won't be detected (though it does protect against attacks where someone says the first OTP is wrong, gets a second one, then redirects you with the first, leaving them with the second).

      On a rooted device (particularly ones with non-standard bootloaders), it's reasonably easy to extract those secrets if you get your hands on the device, even if it's just to modify the device to log the decryption password. Once you have the secret, you have all the tokens you want.

    2. Re:Interesting but not sure how 'practical' it is by SmilingBoy · · Score: 3, Interesting

      Apparently it is not possible. See http://stackoverflow.com/quest... - "This code requires the activity to be in memory and in the foreground. Without root access and without modifying Android's source there is no way you can one can take a screenshot."

    3. Re:Interesting but not sure how 'practical' it is by fuzzyfuzzyfungus · · Score: 2

      Given that basically everyone with something even resembling an 'ecosystem' is pushing as hard as they can to have users logging into the same services, under the same account, on their phones, computers, tablets, etc. the only real fix is going to involve dropping the pitiful little farce that 'something on your phone' is actually a 'second factor' in any useful sense.

      Phones(whether running software implementations of authentication fobs, or using SMS) have never been ideal for the job(software fobs on network connected devices are obviously vulnerable to attack; and SMS could hardly have been designed with less interest in securing the contents of messages); but at least in the dumbphone days there was no particularly good way to correlate the PC you just hacked with the correct phone, must less initiate a push install of some horrid BREW or mini-java-something program to the handset. The user would be pretty screwed if they were going up against a state-level adversary, since those typically have the full cooperation of the telco and thus do have a decent shot at identifying the correct handset and getting access to the SMS traffic sent to it.

      Thanks to the vendors' cross-platform ambitions, though, we have the same lousy device security(possibly worse, since the OSes have gotten substantially more complex); but correlating the target PC and the target phone is no longer an intractable business for all but the atypically motivated and well supplied. I doubt we'll see much change, since it's probably still less dreadful than most people's passwords; and it's certainly a lot cheaper than any of the proper 'second factor' options; but it's not really a second factor.

    4. Re:Interesting but not sure how 'practical' it is by tepples · · Score: 2

      The confusion is that "OTP" stands for one-time pad, which you're talking about, and one-time password, which people discussing Google Authenticator are talking about.

  6. Uhh... by The+MAZZTer · · Score: 3, Interesting

    Nobody's beaten Google's 2FA. Remote install does not REQUIRE 2FA. If Google should decide it does, they can throw up a prompt for a code when you go to do a remote install and suddenly the "vulnerability" is gone. I agree with the article as much as they might want to do this. Right now Google uses 2FA for login and protecting account security settings only.

    It's important to note that an attacker would already have to be logged in as a user. If a user keeps themselves logged into an insecure PC an attacker can use there's only so much Google can do... the article doesn't really mention the attacker has access to much of the user's Google services and data in addition to remote install. It brings to mind the "It rather involved being on the other side of this airtight hatchway" class of "vulnerability" that Raymond Chen bases off a quote from The Hitchhiker's Guide.

    In addition there's a couple problems not addressed in the link I can see. First of all, AFAIK, other than on a really old version of Android through a glitch, any newly installed app cannot run any code until the first time the user launches it. Then it is allowed to install background services and whatever. But not before then. So if you manage to silently install an app which the user never sees or runs you've defeated yourself. Secondly, this can only be used to install apps from Google Play, which Google can manage to take down malicious apps as they are reported.