客户现场的一次PostgreSQL注入

文章来自本人freebuf的文章
https://www.freebuf.com/vuls/361294.html

1、前言：

有网友评论我前面写的太水…呜呜呜，很少发文章，因为需要处理敏感信息，感觉很麻烦，发了师傅们却看不上眼…

首先说明一下，我在文章开头提示了一下，原始报告没有了，还有思维导图的攻击链路分析也没了，只是剩下的初始笔记，都在一个深夜…硬盘…，说多了都是气，现在我换成了机械，而且配合网盘，但是一些敏感信息还是不敢上传网盘，毕竟我身边有过真实案例，上传到了网盘，被 J C打电话上门…

贴图。

2、客户现场的一次PostgreSQL注入

今天不分析流量，也不应急。渗透网站。

2.1 放主页图

什么也不给，就给个页面，你这不是为难我吗，问了客户，有什么注意事项，比如不能上传马子之类的，客户说: "不能影响业务，不能删除数据，不能影响站点运行，不能上传恶意文件…”

我心想：这也没有注册功能，也不提供测试账号，就给我个页面，进不去就只能在外面转圈，我怎么上传恶意文件，，，除非组件有公开的漏洞。

经过一番信息收集，一番折腾，确实，组件没漏洞，都是最新版，即使不是最新版，也可能都有了补丁，甚至这个cms改动很大，没有识别出来，后续进系统之后，发现各种接口都是专属于这个系统的，专属于客户起的名字，网上很难找到类似的。

开始搞吧，

• 弱口令：失败

多次以后，锁定了3分钟，发现不像大家所写的报告中那样，用户名可枚举，密码爆破之类的。

2.2、Fuzz

没啥招啊，开始，fuzz后台和接口，因为，线程量过大，就限制访问…，那就设置延迟，5秒一个包。

让工具去扫吧，手工搞其他的。

既然只有登录功能，那就，就地开工，掘地三尺，老子今天也要进系统。

2.3、登录框 - SQL注入

因为前期信息收集了解到后端使用的数据库是postgresql，开始登录框测试

userName=admin'and'a'='a&password=admin

返回包：

再来：

userName=admin'and'm'='s

嘿，感觉有戏，上工具。sqlmap跑一跑，注入漏洞不能少。

果然可以

爆数据库

python sqlmap.py -u "http://x.x.x.x" --current-db --batch

有public数据库

爆出所有的表，好家伙，好几十个表

python sqlmap.py -u "http://x.x.x.x" -D public --tables

找到用户信息的表，出数据

python sqlmap.py -u "http://x.x.x.x" -D public -T users C "username.password" --dump --batch

哈哈，进系统（不好意思，打码太多了，不打码就泄露用户的网站了）

2.4、第二处 - SQL注入：

都进来了，不搞出一堆洞，多对不起客户，连个测试账号也不提供，哼@–@

开始

.

登录后，找到一个接口，

再测，第一次：返回查询成功

第二次返回：暂无数据

再次sqlmap跑起来，又一处注入。

而且这一处属于高危，因为是系统数据，后面测试，不用登录账号，也可以查询并注入，属于未授权查询+SQL注入

心里暗暗一笑，没事了，起码今天有交代了，在搞几个业务逻辑的洞，就可以报告了。

2.5、会话固定+cookie退出不失效：

经过反反复复的登录退出管理员账户和普通账户，发现用户登录时，服务端每次发放的cookie值不变，难道是浏览器缓存问题？

清空浏览器缓存后，依然是同一个cookie，妥了，后端居然是写死的cookie，给每个用户绑定了自己的cookie，其实不是cookie，是cookie里面包含的token，服务端将token放在了Cookie里。

格式为：Cookie：token=xxxxxxxxxxx；

第一次的cookie：

第二次登录，服务端下发的Set-Cookie：

要不说这个cms是改动很大的。互联网上找不到类似的资产，要不然不捡漏个CNVD或CVE了，可惜了。

2.6、越权修改密码

找啊找，寻啊寻，到了修改密码的地方，好家伙，没有专属的后台，这页面管理员登录后，就可以改所有账户。

都发现修改用户的接口了，心想这不来几个越权的洞，怎么行

登录管理员，抓包修改密码的接口，用低权限的用户的cookie去改其他用户的密码。

搞定，越权一枚。

2.7、修改密码处逻辑错误

当我处在管理员账户页面时，可以看到所有账户，所有账户的密码也都以加密的方式存储在了前端，加密方式是base64，这个地方后续也写在了报告里面。

我点击了保存以后，退出账号，再次登录，所有用户都登录不上了。

纳尼？？？当时惊了，不会吧，没有做什么高危操作啊！这怎么回事…我惊慌失措，坏了，不会要犯错吧，这大白天的，大家可都在工作啊，等会大家都反应系统登不上了，我怎么收拾残局啊，领导可是亲口告诉我的，不能影响业务！！不能影响业务！！！

这时往上看，有sql注入啊，再看一次用户信息表，到底怎么回事，@–@，再次通过注入漏洞，看了一下用户信息的表，发现密码，之前都是明文存放在数据库啊，base64解码后才看到明文，前面说了，是base64加密方式存储在了客户端。

瞬间明白了，原来是点击保存后，前端或者后端将存储在前端的base64密码，直接提交给了数据库，所以密码变成了base64，如果登录，要将密码编码成base64，然后当作密码登录。

我的天，可坑死我了。。。今天差点闯祸。

然后登录管理员账户，将所有用户的密码改过来，喘了一口气，瞬间放松了。

2.8、git源码泄露

还记得刚开始的fuzz吗，对，出结果了，哈哈，扫出了git目录，二话不说上工具。

GitHack: https://github.com/lijiejie/GitHack

很无奈，尽然都是前端的源码，老子都进入系统了，也知道了登录密码加密方式。前端源码貌似用处不大。

要是有后端源码，这不就知道哪个cms了，真是白惊喜一场。

后续还有很多未授权访问，工具并没有扫出来，都是登录后发现的，由于没有啥技术含量，这里不提了。

3、总结

结束，其实这个站的其他地方也有漏洞，有验证码失效的，越权的，由于当时给客户的是word文档格式，很多东西要重新写成markdown格式，发出来需要打码，一个图一个图的审核，怕泄露敏感信息。

上面写这个经历，就当给大家一个警醒吧，渗透测试过程中一定要注意，每个测试项，测试之前都要去想一下有没有什么危害，给客户做渗透，不是打护网，可以不记手法的拿权限。当然护网也不能该人家数据，如果不慎修改或删除了，没有办法还原，一定及时与客户沟通。

最后提醒大家一下，挖洞思路千万条，业务安全第一条，挖洞不规范，局里好几年。

感谢大家看完写的文章，工作之余尽量多写，一边提高个人能力，也跟大家分享真实的渗透