Internet Security, Building Trust, Customer Service, and how to fail all three

Internet Security, Building Trust, Customer Service, and how to fail all three

This is a story of how a local web hosting company lost my business. Although I have all records, I won’t share their name here.

Why? Well..

  1. It is a local, Swiss company.
  2. The story is an educational piece on how not to do things. The company in question does not matter.
  3. Yes, if you are in Switzerland and looking at hosting companies… I will share this information with you.

Let’s get started.

I host several small sites with this company. So small, that shared hosting is all I need.
As a technical backend, I use wolfcms. A nice, small, and a bit hackish CMS that fits my purposes better than WordPress a lot of times.

One of the nice security features of WolfCMS is that is disables itself if it finds the configuration file writable.

The site will not be displayed, instead a small notice is the only thing you see.

Wolf CMS automatically disabled!
Wolf CMS has been disabled as a security precaution.
Reason: the configuration file was found to be writable.
The broadest rights Wolf CMS allows for config.php are: -rwxr-xr-x

This is as it should be. No one should be able to write to the config file but you.

Incident one

After the site had been up and running a few months, I get the above notice. I didn’t think much of it, instead shrugged, reset the permissions and life went on.

Incident Two

Just two days ago, Google analytics starts screaming at me:”Tracking code not found!”

“Odd”, I think to myself and go to check the site.

Lo and behold!

“Wolf CMS automatically disabled!…..”

The fun starts

I send a message to support, asking them why the permissions on the file have been changed and leave it as is, so they can check.

I get an email later that day stating:

  1. We ain’t done nuttin’.
  2. We went ahead and went into your .php files and removed that important_internet_security(tm) routine, all is well now.

What?

u wot m8?

I was fuming.

  • You don’t touch my files without my permission.
  • You don’t just change code.
  • You sure as hell don’t remove security checks.

Especially if the correct solution is to set the file permissions to the correct, restrictive state.

The fun goes on

As it was after hours when I read the mail, I had no choice but to wait until the next morning to call them.

The info I got was:
“Yes, we did change something. There is a ‘security script’ that changes unsafe permissions.”

Wait…

yeah

I informed him that their script was making things insecure, opening files up to abuse instead of closing them down.

He told me they’d look into it.

The solution?

1. We undid the changes we made
2. We changed the permissions on the config.php file

So far, so good, now everything works.

3. We removed your directories from the script so this won’t happen again.

Let me summarize

  • Your script opens up security holes on every client’s site
  • Your staff lied to me about nothing having changed (out of incompetence or malice, I don’t know).
  • Your IT support changes PHP files they have no right to touch.
  • They think removing security measures is a good idea.
  • Even the senior IT support sees no problem in a script that opens up file permissions.
  • The solution is to reduce security again.

The end

I got an email telling me that everything is fine now and they hope they can keep me as a customer.

Fat.Chance.