Insecurity provider. How Windows leaks user passwords

Windows features a complex authentication system with multiple components. Cornerstones of this system are LSA (Local Security Authority) and SSP.

LSA is a huge subsystem that authenticates users, creates them, changes passwords, and performs other similar operations. Also, LSA stores information about all security aspects of the local computer (e.g. number of unsuccessful password entries required to lock an account). LSA can even be used to assign privileges to user accounts; the Privileger tool has been developed for this purpose.

SSP isn’t as simple as it seems, too. Not only does it help developers to encrypt data, ensure the integrity of transmitted information, and build context, but can also expand standard authentication. To be specific, SSP/AP, not just SSP is used for this purpose (to be addressed in more detail later).

Security components

Security components are bricks forming the immense authentication system in Windows. Important: theory provided in this article applies to future articles as well. Let’s start with a simple password interception and then gradually complicate this task.

Security Package

Security Package (SP) is a software implementation of a certain security protocol. Security Packages are stored in SSP (and/or SSP/AP) as DLL files. For instance, Kerberos and NTLM are stored in the SSP Secur32.dll. Yes, in Secur32.dll since this SSP delegates security functions to the required SP. For instance, if a service requires Kerberos authentication, then Secur32.dll will call Kerberos.dll.

SSP/AP (or just AP)

AP is an Authentication Package. It’s a DLL that contains one or more SPs. The main difference from the standard SSP is that the SSP/AP can act as an Authentication Package (AP). In other words, it can verify the authenticity of the entered data when the user logs in to the system.

However, SSP/AP also performs all standard SSP functions (i.e. build context, encrypt data, etc.). To enable SSP/AP to function both as an Authentication Package and a regular SSP for client/server processes, it’s loaded to the lsass.exe process space at system startup.

If you only need to use client-server functions of a specific SSP/AP, it can be loaded into a client-server app. This can be done, for instance, using the dynamic LoadLibrary() function or the static pragma comment linking method (i.e. without loading it to the lsass.exe process). In this case, functions of the Authentication Package won’t be used.

Security Providers

Never confuse Security Providers with Security Package. These are different things.

Security Providers are implemented as DLLs and are responsible for so-called secondary authentication: after authentication on one PC, the user can be authenticated on another PC (e.g. a Linux server). This enables the user to gain access to resources of a UNIX server from a Windows PC without additional authentication. The scheme is called Single Sign-On.

Credential Providers

Credential Providers are COM objects that provide passwordless access to the system. They are also implemented in the form of dynamic DLLs. For instance, FaceCredentialProvider.dll is used for facial recognition; SmartcardCredentialProvider.dll, for smart cards.

A third-party Credential Provider can be used as well. All available Credential Providers are listed in the following registry key:

Each key in this registry path identifies a specific Credential Provider class based on its CLSID. The respective CLSID must be registered in HKCR\CLSID since it’s the COM class. You can use the CPlist.exe tool to review all available providers.

Password Filters

Using Password Filters, you can extend the standard password policy on specific hosts. When a password reset request is made, LSA calls all Notification Packages to check whether the new password complies with filters implemented within each Notification Package. Furthermore, each Notification Package is called twice:

1. To validate the new password. If one of the Notification Packages reports that the password isn’t suitable, the system will request the user to create a different password; and 
2. To notify the user that the password has been reset. This call will be made only when all Notification Packages have confirmed that the password is suitable and complies with their filters.

Password filter can be considered a specific instance of Notification Package.

How users log in to the system

Prior to intercepting a user password, you have to comprehend the user login process. Such aspects as Winlogon initialization, desktop creation, and GINA are beyond the scope of this article. All you have to know is that the Winlogon.exe process enables interactive login. So, the system starts, and the user places hands on the keyboard.

1. To start authentication, a SAS key combination is sent (by default, it’s Ctrl + Alt + Del). Winlogon receives this message and the login process begins;

2. Since modern systems have many passwordless login options (e.g. fingerprint or facial recognition), Winlogon addresses Credential Providers to receive information about the authenticating user;

3. Regardless of the response from the Credential Provider, Winlogon creates the LogonUI.exe process. It provides an interface for password entry and exits when this action is completed. LogonUI.exe can be restarted an infinite number of times if an error occurs. This is how the system protects itself against potential crash of Winlogon.exe;

4. Once the user has entered the login and password (or the Credential Provider has returned them), Winlogon creates a unique login SID for that user. This SID is assigned to the entire current desktop instance (i.e. keyboard, mouse, and screen). Then the lsass.exe process is called to authenticate the user;

5. This call can be divided into several stages. First, Winlogon.exe registers itself as an authentication process by calling the LsaRegisterLogonProcess() function. If this call is successful, the process receives a handle to LSA for subsequent interaction. This interaction will be performed via ALPC (Advanced Local Procedure Calls);

6. Next, Winlogon.exe receives a handle to the MSV1_0 authentication package (or to Kerberos in the case of AD; but this article describes only the situation with MSV1_0) by calling LsaLookupAuthenticationPackage():

   NTSTATUS LsaLookupAuthenticationPackage(

   [in] HANDLE LsaHandle,

   [in] PLSA_STRING PackageName,

   [out] PULONG AuthenticationPackage

   );

   This function doesn’t require anything special. LsaHandle is the handle received when LsaRegisterLogonProcess() is called; PackageName is the name of the Authentication Package (e.g. MSV1_0_PACKAGE_NAME); and AuthenticationPackage is the received identifier of the Authentication Package to be used by Winlogon;

7. Once Winlogon has received the Authentication Package identifier, Winlogon passes the information to it in a call to the LsaLogonUser() function. This information contains SID from step 4 and information about the authenticating user. SID transmission helps to prevent unauthorized access to the desktop (e.g. if you enter the password of one user and attempt to gain access to the desktop of another user);

8. Inside MSV1_0, the LsaApLogonUserEx() function is called, and the username and password are authenticated in it using the SAM database. If authentication is successful, a logon session is created: LsaCreateLogonSession() is called and a LogonID (LUID) generated by the Authentication Package is assigned to it. After that, MSV1_0 adds special information to the session by calling LsaAddCredential(). Usually, this is the username, domain name, and checksums of the password’s LM/NT-hash. This information can be required later if the user attempts to access remote nodes;

9. Then Winlogon waits for a response from LSA regarding the entered credentials;

10. After successful user authentication, a user shell is initialized. User shell is a set of processes launched on behalf of a specific account;

11. Too bad, you can’t just create a user shell (e.g. using the standard CreateProcess()). First, lsass.exe calls the NtCreateToken() function to create an access token. This token contains information about the user, and Winlogon.exe uses it to create a process on behalf of the authenticated user;

    You can ask: “Can I generate tokens myself?” Yes and no. Successful creation of a token requires the SeCreateTokenPrivilege privilege, which only lsass.exe has. If you have this privilege, then you can do whatever you want. Absolutely any token – any groups and privileges regardless of the global settings and configurations – can be created. For instance, once I gained rights to execute code on behalf of the Domain Admins group;

    

    And I specified: SID = 0.

    

12. In addition, Winlogon.exe collects information about the user environment. This information is very diverse. I will focus on the initial process also known as system shell: a process that spawns other processes in the system on behalf of the user and applies all the configured user profile settings. This information is stored in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. By default, the Userinit key specifies the userinit.exe process that restores user profile settings. And the system shell (usually explorer.exe) is specified in the shell key;

13. Userinit is called; the program starts; the environment is initialized; and then userinit.exe accesses the shell key and generates a system shell. After that, the Userinit process ends. Actually, this is the reason why you don’t see the parent process of explorer.exe: userinit.exe has already closed; and

14. The user logs into the system and gains access to their desktop.

LSA initialization

LSA plays a key role in user authentication. But how will it initialize your malicious SP, AP, and NP?

When the device starts, LSA automatically loads all registered SPs implemented as DLLs into its address space. The path to all registered DLLs is as follows:

If this key is empty, then the default value is used:

All these DLLs are specified without the full path. Microsoft recommends to place SPs to the folder %systemroot%/system32. Next, the SpLsaModeInitialize() function is called for each SP, and LSA receives a special table, SECPKG_FUNCTION_TABLE, containing pointers to functions that implement this security package. It looks as follows:

If SpLsaModeInitialize() has successfully returned the table, then LSA calls SpInitialize() and passes the LSA_SECPKG_FUNCTION_TABLE structure to it. This structure contains pointers to functions provided by LSA inside SP. For instance, the CreateToken() function can be used to create a token (not an access token, but a token generated during context building in client-server apps).

SpGetInfo()is called third so that LSA gets information about the package (e.g. its name, description, and version). This information will be displayed when the EnumerateSecurityPackages() function is called:

Then LSA loads all available Authentication Packages (APs). Their list is retrieved from the following registry key:

In each of these packages, the LsaApInitializePackage() function is called. Using this function, LSA will pass the LSA_DISPATCH_TABLE containing all LSA functions that the AP can call. The AP, in turn, must specify the last parameter of the function by providing its name. LSA uses this name to determine which AP the program wants to access by calling LsaLookupAuthenticationPackage().

Exploitation

Now that you have mastered the theory, you can start abusing the above-described elements of the Windows security system. Let’s begin with a classical technique that is present even in mimikatz. This is a standard SP injection performed to intercept credentials.

How to debug?

Many of the functions that you are going to use return either NTSTATUS or SECURITY_STATUS. In the first case, you can use the LsaNtStatusToWinError() function to understand what is broken:

After that, you examine the ULONG value and compare it with Win32 error codes.

In the case of SECURITY_STATUS, the situation is slightly more complicated. It’s unclear how to interpret its initial value. Imagine, for instance, that the AddSecurityPackage() function in your code fails every time with the error -2146893051. To understand what this error means, you have to convert it to Hex: 80090305. Next, you add 0x to its beginning and the L character to its end and then search for it in sspi.h.

Password interception through Security Package injection

Requirements

To perform its functions correctly, your SP must meet the following requirements:

1. Be implemented as a DLL;
2. Support the functions SpLsaModeInitialize(), SpGetInfo(), SpInitialize(), and SpAcceptCredentials(); and 
3. Have the same architecture as the target system: x64 for x64 and x86 for x86.

Adding to the system

The first option is the simplest one. Use the AddSecurityPackage() function: it enables you to load your SP into the system with just one click:

The example below shows how it works:

There is also another option, but it requires a system reboot. First, you place your SP to the C:\Windows\System32 folder and then change the respective value in the registry:

After the reboot, LSA will read this value and load your DLL.

Verification

To check whether your SP has been successfully loaded into the address space of the lsass.exe process, use the EnumerateSecurityPackages() function:

Password interception

In addition to the standard initialization functions (SpLsaModeInitialize(), SpGetInfo(), and SpInitialize()), you have to add the SpAcceptCredentials() function to your SP. LSA will call it after the user has entered the correct username and password. The code of your malicious SP becomes as follows:

In fact, the only newly-added element is logging of credentials received in the SpAcceptCredentials function. Let’s inject the SP into the system in any convenient way and try to track user logon.

Password interception through Password Filter injection

Requirements

The following requirements have to be met:

1. Your NP must be implemented as a DLL library;
2. Your NP must implement NP functions;
3. Your NP must have the same architecture as the target system: x64 for x64 and x86 for x86; and 
4. The functions must be declared as extern "C" __declspec(dllexport) and must have the __stdcall calling convention.

Adding to the system

LSA retrieves the list of all Notification Packages from the following registry key:

By default, it includes only scecli. To add your NP, you have to place it into the C:\Windows\System32 folder, and then add the following value to this registry key: name of your DLL without the .dll extension:

Password interception

In the simplest case, the code looks as follows:

The logging functions have been copied from the SP code. Let’s examine the new ones:

• InitializeChangeNotify() – LSA calls this function when an NP is successfully loaded into the address space of the LSA process;
• PasswordFilter() – LSA calls it when the user decides to reset the password. It contains the new password in the plain text for validation; and 
• PasswordChangeNotify() – LSA calls it when all NPs have reported that the new password complies with their filters.

Prohibiting users from changing their passwords

As you remember, the primary purpose of Password Filter is to ensure that the new password complies with all the criteria. You can prohibit any user of the system from changing their password if you modify the PasswordFilter() function as shown below:

As a result, the new password simply won’t pass validation, and LSA won’t allow the user to change it.

Password interception with Credential Manager

Theory

Windows Credential Manager enables you to save credentials (e.g. for some sites). The point is that you can implement your own credential manager to intercept passwords. This technique is based on a special component called MPR (Multiple Provider Router). It provides interaction between the operating system and various providers, including Credential Manager.

When MPR starts, it checks the registry for installed providers. The providers are listed in the registry in a certain order, and this is very important since they are loaded strictly in this order, one by one. All providers listed in the registry are loaded into MPR.

When a user logs in, Winlogon calls the respective function from the MPR, which, in turn, calls each Credential Manager notifying it that the user is logging in or changing the account password.

Unfortunately, this technique is considered obsolete nowadays. Therefore, I cannot guarantee its success on every Windows PC.

Adding to the system

MPR retrieves all available providers from the following registry key:

You can add your own provider in several ways. The easiest one is to use a script. Important: in this case, the name of your DLL must be spy.dll:

The same operations can be performed manually:

1. Copy your DLL (spy.dll) to the C:\Windows\System32 folder.

2. Add the line spy to the end of ProviderOrder in the following key:

   HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

3. Create a key:

   HKLM\SYSTEM\CurrentControlSet\Services\spy\NetworkProvider

   And specify the following data in it:

   "Class" = [REG_DWORD]2

   "ProviderPath" = [REG_EXPAND_SZ]"%SystemRoot%\System32\spy.dll"

   "Name" = [REG_SZ]"spy"

After that, you can check the settings as follows:

Password interception

To intercept the password, use the NPLogonNotify() function. MPR calls this function to notify Credential Manager of a successful logon. After receiving such a notification, Credential Manager can return a logon script (i.e. some script that has to be executed).

The function prototype is as follows:

Note the second parameter (lpAuthentInfoType). Depending on the input type, it takes different values:

Also, depending on the logon type, the third parameter (lpAuthentInfo) contains different structures. In the case of MSV1_0, it will contain the following values:

While in the case of Kerberos, the following ones:

Accordingly, if you intend to intercept MSV1_0, use this code:

After that, you log out of the system and log into it again. The password will be saved to a file.

Conclusions

As you can see, it’s not a big deal to intercept a user password in Windows. Authentication involves too many components, which poses a major security risk. But you can use Security Providers for other purposes as well. In the next article, you will write an AP that literally creates a second password for the user – a kind of pam_backdoor for Windows – and learn how to force MSV1_0 to send you credentials not only from interactive, but also from noninteractive authentications.