4

Per recommendations from SANS and others to mitigate against hash dumping and other attacks, I'm looking at defining the 'Debug Programs' user rights assignments using a group policy. When not enabled, the default policy is to allow this privilege to Local System and Administrators, and I'd like to remove this privilege from Administrators (we're not running cluster services, which as I understand it is about the only reason you'd need Admins to have it).

I'm wondering if I should enable this setting and add Local System only, or just enable the setting. I.e., does Local System need this privilege for any reason?

nedm
  • 5,630
  • 5
  • 32
  • 52

1 Answers1

2

Strictly speaking, no, In theory you should only register a debug event with a non-system administrator (unless, as you mentioned, you need other system accounts to have direct memory access to other computers).

I however do take issue with the idea of this paper (And although its bias, I frequently take issue with SANS advice on any number of topics).

Just so I can summarize the paper to everyone who may read this who isn't already familiar with the attack, It goes something like. "You can grab GUID and/or Access Tokens from memory or the network and use their hashed value without ever knowing the original password". They go on to say that common ways of doing this from a limited account include crashing a service that uses SMB/NetBIOS credentials then immediately trying to register CREATE_PROCESS_DEBUG_EVENT and voila - Instant access to the appropriate users SMB share.

For those of you who use hashes, This is probably a pretty obvious attack and is certainly not new.

My issue with this is - Why? Why would an attacker go through all the hassle of grepping through memory for a hash after crashing (presumably) a system-critical service. If an IPS isn't triggered now - The NOC sure is.

Theres hundreds of easier ways, ARP Poisoning, False BPDU manipulation, OSPF Area-rerouting, even using source-route info, All fantastic ways to intercept MS-CHAP or SMB information. As well, privilege escalation vulnerabilities are dime a dozen on NT, Seizing access tokens from a specific application is comically easy.

Ultimately, From where I stand, You're way better off using something like Kerberos or RADIUS, Provided that kind of infrastructure isn't available - NTLMv2 which has more complex Challenge/Response algorithms which cannot be man-in-the-middled without privileged knowledge.

zetavolt
  • 1,352
  • 1
  • 8
  • 12
  • @Zephyr, thanks for your thoughts -- I'm more worried about the variety of methods demonstrated in the paper that dump persistent password caches than the in-memory hash for the current user -- if I understand correctly, the hash from every user who has ever logged into that workstation (subject to the password cache limit) could be dumped using methods demonstrated in the paper, including those who might have admin privileges in the domain. Many of these methods don't necessarily involve crashing a service as far as I can tell, and use widely-available existing programs and plugins. – nedm Feb 25 '10 at 20:24
  • Enabling this setting in GPO seems like a low-effort extra layer of mitigation (along with not allowing admin privileges to users, up-to-date anti-everything, etc., etc.) against many of these methods of harvesting the cache, and as such seems to me to be worth locking down. I'm just wondering if not allowing LocalSystem debug privileges (rather than just admins) might lead to any issues. – nedm Feb 25 '10 at 20:28
  • 1
    The answer is that you'll certainly be fine disabling debug privs on LocalSystem as long as no other service needs to access any other services page file. The password cache limit is well-known and AFAIK disabled in Win7. You can dump the LSA and get old info, but I've always considered changing the cache limit to 0 as standard security practice. – zetavolt Feb 25 '10 at 20:58
  • Thanks, that's what I was looking for. And agree, setting cache limit to 0 should be standard security practice on the LAN. My specific concern here is remote office users who need to be able to log on when their internet and/or WAN link is down. Alas, still mostly an XP shop. – nedm Feb 25 '10 at 22:51