NT Security Scares?

No need to panic
The sky is falling! The sky is falling! The sky is--oh, whoops, sorry. That was a raindrop. Well, it's almost the same, isn't it? You'll think so if you listen to the current gang of so-called NT security experts, each trying to out-do the other in proving that NT's security has more holes than a bowling ball factory.

If you're an NT administrator or a network security officer, no doubt higher-ups have asked you in baleful tones, "Are you sure it was a good idea to use NT? Hardly a day goes by without another security hole discovery!" If you're having a rough time answering that question, read on.

As more people use NT, they'll examine more and more of NT's nooks and crannies, leading to the discovery of more and more bugs. Some discoveries will be genuine security bugs, worthy of fear and reaction. But I haven't seen one yet. Bear in mind that although I'm no security expert, I have been running PC networks since 1985, so I've picked up a few lessons along the way. One article doesn't give me enough space to consider all aspects of NT security, but I can take up most of the big scares.

SCARE NUMBER ONE:  NTFSDOS
One of my fellow Windows NT Magazine contributing editors, Mark Russinovich, wrote a program, NTFSDOS.EXE, that occasioned the spilling of much ink (see "NTFSDOS Poses Little Security Risk," September 1996). Mark's very clever program lets you read NTFS volumes from DOS: You can go to an NT machine containing one or more NTFS volumes, boot DOS, and run NTFSDOS. You'll see the NTFS volumes, which now show up as regular drives. You can read the volumes, not write them.

Some people claim this program reveals a chink in NT's armor. They claim that previously they could format their server drives to NTFS and know that file and directory permissions would keep the casual user or hacker from coming up to the server, booting DOS, and having full access to the data on the drives.

I don't understand why this scenario is a problem. To use NTFSDOS, an intruder must have physical access to the server (that is, shove a bootable DOS floppy into the server's A drive). But is why would just anyone be able to walk in off the street and reboot a server? One of the first lessons I learned in PC networking was that unless you physically secure servers, you don't have security.

I'm amazed to see companies with swipe cards and security guards, offsite backups, and hot-start sites protecting their mainframes but doing nothing for the LAN servers. "So, where are your servers?" I once asked a client.

"In Scott's office," he replied.

"Does Scott's office have a lock on the door?" I wondered.

"Well, sure." came the answer. "But those servers keep it pretty warm, so I think he keeps the door open most of the time."

Walking into Scott's office, I saw that the servers were in max-height towers, and the towers were on the floor, where the vacuum cleaners could give them a little whack now and then. Several bookshelves piled high with backup tapes were mounted above the computers.

"So," I wondered aloud, "when the servers catch fire, the backups can go as well?" The clients looked sheepish and admitted they needed to move the backups somewhere else, but they just hadn't had the time.

The biggest problem with security is that we know what we're supposed to do, but we forget to do it or we're just too busy. (And I'm no exception, as I detailed in "Recovering from a Network Disaster," March 1997.)

Advice: Think Nike: Just do it. Control access to the servers. Whatever you do on the mainframes--disaster recovery plans, offsite backups, hot-start sites, the works--do it on the LANs

SCARE NUMBER TWO:  The Internet
Many companies want to attach their corporate networks to the Internet but are worried about the consequences. To hear people at such companies talk, you'd think that at this very moment, 50 guys in Stuttgart are waiting for you to put your company on the Net so that they can magically destroy your network by remote control.

Cliff Stoll's excellent book, The Cuckoo's Egg, and Robert Morris Jr.'s 1989 Internet worm highlighted problems in UNIX and VAX Internet security. The problems stemmed from users' lack of concern about security in the early days of the ARPAnet/Internet.

In the NT world, things are different. Let's suppose you put an NT file server on an Internet-connected computer. What can the bad guys do? To access your files, they must log on as recognized users of that server. To do so, they need to know four things: a valid user account name, the password for that account, the name of the server's domain, and either the name of a domain controller in the domain or the IP address of a Windows Internet Name Service (WINS) server in the domain.

Let's suppose you have a C-class network, acme.com at 200.200.200.x, where x can range from 1 to 254. Using NBTSTAT (a command to get NetBIOS information over TCP/IP) and a bit of patience, our theoretical hackers can figure out which machines are domain controllers and the name of your NT domain. (See "Knowing the Angles of NetBIOS Suffixes," February 1997, and Tom Sheldon, "NT Security Tips," December 1996, for specifics on using NBTSTAT to dump network information.) Suppose the hackers find that you have a domain named ACMENET with a domain controller at 200.200.200.15. They've won half the battle, two of the four things that they need to crack your network. Next, they need the name of an administrator account. They can get the name of an administrator account in a few ways, but the easiest is probably the RedButton program that's available on the Internet (http://www.ntsecurity.com/RedButton/index.htm). Another way to get the name of an administrator account is with NBTSTAT. When you dump a machine's NetBIOS name table with NBTSTAT, you often find the name of the person logged on to the server. You often see two names with the suffix <03>. One is the computer's name, and the other is the user's name. To keep this information from displaying, stop the Messenger service on that server.

So the bad guys now have a domain name, the name of a domain controller or two, and the name of the built-in Administrator account; now they need a password. Potential intruders possessing the name of the built-in Administrator account is particularly scary because that account doesn't lock out, like other accounts. You can set your system's account policies so an account becomes locked out if someone tries to log on to that account and fails after a given number of tries. For example, you can set up accounts so that five failed logon attempts in a row keep anyone from logging on to that account until the administrator unlocks it. The built-in Administrator account is unfortunately an exception to that rule; when hackers have the name of your built-in Administrator account, they can try to log on to that account as many times as they like. Would-be intruders can randomly try passwords for the built-in Administrator account until they hit the right one. So don't make the random search easier by allowing a simple password.

You can make the built-in Administrator account safer in another way. The NT resource kit includes a program, PASSPROP.EXE, that modifies the built-in administrative account so that you can lock it out like other accounts.

The key to securing the built-in Administrator account, then, is through a good password. This advice is old, but don't use obvious passwords, and don't use English words or names all by themselves: For example, if you like the password "Hale-Bopp," append some other character, as in "Hale-Bopp7," to make it harder to guess. If you figure each failed logon attempt takes (conservatively) 10 seconds, someone beating on your system unnoticed for a year would have an opportunity to try about 3,000,000 passwords. How worrisome is that? Well, you can have up to 14 characters in an NT password. If you restrict yourself to just lowercase letters, you have 64 quintillion possibilities (64,509,974,703,300,000,000), 26 raised to the 14th power. If you use 26 lowercase, 26 uppercase, and 10 numerics, you get 12,401,769,434,660,000,000,000,000 possibilities--I think that's septillions, but I won't swear to it.

You can use basic rules for developing passwords for most accounts, and go to extremes on the built-in Administrator account. Set the account's password to some randomly generated 14-character password. The password won't be inconvenient for logging in because you don't want to use the built-in Administrator account anyway. You can also protect yourself from someone logging on if you filter out UDP ports 135 through 139 and TCP port 139. With these ports filtered out, you can't log on to an NT server's file-and-print sharing services (unless you're doing Point-to-Point Tunneling Protocol--PPTP). And of course, all this advice goes out the window if you enable the Guest account--don't do it, ever.

Now you know how to secure your files from attack via NT's NetBIOS-based file sharing protocols. But someone can theoretically read or perhaps change files on your server another way--older Internet protocols. I honestly can't detail how someone can crack an NT system with one of these protocols, but I can relate the protocols that most Internet security types talk about: Telnet, Remote Shell (RSH), and FTP. I'm told that running Telnet, RSH, or FTP servers on any machine that contains sensitive data is a bad idea, so I don't. Other people have hinted that HTTP (the protocol underlying Web servers) is also insecure, so I suppose the same advice goes for Web servers. More specifically, if a hacker can upload a dangerous Common Gateway Interface (CGI) program to your Web server and then execute it, that criminal can do some damage to your server. How someone can upload unwanted data to a Web site is not clear to me--there's that sky falling again--but if that feat is possible, you can still protect yourself from the ill-intentioned CGI program. Set the file and directory permissions on your files to keep the intruder from doing damage. People coming in on your server log on as the user IUSR_servername, which Internet Information Server (IIS) automatically creates. If you use file and directory permissions to give that user account No Access to some file, no CGI program (or HTTP hole) in the world will let a criminal damage or even look at one of your files.

Advice: First, never enable the Guest account on any NT machine, ever. And if you're really worried, filter out UDP ports 135 through 139 and TCP port 139 with your firewall or your router. Our Cisco 2501, for example, can filter UDP ports, making a firewall unnecessary. (That is, unnecessary to me. Again, remember I'm not a security expert. Your mileage may vary and all that.) Also, don't put anything sensitive on a computer running an FTP server. Next, use file and directory permissions on all the files on an IIS server to ensure that hackers can't exploit security holes in HTTP; if you really want to be careful, run IIS on a computer that doesn't run anything else. Finally, use a long, randomly-generated password for the built-in Administrator account, or use PASSPROP to lock out the built-in Administrator account. (Again, PASSPROP is part of the NT Server resource kit, a separate Microsoft product.) For more information on Internet security, see John Enck, "Confronting Your Network Security Nightmares," October 1996.

SCARE NUMBER THREE:  RedButton
RedButton is a program that a firm wrote to demonstrate a security hole in NT. (The firm's main line of business is--surprise--NT security consulting.) RedButton interrogates an NT machine via TCP port 139 and reports the name of the built-in Administrator account.

This program raises the question of whether releasing such a program without an antidote demonstrates good ethics, but what can you do? Again, use PASSPROP to make the built-in Administrator account lock out, just like other accounts.

Advice: Use either PASSPROP or a very long password for the built-in Administrator account. And, filter out TCP port 139 on your router or firewall. (For another view of RedButton, see Mark Joseph Edwards, "RedButton Reveals Bugs in NT," page 48.)

SCARE NUMBER FOUR:  The RPC/Telnet Bug
NT systems talk to one another via an inter-process communication mechanism called remote procedure calls (RPCs). When one NT machine tries to talk to another, it establishes an RPC connection. The RPC/Telnet bug exploits that connection and slows your system drastically.

Use Telnet to attach to port 135 on an NT machine. For example, if the machine's IP address is 199.34.57.7, open a command line and type

telnet 199.34.57.7 135

The Telnet screen will appear, looking like a standard dumb terminal interface. Type a few random characters, and close the Telnet window. Within a minute or two, the victim NT machine (199.34.57.7, in this case) will devote 98 percent of its CPU power to the RPCSS.EXE (Remote Procedure Call SubSystem) routine. This activity will, of course, slow anything else running on the victim machine.

When you established a link to 135 and typed some characters, you started the session setup process for the RPC system. When you broke the connection, the RPC system wasn't smart enough to figure out that interruption, and it ran around in circles trying to finish setting up the session. This bug doesn't kill a system, but it does slow it. You have to reboot to reset the system. Microsoft has a hotfix for this NT problem at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/ fixes/usa/NT40/hotfixes-postSP2/RPC-fix.

Advice: Get the hotfix (Service Pack 3--SP3--which came out as soon as I finished writing this article, includes the fix). And filter out TCP port 135 on your router or firewall.

SCARE NUMBER FIVE:  The Password Cracker
Another security consulting firm wrote a program advertised as an NT password cracker, a program that according to some accounts, can crack the Security Accounts Manager (SAM) file on an NT machine and dump all the passwords. (For more information on this scare, see Mark Joseph Edwards, "NT Passwords Compromised?" June 1997.) This boogeyman was largely bad journalism.

You see, passwords in SAM are doubly encrypted. When you give a password to a new account, or change a password in an existing account, NT does not store that password. Instead, NT runs the password through a one-way hash function, producing a one-way function (OWF) password. (For more information on how NT encrypts passwords, see "Windows NT Logons," June 1997.)

What's an OWF? The password is just a series of bits. So you can think of a password as nothing more than a very large binary number, and one that you can run through a mathematical function. Many math functions are as easy to do as to undo: For example, halving a number is as easy as doubling a number. But other math functions aren't as simple: For example, squaring a number is much easier than taking the square root of a number. In another example, multiplying two large prime numbers to get a product is much simpler than taking the resulting number and trying to figure out what its prime factors are. OWFs are designed to be much easier to do than to undo.

So suppose my password is "swordfish." Suppose also that the bad guys get my OWF password, the result of running "swordfish" through the OWF. What can they do with it? They know the OWF--Microsoft has documented it--and so they know the result of the function, the OWF password. They want to know the original value that led to the OWF result. They now do a dictionary hack. They write a program that takes every word in the English language, runs it through the OWF, and compares it to the OWF password. If the values match, then they've found the original word, "swordfish," that led to the OWF password. They know my password--unless, of course, the password isn't an English word. If that's the case, they just have to start testing every possible combination of characters from zero to 14 characters long, and then we're back to doing septillions of operations. Hmmm. Assume that a computer can do a billion operations per second. (Hey, trust me, I've heard that Merced will be really fast.) Septillions of operations (ten to the 25th, recall) would take that machine ten to the 16th seconds, or about one billion years. By then, I suspect I will have changed my password once or twice. Doesn't sound like much of a security hole to me.

But wait, this situation gets even better. To run this program, you must be physically logged on to the domain controller using an Administrator account. When last I checked, administrators could change passwords. Any administrator crooked enough to run this program is also crooked enough to just change a password or modify an object's permissions (taking ownership of any object is a built-in administrative right).

Advice: Be sure to change your passwords at least once every billion years. And don't hire crooked administrators.

And More Advice
My best advice is stop worrying and watch the passwords. Never enable the Guest account. Take some special pains with the built-in administrative account (either run PASSPROP or give Administrator some very long, random password), make all users change their passwords frequently, avoid Telnet and RSH servers, and isolate the FTP and HTTP servers and lock down their files with file and directory permissions. And be wary of people who want to panic you about NT security and then charge you money to repair the problems.

SP3 provides solutions to several of the problems I discussed here. Windows NT Magazine news editor, Mark Joseph Edwards, dubbed SP3 Security Pack 3, and he's right. Install it today.