Remote analysis IIS settings (transfer)

Lift the security of Microsoft IIS Web servers, many people will immediately think about the fatal vulnerabilities for people to be praised: Unicode, CGI analysis, .ida, IDQ, .printer remote overflow, etc. These great vulnerabilities I am waiting for me, etc. Scripts kidding's favorite, use them to get a high system permission. However, this article is not to discuss these fatal vulnerabilities, just more detailed introductions how to remotely determine the various settings of the IIS server, such as directory permissions, certification methods, etc., some things are very old, but new things Still worth seeing. I hope this article can play a role of throwing bricks. Ok, nonsense, go ~! Remote determination of directory permissions let us open an IIS server to see. In the IIS Service Manager, select a directory to see his properties There are such options in the directory properties (log access and indexing this resource is not counted): Script Resource Access: You can read the original file for the script of the site. Read the static resource in the read directory. Write users can create and delete resource directory Browse users to view directory content. There are three options in the execution license of application settings: No access to static pages. Pure scripts can only allow scripts such as ASP scripts and executables to access and perform various file types, how to determine these switches on the server? ? Don't worry, one is coming. Does execute permissions to determine if a directory has executed permission? Very simple, send a request to the server: http://iis-server/dir/no-such-file.dll / dir / to judge the directory, no-sudh-file.dll is just a name, There is no file above the server. The server will return to us to return a message. If returned is a 500 error: HTTP 500 - Internal Server error (INTERNAL server error) then explains the execution permission of this directory is open. For the server, you don't want to open the execution permission. In particular, the execution permission of the virtual directory, everyone wants to know the use of Unicode and secondary decoding vulnerabilities. If the server returns a 404 error: HTTP 404 - The file is not found, then the execution permission of this directory is not open.

Writing Permissions Test a directory for WEB users have write permissions, using the following methods: Telnet to the server's web port (80) and send a request: PUT /DIR/MY_FILE.TXT HTTP / 1.1 Host: Iis-Server Content-Length : 10 This time the server returns a 100 (continued) information: http / 1.1 100 Continue Server: Microsoft-IIS / 5.0 Date: Thu, 28 Feb 2002 15:56:00 GMT Next, let's enter 10 letters: AAAAAAAAA is sent out, after reading the request, see the server's return information, if it is a 201 Created response: http / 1.1 201 Created Server: Microsoft-IIS / 5.0 Date: THU, 28 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 So this directory The write authority is open, and it is, if returned is a 403 error, then write permissions are not boosted, if you need your certification, and return a response to 401 (permission prohibition), the description is to write permission, But anonymous users are not allowed. If a directory has opened "Write" and "Script and Executable Programs", then web users can upload a program and execute it, horror oh,% ^ # $! ~ Pure script execute permission is too much directory. . Many of the directorys that don't need to be permissions are also given to script execution permissions. I remember that he said in shotgun: Minimal permissions least service = maximum security; there is no mistake. There is no need for any excess permissions to the directory. Judging whether a directory can perform a pure script file is also very simple, send a request: http://iis-server/dir/no-such-file.asp Return 404 file There is no explanation with execution rights, return 403 is No open. Browse directory permissions to determine if a directory allows browsing may need a little tip, but if the default home page of the website (such as: default.asp) does not exist, then it is just simple. Inside the browser: http: // IIS-server / dir / if the permissions are open, then return 200 response, and list the contents in the current directory, but there is no listing of the directory. However, if the default page default.asp exists? Open this page directly to the address of the above. Don't worry, there is a request method in WebDAV: profind. This method allows us to get some information such as file names, create time, final modification, and so on from server resources. With it, we can also bypass the DEFAULT.ASP to determine the situation of the directory browsing permission, Telnet to IIS-Server's web port, send the following request: PropFind / DIR / HTTP / 1.1 Host: IIS-Server Content-Length: 0 The server will send back 207 Multi Status responses, if the directory is allowed to browse, then the resources in the directory are listed and their properties.

If the directory browsing is not allowed, the returned information will be much less. Directory browsing is generally only a low-risk rating vulnerability, such as an images directory, except for the picture, there is no other thing, that is not harmful to the server's security, but if the directory puts a management page Admination .asp or some database connection information files, it may cause your server to make your hand to intruders. Reading rights to determine this easy, send a request with TXT files You can: http://iis-server/dir/no-such-file.txt If you return a 404 file does not exist, you will explain that the read permissions are Open, anyway, returning 403 error will indicate that all rights are not open. People who have been in contact with safety have known: $ data leaked the vulnerability of the ASP source code, in fact, if the power ASP script is in a directory, then read permissions can not be opened, and the ASP only needs scripting execution permission. Judging the IIS authentication method This vulnerability is recently released. The IIS server supports anonymous access, basic authentication, and Windows integration authentication using NTLM mode. If the client sends a request to include authentication information, IIS will try to use these The authentication information takes authentication and puts back the response. This way we can determine the configuration of IIS. To determine if IIS support basic authentication, you can Telnet to the server 80 port, send the following request: get / http / 1.1 host: IIS-Server Authorization: Basic C3lzdgvTom1HBMFNZXIA This is a basic authentication request, which contains an Base 64 encoded User ID and Pass, the string of characters behind Basic is SYSTEM: Manager after BASE 64 decoding. If the server returns a 401 message, the basic authentication option is open. If 200 information is returned, there are two possibilities. The basic authentication option is not open or the server has a username that the user name is system name, and the password is Manager (guess, the line of travel.). To determine if the NTLM option is enabled, you can send the following request GET / HTTP / 1.1 Host: IIS-Server Authorization: NegotiateTlrmtvntuaabaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa = For most websites, these two authentication methods do not need to be opened, they may reveal important information about some servers. Leak internal IP address information If the IIS server inside a firewall using NAT, there is usually an internal address such as 10.x.x.x.

If IIS opens the basic authentication option, you can get the following simple requests to get the internal IP of the server: get / http / 1.1 host: Authorization: Basic C3lzdgvTom1HBMFNZXIA server will return a response: http / 1.1 401 access Denied Server: Microsoft -Iis / 5.0 Date: Fri, 01 Mar 2002 15:45:32 GMT WWW-Authenticate: Basic Realm = "10.1.1.2" Connection: Close Content-Length: 3245 Content-Type: Text / HTML 10.1.1.2 is the machine The internal IP address, the value of Realm is a master header provided by the client, but here is empty, so IIS has selected the IP address of this unit. Similarly, the return information of the requests such as PropFind, Write, Mkcol can also leak some information, as we draw to the server: propFind / http / 1.1 host: Content-Length: 0 is configured in IIS In the case of the host name (see after seeing), it will not expose the host's IP address, but the NetBIOS name will be exposed. In fact, we can use IIS's certification to get more information, such as the name of the domain, to send requests with NTLM authentication to the server: Get / http / 1.1 host: IIS-Server Authorization: NegotiateTlrmtvntuaabaaaaaaaaaaaaaaaaaaaaaaaaaaa server will return a message : HTTP / 1.1 401 Access Denied Server: Microsoft-IIS / 5.0 Date: Fri, 01 Mar 2002 16:24:58 GMT WWW-Authenticate: Negotiate TlRMTVNTUAACAAAADAAMADAAAAAFgoKgeGvyVuvy67U AAAAAAAAAAEQARAA8AAAAUwBDAFkATABMAEEAAgAMAFMAQwBZAEwATABBAAEA DABTAEMAWQBMAEwAQQAEAAwAUwBDAFkATABMAEEAAwAMAFMAQwBZAEwATABB AAAAAAA = Content-Length: 3245 Content-Type: text / html that A long string character contains BASE 64 encoding of the name of the host name and NT.