|
|
Many people dislike Bill Gates (though, oddly enough, not Paul Allen) because of his tremendous success. This is an invalid reason. People who do not know his story do not realize that Gates was a talented hacker in his youth. Since then, Gates has contributed much to the computing community; he just happens to have done so from behind a cash register. This is no crime.
NOTE: On the other hand, Gates's assertion in The Road Ahead that we should all document our lives strikes me as a bit Orwellian. In that book, Gates suggests that all good computing citizens should store a complete record of their lives on computer (we should record all movements, purchases, appointments, and so forth). This recorded material, he writes, could serve as an alibi in the event such a citizen is accused of a crime. But if this documented life becomes an accepted alibi, what happens to those who do not maintain such records? In short, Gates is profoundly influencing the social construct of this nation. His work may well result in a two-class society. Gates is a brilliant man who has contributed much. Nonetheless, whether he is a true friend to humankind remains to be seen.
When people in security speak of Gates's products, they sneer. It's a fact: Microsoft has never been a particularly secure platform, but then, these products have historically not needed to be secure. Nonetheless, times have changed; now there is a need. But if programmers at Microsoft take the next five years to hammer out some decent security schemes, they would be on par with the amount of time it took the UNIX community to do the same.
Microsoft products should not be subjected to the same scrutiny as UNIX products because they are in a different class. Despite this fact, many security specialists ridicule Microsoft products. They subject such products to rigorous tests, knowing that the products cannot pass. Then they parade the negative results across the Net, "proving" that Microsoft's security is weak and lackluster. This is irresponsible and creates a good deal of public unrest.
Security specialists should lament, not rejoice, when they find a hole in a Microsoft product. After all, such a hole simply represents one more hole in the Internet. Microsoft products should receive as much attention and respect as any other product. Moreover, security folks should educate, not ridicule, the cult following of Microsoft because that is the right thing to do.
NOTE: Microsoft's Windows NT uses a very good security model and is considered at least minimally safe. Nevertheless, although NT's security model is good, it does not mean that NT is secure in the same way that many versions of UNIX are secure.Many Microsoft advocates point out that the NSA has granted Windows NT a C2 security rating on the Evaluated Products List. This, they contend, is evidence that NT is secure. Not true. First, C2 is the very lowest security rating on the EPL. Moreover, NT's C2 rating is valid only on certain hardware (Compaq Proliant 2000 and 4000 Pentium and the DECpc AXP/150 Alpha). Furthermore, NT's C2 certification assumes that a non-networked, standalone workstation is being used. Thus, the NSA has effectively suggested that NT is minimally secure, as long as it runs on certain hardware, has no network connectivity, and is installed only as proscribed by the evaluation process. True, it was a great step forward for Microsoft's marketing department to obtain any rating on the EPL at all. Because most users have no idea what the EPL is, the rating sounds very impressive ("The National Security Agency says it's secure!"). In reality, however, the rating is not spectacular and is no guarantee of the security of NT.
Microsoft's security problems can be summed up in two words: user friendliness. No other platform (not even MacOS) has been designed so expressly for this purpose. Over the years, the Microsoft team has invested enormous amounts of time and research to deliver ease and enjoyment of use. For example, Microsoft even conducted research to determine from which direction light should fall on an icon. That is, it studied whether users would respond more favorably to a shadow on the right or the left of a button or other object. All developers are expected to adhere to this design convention (the shadow is always on the right, the light source is on the left.
This ease of use comes with a cost. For example, consider the swapping scheme in Microsoft Windows 3.11. Swap files and disk caches are devices that greatly enhance overall performance (they can compensate for sparse RAM resources). When a large swap is present, certain elements of a program need not be loaded into memory again. This results in increased speed and functionality. Unfortunately, it also results in poor security.
Any type of swapped memory system is insecure because traces of data are left within that swap file or swap area. (A good example is the use of encryption like PGP. When done through the Windows environment, the passphrase is written into the swap file and is therefore retrievable.)
Throughout this chapter, you will see how user friendliness has inhibited the development of a truly secure Microsoft operating system. (NT is excluded from this analysis and will be discussed at the end of the chapter. NT has advanced security features; these were responsible for Microsoft getting its first product onto the Evaluated Products List.)
Indeed, this is the greatest challenge facing Microsoft today. It must find a way to reconcile user friendliness with strong security. Until it does, Microsoft has no hope of seizing control of the Internet.
Microsoft's Disk Operating System is indisputably the most popular personal computer operating system in history. It is lightweight, requires little memory to operate, and is limited in commands. In fact, DOS 6.22 has approximately one eighth the number of commands offered by full-fledged UNIX.
You may wonder why I would even bother to treat DOS security issues here. After all, the number of DOS-based machines connected to the Internet is limited. On closer examination, however, the relevance of DOS becomes more apparent. For example, it has become common for legacy Novell networks to be strung to the Internet. Many of these older networks (running 3.x or earlier) also run DOS-based applications. Here are just a few old favorites that you would be likely to find out there:
Because such networks are sometimes connected to the Internet, DOS still remains in the running. Indeed, Novell is not the only host example, either. Many networks retain at least one workstation that runs Windows for Workgroups on top of DOS.
I will not exhaustively cover DOS, but there are a few issues I need to mention. As you might expect, many of these issues relate to physical or local security of DOS machines. If your network is devoid of any DOS machines, feel free to skip this portion of the chapter.
Early IBM-compatible architecture was not designed for security. Indeed, there are relatively few examples of such an architecture implementing reliable security even today. Thus, from the moment an individual stands before a machine running DOS, a security problem exists; that problem is not attributable to Microsoft.
The next series of points are well known to users who are required to use IBM-compatible computers in their occupation. Much of this is therefore old hat, but I will run through it nevertheless. The rush to the Internet has prompted many people who never before had computers to get them. This section may therefore be helpful to some.
The CMOS password option, which can be enabled on most machines (even ranging back to some 286 models), is completely insecure.
NOTE: The CMOS password function on an IBM compatible is used to protect the workstation from unauthorized users gaining control at the console. The CMOS password option (if set) results in a password prompt issued immediately at boot time. Indeed, when the CMOS password function is enabled, the boot is arrested until the user supplies the correct password.
For a user who needs access to the machine (and who has never been granted such access), the solution is to remove, short out, or otherwise disable the CMOS battery on the main board (see Figure 16.1).
FIGURE 16.1.
Physically disabling the CMOS password on an AT IBM compatible.
Your network workstations can easily be compromised in this manner. However, this is more likely done by someone who is attempting to steal the machine, as opposed to trying to breach security. Internal employees would use a different method. Because your own employees have some level of access on the system, they can pose a serious security threat. Even if they do not disassemble the machine, there are ways for internal, trusted folks to bypass that CMOS password. And although this is a commonly known fact among hackers and crackers, the average LAN supervisor may not be so aware.
I have seen offices, for example, where only the Novell administrator knew the CMOS passwords. The procedure was almost comical. The administrator came in early each morning and enabled all the workstations. At the end of the day, those workstations were shut down and the CMOS password would be active. The administrator assumed (wrongly) that in this manner, the network was safe from internal theft or tampering. This assumption was based largely on the premise that no one in the office knew the CMOS passwords but the administrator.
In fact, there are a number of CMOS password catchers on the market. These utilities capture a CMOS password either while the user is already logged in or during boot. Up to this point, we have not yet booted the machine; we are simply looking to get inside. These utilities and techniques will allow us to do so:
Once inside, the cracker will typically want to gain further, or leveraged, access. To gain leveraged access, the cracker must obtain some information about the system. Specifically, on DOS machines that also run Novell and Lantastic, the cracker will need login IDs and passwords. To do that with some measure of stealth, the cracker must employ several tools, including a key-capture utility.
Key-capture utilities are programs (usually very small) that capture any keystrokes that occur after a specified event. These keystrokes are recorded most commonly into a hidden file and a hidden directory.
The technique discussed in Figure 16.2 is quite effective. The Alt+255 character is an extended ASCII character and therefore is invisible at a prompt. In Windows, it appears as a small, accented squiggle and is usually missed unless you are looking for it. Kids use this technique to hide games and racy photographs on their home and school machines.
FIGURE 16.2.
A directory gets hidden on the disk.
TIP: Hidden files are generally created using the attrib command or by the key-capture utility itself (in other words, the programmer has included this feature in the software).
A number of key-capture utilities (or keystroke recorders) are available for DOS, including the following.
Keycopy was reportedly released for the first time in 1990, but current distributions report a date of 1993. The program was authored by Christopher E. BoVee. Keycopy is capable of capturing 200 keystrokes at a time and not just from a prompt. It also captures keystrokes executed in WordPerfect, MultiMate, and reportedly, Norton Editor. The program also sports a nice collection of command-line options that assist in setting the directory, the outfile, and other key elements. The author provides a series of keystrokes commands that can be used to kill, pause, or otherwise alter the behavior of the program. Using this program, crackers can capture login IDs, passwords, and other data. It is located here:
This product was released sometime in 1992. Its author apparently had no intention of it being used as a cracking utility. Rather, it was to be used for the automation of tedious and repetitive personal tasks. Playback records all the keystrokes of a task and later plays them back. Some users may remember communication packages that performed the same function. One of them was Qmodem. It would record keystrokes of logins to BBS machines or other remote servers. This became a script that could later be executed. Coupled with an old utility called tm that timed processes for execution, one could run entire download sessions automatically without ever being there.
One of the more extraordinary features of Playback is the way it handles the timing of keystrokes. Everything is based on exactly the same tempo of the keystrokes recorded. Say, for example, that the session recorded a login procedure. Many login procedures require a waiting period between the moment the user enters his login ID and the point at which he enters his password (this waiting period sometimes relates to a buffer issue and sometimes simply involves a slow file server). In any event, Playback plays back the keystrokes precisely as they are recorded. Therefore, it is a suitable tool for simulating a real session with some remote or even local login program. Based on these amenities, Playback became a favorite among crackers. It is located here:
Phantom 2 is a tool similar to Playback, but far more comprehensive. One major distinction between the two is that Phantom will record your keystrokes no matter what program is running. Moreover, this program provides a control panel from which to operate. This panel allows the user to set a multitude of options. It can record keystrokes as well as sounds and tones. Few DOS-based keystroke recorders are as elaborate. Much like Playback, Phantom plays back keystrokes precisely as they are recorded. It is located here:
DosLog 2 is a standard key-capture utility that captures all activity at the console. The author reportedly wrote it because his younger brother failed to heed warnings about using certain programs. Using this utility is a good way to monitor your employees (or a good way for them to monitor you!). It is located here:
Keytrap is an interesting utility that allows for user-specified time frames in regard to when it will do its work. (This is expressed in terms of minutes. Because you cannot exceed the number of minutes in a day, the outfile must be cleared and you must start again at the beginning of each business day. If you fail to clear out the file, it will be overwritten with a new one.) Otherwise, Keytrap is a standard key-capture utility with a bit less functionality than its counterparts. It is located here:
The main drawback of key-capture utilities is that the outfiles, though hidden, must be removed at some point. Some of the previously listed key-capture utilities will not write a file larger than X number of bytes. Therefore, the cracker must retrieve his bounty and start again. Nevertheless, these tools are standard in the average cracker's toolbox. They are old utilities, but exceedingly useful if one needs to crack a network that harbors at least one DOS box.
At any rate, enough about techniques for cracking DOS. For a moment, I'd like to concentrate on preventing crackers from cracking a DOS box. There are many tools on the Internet designed expressly for this purpose and a majority are free for non-commercial use.
Secure 1.0 restricts directory access. That is, it prevents any unauthorized user from accessing a given directory. As the author is quick to point out in the documentation, however, Secure 1.0 does not obscure the directory's existence; it merely prevents unauthorized access to it. Unfortunately, the unregistered version only allows one directory to be so restricted, so users must choose that directory carefully. It is located here:
This tool is not your average cheesy security tool for DOS. This is an excellent DOS security application suite. The utility applies high-level encryption to DOS volumes (reportedly, you can have as many as five encrypted disk volumes at one time). What is most extraordinary about this utility is that it has enhanced stealth features that prevent monitoring programs from collecting information about SFS's activity.
Clearly, the author of SFS wanted to make a serious contribution to DOS security. Compliance with the Federal Information Processing Standard (FIPS) and several other key standards are built into the program. Its compatibility with a host of disk-caching and memory-management programs makes the program all the more mind boggling. Finally, the documentation on this utility is superb. See the following:
Encrypt-It amounts to DES encryption for DOS. This utility applies high-level DES encryption to a single file or a series of them via batch processing. The program suite also features a macro generator that accepts macros of lengths up to 1,000 keystrokes. The main amenity of this program (besides the level of encryption it provides) is that it requires very little memory to run. It also contains a benchmarking tool through which you can determine how well a particular file is encrypted. See the following:
LCK2 locks the terminal while you are away. When you leave your terminal, simply issue the program's name at a prompt to lock the terminal. It is impervious to a warm reboot or interrupt keystrokes (Ctrl+Alt+Delete, as well as Ctrl+Break). Reportedly, the only way to defeat this program is to reset the entire machine. In network environments where users are strictly forbidden to restart machines, this might be useful. See the following:
This is a powerful program that password-protects a system. It supports password protection for 30 people. Some serious amenities include
This utility provides some excellent protection. The problem is it relies on you changing the boot sequence in the CMOS. Thus, you disable the A: boot option (floppy seek on boot). A cracker can override this by attacking the CMOS settings. In all other respects, though, this is a very useful utility. Gateway2 can be found here:
Similar to Gateway2, PASSW204 relies on changing the boot sequence. This utility loads the password routine in the config.sys file. This has some added functionality because it is ready for network support. One very interesting feature is that you can enable case sensitivity, which exponentially increases the strength of the passwords. See the following:
You have to see it to believe it. For a shareware product, Sentry is quite complete, allowing even the capability to secure individual files. It also has many features commonly available in straight-on commercial products, including password aging and some support for Windows. However, it, too, depends on you to change the boot sequence in the BIOS. See the following:
There are literally hundreds of such programs available, so I will refrain from listing more of them. Instead, I will send you to a series of sites at which some or all can be obtained. However, know this: MS-DOS was never meant to be a secure system. If any of the workstations on your network are running pure DOS, you are vulnerable to an inside attack. From such a machine installed on a network, a cracker can easily grab your passwords.
Also be aware that many programming tools are available to circumvent your security. Certain distributions of C++, for example, contain programs that allow MS-DOS users to monitor system processes. These tools will also monitor network activity. Such monitoring tools are not restricted to programming applications, either.
One such application is Pcwatch. This program is designed expressly to examine the behavior of EXE files as they execute. Using this program, a cracker can accurately determine the elements of a program and where its vulnerabilities might lie (for example, where disk access occurs within the program, where memory swaps are performed, and within what address registers these events occur). It is a common utility employed by crackers when they need to crack a DOS file and is available here:
For specific network problems, refer to the chapter that addresses your operating system (Novell, UNIX, AS/400, and so forth). At this stage, I want to concentrate more on Windows-based security issues. Thus, here are some sites at which you can acquire security tools for the DOS environment:
The Simtel DOS Security Index page offers material about password protection, access restriction, and boot protection. It is located here:
This page contains serious information about access restriction and includes one program that protects specific cylinders on a disk. See the following:
This page offers material about password protection, access restriction, and boot protection. It is located here:
This site contains information about password protection, access restriction, and boot protection. It is located here:
This page is the home of Integrity Master, an NCSA-certified security tool. It can be found here:
Basic security within Windows and Windows for Workgroups is (and always has been) seriously lacking. Password protection relies on the PWL files that are generated when a user creates his password. These files need not be decrypted or even attacked. They can simply be deleted. That alone makes the PWL scheme ineffective.
NOTE: In certain instances (when, for example, the cracker is seeking to gain access to a server), deletion will not do the trick. However, deleting one password allows the cracker to at least reach the local workstation, at which point he can crack other passwords.
Briefly, I want to address the encryption routine and general environment behind the PWL file. First, the process uses two different functions: one to encrypt and store the password, another to retrieve it. Those are, respectively:
The password remains cached. A programmer on your network can write a program that will get the password of another user by using functions identical to WNetCachePassword() and WNetGetCachedPassword(). The only restriction is that the targeted user must be logged in at the time the program is executed (so the password can be trapped). The password can then be cached out to another area of memory. Having accomplished this, your programmer can bypass the password security scheme by using that cached version of the password.
Likewise, you may be able to force the cached password into the swap file. Reportedly, this technique reveals the password. (Nonetheless, this is a cumbersome and wasteful method; there are other, easier ways to do it.)
TIP: One method is where multiple passwords are added to the password database at high speed. You could technically use a utility similar to Claymore to do this. Using this technique, you fill the available space for passwords (255 of them, actually). This causes an overflow, and the routine then discards older passwords.
But again, unless the cracker is seeking access to a Windows NT server via a Windows for Workgroups box, this is academic. In most cases, the password files can simply be deleted. Because there is no default file access control (or restrictions) in Window for Workgroups, the PWL files do not stand a chance.
NOTE: This is vastly different from UNIX or even Windows NT in real NTFS mode, where certain files are protected from read, write, or execute calls from unauthorized users. For example, in UNIX, the file /etc/passwd may indeed be readable (though, the system administrator ought to be using shadowing). However, no one without root privileges can access or write to that file.
Windows for Workgroups, in its out-of-the-box state, provides no protection for those PWL files. Using a utility such as PAC.exe (or Ledbetter's find.exe), you can go to a prompt on a Windows for Workgroups workstation and disable all passwords on the network with a single command line. The process would take no more than two to three seconds. The command would be
pac /I /s *.pwl /k
or
find *.pwl -v
Having executed these commands, the network is yours for the asking. This problem has been carried into the Windows 95 distribution. As explained on the Tip of the Month page at Ronster's Compendium:
Cross Reference: Check out Ronster's Compendium's Tip of the Month page at http://199.44.114.223/rharri/tips.htm.
This problem was not heavily publicized because Windows security was not an issue relevant to the Internet. However, almost immediately after Windows 95 (with rich, new Internet functionality) was released, the issue appeared in national magazines. In fact, many news stories concentrated not only on Microsoft's failure to protect such files, but also on the weak password scheme employed. As Eamonn Sullivan noted in his article "Win 95 Password Caching Flawed" (published in PC Week, December 8, 1995):
However, I need not cover this subject further, for there are utilities currently available that will crack PWL files. Here is one:
Glide cracks PWL files. It comes with the CPP file for those interested in examining it. The cracking party enters the filename (PWL) and the username associated with it. This utility is quite effective (it works at a command prompt in a shell window or at a DOS prompt). It can be found online here:
With respect to Internet security, Microsoft Windows and Windows 3.11 are not so relevant. This is because the majority of implementations of the TCP/IP stack on these two systems do not include server software. Thus, someone connecting to the Net via TCPMAN, for example, is really nothing but a dead IP address from a cracker's point of view. There are no outbound services running and therefore there is nothing to connect to. That situation changes, however, if server software is loaded. Following is one utility that can assist in strengthening that rather weak state of security.
KDeskTop protects your desktop in Windows. One interesting feature is that it disables your ability to execute a warm reboot from the Windows environment. It provides password protection for your Windows desktop (on boot into the Windows environment, this program issues a login prompt). It can be found here:
Windows 95 harbors many of the same security flaws that Windows and Windows for Workgroups do. For example, even though Microsoft has provided a new system of managing the password process, the password problem is still an issue. Although Microsoft hints that its new system will improve security, it does not. The password protection scheme is no more robust than the one in Windows for Workgroups.
Reportedly, the way to password-protect a Windows 95 workstation is to set the properties so that password caching is disabled and to enable user customization of desktop preferences. The process takes no time at all:
FIGURE 16.3.
Set Primary Network Logon to Windows Logon.
FIGURE 16.4.
By default, Windows 95 sets the user profiles so that all users utilize the same
preferences and desktop settings. This must be changed.
FIGURE 16.5.
Select the option that allows users to specify their own preferences and desktop
settings.
If a cracker were to breeze through your department and see such a machine so configured, it would take him less than two minutes to undermine this scheme. His steps would be as follows:
TIP: One excellent way to bypass the password security on networked boxes, particularly security schemes set with the Policy editor, is to simply pull the plug (remove the Ethernet card temporarily or unplug it from the machine). When Windows reboots, you will encounter errors, and you may be forced to go into safe mode (much depends on whether you are using third-party drivers on the box). In any event, in safe mode or normal mode, you can proceed to kill all the password protection.
Many Microsoft security models are fragile. Consider Microsoft Access, the standard package for building business databases. Access uses a language called Access Basic. It is an extremely powerful package, often used to create multiuser databases. The newer versions of Access are incredibly fluid in the manipulation of data.
Access performs authentication based on an internal security identifier (SID). This SID is derived from running the username and the personal identifier (PID) through an algorithm (these variables are used as the keys). The extraordinary thing is that if, in the creation of a new account, a cracker issues the same username and PID as the target, the resulting SID will be identical. Why didn't techs at Microsoft base this process on using the time and as a random number generator? This at least would create a digital value that would be reasonably unusual. In any event, this is academic. All legacy databases created in Microsoft Access 1.0 are vulnerable to another attack that is so simple, I will not print it here. Many businesses rely on such legacy databases, and I do not see how revealing that method will contribute to security. The problem has never been fixed by Microsoft and never will be. However, programmers are well aware of this flaw.
NOTE: Hints about the flaw: The "unique" SID created at setup for the Admins is written to disk 1 of the distribution. Also, anyone with another version of SYSTEM.MDA can access restricted files. Lastly, and perhaps most importantly, the SID of any user can be read and manually altered, allowing any user to inherit the privileges of any user. Did you create any databases while having Admin rights? If so, anyone can completely seize control of your Access database.
Cross Reference: If you are interested in this flaw, check out ftp://ftp.zcu.cz/mirrors/winsite/win3/misc/acc-sec.zip for more information.
NOTE: It is interesting to note that in the retail version of Windows 95, very few instances of the word security occur in the help files. Indeed, these references refer to whether the software on your machine is legal. Microsoft appears to have little interest in the security of 95, except in terms of whether you have stolen it from them. This is in complete contrast to Windows NT.
No doubt about it. Out-of-the-box security for Windows 95 sucks. What can be done about it? Well, many imaginative software authors have been put to the task. Some of their innovations are...well...interesting.
CyberWatch is probably the most extreme solution I have encountered yet. This software operates in conjunction with video cameras attached to the machine. The software recognizes only those faces that are registered in its face database. The machine actually looks at you to determine whether you are an authorized user. The company claims that the technology on which CyberWatch is based is neural net material.
Although it is an interesting proposed solution to the problem, be assured that given 10 minutes alone with a machine so configured, the talented cracker could bypass the entire authentication procedure. Thus, this technology is most useful in offices or other places where such access is unlikely to occur (or where individuals are forbidden to turn off or reboot machines). CyberWatch can be found here:
WinSafe, a promising utility, allows control of individual drives on the machine (see Figure 16.6). This allows you to bar unauthorized users from, say, a CD-ROM drive.
FIGURE 16.6.
The WinSafe drive protection properties settings.
Of particular interest is that WinSafe protects network drives. Users can sample the application by checking out the available shareware application.
WARNING: The documentation suggests that using the Policy editor to set the REAL Mode DOS settings could potentially conflict with WinSafe.
WinSafe is available here:
The Safe Guard line of products (including Safe Guard Easy, Safe Guard Pro, and PC/DACS for DOS/Windows) offers hard disk drive encryption, protection against booting from a floppy, password aging, password authentication, and support for 15 users per machine. The encryption choices are suitable, including both DES and IDEA, as well as several others. Of special interest is that these products can be installed over a network (thereby obviating the need to make separate installations). See the following for more information:
Secure Shell (SSH) provides safe, encrypted communication over the Internet. SSH is an excellent replacement for Telnet or rlogin. As of this writing, there is only a 16-bit version for Windows, but it runs well on any TCP/IP implementation. SSH is no ordinary utility. It uses IDEA and RSA encryption and is therefore extremely secure. It is reported that once an hour, the keys are discarded and new keys are made. SSH completely eliminates the possibility of third parties capturing your communication (for example, passwords that might otherwise be passed in clear text). SSH sessions cannot be overtaken or hijacked, nor can they be sniffed. The only real drawback is that for you to use SSH, the other end must also be using it. While you might think such encrypted communication would be dreadfully slow, it isn't. Enter the following URL to visit one of the main distribution sites for SSH:
The Surveillance Agent is a simple but powerful tool for monitoring system processes. It has two modes of operation. In one, evidence of your monitoring is revealed. In the other, the surveillance occurs without a trace. The program is typically loaded into memory (this can be done in a variety of ways) and begins logging. Alternatively, you can specify a trigger, or certain event that will cause the agent to begin the monitoring process (for example, if someone tries to access your personal diary, this could trigger the agent to begin monitoring). The authors of this software were very thorough. For example, you can actually disguise the Agent's process as some other process (this is in case you have savvy crackers hanging around the workplace). In all, this very comprehensive tool is tailor-made to catch someone in the act and is probably suitable for investigating computer-assisted crime in the workplace. For more information see
This product is an excellent tool. As stated on the Fortres home page, the product can prevent:
The utility is supported under both Windows 3.11 and Windows 95. The price is probably a deterrent for casual users, but system administrators who have labs or offices with multiple Windows-based machines would do well to grab this product. Find out more about it here:
Following are some holes and viruses of note. Some relate specifically to Microsoft, while others are solely the responsibility of third-party vendors. Many of these holes have been fixed. However, as I have mentioned, not everyone gets the latest and the greatest. Many people may be running versions of software that have not been patched.
It is surprising how many Microsoft users are unaware that sophisticated macros can be written in the Microsoft Word environment. WordBasic, the language in which such macros are written, is highly functional. In Word documents alone, WordBasic can save a user many hours of editing. It fully supports while...if...then...else conditional execution of commands. This level of functionality (when coupled with recording of keystrokes) can automate almost any task performed in Word. For that reason, WordBasic qualifies as a bona fide scripting language.
As you might expect, pranksters on the Net have found innovative, new uses for the WordBasic language. One of those uses is to create malicious macros, or macro viruses. These can be gotten from the Internet. They will infect your normal.dot, thereby altering (and perhaps severely retarding) your default document environment.
The most well known of these macro viruses is called Concept. Concept infects not only the normal.dot file but any DOC file it can access. Reportedly, after the first infection (the first instance that Word is opened after initial infection), every document saved thereafter will also be infected. It also reportedly works on any platform that runs Word and has been found on at least one commercial CD-ROM distribution, as noted by Graham Cluley in his article "Another Instance of Concept Macro Virus in Microsoft CD ROM":
Cross Reference: There is a reliable military site where you can acquire tools to determine whether your machine has been infected. That site is located at http://www-yktn.nosc.mil/Desktop_Support/winword/concept_virus.htp.The main tool for identifying the virus is a Word document macro. You can get it at http://ded-2-nt.nosc.mil/~pub/MSOffice/Winword/virus/WVFIX.DOC.
At one point, a fix was issued for this. It was called scanprot.dot, and its primary purpose was to scan for the Concept virus. However, this tool was somehow confused in the public's eyes as a utility that could identify all macro viruses. Microsoft finally set the record straight. Since that time, many Word macro viruses have cropped up. Here are just a few:
As you might guess, these types of viruses are becoming increasingly popular. They are small, require almost no memory, and are easily concealed in downloadable materials. These viruses do not represent a threat to Internet security, but they can be caught from the Internet. Most of them do little more than corrupt your documents. However, they are a nuisance, and you should take measures to prevent them from infecting your machine. One way to do this is to disable automatically executed macro support in Word.
NOTE: It is reported that the Microsoft Word Wizard will not operate if you disable automatic macro execution. If you are a frequent user of wizards, you may have to make some sacrifices.
Cross Reference: You can find the authoritative sources for information on Word macro viruses at these locations:http://www.datafellows.com/macro/faq.html
http://gasp.berkeley.edu/virus/wordmacro.html
Microsoft FrontPage is recognized as one of the best tools for designing WWW pages. Coupled with Microsoft's Image Composer, FrontPage provides the average user with a total Web solution. Moreover, the product distribution includes a personal Web server. This utility serves Web pages directly from your home or office machine (without requiring the use of an intermediate UNIX server). Thus, files and pages can be kept local.
Unfortunately, early versions of Microsoft's FrontPage Web server were distributed with a Practical Extraction and Report Language interpreter (PERL.exe). If this is placed in the /cgi-bin/ directory, a massive security hole develops. It allows any remote user to execute arbitrary commands on your local machine.
I would not have mentioned this here, except that older demo versions of FrontPage may surface in places other than the Microsoft home page. This is not unreasonable. There are still early versions of Microsoft Internet Explorer circulating on demo CD-ROMs from magazines and such.
Cross Reference: For more information about this hole, check out Microsoft's Web site at http://www.microsoft.com.
O'Reilly's WebSite Server for Windows NT/95 version 1 had a hole. If you have this Web server loaded on your machine, disable the DOS CGI interface. If the DOS CGI interface is enabled, it allows files with a *.BAT command extension to be executed. Through this hole, crackers can execute arbitrary commands on your machine from a remote location (for example, they could effectively delete the contents of your hard disk drive). The fix as reported by ORA is as follows:
Cross Reference: The previous paragraph is excerpted from ORA's WebSite security alert at http://website.ora.com/devcorner/secalert1.html. 03/96. Also, there is a sample CGI application, win-c-sample.exe, that shipped with version 1.0. This application is vulnerable to a buffer-overflow attack.
Cross Reference: Because no one seems to give credit to the individual who discovered the buffer overflow hole, it seems right that I do so. To the best of my knowledge, this hole was identified by a hacker going by the handle Solar Designer.
Cross Reference: For more information about holes in O'Reilly's WebSite Server, check out http://website.ora.com/justfacts/facts.html.
On December 20, 1996, Microsoft unveiled a white paper titled "The Microsoft Internet Security Framework: Technology for Secure Communication, Access Control, and Commerce." In this paper, the company describes various aspects of its Internet security plan. This new conglomeration of technologies has been dubbed the MISF.
MISF purportedly will integrate a series of technologies into Microsoft products, thus making them secure for Internet use. I briefly discussed one of these technologies earlier in this book: the certificate signature scheme for ActiveX controls (or in fact, any code that you specify). It revolves around a technology called Authenticode, a system whereby developers can digitally sign their applications. It consists of a series of programs. By using these, the software developer ultimately earns a Software Publisher's Certificate (SPC), which is used to sign the application. Interestingly, you can sign the application in different ways: as a provider, a commercial software developer, or an individual.
This system works effectively only if the signing party is honest. There is no guarantee that signed code will be safe. Thus, the system actually subjects honest, upright programmers to additional hassle (nonetheless, I am confident this system will become exceedingly popular among developers of Microsoft products). However, there is a darker side to this.
The greatest percentage of falsely signed code (code that is malicious and has been signed as safe) will likely come from individuals. I suspect that many virus developers will adopt this system, because it represents a chance to deposit their code into a largely unwary community (if a control is signed, the average person will probably download it). Because of this, widespread use of such signatures will hurt the little guy. Here is why.
Because the technology is new, there have been no instances of signed malicious code. However, as time passes and signed malicious code surfaces, the average user will be less likely to download software from new companies or lone software developers (certainly, the public will be much less likely to download unsigned code). Moreover, this system may cause even further alienation of foreign developers (more than once, the sense of alienation experienced by foreign developers has been blamed for the high number of viruses believed to have originated on foreign soil). Finally, there is something a bit ominous about having to provide a public key to engage in commerce as a software developer. What happens to the remaining folks who refuse to comply with the program? If they suffer in the market for lack of compliance, antitrust issues may develop (particularly if this becomes the only accepted method of okaying software).
NOTE: In February 1997, members of the famed German hacker group known as the Chaos Computer Club used a signed application to demonstrate the weakness of the Microsoft platform and of application signing generally. On national television, they used this application to gain unauthorized access to a personal computer, start an instance of Quicken, connect to the victim's online bank account, and transfer money from the victim's account to another. This was a crushing blow to the signing model. I explain this in further detail in Chapter 30, "Language, Extensions, and Security."
In any event, Microsoft is at least going in the right direction. Public and private key encryption schemes are among the most secure today. Moreover, the new technologies presented within Microsoft's white paper about MISF suggest that Microsoft is quite serious about solutions in Internet security.
Microsoft Windows NT has a real security model and a good one. The most important element of that security model concerns access control. Access control is a form of security most often seen in UNIX-based operating systems. It involves the control of who can access files, services, and directories. In certain instances, this also involves times during which this access can occur.
NOTE: For basic networking, Novell NetWare has always been a fairly secure platform and has long supported access control. This does not mean NetWare cannot be cracked (see Chapter 18, "Novell"). However, control over file and time access has been an integral part of the Novell NetWare security model.
In security vernacular, DAC is generally referred to as discretionary access control (DAC). DAC involves being able to completely control which files and resources a user may access at a given time. For example, perhaps only a small portion of your staff needs to access Microsoft Excel. In the Windows NT security model, you can deny access to all other users who are unauthorized to use Excel.
In DAC, there are different levels of control. For example, some operating systems or utilities offer only moderate control (perhaps one system might allow an administrator to block user access to directories or partitions). This type of control is not really suitable in large networks, where one or more directories may hold applications or resources that other programs need in order to execute. The Microsoft Windows platform is a good example of this. Most applications written for Windows sport multiple file dependencies. That means the application may need files from different parts of the system in order to function correctly.
NOTE: If you have ever had a bad installation of a product intended to run in Windows, you know something about this. The application so installed will, when executed, forward a series of error messages, requesting files that it cannot locate. In most cases, unless the program locates those files, it will not run (or if it does, it will probably GPF or exit on error).
The degree to which a DAC system can control file and directory access is referred to in security vernacular as granularity. Granularity is, quite simply, an index for measuring just how detailed that access control can be. If, for example, you can choose a directory and restrict access to five files within it to a particular group but also allow all users to access the remaining ten files in that directory, then you are dealing with fairly advanced granularity.
DAC is a technology that has trickled down from defense sources. In defense environments, administrators must be assured that only authorized personnel can access sensitive data.
Cross Reference: For a greater understanding about DAC, how it evolved, and what it means in terms of national computer security, you should read DoD 5200.28-STD, the Department of Defense Trusted Computer System Evaluation Criteria (this publication is more commonly referred to as the Orange Book). It can be found at http://www.v-one.com/newpages/obook.html.
DAC is based on common sense: If crackers do not have access to the files, they cannot crack the machine. Setting proper file permissions is the first phase of securing a Windows NT machine. However, in order to do it, you must enable the NTFS option at time of installation (alas, we must begin at the beginning).
NTFS is the enhanced file system included with the NT distribution. At installation, you are confronted with the option of installing a FAT file system or an NTFS file system. There is a sharp difference between the two. The FAT file system will grant you some security, for you can control user access and authentication. However, for severely granular control (control over each file and directory), you must convert the partition to NTFS. This is a point often missed by new system administrators.
CAUTION: Converting the partition to NTFS provides compressive security but is not infallible. For example, a kid sporting a Linux boot disk (only certain versions of Linux) can effectively bypass all of the file restrictions imposed by the NTFS DAC method (I am quite sure that CS lab administrators will be pleased to hear this). Also, this is not the only type of boot disk that will perform this task. When a file called NTFSDOS.EXE, which is being circulated on the Internet, is placed on a DOS or Windows 95 boot disk, it allows a cracker to bypass all file restrictions. Until this is fixed, NT will never get a higher rating than C2 on the EPL. Only those who rely solely upon Microsoft press releases and bug fixes actually believe that out-of-the-box NT is secure.
As noted, the NTFS security model is not perfect. For example, it is known that in certain distributions (such as 3.51), users without privileges can delete files. Microsoft has acknowledged this fact in an advisory. It involves any instance in which a user creates a file and removes all permissions from it. Technically, that file should still be untouchable to anyone but its author. However, for reasons not yet determined, the unauthorized user can delete the file. As noted in a Microsoft technical article titled "Users Without Permissions Can Delete Files at Server,":
Other problems have been acknowledged. For example, it is reported that if you start the File Manager application in 3.51 using the Office toolbar, file permissions are bypassed. This appears to be inherent only in Microsoft Office 97 applications (specifically, Excel and Word 7.0 for Windows 95). This problem has been corrected in subsequent distributions of these applications. Moreover, it has been reported that one would need increased access authorization to exploit this hole.
In general, however, Windows NT DAC is quite good. It resembles in some ways the DAC scheme implemented under UNIX-based operating systems. At the heart of this process are the theories of file ownership and privileges. Thus, whoever creates a file owns that file. The degree to which other users may examine that file depends on what restrictions were set forth by the administrator.
Note that this does not close every local security hole and that many processes require files to have more liberal ownership than you might like. For example, consider Common Gateway Interface (CGI) scripts used to provide functionality to Web pages (these scripts are commonly used to generate quotes, process mail requests, and access databases). Such scripts must have file permissions that, at the very least, allow outsiders (through the Web server) to access them. Thus, the Web server must have at least partial ownership or privileges to execute these files.
So on your drives, you might have files that can be read by some, written by others, and executed by still others. This presents the very first problem with regard to DAC: it is complicated. For example, on networks where permissions are set not only on files and directories, but also on partitions or network drives, the system administrator can become overwhelmed with the possibilities. For this reason, NT system administrators must be every bit as knowledgeable (and as obsessive) as UNIX system administrators.
However, this is where the process of NT security starts. Before setting up a network, you must first determine who will need access to what. Some utilities are available to make the process easier.
Dump ACL (which incidentally has a shareware version) is probably the most important tool for a new NT administrator. Its function is simple: It gathers all permissions on the box and displays them in consolidated format. By analyzing this data, a system administrator can quickly find misconfigurations, bad privilege schemes, and security holes. The analysis provided by this tool is comprehensive, treating all permissions and privileges on files and directories. It also reports various audit settings. In essence, this is a start of a great security profile, saving the administrator hours of work and providing the output in convenient, table format.
This tool, created by Somar Software, is available at the following location:
This program scans the NT Registry. It was originally written in the Perl programming language, but has since been rewritten in C. It runs through a command shell at a prompt. There are reports that the author will be adding a front end to this at some point in the future.
The primary use for the program is to identify outdated objects or links within the Registry. These may be sources of security problems. This utility makes the search quick and convenient. The command line options afford the administrator an enormous amount of control over how the search is performed.
NT RegFind can be found online at
NTRegmon monitors user-initiated privileged system calls. The authors have a distribution that includes the source. The following URL provides a very detailed explanation of how this service is accomplished:
I should note here that NT does not have the same problems with password authentication and encryption that Windows for Workgroups and Windows 95 have. Nonetheless, you should be aware that the NT password implementation is not entirely secure. For example, the following boasts C code to fashion a DLL file that will sniff passwords. In fact, the utility will sniff the username and password into plain text. That utility (or rather, the source for it) is located here:
Moreover, NT passwords are reportedly vulnerable to brute-force attacks. Some utilities available to strengthen your local passwords follow.
ScanNT is a very powerful utility for checking the strength of your passwords. It can implement an attack that tries 10,000 keys per minute. Like most cracking utilities, it requires that you use a dictionary file (and one sample dictionary file is provided in the distribution).
A demo version of this product is available at the following URL:
NOTE: You must have advanced system privileges to run this application. The company that provides this software also performs password recovery services for businesses.
Before I get into strictly Internet-related NT security, I should say something about suspicious internal activity. It is likely that most attacks will originate from people on your own network (those attacks might just be employees fooling around, or they could derive from a mole for a competitor). To keep an eye on internal security, there are a few utilities you should know about.
Microsoft has an excellent product called the Systems Management Server. Contained in this application is a program called Network Monitor (Netmon). This product, when used in the wrong hands, can reveal vital information trafficked over the network, including but not limited to passwords. This product is the equivalent of a sniffer. For more information, check out the following URL:
IP-Watcher by Engarde, a veteran in the field of security that offers other security products, is the equivalent of a very powerful activity sniffer. Its most valuable quality is that it provides a technique of logging. It can catch internal security violations and record these instances. This is excellent for preparing evidence against unlawful activity. This tool should be restricted from unauthorized or untrusted users. IP-Watcher is a very powerful tool. For example, according to documentation provided by Engarde:
Cross Reference: The previous paragraph, excerpted from IP-Watcher Risks: Quick Overview, can be found online at http://www.engarde.com/software/ipwatcher/risks/overview.html.
More information about IP-Watcher can be found online at
This section examines some of the problems that you may encounter from the outside world. Following are ways to subvert the security of NT and effect denial-of-service attacks against NT. If you run a Windows NT Web server, expect bozos from the void to try any or all of these techniques to harass you or render your server inoperable.
Microsoft Windows NT 4, using Internet Information Server 2.0 or earlier, contains a serious bug that allows outsiders to completely mangle your Web server. To test whether you are vulnerable to this attack, initiate a Telnet session to port 80 and type the following command:
GET ../..
If you are vulnerable, your Web server will die and the machine will likely crash. Note that this bug is not evident in IIS 3.0. To fix the problem, obtain Service Pack 1a and Service Pack 2 from Microsoft.
Port 80 is the standard port on which Web servers are normally run. To reach this port by Telnet, you must specify both the address of the targeted server and the port (see Figure 16.7).
FIGURE 16.7.
Initiating a Telnet session to port 80 in Windows 95.
Certain distributions of NT are vulnerable to a denial-of-service attack. This attack will virtually kill the box. The attack involves sending the CPU of the NT server into 100 percent utilization. This effectively brings the machine to a grinding halt. The attack is implemented by a program that consists of only five lines of code. That program (called CPUHog, written by Mark Russinovich) is located here:
The problem was covered extensively in a December 1996 article by Eamonn Sullivan in PC Week Magazine. Sullivan writes:
Mark Russinovich is a consultant with Open Systems Resources, Inc. Russinovich maintains a page at http://www.ntinternals.com/. On that page are various utilities related to Windows NT security and system integrity, including one program that crashes NT boxes entirely. This utility has demonstrated some fairly significant weaknesses in the operating system. Russinovich and his associate, Bryce Cogswell, have a book coming out about Windows NT titled Windows NT Internals. I recommend it.
Meanwhile, that is not the only denial-of-service attack that can be implemented against Windows NT. Other attacks involve simply initiating a Telnet session to certain ports. Naturally, these ports have to open for the attacks to be successful. However, I would bet that a significant percentage of system administrators fail to examine the higher range ports. For example, initiate a Telnet connection to port 135 or port 1031. After you receive a confirmation that you have contacted the port, send several lines of text and disconnect. If the machine has a vulnerable distribution, the CPU of the target will immediately jump to extreme utilization (this will incapacitate the target). One Perl script being circulated across the Internet automates this process.
NOTE: Microsoft has issued a patch for the problem related to port 135, but as of this writing there is no fix for port 1031. In fact, reports as recent as February 2, 1997, reveal that many ports are vulnerable to this attack.
For the moment, it is likely that such holes will continue to surface. Therefore, system administrators should enable not only packet filtering, but also deep logging. If your network is victimized by some malicious character in the void, you will want his IP address.
NT Server version 4.0 is also reportedly vulnerable to a denial of DNS (domain name service) attack. Crackers can implement this by sending a response packet to the DNS server of an NT DNS server. The server receives the response packet, cannot process the transaction, and promptly crashes. Some sources indicate that Service Pack 3 will provide a fix.
There is also reportedly a bug that allows a remote user to gather important information about an NT box. This is done using the NBTSTAT command. The user issues an NBTSTAT--a query on the targeted host to get that host's name. The resulting name is placed in the lmhosts file. Subsequent network queries about the host will reveal shared out directories, a list of users, and other vital network information (the information gathered is roughly equivalent to that in UNIX when utilizing the showmount command and rusers).
The Microsoft platform uses a protocol called the Server Message Block (SMB) protocol. SMB was introduced sometime in 1987. Like most protocols currently running on the Internet, SMB is based on the client/server model.
Cross Reference: Hard-core documentation on the internal specifications of SMB can be found at ftp://ftp.microsoft.com/developr/drg/CIFS/. This site is the main distribution point for Microsoft's documentation on SMB. The file of greatest importance for users wanting to learn the advanced technologies behind SMB is called SMB-CORE.PS. This file is in PostScript, and you will require a PostScript reader to view it.
For purposes of brevity, I will not launch into an exhaustive review of SMB. Basically, it is a network file-sharing protocol based on the client/server model. It is used to share files, directories, printers, and serial communication links. It can be run over (and in conjunction with) a number of other protocols, including
Under certain circumstances, a talented cracker can exploit the SMB protocol to gain access to shared-out directories on an NT 3.5 or 3.51 box. There are two different aspects to this; the first involves a denial-of-service attack that is implemented by disabling the target host. This is accomplished in the following manner:
A cracker using an SMB client package (SAMBA) sends the following message to the SMB server on the remote NT box:
DIR..\
This crashes the target. Microsoft acknowledged this problem and hastily distributed a fix, which you should obtain if you are running 3.5 or 3.51.
Cross Reference: I recommend reading the Microsoft advisory on this problem; this advisory can be found online at http://www.microsoft.com/kb/articles/q140/8/18.htm.
The second hole is more complex and is not likely to be penetrated by the average cracker. It is reported that shared-out directories can be mounted from a remote location using the SAMBA client. This is a complex attack, involving advanced methods of spoofing. As a July 1996 technical paper explains:
Cross Reference: The previous paragraph is excerpted from an RFC titled "Common Internet File System Protocol (CIFS/1.0)," by I. Heizer, P. Leach, and D. Perry. It can be found online at ftp://ietf.cnri.reston.va.us/internet-drafts/draft-heizer-cifs-v1-spec-00.txt.
Such an attack is extremely complex. Few crackers possess the knowledge and expertise to implement such a technique.
This chapter has provided only a cursory overview of Microsoft platform security. However, as you progress in this book, the information offered here will serve you well. As I discuss other techniques of attacking remote servers, you will be able to apply that new information to what you have learned here. In reality, a multi-volume encyclopedia could be written about Microsoft security. Before you progress to the next chapter, I want to leave you with some resources on Microsoft security.
Microsoft Windows NT 3.5: Guidelines for Security, Audit, and Control. Microsoft Press. ISBN: 1-55615-814-9.
Windows NT Administration: Single Systems to Heterogeneous Networks. Marshall Brain and Shay Woodard. Prentice Hall. ISBN: 0-13-176694-5. 1994.
Inside the Windows NT File System. Helen Custer. Microsoft Press. ISBN: 1-55615-660-X. 1994.
NT Server: Management and Control. Kenneth L. Spencer. Prentice Hall, October 1995. ISBN: 0-13-107046-0.
Microsoft Windows NT TCP-IP Guide. Microsoft Press. ISBN: 1-55615-601-4. 1993.
Managing Windows NT Server 4. Howard Hilliker. New Riders. ISBN: 1-56205-576-3.
Windows NT 4 Electronic Resource Kit. Sams.net. ISBN: 0-67231-032-5.
Inside Windows NT Server 4. Drew Heywood. New Riders. ISBN: 1-56205-649-2.
Peter Norton's Complete Guide to Windows NT 4.0 Workstation. Peter Norton and John Paul Mueller. Sams Publishing. ISBN: 0-67230-901-7.
"A Guide to Understanding Discretionary Access Control in Trusted Systems." Technical Report NCSC-TG-003. National Computer Security Center. 1987.
"Authentication and Discretionary Access Control." Paul A. Karger. Computers & Security, Number 5, pp. 314-324, 1986.
"Extended Discretionary Access Controls." S. T. Vinter. SympSecPr, pp. 39-49, IEEECSP, April 1988.
"Beyond the Pale of MAC and DAC--Defining New Forms of Access Control." Catherine J. McCollum, Judith R. Messing, and LouAnna Notargiacomo. SympSecPr, Research in Security and Privacy, pp. 190-200, IEEECSP, May 1990.
© Copyright, Macmillan Computer Publishing. All rights reserved.