- •Exploiting Software How to Break Code
- •Table of Contents
- •Copyright
- •Praise for Exploiting Software
- •Attack Patterns
- •Foreword
- •Preface
- •What This Book Is About
- •How to Use This Book
- •But Isn't This Too Dangerous?
- •Acknowledgments
- •Greg's Acknowledgments
- •Gary's Acknowledgments
- •Bad Software Is Ubiquitous
- •The Trinity of Trouble
- •The Future of Software
- •What Is Software Security?
- •Conclusion
- •Chapter 2. Attack Patterns
- •A Taxonomy
- •An Open-Systems View
- •Tour of an Exploit
- •Attack Patterns: Blueprints for Disaster
- •An Example Exploit: Microsoft's Broken C++ Compiler
- •Applying Attack Patterns
- •Attack Pattern Boxes
- •Conclusion
- •Into the House of Logic
- •Should Reverse Engineering Be Illegal?
- •Reverse Engineering Tools and Concepts
- •Approaches to Reverse Engineering
- •Methods of the Reverser
- •Writing Interactive Disassembler (IDA) Plugins
- •Decompiling and Disassembling Software
- •Decompilation in Practice: Reversing helpctr.exe
- •Automatic, Bulk Auditing for Vulnerabilities
- •Writing Your Own Cracking Tools
- •Building a Basic Code Coverage Tool
- •Conclusion
- •Chapter 4. Exploiting Server Software
- •The Trusted Input Problem
- •The Privilege Escalation Problem
- •Finding Injection Points
- •Input Path Tracing
- •Exploiting Trust through Configuration
- •Specific Techniques and Attacks for Server Software
- •Conclusion
- •Chapter 5. Exploiting Client Software
- •Client-side Programs as Attack Targets
- •In-band Signals
- •Cross-site Scripting (XSS)
- •Client Scripts and Malicious Code
- •Content-Based Attacks
- •Conclusion
- •Chapter 6. Crafting (Malicious) Input
- •The Defender's Dilemma
- •Intrusion Detection (Not)
- •Partition Analysis
- •Tracing Code
- •Reversing Parser Code
- •Misclassification
- •Audit Poisoning
- •Conclusion
- •Chapter 7. Buffer Overflow
- •Buffer Overflow 101
- •Injection Vectors: Input Rides Again
- •Buffer Overflows and Embedded Systems
- •Database Buffer Overflows
- •Buffer Overflows and Java?!
- •Content-Based Buffer Overflow
- •Audit Truncation and Filters with Buffer Overflow
- •Causing Overflow with Environment Variables
- •The Multiple Operation Problem
- •Finding Potential Buffer Overflows
- •Stack Overflow
- •Arithmetic Errors in Memory Management
- •Format String Vulnerabilities
- •Heap Overflows
- •Buffer Overflows and C++
- •Payloads
- •Payloads on RISC Architectures
- •Multiplatform Payloads
- •Prolog/Epilog Code to Protect Functions
- •Conclusion
- •Chapter 8. Rootkits
- •Subversive Programs
- •A Simple Windows XP Kernel Rootkit
- •Call Hooking
- •Trojan Executable Redirection
- •Hiding Files and Directories
- •Patching Binary Code
- •The Hardware Virus
- •Low-Level Disk Access
- •Adding Network Support to a Driver
- •Interrupts
- •Key Logging
- •Advanced Rootkit Topics
- •Conclusion
- •References
- •Index
Attack Patterns
|
Attack Pattern: Make the Client Invisible150 |
• |
Attack Pattern: Target Programs That Write to Privileged OS Resources 152 |
Table of Contents |
|
• |
Index |
|
Attack Pattern: Use a User-Supplied Configuration File to Run Commands That Elevate |
Exploiting Software How to Break Code
Privilege153
ByGreg Hoglund,Gary McGraw
Attack Pattern: Make Use of Configuration File Search Paths156
Publisher: Addison Wesley
Attack Pattern: Direct Access to Executable Files162
Pub Date: February 17, 2004
ISBN: 0-201-78695-8
Attack Pattern: Embedding Scripts within Scripts164
Pages: 512
Attack Pattern: Leverage Executable Code in Nonexecutable Files165
Attack Pattern: Argument Injection169
Attack Pattern: Command Delimiters172
How does software break? How do attackers make software break on purpose? Why are
firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys?
Attack Pattern: Multiple Parsers and Double Escapes173
What tools can be used to break software? This book provides the answers.
Attack Pattern: User-Supplied Variable Passed to File System Calls185
Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and
techniques used by bad guys to break software. If you want to protect your software from
Attack Pattern: Postfix NULL Terminator186
attack, you must first learn how real attacks are really carried out.
Attack Pattern: Postfix, Null Terminate, and Backslash186
This must-have book may shock you—and it will certainly educate you.Getting beyond the scriptAttackkiddiePattern:treatmentRelativefound Pathin manyTraversalhacking187books, you will learn about
Attack Pattern: Client-Controlled Environment Variables189
Why software exploit will continue to be a serious problem
Attack Pattern: User-Supplied Global Variables (DEBUG=1, PHP Globals, and So Forth)
When network security mechanisms do not work
190
Attack Pattern:p tterns Session ID, Resource ID, and Blind Trust192
ReversePattern:engi eering
Attack Analog In-Band Switching Signals (aka "Blue Boxing")205
Classic attacks against server software
Attack Pattern Fragment: Manipulating Terminal Devices210
Surprising attacks against client software
Attack Pattern: Simple Script Injection214
Techniques for crafting malicious input
Attack Pattern: Embedding Script in Nonscript Elements215
The technical details of buffer overflows
Attack Pattern: XSS in HTTP Headers216
Rootkits
Attack Pattern: HTTP Query Strings216
Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break
Attack Pattern: User-Controlled Filename217 software.
Attack Pattern: Passing Local Filenames to Functions That Expect a URL 225
Attack Pattern: Meta-characters in E-mail Header226
Attack Pattern: File System Function Injection, Content Based229
Attack Pattern: Client-side Injection, Buffer Overflow231
Attack Pattern: Cause Web Server Misclassification263
Attack Pattern: Alternate Encoding the Leading Ghost Characters267
Attack Pattern: Using Slashes in Alternate Encoding268
Attack Pattern: Using Escaped Slashes in Alternate Encoding270
Attack Pattern: Unicode Encoding271
•Table of Contents
Attack Pattern: UTF-8 Encoding273
• Index
Exploiting Software How to Break Code
Attack Pattern: URL Encoding273
ByGreg Hoglund,Gary McGraw
Attack Pattern: Alternative IP Addresses274
Publisher: Addison Wesley
Attack Pattern: Slashes and URL Encoding Combined274
Pub Date: February 17, 2004
ISBN: 0-201-78695-8
Attack Pattern: Web Logs275
Pages: 512
Attack Pattern: Overflow Binary Resource File293
Attack Pattern: Overflow Variables and Tags294
Attack Pattern: Overflow Symbolic Links294
How does software break? How do attackers make software break on purpose? Why are
firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys?
Attack Pattern: MIME Conversion295
What tools can be used to break software? This book provides the answers.
Attack Pattern: HTTP Cookies295
Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and
techniques used by bad guys to break software. If you want to protect your software from
Attack Pattern: Filter Failure through Buffer Overflow296 attack, you must first learn how real attacks are really carried out.
Attack Pattern: Buffer Overflow with Environment Variables297
This must-have book may shock you—and it will certainly educate you.Getting beyond the
script kiddie treatment found in many hacking books, you will learn about
Attack Pattern: Buffer Overflow in an API Call297
Attack Pattern: Buffer Overflow in Local Command-Line Utilities297
Why software exploit will continue to be a serious problem
Attack Pattern: Parameter Expansion298
When network security mechanisms do not work
Attack Pattern: String Format Overflow in syslog()324
Attack patterns
Reverse engineering
Classic attacks against server software
Surprising attacks against client software
Techniques for crafting malicious input
The technical details of buffer overflows
Rootkits
Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break
software.
Foreword
In early July 2003 I received a call from David Dill, a computer science professor at Stanford
University. Dill informed me that the source code to an electronic voting machine produced
by Diebold Election Systems, one of the top vendors, had leaked onto the Internet, and that |
|
• |
Table of Contents |
perhaps it would be worth examining it for security vulnerabilities. This was a rare |
|
• |
Index |
opportunity, because voting system manufacturers have been very tight with their
Exploiting Software How to Break Code
proprietary code. What we found was startling: Security and coding flaws were so prevalent
ByGreg Hoglund,Gary McGraw
that an attack might be delayed because the attacker might get stuck trying to choose from all the different vulnerabilities to exploit without knowing where to turn first. (Such delay tacticsPublisher:are notAddisonrecommendedWesley as a security strategy.) There were large, complex chunks of codePubwithDate:noFebruarycomments17, 2004. There was a single static key hard wired into the code for encrypting
vote tallies. Insecure pseudorandom number generators and noncryptographic checksums
ISBN: 0-201-78695-8
were used. And inspection of the CVS logs revealed an arbitrary, seemingly ad hoc source
Pages: 512
code management process. And then there were the serious flaws.
Was the Diebold voting machine example an isolated incident of poor quality control? I don't think so. Many companies such as Diebold are hard pressed to get their products to market
before their competitors. The company with the best, functionally correct system wins. This
How does software break? How do attackers make software break on purpose? Why are incentive model rewards the company with the product that is available first and has the
firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys? most features, not the one with the most secure software. Getting security right is very
What tools can be used to break software? This book provides the answers.
difficult, and the result is not always tangible. Diebold was unlucky: Their code was examined
in a public forum and was shown to be completely broken. Most companies are relatively safe
Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and in the assumption that independent analysts will only get to see their code under strict
techniques used by bad guys to break software. If you want to protect your software from nondisclosure agreements. Only when they are held to the fire do companies pay the kind of
attack, you must first learn how real attacks are really carried out.
attention to security that is warranted. Diebold's voting machine code was not the first highly
complex system that I had ever looked at that was full of security flaws. Why is it so difficult This must-have book may shock you—and it will certainly educate you.Getting beyond the to produce secure software?
script kiddie treatment found in many hacking books, you will learn about
The answer is simple. Complexity. Anyone who has ever programmed knows that there are
unlimited numbers of choices when writing code. An important choice is which programming
Why software exploit will continue to be a serious problem
language to use. Do you want something that allows the flexibility of pointer arithmetic with
the opportunities it allows for manual performance optimization, or do you want a type-safe When network security mechanisms do not work
language that avoids buffer overflows but removes some of your power? For every task, there
are seemingly infinite choices of algorithms, parameters, and data structures to use. For Attack patterns
every block of code, there are choices on how to name variables, how to comment, and even
how toReverselay outengineeringthe code relation to the white space around it. Every programmer is
different, and every programmer is likely to make different choices. Large software projects
Classic attacks against server software
are written in teams, and different programmers have to be able to understand and modify
the code written by others. It is hard enough to manage one's own code, let alone software
Surprising attacks against client software
produced by someone else. Avoiding serious security vulnerabilities in the resulting code is
challenging for programs with hundreds of lines of code. For programs with millions of lines
Techniques for crafting malicious input
of code, such as modern operating systems, it is impossible.
The technical details of buffer overflows
However, large systems must be built, so we cannot just give up and say that writing such
systems securely is impossible. McGraw and Hoglund have done a marvelous job of
Rootkits
explaining why software is exploitable, of demonstrating how exploits work, and of educating
the reader on how to avoid writing exploitable code. You might wonder whether it is a good Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break
idea to demonstrate how exploits work, as this book does. In fact, there is a trade off that software.
security professionals must consider, between publicizing exploits and keeping them quiet. This book takes the correct position that the only way to program in such a way that minimizes the vulnerabilities in software is to understand why vulnerabilities exist and how attackers exploit them. To this end, this book is a must-read for anybody building any networked application or operating system.
Exploiting Software is the best treatment of any kind that I have seen on the topic of software vulnerabilities. Gary McGraw and Greg Hoglund have a long history of treating this subject. McGraw's first book, Java Security, was a groundbreaking look at the security problems in the
Java runtime environment and the security issues surrounding the novel concept of untrusted mobile code running inside a trusted browser. McGraw's later book, Building Secure Software, was a classic, demonstrating concepts that could be used to avoid many of the vulnerabilities described in the current book. Hoglund has vast experience developing rootkits and implementing exploit defenses in practice.
After reading this book, you may find it surprising not that so many deployed systems can be hacked, but that so many systems have not yet been hacked. The analysis we did of an
•Table of Contents
electronic voting machine demonstrated that software vulnerabilities are all around us. The
• Index
fact that many systems have not yet been exploited only means that attackers are satisfied
Exploiting Software How to Break Code
with lower hanging fruit right now. This will be of little comfort to me the next time I go to BytheGregpollsHoglundand ,amGaryfacedMcGrawwith a Windows-based electronic voting machine. Maybe I'll just mail in an absentee ballot, at least that voting technology's insecurities are not based on software
flaws.
Publisher: Addison Wesley
Pub Date: February 17, 2004
Aviel D. Rubin
ISBN: 0-201-78695-8
Associate Professor, Computer Science
Pages: 512
Technical Director, Information Security Institute
Johns Hopkins University
How does software break? How do attackers make software break on purpose? Why are firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys? What tools can be used to break software? This book provides the answers.
Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and techniques used by bad guys to break software. If you want to protect your software from attack, you must first learn how real attacks are really carried out.
This must-have book may shock you—and it will certainly educate you.Getting beyond the script kiddie treatment found in many hacking books, you will learn about
Why software exploit will continue to be a serious problem
When network security mechanisms do not work
Attack patterns
Reverse engineering
Classic attacks against server software
Surprising attacks against client software
Techniques for crafting malicious input
The technical details of buffer overflows
Rootkits
Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break
software.