Analysis of IIS attacks and security reinforcement instances

As a popular Web server, IIS occupies a large proportion in today's Internet environment, and most asp and asp.net websites run on it. Therefore, it attracted the attention of countless hackers. At present, the attack technology against IIS is very mature, and the technical threshold is relatively low, so many beginners use it to practice. Many websites are poisoned by poor security awareness or technical negligence of website administrators. This article uses examples to talk about IIS attack technology and security reinforcement measures.

Attack instance

Exploitation of IIS write permission vulnerability

We first use an attack instance to demonstrate how to quickly break into a website by using improper IIS permission configuration, so as to increase the reader's emphasis on IIS security.

Target website IP Address: 192.168.1.105

Exploitation vulnerability: IIS write permission vulnerability

Tools used: iis put Scaner and Guilin veterans write permission exploitation tools

1. Check whether the target website has the write permission vulnerability.

Open iis put website, enter the IP address and port number of the target website (port 80 by default), and click "Scan" to start scanning. The result is returned soon, as shown in 1:

Figure 1

2 IIS write permission exploitation process

Based on the scan results, we can determine that the target website has the IIS write permission vulnerability. Next, let's take a look at how to use this vulnerability to get a WebShell.

First, we will save the trojan code of "<% eval request (" cmd ") %>" as a txt file. I name it test.txt. Go to the Guilin veterans write permission exploitation tool, enter the IP address or domain name of the target website, and select the "PUT" data packet submission method from the drop-down menu in the "data packet format" area, finally, click the "submit data packet" button to view the results returned by the server. 2:

Figure 2

The server returns a 201 response code, which indicates that the file is successfully uploaded.

Now we need to change the uploaded txt text to an asp file, otherwise the server will not resolve it to an asp file. In the "data packet format" drop-down menu, select the "MOVE" data packet submission method, and modify the file name at "Destination". The default value is shell. asp. Here I change it to cmd. asp. Click "submit data packet" to view the information returned by the server. 3:

Figure 3

In the same way, the server returns the 201”program, indicating that we successfully changed test.txt to cmd. asp.

Now we can use a one-sentence Trojan client to connect to the just-uploaded one-sentence Trojan, which can be accessed successfully. 4:

Figure 4

In this way, we get a WebShell. From the perspective of the entire attack process, the time used is very short, and the technical threshold is very low. An ordinary person can use tools to quickly get a website. Unfortunately, in the actual penetration test process, many websites still have such vulnerabilities. We hope that this instance will attract the attention of network administrators on security.

IIS6.0 resolution vulnerability Exploitation

A. in the web directory, when the file name is "“a.asp; B .jpg", IIS parses it into an asp file, as shown in Figure 5.

Figure 5

B. In the WEB directory, IIS6.0 resolves all files in the folder named "x. asp" to asp files, as shown in figure 6.

Figure 6

The above two points are defects in the design of IIS, but Microsoft regards them as a feature of IIS and has not released any corresponding security patches.
These two methods are sometimes very effective when you try to bypass the File Upload detection. The following is an example of the actual penetration test process.

Log on to the background of the website and upload an asp Trojan directly. The system prompts that the file is illegal and cannot be uploaded. Next, change the local name to 1.asp;2.jpg and upload the file again. The file is successfully uploaded to the website directory, as shown in figure 7.

Figure 7

Security reinforcement

In this part, we track the entire process from IIS installation to configuration, analyze the possible security risks, and provide corresponding reinforcement measures.

IIS installation and version Selection

During IIS installation, only necessary components are installed according to specific business needs to avoid security risks arising from installation of all other unnecessary components. If the website runs normally only in the ASP environment, we do not need to install the. net component.

For IIS versions, at least 6.0 and above are required. IIS5.0 has severe security vulnerabilities. However, there are very few servers running IIS5.0, so don't worry too much about this.

IIS configuration

1. Delete the default IIS Site

Delete or disable the site where IIS is installed by default.

2. disable unnecessary Web service extensions

Open the IIS manager and check for unnecessary "Web service extensions". If yes, disable them. 8:

Figure 8

3. IIS access permission Configuration

If there are multiple websites in IIS, we recommend that you configure different anonymous access accounts for each website.

Method:

A. Create an account and add it to the Guests group.

B. "website attributes" ---> "Directory Security" ---> "Identity Authentication and access control", enable "Anonymous Access" and use the newly created account to replace the default account, as shown in figure 9.

Figure 9

4. website directory permission Configuration

Principles (10 ):

The directory has write permission. Do not assign execution permission.

The directory has the execution permission. Do not assign the write permission.

Generally, you need to assign the write permission to the upload directory and database directory, but do not assign the execution permission.

For other directories, only the "read" and "record access" permissions are assigned.

Figure 10

5. Only necessary application extensions are retained

Based on the actual situation of the website, only necessary application extensions are retained, and all others are deleted, especially extremely dangerous extensions such as cer and asa, and generally websites do not need them either, 11.

Figure 11

6. Modify the IIS log file configuration

Regardless of the server, logs should be highly valued. When a security event occurs, we can analyze the log to restore the attack process. Otherwise, the attack will not be detected. If conditions are met, logs can be sent to a dedicated log server for storage.

First, check whether logging is enabled. If logging is not enabled, enable logging. The log format is set to W3C extended log format, which is enabled by default in IIS.

Next, modify the IIS log file storage path, which is saved in the "C: \ WINDOWS \ system32 \ LogFiles" directory by default. Here, change it to the custom path. It is recommended to save the file in a non-SYSTEM disk path, and the directory where the IIS log file is located can only be accessed by Administrators and SYSTEM users, 12.

Figure 12

7. Prevent Information Leakage

A. Disable sending detailed ASP error messages to the client

"IIS manager" ---> "properties" ---> "main directory" ---> "configuration" ---> "debugging", select "Send the following text error message to the client, error message returned when a custom error occurs, 13.

Figure 13

B. Modify the default error page

"IIS manager" ---> "properties" ---> "custom error", which replaces the default page with a custom error page. The following is a custom 404 error page. When a 404 error occurs on the website, this page will be returned to the client, 14.

Figure 14

8. Customize IIS Banner information

By default, the Banner information will leak information about the server type, version, and so on. We need to modify the information to prevent information leakage and cheat some automated scanning and attack tools.

A. Modify the default HTTP header information

Before modification, let's look at the default HTTP header information. We send a request to the IIS server and use the packet capture tool to analyze the data returned by the request to find the HTTP header information, as shown in Figure 15:

Figure 15

The HTTP header information is marked in the red box. Through this information, we can determine that the target website uses the IIS server.

Now let's take a look at how to customize HTTP header information. First, open "IIS manager" ---> "properties" ---> "HTTP header", select the default HTTP header information in "Custom HTTP header", and edit it, or delete the default one and add a new HTTP header. Figure 16 shows a custom HTTP header.

Figure 16

After the modification is complete, capture the package for analysis, as shown in figure 17:

Figure 17

As shown in the figure, the HTTP header returned by the IIS server is already customized.

B. Modify the default IIS header information

Tools are required to modify the default IIS header information. ServerMask is recommended. It is a tool used to hide or modify the default Banner information of the IIS server to prevent information leakage. 18 is the software interface:

Figure 18

Before modification, analyze the default IIS header information, as shown in 19:

Figure 19

Based on the information returned by the Server, we can easily determine that the target website uses IIS, version 6.0, and operating system Windows Server 2003, this information is very helpful for the attacker to determine the next step.

We can also use scanning tools to obtain information about the target website server. There are many such tools, and they are very easy to use, 20.

Figure 20

Now, we can hide or modify the default IIS header information. First, open the software, select the website to be protected, and select the corresponding policy from the drop-down menu at "Security Profile, here I will customize one.

Figure 21

As shown in Figure 21, I changed the default IIS header information to the Apache server information. In this way, attackers can be confused and the real information of the website can be effectively hidden. Now let's analyze the header information returned by the modified IIS server, 22:

Figure 22

Now the header information returned by the IIS server is customized. It is disguised as an Apache server.

Run the scan tool to check whether the Real Server Type of the target website can be obtained. Result 23:

Figure 23

We can see that the scanner does not have the server type of the target website.

For some automated attack tools, the type and version of the target server cannot be obtained, and further attacks cannot be initiated.

Summary

Through examples of IIS attacks and security reinforcement, I believe that readers have a deeper understanding of IIS server security. In fact, it is not difficult for IIS security reinforcement. In many cases, it is more important for administrators to have security awareness. As long as they have sufficient security awareness and the security reinforcement method described above, I believe you will be able to build a secure IIS server