NTLM Authentication and Insecure Ciphers

Posted on by
RetroTutorial: Installing MS-DOS LAN Manager 2.2c

When it comes to identity management, a directory is a repository of accounts. An account represents an entity with attributes and an identity to identify it uniquely. Password, as an authenticator, is the most commonly implemented authentication factor, something you know, so password breach results in a severe business impact.

Protecting passwords at rest, in transit, and in use is crucial. The account database can exist as a system file, registry, data structure in the memory, backup file in tapes, or in any ephemeral or persistent form in any storage. Understanding how operating systems store, convey, and cache authenticators (the password itself or its derivatives) for authentication is critical to minimizing the attack vectors and surface.

Identity Management

Microsoft’s major Network Operating Systems (NOS) evolved from Lan Manager (1987), Windows NT 3.1 (1993), Windows NT 4 (1996), to Windows 2000 (2000). A standalone Windows NT-based computer in the workgroup mode manages its user accounts through the Security Account Manager (SAM). In the centralized domain model, Windows NT implements the NT Directory Service (NTDS), while Windows 2000 delivers the revolutionary Active Directory (AD) Service.

  • SAM on a standalone or member computer stores user accounts and passwords in the system file %SystemRoot%/system32/config/SAM, which is mounted on the registry hive: HKLM/SAM and SYSTEM, and privileges are required to view it.
  • The NTDS.dit file is the Active Directory database. It stores all Active Directory information including password hashes.

LM and NT Hashes

How a password is stored in the SAM, NTDS, and AD is crucial. As far as Microsoft is concerned, they transform users’ passwords into 16-byte hashes using one-way functions; as you may know, the LM hashes and NT hashes. For example, Lan Manager restricts the maximum length of the user password to 14 bytes, converts passwords to uppercase, and computes the LM hash based on DES in ECB mode, while Windows NT permits 256-byte Unicode-based passwords and switches to MD4 and Hash-based Message Authentication Code (HMAC_MD5, MD5-based MAC).

The following is an example of computing LM Hash using the Microsoft LM Hash algorithm, LMOWFv1():

PASSWORD => e52cac67419a9a224a3b108f3fa6cb6d
DES(UpperCase(Passwd)[0..6] ,"KGS!@#$%"): e5 2c ac 67 41 9a 9a 22
DES(UpperCase(Passwd)[7..13],"KGS!@#$%"): 4a 3b 10 8f 3f a6 cb 6d

Pass-the-Hash

Built-in Windows applications require users to submit passwords and generate LM or NT hashes for authentication, while third-party SAMBA implementations accept LM or NT hashes on the fly, and that is subject to the pass-the-hash attack.

However, after the “Pass-the-Hash Toolkit” for Windows is released in 2008 by Hernan Ochoa, it poses threats to Windows using NTLM authentication because “it allowed the user name, domain name, and password hashes cached in memory by the Local Security Authority to be changed at runtime after a user was authenticated.” (Wikipedia)

NTLM Authentication

Posts NTLM v1 Authentication and NTLM v2 Authentication provide a good introduction to NTLM.

# LAN Manager (LM) One-Way Function (OWF)
Define LMOWFv1(Passwd, User, UserDom) as
ConcatenationOf( 
DES(UpperCase(Passwd)[0..6] ,"KGS!@#$%"),
DES(UpperCase(Passwd)[7..13],"KGS!@#$%"))
EndDefine

Define NTOWFv1(Passwd,User,UserDom) as
MD4(UNICODE(Passwd))
EndDefine

Define NTOWFv2(Passwd, User, UserDom) as 
HMAC_MD5(MD4(UNICODE(Passwd)),UNICODE(ConcatenationOf(Uppercase(User),UserDom)))
EndDefine

Define LMOWFv2(Passwd,User,UserDom) as 
NTOWFv2(Passwd,User,UserDom)
EndDefine

# NTLM v1 Authentication
Set ResponseKeyNT to NTOWFv1(Passwd, User, UserDom)
Set ResponseKeyLM to LMOWFv1( Passwd, User, UserDom )

# NTLM v2 Authentication
Set ResponseKeyNT to NTOWFv2(Passwd, User, UserDom)
Set ResponseKeyLM to LMOWFv2(Passwd, User, UserDom)

Download [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol.

Insecure Ciphers

References

Leave a Reply