Security at our Web Hotel

After the security incident with the Iran hacker we looked more closely at our web hotel. Since we thought that we ourselves did not put anything at our web site that should be able to compromise it a likely reason for the defacing was in our opinion something at the web hotel. But there is more on that below!

The moderators at PowWeb discussion Forum seems to think I am accusing PowWeb for something, see here. I do not really believe I am doing that, but please comment in the Forum if you have thoughts about it! My intention is to work through this to try to avoid further attacks.

On this page:

Where was the Security Problem?

It is of course a difficult matter to find out where a security problem lies. We think it was on the web site, but our pc:s could have been compromised too as the moderators and staff at PowWeb suggested. Some trojans in our computers could have defaced our web site. So we searched for trojans but did not find anything. This of course does not make us sure - that is how it is with computers today. However we are using double firewalls of good reputation and modern anti-virus software with daily updates. We have a long backgrounds in computers and do not allow software we do not trust on our pc:s. We are computer software developers and normally notice what happens on our computers. We think there is a fair chance our pc:s are clean.

Some smaller Problems at our Web Hotel

Investigating the web hotel we saw some problems. Our web hotel does not for example use secure ftp so in theory someone could have grabbed our passwords. If this would have been the case then perhaps just our site got defaced by chance. Could be - but we looked for something more specific.

Most of our site was just html files except for a download area. We had earlier found that the default handling of perl files in the download area was to execute them. We were quite a bit surprised, but just changed the default handling so that the files were instead sent to the visitors web browser. That was what we wanted of course.

In our opinion this default handling of script files at our web hotel is a security problem. However that does not seem to be the common view by forum moderators and PowWeb staff. They instead told us to get educated. So we got nowhere with pointing out this. Of course it is not a big problem for us but we believe for many others. And maybe this is the standard setup on web hotels using Apache web server. We have been told so now and believe it. So we can not blame PowWeb for this, even if we still do not believe it is the best way to do it.

MySQL Security Problems?

I have not at all looked at MySQL security problems. However I just observed that the MySQL in my backup files changed from 4.1.9 to 4.1.15 on 2005-11-05. Version 4.1.9 was released 2005-01-11 (that is Jan). There are several releases in between (and I believe some security fixes in them) until version 4.1.15 was released 2005-10-13 (Oct).

The recommended version of MySQL is today 5.0.15 which was released on 2005-10-19 (that is in Oct). Upgrading to version 5 looks like it requires some planning. However I can not understand why 4.1.9 was used until November. Could that be where the attacher got in?

PHP Security Problems?

Our site uses a php script (WordPress). There are security problems with version 4.4.0 of php, see Version 4.4.1 released on 2005-10-31 included security fixes. The attach on our site were done shortly after.

After the defacing of my site (and several others at PowWeb, our web hotel) PowWeb announced that they are upgrading to php 4.4.1 (see PHP Upgrade Notice: The upgrading started the 4th of November and was finished the next day. (The Knowledgebase at PowWeb still today says php is version 4.4.0.)

The word "after" above is not mentioned as a critic or suggesting that there is a causal link. However it is worth noting that PowWeb announced the upgrade on 4th of November, ie for days after the release of php 4.4.1. Security problems are sometimes made public with the release of a new version of a software, but since php is open source I assume they were known a bit earlier. So I merely think it is a coincidence here. Waiting a few days before installing a new release might in these circumstances be good.

I do not know if the security holes in php where used for the attach, but it could have been. Anyway I have blocked all php execution on our site for the moment until I have time to reinstall WordPress. I will wait for the php upgrade at PowWeb before trying to reinstall WordPress.

Utilities used at our Web Site

Even if most of our files were plain (x)html or files for download we had installed two utilities. Both were supplied from the web hotel as standard utilities so we expected them to be ok. That was unfortunately not so wise.

We had made a quick install of WordPress - supplied by our web hotel so we did not know very much about it. Searching the Internet however we found that there seemed to be security problems with the version of WordPress we got from our web hotel.

This does not mean that it was known by the time we installed it and we do not blame our web hotel for this. However we do think there are some problems with this anyway.

We are not sure, but it seems likely that the hacker got in through WordPress. If we find out something else we will tell you. Or if the police find something else, because we told them. (But we of course do not believe they have time to look at this. It is more for the record. And should something more happen then they might be interested.)

Who is Responsible? - Is that the Question?

We installed two common utilities. Even though we have a long professional experience with computers we missed that the web hotel thought that everything about the utilities were our responsibility. We believed they did something more than just supplied links to the utilities. Maybe they did but they did not take any responsibility for the utilities. The moderators in the discussion forums for the web hotel and the staff made that clear to us. And much to our surprise many normal users seemed to think so to. We think differently.

We do agree that the web hotel can not take a total responsibility for the utilities. That would be impossible. However important things can be made in quite simple ways we believe. It is more a matter of attitude than a matter of very hard problems to solve.

We also agree with the moderators and staff we could have checked for updates. But we did not. And that is the point. We did not. No matter who is responsible. We did not and many others will not. The question is what can be done then to raise security?

Apache Web Server is not using mod_security

WordPress and several others recommend that the Apache web server should use mod_security. This is not done at PowWeb. One of the possible security problems with WordPress 1.5.1 (which we were using) is stopped by mod_security.

However the Apache server version otherwise seems ok (1.3.33 a security update is installed and the new version 2.0 server is not yet installed, 2.1 will probably be more stable - but that is a guess only).


So far I do not know the actual security problem that made the attach possible. The most likely problems are with WordPress or with PHP.

MySQL version was however rather old too. We are also using WebStats which is a perl script. It seems to me unlikely that this is a problem since both perl and this script are more mature. But I do not know yet.

I do not know, but I wonder about the security fixes. Where there problems with MySQL or not? And the attitude of the Forum moderators is too often to blame the customers. Could that really be a good long term plan?

So far the incident, now some proactive comments:

Our Suggestions for a Safer Web Hotel

After this incident and studying how things are managed here at our web hotel we have some rather simple suggestions that we think should make a web hotel much safer for its inhabitants:

If the web hotel supplies a simple installation for a utility it should also supply a simple way of upgrading the utility.
Many web hotels inhabitant may not have very much computer skill or the time or will to aquire it. This is fine, the web should be for those too of course. If the web hotel wants these kind of inhabitants then it normally has simple installation of common utilities. That is fine. However if these inhabitants are left alone after the installation then their web sites can be of big value to hackers. We do not want that, do we?

Just do not supply more simple utility installations than you can afford to have simple upgrades for on your web hotel. Or at least work for this. This will give a good reputation. Sooner or later some web hotel will do this. Why not be first?

Do not install utilities locally if it can be avoided.
This is just a simple way to solve the problem above. If a utility is well written there is no need to install it locally for each hosted web site. Point to a common directory for the executables and store the individual settings locally in each specific web site. Then take responsibility for upgrading the tool. Tell the users that you will upgrade the tool now and then. You simply have to because of security problems. Do not upgrade simply because of new versions. Make that a "new utility" instead.
Do not allow anything to be executed by default.
Why should anything be executable by default? A novice user will be fooled by this. So it is a security threat. More experienced user will learn how to allow execution. And even experienced users may be fooled because you do not notice if something you just put on your web site for downloading instead is executed until you try to download it. You seldom try to download a file you just uploaded.
Install all Security Fixes for Common Software
We were surprised to find that php and MySQL for example was not updated. This means security problems for all web sites hosted. Upgrades that includes security fixes must of course be installed as soon as possible. Maybe it is feasible to wait a few days for new problems to surface, but hardly more in our opinion. If the web hotel thinks and acts differently it should at least clarify its policy on those matters so the user can decide for himself if the web hotel is a good alternative. Otherwise you may not know that until it is too late.
Listen to Your Customers
I have been a bit surprised that our web hotel in my opinion sometimes do not listen carefully to their customers. It might be a problem with recognizing what is worth listening to and what is not, I do not know.

Our Suggestions to the Customer

If you are skilled at computers at the security levels discussed here then you might just learn from our mistake. You are welcome!

If you are not so skilled then maybe it is a good strategy to look for a web hotel following our suggestions above. Just ask for it. Unfortunately we can not tell you where your best bet will be yet. If you find out please tell us. We will surely put it here!

Author and copyright © 2005:
This page is best viewed with Firefox. But if you have read this far you of course know that ;-)