Security Problems .NET Can t Stop

Security Problems .NET Can’t Stop

Security is a problem precisely because it’s a system designed by one person to thwart access to resources by another person. What one person can create, another can just as easily destroy.

Consequently, security is an ongoing process. You need to know the threats your system faces so that you can monitor and protect against them. Although the .NET Framework provides a good basis for building applications with robust security, it can’t protect you from other sources of security problems. The sections that follow detail these security problems. They provide suggestions on how you can use .NET along with other strategies to at least keep problems to a minimum. Make sure you look at Chapter 3 as well because it discusses how you can avoid many of the common errors and traps associated with using .NET as a security strategy.

Stupid User Tricks

You’ve likely seen all of the jokes, heard all of the stories, and seen some of user-related problems yourself. The most horrid stories I’ve read recently appear in an InfoWorld article entitled “Stupid User Tricks.” One is about a traveler who had taped both the dial-in phone number for his server and his password to the outside of his laptop carrying case. (See http://www.infoworld.com/article/03/01/24/030127Security_1.html for details.) Finding plenty of horror stories is never a problem—solving the security issues users create is another story.

After 17 years of consulting, one of the first security scans I perform at a client site is to check the computer, the desk and surrounding area for pieces of paper with passwords on them. Invariably, I usually find at least one piece of paper with not just one, but several passwords on it. The passwords aren’t even hard to figure out. It almost seems that the user is determined to make it easy for the janitor to make off with all of the company passwords.

To an extent, the .NET security features can help overcome problems users create. No, it won’t automatically detect Post-it notes placed on the monitor, but it does ensure that the user doesn’t gain rights to resources by using code incorrectly. Code access security helps in this regard. For example, when a user requests access to a file, the user’s rights are checked and the rights of the code are checked. If either check fails, then access to the file fails. Chapter 4 discusses code access checks in detail.

Training, well-written policies (instructions for handling various security situations), and rules (requirements that everyone must meet) with some teeth in them can also help with user security problems. However, this is one area where you’ll continually have problems because people will normally find a way around rules that are inconvenient. The .NET Framework can help here as well. You can write code in such a way that the network administrator controls security policies, not the user. This technique makes it possible for the network administrator to monitor problems and ensure your program has a reasonable chance of maintaining a secure environment.

It’s also important to know how to set the security policies for your application using .NET Framework features. Chapter 5 discusses policies and code groups in detail. While the techniques in this chapter won’t fix every user problem, they at least make it harder for someone to destroy the security of your system by accident.

Some External Forces

Most people associate external forces that threaten security with crackers. This group does receive a lot of attention from the media, which is why they’re the group that many programmers consider first (and perhaps last). While crackers do cause a great many problems, they aren’t the only external force to consider.

Employees on the road or recently let go from the company can cause a great deal of harm to your applications. The problem is twofold:

• Using the old Windows security system, an application might execute at the same privilege level whether the employee accessed it from a desktop or a remote location. The .NET Framework takes this issue into consideration by adjusting the rights of an application based on the zone in which it executes.

• An employee is much more familiar with the security setup and organization of your system than any cracker. Unfortunately, this is a problem that .NET can’t help you solve. Someone determined to break into your system is almost certainly going to do it. The only way to overcome this problem is to constantly monitor the system.

Other programs can also affect your application—at least if it’s a Web-based application. In a day when distributed applications can rely on services that your program can provide, it’s possible that some other programmer you’ve never met will cause a security problem on your system and not even realize it. The .NET Framework helps you solve this problem by adhering to standards-based security. New standards such as WS-Security and WS-Inspection make it easier to write programs that will work across platforms and provide a secure environment. You can learn more about these standards at Web Services Specifications site (http://msdn.microsoft.com/library/en-us/dnglobspec/html/wsspecsover.asp).

Inept network management can also cause serious problems. A network administrator could restore old policies to a server or overwrite the recently patched files for your application. Newer versions of Windows have some protection for both of these issues. For example, Windows File Protection can help ensure only the latest version of your files remain on disk. The .NET Framework also helps by making version checks before it loads files and executes them. An overwritten file would have the wrong version number and .NET would display an error indicating this fact. This fix may not make the user very happy, but at least you’ll know the cause of the problem. Chapter 6 tells you more about validation and verification issues.

Another source of external problems is the connections you create with other businesses. Distributed applications are becoming more common as companies invest more in Web services. The problems with distributed applications are many and you can’t expect the .NET Framework to solve them all. However, in Chapter 9 you learn how to protect the .NET-specific areas of a Web server. Chapter 10 shows how to protect .NET application generated data. Finally, Chapter 11 demonstrates methods for protecting the connection between a partner and the organization when using a .NET end-to-end solution. Many of the strategies hinge on standards-based application development such as using the WS-Security standard for your application.

Wireless devices present one of the most prevalent and least understood security problems for developers today. Some wireless networks aren’t secured at all. Anyone with the proper equipment can come along and access the network from outside the company. Some people are using this technique to spread illicit e-mail using company Internet connections without anyone knowing. The .NET Framework can’t do anything about this kind of security problem. However, once you have some basic security in place, Chapter 13 can show you how to make best use of the features the .NET Framework does provide for security of wireless application communication.

Something’s always attacking your data, even nature. Fortunately, keeping your data safe, or at least knowing when someone has tampered with it, is relatively easy because this is an area where security professionals have spent a lot of time. First the bad news—if you have any kind of data transfer at all (even on a LAN), be prepared for situations when that data is compromised. The good news is that the .NET Framework uses the latest technologies to secure your information. Chapter 7 discusses cryptographic techniques.

Poorly Patched Systems

Patches are problematic no matter how you look at them. First, there’s the problem that the existence of a patch tells many users that the program wasn’t well tested, so it failed in use. This perception is fueled by the media in many cases. In fact, the perception is warranted, in at least a few cases, because the product was rushed to market. However, perceptions aside, even if the program has bugs that will cause security problems, the user of that program has to be encouraged to apply the patch to fix the problem.

Second, there’s the issue of compatibility. Some patches actually cause more problems than they fix by creating compatibility problems or introducing new problems onto a system. Consequently, many administrators set up test systems to check the patch for problems before they install it on their production system. Extensive testing means the production system is vulnerable longer—perhaps encountering a security problem while it waits.

Although these issues are probably not going away any time soon, you still need to patch your system to ensure it has the latest security features and that any security holes are fixed. You need to consider the results of not patching your system at all and how it will affect any programs you produce on the system. With this in mind, you’ll want to use three tools to check your system for problems before you begin developing a new program.

Windows Update Always check Windows Update to verify the status of any patches for your system. Windows Update works automatically. All you need to do is select the updates you want to download. The one mistake that some developers make is not reading the information about a patch before they install it. Sometimes this leads to problems on a development machine. You can find Windows Update at http://windowsupdate.com/.

Microsoft System Update Services (SUS) Microsoft SUS can reduce the bur- den of updating multiple machines for a business. This system helps you download and distribute updates in a safe environment. Learn more about this product at http://www.microsoft.com/windows2000/windowsupdate/sus.

Microsoft Baseline Security Analyzer (BSA) Windows setups can become quite complex. It’s easy to miss an update when you have multiple pieces of software to consider. Add to this problem, the issue of individual driver updates, and security can become a considerable problem. The Microsoft BSA won’t solve all of your problems, but it can help by providing a comprehensive list of problems within a system. Learn more about this product at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/Tools/MBSAhome.asp.

All of these update tools should tell you something about your own programs. When I start the Acrobat Reader, it automatically asks if I want to scan for the latest updates. Other programs on my machine are starting to do the same thing. The .NET Framework provides more version checking features than the Win32 API ever thought about providing. The goal of these features is to prevent problems such as DLL hell, an issue that still plagues Windows systems. You can easily use version checking to provide update checking for your application. (Make sure you still give the user the choice of actually installing the update.)

Inept Enterprise Policies

I actually knew of a business that had a policy in place that made every network user an administrator. It was a moderately sized business that lacked a real network administrator. The person who was supposed to administrate the network was simply too lazy to set up the required features and didn’t want to hear a lot of user complaints about not being able to access a particular file or feature. That business may still be around, but I found it quite easy to leave before the inevitable security bomb exploded in someone’s face. Fortunately, not every business has a policy as absurd as this one.

Setting enterprise policies is one case when the .NET Framework might actually increase the number of security problems your application will have to face. Microsoft assumes that every network administrator is faithful, loyal, hardworking, conscientious, and knowledgeable. The .NET Framework is set up to ensure the network administrator has maximum access to security features. Unfortunately, some network administrators just aren’t up to the task and you’ll have to find ways to overcome this problem.

Training is one way to help network administrators fulfill their new role with the applications you create. Many will find it quite surprising that they can control who uses a particular function within your components and specific features in an application. Chapter 4 shows you other techniques to work around this problem. The best strategy is to effectively use imperative and declarative security in your applications to ensure they maintain some level of security even if the network administrator doesn’t do anything at all.

Enterprise policies are affected by the environment. A well-maintained domain setup is more secure because the policies are set on the server. Even if the user moves to another machine, you have some assurance that your program will have the proper security and work as anticipated. Unfortunately, the alphabet soup of technologies used for LAN-based applications today makes security difficult (perhaps impossible). Chapter 8 shows you how to get around some of the problems with LAN security. This chapter is an open view of what .NET can do for you and more important, what you still need to tackle using other technologies.

Problems begin with local security policies because they’re often implemented unevenly and the rights don’t move with the user. Code access security ensures that a rogue program can’t make use of this scenario to circumvent security. You can also validate the user, computer, and other data using Active Directory. Chapter 12 discusses how you can use Active Directory to reduce some of the local security problems an application will encounter. It also demonstrates techniques for working with Active Directory security information.

Distributed applications are notorious for opening security holes because these applications make resources that are normally hidden visible to users through an Internet connection. It’s amazing that some companies don’t have security policies in place to protect from these problems. What’s even more amazing is that a few companies actually end up opening new holes in their firewall and other security features to enable an application to work. For example, some companies still rely on Distributed Component Object Model (DCOM) applications to create distributed applications. The .NET Framework isn’t the only solution at your disposal, but by using modern Web services techniques, you can greatly reduce the risks distributed applications impose.

One of the most interesting security problems is one in which a company follows all other best practices, but then fails to lock the computer up so that no one can access it physically. If someone can gain physical access to a server, they can control the server in a relatively short time. A worst case scenario occurs when the company not only leaves the computer in the open, but thoughtfully provides a monitor and keyboard so that anyone entering the room can modify the server setup. Although the best policy is to lock the computer up, there are alternatives if you must keep the computer in plain view. For example, you can add physical locking to the system. The World of Data Security (http://www.crocodile.de/) provides a number of specialized computer-locking mechanisms that make physical access a lot more difficult.

Windows File Protection Vulnerabilities

Windows File Protection is thought to be a safe way to install executable files on a system because those files are supposedly signed. Unfortunately, there’s a well-known method to create files that Windows File Protection will trust even if they aren’t signed by an appropriate digital certificate. You can read the detailed version of the problem on the Bugtraq site at http://archives.neohapsis.com/archives/ntbugtraq/2002-q4/0122.html. A Microsoft security bulletin on the topic appears at http://www.microsoft.com/technet/security/bulletin/MS00-072.asp.

The interesting thing about the .NET Framework is that it doesn’t rely on this security mechanism. When you sign a control, component, or application, the signature is verified by the CLR. The signature uses a hash mechanism that exists outside the Windows File Protection environment, so the security of the file is ensured. You can always check the token used to secure a file with a strong name that’s contained within the Global Assembly Cache by viewing the content of the \WINDOWS\assembly folder. Figure 1.2 shows a typical example of the content of this folder.

Figure 1.2: Managed files use a unique signature system that ensures their integrity.