9

It is a well known security risk that LSASS stores clear-text passwords if a user has performed a keyboard-interactive logon on a machine - be it local login to his/her workstation or using RDP to a remote workstation.

There is also a classic fix to this - disable wdigest and tspkg. So far so good, but if Kerberos is supported, then it apparently needs the clear text password to renew the Ticket Granting Ticket (TGT) and so you're left between a rock and a hard place - don't support Kerberos and enjoy all the risks associated with hash passing or support Kerberos and accept the risk of cleat-text passwords. The linked post gives the following advice which I think is unacceptable:

Therefore, the most effective protection is to avoid interactive logons to any untrusted hosts.

A big enterprise has 1000s of servers, how do you known which one is compromised and login should be avoided?

My question: are there any practical measures other than rolling out a 2FA (onto those issues later) that would permit a secure keyboard-interactive logon?

P.S. About 2FA. The most common methods are passcode + OTP and X.509 PKI on a smart-card. They aren't flawless either:

  1. if you have hijacked the lsass process, then you could arguably use the otp+passcode to log on to other servers while the passcode is valid. Using auotmation, this could mean you've logged on to tens of servers or more during the 60 second window
  2. As per this TechNet article the user sends the PIN to the server and makes the smart-card available to the RDP server. Same process as in the first item can be used to hack many servers while the admin is clicking away at the compromised server.

°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸

2018 Update: Starting from Windows Server 2012 R2 and Windows 8.1, the LSASS can be ran as a protected process by enabling the RunAsPPL setting and inhibiting credential dumping. Starting with Windows 10 and Server 2016, the Windows Credential Guard is enabled by default and achieves similar outcomes.

°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸

Konrads
  • 589
  • 1
  • 5
  • 15
  • You're assuming you're using a time-based OTP system. Event-driven OTP's can only be used once. – Steve Jul 10 '13 at 16:31
  • True, I had your basic RSA token in mind. – Konrads Jul 10 '13 at 16:47
  • 2
    Securing credentials in pre Windows 10 environment is a nightmare. However, Windows 10 introduced Credential Guard which is the only true method of securing against these credential thefts AFAIK. https://technet.microsoft.com/en-us/library/mt483740(v=vs.85).aspx. Unfortunately, when it comes to Enterprise we are still stuck with Windows 7. – void_in Jan 22 '16 at 09:48

2 Answers2

1

To answer your question: I believe that the safest way would be to use psexec to get a remote cmd shell. This method should not result in a plaintext password stored. Or do you mean interactive, AND with a GUI?

Unfortunately your best solution really is to avoid interactive login whenever possible.

Luckily there are some safe ways to remotely manage machines:

  • winrm (including Invoke-Command powershell)
  • psexec (only if you do NOT use the "-u" option)
  • Remote Assistance

These are pretty safe. You generate a token on the machine but that is part of the Windows architecture and not a bug/flaw.

You should avoid using the following whenever possible, as it is possible to dump plaintext passwords using mimikatz:

  • RDP
  • psexec with the "-u" option

With Windows 8.1 (and Windows 2012R2?), the plaintext wdigest password is disabled by default. However, as demonstrated in this article, you can simply re-enable plaintext password storage in the registry. And, there's always kerberos attacks.

nyxgeek
  • 1,297
  • 10
  • 22
0

While you might not like my answer, I don't see a problem with that. Ok, having the password in memory in clear-text is not ideal, it is required in these cases. How would that be a security risk? Well, in order to exploit this, you need Administrative rights, because lsass runs under the protected System account. And be logged in as the same user as you want to exploit. So there's no priviledge escalation resulting from this; the Administrator that logged in has access to his own clear-text password. It would pose a problem, if a program could access that clear-text password without user-intervention. This is not the case (UAC, access to inject code, etc) So you would need additional flaws to get it.

For your specific question: How to know? You don't know. Same as when users tell their password to a friend. You can't protect against that.

Yes, using 2FA or Smartcards is generally a good idea, as you don't enter a password directly.

http
  • 127
  • 1
  • 1
  • 5
  • 1
    The problem lies in the fact that an administrator cannot safely log on to a computer on the enterprise without risking compromising all other computers due to account hijack. – Konrads Jul 12 '13 at 18:21
  • 1
    The problem is that if a user has local admin on a box they can get a SYSTEM shell and dump passwords (and SYSTEM can get everybody's -- you don't need to be the user). – nyxgeek Jan 21 '16 at 16:37
  • You forget that the person logging in might not be doing so with the local administrator password (which is already breached according to you since you need SYSTEM to access LSASS). It might also be a domain admin logging into your system and leaving his credentials. Or maybe it's a support account with admin access on all laptops or servers. You can then escalate from a local admin -> system -> domain admin or admin on all servers/systems. – Silver Feb 10 '21 at 15:56