4 ms·

I recently joined the cult of the smartphone (after my feature phone finally kicked the bucket). Since I, like presumably many folks, set things up so that I c

by wheels 15y ago

I recently joined the cult of the smartphone (after my feature phone finally kicked the bucket). Since I, like presumably many folks, set things up so that I could check my email, used the web browser and let it store some passwords, I became curious about how those passwords are being stored. It turns out that it's just an SQLite database where they're stored in plain text. This leaves me somewhat disconcerted since I carry my phone around everywhere (and have a bad habit of losing them – hence waiting for ages to get a smart phone until they dropped below the price of "this won't hurt too much if I lose it"). My assumption had been that since I set a password to unlock the screen (and have a SIM card password) that it'd be tied into a keychain mechanism that unlocked access to an encrypted password store. While normal apps can't read said file (unless the phone is rooted), it's still a pretty huge vector for identity theft making it rather trivial to extract passwords from a lost / stolen phone.

daeken 15y ago
Edit: This is COMPLETELY INCORRECT (as pointed out by wallflower) but left for context. I can't test right now, but if your phone has ADB enabled, can't you pull this file over USB? I could be totally, totally off on that, though.
- wallflower 15y ago
  No, /data/data/* is protected (as it should be) on non-rooted phones. mediapc:platform-tools media$ ./adb shell $ ls /data/data opendir failed, Permission denied $
  - chopsueyar 15y ago
    But if you have physical access to the phone, why couldn't you root it?
    - ConstantineXVI 15y ago
      1) Official root methods (see `fastboot oem unlock`, as made famous by the Nexus phones) as well as many less official methods require a wipe, thus rendering this attack moot. 2) In the event your phone isn't covered by the situation in #1, having a passcode lock and not enabling ADB (developer mode) should be sufficient to protect from a root attack in most cases. It's worth noting that you're still vulnerable to a root attack that doesn't wipe and can bypass your passcode (runs from fastboot/recovery, or a hole in the passcode lock itself); though I've yet to come across a phone personally with this situation. And it goes without saying, if you've rooted your phone yourself, any OS security is null and void. If you're rooting, you should realize this already.
      - 1880 15y ago
        > if you've rooted your phone yourself, any OS security is null and void Are you sure? If I am not mistaken, even with a rooted phone, a program has to ask the user for root permission via the Superuser.apk app.
        crazysim 15y ago
        If a phone was rooted like as a action, the exploit to get root in the first place is probably still there.
        inportb 15y ago
        Ah, but how does this Superuser.apk achieve root privileges? By calling the setuid root `su` program, you say. And how does this setuid root program actually gain root privileges? Why, the OS is able to execute arbitrary code with arbitrary privileges, and it makes an exception for `su`. Wait... so Android could run processes with root privileges without asking you? Whoa! Now consider that adbd on a rooted device runs with root privileges...
        vetinari 15y ago
        Jumping to conclusions, are we? Superuser.apk does not achieve root privileges and su does not blindly run your program with root privileges. su asks superuser.apk, if your program is allowed to run as root and only when superuser.apk agrees (and displays toast), then your program is run. Also, the arbitrary privileges are reserved for setuid programs, which is not easy to achieve. Basically, su and Superuser.apk are gatekeepers to uid 0, which short of bugs, you can't get around. Also, did you know, that you can disable adbd? Or remove root privileges from it?
- kgermino 15y ago
  Thank you for leaving the original for context, it's drives me nuts when people delete a message or edit out the content when there's a string of replies.
num1 15y ago
In the mean time, be sure to enable two-factor authentication on your account. I'll admit it's not much solace as usually the second factor uses your phone...
- chopsueyar 15y ago
  Is that a Catch-22?
  - darklajid 15y ago
    No, because - the password you store on the phone (in cleartext) is not the real account password, it's a string for this device only and you can revoke access at any time - Someone should not be able to use your phone (via call/text message) as unlock device, unless you lost it - In that case you should lock the SIM for for a multitude of reasons anyway - and you'll get a new SIM that you can use to recover your account I think the first one is the most important though: You just don't have to store your real password.
drivebyacct2 15y ago
No. No it's not. please tell me how someone is going to get those passwords without root. (hint, they're not) additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc.
- chopsueyar 15y ago
  Couldn't someone take the hard drive out of your laptop and mount it in on another system and peruse through the necessary files?
  - drivebyacct2 15y ago
    Well that's just it isn't it. If you took (not mine, but most people's laptop), you'd be able to read out all of their cookies (fun, in and of itself), read the contents of their saved Firefox passwords, read the cached/stored passwords for Pidgin, etc, etc. You can't really remove the flash memory from an Android phone. I mean, you could, but if someone's that interested in you, they're going to get the information through easier or nastier means. Meanwhile, that file is protected by Android, and lacking a root exploit, not much is going to happen. Google's stewardship of the Market combined with their backporting of root escalation bug fixes makes it very hard for me to get as scared or ironically angry as those in the linked bug report.
- daeken 15y ago
  > No. No it's not. please tell me how someone is going to get those passwords without root. (hint, they're not) By running an exploit to get up to root, or by attacking it physically. Neither of these are particularly difficult or unlikely. > additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc. It's not, if you're saving passwords without a master key. If you're using, say, 1Password, then your master key has to be compromised to get the passwords.
  - drivebyacct2 15y ago
    >By running an exploit to get up to root, or by attacking it physically. Neither of these are particularly difficult or unlikely. Keeping in mind that root-escalation bugs are back ported and shipped to consumers quickly and often silently, I find that claim to be a bit bold. In fact, the popular root escalation of choice these days is very specific and must be used in conjuncture with ADB. Rogue software is going to have a hellofa time just accessing this file. >If you're using, say, 1Password, then your master key has to be compromised to get the passwords. I'm not sure we're talking about the same thing, or you missed my point: if I teach Pidgin how to login to my IM accounts (or Thunderbird, IMAP; Email.apk, my POP server; my Facebook notifier, my FB account credentials)... then those applications HAVE to cache those passwords in plaintext. Unless you're so security conscious that you type them in every time you launch your IM client. (Props if you do, but that's the scenario I'm discussing. I'm just taken aback by the pure ignorance exuded in the linked bug report) Basically, even with this "vulnerability" that absolutely can't be avoided in many cases... Android is still better off than your laptop, barring an unlikely root escalation bug (remembering of course Google's stewardship of the Market and them taking down applications using such exploits) edit: I have no problem with the notion of using oAuth to mitigate or eliminate this problem. Unfortunately, as a user or even a third party developer, that's not really a decision I get to make.

by wheels 15y ago

daeken 15y ago

Edit: This is COMPLETELY INCORRECT (as pointed out by wallflower) but left for context. I can't test right now, but if your phone has ADB enabled, can't you pull this file over USB? I could be totally, totally off on that, though.

wallflower 15y ago
No, /data/data/* is protected (as it should be) on non-rooted phones. mediapc:platform-tools media$ ./adb shell $ ls /data/data opendir failed, Permission denied $
- chopsueyar 15y ago
  But if you have physical access to the phone, why couldn't you root it?
  - ConstantineXVI 15y ago
    1) Official root methods (see `fastboot oem unlock`, as made famous by the Nexus phones) as well as many less official methods require a wipe, thus rendering this attack moot. 2) In the event your phone isn't covered by the situation in #1, having a passcode lock and not enabling ADB (developer mode) should be sufficient to protect from a root attack in most cases. It's worth noting that you're still vulnerable to a root attack that doesn't wipe and can bypass your passcode (runs from fastboot/recovery, or a hole in the passcode lock itself); though I've yet to come across a phone personally with this situation. And it goes without saying, if you've rooted your phone yourself, any OS security is null and void. If you're rooting, you should realize this already.
    - 1880 15y ago
      > if you've rooted your phone yourself, any OS security is null and void Are you sure? If I am not mistaken, even with a rooted phone, a program has to ask the user for root permission via the Superuser.apk app.
      - crazysim 15y ago
        If a phone was rooted like as a action, the exploit to get root in the first place is probably still there.
      - inportb 15y ago
        Ah, but how does this Superuser.apk achieve root privileges? By calling the setuid root `su` program, you say. And how does this setuid root program actually gain root privileges? Why, the OS is able to execute arbitrary code with arbitrary privileges, and it makes an exception for `su`. Wait... so Android could run processes with root privileges without asking you? Whoa! Now consider that adbd on a rooted device runs with root privileges...
        vetinari 15y ago
        Jumping to conclusions, are we? Superuser.apk does not achieve root privileges and su does not blindly run your program with root privileges. su asks superuser.apk, if your program is allowed to run as root and only when superuser.apk agrees (and displays toast), then your program is run. Also, the arbitrary privileges are reserved for setuid programs, which is not easy to achieve. Basically, su and Superuser.apk are gatekeepers to uid 0, which short of bugs, you can't get around. Also, did you know, that you can disable adbd? Or remove root privileges from it?
kgermino 15y ago
Thank you for leaving the original for context, it's drives me nuts when people delete a message or edit out the content when there's a string of replies.

num1 15y ago

In the mean time, be sure to enable two-factor authentication on your account. I'll admit it's not much solace as usually the second factor uses your phone...

chopsueyar 15y ago
Is that a Catch-22?
- darklajid 15y ago
  No, because - the password you store on the phone (in cleartext) is not the real account password, it's a string for this device only and you can revoke access at any time - Someone should not be able to use your phone (via call/text message) as unlock device, unless you lost it - In that case you should lock the SIM for for a multitude of reasons anyway - and you'll get a new SIM that you can use to recover your account I think the first one is the most important though: You just don't have to store your real password.

drivebyacct2 15y ago

No. No it's not. please tell me how someone is going to get those passwords without root. (hint, they're not) additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc.

chopsueyar 15y ago
Couldn't someone take the hard drive out of your laptop and mount it in on another system and peruse through the necessary files?
- drivebyacct2 15y ago
  Well that's just it isn't it. If you took (not mine, but most people's laptop), you'd be able to read out all of their cookies (fun, in and of itself), read the contents of their saved Firefox passwords, read the cached/stored passwords for Pidgin, etc, etc. You can't really remove the flash memory from an Android phone. I mean, you could, but if someone's that interested in you, they're going to get the information through easier or nastier means. Meanwhile, that file is protected by Android, and lacking a root exploit, not much is going to happen. Google's stewardship of the Market combined with their backporting of root escalation bug fixes makes it very hard for me to get as scared or ironically angry as those in the linked bug report.
daeken 15y ago
> No. No it's not. please tell me how someone is going to get those passwords without root. (hint, they're not) By running an exploit to get up to root, or by attacking it physically. Neither of these are particularly difficult or unlikely. > additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc. It's not, if you're saving passwords without a master key. If you're using, say, 1Password, then your master key has to be compromised to get the passwords.
- drivebyacct2 15y ago
  >By running an exploit to get up to root, or by attacking it physically. Neither of these are particularly difficult or unlikely. Keeping in mind that root-escalation bugs are back ported and shipped to consumers quickly and often silently, I find that claim to be a bit bold. In fact, the popular root escalation of choice these days is very specific and must be used in conjuncture with ADB. Rogue software is going to have a hellofa time just accessing this file. >If you're using, say, 1Password, then your master key has to be compromised to get the passwords. I'm not sure we're talking about the same thing, or you missed my point: if I teach Pidgin how to login to my IM accounts (or Thunderbird, IMAP; Email.apk, my POP server; my Facebook notifier, my FB account credentials)... then those applications HAVE to cache those passwords in plaintext. Unless you're so security conscious that you type them in every time you launch your IM client. (Props if you do, but that's the scenario I'm discussing. I'm just taken aback by the pure ignorance exuded in the linked bug report) Basically, even with this "vulnerability" that absolutely can't be avoided in many cases... Android is still better off than your laptop, barring an unlikely root escalation bug (remembering of course Google's stewardship of the Market and them taking down applications using such exploits) edit: I have no problem with the notion of using oAuth to mitigate or eliminate this problem. Unfortunately, as a user or even a third party developer, that's not really a decision I get to make.