# Major security hole in AOSP Web browser!



## JBirdVegas

The default web browser from AOSP exposes your password in plain text!

The package com.android.browser uses the default webview which is fine until you click remember after entering your password. The browser caches the password for you so you don't have to enter the same password every time you visit the same page. Sounds good right? Well it usually is good... except the password is then stored in plain text in an SQL database at '/data/data/com.android.browser/databases/webview.db' in a table with the brilliant table name 'password'.

This is crazy and puts all android enthusiasts with rooted devices at risk. I beg of Google to fix it!

Its noteworthy that in Chrome this issue DOES NOT exist. This default behavior is however in lots of other applications that use the default webview to prompt for passwords. One such example was Trello. Once this oversight was pointed out they fixed and pushed an update within 7 hours, bravo! If an app asks you to login through a webview you should check that the app is not storing your password in plain text, use the directions below and sub out the package/app names.

Interested to see what is stored about you? (using the default browser enter your password in any website; click 'Remember'; done your password is now in plain text in a table called password... Epic fail!)
You can pull the database using adb (adb pull /data/data/com.android.browser/databases/webview.db .) then explore like you would any sql database.
or if you would like to view from your phone use SQLite Editor; in the apps tab click 'Browser' then 'webview.db' and check out the table named 'password'
All accounts are saved in this manor... including your gmail password







A screen shot of the plain text passwords :-/








**PS** AOKP is already hard at work implementing a fix for our fork of the AOSP Browser package!

**Update**
Reported as Android Issue 52895
Hacker News thread


----------



## DrMacinyasha

> rooted devices at risk


Precisely why I wouldn't expect Google to fix this anytime soon.

In short, because you (the end-user) have futzed with your phone, and *broken* the security restraints placed on the Android filesystem, you have opened yourself up to vulnerabilities. It's your responsibility to manage what you do, and don't, grant root access, and if you pick poorly, you reap the benefits, much like installing some "Super Happy Funtime!" app from a Chinese warez site that has every permission possible. You can't be too surprised if next month you have a $10,000 bill due to the app calling and texting international premium numbers, and sending all of your personal information to every website the creator could think of.

So to summarize:
Not on a rooted device? Then Google probably won't care because the filesystem permissions will block any other app that doesn't have root access to your device from accessing that database file, and ADB isn't enabled by default.
On a rooted device? Then Google and your carrier/manufacturer won't care because you made that decision, and broke your warranty. You changed a critical function of how the system works.


----------



## jbeez

what if someone steals your phone, roots it themselves and then steals your passwords, is that better?


----------



## JBirdVegas

DrMacinyasha said:


> what if someone steals your phone, roots it themselves and then steals your passwords, is that better?


Theoretically the process of unlocking should wipe the phone completely sdcard and all. (There may be exploits in some devices that forgo this step)


----------



## Soapinmouth

jbeez said:


> what if someone steals your phone, roots it themselves and then steals your passwords, is that better?


 if someone steals your phone and you have no lockscreen password on It and you have important passwords set to autofill that's your own fault. They would be able to access it with or without this bug by just using your browser.

you do have a lockscreen password, how would they go about rooting your phone without wiping the data?


----------



## PrimeDirective

has anyone fixed this in source yet? there's always a way to figure this stuff out if you know enough about it.


----------



## JBirdVegas

PrimeDirective said:


> has anyone fixed this in source yet? there's always a way to figure this stuff out if you know enough about it.


AOKP team is working on it... watch gerrit.


----------



## orion11

correct me if im wrong, but i thought this was how most browsers (desktop) store saved passwords although some have a setting to encrypt passwords, but its usually off by default.

edit - which is why usually lastpass and keypass recommend turning that feature off and using their service solely (you know, besides self promotion)


----------



## SynisterWolf

This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.

Example: You buy a house with a lock on the door, you go ahead and remove said lock. You place an add on craigslist saying you may or may not have removed the locks. You come home and all your things are gone. Do you go after the company that sold you said house and ask for a refund?

Get you head out of your @$$ and be smart, "sometimes you need to be smarter than the device you are using".


----------



## yarly

SynisterWolf said:


> This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.


Specious reasoning. An exploit can access it with or without root. Hashing a password takes barely any time from my development experience and no excuse for not doing it. One also has root all the time on PC, so I suppose we should just chuck out security on PC, because one has root there.

I don't expect Google to patch it soon, but I look at this as more of a call for all of the major ROM developers to do so as it concerns them more.


----------



## skynet11

yarly said:


> Specious reasoning. An exploit can access it with or without root. Hashing a password takes barely any time from my development experience and no excuse for not doing it. One also has root all the time on PC, so I suppose we should just chuck out security on PC, because one has root there.
> 
> I don't expect Google to patch it soon, but I look at this as more of a call for all of the major ROM developers to do so as it concerns them more.


What he said ^^^


----------



## yarly

Easiest way to fix it is generated a private/public key and then encrypt the private key with a master password. if the password needs changed (or a site password does), one would have the user enter the password to decrypt. This is how browsers do it that give you a master password option.

http://support.mozil...t-stored-logins

http://kb.mozillazin...Master_password


----------



## NUNsLAUGHTER92

I'm pretty sure every default browser has this same problem. Even dolphin used to.

"You know, a long time ago being crazy meant something. Nowadays everybody's crazy."


----------



## skynet11

SynisterWolf said:


> This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses...
> ... "sometimes you need to be smarter than the device you are using".


This might not be the *best* forum for ridiculing people who root their devices







Besides, this app comes preinstalled, so it's not a matter of 'knowing what apps you are installing'


----------



## shiznu

SynisterWolf said:


> This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.
> 
> Example: You buy a house with a lock on the door, you go ahead and remove said lock. You place an add on craigslist saying you may or may not have removed the locks. You come home and all your things are gone. Do you go after the company that sold you said house and ask for a refund?
> 
> Get you head out of your @$$ and be smart, "sometimes you need to be smarter than the device you are using".


Sent from my Galaxy Nexus using RootzWiki


----------



## skynet11

shiznu said:


> Sent from my Galaxy Nexus using RootzWiki


ROFL


----------



## Decad3nce

If someone has access to [background=rgb(245, 245, 245)]/data/data/com.android.browser/ [/background]then you have a lot more problems than plain text passwords.


----------



## jcase

You can't one way hash passwords that must be retrieved.

You can do two way encryption but that is only wasting cpu cycles when it a malicious user has root. They will just extract the decryption key and decrypt. Archon (good/smart guy/, myself and even a google employee (Nick, again super smart, nice guy) replied with nearly identical responses on this. There is nothing to patch, this is standard behavior in this case.

To prove my point, I eagerly await the release of it with encryption, expect a decryption tool release from me shortly after (ETA depending on if it is released during my trip or not)



yarly said:


> Easiest way to fix it is generated a private/public key and then encrypt the private key with a master password. if the password needs changed (or a site password does), one would have the user enter the password to decrypt. This is how browsers do it that give you a master password option.
> 
> http://support.mozil...t-stored-logins
> 
> http://kb.mozillazin...Master_password


----------



## JBirdVegas

So your argument is its better for passwords and usernames to be plaintext because encryption it won't stop experts in the field?

No passwords are 100% safe... So at what point do we stop caring?


----------



## HerbieVersmelz

If only we had a patch to fix common sense and naivety...

Sent from my Galaxy Nexus using Tapatalk 2


----------



## jcase

JBirdVegas said:


> So your argument is its better for passwords and usernames to be plaintext because encryption it won't stop experts in the field?
> 
> No passwords are 100% safe... So at what point do we stop caring?


My argument is, it is better not to store passwords at all, but even more so when a device is compromised by default.

No expertise is needed to decrypt local, two way encryption. Hell, I am far far far from a crypto expert, but when the encryption routine is opensource (or easily reversed) anyone with basic java knowledge walk right through it.


----------



## JBirdVegas

jcase said:


> My argument is, it is better not to store passwords at all, but even more so when a device is compromised by default.
> 
> No expertise is needed to decrypt local, two way encryption. Hell, I am far far far from a crypto expert, but when the encryption routine is opensource (or easily reversed) anyone with basic java knowledge walk right through it.


Agreed not storing password is the only winning move... But its not real practical. As for someone writing an app based off our open source yes... Totally possible, however literally any obfuscation would stop casual snoops.

As it stands now I can get your password using only a terminal from a rooted device; close the terminal and the owner would never know.

At least with some obfuscation the attacker would have to pull and transfer (email post to a server) the database. Now can someone then crack the password... Yea probably. It would take considerably more skills than the average user has or they could use your purposed app. My point being it would at least remove the risk of my password being found through one or two sqlite commands from a terminal, we should at least make them work for my password.

I'm not saying its 100% perfect but users are going to click Remember and I would bet almost everyone reading this has root. I think we can do better than a meh your bad. Not to mention I would have liked to know my password is in plain text before I clicked Remember.


----------



## jcase

It would remove no risks, you are missing the concept here. Security by obscurity is NOT the solution, but it is what you are proposing. Even someone from Google's own security team spoke up on this.

You can not secure locally stored passwords with two way encryption if the key is stored locally, hell even if the user has to enter another password we just listen to keyboard input, hell we are root, so lets just MITM the connection and grab the passwords as they are sent, SSL? hell were root we can add our own cert too. That is just as weak as storing them in plaintext.

Why would the attacker have to take it to a remote server to "crack" it, we don't have to crack it, we can just decrypt it on the local device, the phone it self.

EDIT

I'm done ranting and won't comment on this (here, I will continue on the bug report if it isn't dead yet) again, by all means go ahead and do this, but do not fool your users nor yourself into thinking it is more secure, it is just an alternative storage system.


----------



## JBirdVegas

Ok we will encrypt our passwords and you are welcome to break them with malware.

I completely agree its not a fix but I fail to see why the passwords are better off in plain text


----------



## droided

This crap happens all the time, why aren't passwords and account info hashed? Rememeber when gizmodo called 4chan a bunch of script kiddies and then their entire clear text database got dumped?


----------



## jcase

Please see a well cited explanation here: https://code.google....ail?id=52895#c7

Ok I lied I am commenting here. Jbird no offense, but I can't help it when you cant understand basic security concepts. I hope the code reviewers understand the subject more than you do at this point, I have a strong feeling this won't be merged into AOKP or any mainline rom. If it is, great! More fodder for my talk on rom security this Aug. I keep seeing people speak out about how "vulnerable" this is, when people who are paid to know (lets not count me, even tho I am) are straight up pointing out why it is wrong, along with citation.

Also, please learn the definition of malware.



JBirdVegas said:


> This crap happens all the time, why aren't passwords and account info hashed? Rememeber when gizmodo called 4chan a bunch of script kiddies and then their entire clear text database got dumped?


droided again, two different things, you can't do salted one way hashs in this instance, then the browser could not retrieve the password for reuse. Again, local two way encryption is the only option, and it is just as weak as plaintext in this particular case


----------



## blunden

droided said:


> This crap happens all the time, why aren't passwords and account info hashed? Rememeber when gizmodo called 4chan a bunch of script kiddies and then their entire clear text database got dumped?


 There is a difference between how a browser can store them and how the site you are logging into can store it. A browser has to be able to provide the actual password to the site. The website can and should store a one-way hash of the password and salt. When a user sends a log in request their server can add the salt and hash the password and verify that they match the hash they have already stored. If a user were allowed to just supply the hash (which would be required for what you suggest to work) the hashing would be pointless as it would basically act as if the hash was a second clear text password.


----------

