bugtraq - Re: Web Server Botnets and Server Farms as Attack Platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Mon, 12 Feb 2007 20:39:10 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com, ge@...uxbox.org
Subject: Re: Web Server Botnets and Server Farms as Attack Platforms

Interesting paper, Gadi.

Some thoughts:

1) It seems obvious that RFI is equivalent to remote code execution,
   but it's worth repeating.

2) A PHP exploit is much easier to write than a shellcode exploit.
   Plus, with the file inclusion, the payload is not limited in size,
   and you have a lot more reliability because you don't have to worry
   about platform variations.  Also, a fairly unskilled attacker can
   simply plug URLs into some parameters to find an RFI issue in a
   custom application.

3) The fact that you're seeing a lot of live attacks shows that,
   despite register_globals being disabled by default in PHP for a few
   years now, it's frequently enabled.  And even if it's disabled,
   some developers will implement their own version of
   register_globals by using dangerous constructs such as eval(),
   extract(), and $$varname (the latter being what I call dynamic
   variable evaluation).  Since these constructs can be equivalent to
   register_globals, they can be as dangerous.

4) Besides register_globals, other bugs/features in the PHP
   interpreter probably contribute to the high numbers of PHP
   application vulnerabilities.  Stefan Esser's work in this area is
   extensive.  The GLOBALS variable overwrite, and overwrite issues
   for other superglobals, will allow an attacker to control critical
   variables that the programmer would reasonably assume are safe.
   The unset() and XSS-in-error-messages bugs have been fixed, but how
   many servers still run vulnerable PHP versions?  PHP 5 still
   supports some remote behaviors even when allow_fopen_url is
   disabled.

5) RFI's success in compromising web servers is probably one reason
   why we see so many RFI vulnerabilities being disclosed (along with
   other factors like ease of discovery and prevalence of PHP
   applications).

- Steve