Post by Qphoria » Fri Jul 12, 2013 9:26 pm

I'm sorry but what is it that you think this does? Some lunatic cries the sky is falling and you up and believe it?

Looking at the url alone tells me this is a faulty claim
There is no "admin.php" file in opencart
There are no request receptors for "dpt" or "sub" in the code so they will be ignored.
This doesn't even seem to be opencart.

Perhaps you have other files on your site that are failing?

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Sat Jul 13, 2013 1:32 am

MinorXThreat wrote:Ok, no thanks to the OpenCart community this seems to be fixed now...
Seriously, why the attitude? You're asking for someone with a high level of experience in programming, the OpenCart code base, security, and PCI compliance and vendor quirks to solve a problem gratis or on spec and for all this to happen in just a couple hours time. That's a skill set that can command hundreds of dollars an hour. The fact that there are talented developers out there who are willing to help OpenCart users for free is a real testament to the community. It's not an entitlement, though.

For the benefit of anyone else who has this issue, it's a false positive. This is not a user specified URL redirection. It's an internal redirection to the 404/not found page. A redirection like McAfee thinks would be in the form of https://mywebsite.net/store/admin.php?d ... google.com redirecting the user to Google. The change you made will just remove the 404 page redirect which can cause issues for indexers.

As for the CSRF vulnerability, that's a separate issue that PCI vendors won't be able to scan for in an automated way. It absolutely should be fixed along with a couple other issues but it doesn't pose an imminent danger as OpenCart doesn't store payment information (it's also somewhat unlikely to pull off). The worst case scenario on a standard OpenCart install is a hacker changing the account details and accessing the user's order history. There's no real monetary advantage to that, though.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by rph » Thu Jul 18, 2013 12:11 am

MinorXThreat wrote:So, I guess it is safe to assume that Opencart is correct and Mcaffe, Trustwave and Verisign are all wrong? Even though they provide absolute working demo's for the vulnerability...... Tell that to the merchant providers requesting PCI compliance. I've spoken extensively with phone support @ Mcaffe and Trustwave. It is NOT a false positive. This is a serious issue that could allow an attacker to forward users to a phishing site.
Yes, false positives happen all the time in PCI testing. Anyone who uses Redhat or CentOS as their host OS can tell you that. These scans are simple and automated and the level 1 techs are almost always untrained and working off a script. It's extremely likely these scanners don't even know you're using OpenCart nor scan for the actual vulnerabilities specific to it.

If you have a working example of a URL which OpenCart will redirect to another site go ahead and post it. Otherwise I stand by my position. This is a dumb scanner error. While these scans are always evolving, none of the PCI vendors I've worked with have ever stated it as an issue.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by Qphoria » Thu Jul 18, 2013 4:41 am

MinorXThreat wrote:Ok, no thanks to the OpenCart community this seems to be fixed now...

In index.php I commented the not found page and added this to stop the redirect

Code: Select all

// Dispatch
/$controller->dispatch($action, new Action('error/not_found'));/ 
$controller->dispatch($action,"");
This stopped the redirection exploit on McAfee's Vulnerability Demo.

Anyone who is planning to use the latest version of OpenCart should know it is NOT considered "secure" out of the box. (Regardless of what the devs here will tell you.)
What exactly do you think that so-called vulnerability does? Aside from you satisfying mcafee's warning.... that simply redirects you to a not found page for products that aren't found. Those simgle "/" marks aren't even the correct way to comment php.

With your change.. bad urls like:

Code: Select all

http://mysite.com/index.php?route=common/ho
will show a blank page instead of redirecting to a proper not found page.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Thu Jul 18, 2013 6:21 am

Qphoria wrote:What exactly do you think that so-called vulnerability does?
It appears they're using a POST to the currency module to redirect to a third-party website with:

Code: Select all

if (isset($this->request->post['redirect'])) {
    $this->redirect($this->request->post['redirect']);
} else {
    $this->redirect($this->url->link('common/home'));
}
Calling that "User specified URL redirection" for phishing is generous.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by rph » Thu Jul 18, 2013 7:41 am

This thread is rapidly approaching the point where it should be locked.

Whether you believe it or not, these are two separate issues as clearly specified by the technical information. One is for changing the password of a logged in customer, the other ostensibly for redirecting to a third-party website. You can look for developers to assist you with them in the OpenCart partners page or you can create a thread in the commercial support sub-forum.
MinorXThreat wrote:For those of us who don't work w crap code, serious PCI vulnerabilities are rare regardless of if the server is using ubuntu or centos.
Just to note my example was not about real vulnerabilities but false positives. Redhat/CentOS 5 have components like BIND and OpenSSH that PCI scanners will often claim have open CVEs when the fixes have really long been backported from Redhat/CentOS 6.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by MarketInSG » Thu Jul 18, 2013 9:51 am

Let's just do some extra checks to prevent redirect to other websites then...

open catalog/controller/module/currency.php and find

Code: Select all

			if (isset($this->request->post['redirect'])) {
				$this->redirect($this->request->post['redirect']);
			} else {
				$this->redirect($this->url->link('common/home'));
			}

replace it with

Code: Select all

			// Added strpos check to pass McAfee PCI compliance test
			if (isset($this->request->post['redirect']) && (strpos($this->request->post['redirect'], $this->config->get('config_url')) !== false || strpos($this->request->post['redirect'], $this->config->get('config_ssl')) !== false)) {
				$this->redirect(str_replace('&', '&', $this->request->post['redirect']));
			} else {
				$this->redirect($this->url->link('common/home', '')); 
			}
that's the same with the login function of OpenCart and a basic check to pass the PCI compliance test...


User avatar
Guru Member

Posts

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

Post by rph » Thu Jul 18, 2013 10:26 am

I forgot about that code. The hilarious part is that it doesn't even fix the supposed "vulnerability", it just passes the McAfee scan.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by MarketInSG » Thu Jul 18, 2013 10:31 am

That should prevent redirects to external websites, and pass the scan. Shouldn't really be a vulnerability in the first place IMHO


User avatar
Guru Member

Posts

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

Post by rph » Thu Jul 18, 2013 10:41 am

You beat it by simply throwing in the store URL in the redirect somewhere:

Code: Select all

http://stupidhackersite.ru?ref=webstore.com
or

Code: Select all

http://webstore.com.stupidhackersite.ru
It's a pretty well known method and, I believe, the source of all the Timthumb grief a few years back.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by MarketInSG » Thu Jul 18, 2013 10:47 am

ah yes, didn't thought of that. Anyway, this doesn't seem like a big issue to kick up such a fuss. At least the above code can pass the test. Another alternative is for him to further modify the codes such that the URL is not directly pass to the module to redirect.


User avatar
Guru Member

Posts

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

Post by Qphoria » Thu Jul 18, 2013 10:43 pm

rph wrote:
Qphoria wrote:What exactly do you think that so-called vulnerability does?
It appears they're using a POST to the currency module to redirect to a third-party website with:

Code: Select all

if (isset($this->request->post['redirect'])) {
    $this->redirect($this->request->post['redirect']);
} else {
    $this->redirect($this->url->link('common/home'));
} 
Calling that "User specified URL redirection" for phishing is generous.
But how is that related to the

Code: Select all

/$controller->dispatch($action, new Action('error/not_found'));/ 
$controller->dispatch($action,"");
change?

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Fri Jul 19, 2013 12:38 am

Heck, how is any of this related to a CSRF password change or a legit phishing attack? This thread isn't exactly a hotbed of accurate information.

If I had to take a wild guess why the change passed the PCI scan, I'd say it's possibly because the referrer page on the "vulnerability" was "https://mywebsite.net/store/admin.php?d ... ub=general". Since 404/not found was broken and all subsequent 404 traffic was being routed to the home page McAfee may have not carried out any further related tests.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by pprmkr » Fri Jul 19, 2013 1:54 am

Is it save enough to put route, url and connection in separate fields and post them back to the controller.
Then build the url ...

Code: Select all

			$this->data['route'] = $route;
			$this->data['params'] = $url;
			$this->data['connection'] = $connection;
Instead of :

Code: Select all

			$this->data['redirect'] = $this->url->link($route, $url, $connection);

Code: Select all

				$this->redirect($this->url->link($this->request->post['route'], str_replace("&","&",$this->request->post['params']), $this->request->post['connection']));
Instead of:

Code: Select all

				$this->redirect($this->request->post['redirect']);
And in the template:

Code: Select all

    <input type="hidden" name="route" value="<?php echo $route; ?>" />
    <input type="hidden" name="params" value="<?php echo $params; ?>" />
    <input type="hidden" name="connection" value="<?php echo $connection; ?>" />
Instead of:

Code: Select all

    <input type="hidden" name="redirect" value="<?php echo $redirect; ?>" />

Attachments


User avatar
Active Member

Posts

Joined
Sat Jan 08, 2011 11:05 pm
Location - Netherlands

Post by Daniel » Fri Jul 19, 2013 4:42 pm

MinorXThreat wrote:Greetings,

I always thought OpenCart dev's worked to keep everything PCI compliant.. It seems this is no longer a priority. I've seen others within the last month post this same issue on the board with no replies. I'm getting the feeling OpenCart isn't as secure as it claims to be. Anyone else run into this ?

Mcafee won't approve the latest version of opencart v1.5.5.1 for PCI compliance:

Here is the issue:

Vulnerability: User specified URL redirection (Open Redirect)

Protocol https Port 443 Read Timeout 10000 Method POST

Edit Demo
Path /store/index.php
Query route=module/currency
Headers Referer=https%3A%2F%2Fmywebsite.net%2Fstore%2Fadmin.php%3Fdpt%3Dconf%26sub%3Dgeneral


Evidence:

POST /store/index.php?route=module/currency HTTP/1.1
Referer : https://mywebsite.net/store/admin.php?d ... ub=general
Content-Type : multipart/form-data; boundary=X

--X
Content-Disposition: form-data; name="currency_code"

0
--X
Content-Disposition: form-data; name="redirect"

http://www.mcafeesecure.com/
--X--
Content-Type=multipart%2Fform-data%3B+boundary%3DX
Body --X Content-Disposition: form-data; name="currency_code" 0 --X Content-Disposition: form-data; name

Response:

Date Wed, 10 Jul 2013 23:24:43 GMT
Server Apache
X-Powered-By PHP/5.4.16
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Set-Cookie PHPSESSID=6208f8aa02586c9789539509be7ee977; path=/
Set-Cookie language=en; expires=Fri, 09-Aug-2013 23:24:43 GMT; path=/; domain=mywebsite.net
Set-Cookie currency=USD; expires=Fri, 09-Aug-2013 23:24:43 GMT; path=/; domain=mywebsite.net
Set-Cookie currency=0; expires=Fri, 09-Aug-2013 23:24:43 GMT; path=/; domain=mywebsite.net
Location http://www.mcafeesecure.com/
Content-Length 0
Connection close
Content-Type text/html; charset=UTF-8

your an idiot and now your getting banned! there is no vulnerability. its only to pass the PCI compliance test. nothing at all to do with vulnerability. we have repeatedly asked you to show us the vulnerability and you have only carried on talking about pci compliance!

pci fail does not equal vulnerability. it just means it does not pass PCI compliance.

any one else uses the word vulnerability in the opencart forums has actually have to prove they can get access to customer data or take over a site. i'm sick of idiots using this word then continuing arguing rather than admitting there is no issue.

now i'm happy to use a current fix that is used on the login redirect so that it passes pci compliance.

your wasting developers time.

OpenCart®
Project Owner & Developer.


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm
Who is online

Users browsing this forum: No registered users and 57 guests