Index: [Article Count Order] [Thread]

Date:  Mon, 30 Jul 2007 21:43:12 -0700
From:  "Ken Marcus - Precision Web Hosting, Inc." <kenmarcus (at mark) precisionweb.net>
Subject:  [coba-e:10504] Re: Php script vulnerabilities
To:  <coba-e (at mark) bluequartz.org>
Message-Id:  <096801c7d32d$4e2539c0$6700a8c0@OfficeKen>
References:  <46AC07A4.7000106 (at mark) theanchoragesylvania.com> <634ejo$1cta4k (at mark) wnpgmb01-c600f.mts.net> <46AD5046.2090305 (at mark) theanchoragesylvania.com> <46ADDC5C.8040908 (at mark) theanchoragesylvania.com> <08ab01c7d30a$b87fdeb0$6700a8c0 (at mark) OfficeKen> <002b01c7d322$c196e8f0$6400a8c0 (at mark) HPPAVILION>
X-Mail-Count: 10504



>> > Sorry to be the prophet of doom in the list - but this is starting to
>> > worry me.
>> >
>> > I found an interesting post at
>> > http://www.ossec.net/wiki/index.php/WebAttacks_links that describes 
>> > some
>> > of the attacks that are being attempted against hosts that run PHP. 
>> > Note
>> > particularly the links in section 1.2, that show the actual code that
>> has
>> > been found "in the wild" on compromised systems.
>> >
>> > The attacks of course are dependent on one or more of your clients
>> having
>> > some braindead php code in their web space .... It only takes one 
>> > client
>> > to forget to upgrade an open source application to fix a vulnerability,
>> > and you will have people getting all sorts of information from your
>> server
>> >
>> > This information can in turn help them to know how to do a full
>> compromise
>> > and take control of your host.
>> >
>> > How can we protect ourselves? What is the common pattern here? It seems
>> > that any occurrence of "://" in a http query string is required for all
>> of
>> > these attacks. What I would like to do (if it is possible) is to block
>> > this from being passed to ANY php script in the query string or POST
>> > variables etc.
>> >
>> > Does anyone have any ideas on how to block this? I was thinking of
>> > something at the apache level - any ideas?
>> >
>> > Regards,
>> > Greg.
>> >
>> >
>>
>> Greg
>>
>> Possibly in your php.ini you could set
>> allow_url_fopen = Off
>> and
>>
>> #one line below
>> disable_functions
>> ="dl,shell_exec,passthru,exec,popen,system,proc_get_status,proc_nice,proc_
>> open,proc_terminate,proc_close"
>>
>>
>> If you use mod_security
>>      then  in your conf file add something like
>>
>> SecFilter "php" chain
>> SecFilter  "wget"
>>
>> SecFilter "php" chain
>> SecFilter  "perl"
>>
>>
>> set the safe mode,
>> set the
>> open_base_dir  per site.
>>
>>
>>
>>
>> ----
>> Ken Marcus
>> Ecommerce Web Hosting by
>> Precision Web Hosting, Inc.
>> http://www.precisionweb.net
>>
>>
>>



> Would this affect cron jobs that use wget, curl, php or other URL-based
> calls?

Probably the mod_security  rules like I listed it would not affect a cron 
using wget on a php file.

I actually have them set to

SecFilter "phpbb" chain
SecFilter  "wget"

SecFilter "phpbb" chain
SecFilter  "perl"

since that is the exploit I have seen.


----
Ken Marcus
Free Shopping Cart by
Precision Web Hosting, Inc.
http://www.precisionweb.net