Date: Thu, 11 Jul 2013 19:35:15 -0400
From: Rob <synja@...fulvisions.com>
To: bugtraq@...urityfocus.com
Subject: 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 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 Microsoft SRC:
>              "the behavior you are reporting is not something that we
> consider a security vulnerability"
> 2013-07-11: Disclosure
>
> Workarounds/Limitations:
> ----------------------------------
> - Do not setup a password during installation, or change it right
> after (recoverable password becomes useless).
> - Store an empty value as DefaultPassword through
> LsaStorePrivateData() to flush the old value containing the password
> (requires admin privileges).
> - During the first boot after installation of Windows, store twice an
> empty value to flush completely.
> - Delete HKEY_LOCAL_MACHINE\Security\Policy\Secrets\DefaultPassword
> (requires SYSTEM privileges).
> - Network installation for Windows 7/8 (SCCM) do not seem to be
> affected by the issue.
>
> References:
> ----------------------------------
> [1] http://www.passcape.com/index.php?section=docsys&cmd=details&id=23
> [2] http://seclists.org/fulldisclosure/2006/May/119
>

Powered by blists - more mailing lists