Malicious Authorize.Net script being run to process transaction

Using nopCommerce 3.1

This is the second time in two months Authorize.Net has suspended, for an hour, our processing. Someone is running a malicious script against our nopCommerce shopping cart attempting to process the same order over and over again with a different credit card number each run of the script.

How is this possible or more importantly how can it be stopped? Shouldn't there be something within nopCommerce to prevent this? Why can't the captcha be enabled on the 'Payment Information' section of checkout?

Is anyone else experiencing this and what was the solution to stop it? Authorize.Net says if it continues to happen they will suspend our account until the issue is fixed.

Please I need a solution ASAP. TIA

Greg

Edit: I just saw a forum post. Is this an (XSRF or CSRF) attack? We are in the process of upgrading to 3.6.

Hello,

I can think of two ways they could try to run a script against your checkout form:

1) They have written some kind of bot which executes the form requests automatically, just like a user would submit the payment information form. So they are basically sending requests to your server, which do not come from your own website / form. This is prohibited by default, by the web-server you're running - IIS, but maybe you have your configurations file modified? Check this link:

http://enable-cors.org/server_iis7.html

You need to check your web.config file that is in the nopCommerce root folder. If you find that configuration, remove it from the file - or specify the exact domain names that you'd like to accept requests from, never allow all ("*").


2) They have automated the website's UI, using common UI Testing tools like Selenium, and are sending the requests using your website's form.

I think in either case you could try to restrict the IP that the requests are coming from ?  This must be configurable from IIS - if your hosting provider does not allow you direct access to IIS, you could try to contact them and see what they can do. Alternatively, you could search for some nopCommerce plugins that restrict IPs (I've done a brief search in the past, there are some out there)

Hope this helps.

Regards

We've had this site up since 1.9 so this is something new in the last two months. IMO there must be a new vulnerability be exploited that .net or nopCommerce software itself is not secured against. They have definitely replicated the form in some manner and automated the process but I don't know if it's internal or external. What's strange though is the amount they're trying to charge... $45.90? You'd figure they would try for something more.

The web.config modification you posted is not present in my web.config file. I'm attempting to add the captcha to the 'Payment Info' section of checkout without any luck so far. The IP address of the offender shows up in authorize.net transactions and I have been blocking them.

Without the complete code for checkout it doesn't seem possible for them to just replicate the Payment Info so I'm guessing they are using a full nop installation and recoding the section to loop through just the payment code. The problem is how are they even getting into our authorize payment gateway without our authorize.net credentials which leads me to believe they have to be manipulating our websites code either internally or with an injection of some type.

I know that nop states an injection is not possible but for every security threshold there is a hacker who can break it. Bottom line is it is happening and nopCommerce should be concerned. If this is the start of something new there will be lots of unhappy nop users when authorize.net starts shutting down peoples payment gateways like they have stated they will do us if it persists.

This is a serious issue and needs to be addressed by nopCommerce. I'd be more than happy to let them on the site.

So no one from nopcommerce wants to address this???

There is only one way someone could run a loop program to attempt to post fraudulent transactions to our authorize.net gateway. They would need our Transaction Key and Login Id. Only the Global Administrators can access settings, payment methods and plugins in our admin back end and there are only three. The two owners and myself. Shipworks also needs an Administrators account to work.

Our global administrators have full access. Our administrators have full access except:

Allow Customer Impersonation
Manage ACL
Manage Customer Roles
Manage External Authorization Methods
Manage Payment Methods
Manage Plugins
Manage Settings
Manage Widgtes

So unless a hacker has found a vulnerability to spoof the Global Administrators role that's not what is happening.

The second option is they have hacked our database to obtain the information. There are only three accounts with access to do that. The SQL sa account, my SQL administrators account and the nopcommerce database account. Each of these accounts have passwords that are at least 16 characters long containing upper and lower case, digits and special characters. In other words very strong passwords. Of course some one could have obtained one in another fashion. They are obviously written down and stored under lock and key but hey you never know.

Which leads us to this. Why is all of the important security information for PayPal, credit card processors and everything else stored in the database as clear text and not stored as encrypted data???

Storing all this information as encrypted data would ensure that NO ONE could obtain the information either from the website back end or by hacking the database under ANY circumstance!!!

Secondly why hasn't the captcha been modified so that it also can reside on the shopping cart 'Order Confirmation Page'???

Implementing both of these features should be a priority for the nopcommerce team and would literally prevent anyone from obtaining credit transaction security configuration settings. It would also prevent anyone from using a loop program to spoof the 'Order Confirmation' page which is what is happening to us.

Can some one give us the code to implement the captcha on the Order Confirmation page?? We have attempted but in all cases we get errors. This must be happening to a lot of other shopping cart providers as well because we are seeing captcha on more and more Order Confirmation pages from various website.

One of the solutions immediately proposed by Authorize.Net was to implement captcha on the order confirmation page and where as they didn't come right out and say it, it was quite clear to us that this is an issue they are seeing more and more of.

Thanks

Do you have a shipping method defined, Greg?  I found a SQL injection script in a payment method we had defined and I removed the shipping method definition completely so this couldn't be done again.  There seems to be a security bug in at least that portion of the software so getting rid of shipping methods could help at least put a temporary stop to the problem.  At lease on version 2.3 which is what I have running at the moment.

I am also going to review the admin section to impliment windows athentication on top of the software implimention if possible.  to completely lock out access to the admin sections.  Has anyone doubled up the authentication in that fashion?  If the URLs are inaccessible publicly on the admin side I would think that this will significantly reduce the security footprint to deal with as well.

Hi Greg

Were you able to solve the problem, we are having same trouble many fraud transactions. We changed transaction key but not helpful. It would be appreciated if you could please let me know how did you solve this problem ?

Thanks!
Sandeep

For the script injection I removed the payment method. To not give them a record to inject the script into.  I'd suggest looking through your site logs for post request lines from the related IP address.  Might give you some insight as to what URL they are posting to.

Did you look at your shipping method records in the database to see if there is a script tag in it?

Thank you!!

could you please let me know what is  AN fraud protection and how can we use as Greg recommended in this post

https://www.nopcommerce.com/boards/t/38341/malicious-authorizenet-script-being-run-to-process-transactions.aspx#172383

Thanks!