New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 848997 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Password auto-complete function vulnerable to Hosts file changes

Reported by richevil...@gmail.com, Jun 2 2018

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Password auto-complete function of Chrome auto fills ID and password on manipulated web site by hosts file modulation. If target victim's hosts file points to hacker's web page, hacker can get their passwords more easily.
How-to Hack
1. Manipulate the victim's hosts file.
I set "nid.naver.com" (Korea's Big Search Engine site) points to "localhost"
2. Wait the victim clicks ID / PW form or "Submit" button with password that is auto-completed.
3. Hack successful.

<File Attached>
getpassword_using_hostmani.html - My test web page used for getting password
chrome_report_20180602.mp4 - Video shows the process of hacking

Sorry for my bad English, if you have more questions about this issue, please contact me whenever you want...

VERSION
Chrome Version: 67.0.3396.52 (Official Build) + beta (64-bit)
Operating System: Windows 10 1803 Build 17134.81

REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

 
getpassword_using_hostmani.html
673 bytes View Download
chrome_report_20180602.mp4
6.3 MB View Download
Components: UI>Browser>Passwords
Labels: Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Summary: Security: Password auto-complete function vulnerable to Hosts file changes (was: Security: Password auto-complete function auto-filling manipulated web site by Pharming (Hosts file modulation))
Modifying the user's host file is a privileged operation that requires a significant level of permission. Thus, this issue can be summarized as "After I've compromised the user's PC, I have compromised the user's PC."

Of course, DNS is an inherently non-secure protocol, and if passwords are filled into HTTP pages, they're inherently subject to attack, making the interesting part of this issue basically the same as  Issue 777272 . 

Well-designed sites use HTTPS and HSTS which prevents use of this type of attack without first obtaining a valid certificate for the victim site.

The one somewhat interesting bit to verify here is whether Chrome will autofill a password into a http page if it were stored via a httpS page. I /think/ it doesn't, but someone on the password manager team can confirm.
As you can see on the video, Chrome autofills a password into a http page if it was stored on a https page...
And there was an attack that modifies user hosts file or wireless router modify attack on my country, it gave many people damage.. So I reported Chrome auto fills the password even the website is a fake site... Sorry for my English.
Cc: vabr@chromium.org nepper@chromium.org
vabr, nepper: Would you be able to confirm the question about https passwords being autocompleted on http pages?

Comment 4 by vabr@chromium.org, Jun 5 2018

Chrome definitely won't fill a password saved for a HTTPS origin to a frame with a non-secure HTTP version of that origin. I also just tested this with www.cybergrants.com on my machine (GNU/Linux) and Chrome 67.0.3396.62:

(1) Save a password on https://www.cybergrants.com (can use the key icon top-left to save even without submitting).
(2) Modify /etc/hosts to include:
127.0.0.1	www.cybergrants.com
(3) Navigate to http://www.cybergrants.com
(4) Nothing is filled and cannot be filled on demand either.

A possible explanation of what I see in the video is that Chrome stored credentials for both HTTP and HTTPS versions of that host.
Status: WontFix (was: Untriaged)
vabr: Thanks!

richeville703: Can you please check chrome://settings/passwords to see if the http version of the site has the password saved?

Aside from that, this is a local attack and is not in Chrome's threat model as described in comment #1, so I'm closing it as WontFix. Please let us know if you have further information and we can reevaluate.


meacer: Sorry, I should have checked the stored password list first. There was a password which is for HTTP version (I don't know why this saved on my PC). When I deleted password on HTTP version, the problem demonstrated on the video was not showing. I'm sorry for uploading this false report...

Comment 7 by vabr@chromium.org, Jun 6 2018

Thanks for checking the password list, richeville703!
Yes, thanks for confirming!
Project Member

Comment 9 by sheriffbot@chromium.org, Sep 12

Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -vabr@chromium.org

Sign in to add a comment