Become a hacker's worst nightmare proactively protect your NT network

In the past, some users considered Windows NT to be bulletproof because no one had publicly revealed any of the various ways to break NT's security. But let's face the facts: NT isn't even close to being bulletproof--nor is any other commercial mainstream operating system.

Hackers are discovering security holes in NT at an alarming rate. Since March alone, they've found more than 20 new holes in NT or an associated application. And you can expect this rate to climb because former UNIX-only hackers are now turning their attention and expertise to NT. As one notable hacker recently said, "NT is sexy and attractive to hack."

More Than One Way to Protect Your OS
One way to protect NT against hacker attacks is to load the latest Service Pack (SP) and the associated hotfixes as Microsoft releases them. However, this solution will work only if you can load the current SP without breaking NT. SP2 is a perfect example of how an SP might render NT useless in one fell swoop, turning a seemingly harmless upgrade into an adventure in recovery. (For an illustration, see Mark Minasi, "Recovering from a Network Disaster," March 1997.)

In addition, SPs and associated hotfixes aren't always timely and effective. For example, to combat an attack called GetAdmin, Microsoft developed a post-SP3 hotfix, but by the time Microsoft released it, hackers had devised a new way to perform the same exploit. So Microsoft released an updated hotfix the following week. The second hotfix stopped the GetAdmin attack, but it didn't prevent a similar attack from crashing an NT system. (For more information about Microsoft's reaction to security holes, see "Microsoft Needs a Different Approach to Security Risks")

So what if you can't load the latest SP or hotfixes or you want to intensify security? If you study the nature of a given exploit, you can discern ways to protect your NT network without relying on Microsoft to deliver a patch. But protecting your network without a vendor's help requires basic knowledge of TCP/IP and NT architecture and operation. So if you're unfamiliar with how TCP/IP traffic works, what packets look like, and how NT handles security, you need to learn about TCP/IP and NT first.

Avoid Dangerous Attacks
As I mentioned, hackers have exploited more than 20 security holes in NT and associated applications since March. I'll go over some of the more dangerous attacks and how to prevent them without the use of SPs and hotfixes. To give you an idea of just how fast new problems are surfacing, I'll include (in parentheses) the month the risk was revealed to the public and the NT systems affected. Some security risks reside in applications and not the NT OS. These application-based risks are NT security risks because they pose an inherent danger to overall network security.

Bandwidth hogging with chargen (July; NT 4.0 Server and Workstation)
A hacker can launch a bandwidth-hogging attack by sending User Datagram Protocol (UDP) packets to the subnet broadcast address (X.X.X.255) using chargen port 19. In most cases, the hacker also falsifies the source IP address. Once the hacker launches the attack, every NT machine on the network responds to the broadcast, which creates a flood of UDP packets that eat up network bandwidth. The more NT systems you have on the network, the worse the packet flood becomes.

Preventing this attack is easy: Disable the chargen service. You use the chargen service only to generate a steady output of characters for testing purposes, so disabling it doesn't affect network performance.

To stop the chargen service, disable the Simple TCP/IP Service in the Control Panel, under Services. This step not only disables the chargen service, but also the echo, daytime, discard, and quote-of-the-day services--any of which hackers could use for the bandwidth-hogging attack. Although none of these services is required for proper network operation, you might find a particular service useful. For example, you might want the echo service operational if your network monitors occasionally test the echo port when they cannot get a response to a ping. You can run one or more services while turning the others off by adjusting the Registry entry found in the subtree HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SimpTcp\Parameters. To disable a particular service, change the established value of both the EnableTcp XXXX and EnableUdpXXXX parameters (where XXXX is the service name) from 0x1 to 0x0.

Gaining administrator access with GetAdmin (July; NT 4.0 Server and Workstation)
A Russian programmer discovered and revealed the GetAdmin attack. It is one of the most important discoveries in NT security breaches because it is the most commonly used attack against Windows OSs. The attack comes in the form of a program that, when run, adds any user to the Administrators group.

According to Microsoft, a hacker needs direct access to the NT system's keyboard and console to launch the GetAdmin attack. But if a particular NT system is running a Web or Telnet server, a hacker can use a remote Web browser or Telnet client to launch the attack.

You need a combination of tactics to prevent the GetAdmin attack. Start by protecting access to the local console. First, adjust the User Rights so that only trusted network administrators can log on to the local console. Second, never assign a user the right to debug a process unless absolutely necessary.

To prevent a remote GetAdmin attack, don't let users place unknown or untested programs in a Web server's /scripts directory. If you can't analyze and compile the source code, don't use the program. Furthermore, providing Telnet access to an NT system is extremely risky, so don't permit access.

Fragmenting with POD 2 (June; NT 3.51 and 4.0 Server and Workstation)
The Ping of Death (POD) 2 attack is a variation of the previously discovered POD 1 attack. Both versions involve sending Internet Control Message Protocol (ICMP) packets to an NT system. These packets fragment, causing the NT system to lock up. Whereas POD 1 sent one 64KB ICMP packet, POD 2 sends a barrage of 64KB ICMP packets. The barrage of packets causes Win95 and NT systems to lock up cold without warning.

Preventing this attack involves blocking all inbound ICMP traffic on your routers to bordering untrusted networks. If you use Remote Access Service (RAS) instead of a router, install the newer Routing and Remote Access (RRAS--formerly Steelhead) software. With RRAS, you can establish a packet filter that permits access to only the necessary ports, such as those used by Web and mail servers.

Denying service to Internet Information Server--IIS (June; IIS 2.0 and 3.0)
Hackers can crash IIS by sending abnormally large (4KB or more) universal resource locators (URLs) to the server. According to Microsoft, this attack is a very specific boundary condition that occurs during parsing of the headers. The end of a token (method, URL, version, or header) must be exactly at 8KB, followed by a second token. The maximum header buffer for IIS is 8KB; IIS throws out anything beyond that limit as an invalid request. In this scenario, an index gets misinterpreted as a pointer that, in reality, doesn't exist.

Preventing this attack without a hotfix might be next to impossible. Some experts theorize that an Internet Server API (ISAPI) filter could be written to intercept such a long URL, but no one has written and released such a filter yet. On the bright side, this attack is difficult to launch successfully because each IIS server requires a slightly different URL length to make it crash. However, a sly programmer could write code that would continually try various URL lengths until IIS crashes. So if your Web server is exposed to the Internet as a matter of convenience and not necessity, I highly recommend disconnecting it from the Internet unless you can load the hotfix.

Denying Service to Domain Name System--DNS (May; NT4.0 with DNS)
Hackers can make DNS crash by redirecting the output of the chargen service to the DNS service. They launch the attack using a command such as

$ telnet ntbox 19 | telnet ntbox 53

This UNIX command first opens a Telnet session on chargen port 19 on the system named ntbox. The command then redirects all output to a second Telnet session opened on DNS port 53 on the same ntbox. This setup creates a never-ending loop of meaningless data flow, which crashes the DNS service. Launching the attack, however, can temporarily subject the hacker to the same barrage of packets that the DNS service will experience.

One way to prevent this attack is to disable the chargen service. You can disable it using the procedures I outlined in the bandwidth-hogging exploit.

Exposing passwords with the Index Server (May; NT 4.0 Server and Workstation with IIS)
The Index Server (formerly code-named Tripoli) is Microsoft's search engine for IIS. Although the Index Server is a useful search tool, a danger lies in its webhits.exe program. This program highlights those words used in the search query in the retrieved documents, but it also, unfortunately, lets the Web server read files that would not ordinarily be available for reading. If the systems administrator leaves the default sample files on IIS, an intruder can quite easily narrow down the search for a username and password.

To prevent this attack, you can remove the webhits.exe program from the server. Another approach is to move the webhits.exe program out of the server's default installation directory and into any other directory. However, this approach will only make locating a username and password more difficult for the intruder. In addition, you can customize your Index Server search pages and scripts (.idq files) so that the .idq files search only those pages you want searched, such as .htm or .html files.

Sending out-of-band data (May; NT 3.51 and 4.0 Server and Workstation)
Although Microsoft publicly announced the existence of the out-of-band attack in May, certain Internet circles have known about it for more than a year. Internet Relay Chat (IRC) users often use this attack against other IRC members, making it the second most commonly used attack against Windows OSs.

To launch this attack, hackers send out-of-band data to port 139 (the NetBIOS session port) or another port. The OS doesn't know how to handle the out-of-band data, so it crashes. NT then displays the infamous Blue Screen of Death, identifying TCPIP.SYS as the culprit.

Preventing this attack is difficult because hackers can send out-of-band data to one of many ports. The most popular is port 139, but even sending out-of-band data to DNS TCP port 53 can cause the DNS server to crash. I recommend that you block access to UDP port 137, UDP port 138, and TCP 139. You can block access by using RRAS packet filtering technology, by taking advantage of NT's built-in TCP/IP filtering security, by unbinding NetBIOS from your network cards exposed to the Internet, or by blocking access to these ports on your routers to bordering untrusted networks. To prevent this attack from being launched against a DNS server, don't run DNS. Instead, use a DNS service based on a Berkeley Internet Name Domain (BIND) port for UNIX (such as MetaInfo's MetaIP) or BIND port for NT.

Accessing a Registry with RedButton (April; NT 4.0 Server and Workstation)
Midwestern Commerce released an example program called RedButton that demonstrates a vulnerability in NT. The program lets anyone with Microsoft networking access to an NT server connect to that NT system and read the Registry. RedButton reveals the resources available to the Everyone group, determines the name of the built-in Administrator account (even if it has been renamed), reads various Registry entries (revealing the registered owner's name and other information), and lists all shared resources (including hidden shares). In short, RedButton divulges sensitive information about an NT system.

To prevent RedButton or similar attacks, you need to block access to UDP port 137, UDP port 138, and TCP port 139 on your routers to bordering untrusted networks. To block access, follow the same recommendations I gave in the out-of-band data attack. You can also stop the Server service, but your NT box will be unable to share resources.

Another possible solution is editing the Registry, using regedt32.exe. To edit the Registry, you first need to open HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers and create a key called winreg if it doesn't already exist. Next, set the security on the winreg key so that the Everyone group access is not listed. You might want to list, for example, the Administrator group instead. (Do not define the Everyone group with the NO ACCESS privilege. This privilege locks out all accounts.) Then close the Registry editor and reboot the system.

As these examples show, you can usually prevent even the most dangerous attacks on your NT system. You just need to learn exactly how the attack assaults NT and then look for ways to prevent it, such as blocking ports and changing user permissions. With practice, you'll become adept at keeping unwanted visitors out of your NT network.