Issue metadata
Sign in to add a comment
|
Security: accessing stored passwords in guest mode without administrative access
Reported by
elistakz...@gmail.com,
Mar 15 2016
|
||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS There is a small work around to get access to stored passwords on guest mode without administrative access. This allows theft of gmail accounts,paypal accounts and any other sensitive accounts a person may save inside of the chrome browser VERSION Chrome Version: March 15th most updated REPRODUCTION CASE When the computer is booting up you can keep cutting it on and off to force it to ask for recovery mode/scan for problems. You go to the mode and click start. It could take 15 minutes to an hour depending on whether there really is a problem or not. At the end it'll say no problems or something similar to that and to check the log file. If you check the log file you can go to open inside of the log file and it will let you navigate through all files on the computer. From there you go to where the command prompt is located and you rename it to the name of sticky keys and you rename sticky keys to something else. From there you just turn off the computer and boot it up regularly and don't log into guest mode but first turn on sticky keys and the command prompt will oprn. From there you have access to create accounts and set administrative access or even change passwords. So from there you give the account of the person you want to steal their passwords administrative access and change their password to something you will remember and yuo log in. Once logged in you go to chrome and go into the settings and view saved password and it will ask you for administrative access. Enter the password and you can see all stored passwords in chrome. FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Please email me if you would like more info but my old school used chromebooks and i used this to get passwords to bypass the proxies.
,
Mar 16 2016
I'm having a hard time understanding the problem here, but sounds like you are saying that accessing log files allows you to see the user's home directory without logging in? michall: Can you please take a look and reassign/close as appropriate? Thanks.
,
Mar 16 2016
Yes. When performing a system repair it allows you to do so without logging in. After the system repair it prompts you to restart or check the log files of the system repair/scan. If you go into the log files you can browse files on the computer through the "save as menu" you can rename the command prompt application to the name of the "sticky keys aplicacition (sethc). Now whenever you use sticky keys the command prompt will open allowing you to change the passwords of users and grant admin access. Once you change a users password and give them admin access you can log into their user profile and go into the Chrome browser and go to the settings and find all the stored passwords chrome has stored for them
,
Mar 17 2016
,
Mar 21 2016
michall: Ping, can you please help triage?
,
Mar 23 2016
sethc is a Windows application so this is OS=Windows not OS=Chrome. The attack here appears to be describing a well known public attack involving recovery mode: http://superuser.com/questions/732605/how-to-prevent-the-sethc-exe-hack This does not affect ChromeOS so I think comment#1 is invalid. If a user has full control and physical access to a Windows system, then they can pretty much bypass any sort of protection that Chrome might put in place - this sort of attack is excluded here: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- However, I am quite surprised you are actually able to read the stored passwords since those are encrypted with a key that should be unique to that user and changing the user's password while not logged in as the user should invalidate these keys. If you are able to confirm this attack and prove that the passwords are indeed unlocked after changing a user's password then that is an issue with Windows - please report that bug separately and I can try and reproduce.
,
Mar 23 2016
For completeness, I just verified that resetting another user's password from another account does correctly invalidate the protected storage including the Chrome saved passwords, so the second part of this "attack" is also invalid.
,
Oct 1 2016
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
,
Oct 2 2016
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
,
Oct 2 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by elistakz...@gmail.com
, Mar 15 2016