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