Post by htwp » Thu Dec 08, 2016 1:59 am

Unrestricted Backend Login Method Seen in OpenCart

From the attacker’s perspective, creating ways to maintain access to a compromised website is desirable. This allows them to further distribute malware and perform different kinds of malicious activities.

One of the ways attackers try to secure their access is by adding admin users, or pieces of malicious code throughout the site. This allows them to regain access easily, if needed. However, we recently found a unique way to achieve this kind of breach.

Open Access

OpenCart makes use of the system/library/user.php file to handle the login process. As with other CMS authentication mechanisms, if a user does not exist, credentials are incorrect, or the user doesn’t have permission to access the backend, an error message will clearly state that the attempt has failed.

In this case though, attackers modified the file in a way that allows any credentials to be considered valid.

When we attempted to login with a fake user, for example:

opencart-enter-login-details-testRegardless of any set of credentials we used, the result was the same – a successful login:

opencart-dash

While taking a quick look at the database, we verified that none of those users exist. How could that be?

Auditing the User Logs

An interesting point about the login activity is that the same user was being displayed in the list, regardless of the username we entered.

Completely changing the details had no effect on the login process. The login would still work exactly the same way, with any changes to the user being reflected. For investigation purposes, it was very interesting to confirm that the successful logins were based on the first user in the list and not in a specific username-password combination.

Now we can simply just turn our attention back to the file responsible for the logins – system/library/user.php – to ensure that there was no tampering there.

Commenting Out the Authentication Mechanism

Upon checking the file, we found something that immediately jumped out as incredibly strange on two of the SQL queries:

$user_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "user
#WHERE user_id = '" . (int)$this->session->data['user_id'] . "'
AND status = '1'");
And a few lines later we have:

$user_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "user
#WHERE username = '" . $this->db->escape($username) . "' AND (password =
SHA1(CONCAT(salt, SHA1(CONCAT(salt, SHA1('" .
$this->db->escape($password) . "'))))) OR password = '" .
$this->db->escape(md5($password)) . "') AND status = '1'");
At a very quick glance it may be hard to spot anything bad there, but with MySQL syntax highlighted, it becomes more apparent.

opencart-hack-login-backend

The # symbol is a popular comment delimiter in MySQL syntax. Attackers used it to invalidate most of the authentication mechanisms in place within OpenCart by directly editing this core file.

With this one very small character, all the authentication checks (username/password) would be bypassed because they have been effectively commented out. As a result, the following query remains and is successfully executed. It will return all users in the cms_user table and SELECT the first record found to login:

SELECT * FROM cms_user
Usage of such comment delimiting methods is very common on SQLi attacks where the attackers attempt to bypass the rest of the validation query by placing a # on the login forms. This turns the rest of the query into a comment and hence it is ignored by the server.

A good example of this type of attack involving adding comments on a plain login form is:

Username: fakeuser’ OR 1#

Password: pass

A plain translation of this into a MySQL query would be:

SELECT * FROM users WHERE username = 'fakeuser' OR 1#' AND password = 'pass'
Since the # was passed without sanitization, the actual query being sent to the server is:

SELECT * FROM users WHERE username = 'fakeuser' OR 1
This is treated as a valid query and simply returns all the users in the table and allows the attacker to login.

Sanitization, Validation, and Integrity

It’s very important to take into consideration the data being sent to your server, especially if it involves authentication mechanisms and forms. Input validation is one of the most fundamental steps a developer can take to prevent unexpected behavior in an application. If the data received isn’t valid, or doesn’t match expected criteria, the application should not allow it to pass.

In addition to input validation, you should always perform regular integrity checks on core CMS files to ensure everything remains safe. If you modify core files, you need to make sure that those changes won’t damage the existing security controls.

As a good security practice, we always recommend having a solid website firewall solution to protect the site. It is also important to consider additional access control mechanisms such as 2FA or IP filtering.

Active Member

Posts

Joined
Sun Oct 14, 2012 1:29 am

Post by IP_CAM » Thu Dec 08, 2016 3:19 am

Just in case, but I reported this posting to OC ADMIN as follows:

Code: Select all

This Posting should be considered as a very important information. Strictly technically, an extension creator could USE this knowledge, to implement bad code into a Source File, beeing part of an extension, and so eventually 'open up' an Admin Section to anyone.
just to make sure, it will be read for sure by someone of the OC Staff!
But beeing not a Coder, I cannot judge or comment on the matter itselfs,
still, thanks for this information! ;)
Ernie

My Github OC Site: https://github.com/IP-CAM
5'200 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland

Post by OSWorX » Thu Dec 08, 2016 5:33 am

How poor is that posting (and the answer to it)??!!
The original can be read here: https://blog.sucuri.net/2016/12/unrestr ... login.html
And here the OpenCart thread: viewtopic.php?f=179&t=171252

@htwp: if you copy an article, you should also mention the source!
Also posting in the correct section here is recommended!

Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by htwp » Thu Dec 08, 2016 4:08 pm

Hi OSWorX,

the post was from https://blog.sucuri.net/2016/12/unrestr ... login.html and i just re-post it here in case someone want to read it as many of us don't have time to spend on reading any article in internet. My opinion is this post is very serious, i don't agree with you that is poor. My mistake for not mentioned the source but i didn't find it important.

Anyway you can delete this post as i saw you have opened a new one .

Active Member

Posts

Joined
Sun Oct 14, 2012 1:29 am

Post by OSWorX » Thu Dec 08, 2016 5:12 pm

Whenever an article is posted, and is 'copied' from another website, the source / URL should also be published.
Only fair.

You are right, the information maybe important, while they are using for this hack a very old version (the screenshot shows it was from a 1.5.6.4 version).
I have tried that with several versions and was not lucky to get in.
So, even sucuri may be serious, they should also write which version they have used - and that this hack will NOT work on all 2.x versions.
That would be more useful - before people get in 'panic'.

Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by artcore » Thu Dec 08, 2016 5:37 pm

I fail to see the hack possibility. Obviously adding a # to the user.php changes the statement but my attempts to do so with an injection failed.
Last edited by artcore on Sat Dec 10, 2016 6:55 pm, edited 1 time in total.

Attn: I no longer provide OpenCart extensions, nor future support - this includes forum posts.
Reason: OpenCart version 3+ ;D

Thanks!


User avatar
Active Member

Posts

Joined
Tue Jul 09, 2013 4:13 am
Location - The Netherlands

Post by htwp » Thu Dec 08, 2016 7:02 pm

OSWorX wrote:Whenever an article is posted, and is 'copied' from another website, the source / URL should also be published.
Only fair.

You are right, the information maybe important, while they are using for this hack a very old version (the screenshot shows it was from a 1.5.6.4 version).
I have tried that with several versions and was not lucky to get in.
So, even sucuri may be serious, they should also write which version they have used - and that this hack will NOT work on all 2.x versions.
That would be more useful - before people get in 'panic'.
Ok OSWorX,

from now on i will write the source you have absolutely right. They haven't wrote the version i think because it is an aggressive post to opencart otherwise they would have mentioned. Despite all these we all have to be very careful to whom we give access and choose the developer not by lack or the most cheap. Some times (including me) we give access and we forget to delete the account after the job is done.

Please consider my post not as a "panic post" but more as informative.

Active Member

Posts

Joined
Sun Oct 14, 2012 1:29 am

Post by IP_CAM » Fri Dec 09, 2016 3:09 am

Please consider my post not as a "panic post" but more as informative.
well done, htwp, it's a technical Forum here, after all, and it's better, to always act 'preventive', instead of possibly beeing forced later, to be 'reactive'..! :D

Whereby, the Version used in Tests is not of any importance, there are Masses of working 1.5.6.x Shops all over the place. And all those Users deserve, to be informed, if/when it comes to, whatever it possibly takes, to keep their Shops secure and well! This is, what separates professional Software from the Rest. :-[
Ernie

My Github OC Site: https://github.com/IP-CAM
5'200 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland
Who is online

Users browsing this forum: No registered users and 98 guests