Lucene search
K

perliis.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 32 Views

IIS can allow exploit of Perl scripts, leading to unauthorized access to UserIDs and passwords.

Code
`  
[ http://www.rootshell.com/ ]  
  
From [email protected] Sun Jul 12 17:42:29 1998  
Date: Mon, 13 Jul 1998 01:31:11 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: New Perl.exe, IIS exploit   
  
Russ Cooper of ntbugtraq seems unwilling to publish this information -  
perhaps it shows how to exploit this too much:  
  
****************************************************************************  
  
All versions of Internet Information Server seem to have a feature that can  
cause security problems when it has been configured to run Perl scripts to  
produce dynamic web pages, although really it is a combination of IIS and  
the Perl command interpreter (Perl.exe) acting together that can cause this  
hole. Basically the security implications of this problem is that data can  
be read from execute only virtual directories sometimes leading to the  
discovery of UserIDs and passwords.  
  
Script extentions (in this case .cgi or .pl) are mapped against the  
interpreter in the registry under the following key:  
  
HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap  
  
When the web service receives a request from a browser it checks the  
extention of the file requested and deals with it accordingly. In this case  
if a .pl or .cgi file is requested IIS checks the registry to see what  
interpreter should deal with that kind of file and then passes the requested  
information to the interpreter, perl.exe. This is the "fault" of IIS : that  
it does not check to see whether the file actually exists or not; it just  
blindly passes the information to the interpreter. IIS leaves this  
responsibilty to the interpreter.  
  
The second part of this problem is caused by the interpreter : perl.exe.  
Perl.exe will open and try to execute any file that actually exists as long  
as it has the extention .pl (if that is the registered extention.)  
Consequently if a space (%20) and .pl is appended to the end of a URL  
Internet Information Server will pass the request to perl.exe which will  
then open the file and try to execute it:  
  
http://www.site.com/scripts/file.ext%20.pl  
  
To demonstrate how this could be a problem : Some CGI scripts often require  
a .txt file that contains a userID and password such as wwwboard.cgi.  
Create a text file with two lines. On the first line type "Webadmin" and on  
the secondline type "Password". Like so:  
  
Webadmin  
Password  
  
And name the file pass.txt the request the following URL:  
  
http://www.site.com/scripts/pass.txt%20.pl  
  
You should receive a response similar to :  
  
Can't call method "webadmin" in empty package "password" at  
C:\InetPub\scripts\pass.txt line 1  
  
You can also glean information from other "sensitive" files such as .asp or  
.idc  
  
http://www.site.com/scripts/default.asp%20.pl or  
  
http://www.site.com/scripts/database.idc  
  
You could even run old perl scripts that are still in the /scripts  
directory but have had their extention changed:  
  
http://www.site.com/scripts/script.pl.old%20.pl  
  
  
This problem is exacerbated by the fact that perl.exe will accept willcards  
such as * and ? so you don't even need to know that name of a file. You can  
request :  
  
http://www.site.com/scripts/*.txt%20.pl  
  
and perl.exe will open the first text file in the scripts directory that it  
comes across.   
  
This was tested with Perl version 5.001 build 110. It is not yet known if  
other versions are affected. Testing would be appreciated.  
  
Affected machines:  
NT Server 4.0 Service pack 1 IIS 2.0  
NT Server 4.0 Service pack 3 IIS 3.0  
NT Server 4.0 Service pack 3 IIS 4.0  
NT Wkst 4.0 Service pack 3 PWS 3.0  
  
It is not yet know if other Web servers such as Netscape are affected.  
Again testing will prove if this is so and would be appreciated.  
  
The solution to this problem is to use the ISAPI interpreter instead :  
PerlIS.dll. This leads to better performance anyway as the script is run in  
the same memory space as IIS and only one instance of it ever needs to be  
loaded into memory unlike perl.exe where for each script requested a new  
instance of perl.exe is loaded into its own memory space.  
  
Mnemonix  
http://www.users.globalnet.co.uk/~mnemonix  
  
****************************************************************************  
  
Thought you might be interested. Cheers.  
Mnemonix  
http://www.users.globalnet.co.uk/~mnemonix  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

17 Aug 1999 00:00Current
7.4High risk
Vulners AI Score7.4
32