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?