Chrome password manager should bind credentials to HTTPS certificates
Reported by
rnsz...@gmail.com,
Dec 14 2016
|
|||
Issue descriptionI will report a vulnerability in Google Chrome's automatic password entry function (Password Manager). Here, the Password Manager is a function to automatically put the user name and password entered by the user on the login page of a specific website into the form at the second or after visit. Even if it is a fake site, Google Chrome may automatically enter the password. An attacker can exploit this vulnerability to steal user's password and account name. DETAILS AND REPRODUCTION CASE: Currently, Chrome password manager will operate roughly under the following conditions. 1. "FQDN", "Protocol", "Destination", etc. of the WEBsite where the password is stored and the WEBsite to be automatically entered must match. 2. On the broken HTTPS website, automatic entry does not work even if 1 condition is satisfied. The problem is that the SSL / TLS certificate is not included in the condition of 1. Basically, the password manager does not automatically enter the password on the website using the disguised SSL certificate. However, even websites that use camouflaged certificates may decide that Chrome is a valid SSL certificate. For example, I. A vendor's Root certificate such as "eDellRoot" or "Superfish" was pre-installed. Computers with Root certificates used for man-in-the-middle attacks like Superfish may decide that certificates is a valid SSL website. II. A vulnerability exists in the proxy of security products such as "Avast" or "Kaspersky". We have successfully stealed passwords on SSL websites disguised with Avast's products and Kaspersky's products as far as we have investigated. Of course, there are problems with security products In this case , But there is also a serious problem with Chrome, which password manager runs even on disguised SSL certificates. SUGGEST A SOLUTION: We propose to include certificate information in Password Manager's operating condition 1. For example, the issuer of the certificate, the hash value of the certificate, etc. If the hash value or publisher changes due to renewal of the certificate, you should let the user enter the account name and password again.
,
Dec 14 2016
The proposal here is to bind auto-filled credentials to the certificate chain on which the credentials were originally saved. In practice, this would be quite disruptive, as it means that any time the site renewed its certificate or changed certificate providers (e.g. migrating from GeoTrust to LetsEncrypt, or whatever) the password would be inexplicably lost and the user would be forced to type their password again. This, beyond being annoying, could lead the user to distrust the password manager, conditioning them to fill passwords whenever asked and thus making them more susceptible to phishing. At a higher-level, the threat model here assumes that either: 1. The local PC has already been compromised (e.g. the "superfish" case), in which case the attacker need not bother with the password filling and can simply grab passwords out of memory/local storage, or 2. A public CA has been tricked into misissuing a certificate, a threat with a much greater scope than just password theft, and one addressed by other features (e.g. Certificate Transparency, CRLSets, etc). I'll let the Password Manager team weigh in here, but I believe this is Won't Fix.
,
Dec 15 2016
Thanks for the report, and also thanks for the analysis in #2. While I agree the described issue is real, the reasons stated in #2 show why the suggested solution will likely make the phishing risk higher without contributing any other benefits. |
|||
►
Sign in to add a comment |
|||
Comment 1 by rnsz...@gmail.com
, Dec 14 2016