So I received a call from a past client yesterday. Apparently their web site had been hacked and the simple text “hacked by Hmei7” replaced their home page. This was a shock to them, but it was even more of a shock to their customers. Luckily, for my client, and myself, this is an easy fix. Let’s get down to business to get your site back up. More thoughts after the fix.
hacked by Hmei7
Seven files are potentially affected by this attack:
- /images/stories/susu.php (this file name may vary)
Not all files will be affected on every site and there may be more files affected than the seven in this list. Only those files with write permission will be changed by the hacker’s script.
To fix the hack and restore your web site:
- Remove the files susu.php and x.txt.
- Check the configuration.php and index.php files to see if they have been changed by the hacker.
- If configuration.php or index.php has been changed, delete them.
- If index.htm or index.html exist, delete them.
- If your configuration.php file was changed by the hacker, restore the file from a backup or from scratch if needed.
- If your index.php file was changed, restore the file from a backup.
If you don’t have a backup of your configuration.php file, here is a sample file. Create the configuration.php file and put this text into the file. The configuration.php file should be located in the root directory of your site.
Configure these vars to get your site back up and running:
- $secret – change to a random string of uppercase and lowercase letters and numbers.
- $log_path – path to log directory.
- $tmp_path – path to tmp directory
- $user – database username.
- $db – database name.
- $password – database password.
Configuring these six vars is enough to get the the site working. The rest of the configuration.php file can be filled out manually, or it can be configured more easily through the admin area. If you want to use the admin area, be sure to chmod 777 the configuration.php file. It might be a good idea to chmod 644 the configuration.php file once finished configuring the site. This will prevent any unwanted changes in the future.
This should get your web site back into operation. Please continue reading as there is important information for completely removing any lingering files from the hacker and preventing a successful attack in the future.
Check for additional hacker files
It is possible that the hacker changed or created other files on the server that were not mentioned in this article. It would be a good idea to search the web site files for any other changed files as a result of the attack.
An FTP browser or an SSH shell can be used to find any files that were recently changed. If you have SSH access, the following command can help find any files that have been changed:
find . -mtime -2 -type f
Run this command in the root directory of your site. This will find any files that have been changed in the last 2 days. If you only have FTP access, an FTP browser can be used to browse the files and check the date the web site’s files and folders were last changed. Most files in a web site are not changed very often. Look for any files that have been recently changed, or changed within the time frame of the attack.
Since the web site has been compromised, all users of the hacked site should change their passwords immediately. I highly doubt Hmei7 stole passwords from the web sites that were hacked in this manner, or even yet would return to a previously hacked site with that information (even more so if the site is small). In any case, since the site was hacked, the passwords should be changed as a precaution.
Content of the hacker files
Analysis and prevention
Thank you to OrChavex for finding the log entries of this attack in his web server log. These are the attack log entries from my client’s server:
Thank you to Drew for finding more log entries of this attack. These are the log entries of the attacker trying to access his script again:
There are six things to note about this attempted script access (the second set of logs):
- These log entries show that he attempted to access his script two and three days after the original attack. This is unexpected of him to access his script so long after the original attack. On the other hand, Hmei7 probably would not have expected a victim to analyze his attack this thoroughly.
- The first file name attempted to be accessed is susu.php. This could mean that he is keeping a record of his attacks, which would allow him to return to previously hacked servers and access them if those servers have not been cleaned. If this is the case, we could ask the question whether his subsequent file access attempts are due to the hacker being unable to access the first previously known name (e.g. he was unable to access susu.php, the file name he knew he had previously used, but can’t access the file so he tries other names). This could be a coincidence.
- He uses the word “indonesia” in the URL he is accessing. After looking at the script, it is clear that using the indonesia query with the script would show an upload form. This would allow the hacker to upload files to the server, as long as the original script is on the server.
- Several of the names of the PHP files he is trying to access coincide with hacker scripts (c99, r57, 0day). It’s unclear why he would try to access these additional file names. He could have used these names for some of his scripts, or he could be fishing for possible available scripts.
- Drew and I both have similar IP addresses in our scripts. More on this later.
- Every attempt returns an HTTP 404 error, which means that the file he’s trying to access is not on the server. This is expected since I removed the hacker’s files the same day of the attack.
These log entries show that the attacker uses a flaw in the Image Manager plugin (imgmanager) from the JCE component (com_jce) to upload his script. His script is first uploaded with the name susu.gif as imgmanager will not allow a PHP file to be uploaded. Also notice that he gets around the MIME security check by having “GIF89;” at the beginning of the file. Once the script is uploaded, he changes the name of the file to susu.php so he can run the script. I took a closer look at the script to determine exactly what happens when he runs the script. He runs the script “/images/stories/susu.php?yaiyalah” which does his dirty work of creating x.txt in the tmp and images directories, changing the configuration.php and index.php files, and creating the index.htm and index.html files. If the files do not have write permission they will not be changed. Likewise, if a directory does not have write permission, a new file will not be created. These changes make it so that the site will only display “hacked by Hmei7” on every page.
As you can see from my log entries and the log entries of OrChavex and Drew in the comments below, the IP addresses of the attacker were 184.108.40.206/220.127.116.11 for the first access and 18.104.22.168/22.214.171.124 for the second access. Both IP addresses from the first access start with 114.79, and after some research found that they were both from the ISP Smartfren. Smartfren is an Indonesian wireless telecommunications company that provides cell phone and wireless internet services. I was surprised to find that both IP addresses were so similar. I would have thought that Hmei7 would use a proxy of some sort to mask his true IP. Even with this information there is little hope of prosecution and stopping him since he is in Indonesia. Since he is using Smartfren, he could be using his cell phone to provide internet to his computer, or a wireless modem/router that the company offers.
Similarly, both IP addresses from the second access start with 95. This is a wider IP range, but both of the 95. IP addresses are from the ISP Turk Telecom. This raises the question of what the link is between Indonesia and Turkey, if there is a link at all. It is doubtful that he physically travels to Turkey, since he is from Indonesia and most likely lives there. This also raises the questions why and how he uses an IP address in Turkey. He could be using a proxy based in Turkey, or he could have friends, family, or contacts in Turkey. If he is has contacts in Turkey, those contacts could have a proxy set up for him, or they could be helping him with his attacks.
Now that we know what exploit he is using, how his script takes control of the web site being attacked, and we know at least two of the IP address he used to attack, we can help safeguard future attacks. He attacks other web site scripts such as WordPress also, and he could be using a different exploit other than the JCE/imgmanager exploit for those sites. Also, his script could easily be manipulated to take advantage of a different exploit if this exploit were no longer available.
There are four things we can do to help prevent a future attack:
- Update to the latest JCE version or remove the old version that includes the exploit. The latest JCE version no longer includes this exploit (version 2.3.1 as of this writing).
- Update all extensions to the latest version.
- Only give write permission to those directories and files that are necessary for the site to function properly. Do not give write permission to the configuration.php file.
- Block the IP addresses in the 126.96.36.199 range and 188.8.131.52 range. I checked 184.108.40.206 and 220.127.116.11 and both are used by companies other than Smartfren. Smartfren most likely only uses 18.104.22.168 addresses. Checking 22.214.171.124 and 126.96.36.199 shows that they are both used by Turk Telecom. This means that Turk Telecom has a huge number of IP addresses in the 95. range. There are others in the 95. range other than Turk Telecom, but most if not all of them are in Turkey. It is up to you whether or not to block these IP addresses.If you would like to block these IP addresses, add this code to your httpd.conf file:1234
Deny from 114.79
Deny from 95
This will block all IP addresses from Smartfren and Turk Telecom.
Apache must be restarted for this to take affect. To restart Apache:
service httpd restart
There are more steps that can be taken to secure a web site and server, but that will have to be for another article.
Although Hmei7 could cause MUCH more damage if he wanted, he still has done considerable damage by taking complete web sites offline. Especially for those smaller web site owners that must hire someone to restore their site. The owners of these sites also lose functionality of their site during the time it was down. If the site is used to make money this down time could cost money, as everyone knows, time is money. Also taking into consideration the sheer number of sites he has defaced (he has defaced hundreds of thousands), he has caused an extremely high amount of damage. Hopefully this article will help those people, and anyone else, to get their site back online.
Learning from this experience, it would be a good practice to only allow write permissions to the files and directories that are absolutely necessary (e.g. the /tmp directory requires write permission for a Joomla site to function properly).
Be sure to make full backups of your web site files and databases in case of any potential catastrophe! It’s always better to be safe than sorry.
Thank you Gosa, Miguel, and OrChavex for their helpful comments and contributions.