Hack Proofing Your Network / Edition 2

by Syngress

Overview

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.

Product Details

ISBN-13:	9781928994701
Publisher:	Elsevier Science
Publication date:	04/25/2002
Edition description:	2ND
Pages:	704
Product dimensions:	6.12(w) x 9.21(h) x (d)

About 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 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

Introduction

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.

HTTP/HTML

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
   </SELECT>
   <INPUT TYPE="Submit">
   </FORM>

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:

process.cgi?author=Ryan%20Russell

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

process.cgi?author=Rain%20Forest%20Puppy

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:

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

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....

Table of Contents

Foreword v 1.5

Foreword v 1.0

Chapter 1 How To Hack

Introduction

What We Mean by “Hack”

Why Hack?

Knowing What To Expect in the Rest of This Book

Understanding the Current Legal Climate

Summary

Frequently Asked Questions

Chapter 2 The Laws of Security

Introduction

Knowing the Laws of Security

Client-Side Security Doesn’t Work

You Cannot Securely Exchange Encryption Keys without a Shared Piece of Information

Malicious Code Cannot Be 100 Percent Protected against

Any Malicious Code Can Be Completely Morphed to Bypass Signature Detection

Firewalls Cannot Protect You 100 Percent from Attack

Social Engineering

Attacking Exposed Servers

Attacking the Firewall Directly

Client-Side Holes

Any IDS Can Be Evaded

Secret Cryptographic Algorithms Are Not Secure

If a Key Is Not Required,You Do Not Have Encryption—You Have Encoding

Passwords Cannot Be Securely Stored on the Client Unless There Is Another Password to Protect Them

In Order for a System to Begin to Be Considered Secure, It Must Undergo an Independent Security Audit

Security through Obscurity Does Not Work

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 3 Classes of Attack

Introduction

Identifying and Understanding the Classes of Attack

Denial of Service

Information Leakage

Regular File Access

Misinformation

Special File/Database Access

Remote Arbitrary Code Execution

Elevation of Privileges

Identifying Methods of Testing for Vulnerabilities

Proof of Concept

Standard Research Techniques

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 4 Methodology

Introduction

Understanding Vulnerability Research Methodologies

Source Code Research

Binary Research

The Importance of Source Code Reviews

Searching Error-Prone Functions

Reverse Engineering Techniques

Disassemblers, Decompilers, and Debuggers

Black Box Testing

Chips

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 5 Diffing

Introduction

What Is Diffing?

Why Diff?

Looking to the Source Code

Exploring Diff Tools

Using File-Comparison Tools

Working with Hex Editors

Utilizing File System Monitoring Tools

Finding Other Tools

Troubleshooting

Problems with Checksums and Hashes

Problems with Compression and Encryption

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 6 Cryptography

Introduction

Understanding Cryptography Concepts

History

Encryption Key Types

Learning about Standard Cryptographic Algorithms

Understanding Symmetric Algorithms

Understanding Asymmetric Algorithms

Understanding Brute Force

Brute Force Basics

Using Brute Force to Obtain Passwords

Knowing When Real Algorithms Are Being Used Improperly

Bad Key Exchanges

Hashing Pieces Separately

Using a Short Password to Generate a Long Key

Improperly Stored Private or Secret Keys

Understanding Amateur Cryptography Attempts

Classifying the Ciphertext

Monoalphabetic Ciphers

Other Ways to Hide Information

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 7 Unexpected Input

Introduction

Understanding Why Unexpected Data Is Dangerous

Finding Situations Involving Unexpected Data

Local Applications and Utilities

HTTP/HTML

Unexpected Data in SQL Queries

Application Authentication

Disguising the Obvious

Using Techniques to Find and Eliminate Vulnerabilities

Black-Box Testing

Use the Source

Untaint Data by Filtering It

Escaping Characters Is Not Always Enough

Perl

Cold Fusion/Cold Fusion Markup Language (CFML)

ASP

PHP

Protecting Your SQL Queries

Silently Removing versus Alerting on Bad Data

Invalid Input Function

Token Substitution

Utilizing the Available Safety Features in Your Programming Language

Perl

PHP

ColdFusion/ColdFusion Markup Language

ASP

MySQL

Using Tools to Handle Unexpected Data

Web Sleuth

CGIAudit

RATS

Flawfinder

Retina

Hailstorm

Pudding

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 8 Buffer Overflow

Introduction

Understanding the Stack

The Stack Dump

Oddities and the Stack

Understanding the Stack Frame

Introduction to the Stack Frame

Passing Arguments to a Function: A Sample Program

Stack Frames and Calling Syntaxes

Learning about Buffer Overflows

A Simple Uncontrolled Overflow: A Sample Program

Creating Your First Overflow

Creating a Program with an Exploitable Overflow

Performing the Exploit

Learning Advanced Overflow Techniques

Stack Based Function Pointer Overwrite

Heap Overflows

Advanced Payload Design

Using What You Already Have

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 9 Format Strings

Introduction

Understanding Format String Vulnerabilities

Why and Where Do Format String Vulnerabilities Exist?

How Can They Be Fixed?

How Format String Vulnerabilities Are Exploited

How Format String Exploits Work

What to Overwrite

Examining a Vulnerable Program

Testing with a Random Format String

Writing a Format String Exploit

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 10 Sniffing

Introduction

What Is Sniffing?

How Does It Work?

What to Sniff?

Obtaining Authentication Information

Capturing Other Network Traffic

Popular Sniffing Software

Ethereal

Network Associates Sniffer Pro

NT Network Monitor

WildPackets

TCPDump

dsniff

Ettercap

Esniff.c

Sniffit

Carnivore

Additional Resources

Advanced Sniffing Techniques

Man-in-the-Middle (MITM) Attacks

Cracking

Switch Tricks

Routing Games

Exploring Operating System APIs

Linux

BSD

libpcap

Windows

Taking Protective Measures

Providing Encryption

Secure Sockets Layers (SSL)

PGP and S/MIME

Switching

Employing Detection Techniques

Local Detection

Network Detection

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 11 Session Hijacking

Introduction

Understanding Session Hijacking

TCP Session Hijacking

TCP Session Hijacking with Packet Blocking

UDP Hijacking

Examining the Available Tools

Juggernaut

Hunt

Ettercap

SMBRelay

Storm Watchers

Playing MITM for Encrypted Communications

Man-in-the-Middle Attacks

Dsniff

Other Hijacking

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 12 Spoofing: Attacks on Trusted Identity

Introduction

What It Means to Spoof

Spoofing Is Identity Forgery

Spoofing Is an Active Attack against Identity Checking Procedures

Spoofing Is Possible at All Layers of Communication

Spoofing Is Always Intentional

Spoofing Is Not the Same Thing as Betrayal

Spoofing Is Not Necessarily Malicious

Spoofing Is Nothing New

Background Theory

The Importance of Identity

The Evolution of Trust

Asymmetric Signatures between Human Beings

Establishing Identity within Computer Networks

Return to Sender

In the Beginning,There Was… a Transmission

Capability Challenges

Configuration Methodologies: Building a Trusted Capability Index

Desktop Spoofs

The Plague of Auto-Updating Applications

Impacts of Spoofs

Subtle Spoofs and Economic Sabotage

Down and Dirty: Engineering Spoofing Systems

Spitting into the Wind: Building a Skeleton Router in Userspace

Bring Out the Halon: Spoofing Connectivity Through Asymmetric Firewalls

Summary

Solution Fast Track

Frequently Asked Questions

Chapter 13 Tunneling

Introduction

Strategic Constraints of Tunnel Design

Privacy: “Where Is My Traffic Going?”

Routability: “Where Can This Go Through?”

Deployability: “How Painful Is This to Get Up and Running?”

Flexibility: “What Can We Use This for,Anyway?”

Quality: “How Painful Will This System Be to Maintain?”

Designing End-to-End Tunneling Systems

Drilling Tunnels Using SSH

Open Sesame: Authentication

Basic Access: Authentication by Password

Transparent Access: Authentication by Private Key

Command Forwarding: Direct Execution for Scripts and Pipes

Port Forwarding: Accessing Resources on Remote Networks

Local Port Forwards

Dynamic Port Forwards

Remote Port Forwards

When in Rome:Traversing the Recalcitrant Network

Crossing the Bridge: Accessing Proxies through ProxyCommands

No Habla HTTP? Permuting thy Traffic

Show Your Badge: Restricted Bastion Authentication

Bringing the Mountain: Exporting SSHD Access

Echoes in a Foreign Tongue: Cross-Connecting Mutually Firewalled Hosts

Not In Denver, Not Dead: Now What?

Standard File Transfer over SSH

Incremental File Transfer over SSH

CD Burning over SSH

Acoustic Tubing: Audio Distribution over TCP and SSH

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 14 Hardware Hacking

Introduction

Understanding Hardware Hacking

Opening the Device: Housing and Mechanical Attacks

Types of Tamper Mechanisms

External Interfaces

Protocol Analysis

Electromagnetic Interference and Electrostatic Discharge

Analyzing the Product Internals: Electrical Circuit Attacks

Reverse-engineering the Device

Basic Techniques: Common Attacks

Advanced Techniques: Epoxy Removal and IC Delidding

Cryptanalysis and Obfuscation Methods

What Tools Do I Need?

Starter Kit

Advanced Kit

Example: Hacking the iButton Authentication Token

Experimenting with the Device

Reverse-engineering the “Random” Response

Example: Hacking the NetStructure 7110 E-commerce Accelerator

Opening the Device

Retrieving the Filesystem

Reverse-engineering the Password Generator

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 15 Viruses, Trojan Horses, and Worms

Introduction

How Do Viruses,Trojans Horses, and Worms Differ?

Viruses

Worms

Macro Virus

Trojan Horses

Hoaxes

Anatomy of a Virus

Propagation

Payload

Other Tricks of the Trade

Dealing with Cross-platform Issues

Java

Macro Viruses

Recompilation

Shockwave Flash

Proof that We Need to Worry

The Morris Worm

ADMw0rm

Melissa and I Love You

Sadmind Worm

Code Red Worms

Nimda Worm

Creating Your Own Malware

New Delivery Methods

Faster Propagation Methods

Other Thoughts on Creating New Malware

How to Secure Against Malicious Software

Anti-Virus Software

Updates and Patches

Web Browser Security

Anti-Virus Research

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 16 IDS Evasion

Introduction

Understanding How Signature-Based IDSs Work

Judging False Positives and Negatives

Alert Flooding

Using Packet Level Evasion

IP Options

IP Fragmentation

TCP Header

TCP Synchronization

Using Fragrouter and Congestant

Countermeasures

Using Application Protocol Level Evasion

Security as an Afterthought

Evading a Match

Web Attack Techniques

Countermeasures

Using Code Morphing Evasion

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 17 Automated Security Review and Attack Tools

Introduction

Learning about Automated Tools

Exploring the Commercial Tools

Exploring the Free Tools

Using Automated Tools for Penetration Testing

Testing with the Commercial Tools

Testing the Free Tools

Knowing When Tools Are Not Enough

The New Face of Vulnerability Testing

Summary

Solutions Fast Track

Frequently Asked Questions

Chapter 18 Reporting Security Problems

Introduction

Understanding Why Security Problems Need to Be Reported

Full Disclosure

Determining When and to Whom to Report the Problem

Whom to Report Security Problems to?

Deciding How Much Detail to Publish

Publishing Exploit Code

Problems

Summary

Solutions Fast Track

Frequently Asked Questions

Index

Editorial Reviews

"Essential reading for your IT security organization." —Deena Joyce, Director of Information Technology and Network Security, Casino Magic

From the Publisher

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)