Windows NT Security 1.0 by Neon-Lenz Released through The Cyrax Team --------------------------------------------------------------- This paper was intended for people who are new to windows NT, but i hope i could shed up some light for veterans/experts as well. About 90 % of this paper will be focused on REMOTE NT security, so don't be surprised if you have noticed that i didn't cover some major local security issues. Understanding what shares are -------------------------------------------- Shares of Windows NT are files and maps on the NT-server which allows various machines to access. When you are installing Windows NT, it will share some standard shares itself. Some of those shares are only visible to the Administrators. Shares are permanent standard accounts which has a name that ends with a "$". C$ for example is the share for partition C:, which D$ is the share for partition D:. WINNT$ is the main-map for system files. ------------------------------------------------------------------------------------------------------------ Understanding SMB's and Components -------------------------------------------------------- The following was quoted from the great document written by NeonSurge (Rhino9) : Understanding SMB's and Component By NeonSurge Released through the rhino9 team Preface The reason I decided to write this file was because recently the rhino9 team has been giving speaches and lectures. The two questions we most frequently come across is "What is NetBIOS?" and "What are SMBs?". Well I hope I have already answered the NetBIOS question with the paper I recently released on it (www.x-treme.abyss.com/techvoodoo/rhino9). This paper is being written to better help people understand SMB's. Enjoy, have fun, and if you have any questions or comments, send them to NeonSurge@abyss.com. What are SMB's? Server Message Blocks are a type of "messaging protocol" that LAN Manager (and NT) clients and servers use to communicate with each other. SMB's are a higher level protocol that can be transported over NetBEUI, NetBIOS over IPX, and NetBIOS over TCP/IP (or NBT). SMBs are used by Windows 3.X, Win95, WintNT and OS/2. When it comes to security and the compromise of security on an NT network, the one thing to remember about SMBs is that it allows for remote access to shared directories, the registry, and other system services, making it a deadly protocol in the eyes of security conscience people. The SMB protocol was originally developed by IBM, and then jointly developed by Microsoft and IBM. Network requests that are sent using SMB's are encoded as Network Control Blocks (NCB) data structures. The NCB data structures are encoded in SMB format for transmission across the network. SMB is used in many Microsoft and IBM networking software: · MS-Net · IBM PC Network · IBM LAN Server · MS LAN Manager · LAN Manager for Unix · DEC Pathworks · MS Windows for Workgroups · Ungermann-Bass Net/1 · NT Networks through support for LAN Manager SMB Messages can be categorized into four types: Session Control: Used to establish or discontinue Redirector connections with a remote network resource such as a directory or printer. (The redirector is explained below) File: Used to access and manipulate file system resources on the remote computer. Printer: Used by the Redirector to send print data to a remote printer or queue, and to obtain the status of remote print devices. Message: Used by applications and system components to send unicast or broadcast messages. The Redirector The Redirector is the component that enables a client computer to gain access to resources on another computer as if the remote resources were local to the client computer. The Redirector communicates with other computers using the protocol stack. The Redirectors primary function is to format remote requests so that they can be understood by a remote station (such as a file server) and send them on their way through the network. The Redirector uses the Server Message Block (SMB) structure as the standard vehicle for sending these requests. The SMB is also the vehicle by which stations return responses to Redirector requests. Each SMB contains a header consisting of the command code (which specifies the task that the redirector wants the remote station to perform) and several enviroment and parameter fields (which specify how the command should be carried out). In addition to the header, the last field in the SMB may contain up to 64K of data to be sent to the remote station. [QuickNote: SMB and NBT (NetBIOS over TCP/IP work very closely together and both use ports 137, 138, 139. Port 137 is NetBIOS name UDP. Port 138 is NetBIOS datagram UDP. Port 139 is NetBIOS session TCP. For further information on NetBIOS, read the paper at the rhino9 website listed above] ===================================================================== This was meant as a quick and dirty intro to SMB, if you want any further information, contact me. NeonSurge NeonSurge@abyss.com Rhino9:The WindowsNT Security Research Team --------------------------------------------------------------------------------------------------------------------------- Bug in Samba ------------------- Using a samba-client connecting to a share and issueing the command "cd.." from the main-map will cause the NT-machine (version 3.5 and 3.51) to crash. Depending on the configuration of the computer, the NT-machine might re-boot or waits for an handling of the administrator. You can protect your NT-installation by using an higher version of Windows NT: NT server 4.0 or NT server 3.51 with Service Pack 5. ------------------------------------------------------------------------------------------------------------------ Gaining (un)authorized access to shares on the Internet ------------------------------------------------------------------------------- Gaining access to shares on the internet is not too difficult, it is although a bit time-consuming. First you will need some commands which are standardly packed with your copy of Windows NT (98/95). The commands I'm referring to are nbtstat.exe and net.exe. Using these two commands will make you capable of connecting to remote shares. This can be done by using the service in the properties of your TCP/IP called NBT (NetBIOS over TCP/IP.) NOTE: I will not explain you this in a too detailed way, simply because there are other great documents which explains this better than i do. The documents i'm referring to are the ones called "NT Wardoc" by NeonSurge and The Rhino9 Team and the document of KeyDet called "How to break into Windows NT - Improving the security of your site by breaking into it, the NT version". Gathering Information is usually the first thing we would do in order to access the remote shares of the target computer. To determine if the computer has NetBIOS over TCP/IP running, we either do a portscan to see if port 139 is open or we execute the command : nbtstat -A xxx.xxx.xxx.xxx (which is the ip of the target) It will either show you the remote NetBIOS name-table or it will say host not found. If it shows the name-table you might be in luck, if not, try another. Now check the table for <20> behind the names listed on the name-table. <20> means that the target has file-sharing enabled. If that is the case we issue our second command : net use \\xxx.xxx.xxx.xxx\ipc$ "" /user:"" Doing that will connect you to the target's hidden null share which is necessarily in order to get the list of shares or for further information gathering on the target. NOTE: Most IPC$'s are passworded due to the risk of having your computer compromised by the null share, if that is the case you have to get a program which does dictionary or brute-force attacks in order to connect to the null share. Mnemonix's IPCCRACK would be a good one. And if you ARE connected, you should issue the 3rd command: net view \\xxx.xxx.xxx.xxx This will get you a list of the available shares on the target. NOTE: I've made a batch-program which will do all the things mentioned above with one command, all the results will be saved into a file called result.txt, you can get netbios.bat at http://packetstorm.security.com/Win/netbios.bat - Copy the source paste it in an editor, save it as netbios.bat and run it like this: netbios "ipoftarget" For example if you see C$ available on the list, you will issue the command: net use x: \\xxx.xxx.xxx.xxx\C$ This will map the target's C: to your local x: station. The rest should not be too difficult to figure it out yourself. =) And if the attempted connection to the remote share needs a password, then you will need to grab a remote password-cracker called "NAT - NetBIOS Auditing Tool", NAT will attempt to crack the passwords using a standard userlist.txt and a standard password-list called passlist.txt. (You can edit the txt's and add usernames and passwords to it.) When inside the target's machine, an intruder would search for files like : *.sam (or sam._ in c:\winnt\repair), *.pwd, *.ini, *.idc, *.pwl (if it's a 95 or 98 computer) etc. Grab the necessarily password crackers in order to crack them. (L0phtcrack, NTcrack, John the Ripper etc.) --------------------------------------------------------------------------------------------------------------------------- The Relationship between NT and TCP/IP ---------------------------------------------------------- NT-machines mostly don't accept Unix-commands (for example commands for the Network File System, Network Information System or Sun RPC). That, making it way more easier to secure security-holes in TCP/IP in Windows NT than in Unix. Also, remote users which are gaining access to Windows NT are mostly using Remote Access Service (RAS) instead of Telnet, which gives you more control over the remote users. I'm sure you have noticed that Remote Access Service prevents remote users from issueing commands from the command-line. The most important Internet risks for Windows NT are attacks via the services of the Simple Mail Transfer Protocol (SMTP) and the Hypertext Transport Protocol (HTTP). Just keep in mind that when you are starting the services on your system you are only allowing access (on user-level) to the objects or maps for the service. Which for example that users only have read-access to the map with your Webfiles. If a CGI-script creates a webpage in run-time, then the HTTP-service has to have write-access as well. But, of course, only to the specified webpage. That means that neither your SMTP and HTTP should provide full-access to the harddisk of the NT-server. Just by controlling issues like these (access-control) will make your system A LOT more safer. But sadly, the webserver of NT (Internet Information Server - IIS) had and still has, some serious security-issues. One of the issues was for example that everybody that could access the IIS-server (which if the server is connected to the internet, refers to the internet-users) allowing them to delete files which the server can, WITHOUT logging the intruder's deletion. This happens if the administrator hasn't activated control over basic objects. This example gives you some idea why you shouldn't give too much access to the objects of your network. You can prevent problems like this by installing the newest versions of IIS and the IIS patches. --------------------------------------------------------------------------------------------------------------------------- Some of the major Vulnerabilities in the IIS server ---------------------------------------------------------------------- Name: IIS showcode Risk: Web users can view ASP source code and other sensitive files on the web server Versions: Microsoft IIS 4.0 Web Server Date: May 7th, 1999 Author: weld@l0pht.com Internet Information Server (IIS) 4.0 ships with a set of sample files to help web developers learn about Active Server Pages (ASP). One of these sample files, showcode.asp, is designed to view the source code of the sample applications via a web browser. The showcode.asp file does inadequate security checking and allows anyone with a web browser to view the contents of any text file on the web server. This includes files that are outside of the document root of the web server. The showcode.asp file is installed by default at the URL: http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp It takes 1 argument in the URL, which is the file to view. The format of this argument is: source=/path/filename So to view the contents of the showcode.asp file itself the URL would be: http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp? source=/msadc/Samples/SELECTOR/showcode.asp The author of the ASP file added a security check to only allow the viewing of the sample files which were in the '/msadc' directory on the system. The problem is the security check does not test for the '..' characters within the URL. The only checking done is if the URL contains the string '/msadc/'. This allows URLs to be created that view, not only files outside of the samples directory, but files anywhere on the entire file system that the web server's document root is on. http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp? source=/msadc/Samples/../../../../../boot.ini This URL requires that IIS 4.0 was installed in its default location. For production servers, sample files should never be installed so delete the entire /msadc/samples directory. Q184717 - AspEnableParentPaths MetaBase Property Should Be Set To False as well as one on removing samples. also note, that the exair sample (which is NOT installed by default) also has showcode functionality. WebTrends were also reporting the showcode.asp exploit, as well as an exploit in codebrws.asp (both from IIS 4.0). They also reported an exploit in viewcode.asp (from Site Server 3.0 Commerce Edition). All 3 reports result in the same vulnerability, the ability to do "../" up the directory tree and read files. http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind9901&L=NTBU GTRAQ&D=0&P=6155&F=P --------------------------------------------------------------------------------------------------------------------------- Name: IIS4 as proxy Risk: allows proxied password attacks over NetBIOS Versions: IIS 4.0 with /IISADMPWD feature Date: 9 Feb 1999 Author: mnemonix (http://www.infowar.co.uk/mnemonix/) Internet Information Server 4.0 has an interesting feature that can allow a remote attacker to attack user accounts local to the Web Server as well as other machines across the Internet.Added to this if your Web Server is behind a firewall performing network address translation, machines on the clean side of the firewall can be attacked Details By default every install of Internet Information Server 4 creates a virtual directory "/IISADMPWD". This directory contains a number of .htr files. Anonymous users are allowed access to this files, they are not restricted to the loopback address (127.0.0.1). The following is a list of files found in the /IISADMPWD directory, which physically maps to c:\winnt\system32\inetsrv\iisadmpwd. achg.htr aexp.htr aexp2.htr aexp2b.htr aexp3.htr aexp4.htr aexp4b.htr anot.htr anot3.htr The files, save for a few, are pretty much variants of the same file and allow a user to change their password via the Web. This can be used in such scenarios as mentioned in the Introduction.Not only this but, like the vrfy command in the SMTP service it can be used to enumerate valid accounts through guess work. If the user account does not exist a message will be returned saying, "invalid domain". If the account exists, but the password is wrong then the message will say so. If an IP address followed by a backslash precedes the account name then the IIS server will contact the remote machine, over the NetBIOS session port, and attempt to change the user's password. (IPADDRESS\ACNAME) Mechanics Consider aexp3.htr. This produces an HTML form requesting the UserID, old password, new password and confirm new password. The form's action is a POST to /_AuthChangeUrl? /_AuthChangeUrl? is a "virtual file" in memory that actually maps to achg.htr. W3SVC.dll maintains this in memory and has a function, AuthChangeUrl(), which links this to the achg.htr file.(To see this function make a copy of w3svc.dll, rename it to w3svc.txt and open it in notepad. If you can't see it straight away use Find from Edit on the Menubar). .htr files are handled by ISM.DLL and so control is passed across from W3SVC.DLL. ISM.DLL then uses the NetUserGetInfo ( ) and NetUserChangePassword ( ) functions. (Again, open up ism.dll in notepad and you can see references to these functions.) The password is changed if the entered information was correct. If, however, the request is to change a password on a remote machine, the SYSTEM then logs onto the remote machine through a null session then establishes a secure session over which to trade the account and password information. Solution If you don't require this service, then remove the /IISADMPWD virtual directory. This will prevent attackers from "proxing" password attacks. If you do require the service and only need to change passwords on accounts local to the server, disabling the Workstation service should prevent this. If you require this service and want to be able to change passwords on remote machines, do your best to limit where NetBIOS based traffic over TCP port 139 can get to. NOTE In opinion of Russ - NTBugtraq moderator, all of this speculation, mistaken assumption, farcical hyperbole and arm waving takes away from the valid observations of the interaction between files and service which Mnemonix has told us. --------------------------------------------------------------------------------------------------------------------------- Name: IIS 4 Request Logging Security Advisory Risk: allows an successful HTTP request to go unlogged. Versions: IIS 4.0 Date: 22 Jan 1999 Author: mnemonix (mnemonix@GLOBALNET.CO.UK) Microsoft's Internet Information Server 4 allows the use of any request method of almost any length for a r esource that is to be interpreted or executed on the web server.This includes such files as Active Server Pages, Perl Scripts and ordinary executables.Consequently a user can request a file, default.asp, with a request method of AAAAAAAAAAAAAAAAAAAAAAAAA and it will be returned. If the request method used added to the path to the requested resource is over c.10150 bytes long the page is returned and nothing is logged by IIS.This could allow attacks on the server to go unnoticed. MS have probably decided to avoid the situation where an attacker could rapidly fill up disk space by not logging overly long requests. Perhaps it would be better to truncate such a request and log that. To demonstrate this I have written an executable called avoid.exe that will use a request method which is 10140 bytes long that requests /default.asp from a webserver. This program does not exploit anything other than the logging avoidance. You can get a copy from http://www.infowar.co.uk/mnemonix/avoid.exe This was tested on NT 4 with SP3 + hotfixes. There has been a mixed response to this problem - on some machines nothing is logged and the page is returned, others get a 500 error and others log the whole request. >From what I can make out: Machines that first had IIS 3 then were upgraded to IIS 4 with the NT Option Pack and Service Pack 3 or 4 return the page and don't log. Here is the source for avoid.c as many have asked for it - for those that get a 500 response back from the server play around with the request_method length by increasing it until you get a 200ok response. It will chop and change between 5xx, 4xx and 200 responses. --------------------------------------------------------------------------------------------------------------------------- Name: Perl.exe and IIS security advisory Risk: the physical disk location of a virtual web directory can be ascertained. Versions: all versions of IIS Date: 22 Jan 1999 Author: mnemonix (mnemonix@GLOBALNET.CO.UK) In all versions of IIS, where a website has been configured to interpret perl scripts using the perl executable (perl.exe),a problem exists where a request for a non-existent file will return the physical location on a disk of a web directory. A request for: http://www.server.com/scripts/no-such-file.pl will return information similar to the following: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Can't open perl script "C:\InetPub\scripts\no-such-file.pl": No such file or directory Previously this was a problem when requesting a non-existent .IDC file but this was resolved with Service Pack 4. To resolve this problem in IIS 2 and 3 you can use perlis.dll, the ISAPI version of the perl interpreter, instead of the executable. You can use this in IIS 4 as well, however, if you still want to use perl.exe you can configure IIS to check for the file's existence. NTInfoScan, downloadable from http://www.infowar.co.uk/mnemonix/ntinfoscan.htm , checks for this problem and the .IDC issue as well as other security checks. --------------------------------------------------------------------------------------------------------------------------- Another problem with some versions of perl.exe (eg 5.001 build 110) is that it can be used to glean information from files that should not be readable (eg .asp or .idc), possibly even passwords and user IDs. This works even on directories with the "EXECUTE" permission only. The problem is caused by IIS not checking for a file's existence before passing control to a command interpreter. IIS 4.0 can do this, but it does not do it by default. Other versions of IIS don't have this capability. Basically what you do is request a file and append %20.pl to the end of the URL: http://www.server.com/scripts/default.asp%20.pl IIS receives this request and assumes it is a request for a perl script due to the extention so it passes the request to perl.exe. Perl, when it receives the instruction to execute default.asp treats the .pl as an argument. It goes ahead and tries to run the "commands" in the file but can't because it is not a valid perl script. Due to its verbosity in the error messages spawned by the file not being a real script you can glean information from the file. To see this working create a text file and call it passwd.txt. Enter "webadmin" (the user ID) on one line and "secret!" (the password) on another. Save it to your scripts directory and enter the following URL: http://your.server.com/scripts/passwd.txt%20.pl You should, depending upon your version of perl.exe receive the following output: Can't call method "webadmin" in empty package "password" at C:\InetPub\scripts\pass.txt line 1 Some web cgi scripts require password files like these. Depending on how any .asp or .idc files are written you may be able to extract userIDs and passwords. Again another problem is that some versions of perl.exe will accept wildcards such as * or ?. Request: http://www.server.com/scripts/*.pl and perl.exe will open the first .pl it comes across in the directory. You can ask for *.asp%20.pl or d*.idc%20.pl - these will do fine. To stop this problem from happening use the ISAPI perl interpreter instead PerlIS.dll. This provides for better performance anyway because only one instance is ever loaded into memory. For each concurrent perl script request a new instance of perl.exe is loaded into its own memory space. This behaviour was discovered by Mnemonix. --------------------------------------------------------------------------------------------------------------------------- Name: upgraged to IIS 4.0 Date: 14 Jan 1999 Risk: Admin Brute-force hack and Buffer overflow Versions: those that upgraged to IIS 4 from IIS 2 or 3. Author: mnemonix (mnemonix@GLOBALNET.CO.UK) Microsoft's IIS 4 limits Web-based administration to the loopback address (127.0.0.1) by default as a security measure. However, a relict left over from IIS 2 and 3, ism.dll left in the /scripts/iisadmin directory, allows users / attackers to access the previous ISAPI application used for remote web-based administration from an non-loopback IP address. On accessing a URL similar to the following http://www.server.com/scripts/iisadmin/ism.dll?http/dir a user will be prompted for a UserID and password and if successful authentication takes place they are given access to sensitive server information. Note however, that changes can no longer be made with this application. It does however provide an attacker with a means to brute force / guess the Administrators password and if successful an enormous amount of reconnaisance work can be achieved through the application's use. This application is now rundundant and can be removed. It plays no part in IIS 4's Web-based administration. Added to this if IIS 4 is installed from the NT Option Pack and Frontpage Server Extentions are installed too, the fpcount.exe utility found in the /_vti_bin/ contains an exploitable buffer overrun. I advised on this last year and MS produced an updated version in FPServer Extentions 98 which can be downloaded from the MS website. Fpcount.exe (c) mnemonix Microsoft's FrontPage extentions comes with a utility called fpcount.exe - this is used as a webhit counter. If you access this program directly you can cause a buffer over flow and/or tie up the processor at 100%. The two can be combined into a denial of service attack that will cause IIS to stop servicing requests: http://www.server.com/scripts/fpcount.exe?Page=default.htm|Image=3|Digits=10000 Note here we are asking fpcount to calculate to 10000 digits. This will cause the buffer overrun and Dr Watson, or whatever the specified debugger is, will kick in saying so. When Dr Watson loads here it takes up about 4000K of memory. If an attacker reloads the page a number of times the remote machine will soon run dry of memory. To then finally kill IIS an attacker would enter the following URL: http://www.server.com/scripts/fpcount.exe?Page=default.htm|Image=3|Digits=-10000 With this negative integer the program's buffer won't overflow and will tie up the processor at 100% while it tries to generate 10000 digits. The largest number I've been able to send without problems is -99999999. This will kill IIS for upto 10 hrs depending on the speed of the processor. Even when it has finished calculating it is still short on available memory. --------------------------------------------------------------------------------------------------------------------------- Name: newdsn.exe & getdrvrs.exe Date: 1998 Versions: Internet Information Server 3.0 Risk: default scripts can bring hack Source: mnemonix When IIS is installed it will create a tools sub-directory off of the /scripts directory. It will place a number or related .exes in here that are used for creating ODBC datasources for online databases. These executables leave cause two security concerns. The first is that using these .exes a remote attacker can create a file with any extention in any directory that the anonymous internet account has NTFS write permissions to. If FAT is in use then they can write to anywhere. The exe that creates the file is actually dsnform.exe. Lets say they had write access to any of your directories with the "execute" permission. If they knew the real path to this directory they can create a file with a .exe extention - eg run.exe. Assuming they have write permissions to your scripts directory they would enter the following URLs: http://www.server.com/scripts/tools/getdrvrs.exe From here they would choose the *.mdb option and be taken to: http://www.server.com/scripts/tools/dsnform.exe?Microsoft+Access+Driver+(*.mdb) Here they would enter a datasource name to create (can be anything you want)and then specifies the database name. This is where the attacker would enter something like c:\inetpub\scripts\run.exe. They then click on create datasource (making sure that "Create new database with this name" is checked). They should be taken to the following: http://www.server.com/scripts/tools/newdsn.exe? driver=Microsoft%2BAccess%2BDriver%2B%28*.mdb%29 &dsn=sdsd&dbq=hmm.mdb&newdb=CREATE_DB&attr= After they had created run.exe they enter the following URL: http://www.server.com/scripts/run.exe Because run.exe is not a real executable and is infact an mdb file with a .exe extention it has problems executing. Create the file and run it from a command prompt. You'll see invalid CPU calls and it will ask you to "Terminate" or "Ignore". What actually happens is NT tries running it and thinks it's a 16-bit program so will launch an NTVDM (NT's Virtual DOS machine -for running 16-bit apps). Now if this is run via the web because it is non-interactive with the desktop you don't get the prompt to terminate or ignore - the NTVDM just hangs. If this attacker now refreshes his page a number of times you'll soon start to eat into your virtual memory - a new NTVDM is loaded each time. By the way - this invalid CPU call is actually an NTVDM buffer overflow - there is no known way to execute arbitary code with it - you'll need to inject your assembly code into the run.exe mdb file and this can't be done from across the web without having some other means to do this. This is a simple denial of service. The other problems with this set of executables is that existing datasources can be modifed if the database file name is known - instead of choosing "Create new database with this name" choose "This is an existing Access database". This will re-write the ODBC database making it now inaccessible - another Denial of service attack. http://vulnerable.site.com/scripts/tools/newdsn.exe? driver=Microsoft%2BAccess%2BDriver%2B%28*.mdb%29 &dsn=Evil+samples+from+microsoft &dbq=..%2F..%2Fwwwroot%2Fevil.html&newdb=CREATE_DB&attr= will create file evil.html in wwwroot directory. evil.html in fact is a Microsoft Access Database. Solution: delete newdsn.exe :) --------------------------------------------------------------------------------------------------------------------------- Name: Index Server Exploit Date: 1998 Versions: Internet Information Server 3.0 (Index Server Exploit) Risk: default scripts can bring hack If the system administrator has left the default sample files on the Internet Information server, a hacker would have the opportunity of narrowing down their search for a username and password. A simple query of a popular search engine shows about four hundred websites that have barely modified versions of the sample files still installed and available. This file is called queryhit.htm. Many webmasters have neglected to modify the search fields to only search certain directories and avoid the script directories. Once one of these sites is located a search performed can easily narrow down the files a hacker would need to find a username and password. Using the sample search page it is easy to specify only files that have the word password in them and are script files (.asp or .idc files, cold fusion scripts, even .pl files are good). The URL the hacker would try is http://servername/samples/search/queryhit.htm then the hacker would search with something like "#filename=*.asp" When the results are returned not only can one link to the files but also can look at the "hits" by clicking the view hits link that uses the webhits program. This program bypasses the security set by IIS on script files and allows the source to be displayed. Even if the original samples are not installed or have been removed a hole is still available to read the script source. If the server has Service Pack 2 fully installed (including Index Server) they will also have webhits.exe located in the path http://servername/scripts/samples/search/webhits.exe This URL can preface another URL on that server and display the contents of the script. To protect your server from this problem remove the webhits.exe file from the server, or at least from it's default directory. I also recommend that you customize your server search pages and scripts (.idq files) to make sure they only search what you want - such as plain .HTM or .HTML files. Index Server is a wonderful product but be sure you have configured it properly. --------------------------------------------------------------------------------------------------------------------------- Name: Executable Directories in IIS 4 Date: August 31, 1998 Versions: Internet Information Server 4.0 Risk: If a non-administrative user can place executable code into a web site directory which allows file execution, the user may be able to run applications which could compromise the web server. The following directories are marked executable by default on an install of IIS 4.0: /W3SVC/1/ROOT/msadc /W3SVC/1/ROOT/News /W3SVC/1/ROOT/Mail /W3SVC/1/ROOT/cgi-bin /W3SVC/1/ROOT/SCRIPTS /W3SVC/1/ROOT/IISADMPWD /W3SVC/1/ROOT/_vti_bin /W3SVC/1/ROOT/_vti_bin/_vti_adm /W3SVC/1/ROOT/_vti_bin/_vti_aut In a default install, the physical drive mappings will be: msadc c:\program files\common\system\msadc News c:\InetPub\News Mail c:\InetPub\Mail cgi-bin c:\InetPub\wwwroot\cgi-bin SCRIPTS c:\InetPub\scripts IISADMPWD C:\WINNT\System32\inetsrv\iisadmpwd _vti_bin Not present by default - installed with FrontPage extensions Access to the physical directories can be obtained through drive sharing, remote command shells (e.g., rcmd, telnet, remote.exe), HTTP PUT commands, or FrontPage. None of these methods are available in a default install, but are often added by administrators. The default NTFS permissions are overly permissive, and allow change control (RWXD) to the Everyone group by default, with the exception of msadc which is full control to Everyone. Due to the sensitive nature of these directories, it is recommended that NTFS access permissions should be: Administrators, LocalSystem: Full Control Everyone: Special Access(X) Recommended Action: Administrators should verify access permissions on all virtual HTTP server directories that are marked executable. See below for recommended permissions. All security patches that protect against local attacks should be applied to HTTP servers due to the possibility of the server executing code locally. See http://www.microsoft.com/security for details. -------------------------------------------------------------------------------------------------------------------------- Well that's about it, i will update this paper once in a while. Simply because of the constant progress in the computer-security scene. If you have any questions or comments, e-mail them to neonlenz@ellicit.org, I'll try to reply you ASAP. Greetings, Neon-Lenz. neonlenz@ellicit.org http://ellicit.org/~neonlenz Cyrax Security Research Team.