s that were fixed many years ago in older OSes.
Why hasn't anybody noticed until recently? The Internet is largely a network of Unix computers, so hackers aimed their sights on the thousands of Sun, Hewlett-Packard, and IBM servers on it. NT was largely ignored. Microsoft's marketing juggernaut changed that. The hacker community targeted NT security starting in the fall of 1996, and the rash of security breaches has been relentless ever since.
The shame of it is that none of these threats are new to the security world. Why does an OS only five years old (compared to Unix's 25-year history) have these problems? NT may be another example of the veracity of Santayana's statement that "those who cannot remember the past are condemned to repeat it."
Let's look at NT's security by highlighting some of the breaches, how they work, and what you can do about them.
Denial of Service Attacks
Denial of Service attacks, commonly referred to as DoS, make a machine unusable. They range from shutting services off to blue screen of death (BSOD) attacks to devoting resources to one process and thus depriving other tasks of any sort of sizable time slice. In general, DoS attacks do not require user names or passwords. Instead, they work by combining the inherent weaknesses of TCP/IP and the OS. Let's take a look at four examples: WinNuke, Domain Name System (DNS), Internet Information Server (IIS) 1.0, and Microsoft remote procedure call (RPC).
WinNuke is particularly troublesome. Most of the NT boxes out on the Internet are still vulnerable to this attack. We don't know just who came up with the first example of WinNuke or found the initial problem. Our apologies for not being able to give credit where it is due.The scenario goes something like this.
A cracker makes a TCP connection to a machine running Windows 95 or NT. As soon as the connection is made, and before any regular data is
sent, the cracker transfers a message over the connection with the Out of Band (OOB) flag set. This flag normally signals an application that some information needs to get through right away and cannot wait in the regular data stream to be processed. The paradox here is that there is no data in the regular stream.
In an unpatched or under-patched NT machine, your screen turns a nice shade of blue. You must reboot to clear this problem.
The moral of this example? TCP stacks are not the easiest things in the world to write. Users continue to find bugs in most vendors' implementations. The one stack that is probably closest to being bulletproof is BSD Unix. What's more, the source code for this more robust and quicker stack is free. The only catch is that the license states you must mention that parts of your product were derived from Berkeley code if you use it.
NT also had problems with DNS. DNS is responsible for mapping numbers such as 10.23.143.12 to names such as foo.bar.com. It is in mu
ch need of an overhaul, but it's entrenched in how the Internet works.
The Canadian company Secure Networks found a problem in Microsoft's implementation of DNS. The standard operation for a DNS server is to field queries and send responses or send queries and field their associated responses. What happens when you send a response to a nonexistent query? The DNS server dies, most likely as a result of trying to reference a fictitious ID number in the DNS packet.
IIS 1.0 had a similar problem. All someone with malicious intent or sloppy fingers had to do was request a URL in the form of
http://www.someiismachine.com/../../../.., and the Web server would stop running. An easier way of doing this was simply to telnet to port 80 of the target machine and type "GET ../.." Why did the server die? Probably, this is a case of requesting a file handle, getting a NULL pointer in response, and trying to dereference the NULL pointer.
Finally, and not because we are running out of DoS attacks on
NT, but because we don't want to write exclusively on ways to make your NT network unusable, we have the problem of how a program should respond to unexpected or erroneous input. There are three possible responses to this question: Ignore the input, report the error and terminate gracefully, or act in an undefined manner (the program dies from a segmentation fault or a bus error, munges its stack frame, or sits there spinning its wheels in an endless loop).
We believe most people would prefer either of the first two responses to the third. Unfortunately, however, the last one is what happened to most
Microsoft services
that listened on the network.
Windows NT 4.0 Service Pack 3 fixed the port 80 OOB attack, but crackers struck again. By connecting to port 135 of an NT machine and letting your 2-year-old bang away at the keyboard for a second, you would leave the program previously listening on that port spinning its wheels and pegging the CPU use at 99 percent. Microsoft plu
gged the port 135 hole in one of the 14 patches to Service Pack 3, but there are probably more TCP/IP bugs remaining than we'd care to think about.
Noncaptive Environments
In many situations, it is necessary to give someone or something limited access to your system. It is not necessary for everyone who connects to your FTP or Web server to have access to your main C or D drives. In the case of HTTP servers, all that people will usually need is the document root.
For example, if your Web tree lives in c:\users\web\html and your main page is c:\users\web\html\index.htm, users should be able to request
http://your.site.com/index.htm. Thus, \users\web\html looks like \ to the foreign entity. The same holds true for FTP servers, file sharing, and the like.
In the Unix world, administrators found that you had to double-check to be sure that restricted environments were really restricted. Administrators found this out the hard way and fixed it over time. Now it's Microsoft's turn to learn for itself. It's also possible that Unix vendors had an easier time of it, because the Unix source code they released actually helped hackers find and plug security holes.
In some versions of Microsoft's Web server, FTP server, and file sharing, it was possible to believe you were sitting at \, attempt to go up a level anyway, and magically find yourself outside your restricted environment. Although Microsoft has since patched the flaw, the idea that it could introduce the flaw years after the Unix community identified the problem is troubling.
Privilege Escalation Attacks
ActiveX and Java have provided a wellspring of privilege escalation
attack opportunities
. Some of the most interesting attacks involve the construction of hostile Java, ActiveX, or plain old C++ Trojan horses.
In theory, Authenticode gives a level of protection against Trojan horses. ActiveX controls are signed by certificate authorities and must identify their creators before they
run. You get to decide if the creator should be trusted. Regardless of Microsoft's threats of litigation, however, unscrupulous crackers will still find people to sign their ActiveX controls.
In the ActiveX/Authenticode security model, once a source is trusted, it is always trusted. For example, users who go to Microsoft's Web site are sent a flood of ActiveX controls without warning, because the controls came from a trusted source -- Microsoft. What if a rogue Microsoft employee decided to modify registry settings, plant backdoors for later use, or deposit logic bombs? An example of a rogue ActiveX control, called Internet_Exposure, can be found at
http://www.network-security.com/nt/internet-exposure
.
Déjà Vu All Over Again
