
Pro-security? Stay away from these hosters - dolfje
https://blog.patrolserver.com/2015/07/28/the-infamy-list-hosters-edition/
======
kijin
Without knowing the OS and patch version number, whether or not a company uses
PHP 5.3 is completely irrelevant to how secure they are.

Ubuntu 12.04 LTS ships with PHP 5.3.10, and has been backporting security
fixes since the PHP project EOL'd it. This will continue until April 2017.

RHEL 6 and CentOS 6 both support PHP 5.3.3, and will continue to do so for the
remainder of their impressively long support cycle, until November 2020.

There's been a lot of FUD about outdated PHP versions going around in some
circles, and I'm frankly very annoyed by it. Free and open-source software
aren't like Windows XP. The original developer(s) announced EOL, so what? I'm
under no obligation to get my PHP interpreter from the original developer(s),
I get it from Red Hat and/or Canonical.

The whole point of having a stable Linux distribution is so that you can stop
worrying about upstream EOL issues. Heck, RHEL/CentOS have even been
backporting security fixes for PHP 5.1.6, not that any sane person would want
to use that dinosaur of a version.

Some of the hosts on that list, however, are indeed using dangerously outdated
PHP versions. Feel free to name and shame them.

~~~
dolfje
To clarify, when we say outdated PHP 5.3, we only mean the standalone PHP
version. When an ubuntu version was detected, it was correctly marked as
maintained. So all these hosters use 5.3 without package managers.

~~~
dspillett
How are you scanning to detect the OS version though? And verifying if PHP
came from a package or a separate compile? Some hosts deliberately fuzz
external indications of the base OS so you'd need an account to log into to
properly check this, and they could have a compile from source version of PHP
due to install procedures that date back before major updates to the base OS
(and were updated "the wrong way"). Your effort is laudable (I'm all for
naming and shaming the insecure) but you are open to false positives which
could cause you legal issues.

~~~
dolfje
By using multiple versions of multiple software, you can determine the false
positives. There are little servers that deliberately fuzz external in a
consistent way of all software found. Mostly they only do PHP or Apache, but
forget OpenSSH. If there is a hoster doing it in consistent way and ended on
our shame list. Please stand up, you deserve a full new blog post about how it
should be done.

------
daenney
I wonder if anyone bothered to contact the hosters? If not I think this is in
poor taste. As far as I'm concerned when you see issues like this the right
thing to do is to reach out to said companies, detail the problem you found
and give them some time to fix it before setting up a wall of shame.

Besides that, being up to date with software patches is hardly the only
measurement of good security. The fact that some hosters don't even provide
2FA for your account would have me equally if not more worried, as would their
practices regarding storing data and credentials.

~~~
dolfje
It is definitely not the only measure. There are many more aspects of
security. But a hacker only needs to find one gap. So the security is not the
average of all aspects, but the minimum. So finding hosters that fail one
aspect (outdated software) are already problematic.

That is the reason why security is hard ;)

~~~
mediacatch
Mediacatch here. We really do appreciate it. I'm surprised we made it to the
list of 100 hosters since we're very(extremely) small compared to the others.

As to the issues:

\- Our apache was 2.2.29, it is recommended for 2.2.31 due to the 1 CVE. The
re-compile is running now. Edit: It's now done.

\- We use a piece of software called cloudlinux, and it features the ability
to switch PHP versions. We just moved this server a few months ago and it had
PHP 5.2 as the default. Admittingly, this was an oversight and I've just
switched it to PHP 5.3.29. This PHP version does have security backports for
CentOS/RHEL 6. This is the latest version that we can use due to our billing
system. We use WHMCS, so we need to go to V6 instead of our current V5. This
is a large undertaking since we need to re-theme a complex theme.

\- Openssl/OpenSSH is now up to date according to the CentOS repo, which has
backported patches for exploits mentioned. I'm actually not sure why this
wasn't auto-updated since we had that enabled like our other servers. We don't
have the experimental J-PAKE enabled, so the 2 warning vulnerabilities that
your system cited are not relevant.

I've also run this your tool again on our site to confirm the openssl/openssh
were fixed.

You didn't provide a contact on your blog post, would you be able to please
downgrade/remove us?

Thank you.

~~~
dolfje
Glad to see you fixed the issues, I absolutely love it that you acted to fast.
You have been removed from the list.

------
noja
> sometimes see that their front page has outdated PHP, as in 5.3 old. EOL for
> 11 months. That really bothers me. How can I rely on their security when
> their frontpage isn’t even up-to-date.

Errr... are you determining that the software is vulnerable through the
version number alone? That won't work, some vendors backport security patches.

~~~
qewrffewqwfqew
A version that has been end-of-lifed and is superseded by three minor releases
is a pretty strong indication. The amount of work involved in backporting
patches is likely to be significantly more than migrating to a supported
version which receives timely patches.

~~~
noja
No it's not a strong indication at all. Red Hat does the backporting work for
you. You choose that platform if you want your software you spent man-decades
writing to keep working for 10-13 years.

~~~
dolfje
It is a strong indication, because we are talking about non-packaged versions.
PHP 5.3 is still maintained in Ubuntu, so those hosters aren't on the blame
list. Only if PHP 5.3 / 5.2 / 5.1 is used without package manager.

~~~
noja
It might be a strong enough indication to investigate further, but it is not a
strong enough indication to out a company. You need to actively test the
vulnerability to be sure (or relabel your page with a heavy disclaimer).

------
helb
"Error establishing a database connection", googlecache here:
[http://webcache.googleusercontent.com/search?q=cache%3Ablog....](http://webcache.googleusercontent.com/search?q=cache%3Ablog.patrolserver.com%2F2015%2F07%2F28%2Fthe-
infamy-list-hosters-
edition%2F&oq=cache%3Ablog.patrolserver.com%2F2015%2F07%2F28%2Fthe-infamy-
list-hosters-edition%2F)

~~~
dolfje
The HackerNews effect, was unfortunately down for 3 min. Should be okay now.
Apparently login into Wordpress was a query to much.

------
omgtehlion
Pro-security? Stay away from shared hosting.

VPS/VDS are cheap nowadays

~~~
dogma1138
Depends on whether you consider "privacy" as paramount in your security, in
that case VPS's aint that great either.

Shared hosting can be more secure than most self configured dedicated hosting
options, simply because the hosting providers "cares" about the security in
the former while outsourcing the risk to you for the most part in the latter.

If say we look at how many times a shared hosting provider was compromised
(excluding stolen credentials for individual accounts since it doesn't matter
if they steal your credentials for the shared control panel or for the SSH on
your dedicated box) i think the picture will be quite different than what you
imagine.

Big hosting providers rarely get actually compromised, on the other hand self
configured dedicated hosting boxes get owned everyday by the truck load, from
configuration issues to missing updates to unhardened environments they tend
to be much more vulnerable.

Shared hosting providers need and do lockdown everything since their
adversaries are not only external attackers but also customers with high
degree of access. This doesn't just reduces the likelihood of a security issue
but also reduces the impact of such issues for example SQL injection on a
shared hosting will yield pretty much nothing, yes they'll be able to dump the
application tables but that's it, forget about code/command execution that DB
is locked down harder than one would think it's possible same thing go for
other issues, local file inclusion? well GL, directory traversal, breaking out
of the chroot, try agin...

Now this ofc doesn't mean that some one can't configure their own box to be
just as secure for but for all effective purposes if you are running a small
operation like a personal site or a site for you own small business the
chances of you being able to effectively managing security at the same level
of a solid hosting provider is quite slim.

