Hack Proofing Your Network 2E / Edition 2

Paperback (Print)
Buy New
Buy New from BN.com
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (20) from $1.99   
  • New (6) from $31.58   
  • Used (14) from $1.99   


A new edition the most popular Hack Proofing book around!
IT professionals who want to run secure networks, or build secure software, need to know about the methods of hackers. The second edition of the best seller Hack Proofing Your Network, teaches about those topics, including:
· The Politics, Laws of Security, Classes of Attack, Methodology, Diffing, Decrypting, Brute Force, Unexpected Input, Buffer Overrun, Sniffing, Session Hijacking, Spoofing, Server Holes, Client Holes, Trojans and Viruses, Reporting Security Problems, Choosing Secure Systems

The central idea of this book is that it's better for you to find the holes in your network than it is for someone else to find them, someone that would use them against you. The complete, authoritative guide to protecting your Windows 2000 Network.

Updated coverage of an international bestseller and series flagship
Covers more methods of attack and hacker secrets
Interest in topic continues to grow - network architects, engineers and administrators continue to scramble for security books
Written by the former security manager for Sybase and an expert witness in the Kevin Mitnick trials
· A great addition to the bestselling "Hack Proofing..." series
· Windows 2000 sales have surpassed those of Windows NT
· Critical topic. The security of an organization's data and communications is crucial to its survival and these topics are notoriously difficult to grasp
· Unrivalled web support at www.solutions@syngress.com

Featuring real-world examples using UNIX, Windows, and Cisco routers and switchers, this nuts-and-bolts guide helps computer professionals make a meaningful security assessment of their systems by understanding hackers' methods. Tables summarize key information and little-known intrusion detection tips are listed in an appendix.

Read More Show Less

Editorial Reviews

From the Publisher
Essential reading for your IT security organization." —Deena Joyce, Director of Information Technology and Network Security, Casino Magic
From The Critics
This attack-oriented (rather than defense-oriented) guide is intended to teach skills for breaking into computer systems. Readers can use these skills for security testing, consumer advocacy and civil rights purposes, and military and political reasons. The book begins with a discussion of the current climate in regards to hacking, reverse engineering, copy protection, and the law, then describes types of attacks and various methods for discovering security problems. The bulk of the book gives instructions for breaking encoding schemes, writing machine language, and monitoring network communications for hacking purposes. Individual chapters are rated for beginning, intermediate, and advanced hackers. A companion Web site contains code, files, applications, and links to applications. This second edition offers new material on hardware hacking, tunneling, evasion of intrusion detection systems, and format string attacks. Ahmad works for a provider of security intelligence services. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9781928994701
  • Publisher: Elsevier Science
  • Publication date: 4/25/2002
  • Edition description: 2ND
  • Edition number: 2
  • Pages: 826
  • Product dimensions: 7.50 (w) x 9.25 (h) x 1.61 (d)

Meet the Author

Ryan Russell (CCNA, CCNP) is the best-selling author of Hack Proofing Your Network: Internet Tradecraft and Hack Proofing Your ECommerce Web Site. He is an MIS manager at SecurityFocus.com, has served as an expert witness on security topics, and has done internal security investigation for a major software vendor. Ryan has been working in the IT field for over 11 years, the last 6 of which have been spent primarily in information security. He has been an active participant in various security mailing lists, such as BugTraq, for years. Ryan holds a Bachelors of Science degree in Computer Science.
Read More Show Less

Read an Excerpt

Chapter 7: Unexpected Input

Solutions in this chapter:
  • Why Unexpected Data is Dangerous
  • Situations Involving Unexpected Data
  • Techniques to Find and Eliminate Vulnerabilities
  • Available Safety Features
  • Related Tools
  • Summary
  • Solutions Fast Track
  • Frequently Asked Questions


The Internet is composed of applications, each performing a role, whether it be routing, providing information, or functioning as an operating system. Every day sees many new applications enter the scene. For an application to truly be useful, it must interact with a user. Be it a chat client, e-commerce Web site, system command line utility, or an online game, all applications dynamically modify execution based on user input. A calculation application that does not take user-submitted values to calculate is useless; an e-commerce system that doesn't take orders defeats the purpose.

Being on the Internet means the application is remotely accessible by other people. If coded poorly, the application can leave your system open to security vulnerabilities. Poor coding can be the result of lack of experience, a coding mistake, or an unaccounted-for anomaly. Large applications are often developed in smaller parts consecutively, and joined together for a final project; it's possible that there exist differences and assumptions in a module that, when combined with other modules, results in a vulnerability.

Notes from the Underground…

Politics as Usual

The battle between application developers and network administrators is ageless. It is very hard to get non-security-conscience developers to change their applications without having a documented policy to fall back on that states security as an immediate requirement. Many developers do not realize that their application is just as integral to the security posture of a corporation as the corporation's firewall.

The proliferation of vulnerabilities due to unexpected data is very high. A nice list can be found in any Web CGI (Common Gateway Interface) scanner (cgichk, whisker, etc). Most CGIs scanned for are known to be vulnerable to an attack involving unexpected user input.

Why Unexpected Data Is Dangerous

To interact with a user, an application must accept user-supplied data. It could be in a simple form (mouse click, single character), or a complex stream (large quantities of text). In either case, it is possible that the user submits (knowingly or not) data the application wasn't expecting. The result could be nil, or it could modify the intended response of the application. It could lead to the application providing information to users that they wouldn't normally be able to get, or tamper with the application or underlying system.

Three classes of attack can result from unexpected data:

  • Buffer overflow When an attacker submits more data than the application expects, the application may not gracefully handle the surplus data. C and C++ are examples of languages that do not properly handle surplus data (unless the application specifically is programmed to handle them). Perl and PHP automatically handle surplus data by increasing the size for variable storage. (See Chapter 8 for more information on buffer overflows.)
  • System functions The data is directly used in some form to interact with a resource that is not contained within the application itself. System functions include running other applications, accessing or working with files, etc. The data could also modify how a system function behaves.
  • Logic alteration The data is crafted in such a way as to modify how the application's logic handles it. These types of situations include diverting authentication mechanisms, altering Structured Query Language (SQL) queries, and gaining access to parts of the application the attacker wouldn't normally have access to.
Note that there is no fine line for distinction between the classes, and particular attacks can sometimes fall into multiple classes.

The actual format of the unexpected data varies; an "unexpected data" attack could be as simple as supplying a normal value that modifies the application's intended logical execution (such as supplying the name of an alternate input file). This format usually requires very little technical prowess. Then, of course, there are attacks that succeed due to the inclusion of special metacharacters that have alternate meaning to the application. The Microsoft Jet engine had a problem where pipes ( | ) included within the data portion of a SQL query caused the engine to execute Visual Basic for Applications (VBA) code, which could lead to the execution of system commands. This is the mechanism behind the popular RDS (Remote Data Services) exploit, which has proven to be a widespread problem with installations of Internet Information Server on Windows NT.

Situations Involving Unexpected Data

So where does unexpected data come into play? Let's review some common situations.

Local Applications and Utilities

A computer system is composed of various applications that the user or system will run in order to do what it needs to do. Many of these applications interact with the user, and thus give a malicious user the chance to do something the application wasn't expecting. This could, for example, mean pressing an abnormal key sequence, providing large amounts of data, or specifying the wrong types of values.

Normally this isn't a large problem-if a user does something bad, the application crashes and that's that. However, in the Unix world (which now includes the Macintosh OS X world as well), some of these applications have special permissions called 'set user id' and 'set group id'. This means the applications will run with elevated privileges compared to that of the normal user. So while tricking a normal application might not be of much benefit, tricking a suid or sgid application can result in the privilege to do things that are normally limited to administrator types. We'll look at some of the common ways to trick these types of applications later in this chapter.


I have seen many assumptions made by Web applications; some of the assumptions are just from misinformation, but most are from a lack of understanding of how the HyperText Transport Protocol (HTTP) and/or HyperText Markup Language (HTML) work.

The biggest mistake applications make is relying on the HTTP referer header as a method of security. The referer header contains the address of the referring page. It's important to note that the referer header is supplied by the client, at the client's option. Since it originates with the client, which means it is trivial to spoof. For example, we can telnet to port 80 (HTTP port) of a Web server and type:

GET / HTTP/1.0
User-Agent: Spoofed-Agent/1.0
Referer: http://www.wiretrip.net/spoofed/referer/

Here you can see that we submitted a fake referer header and a fake user agent header. As far as user-submitted information is concerned, the only piece of information we can justifiably rely on is the client's IP address (although, this too can be spoofed; see Chapter 12 for more information on spoofing).

Another bad assumption is the dependency on HTML form limitations. Many developers feel that, because they only gave you three options, clients will submit one of the three. Of course, there is no technical limitation that says they have to submit a choice given by the developers. Ironically enough, I have seen a Microsoft employee suggest this as an effective method to combat renegade user data. I cut him some slack, though-the person who recommended this approach was from the SQL server team, and not the security or Web team. I wouldn't expect him to know much more than the internal workings of a SQL server.

So, let's look at this. Suppose an application generates the following HTML:

 <FORM ACTION="process.cgi" METHOD="GET">
   <SELECT NAME="author">
         <OPTION VALUE="Ryan Russell">Ryan Russell
         <OPTION VALUE="Mike Schiffman">Mike Schiffman
         <OPTION VALUE="Elias Levy">Elias Levy
         <OPTION VALUE="Greg Hoglund">Greg Hoglund
   <INPUT TYPE="Submit">

Here we've been provided with a (partial) list of authors. Once receiving the form HTML, the client disconnects, parses the HTML, and presents the visual form to the user. Once the user decides an option, the client sends a separate request to the Web server for the following URL:


Simple enough. However, at this point, there is no reason why I couldn't submit the following URL instead:


As you can see, I just subverted the assumed "restriction" of the HTML form. Another thing to note is that I can enter this URL independently of needing to request the HTML form prior. In fact, I can telnet to port 80 of the Web server and request it by hand. There is no requirement that I need to request or view the prior form; you should not assume incoming data will necessarily be the return result of a previous form.

One assumption I love to disprove to people is the use of client-side data filtering. Many people include cute little JavaScript (or, ugh, VBScript) that will double check that all form elements are indeed filled out. They may even go as far as to check to make sure numeric entries are indeed numeric, etc. The application then works off the assumption that the client will perform the necessary data filtering, and therefore tends to pass it straight to system functions.

The fact that it's client side should indicate you have no control over the choice of the client to use your cute little validation routines. If you seriously can't imagine someone having the technical prowess to circumvent your client-side script validation, how about imagining even the most technically inept people turning off JavaScript/Active scripting. Some corporate firewalls even filter out client-side scripting. An attacker could also be using a browser that does not support scripting (such as Lynx).

Of interesting note, using the size parameter in conjunction with HTML form inputs is not an effective means of preventing buffer overflows. Again, the size parameter is merely a suggested limitation the client can impose if it feels like it (i.e., understands that parameter).

If there ever were to be a "mystical, magical" element to HTTP, it would definitely involve cookies. No one seems to totally comprehend what these little critters are, let alone how to properly use them. The media is portraying them as the biggest compromise of personal privacy on the Web. Some companies are using them to store sensitive authentication data. Too bad none of them are really right.

Cookies are effectively a method to give data to clients so they will return it to you. Is this a violation of privacy? The only data being given to you by the clients is the data you originally gave them in the first place. There are mechanisms that allow you to limit your cookies so the client will only send them back to your server. Their purpose was to provide a way to save state information across multiple requests (since HTTP is stateless; i.e., each individual request made by a client is independent and anonymous).

Considering that cookies come across within HTTP, anything in them is sent plaintext on the wire. Faking a cookie is not that hard. Observe the following telnet to port 80 of a Web server:

GET / HTTP/1.0
User-Agent: HaveACookie/1.0
Cookie: MyCookie=SecretCookieData

I have just sent the "MyCookie" cookie containing the data "SecretCookieData." Another interesting note about cookies is that they are usually stored in a plaintext file on the client's system. This means that if you store sensitive information in the cookie, it may stand the chance of retrieval.

Unexpected Data in SQL Queries

Many e-commerce systems and other applications interface with some sort of database. Small-scale databases are even built into applications for purposes of configuration and structured storage (such as Windows' Registry). In short, databases are everywhere.

The Structured Query Language (SQL) is a database-neutral language syntax to submit commands to a database and have the database return an intelligible response. I think it's safe to say that most commercial relational database servers are SQL compatible, due to SQL being an ANSI standard.

Now, there's a very scary truth that is implied with SQL. It is assumed that, for your application to work, it must have enough access to the database to perform its function. Therefore, your application will have the proper credentials needed to access the database server and associated resources. Now, if an attacker is to modify the commands your application is sending to your database server, your attacker is using the preestablished credentials of the application; no extra authentication information is needed on behalf of the attacker. The attacker does not even need direct contact with the database server itself. There could be as many firewalls as you can afford sitting between the database server and the application server; if the application can use the database (which is assumed), then an attacker has a direct path to use it as well, regardless.

Of course, it does not mean an attacker can do whatever he or she wishes to the database server. Your application may have restrictions imposed against which resources it can access, etc; this may limit the actual amount of access the attacker has to the database server and its resources.

One of the biggest threats of including user-submitted data within SQL queries is that it's possible for an attacker to include extra commands to be executed by the database. Imagine we had a simple application that wanted to look up a user-supplied value in a table. The query would look similar to:

SELECT * FROM table WHERE x=$data

This query would take a user's value, substitute it for $data, and then pass the resulting query to the database. Now, imagine an attacker submitting the following value:

1; SELECT * FROM table WHERE y=5

After the application substitutes it, the resulting string sent to the database would be:

SELECT * FROM table WHERE x=1; SELECT * FROM table WHERE y=5

Generically, this would cause the database to run two separate queries: the intended query, and another extra query (SELECT * FROM table WHERE y=5). I say generically, because each database platform handles extra commands differently; some don't allow more than one command at a time, some require special characters be present to separate the individual queries, and some don't even require separation characters. For instance, the following is a valid SQL query (actually it's two individual queries submitted at once) for Microsoft SQL Server and Sybase databases:


Notice there's no separation or other indication between the individual SELECT statements.

It's also important to realize that the return result is dependent on the database engine. Some return two individual record sets as shown in Figure 7.1, with each set containing the results of the individual SELECT. Others may combine the sets if both queries result in the same return columns. On the other hand, most applications are written to only accommodate the first returned record set; therefore, you may not be able to visually see the results of the second query-however, that does not mean executing a second query is fruitless. MySQL allows you to save the results to a file. MS SQL Server has stored procedures to e-mail the query results. An attacker can insert the results of the query into a table that he or she can read from directly. And, of course, the query may not need to be seen, such as a DROP command....

Read More Show Less

Table of Contents

Foreword v 1.5 xxix
Foreword v 1.0 xxxiii
Chapter 1 How To Hack 1
Chapter 2 The Laws of Security 11
Chapter 3 Classes of Attack 45
Chapter 4 Methodology 99
Chapter 5 Diffing 131
Chapter 6 Cryptography 165
Chapter 7 Unexpected Input 205
Chapter 8 Buffer Overflow 243
Chapter 9 Format Strings 319
Chapter 10 Sniffing 361
Chapter 11 Session Hijacking 407
Chapter 12 Spoofing: Attacks on Trusted Identity 443
Chapter 13 Tunneling 527
Chapter 14 Hardware Hacking 609
Chapter 15 Viruses, Trojan Horses, and Worms 655
Chapter 16 IDS Evasion 689
Chapter 17 Automated Security Review and Attack Tools 719
Chapter 18 Reporting Security Problems 749
Index 767
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)