After a recent scare with WordPress 2.1.1, I thought it would be a good idea to list out some of the threats to owning a web server…namely mine. Before I continue I want to make it clear that I am not giving permission to perform this on this server or any server for that matter. This is some useful information you should be aware of if you are hosting or paying some entity to host your web service. You should perform this on your own server regularly to see if you are vulnerable to attack.

Server Level
Performing a banner grab of the this domain reveals the following:

curl -I www.securitytechscience.com

HTTP/1.1 200 OK
Date: Fri, 16 Mar 2007 23:54:28 GMT
Server: Apache/1.3.36 (Unix) mod_gzip/1.3.26.1a mod_jk/1.2.14 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.27 OpenSSL/0.9.7a PHP-CGI/0.1b
X-Powered-By: PHP/5.0.5
Content-Type: text/html

Taking a quick look at the SecurityFocus vulnerabilities page for Apache 1.3.36, I found 2 vulnerabilities that are not applicable to this server. Firstly, it is not running mod_rewrite and I know my costs are to low for them to be running Windows.

Lesson learned:

1. Always stay up-to-date with the latest version of you server and perform regular patching.
2. Do not run any unnecessary services or unnecessary modules within that service.

Application Level Type 1 – Underlying Supporting Code

The above banner also reveals that PHP 5.0.5 is installed. Once again, taking a look at SecurityFocus vulnerabilities page for PHP 5.0.5 this time reveals 30 vulnerabilities…mmm. Apart from being more than a little pissed with my hosting company, two things come to mind right now. One, whether any of these vulnerabilities are exploitable remotely and two, which one’s are local vulnerabilities.

Successful remote exploitation obviously means the server would be turned into a phishing or warez site within a matter of seconds. duh!

But local exploitation means that I can own all the content on the server including the other websites that share their hosting with me and vice versa they could also own me. My site has no sensitive or confidential information so if the server gets 0wned then I lose only reputation if they deface my site. But what if I were malicious and were to own my neighbours sites and they perform e-commerce functionality or store confidential information? Totally different story.

Lesson learned:

1. Always stay up-to-date with the latest version of your application.
2. Do not host your site in a shared environment if it contains information that is either confidential or sensitive.
3. If you pay some entity to host your site be well aware they may not be security conscious. Check before you buy as you may not be lucky enough to share your domain on the same server as the security conscious

Note: An email has already been sent to my provider about the PHP issue before I finished writing this blog.

Application Level Type 2 – Add-on Applications

Recently I updated my version of Word Press just at the wrong time. The Word Press dev server was hacked recently and additional code was added to version 2.1.1 which allowed remote PHP code execution. You can read more here. Anyway, I have updated to version 2.1.2 and deleted all my files and updated all the files from my local server that is not Internet accessible.

Lesson learned:

1. Keeping up-to-date doesn’t mean you are 100% safe/secure either. There is no such thing as 100% secure.
2. Always store multiple backups of your data which are recoverable in case of data loss or data corruption.

Application Level Type 3 – In-house Code

There are a number of pages that rely on PHP. I won’t specify which one’s but it is pretty apparent that if parameters are being passed around there needs to be something other than HTML moving these parameters around. My main concern here always comes down to “Injection” attacks. I don’t store any data so SQL injection is not an issue. I don’t use XML or authentication so LDAP and XML injection is also not an issue. But I do take my data from an untrusted source (securityfocus) and redisplay it back to the end client browsing my site. It is not far fetched that if someone were to own the security focus site and inject malicious code (JavaScript, VBScript) into their RSS feeds then the end user and possibly the server could be open to attack. That is, the attacker injects code into the RSS feed. I take the RSS feed in a nightly batch and when someone browsers to my site I display this information to them. Luckily for all involved (except Security Focus) I perform both input and output filtering on all data involved. If the code I wrote doesn’t like the look of the data then it gets dropped.

Lesson learned:

1. Always validate input data from an untrusted source
2. Always validate output data being redisplayed to the end user

Conclusion

What I find most interesting here is that the www.securitytechnologyscience.com domain is only one site with mostly static information, a small amount of dynamic information and a blog. The avenues of attack are not small but we are only talking about a small site. I think it is worth thinking about this and comparing it to a site that has an authentication modules, must enforce authorisation on components, interacts with other services such as a database back-end or web services. Let’s also mix in a little AJAX to top it off and we end up with something that could be easily exploited if the appropriate controls are not put in place during development and managed throughout the system life cycle.