New issue
Advanced search Search tips

Issue 818156 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 777272
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Cached passwords are exposed to page DOM of HTTP pages after single click or keypress

Reported by elliott....@surecloud.com, Mar 2 2018

Issue description

When a page is loaded that has associated cached credentials, Chromium inserts these credentials into the respective fields.
Text fields are immediately available in page DOM.
Password fields are available in page DOM only after some interaction. This interaction can be a single click anywhere on screen or a keypress.

In a Man-in-the-Middle attack or Cross-Site Scripting attack a user would only need to click or press a key to have their cached password captured from Chromium.

Firefox & Safari prevent this by requiring clicking on the field itself and selecting the username from a dropdown. This also prevents the fields from being hidden from users. This was also previously the case in Chromium.

VERSION
Chrome Version: 64.0.3282.186
Operating System: Windows 10.0.16299 Pro

MitM ATTACK EXAMPLE
Using this behaviour it is possible to reliably capture the administrator credentials for various common routers WITHOUT having the ‘victim’ login to see the credentials being sent in a POST request.

(1-5 are standard Karma attack, ignore if the steps are known)

1. TARGET is connected to their own WIFI_NETWORK
2. ATTACKER sends 802.11 DEAUTH to TARGET
3. TARGET is disconnected from WIFI_NETWORK
4. TARGET sends wireless PROBES for other known networks
5. ATTACKER responds to PROBES, causing TARGET to connect to MALICIOUS_WIFI

(6-9 are related to the actual vulnerability being reported)

6. ATTACKER triggers CAPTIVE PORTAL detection (On Windows this uses the default browser)
7. CAPTIVE PORTAL is hosted by ATTACKER on the most likely IP address used by router interface (must be guessed)
8. CAPTIVE PORTAL has invisible fields which TARGET Chromium populates with username and password
9. If TARGET clicks anywhere on CAPTIVE PORTAL, the username and password are both exposed to the DOM of the malicious CAPTIVE PORTAL and sent to ATTACKER.

(10-12 are slight additions that make the attack more useful, not specifically relevent to Chromium)

10. ATTACKER stops MALICIOUS_WIFI network
11. TARGET automatically reconnects to WIFI_NETWORK
12. CAPTIVE_PORTAL is still running, when connected to WIFI_NETWORK the username and password are used to capture/change any information in the admin interface. In many cases this includes the network name and PSK.

CODE:
The attached files execute the attack using Kali Linux on a Raspberry Pi.
HostAPD is currently configured to use the Karma attack as well as expose the 'Starbucks_wifi' network for debugging.

 
1-clean.sh
305 bytes View Download
2-ipstart.sh
50 bytes View Download
3-firewall.sh
722 bytes View Download
4-dnsmasq.sh
55 bytes View Download
5-portal.py
854 bytes View Download
6-hostapd-wpe.sh
49 bytes View Download
hostapd-wpe.conf
36 bytes Download
portal.html
14.3 KB View Download
Cc: dvadym@chromium.org
Components: UI>Browser>Passwords
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows
This is working as designed; the feature is named PasswordValueGatekeeper.

> This was also previously the case in Chromium.

To the best of my knowledge, this is not correct. It's only true in Incognito mode, or if the use manually changes the setting. https://textslashplain.com/2017/12/28/taking-off-your-nametag/
Many thanks, I expected this was a convenience trade-off. For HTTPS it makes absolute sense, but for HTTP it does reduce the barrier to credential theft.

But I accept this is intended behaviour and happy for it to be closed.
Mergedinto: 777272
Status: Duplicate (was: Unconfirmed)
Just to add,

We're going to be creating and releasing a writeup and (at some point) releasing the example code as it was used to capture a router's PSK in a recent engagement that a client is intending to make public.

As the feature is working as designed and this report will eventually go public anyway, I expect there is no issue with this from Chromium's side. If this is incorrect please do let me know.
Thanks for checking, we welcome the writeup. Please do consider adding a link to it here when available for future bug readers.
Project Member

Comment 6 by sheriffbot@chromium.org, Jun 9 2018

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

Sign in to add a comment