Physical Security of an W2K3 DC

[thatch]

To help build a case for a security budget, amongst other things, I would like to demonstrate why the physical security of (W2K3) AD DC's is important.

if a rogue employee (or anyone for that matter) had physical access to such a box using Knoppix, BackTrack or other tools would he or she be able to extract the AD database from a unsecured box and crack the passwords. Could anyone either explain the steps or direct me to a resource.

Thanks

T.

[576869746568617]

Well, from what I understand from your scenario of users having admin rights indiscriminately, you wouldn't even have to have anything like that. All it would take in your organization is to piss off the wrong employee. The main issue that you have to get the boss to think about is that if everyone is an admin...no one is. Any one of those users could bring your network to its knees, either intentionally or unintentionally.

But to answer your question directly, the answer is yes, if they have physical access to your DC, they can do WHATEVER they want. This is compounded by the fact that they already have admin rights on the box (from the info you provided in your other post.) They really wouldn't have to do it offline either...they could just do a NetBIOS hack from a workstation on the LAN, using tools like User2SID and SID2User.

Another thing that you need to stress to the admin about physically and logically securing the DCs is that once the network has been thoroughly hacked, the admin has three options: update their resume, hope the hacker does a good job running the network, or drain the network. They will also need to take action to deal with the attack and clean the hacked system. This is more work for the admin than securint the machines in the first place, because:

You cannot clean a compromised system by patching it; patching only removes the vulnerability. Once te system has been compromised, the attacker will almost always build themselves an alternate point of entry.

You cannot clean a compromised system by removing the backdoors, because you cannot always find them all.

You cannot clean a compromised system by using some "vulnerability remover." Let's say your system was hit by Blaster. A number of vendors (including Microsoft) published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? I wouldn't. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it? I didn't think so.

You cannot clean a compromised system by using a virus scanner. A fully compromised system cannot be trusted to tell you the truth.

You cannot clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that can lie to the installer. .

You cannot trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. Copying data from a compromised system and putting it on a clean system will in the best case scenario give you potentially untrustworthy data. In the worst case, you may actually have copied a backdoor hidden in the data.

You cannot trust the event logs on a compromised system. Once an attacker gets full access to a system, it is simple to modify the event logs on that system to cover his tracks. If you rely on the event logs to tell you what the attacker has done to your system, you may just be reading what they want you to read.

You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is completely useless. It may be a backup that includes all the backdoors currently on the system. For that matter, how can you trust any backup?

The only proper way to clean a compromised system is to flatten and rebuild it. If you have a system that has been completely compromised, the only safe thing you can do is to flatten the system, wipe it clean, and rebuild it from scratch.

Using Knoppix to "recover" AD Passwords

[Black Cluster]

Just lock the CD driver, and get rid of the burden of having to put scenarios .....

[576869746568617]

but that's only part of the problem. The scenario we are talking about is not ficticious...this is the actual operating environment that thatch is facing:

No physical security of DCs
indiscriminate granting of admin rights to users that do not need such privlidged accounts
no patches other than service packs on clients or servers
default IOS packages on routers and switches
permitting USB mass storage devices

These are but just a few of the unsafe practices allowed on the actual production environment that he works with.

Just disabling the CD driver doesn't do squat to stop me if I have physical access and an admin account.

[ShagDevil]

f a rogue employee (or anyone for that matter) had physical access to such a box

Thatch,
We keep both our DC's and one other server in a seperate, locked room that only myself and the other Admin know the key-combo to get in. Put it to you this way, short of cutting the bolt-lock off the door, no one can get in that room except us two. Someone copying the AD and cracking passwords would be the least of my concerns if someone (with malicious intentions) got into our server room.
Like 576869746568617 is saying, if these people get administrative rights, forget it. You could lose everything, from the right to log on to your own network, to every file stored on that server. Hell, if someone is malicious enough, you might not even have a server when you walk in the next morning.

[TechGrunt]

Hi there
Sounds like a nasty scenario. 5768.. is very correct in the assessments he puts forward regarding the vulnerabilities you face. In short, physical access = compromise. Regardless of what other security you have in place.

I would also look at doing something about the distribution of administrator rights you seem to have in your organisations. The larger the number of admin accounts you have the greater the risk of a rogue admin or a hijacked account. Particularly if you have personnel who (from the description of the environment) don't seem to need the right. In this case, those personnel are likely not to treat the account with the care it deserves and may forget the power that the commands they issue on the system have. In which case you get lots of accidents.

In addition to putting a case forwarded for physical security, I would also look at either rationalising the admin accounts (sooner rather than later) or trying to implement a system of RBA and give the personnel just the access they need to do their jobs

Hope this helps

TG

[thatch]

Thanks for your comments and suggestions guys. i certainly have some good pointers now about how to tackle this issue and where to go from here.

Thanks

Thatch.