Saiweb

Bad TMNT reference I know but with a reboot coming what do you expect realy?

Right so you have hidden your versions via The Hooded Apache so what now?

Well no matter what you do if your url’s contain .php / .asp / .cfm (Frankly if you are using coldfusion you deserve what you get … just saying …)

You are disclosing what your webapp is using as it’s server side language, now to be clear this hiding is only going to be effective if you are using a bespoke webapp, and not say Joomla / WordPress as they are easily identifiable via other means (for another post) …

mod_rewrite

Learn this, I mean seriously not only can it help cloak your server side language but you can do so using SEO urls.

BUT be careful if you think you’re being cleaver by having mod_rewrite change the extension alone …

it will be easy to enumerate the back end language this way … the first 404 that an attacker gets when enumerating your file names will reveal this rule i.e.

“The file /asfasdgasdg.php was not found on this server” … yeh …

Change the extension entirely

Security through obscurity? you bet your ass, just add your new extension onto your AddType declaration, because you are already avoiding the dual extension vulnerability right?

how about .wtf

Now just name your files .wtf instead of .php

So your using subversion good for you! you can use subversion as part of PCI 11.5 (iirc) to enforce file integrity assuming of course you have your subversion deploy setup securely just one tiny problem …

Seemingly innocent right? oh how wrong you are …

1. http://domain.com we know the version control server location, we can attack that later
2. http:// is not an encrypted protocol, easy to sniff for if you get access to the server / company lan
3. joe.blogs we have a known username we can attempt to access using dictionary / brute force / social engineering
4. http:// the server could be vulnerable to CVE-2011-1921
5. we know that config.php exists we can target that later for other crednetials

So assuming a worst case scenario,

1. Webapp is compromised and we managed to deploy a remote shell
2. Sniffing for http:// hiding silently in the background we find a site update / commit, and snag joe.blogs user credentials
3. Exploiting CVE-2011-1921 we enumerate all projects on the svn server (If we even have to … joe.blogs could have access to everything anyway …)
4. Inject backdoors into all projects committing changes as joe.blogs
5. Wait for co de to be deployed to production …
6. And now you have backdoors into multiple projects

You can prevent this by …

Or using mod_security

Ensure you use an ENCRYPTED protocol for your version control https:// / ssh+svn:// for example with subversion.

Tweet

Go ahead and run

You will get

As an attacker looking to hit a web app, one of the first things you’re going to want to look into is what version of web server is running, in this case you can see this blog in fact runs apache … but there is not much else to go on here is there.

That’s intentional, and by manual configuration changes I have put in place, this is not the case of a default LAMP install, take for instance, this snippet from another website,

This already has given me a wealth of information to go on and begin prepping an attack, I now know the site is running php version 5.2.14 Apache version 2.2.16 and that the underlying OS is Debian.

See the dilemma? your default roll outs are just declaring their running versions to anyone willing to listen, so lets make it a little more stealthy.

First and foremost if you are using php, edit your php.ini and set the following:

Now head into your httpd.conf and set the following

and

With these 3 simple steps all the headers will now return is Server: Apache this is the first step to shielding your app, I’ll be covering further steps as time allows.

Tweet

Welcome to part one of the ‘zen of secured shared hosting’ series.

In this part I will be covering the concepts of secured shared hosting, and why you as a shared hosting provider should be taking steps to ensure this is how you deploy your hosting environments.

Let’s first take a typical L.A.M.P setup:

PHP Compiled from source as apache module.
mySQL installed from RPM or update package (yum / up2date).
HTTPD installed as RPM or update package (yum / up2date).

Please note at the time of writing if you yum / apt-get / up2date install your PHP package you will have varying results when attempting to compile and install suPHP, as such grab the source code from php.net, and follow this series.

As a shared hosting provider lets say you have 5 clients all hosted from the one server, each client using vsftpd is chrooted() into their home directory, and their ssh access disabled, supposedly secure enough.

Unfortunatly not so, due to the L.A.M.P configuration the ‘apache’ user needs a minimum of read and execute permissions over all the PHP files on the system, why is this a problem?

This is a problem largely due to human nature of the client, your ‘joe bloggs’ client doesn’t care about the technical aspects of web hosting or websites, they just want an easy pretty interface to get their corner of the internet online, downloading something like drupal or joomla.

Now this isn’t a dig at open source CMS, this is an insight into human nature, look at the changelog for any open CMS and you will see ‘security fixes’, unfortunatly all ‘joe bloggs’ cares about is that their website is working, and this is wher things take a turn for the worse.

Joe Bloggs never updates his open CMS platform, meaning any vulnerabilities patched in subsequent releases are still exploitable on his website, worst case scenario that this is an XSSI (Cross Server Script Includes) vulnerbility.

An attacker finds this website and idetifies the security hole, using XSSI to install a PHP interactive shell, giving the attacker SSH like access to the hosting environment, most people at this point think so the attacker has compromise one site … so what we can restore that site from backups and it’s only one site that’s affected, the other 4 users either do not use open CMS or are up to date with all the security patches.

Well that’s where you would be wrong, with the hosting setup outlined above the SSH like PHP shell is now running as the apache user, meaning the attacker can go anywhere and read anything apache can, and with the hosting setup oulined above that mean reading things like datbase connection files, suddenly all the clients on the hosting environment have their websites compromised as the attacker gains mySQL access and starts changing content on thewebsites, despite the fact that the other 4 sites themselves were never exploited.

One clients error just became a cascading exploit on your hosting platform, now make that a more realistic platform say 30 clients on the box, some are online shops, the issue just became a whole lot bigger there is lost revenue due to downtime of the shop sites, and worse still the attacker now has access to any customer details those shops were storing! but it’s not Joe Bloggs that’s accountable it’s YOU as the hosting provider, you can take steps to prevent one exploited site becoming 30, and this web series will tell you host to do it.

coming in part 2:

an introduction to suPHP
compiling php as a cgi binary, and why you need to do so

Tweet

As the old adage goes, any security measure is pretty pointless if the attacker has physical access to the machine.

But surely disk encryption should at least slow this down … right?

Well apparently not, as when booted systems like Bitlocker and Filevault store the key in ram, all the attacker need do, is cool the ram stick with an inverted air duster can, take out the DIMM and place it into another machine where the key can be read from.

Scary stuff, there’s even some information as to what data still remains in the RAM once the machine is powered off …

Check the video at this link out:

http://citp.princeton.edu/memory/

[via: engadget ]Tweet