Matt, either I'm missing something or you're overlooking a mitigating
factor in your scenario. Let's see if we're on the same page with
your scenario: domain admins once in a while have to fix something on
a user's PC (laptop or desktop), and are trained not to logon at the
console but to use RunAs (either command line or through UI context
menus) to elevate certain processes to help resolve the issue.
One primary concern is that a compromised user's PC will allow an
attacker to grab a copy of the domain admin's cached domain creds
(agreed) and brute force the password using a combination of rainbow
tables and password crackers. Are we still on the same page?
Assuming we are, then I would suggest that you have it within your
power to make it extremely unlikely that an attacker can actually
*exploit* this residual risk. If your domain admins' passphrases are
reasonably long (15-20 characters, complex or not, is fine for most
organizations), and if your password expiry policy is reasonably
priced (are you much greater than 90 days?), then under normal
circumstances an attacker would have to brute force a 15-character
cached domain verifier in something less than 90 days. If it takes
them more time than the next required password update, then who cares
if they've brute-forced a domain admin password - it's of no use to
them anyway (is it - you aren't incrementing your DA passwords are
you? If you are, don't answer that).
Remember that a "rainbow table attack" against a cached domain
verifier means that instead of the single table for all LM or NTLM
hashes, they'll need to build one of these tables *each* for every
combination of (NTLM hash + username). That's a whole lot more
compute power, storage and effort than we're typically seeing (at
least for now). And when we're looking *only* at the attack space
against 15+ character passphrases, even the NTLM hash table itself is
a freakin' monster (let alone the set of (NTLM hash + username)
tables. Sorry, but I think we'll get a positive hit on SETI before we
see that as an instantaneous web service [but then I was a big fan of
the X-Files].
Hell, if for your organization, the residual risk here is *still*
unacceptable, you will have to consider issuing tokens such as smart
cards for all privileged accounts. Try brute-forcing the public key-
encrypted cached domain verifier - THAT's got reasonable odds against
Zefram Cochrane.
Out of scope for this scenario (at least I hope so, with your
admirably level-headed beachhead approach) are compromised systems
where the domain admins frequently logon (e.g. servers, their primary
workstations), and less-privileged user accounts used more frequently
on client PCs. [Surely there are risks here as well, but they
shouldn't be as significant, and are presumably lower priority on your
list right now.]
Hope this helps,
Mike Smith-Lonergan
Intel Security Center of Excellence
Thanks for the answer(s). And the commercial(s).
That's a bummer. I was hoping I could just mitigate this (arguably large,
arguably small) residual risk by using a change to our administrative
procedures. I guess not completely. Yes, the larger password for the domain
administrator accounts is a good mitigation.
For what its worth, my working hypothesis is that I have compromised hosts
in my network (egads! what candor). Surprisingly many large networks have
this problem (the prevalence of botnets within corporate intranets is scary),
though most corporate IT shops are in denial. Worse, most just practice
"patch and release" instead of "wipe and reload" as part of their "incident
response". As a result, the intruder's entrenchment remains high.
As a result, I'm attempting to pull together a incident response best
practices guide that allows shops to actually recover from an entrenched
attack over time. It is naive to think that you'll find and fix every
effected host in the initial response activities. So you must start with
securing a "beachead" that over time allows you to be confident in your
server infrastructure, then over time through precision monitoring of network
traffic and host event logs along with solid desktop configuration/patch
management you can keep peeling back the onion to ensure the network is
eventually "intruder free".
You'll note that the original question was laptop based, but if you assume
that desktops in your network will be compromised, you need to be sure that
you have a way to limit exposure to this sort of expanded attack originating
from them too.
Regards,
-Matt
Steve Riley said:
Oops! Right, I missed that bit.
In answer to your original question, it depends on which kind of logon you
use. Anything that does an interactive logon will store cached credentials,
so yes, the GUI RunAs will do this. The command-line RunAs will also, unless
you include the /netonly switch.
Sure, rainbow tables are growing in popularity. They're effective in
pass-the-hash attacks, and this is why I've become an ardent fan of long
simple passphrases rather than short complex passwords. Pass phrases are
easier to remember, you can type them quicker, and they thwart rainbow
tables. Consider a simple 20-character passphrase: you're looking at many
tens, maybe low hundreds, of years to generate. And I can't find a handy
formula now, but I suspect that finding sufficient hard drive space to store
the output will be a bit problematic. For the same reasons, rainbow tables
become ineffective against password verifiers: remember these are salted
with user IDs, which require significantly larger tables--again, there's the
time and space issues to contend with.
Interesting corollary you've thought of, and I'm sure there's a lot of smart
discussion that could take place around it. I would consider it this way:
the only true defense we have against physical access is time. If we can
implement measures that seriously increase the time it would take to launch
an attack, then the stolen asset becomes less interesting (and indeed
probably encourages the attacker to move on to someone not as smart as you).
I like to think of encryption as the thing that buys us time. If the
available measures increase the time cushion to millions of years, then I'm
cool with that--to me, it's good enough. Long simple passphrases and
BitLocker (with TPM and PIN, please) are satisfactory mitigations to
Immutable Law #3.
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
"(e-mail address removed)" <
[email protected]>
wrote in messageThanks for the quick response. And while I agree with each of your points
(I
was attempting to acknowledge that in my original post), you didn't
actually
answer my question...
If a user logs into a domain machine using "normal" domain user access
credentials, and uses runas to do priviledged operations (assume they use
domain admin account credentials), is a credential cached anywhere for the
domain admin account?
As to your point, rainbow tables are starting to become available to more
"ordinary" users, and so the "theoretical" is becoming more and more
"practical" every day. Underground, distributed, collaborative rainbow
table
cracking networks do exist...
My concern is that I'm trying to determine if Corallary 1 to Immutable Law
#3 is true or not... -- "If a bad guy has unrestricted physical access to
any
computer in your network, even if its disconnected from your network, it's
not your network anymore" That would be bad....
"Steve Riley [MSFT]" wrote:
As Jesper and I describe in our book
(
http://www.protectyourwindowsnetwork.com), cached credentials:
* Are stored not in LSA but in the security hive, a better place for
storing
secrets
* Are _not_ your ID/password or the hash of your password, but instead a
hash of the hash, salted with your user name (in practicality, this makes
them nearly impervious to ordinary password cracking tools)
* Require running attack tools in SYSTEM context: meaning the bad guy
already has complete control of your computer anyway, so who cares?
There's way too much fretting and worrying over this. Without cached
credentials, laptop computers become completely useless when not
connected
to the domain--and this, then, destroys the very reason that laptops
exist.
If you're really worried about cracking passwords, then set password
policies that require certain complexity or--better--a minimum length of
at
least 15 characters (then you can ignore complexity). Now you can
eliminate
password cracking attacks from your list of worries, because the time
required to crack them stretches into the hundreds of millions of years.
(Actually, password cracking attacks really aren't even that interesting.
"Pass-the-hash" attacks, where the bad guy already has hashes of
passwords,
_are_ interesting: see the "Should I be concerned about password
cracking?"
section in Jesper's article at
http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx.)
In your note, you quote Immutable Law #3
(
http://www.microsoft.com/technet/archive/community/columns/security/e...).
Not to sound flippant, but the best way to thwart this attack is to make
sure you don't get your laptop stolen. There is, of course, a mitigation
for
this, too: BitLocker Drive Encryption in Windows Vista Business (if you
have
Software Assurance), Enterprise, and Ultimate editions.
One other point that might matter: here at Microsoft, we don't disable or
tweak the settings. We leave the number of cached credentials set to the
default (10), and we require strong passwords. Soon we'll be moving to
corp-wide smartcard logon and finally getting rid of passwords.
Steve Riley
(e-mail address removed)
http://blogs.technet.com/steriley
"(e-mail address removed)" <
[email protected]>
wrote in message
I know this is a topic that has been argued about in security circles
for
some time...
However, I haven't been able to find an answer to this particular
question:
If a user logs into a domain machine using "normal" domain user access
credentials, and uses runas to do priviledged operations (assume they
use
domain admin account credentials), is a credential cached anywhere for
the
domain admin account?
Background: if I login to a machine directly with a domain admin
account,
the domain admin credentials will be cached locally. While these
credentials
are somewhat protected through Microsoft's approach with encrypted
"verifiers", they are not completely secure from a determined attacker.
Lots
of argument about how difficult it would be, but I'm confident there is
an
attack vector there. The old adage "if I have physical access to your
machine, there is no telling what I can do" applies.
I understand that there is a registry key (CachedLogonsCount=0) that
can
be
set to disallow the caching of credentials, but that doesn't really
work
well
when the computer is a laptop that needs to be useable when
disconnected
from
the domain. My ultimate goal is to ensure that our security practices
for
domain adminstrators don't expose the corporate network to additional
risk
when a laptop is stolen.
-Matt
