Chapter 4. Exploiting Server Software
Hacking a computer by sitting down in front of it with a boot disk borders on the trivial.
However, a boot disk attack requires sitting in front of a console that may have physical |
|
• |
Table of Contents |
controls (including, say, armed guards and dogs). The only serious skill required to carry out
•Index
this sort of attack is breaking and entering. For this reason, physical security of the armed
guard sort is necessary to secure the most security-critical computers in the world (think
ByGreg Hoglund,Gary McGraw
National Security Agency). Of course, taken to the extreme, the most secure computer is not
connected to a network, remains "off" at all times, has its disk wiped, and is buried under
fourPublisher:tons ofAddisonconcreteW sley. The problem with extreme physical security is that the most secure
computer also appears to be completely useless! In the real world people like to do things
Pub Date: February 17, 2004
with their computers. So they plug them in, boot them up, wire them to the Net, and start
ISBN: 0-201-78695-8
tapping away at the keyboard.
Pages: 512
On the Internet, very little is done to secure most machines. Insecure machines, plugged in right out of the box are "naked." The Internet is, for the most part, a collection of naked machines strung together like so many tin cans with string between them. The problem is so bad that a script kiddie wanna-be can literally download an exploit tool that is more than two
How doesfroms ftwarepublicreak? How do attackers make software break on purpose? Why are years old Web site and still successfully attack surprisingly large number of
firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys? machines. There are always lame targets to practice against on the Net. In more realistic
What tools cantargetbe used to break software? This book providesusingthe answers.
scenarios, a network will be somewhat more secure, the latest software patches,
running an intrusion detection system to uncover known attacks, and having a firewall or two
Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and with some real auditing equipment to boot.
techniques used by bad guys to break software. If you want to protect your software from
attack, you must first learn how real anywhere,ttacks are really carried out.
Of course, software can be exploited not just on machines connected to the
Internet. "Old-fashioned" networks still exist in the form of telephone networks, leased lines,
This must-have book may shock you—and it will certainly educate you.Getting beyond the high-speed laser transmission, frame relay, X.25, satellite, and microwave. But the risks are
script kiddie treatment found in many hacking books, you will learn about similar, even if the communications protocols are not.
Remote attacks—attacks across the network—are much less dangerous (to the attacker) from
Why software exploit will continue to be a serious problem
a physical perspective than attacks requiring physical access to a machine. It's always good
to avoid physical peril such as bullet wounds and dog bites (not to mention prison). However,
When network security mechanisms do not work
remote attacks tend to be technically more complex, requiring more than a modicum of
engineering skill. A remote attack always involves attacking networked software. Software
Attack patterns
that listens on the network and performs activities for remote users is what we call server
software. Server software is the target of remote attacks. Reverse engineering
This chapter is about exploiting server software. We focus mostly on Internet-based software, Classic attacks against server software
but keep in mind that other forms of server software fall prey to the same attacks we
describe here. Server software can be exploited for any number of reasons. Perhaps the Surprising attacks against client software
programmer had a lack of security expertise. Perhaps the designer made bad assumptions
aboutTechniquesthe friendlinessfor craoftingthe environmemaliciousnput.Perhaps poor development tools or broken
protocols were used. All these problems lead to vulnerabilities. A number of exploits have as their rootThe technicalcause incrediblydetails ofsimplebuffer(andoverflowssilly) mistakes such as misused APIs (think gets()).
These kinds of bugs appear to be glaring over sights on the part of developers, but remember
Rootkits
that most developers today remain blithely unaware of software security issues. In any case,
whether such vulnerabilities are trusted input vulnerabilities, programming errors,
Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break miscalculated computations, or simple syntax problems, taken together they all lead to
software. remote exploit.
The most basic kinds of attack we cover in this chapter are introduced in depth in books like
Hacking Exposed [McClure et al., 1999]. Most simple server attacks have been captured in highly available tools that you (and others) can download off the Internet. If you need more exposure to the basics of server-side attack, and the use of simple tools, check out that book. We begin here where they left off.
In this chapter we introduce several basic server-side exploit issues, including the trusted
input problem, the privilege escalation problem, how to find injection points, and exploiting trust through configuration. We then go on to introduce a set of particular exploit techniques with lots of examples so that you can see how the general issues are put into practice.
•Table of Contents
•Index
Exploiting Software How to Break Code
ByGreg Hoglund,Gary McGraw
Publisher: Addison Wesley
Pub Date: February 17, 2004
ISBN: 0-201-78695-8
Pages: 512
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.
The Trusted Input Problem
One very common assumption made by developers and architects is that the users of their
software will never be hostile. Unfortunately, this is wrong. Malicious users do exist,
•especially whenTablesoftwaref Contentstakes input directly from the Internet. Another common mistake is a
logical• fallacyIndexbased on the idea that if the user interface on the client program doesn't allow
forExploitingcertainSoftwareinput toHowbetogenerated,Break Co then it can't happen. Wrong again. There is no need for an
attacker to use particular client code to generate input to a server. An attacker can simply dip
ByGreg Hoglund,Gary McGraw
into the sea of raw, seething bits and send some down the wire. Both of these problems are
the genesis of many trusted input problems.
Publisher: Addison Wesley
Pub Date: February 17, 2004
Any raw data that exist outside the server software cannot and should not be trusted. Client-
side securityISBN: 0-is201an-78695oxymoron-8 . Simply put, all clients will be hacked. Of course the real
problemPages:is one512 of client-side trust. Accepting anything blindly from the client and trusting it
through and through is a bad idea, and yet this is often the case in server-side design.
Consider a typical problem. If what should be untrusted data are instead trusted, and the
input gets used to build a filename or to access a database, the server code will have
explicitly relinquished local system access to (a possibly undeserving) client. Misplaced trust How does software break? How do attackers make software break on purpose? Why are
is a pervasive problem—perhaps the most prevalent of all security problems. A potential firewalls, intrusion detection systems, and antivirus software not keeping out the bad guys? attacker should not be implicitly trusted by a software system. The transactions performed by What tools can be used to break software? This book provides the answers.
a user should always be treated as hostile. Programs that take input from the Internet (even
if it is supposedly "filtered" by an application firewall) must be designed defensively. Yet, Exploiting Softwareis loaded with examples of real attacks, attack patterns, tools, and
most programs happily take user input and perform file operations, database queries, and techniques used by bad guys to break software. If you want to protect your software from
system calls based on the raw input.
attack, you must first learn how real attacks are really carried out.
One basic problem involves the use of a "black list" to filter and remove "bad input." The This must-have book may shock you—and it will certainly educate you.Getting beyond the
problem with this approach is that creating and maintaining an exhaustive and complete script kiddie treatment found in many hacking books, you will learn about
black list is difficult at best. A much better approach is to specify what inputs should be
allowed in a "white list." Black listing mistakes make the attacker's job much easier.
Why software exploit will continue to be a serious problem
Many vulnerabilities exist because user input is trusted and used in ways that allow the user
to open arbitrary files, control database queries, and even shut down the system. Some of When network security mechanisms do not work
these attacks can be carried out by anonymous network users. Others require a user account
and aAttackpasswordpatternsbefore they can be properly exploited. However, even normal users shouldn't
be able to dump entire databases and create files in the root of the file server. 
Reverse engineering
In many cases of standard client–server design, a client program will have a user interface
Classic attacks against server softwarebetween
and thus will act as a "middle layer" a user and the server program. For example, a
form on a Web page represents a middle layer between a user and a server program. The
Surprising attacks against client software
client presents a nice graphical form that the user can enter data into. If the user presses the
"submit" button, the client code gobbles up all the data on the form, repackages it in a
Techniques for crafting malicious input special format, and delivers it to the server.
The technical details of buffer overflows
User interfaces are intended to place a layer of abstraction between a human and a server
program. Because of this, user interfaces almost never show the nuts and bolts of what is
Rootkits
being transmitted from a client to a server. Likewise, a client program tends to mask much of
the data the server may provide. The user interface "frobs" the data, converts it for use, Exploiting Softwareis filled with the tools, concepts, and knowledge necessary to break
makes it look pretty, and so forth. However, behind the scenes, raw data transmission is software.
taking place.
Of course, the client software is only assisting the user in creating a specially formatted request. It is entirely possible to remove the client code from the loop altogether as long as the user can create the specially formatted request manually. But even this simple fact seems to escape notice in the "security architecture" of many on-line applications. Attackers rely on the fact that they can craft hostile client programs or interact with servers directly. One of the most popular "evil client" programs in use by attackers is called netcat. netcat simply opens a dumb port to a remote server. Once this port is established, an attacker can manually enter
keystrokes or pipe custom output down the wire to the remote server. Voila, the client has disappeared.
|
Attack Pattern: Make the Client Invisible |
• |
Table of Contents |
• |
Index |
|
Remove the client from the communications loop by talking directly with the |
Exploiting Software How to Break Code |
|
|
server. Explore to determine what the server will and will not accept as input. |
ByGreg Hoglund,Gary McGraw |
|
|
Masquerade as the client. |
Publisher: Addison Wesley
AnyPubtrustDate:thatFebruaryis placed17, 2004in a client by the server is a recipe for disaster. A secure server programISBN:should0-201-be78695explicitly-8 paranoid about any data submitted over the network and must alwaysPages:assume512 that a hostile client is being used. For this reason, secure programming practice can never include solutions based on hidden fields or Javascript form validation. For the same reason, secure design must never trust input from a client. For more on how to avoid the trusted input problem, see Writing Secure Code [Howard and LeBlanc, 2002] and
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.