Chapter 2. Attack Patterns
One very real problem in computer security is the lack of commonly accepted terminology.
Software security is no exception. Confusion by the popular press (which jumps at the chance |
|
• |
Table of Contents |
to cover computer security issues) doesn't help. Nor does intentional misuse of terms by
•Index
unscrupulous vendors trying to con you into buying their wares. In this section we'll informally define some terms that are used throughout the book. Some people may not agree
ByGreg Hoglund,Gary McGraw
with the way we're defining and using terms. Suffice it to say, our aim is clarity and consistency, and we think carving up the space our way makes sense for this discussion.
Publisher: Addison Wesley
The first and most important definition is the target. Half the fun of exploiting software is
Pub Date: February 17, 2004
picking your target. A software program that is under active attack, either remotely or
ISBN: 0-201-78695-8
locally, is called target software.
Pages: 512
A target could be a server on the Internet, a telephone switch, or an isolated system that controls antiaircraft capability. To attack a target, it must be analyzed for vulnerabilities. Sometimes this is called risk assessment. If a high-risk vulnerability is discovered, it is ripe for exploitation. Vulnerability is not an exploit, but it is necessary for an exploit.
How does software break? How do attackers make software break on purpose? Why are
Software produces output. While testing, we observe software to determine whether a firewalls, intrusion detection systems, and antivirus software noutputkeeping out the bad guys?
fault has resulted in a failure. The more output provided by the software, the easier it is to What tools can be used to break software? This book provides the answers.
detect faulty internal states and so forth. Observability is the probability that a failure will be
[1]
noticeableExploitinginSoftwarethe outputis loadedspace. withThexamplgreatesr theofrealobservability,attacks, attackheeasierpatterns,it istools,testandgiven
techniquespiece of softwareused by.Softwarebad guysthatto breakproducessoftwareno external.If yououtputwant tohasprotectno wayyourto indicatesoftwareafromfailure. attack,A highlyyoubservablemust firstproglearamnhowmightrealbeattacksone thatarehasreallyembeddedcarried outdebug. output capability. A program that normally has low observability can be altered using a debugger to provide high
This must-have book may shock you—and it will certainly educate you.Getting beyond the observability. This would be the case if data flow tracer were attached to the target, for
script kiddie treatment found in many hacking books, you will learn about example.
[1] For more information on the importance of observability and testing, see Software Fault Injection [Voas
Whyand McGraw,soft are1999exploit]. will continue to be a serious problem
Exploiting software encompasseschanismsthe idea of observability, especially when we think about When network security do not work
remote exploits. Throughout the book we discuss a number of techniques for improving observabilityAttackpatt.Thernsbasic idea is to gather as much information about a program's possible internal states as possible, both statically while it is being constructed and dynamically while
Reverse engineering it is running.
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.
A Taxonomy
To measure risk in a system, vulnerabilities must be identified. One basic problem is that software vulnerabilities remain, for the most part, uncategorized and unidentified. Some basic science exists, but it is sketchy and dated. The good news is that during the last few
• |
Table of Contents |
years, a large body of specific software exploits have been identified, discussed, and |
|
• |
Index |
publicized in various parts of the software community.
Exploiting Software How to Break Code
Two common collections of vulnerabilities include the bugtraq mailing list, where many
ByGreg Hoglund,Gary McGraw
exploits are first publicly discussed (http://www.bugtraq.com), and the CVE, where scientists
and academics catalog vulnerabilities. Note that in the early 2000s, bugtraq became a
Publisher: Addison Wesley
commercial enterprise now exploited by Symantec to load their proprietary databases (which
Pub Date: February 17, 2004
they happily rent to subscribers). The CVE, administered by Mitre, is another attempt to
ISBN: 0-201-78695-8
collect bug and flaw data in one place. The problem with the CVE is that it lacks much in the way ofPages:categorization512 .
The two forums we mention do begin to allow researchers to ascertain that certain software bugs commonly occur in many diverse products. There are, after all, a number of general problems in software. Although two software products may suffer from a particular instance
of a buffer overflow bug, taken together with other instances, a general class of problems can How does software break? How do attackers make software break on purpose? Why are
be defined. In many respects, a buffer overflow looks the same no matter which software firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys?
product it occurs in.
What tools can be used to break software? This book provides the answers.
In our taxonomy, vulnerabilities (both bugs and flaws) are grouped together by central Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and
characteristics and give rise to particular attack patterns. This is based on the following techniques used by bad guys to break software. If you want to protect your software from
premise:Related programming errors give rise to similar exploit techniques. Thus, we attack, you must first learn how real attacks are really carried out.
aim to cover the generic problems of software rather than specific, known vulnerabilities.[2] A
general classification provides a framework that can be used when auditing large software This must-have book may shock you—and it will certainly educate you.Getting beyond the
systems for vulnerabilities to understand and assess results. Such a framework can help an script kiddie treatment found in many hacking books, you will learn about
auditor locate specific types of software problems. Of course, such information is useful both in defending systems and in attacking them.
Why software exploit will continue to be a serious problem
[2] We will, of course, provide plenty of real examples throughout the text.
When network security mechanisms do not work
Attack patterns
Bugs
Reverse engineering
Abug is a software problem. Bugs may exist in code and may never be executed. Although
the term bug is applied quite generally by many software practitioners, we reserve use of the Classic attacks against server software
term to encompass fairly simple implementation problems. For example, misusing strcpy() in C andSurprisingC++ attackssuch wayagainstthatclienta buffersoftwareoverflow condition exists is a bug. For us, bugs are implementation-level problems that can be easily "squashed." Bugs can exist only in code.
Techniques for crafting malicious input
Designs do not have bugs. Code scanners are great at finding bugs.
The technical details of buffer overflows
Flaws
Rootkits
Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break Aflaw is also a software problem, but a flaw is a problem at a deeper level. Flaws are often
software.
much more subtle than simply an off-by-one error in an array reference or the use of a dangerous system call. A flaw is instantiated in software code but is also present (or absent!) at the design level. For example, several classic flaws exist in error handling and recovery systems that fail in an insecure fashion. Another example is exposure to cross-site scripting attacks through poor design. Flaws may exist in software and may never be exploited.
Vulnerabilities
Bugs and flaws are vulnerabilities. A vulnerability is a problem that can be exploited by an attacker. There are many kinds of vulnerability. Computer security researchers have created taxonomies of vulnerabilities.[3]
[3] Ivan Krusl and Carl Landwehr are two scientists who have studied vulnerabilities and have built taxonomies. See Krusl [1998] and Landwehr et al. [1993] for more information.
Security vulnerabilities in software systems range from local implementation errors (e.g., use
• |
Table of Contents |
of the gets() function call in C/C++), through interprocedural interface errors (e.g., a race |
|
• |
Index |
condition between an access control check and a file operation), to much higher design-level
ExploitingmistakesSoftware(e.g., errorHow handlingto Break Codeand recovery systems that fail in an insecure fashion, or
object-sharing systems that mistakenly include transitive trust issues[4]).
ByGreg Hoglund,Gary McGraw
[4] A transitive trust issue may occur when an object is shared with an agent that may then go on to share
Publisher: Addison Wesley
the object further (in a manner that can't be controlled by the original granter). If you dole out a secret to
somebody, she may choose to share it, even if you don't want her to.
Pub Date: February 17, 2004
ISBN: 0-201-78695-8
Attackers generally don't care whether a vulnerability is the result of a flaw or a bug,
Pages: 512
although bugs tend to be easier to exploit. Some vulnerabilities can be directly and completely exploited; others only provide a toehold for a more complex attack.
Vulnerabilities can be defined in terms of code. The more complex a vulnerability, the more code must be examined to detect it. Sometimes just looking at code doesn't work though. In manyHow doescases,softwarehigherbreak?level Howdescriptiondo attackersof what'smakegoingsoftwareon otherbreakthanonwhatpurpose?is availableWhy arein code isfirewalls,necessaryintrusion. In manydetectioncases,systems,a design anddescriptionantivirusatsoftwarewhite boardnot kelepingvel isoutnecessarythe bad. guys?Other times,What toolsdetailcanregardingbe usedtheto breakexecutionsoftware?environmentThis bookmustprovidesbe knownthe.answersSuffice .it to say that there is a significant difference between trivial program errors (bugs) and architectural flaws. ExploitingTrivial errorsSoftwarecan nisbeloadedfixedwithin a singleexampleslineofofrealcode,attacks,whereasattackdesignpatternflaws,requiretools, and trechndesignquesthatusedalmostby badlwaysguystouchesbr akmultiplesoftwareareas. If you. want to protect your software from attack, you must first learn how real attacks are really carried out.
For example, we can usually determine that a call to gets() in a C/C++ program can be Thisexploitedmust-inhavebufferbookoverflowmay shockattackyou—withouand it knowingwill certainlyan thingeducateaboutyouthe.Gettingrest ofbeyondthe code,theits design,script kiddieor anythingtreatmentaboutfoundtheinexecutionmany hackingenvironmentbooks,.youToexpwilloitlearnbufferaboutoverflow in gets(), the attacker enters malicious text to a standard program input location. Hence, a gets()
vulnerability can be detected with good precision using a very simple lexical analysis. 
Why software exploit will continue to be a serious problem
More complex vulnerabilities involve interactions among more than one location in the code.
When network security mechanisms do not work
Precisely detecting race conditions, for example, depends on more than simply analyzing an
isolated line of code. It may depend on knowing about the behavior of several functions,
Attack patterns
understanding sharing among global variables, and having knowledge of the OS providing
the execution environment. 
Reverse engineering
Because attacks are becoming more sophisticated, the notion of what kind of vulnerabilities
Classic attacks against server software
actually matter is constantly changing. Timing attacks are now common, whereas only a few
years ago they were considered exotic. Similarly, two-stage buffer overflow attacks involving Surprising attacks against client software
the use of trampolines were once the domain of software scientists, but are now used in 0day
exploits.
Techniques for crafting malicious input
The technical details of buffer overflows
Design Vulnerabilities
Rootkits
Design-level vulnerabilities carry this trend further. Unfortunately, ascertaining whether a Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break
program has design-level vulnerabilities requires great expertise. This makes finding designsoftware.
level flaws not only hard to do, but particularly hard to automate. Design-level problems appear to be prevalent and are at the very least a critical category of security risk in code. Microsoft reports that around 50% of the problems uncovered during the "security push" of 2002 were design-level problems.[5] Clearly, more attention must be paid to design problems to address software security risks properly.
[5] Michael Howard, personal communication.
Consider an error handling and recovery system. Failure recovery is an essential aspect of
security engineering. But it's also complicated, requiring interaction between failure models, redundant designs, and defense against denial-of-service attacks. In an object-oriented
program, understanding whether an error handling and recovery system is secure involves
ascertaining a property or properties spread throughout a multitude of classes that are
themselves spread throughout the design. Error detection code is usually present in each object and method, and error-handling code is usually separate and distinct from the
detection code. Sometimes exceptions propagate up to the system level and are handled by
the machine running the code (e.g., Java 2 VM exception handling). This makes it quite |
|
• |
Table of Contents |
difficult to determine whether a given error handling and recovery design is secure. This
•Index
problem is exacerbated in transaction-based systems commonly used in commercial e- commerce solutions, in which functionality is distributed among many different components
ByGreg Hoglund,Gary McGraw running on several servers.
Other examples of design-level problems include object sharing and trust issues, unprotected
Publisher: Addison Wesley
data channels (both internal and external), incorrect or missing access control mechanisms,
Pub Date: February 17, 2004
lack of auditing/logging or incorrect logging, ordering and timing errors (especially in multithreaded systems), and many others. For more on design problems in software and how to avoid them, see Building Secure Software [Viega and McGraw, 2001].
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.