Post by Daniel » Sat Dec 10, 2016 6:33 pm

Hi Guys,

I get lot of flack for telling security researchers were to go but 99% of the time the issues reported to me are not tested, no issue, minor issues that blown out of proportion or just out right lies!

Most of the time the people that report these type of issues are trying to make a name for themselves in the hacker community or to sell their own services or wares.

Today I read the latest hack job of lies, untested coded and unprofessional-ism in both the people who post the issues and the so called security news blogs that re-post them.

https://www.scmagazine.com/website-hack ... le/577878/

by Bradley Barth, Senior Reporter

Reported from:

https://blog.sucuri.net/2016/12/unrestr ... login.html

By CESAR ANJOS
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 in OpenCart version 1.5.6.4. Since the writing of this post, the login process may have been modified.
Does not matter is 1.5.6.4 the login has not changed.
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.
How did they modify the file? If some one can modify files they dont need to use the hack your about to talk about!
Regardless of any set of credentials we used, the result was the same – a successful login:
yes but how was the file modified? Since opencart code does not allow files to be modified on the server!
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.
$user_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "user
#WHERE user_id = '" . (int)$this->session->data['user_id'] . "'
AND status = '1'");
I have never used #WHERE any where in opencarts code! so unless you are modifying the file your self then its not a vulnerability! you have caused the vulnerability your selves!!!

If i had access to modify the files then the whole server would be compromised and there would be no need to use a hack like this as i would have just added myself as a new 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.
Only if the there was no validation or filtering. OpenCart has both!
A good example of this type of attack involving adding comments on a plain login form is:

Username: fakeuser’ OR 1#

Password: pass
Really!!!

Code: Select all

#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)) . "') 
you see this part of the code:

Code: Select all

$this->db->escape($username)
thats called filtering!

you see this part of the code i the request class:

Code: Select all

		if (is_array($data)) {
			foreach ($data as $key => $value) {
				unset($data[$key]);

				$data[$this->clean($key)] = $this->clean($value);
			}
		} else {
			$data = htmlspecialchars($data, ENT_COMPAT, 'UTF-8');
		}
that is also called filtering! it blocks # being used but even so its still wouldn't work because its being escaped via $db->escape!

If there is a script modifying files and adding #WHERE to the user class than its not the opencart script doing the modification! or the request vars! try looking at what ever other scripts are on the server, vulnerabilities in cpanel or the server you are running.

check the logs is the 1st thing i do to find out when a file has been modified as even if you correct the issue the vulnerability of a compromised server will still be there. Something who reported this seems not to have done.

So lets look at who wrote this:
ABOUT CESAR ANJOS

Cesar is a Security Analyst who spends his free time researching. One of his main concerns is privacy. As such, you won’t find him on social media.
Cesar, I wouldn't call your self a Security Analyst, A professional clown would be a more accurate description.
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.
in fact you seem to be trying to sell your firewall software which would do nothing against a compromised server!


https://www.scmagazine.com/contact-us/section/6366/

Bradley Barth, Senior Reporter

Do you know what the word professionalism means! You should actually check your articles and also email opencart to ask for comment before posting!

OpenCart®
Project Owner & Developer.
OpenCart commercial support now available!


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by Johnathan » Sat Dec 10, 2016 10:51 pm

I think the most important part is this:
In this case though, attackers modified the file in a way that allows any credentials to be considered valid.
Daniel is exactly right: if someone can modify files on your server, there's nothing you can do to stop them. THIS is the source of the issue, and while the explanation in the article shows why it works, it doesn't mean OpenCart is insecure. It just means someone's server security was breached, and now someone has access to modify files.

Image
Image Image Image Image Image Image


User avatar
Global Moderator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by MarketInSG » Sun Dec 11, 2016 2:40 pm

It's a bad way to use OpenCart as an example on that blog post. With ability to modify files on the server, the hacker could just rewrite anything he wants to gain access. Or even just view the database password. So it isn't a problem on OpenCart...what a bad way to use OpenCart as an example.


User avatar
Newbie

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by pipoy » Wed Dec 14, 2016 1:28 pm

Daniel, probably pretend to take the bait next time. If later on they offer you their security software, then I am 101% sure that he's just taking the time pretending he compromised opencart.

If I were the hacker, I would hack demo.opencart.com to prove a point.

Newbie

Posts

Joined
Fri Mar 04, 2016 12:18 pm

Post by Johnathan » Wed Dec 14, 2016 11:50 pm

In which case, Daniel should really update the demo to 2.3.0.2 instead of 2.0.0.1b, since that version is super outdated.

Image
Image Image Image Image Image Image


User avatar
Global Moderator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by Daniel » Tue Dec 20, 2016 5:14 am

demos fine. will update when i have time.

OpenCart®
Project Owner & Developer.
OpenCart commercial support now available!


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm

Post by Johnathan » Tue Dec 20, 2016 11:23 pm

I just noticed there's no Download link in the header menu, so you might want to change that at some point too. Otherwise people might have difficulty finding it (I know it's on the Home page and footer, but in my experience people need as many links as they can get). :)

Image
Image Image Image Image Image Image


User avatar
Global Moderator

Posts

Joined
Fri Dec 18, 2009 3:08 am

Who is online

Users browsing this forum: No registered users and 4 guests