Trustwave Application Penetration Test Digitaltransactions-080815

Boland Hills 

Application Penetration Test Report 

Digital Transactions 

August 15, 2008 

Copyright © 2008 Trustwave. All Rights Reserved. 

CONFIDENTIAL INFORMATION – FOR INTERNAL USE ONLY 

This document is the property of Boland Hills; it contains information that is proprietary, 

confidential, or otherwise restricted from disclosure. If you are not an authorized recipient, please 

return this document to the above-named owner. Dissemination, distribution, copying or use of this 

document in whole or in part by anyone other than the intended recipient is strictly prohibited 

without prior written permission of Trustwave and Boland Hills.


Trustwave 

Application Penetration Test 

Report Author 

Customer 

Application 

Project 

Document Control 

Jon Rose 

Security Consultant 


Boland Hills 

Digital Transactions 


Draft Version 0.1 08/15/2008 Jon Rose 

QA Review 0.5 08/22/2008 Trustwave QA 

Final Version 1.0 08/24/2008 Jon Rose 

- 2 - 


CONFIDENTIAL INFORMATION – FOR INTERNAL USE ONLY




Table of Contents 

1  EXECUTIVE SUMMARY............................................................................................ 4  

1.1  Scope ................................................................................................................... 4  

1.2  Results ................................................................................................................. 4  

1.3  Recommendations ................................................................................................. 5  

2  NETWORK RECONNAISSANCE................................................................................ 6  

2.1  Port Scanning........................................................................................................ 6  

2.2  Banner Scanning ................................................................................................... 6  

2.3  Remote OS Detection via TCP/IP Stack Fingerprinting .............................................. 6  

2.4  Reconnaissance Results ......................................................................................... 6  

3  APPLICATION PENETRATION TESTING METHODOLOGY ....................................... 8  

3.1  Information Gathering ..........................................................................................10  

3.2  Application Investigation .......................................................................................10  

3.2.1  Site Overview ............................................................................................10  

3.2.2  Data Handling and Request Processing........................................................10  

3.3  Issue Identification And System Exploitation...........................................................12  

3.4  Compromise.........................................................................................................12  

3.5  Data Extraction ....................................................................................................12  

3.6  Further Compromise .............................................................................................12  

4  RISK LEVELS......................................................................................................... 13  

5  DISCOVERED VULNERABILITIES ......................................................................... 15  

6  CONCLUSION........................................................................................................ 26  

List of Tables 

Table 1 – Information Provided ............................................................................................ 4  

Table 2 – Recommendation Summary................................................................................... 5  

Table 3 - Supporting Application Infrastructure ..................................................................... 7  

Table 4 - Application Attack Classes.................................................................................... 11  

Table 5 - Risk Rankings ..................................................................................................... 14  

- 3 - 





1 Executive Summary 


Boland Hills (Boland Hills) engaged the SpiderLabs division of Trustwave (Trustwave) to 

perform an application penetration test of the Digital Transactions application. The primary 

objective of this security test was to gauge the resiliency of the Digital Transactions application 

to various attacks launched against both authenticated and unauthenticated surfaces. 

1.1 Scope 

Before the penetration exercise began, Boland Hills provided the Trustwave team with the 

following information: 

IP Addresses and Domain Names: digitaltransactions.net: 69.67.208.190 

Exempt Architecture or 

Application Components: 

Test IDs Used: 

No architecture or application components were exempt from testing. 

No user accounts were supplied for testing. 

Table 1 – Information Provided 

1.2 Results 

After careful review of the systems and access levels included in this test, Trustwave feels that 

Boland Hills needs to take additional measures in order to protect itself from compromise. 

Vulnerabilities were found related to improper input sanitization that may enable a more 

complex attack, for example, Cross-Site Scripting and SQL Injection. The most severe of these 

vulnerabilities, SQL Injection, was immediately fixed by the Digital Transactions team and 

verified closed by Trustwave during testing. By implementing best practices and the 

recommendations in this report, Boland Hills can strengthen the security of Digital Transactions 

and prevent additional vulnerabilities that were identified. 

Vulnerability (Risk) 

SQL Injection (High) 

Email Denial of Service (Medium) 

Missing Security Patches (Medium) 

Multiple Cross-Site Scripting 

Recommendation Summary 

Sanitize user-supplied input against a white-list of good characters 

and redesign the application to use cfstoredproc or cfqueryparam 

elements when querying databases. 

Consider building an administrative orders page that allows a Digital 

Transactions employee to review submitted orders online instead of 

having automatic emails created. 

Review and install all recent ColdFusion security patches. Register 

with the Adobe Security Notification system to be informed of the 

latest updates for ColdFusion. 

Implement best practices for user-input sanitization across all 

- 4 - 






Vulnerabilities (Medium) 

FTP Enabled (Low) 

Missing Custom Error Page (Low) 

application source code. 

Replace FTP with a more secure file transfer mechanism such as SCP 

or SFTP. 

Configure error handling pages through the ColdFusion Administrator 

Server Settings page. 

Table 2 – Recommendation Summary 

Boland Hills’s efforts, as evidenced by this test, show a strong basis for a comprehensive 

information security program; Boland Hills should continue a multi-year program of periodic 

assessments and reviews addressing both technical and policy issues as part of an ongoing 

information security program. 

1.3 Recommendations 

Trustwave has documented recommendations for the remediation of specific vulnerabilities in 

the appropriate sections of this report. However, based on our cumulative years of experience, 

industry best practices, and observations documented during testing, we suggest the following 

actions that Boland Hills could take to further improve their overall security posture: 

• Perform an analysis of the issues documented in this report and devise and implement 

remediation strategies for identified issues. 

• Execute an internal strategy for periodic development security best practices training for 

all developers. 

• Continue to perform periodic security assessments of the application source code, server 

security posture, and network architecture to ensure compliance with the corporate 

security policies and procedures. 

Trustwave is available to help you with any of these issues. 

- 5 - 





2 Network Reconnaissance 


This phase of the testing focuses on gathering as much information about the target application 

infrastructure as possible. This report section details how we obtain information from 

interrogation probes directed at the target, and presents the combined results of research. Port 

scans attempt to determine what services the target is offering. TCP/IP fingerprinting is used to 

determine operating system type and version. Banner scanning is used to discover software 

types and version. 

2.1 Port Scanning 

Port scanning is a highly effective technique used to determine what services a target system is 

offering. There is a wide range of methods ranging from obvious to nearly invisible. Trustwave 

employs SYN scanning, a method of scanning where TCP packets with the SYN flag set are sent 

requesting a connection. If a TCP packet with the SYN and ACK flags set is received from the 

target, indicating that the connection was accepted, a packet with the RST flag is sent to tear 

down the connection. 

2.2 Banner Scanning 

Banner scanning is a technique for determining the type and version of a particular network 

service. The testing team connects to an open port and parses any information that is returned. 

This information is then used to search for exploits for that specific service and version. 

2.3 Remote OS Detection via TCP/IP Stack Fingerprinting 

Trustwave utilizes OS fingerprinting in an attempt to discover the exact type and version of the 

operating system to provide additional insight into potential vulnerabilities. It should be noted 

that OS fingerprinting is most effective when at least one port on the target host is open, and at 

least one port is verifiably closed. If some piece of network hardware blocks all non-open ports, 

it significantly reduces the accuracy of the remote OS guess. 

2.4 Reconnaissance Results 

The test team conducted reconnaissance against the services discovered, and/or listed in Table 

1. The following table represents the core application infrastructure components: 

- 6 - 






IP Address 

Domain Names 

Operating 

System 

Applications 

Open 

Ports 

Notes 

69.67.208.190 digitaltransactions.net 

Microsoft 

Windows Server 

2003 SP1 

Digitaltransactions 

21/TCP, 

80/TCP, 

443/TCP 

IIS v6.0 

Table 3 - Supporting Application Infrastructure 

- 7 - 





3 Application Penetration Testing Methodology 


Trustwave's primary goal in conducting the penetration test was to circumvent application 

security controls and gain access to the systems and protected data an unauthenticated or 

unauthorized user should not be able to obtain. The attack simulation was structured to enable 

Boland Hills to accurately understand their current controls and how they could be 

circumvented during an actual attack. No attempts were made to disguise the simulated attack; 

it should be noted that actual attacks might not be as obvious to system and application 

administrators. 

The manner in which the testing was performed encompassed several distinct phases. The 

following phases applied to both the public and the protected sections of the Digital 

Transactions application. 

To visually depict our methodology for penetration testing, we have provided a process flow 

diagram. This diagram is shown on the next page, followed by a narrative of each step. 

- 8 - 






- 9 - 





3.1 Information Gathering 


Before performing active testing, Trustwave gathered information about the manner in which 

the various elements of the application operate. Manual investigation and automated tools were 

used to traverse the entire application in order to document all distinct inputs and processes. 

Trustwave used automated tools to make a local copy of the Digital Transactions webpages and 

investigated them in detail. 

Working with local copies of the HTML, the Trustwave team mapped the application’s attack 

surface by determining how various application elements are called as well as the parameters 

and data types passed to the application elements. All HTTP queries that accepted clientsupplied 

data were deemed a distinct element of the application. The application was then 

investigated online to better understand how elements worked together and to discover any 

elements that may have been missed during the HTML review. 

3.2 Application Investigation 

After gaining a basic understanding of the application environment, Trustwave manually probed 

the various application elements identified, as described within the Information Gathering 

section of this methodology. Test data for each parameter was supplied and traced throughout 

the application. Data flows and application-interdependencies were discovered. Client-side 

scripting was traced manually. 

3.2.1 Site Overview 

The Digital Transactions application is a ColdFusion application that does not require 

authentication. The site consists of online articles for “Digital Transactions” magazine related 

information technology and it’s effect on business and consumers. The site also provides 

research documents on consumer electronic transactions in PDF format as a product. The 

application itself is Internet-accessible. 

3.2.2 Data Handling and Request Processing 

The Trustwave team reviewed the application for generic vulnerabilities which occur in a wide 

variety of applications. These issues are generally due to incorrect or unsafe handling of clientsupplied 

data. To that end, attempts were made to disrupt the process-flow and induce the 

application to behave in unexpected, anomalous, or dangerous ways by supplying specific and 

hazardous data. This includes data containing characters that could either redirect program flow 

or force errors. 

The majority of web-based application vulnerabilities fall into the general category of “improper 

meta-character handling”. This category includes such issues as SQL Injection, Shell-Escape 

Command Execution and Cross-Site Scripting (XSS). The essential issue underlying all metacharacter 

vulnerabilities is a failure on the applications part to correctly filter and interpret 

- 10 - 






unexpected characters. These characters are sometimes referred to as “special” characters. 

Different shells, applications, command processors and languages respond in different but 

predictable ways to specific combinations of characters. If an application does not properly 

sanitize client input, a malicious user may, among other actions, be able to access or modify 

protected or privileged data, execute arbitrary code on a server, or induce a legitimate user to 

execute code on the attacker’s behalf. 

In testing for meta-character sanitization, Trustwave supplied data with specific characters and 

interpreted server responses. Meta-characters that have meaning to a wide variety of 

applications were tested; some of these characters are likely benign in the Boland Hills 

application infrastructure. Since application infrastructure changes cannot be accurately 

predicted, Trustwave feels that the best approach is to protect against all meta-characters, not 

just those known to the current environment. 

An analysis of each category can be found below. 

Session Management 

(Analysis of session state, cookies, 

session theft) 

Input Validation 

(This attack tree is predicated on 

poor application input validation) 

Parameter Tampering 

(These attacks deal primarily with 

data theft, and escalation of 

privileges - there is overlap with 

Input Validation attacks) 

Programmatic Errors 

(These attacks are launched against 

the application engine and 

application server themselves. They 

deal with “universal” weaknesses in 

the architecture that manifest 

themselves in the application flow.) 

Cookie Predictability, Cookie Manipulation, Cookie Analysis, 

Session Theft, Session Fixation, Session Trapping, Ability to Sniff 

Application Traffic, Potential for Man in the Middle, Potential for 

phishing, Eavesdropping, Cross-Site Request Forgery, and others. 

Cross-Site Scripting (XSS), Alternate XSS Syntax, Blind SQL 

Injection, Blind XPath Injection, Command Injection, Handling of 

Meta-Characters, HTTP Response Splitting, Application Interpreter 

Injection, SQL Injection, Server-Side Includes (SSI) Injection, 

Encoding Types Supported, and others. 

Type Conversion Errors, Argument Injection or Modification, 

Code/Command Injection, Application Common Elements, Direct 

Dynamic Code Evaluation, HTTP Request Smuggling, HTTP 

Response Splitting, XML Injection, and others. 

Directory/Path Traversal, Attacks Against Application Error Pages, 

Buffer Overflows, Format String, Forceful Browsing, Integer 

Overflows/Underflows, Log Forging, and others. 

Table 4 - Application Attack Classes 

- 11 - 





3.3 Issue Identification And System Exploitation 


Identified vulnerabilities were combined with knowledge of attack logic to leverage system 

exploits. The testing team then used information gathered in the reconnaissance phase to 

identify possible vulnerabilities and devise an attack strategy. Specific attacks were crafted for 

the application or network to exploit a vulnerability. The test team kept careful notes of controls 

in place that would inhibit the successful exploitation of an application or system. To minimize 

any potential negative impact, exploitation was only attempted when it would not adversely 

effect production applications and systems, and then only to confirm the presence of a specific 

vulnerability. Any exploitation with the potential to cause unwanted system downtime or 

seriously impact business continuity was carefully coordinated with Boland Hills. 

3.4 Compromise 

If application elements were compromised, the client’s key security contacts were notified 

immediately. The client contacts were given the opportunity to decide if the particular 

application should undergo additional tests. If they decided to have Trustwave continue, 

additional techniques were used to further penetrate the target application and supporting 

environment. The client’s key security personnel immediately notified once successful 

exploitation allowed Trustwave to compromise client data. 

3.5 Data Extraction 

If confidential application data or files were compromised a sample was downloaded and 

securely stored by Trustwave until the presentation of the deliverable. When practical, sensitive 

data has been masked in this report as an additional measure to protect client confidentiality. 

3.6 Further Compromise 

Once a portion of an application has been compromised, there are many trust relationships that 

may be exploited. Additionally, data exposed through a compromise may lead to the 

compromise of additional portions of an application. Trustwave used this information to launch 

a new stage of discovery against the application. 

- 12 - 





4 Risk Levels 


The following levels categorize the risk of issues presented in this report. 

Risk Level 

Critical 

High 

Medium 

Low 

Definition 

The attack scenario tested in this exercise succeeded, and resulted in a systems 

compromise 

Exploitation impacts production systems without requiring valid authentication 

Exploitation is trivial 

Successful exploitation results in a large-scale loss of customer or cardholder information — 

no controls to prevent the exploit are present or controls to prevent the vulnerability from 

being exploited are ineffective 

A strong need for immediate corrective measures exists 

The attack scenario tested in this exercise succeeded, and resulted in a systems 

compromise 

Technical vulnerability details and/or exploit code are publicly available 

An additional attack vector may be needed to craft a successful attack using this exploit, but 

that vector is trivial 

No controls to prevent the exploit are present or controls to prevent the vulnerability from 

being exploited are ineffective 

Exploitation of the vulnerability (1) may result in the highly costly loss of major tangible 

assets or resources or (2) may significantly violate, harm, or impede the organization’s 

mission, reputation, or interest. 

A strong need for corrective measures exists 

Exploitation requires a skilled attacker 

Exploitation does not result in elevated privileges 

Controls are in place that may impede successful exploitation of the vulnerability 

To craft a successful attack using this exploit/vulnerability an additional vector is needed 

(such as phishing or social engineering) this additional attack vector might be something 

challenging 

Exploitation of the vulnerability (1) may result in the costly loss of tangible assets or 

resources or (2) may violate, harm, or impede the organization’s mission, reputation, or 

interest 

Corrective actions are needed and a plan must be developed to incorporate these actions 

within a reasonable period of time 

Exploitation is extremely difficult 

Controls are in place to prevent, or at least significantly impede, the vulnerability from being 

exploited 

The attack scenario under which this vulnerability can be exploited is possible, but 

extremely unlikely 

- 13 - 






Exploitation of the vulnerability (1) may result in the loss of some tangible assets or 

resources or (2) may noticeably affect the organization’s mission, reputation, or interest 

The system’s accrediting authority must determine whether corrective actions are required 

or decide to accept the risk 

Informational 

Information disclosed may be of interest to an attacker 

The Information disclosed will be useful to an attacker should a higher risk issue be found 

that allows for a system exploit 

Information is disclosed that is necessary to carry out an attack 

Table 5 - Risk Rankings 

- 14 - 






5 Discovered Vulnerabilities 

This section provides details regarding vulnerabilities that were identified during testing. 

Vulnerability 

Risk 

Impact 

Vulnerable System 

SQL Injection 

High 

SQL Injections allows for attacker to bypass all business logic and gain direct access to 

application data. These types of attacks often allow for the unauthorized disclosure of 

customer information, privilege escalation, and the corruption of system data. 

http://www.digitaltransactions.net/newsstory.cfm 

Comments 

• SQL Injection is a vulnerability that allows an attacker to insert arbitrary commands into a SQL query or 

statement. It is possible when user-supplied input is not properly sanitized before being used in a command sent 

to the database server. Most commonly, SQL Injection can allow an attacker to extract data stored in the 

targeted database. Under the right circumstances, it can be used to modify data, execute operating system 

commands, read and write local files, and even tunnel internal network traffic to the Internet. 

• The “newsid” parameter on http://www.digitaltransactions.net/newsstory.cfm is vulnerable to SQL Injection. 

When a single quote (') was appended to the query parameter, the resulting error message indicated that SQL 

Injection was likely. 

• By crafting a specially formatted request, Trustwave was able to retrieve the database schema, including table 

and column names. An example URL is below (exploit highlighted in yellow): 

http://www.digitaltransactions.net/newsstory.cfm? 

newsid=182111+union+select+null,TABLE_NAME,column_name,null,null,null%20 

from%20information_schema.columns-- 

• Multiple commands could be submitted by separating them with a semicolon (;). This could allow for 

manipulation of database content, although such an attack was not attempted. Extended procedures that can 

execute operating system commands (xp_cmdshell and sp_oacreate) were not enabled. 

NOTE: This issue was communicated to the client and fixed immediately. Further testing has shown this issue is 

now closed. 

Example 

The screenshot below shows the SQL injection on the digitaltransactions site which displays the tables and column 

names from the backend database. 

- 15 - 






Recommendation 

• Sanitizing user-supplied input against a white-list of good characters is a recommended best-practice, regardless 

of how the input is used. The white-list should always be made as restrictive as possible. For example, with a zip 

code parameter, user input should only be accepted if it is comprised entirely of numbers. Validation should be 

performed on the application server, since client-side validation is trivial to bypass. 

• For ColdFusion applications, all database access should be performed using cfstoredproc or cfqueryparam 

elements. These elements will allow the application to securely pass data into prepared SQL statements or 

stored procedure parameters, and provide automatic escaping of characters such as single quotes. These 

elements can also be used to enforce strong data typing and input length requirements. This provides a robust 

defense against SQL Injection attacks since all query input data, regardless of its source, will be properly 

escaped and/or validated. 

• When building a SQL statement, it is critical to avoid concatenating user-supplied input into a predefined query. 

Doing so will negate the benefits of using prepared statements. 

- 16 - 






Related 

Information 

http://www.us-cert.gov/cas/tips/ST04-015.html 

Vulnerability 

Risk 

Impact 


Email Denial of Service 

Medium 

An attacker or competitor could cause a major disruption of online business by flooding 

digitaltransactions employee’s email with junk order request and cause legitimate 

business to be lost. 

http://digitaltransactions.net/datastore/order.htm 

Comments 

• The order page on the digitaltransactions web site is designed to take customer information for purchasing 

reports. This page allows a customer to request specific reports, quote a price, and then submit the order for 

review. The completed form is then automatically emailed to a digitaltransactions employee for review and 

additional processing, such as collecting billing information. 

• Since the system is designed to automatically send emails when a request is submitted, a malicious user could 

repeatedly make requests to the order page resulting in an extremely large number of emails. 

• An attacker could automate this process which would quickly fill the recipient’s email mailbox and cause a denial 

of service. The Trustwave team believes a sustained attack against this page would continuously fill the email 

box of the digitaltransactions employee responsible for processing orders and cause major business operational 

issues. 

Example 

The following screenshot shows the order page of the application: 

- 17 - 






Clicking on submit 

sends an email to 

digitaltransactions.net 

By simply pressing the submit button, even without filling out any input fields, an email is automatically generated. 

Depending on the bandwidth and load of the server, thousands of emails a second could be generated. 


• Consider building an administrative orders page that allows a digitaltransaction employee to review submitted 

orders online instead of having automatic emails created. When a user submits an order, the information could 

be stored in a backend database and later reviewed through a web interface when convenient for a 

digitaltransaction employee. 

• The orders page could contain a list of all reports and allow a customer to select the appropriate report, rather 

than the error prone process of manually typing in the report name. 

• Unless price is negotiable, price should be stored in a backend database and associated with a specific report 

instead of allowing a user to manually enter in the price. 

• Consider redesigning the orders component of the site to utilize shopping cart functionality instead of a manual 

transaction process. 

- 18 - 






Related 

Information 

http://www.us-cert.gov/cas/tips/ST04-015.html 

Vulnerability 

Risk 

Impact 


Missing Security Patches 

Medium 

Known vulnerabilities are present in the server that may be actively exploited by 

attackers. 

http://digitaltransactions.net 

Comments 

• The Cross-Site Scripting vulnerability in the default error page indicates that ColdFusion security patches have 

not been applied to the server. The patch for the Cross-Site Scripting vulnerability was issued February 13, 

2007. 

• Missing critical security patches indicates a lack of patch management and monitoring as part of ongoing system 

maintenance. 


• Review and install all recent ColdFusion security patches. 

• Register with the Adobe Security Notification system to be informed of the latest updates for ColdFusion. 

Related 

Information 

http://www.adobe.com/support/security/#coldfusion 

http://www.adobe.com/support/security/bulletins/apsb07-04.html 

http://www.adobe.com/cfusion/entitlement/index.cfm?e=szalert 

Vulnerability 

Risk 

Impact 


Multiple Cross-Site Scripting Vulnerabilities 

Medium 

Possibility of credential theft, session hijacking, phishing attack, or the control of an end 

user’s browser environment using an additional attack vector such as phishing or social 

engineering. 


Comments 

• The application is vulnerable to Cross-Site Scripting attacks. This occurs when web applications do not properly 

validate user-supplied inputs before re-using them in dynamic web pages. 

- 19 - 






• By modifying input parameters, Trustwave was able to inject code, including malicious JavaScript in the 

application. 

• Exploiting this issue allows an attacker to supply arbitrary client-side code (JavaScript, VBScript, etc.) within 

application input parameters that will ultimately be rendered and executed within the end user’s web browser. 

• This type of attack may be used to steal information such as usernames and passwords, sensitive information, 

remotely control or monitor the users browser, or impersonate a web page used to gather order information, 

including credit card numbers. 

• For example, an attacker could use this vulnerability by sending a customer or employee a URL with malicious 

code, which may be more likely to be executed or run at a different security level because it is from a “trusted” 

site. 

Detailed Examples 

One example of Cross-Site Scripting was found in the clickthru page of the site (attack string highlighted and bold): 

http://www.digitaltransactions.net/clickthru.cfm? 

adid=%3Cscript%3Ealert(%27xss%27)%3C/script%3E 

By injecting this previous JavaScript into the “adid” parameter, the script gets executed in the users browser running 

in the context of digitaltransactions.net, causing a simple proof of concept alertbox to be displayed: 

The URLs listed below were found to be vulnerable to Cross-Site Scripting attacks: 

GET http://digitaltransactions.net/newsstory.cfm?newsid= 

"/>alert(document.cookie) 

GET http://digitaltransactions.net/clickthru.cfm?adid=" 

/>alert(document.cookie) 

GET http://digitaltransactions.net/newsstory.cfm?newsID= 

"/>alert(document.cookie) 

- 20 - 






POST http://digitaltransactions.net/searchcollaction.cfm 

(collection="/>alert(document.cookie) 

&searchstring=trustwave&search1=Search) 

POST http://digitaltransactions.net/searchcollaction.cfm (collection=digitrans&searchstring="/> 

&search1=Search) 

POST http://digitaltransactions.net/searchdbaction.cfm 

(searchstring=">alert(document.cookie)) 

NOTE: In most cases, these Cross-Site Scripting payloads appear to be executed on the default error handler, 

although it’s difficult to determine without having access to the source code. 


• Before using any user-supplied data, validate its format and reject any characters that are not explicitly allowed 

(i.e. a white-list). This list should be as restrictive as possible. 

• While not able to stop all attacks, a significant number of issues can be prevented by configuring turning on the 

“Enable Global Script Protection” setting in the ColdFusion MX Administrator or setting the following tag in the 

Application.cfm: 

 

• Mark cookies as “Secure” and “HTTP-Only” where appropriate to minimize the impact of Cross-Site Scripting 

attacks. 

• Before using any data (stored or user-supplied) to generate web page content, escape all non alpha-numeric 

characters (i.e. output-validation). This is particularly important when the original source of data is beyond the 

control of the application. Even if the source of the data isn’t performing input-validation, output-validation will 

still prevent XSS. As demonstrated in the following table, this can be done by converting characters to “&#nn;” 

(ignore the quotes), where “nn” is the hexadecimal ASCII character number. 

Character Encoding Character Encoding 

< < or < ) ) 

> > or > # # 

& & or & % % 

" " or " ; ; 

' ' + + 

- 21 - 






( ( - - 

Related 

Information 

http://www.owasp.org/index.php/Cross-site_scripting 

http://www.cftagstore.com/tags/trimvars.cfm 

http://ha.ckers.org/blog/category/webappsec/xss/ 

http://www.technicalinfo.net/papers/CSS.html 

http://xss-proxy.sourceforge.net/Advanced_XSS_Control.txt 

Vulnerability 

Risk 

Impact 


FTP Enabled 

Low 

An attacker may be able to intercept unencrypted traffic to the FTP server and steal user 

credentials, gain unauthorized access to the system, and potentially access 

digitaltransaction products such as PDF reports. 

ftp.digitaltransactions.net 

Comments 

• FTP transmits usernames and passwords, as well as data, in clear text and can be intercepted by anyone 

between the server and users. 

Example 

The following screenshot shows the FTP server listening on digitaltransactions.net port 21. The FTP banner identifies 

the server as Microsoft FTP: 


• Replace FTP with a more secure file transfer mechanism such as SCP or SFTP, or an https protected file upload 

page that requires authentication on the web application. 

- 22 - 






Related 

Information 

http://en.wikipedia.org/wiki/FTP_server#Security_problems 

Vulnerability 

Risk 

Impact 


Missing Custom Error Page 

Low 

Errors often reveal the internal workings of an application, disclose sensitive information, 

and can be used to aid additional attacks against a site. 


Comments 

• Exceptions and errors were encountered when attempting to insert non-integer characters into a SQL integer 

type field or when incorrect parameters were supplied to verity searches. 

• Error messages that contain useful information can aid an unauthorized user in performing more elaborate 

attacks. For example, a information may reveal internal application logic such as SQL queries or display 

software version information that can be used as targeting information in subsequent exploitation. 

• Application errors are also an indication that proper server hardening guidelines have not been followed and may 

lead to the presence of additional security problems. 

Example 

The following screenshot shows a ColdFusion error message being displayed to users. 

- 23 - 






The following URLs produced similar ColdFusion exceptions (malicious input highlighted): 

GET http://digitaltransactions.net/index.cfm?pageid=%27 

POST /searchcollaction.cfm 

(collection=digitrans&searchstring=%27&search1=Search) 

POST /searchcollaction.cfm 

(collection='&searchstring=trustwave&search1=Search) 

GET /clickthru.cfm?adid=' 

GET http://www.digitaltransactions.net/newsstory.cfm?newsID=%27 

POST http://www.digitaltransactions.net/searchdbaction.cfm 

(searchstring=%3E) 


• At the template level, ensure all code that may cause an error or exception condition is properly wrapped in a 

cftry and cfcatch blocks. 

• At the application level, define custom templates for error conditions with the tag in the 

Application.cfm file. 

• Site-Wide error handling pages and Missing Template Handlers can be configured through the ColdFusion 

Administrator Server Settings page. In addition, the cferror tag can be used to specify ColdFusion pages to 

handle specific types of errors. 

• Consider logging error messages using the cflog tag. 

Related 

Information 

http://livedocs.adobe.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/ 

common/html/wwhelp.htm?context=ColdFusion_Documentation& 

file=00001138.htm 

- 24 - 






- 25 - 





6 Conclusion 


Based on the results of this penetration test, Trustwave feels that Boland Hills is should take 

additional measures to mitigate risk of compromise of the tested application. There are some 

best-practices issues that were not being fully addressed, such as input validation (in the case 

of Cross-Site Scripting and SQL Injection), denial of service (email order system) and 

maintaining current security patches. These issues could lead to a compromise or the disruption 

of operations by a determined attacker. Boland Hills responded immediately to the most serious 

vulnerability of the issues documented in this report, SQL Injection, and after appropriate 

analysis and discussion with the Trustwave team has closed the issue. 

New vulnerabilities are discovered on a daily basis; keeping that in mind, Boland Hills should 

continue their current program of regular vulnerability scanning and security testing. 

- 26 -

Trustwave Application Penetration Test Digitaltransactions-080815

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?