Windows NT security is under fire. It's not just that there are holes, but that they are holes that other OSes patched years ago.
Do you have a strange feeling? The feeling that you've been somewhere or done something before? It's deja vu and we're developing a serious case of it as we hunt down bugs in Windows NT. It's not strange that there are bugs in it. We certainly have not come across any OS or piece of software that is bug-free.
The peculiar feeling comes from the fact that the bugs we're seeing are the same security holes 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, 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 underpatched 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 much 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 plugged the port 135 hole in one of the l4patchestoServicePack3, but there are probably more TCP/IP bugs remaining than we'd care to think about.
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.
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/.
In addition to the Trojan horse examples, a slick program entitled getadmin was recently released by Konstantin Sobolev, who wrote it in Russia, according to one security expert. This program found functions the NT kernel was providing that would let nonprivileged processes attach to memory areas that they should not be allowed to touch and modify the contents.
The result? A tool that would let an ordinary account convince the system it was just debugging something and place the account in the Administrator group of an NT domain. The next time you logged in, you had full rights to the system. This avenue seems ripe for exploration as Microsoft pulls more and more of the services that used to live in user space into kernel space. Any bug or lack of validity checking in userland gets much worse if it continues to exist in kernel space. As expected, getadmin has been ported into an ActiveX control and an application that a Trojan horse can deliver.
At press time, Microsoft has issued two patches for getadmin, the second of which was headed for NT 4.0 Service Pack 4, but each works only in certain cases. Neither will work if you have any software developers on your system, because they need to be given permission to attach to processes for debugging purposes.
A while back, a white paper on insecurities and potential flaws in Microsoft's CIFS specification (its replacement for NFS and how all systems will share files across networks in the future) was posted on the Internet. The paper, which was by hobbit@avian.org and available at http://www.avian.org, pointed out many areas for concern and gave readers enough information and source examples to create their own "probing kit" to check things out for themselves.
One interesting note in the paper was that logging of attempts to connect to file shares was done via the NetBlOS name, not the IP address. Thus, it was trivial to explicitly tell the machine what to log by handing in the NetBlOS information. Walking into work and seeing your logs filled with connection attempts from "HAHAHAHAH" might tell you that you were under attack, but it gives you little information to work with other than a taunting ramble.
In addition to logging, NT provides account lockout "slowdown" solutions to programmatic dictionary or sequential password attacks over the network. In account lockout, the administrator specifies how many invalid attempts it takes before an account is locked out and how long the lockout period lasts. Great, except you can't lock out the administrator account. If someone renames the Administrator account to try to hide it and leaves a dummy account in its place, you can tell as soon as your automated attack scripts start failing in rapid succession as opposed to slowly and programmatically.
The slowdown solution makes NT introduce a delay between each attempt to authenticate. Ostensibly, this would make it unfeasible for an attacker to launch an entire dictionary at an account over the net--it would take too long. If you have 1000 words you want to try and the slowdown period lets you try only one word every 2 seconds, it will take 33 minutes to go through them. The problem here is that the slowdown solution works only per connection. To bypass it, simply open 10 connections with different words from the list. Now it will take you only 3 minutes (these numbers are used just as an example).
For more information on this, see http://www.avian.org, http://www.secnet.com, and http://www.L0pht.com for the vulnerability-in-CIFS white paper, the NAT 10 auditing tool, and L0phtcrack, respectively.
The encryption implementation in NT 4.0 has left passwords vulnerable to attack (see the text box "Password Protection at a Price"). Microsoft recommends abandoning LAN Manager-style passwords. NT-style passwords can be up to 128 characters in length. These passwords are case-sensitive. NT converts them to Unicode and then runs them through Rivest-Shamir-Adleman's (RSA) MD4 message digest function. The resulting 16-byte value is the NT hash. The only time hackers should be able to retrieve a LAN Manager password and not the NT MD4 version is if the MD4 version is originally longer than 14 characters. But ironically enough, NT's UserManager application won't let you type in a password greater than 14 characters.
Microsoft officials we spoke to downplay these problems and characterize NT as "a very solid and secure OS." According to Enzo Schiano, group product manager for NT Server, "if you compare NT to Unix, we probably have a very, very comprehensive security infrastructure."
But much of Microsoft's advice on its Web site smacks of the obvious: Precautions include reminding users not to pick easily guessable passwords. The Syskey patch to NT 4.0 prevents anyone from reading hash values out of the NT registry. The hacker community is now calling Microsoft's bluff by exposing more holes every day.
Unfortunately, the cracker community is exploiting the revealed vulnerabilities for criminal purposes, and patches such as Syskey hamper administrators, not the crackers. To help administrators test the strength of their encryption, a future version of L0phtcrack will include an NT-based sniffer kit, for reading hash values over the NT server's network.
You can't just blame users who don't adopt or enforce security policies rigorously. DoS attacks, noncaptive environment attacks, and privilege escalation attacks will continue, even through the implementation of Kerberos security in NT 5.0. Eventually, users will complain enough that Microsoft will turn its full attention to the problem. The seriousness of the situation may even cause Microsoft to turn to Unix methods and technologies developed over the years to patch the holes. NT is a robust OS, but only compared to other Microsoft OSes. It can prosper only if it becomes something more.
On July 14, 1997, Microsoft quietly admitted a major security problem with all versions of Windows NT. Simply put, the encryption implementation in NT 4.0 makes it possible to extract all the LAN Manager and NT user names and passwords in any NT workstation, server, or domain. After this, you can then brute force the plain-text passwords. Microsoft Knowledge Base "Document:Q147706" (it can be found at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/ sa/NT40/hotfixes-postSP3/lmfix/Q147706.txt) is a disturbing mea culpa. The essence of the document is that security has a price-a very high price. Microsoft will guarantee security for your network only if all clients and servers are 100 percent NT. If your network has clients that require the LAN Manager protocol, such as Windows 95, Windows for Workgroups, or regular
Windows 3.1, anyone with the right tools can intercept the obfuscated user names and passwords, and extract their plain-text equivalent.
A white paper by the researcher known on the Internet as hobbit started it all, analyzing bit by bit the CIFS protocol used by NT. Dominique Brezinski of Cybersafe then released a paper that concentrated on the man-in-the-middle problem in the process. From down under, an anonymous Australian programmer released the source that allowed the programmatic deobfuscation of LAN Manager and NT hashes from the NT registry.
Cygnus programmer Jeremy Allison quickly cleaned it up and released PWDump, which was meant to be a password audit tool for NT. PWDump unleashed a storm of controversy after it was incorporated in a Trojan horse by a Bay Area-based programmer.
Later, the hacker group that's known as the LOpht built a sophisticated brute-force password cracker that extracted plain-text passwords from the PWDump hashes.
NT's security is based on two cryptographic methods: the IBM-sired LAN Manager security protocol and the NT security protocol. While each has strengths and weaknesses, together they prove to be disastrous, because the weaker LAN Manager protocol emasculates the stronger NT protocol. Unfortunately, because of backward-compatibility requirements, Microsoft continues to use the weak LAN Manager protocol.
Why is the LAN Manager protocol weak? It's the implementation. In a nutshell, LAN Manager hashes the passwords in a predictable way and does not use salting (the process of inserting several random bits into the hash).
From our research, we have found that you have to go through only seven characters to retrieve passwords (up to 14 characters in length) in the LAN Manager hash. Also, because no salting is being done, constants show up all over the place, giving away too much information and speeding up attacks tremendously.
The first 8 bytes are derived from the first seven characters of the password, and the second 8 bytes are derived from the eighth through fourteenth characters of the password. If the password is less than seven characters, the second half is always the same.
Let's assume for this example that the user's password has an LM hash of –0xC23413A8A1E 7665fAAD3B435B51 404EE (I will save everyone the nanosecond it would have taken for them to plug this into LOphtcrack and have it tell them the password is "WELCOME") .
The following is what happens to this hash on the network:
System B sends an 8-byte challenge to system A. (Assume Ox0001020304050607.)
Machine A takes the hash of OxC23413A8A1 E7665fMD3B 435B51404EE and adds five nulls, thus becoming OxC23413A8A1 E7665fMD3B435B5140 4EE0000000000. This string is broken into three groups of seven.
The 7-byte strings are str to_key'd (if you will) into three 8byte odd-parity DES keys.
Then, 8byteDeskey1 is used to encrypt the challenge Ox0001020304050607. Let's assume the result is 0~~ M.
Next, 8byteDeskey2 is used to encrypt the challenge Ox0001020304050607. Let's assume the result is OxBBBBBBBBBBBBBBBB.
Next,8byteDeskey3 is used to encrypt the challenge Ox0001020304050607. Let's assume the result is OxCCCCCCCCCCCCCCCC.
The three 8-byte values are concatenated (dumb), and the 24-byte response of OxAAAAMAABBBBBBBBCCCCCCCC is returned to the server. The server does the same thing to the hash on its end and compares the result to the 24-byte response. If they match, it was the correct original hash.
Why is this weak? The first thing we check to see is if the user's password is less than eight characters in length. We do this by taking the 7-byte value of Ox04EE0000000000, turning it into an 8-byte odd-parity DES key, and encrypting it against the 8byte challenge of Ox0001020304050607. If we get the result of OxCCCCCCCCCCCCCCCC, we are pretty sure it's fewer than eight characters in length.
To be sure, we can run through Ox??AAD3B435B514 (i.e., 256 possible combinations) to see that 5f shows us that the result is OxBBBBBBBBBBBBBBBB, proving that the password is less than seven characters and also giving us the last byte of the first half of the LAN Manager hash.
Note that we're not worried about optimizing the way this is done, and that there are much more effective ways to do this that reduce the amount of time required even further. Even so, this shows that even a simplistic attack works against this implementation, and it's no different than how a tool such as L0phtcrack attacks the hashes in the registry.
What if the password is eight characters or more? Let's say that machine A takes the hash of C23413A8A1 E766AC435F2D D90417CCD6 and adds five nulls to it, thus becoming C23413A8A1E766AC435F2DD90417CCD60000000000.
The first thing to check is if the password is fewer than eight characters in length. Deriving the 8-byte odd-parity DES key from Ox04EEOOOOOOOOOO and encrypting against Ox0001020304050607 does not, in this case, give us OxCCCCCCCCCCCCCCCC, so we know that the password is eight characters or greater.
It takes us, in a worst-case scenario, 65,535 checks to figure out that the 2 bytes that are used in the last third are OxCCD6.
You can go through your seven-digit combinations of characters for the first third the same way you would the LAN Manager hash from the registry. This will yield not only the first third of the response, but also the first byte of the second third. Keep in mind that you already have the last 2 bytes that made up the final third. You can approach the middle third in the same fashion.
Together, these problems enable utilities such as L0phtcrack to get and decrypt passwords quickly using brute-force methods.
Because opting out of the LAN Manager security model precludes continued use of Windows 95 machines as clients to NT machines, it is still a moot point as to how tough or well done the NT hash might or might not be.
No add-on or accessory can close Windows NT's holes, but they all claim to help you tackle the job of guarding NT servers in more systematic ways. Internet Security Systems (http://www.iss.net) recently released RealSecure 1.0 for NT 4.0, featuring an automated, real-time attack recognition and response system, and a significantly enhanced management console, including predefined engine configuration templates. It also features built-in reporting capability, an ODBC-compliant database, and the ability to recognize attacks in a Windows networking environment. Network Information Technology (http://www.nit.com) offers UniShield APD for Windows NT. UniShield's publishers say it transparently enforces security policies and audits all administrative activity, irrespective of whether such activity originates from the native NT programs such as User Manager or Server Manager, Net Commands, or third-party software developed using Net API functions. Axent Technologies (http://www.axent.com) claims to guard against NTCrack, insecure registry, and the anonymous log-on loopholes, with OmniGuard/Enterprise Security Manager 4.4.