【技术分享】数据库连接池信息泄露引起的主机沦陷实战记录
作者:admin | 时间:2017-8-9 11:17:49 | 分类:黑客技术 隐藏侧边栏展开侧边栏
本篇实战文档主要是跟大家交流分享学习一份因为一个由于“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) 数据库相关路径信息收集
1
2
3
|
>select @@datadir;#数据库存放路径查询
>select @@basedir;#数据库安装路径查询
>select @@plugin_dir; #数据库第三方插件存放路径查询
|
(2) apache配置文件的读取
通过上面数据库相关目录信息的读取,我们可以猜测apache中间配置文件的路径可能是:/opt/thirdsoft-2.0/apache2/conf/httpd.conf
此时我们通过数据库文件读取函数进行配置文件信息的读取,这里由于直接命令行读取时文件显示不全,这里直接使用了一个数据库管理软件进行登录操作。可能我们的人品比较好,竟然真的读取到了apached的配置文件httpd.conf的内容,我们从其中的DocumentRoot找到的网站的真实存放路径,且到这里我们知道了前面图片路径信息收集时,收集到的路径”/eis”,其实它是个“别名路径”,这里做的还是很到位的。
1
2
|
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) 物理路径信息收集
通过图片上传成功后,我们收集到了图片上后的“物理访问路径信息”,具体信息如下:
1
|
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这类脚本文件直接上传的可能;
本文由 安全客 原创发布,作者:myles007