Encrypted windows logon что это

Dameware Mini Remote Control (MRC) has a variety of security and encryption features to help you comply with security guidelines.

Authentication

MRC supports different authentication methods, three of which are integrated within the security of the operating system. You can define security policies within the operating system that allow or prevent users from establishing an unauthorized MRC connection to a remote system. MRC always authenticates locally to remote systems and does not increase or decrease the connected user’s permissions in the operating system.

For example, if an MRC user has Administrator rights on the remote system when connecting to the system locally, the user will have Administrator rights when connecting remotely with MRC. MRC does not log users into the operating system of remote systems. Instead, it establishes a remote connection to the desktop of the remote system. If no user is currently logged in to the remote system, the MRC user must log in to the operating system as if they were connecting interactively.

MRC supports the following authentication methods:

• A proprietary challenge/response authentication method
• Windows NT Challenge/Response (OS-level)
• Encrypted Windows Logon (OS-level)
• Smart Card Logon (OS-level) authentication methods.

Restricting Connections

MRC includes features within the Dameware client agent service that can restrict MRC connections. To modify these settings, that user must have Administrator rights on the remote system.

The Dameware client agent service offers the following restriction options:

• Enable or disable specific authentication methods
• Specify and require an additional password, or shared secret, for MRC connections
• Limit MRC connections to users with administrative permissions
• Allow or deny MRC connections based on IPv4 filtering
• Restrict MRC connections to users within specific Windows security groups

Logging

The MRC program provides three logging features.

DWMRCS app event logs

Each time an MRC user connects to a remote system, MRC writes DWMRCS entries to the Application Event Log on the remote system for the following events:

• Attempts to connect
• Disconnects

These DWMRCS Application Event Log entries contain connection information, along with specific information about the system the MRC user connected from and the username used to establish the MRC connection. For security reasons, this functionality cannot be disabled within the MRC program.

Centralized logging

The Centralized Logging feature allows Administrators to send duplicate copies of the DWMRCS Application Event Log entries to a separate, independent centralized logging server. For this to work, the logging server and all remote systems must be running the Dameware client agent service.

Email notification

The Email Notification feature sends an email every time MRC establishes a connection to that system.

Encryption

MRC encrypts all credentials and other session negotiation information for its connections. MRC uses the Microsoft built-in Cryptographic Service Providers & CryptoAPIs to support strong encryption for authentication and session negotiation (key exchange). MRC uses multiple encryption algorithms (ciphers), and negotiates the strongest keys possible based on what the local and remote systems’ Crypto Subsystem agree on.

MRC provides additional encryption options for general data, images, and Simple File Transfers.

FIPS Mode

MRC also includes RSA’s BSAFE Crypto-C ME encryption modules, which are FIPS 140-2 level certified by the NIST. Federal Information Processing Standard 140-1 (FIPS 140-1) and its successor, FIPS 140-2, are US Government standards that provide a benchmark for implementing cryptographic software. MRC meets all Level 1 requirements for FIPS 140-2 compliance when operated in FIPS Mode. When you configure these options, MRC uses the BSAFE Crypto-C ME FIPS 140-2 validated cryptographic library exclusively, which only allows FIPS-approved algorithms.

When MRC is not running in FIPS Mode, MRC uses Microsoft’s cryptographic services providers (CSPs) and CryptoAPIs exclusively. The Encryption Algorithms used can be anywhere from a minimum of RC4 (primarily used for older operating systems, such as NT4) to a maximum of AES 256. The following example illustrates this range:

• AES 256 (Key length: 256 bits)

Forcing encryption

In addition to the encryption options in MRC, you can set the encryption restrictions on the Dameware client agent service. You can configure remote systems to allow only FIPS Mode connections, or require specific encryption options for all MRC connections.

Permission Required

The Dameware client agent service provides several Permission Required settings in the Agent Service Settings dialog box. When these settings are enabled, users who are logged into a target MRC system locally must allow incoming MRC connections. The client agent service can also prohibit non-administrative users from establishing a connection if no local user is logged on.

For MRC users connecting with non-administrator credentials, the following settings on the Access tab are enabled by default:

• Permission Required for these Account Types
• Disconnect if at Logon Desktop
• View only for these account types

The Permission Required setting on the Additional Settings tab applies to MRC users connecting with or without administrator credentials. If this setting is enabled and an MRC user attempts to connect to the remote system while another user is logged on, the logged on user must allow the MRC connection for it to be successful.

Passwordless products promise greater security and convenience by allowing users to log in to Windows systems with only their smartphone. But what is going on behind the scenes and how could a domain’s security stance be worsened by such a solution? In this post I will explain how these products are implemented and detail the vulnerabilities and weaknesses discovered in three tested products.

Windows Hello

This blogpost is not about Windows Hello. It is about a specific class of products, which I will call passwordless products, that allow users to login to any domain joined PC using only their smartphone. Think of it as the modern iteration of the smartcard login, but instead of a smartcard the user uses his smartphone. Additionally all the products in this blogpost are third party products, as far as I know there is no such product by Microsoft itself.

General Architecture/Implementation

The general architecture involves three parties: the smartphone on which the product specific app is installed, the computer on which the product is installed and an on-prem or cloud server, which facilitates the communication between the smartphone and the PC.

When a user authenticates on his computer, the user also authenticates to the domain controller, to access network resources in the Active Directory environment. When a user logs in with one of these passwordless products this is also the case, and the described products do not modify how authentication is done in the Active Directory environment.

The implementation on the computer is done with a custom Windows credential provider and a service. Windows credential providers are DLLs loaded by the login process, which have the purpose to gather user credentials and pass them to the login process. (Microsoft Documentation) The paswordless products install their own credential provider to hook themselves into any started login process. The service handles communication to the server and communicates via IPC to the credential provider.

The most important takeaway of the client implementation is that the credential provider needs to pass valid credentials to the logon process, which are then validated later on in the login process. The credential provider itself does not have the power to validate credentials. Since the user is not entering his credentials, valid credentials need to be cached somewhere and on successful authorization by the user (on the app) are then passed to the credential provider.

This is the main functionality these products implement, which is caching user credentials and passing them to the credential provider, once the user has authorized the login on their smartphone.

In the rest of this blog, three products are detailed and a vulnerability for each product is presented. The vulnerabilities allow non-privileged users to abuse these cached credentials to log in as another user.

Thales SafeNet CVE-2021-42138

User Experience

The user installs the SafeNet mobile app and enrolls the app for his user by scanning a QR code provided by the company.

When a user logs into a computer, the user enters the username, gets a login notification on the app and after accepting the notification, if it’s the first time the user logs into that computer, the user has to enter the password.

On subsequent logins to the same computer the user will only need to enter the username and accept the login notification on the smartphone to log in.

How it works

SafeNet caches the login credentials on the computer. When a user logs in the first time to a computer, the SafeNet credential provider encrypts the user’s password and writes it to a file. The next time the user logs in, the credential provider reads that file and decrypts the user’s password.

Vulnerability

Since the file is readable for all users I investigated how the passwords were encrypted, as a vulnerability there, could allow any user to decrypt the passwords of other users.

Using dynamic analysis it can be seen that DPAPI is used to decrypt the credentials.

Checking how the passwords are encrypted, shows that the DPAPI encryption is done with the LocalMachine flag:

A quick glimpse at the documentation shows that with this flag, any user on the computer can decrypt the data.

Additionally, the decryption uses the entropy parameter. In DPAPI the entropy acts as a sort of password, meaning a blob can only be decrypted if the same entropy value as used in the encryption, is used for decryption. However, it turns out the value is static and hardcoded into the binary.

So here is what we have: a file with encrypted user passwords readable by all users, DPAPI encryption with the LocalMachine scope and static entropy. These together result in a vulnerability (published as CVE-2021-42138), which allows any user on the machine to decrypt the passwords stored in the file, including the password of other users.

The following tiny PowerShell script can decrypt the passwords stored in the file on any PC with the vulnerable SafeNet version installed.

Thales deployed mitigations against this vulnerability. However in a follow-up test, it turned out that it was still vulnerable. The only thing that changed was another 2 layers of encryption. A new DLL manages the new encryption of the user’s passwords. To exploit the new vulnerability, it is possible to import the DLL and call one of the exported functions, appropriately named getADCachedCreds.

So why not just change the access permissions on the file with the encrypted passwords, surely this would be the most intuitive way of fixing this vulnerabilty? The reason why the file needs to be readable, and the password being decryptable by normal users is the fact that Thales SafeNet supports passwordless login for the “Run as different user” Windows functionality. The login process for “run as different user” runs as the current user. As opposed to when normally logging in on the lock screen or clicking run as Admin, where the login process runs as the SYSTEM user.

Since the Credential Provider DLL is loaded into the logon window process the encryption/decryption of the passwords is done with the permissions of that process. Passwordless login for “run as different user” would not work if the file containing the encrypted passwords was only readable by the SYSTEM user, since on this login, the DLL will be running with the permissions of a normal user.

In the newest version of SafeNet, a registry key is present, which if set to 1 ensures that DPAPI encryption will be done without the LocalMachine flag. As far as I know however, this registry key is not set to 1 by default…

VeridiumAD CVE-2021-42791

User Experience

The user installs the VeridiumAD mobile app and enrolls the app by scanning a QR code provided by the company.

When the user logs into a computer, the user enters the username, gets a login notification on the app and is logged in. Unlike SafeNet and HYPR, the user never has to enter his password even the first time logging into a computer.

How it works

VeridiumAD uses an on-prem server, which interacts with the AD CS service to obtain a user login certificate. This login certificate is sent to the computer after the user has authorized a login. The login process is shown in the image below. After the user clicks log in with VeridumAD and enters the username, the service makes an HTTP request to the server. After the server receives the HTTP request, the push notification is triggered for that user.

The service also starts polling the server, waiting for the user to either approve or decline. Once the user approves, the login certificate of the user is returned on one of the polling requests. This login certificate is passed to the VeridiumAD service, which in turn sends it to the VeridiumAD credential provider and then to the login process.

Vulnerability

The HTTP request, which triggers the login notification, can be made by anyone in the internal network with access to the VeridiumAD server API. When sending the request, an arbitrary user-SID and a custom notification text can be specified. This will trigger the login notification for that arbitrary user. Additionally, the server can also be polled and if the victim user accepts the malicious push request, the polling user obtains this victim’s login certificate.

There is a small complication however, in that a SSL client certificate is required to actually communicate with the server’s API.

When the VeridiumAD service is restarted, the service sends a certificate signing request to the server and in the response receives the SSL client certificate.

The endpoint is protected with NTLM authentication. However, this CSR HTTP request can be made by any domain user.

This vulnerability then allows for any user to potentially obtain the login certificate of all other user’s if they fall for the malicious push notification. The requirements for mounting the attack are access to the VeridiumAD API and credentials of any valid domain user.

VeridiumId mitigated the vulnerability by making it such that only computer accounts in a specific group may make the CSR HTTP request.

HYPR (CVE to be assigned)

User Experience

The user installs the HYPR app. To enroll the HYPR app for passwordless log in to a computer, the user logs in normally (with password) to a computer, then opens the HYPR desktop app and scans a QR code displayed by the desktop application. Afterwards the user gets a button in his HYPR app to log in as the current user for that computer. A user may have multiple user/computer login buttons in his app.

To log in the user simply clicks the desired user/computer login button and will be logged in and therefore the user does not even need to touch the keyboard.

How it works

HYPR caches the user’s login certificate on the user’s phone. The HYPR service on the computer continuously polls the cloud server and if the user authorizes a login in the app, the app sends the encrypted login certificate to the cloud server, which then forwards the certificate to the client as part of a polling response,. On the client the certificate is decrypted by the HYPR service and passed to the login process.

The login certificate is encrypted with a key derived with Diffie-Hellman between the computer and the smartphone. The certificate can only be decrypted as SYSTEM on the computer or with full control of the smartphone.

Vulnerability

It is possible to obtain encrypted login certificates of other users. This stolen encrypted login certificate can be leveraged to login as another user. The attack scenario is that an attacker has code execution as a low privileged user and is looking to login as another user (referred to as the target user), who uses HYPR to log in to that computer.

Obtaining Encrypted Login Certificates of other users

HYPR stores information of the users enrolled for passwordless login on the computer in the registry. Each user has a key, containing his devices (smartphones) and values needed to communicate to the cloud server. The keys are readable for any user on the computer.

The values are stored DPAPI encrypted without entropy and the LocalMachine flag set. Meaning these values are readable by any user on the machine and a local attacker can read out the values of other users.

With these values it is possible to poll the cloud server. If the target user clicks the login button in their HYPR app for that computer, the attacker obtains the encrypted login certificate of the target user.

Exploit

To exploit the vulnerability. the attacker starts a login process on his own HYPR app, which the attacker enrolled for the low-privileged user on the computer, modifies the parameters sent to the HYPR cloud server in step 2 to start a login process for the target user on the computer and then sends the stolen encrypted login certificate of the target user to the server in step 3.

There is however a complication. When initiating a login, the HYPR cloud server sets the encCounter value. This encCounter value is sent to the app after the login flow is started and also to the HYPR service in the polling response containing the encrypted login certificate.

The app takes the encCounter value prepends it to the login certificate, encrypts that data and sends it to the server. The HYPR service takes the encCounter value and compares it to the value in the obtained plaintext. If the encCounter in the plaintext does not match the encCounter received in the HTTP response, the HYPR service aborts the login.

This complicates the attack, since after stealing the encrypted login certificate, the attacker now needs to make sure that the static encCounter of the stolen encrypted login certificate matches the encCounter set by the server. However, the attacker cannot influence the value set by the server.

Fortunately for the attacker, the encCounter value is predictable. It starts at 1 and is incremented by one for each login. Additionally the encCounter is reset back to 1 when a user is deregistered from the computer. When a user deregisters from a computer and reregisters, the shared encryption key between smartphone and computer however stays the same, since the DH private/public keys are static for a smartphone/computer.

With the values in the registry it is possible to deregister the target user from the computer.

So to prepare the actual attack, the attacker first obtains an encrypted login certificate of the target user, then deregisters the target user and waits for the target user to re-register. Afterwards the attacker starts a login process on the computer (in this case a UAC login prompt) and starts a login process on the app. On the first HTTP request sent by the app, the attacker replaces the username and device id (identifying the smartphone) with the target user’s username/device id.

Afterwards a biometric/pin prompt needs to be done by the attacker on the app and then a session id is sent back. This session id is used to obtain the encCounter value and prepare the server to receive the encrypted login certificate.

If the EncCounter matches the one of the encrypted login certificate of the target user, the attacker continues to the next step, otherwise the previous steps are repeated.

The attacker nows sends the stolen encrypted login certificate to the server:

This certificate is now sent as the polling response to the HYPR service by the server. The service decrypts the certificate and passes it to the login process. Now the attacker is logged in as the target user.

Another vulnerability which allows a user to log in as another user. There are however a number of countermeasures which can be taken to foil this attack. Making the encCounter a random value and making sure the value does not repeat, will making reusing encrypted login certificates impossible. Ensuring that only the correct user has access to the values stored in the registry would prevent being able to deregister or poll the server on behalf of another user. And lastly it should not be possible to start login flows on the app for other users. The first and second issue are fixed in newer HYPR releases.

Conclusion

It should be clear that these passwordless solutions in no way eliminate passwords from the network. Instead credentials are cached somewhere and a complex infrastructure is set up to pass the credentials to the login process upon user authorization. Vulnerabilities will expose these cached login credentials to be abused by attackers with a foothold in the network or on a computer.

For all tested products there is a new way to obtain login credentials of other users as a local Administrator. This is of course anyway possible on Windows. However with such a product installed, obtaining the credentials cached by the passwordless product does not require dumping memory or cracking a hash. Instead simply mimicking the credential provider/service will suffice. This will make such an attack hard to detect/prevent.

I hope this blogpost was able to shed some light on how these products work. I want to finish by saying that I have only tested the three products above, there are other products whose implementation may hugely differ. All three companies were very cooperative and were quick to fix the vulnerabilities, that were responsibly disclosed to them. The vulnerabilities, as presented above should not be present anymore in the newer versions of these products.

Last updated on February 24th, 2023

Microsoft is slowly rolling out Windows 11. Some Windows 10 devices have already started prompting their users with information about a possible free update to Windows 11.

As Microsoft stated in its blog post, Windows 11 is being released in phases. As a result, it may take as long as until mid-2022 for Windows 11 to be available as an auto-update for all Windows 10 devices.

If you cannot wait and still have not received any information on a possible update to Windows 11, you can manually download and install Windows 11 from Microsoft’s website.

What’s New in Windows 11

Windows 11 boasts a Mac-like interface, integrates with Android apps, and provides a great gaming experience.

From Secure Boot through Device Encryption to Virtualization-based Security (VBS), Windows 11 comes packed with in-built features.

But what about logon security?

Are Your Logons Secure?

The release of Windows 11 makes a perfect opportunity to review the security policies of your company. Identity and Access Management (IAM) is the core of any company’s security posture. Therefore, you should:

• Review the security of your network infrastructure
• Review how your users authenticate to Windows Logon & RDP

A common approach to Windows accounts includes creating a set of Active Directory domains and filling them with users. These users can then log in to their local Windows devices using their Active Directory user name and password.

But some companies do not use Active Directory. Instead, they prefer a simple network infrastructure they create using in-built Workgroup Accounts.

Then, there’s the question of users. Some users log in to Windows using their local machines. But there are also users, including remote workers, who log in via RDP.

Your company has to deal with at least some of these challenges. If you already set up a way to authenticate your users with passwords, you might think the job’s done. Not so fast. Did you remember about security? 

You must now ask yourself a question: Am I secure enough to give all my users the protection they need? Better yet, will my users still be secure even if their passwords get cracked?

Basic Windows authentication is password-based. Unfortunately, passwords are an absolute nightmare for security. While Microsoft allows you to go passwordless on your Microsoft account, not all users have a Microsoft account. In addition to that, Microsoft Azure Active Directory is costly. There is a better option.

Why Two-Factor Authentication (2FA) Is The Way to Go

Let’s face it: passwords are not very secure. Of course, you can replace the password with something else. But you can also add something else besides the password. Two-Factor Authentication (2FA) does exactly that.

With 2FA, you will be using passwords just like before. However, a correct password will not be enough for you to log in. 2FA adds another step to your login process. This second step may require you to provide a short passcode that has been sent to you via SMS. You can also receive a notification request on your mobile phone. These are only two of many available authentication methods. A good 2FA solution lets you choose from many options.

But how can a second authentication step (or factor) increase your login security?

When you log in using your password, you are only using one communication channel and one piece of evidence that you is you. As a result, a malicious actor who guesses, cracks, or steals your password can successfully gain access to your account. Apart from hacking your password, a malicious actor can, for example, eavesdrop on the channel of communication between you and the security system and tamper with the information sent in between. Possible hacking scenarios abound.

Deploying 2FA and setting up the Mobile Push authentication request transforms this one-channel authentication process into a two-channel authentication process. Now the security system requires two separate pieces of evidence. The proof that you are you is not only your password but also your phone. If you start a login process and then receive an authentication request on your phone, you can be sure that it’s you. A hacker does not have your phone so they cannot gain access to your account.

Naturally, a malicious actor can also steal your phone. But stealing a phone is much harder than stealing a password. And since now there are two channels of communication, the malicious actor has to eavesdrop on both. At the same time. And try to steal encrypted information. In a matter of seconds. This is much harder than brute-forcing a simple password of an untrained employee. As a matter of fact, this is so much harder that Microsoft famously stated that MFA/2FA prevents 99.9% attacks on accounts.

Rublon Secures Your Windows 11 Logons

The Rublon for Windows Logon and RDP connector introduces strong 2FA to Windows Server and Windows Home & Pro systems. From now on, Rublon for Windows also supports Windows 11.

Rublon for Windows Logon and RDP supports both local and RDP logons while pulling users from Workgroup Accounts or Active Directory accounts.

Rublon empowers you with secure second-step authentication methods, including Mobile Push, Mobile Passcode (TOTP), and QR Code.

It does not matter how you configured your network infrastructure. Rublon 2FA protects all your users with cutting-edge Two-Factor Authentication.

And just for $2 per user.

Start a Free Trial of Rublon Now

КриптоПро Winlogon — это программное обеспечение для проверки серверов, контролирующее компьютерную сеть и пользователей в операционной системе Windows. Осуществляет аутентификацию статуса пользователя с помощью сертификатов открытых ключей и электронных цифровых подписей (ЭЦП). Аутентификация осуществляется при входе пользователей на домен с использованием средства криптографической защиты информации (СКЗИ) «КриптоПро CSP» версии 3.0 и выше.

Открытые ключи используются для проверки пользователя, а ЭЦП для авторизации домена Windows в соответствии с RFC 4490. Сертификаты пользователей и контроллеров домена выпускаются и управляются с помощью сертифицированного удостоверяющего центра или находятся под управлением домена операционной системы.

Его назначение

Программное обеспечение усиливает сетевой протокол аутентификации «Kerberos» с помощью инструментов криптографической защиты информации, расширяя штатную функциональность операционной системы.

Программное обеспечение КриптоПро Winlogon формирует ключи шифрования и ключи ЭЦП, шифрует данные, защищает их от навязывания ложных данных, обеспечивает целостность, подлинность и конфиденциальность информации.

Также КриптоПро Winlogon использует расширенный протокол аутентификации EAP-TLS (Extensible Authentication Protocol). Данный протокол использует двустороннюю криптографическую аутентификацию между удалённым пользователем и Radius сервером (Remote Authentication Dial-In User Service).

Характеристики

Программное обеспечение производит аутентификацию на любом сервере, который предназначен для взаимодействия с доменом Windows или со сферой Kerberos V5. При использовании КриптоПро CSP 3.0 необходимо скачать и установить дистрибутив по одной из приведённых ниже ссылок:

• Дистрибутив КриптоПро Winlogon (rus)
• Дистрибутив КриптоПро Winlogon (eng)
• Документация на КриптоПро Winlogon

Отдельная установка КриптоПро Winlogon не требуется, если используется КриптоПро CSP 3.6 и выше.

Подробные характеристики о совместимости с вашим удостоверяющим центром, операционной системой, доменом и дополнительными настройками вы можете узнать у нашей круглосуточной поддержки.

Срок пробной версии программы — 30 дней с момента установки. После необходимо получить лицензию у официального дилера. «Астрал-М» распространяет, внедряет и сопровождает программы КриптоПро с круглосуточной поддержкой пользователей 24/7. Является официальным дилером продукции торговой марки КриптоПро. Приобрести продукцию и актуальную лицензию КриптоПро Winlogon легко, достаточно заполнить форму обратной связи на сайте, вписав своё имя, телефон и адрес электронной почты.

Load More