CHMAG-Feb2013

www.chmag.in February 2013 | Page - 1



Content-Type Attack: Dark Hole in a Secure Environment

Introduction

Content-Type attacks are related to the

vulnerabilities in client side software that

are used to read the content like adobe

reader, Microsoft office, Image viewer.

Attackers attempt to exploit programming

flaws in that code to induce memory

corruption issues, resulting in their own

attack code being run on the victim

computer that opened the PDF or DOC file.

Content-Type attack is Dark Hole in a

secure environment due to following

reasons:

Un-detective Nature: There are

multiple types of attack e.g. cross-

site scripting, SQL injection, DNS

cache poisoning, HTTP tunneling

etc. Though there are multiple

devices like WAF (Web Application

Firewall), IPS (Intrusion Prevention

System) that can be used to detect

and prevent these attacks, it's

difficult to detect content-

type attack.

Ignorance: Most of the penetration

testing assignments focus on web-

application testing and some are for

critical servers in the infrastructure.

But very rarely organizations focus

on the workstation in the

environment. Even if the

organizations look for workstation

related vulnerabilities and patches, it

is still limited to Windows or any

other critical application running in

the environment. Last, if any

organization looks into vulnerability

of content reading software then 0-

day attacks cannot be avoided

without any other preventive

measurements.

False sense of Security: When we

talk about security of any

environment components like

firewall, IPS, IDS, Anti-Virus comes

first in the mind. But having these

components does not mean that

environment is completely secure. It

also required best configuration of

these component as well as other

components in the environment like

Proxy Server, outbound policy at

internet gateway etc.


Content-Type Attack Process:

This attack document is sent by an

attacker to a victim, perhaps using a

compromised machine to relay the

e-mail to help conceal the attacker’s

identify.

If the victim opens the file attached

to the e-mail, the application

registered for the file type launches

and starts parsing the file.

In this malicious file, the attacker

will have embedded malformed

content that exploits a file-parsing

vulnerability, causing the application

to corrupt memory on the stack or

heap.

Successful exploits transfer control

to the attacker’s shell code that has

been loaded from the file into

memory.

The shell code often instructs the

machine to write out an EXE file

embedded at a fixed offset and run

that executable. After the EXE file is

written and run, the attacker’s code

writes out a “clean file” also

contained in the attack document

and opens the application with the

content of that clean file.

In the meantime, the malicious EXE

file that has been written to the file

system is run, carrying out whatever

mission the attacker intended.

Malicious Content-Type

Attack Document

Structure

A malicious document is

combination of multiple

components that is used by

attacker to compromise any

victim machine. Following

are the different

components.

Vulnerability:

This code is used by attacker

to exploit the vulnerability

of the content reading

software. After successful

exploitation control gets

transfer to shellcode part of the

document.

ShellCode: This part of document

is used by attacker for post

exploitation activity, which can vary

from executing binary file,

downloading malicious file,

installation of key-logger, reverse

tunnel to attacker controlled server

and many more.


Embedded binary code:

Embedded binary code is the

executable code that attacker wants

to execute on victim machine as part

of post-exploitation activity.

Clean Document within

context: This part is used by

attacker to clean the evidences or to

cover the attack vector.

PDF File Analysis

This part includes brief about PDF file

structure, PDF file format and different

objects which are interest of attacker as well

as for analysis of PDF file. Also analysis of

PDF using python based scripts.

PDF file structure: PDF file is divided

into four main parts - PDF Header, Body,

Cross-Reference table and Trailer.

PDF Header: The first line of the

PDF specifies the version of a PDF

file format. These headers are the

topmost portion of a document. It

reveals the basic information of a

PDF file, for example, "%PDF-1.4"; it

means that this PDF format is the

fourth version. By the way, to read a

PDF, you need a later version of PDF

reader, i.e. you have to

download Adobe

Acrobat 5.0 to view

%PDF-1.4.

PDF Body:

The body of a PDF file

consists of objects that

compose the contents

of the document.

These objects include

image data, fonts,

annotations, text

streams and so on. Users can also

integrate invisible objects or

elements. These objects embed the

interactive features in a document

like animation or graphics. A user

can also implement logical structure

in the document. You can also make

the content of a PDF document more

secure by implementing security

features. One can protect the content

of a document from unauthorized

printing, viewing, editing or

modifying. The body of a PDF also

supports two types of numbers

called integers and real numbers.

The Cross-Reference Table: The

cross-reference table consists of

links to all the objects or elements in

a file. You can deploy this feature to

navigate to other pages or content in

a document. When users update


their PDF files, they will

automatically get updated in the

cross-reference table. One can also

trace the updated changes in the

cross-reference table.

The Trailer: The trailer contains

links to cross-reference table and

always ends up with "%%EOF" to

identify the end of a PDF file. The

"%%EOF" is necessary for a PDF file,

if this line missed, the PDF-file is not

complete and may not be processed

correctly. This is not same as

PostScript files. If the last few lines

of a PostScript file missed, you will

still print most of the pages. For a

PDF file, you lose everything. The

trailer enables a user to navigate to

the next page by clicking on the link

provided.

PDF file format

PDF file format use Post-Scripting language

to describe a PDF file. In which one object

contains reference of other objects and form

a tree like structure as shown below.

In the body (the object list), there are

following different kind of definitions:

Indirect reference (n r R):

References an object, e.g. 5 0 R. If

the objects doesn't exist this is

equivalent to the Null object (see

below).

Name (/Name): Names are

identifiers. If you know Lisp or

Scheme, this is similar to the quote

special form (e.g. 'ok). The initial /

introduces the name but isn't part of

the name; this is similar to $ in

Bash, Perl or PHP.


Dictionary (<< ... >>): This is

an unordered list of (Name, Object)

pairs. They are essentially hash

tables. The Object part can be

another Name (e.g. /Type /Font).

Array ([x y z ...]): an ordered

list of objects, e.g. [0 0 200 200].

String Object ((text)): text. The

complete syntax is complex, but for

now suffice to say it's text between

parenthesis, e.g. (Hello, world!).

Stream (<< /Length ... >>

stream ... endstream):

Embedded data can be compressed.

It starts with a dictionary that

describes the stream such as its

length or the encoding (/Filter) is

uses.

PDF File analysis using scripts

Multiple scripts are available publically to

analyze PDF file. For demonstration

purpose I will use pdfid.py and pdf-

parser.py scripts developed by Didier

Stevens.

PDF analysis using pdf-parser.py: This

tool will parse a PDF document to identify

the fundamental elements used in the

analyzed file. It will not render a PDF

document.

The stats option display statistics of the

objects found in the PDF document. Use

this to identify PDF documents with

unusual/unexpected objects, or to classify

PDF documents. The search option searches

for a string in indirect objects (not inside

the stream of indirect objects). The search is

not case-sensitive, and is susceptible to the

obfuscation technique.

filter option applies the filter(s) to the

stream. For the moment, only FlateDecode

is supported.

The raw option makes pdf-parser output

raw data.

OBJECT outputs the data of the indirect

object which ID was specified. This ID is not

version dependent. If more than one object

have the same ID (disregarding the version),

all these objects will be outputted.

reference allows you to select all objects

referencing the specified indirect object.

This ID is not version dependent.

type allows you to select all objects of a

given type. The type is a Name and as such

is case-sensitive and must start with a slash-

character (/).


PDF analysis using pdfid.py

This tool is not a PDF parser, but it will scan

a file to look for certain PDF keywords,

allowing you to identify PDF documents

that contain (for example) JavaScript or

execute an action when opened. PDFiD will

also handle name obfuscation.

PDFiD will scan a PDF document for

different type of objects as shown in the

below snapshot and count the occurrences

(total and obfuscated) of each word.

Protection Measure Against

Content-Type Attack

Following are the few protection measure

that can be used to protect the environment.

Security update: All the security

updates must be available, which can

prevent from exploitation of all

vulnerabilities except 0-day attack.

0-day attack can be avoided by use

of other protection measures.

Java script in Adobe reader:

Java Script is used for automation of

some task in PDF e.g. calculation,

form filling etc. But attackers use the

same for some malicious activity. So

Java Script should be disabled in

PDF and should be enabled only if

required.

DEP implementation: DEP (Data

Execution Prevention) prevents

execution of code in non-executable

area. Attacker usually tries to

overflow the buffer to execute the

code in non-executable area. So DEP

should be enabled and if required it

should be enabled for trusted

application.

Security Awareness: Security

awareness related to emails &

attachments can prevent content-

type attack. This awareness should

motivate employee to submit

attachment from un-trusted source

for analysis purpose.

White-list based proxy: Internet

proxy can be implemented in two

ways. First black-list based which

prevent access to some of the URL's

like Facebook, Gmail etc. Second

white-list based which grant access

to only allowed URL's. White-list

based proxy implementation can

prevent from post exploitation

activity where attacker wants victim

to connect to malicious websites.

Strong outbound firewall

policy: Strong firewall policy both

for inbound and outbound traffic


also prevents from post exploitation

activity where attacker's post

exploitation code tries to open

reverse channel from victim to

attacker controlled machine as

shown in Content-Type attack

process diagram.

Every organization should implement

maximum of the protection measure to

secure the environment from Content-Type

Attack.

References

http://blog.didierstevens.com/progr

ams/pdf-tools/

http://www.simpopdf.com/resource

/pdf-file-structure.html

http://www.gnupdf.org/Introductio

n_to_PDF

Raman Gupta [email protected]

Raman Gupta works in TCS as

Information Security consultant. His

work area includes vulnerability

assessment, penetration testing and

secure configuration of network. Raman

is also interested in reverse engineering

and exploit writing.

http://www.gnupdf.org/Introduction_to_PDF

http://www.gnupdf.org/Introduction_to_PDF

mailto:[email protected]


GRC – An introduction

Usually when one talks about Information

Security audit, governance, risk

management, compliance and such topics it

is dubbed “management-speak” and wished

away by hacker community members. It

worked the same way for the management

people too who wished away the geeky types

who could bang a keyboard at the speed of

light or “go where no one had been before”.

Times are a changin’ and the twain are set to

meet.

Yes, over the years, the ethical hacker has

realized that he/she has to learned that

report writing is as much a difficult skill as

finding a 0-day and claiming a 100k prize

(ok not as difficult but maybe equivalent to

a 50k prize ). While the hacker community

was learning the difference between an

Executive Summary and a Summary and the

necessity of running a spell and grammar

check before closing a document (oh oh!

don’t forget you need to have a standard

font through and also font size)… ok while

the community was learning these subtle

differences, the management and auditor

types started brushing up on their

knowledge about tools, exploits, ports,

networks, vulnerabilities, remediation and

more.

While CH Mag has been fulfilling the need

for the non-techie to learn and understand

the techie’s hackie thought process, there

has been a gap in terms of providing the

techie with non-techie knowledge and skills.

And, this is now due for change with the

new section on GRC et al starting off with

this issue.

I have the privilege of penning this kickoff

piece and will spend the remaining bytes

walking you into the bright world of audit,

risk and compliance.

Fundamentally, everyone is on the same

team and doing the same work, except that

the methods vary. The ethical hacker goes

blind into a system, runs tools / exploits,

uses his/her knowledge of IT infrastructure

to discover weaknesses and then presents

findings along with the solution for closing

the vulnerabilities. In the same manner, an

auditor too goes blind into the organization

and calls for evidence that will prove that

the organization is complying with the

policies they have formulated – he/she will

use his knowledge and skills to dig into


documents and systems and will do a good

bit of mind reading and body language

analysis to discover weaknesses in the

processes and technologies which will be

reported along with suggestions for closure

of the same.

In effect – the same work (assessment,

testing, analysis…); the same goal

(information, IT, data, security…); work

done at the same place and the same

deliverables submitted (soft copy and hard

copy of the report with remediation).

For the sake of simplicity, we shall call this

the GRC domain while the techie domain

may be referred to as Hackers.

Enough said, and we move on to know more

about this specialization in Information –

certifications are aplenty and some carry a

strong reputation while some are around.

Some of the most well-known certifications

are CISSP, CISA, CISM, ITIL, ISO27001

Implementation, ISO27001 Lead Auditor,

BCP, CIA, CRISC, CGEIT, CFE, C|CISO,

DISA, CIPP, ABCP, CBCP and many others

covering various specializations. These

professional certifications usually require

the person to have a few years of work

experience then qualify by passing an

examination. The areas of specialization and

experience will be in IT Audit, systems

audit, risk management, business

continuity, disaster recovery, governance,

compliance, asset management, data center

audits, IS management, ISMS

implementation, metrics management and

much more.

We usually bundle all these specialist areas

of work under the single label of GRC or IS /

IT Auditor which may seem to be incorrect

but, in a different manner, it is

representative of the knowledge

requirement of the auditor too! He/She, as

an information security professional has to

understand and know about all the areas

mentioned above, plus all those that are not

mentioned. And of course, report writing is

an integral part of the profession itself.

A GRC (Governance, Risk, and Compliance)

professional is an information security

practitioner and may be working as a CISO

(Chief Information Security Officer), an IS

Manager, or Auditor in an organization.

Other roles may be that of Change Manager,

Incident Manager, Risk Manager etc.

The fundamental attributes that drive the

profession are the principles of

Confidentiality, Integrity and Availability of

IT for running the business and as applied

to People, Process and Technology using

‘controls’ or ‘rules’.

As one starts on the GRC practice the first

thing one is usually asked for is a Gap

Analysis or a Risk Assessment. The gap

analysis is just that – an analysis of the area

of investigation and discovery of the gaps so

it is a VA but carried out on processes and

not on systems. A Risk Assessment is a

more critical activity because it is not

something which is done and then on an

annual basis but more dynamic as it has to

be made part of the overall organization

culture - this is critical to the success of any

Information Security program in an

organization. In fact a VA/PT or AppSec is

usually termed as a Technical Risk

Assessment and is usually carried out as a

result of a risk or gap assessment.

While implementing Information Security

in any organization the team carries out a

Risk Assessment and identifies risk areas

along with the path and strategy for

mitigation. Risks are identified in respect of


current practices and processes,

technologies deployed in the infrastructure,

people related policies and practices, assets

etc. The mantra followed by all mature

organizations, and advised by all

Information Security Auditors /

practitioners / consultants is that all

controls and policies should be risk based.

In effect this means that any new control or

asset must be deployed once a proper risk

assessment has been carried out. A

thorough risk assessment will identify

threats, vulnerabilities, challenges, issues

relating to the process in terms of the

environment and working and the

organization management will be able to

take informed decisions for the same.

Risk values can be quantitative or

qualitative – which means that it can be

expressed as a number or stated as ‘high’,

‘medium’, ‘low’ or in one’s own terminology

as it is a gut feel. The most basic formula is

risk = impact * probability – where impact

or probability can be a number on a defined

scale. These inputs are received from the

asset stakeholders by the Risk Assessor

based on specific interactions and informed

questioning.

This is a very basic introduction to risk

assessment and this is a very big area of

specialization. Risk managers carry huge

responsibilities in their organizations and

they depend on much more than this basic

formula. Needless to say this will be an

important topic that will be carried in future

issues and hope you will gain a deeper

understanding which you can apply to your

work too and benefit.

Elements of GRC, like governance, risk

management, gap analysis, change

management and others are based on best

practices and standards like ITIL,

ISO27001, CoBIT etc. and provide

organizations with the necessary direction,

guidance and controls for effective

information security and management.

Dinesh O Bareja

[email protected]

Dinesh is an Information Security

professional specializing in security

strategy, architecture design and

operations. He is an Advisor to Cyber

Defence Research Centre (Special

Branch, Jharkhand). He also leads the

Indian Honeynet Project.



HAWAS – Hybrid Analyzer for Web Application Security

Penetration testing is more than just

running automated tools and redoing the

same manual testing workflow. It is about

analyzing the target, understanding how it is

built and coming up with unique attack

scenarios.

When you are testing a web application of

even moderate size then the amount of

pages, parameters and values travelling

between the browser and the server can

become overwhelming even for seasoned

testers. Finding patterns or mapping

connections in a maze of data is not a trivial

task.

Another problem arises when you have to

do a technically simple check repeatedly for

a large number of times. For example, chec-

king for CSRF vulne-rabilities across the site

is a very simple but time consuming and I

must say

also a very

boring

process.

The same is

true for

privilege

escalation

checks, hidden

parameter guessing etc. When a part of the

test is boring and time consuming then

testers usually tend to skip it or not do

proper justice to it. Needless to say this can

turn out to be very dangerous for the site’s

security.

HAWAS is a tool designed to help testers in

these areas. It will help perform automatic

analysis of the site and provide data in an

easily consumable form so that you can

identify patterns and map connections. It

also helps automate tests for CSRF,

Privilege Escalation, Access Control and

Hidden Parameter Guessing, these tests

would otherwise take up a lot of manual

effort and time.

HAWAS is built as a Module for IronWASP

and is bundled along with it. To use HAWAS

you must first start IronWASP, configure

your browser to use IronWASP as the proxy

and then browse through the target site.

This way IronWASP will collect all the site

information in its proxy logs. Once the

entire site is covered you can launch

HAWAS from the ‘Modules’ menu, it will be

available under the ‘Analysis’ category.

Figure 1 - Launching HAWAS from the Modules menu


Once HAWAS is started up, just click on the

‘Start Analysis’ button, this will start the

analysis of the data collected in the Proxy

Logs. Depending on the size of the log this

analysis could take anywhere from a minute

to a significantly longer time. Once the

analysis is complete click on the ‘Show

Results’ button.

The results section has multiple tabs, let’s

look at them one by one.

Parameter Names and Values

The first tab lists information about all the

parameter names and values discovered in

the logs. This information is categorized by

hostname. The list of hostnames found in

the log are shown on the left-side of this tab.

When you click on a hostname you can see

the list of all parameter names found in the

logs related to that hostname. When you

click on any of the parameter names you can

see the sections in which this parameter was

found, E.g. Query, Cookie etc. When you

click on a particular section you can see the

list of all the values this parameter had

when it occurred in the selected section.

This section is of great important as it lists

all the information about the site in one

single location, in an easily analyzable way.

Let’s look at some scenarios where this can

come in handy.

In the list of parameters if you see a

parameter named ‘is_admin’ then you will

immediately agree that this is worth

exploring. Maybe this parameter is used to

decide if you must be shown the admin page

or not, you could try manipulating this

parameter manually and probe further. If

this parameter appeared only once in the

entire site then without HAWAS it is very

likely that you could have missed this.

Figure 2 - HAWAS has been launched, click ‘Start Analysis’ to begin

Figure 3 - HAWAS is analyzing the Proxy logs

Figure 4 - Analysis is done, click on ‘Show Results’ to view the results


Let’s say there is a parameter named

‘SessionId’ and this parameter contains the

session id for the application. When you

click on this parameter name HAWAS will

tell you which sections this parameter

occurred in. If it only occurs in Cookie then

its fine but if it occurs in Query as well then

you have a problem because passing Session

id over Urls is not safe. Out of a 1000 pages

the application might have sent the session

id over url in just one page but HAWAS still

picks it up and makes this very obvious to

you. Without HAWAS this could have most

likely been lost in the noise.

When you look at the list of all parameter

values you might pick up some interesting

leads. For example if there is a parameter

value that looks like

“http://example.org/info.php” then you

know that this parameter needs to be tested

for Open Redirect and Remote File Include

vulnerabilities. Similarly if you see a

parameter value like “./lib/report.php” then

this is a candidate for Local File Include

testing. Sometimes you might miss noticing

these items when you are crawling through

the site but with HAWAS you would always

notice these interesting patterns.

Figure 5 - Click on Hostname to view Parameters, click on a Parameter to view Sections, click on a Section to view Values, click on a Value to view details about the Value


Encoded Parameter Values

Sometimes web applications transmit values

in encoded form. The encoded value might

look harmless or might look like junk but

when decoded could actually be holding

something sensitive. Hex and Base64 are

the most commonly used encoding schemes

in web applications. When there are

thousands of parameters in an application it

is practically impossible for a tester to

determine which ones look like encoded

values. HAWAS performs this task

automatically. It tries to Hex and Base64

decode every single parameter value, if the

result of decoding is a proper ASCII string

then this is added to this section.

The left-side of this tab contains the list of

all hostnames that contain encoded

parameter values. If you click on any of the

hostnames then the encoded value, the type

of encoding and the decoded values are

displayed. HAWAS makes it almost

impossible to miss these types of encoding

in the application (Fig. 6).

Hashed Parameter Values

Like the use of encoding sometimes

applications might transmit hashed values.

What could be even more interesting is

often these hashed values are created from

some other parameter values within the

same application. For example when a user

logs in with a username and password then

the password might be hashed and this

hashed value might be passed around in

other sections of the application in some

other parameter. Identifying this manually

is a very difficult task but HAWAS

automates this entire process.

Figure 6 - Click on Hostname to view list of Encoded values, click on an Encoded Value to view details


First it identifies all parameter values that

look like MD5, SHA1, SHA256, SHA384 or

SHA512 hashes. Then it uses the list of all

parameter values belonging to that host as a

dictionary list and tries to crack these

hashes. The results are shown to the user in

this section. The left-side of this tab lists all

the hostnames where parameters containing

hashed values were discovered. When you

click on the hostname then the hashed value

and the type of hash are displayed. If

HAWAS was able to crack this hash then the

cracked value is also displayed (Fig. 7).

Stored XSS Candidates:

Stored XSS are difficult to detect because in

a big application it is very hard to find out

which parameter values are stored on the

server-side and reflected back at a later

stage. Manually finding out this pattern is

an uphill task however HAWAS makes this

task easy for you.

HAWAS stores every single request

parameter value found in the log in memory

and then checks if any of the responses have

this same value embedded in them. Let’s say

Response B was found to have a parameter

value that originally found in Request A

then HAWAS checks if Request B also had

the same parameter value. If Request B did

not have this value then it is very likely that

this value was sent by Request A, saved on

the server-side and then reflected back in

Response B. This would make it an ideal

candidate for Stored XSS testing. HAWAS

identifies all such instances and shows them

in this section (Fig. 8)

Figure 7 - Click on Hostname to view list of Hashed values, click on a Hashed Value to view details


Interactive Testing

This section was originally supposed to be

implemented within the HAWAS UI itself

but to provide a better experience this was

instead added as a core component of

IronWASP.

This section provides a single area from

which you can automate the testing for

CSRF, Privilege Escalation, Access Control

and Hidden Parameter Guessing

vulnerabilities.

Though these four vulnerabilities are very

different the testing methodology for them

is more or less similar. For the sake of those

unfamiliar let me briefly explain these

vulnerabilities and how to test for them. For

detailed explanation on these issues please

refer to the OWASP portal.

CSRF:

If an application does not send a CSRF

token or if it does not properly validate a

CSRF token when performing an important

action then it is vulnerable to CSRF.

You test for this issue by picking a request

that already has this token then you resend

this request after deleting this token or

editing it with some junk value. You

compare this response with the response of

the original request. If both are same then it

means the application is not properly

validating the token. If the responses are

different then it indicates that the

application had rejected this request due to

an invalid CSRF token, you can confirm this

by analysis exactly which section of the two

responses are different.

Figure 8 - Click on Hostname to view list of Stored Reflections, click on a Stored Reflection to view details


Privilege Escalation:

If an application allows a low privileged user

to access sections of the site and perform

actions that are only meant for high

privileged users then it is vulnerable to

Privilege Escalation attack.

To test for it you first browser through the

site as a high privileged user and then you

resend the same requests but this time you

set the session id as the session id of the low

privileged user. If the response is similar

then it means the low privileged user is able

to access the same section and the

application is vulnerable. If the responses

are different then probably the application

rejected the request of low privilege user,

you can confirm this by analyzing the

differences between both the responses.

Access Control:

Some sections of the site are only meant to

be accessed after the user is logged in. But if

the application allows even unauthenticated

users to access some of these pages then it

has Access Control issues.


site as an authenticated user and then you

resend the same requests but this time you

either remove the session id or replace it

with an unauthenticated session id. If the

response is similar then it means the

unauthenticated user is able to access the

authenticated section and the application is

vulnerable. If the responses are different

then probably the application rejected the

request of unauthenticated user, you can

confirm this by analyzing the differences

between both the responses.

Hidden Parameter Guessing:

Sometimes applications have hidden

backdoors because of which you might be

able to access hidden functionality by

adding a special parameter and value. For

example if you add a new parameter

‘admin=1’ to the url then you might be able

to access administrative functions of the

site.


site normally and then you resend the same

requests but this time you add a new

parameter name and value, like

‘admin=true’. If the response is similar then

it means the added parameter did not have

any effect on the application. If the

responses are different then probably the

application exposed some new functionality

based on this parameter, you can confirm

this by analyzing the differences between

both the responses.

Automating these Tests:

By now you would have seen the common

pattern in these tests. In all of them we edit,

delete or add a parameter in the request,

send it to the server and compare the new

response with the old response. And based

on the results of this comparison we

determine if there is vulnerability or not.

To automate these steps you must go to the

Logs section of IronWASP. At the top-right

corner of this section you can see a button

named ‘Search and Analyze Logs’, clicking

this button would launch the Log Analyzer.

Here you can set a filter and search the logs.

When the search results are displayed you

can either select all the logs from the results

or select only the logs you are interested in

testing. After selecting, click on the ‘Test

Selected Sessions’ button, this will launch

the Log Tester.


Figure 9 - Click on ‘Search and Analyze Logs’ to launch the Log Analysis utility

Figure 10 - Specify a log filter (File Extensions to ignore and Response Codes to include are selected here) and click on ‘Search with this Filter’

Figure 11 - Select the logs to test from the search results and click on ‘Test Selected Session’. To individually select a log entry first set the ‘Click Action’ value to ‘Select Log’ from the default value of ‘Display Log’


The Log Tester will show a wizard where

you are given three test options:

1) New Parameter Addition Test

2) Edit Existing Parameter Test

3) Delete Existing Parameter Test

The names of the test are self-explanatory,

once you select one these tests and click

‘Next’ you will asked to enter the details of

the parameter. You must mention if it is a

Query, Body, Cookie or Header parameter.

After mention the type of the parameter you

must mention the name of the parameter. If

you selected ‘New Parameter Addition’ or

‘Edit Existing Parameter’ options then you

would be asked to enter the value of the

parameter also.

Figure 12 - Test Options shown, select one and click ‘Next Step ->’


Once this is done you can click ‘Start Test’.

Now IronWASP will send each of the

selected requests once without making any

changes, this is called as Resent Request.

After this the parameter manipulation you

selected will be made, be it adding a new

parameter, editing an existing parameter or

deleting a parameter. The edited request

will be sent to the server, this is called as the

Test Request.

After sending these requests and getting the

responses, the response details are shown to

you. The results UI shows the response

status code and length of the original

response from the log, the status code and

length of the resent response, the status

code and length of the test response.

Apart from these values IronWASP also

does a diff of all the three responses and

shows the percentage of difference between

them. 0% means that the responses are the

same and 100% means the responses are

completely different. By looking at this

information you can immediately determine

if the parameter manipulation had any

effect. If it looks like there was some effect

you can explore it more by clicking on one of

the entries, this will display the original

request/response, resent request/response,

test request/response and the detailed diff

of these requests and responses. From one

single place you can analyze and find out

what where the exact differences between

the responses and based on that determine

if the vulnerability actually exists.

Figure 13 - Enter the details of the Parameter that must be manipulated and click on ‘Start Test’


This feature can help reduce your testing

time for these tests from days to mere

minutes! It can also handle complex

scenarios where while testing for CSRF you

would have to maintain the session. For

example during the test you want to

constantly check if the user is logged in to

the application and perform a login if user is

logged out. To handle this you can make use

of the Session Plugin support built-in. When

you are creating a test you will asked if you

want to make use of this feature, if you

choose to use it then a GUI based assistant

will get the details from you and create a

Session Plugin and then handle

authentication or any other customization.

By making use of these features you can

hugely increase your test coverage while

simultaneously reducing your testing time,

so don’t forget to reap the benefits of

HAWAS in your next pentest.

Lavakumar Kuppan [email protected]

Figure 14 - Test Results are displayed. Click on any of the result item to view more details about it

Lavakumar is the author of IronWASP, the

advanced Web Security Testing Platform.

He has also authored many other security

tools like ‘Shell of the Future’, JS-Recon,

Imposter and the HTLM5 based Distributed

Computing System – Ravan. He has spoken

at multiple conferences like BlackHat,

OWASP AppSec Asia, ClubHack,

Securitybyte, Nullcon, etc.



Case Study - Section 66C Vinod Kaushik and Ors. V. Madhvika Joshi and Ors., Before Sh. Rajesh Aggarwal, Adjudicating Officer, Information Technology Act, 2000, Government of Maharastra, At Mantralaya, Mumbai - 400032, Complaint No.2 of 2010 192

The adjudicating officer held that the act of the wife to access information from the email account of the husband without his permission is unauthorized access under Section 43 of the IT Act, 2000. It also noted that there cannot be any compensation as the wife has not published the information. She has only submitted it to the police and court. The adjudicating officer also held the wife liable under Section 66-C 193 of the IT Act for dishonestly making use of password of any other person.

The main issue in this case is whether accessing husband’s and father in law’s email account without their permission amounts to ‘unauthorized access’.

In this case, the first respondent had accessed the email account of her husband and father in law, in order to acquire evidence in a Dowry harassment case. The Adjudicating Officer held that, accessing e-mail account without authorization amounts to contravention of section 43 of the Information Technology Act, 2000. There was no compensation awarded to the complainant as the respondent has only submitted the information so obtained to the police and the court. The Adjudicating Officer, however ordered the first respondent to pay a fine of Rs. 100, as she was held to be in contravention of Section 66-C (identity theft and dishonest use of password of any other person) of the Information Technology Act, 2000.

Defense of a bonafide intention, in case of violation of privacy by accessing e-mail account without the consent of the user was upheld. The relationship of husband and wife was also taken into consideration The adjudicating officer also relied on the reasoning that the information procured by the ‘unauthorized access’ was only disclosed before the Court and the police, therefore the respondent is not liable to pay any compensation to the complainant.


It can be safely concluded that this judicial interpretation was made due to the peculiar facts of the case that the relationship between the Petitioner and Respondent was that of husband and wife and that the information was used only to be shared with the police as evidence

Vaishali Bhagwat [email protected]

Vaishali Bhagwat is a Computer Science

graduate and now practicing lawyer in

Pune since last 15 years. She has vast

experience in Cyber Cases, both civil and

criminal and is an advisor to several IT

and ITES companies in India



Documents

CHMAG-Feb2013