Post by garyw75 » Tue Sep 26, 2017 3:33 pm

I am not sure if the community is aware but there is a Python script circulating online that automates a brute force attack on the Opencart admin login page.

We are a design agency who use Opencart for our clients. We have several servers with a dozen or so installations on each. They are pretty much all under attack.

We have also tested the code against an installation in the wild ourselves with weak passwords. The code checks for the login cookie and outputs the user/pass combination that has worked. Google it. The codes everywhere online.

Opencart gives a HTTP/1.1" 200 on a failed login attempt. The user-agent is always different and the IP's are being cycled. We have also seen an attack from a CloudFlare range of IPs. The attack is slow so it isn't affecting the server load in any way and it's not fast enough to be picked up by ModSecurity's standard rules.

I think there may be several variations of the attack script as there are two styles showing up in the logs.

Code: Select all

163.172.22.148 - - [21/Sep/2017:15:49:06 +0100] "POST /admin/index.php HTTP/1.1" 200 3826 "-" "python-requests/2.11.1"
and

Code: Select all

45.77.89.33 - - [22/Sep/2017:01:51:29 +0100] "POST /admin/index.php?route=common/login HTTP/1.1" 200 3926 "xxx/admin/index.php" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/534.16.69 (KHTML, like Gecko) Version/4.6.2 Safari/533.24"
The script kiddies are hitting the server fast and with the default useragent left in the script. These can be blocked easily. I have managed to block the obvious Useragents with Mod security. That's worked.

The other one is rotating real useragents on each connection so I cant work out what to do.

I was hoping the Devs could assist in editing this Joomla password attack rule for Modsecurity which in turn everyone can use.

Code: Select all

<Location /admin/index.php>
    SecDefaultAction phase:2,deny,status:403,log,auditlog
    SecRule IP:bf_counter "@eq 5" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=3600,msg:'IP address blocked because of a suspected brute force attack on the Joomla website'"
    SecRule ARGS:option "@streq com_login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Joomla authentication failures from IP address', setvar:IP.bf_counter=+1"
</Location>
This is the heart of the blocking logic which needs changing:-

Code: Select all

SecRule ARGS:option "@streq com_login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Joomla authentication failures from IP address', setvar:IP.bf_counter=+1
When you login unsuccessfully to a Joomla website, com_login will be a post value passed back to the login page.
Does Opencart post something similar and can this be modified?

Thanks

New member

Posts

Joined
Thu May 12, 2016 7:59 pm

Post by ADD Creative » Tue Sep 26, 2017 8:21 pm

Do any or the scripts you know of attempt to use a username other than 'admin'? Changing 'admin' to something else is good idea anyway. I suspect changing the admin directory would also stop the scripts.

For the ModSecurity rule I don't think the Joomla example is a good fit for the OpenCart login. You would need to include the query string ?route=common/login in the rule somehow, as /admin/index.php would be any page in the admin. You also can't check the args for com_login, you probably need to check the the response to the POST was 200 (failed) and not a 302 (logged in).

www.add-creative.co.uk


Expert Member

Posts

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

Post by IP_CAM » Tue Sep 26, 2017 8:50 pm

Have you ever tried something like this ?
Ernie
https://www.opencart.com/index.php?rout ... n_id=23969
Image

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.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland

Post by garyw75 » Tue Sep 26, 2017 10:10 pm

For now, I have added the common/login as the failure point in ModSecurity. If a referer hits this multiple times they are failing with a password. Setting it to 10 times in an hour gives genuine administrators a few times to get it wrong without getting blocked. It's not perfect, agreed, but it is mitigating an awful lot.

As it stands at the moment adding modules to hundreds of sites isn't really an option for us and we need a server level solution.

Code: Select all

<Location /admin/index.php>
    SecDefaultAction phase:2,deny,status:403,log,auditlog
    SecRule IP:bf_counter "@eq 10" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=3600,msg:'IP address blocked because of a suspected brute force attack on the Opencart website'"
    SecRule ARGS:option "@streq route=common/login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Opencart authentication failures from IP address', setvar:IP.bf_counter=+1"
</Location>
We have many of the attack IP's hitting different servers at the same time. I am not convinced we have been targeted, I think this could be a wider issue and could escalate to a more serious issue like the recent Wordpress problems as this Python script and subsequent variants are coded.

New member

Posts

Joined
Thu May 12, 2016 7:59 pm
Who is online

Users browsing this forum: No registered users and 48 guests