作者：myles007
预估稿费：300RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
本篇实战文档主要是跟大家交流分享学习一份因为一个由于“xml配置文件”的信息泄露在配合各种配置不当和平台漏洞的情况下，最终引发的一起主机沦陷的个人渗透测试学习笔记，仅为个人的学习总结，希望各位路过大大多多指点。
1. xml配置文件信息泄露
通过前期的信息收集，发现了配置文件web.xml直接暴露在网络中，通过读取发现了“数据库连接池”与“后台管理”的访问目录信息。
2. 数据库连接池账号密码暴露
通过前面数据连接池目录/pool/的挖掘，我们可以直接访问本目录，通过目录信息的读取，我们发现平台直接连接后台数据库的账号和密码信息。
3. 管理后台暴露
通过前面配置文件信息泄露的后台管理路径信息，我们直接访问目录/admin，可以直接找到后台的管理界面，具体信息如下。
4. 数据库登陆尝试
我们在获取数据库登陆账号后，直接尝试连接数据库管理后台，通过尝试发现竟然可以直接登录成功，并成功读取了数据库root账号的密码以及后台管理账号的密码信息。
4.1. 数据库管理账号信息挖掘
4.2. 后台管理账号密码挖掘
5. 尝试写入jsp脚本测试
我们在获取后台数据库控制权限后，为进一步获取主机的控制权限，首先想到尝试使用数据库的写入操作权，直接写入jsp脚本，获取主机的控制权限。
5.1. 尝试写入jsp脚本
5.1.1. 写入路径查找
对于写入路径查找，最直接的方法就是访问系统登录页面的的图片路径，收集其存放的的路径信息，当然这里的路径信息可能是相对路径信息，而非物理路径信息，不过我们可以直接测试下，也许我们的运气比较好呢。
图片存放路径收集：/eis/images/login/default/
5.1.2. 写入jsp脚本尝试
我们在获取图片存放路径后，直接尝试进行测试文件的写入，尝试后发现写入失败，具体截图如下。
报错小结：写入报错，回显显示，没有创建和写入权限，那么一般出现这个情况的可能有两种：
1. 我们写入的路径是一个相对路径，并非真实的网站物理路径，故没创建和写入权限；
2. 这个路径的确是物理路径，但是我们真的没有写入权限；
有了以上的总结，我们现在直接写入jsp脚本的想法就泡汤了，接下来我们还是按部就班的去找下apache配置文件，从配置文件中收集站点的真实物理路径信息。
5.1.3. Apache中间配置文件的读取尝试
由于我们已经获取了数据库的后台管理权限，此时我们可以通过后台管理权限进行数据库的“mysql安装目录”、“mysql数据存放目录”以及“mysql的插件目录”，然后进行apache配置文件信息的猜测和读取，具体操作如下。
（1） 数据库相关路径信息收集
>select @@datadir;#数据库存放路径查询
>select @@basedir;#数据库安装路径查询
>select @@plugin_dir; #数据库第三方插件存放路径查询
（2） apache配置文件的读取
通过上面数据库相关目录信息的读取，我们可以猜测apache中间配置文件的路径可能是：/opt/thirdsoft-2.0/apache2/conf/httpd.conf
此时我们通过数据库文件读取函数进行配置文件信息的读取，这里由于直接命令行读取时文件显示不全，这里直接使用了一个数据库管理软件进行登录操作。可能我们的人品比较好，竟然真的读取到了apached的配置文件httpd.conf的内容，我们从其中的DocumentRoot找到的网站的真实存放路径，且到这里我们知道了前面图片路径信息收集时，收集到的路径”/eis”，其实它是个“别名路径”，这里做的还是很到位的。
DocumentRoot "/home/ema/ema-3.4.1/web"
Alias /eis "/home/ema/ema-3.4.1/web"
通过apache配置文件的读取，我们看到站点物理路径是：/home/ema/ema-3.4.1/web/
接下来，就是尝试找到一个可以写入文件的路径，我直接使用数据库写入函数进行jsp脚本的写入了。
5.2. 再次尝试写入jsp脚本
首先我们尝试写入一个测试文本，看是否有写入权限，操作如下。
运气差了点，还是没有写入权限，估计是数据库进程运行权限被降权了，无写入权限。
6. 尝试通过udf自定义函数提权测试
6.1. plugin 插件目录查询
6.2. 尝试写入文件测试
通过写入函数，写入测试数据，写入失败，操作过程如下。
测试结果：写入测试文件失败，可能还是由于当前数据库运行权限过低或目标服务器上并没有plugin目录，默认情况下5.0以上版本是没有此目录的。
7. 上传点getshell测试
以上各种测试失败后，我们尝试直接登录后台查找上传点，查找可以上传jsp脚本的利用点，这里笔者实际测试中测试了多个上传点，最后在平台首页定制的位置找到一个上传点，并成功获取了webshell，且其权限为root权限，有关具体测试利用过程如下。
7.1. 图片上传测试
通过在获取直接上传图片测试，看是否可以找到真实图片的物理访问路径。
7.1.1. 测试过程
（1） 图片上传
直接进行1.jpg图片文件的上传，收集上传后服务返回的相关信息。
（2） 物理路径信息收集
通过图片上传成功后，我们收集到了图片上后的“物理访问路径信息”，具体信息如下：
http://x.x.x.x/eis/images/login/custom/1.jpg
7.1.2. 测试结果
找到图片上传的物理访问路径：http://x.x.x.x/eis/images/login/custom/1.jpg
7.2. 直接上传1.jsp脚本测试
7.2.1. 测试过程
我们现在直接上传1.jsp木马脚本，测试是否可以上传成功。
7.2.2. 测试结果
直接上传1.jsp木马脚本失败了，进过测试发现应该是应用后台对文件类型有安全过滤与检测。
7.3. 尝试抓包改包进行1.jsp上传测试
直接上传1.jsp脚本失败后，我们接下来尝试使用抓包改包绕过的方式，测试脚本上传的可能。
7.3.1. 测试过程
增加文件类型（jsp）测试
通过抓包，我们可以发现当前我们直接上传1.jsp文件的数据包中，有关文件类型仅有图片类型：jpg|gif||png|bmp，故我们测试增加一种jsp文件类型的支持，然后重新发包测试是否可以上传1.jsp成功，经过测试发现1.jsp上传成功。
7.3.2. 测试结果
通过增加上传文件类型的支持，直接绕过了后台的检查，上传1.jsp恶意脚本成功，只要后续能过正常解析1.jsp，即可直接拿下服务。
7.4. 直接上菜刀getshell
7.4.1. 测试过程
此时我们直接访问1.jsp的物理访问路径，测试其是否可以正常解析，访问情况截图如下。
通过上面的访问测试，可以获取1.jsp可以被正常解析，接下了就是上菜刀，直接getshell了。
7.4.2. 测试结果
通过菜刀连接可以获悉，我们直接拿到服务器的root控制权限，服务器彻底沦陷。
8. 主机沦陷回顾
8.1. 本次主机沦陷的整个过程：
（1） 首先，是由于“xml敏感信息泄露”引发数据库连接池目录与管理后台目录信息的泄露；
（2） 随后，由于数据库连接池映射目录的暴露，导致数据库管理账号与密码信息直接暴露在web页面；
（3） 而后，由于数据库的管理允许远程的登录访问，在收集了数据库账号密码信息的情况，又导致了数据库的沦陷；
（4） 再次，就是由于后台管理系统管理账号密码的被读取，导致后台的沦陷；
（5） 最后，我们在后台上找到了上传点的存在，最终导致了平台主机的沦陷。
8.2. 安全加固建议
（1） 对于敏感目录要设置访问控制策略，禁止WEB页面的直接访问，对于不需要的目录连接信息可以考虑删除操作；
（2） 对于管理后台，应下发相应的访问控制策略，当然是在业务允许的条件下进行；
（3） 对于数据库管理，应该想法严格的访问控制，禁止外网的直接登录访问，将数据库的外在威胁降到最低；
（4） 最后是应用平台，也应进行相应的整改，加强对于上传文件的内容进行后台检查，禁止jsp这类脚本文件直接上传的可能；
还没有评论，来说两句吧...