Donate to Camp Laurel and Room to Read
Tomorrow we’ll be changing the charities at our Charity Area, so it’s your last chance to donate to Camp Laurel and/or Room to Read and have your donation matched by us!
So far we’ve received 18 donations for $591.21 for Camp Laurel and 24 donations for $990.73 for Room to Read, not too shabby, but we can do better!
.
July 1st, 2007 at 1:54 pm
LOL! XD
July 1st, 2007 at 1:54 pm
LOL! XD
July 1st, 2007 at 1:56 pm
jaja, está bien… xD
July 1st, 2007 at 1:56 pm
SOY EL PRIMERO!!! xDD
July 1st, 2007 at 1:58 pm
Yo he donado $ 25 :o)
July 2nd, 2007 at 3:48 am
Here`s my donation to DreamHost (they need it).
From http://isc.sans.org
Mass website hosting = mass defacements
Published: 2007-07-02,
Last Updated: 2007-07-02 01:42:08 UTC
by Bojan Zdrnja (Version: 1)
Couple of weeks ago we mentioned a large MPack compromise (http://isc.sans.org/diary.html?storyid=2991). As you are probably aware, thousands of web sites (mainly in Italy) have been compromised and iframe tags added that pointed to other sites hosting exploits.
After checking were the compromised web sites were hosted, it became clear to us that we were dealing with a mass defacement when a single (or multiple) physical web servers were hosting thousands of web sites.
One of our readers sent us a PHP script he acquired from a compromised web server. The PHP script is pretty simple, and all it does is traverse through the file system and modify all files so that a malicious iframe tag is appended.
Two things were obvious here:
* The hosting web server did not have proper security on the file system level. This is, unfortunately, pretty common for (cheap?) hosting servers and is required when PHP is executed as a module in Apache. In this case, the main Apache process must be able to at least read all the files, but it appeared that it was able to write to them as well (wrong file permissions maybe?).
* The attackers had to find only one vulnerable PHP script on the server (note – the server might have been hosting thousands of different web sites).
Once attackers found a vulnerable PHP script they first detected the directory hierarchy on the web site. In case of the sample PHP script we received, it looked like this:
for ($i = 3; $i /home/sites/site’ . $i . ‘/web:’);
iframe_account(array(’/home/sites/site’ . $i . ‘/web’));
}
From the code snippet above, you can see that all sites have their document root directory set as /home/sites/site[number]/web. The loop creates an array which is then passed to another function called iframe_account().
This function takes every director and performs a recursive search for 4 file types:
$file_types = array(’php’, ‘htm’, ‘html’, ‘tpl’);
It then opens the files and searches for the “” tag which is replaced with the malicious iframe and properly closed:
$iframed_content = str_replace(”, ”, $content);
And voila – a mass compromise happened.
Conclusion
The main reason why this attack was possible was the fact that Apache’s process must be able to read all files (in order to serve/process them) and that the file system permissions were not correctly set. It remains questionable how many big hosting sites are affected with this (poor) setup.
As far as I know, the only proper way to do this is to run PHP as a CGI program and use chroot and/or suExec with Apache. Only with this you will make sure that one user’s web site can’t affect everyone else on the site. Of course, this has its price in performance which is why some hosting companies decide to sacrifice security instead of buying extra hardware. A nice document describing this setup can be found at http://www.seaoffire.net/fcgi-faq.html
PHP’s safe_mode, despite its name, doesn’t imply that you will have a secure environment. On the contrary, it is possible to work around the safe_mode requirements. This caused so many problems that the PHP developers decided to remove safe_mode from PHP version 6.
So, be sure to check if your hosting company uses chroot and/or suExec because that is the only way to make sure that your own web site will not be compromised by other users sharing the same physical server.
July 2nd, 2007 at 11:27 am
DH already uses suExec by default, so your donation is useless..
July 2nd, 2007 at 12:55 pm
Burn!
July 2nd, 2007 at 4:02 pm
Nice one smarty pants.
July 2nd, 2007 at 8:22 pm
BWAH! Suck on that one S.
^5 Javi
July 3rd, 2007 at 1:35 am
Any news on the outage we’re experiencing right now?
July 3rd, 2007 at 11:21 am
Why does the panel now say:
Camp Laurel We raised $399.21 from 18 contributors
Room to Read! We raised $908.73 from 25 contributors
after this blog previously said:
18 donations for $591.21 for Camp Laurel
24 donations for $990.73 for Room to Read,
i.e. what explains the significant decrease? Typos?
November 24th, 2007 at 9:42 am
everything is fine now… at least on my hosting account.
January 7th, 2008 at 7:46 am
veryy good
January 7th, 2008 at 7:53 am
asdg veryy good
January 7th, 2008 at 7:55 am
asf veryy gooj
January 7th, 2008 at 8:02 am
kıloldum
January 7th, 2008 at 8:04 am
kıl oldum
June 5th, 2008 at 4:10 am
sağolasın