Windows authentication procedure. An old Windows NTLM authentication bug allows you to deanonymize a user Storing passwords in the account database

02/11/2011 Jean de Klerk

Any Windows administrator, of course, has had to deal with the two main authentication protocols in the Windows environment more than once: Kerberos and NTLM. This article focuses on how Kerberos and NTLM are supported on Windows 7 and Windows Server 2008 R2 systems. But first, I would like to highlight the key differences between these protocols.

Microsoft developers first implemented the Kerberos protocol in Windows 2000. The NTLM protocol came into use much earlier, in the days of Windows NT. Kerberos is an authentication protocol based on the trusted third party (TTP) concept, while NTLM is based on a challenge/response mechanism. The differences between the two protocols are described in more detail in the table.

When communicating during NTLM authentication, a server resource (for example, a file server) generates a request that is sent to the client. The client generates an NTLM response that includes the user's password hash, and the server verifies that the response is correct. If the client is using a local account, the server validates the user's response against the user's password hash, which is stored in the local Security Account Manager (SAM) database. If the client is using a domain account, the server passes the response to the domain controller for verification, because only domain controllers store copies of user password hashes in their Active Directory (AD) databases.

In Windows Kerberos, the trusted third party is a Windows 2000 or later domain controller that hosts the Kerberos Key Distribution Center (KDC) service. The KDC facilitates authentication between a Kerberos-enabled client and server. The KDC service is automatically installed as a component of the AD system and consists of two subsystems: the Authentication Service (AS) and the Ticket-Granting Service (TGS).

When a user logs on to a Windows domain using the Kerberos protocol, the Windows client first authenticates the user to the domain controller using the user's password. At the same time, the client requests a Ticket Grant Ticket (TGT) to the authentication service. The TGT can be thought of as a temporary password (by default, its lifetime is 8 hours) that will replace the user's password in subsequent authentication requests. When a user needs to access a server resource, the client will present a TGT to issue a TGT to authenticate against the server resource. Be aware that, unlike NTLM, the Kerberos protocol is not used for local authentication with the Windows Security Accounts Manager; its scope is limited to domain authentication on a domain controller.

Kerberos is the standard authentication protocol in Windows 2000 and newer versions of Microsoft. On these operating systems, the authentication protocol is defined using a negotiation mechanism. If the default Kerberos protocol is not suitable or supported by one of the client or server components involved in authentication, Windows falls back to using NTLM.

Why Kerberos?

Kerberos is more efficient than NTLM for several reasons. When using the Kerberos protocol, the user's password hash is exposed much less frequently than when using NTLM. The password hash is only exposed when the user requests the TGT - in fact, once every eight hours. On the other hand, with NTLM, the password hash is exposed whenever the client uses NTLM to authenticate to the server. This is an important advantage of the Kerberos protocol over the NTLM protocol; the fact is that there are special tools that check network traffic for the presence of password hashes. These tools capture the discovered hashes and use them to recover user passwords using a brute-force method.

Another benefit of Kerberos is that it uses timestamps to protect against replay attacks. That's why it's so important to have a time synchronization service that works flawlessly in a Kerberos-centric Windows environment. In Windows 2000 and newer versions of the system, time services work without prior configuration. If computer clocks on different computers are out of sync, this can result in additional traffic in the Kerberos authentication process or, in the worst case, this situation can cause an error in the authentication process.

In addition to the above, the Kerberos protocol implements advanced authentication features such as mutual authentication and authentication delegation. Mutual authentication means that the user and service authenticate each other, while NTLM is limited to user authentication. Without this feature, there may be situations where users provide their credentials to a bogus server.

A service can access remote resources on behalf of a user using an authentication delegation mechanism. In other words, the user can grant the intermediary system the right to authenticate itself (the user) on the application server on its own behalf. As a result, the application server is able to make authorization decisions not based on the identity of the proxy system, but based on the identity of the user. The authentication delegation feature is very useful in multi-tier applications such as accessing databases using a Web-based front end.

Finally, it must be said that although Microsoft has done a lot of work on modernizing the NTLM protocol, namely, creating a version of NTLMv2 that is supported in the environment of NT4 SP4 and newer versions, Microsoft Kerberos implements a larger number of modern encryption algorithms. I will talk about this in more detail in the section on Kerberos protocol encryption tools.

NTLM protocol limitations

The benefits of authentication using the Kerberos protocol are beyond doubt. But even in an AD Server 2008 environment, Windows often uses NTLM, such as when you connect to a pre-Windows 2000 Windows system or when you connect to a shared resource using the net use command and an IP address (rather than a NetBIOS name). In addition, applications that do not have service principal names (SPNs) properly configured will still use the NTLM protocol.

To find out which protocol - NTLM or Kerberos - you are currently using, you can visualize NTLM traffic using the netmon utility or other network tracer; An alternative is to check the contents of the Kerberos ticket cache using the klist tool (which is included with Windows 7 and Server 2008). In Windows 7 and Server 2008, Microsoft has implemented new Group Policies that can be used to monitor and block the use of the NTLM protocol by your users and applications. There are three such policies in total: one for incoming NTLM traffic (to track and block at the server level), another for outgoing NTLM traffic (to track and block at the client level), and the third for domain traffic (to track and block at the domain controller level). They are located in the Security Options Group Policy Object (CPO) container, which can be accessed by successively selecting Computer Configuration, Windows Settings, Security Settings, Local Policies (see Figure 1). They all start with Network security: Restrict NTLM:.

Each policy setting has audit and block options. When you enable the NTLM auditing feature, the program creates event log entries with the original NTLM data and the numbers 8001, 8002, 8003, and 8004. The log entries are stored in the Operational container with access path Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. I recommend that you start with an NTLM audit in a test environment and ensure that all your applications are properly represented there. If you start to arbitrarily block the use of the protocol, most likely, some applications will not function. To prevent loss of events, you should install an audit event collection solution before you start testing NTLM auditing tools; You can use the built-in Windows Event Collector, Event Subscriptions, or a third party solution. Also, I recommend that you start monitoring NTLM on your servers first. You can connect clients for detailed analysis after it becomes clear that the server uses the NTLM protocol. Once you understand which applications use NTLM, you can develop an NTLM blocking strategy. This strategy may include an exclusion policy for legacy applications that cannot be rewritten or reconfigured and will always require NTLM to be used.

Unfortunately, the mentioned NTLM settings cannot be applied on older Windows systems. However, these systems allow versioning of the NTLM protocol. You can, for example, disable the LM snippet of the NTLM authentication protocol (since that snippet is inherently weak) or enforce NTLMv2. To do this, use the Network Security: LAN Manager Authentication Level GPO setting, which is located in the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options GPO container (see Figure 2).

Kerberos encryption tools

The cryptographic protocols used by authentication protocols play an important role in securing the latter. As I already noted, in this area Kerberos performance is higher than that of the NTLM protocol. The RC4 encryption algorithm was first implemented in the Windows Kerberos protocol in Windows 2000 and is still supported on Server 2008 systems as well as Windows 7 (more precisely, its version RC4_HMAC_MD5 is supported). In Server 2008, Windows Vista, and later, Microsoft has added support for Advanced Encryption Standard, AES encryption, while Windows 7 and Server 2008 R2 support Kerberos AES encryption types (AES128_HMAC_SHA1 and AES256_HMAC_SHA1) out of the box. AES is a newer and more powerful encryption algorithm than DES. Kerberos logic on domain controllers will migrate to the AES encryption standard when you upgrade your AD domain to the Windows 2008 Domain Functional Level (DFL).

On Windows 7 and Server 2008 R2 systems, DES encryption types for the Kerberos authentication protocol are disabled by default. This can cause compatibility issues if one of the legacy applications is hard-coded to DES-only encryption, or if the Windows account running a particular service (the service account) is configured to use DES-only encryption. These services or applications will fail if you cannot reconfigure the corresponding service or application to support a different type of encryption (RC4 or AES), or restore support for the DES standard.

To find out if you have applications or services coded for DES-only encryption, you can run a network tracer at the start of the corresponding application or service and check the contents of the Etype fields in the Kerberos authentication headers. To determine whether a user or AD computer account or computer account is configured to use only DES encryption types, check whether Use Kerberos DES encryption types for this account is selected on the Account tab of the object's properties. These properties can be accessed from the AD Users and Computers MMC snap-in.

If you complete the checks mentioned above and you find that you are experiencing this issue, you can enable DES encryption for Kerberos authentication on computers running Windows 7 or Server 2008 R2 using the Network security configuration GPO: configure encryption types that are compatible with the Kerberos standard; these settings are located in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO container.

So, of the two Windows authentication protocols, Kerberos is the preferred one. Administrators should always insist that users and applications use Kerberos and not NTLM. The new restrictions on the use of NTLM introduced in Windows 7 and Server 2008 R2 provide us with a great opportunity to achieve this goal.

Jean de Klerk [email protected]) is an employee of HP's Security Office. Specializes in identity and security management in Microsoft products

Authentication on Windows Server 2008 R2 and Windows 7 systems

I recently ran into this problem: Firefox, Chrome, Opera don't want to pass NTLM authorization. The only one who passed was IE. I forgot to say that this problem is observed on Windows7. Methods for troubleshooting these problems will be described below.

opera: not officially supported NTLM-authorization, although in the settings you can find an item that allows you to enable or disable this option. Therefore, in your proxy server settings, you need to add basic authorization. To disable NTLM authorization(and actually make this browser work through a proxy) do the following:

1) type in browser about:config
2) go to the NetWork section and uncheck the Enable NTLM option
3) restart the browser.

True, there is one nuance (an inconvenience, so to speak): at the first start, you will have to enter the login password (in full, that is, with the domain) and check the box "Save". Now, with each subsequent opening of the browser, the authorization plate will appear, and you just need to press "OK". It's inconvenient, but what can you do.

Note: sometimes on some operating systems, on the contrary, it was necessary to turn on NTLM authorization. Perhaps it also depended on the versions of the browser and OS.

Firefox, Chrome: they support, although you need a little shamanism. I will describe several options that I got on the Internet, you may have to try everything until you find the one that suits you.

1) you will need to add in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa a parameter called LmCompatibilityLevel type DWORD and give it a value 1 . After that, it will be necessary to restart the computer (this option suited me)

2) To Firefox could pass ntlm authorization, it seems to be enough to open about: config in the address bar and change the parameters to the following:

network.negotiate-auth.delegation-uris = http://,https://
network.negotiate-auth.trusted-uris = http://,https://

Then restart the browser.

3) Open the policy editor ( gpedit.msc) Computer Configuration -> Windows Configuration -> Security Settings -> Local Policies -> Security Settings -> Network Security: LAN Manager Authentication Level and set the parameter Send LM and NTLM - use NTLMv2 session security when negotiating.

Then we close the policy and reboot.

If you have an English version, then like this: machine policy-> computer config->windows setting->local policies->security option->Network security: LAN Manager authentication level and select LM & NTLM - Use NTLMv2 session if negotited.

4) Another option is to set up squid_ldap:

auth_param basic program /usr/lib/squid3/squid_ldap_auth -b "cn=users,dc=office,dc=ru" -f "sAMAccountName=%s" -h 192.168.0.74 -D "cn=administrator,cn=users, dc=office,dc=en" -w "secpass"
auth_param basic children 5
auth_param basic realm My inet Proxy
auth_param basic credentialsttl 60 minutes

external_acl_type nt_groups %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "cn=users,dc=office,dc=ru" -f "(&(cn=%v)(memberOf=cn=%a,cn= users,dc=office,dc=ru))" -D "cn=administrator,cn=users,dc=office,dc=ru" -w "secpass" -h 192.168.0.74

acl all src 0.0.0.0/0.0.0.0
acl group_inet external nt_groups inet

http_access allow group_inet
http_reply_access allow all
icp_access allow all
http_access deny all

Try it anyway 🙂

Researchers have been talking at conferences for years about how single sign-on technologies are insecure. Microsoft has been using this system of single authentication for everything at once for a long time, and information security specialists said back in 1997 that this was not a good idea. Once again, the single sign-on vulnerability in general and in the case of working with SMB resources in particular was demonstrated by the Russian researcher ValdikSS. He described a method that allows you to compromise the victim's Microsoft Account, deanonymize Microsoft users and find out VPN data.

In fact, to successfully implement an attack, it is enough for an attacker to disguise a link to their own SMB resource (network resources: files and folders, printers, etc.), for example, under a picture and force the victim to open it. The attack works on all modern operating systems, including Windows 10 with the latest updates. Moreover, these problems with NTLM authentication were discussed not only in 1997, they are mentioned regularly. So, this issue was raised (PDF) last year at the BlackHat conference. Unfortunately, nothing changes from frequent references.

On Habrahabr, the user ValdikSS talked about how this “bug from the 90s” can be exploited today. The researcher writes:

"As soon as you try to open a link to an SMB resource in a standard browser (Internet Explorer, Edge) or any application that works through standard Windows API calls or uses Internet Explorer as the engine for displaying HTML (Outlook, Windows Explorer), the SMB resource immediately receives your account information even before you see the login and password dialog. It is enough for an attacker, for example, to add a link to an image from an SMB server to a website page, or send you an email that will just be enough to open, and - boom! - Your account information is in the hands of an attacker.

While the leakage of the account name and password hash of a home computer is not considered a disaster, when it comes to a corporate domain, a completely different conversation begins.

“From the domain name, it is usually easy to understand which organization the account belongs to, and then, if the password is successfully guessed, you can try to authenticate on corporate resources accessible from the Internet (mail, VPN).

But the password is not always necessary to guess. If you know in advance some resource where you can log in using NTLM authentication, you can in real time, as soon as the client connects to your SMB server, proxy requests from the client to the remote server and from the server to the client, and successfully Authenticate on it!” ValdikSS explains.

The situation is also aggravated by the fact that in modern Microsoft operating systems they are actively promoting the use of a single Microsoft Account, literally forcing the user to create it. For Microsoft Account users, such attacks can be doubly dangerous, not only for organizations, but also for individuals. The fact is that in the event of an attack on an attacker's SMB server, data will be transmitted that, in fact, will compromise the victim's Microsoft Account, and many services are attached to it (Skype, Xbox, OneDrive, Office 360, MSN, Bing, Azure, etc. Further).

The researcher also writes that in some cases, the attack can be used to extract data about the login and password hash of the victim's VPN connection.

At the same time, ValdikSS described a number of ways to exploit problems with NTLM authentication. In addition to the very obvious things, the researcher suggested using a gap to deanonymize users:

“Exploitation for the purpose of deanonymization is more interesting. The account will be sent from the pages of the site if the victim uses Internet Explorer, or by clicking inside the letter, in the case of Outlook. Almost all web interfaces of mail services filter pictures with the file:// scheme when outputting messages (the file:// scheme is analogous to the \\ scheme), but not Yandex, which does not consider this a vulnerability (which, in general, is correct ). Deanonymization using mail is more dangerous, because gives a link not only to IP-addresses with a Windows account, but also with mail.

The Chrome file:// scheme also works, but only from the address bar. Downloading anything with an SMB image or clicking on a link will not work. Since Chrome is much more popular than Internet Explorer, social engineering will have to be applied.

You can steal accounts for your own good. Some VPN providers use the same usernames and passwords for both account login and VPN authentication. The account belonging to a particular service can be determined by the IP address of the user's incoming connection. And if you got a Microsoft Account, and you found the password from the hash, then congratulations - you have access to files in the OneDrive cloud, Outlook mail, Skype account if it is linked to a Microsoft account, and a lot more.

In conclusion, ValdikSS writes that you can protect yourself from such attacks, for example, by restricting access to TCP port 445 for all address ranges except:

• 192.168.0.0/16
• 169.254.0.0/16
• 172.16.0.0/12
• 10.0.0.0/8
• fd00::/8
• fe80::/10

Also in the comments to the article, users suggested the following method:

Windows Registry Editor Version 5.00

"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002

In addition, the researcher has created a special page that allows you to check your system for vulnerability to this type of attack.

I have successfully configured ntlm authentication. Unfortunately, config allows you to get semi-primary authorization. For example, when I use turtle svn1.8.4 (privileged lib), chrome, or IE web browsers, they successfully exit NTLM without asking for anything. In the log file, I see authenticated users. Unfortunately, when I use for example unconfigured FireFox or Maxthon, this browser asks me for credentials. I don't need it because the same situation occurs when I try to access from a computer without a computer.

I am using windows server as domain controller, windows7/8 as system client, linux/debian as webserver. I configured kerberos from linux do windows AD, winbind for local NTLM authentication and apache 2.2 series. For apache glue authentication, I use the mod_auth_ntlm_winbind.so module apache2 and in the context of config/ntlm to support communication with winbind. This works correctly, example for apache:

#defaults for main www directory Options Indexes FollowSymLinks MultiViews AllowOverride None #modified, prevent for any ip access, for future add authless access from specified hosts Order deny,allow deny from all #allow from IP/mask #settings for NTLM auth with winbind helper AuthName "NTLM Authentication" NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --domain=MY.WINDOWS.DOMAIN --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative on AuthType NTLM require valid-user #because ip is default deny satisfy any

I was hoping maybe I can do some redirect using the apache authtype variable and then added to the above rewrite config:

RewriteEngine on RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER)

And an example script TestAuth.pl as cgi content:

#!/usr/bin/perl use strict; use warnings; use Data::Dumper; #easy way to print system variables print "Content-type:text/plain\r\n"; #respectint HTML protocol print "\r\n"; print "Environment contains:\r\n"; print "x\r\n"; print Data::Dumper->Dump([\@ARGV,\%ENV],); #prints all script arguments and process variables

Unfortunately, in all cases, using windows based ntlm auth and prompting for credentials, I always see the AUTH_TYPE is always NTLM. Then there is no way to know what the browser is doing. In this situation, I can access from clients from the domain.

I tried wrapping ntlm hepler strace. Unfortunately, I don't see anything important in my four-way dump of success/failure and IE access triggered by the FF ant request. I think the same situation occurs when the ntlm helper authenticates to the local samba server, but I've never tested this.

Now I'm trying to do some configuration with multiple auth, Basic and NTLM types. First I try to do Basic and filter that when allways fail and redirect it to info page. Unfortunately currently without success with NTLM mix:(NTLM is always done first.

Then does anyone have an idea how to prevent credentials? How do I revoke access from invited customers? How to recognize credentials from prompt or from api client window?

0

2 responses

Currently I solved this problem by switching NTLM to Kerberos authentication. All winbind-ready ones run directly under kerberos because I previously configured kerberos for winbind with AD server communication. Because kerberos is open, the developers predicted different sub-authenticators on the user's endpoint. A very useful flag is in the apache2.2 kerberos module:

KrbMethodNegotiate on KrbMethodK5Passwd off

This is what I want. The browser receives a krb frame with the "Don't Pop Up User Credentials" attribute, then the client just doesn't do it. But if so (some kind of incompatibility?), the Apache server module should detect that and should revoke the authentication.

Using Microsoft's NTLM, this is not possible because the protocol is broken. The first NTLM frame after the website code 201 is returned does not have the option to add the "don't prompt user for credentials" attribute. I can then filter that frame after the OS session key popup or sign. This browser always shows a popup when the OS session key is not available.

After all, this is another chance. The user takes some time to enter the credentials or accepts when the credentials are stored in the browser. I can count the time between the auth frame being sent to the browser and the frame being assembled from the client. When the time is too long, I can cancel. Unfortunately, this can cause false authorization on busy computers or networks.

I will use both methods in the future :) It would be fun if everything could be done with the apach winbind auth module. The whole configuration can then be encapsulated under apache, the same as for kerberos auth.

Thank you all for interesting, research and help :)

Using NTLM authentication does not guarantee credentialless authorization. If you have valid Windows credentials that the server can recognize, you will not receive a password prompt.

If the user does not have valid skipped NTLM credentials, they will be prompted to provide them. This is not a way to revert to "basic" authentication.

Unfortunately, there is no way to determine if the user provided credentials or if they went through the system.

Maybe ask a new question about what you want your users to experience (i.e. different sites for internal and external users) and someone else might be able to help.