Exploiting Information - PowerPoint Presentation

Slide1

Exploiting InformationDisclosure

Vincent

CH14Slide2

Introduction

In this chapter, we will try to

extract further information from an application during an

actual attack

.

This mainly involves

I

nteracting

with the application in

unexpected and malicious ways

E

xploiting anomalies

in the application’s behavior in order to

get

information that is

usefulSlide3

Exploiting Error MessagesScript Error Messages

Stack TracesInformative Debug MessagesServer and Database Messages

Using Public Information

Gathering

Published Information

Using InferencePreventing Information LeakageUse Generic Error MessagesProtect Sensitive InformationMinimize Client-Side Information LeakageChapter Summary

Outline

Many web applications return informative error

messages when unexpected events occur.

These messages may be

useful for attackers

.

Slide4

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 occurredSlide5

Exploiting Error Messages-Script Error Messages

Eg

.

The input should be

numeric

, and we have supplied non-numeric characters

First,we

should

know that

n

othing

is to be gained by submitting non-numeric attack strings as this parameter,

and

we

will be

better off targeting other parameters.Slide6

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

.Slide7

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

Exploiting Error MessagesScript Error Messages

Stack TracesInformative Debug MessagesServer and Database Messages

Using Public Information

Gathering

Published Information

Using InferencePreventing Information LeakageUse Generic Error MessagesProtect Sensitive InformationMinimize Client-Side Information LeakageChapter Summary

Outline

Many web applications return informative error

messages when unexpected events occur.

These messages may be

useful for attackers

.

Slide9

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

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

Exploiting Error Messages- Stack TracesSlide12

Exploiting Error Messages- Stack Traces

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 traceSlide13

Exploiting Error Messages- 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. Information from stack traceSlide14

Exploiting Error Messages- 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

.Information from stack traceSlide15

Exploiting Error Messages- 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.Information from stack traceSlide16

Exploiting Error MessagesScript Error Messages

Stack TracesInformative Debug MessagesServer and Database Messages

Using Public Information

Gathering

Published Information

Using InferencePreventing Information LeakageUse Generic Error MessagesProtect Sensitive InformationMinimize Client-Side Information LeakageChapter Summary

Outline

Many web applications return informative error

messages when unexpected events occur.

These messages may be

useful for attackers

.

Slide17

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 applicationSlide18

Exploiting Error Messages- Informative Debug MessagesSlide19

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 statusHostnames and credentials for back-end components such as databases.

File and directory names on the server.Slide20

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

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

Exploiting Error MessagesScript Error Messages

Stack TracesInformative Debug MessagesServer and Database Messages

Using Public Information

Gathering

Published Information

Using InferencePreventing Information LeakageUse Generic Error MessagesProtect Sensitive InformationMinimize Client-Side Information LeakageChapter Summary

Outline

Many web applications return informative error

messages when unexpected events occur.

These messages may be

useful for attackers

.

Slide23

Exploiting Error Messages- Server and Database Messages

Informative error messages are often

returned by some

back-end component such as a

D

atabase, 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. Slide24

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

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:Slide26

Exploiting Error MessagesScript Error Messages

Stack TracesInformative Debug MessagesServer and Database Messages

Using Public Information

Gathering

Published Information

Using InferencePreventing Information LeakageUse Generic Error MessagesProtect Sensitive InformationMinimize Client-Side Information LeakageChapter Summary

Outline

Many web applications return informative error

messages when unexpected events occur.

These messages may be

useful for attackers

.

Slide27

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

Exploiting Error Messages- Using 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.

Those from public informationSlide29

Exploiting Error Messages- Using 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.

Those from public informationSlide30

Exploiting Error Messages- Using 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.

Those from public informationSlide31

Outline

Exploiting Error MessagesScript Error Messages

Stack Traces

Informative Debug Messages

Server and Database Messages

Using Public InformationGathering Published InformationUsing InferencePreventing Information LeakageUse Generic Error Messages

Protect Sensitive InformationMinimize Client-Side Information LeakageChapter SummarySometimes web applications give away sensitive data is by actually publishing it

directly and there are various reasons why an application may publish

information.Slide32

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

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

Outline

Exploiting Error MessagesScript Error Messages

Stack Traces

Informative Debug Messages

Server and Database Messages

Using Public InformationGathering Published InformationUsing InferencePreventing Information LeakageUse Generic Error Messages

Protect Sensitive InformationMinimize Client-Side Information LeakageChapter SummaryApplication

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

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 beforeSlide36

Using Inference- examining other categories of common vulnerability

By

different

lengths of

time of

operatingsRetrieved 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 nowSlide37

Using Inference- examining other categories of common vulnerability

Request

may depend upon whether a submitted item of data is valid.

Valid

username

Retrieve account informationUpdate the audit logPerform computationally intensive operations to validate the supplied password

Not validRejectAttacker can detect this timing difference, he may be able to exploit it to enumerate valid usernames.

And more nowSlide38

Using Inference- examining other categories of common vulnerability

F

unctions

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 balancerAttacker 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 nowSlide39

Outline

Exploiting Error MessagesScript Error Messages

Stack Traces

Informative Debug Messages

Server and Database Messages

Using Public InformationGathering Published InformationUsing InferencePreventing Information LeakageUse Generic Error Messages

Protect Sensitive InformationMinimize Client-Side Information LeakageChapter SummaryThere

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

Preventing Information Leakage- Use Generic Error Messages

The application should

never return

error

messages or debug information

to the user’s browserWhen 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.Slide41

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 requiredSlide42

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 PlatformWeb serverIn Microsoft IISIn ApacheSlide43

Preventing Information Leakage- Protect Sensitive Information

A

pplication

should not publish information that may be of use to an attacker, including usernames, log entries, or user profile

I

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

Preventing Information Leakage- Minimize Client-Side Information Leakage

R

emoved

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

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 codeSlide46

Thanks for listening!