hack book hack proofing your network internet tradecraft phần 10 pdf

teaching well-meaning people how to find security problems, you are also teaching the bad guys. But, recall that some hackers already have access to such information and share it among themselves. The currently recommended approach is to try to contact the vendor before making the details of the problem publicly known. You must try to work with them to release a fix quickly at the same time you reveal the security problem to the public. In this way, you obtain the benefits of full disclosure, while at the same time releasing a fix in a timely manner. Yet even today, you must be very careful that the vulnerability information does not fall into the wrong hands while you are working with the vendor to produce a fix. For example, in July of 1999, a vulnerability in the rpc.cmsd service in Sun Solaris was discovered. One of the exploits found for this vul- nerability seems to have been authored by a well-known computer security company. It seems that they were researching the problem and somehow the exploit leaked to the computer underground. More recently, in June of 2000, a vulnerability in the capability subsystem of the Linux kernel was discovered that allowed local users to get root privi- leges. The vulnerability was first published by Peter van Dijk, who believed it was used to break into somebody’s systems. From Peter van Dijk [06/07/2000]: I do not have complete info right now, but here’s the scoop: Local users can gain root thru a _kernel_ bug in Linux 2.2.15 and some earlier versions. This is fixed in 2.2.16pre6. Linux 2.0.x is not vulnerable, I do not know of any other vulnerable OSs. The bug is that is it somehow possible to exec sendmail without the CAP_SETUID priv, which makes the setuid() call that sendmail eventually does to drop privs, fail. Big chunks of code that were never meant to run as root then do run as root, which is of course easily exploitable then. This is just about all the info I have, I do not have the exploit but I know that some black hats do have it. A couple of boxes already got completely trashed after being rooted through this hole, which is why I am making this public right now. I did not discover this bug, I only extrapolated from the small info I had: ‘it has to do with capsuid’ ‘sendmail is vulnerable, crond is not’. Some reading of the kernel source then suggested the above to me, which has been confirmed by a more knowledgeable source. It was then discovered that the vulnerability had already been found by someone else who had contacted some of the kernel developers to create a fix, but somehow the information leaked to the computer underground. From Roger Wolff: Wojciech Purczynski (wp@elzabsoft.pl) found this and wrote a proof-of-concept exploit. He discussed this with the appropriate people to make sure fixes were available before he would release the exploit and the story. 412 Chapter 15 • Reporting Security Problems www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 412 In the meanwhile, hints about this have leaked, and it seems someone put all the hints together, and found out what was going on. By now a fix is available for the Linux kernel, and the workaround in sendmail. Later on, Wojciech Purczynski posted to the Bugtraq mailing list an explana- tion of the vulnerability and a proof-of-concept exploit he had created. But Gerrie Mansur followed up with a message stating his belief that the exploit created by Wojciech was used to break into his systems before they where made public. From Gerrie Mansur: This story isn’t completely true. I’ve given the Dutch police department of cybercrime proof that the exploit written by Wojciech Purczynski, was used on the 2 wiped boxes. I don’t know what you mean by ‘He discussed this with the appropriate people’ and ‘ hints about this have leaked ’ but the ‘proof of concept’ exploit which he wrote were in the hands of Dutch script kiddies. Reporting Security Problems • Chapter 15 413 www.syngress.com Keep reading! Reading security reports by organizations that subscribe to the full disclo- sure security philosophy is a great way to learn about security problems and how to find them. Reports by these organizations usually provide suf- ficient information for you to independently verify the problem, and sometimes include step-by-step descriptions of how they found them. If you work as an information security professional, you’ll probably need to read these lists anyway to make sure that your systems are secure against the latest published vulnerabilities. Most of the security mailing lists will publish the vulnerability information regardless of whether the vendor has been notified. It won’t be enough to watch the reports from the vendors, as sometimes they will be finding out at the same time as everyone else in the world. There will always be a few researchers out there who hold a grudge against some vendor, or who are too lazy to track down the right place to report the problem. You might as well go the extra step and look at the published vulner- abilities as your continuing education after reading this book. Techniques are constantly evolving, and you’ll need to keep up. Just a few years ago, buffer overflows were known to exist, but weren’t widely used. Now, a huge portion of the vulnerabilities and exploits relate to buffer overflows. For IT Professionals 95_hack_prod_15 7/13/00 12:28 PM Page 413 I think that there’s nothing ethical about how this bug came to the surface. It also isn’t true that hints about this where leaked—not to me—a reconstruction of facts and 7 hours of disk editing and the quick analyses of those facts by Peter van Dijk did the job. As you can see, you must be very careful with this sensitive information, how you protect it, whom you share it with, and how long you keep it private. Reporting Security Problems to Vendors Trying to contact vendors to inform them about security problems can some- times be difficult. Vendor commitment to security varies widely. Some vendors only allow you to provide product or service feedback via their customer sup- port department, and will not have a special procedure to handle security problems. Some will not even allow you to give feedback unless you are a cur- rent licensed customer. There have even been a few cases when vendors have threatened retaliation against the person who found the hole if he or she intended to publish it. Under such circumstances, sometimes you are left with little choice but to go to the public first with information about security prob- lems—anonymously, if necessary. Other vendors will have security reporting procedures that bypass the cus- tomer service bureaucracy, which allows them to respond quickly to security problems. This will normally take the form of a security contact that can be reached via an e-mail address or telephone number as shown in Table 15.1. When reporting security problems to vendors, include as much information as possible. If you are reporting a problem in a software product, include what platform you run, your hardware configuration, the date and time you found the problem, other software you may have installed, and what you were doing when you found the problem. Remember to always include version numbers and a way for the vendors to contact you. Unless the vendors can reproduce the problem you are reporting, they will likely not acknowledge it and will not be able to fix it. You should also make sure you’ve not found an already known security problem by checking the vendor’s knowledge base, bug reporting system, secu- rity advisories, and freely available vulnerability databases, such as Common Vulnerabilities and Exposures (CVE) (http://cve.mitre.org) and the SecurityFocus.com Vulnerability Database (www.securityfocus.com/bid). Do not set your expectations too high regarding how long it will take a vendor to produce a fix. While it may take you a few hours to come up with a fix for the problem, companies act much slower—the larger the company, the slower it tends to be. Don’t expect to report a security problem on a Friday afternoon and have a fix by Monday morning. 414 Chapter 15 • Reporting Security Problems www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 414 Table 15.1 List of Vendors with Their Corresponding E-Mail Contact for Security Matters Vendor E-mail Contact Allaire mgin@allaire.com Alt-N issues@altn.com Apache security@apache.org Debian security@debian.org BSDI problems@bsdi.com Caldera security@calderasystems.com CheckPoint cpsupport@ts.checkpoint.com Cisco security-alert@cisco.com Cobalt security@cobalt.com FreeBSD security-officer@freebsd.org Gordano support@gordano.com HP security-alert@hp.com IBM security-alert@austin.ibm.com IpSwitch Imail dkarp@ipswitch.com ISC BIND bind-bugs@isc.org KDE submit@bugs.kde.org Lotus security@lotus.com Microsoft secure@microsoft.com NetBSD security-officer@netbsd.org Novell fberzau@novell.com frank@novell.com ncashell@novell.com bill_olsen@novell.com OpenBSD deraadt@openbsd.org Qualcomm Qpopper qpopper@qualcomm.com Qualcomm Eudora eudora-bugs@qualcomm.com win-eudora-bugs@qualcomm.com mac-eudora-bugs@qualcomm.com Red Hat bugs@redhat.com SCO security-alert@sco.com Slackware security@slackware.com SGI security-alert@sgi.com Sun security-alert@sun.com SuSE security@suse.de TurboLinux k8e@turbolinux.com WarFTPD jgaa@jgaa.com Wu-FTPD wuftpd-members@wu-ftpd.org Reporting Security Problems • Chapter 15 415 www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 415 Once received, your report must first be read, analyzed, and prioritized. If you did not provide enough information to reproduce the problem, then the vendor must contact you and ask a few questions. This can go on for a while. Once the problem is reproduced, its repercussions may need to be filtered up the management chain of command. Engineers need to be pulled from whatever they are working on to work on a fix. Depending on the complexity of the problem, this may take a while. Then the fix must be regression tested. Regression testing ensures that the older code still works with the new changes. Finally, a security advisory must be written and its release coordinated with you. In reality, few large companies can produce a fix in less than two weeks. You should work with the company and be patient with them as long as you believe they are making a good faith effort in creating a fix in a timely manner. That said, there are circumstances where you will want to release information about the security problem to the public before the company has completed the fix. For example, if you feel that you have allowed plenty of time for the vendor of the product to provide a fix and they haven’t done so, and you feel they are not making a good faith effort to produce a fix quickly and they are dragging things out, you may want to release information about the security problem. Another instance where you may want to release information about the security problem before the vendor has a fix ready is when you believe the problem is being actively exploited. In such a case, it is better to release the information early so that people have a chance to protect their systems, rather than to wait for an official fix. Many systems may be compromised before the fix is ready. Even if the owners of these systems cannot patch them yet, they might like to have the option of taking them offline until the fix is ready, or they may want to employ an Intrusion Detection System (IDS) to watch for attacks. Beware that if you release information to the public without working with the vendor or waiting until they have a fix ready, and are willing to publish the information, it is very unlikely the vendor will credit you with finding the vul- nerability in their advisory or other documentation. For example, Microsoft has a policy document called “Acknowledgment Policy for Microsoft Security Bulletins,” which can be found at www.microsoft.com/technet/security/bul- letin/policy.asp. Presented here is a portion of this policy, which states: No vendor can develop security patches overnight. Microsoft prod- ucts run on thousands of different manufacturers’ hardware, in millions of different configurations, and in conjunction with count- less other applications. Our patches must operate correctly on every single machine. This is a significant engineering challenge under any conditions, but it is even more difficult when details of a vulnerability have been made public before a patch can be devel- oped. In such cases, speed must become our primary considera- tion, in order to protect our customers against malicious users who would exploit the vulnerability. 416 Chapter 15 • Reporting Security Problems www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 416 The responsibility for Microsoft’s products rests with Microsoft alone, and we take that responsibility very seriously. However, there has traditionally been an unwritten rule among security profes- sionals that the discoverer of a security vulnerability has an obliga- tion to give the vendor an opportunity to correct the vulnerability before publicly disclosing it. This serves everyone’s best interests, by ensuring that customers receive comprehensive, high-quality patches for security vulnerabilities but are not exposed to malicious users while the patch is being developed. Once customers are pro- tected, public discussion of the vulnerability is entirely in order, and helps the industry at large improve its products. Many security professionals follow these practices, and Microsoft wants to single them out for special thanks. The acknowledgment section of our security bulletins is intended to do this. When you see a security professional acknowledged in a Microsoft Security Bulletin, it means that they reported the vulnerability to us confidentially, worked with us to develop the patch, and helped us disseminate information about it once the threat was eliminated. They minimized the threat to customers everywhere by ensuring that Microsoft could fix the problem before malicious users even knew it existed. For comparison purposes, we present a portion of the disclosure policy used by someone who releases vulnerability information. This is from the RFPolicy, the policy that Rain Forest Puppy, one of the contributors to this book, uses when disclosing a new hole he has found: B. The MAINTAINER is to be given at least 48 hours from the DATE OF CONTACT, which is to be inclusive of 2 partial working days (in respects to the ORIGINATOR), to respond. If a response is not sent within this time period, the ORIGINATOR can choose to disclose the ISSUE. C. The MAINTAINER is to be given 5 working days (in respects to the ORIGINATOR) from the DATE OF CONTACT; the ORIGI- NATOR may choose to disclose the ISSUE after this point. During this waiting period, communication is encouraged between the MAINTAINER and ORIGINATOR, in regards to the progress of the MAINTAINER finding a resolution, difficulties involved, etc. Requests from the MAINTAINER to help in reproducing problems should be honored by the ORIGINATOR. D. Discussions between the MAINTAINER and ORIGINATOR for delay of disclosure of the ISSUE are possible, provided that the MAINTAINER provides reasoning for requiring so. Delaying the dis- closure of the ISSUE by the ORIGINATOR given the circumstances is not required but highly encouraged. Reporting Security Problems • Chapter 15 417 www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 417 E. In respect for the ORIGINATOR following this policy, it is encouraged the MAINTAINER provide proper credit to the ORIGI- NATOR for doing so. Failure to document credit to the ORIGI- NATOR can result in the ORIGINATOR being reluctant in following this policy in conjunction with the same MAINTAINER concerning future issues, at the ORIGINATOR’s discretion. Suggested (minimal) credit would be: “Credit to <ORIGINATOR> for disclosing the problem to <MAINTAINER>.” F. The MAINTAINER is encouraged to coordinate a joint public release/disclosure with the ORIGINATOR, so that advisories of problem and resolution can be made available together. G. If the MAINTAINER publicly discloses the ISSUE the ORIGI- NATOR, at their option, can disclose the ISSUE as well. The full text of this policy can be found at: www.wiretrip.net/rfp/policy.html Reporting Security Problems to the Public Now that the vendor has a fix ready, or you have decided you will not wait for a fix from them, where should you report the security problem you’ve found? To begin with, you should send your report to the Bugtraq mailing list at bugtraq@securityfocus.com. The purpose of this moderated mailing list is the distribution and discussion of computer security problems for any platform or application. To subscribe to Bugtraq, e-mail listserv@securityfocus.com with a message body of “SUBSCRIBE bugtraq Firstname Lastname” without the quotes, and enter your first and last names. To find out more about Bugtraq, read the mailing list Frequently Asked Questions (FAQs) available at: www.securityfocus.com/frames/?content=/forums/bugtraq/faq.html If this is a security problem that affects Microsoft’s Windows NT or Windows 2000, you may also want to send your report to the NTBugtraq mailing list. The purpose of this moderated mailing list is the distribution and discussion of computer security problems related to Windows NT and Windows 2000. To subscribe to NTBugtraq, e-mail listserv@listserv.ntbugtraq.com with a message body of “SUBSCRIBE ntbugtraq Firstname Lastname” without the quotes, and enter your first and last names. To find out more about NTBugtraq, visit: www.ntbugtraq.com Between these two lists, you will be reaching more than 100,000 people interested in computer security vulnerabilities. 418 Chapter 15 • Reporting Security Problems www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 418 You may also want to report the problem to Computer Emergency Response Team (CERT). CERT is an organization that collects security incident information and puts out security advisories that are read by a large portion of Internet users. If the problem you are reporting is severe enough and affects a large number of the Internet users, CERT may release an advisory on the problem (but historically usually only a long time after the initial discovery and publication of the problem in other forums). To reach CERT, e-mail them at cert@cert.org or visit their Web page at: www.cert.org Sometimes, even reporting the problem to the vendor and to the computer security community is not enough. In January of 2000, Kevin Kadow reported a number of security problems to Standard & Poor’s related to their MultiCSP product. He reported his findings in March of 2000 to the computer security community. Stephen Friedl reported the problems to the computer security community again in May of 2000. It was not until the press was informed of the security problems, and news articles published about them, that the com- pany moved swiftly to fix the vulnerabilities. From Kevin Kadow [03/24/2000]: On January 12th, Standard & Poor, Mcgraw-Hill and ComStock were contacted about the issues detailed below. We have yet to receive any response. I was given access to a brand new MultiCSP unit in early March, and found all of the same issues, with only minor, cosmetic changes. From Stephen Friedl [05/16/2000]: Sta ndard & Poor’s ComStock division sells a MultiCSP system that provides real-time stock quotes and news, and this was the subject of a Bugtraq posting in February 2000 by Kevin Kadow (this link a copy posted in March): www.securityfocus.com/ templates/archive.pike?list=1&date=2000-03-22&msg=20000324230903. 13640.qmail@msg.net His review was fairly scathing, but he substantially UNDERstates the risk of running one of these machines. He told me he didn’t want to give away everything (to allow people time to clean things up), but I intend to do so here. These machines are an unmitigated *disaster* for security, and it’s not often I can use “unmitigated” so literally.… Scream *bloody murder* at your S&P representative. They have more or less completely ignored reports of this serious matter as far as I can tell. The previous reporter of this (Kevin Kadow) tried every way he knows how to get them interested, and nothing happened, and even an indirect communication to S&P’s CTO got no response. Talk to your legal counsel if you are so inclined. S&P is just grossly negligent on this front. Reporting Security Problems • Chapter 15 419 www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 419 Again from Stephen Friedl [05/23/2000]: As many of you know, this has hit CNet http://news.cnet.com/ news/0-1005-200-1933917.html What I found in working on this issue is that S&P really believed that the Concentric network was a private one, and appar- ently S&P’s CTO told the journalist flat out that one customer can’t get to another customer via the VPN. This turns out not to be true, but if it really was a private network, then the secu- rity vulnerabilities of the Linux box would be nearly moot. So the VPN is the issue, and it looks like S&P is trying to blame Concentric for this. Of course, it’s always possible that Concentric has done it wrong, but if S&P didn’t do regular audits *or* if they ignored repeated attempts to point this out, then the onus is squarely on them. Numerous people have told me that they tried very hard to get this reported, and I even had A Very Close Friend leave a voice- mail and email on the CTO’s direct line two weeks ago that included all the details. When we got nothing in response, I posted to Bugtraq. Now I see firsthand what “spin” is. What I have repeatedly heard in private email is that S&P customer service is very friendly and want to help, but they just don’t get it. Anyway, a couple of hours before this all hit the fan, I was forwarded a letter received from S&P to their customers regarding steps on the security front. It follows this note. A tip of the white hat to Kevin Kadow for his initial reporting of this on Bugtraq that got this rolling, and his help after the fact. If you’ve found a problem that affects a large portion of Internet or com- puter users or is severe enough, you may wish to contact the media. They have the power to bring the security problem to the attention of large groups of people who otherwise may never find out about it, and force action out of an uncooperative vendor. At the same time, they can create more awareness of computer security in the general public. Publishing Exploit Code Should you, or should you not, create and distribute an exploit with the description of the security problem? This is a difficult question that you will have to answer on your own. Creating an exploit program can allow people to quickly test whether their systems are vulnerable for problems that would be difficult to test otherwise. For example, sending an exploit to the vendor as part of your report can make it easier for them to reproduce the problem and pinpoint the problem, thus enabling them to create a fix faster. So, you could create an exploit but only distribute it to the vendor. But recall what I said earlier about hackers breaking into security expert machines to read their mail to find out about security problems. If hackers think you have an exploit program you are not distributing, they may come after you in search of it. 420 Chapter 15 • Reporting Security Problems www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 420 Releasing the exploit to the public also tends to speed up the delivery of a fix from a vendor, since they can’t deny there is a problem. On the other hand, by releasing an exploit you are adding a weapon to the hackers’ arsenal to use against others. But factor in how difficult the exploit is to create—if a hacker can create an exploit in one day of work, while a system administrator doesn’t have the time to do so, whom are you benefiting by not releasing the exploit, the hacker or the system administrator? Some of the people who create exploits to illustrate a security problem attempt to make watered-down exploits that test for the problem but don’t per- form any dangerous action. This is usually an attempt to avoid handing mali- cious readers a ready-made tool to break into others’ systems. This is usually only marginally effective, as it’s often pretty easy to modify the supplied exploit to perform the more dangerous action. In addition, someone who knows enough to produce a full-strength exploit, but doesn’t feel the need to protect the public, will probably make one, and post it. Many security scanner software vendors face the same issue. They want to sell products that allow buyers to test their own systems for vulnerabilities, but they’d rather not hand out a point-and-click break-in tool. Problems The following are problems that can arise from releasing products that contain security problems. Repercussions from Vendors Although there really have been almost no cases, there is always the possibility that a vendor may sue you for publishing security problems in their products or services, or that someone may attempt to hold you liable if he or she gets attacked by someone making use of a security problem you reported. Some vendors may claim you have broken their shrink-wrap or one-click licensing agreement that forbids reverse engineering their product or service. Others may claim that you are releasing trade secrets. You have to be particu- larly careful when dealing with copyright protection technologies, as these seem to be explicitly protected from reverse engineering by international treaties, or in the United States (US) by the Digital Millennium Copyright Act (www.loc.gov/copyright/legislation/hr2281.pdf). For example, the Motion Picture Association of America (MPAA) has sued a number of individuals who reverse engineered the Digital Versatile Disk (DVD) encryption algorithms and found them to be extremely weak and insecure. The MPAA was able to affect the seizure of a computer by law enforcement in a for- eign country. Reporting Security Problems • Chapter 15 421 www.syngress.com 95_hack_prod_15 7/13/00 12:28 PM Page 421 [...]... 41 Hacker Manifesto, 24 Hacking See Structured Query Language skills, 17 learning, 19 systems, 29 tools, regulation, 21 Hackman, 129–130 Hacktivism, 8–9 HandleEx, 108 , 138 Hang-up command, 408 Hard-coded password, 66 Hardware See Tamper-proof hardware hacker, 107 Hashes, 135–136, 140–141 Hashing loader, 243–245 Heap smashing, 222–225 trespassing, 223–224 Hellman, Martin, 148 Hello buffer, 207– 210 Heuristics,... Flight Recorder (NFR), 90 Network Interface Card (NIC), 93, 281, 302 NIC-NAME, 93 Network Monitor (Netmon), 268, 269, 272, 283 See also Windows NT Network News Transport Protocol (NNTP), 263, 379 Network/ machine recon, 344, 347–354 Newsham, Timothy N., 91 NextOS/Linux, 289 NFR See Network Flight Recorder NFS See Network File System NIC See Network Interface Card NIC-NAME See Network Interface Card NIST... 366 Netmon See Network Monitor Netscape mail passwords, 56 Network See Computer networks cards, 260 communications, diffing usage, 143 detection, 282–283 effects, 314 monitoring, legality, 284 traffic, 266 worm, 253 Network Associates See CyberCop; Sniffer Pro Network File System (NFS) daemon, 265 file handles, 264–265 95 _hack_ prod_index 440 7/13/00 3:33 PM Page 440 Index server, 82 Network Flight... detection evasion, 358 usage, 416 Invalid input function, 198 Invisibility See Worms IOS See Internetwork Operating System IP See Internet Protocol IPD See Integrity Protection Driver IPSec See Internet Protocol Security IRC See Internet Relay Chat IRC clients, 48 ISO See International Standards Organization ISP See Internet Service Provider ISS, 379 IT See Information Technology 437 J Jargon File, 3, 4,... messages/packets, 291 Internet Engineering Task Force (IETF), 152 Internet Explorer (IE), 12, 53, 156, 376 ActiveX security hole, 361–362 95 _hack_ prod_index 7/13/00 3:33 PM Page 437 Index Internet Message Access Protocol (IMAP), 262–263, 302 Internet Protocol (IP), 68, 288, 337 address, 38, 287, 367, 375 firewalling, installation, 352 forwarding, 274 level, 282 spoofing attack, 308 Internet Protocol Security... firewalling, installation, 352 forwarding, 274 level, 282 spoofing attack, 308 Internet Protocol Security (IPSec), 152, 279, 302 Internet Relay Chat (IRC), 6, 365, 380, 381 Internet Scanner, 379 Internet Service Provider (ISP), 21, 22, 92, 290, 321, 374 Internet Worm (1988), 79 Internetwork Operating System (IOS), 91 See also Cisco Systems, Inc Intrusion detection, 345 Intrusion Detection System (IDS), 44,... Spoofing BGP See Border Gateway Protocol Biham, Eli, 50 Binary logic, 104 Binary-only files, 113 BIND See Berkeley Internet Name Daemon 95 _hack_ prod_index 7/13/00 3:33 PM Page 429 Index BIOS See Basic Input/Output System Black box, 102 107 approach, 190 Black Hat Briefings, 6 Black hat hacker, 6–7, 27 Black-boxing, 186–189 Blind return, 216–218 Blind spoofing, 311, 322–323 attacks, 336 Blowfish, 151,... overview, 146–153 problems, 153–158 resources, 173–174 Crystal box, 102 , 117 CSS See Content Scrambling System Curiosity See Hacker CVE See Common Vulnerabilities and Exposures Cyber warrior, 14, 17 CyberCop (Network Associates), 90 Cyclic Redundancy Check (CRC), 136, 244 CRC32, 141 D Daemons, 78 See also Berkeley Internet Name Daemon; Network File System; Trinoo vulnerabilities, 341 Dark Tangent, 6 Data... License Graham, Robert, 283 Graphic User Interface (GUI), 129 Grey hat, 7–8, 27 Grey-hat hackers, 283 GTAC See Government Technical Assistance Center GUI See Graphic User Interface Guninski, Georgi, 45, 361, 363, 376 H Hacker See Criminal hackers; Greyhat hackers; Hardware admiration, 16 community, 119 concept, 16 95 _hack_ prod_index 7/13/00 3:33 PM Page 435 Index curiosity, 16–17 definition, 2–9 employment,... 364 sites, 92, 272 95 _hack_ prod_index 434 7/13/00 3:33 PM Page 434 Index File-by-file compression, 133 Filemon, 108 , 138, 139 Files, 123–140 See also Binary-only files; Input access See Special file/database access attributes, 133–135 comparison tools, 126–128 corruption, 140 creation, 82, 93–95 handles See Network File System integrity, 355 modification, 82, 93–95 permissions, 110 reading, 82, 93–95 . files, 113 BIND. See Berkeley Internet Name Daemon. 428 Index 95 _hack_ prod_index 7/13/00 3:33 PM Page 428 Index 429 BIOS. See Basic Input/Output System. Black box, 102 107 approach, 190 Black Hat. Firewall-1, 62 Checksums, 135–136, 140–141 Chips, 102 105 Cipher. See Asymmetric cipher. Ciphertext, 146 output, 171 Cisco Systems, Inc., 39 Internetwork Operating System (IOS), 291 routers, 91,. producing security patches your top priority. People and companies depend on your products to perform securely. It’s bad enough that a security problem was found. Don’t leave your customers vulner- able