Exactly 3 days ago, the Joomla team issued a patch for a high-severity vulnerability that allows remote users to create accounts and increase their privileges on any Joomla site. Both issues combined give the attackers enough power to easily upload backdoor files and get complete control of the vulnerable site.
A few hours after the patch was released, we were able to reverse-engineer it. We created an internal-only tool that allowed us to exploit the vulnerability and upload a backdoor. Marc explained the technical details in yesterday’s post. His research allowed us to understand how attackers could potentially abuse the vulnerability and what we would need to do to update the virtual patching rules in our cloud Firewall to keep our customers protected.
However, we were not the only ones performing this research. Less than 24 hrs after the initial disclosure, we started to see tests and small pings on some of our honeypots trying to verify if this vulnerability was present.
In less than 36 hrs after the initial disclosure, we started to see mass exploit attempts across the web. In fact, because of the sharp increase, it’s our belief that any Joomla! site that has not been updated is most likely already compromised.
Phase 1: Initial Pokes
The first attacks started at around 1pm UTC on the 26th, less than 24 hrs after the initial disclosure by the Joomla team. Most of them were looking for the user.register tasks and trying to create users. They were especially targeting some of the most popular Joomla sites.
This is how the payload would look in your web logs:
POST /index.php?option=com_users&task=user.register HTTP/1.1"
Phase 2: First Mass Exploits
A few hours later, at around 8pm UTC, a couple of IPs from Romania started a mass attack against thousands of different Joomla sites. In all of them, they tried to create a username called db_cfg with the password fsugmze3. They were going to the same URL with a payload that looks like:
82.77.15.204 - - [26/Oct/2016:18:09:24 -0400] "POST /index.php/component/users/?task=user.register user[name] = db_cfg user[username] = db_cfg user[password1] = fsugmze3 user[password2] = fsugmze3
If your site was not updated in time, look for the db_cfg username on your site as you are likely to have been hacked already. You can also look for these 3 IP addresses in your log:
82.76.195.141 82.77.15.204 81.196.107.174
They were the ones doing this initial mass exploitation campaign. Shortly after, another IP address from Latvia started a similar mass exploit campaign trying to register random usernames and passwords on thousands of Joomla sites. The only similar pattern for this Latvia IP address was the email: ringcoslio1981@gmail.com.
So we have another IP to look for in your logs:
185.129.148.216
Both campaigns kept running strong through the 26th and 27th attempting to compromise every Joomla site we were watching, including our Honeypots.
Phase 3: Public Knowledge
After these initial mass exploits, multiple researchers and security professionals started to share different exploits for this attack. Some of them are even automating the upload of backdoors and using some unique techniques to bypass the media uploader (using .pht files).
That led to a massive increase in IP addresses trying to exploit this vulnerability using different patterns and techniques.
This is the graph of exploit attempts against this vulnerability since the disclosure:
… And that’s just based on the number of sites for which we have visibility.
Likely Already Compromised
If you have not updated your Joomla site yet, you are likely already compromised. Every Joomla site on our network was hit (and blocked by the Sucuri Firewall) and I assume pretty much every site out there suffered the same way.
I still recommend updating your site ASAP and checking for any new users in your dashboard. Also look for the provided IP addresses in your logs, along with the task=user.register pattern. If you find yourself in a situation where you have been compromised we have a new guide on how to clean a hacked Joomla site that you can follow. If you are unable to do it yourself we can help with the incident response.
Sucuri Malware Research Team
Eugene Wozniak
Luke Leal
Cesar Anjos
John Castro
Fioravante Souza
Alycia Mitchell
Daniel Cid
9 comments
Thank you Daniel…
With your help, here’s the command I’ve used to look for attempts in a centos cpanel environment.
grep -r “POST /index.php/component/users/?task=user.register” /usr/local/apache/domlogs
Thanks
two another ip here:
80.88.87.84
186.202.113.85
New attacking IP : 93.170.186.28
This IP 185.129.148.216 created an account in our system at [27/Oct/2016:04:23:50 +0200].
Luckily it (ringcoslio1981@gmail.com) wasn’t enabled/activated and the user never logged in.
Our system doesn’t seem compromised. No newer files were found on the server. I checked that before we updated to 3.6.4.
I would like to know if we were lucky because our admin folders are password protected by htaccess?
Or was it just stupidity of the hacker 185.129.148.216?
BTW: This IP still tries something. I don’t understand what. I just notice lots of new log-entries trying something in the admin folder and always getting a “client denied by server configuration”.
Can’t nobody do something against this IP?
Thnks
Base on my test,if you don’t allow user registration,the account will not be enabled and activated.
But if you allow,the account will be enabled and activated.
Ahh, OK.
Thank you.
Your tests were correct:-)
User registration was not allowed!
Does anybody understand what this is aimed for:
{norformat}
185.129.148.216 – – [01/Nov/2016:00:02:35 +0100] “POST /jconfig.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:00:43:58 +0100] “POST /images/logo_img.php HTTP/1.0” 403 1295 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:01:30:54 +0100] “POST /elements.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:02:14:13 +0100] “POST /images/stories/alfa.php HTTP/1.0” 404 1844 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:03:08:53 +0100] “POST /help.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:04:06:54 +0100] “POST /default_component.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:04:58:34 +0100] “POST /go.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:05:53:34 +0100] “POST /mide.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:06:41:20 +0100] “POST /wp-cache.php HTTP/1.0” 404 1844 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:07:15:35 +0100] “POST /u.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:08:04:10 +0100] “POST /wp-data.php HTTP/1.0” 404 1844 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:08:35:38 +0100] “POST /images/laj.php HTTP/1.0” 403 1295 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:09:52:34 +0100] “POST /ws0.php HTTP/1.0” 404 1836 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:10:44:37 +0100] “POST /images/al277.php HTTP/1.0” 403 1295 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:11:32:38 +0100] “POST /tmp/bogel.php HTTP/1.0” 403 1295 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
185.129.148.216 – – [01/Nov/2016:12:39:19 +0100] “POST /libraries/joomla/web.php HTTP/1.0” 403 1295 “-” “Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0”
{noformat}
Seems like they are looking for backdoors on your site. They all returned 404’s, so you are good in that regard.
Thank you.
Do you mean backdoors that they believe have left behind?
I understand. These are automatic processes which have no memory and don’t know that the user login failed.
Do you think it’s more than one person behind 185.129.148.216?
Probably I should not take this too personally.
Comments are closed.