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?

Online Store Benchmarking

This part of our web metrics program assessed and measured the current state of websites on which our products were sold. This initial assessment would then be compared to the same web- sites in the same measurement methods after improvement recommendations had been implemented.

This methodology uses parts from inspection methodology. Because it uses category experts as reviewers instead of actual customers, it does not measure usability. It does, however, measure how well a website is optimized for category and product profitability. This environmental scan is necessary to set the bar for improvement.

The strategy was to use an objective process to measure each site, provide recommendations and e-planograms to the online merchants based on what we learned, and then re-measure the effectiveness after the recommendations were implemented.

It was important that the results be reproducible, so back up copies of specific key findings were made in case the website changed. It was also critical to have a knowledgeable category expert conduct the evaluation because a nuance to one person could result in missed opportunities that would have gone overlooked. Benchmarking methodologies assess the current state of a website and how well it is optimized for sales.

Objectives

The online store benchmark program had four main objectives:

• Understand online store design and content in key areas that shape the user experience.
• Identify gaps and weaknesses in online store deployment and customer expectations.
• Define problem areas and issues related to performing key navigation and ordering tasks.
• Make recommendations for improved customer usability and chances for increased sales based on documented findings and conclusions.

The benchmarking must accommodate different types of store designs and configurations, because all online stores are different. The benchmarking must also accommodate the morphing online marketplace and have relevance to the online merchant.

Strategies

We defined the following strategies to accomplish our objectives:

• Establish objective evaluation criteria, and rate the store's effectiveness in selling key products.
• Quantify which important online sales features are present in key focus category areas.
• Develop search strategy and methodologies based on known customer expectations of the purchasing process.
• Recommend improvements of the site that will result in increased sales and enhance customer usability.
• Aggregate results, and relatively rank all stores evaluated.

Track effectiveness of the store over time, and define ROI of this process based on the increased sales or consumer loyalty index ratings.

The benchmarking program was designed as an ongoing, iterative process instead of a one-time program. Because Internet selling was growing at a rapid rate, it was important to monitor this business. Also, online stores carry a broader product mix than traditional channels. The sites reflect changed navigation models and product profitability.

The Benchmarking Process

We developed and used the following process:

1. Establish search criteria.
2. Develop a metrics scorecard.
3. Conduct the evaluation.
4. Map out purchase process flow issues.
5. Purchase products.
6. Total the scores.
7. Recommend improvements.

Recommendations were supported by annotated screen captures. Recommendations were detailed in an overall recommendations/assessment document that lists good and confusing aspects of navigation by area and category. It also noted best practices that reinforced what appeared to work well within the site.

A meeting was conducted with the online merchant to share key findings and deliver recommendations on online store improvement as it related to category profitability. Store executives, buyers, merchandisers, and members of the IT department attended the meeting, because all have an influence on the online store design.

Iterating Through Records in an SQL Server Table

In many situations you no longer need to iterate through records in an SQL Server table in ASP.NET pages as you did with ASP. This is because you can now bind DataSet Tables directly to controls.

But on occasion you may still need to iterate through all the records in a DataSet Table so that they can be processed in some special way.

The DataSet Table object contains a Rows collection that allows you to iterate through each record it contains. This technique shows you how to create a loop so that you can process each record from an SQL Server table through a DataSet Table object.

The ASP.NET page presented with this technique iterates through each record in an Employees table using a For loop. The ID of each employee is placed into the Text property of this Label control as it is processed:

<asp:label id="1b1Message" runat="Server" />

The code that iterates through the records fires when the page loads:

Sub Page_Load(ByVal Sender as Object, ByVal E as EventArgs)

Within that procedure, these data objects are needed:

Dim DBConn as SQLConnection

Dim DBCommand As SQLDataAdapter Dim DSPageData as New DataSet

You also need a variable that will be used in the For loop:

Dim I as Long

You start by connecting to the SQL Server database:

DBConn = New SQLConnection("server=localhost;"
& "Initial Catalog=TT;" _
& "User Id=sa;" _
& "Password=yourpassword;")

Then you retrieve all the employee records:

DBCommand = New SQLDataAdapter ("Select * from Employees", DBConn)

and place them into a DataSet table object:

DBCommand.Fill(DSPageData, "Emps")

Next, you initiate a For block that will go from 0 to the total number of records in the DataSet table minus 1. You retrieve the record count in the DataSet Table object through the Count property of the Rows collection:

For I = 0 To DSPageData.Tables("Emps").Rows.Count - 1

Then within the loop you can process each record. You would use the variable "I" to refer to the CU rrent row within the current iteration of the loop:

'Code to process record

lblMessage.Text = lblMessage.Text _
& "
Processed Record: "
& DSPageData.Tables("Emps"). _ Rows(I).Item("EmpID")

You would then move on to process the next record: Next