Blog post

CubeCart 6.1.12 - Admin Authentication Bypass

Robin Peraglie photo

Robin Peraglie

Vulnerability Researcher

CubeCart is an open source e-commerce solution. In one of our latest security analysis we found two flaws in this web application that allow an attacker to circumvent the authentication m...

TL;DR overview

  • Sonar's security research team disclosed an authentication bypass vulnerability in CubeCart, a PHP-based e-commerce platform, allowing attackers to bypass admin authentication under certain conditions.
  • The bypass exploits a logic flaw in how CubeCart validates administrator login credentials, enabling unauthenticated users to gain full admin access to the store backend.
  • With admin access, attackers can exfiltrate customer data, modify store configuration, inject malicious code, or pivot to the underlying server.
  • CubeCart administrators should apply the available security patch immediately and implement additional access controls such as IP allow-listing for the admin interface.

CubeCart is an open source e-commerce solution. In one of our latest security analysis we found two flaws in this web application that allow an attacker to circumvent the authentication mechanism required to login as an administrator (CVE-2018-20716). Once bypassed, an attacker can execute arbitrary code on the web server and steal all sensitive files and data.

I Forgot My Password!

Both vulnerabilities are exploitable through CubeCarts “I forgot my Password!” functionality. It is implemented in the file classes/cubecart.class.php, in the method _recovery(). When a user forgot his password, he can use this feature to enter his email address, a valid password reset token he received via email, and his new password for reset.

classes/cubecart.class.php

2761    private function _recovery() {
2762        if (isset($_POST['email']) 
2763        && isset($_POST['validate']) 
2764        && isset($_POST['password'])) {
2765            $GLOBALS['user']->passwordReset($_POST['email'], 
2766                $_POST['validate'], 
2767                $_POST['password']);
2768        }

At the beginning of this method, these three user controlled parameters are passed to the passwordReset() method of the User class located in classes/user.class.php. The method is responsible for the account retrieval.

classes/user.class.php

679    public function passwordReset($email, $verification, $password) {
680        if (filter_var($email, FILTER_VALIDATE_EMAIL) 
681        && !empty($verification) &&!empty($password['password'])
682        && !empty($password['passconf']) 
683        && ($password['password'] === $password['passconf'])) {
684
685            if (($check = $GLOBALS['db']->select('CubeCart_customer', 
686                array('customer_id', 'email'),
687                array('email'=>$email, 'verify'=>$verification)))!==false) {
688                ⋮
689                // Password reset successful
690                ⋮
691            }
692        }	
693        ⋮
694        return false;    // Password reset failed
695    }

The passwordReset() method starts to check if the email is a valid email address, if all parameters are non-empty, and if the passwords are equal on line 680-683. If one of those checks fails the password reset progress will fail on line 694. Otherwise, the next check is a database query issued by a select() call in the lines 685-687. Here, the user supplied $email and $verification token is used as arguments.

classes/database.class.php

569    public function select($table, $columns = false, $where = false) {
570        $table_where = $table;
571        ⋮
572        $parent_query = "SELECT $sql_cache $calc_rows ".
573            implode(', ', $cols). " FROM $wrapper{$prefix}$table$wrapper ".
574            $this->where($table_where, $where)." $group $orderString $limit;";
575        ⋮
576        $this->_execute($cache);

The select() method constructs a SQL query which is then sent to the database (line 576). To construct the WHERE clause of the SELECT query, the application uses the vulnerable method where() in line 574. In the next two sections we will analyze this where() method and present two individually detected vulnerabilities.

Unauthenticated Blind SQL Injection

The where() method of the database.class.php sanitizes values provided in the second parameter $whereArray perfectly fine with the PHP built-in function mysql_real_escape_string(). However, if the value is an array (line 811), then each value of the array is concatenated unsanitized into the SQL query on line 816.

classes/database.class.php

807    public function where($table, $whereArray = null, $label = false) {
808    ⋮
809        foreach ($whereArray as $key => $value) {
810            ⋮
811            if (is_array($value)) {
812                foreach ($value as $val) {
813                    ⋮
814                    $or[] = "`$key` IN (".implode(',', $value).')';
815                    ⋮
816                }
817                if (isset($or) && is_array($or)) {
818                    $where[] = implode(' OR ', $or);
819                    unset($or);
820                }
821            }
822            ⋮
823        }
824        return 'WHERE '.implode(' AND ', $where);

As an attacker we can now pass an array as our user input. This will allow us to inject SQL syntax into the constructed SQL query and to perform SQL injection attacks to extract sensitive information from the database. A malicious POST request could look like the following:

email=contact@ripstech.com
validate[]=0)+OR+sleep(10
password[password]=secretnewpassword
password[passconf]=secretnewpassword
token=15f84b621a9982d65f82d6f12764ecdb

Note how the validate input parameter now is an array not containing a valid password reset token anymore but our SQL payload. The constructed SQL query can be seen below (the injected part is at the end):

SELECT `customer_id`, `email` FROM `cc6111_CubeCart_customer` WHERE 
cc6111_CubeCart_customer.email = 'contact@ripstech.com' 
AND `verify`  IN (0) OR sleep(10);

Authentication Bypass

Our second vulnerability is only a few lines away from our SQL injection vulnerability showing that we actually do not need to inject SQL syntax to gain access as an administrator. The where() method of the database.class.php file also introduces search modifiers.

classes/cubecart.class.php

807    public function where($table, $whereArray = null, $label = false) {
808        ⋮
809        foreach ($whereArray as $key => $value) {
810            ⋮
811            if (isset($value) && !ctype_alnum($value) || $value=='NULL' || 
812                is_null($value) || $value=='NOT NULL') {
813                    if(preg_match('#^([<>!~\+\-]=?)(.+)#',$value, $match)){
814                        switch ($match[1]) {
815                            case '~':
816                                // Fuzzy searching
817                                $symbol = 'LIKE';
818                                $value = "%{$match[2]}%";
819                                break;
820                            default:
821                                $symbol = $match[1];
822                                $value = trim($match[2]);
823                        }
824                    }
825                }
826                $full_key = ($label ? $label : $this->_prefix.$table).".".$key;
827                ⋮
828                $where[] = "$full_key $symbol ".$this->sqlSafe($value, true);
829	
830        ⋮
831        return 'WHERE '.implode(' AND ', $where);

Basically the where() method checks the input values for special characters (< > ~ ! + -) ultimately effecting which comparison operator will be used in the WHERE clause of the SQL query. For example, a prefixed tilde character (~) in a value will construct a SQL query with a LIKE syntax (line 817-818). A LIKE operation does not require an exact match in the database but allows wildcard characters (%). This can be abused to bypass the check for a valid password reset token. All we have to do is to prefix our password reset token with a ~ character and to put as many wildcard characters into the password reset token as the expected token length is. This will result in the following SELECT query:

select * from CubeCart_customer where email = 'contact@ripstech.com' 
 and verify LIKE '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%'

The WHERE condition that requires a correct verify token will evaluate to true almost all the time with our crafted verification token and is thus bypassed. This allows an adversary to reset the password of an administrator in a matter of seconds and to login as admin. In the administration panel, an attacker can then abuse admin features to execute arbitrary PHP code.

Timeline

Date

What

2017/10/11

Provided vulnerability details and PoC to vendor

2017/10/11

Vendor confirmed security issue

2017/10/16

Vendor released 6.1.12 version

2017/11/23

Vendor informed about additional issues

2017/11/29

Vendor released 6.1.13 fixed version

Summary

We detected two critical issues that allow an attacker to bypass CubeCart’s authentication and to login as an administrator. The security issues base on a custom database abstraction layer that compiles SQL queries in an unsafe manner. Due to the absence of prepared statements and custom SQL concatenation features, an attacker can malform the SQL query that is used for authentication in order to bypass it.

We would like to thank the CubeCart team for their very fast and professional handling of these issues. They responded immediately to our report and released a fixed version rapidly. We recommend to update to CubeCart 6.1.13 immediately.

Related Posts