Hackers Beware

On the other hand, if only a few people have root access, an administrator can quickly scan and detect unauthorized root access

Summary

As you can see, password security is critical, no matter what operating system you are running. It is important to remember that the tools discussed in this section for password cracking are not just for attackers to use. Many administrators are afraid or get upset when they run across these tools, only seeing the negative aspect.

The positive side of using these tools is that they can be used to protect your site and should be embraced if they are used properly. If an administrator runs cracking programs on a consistent basis and uses them to increase the security on his site, the usefulness of these tools to an attacker decreases tremendously. Therefore, it is imperative that you not only understand what tools are available, but also use them, especially when it comes to password security

Chapter 11. Fundamentals of Microsoft NT

Before you go to the next chapter, where we cover a detailed discussion of specific NT exploits, how to detect them on your network, and how to protect against them, it is important to lay the groundwork for how NT works. This chapter starts with an overview of NT exploits highlighting some similarities between the exploits and emphasizing some issues, which lead to the fairly high number of vulnerabilities. It is important that you understand the general concepts of why there are vulnerabilities and how they work, so you can better protect your system.

No single book could list every vulnerability and every step you need to take to protect your system. This book tries to give you enough details so that when you are protecting your systems, you can address the problem areas. This way, when a new exploit comes out, your potential damage is minimized. This chapter gives you a basic understanding of NT, so that not only the exploits in the next chapter make sense, but also you understand what can be done to secure NT.

After an overview, we will then look at some fundamental concepts that are needed to understand NT exploits, which will be covered in Chapter 12, “Specific Exploits for NT.” NT has so many features that even the most proficient users still discover features or tools that they did not realize existed. This chapter will look at these features from a security standpoint and make sure you understand and concentrate on the right aspects needed to protect your systems. So many think they understand NT, but do not understand NT security, because NT from a server standpoint and NT from a security standpoint are two different things.

There are entire books written on NT and NT security, and this chapter is not meant to replace those books. Its purpose is to give you enough understanding of how the exploits work, and the right features and tools that are needed to secure your systems

Overview of NT Security

There is a great deal of criticism for NT, highlighting its high number of security vulnerabilities. Yes, NT has made some mistakes that lead to the high number of vulnerabilities, but you also have to put them in perspective considering the functionality and the length of time NT has been around.

NT has been around a shorter time period than UNIX, so it is natural that UNIX is a more mature operating system. The other benefit UNIX has is it matured over a longer period of time, when networking and the Internet were not as popular as they are today, so issues could be resolved before they turned into major problems.

Today, with such a large install base of NT and the type of mission-critical systems it is running, even minor problems can have a major impact from a security standpoint. Keep in mind that NT is a fairly new operating system and will continue to have security vulnerabilities. If you run NT, you have to make sure you understand it from a security perspective and stay on top of the issues so that your company can be secure.

Another security issue with NT is the size and features of the operating system. For those of us who write code, we know that there is a direct correlation between the features of a piece of software and the number of lines of code. The more features you add, the more code is needed to support these features. There is also a correlation between the amount of code and the number of bugs that are in the code. As the size of the code increases, the chance for unforeseen issues to appear in the code also increases.

When you have a program that is as feature rich as NT, which leads to a large amount of code, it is only natural that there are inherent bugs and

security vulnerabilities in the code. From a user’s perspective, the trick is to configure the system in such a way as to minimize the effect it could have on your company. It is also important to point out that Microsoft made some design decisions that affected the overall security of the operating system. For example, it put the GUI and user interface code at the kernel level, making it more vulnerable to attack.

Unfortunately, things do not get better from a security standpoint. Another key aspect when looking at code is not just the amount of code, but the time in which it was developed. The more time you have to develop a system, the less bugs there will be in the code. This is based on the fact that you will have more time to do a proper design, think out the problem, and, most importantly, test the code. In most cases, when deadlines are moved up and there is less time to develop a system, testing is what is sacrificed. If the developers cannot test the system properly, in essence, they are letting the consumers of their product test it; and when their consumers find bugs or security vulnerabilities, the developers will fix them. With a lot of software, what was considered a beta release five years ago, is the final release today.

Also, vulnerabilities are introduced when Microsoft tries to make software downward compatible with earlier versions of the operating system. Features that might have been considered secure 10 years ago are no longer considered secure, but are still included in the operating system. A perfect example of this is the LAN Manager password hashes that were covered in detail in Chapter 9, “Microsoft NT Password Crackers.”

Lack of error checking is another result of today’s added functionality and less time built in to develop. Normally when you write code, whenever data is passed into a program, it should be validated to make sure it adheres to what the program is expecting. If you were writing a program that prompts the user for two numbers and adds the numbers together, you would want to check the input and make sure it is two numbers. If the user enters a letter, the program should discard the data and print a message to the user saying, Please enter a number from 0-9. If you trust the user to do the right thing, the program will still work properly, even if error checking is missing, which is scary.

Based on the time factor, most code (and NT is no exception) is developed so quickly that error checking is either ignored or done poorly. By doing this, the developers are saying that they trust anyone who will use the software to do the right thing, therefore believing that they are secure. History has shown that this type of reasoning will get you into a lot of trouble. Interestingly enough, most NT exploits are allowed by poor or non-existent error checking. If proper error checking were performed on all data, a lot of the security vulnerabilities would go away. Keep this point in mind when you go through the NT exploits and consider error checking.

Let’s briefly look at a simple exploit: the land attack. The land attack crashes a machine by setting the source and destination IP address to the same value and the source and destination port numbers to the same value. (For additional information, this exploit is covered in detail in Chapter 6, “Denial of Service Attacks.”) This is a fairly simple attack, but it is possible because proper error checking is not performed. If error checking is performed to validate that the source and destination IP addresses and the source and destination port numbers are not the same, and if the packet is discarded, this problem goes away. This is very simple error checking, but because it is not done, it can cause a lot of problems by crashing and causing a Denial of Service attack against a large number of networks.

Now that we have looked at some of the reasons why NT has so many exploits, let’s take a look at why it is a big target for attackers.

Availability of Source Code

The easier it is to do something, the more people there are who will do it. For example, if there is an exploit that takes 20 hours to run with a high amount of expertise and another one that takes five minutes to run with minimal expertise, and they both have the same effect, most attackers will choose the one that takes a shorter period of time. It only takes five minutes to run and is easier to use; therefore, more attackers can take advantage of it. The easier it is to install a program and run it, the higher the chance that more attackers will use the program.

Based on the preceding information, another important factor that contributes to why NT gets a lot of publicity and broken into a lot has to do with how the source code for the exploit is distributed. In most cases, NT exploits are distributed by allowing people to download the executable program that has an easy-to-use GUI. This makes it trivial for anyone to run the exploit. If you can use a mouse and surf the web, you can download one of these programs, double-click on the icon, and run the exploit. This makes it easy for anyone with minimal knowledge to attack or take down an NT machine.

On the UNIX side of the house, most vulnerabilities are distributed via source code. This means that a potential attacker has to download the code, install a compiler on the system, customize the code for the target system, make sure the proper libraries are installed, and compile the code. Some programs come with make files, which makes this easier to do, but the bottom line is it requires more work and expertise.

Let’s take a look at the source code versus executable problem. The following is the source code for the WinNuke exploit, which we learned about in Chapter 6 when we covered Denial of Service attacks:

#!/usr/bin/perl use IO::Socket; IO::Socket::INET

->new (PeerAddr=>"some.victim.com:139") ->send("bye", MSG_OOB);

Figure 11.1 shows the executable version of the same exploit.

Figure 11.1. GUI for the WinNuke exploit.

Even if you have a high level of expertise, the pre-compiled executable with the easy-to-use interface is much easier to run than the source code that must be compiled and run from a terminal window. With WinNuke, you just type in the address and message, and you can launch an attack just like the professionals. With NT, most of the executables run in nice GUIs, which makes them simple for anyone to use.

To summarize, there is a twofold reason why there are so many security issues with NT. The first has to do with how the program is developed. It is developed under a very tight deadline with a lot of functionality, which means it is not properly tested, and error checking is usually ignored. The second reason is the attacker community makes it easier for others to attack NT machines by distributing exploits in easy-to-run, pre-compiled formats.

Now that you have a good understanding of the issues pertaining to NT vulnerabilities, we will lay the foundation for understanding the exploits by covering some of the main features and security tools of the NT operating system.

NT Fundamentals

In this section, we will look at some of the core concepts of NT that will help you understand how the specific exploits work and are needed to properly secure your systems. Remember, the point of this book is not to

show an attacker how to break into systems, but to show you how attackers break in. You can use this knowledge to secure your systems and minimize the damage that an attacker can cause. To protect your systems, you need an understanding of how NT works and some of the tools that are available to secure your systems.

The following are the main areas that we will cover in this section:

•NT under the hood

•Physical security

•Registry

•Services running

•Account manager

•Network settings

•Auditing

•NetBIOS

•Service packs

•Resource kits

•Hardening guides

NT Under the Hood

We are going to take a look at some of the design components of NT and how the operating system is put together. NT is the synthesis of several different operating systems that came before it. In some cases, NT developers did things right, and in other cases, they did things wrong. This is natural—after all, there is no such thing as a perfect operating system. Figure 11.2 shows the general design of the NT operating system.

Figure 11.2. General design for the NT operating system.

The key about NT is that there are two basic modes: user mode, which is very restricted, and kernel mode, which allows full access to all of the resources. Therefore, it makes sense that most programming (besides system level programming) be performed in user mode. This prevents a rogue program from taking down the system. As you will see in the next chapter, there are some weaknesses that allow exploits to do things they should not and cause problems for the operating system.

It’s important to mention that the Intel 386 and later chips provide a ring architecture that provides hardware support for distinguishing between user mode and kernel mode. Therefore, Microsoft hasn’t taken full advantage of this architecture for security of the operation system.

One question you might be asking is this: If programmers are supposed to operate only at the user mode, doesn’t that limit the functionality and power of the programs, because there are cases where someone would want to access the Kernel? In these cases, there are APIs, or application programming interfaces. APIs are gateways that programmers use to allow them to make calls to the subsystem, which in turn makes calls to the Kernel. Because these APIs were well thought out and carefully tested, they give the programmer the access he needs, while limiting the potential damage they can cause.

Now let’s briefly look at each piece of the kernel mode. The hardware abstraction layer (HAL) is the piece that directly interacts with the hardware. This allows NT to run on different hardware platforms like Intel and DEC ALPHA. If the system weren’t designed in this fashion, the entire system would have to be rewritten for new hardware. Because of the HAL,

only this piece has to be rewritten for a new hardware platform, which allows it to be ported fairly quickly.

The Kernel is an integral part of the operating system, and it gets its configuration from the Registry, which we will cover in the upcoming section, “The Registry.” This is one of the reasons why the Registry is so critical, because if it gets corrupted, the Kernel cannot load, which means the operating system cannot run. The Kernel is responsible for the core aspects of the operating system, including the scheduling, interrupt handling, and multiprocessor support.

The NT executive uses the services of the two layers below it—the Kernel and the HAL—to provide its services. Some of the services it provides are handling input and output, device drivers, and the files system. It also acts as an interface between the user mode processes and the kernel mode processes.

Physical Security

Before any of you try to harden the software, the server’s physical location and security must be addressed. Even with every hardening script run and the tightest policies applied, if an attacker can gain access to the machine’s console, all of those security measures are erased. All servers should be kept in a central location in a secure, racked environment. Access to the room that houses those racks should be strictly controlled and monitored. The racks should be locked with the key given to only a select few individuals. By following these basic measures, an administrator can assure that unwanted users do not have access to the console of the servers. Remember, if an attacker can get access to the physical server, he can always boot into another operating system (like Linux) off of a floppy and have full control of the system.

The Registry

The Registry is basically the brains of NT and therefore is critical to the security of an NT system. It is a large database that contains information on how the operating system should function, how it should operate under certain conditions, and lots of other information that is needed for NT to work properly. If an attacker goes in and modifies some values in the Registry, the operating system can stop working. The only way to fix it is to reinstall the operating system or boot with an alternate kernel or from a different device and restore a backup of the Registry. This shows you how critical the Registry is to the successful operation of NT and to the security of NT. The Registry is set up in a directory-like structure, which contains keys that contain a value that tells the system how it should perform.

To better understand how the Registry works, let’s take a look at an example. When you perform a default install of NT workstation and you press the Ctrl+Alt+Del keys to log on to the system, the shutdown key is active and can be used to shut down the system before you ever log on; however, on the NT server, it is grayed out, which requires you to log on before shutting the system down. The Registry controls this functionality, and there is a Registry setting that determines whether the key is grayed out. The key is HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ ShutdownWithoutLogon. Figure 11.3 shows a graphical version of the same key.

Figure 11.3. Accessing a Registry key through the Registry Editor.

This figure also gives you a better idea of the layout of the Registry. If you know what you are doing, you can go in and modify keys, add keys, or even delete keys from the Registry. As you can see, the format for each key is the name, followed by the data type, followed by a value. The following are the data types and format of each type:

REG_SZ text REG_EXPAND_SZ text

REG_MULTI_SZ "string1" "string2" ...

REG_DATE mm/dd/yyyy HH:MM DayOfWeek REG_DWORD numberDWORD

REG_BINARY numberOfBytes numberDWORD(s)...

REG_NONE (same format as REG_BINARY) REG_RESOURCE_LIST (same format as REG_BINARY) REG_RESOURCE_REQUIREMENTS (same format as REG_BINARY)

REG_RESOURCE_REQUIREMENTS_LIST (same format as REG_BINARY)

REG_FULL_RESOURCE_DESCRIPTOR (same format as REG_BINARY) REG_MULTISZ_FILE fileName

REG_BINARYFILE fileName

If no value type is specified, the default is REG_SZ.

Now that you understand what the Registry is, let’s take a look at how you access the Registry. The main way you access the Registry is with a program called REGEDT32.EXE, which is located in the winnt/system32 directory on your hard drive. When you double-click on the REGEDT32.EXE icon, Figure 11.4 is displayed.

Figure 11.4. Main screen for the Registry editor.

As you can see, the Registry is organized in a hierarchical fashion. There are the main sections that start with HKEY like HKEY_USERS, HKEY_LOCAL_MACHINE, and HKEY_CURRENT_USER. Then, each window has a tree structure with directories embedded within directories, and some directories have keys with values. Figure 11.5 shows two examples of this.

Figure 11.5. Examples of using the Registry Editor.