XSS, CSRF & Other Vulnerabilities in CubeCart Web Application
This article explains in details the various vulnerabilities Netsparker’s security researchers identified in CubeCart, an open source ecommerce solution.
Your Information will be kept private.
Your Information will be kept private.
CubeCart is an open-source e-commerce web application that enables shop owners to manage and list their products on their online shop and website. The first version of CubeCart was released in 2003 and since then it has been installed on tens of thousands of online shops.
While doing some research I identified a number of vulnerabilities in CubeCart version 6.1.5, the latest version available as of the writing of this article. In this article, I will explain what these web application vulnerabilities are and how attackers can exploit them to hijack the accounts of both customers and the shopping cart admin to gain administrative access to the online ecommerce solution.
Note: CubeCart fixed all of the below-reported issues in a patch that was released in April 2017. This is an advisory about these vulnerabilities and the advisory number is NS-17-022. Refer to the web application vulnerabilities advisories page for more a complete list of advisories released by Netsparker.
Vulnerabilities in CubeCart Affecting Online Shops’ Customers
By exploiting these vulnerabilities the attacker will be targeting the online shop’s customers, and hijack and possibly change their account details.
Reflected Cross-Site Scripting in the Password Recovery Function
Just like most of the web applications, CubeCart offers a password reset functionality that allows users to change their passwords. To reset a password the customer has to visit the URL http://www.example.com/cubecart/recover.html and supply the email address they used to sign up. Then they receive a password reset link in their mailbox, which has the following structure:
The TOKEN is an 8 byte random string that serves as a password reset token. The value of this token is then reflected into an <input> field without proper encoding, thus making the web application susceptible to a reflected cross-site scripting vulnerability.
This combination of event handlers allows us to achieve the effect of classic cross-site scripting payloads that automatically fire up once the page has loaded, such as <img src=x onerror=alert(1)>. The following is a screenshot that shows the alert box that appears once the page loads:
This page is also accessible to customers who are already logged in, so the attack can work against authenticated customers as well, which allows attackers to hijack their accounts.
Cross-Site Request Forgery in Customer Profiles Page
Customers can edit account information such as their First Name, Last Name, Mobile Number, etc from the profile page. Typically on such pages, a randomly generated token is sent along with the profile changes request, in order to make sure that the request originated from the legitimately logged in user.
But in the case of CubeCart there is no such token, so attackers can launch a cross-site request forgery attack which allows them to trigger a functionality that isn’t protected. The impact of a CSRF attack varies for every scenario, depending on what the functionality is designed to do.
In this case, the CSRF issue allows an attacker to fully hijack a customer account and also deny them access to the account. The attacker can successfully hijack a user’s account by:
- Building a page that sends a request to change the victim’s email address to one that is owned by the attacker.
- Tricking the victim into visiting the page. Once the victim visits the page, the request to change the email address is sent in the background.
Now the attacker can request a password reset for that user, which is sent to the email address of the attacker. Once the attacker changes the password, they hijack the account and the victim is logged out.
The following video is a proof of concept of such attack:
Vulnerabilities Affecting CubeCart Administrators (Online Shop Owners)
This category describes the threats that affect the administrators of the web application rather than the customers. These vulnerabilities have a much higher impact on the application than the ones mentioned above since they allow the attackers to take control of the web application, i.e. the online shop.
Note: CubeCart’s admin pages use the following naming convention: admin_HASH.php.
HASH corresponds to a 6 byte randomly generated hash and the attackers need to know the value of this hash in order to successfully exploit the below vulnerabilities.
Cross-Site Request Forgery in CubeCart’s Administrator Account Deletion Function
CubeCart administrators can delete other administrators, as shown in the above screenshot. The GET request that is used to delete an administrator account is:
HASH corresponds to the hash previously explained and ID is the user id of the administrator that the logged in administrator wishes to delete. This functionality is vulnerable to CSRF attacks since there is no token value sent along with the request to verify that it was triggered by the logged in administrator. Therefore the attacker can delete all administrator accounts by writing a simple JS code that iterates over a range of values to substitute the admin_id value.
The following is a screenshot of an example code that assumes the knowledge of the HASH value and deletes any administrator with a user id value that lies between 1 and 20, inclusive:
CSRF and Directory Traversal in CubeCart’s Directory Deletion Functionality
Administrators can create and delete directories, and upload files through the Download Filemanager section in CubeCart, as shown in the below screenshot:
The GET request to delete directories is:
In the above URL, NAME is the name of the directory. This functionality is vulnerable to CSRF attacks in the same fashion as the previously mentioned functionality, but it is also vulnerable to directory traversal attacks. The delete GET parameter’s value is not well sanitized, allowing an attacker to traverse across the application, deleting any directory they would like to delete.
The attacker can also delete any directory outside of the web root if the PHP script executes with enough privileges, allowing them to delete important directories in the operating system. For example, let’s assume the directory “test” is in the root of the C drive; c:\test, and that a directory that is created from the Filemanager section is placed in c:\xampp\htdocs\cubecart\files. An attacker will be able to delete the directory by luring a logged in admin to visit a page under the attacker’s control, which contains a script that sends the following GET request:
The above request contains four occurrences of ../, which means that the function should go back to the parent folder of the current directory. The four occurrences then instruct the function to navigate to c:\. Finally, the folder name in the request instruct the function to delete that specific folder.
CubeCart v6.1.5 is vulnerable to numerous attacks, four of which were explained in this write-up. The following is a summary of the other vulnerabilities that were identified:
- Limited local file inclusion: Admins can include any file in the “backups” directory,
- CSRF in file deletion,
- Reflected XSS against customers in the addressbook,
- Reflected XSS in the contact us form via POST,
- Reflected XSS against admins in the reports area,
- Stored XSS in the Title, Firstname, Lastname fields of users that executes against admins.
The impact of these attacks varies from allowing a complete takeover of customer accounts to possible deletion of directories which are outside the webroot. Therefore readers are encouraged to upgrade their CubeCart installation to the latest version which addresses the above-mentioned vulnerabilities.