- •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
Audit Poisoning
Up to this point we have focused on attacks against filters or the classification decisions made by servers. Another area in which character obfuscation comes in handy is in manipulating log files. There are many real-world examples in which attackers confuse the log file to
• Table of Contents
escape detection. This is an excellent technique to avoid creating trusted forensic evidence.
•Index
Exploiting Software How to Break Code
ByGreg Hoglund,Gary McGraw
AttackPublisher:Pattern:Addison WesleyWeb Logs
Pub Date: February 17, 2004
ISBN: 0-201-78695-8
Escape characters are often translated before being printed to the log file. For example,Pag s:under512 IIS the string /index%2Easp is recorded in the log file as
/index.asp. A more complicated string can be used to record fake entries in the logfile. For example:
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.
/index.asp%FF200%FFHTTP/1.1%0A00:51:11%FF[192.168.10.10]%FFGET%FF
This must-have book may shock you—and it will certainly educate you.Getting beyond the script/cgi-kiddiebin/phftreatment 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
This string will force a carriage return in the log file and forge a fake entry
showing the address 192.168.10.10 getting the cgi-bin/phf file. Attack patterns
Reverse engineering
This kind of problem has taken many forms over the years. In the worst cases, exploits have
Classic attacks against server software
been written that will execute when the log file is piped through grep or some other log file
analysis script. In this case, the attack is aimed squarely at a security mechanism. Clearly,
Surprising attacks against client software
many layers of encoding and interpreting can get involved here. For those organizations
using simple log file analysis, here is a simple question: Can you trust the characters in your
Techniques for crafting malicious input log file?
The technical details of buffer overflows
Note that only log analysis tools that "do stuff" with active content will be susceptible to
attacks like this. Simple tools like grep are unlikely to suffer from such problems. Of course,
Rootkits
even simple tools may have bugs or flaws that can be exploited (the fun part being that such
tools are often invoked from root or administrator).
Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break software.
Conclusion
At the beginning of this chapter, we invoked the complexity problem in open dynamical systems, and then went on to discuss the complicated ways that input can influence state in computer software. Throughout the chapter we provided supporting evidence for our
• |
Table of Contents |
complexity claims through specific examples, showing how input can be specially crafted so |
|
• |
Index |
that it can subvert filtering mechanisms and run-of-the-mill IDS equipment. But we've really
Exploitingonly scratchedSoftwaretheHowsurfaceto Break. Code
ByGreg Hoglund,Gary McGraw
Security problems related to state over time (the dynamics of a system) are destined to
become more and more difficult and relevant as well-worn, easy-to-identify bugs such as
Publisher: Addison Wesley
buffer overflows are eradicated in code. All good attackers know to examine state very closely
Pub Date: February 17, 2004
and to measure how user input can be used to induce insecure states. As systems become
ISBN: 0-201-78695-8
more distributed, attacks will with more regularity take advantage of race conditions and state desychronizationPages: 512 between far-flung parts. Solving these difficult problems will require another generation of tools, more sophisticated techniques, and some creative imagination.
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.