Network and Host Misconfigurations One of the biggest drivers behind security breaches is the misconfigurations of the targets. This can bring down any site at any time, regardless of the security measures taken. (For example, when the Justice Department server was cracked, DOJ was running a firewall. As they discovered, a misconfigured firewall might as well be no firewall at all.) Misconfiguration can occur at any point along the distribution chain, all the way from the factory to your office. For example, certain network utilities, when enabled, open serious security holes. Many software products ship with these utilities enabled. The resulting risks remain until you deactivate or properly configure the utility in question. A good example would be network-printing utilities. These might be enabled in a fresh install, leaving the system insecure. It's up to you to disable those utilities. However, in order to disable them, you first have to know of their existence. Seasoned network administrators laugh about this. After all, how could anyone be unaware of utilities running on their box? The answer is simple: Think of your favorite word processor. Just how much do you know about it? If you routinely write macros in a word-processing environment, you are an advanced user, one member of a limited class. In contrast, most people use only the basic functions of word processors: text, tables, spell check, and so forth. There is certainly nothing wrong with this approach. Nevertheless, most word processors have more advanced features, which are often missed by casual users. Note There is an often-quoted axiom in computing publishing circles, and it goes like this: "Eighty percent of the people use only twenty percent of a program's capabilities." For example, how many readers that used DOS-based WordPerfect knew that it included a command-line screen-capture utility? It was called Grab. It grabbed the screen in any DOS-based program. At the time, that functionality was unheard of in word processors. The Grab program was extremely powerful when coupled with a sister utility called Convert, which was used to transform other graphic file formats into *.wpg files, a format suitable for importation into a WordPerfect document. Both utilities were called from a command line in the C:\WP directory. Neither were directly accessible from within the WordPerfect environment. Despite the power these two utilities possessed, they were not well known. Similarly, users might know little about the inner workings of their favorite operating system. For most, the cost of acquiring such knowledge far exceeds the value. Oh, they pick up tidbits over the years perhaps they read computer periodicals that feature occasional tips and tricks, or perhaps they learn because they are required to at their job or another official position where extensive training is offered. No matter how they acquire the knowledge, nearly everyone knows something cool about their operating system. Keeping up with the times is difficult, though. The software industry is a dynamic environment, and users are generally two years behind development. This lag in the assimilation of new technology only contributes to the security problem. When an operating system develop ment team materially alters its product, many users are suddenly left knowing less. Microsoft Windows 95 is a good example. When it was released, 95 had new support for all sorts of different protocols protocols with which the average Windows user wasn't familiar (and migrating to a Registry-based system was quite a leap). It is possible (and probable) that users can be unaware of obscure network utilities. That's one scenario. Utilities and services are enabled, and this fact is unknown to the user. These services, while enabled, can foster security holes of varying magnitude. When a machine configured in this manner is connected to the Net, it is a hack waiting to happen. Such problems are easily remedied. The solution is to turn off (or properly configure) the offending utility or service. Typical examples of this type of problem include the following: Network printing utilities Remote system-configuration utilities File-sharing utilities Default passwords Sample CGI programs and scripts Of the examples listed, default services (i.e. file sharing, printing, or Web-based sample scripts) with known vulnerabilities are the most common. There is also the reverse situation. Instead of being unaware of active services that threaten your security, you might be unaware of inactive utilities that could strengthen your security. Many operating systems have built-in security features. These features can be quite effective when enabled, but remain worthless until you activate them. Again, it boils down to knowledge. If you're lacking in knowledge, you are bound to suffer needlessly. But, unfortunately, it doesn't end there. There are other problems facing the modern network administrator. For instance, certain security utilities are simply impractical. Consider security programs that administrate file-access privileges and restrict user access depending on security level, time of day, and so forth. Perhaps your small network cannot operate with fluidity and efficiency if advanced access restrictions are enabled. If so, you must take that chance, perhaps implementing other security procedures to compensate. In essence, these issues are the basis of security theory: You must balance the risks against practical security measures, based on the sensitivity of your network data. You'll notice that most network security problems arise, however, from a lack of education. For that reason, education is a recurring theme throughout this book. Note Education issues are entirely within your control. That is, you can eliminate these problems by providing yourself or your associates with adequate education. (Put another way, crackers are most effective at gaining entry into networks where such knowledge is lacking.) Operating System and Application Flaws As if the complexity surrounding advanced security features combined with the fact that operating systems are shipping with dozens of enabled services weren't enough of a problem, we face an additional challenge: vulnerabilities introduced by flawed programming. Unfortunately, these forces are well beyond your control. That's too bad because here's a fact: Vendor failure is one of the most common sources of security problems. Anyone who subscribes to a bug or security mailing list (such as BUGTRAQ) knows this. Every day, bugs or programming weaknesses are found in network software. Every day, these are posted to the Internet in advisories or warnings. Unfortunately, not all users read such advisories. System flaws needn't be classified into many subcategories here. It's sufficient to say that a system flaw is any flaw that causes a program to do the following: Work improperly (under either normal or extreme conditions) Allow crackers to exploit that weakness (or improper operation) to damage or gain control of a system There are two primary types of system flaws. The first type, which I call a primary flaw, is a flaw nested within your operating system's security structure. It's a flaw inherent within a security-related program. By exploiting it, a cracker obtains one-step, unauthorized access to the system or its data. The Netscape Secure Sockets Layer Flaw In January 1996, two students in the Computer Science department at the University of California, Berkeley, highlighted a serious flaw in the Netscape Navigator encryption scheme. Their findings were published in Dr. Dobb's Journal. The article, "Randomness and the Netscape Browser," was written by Ian Goldberg and David Wagner. In it, Goldberg and Wagner explain that Netscape's implementation of a cryptographic protocol called Secure Sockets Layer (SSL) was inherently flawed. This flaw would allow secure communications intercepted on the WWW to be cracked. This is an excellent example of a primary flaw. | Conversely, there are secondary flaws. A secondary flaw is any flaw arising in a program that, although totally unrelated to security, opens a security hole elsewhere on the system. In other words, the programmers were charged with making the program functional, not secure. No one (at the time the program was designed) imagined cause for concern, nor did they imagine that such a flaw could arise. Secondary flaws are far more common than primary flaws, particularly on platforms that have not traditionally been security oriented. An example of a secondary security flaw is any flaw within a program that requires special access privileges in order to complete its tasks (in other words, a program that must run with root or superuser privileges). If that program can be attacked, the cracker can work through that program to gain special, privileged access to files and services. Whether primary or secondary, system flaws are especially dangerous to the Internet community when they emerge in programs that are used on a daily basis, such as FTP, DNS, SSH, or Telnet. These mission-critical applications form the heart of the Internet and cannot be suddenly taken away, even if a security flaw exists within them. To understand this concept, imagine if Microsoft Word were discovered to be totally insecure. Would people stop using it? Of course not. Millions of offices throughout the world rely on Word. However, there is a vast difference between a serious security flaw in Microsoft Word and a serious security flaw in the Apache Web server. The serious flaw in Apache would place hundreds of thousands of servers (and therefore, millions of accounts) at risk. Because of the Internet's size and the services it now offers, flaws inherent within its security structure are of international concern. To understand the true scope of this problem, take a look at just some of the vulnerabilities discovered in services during 1999 and 2000 that have allowed "root" or "administrative" level compromises: The wu-ftpd FTP daemon shipped in many BSD and Linux distributions The University of Washington imapd daemon ISC's Bind (an implementation of DNS) Numerous services found in Sun Solaris Microsoft's IIS The Linuxconf configuration utility SSH (Secure Shell) and that's just a small sample. At the time of this writing, based on the Security Alert Consensus (SAC, a weekly vulnerability newsletter put out by SANS, Network Computing, and Neohapsis), there are new vulnerabilities being discovered at the rate of 10 30 per week. We will go into the entire process of vulnerability research and publication in greater detail in Part III, "Hacking 101: The Tricks of the Trade." For now, know that when a flaw is discovered within sendmail, FTP, DNS, SSH, or other indispensable elements of the Internet, programmers develop patches (small programs or source code) to temporarily solve the problem. These patches are distributed to the world at large, along with detailed advisories. This brings us to vendor response. Deficiencies in Vendor QA Efforts and Response Two summers ago I found myself sitting in on a meeting between Microsoft officials and one of their larger clients. During this meeting the topic of the hidden flight simulator in Excel came up. The client wanted to know what a flight simulator was doing in a spreadsheet pro gram. They wanted to know how much room it was taking up in the program, in memory, and on their workstations. But above all else, they wanted to know how it had gotten past Microsoft's QA/QC efforts. A few lines of code is one thing, but an entire flight simulator is quite another. Microsoft's response? That they knew it was in there all along, and that this "Easter egg" was just something they let their programmers in Redmond do for fun. "It's part of the development culture," the Microsoft representatives said. Note If you weren't aware of the embedded gift in your Microsoft Excel application, fire up a copy of MS Excel that shipped in Office 97. Press F5 (to go to a location), type X97:L97, and then click OK. Press the Tab key. Then hold down Ctrl and Shift at the same time, and simultaneously click the "chart wizard" button once it's the one with the colorful bar graphs. Viol instant flight simulator. The first word that came out of my mouth began with a "B" and ended with a "T." But what else was Microsoft going to say? Whoops? Sorry? We missed the few thousand lines of extra code that just happened to be a mini video game? So in the spring of 2000 when "rain forest puppy," an infamous and clever member of the underground reported that the phrase "Netscape Engineers are Weenies" had been used as a key and served as a pseudo back door into servers running FrontPage 98 extensions, I couldn't wait to hear Microsoft's excuse for this one. Was this part of the development culture as well? Back doors and cheap shots at the competition's development staff? It turns out Microsoft initially admitted to the existence of the egg that was all over their face, but then quickly masked it with an even bigger problem that was released a bit later. Check out the updated advisory at http://www.microsoft.com/technet/security/bulletin/ms00-025.asp at no point is there any mention of the word "weenie," back doors, or other such shenanigans. Microsoft has appeared to have swept this one under the carpet as well. Note One more thing I'd like to note about the Excel "Easter egg" story. When MS offered this client the "We knew about it" excuse, this client demanded a list of other back doors and Easter eggs MS supposedly knew about. MS agreed and then never delivered on its promise. Makes you wonder, huh? So if the largest software vendor in the world can't control what is entering its code, is there any hope for the rest of the industry? The simple fact of the matter is that many software companies don't have adequate quality control/quality assurance programs in place. Microsoft is an easy target as it has SO MANY software products in the marketplace, but the truth is that a lot of companies are guilty of this as well. Who winds up ultimately paying for these oversights? We do the consumers. We're the ones who get hammered when these oversights get used for breaching our networks. However, the vendors claim that their customers want more features, not more security. If that's not the case I encourage the readers of this book to make their voices heard. Tell your vendors how you really feel. Let's take a look at a few of specific examples of oversights and their impact on the scene. Allaire's ColdFusion Problems The beginning of 1999 was a great time for Allaire. Their product, ColdFusion, had taken the industry by storm in giving Web developers some powerful but easy tools for designing Web sites that interacted with database back-ends. In the spring of 1999, however, rain forest puppy reported a number of problems with the CGI sample scripts Allaire shipped with ColdFusion. Remote attackers could leverage these scripts to execute code on the vulnerable machines, retrieve protected files, and ultimately compromise the targeted machine. A few months later, the L0pht reported more problems. Although administrators probably shouldn't have been installing sample scripts on production servers to begin with, ignorance had prevailed once again. Soon black hat hackers all over the planet were hacking ColdFusion servers at an alarming rate, and Allaire had a major public relations issue on its hands. Allaire was slow to react, as this was its first exposure to the harshness known as the information security community. Eventually Allaire released advisories urging customers to remove the scripts and patch their servers, but the damage was done. Hundreds upon hundreds of machines had already been hit, and the trend continued throughout the rest of the year. Eventually the chaos subsided, and attackers moved on with more popular attack trends. Allaire has since then beefed up its internal security efforts, released new, more secure versions of ColdFusion, solicited third-party application reviews, and launched an awareness heightening campaign within its user base. Allaire is now one of the most pro-active vendors out there when it comes to security. However, Allaire has been paying for its sins ever since. In June 2000 when SANS (System Administration, Networking, and Security) released its report on the Top 10 vulnerabilities found on the Net today, Allaire's ColdFusion problem had crept up once again it was on the charts because it had been a BIG problem. Even though the vulnerabilities had been addressed for close to a year, people remembered them. The simple fact of the matter was that the vulnerability hit the security scene really hard, and organizations were hurt pretty badly by it. Vulnerable servers based on older versions of ColdFusion still creep up once in a while, and administrators who suffered through the siege of 1999 were slow to forgive. Fortunately, Allaire learned from its mistakes and its customers will benefit from this. However, the people who were hacked because of ColdFusion's earlier problems paid the price of this education. Microsoft PPTP Another example that wasn't exploited en masse but is definitely flawed is Microsoft Corporation's implementation of Point-to-Point Tunneling Protocol (PPTP). PPTP is a protocol that's used to build Virtual Private Networks (VPNs) over the Internet. VPNs enable secure, encrypted traffic between corporate link-points, thus eliminating the need for leased lines. (Through VPNs, corporations can use the Internet as their global leased line.) Microsoft's implementation of PPTP had been lauded as one of the most solid security measures you could employ. In fact, it even won an award or two in consumer computing magazines, Microsoft's PPTP had been written up as an industry standard solution. That's great. One month before the second edition of this book went to press, Microsoft's PPTP was broken by two well-respected encryption authorities, Bruce Schneier and Mudge. The press release rocked the security world. Here's a portion of that release: Doesn't Microsoft know better? You'd think they would. The mistakes they made are not subtle; they're "kindergarten cryptographer" mistakes. The encryption is used in a way that completely negates its effectiveness. The documentation claims 128-bit keys, even though nothing remotely close to that key length is actually used. Passwords are protected by hash functions so badly that most can be easily recovered. And the control channel is so sloppily designed that anyone can cause a Microsoft PPTP server to go belly up. Frequently Asked Questions, Microsoft's PPTP Implementation. Counterpane Technologies. http://www.counterpane.com/pptp-faq.html That doesn't sound as if Microsoft's version of PPTP is very secure, does it? Researchers found five separate flaws in the implementation, including holes in password hashing, authen tication, and encryption. In short, they discovered that Microsoft's implementation of PPTP was a disaster. I am willing to bet that you never saw that advisory. If you didn't, you're like information officers in companies all over the country. They believe that the products they're using are secure. After all, Microsoft is a big, well-established company. If they say their products are secure, it must be true. That's the mindset of the average network manager these days, and thousands of companies are at risk because of it. Note Mistakes of this sort are made all the time. Here's an amusing example. It was discovered a while ago that the encryption scheme in Microsoft Windows NT could be effectively turned off. The attack is now known as the "You Are Now in France" attack. It works like this: France did not allow private citizens access to strong encryption. If Windows NT interpreted that your location was France, the operating system's strong encryption was disabled. Not very secure, is it? The bottom line is this: You're on your own. That is, it's up to you to take measures to secure your data. Don't count on any vendor to do it for you. If you do, you're setting yourself up for a serious fall. Vendor Response Vendor response has traditionally been good, but this shouldn't give you a false sense of security. Vendors are in the business of selling software. To them, there is nothing fascinating about someone discovering a hole in the system. At best, a security hole represents a loss of revenue or prestige. Accordingly, vendors quickly issue assurances to allay users'fears, but actual corrective action can sometimes be long in coming. The reasons for this can be complex, and often the vendor is not to blame. Sometimes, imme diate corrective action just isn't feasible, such as in the following cases: When the affected application is comprehensively tied to the operating system When the application is widely in use or is a standard When the application is third-party software and that third party has poor support, has gone out of business, or is otherwise unavailable In these instances, a patch (or other solution) can provide temporary relief. However, for this system to work effectively, all users must know that the patch is available. Notifying the public would seem to be the vendor's responsibility and, to be fair, vendors post such patches to security groups and mailing lists. However, vendors might not always take the extra step of informing the general public. In many cases, it just isn't cost effective. Once again, this issue breaks down to knowledge. Users who have up-to-date knowledge of their network utilities, of holes, and of patches are well prepared. Users without such knowledge tend to be victims. That, more than any other reason, is why we wrote this book. In a nutshell, security education is the best policy. Lack of Qualified People in the Field So if we didn't have vendors and programmers putting out buggy code, operating systems shipping with every possible service enabled and running by default, sample scripts installed everywhere, and a slew of misconfigurations and mistakes being made, we'd still have one major problem not enough people have information security experience. IT managers are having a hard enough time these days finding competent network engineers, system administrators, and programmers, much less security professionals. Making matters worse, you can't get training that will instantly make you an information security specialist. You have to take it in steps. First, become competent with routers, switches, and firewalls. Learn the ins and outs of UNIX and Windows NT. Learn the basics surrounding cryptography and programming, and obtain a SOLID understanding of TCP/IP. And then you can BEGIN to learn the intricacies surrounding security, incident response, and other late night and stressful activities. Excited yet? The lack of personnel contributes to misguided or absent information security programs within organizations. Policies remain incomplete or nonexistent. Companies operate without a threat identification effort. Machines go unpatched, development efforts go awry, logs go unmonitored, and users remain uneducated. In short, we find ourselves living in the world that we exist in today. It doesn't have to be like this, however. If administrators and users held up their areas of responsibility from a security standpoint, we wouldn't be needing fleets of all-encompassing infosec gurus. We're hoping for the day when security practices are as common as running system backups part of any good system administrator's job. Unfortunately, we believe that day is a ways off. The funniest part about this crazy field is that most of us who are considered information security professionals got here by accident. However, as time goes on, it continues to get easier to exchange knowledge and learn at a quicker pace. More books are coming out, more conferences exist, more papers are being written, information security portals and sites continue to improve, and the security mailing lists that exist on the net are only getting better. Security-related certifications like the CISSP and the SANS GIAC programs are starting to crank out more and more qualified people. In short, it's getting easier to learn as there is a lot more out there then there was even two to three years ago. Suffice it to say, however, that there will be a shortage of good security people for quite some time. 
| 