Re: Windows 7/8 admin account installation password stored in the clear in LSA Secrets
Hi, I've often found this behaviour during security assessments for corporate Clients. It should indeed be considered a vulnerability, especially in enterprise scenarios where for instance it can be leveraged by a regular notebook user to escalate privileges and be able to access all other corporate user's notebooks (including their bosses';). Cheers, MI On Thu, 11 Jul 2013, Dnegel X. wrote: 1. I didn't find an explanation about this behavior that deals with installation password, although this LSA Secret is well known to contain passwords, mainly from Windows XP era. Could you provide a link? It also hasn't been fixed in Window 8 released this year. 2. You could e.g. retrieve a password from one vulnerable machine (where physical access or admin shell is possible) and use it against more secure ones sharing same admin password, typically when a Windows image is replicated over a network to multiple machines. Anyhow, having a cleartext password residue somewhere without documentation looks like a sad bug to me. Xavier On Thu, Jul 11, 2013 at 7:35 PM, Rob wrote: Two things: 1. This was made public sometime in 2012 or earlier IIRC. 2. Exploiting this requires the same permission levels that would be required to change or access the password anyway. Where's the realistic security threat? Rob -- -- Marco Ivaldi OPSA, OPST, OWSE, QSA, ASV Senior Security Advisor @ Mediaservice.net SrlTel: +39-011-32.72.100 Via Santorelli, 15Fax: +39-011-32.46.497 10095 Grugliasco (TO) - ITALY http://www.mediaservice.net/ -- PGP Key - https://keys.mediaservice.net/m_ivaldi.asc
Re: Windows 7/8 admin account installation password stored in the clear in LSA Secrets
1. I didn't find an explanation about this behavior that deals with installation password, although this LSA Secret is well known to contain passwords, mainly from Windows XP era. Could you provide a link? It also hasn't been fixed in Window 8 released this year. 2. You could e.g. retrieve a password from one vulnerable machine (where physical access or admin shell is possible) and use it against more secure ones sharing same admin password, typically when a Windows image is replicated over a network to multiple machines. Anyhow, having a cleartext password residue somewhere without documentation looks like a sad bug to me. Xavier On Thu, Jul 11, 2013 at 7:35 PM, Rob wrote: > Two things: > 1. This was made public sometime in 2012 or earlier IIRC. > 2. Exploiting this requires the same permission levels that would be > required to change or access the password anyway. Where's the realistic > security threat? > > Rob >
Re: Windows 7/8 admin account installation password stored in the clear in LSA Secrets
Two things: 1. This was made public sometime in 2012 or earlier IIRC. 2. Exploiting this requires the same permission levels that would be required to change or access the password anyway. Where's the realistic security threat? Rob On 07/11/2013 06:26 PM, Dnegel X. wrote: -- Bug title: Windows 7/8 admin account installation password stored in the clear in LSA Secrets Affected systems: Windows 7, 8 (related issue on XP) Author: Xavier CC -- Background: -- "Windows LSA Secrets" are stored in an encrypted form in registry along with the respective encryption keys at HKEY_LOCAL_MACHINE\Security\Policy\Secrets which is not directly accessible by an admin account. SYSTEM permissions are required to browse this key, which can be achieved by installing any service, dumping the registry hives by booting another OS on the machine, or by getting any sort of quick admin access (unlocked computer). Each secret contains a modification timestamp (Cupdtime), the current encrypted value (CurrVal), a security policy saying which user can access the secret (SecDesc), but it also stores the previous value of the secret (OldVal) and its modification timestamp (OupdTime). By using the standard Windows API, changing the value of a secret will automatically keep the previous value as OldVal. [1] When using autologin feature, the password for the autologged account is stored as the current value of DefaultPassword secret for Windows to use it instead of asking the password to the user. Bug description: -- DefaultPassword secret also stores the admin account password provided during Windows 7/8 installation. During the first boot, the DefaultPassword current value contains the user password. After a reboot, the current value is overwritten with an empty value but the mechanism behind the LSA Secrets keeps the cached password as the old value which is still accessible until someone changes the secret. Because the user is not prompted for his/her password at first boot, we believe the autologin feature is being used at that time and disabled right after, making the password cached in the LSA Secrets. Failure to properly erase the password used for autologin is believed to be the cause of the problem. Proof of concept: -- - Boot on a Windows 7/8 installation disk and proceed with installation - Provide a password for the created admin account on "Set a password for your account" screen - After being logged on to the desktop, reboot the computer - With admin privileges or by booting on another device, dump the SYSTEM and SECURITY hives - On any computer, launch ElcomSoft Proactive System Password Recovery, go to Advanced features > NT secrets, check Manual decryption, provide the dumped hives, check Show old secrets and press Manual decryption - Two values of DefaultPassword are shown: the current one which is empty, and the old one, which contains the password provided at installation in plaintext Vulnerable/tested versions: -- Checked on Windows XP SP3 x86, Windows Vista SP2 x86 Business, Windows 7 SP1 x64 Home Premium/Pro, Windows 8 x64 Pro (MSDNAA ISOs) Affected products: Windows 7, 8 On Windows XP, the password provided at installation is not cached. However, when an admin user changes his/her password when currently logged with his/her account using User Accounts in Control Panel, the changed password is cached as the current value of DefaultPassword. The previous password is still stored as the OldVal of the secret. Windows XP does not store the password when it is changed through net user or control userpasswords2. Non-admin passwords are not cached either. [2] Windows Vista doesn't seem to be affected by installation password nor password change plaintext caching. It is to be noted that a user needs to enter his/her password even on the first boot. On Windows 8, only local accounts are vulnerable while online Microsoft accounts, created or already existing, are not subject to this plaintext caching. In addition, at the first boot, it is possible to see the DefaultPassword's OldVal which gets replaced at installation. While it is empty on Windows 7, the value is "ROOT#123" on Windows 8 (and Vista), which appears to be the default admin password on some beta builds. Real-world exploitation scenarios: -- A malicious user who gets a quick access to a system with admin privileges can retrieve an admin password in little time and later use this password, if it has not been changed since installation, for wider malicious purposes. When using a company, school or public computer such as the ones provided for a short period loan, a malicious user has all the liberty to physically retrieve the needed registry files to get the admin password
Windows 7/8 admin account installation password stored in the clear in LSA Secrets
-- Bug title: Windows 7/8 admin account installation password stored in the clear in LSA Secrets Affected systems: Windows 7, 8 (related issue on XP) Author: Xavier CC -- Background: -- "Windows LSA Secrets" are stored in an encrypted form in registry along with the respective encryption keys at HKEY_LOCAL_MACHINE\Security\Policy\Secrets which is not directly accessible by an admin account. SYSTEM permissions are required to browse this key, which can be achieved by installing any service, dumping the registry hives by booting another OS on the machine, or by getting any sort of quick admin access (unlocked computer). Each secret contains a modification timestamp (Cupdtime), the current encrypted value (CurrVal), a security policy saying which user can access the secret (SecDesc), but it also stores the previous value of the secret (OldVal) and its modification timestamp (OupdTime). By using the standard Windows API, changing the value of a secret will automatically keep the previous value as OldVal. [1] When using autologin feature, the password for the autologged account is stored as the current value of DefaultPassword secret for Windows to use it instead of asking the password to the user. Bug description: -- DefaultPassword secret also stores the admin account password provided during Windows 7/8 installation. During the first boot, the DefaultPassword current value contains the user password. After a reboot, the current value is overwritten with an empty value but the mechanism behind the LSA Secrets keeps the cached password as the old value which is still accessible until someone changes the secret. Because the user is not prompted for his/her password at first boot, we believe the autologin feature is being used at that time and disabled right after, making the password cached in the LSA Secrets. Failure to properly erase the password used for autologin is believed to be the cause of the problem. Proof of concept: -- - Boot on a Windows 7/8 installation disk and proceed with installation - Provide a password for the created admin account on "Set a password for your account" screen - After being logged on to the desktop, reboot the computer - With admin privileges or by booting on another device, dump the SYSTEM and SECURITY hives - On any computer, launch ElcomSoft Proactive System Password Recovery, go to Advanced features > NT secrets, check Manual decryption, provide the dumped hives, check Show old secrets and press Manual decryption - Two values of DefaultPassword are shown: the current one which is empty, and the old one, which contains the password provided at installation in plaintext Vulnerable/tested versions: -- Checked on Windows XP SP3 x86, Windows Vista SP2 x86 Business, Windows 7 SP1 x64 Home Premium/Pro, Windows 8 x64 Pro (MSDNAA ISOs) Affected products: Windows 7, 8 On Windows XP, the password provided at installation is not cached. However, when an admin user changes his/her password when currently logged with his/her account using User Accounts in Control Panel, the changed password is cached as the current value of DefaultPassword. The previous password is still stored as the OldVal of the secret. Windows XP does not store the password when it is changed through net user or control userpasswords2. Non-admin passwords are not cached either. [2] Windows Vista doesn't seem to be affected by installation password nor password change plaintext caching. It is to be noted that a user needs to enter his/her password even on the first boot. On Windows 8, only local accounts are vulnerable while online Microsoft accounts, created or already existing, are not subject to this plaintext caching. In addition, at the first boot, it is possible to see the DefaultPassword's OldVal which gets replaced at installation. While it is empty on Windows 7, the value is "ROOT#123" on Windows 8 (and Vista), which appears to be the default admin password on some beta builds. Real-world exploitation scenarios: -- A malicious user who gets a quick access to a system with admin privileges can retrieve an admin password in little time and later use this password, if it has not been changed since installation, for wider malicious purposes. When using a company, school or public computer such as the ones provided for a short period loan, a malicious user has all the liberty to physically retrieve the needed registry files to get the admin password of the local machine and can then compromise all similar computers using the recovered password independently of its complexity. Vendor contact timeline: -- 2013-05-20: Bug found 2013-06-14: Contacted Microsoft Security Response Center 2013-06-14: Reply from M