Date:  Tue, 31 Jul 2007 12:45:13 -0400
From:  "Darrell D. Mobley" <dmobley (at mark) uhostme.com>
Subject:  [coba-e:10509] Re: Php script vulnerabilities
To:  <coba-e (at mark) bluequartz.org>
Message-Id:  <005b01c7d392$2c950c80$6400a8c0@HPPAVILION>
In-Reply-To:  <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> <096801c7d32d$4e2539c0$6700a8c0 (at mark) OfficeKen>
X-Mail-Count: 10509



> -----Original Message-----
> From: Ken Marcus - Precision Web Hosting, Inc.
> [mailto:kenmarcus (at mark) precisionweb.net]
> Sent: Tuesday, July 31, 2007 12:43 AM
> To: coba-e (at mark) bluequartz.org
> Subject: [coba-e:10504] Re: Php script vulnerabilities
> 
> 
> 
> >> > 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.

I don't use mod_security...