NT Security

Subjects in NT are processes and threads. Each process and thread is associated with an access token that is a complex data structure defining characteristics of the subject. One of the most important attribute lists in the access token is its privileges. Any time a process or thread is able to increase its privileges, that subject is able to access other resources that might normally be off limits.

Access control lists are associated with objects. Two different ACLs—object ACLs and system ACLs. Object ACLs control access requests by subjects. System ACLs control activities, such as auditing for that object. Depending on the type of object, the ACL entries vary. For example, access control entries (ACE) for files are different than they are for registry keys.

Based on this simple review, you probably see some of the important events to monitor on NT systems. Any time a change is made to a user's privilege list in the user database you want to be notified. Changes to ACLs for important system files and directories also are potential preludes to an attack. As in UNIX systems, you should watch for attempts to install Trojan Horses. Especially serious is any attempt—successful or not—to increase the privileges associated with a thread or process.

Sources of Data for NT IDSs

By now, it should be apparent to you that intrusion detection is a special case of monitoring. Performance monitoring tools track network traffic, system resource utilization, and application behavior. IDSs also need data from various sources to operate effectively.

Vulnerability scanners that assess the state of your machines operate in one of two modes. Remote assessments are carried out from a central console and targeted at individual nodes in your network. With a remote scan, no special software is needed on the target machines. Local assessments are undertaken by software specifically installed on the node. When a scan is activated by a remote manager station or by a scheduled job, the local scanning software runs on the target node itself.

NT local vulnerability assessment tools operate much the same way as UNIX scanners. They look at configuration information on the system, inspect the contents of files, scour through registry entries, and attempt to crack passwords in the SAM. Other features, such as file-integrity checkers, are supported as well. Recall that a local scanner has the advantage of operating on the system as a login user. This means that the local scanner can read files and access other resources that a remote scanner cannot. Of course, you must install the local scanning code on each target.

Remote scanners against NT systems probe for known network configuration problems, check for back-level programs with holes, and attempt to gain access to the system by breaking in as normal users or as the administrator. The source of data for these IDSs is primarily feedback that comes from interacting with NT network services or applications, such as the Internet Information Server (IIS). Remote scanners benefit from the fact that they do not run client code directly on the target. For this reason, vendors can combine both NT and UNIX probing into the same product. As in the case of UNIX remote scanners, it is possible to peer into some of the internals of an NT system even though you are not running a process on that system. For example, if the trust relationship is configured to permit remote access, some NT registry entries can be inspected. Microsoft's Server Message Block protocol also divulges information to remote scanners, including the list of currently logged in users.

Network sniffers for UNIX and NT often are combined into one product, too. The source of data is the same for UNIX and NT network sniffers. Only the attacks monitored varies between the two operating system types. Many attacks are equally applicable to the IP stacks on both, such as SYN Flood.

System-level IDSs in UNIX and NT rely on different datastreams. NT provides an event log (or audit log) that tracks many important activities on the system. Vendors, who write system-level IDSs for NT, such as Centrax and Kane, depend on the event log for the data that drives their engines.

NT Event Log

There are really three different event logs in NT—system, application, and security. The security log is the one IDS vendors are most interested in watching. Records are stored in a log file as events occur. NT Administrators can control the behavior of the logging subsystem in a number of ways. Space is controlled by defining a limit on the size of the log file. When the threshold is hit, options include the following:

• Overwriting events that are only N days old
• Pushing out the oldest records as new ones come in
• Halting the system to prevent loss of an audit trail

To configure auditing, you first decide which event categories you want to monitor:

• Logins and logouts
• File and object accesses
• Changes in user rights
• Processes or thread events, such as creation and termination
• Changes to the security policy for the system, such as giving additional privileges to a user
• Restart, shutdown, and other system events

When you know which categories of events to monitor, you must enable auditing for individual users and objects. Auditing is turned on for a user through the user and group manager application. To enable auditing for an object, such as a file or directory, you use the File Manager. For a file, you can select whether to monitor success or failures for the following access types:

• Reads
• Writes
• Executes
• Deletes
• Permission changes
• Ownership changes

What to Monitor on NT part 2

Impersonation

In earlier chapters, you learned that a critical component of computer systems is the capability for a process to act on behalf of another user. NT refers to this as impersonation. Recall that after a user logs into NT, an access token is created. In addition to containing a list of privileges and other fields, the token has a setting that defines the impersonation level for that token:

• Anonymous. No other process or thread is allowed to see any of the details about this token.
• Identifying. A process with the appropriate privileges can obtain information from the token, such as its SID, its groups, and its currently assigned privileges.
• Impersonation. A process with the appropriate privileges can impersonate the owner of the token on the local system (note that this does not include impersonation on a remote system).

The impersonation level for a token can be changed any time during the lifetime of the token through NT APIs. If you are writing software, you can decide whether to allow remote systems to operate with the security context of your token. If you allow impersonation, other remote services can act on your behalf. This practice is necessary for accessing remote shares, for example. However, it also could be a security hole. A hacker who plants a bogus service with impersonation privileges will be able to use your credentials to impersonate you on other remote systems.

When you are logged into a system running NT, you might interact with system services and higher privileged processes many times. These process do have sufficient privileges to impersonate your access token. Because the system services run with very high privileges, they are essentially downgrading their capabilities when they create a thread to handle your request and associate your access token with the thread.

NT does not log all of the activities associated with impersonation. This is somewhat unfortunate because many unrecorded events affect the security policy of the system. Numerous system calls are provided to create access tokens, assign privileges to tokens, associate tokens with threads or processes, impersonate access tokens, and duplicate access tokens. A process must have very high privileges in order to successfully complete an operation through one of these interfaces. For example, a process must have the right to duplicate tokens if it wants to invoke the duplicate token system call. When this call is requested, it is the beginning of an attempt by one process to act on behalf of another. You can understand why this is an important event to monitor.

Other than security-relevant events that you want to track, NT has been hit by a number of hack attacks. You should know that many early attacks were found in NT 3.51 and were fixed in NT 4.0. Some intrusions have been reported on NT 4.0 as well, although service packs and patches are available to correct the bugs.

Remote Attacks

Because NT supports TCP/IP, NT is vulnerable to the protocol attacks mentioned earlier in the book—Ping of Death, SYN Flood, session hijacking, and address impersonation. Some vulnerabilities specifically are found in the IP implementation on NT. The Teardrop UDP attack is a Microsoft-specific bug found in the way NT handles UDP packets. Large datagrams can cause the receiving system to hang. Different variations on this attack have surfaced often in the last few months.

The SMB protocol begins with a challenge-response authentication phase, but like I&A servers, it is still open to impostor-in-middle packet attacks. Other attacks specific to NT itself have been publicized during the last several years. Summaries are provided in the next few paragraphs.

The Anonymous vulnerability was one of the first widely announced weaknesses. The problem arose from an undocumented user in the operating system known as the anonymous user. Machine-to-machine communications relied on this anonymous user for exchanging information. Because the anonymous user was still a user to the operating system, it was able to access resources available to the Everyone group. A remote user could read registry entries, list users, and obtain other data that could reduce the time it takes to crack a system. Microsoft fixed the problem with a patch.

The DNS query ID attack also gives remote users an opportunity to spoof responses from the DNS server. The query IDs were generated from a predictable sequence giving hackers a chance to forge DNS responses and to cause the victim to carry out conversations with an impostor host. This sounds much like the TCP session number guessing attack "Traditional Network Security Approaches." Microsoft also fixed this bug in a patch.

Shared resources from NT are exported to other network users using NetBIOS. A share with weak permissions gives remote users access to data they should not have. Although this is not a program bug, it is an administrator configuration error that can lead to intrusions. No patch is available for this—you need to be diligent about permissions for exported and shared resources. The corollary in UNIX is the set of permissions for exported NFS file systems. Several variations of the problem exist. Any user with legitimate access to the system can by default have full access to a share. For this reason, it is important to explicitly set permission when a share is created. Another variation allows anyone who can access the system as Guest to also have full permissions on the share. Shares also can be protected with a password. Scanners attempt brute force attacks against share passwords to look for openings.

Microsoft's IIS was at one time vulnerable to a rather nasty problem. Arbitrary remote browsers could run any accessible command on the Web server. Two flavors of this problem were called the ".bat" and the ".cmd" bugs. A new release of IIS has since fixed the problem, but scanners look for back-level versions of the program. In the summer of 1998, a few more variations on this attack were discovered, too.

The NBSTAT command can probe remote NT systems for important information, such as the names of logged in users (similar to rwho on UNIX). A hacker now can try cracking attacks against the accounts and possibly cause denial-ofservice if failed login thresholds are set.

One of the early problems encountered by NT administrators was the ntfsdos.exe attack. A normal user could run ntfsdos.exe from a floppy and bypass all of the ACLs set for the NT file system. This hack is listed here because a perpetrator did not even need an account on the system to threaten the system. A patch was released shortly after the problem was reported.

Attacks are not always directed at servers. A LOpht Security Advisory (LOpht, 1997) showed that Microsoft's Internet Explorer experienced a buffer overflow condition when processing URLs. A malicious Web server could trick your NT workstation into executing arbitrary commands In general, browsing the Internet is difficult without risking attacks such as these. Connections are inherently anonymous, and therefore access control is minimal. Also, attacks such as the Internet Explorer URL bug point to the importance of personal intrusion detection products. When browsing the Web, wouldn't it be good to know if some process or thread launched by the Web browser suddenly is deleting files from your disk?

What to Monitor on NT part 1

How do you know what to monitor on an NT system? First, you definitely want to watch for any well-known hacks. Most NT IDSs do this today. The next kind of event you want to know about is anything that might affect the security of your system. No doubt that sounds a bit broad. Unfortunately, this description is vague and does encompass a number of events. Here are some examples:

• A new user is added to your system.
• The administrator logs in or logs out.
• The administrator establishes a trust relationship.
• Someone deletes a critical system file.
• Someone changes another user's profile.
• Someone takes ownership of another user's file.

These types of activities are all single events that can affect the security of your system. Even a single login event is something you might want to monitor. How much to monitor depends on how tight your security must be. System monitors, such as KSM and eNTrax, have a predefined set of events or signatures they detect. If you don't know which of these events to capture, select all of them until you have a better idea of what's important. Two very important event categories to keep an eye on in NT are privilege changes and impersonation. Both are ways one can gain additional privileges.

Increased Privileges

When a user is created on the system, a set of default privileges is granted. Privileges allow a user to perform operations such as shutting down the system, adding other users, acting as part of the operating system, creating processes, logging in remotely, and backing up files belonging to others. DAC and privileges together limit what an individual user can do on the system.

A privilege vector is stored with the user definition in the system. Privileges associated with a group also are stored with the group information in the SAM. When a user logs in, the privilege vector is constructed from privileges assigned to that user and privileges defined for groups to which the user belongs. The complete set of privileges controls what kinds of operations that user is allowed to initiate while logged in to the computer. A privilege that enables a user to act as an administrator is something to be carefully monitored. The GetAdmin hack introduced earlier in the book grants administrator rights to an arbitrary user by exploiting an NT bug. The event log contains enough evidence to spot when this happens. To distinguish the GetAdmin hack from a legitimate change in privileges, the IDS must contain a signature relating multiple events. Nonetheless, the event log does allow an IDS to detect GetAdmin.

NT administration somewhat simplifies the task of assigning privileges to user and groups. Sets of common privileges are grouped into rights. Instead of assigning individual privileges to a user, you normally assign rights through the user and group manager application. If you want, you can select privileges one at a time and grant them to specific users, too.

The NT audit log reports privilege changes for users in distinct event records. IDSs watch the log for these entries to alert you to possible security problems. The privilege vector associated with an access token also can be altered through programming interfaces provided with NT. This means that the administrative GUI is not the only way for users to increase their privileges. You saw that UNIX systems had a number of facilities for increasing privileges. SUID programs in UNIX give users temporary privileges associated with the owner or group associated with that program. NT has similar capabilities through impersonation.