September 21, 2007

TLS-Cookie can track you

Filed under: browser,firefox,privacy — admin @ 11:48 am

It’s always interesting how some features which are nice and really used, can become evil for you if your configuration is not very strict:

Alexander Klink found out that you can track people over websites by setting them a so called TLS-cookie. Which is nothing else than a server is setting you a client certificate in your Web browser, which is presented to every Web server without notifications by default settings within your Firefox. Read more on Heise.de in German.

So what to do? Just disable the automatic sending of a certificate under Preferences -> Advanced -> by switching from “Select one automatically” to “Ask me every time” in the Certificates section. With this option you will always be asked if a server is requesting a certificate if you want to present any. Then you can decide if you want to or not…

September 13, 2007

Social networking privacy

Filed under: privacy,social networks,society — admin @ 10:24 pm

BlogSec, a very nice blog about blogs and security, have published some interesting articles about social networking platforms and (their) privacy:

and they want to continue their article series about this topic, so other interesting articles might get to your attention.

It is always suprising how today people are throwing away their privacy that fast and what people make public about themself. Hopefully some people will change their mind about privacy and all after they read that. Will they? Maybe there’s something like hope out there… 😛

September 5, 2007

About third party packages in hosted CMS’s

Filed under: joomla,webapplications — admin @ 2:26 pm

Recently we had an incident on one of our PHP-Hosting servers and everyone could learn once again a bit more about security and how important it is to track all the software-versions installed on a server. However first we want to post some facts:

  1. One Joomla website defaced
  2. No other hosted websites affected, nor spied
  3. Defacement could have been avoided
  4. Nothing more happened, but everyone has to learn something

Turkish script kiddies defaced a little Joomla website hosted by us and called them self the bloodiest terror group :P. Unfortunately none of our administrators was near a computer and the Joomla users simply replaced the defaced index.php with an original one. However the defacement happened again and again and it was obvious that this is very nasty. Finally when someone of us could have a look at the site, we saw that we have done a mistake from our side which made the Joomla installation completely writable by the web server. This is very bad from our side, as we try to avoid such setups in normal and try to restrict write permission per default to a minimum. However nobody is perfect, so such things might happen and it is important that everyone using our systems is also watching on our fingers. So we fixed these settings and thought that it is done with that.

Unfortunately one week later the defacement happened again and this time not the index.php was replaces by their ridiculous statement: the whole configuration.php (Joomla configuration file) was overwritten. But why was it still writable? Well CMS’s are normally chosen because they are nice and simple to use. And therefore their configurations files have often to be writable by the web server. This is a severe security fact, however most user want this as they don’t want to upload the configuration every time by ftp. This was why we had enabled that overwriting of the configuration.php is possible.

So we restored the configuration.php (as it was completely overwritten with the defacement) changed the MySQL password (as this is normally in the configuration file and was accessible therefore by the script kiddies, however we don’t think they were interested in that) and locked from now on for security reasons every configuration.php on our host to be overwritten by the web server. Just a little side note on that: Normally when we setup a new Joomla-Site, we told the people that currently the configuration.php is writable and for security reasons they should tell us when they finished with configuration don’t need to change it anymore, so we can lock it. However less than 10 percents of the Joomla users told us in the past to lock the configuration.php. :-/ So now every configuration.php is locked per default and we learned that we have to insist more on this issue.

After restoring the page we could then examine how the page was defaced. While searching for actual possibilities to deface Joomla websites, we found a posting which lead us to some issues with a third-party gallery module. So we found out that there was exploit publicly posted in the mid of July and a fix for this exploit 1 day later (FOSS rules!). So we examined more about this exploit and found out that exactly this was used to upload some php-script which contained some kind of a web-shell. A so called swiss-army-web-knife in php. This shell then could be used to step through all folders of the installation and edit any files which were writable by the web server (index.php and configuration.php). However due to our open_basedir restrictions they could not access any other folders on our server than the application’s one. Yes we know that there are possibilities for advanced white and black hats to walk around this restriction however for these script kiddies it did its job. 🙂

They uploaded as well other php scripts as well some Perl scripts which could have been used to run some irc-bots and which could have been used to attack as well other servers from our server. However they were completely unusable on our servers, as our (we hope) secure setup avoided them to be executed.

So finally we removed all the uploaded scripts, patched the third party module with the update available since a month, informed the Joomla-users about our examination and since then their site wasn’t defaced anymore. So we all could learn once again some stuff about security:

  1. Security can not be delegated, everyone is responsible for it
  2. Nobody is perfect, everyone can make mistakes which lead to security issues
  3. Tracking the version of your current installed software, modules etc. is important! If the update would have been installed the site would have never got defaced
  4. Hosters can (but this is already very hard and a lot to do) only watch the versions of the main application, but they can not automatically know which third party modules you install nor they can track the versions. The best thing is that you look on yourself that your application is uptodate
  5. A safe setup can avoid of much more damage. (Access all the other setups etc.)
  6. Security gives a lot to do!

Therefor we want once again to remind you to:

  1. not delegate security to us…
  2. track the versions of your installed software…
  3. be aware of security issues, harden your application and work with us together to make our hosting a more secure place

Thanks!

Proudly powered by wordpress 4.7.5 - Theme by neuro