When it comes to cleaning up hacked websites one of the three basic pieces of doing a proper cleanup is trying to determine how the website was hacked. Without doing that you leave open the possibility that the vulnerability still exists and can be exploited again. Not surprisingly then when people come to us re-clean a hacked website after another company has done that and the website got hacked again there has almost never was an attempt to determine how the website was hacked during the previous cleanup.
Another reason for trying to determine how the website was hacked is so that you can possibly prevent other websites from being hacked through the same vulnerability. We say possibly, because as a hack we recently traced back to a template from Template Monster, trying to work with the party responsible for the vulnerability may not get you anywhere.
Before we get to the vulnerability let’s do a quick walk through how we came to find out it had been exploited.
We were recently brought in to clean up hacked Joomla website where the person already dealing with it was removing malicious code from .htaccess files and the index.php files of the installed template, but it kept returning. In situation like that our first step is to review any available log files to see what they show about how the hacker is making the changes. In this case we found suspect requests being sent to a file in the /modules/ directory.
That file was highly obfuscated and due to that, it was fairly obvious that it was malicious without needing to deobfuscate it. What was more important at the moment was figuring out how it got on the website. In looking over the other files in the directory it was pretty clear that the whole directory it was in was not legitimate and had been created by installing an intentionally malicious extension. One of the items that pointed to that was the manifest file for the extension:
<?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module"><?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module"> <name>System</name> <author>Joomla</author> <creationDate>08 Jan 2010</creationDate> <copyright>Copyright (C) Profexor Liberty</copyright> <license>http://www.gnu.org/copyleft/gpl.html GNU/GPL</license> <authorEmail>profexor@hell.com</authorEmail> <authorUrl>http://profexor.hell/</authorUrl> <version>1.0.0</version> <description>ͮ崫��殨��鲯ﲲ橼/description> <files> <filename module="mod-favicon-image">mod-favicon-image.php</filename> <filename module="mod-favicon-image">mod-favicon-image.xml</filename> </files> <params description="this module has no parameteres" > </params> </install>
The installation of a malicious extension would most likely be done through a hacker’s access to a Joomla admin account. So we then reviewed the database table that stores user accounts and found there were numerous accounts that didn’t look legitimate. Only one of those was recorded as having been used to log in to the website recently.
For that account the email address was “demo@demoolink.org”. We then did a Google search on that address and found a thread on the Joomla Forum where someone had a template that was trying to create exactly the same user using a SQL statement. By exactly the same, the registration time specified for both was exactly the same, down to the second.
What didn’t make much sense to us is why a template would be trying to create a user. Considering that the template in use on the website we were cleaning was a commercial template from Template Monster, we first thought the explanation might be that it had been obtained from a warez website and the template was modified to allow website installing it to be exploited.
When we reviewed the installer file for the template though we found that there was no code to create the user. At that point we thought we had hit a dead end, but after doing some more investigating we found more evidence to connect the account to the template. After that we got access to another file that had come from Template Monster. This file was named fullpackage.zip and in addition to the template, it included a copy of Joomla and a sample data file created by Template Monster. When installing Joomla you have the option to install various sample data files, so when using this file to set up Joomla you could install the sample data provided by Template Monster
In that sample data file was the following SQL statement that created the user:
INSERT INTO `#__users` (`id`, `name`, `username`, `email`, `password`, `block`, `sendEmail`, `registerDate`, `lastvisitDate`, `activation`, `params`, `lastResetTime`, `resetCount`) VALUES
(846, 'Demo User', 'demo', 'demo@demoolink.org', 'ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE', 0, 0, '2012-10-17 10:56:12', '0000-00-00 00:00:00', '', '{"admin_style":"","admin_language":"","language":"","editor":"none","helpsite":"","timezone":""}', '0000-00-00 00:00:00', 0);
INSERT INTO `#__user_usergroup_map` (`user_id`, `group_id`) VALUES
(846, 8);
Any website that installed that sample data would have a Super User (the highest level user in Joomla) with the same username/password combo. Unless one of those was changed then someone that could figure out the password could log in to the websites where this sample data has been installed. At that point it looked to us that the user might have been installed across multiple Template Monster templates.
At that point we also contacted Template Monster informed them of the issue and suggested that they notify anyone that had purchased the impacted templates about the potential issue. We also suggested that they register the domain name demoolink.org seeing as that isn’t registered and someone could register and use it to gain access to the impacted website without even knowing the password (by resetting the password).
The first response we received was as follows:
Thank you for reaching the Technical Department of Template-Help.com!
Take our apologies for the delayed reply.
We are sorry for inconvenience caused by this. Usually clients change demo email address. We are happy that you managed to resolve it yourself.
Let us know if you are having any other issues with the template.
We responded trying to explain the issue wasn’t just related to the email address and we received the following response:
Take our apologies for the delayed reply.
demo@demoolink.org is added in admin panel as example of demo link, you can easily change it. Please specify with some screenshot what issue exactly you are having so we will be able to check it for you.
At this point we asked if there was a security department we would be transferred to we received the following response:
We appreciate the information you’ve provided. We will forward it to our development department. They will check it more carefully.
Thank you. Have a nice weekend.
While we waited for another response (none has come in two weeks) we wondered if the password might be something really easy to guess. It turned out that we didn’t need to guess it, as we entered the password hash, “ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE” in to Google and on got this page as one of the results. From that we then knew that the password was “demo123”. Not only is that not strong password, but with that in hand we found a page on the Template Monster website that told everyone what the username and password was for website using this sample data:
Right below that is a message that indicates that they were aware of there being a risk from providing this user account:
You can delete sample user though the Joomla administration panel in the “Users > Users Manager”. In case you are planning to use sample data we recommend you to change Sample Author user login and password.
We still don’t understand what the purpose of creating a sample Super User like this, since another one is created when installing Joomla.