Bringing up security issues with Microsoft's IIS Web server, many people immediately think of the fatal vulnerabilities that people have hailed: UNICODE, CGI parsing,. ida,idq. Printer remote overflow and so on. These great holes are probably the favorites I've had for scriptskidding, and it's easy to use them to get higher system privileges. But this article is not a discussion of these fatal vulnerabilities, but a more detailed description of how to remotely determine the IIS server settings, such as directory permissions, authentication methods and so on, some things are already very old, but the new things are worth seeing. I hope this paper can play a role in the study. Okay, cut the crap, go~!.
Win2003 IIS security settings to remotely determine directory permissions
Let's open an IIS server to see. In IIS Service Manager, select a directory to see his properties
There are some options in the Directory property entry (log access and index this resource is not counted):
Script resource access: Scripts for Web sites can read the original file.
Read the static resources inside the directory.
Write users can create and delete resources
Directory browsing users can browse the contents of the directory.
Win2003 IIS security settings Application settings have three options in the execution license:
No access to static pages only
Pure script only allows scripts such as ASP scripts to be allowed
Script and executable programs can access and execute various file types
So, how do you determine these switch settings on the server? Don't worry, one of them comes.
Execute permissions
How do I determine if a directory has permission to execute? Very simply, send a request to the server below:
Http://iis-server/dir/no-such-file.dll
/dir/to judge the directory, No-such-file.dll is casually get a name, the server does not have this file.
The server will return a message to our request. If a 500 error is returned:
HTTP 500-Internal server error (Internal server error)
Then it means that the permissions on the directory are open. For servers, do not open the execution authority. In particular, the implementation of the virtual directory permissions, we think of Unicode and two of times decoding vulnerabilities in the use of the process to understand.
If the server returns a 404 error:
HTTP 404-File not Found
Then it shows that the execution permissions for this directory are not open.
Write permission
Win2003 IIS security Settings test whether a directory has write permissions for Web users, using the following methods:
Telnet to the server's Web port (80) and sends a request for the following:
Put/dir/my_file.txt http/1.1
Host:iis-server
Content-length:10 <enter><enter>
The server then returns a 100 (continue) Message:
http/1.1 Continue
server:microsoft-iis/5.0
Date:thu, Feb 2002 15:56:00 GMT
Next, we enter 10 letters:
Aaaaaaaaaa
After sending out this request, look at the server's return information if it is a 201 created response:
http/1.1 201 Created
server:microsoft-iis/5.0
Date:thu, Feb 2002 15:56:08 GMT
Location:http://iis-server/dir/my_file.txt
content-length:0
Allow:options, TRACE, GET, head, Delete, put, COPY, move, PROPFIND,
Proppatch, SEARCH, LOCK, UNLOCK
Then it means that the Write permission for this directory is open, conversely, if the return is a 403 error, then write permission is
Not open, if you need authentication, and return a 401 (permission prohibited) response, it is open Write permission, but anonymous users do not allow. If a directory has both "write" and "script and executable programs" open, then Web users can upload a program and execute it, scary oh%^#$!~
Pure Script Execution Permissions
There are too many of these directories. Many directories that do not need to execute permissions are also given script execution permissions by the administrator, and I remember
Shotgun an article in which he said: the smallest permissions + the least service = maximum security; nothing wrong. It is not necessary to give any extra permissions to the directory. It is also simple to determine whether a directory can execute a plain script file, sending a request as follows:
Http://iis-server/dir/no-such-file.asp
Return 404 file does not exist description has EXECUTE permission, return 403 is not open.
Win2003 IIS security settings Browsing directory permissions
It may take a little trick to determine whether a directory is allowed to browse, but the default home page (such as: default.asp) does not exist. Enter in the browser:
http://iis-server/dir/
If the permission is open, it returns 200 responses and lists the contents of the current directory, otherwise it is closed without listing the directory. But what if the default page default.asp exist? Typing the above address directly opens the page. Don't worry,
WebDAV has a request method called: Profind. This method allows us to get some information from the server resources, such as filename, creation time, last modified time, and so on. With it we can also bypass default.asp to determine the directory browsing permissions, Telnet to the Iis-server Web port, send the following request:
propfind/dir/http/1.1
Host:iis-server
content-length:0
At this point, the server sends back a 207 Multi status response, and if the directory is allowed to browse, it also lists the resources in the directory and their attributes. If directory browsing is not allowed, the information returned will be much less. Directory browsing generally can only be regarded as a low risk level of vulnerability, such as a images directory, in addition to the picture there is nothing else, there is no harm to the security of the server, but, If the directory contains a management page adminpage.asp or some database connection information file, may cause your server to hand over to the intruder.
Read permissions
It is easy to judge this, send a request with TXT file can:
Http://iis-server/dir/no-such-file.txt
If a response that does not exist for a 404 file is returned, the Read permission is open, anyway, the return of the 403 error indicates that the permission is not open. Early years of contact with security must know:: $DATA leakage of ASP source code loopholes, in fact, if a directory inside the powerful ASP script, then read permissions can not open, the ASP only need script execution permissions on it.
The judgment of IIS authentication method
This vulnerability was only recently announced, with IIS servers supporting anonymous access, Basic authentication and Windows Integration authentication using NTLM, and if the client sends a request that contains authentication information, IIS will forcibly attempt to authenticate with the authentication information and put back the unresponsive response. This allows us to determine the authentication configuration of IIS.
To determine if IIS supports Basic authentication, you can telnet to the server's port 80 and send the following request:
get/http/1.1
Host:iis-server
Authorization:basic C3lzdgvtom1hbmfnzxia
This is a Basic authentication request that contains a base 64 encoded user ID and a string of characters after pass,basic after base 64 decoding is System:manager. If the server returns a 401 message, the Basic authentication option is open. If 200 information is returned, there are 2 possibilities, the Basic authentication option is not on or the server exists a username is
System username, and the password is manager (guess, good luck).
Current 1/2 page
12 Next read the full text
