安全路透社
当前位置:安全路透社 > 安全客 > 正文

【技术分享】数据库连接池信息泄露引起的主机沦陷实战记录


本篇实战文档主要是跟大家交流分享学习一份因为一个由于“xml配置文件”的信息泄露在配合各种配置不当和平台漏洞的情况下,最终引发的一起主机沦陷的个人渗透测试学习笔记,仅为个人的学习总结,希望各位路过大大多多指点。


1. xml配置文件信息泄露


通过前期的信息收集,发现了配置文件web.xml直接暴露在网络中,通过读取发现了“数据库连接池”与“后台管理”的访问目录信息。

http://p2.qhimg.com/t011a2b165765d4dd2f.png

http://p7.qhimg.com/t0144c5b81f38b6c885.png


2. 数据库连接池账号密码暴露


通过前面数据连接池目录/pool/的挖掘,我们可以直接访问本目录,通过目录信息的读取,我们发现平台直接连接后台数据库的账号和密码信息。

http://p1.qhimg.com/t01124e04c9c79b651d.png


3. 管理后台暴露


通过前面配置文件信息泄露的后台管理路径信息,我们直接访问目录/admin,可以直接找到后台的管理界面,具体信息如下。

http://p0.qhimg.com/t01b5d2ab0b1e864899.png


4. 数据库登陆尝试


我们在获取数据库登陆账号后,直接尝试连接数据库管理后台,通过尝试发现竟然可以直接登录成功,并成功读取了数据库root账号的密码以及后台管理账号的密码信息。

4.1. 数据库管理账号信息挖掘

http://p3.qhimg.com/t0167415c661fcd129e.png

http://p8.qhimg.com/t01748128747d0f44ae.png

4.2. 后台管理账号密码挖掘

http://p4.qhimg.com/t01fd147db54f9deb0a.png

http://p7.qhimg.com/t01556f8af6298e708d.png


5. 尝试写入jsp脚本测试


我们在获取后台数据库控制权限后,为进一步获取主机的控制权限,首先想到尝试使用数据库的写入操作权,直接写入jsp脚本,获取主机的控制权限。

5.1. 尝试写入jsp脚本

5.1.1. 写入路径查找

对于写入路径查找,最直接的方法就是访问系统登录页面的的图片路径,收集其存放的的路径信息,当然这里的路径信息可能是相对路径信息,而非物理路径信息,不过我们可以直接测试下,也许我们的运气比较好呢。

图片存放路径收集:/eis/images/login/default/

http://p2.qhimg.com/t01d7fd83a69bd9083d.png

5.1.2. 写入jsp脚本尝试

我们在获取图片存放路径后,直接尝试进行测试文件的写入,尝试后发现写入失败,具体截图如下。

http://p9.qhimg.com/t010efd82ad9b68addd.png

报错小结:写入报错,回显显示,没有创建和写入权限,那么一般出现这个情况的可能有两种:

1. 我们写入的路径是一个相对路径,并非真实的网站物理路径,故没创建和写入权限;

2. 这个路径的确是物理路径,但是我们真的没有写入权限;

有了以上的总结,我们现在直接写入jsp脚本的想法就泡汤了,接下来我们还是按部就班的去找下apache配置文件,从配置文件中收集站点的真实物理路径信息。

5.1.3. Apache中间配置文件的读取尝试

由于我们已经获取了数据库的后台管理权限,此时我们可以通过后台管理权限进行数据库的“mysql安装目录”、“mysql数据存放目录”以及“mysql的插件目录”,然后进行apache配置文件信息的猜测和读取,具体操作如下。

(1) 数据库相关路径信息收集

>select @@datadir;#数据库存放路径查询
>select @@basedir;#数据库安装路径查询
>select @@plugin_dir;  #数据库第三方插件存放路径查询

http://p8.qhimg.com/t015cb15e730ce7378b.png

(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"

http://p7.qhimg.com/t0192c6809c0329696d.png

通过apache配置文件的读取,我们看到站点物理路径是:/home/ema/ema-3.4.1/web/

接下来,就是尝试找到一个可以写入文件的路径,我直接使用数据库写入函数进行jsp脚本的写入了。

5.2. 再次尝试写入jsp脚本

首先我们尝试写入一个测试文本,看是否有写入权限,操作如下。

http://p2.qhimg.com/t01a3ec261cbacba8c5.png

运气差了点,还是没有写入权限,估计是数据库进程运行权限被降权了,无写入权限。

6. 尝试通过udf自定义函数提权测试


6.1. plugin 插件目录查询

http://p9.qhimg.com/t01a85a80b29a514a1d.png

6.2. 尝试写入文件测试

通过写入函数,写入测试数据,写入失败,操作过程如下。

http://p5.qhimg.com/t016bdb783c0f82daf4.png

测试结果:写入测试文件失败,可能还是由于当前数据库运行权限过低或目标服务器上并没有plugin目录,默认情况下5.0以上版本是没有此目录的。


7. 上传点getshell测试


以上各种测试失败后,我们尝试直接登录后台查找上传点,查找可以上传jsp脚本的利用点,这里笔者实际测试中测试了多个上传点,最后在平台首页定制的位置找到一个上传点,并成功获取了webshell,且其权限为root权限,有关具体测试利用过程如下。

http://p2.qhimg.com/t016a5f6185ba269b90.png

7.1. 图片上传测试

通过在获取直接上传图片测试,看是否可以找到真实图片的物理访问路径。

7.1.1. 测试过程

(1) 图片上传

直接进行1.jpg图片文件的上传,收集上传后服务返回的相关信息。

http://p8.qhimg.com/t016047c0232c9e3334.png

(2) 物理路径信息收集

通过图片上传成功后,我们收集到了图片上后的“物理访问路径信息”,具体信息如下:

http://x.x.x.x/eis/images/login/custom/1.jpg

http://p8.qhimg.com/t0110fedd758ae19205.png

7.1.2. 测试结果

找到图片上传的物理访问路径:http://x.x.x.x/eis/images/login/custom/1.jpg 

7.2. 直接上传1.jsp脚本测试

7.2.1. 测试过程

我们现在直接上传1.jsp木马脚本,测试是否可以上传成功。

http://p4.qhimg.com/t01494d93bf2131a618.png

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上传成功。

http://p8.qhimg.com/t01a82f4b500c1e9ba0.png

http://p5.qhimg.com/t018beba0d874c3d064.png

http://p2.qhimg.com/t01a5b8a0948b15096e.png

7.3.2. 测试结果

通过增加上传文件类型的支持,直接绕过了后台的检查,上传1.jsp恶意脚本成功,只要后续能过正常解析1.jsp,即可直接拿下服务。

7.4. 直接上菜刀getshell

7.4.1. 测试过程

此时我们直接访问1.jsp的物理访问路径,测试其是否可以正常解析,访问情况截图如下。

http://p9.qhimg.com/t01d24c34592beb3e6c.png

通过上面的访问测试,可以获取1.jsp可以被正常解析,接下了就是上菜刀,直接getshell了。

http://p8.qhimg.com/t01fd52d418f4c354c7.png

http://p7.qhimg.com/t0144d861a93800c13c.png

7.4.2. 测试结果

通过菜刀连接可以获悉,我们直接拿到服务器的root控制权限,服务器彻底沦陷。


8. 主机沦陷回顾


8.1. 本次主机沦陷的整个过程:

(1) 首先,是由于“xml敏感信息泄露”引发数据库连接池目录与管理后台目录信息的泄露;

(2) 随后,由于数据库连接池映射目录的暴露,导致数据库管理账号与密码信息直接暴露在web页面;

(3) 而后,由于数据库的管理允许远程的登录访问,在收集了数据库账号密码信息的情况,又导致了数据库的沦陷;

(4) 再次,就是由于后台管理系统管理账号密码的被读取,导致后台的沦陷;

(5) 最后,我们在后台上找到了上传点的存在,最终导致了平台主机的沦陷。

8.2. 安全加固建议

(1) 对于敏感目录要设置访问控制策略,禁止WEB页面的直接访问,对于不需要的目录连接信息可以考虑删除操作;

(2) 对于管理后台,应下发相应的访问控制策略,当然是在业务允许的条件下进行;

(3) 对于数据库管理,应该想法严格的访问控制,禁止外网的直接登录访问,将数据库的外在威胁降到最低;

(4) 最后是应用平台,也应进行相应的整改,加强对于上传文件的内容进行后台检查,禁止jsp这类脚本文件直接上传的可能;


本文地址:http://bobao.360.cn/learning/detail/4219.html

未经允许不得转载:安全路透社 » 【技术分享】数据库连接池信息泄露引起的主机沦陷实战记录

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册