Typical NT Environment Security Weaknesses

by Archer - 3/18/00

Have you ever been asked or pondered the idea of what to target when attacking a network? Some say go for the servers, because that is where all of the goodies are kept. Such as a large collection of users, Domain level user and administrator accounts, network applications to exploit, etc. My opinion differs. I go for the workstations. Why, you may ask. Let me answer the question by presenting a scenario of what I have found more often than not when performing security reviews of numerous organizations.

1. A typical NT environment usually consists of at least 1 server and numerous workstations with similar configurations.
2. Users are often given Administrator privileges of their local workstations or the ability to perform some administrator functions.
3. Users create local accounts that are governed by the local security requirements.
4. Users create shares on the local system and usually do not modify the default permissions.
5. Workstations are typically not audited.

So, what does this info do for us? In a common office environment, users often need to share files with co-workers so they create shares. What I have learned from discussions with users, is that they create shares then remove them, over and over again until someone comes up with the idea to share out the entire C drive. At this point they have forgotten about or never were concerned with the "everyone" group having full control of the share. Also, they usually create a guest or user account on the local system for co- workers to use to access the share. This account typically has no password or "password" as the password.

Now, after some information gathering through the NULL connection, we have guest access to the boot partition. Which gets us limited (or unlimited, depending on local security configuration) access to the system files, system directories, repair directory, etc. At this point, I typically run that systems registry editor, then (after pausing to thank the guys at the L0pht) use L0phtCrack to dump the target systems passwords, and begin cracking. If registry access is denied, go after the repair directory SAM file and hope it has been updated with the current Administrator password. Can't get to that either, then you have to plant trojan code and wait for someone to open your backdoor.

What's that you say, you use strong passwords. Good for you, but when was the last time you changed the passwords on the local workstation Administrator account? Probably when it was installed. When is the next scheduled password change for the local workstation Administrator account? Probably never. So, now we have the administrator password hash and an extended (if not indefinite) amount of time to crack the hash.

Wow! We have administrator privileges on a system and can now begin attacking the other systems on the network. But, do we have to start from scratch? Typically not. Network administrators need to be able to log on locally to fix local problems, so they use a common password for most, if not all, workstations on the subnet. I have found a site with every workstation on an entire Domain configured with the same local administrator password. Wow! I had administrator privileges on 850 workstations.

Thanks to the kindness of users and weak workstation security policies, we probably have administrator access to every workstation on the Domain.

How do you remedy this problem? Below are several suggestions on how to limit the attack.

1. Block ports 135 - 139 at the network perimeter.
2. Don't give the local user administrator privileges on their workstations.
3. Do not use the same Administrator password on every subnet.
4. Give the workstation Administrator account a 14 character password that has at least 1 alpha, 1 numeric, and 1 special character in both the first 7 and last 7 characters of the password.
5. Create at least 2 partitions on workstations. One for the boot partition and system files and another for user use. Don't give the local user permissions to the system partition.
6. Use SMS or login scripts to force changes to the administrator password quarterly cycle. More often if you are paranoid like me.
7. Disable the NULL connection in the registry and rename the local Administrator account. Security through obscurity. Disabling of the NULL session is only available with Service Pack 4 or later.

1.Run Registry Editor (Regedt32.exe).

2.Go to the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

3.On the Edit menu, click Add Value and use the following entry:

Value Name: RestrictAnonymous
Data Type: REG_DWORD
Value: 1


4.Exit the Registry Editor and restart the computer for the change to take effect.