Transcript Exploiting Error Messages

CH14
Exploiting Information
Disclosure
Vincent
Introduction
• In this chapter, we will try to extract further
information from an application during an
actual attack.
• This mainly involves
– Interacting with the application in unexpected
and malicious ways
– Exploiting anomalies in the application’s behavior
in order to get information that is useful
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Many web applications return
informative error messages
when unexpected events
occur.
These messages may be useful
for attackers.
Exploiting Error Messages
-Script Error Messages
• Error arises in an interpreted web scripting
language, such as VBScript, the application
typically returns a simple message
disclosing what happened, and possibly the
line number of the file where the error
occurred
Exploiting Error Messages
-Script Error Messages
• Eg.
The input should be numeric , and we have supplied non-numeric characters
First,we should know that nothing is to be gained by
submitting non-numeric attack strings as this
parameter,
and we will be better off targeting other parameters.
Exploiting Error Messages
-Script Error Messages
• Eg.
The input should be numeric , and we have supplied non-numeric characters
Second,we can gain a better understanding of the
logic.
Because we know the line number where the error
occurred,
we may be able to confirm whether two different
requests are triggering the same error or different
errors.
Exploiting Error Messages
-Script Error Messages
• Eg.
The input should be numeric , and we have supplied non-numeric characters
Third,we can try to determine the sequence in which
different parameters are processed, by submitting bad input
within multiple parameters and identifying the location at which
an error occurs.
Finally,by systematically manipulating different parameters, we
may be able to map out the different code paths being executed
on the server.
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Many web applications return
informative error messages
when unexpected events
occur.
These messages may be useful
for attackers.
Exploiting Error Messages
- Stack Traces
• Most web applications are written in
languages that are more complex than simple
scripts
Java, C#, and Visual Basic .NET.
• When an unhandled error occurs, it is
common to see full stack traces being
returned to the browser in those languages.
Exploiting Error Messages
- Stack Traces
• Stack trace is a structured error message that
begins with a description of the actual error.
• The top line of the call stack shows the
function that generated the error,
• the next line shows the function that invoked
the previous function,
• and so on down the call stack until the
hierarchy of function calls is exhausted.
Exploiting Error Messages
- Stack Traces
Exploiting Error Messages
- Stack Traces
Information from stack trace
• It often describes the reason why an error
occurred. This may enable us to adjust our input
to avoid the error condition and advance our
attack.
• The call stack typically makes reference to a
number of library and third-party code
components .We can ….
– review the documentation for these components to
understand their intended behavior and
assumptions.
– create our own local implementation and test this to
know potential vulnerabilities.
Exploiting Error Messages
- Stack Traces
Information from stack trace
• The call stack includes the names of the
proprietary code components being used to
process the request. The naming scheme for
these and the interrelationships between
them
• may allow us to infer details about the
internal structure and functionality of the
application.
Exploiting Error Messages
- Stack Traces
Information from stack trace
• The stack trace often includes line numbers.
As with the simple script error messages
described previously,
• these may enable us to understand the
internal logic of individual application
components.
Exploiting Error Messages
- Stack Traces
Information from stack trace
• The error message often includes additional
information about the application and the
environment.
• In the preceding example, you can determine the
exact version of the ASP.NET platform being used.
• This enables us to investigate the platform for
known or new vulnerabilities, anomalous
behavior, common configuration errors, and so
on.
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Many web applications return
informative error messages
when unexpected events
occur.
These messages may be useful
for attackers.
Exploiting Error Messages
- Informative Debug Messages
• Some applications generate custom error
messages that contain a large amount of
debug information.
• These are normally implemented to facilitate
debugging during development and testing,
and
• often contain rich detail about the runtime
state of the application
Exploiting Error Messages
- Informative Debug Messages
Exploiting Error Messages
- Informative Debug Messages
• commonly included in those debug messages:
– Values of key session variables that can be
manipulated via user input.eg:login status
– Hostnames and credentials for back-end components
such as databases.
– File and directory names on the server.
Exploiting Error Messages
- Informative Debug Messages
• commonly included in those debug messages:
– Information embedded within meaningful session
tokens (see Chapter 7).
– Encryption keys used to protect data transmitted
via the client (see Chapter 5).
– Debug information for exceptions arising in native
code components,including the values of CPU
registers, contents of the stack, and a list of the
loaded DLLs and their base addresses (see
Chapter 15).
Exploiting Error Messages
- Informative Debug Messages
• When user can see these information, it may
signify a critical weakness to the security of
the application.
• By those information,we can
– further advance our attack, and
– find ways to manipulate the application’s state
and
– control the information retrieved.
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Many web applications return
informative error messages
when unexpected events
occur.
These messages may be useful
for attackers.
Exploiting Error Messages
- Server and Database Messages
• Informative error messages are often returned
by some back-end component such as a
– Database,
– Mail server, or
– SOAP server.
• When error occurs, the application will
typically respond with an HTTP 500 status
code, and the response body may contain
further information about the error.
Exploiting Error Messages
- Server and Database Messages
• In other cases, the application may return
a customized message to the user,
• sometimes including error information
generated by the back-end component
.
Exploiting Error Messages
- Server and Database Messages
Database error messages often contain
information that you can use to advance
an attack
For example, they often disclose the query
that generated the error, enabling you to
fine-tune a SQL injection attack:
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Many web applications return
informative error messages
when unexpected events
occur.
These messages may be useful
for attackers.
Exploiting Error Messages
- Using Public Information
• Because of the huge variety of web
application technologies and components in
common use
• we can often obtain further information
about the meaning of the message from
various public sources.
Exploiting Error Messages
- Using Public Information
Those from public information
• Often, an unusual error message is the result
of a failure in a specific API.
• Searching for the text of the message may
lead us to the documentation for this API or to
where the same problem is discussed.
Exploiting Error Messages
- Using Public Information
Those from public information
• Many applications employ third-party
components to perform specific common
tasks, such as searches, shopping carts, and
site feedback functions.
• Any error messages that are generated by
these components are likely to have arisen in
other applications, and to have been
discussed elsewhere.
Exploiting Error Messages
- Using Public Information
Those from public information
• Some applications incorporate source code
that is publicly available.
• By searching for these unusual error
messages, we may actually discover the
source code which implements the relevant
function.
• We can then review this and think how we
may be able to manipulate the application to
exploit a vulnerability.
Outline
• Exploiting Error Messages
–
–
–
–
–
•
•
•
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
Sometimes web applications give away
Gathering Published Information sensitive data is by actually publishing it
Using Inference
directly and there are various reasons why an
Preventing Information Leakage application may publish information.
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Why an application may publish
information can be of use to an attacker
• By design, as part of the application’s core
functionality.
• As an unintended side effect of another
function.
• Through debugging functionality that remains
present in the live application.
• Because of some vulnerability, such as broken
access controls.
Potentially sensitive information that
applications often publish to users
• Lists of valid usernames, account numbers, and
document IDs.
• User profile details, including user roles and privileges,
date of last login, and account status.
• The current user’s password (this is usually masked onscreen but is present in the page source).
• Log files containing information like sernames, URLs,
actions performed, session tokens, and database
queries.
• Application details in client-side HTML source, such as
commented-out links or form fields, and comments
about bugs.
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
Application may not
show any data to you
directly,
but it may behave in
ways that enable you
to reliably infer
information that is
of use.
Using Inference
- examining other categories of common vulnerability
We had learned before
• A registration function that enables you to enumerate
registered usernames on the basis of an error message
when an existing username is chosen (see Chapter 6).
• A search engine that allows you to infer the contents
of indexed documents that you are not authorized to
view directly (see Chapter 11).
• A blind SQL injection vulnerability in which you can
alter the application’s behavior by adding a binary
condition to an existing query,enabling to you extract
information one bit at a time (see Chapter 9).
Using Inference
- examining other categories of common vulnerability
And more now
• By different lengths of time of operatings
– Retrieved quickly from the server’s local cached
copy, retrieved more slowly from the relevant
back-end source. enabling a skilled attacker to
enumerate accounts that have been accessed
recently by other users.
Using Inference
- examining other categories of common vulnerability
And more now
• Request may depend upon whether a submitted
item of data is valid.
– Valid username
• Retrieve account information
• Update the audit log
• Perform computationally intensive operations to validate the
supplied password
– Not valid
• Reject
– Attacker can detect this timing difference, he may be
able to exploit it to enumerate valid usernames.
Using Inference
- examining other categories of common vulnerability
And more now
• Functions may perform an action on the basis of user
input which will time out if an item of submitted data
is not valid
• Eg. application may use a cookie to store the address of
a host located behind a front-end load balancer
– Attacker may be able to manipulate this address to scan
for web servers inside the organization’s internal network
• not part of the application infrastructure,immediately return an
error.
• nonexistent address is supplied, may time out attempting to
contact this address, before returning the same generic error
Outline
• Exploiting Error Messages
–
–
–
–
–
Script Error Messages
Stack Traces
Informative Debug Messages
Server and Database Messages
Using Public Information
• Gathering Published Information
• Using Inference
• Preventing Information Leakage
– Use Generic Error Messages
– Protect Sensitive Information
– Minimize Client-Side Information
Leakage
• Chapter Summary
There are various relatively
straightforward measures
that can be taken to reduce
information leakage to a
minimum and to withhold
altogether the most
sensitive data that can
critically undermine an
application’s security if
disclosed to an attacker.
Preventing Information Leakage
- Use Generic Error Messages
• The application should never return error
messages or debug information to the user’s
browser
• When an unexpected event occurs (such as an
error in a database query, a failure to read a
file from disk, or an exception in an external
API call), the application should return the
same, generic message informing the user
that an error occurred.
Preventing Information Leakage
- Use Generic Error Messages
• If it is necessary to record debug information
for support or diagnostic purposes, then this
should be held in a server-side log which is
not publicly accessible, and an
• index number may be returned to the user,
enabling them to report this when contacting
the helpdesk, if required
Preventing Information Leakage
- Use Generic Error Messages
• Most application platforms and web servers
can be configured to mask error information
from being returned to the browser:
– Application platform
• In ASP.NET,
• In the Java Platform
– Web server
• In Microsoft IIS
• In Apache
Preventing Information Leakage
- Protect Sensitive Information
• Application should not publish information that may be of
use to an attacker, including usernames, log entries, or
user profile
• If there is a need for certain users to access this
information, it should be protected by effective access
controls and made available only where strictly
necessary.
• Existing data should not be disclosed where it is not
necessary.eg.
– Stored credit card numbers should be displayed in truncated
form,
– Password fields should never be prefilled, even if masked
on-screen.
Preventing Information Leakage
- Minimize Client-Side Information Leakage
• Removed or modified to minimize the
disclosure of specific software versions, and
so on
• Steps of this measure are dependent upon
the technologies in use Eg.
– Microsoft IIS, the Server header can be removed
using URLScan in the IISLockDown tool.
– later versions of Apache, this can be achieved
using the mod_headers module.
Preventing Information Leakage
- Minimize Client-Side Information Leakage
• All comments should be removed from clientside code that is deployed to the live production
environment, including all HTML and JavaScript
• Such as Java applets and ActiveX controls,no
sensitive information should be hidden within
these thick-client components.
A skilled attacker can decompile or reverse
engineer these components to effectively recover
their source code
Thanks for listening!