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



• 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.



• Eg.


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.



• Eg.


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



– Stack Traces





• Using Inference





Leakage

• Chapter Summary



for attackers.


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.


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.


Stack Traces


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.


Stack Traces


• 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.


Stack Traces


• 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.


Stack Traces


• 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



– Stack Traces





• Using Inference





Leakage

• Chapter Summary



for attackers.


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





• 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.



• 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).



• 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



– Stack Traces





• Using Inference





Leakage

• Chapter Summary



for attackers.


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.



• In other cases, the application may return

a customized message to the user,

• sometimes including error information generated by the back-end component

.



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



– Stack Traces





• Using Inference





Leakage

• Chapter Summary



for attackers.


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.



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.




• 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.




• 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


– Stack Traces




• Gathering Published Information

• Using Inference





Leakage

• Chapter Summary

Sometimes web applications give away sensitive data is by actually publishing it directly and there are various reasons why an application may publish information.

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



– Stack Traces





• Using Inference





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


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


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


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



– Stack Traces





• Using Inference

• Preventing Information Leakage




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.



• 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



• 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


- 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.


- 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.


- 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!

Exploiting Error Messages

Why an application may publish information can be of use to an attacker

Related documents

Products

Support

Exploiting Error Messages

Why an application may publish information can be of use to an attacker

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib