Issue metadata
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 descriptionWhen 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.
,
Mar 2 2018
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.
,
Mar 2 2018
,
Mar 26 2018
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.
,
Mar 26 2018
Thanks for checking, we welcome the writeup. Please do consider adding a link to it here when available for future bug readers.
,
Jun 9 2018
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 |
|||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Mar 2 2018Components: UI>Browser>Passwords
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows