Exploiting Information Disclosure

Exploiting InformationDisclosure

Vincent

CH14

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

• 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

Outline

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


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.


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



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

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.



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



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


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.


• 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


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.


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

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.



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






Application may not show any data to you directly,but it may behave in ways that enable you to reliably infer information that isof use.

Using Inference- examining other categories of common vulnerability

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

We had learned before


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

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.

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

And more now






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

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

Documents

Exploiting Information Disclosure