Persistent XSS in CactuShop User Invoices

What this paper is

This paper is a security advisory detailing a Persistent Cross-Site Scripting (XSS) vulnerability found in CactuShop, an e-commerce web application built with ASP. The vulnerability allows a malicious user to inject arbitrary JavaScript code into the system, which can then be executed by other users, particularly administrators, when they view invoices. This can lead to actions like code execution within the administrator's browser session.

Simple technical breakdown

Imagine CactuShop is a digital storefront. When a customer orders something, the system generates an invoice. This invoice contains the customer's billing and shipping addresses. The vulnerability lies in how CactuShop handles these addresses when displaying them on an invoice.

If a malicious customer provides a specially crafted address that contains JavaScript code (like <script>alert(1);</script>), and this code isn't properly "cleaned" or escaped by the application, it gets stored in the database. Later, when an administrator views this customer's invoice, the browser will interpret and execute the stored JavaScript code. Because this code is executed within the administrator's browser session, it can perform actions as if the administrator themselves had run it, potentially leading to compromise.

The paper states that the vulnerability was fixed by introducing a WriteSafe function, which is designed to HTML-encode potentially harmful characters, preventing them from being interpreted as code.

Complete code and payload walkthrough

The provided paper does not contain any executable code or shellcode. Instead, it describes the vulnerability and the fix. The "proof of concept" mentioned is a description of the attack vector rather than actual code.

The core of the vulnerability lies in how the _invoice.asp file processes user-provided data for billing and shipping addresses. The paper highlights the lines of code that were modified to fix the issue:

• Line 88: O_BillingAddress = WriteSafe(replace(O_BillingAddress, vbcrlf & vbcrlf, vbcrlf))
• Line 100: O_ShippingAddress = WriteSafe(replace(O_ShippingAddress, vbcrlf & vbcrlf, vbcrlf))

Let's break down what these lines likely do and what the WriteSafe function implies:

• O_BillingAddress and O_ShippingAddress: These are likely variables holding the billing and shipping address strings retrieved from the database or user input.
• replace(..., vbcrlf & vbcrlf, vbcrlf): This part of the code is intended to clean up the address strings. vbcrlf represents a carriage return and line feed character (a new line). The replace function is looking for occurrences of two consecutive new lines (vbcrlf & vbcrlf) and replacing them with a single new line (vbcrlf). This is a common practice to normalize address formatting.
• WriteSafe(...): This is the critical function introduced to mitigate the XSS vulnerability. Based on the description, WriteSafe is designed to take a string and HTML-encode any characters that could be interpreted as code by a web browser. For example, if the input was "/><script>alert(1);</script>, WriteSafe would likely transform it into something like "/><script>alert(1);</script>. This encoded string, when displayed in HTML, would appear as literal text rather than executing as a script.

Mapping list:

• O_BillingAddress / O_ShippingAddress variables: Represent user-supplied address data.
• replace(..., vbcrlf & vbcrlf, vbcrlf): Address formatting cleanup.
• WriteSafe(...) function: HTML encoding of potentially malicious input to prevent XSS.

Shellcode/Payload:

There is no shellcode or payload provided in this paper. The "payload" in this context is the malicious JavaScript string injected into the address fields.

Practical details for offensive operations teams

This vulnerability is a classic example of a Persistent XSS.

• Required Access Level: Low. An attacker only needs the ability to create or modify user accounts and request invoices. This could be a regular customer account, not necessarily an administrator account.
• Lab Preconditions:
  • A running instance of CactuShop v6.1.
  • An administrator account with privileges to view invoices.
  • A method to interact with the application as a regular user (e.g., creating a customer account).
• Tooling Assumptions:
  • A web browser to interact with the application.
  • Potentially a proxy tool (like Burp Suite or OWASP ZAP) to intercept and modify requests if direct input manipulation is difficult.
  • A text editor to craft the malicious payload.
• Execution Pitfalls:
  • Input Sanitization: The application might have other input sanitization mechanisms that could interfere with the payload.
  • Admin Behavior: The administrator must actually view the invoice containing the malicious data. If they never access that specific invoice, the payload won't execute.
  • Version Specificity: The vulnerability is confirmed for v6.1. Older versions are "probably affected," but this is not guaranteed. Newer versions (like v6.155) are patched.
  • Payload Encoding: The effectiveness of the payload might depend on how the application handles different character encodings.
• Tradecraft Considerations:
  • Reconnaissance: Identify the version of CactuShop being used. Look for the invoice generation and viewing functionalities.
  • Payload Crafting: The simplest payload is "/><script>alert(1);</script>. More complex payloads could be used to steal session cookies, redirect users, or perform other actions.
  • Delivery: The attacker needs to trick an administrator into viewing the compromised invoice. This might involve social engineering or simply waiting for the administrator to perform their routine duties.
  • Persistence: The XSS is persistent because the malicious script is stored in the database. It will execute every time the affected invoice is viewed.

Where this was used and when

• Context: This vulnerability was found in CactuShop, an ASP-based e-commerce shopping cart application.
• Year: The advisory was published in 2010. The vulnerability was likely discovered shortly before this.
• Usage: The paper describes a scenario where a malicious user (customer) crafts a malicious address. When an administrator views the invoice generated for this customer, the malicious JavaScript executes in the administrator's browser.

Defensive lessons for modern teams

• Input Validation and Sanitization: Always validate and sanitize user-supplied input on both the client-side and server-side. For web applications, this means properly encoding or escaping characters that have special meaning in HTML, JavaScript, and SQL.
• Context-Aware Output Encoding: The WriteSafe function in the patch is a good example of context-aware output encoding. It specifically targets characters that could be interpreted as HTML or script. Different contexts (HTML body, HTML attribute, JavaScript string, URL) require different encoding strategies.
• Principle of Least Privilege: Ensure that administrative interfaces are well-protected and that regular users cannot inject malicious content into areas that administrators will access.
• Regular Patching and Updates: Keep all software, including web applications and their underlying frameworks, up-to-date with the latest security patches.
• Web Application Firewalls (WAFs): WAFs can help detect and block common XSS attack patterns, but they are not a substitute for secure coding practices.
• Content Security Policy (CSP): Implementing a strong CSP can significantly mitigate the impact of XSS vulnerabilities by restricting the sources from which scripts can be loaded and executed.

ASCII visual (if applicable)

This vulnerability is primarily about data flow within a web application. An ASCII diagram can illustrate the process:

+-----------------+      +-----------------+      +-----------------+
| Malicious User  |----->| CactuShop App   |----->| Database        |
| (Customer)      |      | (_invoice.asp)  |      | (Invoice Data)  |
+-----------------+      +-----------------+      +-----------------+
    ^                                                     |
    |                                                     | (Malicious script stored)
    |                                                     v
+-----------------+      +-----------------+      +-----------------+
| Admin User      |<-----| CactuShop App   |<-----| Database        |
| (Browser)       |      | (_invoice.asp)  |      | (Invoice Data)  |
+-----------------+      +-----------------+      +-----------------+
                           (Renders Invoice)
                           (Executes Script)

Explanation:

1. The Malicious User provides a crafted address containing JavaScript.
2. The CactuShop App (specifically _invoice.asp) receives this data. Without proper sanitization, it stores the malicious script in the Database.
3. Later, when an Admin User requests to view an invoice, the CactuShop App retrieves the data from the Database.
4. The application renders the invoice in the Admin User's Browser. Because the script was not properly escaped, the browser interprets and executes it.

Source references

• Paper Title: CactuShop - User Invoices Persistent Cross-Site Scripting
• Author: 7Safe
• Published: 2010-04-21
• Exploit-DB Paper ID: 12329
• Exploit-DB URL: https://www.exploit-db.com/papers/12329
• Original Advisory URL: http://www.coresecurity.com/content/cactushop-xss-persistent-vulnerability
• CVE Name: CVE-2010-1486
• Bugtraq ID: 39587

Original Exploit-DB Content (Verbatim)

User Invoices Persistent XSS Vulnerability in CactuShop

1. Advisory Information

Title: User Invoices Persistent XSS Vulnerability in CactuShop
Advisory Id: CORE-2010-0406
Advisory URL: http://www.coresecurity.com/content/cactushop-xss-persistent-vulnerability
Date published: 2010-04-20
Date of last update: 2010-04-20
Vendors contacted: Cactusoft International and Cactusoft Ltd.
Release mode: Coordinated release

2. Vulnerability Information

Class: Cross site scripting [CWE-79]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2010-1486
Bugtraq ID: 39587

3.Vulnerability Description

CactuShop is an ASP shopping cart designed to provide a powerful base for e-commerce web sites hosted on Microsoft Windows web servers. A Cross Site Scripting (XSS) vulnerability has been discovered in CactuShop. This vulnerability occurs in the file that processes the user invoices (_invoice.asp). A malicious user can abuse of this flaw by requesting for an invoice and thus tricking an admin user into issuing him an invoice.

4. Vulnerable packages

    * CactuShop v6.1.
    * Older versions are probably affected too, but they were not checked.

5. Non-vulnerable packages

    * CactuShop v6.155.

6. Vendor Information, Solutions and Workarounds

The change made to the file _invoice.asp was to use the WriteSafe function on lines 88 and 100: 

	87  ...
	88  O_BillingAddress = WriteSafe(replace(O_BillingAddress, vbcrlf & vbcrlf, vbcrlf))

	99  ...  
	100  O_ShippingAddress = WriteSafe(replace(O_ShippingAddress, vbcrlf & vbcrlf, vbcrlf))  

This function HTML encodes any code an attacker might try to insert into the addresses to be run. This patch was applied to CactuShop v6.155.

7. Credits

This vulnerability was discovered and researched by 7Safe.

8. Technical Description / Proof of Concept Code

A Cross Site Scripting vulnerability has been discovered in the file that processes the user invoices: _invoice.asp. This occurs when a user with a malicious billing address ("/><script>alert(1);</script>) requests for an invoice and could thus trick an admin user into issuing him an invoice.
9. Report Timeline

    * 2010-04-06: Core Security Technologies notifies the CactuShop team two vulnerabilities in their software, a XSS vulnerability and a SQL-Injection vulnerability. April 19th, 2010, is proposed as a release date.
    * 2010-04-07: The CactuShop team asks Core for a technical description of the vulnerabilities.
    * 2010-04-07: Technical details sent to CactuShop team by Core.
    * 2010-04-08: The CactuShop team confirms the XSS vulnerability but notifies they do not think the SQL-Injection belongs to CactuShop code; it looks like it may be a customer modification.
    * 2010-04-09: Core agrees the code with the SQL-Injection vulnerability will be probably a customer modification.
    * 2010-04-12: CactuShop team notifies they addresses the XSS problem and will make the patch available for registered users from CactuShop website. The release version of CactuShop will be v6.155.
    * 2010-04-19: Core notifies the advisory will be released tomorrow (2010-04-20).
    * 2010-04-20: The advisory CORE-2010-0406 is published. 

10. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com/.
11. About Core Security Technologies

Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.
12. Disclaimer

The contents of this advisory are copyright (c) 2010 Core Security Technologies and (c) 2010 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.