Here's what this morning's security advisory read here:
``In the last 3 months we have noticed an marked increase in the number of
web-server attacks and successful compromise on our network. These are
mostly PHP-script exploits and are giving hackers easy shell access to
virtual servers, as mentioned in the PHP Security Advisory in the News
section of the control centre. We really cannot do much about these
network attacks other than to inform our customers to stay vigilant and
upgrade PHP-script software whenever newer versions become available.
The allow_url_open change to PHP is about as much as we can do here.''
They offer a more detailed description of the problem:
``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.
Following our own investigation of these hacked accounts, we
believe we have established the common point-of-entry for
these attacks.
As you may be aware, PHP provides a number of functions for
opening files such as 'fopen()' and it's also possible to
pass an HTTP or FTP URL to these such that
fopen('http://www.dsvr.co.uk/'); will fetch the contents of
the DSVR homepage for PHP to treat as a file.
What you may not be aware of is that functions such as
include() also allow URLs to be passed as their argument.
Since these functions cause the included file to be parsed
and executed as PHP code, this can be a major security flaw.
Many clients seem to be using PHP that looks like this:
<html>
...standard header...
<? include($page); ?>
...standard footer...
</html>
as a cheap way to manage common headers and footers. These
pages can be accessed like so:
so that a file 'about.inc' is included inside the standard
header/footer.
However, unless the $page variable is checked for valid
content -- and input sanity checking is conspicuously absent
in many PHP scripts we encounter -- this is very open to
misuse. Malicious third parties could do the following:
This example would cause
to be downloaded and executed as PHP, allowing the hacker to
manipulate server files and create backdoors which allow
them to log in using telnet or ssh and cause further
disruption.''
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.
``In the last 3 months we have noticed an marked increase in the number of
web-server attacks and successful compromise on our network. These are
mostly PHP-script exploits and are giving hackers easy shell access to
virtual servers, as mentioned in the PHP Security Advisory in the News
section of the control centre. We really cannot do much about these
network attacks other than to inform our customers to stay vigilant and
upgrade PHP-script software whenever newer versions become available.
The allow_url_open change to PHP is about as much as we can do here.''
They offer a more detailed description of the problem:
``Recently, we've seen an increase in malicious activity on
our servers, caused by hackers who have successfuly gained
shell access via insecure PHP scripts.
Following our own investigation of these hacked accounts, we
believe we have established the common point-of-entry for
these attacks.
As you may be aware, PHP provides a number of functions for
opening files such as 'fopen()' and it's also possible to
pass an HTTP or FTP URL to these such that
fopen('http://www.dsvr.co.uk/'); will fetch the contents of
the DSVR homepage for PHP to treat as a file.
What you may not be aware of is that functions such as
include() also allow URLs to be passed as their argument.
Since these functions cause the included file to be parsed
and executed as PHP code, this can be a major security flaw.
Many clients seem to be using PHP that looks like this:
<html>
...standard header...
<? include($page); ?>
...standard footer...
</html>
as a cheap way to manage common headers and footers. These
pages can be accessed like so:
so that a file 'about.inc' is included inside the standard
header/footer.
However, unless the $page variable is checked for valid
content -- and input sanity checking is conspicuously absent
in many PHP scripts we encounter -- this is very open to
misuse. Malicious third parties could do the following:
This example would cause
to be downloaded and executed as PHP, allowing the hacker to
manipulate server files and create backdoors which allow
them to log in using telnet or ssh and cause further
disruption.''
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.
Comment