Nov 2016 Update: We released a new free guide to help you identify and remove Joomla hacks.
Last week, the Joomla team released an update to patch a serious vulnerability on Joomla 3.x. This vulnerability is an SQL injection (CVE-2015-7858) that allows for an attacker to take over a vulnerable site with ease. We predicted that the attacks would start in the wild very soon, due to the popularity of the Joomla platform along with how easy the exploitation was.
Attacks in the Wild – Patient Zero (2015 / Oct / 22)
We were right. Within 4 hours of the initial disclosure by Joomla and TrustWave, we saw direct attacks against 2 very popular Joomla sites that use our network. The attack tried to extract the current session from any logged in admin user and were blocked by our generic Joomla SQL Injection signatures:
What is very scary to think is that neither of these sites were patched at the time. The disclosure happened on a Thursday afternoon (evening in Europe), when many webmasters were already off for the day. Both sites would be compromised by now, if they were not deploying the defence in depth approach, which in their case, was to use a WAF on top of their site.
Attacks in the Wild – First Day (2015/Oct/23)
Within less than 24 hours after disclosure, we started to see Internet-wide scans trying to hit every single site on our network to see if they were vulnerable. They were leveraging 2 types of requests:
The first one was just a simple request, not an actual exploit, looking for the default Joomla SQL syntax error page. If the SQL error page showed up, they knew the site was likely a viable target for a follow-up exploitation. The second request, was trying to get the admin user from the jos_users table.
In both cases, ff the following error was returned:
They knew they had a valid target based on the response. Note that during the first day since the release, the IP addresses we flagged in these attacks were mostly behind the Tor network.
Attacks in the Wild – Following Days
Starting over the weekend, attacks on the Joomla SQL injection vulnerability increased, with different attempts and variations being tried against every single site on our network. This is the growth of exploit attempts so far since disclosure:
What we found interesting was that many of the attacks started to check for the Joomla version before running the exploit payloads:
184.108.40.206 – – [26/Oct/2015:05:55:03 -0400] “GET /plugins/system/cache/cache.xml HTTP/1.1” 200
If the cache.xml returned a version over 3.x they would run the payload to try to get the admin session or a valid admin user:
220.127.116.11 – – [26/Oct/2015:12:18:29 -0400] “GET /?view=history&list[select]=extractvalue(rand(),concat(0x3a,(sElect(EXP(2))),0x3a,user()))&option=com_contenthistor
This likely saves them time with false positives and increases the odds of a successful exploitation attempts. Based on this pattern, it’s a very clear example of how basic automated scans can be adjusted to look for version numbers before applying more nefarious actions.
We are also seeing attacks leveraging the GoogleBot user agent, so do not get fooled by that. Googlebot would not try these types of requests:
18.104.22.168 – – [26/Oct/2015:13:03:47 -0400] “POST /index.php HTTP/1.1” 403
User Agent: “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
If you have not patched yet, do it now! We can’t stress this enough!
This data tell us is that the average webmaster has less than 24 hours to patch a site after a serious disclosure like this. That’s for the average website (small to medium size). If you have a popular site, you have only a couple of hours from disclosure to attack, so you have to react fast.
This is why we emphasize the importance of Defense in Depth. You can not just rely on being updated as your only layer of security. With the proper access control, monitoring, Intrusion detection and prevention system, you can be ahead when cases like this happen or even a 0-day exploit. In this specific scenario, security mechanisms that blocked generic SQL Injections and evasions, prevented the worst from happening.
Is the log entry containing “option=com_contenthistor” correct? Are they actually omitting the “y” on that request?
It has to have the y at the end: option=com_contenthistory. Little typo there.
Very interesting data about how an exploit spreads in the wild once publicly disclosed.
Thanks for the update.
Kudos to the Joomla community for realising the seriousness of this vulnerability and announcing ahead of time that an urgent security update was imminent. (I don’t think Joomla security announcements have happened quite like this before).
For me on the east coast of Australia, the scheduled release time was 1 am. I stayed up and patched the 40 or so Joomla 3.x websites I am responsible for.
Some of these have web application firewalls installed but I didn’t want to take the risk of waking up to 40 hacked websites!
Nice! I wish more webmasters would take security as seriously as you do. We are still seeing a LOT of unpatched sites out there :/
Thanks for letting us know how dangerous this exploit can be
Thanks for this update to patch a serious vulnerability on Joomla. We are hoping more updates in the future as well, so it will help Joomla Developers.
Comments are closed.