Recently, we were approached by a customer that claimed to be immune to Pass-the-Hash and Pass-the-Ticket attacks, as they were using Windows Smart Card Logon. Ten minutes later, we had demonstrated these specific attacks on their “immune” environment, thus taking complete control over it.
This story made us realize that although on the face of it, Smart Card Logon in Windows seems like a good upgrade to the security of the authentication process, recommended by the PCI-DSS (Payment Card Industry-Data Security Standard) regulation, a deeper look reveals it has also a bad side to it as it provides a false sense of security in regards to credential theft from malware infected machines. To add insult to injury, Windows Smart Card logon has a truly ugly side to it, as it generates an “everlasting” hash, thus providing less security than the regular password-only logon process against Pass-the-Hash attacks.
This matter is so grave, that organizations may find themselves in a “PCI’s Catch 22″ situation: Implementing PCI’s recommended Smart Card Logon for Windows may be in breach of another PCI requirement: to change passwords on a regular basis.
Smart Card Logon enables users to log in to the Windows system using a Smart Card and Personal Identification Number (PIN), instead of using the traditional user name and password login mechanism.
A Smart Card is a credit card sized plastic plate, with an embedded integrated circuit chip that provides memory and a processing unit. The security of a Smart Card stems from the fact that its memory cannot be directly read, therefore making it ideal to store secret data. Even indirect access to the smart card is protected from misuse through a PIN, known only to the smart card’s owner.
The Smart Cards used in Windows environment store users’ certificates and private keys in their protected memory and their processing unit can perform public key cryptography operations, such as digital signing and key exchange.
Windows supports logging on with a Smart Card by using extensions to the Kerberos v5 protocol. Instead of typing a password, a user inserts the Smart Card to a reader that is attached to a computer to initiate the logon sequence. The user is then prompted to enter the PIN for the Smart Card. If the user’s PIN is valid, then the Smart Card’s stored certificate is validated against the Domain Controller by using extensions to the Kerberos v5 protocol. If the Domain Controller is able to validate the certificate, the user is logged on and granted rights and permissions to their account.
PCI-DSS (Requirements 8.2, 8.3) defines two-factor authentication as an authentication method which requires that two of the following three authentication methods:
Since Smart Card includes an embedded private key (“something you have”) and requires PIN identification (“something you know”) it is a true two-factor authentication mechanism. Therefore, Smart Card Logon can reduce the risk of a user’s identity theft, since a potential imposter needs to steal two orthogonal factors in order to masquerade as the legitimate user.
As a result, the PCI-DSS recommends two-factor authentication for internal network access as a “compensating control” that can be used as a substitute for other controls when they are not applicable.
The problem starts when Smart Card Logon is perceived to provide protection in cases which it does not; most specifically malware attacks. The source of the error is very much understandable. The Smart Card is a detached physical device that protects its inner secrets and should be immune to a malware residing on the machine. Microsoft’s documentation states exactly that: “Because cryptographic operations are isolated from the operating system, Smart Cards are not susceptible to attacks on the operating system (such as buffer overflow attacks and memory dump attacks, which might reveal private keys or other cryptographic secrets).” It is likely that a reader following the guidelines presumes it is safe to logon to a malware infected machine with a Smart Card as no credentials are left on the machine once the card has been removed.
However, in Windows environment this logical argument is completely false. Smart Card’s secrets are indeed beyond the reach of a memory residing malware. However, both of the Windows supported authentication protocols, NTLM and Kerberos, create some memory stored tokens, namely the NTLM hash and the Kerberos ticket, to support the Single Sign on (SSO) authentication paradigm. These memory residing tokens, are generated during the process of every logon, including Smart Card logon. Consequently, Smart Card logon’s users are every bit as exposed as password logon users to Pass-the-Hash and Pass-the-Ticket attacks which allows the attacker to abuse the victim’s credentials and steal their identity long after the Smart Card has been removed from the infected machine.
Smart Card’s Pass-the-Hash perils does not stop at its false sense of security. In order to support systems that require NTLM authentication, Windows needs to generate an NTLM hash. Since Smart Card does not have a password to derive the hash from, Windows engineer decided to artificially generate an NTLM hash for Smart Card users. The problem: this token, which is password equivalent, NEVER EXPIRES. This is not a implementation bug, as a Microsoft’s official white paper states it explicitly: “If the account has been configured with the attribute Smart Card required for interactive logon, then the NT hash is a random value calculated when that attribute was enabled for the account. This password hash is provided to the client computer during the smartcard logons process by the domain controller. This password hash that is automatically generated when the attribute is set does not change“
Therefore, a malware that was able to grab the NTLM hash of a Smart Card’s user, steals her identity forever. The victim would have been better off had she used a password to login to the infected machine, as at least that password would have been expired eventually (typically after 90 days) and the malware would have lost the grip on her identity.
This Windows behavior seems to be in breach of the PCI-DSS regulation, as it violates requirement 8.2.4: “Change user passwords/passphrases at least every 90 days.”
Therefore, implementing Windows Smart Card authentication should be weighed very carefully by the security team and must be compensated with additional security controls to mitigate Pass-the-Hash and Pass-the-Ticket attacks.