Post by JNeuhoff » Tue Jan 25, 2022 8:46 pm

Further to this: Though the intent is that of a bruteforce attempt, it also has the effect of a DDoS attack because it quickly creates thousands of session entries in the 'oc_session' DB table, causing the OpenCart-based web server to slow down and eventually to become non-responsive. I have changed the forum thread title accordingly.

Also, unless the attacker has changed his script, according to our own past observations he also uses different randomly created user names, not only 'admin', as well as randomly generated passwords.

The good news is that, even if in the extremely unlikely event of using a correct user/password, the VQmod XML script from antropy, or our suggested modification of the 'admin/index.php', would still repel this attacker!

It's just simply a waste of network resources for everyone involved in this.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by pipoy » Wed Jan 26, 2022 8:49 am

Thank you @paulfeakins for relaying me to this thread.

I didnt actually read the whole thing. But reading this now, I am partially relieved that the attack didnt happen just to my friend's website.
We thought we are being hacked by a competitor.

If only I saw this thread earlier, I wouldnt have a day and a half troubleshooting.

I have 6 Opencart websites including I manage for a friend. 5 of them have hidden admin. 1 of them does was not and the attack only happened to it.

So hiding the admin helps.

But I am happy the community is doing something about this.

Active Member

Posts

Joined
Fri Mar 04, 2016 12:18 pm

Post by tiredman » Mon Feb 07, 2022 1:12 pm

JNeuhoff wrote:
Wed Nov 24, 2021 10:27 pm
I just changed the original thread title, removing the '[SOLVED' prefix.

Reason for this: We have tried the Bitninja WAF. It repels about 90% or so of the bruteforce attackers' POST requests, but that still leaves too many to slip through to our websites. Some of Bitninja's rules are based on an old Google reCaptcha, and invisible captcha, and/or a honeypot trap. These may be good enough for rejecting simply spambots, but are insufficient for bruteforce attacks. Ours resulted in over a million gray-listed IP addresses in a matter of a few weeks.

Also, the Bitninja caused some 405 errors, especially for Safari web browser users. Safari has known autofill bugs anyway, so server-side honeypot traps often result in false rejections for Safari.

So it's back to square one: A decent WAF is needed here!

BTW.: This simple PHP script in our admin/index.php rejects the bruteforce attackers' POST requests to the /admin quite effectively:

Code: Select all

if ($_SERVER['HTTP_USER_AGENT'] == 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0') {
	header('HTTP/1.0 403 Forbidden');
	exit;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
	if (empty($_GET)) {
		header('HTTP/1.0 403 Forbidden');
		exit;
	}
}
But such a rule should really be implemented on a firewall level!
The above code didn't work for me... after changing the 'HTTP_USER_AGENT' string. I had a similar attack on Friday, and it increased the access log by 10MB/ hr. Here's a sample of my logs:

Code: Select all

218.76.202.167 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.213 
195.87.182.10 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10030 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.715 
94.139.170.82 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.054 
8.142.35.42 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10034 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.705 
113.20.31.19 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10029 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.683 
47.243.135.104 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.677 
It started to slowly diminish after isolating the IPs into a banned table for the firewall to handle. My usual dashboard "PEOPLE ONLINE" is about 150, that time it went to 2500, and I even saw 2800.

It has since stopped. In order to buy some time, and because I don't have a lot of customer logins in a day, I temporarily added a line in catalog/controller/account/login.php just under the 'validate' function. I'm not sure what the implications are except transfer the attacker back to itself, but I noticed that it stopped very quickly.

Code: Select all

	protected function validate() {
			exit(header("Location: http://" . strval($_SERVER['REMOTE_ADDR'])));
I think the long term solution is to ban the IPs using the firewall.

New member

Posts

Joined
Mon Aug 06, 2018 1:11 am

Post by JNeuhoff » Mon Feb 07, 2022 7:50 pm

tiredman : This is a different bruteforce attack targeting the frontend account/login. What exact POST requests did you get (query params, query string)?

I am thinking about adding some protection for these kinds of bruteforce attackers to our SpamBot Buster, shouldn't be too hard because these bruteforce POST requests usually don't involve keyboard/mouse/touch events, unlike with genuine human users.

I like your idea of transferring the attacker back to itself :)

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by ADD Creative » Mon Feb 07, 2022 8:38 pm

tiredman wrote:
Mon Feb 07, 2022 1:12 pm
The above code didn't work for me... after changing the 'HTTP_USER_AGENT' string. I had a similar attack on Friday, and it increased the access log by 10MB/ hr. Here's a sample of my logs:

Code: Select all

218.76.202.167 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.213 
195.87.182.10 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10030 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.715 
94.139.170.82 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10024 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=1.054 
8.142.35.42 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10034 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.705 
113.20.31.19 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10029 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.683 
47.243.135.104 - [04/Feb/2022:10:23:37 +0800] "POST /index.php?route=account/login HTTP/1.1" 200 10033 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" res_time=0.677 
It started to slowly diminish after isolating the IPs into a banned table for the firewall to handle. My usual dashboard "PEOPLE ONLINE" is about 150, that time it went to 2500, and I even saw 2800.

It has since stopped. In order to buy some time, and because I don't have a lot of customer logins in a day, I temporarily added a line in catalog/controller/account/login.php just under the 'validate' function. I'm not sure what the implications are except transfer the attacker back to itself, but I noticed that it stopped very quickly.

Code: Select all

	protected function validate() {
			exit(header("Location: http://" . strval($_SERVER['REMOTE_ADDR'])));
I think the long term solution is to ban the IPs using the firewall.
A firewall would be a long term solution. However, baning by IP address wouldn't. These these types of brute force attempts usually come from multiple compromised addresses that change all the time.

If the IP addresses you access the admin from doesn't change it is best to add an allow list and ban all others.

One short term solution is a more general ban for old user agents (or even an allow list) in htaccess. Most bots seem to pretend to be older versions of web browsers. So you can use something like the code below in htaccess.

Code: Select all

SetEnvIfNoCase User-Agent "^.*Chrome/[1-8][0-9]\..*$" bad_bot
SetEnvIfNoCase User-Agent "^.*Firefox/[1-8][0-9]\..*$" bad_bot
Deny from env=bad_bot

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by tiredman » Mon Feb 07, 2022 10:25 pm

The store is running off on a Nginx web server. It doesn't have .htaccess file.

This time the operator is acting as a customer trying to log in, in the hope of scoring an entry through a customer's weak credentials. I kinda think he is polling for some sort of success response, and not expecting a redirect to itself. All the IPs are proxy IPs, so the machines are innocent cover-ups for it, and when enough comes back to hit itself, they'll sooner than later realize that they have been used... and he can't risk that happening – just my guess, what do I know. :laugh:

New member

Posts

Joined
Mon Aug 06, 2018 1:11 am

Post by tiredman » Mon Feb 07, 2022 10:41 pm

JNeuhoff wrote:
Mon Feb 07, 2022 7:50 pm
tiredman : This is a different bruteforce attack targeting the frontend account/login. What exact POST requests did you get (query params, query string)?

I am thinking about adding some protection for these kinds of bruteforce attackers to our SpamBot Buster, shouldn't be too hard because these bruteforce POST requests usually don't involve keyboard/mouse/touch events, unlike with genuine human users.

I like your idea of transferring the attacker back to itself :)
I wished I had harvested the POST body request, but did not... I'm not sure if the database logs them. I did not check. The attacks are so fast that it crashed the php-fpm service. I was alerted only when Monit restarted it and notified me.

I'm halfway through it now. It has to do with geo-locating the IP addresses. This https://www.ipqualityscore.com/ will be it for me.

New member

Posts

Joined
Mon Aug 06, 2018 1:11 am

Post by khnaz35 » Sat Feb 12, 2022 11:30 pm

MaxD wrote:
Tue Jan 25, 2022 6:18 am
I have seen this today on few client's shops. Request rate is so high that shops go down.

Here is my one-line solution for any configuration including renamed or password-protected admin folder.

Add this line to the beginning of index.php and admin/index.php:

Code: Select all

if (!empty($_POST) && @$_SERVER['REQUEST_URI'] == '/admin/') exit;

The response code doesn't matter, it seems that the bruteforcer doesn't analyse the answer.
This will work if the request is empty

Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature ;) :) :-*


User avatar
Active Member

Posts

Joined
Mon Aug 27, 2018 11:30 pm
Location - Malaysia

Post by khnaz35 » Sun Feb 13, 2022 12:14 am

Hi @OSWorX ,
I send you PM have a look into it.

Thanks in advance

Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature ;) :) :-*


User avatar
Active Member

Posts

Joined
Mon Aug 27, 2018 11:30 pm
Location - Malaysia

Post by EvolveWebHosting » Sun Feb 13, 2022 12:46 am

You're going to pull all of your hair out trying to manually keep up with the attackers! They're very clever and very fast.

2 Week FREE Trial of our Shared Hosting plans (DIrectAdmin or cPanel) for new customers
2 Week FREE Trial of Astra Firewall and Malware Scanner
Visit our website for full details and to start your trial today - www.evolvewebhost.com


User avatar
Active Member

Posts

Joined
Fri Mar 27, 2015 11:13 pm
Location - Denver, Colorado, USA

Post by OSWorX » Sun Feb 13, 2022 1:09 am

khnaz35 wrote:
Sun Feb 13, 2022 12:14 am
Hi @OSWorX ,
I send you PM have a look into it.

Thanks in advance
Read my answer there ..

Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by khnaz35 » Sun Feb 20, 2022 9:03 pm

Update on this thread regarding recent attacks on Open-cart base websites. I have face the one and sharing my solutions to the follow community as well.

Most of us we are all aware of the DDOS attack on admin is common where the attacker/stress send million of empty get requests on the admin url but this time I face posit of it on the front end.

Attacker used legals method to crawl website/bots but illegal way and the site went crashing because all the resources we exhausted during the attack.
When site went crash the front end was throwing the error

Code: Select all

Fatal error: Uncaught Exception: Error: Could not make a database link using _____________________@localhost! in /home/xyz/public_html/system/library/db/mysqli.php:19 Stack trace: #0 /home/xyz/public_html/system/library/db.php(31): DB\MySQLi->__construct('localhost', 'abcd', 'efgh'ijkl, '3306') #1 /home/xyz/public_html/system/framework.php(80): DB->__construct('mysqli', 'localhost', ...................thrown in /home/xyz/public_html/system/library/db/mysqli.php on line 19
The worst part of this attack was because of millions of requests database server couldn't handle and it throw error and database user name, password and database name , port everything was shown on the page.

mistake: error_log setting was kept on from the php.ini

We do use cloud flare for our website once notice the attack haded to the cloudflare and start implementing the rules.
  • 1.Change the ip of my website.
    2. Proxy my ip from cloudflare.
    3. Buy the pro plan in cloudflare
    4. Added the code in admin index.php and index.php
    5.Block all the country on base of cloudflare access data
    6.Turn on i am under attack challenge
    7.Turn on the DDos protection from the cloudflare.
    8.Setup the rules in cloudflare system to block some browser which was being used in malicious activities.
    9.Changed the username and password for the database
    10.Enable the WAF in cloudflare too.
    11. Also I cleared the session table as well. Because of this activity the session table was going crazy. I have code for it to be cleared every day twice as per my needs.
    12.Changed all my username and passwords in my all accounts
    13. Modify my .htaccess file
    14. Allowing Cloudflare IPaddresses
P.s also contacted @osworx regarding the Mysqli.php. Thanks for his help

Attachments

image002_1.png

image002_1.png (61.16 KiB) Viewed 11523 times

image001.png

image001.png (33.91 KiB) Viewed 11523 times

image001_1.png

image001_1.png (33.91 KiB) Viewed 11523 times


Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature ;) :) :-*


User avatar
Active Member

Posts

Joined
Mon Aug 27, 2018 11:30 pm
Location - Malaysia

Post by ADD Creative » Sun Feb 20, 2022 9:15 pm

khnaz35 wrote:
Sun Feb 20, 2022 9:03 pm
The worst part of this attack was because of millions of requests database server couldn't handle and it throw error and database user name, password and database name , port everything was shown on the page.

mistake: error_log setting was kept on from the php.ini
It's not the error_log setting that is the problem it's the displaying of errors.

You need make sure display errors in set to off in all 3 places. Your PHP settings, in system/config/default.php and in the settings. Not only can this cause minor notices and warnings to cause bigger errors, is also be a security risk.

1. In your PHP settings make sure display_errors is set to Off. Use phpinfo() to check. It should be off by default, but there are lots of rubbish hosts out there.

2. In system/config/default.php set error_display to false.

3. In your OpenCart Setting on the server tab set Display Errors to No.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by khnaz35 » Sun Feb 20, 2022 9:33 pm

ADD Creative wrote:
Sun Feb 20, 2022 9:15 pm
khnaz35 wrote:
Sun Feb 20, 2022 9:03 pm
The worst part of this attack was because of millions of requests database server couldn't handle and it throw error and database user name, password and database name , port everything was shown on the page.

mistake: error_log setting was kept on from the php.ini
It's not the error_log setting that is the problem it's the displaying of errors.

You need make sure display errors in set to off in all 3 places. Your PHP settings, in system/config/default.php and in the settings. Not only can this cause minor notices and warnings to cause bigger errors, is also be a security risk.

1. In your PHP settings make sure display_errors is set to Off. Use phpinfo() to check. It should be off by default, but there are lots of rubbish hosts out there.

2. In system/config/default.php set error_display to false.

3. In your OpenCart Setting on the server tab set Display Errors to No.
That's correct!
Was just generalising it

Urgent Questions shoot here: khnaz35@gmail.com
Enjoy nature ;) :) :-*


User avatar
Active Member

Posts

Joined
Mon Aug 27, 2018 11:30 pm
Location - Malaysia

Post by Khal » Tue Feb 22, 2022 8:19 pm

BTW.: This simple PHP script in our admin/index.php rejects the bruteforce attackers' POST requests to the /admin quite effectively:
Code: Select all

if ($_SERVER['HTTP_USER_AGENT'] == 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0') {
header('HTTP/1.0 403 Forbidden');
exit;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
if (empty($_GET)) {
header('HTTP/1.0 403 Forbidden');
exit;
}
}
I added this code to the .htninja file and it would not let me access the Ninja firewall dashboard. The Ninja Firewall support said that the following code is blocking access and it needs to be removed:

Code: Select all

if ($_SERVER['REQUEST_METHOD'] == 'POST') {
if (empty($_GET)) {
header('HTTP/1.0 403 Forbidden');
exit;
}
}
Just wanted to let others know in case they are having the same issue.

Active Member

Posts

Joined
Thu May 24, 2012 9:24 pm
Location - Teesside, UK

Post by ri2k » Thu Mar 03, 2022 9:43 pm

messor wrote:
Fri Nov 05, 2021 3:49 am
You can use Messor security plugin to stop DDoS its free forever.
https://www.opencart.com/index.php?rout ... rch=messor
Has anyone used this? Does it work?
Do you guys recommend this?

New member

Posts

Joined
Mon Aug 24, 2020 7:31 pm

Post by johnp » Fri Mar 04, 2022 12:39 am

ri2k wrote:
Thu Mar 03, 2022 9:43 pm
messor wrote:
Fri Nov 05, 2021 3:49 am
You can use Messor security plugin to stop DDoS its free forever.
https://www.opencart.com/index.php?rout ... rch=messor
Has anyone used this? Does it work?
Do you guys recommend this?
Never used it but will take a look. I normally use Ninja Firewall which I can have up and running in 5-10 mins.

Opencart 1.5.6.5/OC Bootstrap Pro/VQMOD lover, user and geek.
Affordable Service £££ - Opencart Installs, Fixing, Development and Upgrades
Plus Ecommerce, Marketing, Mailing List Management and More
FREE Guidance and Advice at https://www.ecommerce-help.co.uk


User avatar
Active Member

Posts

Joined
Fri Mar 25, 2011 10:25 am
Location - Surrey, UK

Post by ri2k » Fri Mar 04, 2022 11:58 am

johnp wrote:
Fri Mar 04, 2022 12:39 am
ri2k wrote:
Thu Mar 03, 2022 9:43 pm
messor wrote:
Fri Nov 05, 2021 3:49 am
You can use Messor security plugin to stop DDoS its free forever.
https://www.opencart.com/index.php?rout ... rch=messor
Has anyone used this? Does it work?
Do you guys recommend this?
Never used it but will take a look. I normally use Ninja Firewall which I can have up and running in 5-10 mins.
I installed it but couldn't get it to work. I signed up but then it didn't login from Opencart admin panel.

New member

Posts

Joined
Mon Aug 24, 2020 7:31 pm

Post by thanos74 » Mon Apr 04, 2022 4:45 pm

I have the same problem....
Which is the better code to avoid Bruteforce in /admin ?

admin/index.php

Code: Select all

if ($_SERVER['HTTP_USER_AGENT'] == 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0') {
	header('HTTP/1.0 403 Forbidden');
	exit;
}
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
	if (empty($_GET)) {
		header('HTTP/1.0 403 Forbidden');
		exit;
	}
}
or
from @antropy
https://www.opencart.com/index.php?rout ... n_id=43261

Code: Select all

<![CDATA[
			if (defined('HTTPS_CATALOG') && defined('DIR_CATALOG') && $_SERVER['REQUEST_METHOD']==='POST' && empty($_GET)) {
				http_response_code(403);
				die;
			}

New member

Posts

Joined
Thu Nov 05, 2015 4:55 pm

Post by ADD Creative » Mon Apr 04, 2022 6:11 pm

thanos74 wrote:
Mon Apr 04, 2022 4:45 pm
I have the same problem....
Which is the better code to avoid Bruteforce in /admin ?
They both do the same thing. It is probably more efficient to do the same in htaccess. That was the server doesn't have to start a PHP process.
viewtopic.php?f=179&t=225771&start=20#p836216

If the IP addresses you access the admin from doesn't change it is best to add an allow list and ban all others.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom
Who is online

Users browsing this forum: No registered users and 24 guests