Explanation of IIS write permission exploitation and write permission vulnerability

I wrote an article three and a half years ago:Try IIS write permission and move to aspAt that time, there was still a problem. This article was used to solve the problems left over from that year.

Many people may think that iis put is not worth mentioning... in fact, Party B always encounters IIS write permission issues when providing security services to customers. On the one hand, WVS7.0 can scan and use POC to successfully write the vulnerability target, on the other hand, boring Turkish or Indonesian hackers always like to use the write permission to upload txt or html to the vulnerability target, to show that the other party's hack technology is powerful.

Currently, we have seen the use of IIS write permissions. To put it bluntly, the cainiao administrator has incorrect IIS configuration (due to two incorrect configurations ):
1. Set WebDAV to allow in the WEB server extension;
2. The write permission is enabled in the website permission configuration.

For WebDAV, see the introduction of Baidu Encyclopedia:

Web-based Distributed Authoring and Versioning is a communication protocol based on the HTTP 1.1 protocol. it extends HTTP 1.1 and adds some new methods in addition to GET, POST, HEAD, and other HTTP standard methods so that applications can directly read and write to the Web Server, it also supports write Locking and Unlock, and supports file version control.

Many client tools provided by Microsoft can publish and manage Web resources through WebDAV. However, normal Web websites are generally not used. Therefore, generally, WebDAV is not allowed at all.
As for the write permission, everyone understands that the write permission is to allow PUT and has no connection with the website's own operation permission. If it is enabled, there is no security awareness.

So what I want to say is that the so-called IIS write permission vulnerability is actually a man-made fault. A qualified server administrator should not make such a mistake...

The exploitation of vulnerabilities is clear to everyone. It has been around for many years. We all know that zwell's IIS put scripts and Veteran's write permission exploitation tools are used to obtain a webshell. In fact, they PUT a txt file first, MOVE to asp. For details, see html "target = _ blank>Try IIS write permission and move to aspBut this article leaves a problem: in X-Powered-By: ASP. NET is... NET environment), returns 207 Multi-Status.

This question had been entangled for a long time and was never answered. Until the IIS6.0 File Parsing Vulnerability was discovered, the problem was solved by myself. It took a long time, And someone mentioned it:
PUT a txt file to the server, such as oldjun.txt, and then

MOVE/oldjun.txt HTTP/1.1
Host: www.oldjun.com
Destination: http://up.2cto.com/Article/201012/20101217103833650.jpg

The packet can be sent by using nc, and the returned http status code is 202, which indicates that the MOVE is successful.

If you do not have the write permission, you can use this tool to traverse the directory to browse the file. If you have enabled the write permission, you can easily grasp the website...